ARM64 Port Status

Not so many changes left for bootloader to build/start, won’t happen today though…
arm64_changes

26 Likes

I tweaked my efi shell-script adding graphics hardware, xhci, usb-kbd and usb-tablet. Then this showed up…
bootmenu

33 Likes

Navigation works as well:
bootmenu_navigation

30 Likes

I’ve pushed the changes I think are needed to reproduce my progress. Lets try to explain how to build.

Packages

I am using a Debian Buster container for building so these are packages I install:

apt-get install --no-install-recommends bc attr git nasm autoconf automake texinfo flex bison gawk build-essential unzip wget zip less zlib1g-dev libtool mtools gcc-multilib xorriso python python3 u-boot-tools device-tree-compiler ca-certificates libncurses-dev cmake autopoint pkg-config

cmake for haikuporter, autopoint for make build
pkg-config for make
libncurses-dev for texinfo host tools

Get the Code:

Then I have a base directory haiku-projects where I setup git repos:

git clone https://review.haiku-os.org/buildtools
git clone https://review.haiku-os.org/haiku
git clone git@github.com:haikuports/haikuports.git
git clone git@github.com:haikuports/haikuports.cross.git
git clone git@github.com:haikuports/haikuporter.git

Build and Install jam

(from haiku-projects dir)

cd buildtools/jam
make
sudo ./jam0 install

Configure cross-compiler

(from haiku-projects dir)

cd haiku
mkdir arm64
cd arm64
../configure --build-cross-tools arm64 --cross-tools-source ../../buildtools --distro-compatibility official -j4 --use-gcc-pipe  --bootstrap ../../haikuporter/haikuporter ../../haikuports.cross ../../haikuports

Build Bootstrap Packages and Haiku

Note: It will fail before full haiku image atm
(still in arm64 dir from previous step)

jam -j4 -q @bootstrap-raw

This will take a very long time, but rerunning it should be much faster as bootstrap packages should have been built and it is more like an ordinary Haiku build.

Install QEMU

Note: Debian QEMU is very outdated in buster so we use buster-backports

apt-get install -t buster-backports qemu-system-aarch64 qemu-efi-aarch64

The qemu-efi-aarch64 will install the UEFI firmware in /usr/share/qemu-efi-aarch64/

Running the Bootloader

(still in arm64 dir from above steps)

Create a Fake UEFI Boot Partition

mkdir disk
cd disk
ln -s ../objects/haiku/arm64/release/system/boot/efi/haiku_loader.efi
cd ..

Copy UEFI fw to dir

cp /usr/share/qemu-efi-aarch64/QEMU_EFI.fd .

Just to make sure that we don’t mess with the original.

Launch QEMU

qemu-system-aarch64 -m 256M -cpu cortex-a57 -M virt -bios QEMU_EFI.fd \
	-device virtio-gpu-pci -device qemu-xhci \
	-usb -device usb-kbd -device usb-tablet \
	-display gtk,grab-on-hover=on,zoom-to-fit=off \
	-net none -no-reboot -serial stdio \
	-drive file=fat:rw:disk,format=raw

The fake disk we created above is used as a fat drive.

Launch haiku_loader.efi

You should now be in UEFI shell. It will countdown or you can press ESC.
Here you can type help for info about commands in the shell.
We are going to change to our disk called fs0 as it is the first filesystem found.

fs0:

Then you can do ls if you want to see what is there, but lets run, start typing hai and press TAB, for auto-completion. Or do:

haiku_loader.efi

This should bring you to the bootloader and where the port is currently at. Here is how it looks like:
uefi_shell

33 Likes

After running jam to build bootstrap packages and Haiku I get the following error: (I’ve got git version 2.25.1)

