ftg has quit [Read error: Connection reset by peer]
<apritzel>
nice!
<apritzel>
I think I found my longstanding MMC clock bug for the A523: the width of the P divider field is too large for the algorithm
<apritzel>
traditionally it's a "parent / M >> P" formula, with P being encoded is like 2 or 3 bits. Now the A523 replaces this with "parent / M / P", with P now being 5 bits wide
<apritzel>
and the sunxi-ng CCU code determines the maximum value of P, for sizing the outer loop, with: "unsigned int max_p = 1 << ((1 << width) - 1);"
<apritzel>
which gives ~2 billion for width=5, of course ;-)
junari has joined #linux-sunxi
Daanct12 has joined #linux-sunxi
<MasterR3C0RD>
apritzel: That must have been fun to find
<MasterR3C0RD>
Also, that bug I mentioned in the address mapping indeed solves the odd aliasing pattern of bank groups. Additionally, since there's only two possibilities on DDR4 (1 or 2 bank group bits), the check is super simple: check for aliasing at bit 6 of the HIF
<MasterR3C0RD>
If it's aliased, it's 1 bit (2 bank groups), otherwise it's 2 bits (4 bank groups)
<MasterR3C0RD>
Or rather, shift (which is 1 + bus_full_width) + 4
<MasterR3C0RD>
for the bit to check
<apritzel>
seems like you are now even reverse engineering the comments in the original DRAM code ;-)
<MasterR3C0RD>
Heh, the guy that wrote the boot0 init code wrote the weirdest code in order to do it, when it only needed a single test due to the properties of DDR4 and the controller
<apritzel>
not surprised, really, but I reckon they just lack some serious review most of the time
<MasterR3C0RD>
Very true; every time I look at the vendor tree I kinda just shake my head at some of the code, and their... interesting approaches to device tree bindings
<MasterR3C0RD>
On the other hand, I realized there's practically no barriers in their DRAM init code (there's like 2 or 3 used during test sequences), which seems to imply I could replace pretty much every writel with writel_relaxed and probably save on a decent chunk of code space
<apritzel>
yes, I had patches for doing this for the other DRAM drivers, in particular when just setting timing parameters and such
<apritzel>
given that we run with the MMU off, on a single core, and on an in-order core, the barriers probably don't do much anyways
<MasterR3C0RD>
In my original code for determining bank groups, I did notice that barriers made a bit of difference in stability, but mctl_mem_matches has barriers already so I don't need to touch that. The mctl_mem_matches_base does seem to be potentially a bit too barrier happy though; I wouldn't think full writel/readl would be necessary here either, as
<MasterR3C0RD>
there's already a dsb right before it
<MasterR3C0RD>
A dsb right before the readl to compare I mean
<apritzel>
and I was wondering if the barriers act merely as small delays at times, in our case
hipboi has joined #linux-sunxi
hipboi has quit []
hipboi has joined #linux-sunxi
<MasterR3C0RD>
I guess I can't be sure; I'll push up my updated code with the replacing of writel with writel_relaxed and see how that fares on other boards
<MasterR3C0RD>
There is a comment on mctl_mem_matches_base that dsb() isn't available on ARMv5, so potentially that's why there's full writel/readl there
<apritzel>
I am pretty sure if you set up a bunch of register you don't need barriers, as the order of writes doesn't matter anyways, until you do some final write that triggers something
<apritzel>
for example programming the timing parameters
<MasterR3C0RD>
Yeah, I think that's unnecessary. I also think that's the case for the address map registers, as those don't mean anything until the DRAM controller is out of reset
<MasterR3C0RD>
Most of the setup before MCTL_CTL is out of reset shouldn't really matter actually
<apritzel>
exactly
hipboi has quit [Quit: hipboi]
<MasterR3C0RD>
I'll take a more critical look when my H616 board comes in and can start messing with merging the code together
<MasterR3C0RD>
parthiban: I updated the DRAM init code to fix a few bugs; it should hopefully have a positive effect on your device. If not, it prints out a more accurate reading of the amount of DRAM in your system, which should give more clues
<MasterR3C0RD>
s/amount of DRAM/address aliasing occurs/
apritzel has quit [Ping timeout: 480 seconds]
hipboi has joined #linux-sunxi
flyback has quit []
hexdump0815 has quit [Ping timeout: 480 seconds]
flyback has joined #linux-sunxi
flyback has quit [Remote host closed the connection]
Schimsalabim has quit [Read error: Connection reset by peer]
<parthiban>
MasterR3C0RD: Will get some breakfast and coffee. back in an hour.
hipboi has quit [Quit: hipboi]
<MasterR3C0RD>
Afraid I can't dig any deeper tonight, but I'll keep hunting tomorrow. Considering that it's happening every time it must still be an address mapping issue; it's just a question of "why?"
apritzel has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
hipboi has joined #linux-sunxi
warpme has joined #linux-sunxi
<parthiban>
MasterR3C0RD: So far I can only help in testing this as my knowledge to DDR to super limited to none.
Schimsalabim has joined #linux-sunxi
aggi has quit [Remote host closed the connection]
aggi has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
gsz has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has quit []
mripard has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
hipboi has quit [Quit: hipboi]
szemzoa_ has quit [Read error: Connection reset by peer]