06:24 <mmind00> TahomaSoft: glad things worked out

08:49 <diederik> user21: I see a "supply phy not found, using dummy regulator", so it's probably missing a phy-supply property (or sth like that)

09:43 <TahomaSoft> mmind00: Thank you very much for your help!

10:27 <TahomaSoft> Is refining it for a bit, shooting to patch into Linux 6.18 a reasonable goal?

10:37 <robmur01> TahomaSoft: almost certainly! New board DTs are fairly straightforward, and you've probably got at least 5 weeks

10:49 <TahomaSoft> Thanks robmur01!

10:50 <robmur01> in fact the next 5-6 weeks would be for 6.17 stuff - I always get confused right at the start of a cycle :)

10:54 <robmur01> I'd suggest having a look through the list archive at similar new board submissions to get a feel for what the reviewers want to see, and with luck you might get it done in only a couple of spins

10:58 <TahomaSoft> Thanks, good idea. I subscribed to the list in part to see them as they come in to get a feel for that. Any particularly notable boards I should look at?

11:13 <robmur01> Most vendors don't stray too far from the reference designs, so similar RK3568 router boards upstream like NanoPi-R5 or BPi-R2-Pro would be the first things I'd compare against

11:15 <robmur01> for the actual reviews, something like https://lore.kernel.org/linux-rockchip/?q=rk3568+dts+board seems an OK starting point to sift through

12:24 <diederik> TahomaSoft: I have the NanoPi R5S and it is supported both in OpenWrt and upstream. Currently I have both on (separate) SDcards

14:11 <macromorgan> is the only valid offset for the idbloader.img (talking about an rk3566) at block 64 (0x40)?

14:12 <macromorgan> or are there other valid locations the bootrom checks as well?

14:20 <a3f> macromorgan, there are multiple afaik, see: https://github.com/barebox/barebox/blob/master/arch/arm/mach-rockchip/bbu.c#L19-L24

14:23 <a3f> for context, rockchip_bbu_mmc_handler() is called when applying a barebox update (bbu) onto an MMC device, e.g. with fastboot flash bbu-mmc $image

14:24 <qschulz> a3f: interestingly, on RK3399, it also looks at offset 0 as far as I could tell, since this is where we flash it on RK3399 Puma on SPI-NOR

14:25 <a3f> qschulz, I am not sure it follows from that that it does so as well for MMC, but maybe it does

15:02 <macromorgan> jackpot, thank you

15:04 <CounterPillow> does the maskrom have a boot counter that cycles through them or does it just look for the first valid signature?

15:05 <qschulz> CounterPillow: wdym?

15:06 <CounterPillow> does the watchdog triggering increase a counter that survives a warm reboot of the maskrom that then makes it try the second, third, etc offset

15:18 <robmur01> At least in my experience with older SoCs, the boot ROM does not do anything remotely clever at all

15:19 <CounterPillow> I guess this is the type of in-the-woods territory where I should dump the bootrom and check myself

15:23 <robmur01> I mostly just recall the pain of corrupting the IDBloader on eMMC, but leaving the initial signature intact, on a TV box with no hardware "MaskROM" button...

15:27 <macromorgan> I would still love to dump the bootrom and figure out if there is any provision in there (undocumented) that lets me use the eMMC boot partition

15:27 <qschulz> macromorgan: many people would be interested in that

15:27 <qschulz> but I would be very surprised Rockchip would not document this

15:28 <qschulz> I believe NXP made a 180 on that though? They had this implemented on i.MX6 AFAIR, but I've heard it's gone on i.MX8?

15:28 <CounterPillow> I wouldn't be ;)

15:33 <robmur01> Indeed I wouldn't expect actual documentation either way, but going to the effort to implement something, validate that it works, then never use it nor even have any hint of its existence in the BSP and tools, *that* seems unlikely ;)

15:35 <user21> I see this in the dmesg: "rk_gmac-dwmac fe1b0000.ethernet: probe with driver rk_gmac-dwmac failed with error -22"

15:37 <qschulz> user21: -22 = -EINVAL but that doesn't really help to pinpoint where the issue is

15:39 <qschulz> user21: I would just add printk every other line in the probe function to figure out where it comes from :)

15:41 <user21> just looking at the errors https://snipboard.io/xncBXg.jpg

15:42 <user21> as immediate I need the network up and running this will give me a baseline to fix the rest

15:57 <qschulz> user21: look at the log before the first line

15:57 <qschulz> sometimes you get more info right before the error

15:57 <qschulz> grepping the log isn't always the best idea :)

16:20 <a3f> qschulz, eMMC boot partitions are still supported on newer i.MX SoCs. What changed as far as I heard was the mechanism for having multiple redundant copies on eMMC user partition

16:21 <a3f> but I never used that myself, although I hear it actually had a provision for "handshaking" with bootrom to tell it not to boot the next copy

16:37 <user21> removed the audio as it was creating too many errors, here is the first boot https://voidbin.com/paste/815e366f-0884-464f-945f-2ef94d1b8e51

16:41 <user21> basically when I do "dhcpcd eth0" I get "eth0: waiting for carrier" then "timed out"

17:12 <diederik> I suspect that when you do ``dmesg --level 0,1,2`` you may see several lines. If not or in addition to that, ``dmesg --level 3`` (and level 4) will likely also report several issues. I'd recommend to first try to resolve those

17:16 <diederik> several pinctrl related issues; an apparently misconfigured bridge; problems with configuring power management; and a mention about 'legacy-interrupt-controller' ... which surprises me

17:24 <diederik> I don't know what armbian uses, but it seems useful to compare that to what's here: https://lore.kernel.org/all/20250508-rock5bp-for-upstream-v2-0-677033cc1ac2@kernel.org/ (which should (mostly) land in 6.16-rc1)

18:54 <robmur01> user21: GMAC0 failing to probe for some reason seems unlikely to have any influence on the behaviour of GMAC1 (probed as eth0)'s phy

18:55 <robmur01> unless maybe you've got some sort of weird MDIO mux between the two?

19:01 <robmur01> Or perhaps GMAC0 is actually the interface you want, and you're chasing the wrong problem?

19:32 <user21> hmm good info, need to think, this is all new stuff to me, learning a lot

21:40 <CounterPillow> "The mailinglist mostly has patches on it, so I don't really know if people are expecting non-patch mails." mmind00, I am disappointed you forgot about our rich and vibrant community of Polish B2B e-mail spammers.