ftg has quit [Read error: Connection reset by peer]
colinsane has quit []
colinsane has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
rajkosto has joined #linux-sunxi
rajkosto has quit [Remote host closed the connection]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
rajkosto has joined #linux-sunxi
rajkosto has quit [Remote host closed the connection]
rajkosto has joined #linux-sunxi
rajkosto has quit [Remote host closed the connection]
hipboi has joined #linux-sunxi
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
hipboi is now known as Guest7485
hipboi has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
Guest7485 has quit [Ping timeout: 480 seconds]
<MasterR3C0RD>
Not entirely sure how useful this is yet, but I've at least gotten a start on some DRAMC documentation. https://linux-sunxi.org/A133/DRAMC
<MasterR3C0RD>
apritzel, paulk, parthiban: ^
<MasterR3C0RD>
Interesting; there's an unused ZQ calibration routine
<MasterR3C0RD>
That appears to be the only unused routine
<MasterR3C0RD>
Unused DRAM-related routine at least
<MasterR3C0RD>
Additionally, highest address accessed within the DDRPHY block is usually 0x0b80, except for a quirk set when the chipid in the SID is 0x800 or 0x2400, in which case 0x2388 is written to during CA bit delay compensation (which I presume is equivalent to CA per-bit deskew)
<MasterR3C0RD>
This was someone else's decomp; I've verified it's nearly 1-to-1 with what I was getting in BinaryNinja. We can't copy any code from it, but it's a good reference when it comes to reviewing behaviors
<MasterR3C0RD>
My code is structured a bit differently from the H616 and this code base, mainly in an attempt to be slightly more descriptive, but it should be fairly easy to map them (the only major rename is "mctl_sys_init" -> "mctl_clock_init", as that more accurately described what was going on there for me
hipboi has joined #linux-sunxi
<Parthiban>
oh, that's based on 2022.10.
<Parthiban>
Is this functional tree for A133?
<MasterR3C0RD>
I haven't tested it outside of the DRAM code, which I verified worked on my device when copy-and-pasted into mainline U-Boot. Licensing on that is a bit of an open question though
<Parthiban>
I can try that for LPDDR4 in my end?
<Parthiban>
Do you have a branch or something with that changes in?
<MasterR3C0RD>
You could use it to see if the parameters are correct for your device, but no, I don't have a branch with that code. I've been working off only my own code to make sure the new implementation (which I'm trying to get mainlined) is clean
<Parthiban>
MasterR3C0RD: Ok, am currently testing your patch series for the kernel.
<MasterR3C0RD>
Awesome! As apritzel mentioned, test each of the things added; if they work, then I'd appreciate if you would add a "Tested-by" comment on the patches in my patch series that add code specifically
<Parthiban>
yeah, I will do that.
<Parthiban>
Am currently moving my devicetree based on your changes. It was in 6.10, so it will take a while.
<Parthiban>
I should be able to complete by Monday.
<loki666>
MasterR3C0RD: was comparing phy_init arrays for LPDDR4 with uboot mainline, and there are some differences
<MasterR3C0RD>
parthiban: A few things have already been pointed out in review that I'll need to resolve in a V2, but none of them are massive changes. One interesting observation is that USB should work with an "allwinner,sun20i-d1-usb-phy" compatible on the USB PHY, even without the additional compatible that was originally added for the A100
<MasterR3C0RD>
loki666: phy_init for H616?
<loki666>
yup
<Parthiban>
MasterR3C0RD: adapted that in my local tree. Yet to come to USB though.
<MasterR3C0RD>
loki666: What differences did you notice? I'm curious
<MasterR3C0RD>
Ahhhh. Yeah, it's likely slight pinout differences between the A133 and H616; LPDDR3 is very different as well
<MasterR3C0RD>
That seems to align with the theory that phy_init is used for DQ pin swizzling, which would mean the name of the function it calls makes more sense as well (it's remapping the relationship between HIF and real pins)
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
apritzel has quit [Ping timeout: 480 seconds]
<loki666>
Ok thanks was wondering because I still have lpddr4 detected as 2Gb where I only have 1
Parthiban has quit [Ping timeout: 480 seconds]
<loki666>
Tried to set the MAX_DRAM config, but uboot still hangs sometimes, I guess the 2gb being detected is just a symptom of bad training and forcing 1gb doesn't fix that
<loki666>
Anyway I'd say it's the least of the issue we have with H700. apritzel I made some more tests and your patch doesn't fix the crashes 😞
Parthiban has joined #linux-sunxi
<MasterR3C0RD>
Working on a table description of the PHY registers based on read/write patterns, hopefully it'll lead to finding some patterns that either I or other people can find
<MasterR3C0RD>
loki666: I was thinking mctl_com is a misnomer for this block on A133; it's used very differently in the H616 code than it is in the A133
<loki666>
ok was wondering, the surounding code is very similar, but then this unk_0x008 instead of unk_0x500
<MasterR3C0RD>
Yeah; I do believe this individual's decomp is accurate to what I found when decompiling, which is that only two offsets seem to be used.
<MasterR3C0RD>
I'm working on uploading register dumps of the A133's PHY that could be referred to alongside my field use reference; so far it looks like very little address space in the COM region is used
<loki666>
rha it's so frustrating... that feeling this stuff is flying (and sometimes crashing) so far above my head
<MasterR3C0RD>
loki666: Do you have serial on your device? If so, would you be willing to provide dumps of your MCTL regions? Those would be `0x04002000` (COM, 0x1000 bytes), `0x04003000` (CTL, 0x2000 bytes), and `0x04005000` (PHY, I believe 0x1000 bytes?)
<loki666>
I do but you'll have to drive me to dump that
<MasterR3C0RD>
Should be fairly straightforward, if a little tedious. You would need to go into U-Boot and type the following commands:
<MasterR3C0RD>
Each one will drop hex dumps in your terminal, you can just copy and paste those somewhere and send them over
<loki666>
ok I'll do, you want that from bsp uboot?
<loki666>
or mainline ?
<MasterR3C0RD>
Dumps from both would be interesting
<loki666>
I'll see what I can do, not sure bsp will cooperate
<MasterR3C0RD>
If not a dump from mainline is perfectly workable
<MasterR3C0RD>
Also, I understand how you feel HAHA; it took a while for even (relatively) simple concepts like the address map setup to click, and that was after staring at decomps and references for hours
<MasterR3C0RD>
Sadly a lot of the difficulty comes from the fact the PHY registers are complete unknowns; if we had information on what exactly is getting set up in functions like `phy_para_config`, things would hopefully click a lot more, and it'd be easier to research what things mean.
<MasterR3C0RD>
DFI initialization handles setting up some refreshing and mode registers (essentially additionally settings for timings that are used by both the DRAM modules themselves and the PHY)
<loki666>
I don't know what I'm looking for really, just puzzled at why the same code works "almost" 100% on device A, but more like 50% on device B, both H700 LPDDR4
<MasterR3C0RD>
That can just come down to different board designs and the DRAM modules used; sometimes they require more training or different quirks to be consistent
<loki666>
they indeed have different boards layout (not sure if the H700 <-> DRAM is that much different), but indeed I suppose a simple udelay could make the diff
<MasterR3C0RD>
That's what makes it difficult; we don't know what we're waiting/delaying for and why it matters, since the PHY is essentially a black box
<loki666>
anyway.. I'll try to get you the dumps
apritzel has joined #linux-sunxi
vagrantc has joined #linux-sunxi
<MasterR3C0RD>
Found some interesting offsets that appear to change during different bootups: +0x248, +0x278, +0x308, and +0x338
<MasterR3C0RD>
They aren't written to, so I assume those are some sort of information about calibrations. 0x248 is closest to offsets written during write levelling, while 0x338 is closest to variables written during drive_odt_config's CA drive
<apritzel>
MasterR3C0RD: btw, do you see some "eye scan" early in the DRAM setup with your boot0? Those values probably seem to be measured, and I guess might differ slightly, depending on exact voltage, temperature, and moonshine
<apritzel>
DRAM simple test FAIL----- at address 40000000
<MasterR3C0RD>
apritzel: Ooh neat find. I don't get those in my boot0, but I know an eye scan is done if a bit is set in tpr13 (bit 11 I believe); it's run during a "dram_software_training" routine
<apritzel>
I took the parameters from the output of sunxi-fw (set7, the only LPDDR4 one, and mentioned in the bootlog)
<apritzel>
but also some parameters don't seem to match the boot0 output, and some wording in the log seems to suggest that some parameters are adjusted/tuned at runtime?
<MasterR3C0RD>
Hmm, okay. I'll cross compare some of the LPDDR4 code then and see if there's a step I'm missing. Some values do get overwritten, I believe MR1 and MR2 are constants for example
<MasterR3C0RD>
Your device does appear to be doing an auto scan for DRAM parameters
<apritzel>
are those MR1/MR2 actually JEDED defined values, that just depend on the DRAM type?
<MasterR3C0RD>
I don't think so, I believe those control some timing parameters that can be different depending on the DRAM
<MasterR3C0RD>
At least on DDR4, MR0 stores burst length, read burst, CAS latency, test mode, DLL Reset, and Write Recovery/tRTP
<apritzel>
ah right, but at least they are JEDEC defined, right? And not some AW or DW invention?
<MasterR3C0RD>
Yeah, I'm reading those off JESD79-4
<MasterR3C0RD>
I don't think any of the MRs are made up, since they're all written to uMCTL2
<apritzel>
btw: very nice write up in the Wiki, btw, many thanks for that
<MasterR3C0RD>
No problem, it's useful to have something to refer to
<apritzel>
regarding hangs: in my experience, if the bus clock is gated, the interconnect just hangs on Allwinner chips, and it's not delivered back as a fault of any kind
<apritzel>
on any peripheral, not just DRAM
<apritzel>
also accesses to DRAM hang silently, before the DRAM is initialised
<MasterR3C0RD>
Ahh, that clears up what offset 0x20 is doing then
<MasterR3C0RD>
In the "MCTL_COM" registers
<apritzel>
yes, that's probably just some clock or reset gate
<MasterR3C0RD>
It doesn't appear any of the MRs are changed when using LPDDR4
<MasterR3C0RD>
Values from the dram parameters are used as-is
<MasterR3C0RD>
apritzel: What is your TPR10 parameter?
<apritzel>
was just about to post that: TPR10 is 0x273333, TPR13 is 0x81d20, at least in the boot0 binary (set 7)
<MasterR3C0RD>
Looks like it's another device where it isn't missing trainings that are causing the issue
<MasterR3C0RD>
That only wants CA bit delay, both DX bit delays, and read calibration, which are all implemented
<apritzel>
actually those values are from an update image, as I haven't been able to access the eMMC yet. Let me test if this image actually initialises the DRAM successfully ...
<MasterR3C0RD>
I just pushed up a new commit that'll add an extra debug, if you could give that a try it might help me figure out if it's an issue with aliasing
bauen1 has joined #linux-sunxi
<apritzel>
sure: it says it read 0
<apritzel>
(and the update image seems to behave the same as what's one the eMMC, both are version 0.45)
<MasterR3C0RD>
Hmm, so DRAM isn't working at all then
<MasterR3C0RD>
Let's try something else; can you comment out lines 381-383?
<MasterR3C0RD>
I wouldn't think DBI would break anything, but doesn't hurt to check
<apritzel>
so I just used the TPR11 TPR12, para1, para2 as output by boot0: I get the same error, but now it says 16 rows instead of 14
<apritzel>
sure, just a sec
<MasterR3C0RD>
Yeah, para1 controls DRAM organization, and for whatever reason the values change a little bit before they get spit out. That shouldn't cause any issues aside from not having access to all of RAM though
<apritzel>
no change without setting bit 2 in dbictl