Odroid M2 - how to boot this board?

[nmset]

With kernel v6.14-rc1 self-built in a minimal config, it could go to 22 hours uptime when I rebooted on purpose. It never got that far before. I'll do a bunch of tests with Arch installed on a spinning hard drive before I can tag it as reliable. My former Odroid U2, U3 and current XU4Q were just 'plug and play'!

Please share your experiences with that board.

[nmset]

Skimming through mine experience with this board.

There were many parameters that can be combined in multiple ways:
- boot partition: EMMC, SD, hard disk, usb stick...
- root partition: same as above
- 'pci=nomsi' flag
- interrupt rate
- kervel version
- HDMI output
- built-in ethernet port
- USB attached ethernet adapter
- ... spare time and spare time ...

My impressions:
- the minimal patch to the device tree file has been required throughout to establish network connection.
- 'pci=nomsi' is not mandatory. I related it above to a high interrupt rate in the ' GICv3 188 Level fdd97e00.iommu, fdd90000.vop' line of /proc/interrupts. Actually, it only means that an HDMI screen is attached. Probably, more than one parameter was altered at a a time.
- stability does not seem to be affected by the kernel version nor the ethernet port being used. I *suspect* it might be related to the exclusive use of an SD card. Admittedly, my test SD card is old and not fast.
- when the system is up, a hard disk plugged in the USB 3.0 port might not be detected, or a message like 'perhaps the cable is bad' appears in dmesg. If the device is booted while the cable is already plugged in the USB 3.0 port, it is rightly detected and becomes usable. The USB 2 port is more friendly however.

[hyke]

Head-ups regarding the changes for onboard ethernet. tobetter has a different modification to the DTS for 6.13.
make_clickable_callback(MAGIC_URL_FULL, '
', 'https://github.com/tobetter/linux/commit/3b3b1bcbce41e5800daabd2277c682f56d80e8d4', '', ' class="postlink"')

Regarding lockups, I had a problem with old uSD card on a Raspberry Pi before. I swapped it out, and the system worked fine again.
Maybe it's worth trying to running with the root partition on the eMMC?

[nmset]

@hyke

Thanks for the advice about lockups and the link.

I am running with boot and root partitions on the EMMC and it seems stable now. I just wanted to let it go for a few days before reporting.

[nmset]

I pushed a bash script online to install Arch on an SD card.

It can be found at:
make_clickable_callback(MAGIC_URL_FULL, '
', 'https://github.com/nmset/A7/', '', ' class="postlink"')

Testing has been done with Arch installed on the EMMC. If you find any issue with Ubuntu installed on the EMMC, please report it for a fix.

[solskogen]

Got Arch to boot now by starting with the Debian Bookworm image, and just formatting the filesystems and putting Arch on it instead. I'm missing sound, but I'll try the dtb file from tobetter .

[solskogen]

No dice on sound

[hyke]

Are you using the Debian Bookworm kernel or using Arch Linux Arm linux-aarch64 6.13-2?

Are you looking for analog sound from the 14-pin header? Or referring to HDMI audio?

If you want HDMI audio in the mainline kernel, the patchset has been sent to the LKML. So hopefully it gets in kernel 6.15.
make_clickable_callback(MAGIC_URL_FULL, '
', 'https://lore.kernel.org/linux-rockchip/20250203171925.126309-1-detlev.casanova@collabora.com/', '', ' class="postlink"')

I've applied the patchset on 6.14-rc1, and it works on the Orange Pi 5 Max.

For analog audio, it seems like porting the DTS from the vendor over to mainline should be straight forward. It uses simple-audio-card and the es8316 codec (just like the Radxa Rock 5C). The hard part is getting a headphone jack on the 14-pin header...

[solskogen]

No, I'm just using the u-boot stuff from the Debian image. The kernel is linux-aarch64, which lacks hdmi sound I found out.

[nmset]

With the patch from @tobetter, the board seems stable up to now; even when booted on an SD card, using 6.13-2-ARCH.

Warm thanks to @tobetter and to @hyke for pointing to this patch. The board can now be installed to replace my XU4Q.

There are other issues with the type-A USB3 and the type-C ports, but that's another subject.