08:02 <hexdump0815> xdarklight: i'm on 5.9.11 now and the clocks are still wrong - do you have your config and dts somewhere online so that i can build a kernel exactly like yours to rule differences in there out?

08:17 <asdf28> hexdump0815: what isn't working on your device?

08:18 <asdf28> kernels > 5.8 broke a lot for me

08:19 <hexdump0815> asdf28: eth using the external phy, i.e. gbit eth port - i'm using it with 100mbit only (so no gbit problem) and it looks like rx works and tx not - clocks seem to be wrong

08:20 <hexdump0815> asdf28: but for xdarklight it works well with 5.9.11 on his (different) box

08:21 <asdf28> hmm

08:21 <asdf28> ~5.8.5 broke LAN for me but it was an external USB adapter

08:22 <asdf28> and graphics don't work anymore, everything runs at 5 fps

08:22 <asdf28> so it's just a wild guess, but if you haven't tried 5.8 yet, give it a go

08:26 <hexdump0815> but as it works with v5.9.11 for xdarklight: i guess its either a problem of my setup or the box

08:43 <asdf28> just saying. trying different kernels is quick and easy, and will also allow you to pinpoint which commit introduced a bug

08:43 <asdf28> not everything breaks for everyone

08:45 <hexdump0815> yes - but i had that non working eth on that box also with older kernels - its not just v5.9

08:45 <asdf28> oh, okay. i thought maybe you started with a bleeding edge kernel to begin with

08:46 <hexdump0815> xdarklight: with v5.9.11 i now get "meson8b-dwmac ff3f0000.ethernet: The only allowed RGMII RX delays values are: 0ps, 2000ps" with a value of 800 in the dts - also saw this when testing the libreelec images from chewitt

08:49 <chewitt> hexdump0815: I have @xdarklight RFC patches which use picoseconds not milliseconds in my 5.10.y branch

08:51 <hexdump0815> chewitt: me too and i think we both get the above warning with his setting of 800ps

08:51 <chewitt> I saw a few general issues in 5.9, but 5.10 is quite stable and I would recommend using 5.10

08:52 <hexdump0815> asdf28: thx for the pointer to older kernels - i just booted an old 5.6.13 kernel and there the clocks are ok but looks like the phy is not connected properly - will try to build a kernel now with the config from back then

08:53 <chewitt> I've seen some issues with GX devices where I need to disconnect/connect ethernet before the interface comes up

08:53 <chewitt> but nothing on G12A or newer

08:53 <chewitt> I didn't have time to see if that's resolved by reverting @xdarklight patches or not

08:54 <chewitt> hexdump0815 what box do you have, and is the dts in a repo somewhere?

08:56 <hexdump0815> chewitt: https://github.com/hexdump0815/linux-mainline-and-mali-amlogic-kernel/blob/master/misc.aml/dtb/meson-sm1-h96max-x3.dts

08:58 <chewitt> what wifi/bt chip is in the box?

08:58 <chewitt> (unrelated to ethernet I know)

08:59 <hexdump0815> broadcom - that one works kind of

09:03 <chewitt> https://chewitt.libreelec.tv/testing/9.80/LibreELEC-AMLGX.arm-9.80.7-box.img.gz

09:03 <chewitt> pick the x96-air-4g dtb

09:04 <chewitt> (edit uEnv.ini)

09:04 <chewitt> and see what happens

09:04 <chewitt> when booting LE from SD card

09:05 <chewitt> the image should boot from vendor u-boot (which I guess you're using)

09:07 <hexdump0815> did that yesterday - did not work ... this is why i know that you have this 2000ps warning in your images as well :)

09:08 <hexdump0815> one thing is a bit suspect maybe: "meson-g12a-pinctrl ff634400.bus:pinctrl@40: pin GPIOZ_2 already requested by ff3f0000.ethernet; cannot claim for ff661000.audio-controller"

09:08 <hexdump0815> maybe there is something not ok between audio and eth? - compiling a kernel without audio now

09:10 <chewitt> I think it just means your box deviates from the reference design a little .. but without schematics it will be hard to tell

09:10 <chewitt> so far the sm1 box device i've seen have all worked with the ac2xx dtsi that I created

09:16 <hexdump0815> are there any plans to upstream those dts?

09:16 <chewitt> have you tried booting 5.10 with the SEI610 or C4 dtbs?

09:16 <hexdump0815> not yet

09:17 <chewitt> I'd like to get confirmation that @xdarklight patches for ethernet are accepted first, or I need to rework them a little

09:17 <chewitt> so I will send upstream, but prob. not until the 5.12 merge window

09:30 <chewitt> vim3l is also sm1

09:30 <chewitt> see if any of the other sm1 device trees work (with 5.10)

09:31 <chewitt> it might give a better starting point for creating a dts

09:52 <hexdump0815> chewitt: i think i saw that "having to replug eth to make it work" on gx as well - that was without the picosecond patches, so they can't be the reason

