09:13 <narmstrong> minute: did you set the GPIO_OPEN_DRAIN in both uboot and linux ?

10:25 <minute> narmstrong: i noticed after some more experimentation that i don't even have to set the gpio in uboot, if i disable ethernet there, and i can use the legacy reset (snps,...) in the driver, _but_ i have to reload all the drivers once. the first time the PHY is not detected. but then it works reliably

10:25 <minute> so it might be a sequencing issue among the drivers

10:26 <minute> it looks like maybe the mdio (at least mux) and mac drivers don't have a clear dependency in terms of when which is initialized?

10:28 <narmstrong> yep this is probable

14:24 <amebag> hello *, i'm looking for an explanation for a strange behavior observed on the SPI interface. can someone point me in the right direction please?

14:24 <amebag> the behavior is that the spidev_test program shows me the expected RX results if i connect the MISO-MOSI with a jumper cable; but if i _remove_ the cable, then RX still shows some data, not only 00. agreed, the RX data is not the same as TX, the last 6 bytes seem to change randomly, but still: why is it not all zeros? where do those bits come from?

14:24 <amebag> context: i have successfully built a vanilla kernel 6.5.5 for my Odroid N2+ device, and managed to fix the device tree so that the /dev/spidev0.0 is now available. apart from the kernel, the os is a custom-built Debain Bullseye. (my precious.)

14:25 <amebag> test output with jumper cable:

14:25 <amebag> spi mode: 0x0

14:25 <amebag> root@odroid:/home/ameba# ./spidev_test -D /dev/spidev0.0 -v

14:25 <amebag> bits per word: 8

14:25 <amebag> max speed: 500000 Hz (500 kHz)

14:25 <amebag> TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D |......@.........................|

14:25 <amebag> RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D |......@.........................|

14:25 <amebag> test output without jumper cable:

14:25 <amebag> spi mode: 0x0

14:25 <amebag> root@odroid:/home/ameba# ./spidev_test -D /dev/spidev0.0 -v

14:25 <amebag> bits per word: 8

14:25 <amebag> max speed: 500000 Hz (500 kHz)

14:25 <amebag> TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D |......@.........................|

14:25 <amebag> RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FA A8 80 80 00 0D |......@.........................|

14:25 <amebag> thanks in advance.

14:27 <f_> amebag: Please don't spam the channel with logs. Use a pastebin.

14:31 <f_> oh well

14:32 <f_> I'll update all gxbb defconfigs with the required SPL config

14:33 <f_> to ease testing

14:53 <f_> oh nice I broke support for gxbb

14:57 <f_> initcall sequence 000000000106b7d8 failed at call 000000000101ceac (err=-12)

15:15 <f_> I'll try `make clean` && `make`

15:15 <f_> but uh oh

15:15 <f_> (even with the last working HEAD it crashes..)

15:17 <f_> meson_gx_mmc and simple_bus failed to bind

15:18 <f_> errno ENOMEM ???

15:34 <f_> hmm happens with Amlogic BL2 too...

15:35 <f_> ^ narmstrong any idea what it could be?

15:35 <f_> https://bin.vitali64.duckdns.org/6512fa4d

15:36 <f_> Tested with an old build and it worked.

15:36 <f_> So that's not the board

15:49 <f_> Did some research and...

15:50 <f_> Perhaps MALLOC_F_LEN is too small?

16:00 <f_> It was that

16:00 <f_> but then SPL still fails to run SCP :/

16:02 <f_> CONFIG_DRAM_SIZE seems wrong to me. Gah.

16:06 <f_> Ah it works now lol

16:10 <f_> all right

16:10 <f_> my pmOS+XFCE install is still intact :P