<apritzel>
smaeul: does RTC wakeup in Linux work with crust? IIUC this works via Linux doing all the setup, and crust waiting for the IRQ to fire?
<apritzel>
smaeul: in this case I guess it doesn't work on the H616 easily?
<apritzel>
Unless we do something in TF-A, like bringing the system down as much as we can, then putting core 0 in WFI?
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
<megi>
apritzel: I think crust just busy polls the irq flags
apritzel has quit [Ping timeout: 480 seconds]
ftg has quit []
_whitelogger has joined #linux-sunxi
<smaeul>
yes, that's correct. Linux does all the setup and crust polls the R_INTC status bits
<smaeul>
apritzel: for H616, you can rely on the CPUIDLE hardware to turn your CPU back on when the IRQ triggers
<smaeul>
so after doing all of the setup (DRAM, bus clocks, DCXO, etc.) in TF-A, you can actually turn all 4 CPUs off
vagrantc has quit [Quit: leaving]
swiftgeek has joined #linux-sunxi
<swiftgeek>
at least it's the same server as postmarketos :D
<wens>
libv: I think #cedrus has served its purpose. Now that everything is in mainline, and H.264 and VP8 stateless is released, eveything should be going through standard V4L2 APIs
<wens>
granted cedrus is still special in that of the hardware supporting stateless, it is the only one that expects slices vs frames
smaeul has quit [Quit: cya]
smaeul has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
insep has joined #linux-sunxi
tllim has quit [Remote host closed the connection]
<libv>
my plan from day 1: do not touch powervr, as its driver/firmware structure is an unstable/moving target, free the other vendors, and force img to do this work on its own
<libv>
i had to convince 2 people to stop looking at powervr, rob clark went to qualcomm, and eric faye lund went to tegra
<libv>
vivante only happened a few weeks later
<libv>
but this is why people have not touched powervr properly
<libv>
despite omap and beagleboard, despite the a80, despite renesas still sticking to powervr
<megi>
btw, do you have a guess on what GPU this might be?
<libv>
powervr
<libv>
they are hiring for this specific task
<libv>
and they have of course shot down my application already, without even having a chat
<megi>
oh, well
<megi>
I guess they'll not be in a rush to support older variants of their GPU, so this is only interesting for the current/future versions
<libv>
depends
<libv>
i am very certain that this is because they want to play in the risc-v ecosystem
<libv>
i am very certain that there is someone employed by img already
<libv>
and it remains to be seen just how related this persons experience really is
Danct12 has joined #linux-sunxi
<libv>
i went through this with modesetting, intel hired keithp, who never cared about graphics drivers a day in his life
<libv>
but with danvet posting that, i am very certain that this already is well underway
<rellla>
we can keep them and just see, what will happen...
ats has joined #linux-sunxi
<jernej>
it would be nice to mention also OFTC there, otherwise no people will really notice it
<jernej>
some might even try libera.chat
<rellla>
i guess, it's horribly outdated, too...
Daanct12 has joined #linux-sunxi
Daanct12 has quit []
Danct12 has quit [Ping timeout: 480 seconds]
diego71 has joined #linux-sunxi
<libv>
i will get to that now, now that the 4.5y old is in his bed, and i adjusted the bearings on the biketrailer ahead of the tour tomorrow (he's been relegated back to the trailer as a punishment ;))
Xalius has quit [Quit: Leaving]
<libv>
jernej: we had some spam yesterday or the day before
<libv>
freenode vs libera psyops or something
ats has quit []
ats has joined #linux-sunxi
ats has quit []
pentabarf has joined #linux-sunxi
ats has joined #linux-sunxi
ats has quit []
ats has joined #linux-sunxi
pentabarf1 has joined #linux-sunxi
pentabarf1 has left #linux-sunxi [#linux-sunxi]
pentabarf has quit []
pentabarf1 has joined #linux-sunxi
<pentabarf1>
Hi, I am working with NanoPi Neo Core (Allwinner H3) and got stuck running secure boot with the internal eMMC. I successfully got it working for booting from SD-Card unsing https://pastebin.com/Aw5q6bdU to burn ROTPK to eFUSES and generating TOC0 with the correct Key by using jemk script (https://gist.github.com/jemk/2abcab1359c4bce793679c5854062331). When i write TOC0 to eMMC and boot without SD inserted the boa
<pentabarf1>
to boot from SD. Before burning eFUSES and without TOC0 the board was booting from eMMC when no SD was inserted. Did burning eFUSES or writing TOC0 to eMMC somehow disabled eMMC as bootable device?
<apritzel>
pentabarf1: where do you write your TOC0 to, exactly? Sector 16 of the eMMC data area? Or into the eMMC boot partition?
<vagrantc>
hrm. my attempts to get ethernet working on orange pi plus may be somewhat moot ... seems to have stability issues on linux 5.10.x ... just silently hangs now and then
<pentabarf1>
apritzel: i am booting from SD and retrieve SPL by using dd if=/dev/mmcblk2 of=sunxi-spl.bin bs=8k skip=1 count=3 then i create TOC0 with jemk script from it and put it back by using sudo dd if=sboot.toc0 of=/dev/mmcblk2 bs=1024 seek=8
<pentabarf1>
i was doing it the same way for SD cards and it worked
<apritzel>
pentabarf1: I wonder if there is something left on the eMMC that spoils the checksum?
<apritzel>
can you try to zero out from 8k to 40k, before writing TOC0
<apritzel>
pentabarf1: in general I am not sure if someone has tried eMMC boot under the secure fuse before, tbh
<apritzel>
pentabarf1: so there might be indeed some surprises lurking
<apritzel>
pentabarf1: why do you actually copy the SPL from the eMMC first? You are booting with TOC0 on the SD card, right? Just use that same one for the eMMC
<pentabarf1>
apritzel: like this? dd if=/dev/zero of=/dev/mmcblk2 bs=8k seek=1 count=4
<apritzel>
yes
<apritzel>
IIRC TOC0 is slightly larger than the eGON image, not sure if there is something affecting the checksum there (I might be wrong, though, but worth a try)
<pentabarf1>
yes i already used the same SPL from SD card. but i thougt maybe there was some change when wrote the system to emmc by using nand-sata-install. thats why. i am not firm with all of this tbh
<pentabarf1>
the reason for all of this is to impede booting unknwon SD cards. but i need the system on emmc because my application makes use of the SD slot
<apritzel>
pentabarf1: from all I know the BROM *almost* always prefers SD card over eMMC
<apritzel>
so if you have something bootable in the SD slot, it will boot that
<apritzel>
there *might* be some fuse to turn that off, but I haven't actually seen anything like that before
<pentabarf1>
thats right, but without the correct key in TOC0 probably it won't ?
<apritzel>
that's correct
<pentabarf1>
this is already working. when i insert a SD with a fresh image it will not boot. after writing TOC0 with the correct key to it it will
<apritzel>
OK, good
<apritzel>
but now you are booting with an empty SD slot, and it doesn't like your eMMC TOC0?
<pentabarf1>
yes. i get: Trying to boot from MMC1 MMC: no card present spl: mmc init failed with error: -123 SPL: failed to boot from all boot devices
<pentabarf1>
and MMC1 is SD. it should switch to MMC2 which is eMMC. normaly (without burned fuses and without toc0) it will
<apritzel>
yes, it should
<apritzel>
maybe the detection algorithm doesn't work correctly?
<apritzel>
I thought jemk's script takes care of that ...
<apritzel>
normally the BROM writes the boot source (SD/eMMC/SPI/NAND) to offset 0x28 of the area where the SPL is loaded
<apritzel>
and U-Boot looks in there to know where to find U-Boot proper
<pentabarf1>
ok i was zeroing out from 8k to 40k ... still the same
<apritzel>
yeah, otherwise you wouldn't see SPL messages
<apritzel>
(I was assuming it was completely silent)
<pentabarf1>
it is silent without writing the toc0 to eMMC
<pentabarf1>
so it has to look on the eMMC. but i am wondering why it tries to boot from MMC1
<apritzel>
probably because it reads the bootsource wrongly
<apritzel>
not even sure the BROM writes it to that address in secure boot mode
<pentabarf1>
i dont know much about it but there is the TOC0 Main Header entry "BOOT_MEDIA" which is set to 0 by jemk script. i played arount and set it to 1 or 2, but it had no effect
<apritzel>
yeah, I remember that was some code to fix this up
<apritzel>
pentabarf1: you can look at smaeul's TOC0 efforts, he made this work more directly, without needing a conversion script
<pentabarf1>
to get it right: BROM is deciding which boot source to use and writes it to 0x28 and then loads SPL which loads u-boot. and u-boot uses boot source from 0x28?
<pentabarf1>
0x28 -> 0x20
<apritzel>
0x28 is the offset for eGON, 0x20 for TOC0
<apritzel>
and the SPL already needs to know the boot source
<apritzel>
to know where to find the "rest" of U-Boot (U-Boot propeR)
<pentabarf1>
so i need to modify SPL to look at 0x20?
<apritzel>
pentabarf1: I was under the impression that jemk's script did this already, somehow
<apritzel>
otherwise look at the top patch in smaeul's toc0 branch (I linked above)
<apritzel>
which does exactly that
<apritzel>
(it actually breaks eGON boots, so needs some work still, but you get the idea)
<pentabarf1>
maybe jemk's script is not doing it but it is working becaus 0 is default and is also for SD
<apritzel>
yeah, something like that
<apritzel>
but I seem to remember there was some nifty hackery around the boot source in that script
<apritzel>
pentabarf1: you might want to hack it, similar to smaeul's top patch
<pentabarf1>
btw thanks for your help your presumtions seem to make sense and everything is clarifying a little bit for me
<apritzel>
or even worse: you can just force the boot source to always be MMC2 ;-)
<pentabarf1>
how would you do that? would be okay for me
<pentabarf1>
i am not into ruby but i will have a look at mktoc0.rb
<apritzel>
pentabarf1: me neither ;-) I meant to hack the U-Boot source to actually ignore the BROM written boot source, and always use MMC2
<apritzel>
just to prove that this is the source of your problem - and to move it forward ;-)
<pentabarf1>
mktoc0.rb: it reads the key, creates a cert of it and makes an toc0 item header entry for it. also it makes an toc0 item entry for firmware item and pack everything to toc0 with toc0 main header and creates an output file of it. there is nothing about a boot source
<pentabarf1>
ah okay hacking u-boot should be doable. but you said that SPL also needs the boot source?
<apritzel>
the SPL is part of U-Boot, and gets compiled with it (if that was your concern)
<pentabarf1>
okay and i can use the smaeul path to achieve this?
<apritzel>
pentabarf1: yes, you should switch to smaeul's tree, that is the much better solution
<apritzel>
I don't think that jemk's script will go anywhere
<apritzel>
smaeul has a proper mkimage port, so we can natively create a TOC0 image as part of the U-Boot build process
<pentabarf1>
cool. will it also handle the key? or do i have to replace the TOC0 by my modified one afterwards?
<apritzel>
and I think someone did another script, based on jemk's, to fix this, and this took care of the boot source
<pentabarf1>
unfortunately there are no forks
<apritzel>
pentabarf1: ah, found it, in my /usr/local/bin ;-) egon2toc.rb