Skip to content

Conversation

sambonbonne
Copy link

@sambonbonne sambonbonne commented Dec 31, 2024

Set CONFIG_ARCH_ROCKCHIP

After some discussion on Matrix about Odroid M1S (based on RK3566), I made this PR to enable Rockchip arch in the kernel.

The goal is to test the generated aarch64 image on my hardware and to see if the initrd size is not increased to much before discussing about the possible inclusion of this configuration in Flatcar.

How to use

Installing the image in Odroid M1S requires U-Boot binaries and multiple steps. I will add testing commands if it works on my hardware and someone want to try it on real hardware.

What works and doesn't work

This list shows what works and doesn't work on an Odroid M1S SBC (eg nothing really works right now):

  • Booting kernel directly (eg U-Boot loads and boots the kernel, when finished the blue LED is blinking continuously)
  • Booting with EFI Stub (eg U-Boot boots Grub, Grub boots the kernel, when finished the blue LED is blinking continuously)
  • HDMI output (the console shows up on the HDMI monitor, login works)
  • Ethernet (the device is detected on the network by other devices, get an IP and can connect to the internet, SSH access works)
  • NVME (the device detects the NVME SSD and can format, read and write it)

Testing done

No testing for now (the image does not boot on Odroid M1S).

  • Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
  • Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

CONFIG_ARCH_BCM_IPROC=y
# CONFIG_ARCH_MEDIATEK is not set
# CONFIG_ARCH_QCOM is not set
CONFIG_ARCH_ROCKCHIP=y
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CONFIG_ARCH_MULTI_V7 might be required too

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RK3566 is ARMv8-A (it has only 4 Cortex A-55, which are ARMv8.2-A) and CONFIG_ARCH_MULTI_V7 is for ARMv7 (if I understand correctly). So at first sight, it should not be required but if my real test fails, I'll try to add it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this is weird because it says it's for Rockchip Cortex-A9 so I'll try without it and if it doesn't work, I'll try to add it.

If I add it, I'll try to use the SDK container to build locally and make the change if it helps.

@ader1990
Copy link
Contributor

ader1990 commented Jan 3, 2025

@sambonbonne the image was built, you can download it and try it from the github actions artifacts page. https://github.com/flatcar/scripts/actions/runs/12575139169?pr=2556

Copy link

github-actions bot commented Jan 3, 2025

Build action triggered: https://github.com/flatcar/scripts/actions/runs/18092542388

@ader1990
Copy link
Contributor

ader1990 commented Jan 3, 2025

The vmlinuz image increase is pretty big, by 3MB, which is more than the space allowed for the updates to work, that s why some of the tests failed. But as a PoC, you can try first the resulting image and see if it works.

@sambonbonne
Copy link
Author

@ader1990 thank you! I had some problems when trying to edit the partition layout of my SD card with fdisk on thursday (for U-Boot) and I couldn't try to fix it this week-end but I may have time to work on it on Monday or Tuesday. I already know what I can try to fix my partitioning problem so it should not take too long for me to try.

I understand 3MB is too big, unfortunately I don't know enough about "kernel things" to help on this so if I manage to have a working image, I hope we will be able to reduce the added size or find an alternative.

@sambonbonne
Copy link
Author

@ader1990 I'm trying to use flatcar-install /path/to/flatcar_production_image.bin but I have some errors, IDK if I did something wrong. Here are the logs:

$ flatcar-install -d /dev/sdb -B arm64-usr -i /path/to/ignition.json -f /path/to/flatcar_production_image.bin -u
Using existing image: /path/to/flatcar_production_image.bin
Writing /path/to/flatcar_production_image.bin...
Running in chroot, ignoring request.
Running in chroot, ignoring request.
mount: /tmp/flatcar-install.77HskzhsAm/oemfs: WARNING: source write-protected, mounted read-only.
Installing Ignition config /path/to/ignition.json...
cp: cannot create regular file '/tmp/flatcar-install.77HskzhsAm/oemfs/config.ign': Read-only file system
Error: return code 1 from [[ -n "${IGNITION}" ]]
/dev/sdb: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sdb: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/sdb: calling ioctl to re-read partition table: Success