2021-08-27 14:55:40 (6.13 MB/s) - ‘/home/leo/Dev/haiku/arm64/…/…/haikuports.cross/sys-devel/gcc_bootstrap/download/4ab0fe4d95a13d203733d2dac3895c014ba7d293.tar.gz’ saved [196090445]
Validating checksum of 4ab0fe4d95a13d203733d2dac3895c014ba7d293.tar.gz
Unpacking source of 4ab0fe4d95a13d203733d2dac3895c014ba7d293.tar.gz
error: unknown switch `b’
usage: git init [-q | --quiet] [–bare] [–template=] [–shared[=]] [
]

I also noticed this error that happened before the git one:

LinkApplicationCatalog1 objects/catalogs/kits/package/pt_BR.catalog
In file included from /home/leo/Dev/haiku/arm64/cross-tools-arm64/aarch64-unknown-haiku/include/c++/8.3.0/bits/stl_algo.h:59,
from /home/leo/Dev/haiku/arm64/cross-tools-arm64/aarch64-unknown-haiku/include/c++/8.3.0/algorithm:62,
from …/src/kits/interface/TextView.cpp:28:
/home/leo/Dev/haiku/arm64/cross-tools-arm64/aarch64-unknown-haiku/include/c++/8.3.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
^~~~~~~~~~

You need to upgrade git.

I updated git and progressed further. Now it ended with the following message, not sure it’s intended:

BUILD FAILURE:
…failed updating 2 target(s)…
…skipped 1897 target(s)…
…updated 887 target(s)…

Yes, it is a ongoing port. You should probably know a lot of the basics about building to try to follow these instructions. Otherwise I will have to focus on being a support person instead of progressing the port.

That being said, maybe it would be good to have a different topic where build related questions and help can be given.

3 Likes

Time to get the ports building so the haiku image can be built.
ports

14 Likes

Bra jobbat (Nice work) :smiley:

5 Likes

If I get enough time after doing my COVID project this weekend I plan on going through the ‘minimal’ ports and then the full release ports to add in arm64 for any missing it, and fixing any issues in there. How far we get depends on the excellent work @tqh is doing, but as he says, his time is best spent getting the base image built and then we can all pore in on the ports for the rest of the system.

4 Likes

It seems it was enough to solve the bash problem by adding arm64 to its haikuports recipe. So I guess I have some work to do for other packages…

7 Likes

After enabling a lot of recipes for arm64 and riscv64 I still have to deal with some python2 / python3 mess, and then maybe more dependencies. But it is closer to building an image…
deps

9 Likes

Is regular HaikuPorts (not cross) repository really needed? It is not very useful until system on target architecture will functional.

1 Like

I don’t know. I asked same questions but nobody could answer. It seems a bit weird for bootstrap-raw. It should not be that many packages though and they should be enabled anyway as they are base packages.

You can build only bootstrap packages, unbootstrap it, put to download folder and then build regular Haiku image. You can upload unbootstrapped packages so everyone can build arm64 image like it was done with riscv64. @kallisti5 probably knows where unbootstrapped packages should be uploaded to be downloaded automatically by build system.

2 Likes

I did a local fix for libxml and fixed gawk. It seems that was the last package needed. So I think I am already past that stage.

3 Likes

Building bootstap-raw have a little meaning because it will not run without implementing kernel code. It is supposed to be run on virtual machine to build regular HaikuPorts packages.

I didn’t used bootstrap-raw at all for riscv64, I am building regular HaikuPorts packages with nightly-raw Haiku on real hardware.

1 Like

I guess I didn’t get the same info as you on how to bring up a new port. I still just want an image built, so seems the effort is the same for both approaches now.

2 Likes

There are two processes for bootstrapping a new architecture:

Method as originally designed

  1. Get the port 100% functional (compiling and booting) with just @bootstrap-raw.
  2. Once the arm64 bootstrap-raw image boots, it will “bootstrap” and build all the haikuports.cross packages on the new architecture
  3. The resulting ‘compiled-under-real-haiku-arm64’ “build-packages” are pushed to the infrastructure

Short circuit unbootstrap method

  1. Get the port far enough to cross-compile all of the needed build-packages
  2. Run the “unbootstrap tool” to convert the cross-compiled bootstrap packages into “normal packages”
  3. The resulting Frankenstein ‘compiled under linux for haiku arm64’ “build-packages” are pushed to the infrastructure.

The difference between the two is you can build targets other than “@bootstrap-raw” with the short circuit method. (@minimum-mmc, @nightly-raw, etc). The “unbootstraped” packages shouldn’t be trusted long-term and should be replaced once the port is stable enough to boot.

The original design of package management kind of missed the point that getting an entire architecture port working in bootstrap mode is pretty difficult.

10 Likes