added alarm/uboot-odroid-c4

[sfan5]

The shipped script is only meant to boot a mainline kernel.
No unusual setup needed, u-boot will load stuff directly from /boot on the root partition.

Tested to work with linux-aarch64 5.8.9-2 from repos and 5.10.1 too.
eMMC booting should work too but I don't have one to test.

# Note: must be built on x86 with an old cross toolchain

I used the following toolchain locally.

---

Edit: Mainline U-Boot also supports the ODROID-C4, but building it appears to be just as if not more bothersome as the vendor u-boot.

[yuvadm]

@sfan5 Thanks for this! Is there any pre-made image that can be used to bootstrap a C4 with alarm? Or can you publish a short description of how to get one built?

[sfan5]

Here's roughly what should work:

• Build this package on an x86 machine: CARCH=aarch64 makepkg (also make sure to get the toolchain as above)
• Format an SD card, one ext4 partition for /
• Get rootfs from https://archlinuxarm.org/platforms/armv8/generic and extract it there
• Extract the respective files from the uboot-odroid-c4 package into /boot
• cd into /boot and run the sd_fusing.sh script manually

 
For anyone not wishing to mess with the build steps here's it precompiled: https://kitsunemimi.pw/tmp/uboot-odroid-c4-2015.01-1-aarch64.pkg.tar.zst

[yuvadm]

@sfan5 thanks for the pointers! Seems like the only part missing in that toolchain is:

aarch64-none-elf-gcc: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

From where did you install that (assuming you're on Arch as well)?

[sfan5]

lib32-gcc-libs + lib32-glibc + lib32-zlib

[yuvadm]

@sfan5 Getting lots of build errors from what appears to be dtc such as:

/usr/include/libfdt.h:1865:19: error: redefinition of ‘fdt_appendprop_cell’

Any idea why the mismatch? Edit: this seems to be resolved by temporarily removing sudo pacman -Rdd dtc

Also, did you try to build this pacakge with the pre-buitl toolchains provided at https://archlinuxarm.org/wiki/Distcc_Cross-Compiling ? Is there any reason those shouldn't work?

Edit: anyway, got the image built and working, thanks for the tips!

[yuvadm]

@sfan5 slightly off-topic: do you have any success with enabling I2C on the C4? It seems some DTBs might be required for that, but have been unsuccessful in finding a good reference on how do to that.

[sfan5]

Never used that, no idea. I can spot some i2c stuff in one of the related DTBs though: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi#L2250-L2288

[yuvadm]

Any reason this PR shouldn't be merged? It would be great to have C4 fully supported upstream + @kmihelich

[0xFEEDC0DE64]

what is blocking the merge here?

[sfan5]

My educated guess is that maintainers aren't fond of having another package that needs to be built manually with some obscure toolchain instead of being able to run through their automation. But having an official answer would be great.

[yuvadm]

@sfan5 per your edit that mainline u-boot supports C4, is there any update to the recommended way for bootstrapping an image? Specifically, is it possible to use the vanillla alarm u-boot package (with any required changes) instead of building this one?

[sfan5]

No, that does not simplify anything.
Speaking of bootstrapping an image you can get away with just extracting the files and skip a chroot/qemu-user, I edited the comment above.

Edit: By the way, kernel versions 5.16 and later do not boot on odroid-c4. The first that works again is 5.18-rc1.

[yuvadm]

Thanks for the heads up on the bad kernel. Indeed the current rootfs has a kernel that doesn't boot, so this does require chrooting on an aarch64 machine in order to update to linux-aarch64 5.18.1.

Edit: actually - attempting to build a new image, I get a proper boot sequence, but kernel log stops at about 2.75 seconds after boot right after initializing USB and meson-gx-mmc and then doesn't complete the boot sequence. This is with @sfan5 precompiled uboot and with updated 5.18.1 kernel. Any ideas what's going wrong?

[sfan5]

Can confirm with 5.18.1-1, freezing at "meson-gx-mmc" is the exact behavior I saw before too.
A 5.18.3 kernel I compiled myself (albeit based on an older config) runs perfectly fine, not sure what's going wrong here. Here's a diff of the config: http://sprunge.us/UyY166?diff

[yuvadm]

Thanks for the additional data point @sfan5 , there doesn't seem to be any immediate suspect in that config, any chance you can attempt a kernel build with the distro config?

[sfan5]

Done that and the result is ... it doesn't boot.

[yuvadm]

Looks like I'll be using your config then 😉 although it could be nice to reach a minimal patch for pushing a fix upstream

[0xFEEDC0DE64]

I started my arch on odroid-hc4 now from manjaro and it runs fine, the only leftovers from manjaro are the partition names, the rest is arch provided.

[yuvadm]

I haven't kept up with this issue for the past few months, what's the current status on the 5.18 kernel freeze bug?

Does it still occur with latest kernel package?

[sfan5]

Installed the latest ver from ALARM repos, still freezes:

[...]
[    2.703931] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.19
[    2.711977] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.719129] usb usb1: Product: xHCI Host Controller
[    2.723983] usb usb1: Manufacturer: Linux 5.19.8-1-aarch64-ARCH xhci-hcd
[    2.730600] usb usb1: SerialNumber: xhci-hcd.0.auto
[    2.735804] hub 1-0:1.0: USB hub found
[    2.739185] hub 1-0:1.0: 2 ports detected
[    2.743458] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[    2.751227] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.19
[    2.759322] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.766558] usb usb2: Product: xHCI Host Controller
[    2.771311] usb usb2: Manufacturer: Linux 5.19.8-1-aarch64-ARCH xhci-hcd
[    2.777956] usb usb2: SerialNumber: xhci-hcd.0.auto
[    2.783126] hub 2-0:1.0: USB hub found
[    2.786513] hub 2-0:1.0: 1 port detected
[    2.790904] dwc3-meson-g12a ffe09000.usb: switching to Device Mode
[    2.800264] meson-gx-mmc ffe05000.sd: Got CD GPIO
[    2.801991] meson-gx-mmc ffe07000.mmc: allocated mmc-pwrseq

[0xFEEDC0DE64]

fixed now or what was the solution?

[sfan5]

No, not fixed. It's clear that ALARM has no interest in supporting this device.

[yuvadm]

It's very disappointing to realize that the project isn't willing to accept community contributions for new devices, especially with how many boards have yet to receive proper support.

As a side note, @sfan5 have you had any luck with newer kernels with the freeze issue?

[sfan5]

As a side note, @sfan5 have you had any luck with newer kernels with the freeze issue?

Still broken as of 6.2.10-1-aarch64-ARCH.