If you have any idea to help me, I will be very happy!

@sambonbonne
Copy link
Author

@ader1990 I managed to fix my problem and to use flatcar-install with the generated image.

But it seems the first partition, the EFI one, is not mountable when installed so I could not write the boot.scr file. I mounted the partition of the image file to copy the boot.scr before running flatcar-install so I guess it's a workaround but I find it suspicious that the partition is not mountable after dd.

Anyway, the image does not seem to boot so I added CONFIG_ARCH_MULTI_V7 as you recommended but I can't run the pipeline myself. I tried to build using the SDK container but I have some problems when emergeing and I don't have the knowledge to fix it.

Can you launch the pipeline so I can try a new image with the added kernel parameter? Otherwise, should I ask for help with the SDK container (if yes, where? The Matrix channel?)?
Thanks in advance!

Just FYI, here is the boot.txt file I use to generate the boot.scr:

load ${devtype} ${devnum}:1 ${kernel_addr_r} /EFI/boot/bootaa64.efi                                           
bootefi ${kernel_addr_r}  

@ader1990
Copy link
Contributor

@sambonbonne had to solve some conflicts, I did trigger a new build and you should be able to download the image artifact in a few hours, if all goes well.

@sambonbonne
Copy link
Author

@ader1990 thanks! I hope the new image will boot. I'll give it a try when I'm able to.

@sambonbonne
Copy link
Author

@ader1990 it seems I cannot set CONFIG_ARCH_MULTI_V7, the pipeline for ARM64 failed with:

ERROR: sys-kernel/coreos-modules-6.12.0::coreos-overlay failed (configure phase):
  Requested options not enabled in build:
    CONFIG_ARCH_MULTI_V7

See https://github.com/flatcar/scripts/actions/runs/12743950372/job/35527535677#step:7:4656.

So I guess I can't enable the CONFIG_ARCH_MULTI_V7 option?

@ader1990
Copy link
Contributor

@ader1990 it seems I cannot set CONFIG_ARCH_MULTI_V7, the pipeline for ARM64 failed with:

ERROR: sys-kernel/coreos-modules-6.12.0::coreos-overlay failed (configure phase):
  Requested options not enabled in build:
    CONFIG_ARCH_MULTI_V7

See https://github.com/flatcar/scripts/actions/runs/12743950372/job/35527535677#step:7:4656.

So I guess I can't enable the CONFIG_ARCH_MULTI_V7 option?

it seems that the newer kernel 6.12 does not need it anymore. You can push a new change and I can start the build.

For building the kernel properly with Flatcar, I have the following notes for https://www.flatcar.org/docs/latest/reference/developer-guides/sdk-modifying-flatcar/#getting-started:

./build_packages --board arm64-usr

# make sure the tmp is clean
sudo rm -rf /build/arm64-usr/var/tmp/portage/sys-kernel*

# if the kernel sources have been changed
emerge-arm64-usr sys-kernel/coreos-sources

# if the kernel config or patches have changed
emerge-arm64-usr sys-kernel/coreos-modules

# if the bootengine commit id has changed
emerge-arm64-usr sys-kernel/bootengine

# if the bootengine commit id has changed
sudo rm /build/arm64-usr/usr/share/bootengine/bootengine.cpio
emerge-arm64-usr sys-kernel/coreos-kernel

# do a build packages to make sure
./build_packages --board arm64-usr

# follow the official docs
# https://www.flatcar.org/docs/latest/reference/developer-guides/sdk-modifying-flatcar/#getting-started
# do build_image
# do image_to_vm

@sambonbonne
Copy link
Author

sambonbonne commented Jan 18, 2025

Hello @ader1990 and thanks for those details!

I pushed a commit to remove the CONFIG_ARCH_MULTI_V7. I also got the error when trying to build locally.

Speaking of, I tried to build again after removing this config, so I enter the SDK container with ./run_sdk_container -a arm64 -t and run ./build_package --board arm64-usr but I get another error and I don't understand how it's possible, as I use the SDK container:

sys-kernel/coreos-modules-6.12.0 is missing libraries:
	x86_64: libcrypto.so.3
