gaston1980 has quit [Quit: Konversation terminated!]
anaesthetize has joined #linux-sunxi
lurchi__ is now known as lurchi_
dev1990 has joined #linux-sunxi
victhor has quit [Ping timeout: 272 seconds]
lurchi_ is now known as lurchi__
azend has quit [Ping timeout: 240 seconds]
ChriChri_ has joined #linux-sunxi
anaesthetize has quit [Ping timeout: 258 seconds]
vagrantc has quit [Quit: leaving]
ChriChri has quit [Ping timeout: 265 seconds]
ChriChri_ is now known as ChriChri
azend has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 256 seconds]
reinforce has joined #linux-sunxi
apritzel has joined #linux-sunxi
pCactus has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
apritzel has quit [Ping timeout: 276 seconds]
pCactus has quit [Ping timeout: 240 seconds]
pCactus has joined #linux-sunxi
asdf28 has joined #linux-sunxi
lkcl has quit [Ping timeout: 276 seconds]
lkcl has joined #linux-sunxi
cmeerw has joined #linux-sunxi
cmeerw has quit [Ping timeout: 258 seconds]
niceplace has joined #linux-sunxi
pCactus has quit [Ping timeout: 240 seconds]
pCactus has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
cnxsoft1 has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
BenG83 has joined #linux-sunxi
ldevulder has quit [Ping timeout: 246 seconds]
niceplace has quit [K-Lined]
matthias_bgg has joined #linux-sunxi
<prefixcactus>
libv: If you're talking about our own carrier board, it's unlikely anyone reading the wiki outside of the company will actually get their hands on one. The SOM itself, though..
ldevulder_ is now known as ldevulder
BenG83 has quit [Quit: Leaving]
<libv>
prefixcactus: indeed
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
rzerres has quit [Read error: Connection reset by peer]
rzerres has joined #linux-sunxi
azend has quit [Ping timeout: 240 seconds]
apritzel has joined #linux-sunxi
<prefixcactus>
apritzel: have you by any chance found your notes? :)
<apritzel>
prefixcactus: I found my tool to decode the boot0 parameters, at least
<apritzel>
prefixcactus: but unfortunately the R40 uses a slightly different format
<apritzel>
the tool was for the A64 boot0
<apritzel>
so those values have apparently moved around somehow
azend has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
<prefixcactus>
hm.
<prefixcactus>
well that sucks
<prefixcactus>
I suppose I can try digging into the u-boot provided with the thing
<libv>
apritzel: sunxi-tools might be a good home for your tool, and then others can add to it
<apritzel>
libv: yeah, I thought about it, but it's mostly obsolete, as it would only work on A64 boot0's
lkcl has quit [Ping timeout: 276 seconds]
victhor has joined #linux-sunxi
\\Mr_C\\ has joined #linux-sunxi
<apritzel>
prefixcactus: another approach would be to dump the DRAM registers after boot0 booted
<apritzel>
prefixcactus: can you get to the U-Boot shell with the original firmware?
<apritzel>
and do you have the "md" command available there?
<apritzel>
prefixcactus: a low hanging fruit would be the delay registers, you could descramble them according to mctl_set_bit_delays() in mainline U-Boot's arch/arm/mach-sunxi/dram_sunxi_dw.c
<libv>
apritzel: better than nothing, and it might be the jump off point for others
<apritzel>
libv: I'd rather put the info in the wiki, which would be more versatile
<prefixcactus>
apritzel: lemme try
<prefixcactus>
Yep, I do have md
<prefixcactus>
which addresses shall I dump?
lkcl has joined #linux-sunxi
s_frit has quit [Ping timeout: 265 seconds]
alexeymin has joined #linux-sunxi
<tuxd3v>
can't have regulator_phy and regulator_phy_io with dwmac-sun8i :( also not sure if shutdown function is working.. on orange Pi one plus
<tuxd3v>
sinke kernel 5.10
<tuxd3v>
each time that I patch dwmac-sun8i. I endup without ethernet :/
<tuxd3v>
I am on kernel 5.10.13
<apritzel>
prefixcactus: you could try to chase down the used addresses in that set_bit_delays() function
<libv>
apritzel: also cool, thanks
<prefixcactus>
I've kind of broken my brain trying to chase down everything that function references
<prefixcactus>
(having zero prior knowledge of the u-boot codebase)
<prefixcactus>
e.g. wtf is SUNXI_DRAM_CTL0_BASE, where's the definition of struct sunxi_mctl_ctl_reg or setbits_le32() etc
<KotCzarny>
grep is your friend
<apritzel>
prefixcactus: yeah, no worries, you just have to wait then until the sun has set over the Fens ;-)
<apritzel>
ctags/cscope is much better
<prefixcactus>
KotCzarny: yeah, it gives me 9000 uses of those elsewhere
<KotCzarny>
for definition, its usually in .h files
<KotCzarny>
and wiki might have it too if you are lucky
<prefixcactus>
ctags would probably be better, but my spacemacs setup currently refuses to work with them
<apritzel>
and then use struct sunxi_mctl_ctl_reg in dram_sunxi_dw.h
<apritzel>
prefixcactus: and yes, it's not a walk in the park, because this is the DRAM controller
<apritzel>
if you have a business relationship with Allwinner, you should complain there
<apritzel>
because DRAM is a major pain for all of us here (ask jernej)
<prefixcactus>
Do I understand correctly that the reason I'm doing this is because in allwinner firmwares it's boot0 that sets all those parameters before loading u-boot, and with mainline the SPL has to do this instead?
Mangy_Dog has joined #linux-sunxi
<apritzel>
prefixcactus: yes
<apritzel>
because their boot flow is insane
<prefixcactus>
I see
<apritzel>
prefixcactus: plus: there is absolutely zero documentation about any DRAM controller IP from Allwinner
<prefixcactus>
I noticed
<apritzel>
so clever and diligent people here (like jernej and MoeIcenowy) pieced this together the hard way over the years
<prefixcactus>
well, I found the actual code that spewed those "dram para[%d]" lines
<apritzel>
tuxd3v: is that our good old phy-mode = "rgmii-not-anymore" friend?
<tuxd3v>
apritzel, phy-mode = "rgmii-id";
<tuxd3v>
at least its what I was using in the past
<tuxd3v>
and is what came in mainline dts
<apritzel>
tuxd3v: OK, was worth a try, but this should indeed work with 5.10
<tuxd3v>
with 5.10.2 was indeed woreking but the dwmac-sun8i sufered a lot of changes
<tuxd3v>
and I tried with 5.10.13, and its not working anymore :/
<apritzel>
tuxd3v: oh wow, so it's a regression within the stable branch?
<tuxd3v>
yes it seems to be
<apritzel>
tuxd3v: thanks for now bisecting this :-D
<tuxd3v>
you welcome
\\Mr-C\\ has joined #linux-sunxi
\\Mr_C\\ has quit [Ping timeout: 276 seconds]
\\Mr-C\\ has quit [Quit: (Read error: Connection reset by beer)]
\\Mr_C\\ has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
dlan has quit [Remote host closed the connection]
<prefixcactus>
the sunxi chips are big-endian, right?
<apritzel>
prefixcactus: ARM support both endian, in AArch32 you can switch on the fly
<apritzel>
but normally it's all little endian
<prefixcactus>
hm.
<prefixcactus>
that makes things a bit harder, cause the struct features lots of byte arrays and the hexdump has the 32-byte words MSB-first from what I can gather
<prefixcactus>
but I could be totally wrong
<apritzel>
hexdump -C?
<prefixcactus>
er, it's uboot's md
<apritzel>
md.b
<apritzel>
but md.l should do the right thing?
<apritzel>
prefixcactus: if you dump the output of: "md.l 0x01c63300 80" somewhere, I can have a look later
<prefixcactus>
the bootable SD is on MMC0, and there is a second SD slot which the chip doesn't boot from (at least in the initial stages) on MMC3; MMC1 has nothing connected (although I believe it's broken out on the devboard somewhere)
<jernej>
prefixcactus: I just checked, MMC1 means SD card and MMC2 means eMMC. Those names come from generic code and are not sunxi related
<prefixcactus>
Aha. So it couldn't detect any cards somehow?
<jernej>
probably, that could be also result of corrupted memory
<prefixcactus>
or is it that I haven't configured which is which?
<jernej>
no, R40 is otherwise properly supported, I would bet on memory issue
<prefixcactus>
Well, I've got two sd cards here that I'm trying to boot from, and they both fail in this way
<prefixcactus>
or do you mean corrupted ram
<jernej>
yes
<prefixcactus>
hm.
<prefixcactus>
Is there a way I could check if it really is corrupted?
<prefixcactus>
(or whether it's something else)
<KotCzarny>
try more cards
<KotCzarny>
different makers/sizes
<KotCzarny>
somtiems it helps
<prefixcactus>
I don't have more cards
<KotCzarny>
they are cheap, buy some?
<jernej>
you could add some test code in SPL which would try to write different patterns in whole memory and read them back - if they don't match, printf something
<prefixcactus>
(also, the stock image does boot okay from these)
<prefixcactus>
a poor man's memcheck? :)
<jernej>
exactly
<jernej>
do that at the end of DRAM driver, code at that point still uses only SRAM
<prefixcactus>
okay, looks like I've got something to do on the weekend
<prefixcactus>
cause I'm gonna leave work in a few minutes
<prefixcactus>
any good guides to u-boot internals that I could also read while I'm away from the hardware?
<prefixcactus>
or just code
<jernej>
I don't believe there is any good documentation about such low level internals, each platform or even each SoC have some specifics
<prefixcactus>
apparently there aren't any good docs on the soc itself either
<prefixcactus>
(its DRAM-related guts, anyway)
<jernej>
welcome to the world of reverse engineering :)
<prefixcactus>
Thanks! :)
prefixcactus has quit [Ping timeout: 265 seconds]
pCactus has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
pCactus has quit [Read error: Connection reset by peer]
hlauer has joined #linux-sunxi
pCactus has joined #linux-sunxi
prefixcactus has quit [Ping timeout: 276 seconds]
ganbold_ has quit [Read error: Connection reset by peer]
lucascastro has quit [Ping timeout: 240 seconds]
vagrantc has joined #linux-sunxi
lucascastro has joined #linux-sunxi
lucascastro has quit [Ping timeout: 246 seconds]
lucascastro has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
prefixcactus has quit [Client Quit]
pCactus has quit [Read error: Connection reset by peer]