00:16 <MasterR3C0RD> Just changing `writel(0xe08, &mctl_ctl->mrctrl1)` to `writel(0xe0e, ...)` gets me through DRAM init

00:17 <apritzel> MasterR3C0RD: on the A5E?

00:18 <MasterR3C0RD> Yep, fails afterwards over FEL since it can't boot from anything; writing a new image now to try booting real media

00:18 <apritzel> so for me it always passed the DRAM init, and detected the right size, but then fails in weird ways, which jernej and I tried to attribute to a subtle DRAM failure

00:19 <apritzel> FEL is broken probably for a different reason: that's the same problem on the Avaota

00:19 <apritzel> but I got failures from an SD card as well, and our "hope" was this is due to DRAM not being quite right

00:19 <MasterR3C0RD> Once I get into U-Boot I'll see if I get anything special

00:20 <apritzel> the same branch works completely fine on the X96QPro+ (DDR3L DRAM), so the FEL and MMC code are fine in general

00:24 <MasterR3C0RD> Could be something marginal with DRAM, though in my experience once it works it works. Only other thing I could think of off the top of my head is if there's a similar "special case" for DRAM organization on the A523 as there is on the A133 (16 row 10 col treated in a special way)

00:24 <MasterR3C0RD> 4GB boards seem to have the most special cases thus far

00:25 <MasterR3C0RD> Hmm, still getting "failed to boot from all boot devices"... maybe I'm missing a config option lol

03:30 <MasterR3C0RD> apritzel: I presume by boot failures you had meant you weren't even able to get into U-Boot shell? That's at least where I'm at right now

03:32 <MasterR3C0RD> In terms of additional calibrations, it appears the Cubie only wants read calibration, so the others aren't involved at all in this process, and if read calibration didn't work, I would expect no board to work. So problem must run deeper

10:36 <apritzel> MasterR3C0RD: ah, no, mine was stuck in SPL still, the MMC code there was complaining. That code typically has no issues, and works on the X96QPro+, so I'd assume it's a DRAM issue

16:40 <MasterR3C0RD> Avaota arrived today, so should have something to compare against now. Very pretty and has just about every peripheral you could ask for on a bringup board

17:36 <apritzel> MasterR3C0RD: which PCB version do you have? v1.3 as well?

17:41 <MasterR3C0RD> 1.5, Pine Store branded

17:51 <MasterR3C0RD> apritzel: Does your v1.3 have SPI NAND? Looking at the changelog entries one of the differences is support for SPI NOR boot, but I see an FM25S01 on the back of the board which would be SPI NAND

17:52 <apritzel> MasterR3C0RD: mine is SPI NAND: Winbond 25N02, as seen in the pictures in the Wiki

18:00 <MasterR3C0RD> Don't see any NOR flash in the schematics either, so I guess it meant SPI NAND boot?

18:17 <apritzel> seems to be more popular these days: you get much larger capacity, I think. We just don't support it yet in U-Boot, though there were patches on the list

20:59 <jernej> MasterR3C0RD: MR14 must be also set in init[7] reg in lpddr4 timing code

21:00 <MasterR3C0RD> jernej: Ahhh I forgot about the init registers

21:03 <jernej> in any case, memtest code in systerkit is pretty thorough, so if it passes, DRAM is not to blame for SD card or other issues

21:37 <MasterR3C0RD> From my POV it's either DRAM or voltages, but I'm not sure which yet; even after fixing init[7] I get corrupted errors when logging is maxed out in SPL on the Cubie, but no issue at all on the Avaota

21:50 <Soupborsh> Hello, I found that kernel bsp source for B288 has standby dram initialization code. How much it differs from the one that runs on boot? How can It be adapted to work in U-Boot Mainline SPL?

21:50 <Soupborsh> https://github.com/Soupborsh/kernel-b288/blob/master/drivers/soc/allwinner/pm/standby/dram/sun8iw10p1/mctl_standby-sun8iw10.c

21:54 <apritzel> Soupborsh: ah, good find, even has comments! But I don't know how much this differs, I think smaeul might know: he added DRAM suspend code to the crust firmware

21:54 <apritzel> MasterR3C0RD: jernej: actually: why would the DRAM init need to be so different between the two boards? Just because the BSP does it this way?

21:55 <apritzel> I mean couldn't we try to use the same static init approach as on the Avaota also for the Radxa?

21:56 <MasterR3C0RD> apritzel: There's no real difference in the RAM init code; the only difference is the changing of a parameter that isn't parameterized

21:59 <MasterR3C0RD> Soupborsh: Quick glance makes me think that is very similar to DRAM initialization; there's a full reset of the DRAM controller in there

22:01 <MasterR3C0RD> It's also doing some trainings, which is very interesting

23:53 <smaeul> apritzel: BSP standby DRAM code is mostly similar to the boot code; it does a full reinitialization of the controller. it may be missing some things like training if it grabs the values from before standby

23:56 <smaeul> crust code is very different because it avoids resetting the controller. it only clock gates the controller and powers down some pad drivers