pCactus has quit [Read error: Connection reset by peer]
pCactus has joined #linux-sunxi
apritzel has joined #linux-sunxi
cmeerw has joined #linux-sunxi
apritzel has quit [Ping timeout: 256 seconds]
cmeerw has quit [Ping timeout: 272 seconds]
alexxy has quit [Quit: No Ping reply in 180 seconds.]
alexxy has joined #linux-sunxi
<MoeIcenowy>
I remember seeing her in this channel
<prefixcactus>
I'm pleased to announce I've got progress on the MMC problem
<prefixcactus>
it was a matter of specifying the correct GPIO for the MMC0 CD pin
<prefixcactus>
now it doesn't fail by complaining about no card being present, it just hangs instead
<prefixcactus>
now it doesn't fail by complaining about no card being present, it just silently hangs instead
rojiro has quit [Ping timeout: 268 seconds]
rojiro has joined #linux-sunxi
BenG83 has joined #linux-sunxi
iyzsong has quit [Ping timeout: 258 seconds]
iyzsong- has joined #linux-sunxi
iyzsong- is now known as iyzsong
warpme_ has joined #linux-sunxi
mmarc__ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
daregap has joined #linux-sunxi
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
elros1 has joined #linux-sunxi
ScrumpyJack has quit [Quit: Eat more sushi]
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc__ has quit [Ping timeout: 240 seconds]
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
asdf28 has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
<gediz0x539>
prefixcactus: congratz
Mangy_Dog has joined #linux-sunxi
mmarc__ has quit [Remote host closed the connection]
mmarc__ has joined #linux-sunxi
mmarc___ has joined #linux-sunxi
<apritzel>
prefixcactus: is this still failing in the SPL?
<apritzel>
prefixcactus: if yes, have you added "#define DEBUG" at the *very* beginning of some SPL files responsible for loading?
mmarc__ has quit [Ping timeout: 264 seconds]
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
\\Mr_C\\ has joined #linux-sunxi
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
<mmarc___>
Hi, I could not find any distro for Tanix tx6 right away, both CoreELEC and LibreELEC do not support it. What did you mean earlier, particularly?
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
tuxillo has quit [Remote host closed the connection]
AndroUkeie has joined #linux-sunxi
AndroUkeie has quit [Read error: Connection reset by peer]
lurchi_ is now known as lurchi__
<prefixcactus>
apritzel: looks like it.
mmarc___ has quit [Remote host closed the connection]
tuxillo has joined #linux-sunxi
<prefixcactus>
spl_mmc_load_image() finishes successfully and apparently the SPL then fails wherever that was called from
mmarc__ has joined #linux-sunxi
<prefixcactus>
apritzel: I did, but it didn't change what was printed to console
<prefixcactus>
so I'm sticking my own printf's everywhere
<apritzel>
prefixcactus: did you put the "#define DEBUG" *before* the #include's?
<prefixcactus>
no, I put it after them
reinforce has quit [Quit: Leaving.]
<apritzel>
prefixcactus: that's a common trap, it *must* be the first in the file, otherwise it won't be honoured by the files you include
<apritzel>
(and which will use that option to define the actual debug() function)
lurchi__ is now known as lurchi_
<prefixcactus>
I see.
mmarc__ has quit [Ping timeout: 264 seconds]
<prefixcactus>
I put the define before everything now, but it didn't print anything after my own checkpoints
<prefixcactus>
I probably should put it into more files, however I don't know which ones
<prefixcactus>
Where does spl_mmc_load_image() get called from?
<apritzel>
prefixcactus: yeah, that's a rabbit hole, I don't know from the top of my head, I am afraid you need to grep for that
<prefixcactus>
I'd do that, but it looks like it doesn't get called by name
<prefixcactus>
immediately after the definition there's this:
<apritzel>
the SPL is not supposed to be a memory hog ;-)
<apritzel>
I am actually not even sure the 32-bit SPLs use DRAM at all
<prefixcactus>
I assumed it was allocating memory for the image
sunshavi has quit [Read error: Connection reset by peer]
annieslmaosok has joined #linux-sunxi
annieslmaosok has quit [Connection closed]
<apritzel>
well, yes, it's writing the image to DRAM, but might not be using DRAM for its own purposes
woddf2vV has joined #linux-sunxi
YuGiOhJCJ has joined #linux-sunxi
woddf2vV has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Remote host closed the connection]
<apritzel>
for the 64-bit SPLs we do use DRAM (after it's initialised), so faulty DRAM makes it crash earlier
JStokerlZ has joined #linux-sunxi
JStokerlZ has quit [Remote host closed the connection]
Pilfers has joined #linux-sunxi
<karlp>
could yo.... try just configuing half of the ram?
<karlp>
see if it all boots ok at least that way?
berndjUT has joined #linux-sunxi
Pilfers has quit [Remote host closed the connection]
berndjUT has quit [Remote host closed the connection]
MEPBZL has joined #linux-sunxi
ruunyan has joined #linux-sunxi
MEPBZL has quit [Remote host closed the connection]
ruunyan has quit [Remote host closed the connection]
<apritzel>
that could be an interesting experiment
<apritzel>
U-Boot gets loaded to 160MB, but relocates itself to the end of DRAM immediately
<apritzel>
prefixcactus: so if you hardcode the return value of sunxi_dram_init() to 512MB (or remove that last line with the ternary operator)
<apritzel>
though I don't know how the second rank is actually mapped into the address space, but it might be an easy check
<prefixcactus>
apritzel: nice idea, but didn't work unfortunately
<prefixcactus>
oh, by the way
<prefixcactus>
I just realized that the magic memtest doesn't affect the two most significant bits of each u32 written to memory
<apritzel>
prefixcactus: "doesn't affect" as in: the write does not touch and check those bits, or in: those bits always appear fixed when read back(to 0)?
<prefixcactus>
The former. It does check those bits, but they are the same everywhere
<prefixcactus>
I meant to say it won't detect any aliasing if it were to occur in these two bits only, because their "correct" value stays fixed all over.
<prefixcactus>
I'm not sure if something like that (two bits only getting aliased) is even possible, buuut...
<apritzel>
just two bits alone is probably unlikely, I would expect issues to appear in groups of 8 bits
<apritzel>
that's the value from your boot0 register dump
<apritzel>
another thing to try is to use cr_val, but clear the rank bit (bit 0)
<prefixcactus>
still the same with 0x9f4
reinforce has quit [Quit: Leaving.]
JohnDoe_71Rus has joined #linux-sunxi
<jernej>
mmarc___: there is LibreELEC, just not stable, but nightly. CoreELEC is Amlogic only.
prefixcactus has quit [Ping timeout: 272 seconds]
mmarc__ has quit [Remote host closed the connection]
mmarc___ has joined #linux-sunxi
<smaeul>
one way to debug a failure to jump to U-Boot from SPL is to add a hexdump (hexdump.h, CONFIG_HEXDUMP) of where you expect U-Boot to be in DRAM, right before the jump, and compare that to a hexdump of the u-boot.img file
<smaeul>
hmm, actually CONFIG_SPL_HEXDUMP in this case, and the first couple of KB is probably enough as a sanity check
pCactus has joined #linux-sunxi
<apritzel>
pCactus: are you actually sure that your memtest is working correctly? It's somewhat tricky to get this kind of code past the compiler's lust for optimisation ...
<pCactus>
I've put a #pragma gcc optimize "O0" before it
<pCactus>
apritzel: by the way, what if I take Forlinx's sd image and substitute their uboot with mine (sans SPL)? At least if that boots we could rule out problems with u-boot itself
<apritzel>
pCactus: not sure that works easily, since they don't use SPL, but their boot0
<apritzel>
pCactus: and we rely on some SPL specialities these days in U-Boot proper
<apritzel>
but yeah, I was thinking about this already
<apritzel>
there is a hack where you can transplant the DRAM init code from boot0 into a mainline SPL, replacing the DRAM driver
<apritzel>
but this is rather ugly and you need an actual libdram.o file, IIRC
<pCactus>
This does sound unpleasant, yes
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #linux-sunxi
cmeerw has joined #linux-sunxi
<pCactus>
apritzel: for some reason I was unable to load anything via FEL on this board
<libv>
libdram.o again?
<libv>
and still?
<libv>
pCactus: how many units of this board does your company plan to use?
<libv>
or better, how much leverage do you have over this board maker?
<libv>
because if they give you uboot with libdram.o, then you have a gpl violation right there
iamfrankenstein has joined #linux-sunxi
<libv>
ah, no, it's before their u-boot
ganbold_ has quit [Read error: Connection reset by peer]
<libv>
heh, allwinner-zh account was only active during gpl violation noise making
<libv>
it was even before the chip kickstarter
<apritzel>
libv: libdram.o would have just been a temporary debugging vehicle
<apritzel>
libv: we need to isolate the failure first to be really DRAM related
<libv>
apritzel: for us yes, but it could've been another gpl violation that $devicevendor handed down from allwinner
wens has quit [Ping timeout: 240 seconds]
<apritzel>
libv: it's all fine, don't worry ;-)
<apritzel>
it's just the DRAM debugging is never a walk in a park, and doing that remotely is even more complicated
wens has joined #linux-sunxi
matthias_bgg has quit [Read error: Connection reset by peer]