00:13 <saintdev> xdarklight: that patch appears to "fix" the issue with ethernet

00:18 <xdarklight> saintdev: "nice". I guess it's some timing problem but I've no idea where to start debugging

00:19 <saintdev> I think you might be right. when I powered my C1 back up after copying the patched kernel package to the SD card, the network came up on the old kernel

00:20 <saintdev> I rebooted a few times on that kernel and it didn't come up again lol

00:20 <saintdev> The patched one has come up every time so far (about 5 or 6 reboots)

00:52 <afaerber> Hm, looks like S905X GPIOAO has no interrupt support, only the non-AO one?

01:39 <saintdev> How do I set the MAC address? it doesn't seem to be picked up from u-boot.

08:30 <xdarklight> saintdev: unfortunately you have to do it in userspace, see https://wiki.archlinux.org/index.php/MAC_address_spoofing for some options

08:32 <xdarklight> afaerber: it should have GPIO IRQ support on GPIOAO* but probably not on TEST_N and RESET_N

12:25 <afaerber> xdarklight, I found only one gpio-intc node in the linux-next DT though, navigating down to meson-gx.dtsi (and I'm testing 5.1.7)

12:25 <afaerber> so I was wondering whether the hardware doesn't have it or whether it's not yet implemented or whether I'm just not seeing it...

12:26 <afaerber> GPIOAO_8 is the one I'd need for a HAT

12:28 <xdarklight> afaerber: are you requesting the GPIO IRQ via the GPIO number or directly via the gpio-intc?

12:29 <xdarklight> gpio_to_irq is not implemented yet, so you have to use the latter (like it's done for the Ethernet PHY IRQ)

19:51 <zkrx> anyone's got a clue why I can't reboot with microSD on odroid n2? here are the logs https://pastebin.com/raw/dt5LGSHy

19:51 <zkrx> I tried two different cards

20:01 <xdarklight> zkrx: random guess: maybe Linux turns off the TFLASH_VDD and u-boot doesn't turn it back on?

20:02 <xdarklight> zkrx: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts#n47 try adding a regulator-always-on; property in this node

20:22 <zkrx> wow it works

20:22 <zkrx> xdarklight: ^

20:23 <zkrx> xdarklight: is this the proper way to fix it?

21:34 <xdarklight> zkrx: I believe the proper way is to fix u-boot, but I'm not sure if all vendor u-boots are affected (then it's very likely that we should fix it in Linux)

21:34 <xdarklight> narmstrong: ^

21:35 <xdarklight> actually, it may even be a bootrom issue. so I'm not sure if a "fix" requires shipping new chips

21:48 <zkrx> xdarklight: I don't think we can fix this in U-boot. As you just said, it's the bootrom that fails here. Linux needs to leave this regulator enabled.

21:58 <xdarklight> zkrx: there are some suspend related regulator flags but none for shutdown/reboot. I guess this means we need to talk to the regulator maintainers and see what they think about this