10:44 <Cheaterman> Nah that still doesn't work, in fact I seem to get a reboot loop instead of a hang

10:51 <xdarklight> Cheaterman: do you have serial console connected and can get the log output?

11:21 <Cheaterman> xdarklight: Sadly no :-( we ordered a UART module so that we can get that sort of invaluable debugging info

11:21 <Cheaterman> But right now I'm sadly without tooling

11:22 <Cheaterman> (a good reason we don't just wire any UART converter to the device is that it operates on 3v3 logic apparently, I'd have USB converters but these obviously operate on 5V)

11:22 <Cheaterman> (saying that, if I used the right chip, I could wire VDDIO to the 3V3 ref but... I'd rather just wait for the UART module than risk frying my board)

11:23 <Cheaterman> xdarklight: What do you consider my most reliable next step from this? Rolling back to a previous kernel version (this is 5.18.1-r1 gentoo sources), or using vanilla-sources, or using the tobetter fork I mentioned earlier?

11:24 <Cheaterman> I could just use Ubuntu kernel + initrd and call it a day, but I'm terrified of the day I encounter something I need to tweak my kernel config for

11:34 <xdarklight> Cheaterman: UART is always helpful, so fingers crossed that it'll arrive soon. if you have another SBC (raspberry pi, ...) you could connect UART to that SBC instead. otherwise it's a lot of guess-work (at least for me :/)

11:34 <Cheaterman> xdarklight: As an alternative, would you happen to have the device? I could give you all the boot files I got

11:34 <Cheaterman> Assuming you have the UART on your end, maybe we'd get some clarity

11:35 <Cheaterman> I could perhaps send you the kconfig first if you see anything fishy - but I did what you recommended there and just went with a defconfig for now

11:35 <xdarklight> Cheaterman: unfortunately not, the only Odroid board that I have is an Odroid-C1+ (which is a few generations before your N2+ ;))

11:35 <Cheaterman> Ah yeah not quite the same board :-)

11:36 <Cheaterman> No worriez - as you said, what we might need here is patience for the UART module ; I'm asking the Gentoo folks on the side if they have either 1°) an idea of why this fails (should I use vanilla sources, should I downgrade, other?) and/or 2°) an idea of how to get extra debugging despite the current lack of hardware

11:36 <Cheaterman> It's worth noting that I _do_ have a Pi here, all I'm really missing is a couple dupont wires!

11:36 <Cheaterman> (I'm at home :-) )

11:37 <xdarklight> if you have an old IDE cable laying around you can rip out some wires and use them instead of dupont wires (just make sure you don't short anything out)

11:38 <Cheaterman> Hahahaha that's a very imaginative option! Now that you mention it, not necessarily IDE but I could have some IDC ribbon cable sitting unused somewhere, and/or the "weekend" electronics kit somewhere

11:39 <Cheaterman> but to be perfectly fair if the debugging gets too involved I'll leave that for a weekday (this happens to be company work)

11:39 <Cheaterman> (it's just that I happen to own the company so sometimes I wanna put in some extra work hehe)

11:40 <Cheaterman> It's worth noting that I do get HDMI output somehow ; so I'm wondering exactly what's up with that, and if there was a way we could get the equivalent of what the UART would tell us directly displayed on screen

11:40 <Cheaterman> I tried tweaking the cmdline a bit but didn't go with the full drm modesetting correct stuff yet (I expected it to boot one way or another without that)

11:41 <Cheaterman> perhaps getting the kmesg on screen is an option? :-)

11:41 <xdarklight> using HDMI may be an option too, but I am not sure how to do that (I operate most of my boards without a screen attached)

11:42 <Cheaterman> (right now it's the stock cmdline, has manual "modeline=" with timings... admittedly, this could be what conflicts with DRM in the first place and prevents booting... need to investigate even more)

11:42 <Cheaterman> Makes sense, that seems to be a common use for these machines

11:43 <Cheaterman> I seem to largely be a super-minority doing kiosks or writing other GLES-driven apps on these boards (but they're MORE than powerful enough to handle it, particularly with the Mali GPUs, and parti-particularly when compared with the Broadcom offerings...)

11:44 <Cheaterman> (the S922X also kinda puts Broadcom's offerings to shame, considering the performance it yields and the absence of active cooling)