WARNING build_packages: test_image_content: Failed dependency check
WARNING build_packages: This may be the result of having a long-lived SDK with binary
WARNING build_packages: packages that predate portage 2.2.18. If this is the case try:
    emerge-arm64-usr -agkuDN --rebuilt-binaries=y -j9  @world
    emerge-arm64-usr -a --depclean

I will try to run both emerge commands and rebuild but I you think of something else, feel free to tell me.
Edit: I ran both command, both seem to not do anything specific (but succeeded) and the build fails with the same error.

I hope I don't ask for too much with all my questions, to be honest this is my first time building an entire distro, it's challenging and very instructive.

@ader1990
Copy link
Contributor

What usually happens when trying to run build_packages, is that the error is a little up in the logs, and you might need to tee those logs in a file to better search for the error: ./build_packages --board arm64-usr 2>&1 | tee -a build_packages.log.

When I have errors with the build process, I usually start with a very clean environment from scratch, as there might be leftovers or errors introduced by multiple builds. Being a dockerized environment, it is usually easy to create a new env, just remove the cloned repository, do a docker rm of the dangling containers and images, do a docker system prune for safety (of course, make sure you are not using that env for other work), and start over. Always start with a new cloned repo of flatcar/scripts, otherwise you can do a git reset, git clean -fxd, git rebase on flatcar/scripts main branch, and start the process from step 1: ./run_sdk_container -t.

@ader1990
Copy link
Contributor

@sambonbonne
Copy link
Author

sambonbonne commented Jan 26, 2025

@ader1990 just wanted to tell you I'm still investigating the boot problem.

I tried multiple boot.txt files, even to directly boot vmlinuz-a (with the bootz command) and even that don't work so I think the problem is on U-boot (the difficult part being: I don't have a UART cable so I can't see U-boot logs).

Beside this, I managed to boot MicroOS with this simple boot.txt (using mkimage to make a boot.scr of course):

btrload ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/grub2/arm64-efi/kernel.img
bootm ${ramdisk_addr_r}  

So I know U-Boot is capable of booting a working OS, I just don't know why it doesn't boot Flatcar.

Edit: I just decided to order a serial cable to see if U-Boot logs message to the UART port, it may take some time to arrive but I still want to work on this.

@sambonbonne sambonbonne marked this pull request as draft January 26, 2025 15:32
@sambonbonne sambonbonne force-pushed the feature/enable-rockchip-in-kernel branch from 9ed0ab0 to 87bc1d5 Compare January 26, 2025 15:38
@sambonbonne
Copy link
Author

Latest push is due to me rebasing this branch from ader1990/linux_kernel_6_10 and removing the commits which added then removed CONFIG_ARCH_MULTI_V7. No need to rebuild for now.

@sambonbonne
Copy link
Author

Good news: I got my cable and I already have some things.

Bad news: right now, it's still complicated to find why Flatcar doesn't boot.

I can see the Grub menu through the serial port but after booting Flatcar, even by adding a debug parameter, all I get is:

Booting a command list

EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...

I also tried to boot the A partition directly (still from Grub menu) with the debug parameter, nothing more than the above logs.

I think I miss a kernel configuration, I'm looking for it. Fortunately, Home Assistant provides a working image for Odroid M1S so I will try to find out what they use. I hope I'll be able to build locally this time, this would avoid multiple pipelines just to find out missing parameters.
I guess this will increase the initrd size but let's find out the config, then we'll see.

@ader1990
Copy link
Contributor

I see that the support has been there since the 6.12 torvalds/linux@10dc64f, so it should work. For the debug logs, I might suggest adding more kernel config params - mainly console=ttyAMA0 console=ttyAMA1 console=ttyS0 console=ttyS1, maybe you can get some more information. Also, it would be helpful to share a kernel config file from an image that works, to cross-compare and see what might be missing.

Thanks.

@sambonbonne
Copy link
Author

sambonbonne commented Feb 12, 2025

My comment is a bit long so I tried to structure it two parts.

Debug

I tried different parameters for debug logs: the four console=… you gave and console=tty0 (this last was tried because I found it in the boot partition of the HAOS image): I get nothing. I tried in the default entry and in the A partition entry.

