sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
macromorgan has quit [Quit: Leaving]
chewitt has quit [Quit: Zzz..]
chewitt has joined #linux-sunxi
macromorgan has joined #linux-sunxi
macromorgan has quit []
macromorgan has joined #linux-sunxi
macromorgan is now known as Guest967
macromorgan has joined #linux-sunxi
Guest967 has quit []
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
hlauer has joined #linux-sunxi
Daanct12 has quit [Quit: Quitting]
Danct12 has joined #linux-sunxi
gsz has joined #linux-sunxi
apritzel has joined #linux-sunxi
Danct12 has quit [Remote host closed the connection]
gsz has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
evgeny_boger has quit [Ping timeout: 480 seconds]
cnxsoft has quit []
evgeny_boger has joined #linux-sunxi
apritzel has joined #linux-sunxi
<apritzel>
jernej: do you have an idea how to best scan for those misspelled symbols? It's not the first time we have one ...
<jernej>
apritzel: no, I caught it by luck
<jernej>
btw, with sunxi custodian master branch FEL boot doesn't work on OPi zero2, any idea what could be wrong?
<apritzel>
jernej: tbh I had trouble with my OPi zero2 as well, but even an older U-Boot didn't work. Do you have a working commit?
<jernej>
I think v2021.10 should work
<jernej>
let me test again
<jernej>
hm... it doesn't work. weird, I could swear it worked before
<jernej>
maybe it's some size thing
<jernej>
probably something is overwritten
<apritzel>
I actually had the same experience
<apritzel>
I even went back to some old image around the time we merged this
<apritzel>
and I suspected TF-A for a while, but even there an old image wouldn't work
<jernej>
it's something in SPL, because even sunxi-fel spl spl/sunxi-spl.bin fails
<jernej>
or maybe sunxi-fel misses something
<jernej>
oh, let me try without TF-A
<jernej>
ah, it's without TF-A
<jernej>
so yeah, either SPL or sunxi-fel issue
<jernej>
apritzel: I removed some DRAM options (write leveling, read training and write training) and now booting via FEL works
<jernej>
is it possible sunxi-fel is limited to 32 KB?
<jernej>
above config change lowered SPL size from 40 KB to 32 KB
vagrantc has joined #linux-sunxi
<jernej>
apritzel: there is commit 2a2af190d407 ("fel: H616: Allow bigger SPL size") in sunxi-tools, but it seems that it doesn't really work
<apritzel>
jernej: but the H616 was always bigger than 32K, wasn't it?
<apritzel>
(I mean the H616 SPL)
<jernej>
no, for example on T95 it's 32K
<jernej>
at least I think
<jernej>
build system (binman?) pads SPL binary to multiple of 8 KB
<apritzel>
jernej: yeah, so the OPi Zero2 SPL was always 40K
<apritzel>
which lead to this sunxi-tools commit
Danct12 has joined #linux-sunxi
<apritzel>
jernej: TF-A runs from DRAM on the H616, maybe that causes issues?
<apritzel>
so your "smaller SPL with DRAM changes" work is not due to smaller, but due to DRAM changes?
<jernej>
I don't follow
<jernej>
sunxi-fel always loads SPL first, run it and then loads everything else
<jernej>
so DRAM is already initialized
<jernej>
and if there would be something wrong with it, running from SD card wouldn't work
<jernej>
but it does
<apritzel>
mmh, true
<apritzel>
but the SPL itself seems to work, and it returns successfully to FEL
<jernej>
it doesn't for me, when it's 40 KB
<jernej>
sunxi-fel timeouts and subsequent command like sunxi-fel ver doesn't work
<apritzel>
mmh, that works fine for me, I can do FEL into DRAM afterwards just fine
<jernej>
ah, wait
<jernej>
maybe I'm using old sunxi-fel
<apritzel>
maybe it silently corrupts something when uploading, due to some SRAM buffer problem?
<apritzel>
let me try to read back and compare
<jernej>
hm... once I managed to execute "sunxi-fel ver" after spl loaded
<jernej>
however, another attempt failed again
<apritzel>
jernej: it looks indeed like some corruption is going on, I did a "write 0x40000000 pattern.bin read 0x40000000 131072 pattern2.bin"
<apritzel>
and they come back differently
<jernej>
which u-boot version do you have?
<apritzel>
some mainline, but without your patches
<apritzel>
jernej: what led to your patches? The code seemed to work before, when we upstreamed it, didn't it?
<jernej>
I'm using v2021.10
Vdrd has joined #linux-sunxi
<jernej>
apritzel: according to my recent test (commenting few DRAM options to lower SPL size) it seems that DRAM controller works with non-ideal options
<jernej>
but having them as close as possible to BSP configuration is best imo
<apritzel>
sure, was just wondering if that could be the culprit
Vdrd has quit [Remote host closed the connection]
<apritzel>
so I see single bit corruptions, in the first 32KB regularly (bit 30 gets set), on top of that a few single bits flipped seemingly randomly
devtag has joined #linux-sunxi
<apritzel>
the "bit 30 set" repeats at 64K
<apritzel>
apparently with and without your patches
<jernej>
can you try with CONFIG_DRAM_SUN50I_H616_BIT_DELAY_COMPENSATION=y ?
devtag has left #linux-sunxi [#linux-sunxi]
<jernej>
oh, disabling read and write training solved issue for me
<jernej>
spl is still 40 KB
<jernej>
I guess I should compare BSP values to mainline again
devtag has joined #linux-sunxi
<apritzel>
so I get seemingly less and less errors, with your patches, with BIT_DELAY, without training
<apritzel>
but still some left
<devtag>
I'm getting this error "Kernel panic - not syncing: No working init found.". I had created the image following the steps on https://licheepizero.us/.
<devtag>
My lichee pi zero keeping rebooting after this error
<jernej>
apritzel: try also without DRAM_SUN50I_H616_WRITE_LEVELING
<jernej>
so only read calibration and bit delay is enabled
<jernej>
if that doesn't completely solves the problem, try with DRAM_SUN50I_H616_UNKNOWN_FEATURE too
<jernej>
then this would be standard array of H616 DRAM options
<jernej>
apritzel: another possibility would be that BROM initializes things differently for SD card boot