<f_>
I also confirmed when running bl2 that it's an SPL-related issue
<f_>
this box isn't dying anytime soon
Terry13732293409 has quit [Read error: Connection reset by peer]
Terry13732293409 has joined #linux-amlogic
f_[xmpp] has joined #linux-amlogic
psydroid has joined #linux-amlogic
stylon has joined #linux-amlogic
stylon has quit [Client Quit]
<f_>
I tried Kwiboo's BL30X binaries and they result in the same behaviour
<f_>
It must be sending the firmware to the scp that borks (I have nothing else to check)
<f_>
But first I'd like to see if gxl panics too.
<f_>
hm gxl reboots without warning?
<f_>
Must be the watchdog not properly disabled.
<f_>
(which it isn't)
<f_>
Then it may be why you should never attempt to run gxbb linux things on gxl
* f_
remembers that the exact same kernel package is used on *all* amlogic things, in pmOS world
<f_>
lvrp16: I learned something today, never ever ever power boards with a USB-A-to-USB-A cable connected to your computer
<f_>
(unless running things from USB)
<f_>
the resets were because of low power!
<lvrp16>
f_: yeah USB 2.0 is 0.5A, 3.0 is 0.9A
<f_>
Plugged in to something that *actually* provides enough power now, doesn't reset.
<lvrp16>
The moment you power on the EE domain...
<f_>
lvrp16: It was plugged into the eSATAp port
<lvrp16>
It might work with one of those 1A or 1.5A ports
<lvrp16>
but you're driving all of the circuits backwards
<f_>
Anyway, I can't reproduce the SCP firmware issue on gxl, yay.
<lvrp16>
so if there's a limit somewhere, whatever regulators behind that won't work
vagrantc has joined #linux-amlogic
<lvrp16>
SCP firmware issue?
<f_>
Yeah on gxbb linux kernel oopses and sometimes even kernel panics, probably because of SCP (as when it tries to restart it doesn't actually restart..)
<f_>
When booting from U-Boot SPL, that is.
<f_>
But I can't reproduce this issue on gxl, lepotato at least.
<lvrp16>
Are you using HK's SCP?
<lvrp16>
They have that funny single core overclock control thing
<f_>
I initially tried with WeTek Play2 SCP firmware
<f_>
But it also doesn't work when using Kwiboo's modified HK BL301
<f_>
lvrp16: oh BTW have you got a lepotato right now and would like to test SPL?
<lvrp16>
I am on the road today but I can test tomorrow
<lvrp16>
6 hour drive
<f_>
Sure, I'll write instructions to test
<lvrp16>
great, I'll give it a go. If it works well, I'm gonna switch to it
<f_>
Switch to it? Literally?
<lvrp16>
although I think you said the eMMC or SPI still has issues?
<lvrp16>
yeah for the bootloader builder
<f_>
eMMC still has issues, yes. Haven't tested SPI.
<f_>
And I wouldn't recommend switching to it until this goes upstream.
<lvrp16>
and what's packed in our images
<lvrp16>
ok
<lvrp16>
cause we use upstream ATF for allwinner and rockchip
<f_>
I see.
<lvrp16>
amlogic's the only one where we're doing custom bl2
<f_>
and custom BL31..all custom and messed up TF-A really
<lvrp16>
you've put in so much work
<lvrp16>
yeah, the bl30 situation is not fun but we do control the few calls that handle PSCI, suspend, wake and all that
<f_>
Still have to cleanup things and fixup eMMC...add support for DDR4 so that lafrite boots and I can test SPI as well...
<lvrp16>
powering on and off the reguators
<lvrp16>
whatever the other "stuff" is, I have no idea
<f_>
I do my best to update this page with known issues etc
<f_>
And I'll update it to say that DDR init *partially* works
<lvrp16>
this work also minimizes the messages coming out of ao rx and tx and maybe turn those pins into something useful
<lvrp16>
I've been wanting to turn La Frite into headend controllers for clusters since it has 4 UARTs and a bunch of GPIOs
<lvrp16>
it's a lot more efficient than the H5's I've been using
<f_>
Probably not the only one excited for SPL on Amlogic :)
<f_>
Forgot to mention that TF-A BL31 does need mods in order to boot (boot args).
<f_>
Kwiboo made his tree use a proper function to parse arguments on gxbb and gxl (else BL31 will complain) and I also hardcoded the scp image info passed from BL2.
<f_>
Anyway lafrite won't boot (haven't tested but I know for sure it won't boot) because of missing DDR4-specific bits in DRAM init code
<f_>
But hey, looks like SPL is quite reliable when it boots :)
<narmstrong>
f_: do you plan to upstream the bl31 changes in the tf-a repo ?
<f_>
I could, but not sure if they'll accept
<f_>
After all, these changes break Amlogic BL2 support.
<f_>
(probably break..haven't tested)
<f_>
I think upstreaming is very important but I'd first have to find a "way" to detect if BL31 is running from SPL or not.
<f_>
or perhaps let that be a flag you have to enable?
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #linux-amlogic
<f_>
Or perhaps if repk_ doesn't care about Amlogic BL2 support I probably could send patches as is? No idea.
<f_>
(AFAICT repk_ maintains the gxl TF-A BL31 port)
jacobk has quit [Ping timeout: 255 seconds]
ldevulder has quit [Ping timeout: 268 seconds]
<repk_>
f_ I think a compilation flag could be enough