Maybe I do it wrong but it's not my first time adding a temporary kernel parameter from Grub: I use cu as a serial console, I some Odroid boot information, then I have the Grub menu. I edit the first entry, append the parameter at the end of the line starting with linux and ending with $linux_cmdline and hit Ctrl-x to boot.

Kernel configs

As a theoretically working kernel config, I have two sources for Odroid M1S:

Gentoo wiki configs try

I tried to add configs from Gentoo wiki but that's where I got some build error when running build_packages from my machine. I pulled my branch since you rebased it on main (thanks for that) but now I have a new build error, from podman, the podman's build log (in /build/arm64-usr/var/log/portage/app-containers:podman-5.3.0:20250212-102732.log) just ends with this:

/build/arm64-usr/var/log/portage/app-containers:podman-5.3.0:20250212-102732.log
cd .                                                                                                                                                                                         
GOROOT='/usr/lib/go' /usr/lib/go/pkg/tool/linux_amd64/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -installsuffix shared -X=runtime.godebugDefault=asynctimerchan=1,goty
pesalias=0,httpservecontentkeepheaders=1,tls3des=1,tlskyber=0,x509keypairleaf=0,x509negativeserial=1 -buildmode=pie -buildid=Di7VbJOVEz0cCecPSPVh/lIE-3YL_RKIYFm-tCLNS/g5oi0ADpMmXJOtBy8UrJ/D
i7VbJOVEz0cCecPSPVh -X github.com/containers/podman/v5/libpod/define.buildInfo=1739356126 -X github.com/containers/podman/v5/libpod/config._installPrefix=/usr -X github.com/containers/podma
n/v5/libpod/config._etcDir=/etc -X github.com/containers/podman/v5/pkg/systemd/quadlet._binDir=/usr/bin -X github.com/containers/common/pkg/config.additionalHelperBinariesDir= -extld=aarch6
4-cros-linux-gnu-gcc $WORK/b001/_pkg_.a                                                                                                                                                      
/usr/lib/go/pkg/tool/linux_amd64/buildid -w $WORK/b001/exe/a.out # internal                                                                                                                  
mkdir -p bin/                                                                                                                                                                                
cp $WORK/b001/exe/a.out bin/podman-testing                                                                                                                                                   
/usr/lib/go/pkg/tool/linux_amd64/buildid -w $WORK/b001/exe/a.out # internal                                                                                                                  
mkdir -p bin/                                                                                                                                                                                
cp $WORK/b001/exe/a.out bin/podman                                                                                                                                                           
test -z "" || chcon -t container_runtime_exec_t bin/podman                                                                                                                                      

I built from a fresh environment (new clone and remove all Flatcar containers and images) so I don't understand how I can still face this kind of errors (I run the ./build_package --board arm64-usr from the SDK container, run with ./run_sdk_container -a arm64 -t).

Is it possible to build a smaller set just to try the boot, without Podman for example?

Home Assistant OS info

For HAOSS (short for Home Assistant OS), it bootloops when installed on SD card so I may have to try to install it directly on eMMC and maybe I can find a way to copy the /proc/config.gz to check if there is useful kernel parameters. But even if I find other kernel parameters to add, I may face build errors.

@sambonbonne
Copy link
Author

I managed to build with more parameters but still no luck. I created a PR on my repo for that and started a self-hosted runner with the required labels.

Build working but image still not booting: sambonbonne@1eb4d0b

