<junari>
BroderTuck: Yes, the patches are a bit confusing, but that's because I didn't do them at the same time. Maybe I'll get around to rebase them
<junari>
What kind of device do you have? If it is x96qproplus, I had to lower the emmc bus frequency to detect it correctly
Asara_ is now known as Asara
<junari>
But in reality, I haven't thoroughly tested emmc in daily work, because I want to save android image
<junari>
I also noticed that the dtsi tree lists the wrong drive-strength for the mmc pins, but increasing the value did not produce the desired result
<junari>
Also, one of the voltage values is not set correctly, but it is possible that it does not affect anything
<junari>
In the case of walnutpi, the factory image uses 2.1V for IO. After setting this voltage the emmc works well at 150MHz
<junari>
Also sometimes I can boot the OS from the emmc with a modified u-boot that sets the correct voltage value
loki6661 has joined #linux-sunxi
tvc has joined #linux-sunxi
loki666 has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
sdfgsdfs has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
tvc has quit [Ping timeout: 480 seconds]
junari_ has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari__ has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
tvc has joined #linux-sunxi
sdfgsdfs has quit [Ping timeout: 480 seconds]
evgeny_boger has joined #linux-sunxi
loki6661 has quit []
loki666 has joined #linux-sunxi
warpme has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
warpme has quit []
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
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
warpme has joined #linux-sunxi
mripard has joined #linux-sunxi
evgeny_boger has quit [Quit: evgeny_boger]
apritzel has joined #linux-sunxi
aggi has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
aggi has joined #linux-sunxi
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<paulk>
apritzel: turns out the issue for a133 was a bad sdcard
<paulk>
so the liontron board boots, now up to linux, and I see it bring up all the cores
<paulk>
did you start looking into ethernet support?
<apritzel>
paulk: oh great, thanks for testing!
<apritzel>
paulk: the Ethernet MAC itself worked, with just the fallback compatible for the A64 EMAC. But the PHY on this board is a problem, as there is apparently no pull-up for the reset pin
<apritzel>
there is a generic reset GPIO property, but this doesn't work, it looks like the code is never triggered, with our EMAC driver
<paulk>
apritzel: should I reply something to the u-boot pull request?
<paulk>
apritzel: ah interesting. I see lots of unpopulated resistors/caps around the PHY on the board...
<apritzel>
you can reply, though it's optional, typically Tom applies it after a day or so
<paulk>
ok
<paulk>
I tried adding the emac with the a64 compatible, but I get dwmac-sun8i 5020000.ethernet: EMAC reset timeout
<paulk>
and also I didn't guess the PHY address and assumed it's RMII
<apritzel>
yes, that's the symptom
<paulk>
mhh I assumed it was a MAC reset issue, not a PHY reset issue
<apritzel>
and yes, it's MDIO address 1, using RMII
<paulk>
apritzel: another thing, I tried to get adb access on the board via the usb connector (using a male-to-male cable) and it only shows up for a minute or so and then goes away :(
<apritzel>
yes, same for me, you have to be quick!
<paulk>
lol ok
<apritzel>
(assuming you mean the vendor firmware)
<paulk>
at least I got clk_summary and regulators_summary
<paulk>
yes indeed
<apritzel>
exactly what I did ;-)
<paulk>
there's maybe some trick to tell android to keep it alive but it's been too long since I've digged into it
<apritzel>
pre-typed that, and copy & pasted. Felt a bit like paid-by-the-minute Internet in the 90s ;-)
<paulk>
haha I see :)
<apritzel>
so PH12 is the reset pin for the PHY
<apritzel>
if you play around with this (for instance in U-Boot, clearing, then setting), you might get it to work in the kernel
<paulk>
I'll give it a try then
<apritzel>
there are two ways to trigger a PHY reset: via the snps,reset-gpio property in the MAC node (but I think that's deprecated), and via reset-gpios in the PHY node (preferred)
<apritzel>
I also had: reset-assert-us = <10000>; reset-deassert-us = <1000000>; in the PHY node, matching what the PHY manual says about the length of the reset pulse
<paulk>
ooh it does work!
<paulk>
(from u-boot)
<apritzel>
in my experiments it seemed a bit random, probably depending on the state of the reset pin, and the state of the PHY. Sometimes it worked after a cold boot, sometimes not
<paulk>
also the green led is always off
<apritzel>
I think triggering the PHY reset (manually) made this reliable, but somehow the DT based code doesn't trigger, if I remember my research correctly. Which seems like a generic dwmac-sun8i problem, not A133 specific
<apritzel>
and we are just lucky that most other boards do not rely on a PHY reset
<paulk>
indeed
<paulk>
I'll try to look into it then
<apritzel>
many thanks!
Hypfer is now known as Guest18727
Guest18727 has quit [Read error: Connection reset by peer]
Hypfer has joined #linux-sunxi
BroderTuck has joined #linux-sunxi
<BroderTuck>
apritzel: Verified now, the change that junari made that makes the emmc seem usable is to add a line setting max-frequency to 25M in the pro+ board dts mmc2 section
<BroderTuck>
Question is then if that's the best way to deal with it, or if something else should be done
warpme has quit []
<apritzel>
BroderTuck: 25MHz sounds wrong, that's most likely papering over something else - we had this kind of hack before, in U-Boot, at the end it turned out to be a driver problem (fixed by jernej)
<apritzel>
also it's severely limiting the performance, of course
<apritzel>
BroderTuck: and I think I checked, the BSP uses the normal frequency
<BroderTuck>
seems I dont have that particular patch included, but I tend to have that command line argument about clocks active, should cover it as well, no?
<BroderTuck>
and I agree that 25Mhz doesn't sound like the right solution.
<BroderTuck>
but it does show that it's most likely something minor that is wrong
hentai has quit [Ping timeout: 480 seconds]
<apritzel>
BroderTuck: yes, clk_ignore_unused should cover this
<apritzel>
can you check what transfer mode the BSP uses? Is it HS400 or HS200?
<BroderTuck>
according to the android bootlog that warpme poste way back when, it claims to use hs400, and 200Mh
<BroderTuck>
2024-11-20 10:43
<BroderTuck>
seems he also has the ersion with a 32G emms
<paulk>
apritzel: btw I've extracted the dt from the android boot img, in case you don't have it :)
<paulk>
it does have phy-rst = <0x5e 0x07 0x0c 0x01 0x01 0x01 0x01>;
<apritzel>
thanks, but I did this a while ago, and complemented the info from what I gathered by inspecting the running image. Did you find anything missing in the mainline DT?
<paulk>
no not really :)
<apritzel>
and yes, that's where I got the PH12 from
<paulk>
all good then
<apritzel>
I need to order those connectors, to get I2C and SPI tested
<paulk>
if you have some a133 tablet I guess there's some i2c stuff there
warpme has joined #linux-sunxi
radxanaoki has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
warpme has quit []
<paulk>
apritzel: ok I understood the issue, the mdio core assumes the PHYs are accessible at probe time as it scans their IDs
<paulk>
so the reset-gpios property has to be attached to the mdio bus, not to the PHY itself
<paulk>
because the MDIO core will not attempt to deassert PHY reset before trying to access it
<paulk>
but it does it for the "bus-wide" MDIO reset
<paulk>
apritzel: I can send patches for this if you're fine with it
<paulk>
(so nothing wrong with sun8i-emac after all!)
<apritzel>
ah, yeah, I was suspecting something about the wrong order already. If you have any patches, I am happy
<apritzel>
just find it odd, because typically the rule is that the driver enables the prerequisites, then tries to access the device
BroderTuck has quit [Remote host closed the connection]
<apritzel>
we rely on this for basically all (MMIO based) peripherals, for instance accesses to the I2C controller would hang if the clocks and reset are not enabled
<apritzel>
but that might be a specialty of the networking subsystem
<wens>
hmm, the sun20i-d1 ppu driver doesn't have a copyright notice
<apritzel>
didn't you rewrite it anyway? And isn't there some default GPL license in effect, in this case? After all it's shipped under the GPL ...
apritzel has quit [Quit: Leaving]
<wens>
it's not a full rewrite, just heavily cleaned
radxanaoki has quit [Quit: radxanaoki]
cnxsoft has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
ungeskriptet_ has joined #linux-sunxi
ungeskriptet has quit [Ping timeout: 480 seconds]
dsimic is now known as Guest18738
dsimic has joined #linux-sunxi
vagrantc has joined #linux-sunxi
Guest18738 has quit [Ping timeout: 480 seconds]
gsz has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
pmp-p is now known as Guest18741
Guest18741 has quit [Read error: Connection reset by peer]
pmp-p has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
hazardchem has quit [Read error: Connection reset by peer]