Looking for help installing on the AML-S905X-CC with the generic ARM addition. Visited libre.computer and successfully got the Raspbian img to work, so know the board is fine. Presence of the libretech-cc directory in the u-boot folder of generic ARM (aarch64) makes me think this is doable. Followed the instructions at Alpine on ARM - Alpine Linux and was unsuccessful. Particularly confused by the mention of the SPL when no such file was in the tarball. Any help or advice appreciated.
We have our bootloaders available at boot.libre.computer and you can run the following to install the bootloader:
sudo dd if=aml-s905x-cc of=TARGET bs=512 seek=1
This is not compatible with GPT partition tables so you will need MBR.
We have some customizations in our kernel but you should be able to run generic kernels as Alpine is built with musl.
I ran that command and was able to see the boot loader on my display. I then went back to continue with the alpine install, and was unable to see the bootloader in any partition managers, so I simply proceeded to use GParted and leave 1 MiB free before creating an ext4 partition on the rest of my SD card. I then skipped straight to copying the files as detailed in their instructions. This did not work, and resulted in an infinite loop of the libre computer bootloader. I then went back and tried to use their u-boot.bin file as well, that was also unsuccessful. I tried writing img files for various distros to the SD 1MiB after the start of the disk as well to see if anything would work, all attempts were unsuccessful.
Their u-boot.bin will not work. Our bootloader is EFI compliant and can use extlinux or u-boot.scr as well. You can ignore all of their bootloader instructions. As long as they conform to either UEFI spec or have extlinux or a custom u-boot.scr, it will boot properly.
I was careful to select MBR in GParted before proceeding with anything else. Correct me if I’m wrong, with their boot loader being ignored all that would be left to do is make that ext4 partition and transfer files. If so, what could have possibly led to the infinite loop of the bootloader I experienced?
You need logic to hook the kernel and initramfs to the bootloader. This is done via GRUB, extlinux, or u-boot.scr. They probably don’t have any of these setup in their default rootfs so you need to set it up manually.
- Setup the link between the bootloader and the kernel.
- Setup the root filesystem path to the kernel (root= parameter of bootargs)
- You also need fstab entries in the root filesystem to tell the kernel how to mount the partitions.
I built a booting image using GitHub - mathieu-lm/libretech-cc-buildroot: Buildroot with Amlogic S905X LibreTech-CC "LePotato" support in a devuan chroot on alpine linux x86_64 (Using the linux branch linux-4.14/libretech-cc-master-stable and uboot u-boot/2020.04/lepotato-r1).
I dd the sdcard.img to my sdcard root, i.e. /dev/sdc, and that boots with console only. Great.
Then I pulled the card, copied (saved) the files from the second partition, then deleted the partition, recreated it full size (fdisk delete, then re-create the partition) and re-recreated the ext2fs (mke2fs). After pulling down the alpine-minirootfs-3.17.0_rc4-aarch64.tar.gz, I untarred it and placed those files on the second partition. The kernel loads, but it hangs when trying to run init from what I can tell.
So just to be sure, I removed all the files from the second partition and added the ones built by the buildroot I copied earlier, and it boots again. I then ssh busybox from the alpine tarball over to the booted box and tried to run it, but it will not run. Busybox should be a static binary.
Ideas? My next step is to pull down the edge/testing linux-amlogic kernel and see if that will boot, then try the rootfs as before.
Alpine is a truly awesome option. I am running it on my pi zero as a firewall/wifi router, on my i7-10700K, and at work for obscure video sources using pi zeros, so I will figure out a way to get it to run even if I have to start a new build with alpine.
busybox would not run because it still needs musl-libc.so and the ld.so, so not fully static after all. Ran fine after I put those in place. Neither the minirootfs (MRFS) or the iso will work out of the box. I don’t even know why they bother with the, but I am likely missing something important. I had to add the openrc-run binaries (which did not exist on the MRFS)
Some more data points. There is a boot.scr and aml_autoscript that appear to satisfy the ROM boot loader in the amlogic part that are in the first partition, which is FAT. These are built with a tool in utils/amlogic/binaries/mkimage in the buildroot mentioned above, and invoked from the board/amlogic/s905x-libretech-cc/post-build.sh, so that command can be used to re-create those files.
In none of these cases do I get more than a black screen on HDMI (HDMI out, but black , or black with a blinking cursor top left). Some of them produce no video output at all.
On an unrelated project, I already had an older alpine install on an EFI system, and found that the ISO image was likewise brain damaged. There is clearly a script that must run to create all the bits to make Alpine work, and am still discovering how to invoke it. This should not be this hard. I would use the libreelec images but both the nightly and whatever the stable is freeze during any kind of seek of a H.256 4K video. So far, I have to declare this board to not be suitable for video playback, which is too bad - it would be nice to have a lightweight option like this.
CoreELEC for video. LibreELEC is based on un-finished upstream codec work.
Our boards with standard upstream Linux. If Alpine supports generic EFI aarch64, it should work on our board by just plugging the bootloader. If they don’t, they need to release something.