Updating Void and Arch Linux downloads to AArch64 versions for Raspberry Pi 3

[win8linux]

I noticed that both Arch and Void Linux have ARM64/AArch64 versions for the Raspberry Pi 3. Could updating the downloads for these respective distributions be considered for the Raspberry Pi 3?

[procount]

I tried already but they use Uboot which requires a lot more work to adjust the partition locations of the os. I haven't figured it out yet

[librarianmage]

@procount Have you made any progress on this?

[procount]

Sorry, no. There was an attempt to port Netbsd into noobs/pinn but they seem to have given up, I suspect for the same uboot reason.

[librarianmage]

Darn :( On Wed, Feb 28, 2018 at 11:24 AM procount notifications@github.com wrote:

Sorry, no. There was an attempt to port Netbsd into noobs/pinn but they seem to have given up, I suspect for the same uboot reason.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/procount/pinn/issues/58#issuecomment-369313792, or mute the thread https://github.com/notifications/unsubscribe-auth/ALz_82BaW3zmIszZ-VIpyCIKqm2nCkBhks5tZYrMgaJpZM4Na5uc .

[sakaki-]

Hi @procount,

so, I've just been trying out the current aarch64 archlinuxarm for the RPi3 (initially installed to a microSD card using this script). I've worked with u-boot before (for my Excito B3 gentoo and arch images), so thought I'd take a look at this one too.

It seems possible to make the necessary edits reasonably easily, as u-boot uses /boot/boot.scr to control the startup. This file is generated from /boot/boot.txt (which is what you need to edit). Here's the shipped version of /boot/boot.txt:

# After modifying, run ./mkscr

# Set root partition to the second partition of boot device
part uuid ${devtype} ${devnum}:2 uuid

setenv bootargs console=ttyS1,115200 console=tty0 root=PARTUUID=${uuid} rw rootwait smsc95xx.macaddr="${usbethaddr}"

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /Image; then
  if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /dtbs/${fdtfile}; then
    if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /initramfs-linux.img; then
      booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
    else
      booti ${kernel_addr_r} - ${fdt_addr_r};
    fi;
  fi;
fi

Necessary changes to the above are pretty self-evident.

Once modified, generate /boot/boot.scr by running (the bundled) /boot/mkscr:

#!/bin/bash

if [[ ! -x /usr/bin/mkimage ]]; then
  echo "mkimage not found. Please install uboot-tools:"
  echo "  pacman -S uboot-tools"
  exit 1
fi

mkimage -A arm -O linux -T script -C none -n "U-Boot boot script" -d boot.txt boot.scr

Note that you need mkimage installed, which does not ship on the arch rootfs by default, but that's not problem, it it can simply be pre-installed on the deployed image. Then, after modding /boot/boot.txt, you could simply mount the rootfs ro, bind mount the boot partition into it (at /boot) rw, then temporarily chroot into the image and run it's mkimage to do the update. Then dismount and invoke your normal reboot.

If you like I can try to set up a play image to see if this will work in practice.

Best, sakaki

[procount]

Don't forget that the partition_setup.sh script needed to do this is run under the context of PINN's buildroot under busybox not Aarch64, so I need to install all the uboot tools in PINN. But it should be doable. I think I half got it working before. I can't remember what the problem was now. Might have just been lack of time. I'll maybe have another crack at it. Thanks.

[sakaki-]

Don't forget that the partition_setup.sh script needed to do this is run under the context of PINN's buildroot under busybox not Aarch64, so I need to install all the uboot tools in PINN.

Not necessarily, as busybox has (or can be configured to have) chroot I think, so you could still use mkimage if it was installed on the target root filesystem. Mount the target root r/o, bind mount /boot into it (r/w), chroot into the (ro) target root, run the necessary program (mkimage, via /boot/mkscr), exit the chroot and dismount.

[sakaki-]

If PINN boots under a 32-bit kernel, mkimage and all its library deps would have to be available in 32-bit form on the target rootfs, of course.

[procount]

Quite. And I have to add mkimage anyway, so it may aswell run under pinn. I can't rely on each os having the right tools installed.

[sakaki-]

If PINN boots under a 32-bit kernel, mkimage and all its library deps would have to be available in 32-bit form on the target rootfs, of course.

Geek note: actually my statement above is not quite true, since you could ship a 32-bit arm binary of qemu-aarch64-static in PINN (easily available by e.g. installing the qemu-user-static package using apt-get on Raspbian, then copying the statically linked binary /usr/bin/qemu-aarch64-static from there), setup an appropriate binfmt_misc matching rule for aarch64 binaries (assuming PINN's kernel has CONFIG_BINFMT_MISC configured) vectoring to /usr/bin/qemu-aarch64-static; something like the following (in e.g. /etc/binfmt.d/qemu-aarch64):

# emulate aarch64 ELF binaries using a static QEMU
:aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-aarch64-static:

then bind mount qemu-aarch64-static into the target (aarch64) rootfs under (its) /usr/bin and then chroot in and run your desired (aarch64) userland tool, such as mkimage.

But your point about not being able to rely on the contents of the rootfs still wins ^-^

[procount]

@sakaki -

Necessary changes to the above are pretty self-evident.

Sorry, but my google fu is failing me, and despite searching the DULG manual.

part uuid ${devtype} ${devnum}:2 uuid

What does the above line do? Is this trying to get the uuid of the required partition? What are ${devtype} and ${devnum} and their respective formats? Or am I going too deep and I just need to replace the '2' with the rootfs partition number?

[sakaki-]

See e.g. https://github.com/armbian/build/projects/2

It saves the UUID of the second partition of the boot device to a variable named uuid (last arg, it'd be clearer if they'd named it something other than uuid ^-^). This variable is then referenced by the next line, which sets up the kernel cmdline:

setenv bootargs console=ttyS1,115200 console=tty0 root=PARTUUID=${uuid} rw rootwait smsc95xx.macaddr="${usbethaddr}"

So all you have to do is substitute '2' with the actual rootfs partition number in the line:

part uuid ${devtype} ${devnum}:2 uuid

run /boot/mkscr, and it should boot fine.

I've just verified that this works, if I move e.g. the rootfs to partition 3, it fails to boot with the shipped boot.scr, but boots fine after I changed the line in boot.txt to read:

part uuid ${devtype} ${devnum}:3 uuid

and ran /boot/mkscr.

PS this image does not set up any entry for root in /etc/fstab - your script will need to add one. There is an entry for /boot, but that will need patching too (as shipped, points to /dev/mmcblk0p1).

hth, sakaki

[procount]

Yes, thanks. I'll probably have a go when I've finished my current enhancement tasks.

[procount]

I guess I can even ignore the part uuid... statement and just insert the correct partuuid in the bootargs statement. I'll have to do this anyway if the rootfs target device is a USB stick when the boot partition is on the SD card.

[sakaki-]

I guess I can even ignore the part uuid... statement and just insert the correct partuuid in the bootargs statement.

That should work fine too.