<Raqbit>
tokyovigilante: I'm trying to get your u-boot branch running on the rg35xx-h, but it seems like something is going wrong between (what I understand is) the handover between the U-boot SPL & TF-A: https://gist.github.com/raqbit/165eaf49c739a28b604101f955781c70
gsz has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
apritzel has joined #linux-sunxi
<apritzel>
Raqbit: your log reports 2GB of DRAM, which means that the DRAM init routine subtly failed. It's known to be flaky at times, can you just do the "Windows trick" and try again?
<apritzel>
ah, I see you updated that, does it still fail?
<Raqbit>
apritzel: Yep, I only just now noticed that it was a bit flaky, but I've got it consistently reporting 1GB of DRAM. But it is failing every time.
<Raqbit>
But from the messages after that, I can't tell whether they got their own u-boot booting in the end
<apritzel>
tokyovigilante's U-Boot branch seems a bit old (28 days), not sure he has updated his meanwhile
<apritzel>
and those IRC logs point to some FEL *host* problems? Any change you can try on a different system?
<Raqbit>
I could, I have a raspi laying around somewhere. But I'm not suspecting anything to be wrong with the BL31 upload, as I did a read-back with FEL and it matched the file on disk.
<Raqbit>
Unless something is consistently corrupting write & read in the same way, of course
<apritzel>
right, and failing FEL upload is rare anyways
<apritzel>
Raqbit: did you try to split this up? $ sunxi-fel spl spl/sunxi-spl.bin write 0x40000000 bl31.bin exec64 0x40000000
<apritzel>
otherwise it might still be a subtly broken SPL/DRAM init routine, not sure what branch or tree macromorgan uses these days?
<Raqbit>
I did, and it failed in exactly the same way, at the execute. Though I believe I used reset64 and not exec
<apritzel>
... and rightly so, as that's the right command ;-)
<Raqbit>
If I understand this correctly, the SPL is supposed to init, hand over to TF-A, which then starts uboot proper? And I assume TF-A is otherwise silent over UART?
<macromorgan>
I honestly don't recall, I'll have to look at it, sadly I've just been super busy lately. I believe I had A-TF right when we first started to work on this and haven't messed with U-Boot much at all since then. I'm going to start with rebuilding an image with newer branches so I can better document what I'm working on.
<apritzel>
Raqbit: yes for the boot sequence, but TF-A should always output something (even with DEBUG=0)
<macromorgan>
for me it still fails occasionally on cold boot due to the ram init
flyback has quit []
<apritzel>
macromorgan: reporting 2GB?
<macromorgan>
yes, or rarely 4GB
flyback has joined #linux-sunxi
<Raqbit>
Argh, so not an off-by-one then ;)
<apritzel>
macromorgan: yes, that's unfortunately a generic H616 issue, not confined to the Anbernic boards
<apritzel>
there are some patches floating around, but I feel they all paper over the real issue
<Raqbit>
apritzel: Okay, so in this case something is not going right during the init in SPL, which is breaking TF-A. I assume the init that the SPL is supposed to do is stable? E.g. it shouldn't be an issue that I'm grabbing a very new TF-A with a u-boot that's a bit behind?
<apritzel>
TF-A and SPL/U-Boot should be independent, yes. We do not promise that every weird combination really works, but conceptually it should
<apritzel>
TF-A is the first bit of code that uses the DRAM in anger, which is mostly the issue. Apart from BL31 being miscompiled, that is
<apritzel>
I mean the image somehow broken, or wrong PLAT= or something