junari has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
junari has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
arti has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
diego71 has quit [Ping timeout: 480 seconds]
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
arti has joined #linux-sunxi
diego71 has joined #linux-sunxi
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
gsz has joined #linux-sunxi
<Lightsword>
anyone know what might be causing a "dwmac-sun8i 5030000.ethernet end0: NETDEV WATCHDOG: CPU: 2: transmit queue 0 timed out 5804 ms" error?
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
apritzel has joined #linux-sunxi
<montjoie>
Lightsword: packet are not sent on the wire
<montjoie>
perhaps related to your PHY problem, no link, no send
<Lightsword>
montjoie, hmm, yeah, it works in uboot but not linux so far
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
<montjoie>
add some debug in the phy_core to check evrything is ok
<montjoie>
use ethtool/mii-tool also
<montjoie>
apritzel: good mac address with ethernet = &emac0, thanks
vagrantc has joined #linux-sunxi
<loki666>
got my A527 handheld, what's an up-to-date u-boot/atf combo for that ?
ftg has joined #linux-sunxi
<loki666>
also I don't have a bootable sd card to extract the dram params...
<loki666>
I'll try to hook a UART this weekend
<Lightsword>
montjoie, got it working by disabling the phy configuration nodes in device tree which I suspect were putting it in an invalid state after uboot had properly initialized it
<apritzel>
Lightsword: that's one hacky way to do it: set everything up in U-Boot, then just configure the DT like with a normal, external PHY (without any trace of an AC200/AC300)
<Lightsword>
apritzel, pretty much exactly what I'm doing
<apritzel>
I think I used this a while ago with the H6
junari has quit [Remote host closed the connection]
<Lightsword>
apritzel, I removed the i2c3 node entirely from the device tree
junari has joined #linux-sunxi
<Lightsword>
apritzel, is it possible that i2c isn't even needed whatsoever for the ac300 phy?
<Lightsword>
maybe mdio is sufficient?
<apritzel>
Lightsword: are you doing this after running some BSP image, or straight from power-off? Maybe the AC300 is still configured correctly from before?
<Lightsword>
apritzel, nope, works all the way from cold start just fine
<Lightsword>
note the mdio address override being used for that
<apritzel>
so at least the AC200 requires an EPHY reset and clock gate bit to be changed, plus an MDIO enable bit. The reset values are all "off" for these
<Lightsword>
apritzel, does it require that part of the initialization routine to use address 16 instead of the normal address like I'm doing?
<apritzel>
(and those bits are in the I2C device)
<Lightsword>
apritzel, hmm, let me try disabling the i2c3 part of the board initialization sequence and see what happens
<apritzel>
the AC200 manual says that the I2C slave address is 0x10, and that the PHY MDIO address is configurable (5 bits, defaults to 0)
<apritzel>
but apparently the AC300 is more different, I think jernej knew more about this, I was just under the impression that it's a subset of the AC200, with just the EPHY
junari has quit [Remote host closed the connection]
<Lightsword>
apritzel, so yeah...looks like i2c3 isn't used at all for AC300...I wonder though if any h616 boards ever shipped with a AC200 as it seems there is conditional logic with the efuse for the i2c3 initialization
<Lightsword>
does allwinner have sub revisions of boards?
<apritzel>
but interesting find about the AC300 being configured solely by MDIO
junari has joined #linux-sunxi
<apritzel>
that simplifies it, but only a bit, because we now need a separate PHY driver
<Lightsword>
apritzel, is fixup the best way to handle this situation? I mean it would be better if linux wouldn't have a hard dependency on uboot for that right?
<Lightsword>
apritzel, I think the pins still needed to be configured, but haven't double checked yet
<apritzel>
if it's really H616 vs. H618 and/or the die revision, then Linux cannot easily know, or at least it would be a nightmare to model in the DT
<apritzel>
so if Linux would just follow what it's been told in the DT, that's the easiest
<apritzel>
if we know that a particular board only ships with AC300 chips, we can hardcode, otherwise we use the auto-detection in U-Boot
<apritzel>
("hardcode" in the DT, so fixed there to AC300 only)
<apritzel>
IIRC there were boards which switched in the past between H616 and H618
<Lightsword>
apritzel, I guess the i2c3 failing to initialize might be largely harmless as long as downstream mdio nodes don't in turn fail, can device tree nodes be dependencies of other nodes while allowing failure?
<apritzel>
depends on the driver implementation, whether a certain dependency is handled as optional
<apritzel>
we have this sometimes for regulators
<apritzel>
we can just describe both the AC200 and the AC300 way in the DT, both with status = "disabled", then just enable the right one at boot time
<apritzel>
(or have one as okay, the other disabled, as some default fallback)
<apritzel>
the U-Boot build is device specific anyway, so I think it's the best place to do this auto-detection. The kernel does not guess, on the other hand, there was push-back against those things in the past
<Lightsword>
apritzel, AFAIU the AC200 and AC300 drivers are similar, just AC300 doesn't need the i2c initialization stage
<apritzel>
... which means it's quite different, actually ;-)
<apritzel>
because that's what the AC200 driver is about: an I2C controlled mixed signal chip, modelled as an MFD (multi-function device)
<apritzel>
if we just need a clock signal and some pins, that looks very much like a normal PHY
<apritzel>
so we "just" need the PWM driver, and some PHY driver. For the AC200 the latter seems optional, because the generic c22 driver worked, I think
<Lightsword>
apritzel, maybe we should have an initializer i2c3 driver node that just handles the initialization sequence as needed(i.e. conditionally skips i2c3 stuff on AC300) using efuse autodetection?
<apritzel>
why so complicated? we just describe both ways, separately, and select the right one. Either at DTB build time, for boards with just a single choice, or at runtime, in U-Boot, for the rest
<apritzel>
the cleaner the kernel part, the better. U-Boot can take a weird hack or two, because it's device specific anyway. The kernel is very generic, on the other hand
<Lightsword>
apritzel, I'm just thinking it may be more reliable to not rely on uboot I guess for the autodetection
<apritzel>
not sure what you mean with "rely", exactly. It either works or it doesn't, then people just update U-Boot
<apritzel>
I would think that many boards just need one choice anyway
<apritzel>
but by all means: propose patches on the list, it's a better place for discussions anyway
<apritzel>
(but that would mean that U-Boot and other kernels (like the BSDs) would need the same hack^Wsolution, whereas the U-Boot-only way would automatically work everywhere)
<Lightsword>
apritzel, so doing it in uboot would basically have us specific it with i2c3 in the device tree, and uboot would then copy the child node and remove the parent conditionally then copy the child node to the parent location or something?
gsz has quit [Ping timeout: 480 seconds]
<apritzel>
no, it would ideally just switch "status" properties, between "okay" and "disabled"
<Lightsword>
apritzel, switching the status to disabled wouldn't also kill the child nodes?
<apritzel>
I am thinking about having both subtrees in parallel. Maybe we just need to switch the PHY phandle on top, then
<apritzel>
Lightsword: regardless: if you get it to work without any real I2C device, can you make Linux patches for that (ignoring the AC200 for now)?
junari has quit [Remote host closed the connection]
<apritzel>
should be just DT changes then? Plus probably a (copy & pasted) PHY driver, ideally auto-detecting that PHY in the generic driver
<apritzel>
we cannot rely on any PHY setup in U-Boot, though, that would require native Linux support (a new driver, probably). PHYs are ideally auto-detected, it would be good to learn the PHY ID
<apritzel>
Lightsword: ah, thanks, so it's the efuse at 0x2c, independent from the die revision
<Lightsword>
apritzel, I see devmem 0x0300622c 32: 0x026C0506
<apritzel>
(which would make sense, as it's a co-packaged, but separate die, so something done at packaging, not as part of the main die manufacturing)
<apritzel>
so bit 8 in 0x2c, that's easy to check
<Lightsword>
apritzel, yep, mine has the bit set so makes sense that we don't need the i2c init
<Lightsword>
I've seen that bit check in BSP code as well I think
<apritzel>
so what else do you need: just that PWM clock, in by-pass mode, and those extra PHY registers?
Kirby64 has joined #linux-sunxi
hazardchem has quit [Remote host closed the connection]
<apritzel>
if you have a later(?) H616 with an AC300, and in fact the modern chips (like the H618) all have an AC300, then the AC200 would only be in the early H616 chips
junari has quit [Remote host closed the connection]
Kirby64 has quit [Ping timeout: 480 seconds]
<dlan>
apritzel: I forgot to add the alias..
junari has joined #linux-sunxi
<apritzel>
dlan: no worries, makes an easy comment on the list for me ;-)
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
<Lightsword>
apritzel, yeah, that's what I'm not sure about, I only have one board with me at the moment but I can probably check older ones we have in the field remotely
tokyovigilante has joined #linux-sunxi
<tokyovigilante>
jernej: regarding the DE33 patches, did you have any update on a plane driver?
bauen1_ has joined #linux-sunxi
bauen1 has quit [Read error: Connection reset by peer]
<apritzel>
Lightsword: so sampled my H616 class boards: the two older ones (labelled H616) I got end of 2020 / early 2021 have bit 8 clear, all the newer ones (labelled H618, or a newer(?) H313) have it set
vagrantc has quit [Quit: leaving]
<Lightsword>
apritzel, ah, so none of the ones you have labeled H616 have the bit set?
<Lightsword>
I can't actually see the label on my unit since the heat sink is hard to remove.
ftg has quit [Read error: Connection reset by peer]
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
<apritzel>
exactly, but then again I only have H616 chips from the very beginning (like 4 years ago)
junari has quit [Remote host closed the connection]
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]