<MasterR3C0RD>
Looks like I received the Cubie A7A myself. Any work started on that front yet?
<MasterR3C0RD>
(A733)
<MasterR3C0RD>
parthiban: Been extremely busy, terribly sorry. I was able to figure out that the A133, H616, and A523 appear to use Innosilicon DDR PHYs; I never updated the wiki as it was something I stumbled upon.
<apritzel>
MasterR3C0RD: do you have an A133 device with anything other than LPDDR4?
<MasterR3C0RD>
My Sonic Pad has DDR4
<apritzel>
you have support for DDR3 and LPDDR3 in your driver, are those bits straight from the BSP driver? And were you able to test this somehow?
<MasterR3C0RD>
Those were implemented as closely as possible to boot0's implementation. Didn't test them on anything though
<apritzel>
I see, thanks
<MasterR3C0RD>
DDR3 at least wasn't too far off from DDR4; was just different settings and such. Why do you ask?
<apritzel>
all those timings seem to be very conservative, so using the much longer delays JEDEC specifies for higher frequency, but at a much lower frequency
<apritzel>
I was trying to make sense of some values
<MasterR3C0RD>
Ahh. Yes, those would be direct from boot0, with no modifications
<apritzel>
for one of my H618 TV boxes I was able to apply for sensible timings, and gained a decent uplift in tinymembench
<MasterR3C0RD>
Very nice! Free performance is the best :)
<apritzel>
just not sure it's as stable
<MasterR3C0RD>
Also, just took a quick look at A733's boot0. Looks like DDR init is... suspiciously simple
<apritzel>
I think AW does no real training or optimisation during the DRAM setup, so they go with very conservative timings, just to cover everyone
<apritzel>
calling into something else, maybe?
<MasterR3C0RD>
I think it's firmware driven
<MasterR3C0RD>
It just writes a bunch of values and then waits for a bit to clear
<apritzel>
what firmware do you mean? boot0 is firmware
<MasterR3C0RD>
Oh sorry, half asleep. SPL
<apritzel>
still doesn't parse. boot0 is the SPL equivalent in the Allwinner boot firmware stack
<MasterR3C0RD>
OHH. I mean the DDR controller uses its own microcode firmware thing like SoCs from other vendors have been doing for a while
<apritzel>
or do you mean there is something uploaded to the DDR controller itself
<apritzel>
ah I see
<apritzel>
and this firmware is in ROM, or do we need to provide and upload it?
<apritzel>
so you just set the timing parameters you want for your chips, and maybe provide some board specific delay values, and that's it?
<MasterR3C0RD>
I don't even think there's timing parameters being set
<apritzel>
does it do proper training them to figure them out?
<MasterR3C0RD>
Looks much more like proper DRAM init
BroderTuck has joined #linux-sunxi
<MasterR3C0RD>
Oh right; I believe iscle was looking at this previously
ungeskriptet_ has joined #linux-sunxi
warpme has quit []
ungeskriptet has quit [Ping timeout: 480 seconds]
<BroderTuck>
my teclast t60ai has code T8E3 and has a rom download available on their site, iirc. might be a good idea to compare if there are any differences
<MasterR3C0RD>
BroderTuck: Might be useful down the road, but just like with A133, it'd be easier to tackle this libdram object file (which has symbols) vs trying to trudge through a raw binary
Sensu_Be1 has joined #linux-sunxi
Sensu_Bean has quit [Read error: Connection reset by peer]
<apritzel>
so boot0 now just contains a stub that calls into a separate library? And is that part of boot0 or loaded separately?
<MasterR3C0RD>
I think that spl_pub repo might be borked for A733; libdram would be straight up linked into a proper build
<MasterR3C0RD>
libdram just has the DRAM init code and nothing else
<apritzel>
that's how boot0 source code has always been distributed in the past (when it appeared somewhere)
<MasterR3C0RD>
A133 was just the odd one out since the DRAM code was already in the object files, and there was no separate libdram
<dlan>
MasterR3C0RD: re A733, I'm looking into uboot, but not touched the ddr part - plan to use vendor boot0 to initilize DDR, so could skip this step for now
<dlan>
for sunxi-tools (fel), I have cooked a branch for a733, you could start with it for dumping registers..
<dlan>
apritzel: I vaguely remembered that you've done some pinctrl/clock? for a733, is there any branch that you pushed out
BroderTuck has quit [Quit: BroderTuck]
<apritzel>
dlan: I will try to finish the pinctrl driver over the weekend, but I won't be able to test it yet
<apritzel>
if you get DRAM hacked up with U-Boot, we might be able to load a kernel
<apritzel>
or maybe we can even use the BSP U-Boot, to load our own kernel?
<apritzel>
(to avoid blocking kernel development, so U-Boot/DRAM can go in parallel)
<dlan>
sure, it should be practical to do in parallel, either use vendor uboot or download all images (Image/dtb/ramdisk) via fel, then just boot it
<dlan>
if you need someone help to test, just let me know..
<paulk>
MasterR3C0RD: very nice work on dram research!
<paulk>
especially identifying the phy
<MasterR3C0RD>
paulk: Thank you, though to be fair, iscle had already determined it was DWC a few months ago. I just confirmed as much myself and managed to find a symbol I could search on GitHub
<paulk>
is it still umctl2/upctl2?
<paulk>
for the controller
<paulk>
or is it the lpddr54?
<MasterR3C0RD>
I haven't verified the DFI controller, but there's a possibility it's different. At least on first glance, it doesn't look exactly familiar, though that could also be because I didn't add any defines yet to make things clear
<MasterR3C0RD>
Let me see if it looks more familiar with that...
<MasterR3C0RD>
Ah, there's two memory controllers. Perhaps that might explain some of the strangeness
paulk-bis has joined #linux-sunxi
paulk has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
paulk: It's the lpddr54; registers for DFI setup match up perfectly with the databook for it in that repo
<MasterR3C0RD>
Workflow is similar to the uMCTL2, just different register offsets mainly
<MasterR3C0RD>
Some niceness with the firmware in theory: apparently there's a debug flag that can be set that'll make the PHY send back debug information. That would be *very* cool to find.