tparys

Quick update for the interested. Looks like the Armbian build for the M1S actually works as expected, but not with the boards as shipped from Hardkernel. The OEM installs an old copy of u-boot which changes the memory map, and leaves the Ethernet card in reset. Explicitly zeroing the first 1 MB of the eMMC seems to address the issue. Shorting the MASKROM pins should also work as well. A little annoying, but it's fine if you know about it. PR closed, but we should have a note on the download page for silly geese like myself who don't know better.

Yes. And the patch is conflicting with a tool that is also touching that Makefile. And it looks like you don't need the kernel patch at all if you put your .dts in the rockchip64-6.18/dt folder.

To be honest, I'm not sure offhand why your autogenerated patch isn't working. But looking at that file, the tail end seems autogenerated from armbian/build/patch/kernel/archive/rockchip64-6.18/dt At a glance, if you toss your .dts in that folder, looks like it'll pick it up. dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-lubancat-4.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-neo3-rev02.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-lincstation-e1.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-xc3399fr.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3576-dshanpi-a1-cm5-waveshare-cm5-to-pi5-adapter.dtb Were I to wager, that's probably a newer feature, and you're looking at older documentation that hasn't been updated yet. Happy to be told otherwise if someone knows better. If that's the case, file a bug.

From your logs: ~ $ grep PATCHDIR log-build-5be2103c-d2b7-414e-ba03-19e87beec54b.log --> (2) CHANGE-TRACKING: change-tracking: after sourcing family config [ BOOTPATCHDIR='u-boot-rockchip64' ] --> (3) INFO: KERNELPATCHDIR is unset; using 'archive/rockchip64-6.18' [ common_defaults_for_mainline ] --> (3) CHANGE-TRACKING: change-tracking: after late_family_config hooks [ KERNELPATCHDIR='archive/rockchip64-6.18' ]As your build has a RK3568, I think you should be using rockchip64, not rockchip. Not that it should matter, but you should be able to put your kernel patches in archive/rockchip64-6.18 And more than likely, it's using a rockchip specific u-boot, which needs its own patch directory.

Alright, found a boot.cmd tweak in the config for dshanpi-r1, and followed that. Looks like it's working as expected, so no need for duplicate bootscript. Other basic functions appear to be working. SD Card USB HDMI NVME Initial PR submitted to get CSC images working. Now to poke at GPIO headers.

Any pointers on which boards use this? I'm sure I'll find it, but might save me reading though a few dozen family configs. In the meantime, I've integrated the above Ethernet tweak as a rockchip64 patch. I'm assuming something moved in the kernel and the M1S's .dts didn't get updated. /_\ _ _ _ __ | |__(_)__ _ _ _ ___ _ _ _ _ ___ / _|/ _(_)__(_)__ _| | / _ \| '_| ' \| '_ \ / _` | ' \___| || | ' \/ _ \ _| _| / _| / _` | | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| \_,_|_||_\___/_| |_| |_\__|_\__,_|_| v26.11 rolling for ODROID M1S running Armbian Linux 6.18.62-current-rockchip64 Packages: Ubuntu stable (noble) Updates: Kernel upgrade enabled and 7 packages available for upgrade Support: DIY (custom image) IPv4: (LAN) 10.42.0.119 (WAN) ---.---.---.---

Found this thread by @Mortimer2003 , who probably deserves some kudos for identifying some fairly major issues, but were never submitted for PR. Looks like things have been broken for a bit in the build. So, let's take a swing at it: https://github.com/tparys/build/tree/odroid_m1s First up is the load address. The rk35xx family boot script loads data at 0x9000000, but doesn't seem to be valid for M1S? Adding a custom boot script that loads 0xc000000 gets us booting and to first boot login. But Ethernet isn't working (as identified). rk_gmac-dwmac fe010000.ethernet eth0: cannot attach to PHY (error: -ENODEV)

Just got an ODroid M1S (8GB), tried current community build, and found it wasn't working (Armbian_community_26.11.0-trunk.120_Odroidm1s_resolute_current_6.18.60_minimal.img.xz). So, a thread while I'm debugging if anyone's interested. Lets see how far I get. boot_fail.txt

Small ARM boards generally don't have UEFI support, so can't just run a generic kernel. They're pretty dependent on board specific DTBs, which are often tied to certain kernels that are bleeding edge or heavily patched. I think the Armbian team would love to reduce the number of images maintained. But if you do get that working, definitely share.

During the build, compile.sh should generate a build log. Would be helpful to post that.

Could still be a hardware issue if your SD adapter is bad. Counterfeit flash is also thing, especially If you purchased both from Amazon, it may be worthwhile confirming the cards actually support the claimed storage: https://github.com/AltraMayor/f3 Also worth trying with other tools such as Balena Etcher. If something else works for you, provide logs to help identify the issue.

Unfortunately, Link Star H68K is not one of the supported boards. Hinlink H68K is Community Maintained and is provided as-is with no guaranteed support and no any maintainer listed. If you can figure out what is different in the bootloader and device tree, you should be able to adapt what is in the Hinlink H68K build configuration.

There's nearly 400 boards in the Armbian build system. There are not nearly that many people actively supporting those configurations, so not all are seeing the level of care and attention to detail that we'd all like to see. There are other threads of folks discussing Rockchip hardware acceleration, which seems relatively new. You may need a more recent kernel (7.x mainline), and/or other bleeding edge software which is not part of the Ubuntu 26 baseline.

From what I've seen, that particular tool is not as well maintained as some others. If it's a major uboot failure, it won't boot. If it's working, I think that's your answer.

It may be possible. But due to limited resources, forum support is limited to using Armbian as-is. Everything else goes in Off Topic. If you're truly interested, you could attempt to take the Armbian bootloader, kernel, and device tree, and drop that into a Guix install. But at that point, you are very much on your own.