ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #linux-sunxi
<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> 40000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
<tokyovigilante> trying to read 0x40000000 after the full u-boot attempt just times out, so I presume I still have a DRAM issue
<Jookia> tokyovigilante: not sure. maybe try reading 0x4a000000?
<tokyovigilante> that times out too after u-boot, and same result (all FF) with just the SPL
<tokyovigilante> oh hold on I should be running spl but with the complete image
<tokyovigilante> that looks better
<tokyovigilante> or at least different
<tokyovigilante> ok, so comparing the TF-A firmware bin and the memory at 0x40000000, looks like it was successfully uploaded
<tokyovigilante> 4000a4a3: 00 76 32 2e 31 30 2e 30 09 28 64 65 62 75 67 29 .v2.10.0.(debug)
<tokyovigilante> 4000a4b3: 3a 76 32 2e 31 30 2e 30 2d 00 00 00 00 67 38 39 :v2.10.0-....g89
<tokyovigilante> 4000a4d3: 32 30 3a 31 30 3a 30 30 2c 20 46 65 62 20 20 33 20:10:00, Feb 3
<tokyovigilante> 4000a4c3: 62 39 64 39 36 35 37 00 42 75 69 6c 74 20 3a 20 b9d9657.Built :
<tokyovigilante> 4000a4e3: 20 32 30 32 34 00 69 6e 63 6c 75 64 65 2f 6c 69 2024.include/li
<tokyovigilante> 4a00120c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
<tokyovigilante> 4a00121c: 44 00 61 00 73 00 20 00 55 00 2d 00 42 00 6f 00 D.a.s. .U.-.B.o.
<tokyovigilante> 4a00122c: 6f 00 74 00 00 00 00 00 38 12 00 4a 00 00 00 00 o.t.....8..J....
<tokyovigilante> and there is u-boot
<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
<apritzel> how do you compile TF-A?
<tokyovigilante> just getting the 32-bit compiler
<apritzel> you don't need a 32-bit compiler
<apritzel> it's probably another horribly outdated part of the wiki :-(
<tokyovigilante> oh? get an angry message if I omit it from the 64-bit build
<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
<tokyovigilante> ok, definitely there
<tokyovigilante> yeah that works
<tokyovigilante> 4a00121c: 44 00 61 00 73 00 20 00 55 00 2d 00 42 00 6f 00 D.a.s. .U.-.B.o.
<tokyovigilante> 4a00122c: 6f 00 74 00 00 00 00 00 38 12 00 4a 00 00 00 00 o.t.....8..J....
<tokyovigilante> seems neither TF-A or u-boot can run however
<apritzel> so it's a bit of a stretch, but if DRAM is subtly wrong, it could mean that easy reads and writes work, but execute doesn't
<apritzel> I think the I cache uses a different access type and pattern to DRAM
<apritzel> I guess it fills a cache line at once, so would ask for 64-bytes in one request
<apritzel> also, just to make sure, can you read the whole U-Boot back, and compare it against the u-boot.bin you wrote?
<apritzel> sunxi-fel read 0x4a000000 <length> some.tmp.file
<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...
<Jookia> do you have a working bootable u-boot? maybe you could steal the timings from that :)
<Jookia> or poke some registers on a working system
<apritzel> tokyovigilante: is there a link to some vendor image? I think libv mentioned he looked at one before?
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest1643
dsimic has joined #linux-sunxi
Guest1643 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<libv> apritzel: it is huge and a pain to dl, 45GiB of it is console roms that are not owned by nintendo
<libv> tell me what bits you need, and i can hand them to you later today
apritzel has joined #linux-sunxi
<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]
<libv> meh
<libv> machine is full
KREYREN_oftc has joined #linux-sunxi
warpme has quit []
apritzel has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: KVIrc 5.2.0 Quasar http://www.kvirc.net/]
warpme has joined #linux-sunxi
warpme has quit []
<wingrime-ww> https://github.com/YuzukiHD/SyterKit that's guys have recent sdk for t527 and other recent ic's
retpolanne has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel> wingrime-ww: yes, she is GLGH_ or GloomyGhost, the creator of this board https://twitter.com/GLGH_/status/1762464349313257872 (as posted by gamiee the other day)
<apritzel> libv: many thanks, I got it
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #linux-sunxi
<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?
sunshavi_ has joined #linux-sunxi