<apritzel>
tokyovigilante: ah, great! So sunxi-fel returns now?
<apritzel>
so one common problem is that (some?) printf calls require BSS, which is not cleared until before board_init_r() is called
<apritzel>
how do you load U-Boot proper? You have to load it to 0x4a000000, this is the address where it is linked to
<apritzel>
so the common FEL boot flow (with: sunxi-fel uboot u-boot-sunxi-with-spl.bin) would be:
<apritzel>
sunxi-fel uploads the SPL into SRAM, saving the BROM stacks to the end of SRAM, then executing SPL, and waiting for it to return (after restoring the BROM stacks)
<apritzel>
the sunxi-fel uploads the rest: TF-A to 0x40000000, U-Boot proper to 0x4a000000
<apritzel>
then sunxi-fel branches to TF-A, switching to AArch64 (because the BROM is AArch32 only)
<apritzel>
TF-A initialises, then branches on to U-Boot
<apritzel>
so have you compiled U-Boot with the TF-A binary? (you need to add: BL31=/src/to/tf-a/build/sun50i_h616/debug/bl31.bin)
<apritzel>
and for that experiment, with the BSS and stack moved to SRAM, you should use "sunxi-fel spl spl/sunxi-spl.bin" only, then use sunxi-fel to check DRAM accessibility and integrity
<apritzel>
if the SPL didn't return to FEL because of DRAM issues, then anything else (TF-A and/or U-Boot proper) will fail as well
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
kien has joined #linux-sunxi
kein has quit [Ping timeout: 480 seconds]
kien has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
kien has joined #linux-sunxi
kien has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
kein has joined #linux-sunxi
kien has joined #linux-sunxi
kien has quit [Remote host closed the connection]
kein has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
Net147 has quit [Quit: Quit]
Net147 has joined #linux-sunxi
apritzel has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Quasar 5.2.0, revision: 5.2.0+git-7558-9b8fa92ef, build type: debug, sources date: 20160102, built on: 2024-02-17 21:13:17 UTC 5.2.0+git-7558-]
warpme has joined #linux-sunxi
<tokyovigilante>
apritzel: thanks, yup have built TF-A into a u-boot-sunxi-with-spl.bin, but trying the full u-boot over FEL doesn't progress past "Trying to boot from FEL", but the TF-A and u-boot uploads appear to complete
apritzel has quit [Ping timeout: 480 seconds]
<tokyovigilante>
running just the SPL does now result in sunxi-fel returning, so I presumably can try accessing memory directly, but unsure what I'm looking for
<tokyovigilante>
sudo ./sunxi-fel hex 0x1150 64
<tokyovigilante>
00001150: 65 47 4f 4e 2e 42 54 30 00 00 00 00 10 40 2d e9 eGON.BT0.....@-.
<tokyovigilante>
Found the eGON magic, does this mean DRAM access is working?
<Jookia>
tokyovigilante: 0x1150 - is that an offset from DRAM or is that in something like SRAM?
<Jookia>
i haven't been paying much attention to this conversation sorry :) but i think your next step is to try reading 0x40000000 ?
<tokyovigilante>
Not sure, this is just running sunxi-fel spl <image.bin>, letting it boot the SPL, and then probing memory, i was looking at much larger blocks when i saw the eGON header
<tokyovigilante>
should I expect a copy of the SPL to be at 0x40000000 after the relocation? I see when i run the full u-boot over FEL the tool seems to upload the TF-A firmware there and the main u-boot image at 0x4a000000, so i wasn't expecting anything to be there with just the spl booted.
<tokyovigilante>
so DRAM is ok, but it looks like TF-A never runs for some other currently unknown reason
<Jookia>
Das U-Boot
<Jookia>
so the u-boot SPL is suppose to run TF-A but doesn't?
<tokyovigilante>
I think running sunxi-fel with the spl option will upload both the TF-A and u-boot images but NOT run them, but instead return and allow more FEL mode commands
<tokyovigilante>
when run with the u-boot option it both uploads them and tries to run them after SPL, which is hanging for me
<Jookia>
i'm assuming you don't have JTAG?
<tokyovigilante>
so if I just upload them with the spl option, then I can poke around in what I assume must be DRAM based on that offset, and can see the code is there at the correct locations, but yeah, when doing it live it won't boot
<tokyovigilante>
no but I have a serial UART plugged in
<tokyovigilante>
gets as far as "Trying to boot from FEL"
<tokyovigilante>
which I gather is the end of the SPL code and it should then jump to TF-A
<tokyovigilante>
I do note this output - "Starting U-Boot (0x40000000)." I wonder if I need to do anything else to make sure it starts with TF-A
<Jookia>
that's not U-Boot's location anyway
<Jookia>
maybe that's just a fel typo
<Jookia>
but that wouldn't be on serial would it?
<tokyovigilante>
no that's from sunxi-fel
apritzel has joined #linux-sunxi
<apritzel>
tokyovigilante: ah, very good, thanks for the experiments
<tokyovigilante>
the last serial output is "Trying to boot from FEL" either way
<apritzel>
so yeah, if you can write and read back something beyond 0x40000000 (which is the start of DRAM), this would mean that DRAM is working
<apritzel>
you can skip TF-A for now, to rule out that there is an issue with that
<apritzel>
you would lose SMP, so it would be just single core, but you should be able to make progress anyway
<tokyovigilante>
oh yup, cool. Didn't think of that, was aiming for a 64-bit boot, but good to check
<apritzel>
so do "sunxi-fel spl", then upload u-boot.bin to 0x4a000000, and do "sunxi-fel reset64 0x4a000000"
<apritzel>
if you want to run Linux, you should comment the psci node and the other cores in the DT, otherwise it will crash
<apritzel>
(as TF-A provides the PSCI services)
<apritzel>
but for just U-Boot that doesn't matter
<tokyovigilante>
cool, eventually, but probably no point til I fix whatever is wrong here
<tokyovigilante>
Image 'u-boot-sunxi-with-spl' is missing external blobs and is non-functional: atf-bl31
<tokyovigilante>
just ignore this and manually upload?
<apritzel>
tokyovigilante: I am somewhat confused, I thought you compiled the whole U-Boot already (even though you just *used* the SPL part so far)?
<apritzel>
ah, yes, you won't use that image file anyway, but u-boot.bin
<tokyovigilante>
yup I did including the TF-A firmware, I did use the u-boot official instructions at some poitn sory
<apritzel>
so yeah, u-boot-sunxi-with-spl.bin and sunxi-fel does everything for you, but for now we need to take it apart and run the parts separately
<apritzel>
so upload and run the SPL, then upload u-boot.bin and execute that, with reset64
<tokyovigilante>
ok, run spl, uploaded u-boot, and...
<tokyovigilante>
so sunxi-fel reset64 0x40000000?
<apritzel>
no, reset64 0x4a000000
<tokyovigilante>
ewps
<apritzel>
where you uploaded U-Boot to
<apritzel>
because U-Boot is linked against that address
<tokyovigilante>
sorry uploaded to 0x40000000, rookie mistake
<tokyovigilante>
hmmm
<apritzel>
(we could compile it position independent, that's a somewhat newish U-Boot feature, then it would run from anywhere, but we don't at the moment)
<tokyovigilante>
apparently successful, but nothing on the console
<tokyovigilante>
so presumably unsuccessful
<apritzel>
can you read that back and compare it against the file?
<tokyovigilante>
trying to read out memory also fails now (after trying to run it)
<apritzel>
well, yes, that's expected, you gave up FEL access with the reset64 command
<tokyovigilante>
ah right
<tokyovigilante>
so boot spl, upload, then try to read before running?
<apritzel>
yes
<apritzel>
but I think you said earlier that this worked
<apritzel>
with length being the size of u-boot.bin you wrote
<apritzel>
then "cmp" both files
<apritzel>
just to make sure we don't have subtle bit errors, due to insufficient initialisation (I have seen that before)
<tokyovigilante>
u-boot.tmp ../u-boot/u-boot.bin differ: byte 1, line 1
<tokyovigilante>
not a good start
<apritzel>
try to manually compare the hex view, sometimes you can spot patterns
<tokyovigilante>
definitely a problem here, the diff is similar but lots of what I presume are errors in either read or write
<tokyovigilante>
Unknown relocation type %llx
<tokyovigilante>
%s: Relocation at %p is out of range (%lx)
<tokyovigilante>
vs
<tokyovigilante>
Unknown relocation type %llx
<tokyovigilante>
%s: Relocation%p is out of range (%lx)
<tokyovigilante>
subtle but errors everywhere
<apritzel>
interesting!
<apritzel>
so it looks like exactly 4 bytes missing?
<apritzel>
" at "
<apritzel>
wouldn't have expected that, I have seen bits being stuck, but not bytes missing
<tokyovigilante>
yup, and they are nulled out in the read-out file, just didnt paste across
<apritzel>
ah, I see
<apritzel>
note to self: we should have a "sunxi-fel memtest" command ...
<apritzel>
anyone: low hanging fruit and contribution chance, pure userland ;-) ^^^^
<tokyovigilante>
i'm out for the night, but presumably the implication is that the DRAM timings are off somehow?
<apritzel>
yes, that was my theory anyway, so many thanks for following up and this and getting confirmation!
<tokyovigilante>
no worries, thank you for the help!
<tokyovigilante>
Just pushed my local changes so you can see the timings I'm using now, largely cobbled together from the internet so probably the cause of the problems...
<apritzel>
libv: ah, thanks, and I just need the first few MBs, to check the DRAM story there
bauen1 has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
<apritzel>
libv: ah great, thanks. And since 7zip is not good at extracting partial archives, I'd be grateful if you could put the first say 25 MB somewhere, so that I can have a look at their boot0
apritzel has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
apritzel has joined #linux-sunxi
blathijs has joined #linux-sunxi
<libv>
apritzel: just got back, give me a minute
<libv>
apritzel: the first partition is the illegal one with 45GiB
bauen1 has quit [Ping timeout: 480 seconds]
<libv>
meh, i hate the new cloud setup
<libv>
i will stick it on fd.o
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
<apritzel>
tokyovigilante: can you check whether those zero sequences appear in a pattern? I *think* we haven't tested a 1GB LPDDR4 board before, maybe the addrmap setting is wrong?
<apritzel>
any chance you can remove that shield to see how many DRAM chips there are? Also if there are some on the underside of the PCB?