Build failing: sambonbonne@98c0da9 (build log: https://github.com/sambonbonne/flatcar-scripts/actions/runs/13437246231/job/37542450165)

My next try, when I have the time, will be to run the HAOSS image directly in eMMC (instead of SD) and see if the kernel config is available. 🤞

@sambonbonne sambonbonne force-pushed the feature/enable-rockchip-in-kernel branch from 703fd43 to af68cf7 Compare July 2, 2025 13:36
@sambonbonne
Copy link
Author

@chewi I forgot: no ethernet cable plugged for now, so Flatcar is not able check updates online right now. So it may not be it.

Thanks for this explanation, I'll give it a try after my today's rebase is built. In fact I didn't try to remove these parameters since multiple builds because I thought I should get an HDMI console in parallel of the logs I get on UART.

@sambonbonne sambonbonne force-pushed the feature/enable-rockchip-in-kernel branch 2 times, most recently from 51b283e to 7d99468 Compare July 8, 2025 12:17
@sambonbonne sambonbonne force-pushed the feature/enable-rockchip-in-kernel branch from 107fe61 to fdf10b6 Compare July 16, 2025 11:35
@sambonbonne sambonbonne force-pushed the feature/enable-rockchip-in-kernel branch from fdf10b6 to 2f46d31 Compare August 5, 2025 09:57
@sambonbonne sambonbonne force-pushed the feature/enable-rockchip-in-kernel branch 2 times, most recently from c697d77 to 23ee2ec Compare August 16, 2025 12:50
@sambonbonne sambonbonne force-pushed the feature/enable-rockchip-in-kernel branch from 23ee2ec to e1f8cba Compare August 24, 2025 16:24
@sambonbonne
Copy link
Author

Just a little update: I didn't abandon this PR, it's just taking some time. I made some progress (like, the blue LED of my board is blinking, which means it boots) but I still miss some things (no HDMI output, plus I didn't test with an vnme yet, neither I tried ethernet).

I'm working on another branch right now because I added a lot of configs so it would be a mess to put everything in the PR but I still want to make Flatcar work on my Odroid M1s :)

@guilhem
Copy link

guilhem commented Sep 25, 2025

@sambonbonne I have a ROC-RK3399-PC to test if necessary.

And a aml-s905d3-cc and aml-a311d-cc, but they need the MESON ARCH.

@pothos
Copy link
Member

pothos commented Sep 26, 2025

Thank you for the work here, it's not easy to dig up all needed kernel configs from a diff to a working kernel.

And a aml-s905d3-cc and aml-a311d-cc, but they need the MESON ARCH.

Regarding meson, I've the la frite to test.

@sambonbonne
Copy link
Author

@guilhem when I have a new image that builds, I'll send you the link so you can test it.

@guilhem @pothos IDK if I should enable Meson in this PR or if another PR would be required, as it's not the same CPU brand. But when I have a booting image for Rockchip, and after cleaning up the kernel, I can try adding CONFIG_ARCH_MESON (and maybe other required configs) to see if it works easily on your board. But if it doesn't boot with basic configs, I won't be able to work on it as I don't have any Amlogic board (it would be fun to have one though, I could make a "mixed SBC" Kubernetes cluster).

@ader1990
Copy link
Contributor

Hello @sambonbonne, it would be great if you could summarize on the main description of this PR what works and what does not currently work (maybe with bullet points?), so that we can advance on the non-working items. Thanks for the work!

@sambonbonne
Copy link
Author

@ader1990 good point, I should take the time to update my PR to use new configs first, then I can list what doest work and what doesn't. I'll try to do this on friday!

@sambonbonne sambonbonne force-pushed the feature/enable-rockchip-in-kernel branch 9 times, most recently from e06241a to dfdcc41 Compare October 3, 2025 14:35
ader1990 and others added 4 commits October 9, 2025 08:38
Remove CONFIG_AMD_IOMMU_V2, CONFIG_FB_ARMCLCD, CONFIG_MD_LINEAR, CONFIG_NET_ACT_IPT.

Add CONFIG_MODULE_COMPRESS.

See: torvalds/linux@5a0b11a

linux: remove CONFIG_MD_LINEAR

See: torvalds/linux@849d18e

linux: remove CONFIG_NET_ACT_IPT

See: torvalds/linux@86fe596

linux: add required CONFIG_MODULE_COMPRESS=y

See: torvalds/linux@c7ff693

linux: remove CONFIG_FB_ARMCLCD

See: torvalds/linux@dee56cc
@sambonbonne sambonbonne force-pushed the feature/enable-rockchip-in-kernel branch from dfdcc41 to 1fb1326 Compare October 9, 2025 06:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: ⚒️ In Progress

Development

Successfully merging this pull request may close these issues.

6 participants