ftg^ has quit [Read error: Connection reset by peer]
aperezdc has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
aperezdc has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
hexdump02 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
<parthiban>
apritzel: Good morning. Regarding the testing for LPDDR4 4GB RAM for A133 SoC, I couldn't get response from MasterR3C0RD yet. So in the meantime, is there a way I can get into this topic to analyze the root cause? Am very new to DRAM stuff and the documentation posted is high level to me. Could you please recommend a way? Many thanks.
JohnDoe_71Rus has joined #linux-sunxi
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
evgeny_boger has joined #linux-sunxi
evgeny_boger has quit [Quit: evgeny_boger]
mripard has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
colinsane has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
radxanaoki has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
radxanaoki has joined #linux-sunxi
radxanaoki has quit [Quit: radxanaoki]
warpme has quit []
warpme has joined #linux-sunxi
<wens>
apritzel: looking at the datasheets, it seems the t527 doesn't have vcc-pf? instead it's vcc-io for 3.3v and vcc-mcsi for 1.8v
iscle has joined #linux-sunxi
warpme has quit []
<apritzel>
wens: yes, I don't think any Allwinner SoC has a separate VCC-PF power input, it was always using VCC-IO. Since H616 you can switch the PortF I/O voltage between VCC-IO and some always-1.8V rail
<apritzel>
I wrote some code to expose this PIO bit as a regulator, to enable UHS SD cards, but it didn't work, I didn't see the MMC subsystem even trying to set the voltage
<apritzel>
I guess I misunderstood how this SD card I/O voltage switch is supposed to work in the kernel, would be grateful for any hints on this
warpme has joined #linux-sunxi
<apritzel>
wens: or are you referring to the vcc-pf-supply DT property?
<wens>
apritzel: the DT property
<wens>
as for the voltage switch, I think it's supposed to be the vqmmc-supply on the card side?
<wens>
the mmc core doesn't really handle I/O pin supplies on the SoC side AFAIK.
<apritzel>
yes, that was my hope: I pointed vqmmc to this regulator exposed by the pio DT node
<wens>
did you also set the properties to enable the uhs modes?
<apritzel>
and the MMC subsystem correctly *read* the voltage from there (saying 3.3V initially), but I never saw it trying to switch to 1.8V
<apritzel>
yes, I added the UHS nodes, peeking at Rockchip, where I think UHS works
<apritzel>
s/UHS nodes/UHS properties/
<wens>
there's some bit of code in our mmc driver that masks out the higher speeds
<apritzel>
junari: I integrated the regulator code into the pinctrl driver, which avoids the slightly sketchy syscon dance
<junari>
Looks like aw will have a new processor with 4xA76 and 4xA55 called T857
<apritzel>
junari: I guess this code is using the BSP MMC driver version?
<junari>
I don't know
<wens>
apritzel: orangepi board has SPI, so I'll give it a try
<apritzel>
well, I tried the r329 compatible already, and it didn't work. Then I checked BSP code, and found a hint about this difference.
<junari>
wens: orangepi 4a?
Guest17235 has quit [Ping timeout: 480 seconds]
<wens>
yeah
<apritzel>
wens: seems like the old FIFO level register at 0x1c is still around, but doesn't provide the right value anymore, which is the confusing part, I guess
<wens>
:(
<wens>
new compatible then :(
<apritzel>
yes, definitely, and more so some refactoring in the SPI driver ...
<apritzel>
wens: thanks for looking at this
<junari>
wens: If you have time, check out the thermal patches
<apritzel>
wens: do you know which MAC the OPi4A is using? EMAC0 or EMAC1? The X96QPro+ oddly enough uses EMAC1 for its sole Ethernet port, so am curious here
warpme has joined #linux-sunxi
<wens>
looks like it's emac1
<apritzel>
wens: bummer, but a good push for getting this supported as well. And it seems like you were right, the stmmac driver already supports those "other" DMA descriptors, we would just need to enable them somehow
<apritzel>
the BSP driver I looked at was mostly (duplicated) sunxi platform glue boiler plate, and was deferring the actual functionality to the existing stmmac code
<wens>
junari: I wish I had time
<apritzel>
junari: thanks for sending this, and apologies for not having looked at that yet. I will try to do that ASAP
JohnDoe_71Rus has joined #linux-sunxi
<wens>
sunxi_set_gate: (CLK#35) unhandled
<wens>
in u-boot
iscle has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Ping timeout: 480 seconds]
junari_ has joined #linux-sunxi
junari has quit [Remote host closed the connection]
apritzel has quit [Remote host closed the connection]
junari_ is now known as junari
apritzel has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari_ is now known as junari
<junari>
Yeah, no problem. A thorough check takes some time. Also, I haven't checked interrupts. And also I don't quite understand the correct DT binding to tell htop to distribute the temperature to all cores, not just core0 and core4
<loki666>
apritzel: you think you could help me with LPDRR3 on A527 ?
test143345 has joined #linux-sunxi
<apritzel>
loki666: ah sorry, what's your device again? One of those handheld gaming consoles, with an A527 and LPDDR3? And did you have a firmware update file for that?
<apritzel>
Helegaly Action Pi?
<apritzel>
(sorry, but sometimes getting lost in all those devices people play around with. A wiki page would help to collect information in one place ...)
<loki666>
yes, the Helegaly Action Pi, I gain ssh access to the batocera (overwritting their random root pwd with mine via batocera user scripts on SD)
<loki666>
I do have an Phonex Img
<apritzel>
so typically the best way is trying to dump DRAM registers after the BSP has initialised the DRAM, which would be done from the vendor Linux, for instance, if you have root there
<apritzel>
loki666: can you dump the DRAM parameters with sunxi-fw?
<loki666>
how should I dump the DRAM regs from ssh ?
<apritzel>
loki666: you can use peekpoke to dump registers, provided the BSP kernel allows access to /dev/mem. This is a static arm64 binary build of it: https://paste.c-net.org/CosmoSandoval
<apritzel>
(should run on every arm64 Linux machine)
ftg has joined #linux-sunxi
<apritzel>
gather the addresses of the various DRAM IP from the DRAM driver, then dump it, like this: "./peekpoke d.l 0x03120000 11", to dump the first 11 registers of COM
<apritzel>
then you could go through the code to see where LPDDR3 support is missing, and try to figure out what registers are written for the other DRAM types
<apritzel>
and you could try to cross-correlate with what other DRAM drivers (like the H616 one) do for LPDDR3, and how that differs from the DRAM we already support (LPDDR4, DDR3)
<apritzel>
I am afraid I cannot give much more directed advise, as I don't have that much experience with those DRAM internals either
<apritzel>
and then hope that you come up with some interesting results or questions that tickle jernej or MasterR3C0RD ;-)
<loki666>
apritzel: thanks I'll see what I can do
kuba2k236 has quit [Ping timeout: 480 seconds]
linkmauve has left #linux-sunxi [Error from remote client]
<apritzel>
dlan: btw: there is no clean or simple solution yet for the sunxi-gate error message on the A523. You can provide a dummy clock for that, but the real question is why the CCU driver is enabling all those clocks in the first place
<apritzel>
they are just the root clocks, use in Linux to do the frequency calculation (which U-Boot doesn't use yet). And these clocks are enabled already, plus U-Boot wouldn't even know how to enable or disable them anyway, as they are just dummies
<dlan>
apritzel: for why enabling all clocks.. don't know, haven't investigated.. provided a dummy clock would at least silient the warning, make people less panic..
<apritzel>
dlan: well, I know the reason: it would be the right thing to do from a DT perspective and to have a clean driver design, but it's actually pointless in U-Boot
<apritzel>
dlan: can you try to disable the clk_get_bulk()/clk_enable_bulk() calls in drivers/clk/sunxi/clk_sunxi.c:sunxi_clk_probe()?
<apritzel>
dlan: and yeah, if you really care about the warning, you can add a GATE_DUMMY entry, like CLK_APB1 does
kuba2k236 has joined #linux-sunxi
barni2000[m] has quit [Ping timeout: 480 seconds]
exkc has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]