09:53 <hexdump0815> chewitt: btw. i saw that you defined the wifi entry for that mediatek wifi in the a95xf3 dts, but there is still no driver for it - or is there any for mainline meanwhile?

09:54 <chewitt> the BT driver is upstream, but no support in mt76 for wifi, and I didn't find a recent-enough vendor driver to get working on mainline yet

09:55 <chewitt> the other chipset I've seen is the RTL8822CS which I got a driver for, which compiles, but I still didn't get anyone to confirm works yet

09:56 <chewitt> I suspect both the MT and RTL BT nodes/drivers will need some tweaking to get working

09:56 <chewitt> as both look like they were implemented for a specific device

09:56 <chewitt> and past experience is that Amlogic boards require different baud rates etc. to work

09:57 <chewitt> so far I had a number of 'success' reports for booting and general, but then people revert back to vendor kernels for various reasons and stop answering Qs

14:29 <chewitt> [ 0.000000] [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader!

14:29 <chewitt> ^ any suggestions on why that message is in all my logs

14:30 <chewitt> using mainline u-boot

14:51 <narmstrong> chewitt: it's a recent message, we should now use aligned addresses instead on the weird amlogic 0x18000ish

18:00 <hexdump0815> xdarklight: a little update - i tried several old kernels i had around and with 5.6.13 the clocks were looking like yours but eth did not work (maybe due to some missing hacks back then)

18:02 <hexdump0815> xdarklight: with 5.8.0 the clocks look like mine (i.e. under mpll2) but i got ethernet working by changing the phy mode to rgmii - this is the working dtb: https://github.com/hexdump0815/linux-mainline-and-mali-amlogic-kernel/blob/02f7e5b9262dac4fdaed05f603a719ef0dea7a35/misc.aml/dtb/meson-sm1-h96max-x3.dts and config:

18:02 <hexdump0815> https://github.com/hexdump0815/linux-mainline-and-mali-amlogic-kernel/blob/02f7e5b9262dac4fdaed05f603a719ef0dea7a35/config.aml-5.8.0-stb-aml%2B

18:04 <hexdump0815> xdarklight: 5.9.11 looks like my initial 5.9.3 with clocks under mpll2) but eth was not working ... will sync the dtb settings to the working ones from 5.8 for that version next and if that does not help remove your picoseconds patch ... also compiling 5.10-rc6 in parallel

19:01 <hexdump0815> xdarklight: v5.9.11 with the eth+ext-mdio taken from the v5.8.0 working dtb mentioned above gives me working eth on v5.9.11 too - clocks are still below mpll2 in this case

19:37 <hexdump0815> xdarklight: maybe an amateur explanation try from my end - the clocks are not really the problem - it seems to work if we kind of force 100mbit which might need other clocks and ending up below mpll2 might be ok

19:39 <hexdump0815> xdarklight: the problem seems to be getting to 1g mode properly and as i understand it for that your picoseconds patch is supposed to help

19:40 <hexdump0815> xdarklight: either the patch has a problem or my settings were wrong as i got "meson8b-dwmac ff3f0000.ethernet: The only allowed RGMII RX delays values are: 0ps, 2000ps" with 800ps which i think should be ok

19:43 <hexdump0815> xdarklight: or my boxes are very different as it seems to work well for your box ... at least we can investigate it now from a working starting point which is a bit more comfortable - i'll soon have a 5.9.11 and a 5.10-rc6 kernel and can try out things and there is no hurry from my side

19:44 <hexdump0815> xdarklight: so in case you have an idea what i should maybe try, please let me know (i'm reading the irc regularly even if i'm offline btw.)

19:59 <hexdump0815> xdarklight: oh - ihave some new boot up messages in the v5.9.11 with v5.8.0 dts and working ethernet case: "mdio_bus 0.0: ethernet-phy@0 has invalid PHY address" and "mdio_bus 0.0: scan phy ethernet-phy at address 0" - but as said: eth works

20:45 <hexdump0815> xdarklight: last test - same settings which work for the sm1 box do not seem to help for the g12a box - tried tx delay 0 & 2ns, all symptoms are the same: rx works (tcpdump sees something), tx not, clocks below mpll2

23:04 <hexdump0815> xdarklight: correction required - i got it working with that dts on g12a too now - the reason is that i compiled both kernels separately and had a minor change in them which i overlooked (dtb was the same both times)

23:07 <hexdump0815> xdarklight: the difference between the working and non working kernel was mainly that in the working one all SND_MESON and SND_SOC_MESON were disabled (plus some minor changes that can't give problems like F2FS and COMPRESSION/CRYPTO settings)

23:08 <hexdump0815> xdarklight: can it maybe be that the sound stuff with its dozen of clocks somehow breaks the ext phy? do you have those SND options enabled in your working kernel?

23:17 <hexdump0815> xdarklight: for completeness - here is a full diff of the working and non-working config: https://pastebin.com/raw/8aemxPaV