Alpine on ARM: Difference between revisions

From Alpine Linux
m (some style and typo fixes - unsure about section structuring)
Tag: Reverted
Line 17: Line 17:
Fully supported boards are those for which there is a working bootloader shipped in the download.
Fully supported boards are those for which there is a working bootloader shipped in the download.


==Installing Alpine on supported doards==
==Installing Alpine on supported boards==


=== Get latest Alpine image ===
=== Get latest Alpine image ===

Revision as of 22:38, 24 April 2023

This material needs wiki syntax or style improvements ...

Please feel free to help us clean it up.

This page is proposed for moving ...

It should be renamed to ARM SOCs. (Discuss)

(Parts of this page are still incomplete and might even need corrections.)


Supported SoCs

Alpine is compiled with support files for so many formidable SoCs — besides the Raspberry Pi — that to find out about a particular chipset's support it can be useful to refine the search for all *.dtb files in the package database (i.e. filter for "*<some-board-or-SoC-identifying-string>*.dtb" file).

For example, by refining the following search in the current "edge" release:

DTB-files in the current edge branch: https://pkgs.alpinelinux.org/contents?repo=main&file=*.dtb&branch=edge

Fully supported boards are those for which there is a working bootloader shipped in the download.

Installing Alpine on supported boards

Get latest Alpine image

The latest images are available at: https://alpinelinux.org/downloads/

In case the download page provides no specific image for your particular board, download the "Generic ARM" image.

The *.tar.gz files (aka "tarballs") need to be extracted to some boot media device.

Tip: Useful hints about basic identification of and access to your SD card or USB target device, may also be found in the general instructions at https://wiki.alpinelinux.org/wiki/Installation.

After extracting the files onto a USB drive or SD card, some devices, typically those using widely used standards, possibly basic boot selection jumpers, or featuring an internal flash chip with a modern bootloader, possibly with boot menu, may allow to boot the media right away.

However, if your device (even with its internal bootloader firmware, if any, updated to the latest version) is not able to boot the media as is, then some specific adjustment of the boot media (according to the requirements of your device) is needed to allow booting.

Preparation of adjusted boot media in general

Here we are using an SD card and the "Wandboard" as a rather generic example. If your particular board happens to require something to boot Alpine that is not mentioned here, or in any more specific documents link below, please consider adding the missing info, e.g. by adding to the links below.

Start by extracting the archive somewhere.

If needed, manually (re-)partition the boot media.

Either DOS or GPT patitions should work. However, the start of the first partition should be on block 2048 so there is enough space before it for the SPL and uboot code. And the partition should be marked bootable (with the MBR bootable flag, or GPT legacy_bios_bootable attribute).

Then install the SoCs particular boot loader(s) to the places on the SD card where the device expects them, e.g. the SPL and u-boot.img (this differs between boards).

  • SPL often starts at block 64 (but please consult the docs for your board)
  • uboot often starts at block 256 (please consult the docs for your board)

Just write the SPL and uboot with the correct offset to the media you wish to boot:

As user root, and from the location of the extracted image files, do a direct disk (dd) write using as input file the SPL from the extracted Alpine image, and the SD card (here /dev/sdX) as output file node (the target device).

For the SPL on the wandbord, that is:

dd if=u-boot/wandboard/SPL of=/dev/sdX seek=1 bs=1k

Similarly, for the u-boot.img on the wandbord:

dd if=u-boot/wandboard/u-boot.img of=/dev/sdX seek=69 bs=1k

Now format the partition on the sd-card, mount it, and copy the folders apks/, boot/, efi/, extlinux/, and u-boot/ to the sd-card partition. (I'm not sure if all folders are needed).

Finally, put the sd-card in the Wandboard and boot it with a serial console connected.

The board should now boot from the sd-card. When the prompt asks for a login, you can follow https://wiki.alpinelinux.org/wiki/Installation to run setup-alpine as usual.

More specific guides

Installing Alpine on boards without full support

If you have, for example, an armv6/armv7 board that is not fully supported, but whose SoC is already supported by the mainline kernel and uboot, then it's still possible to install Alpine. It may involve a couple more manual steps.


Requirements

  • Alpine's forked uboot to support tarballs (fabled?)
  • serial console
  • crosscompiler/toolchain if you can not compile natively


The embedded world

A lot of the SoCs have their own way of doing things, although they use uboot and Linux kernel but often they are heavily modified to suit easy flashing of "ROMs" or other unknown reasons, e.g. Rockchip's notion "partition" are neither DOS nor GPT partitions. Here, we will try to install Alpine in a more standard way, like on the x86 platform, with either DOS or GPT partitions. To boot this, you will most likely have to install/flash the mainline uboot, which can be non-destructive if you can load it from external storage.


Storage

One can load uboot from the following block devices if it's supported.

  • NAND
  • eMMC
  • SD card
  • USB


Power on

Some SoCs need both SPL and uboot, you need to check uboot for your board. Most (if not all) boards boots from the internal storage first (either NAND or eMMC) you will have to check documentation of your board if you wish to boot the SPL/uboot from SD/USB.

One can view SPL+uboot as BIOS and boot-loader on PC. Think that you could put the BIOS on an external storage :D

Once you have loaded the "standard" uboot, things are more or less like on x86.


Booting Linux kernel

  • uboot uses extlinux.conf file to locate the kernel/initramfs/... just like syslinx, you need to put that file on the partitions which is marked bootable in the /boot directory
  • there should be an extra line "FDTDIR" which points to the DTBs

e.g.

label Fedora (3.17.0-0.rc4.git2.1.fc22.armv7hl) 22 (Rawhide)
	kernel /boot/vmlinuz-3.17.0-0.rc4.git2.1.fc22.armv7hl
	append ro root=UUID=8eac677f-8ea8-4270-8479-d5ddbb797450 console=ttyS0,115200n8 LANG=en_US.UTF-8 drm.debug=0xf
	fdtdir /boot/dtb-3.17.0-0.rc4.git2.1.fc22.armv7hl
	initrd /boot/initramfs-3.17.0-0.rc4.git2.1.fc22.armv7hl.img

Using QEMU

qemu-system-arm -M vexpress-a9 -kernel zImage -initrd initramfs-grsec -dtb vexpress-v2p-ca9.dtb -hda hda.img -serial stdio

References