<MasterR3C0RD>
Took me three hours to figure out that MUSB and Device Model support are incompatible...
apritzel has quit [Ping timeout: 480 seconds]
<loki666>
apritzel I didn't tested yet... I applied your patch, but didn't had the time to test. I'll try today and report
<tokyovigilante>
wens: thanks I will try and implement the headphone switch as a separate patch.
<tokyovigilante>
apritzel: yeah that was great to see, hopefully the DT and clock patches get picked up shortly too, thanks again for all your help with the clocks in particular.
<loki666>
tokyovigilante does your DE33 supports rotation (for RG28XX)?
warpme has joined #linux-sunxi
<loki666>
aprizel patch doesn't seems to have an effect
<loki666>
I'll try to drop some OPP, but I didn't understood your other comment about keeping a bit and flipping another like for D1
<wens>
apritzel: can I get a reviewed by on the clock patch?
<tokyovigilante>
loki666: it can in theory, but the module appears more or less completely undocumented beyond a 64k register block rerefence. there is slightly more detail in the DE2 docs so hopefully it's carried over
<loki666>
tokyovigilante ok I'll try
Schimsalabim has quit [Read error: Connection reset by peer]
<apritzel>
loki666: ah, so your problem stem from an I2C failure. Do you have the patch to enable the pull ups?
<loki666>
apritzel well this time it reported as an I2C error, but sometime it's something else, so maybe it's just another manifestation of this
flyback has joined #linux-sunxi
<loki666>
I have the patch you posted applied yes
<loki666>
but the other thing you wanted to try about how D1 is doing, I have no clue wher to patch this
<apritzel>
but this error is clearly because it couldn't set the required voltage, -110 is time out, because the I2C bus locked up (typically because of missing pull ups)
<apritzel>
I have three patches for the clocks now, but scratching my head because it works perfectly fine on my (H618) boards, with and without the patches, and I think the clocks are identical
<apritzel>
for the D1 approach, you just swap BIT(31) and BIT(27) between the PLL definition at the beginning of the clock driver and the sun50i_h616_ccu_probe() routine at the end
<loki666>
ok gonna try
<apritzel>
so it's: ".enable = BIT(27)," in line 19, and "val |= BIT(29) | BIT(31);" in line 1111
<apritzel>
also did you try the patch I put on my gist?
<apritzel>
I have another one, to allow the PLL to re-lock, as recommended by the manual
<loki666>
the pll notifier yes, not changes
<loki666>
".enable = BIT(27)," line 39 no ?
<loki666>
should I change the .enable in all, or just for pll_cpux_clk ?
<apritzel>
you would indeed need to change them all, as the change below affects all of them
<loki666>
ok
<apritzel>
and line 39, yes, sorry
<loki666>
ok gonna try that, also to test the issue with I2C, would disabling all opp but the 0.9v could validate the hypotesisi ?
<apritzel>
well, if you cannot talk to the PMIC, you probably have bigger problems. Do those messages appear earlier?
<loki666>
no
<loki666>
there are alot of references to BIT(31) in drivers/clk/sunxi-ng/ccu-sun50i-h616.c, should I change them all ?
<loki666>
maybe not same reg
<apritzel>
only for the PLLs
<loki666>
ok
<apritzel>
basically all those that have that "#define SUN50I_H616_PLL_..." line just before the bit
Parthiban has joined #linux-sunxi
<apritzel>
(because this corresponds to the code below: for all those definitions, it goes and toggles the other bits, see "static const u32 pll_regs[] = ..."
<loki666>
and these cpufreq issues, happened when PMIC was addressed over rsb bus alos
<apritzel>
I wonder if these are separate issues: if the board is designed to use RSB, which is push-pull, it probably doesn't have pull-up resistors on those pins
<apritzel>
so you would need to enable the internal pull-ups, in the DT
<apritzel>
just adding "bias-pull-up;" to the r_i2c_pins node
<loki666>
Ok I'll try that also. Thanks for the help. These things are really beyond my league...
<apritzel>
ideally in the board .dts, in that &pio node: r_i2c_pins { bias-pull-up; };
Schimsalabim has quit [Read error: Connection reset by peer]
hipboi has quit [Ping timeout: 480 seconds]
<loki666>
apritzel: so BIT(31) flip + bias-pull-up + Reparent CPU clock patches doesn't fix
<loki666>
it boots, but when it crashe I don't even get a kernel oops
<loki666>
but what's weird, is that if I set ondemand gov, the trans_table show various cpu freq changes, until I launch stress-ng which crash very fast
<apritzel>
and you can definitely attribute this to cpufreq? Or even just the schedutil governour?
<loki666>
schedutil + ondemand and I think conservative gov also do crash at some points
<apritzel>
otherwise I would say that random kernel crashes, especially under load, point more to DRAM problems
<loki666>
only powersave + perf are stable
<loki666>
possibly
<loki666>
ah now
<loki666>
perf is stable
<loki666>
let met double test perf gov
<jakllsch>
perf should have no transitions, except perhaps for thermal throttling
<loki666>
yes but that would rule out DRAM probems
hazardchem has quit [Read error: Connection reset by peer]
hazardchem has joined #linux-sunxi
<loki666>
performance is stable when running stress-ng, and cpu did transiton from 1008 (boot setting I guess) -> 480 (kernel default powersave) -> 1512 (manual perf)
Schimsalabim has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
dsimic is now known as Guest7430
dsimic has joined #linux-sunxi
Guest7430 has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
wingrime-ww has quit [Quit: WeeChat 4.4.2]
wingrime-ww has joined #linux-sunxi
Parthiban has joined #linux-sunxi
<MasterR3C0RD>
Quickly took a look at the vendor tree for the A133 again, as I was curious about its OPP tables; looks like it has an additional set of nvmem values that determine chip "version", which seems close to what was done on the H616. Comments imply a difference between "ic version A-E" and "ic version F and later version"
<MasterR3C0RD>
There's also a "bin_extend" field
<MasterR3C0RD>
s/field/cell/
<apritzel>
MasterR3C0RD: is there any chance you could write down some of your learnings about the DRAM controller? Maybe in the Wiki?
<apritzel>
No need for a novel, but some home explanations (what is DFI?), hints, relationships between parts, pointers to other doc, etc.
<apritzel>
could be terse, and aimed at people with prior knowledge, so no need to explain basics
<MasterR3C0RD>
Sure; I did figure out the exact IP used for "MCTL_CTL" (Synopsys DWC uMCTL2 "Enhanced Universal Memory Controller"), which is the same one used in the H616 and (as previously figured out) the Zynq UltraScale+ SoCs, so I can add that into the IP cores as well
<MasterR3C0RD>
I'll be honest that I'm still unsure of the finer details regarding DRAM, but I'll try my best to write up a decent explanation of what I've figured out
apritzel has quit [Ping timeout: 480 seconds]
flyback has quit [Ping timeout: 480 seconds]
flyback has joined #linux-sunxi
<Parthiban>
MasterR3C0RD: +1 for the wiki/doc about DRAM.
warpme has quit []
<MasterR3C0RD>
Not sure if anyone can even answer this, but is the phy_init array, which in boot0 is used in a "phy_address_remapping" function, meant to configure swizzling of some sort? Had a bit of a realization: there's a special case in the MCTL address map setup code that checks something to the effect of cols_bit + row_bits + rank_bits == 27, the phy_init
<MasterR3C0RD>
array is 27 elements, and each element in "phy_init" is in the range of 0 to 26
<MasterR3C0RD>
Once is by chance, twice is coincidence, three has to be a pattern
<Schimsalabim>
MasterR3C0RD: if you look at the various schematics floating around (i.e. for H616/etc) and the different pinouts for DRAM setup (DDR3 v.s LPDDR v.s DDR4) you can see a connection between the pins used on the SoC and the numbers in init_phy[]. seems to be a direct relation.
<MasterR3C0RD>
Schimsalabim: Cool! I'm assuming it was already known then, but that helps give an idea as to what different parts of the init code are actually doing
<MasterR3C0RD>
s/give/get/
<Schimsalabim>
Not sure whether that is generally known.
<Schimsalabim>
But it does help to understand the components that make it all up. yes.
<apritzel>
MasterR3C0RD: in general there is little knowledge out there about the DRAM controllers, so *any* kind of information helps
<apritzel>
some people have some experience, but apart from the old days (I think A10) this is rarely documented
<apritzel>
because we mostly get it working at some point, and then move on
<paulk>
definitely, I would too love to see more documentation about dram
MasterR3C0RD has left #linux-sunxi [Bye-bye!]
MasterR3C0RD has joined #linux-sunxi
<MasterR3C0RD>
I'll take a crack at it then in the coming days
<paulk>
btw the DFI spec is public
<paulk>
the acronym stands for "DDR-PHY Interface"
<paulk>
it's basically a generic glue layer between the DDR controller and a PHY, allowing to use either from different vendors
<paulk>
in Synopsys designs it's implemented in the PUB/PUBL part of the PHY
<MasterR3C0RD>
^ that's what I had determined as well
<paulk>
PUB/PUBL is the logic part driving analog parts of the PHY, which is what holds the PHY registers
<MasterR3C0RD>
So that implies that MCTL_PHY0_BASE is pointing to the PUB/PUBL block?
<paulk>
yes absolutely
<paulk>
my guess would be that H616 is using one of the DW MultiPHY
<paulk>
maybe a dwc_lpddr4_multiphy
<paulk>
it's also used in imx8q
<MasterR3C0RD>
I had the exact same theory, but any public code I could find on any of the DWC PHYs didn't quite match up with what I had found
<paulk>
yes there quite some variations between different models
<MasterR3C0RD>
I've been trying to get a better idea of what different registers mean so that the actual initialization has more comprehensible flow; with the current implementations having loads of magic numbers and offsets it's been fairly difficult for me to debug any issues with my code. At least some information can be derived from where they're being used
<MasterR3C0RD>
in the init code; the (fairly likely to be) swizzle controls for example are in a "phy_set_address_remapping" function, and there's some different registers used during trainings, ODT mapping, etc. Sadly none of them have given me a good fingerprint to use to figure out the PHY based on publically available documentation yet
<MasterR3C0RD>
s/publically/publicly
apritzel has quit [Ping timeout: 480 seconds]
<paulk>
mhh doesn't seem to match the imx8q unfortunately
<MasterR3C0RD>
It would seem to be that it'd be an DWC PHY; which one it is is an open mystery I suppose, but the function that actually initializes the PHY is called "ddrphy_C_initPhyConfig", which seems to match prints from other boards using DWC PHYs
<MasterR3C0RD>
paulk: Also, the code above wasn't for the STM32MP1 specifically, it's also for the MP2
<MasterR3C0RD>
There are ifdefs checking for DDR4
<paulk>
oh right
<paulk>
probably only for mp2 actually
<paulk>
mp2 has dwc_lpddr4_multiphy_v2 as far as I know
<paulk>
which is the one where the PHY has an ARC core and runs a firmware
<MasterR3C0RD>
Ahhhhh
<MasterR3C0RD>
Perhaps the A133/H616 uses its predecessor then
<paulk>
well normally that would be dwc_lpddr4_multiphy, but that's the one that should be on imx8q and registers don't match
<MasterR3C0RD>
Right... I wonder what it could be then. The user manual for the A133 claims, at least, to support DDR3, DDR3L, DDR4, LPDDR3, and LPDDR4
<MasterR3C0RD>
Assuming the only difference between DDR3 and DDR3L is voltage levels, that would match up with my findings
<jakllsch>
yeah, DDR3L and DDR3 is basically just voltage level change
<paulk>
well I looked around and couldn't find any match :(
<paulk>
maybe Allwinner customized the layout too
<paulk>
they did that a few times already
<paulk>
or maybe it's not Synopsys and they just reused code that still has similar naming
<MasterR3C0RD>
The only other vendor I could find would be Cadence
<paulk>
right, Cadence is the other big player for both controllers and PHYs
<paulk>
but there's a bunch more that are less known/used
apritzel has joined #linux-sunxi
<loki666>
apritzel: hey... i was about to reports that your patch without BIT31 flip was working... but then