<f_>
AFAIK eMMC on GXL and GXBB are identical though (at least that's what xdarklight said)
<f_>
And indeed I can reproduce the exact same issue on both.
<f_>
At that point I think I'll just rip out all eMMC init code...BL2 uses the eMMC without init anyway
<f_>
or try with the full MMC driver framework rather than the tinyified one currently in use (not sure if that's the issue, but it's still worth a try)
<f_>
hexdump0815: Other than that and USB and code cleanup, should be good to go upstream
<f_>
In the future, on GXL, I'd like to also get lafrite booting, which is currently not possible now (theoretically) because lafrite uses DDR4 IIRC
<hexdump0815>
f_: looking forward to have all this in the regular u-boot one day - not so long ago i would have never thought that something like this will ever happen
<f_>
I think it was just me who went way too far.
<f_>
went from "I want linux on my box" to "I want U-Boot SPL on my box" lol
<f_>
hexdump0815: Testing welcome, too!
<f_>
Especially with different DRAM rank modes
<f_>
Oh, speaking of upstreaming..
<f_>
Kwiboo: Wish to upstream your gxbb BL31 patch?
vagrantc has joined #linux-amlogic
<f_>
Perhaps with an "AML_U_BOOT_SPL" #define to enable at compile-time to keep BL2 support
<f_>
Overall I'm pretty happy with how well it went
<f_>
and, pretty cool, TV box didn't panic. stress-ng has been running for a while, stress-testing RAM.
<f_>
stress-ng: info: [2101] passed: 12: cpu (4) io (4) vm (4)
<f_>
stress-ng: info: [2101] failed: 0
<f_>
So AFAICT this is pretty solid and stable now...
<f_>
I'll say it again, testing is very much appreciated to discover/fix remaining bugs I haven't seen
<hexdump0815>
f_: i'll try to do some testing when i find enough energy and time for it - i can test on odroid c2 (gxbb) and a few gxl tv boxes
<hexdump0815>
and when are get there also some g12a and sm1tv boxes