14:02 <_49616e> hexdump0815: boot@SDC works perfectly fine for me on cold boots now, it's 100% reliable so far. Initially it didn't work for me because I messed up the bootloader stuff on the SD card, so the bootrom simply gave up and loaded everything from the emmc anyway. I was expecting the bootrom to simply give up or enter USB burn mode instead.

14:05 <_49616e> I'll test more USB drives with boot@USB in the upcoming days to find out if it actually works with a mass storage device or not.

16:28 <hexdump0815> xdarklight: i think i'm giving up on the idea of a proper s905w u-boot as the hardware around seems to be too mixed so that this would make sense

16:29 <hexdump0815> xdarklight: i built a u-boot based on libretech-cc with the s905w supporting bl30.bin and bl31.img from the khadas commit you mentioned and tested it on 4 different s905w tv boxes:

16:30 <hexdump0815> xdarklight: 1. it boots and runs fine if i cap the scpi clocks via the patch mentioned above (but then only up to 667mhz) and crashes otherwise

16:31 <hexdump0815> xdarklight: 2. u-boot already fails already in the bl2 stage (i tried all bl2 blobs i could find) with "Wrong chip c0"

16:32 <hexdump0815> xdarklight: 3. works perfectly fine like a full s905x with clocks up to 1.5ghz :)

16:32 <hexdump0815> xdarklight: 4. like 1.

16:34 <hexdump0815> xdarklight: my guess is that amlogic is throwing out new s905w all the time with a newer version info and bl2 seems to check the version number and if it does not know it fail ...

16:36 <hexdump0815> _49616e: for me it did not work on the fist boot, i.e. the SD was missing before the EMMC in the initial boot line ... i guess its similar to what i wrote above: tv box hardware is so mixed that you cannot really trust on things to work in a reproducable way across different boxes :)

16:38 <hexdump0815> _49616e: looking forward to more boot@USB results from you - lets see if you get anything working

16:48 <xdarklight> hexdump0815: that's strange, maybe some of these boards have different CPU voltage regulators as others (those are also managed by BL*, not by u-boot or Linux)

16:49 <xdarklight> you can enable pwm_cd and pwm_ef (just enable it in .dts with status = "okay"; and no other properties). then cat /sys/kernel/debug/pwm should show the period and duty cycle that BL* configures for the current frequency (based on that we can calculate the voltage)

16:50 <hexdump0815> xdarklight: but would this also explain that "Wrong chip" error?

16:50 <xdarklight> on Meson8b boards there are some with 1148ns (like Endless Mini EC-100) and others with 12218ns (like Odroid-C1). that would explain why some boards are crashing at some frequencies or work at higher speeds than advertised

16:50 <xdarklight> no it doesn't solve that problem

16:52 <hexdump0815> xdarklight: another thing i noticed is that the memory freq was initialized differently - native u-boot on the boxes always initialized it at 7xx mhz while any u-boot i built with different combinations of bl2 always initialized it at 920 mhz - might be a problem too ...

16:54 <hexdump0815> xdarklight: i even got the bl2 and bl31 build string matched exactly with some of the blobs for one box, but it still behaved differently even before u-boot actually takes over ... i think tv boxes are not really the best hardware for trying to standardize anything upon :)

16:57 <hexdump0815> xdarklight: if there would be sources for those blxy parts things could be better, but this way there is no real chance besides trying something which hopefully works or fail ...

16:59 <_49616e> xdarklight:

17:00 <_49616e> Whoops. I was meant to say the MMC_CAP_ERASE worked fine for me, I'll set up something to test data integrity later.

17:02 <_49616e> My idea is to have multiple medium-sized files with random contents, calculate their hashes, create more random files, delete them, run fstrim, reboot and check verify the checksums.

17:03 <_49616e> I can also hash everything in /usr, /bin, /sbin and check those after reboot as well.

17:55 <xdarklight> hexdump0815: weird, that's why I don't like blobs

17:55 <xdarklight> _49616e: sounds great, looking forward to your results :)

21:36 <_49616e> hexdump0815: I've tried boot@USB with several flash drives including card readers. The bootom stops at here (POC:3;RCY:1;USB:3;) for a few seconds and then carried on to boot from the emmc. I've tried both USB ports on the board, and neither port worked for me. The card readers have LED indicators on them which never flashed, it makes me suspect that the board is not communicating with the USB devices at all.

21:38 <_49616e> I don't have the hardware to sniff USB packets, so that's all I can do at the moment. I can also confirm that the USB devices are being properly powered.

21:42 <_49616e> It also could simply be my USB sticks not having the correct data that the SoC expects. I just wrote the first 2MB of the emmc data to the drives.

22:46 <_49616e> By the way, can someone help me a little for porting the Android devicetree to something that the Linux kernel can use? I'm completely lost on this one: https://file.io/XVlhXx