I can already hear the Action Retro ditty.
4 Likes
There are not that many OLD arm machines, that said, i am waiting for his beta 6 Video, and for beta 6 of course.
My first (long gone arm devices were a Siemens simpad and a Compaq ipaq, had linux installed on both in the early 2000s
Hoping it will run on my RPi 4B & RPi 400 soon, that will certainly speed them up…
1 Like
Impressive.
How the current Haiku scheduler manage the M1 cores asymmetric performance, between the 4 high performance cores and the 4 high efficiency ones? AFAIK, Haiku scheduler doesn’t have mechanism yet to optimize the scheduling of threads on big.LITTLE or like cores topology depending of thread dynamic activity, no?
Looks perfect time to add B_CPU_VENDOR_APPLE to headers/OS.h and update get_cpu_vendor_string() and get_cpu_model_string() 
1 Like
As far as the scheduler knows, the 8 cores are all the same
1 Like
Make sense. I guess it will make a good subject for a Summer of Code to add support in scheduler for asymmetric threads dispatching on such big.LITTLE & co cores topology.
I don’t know if it will really be that complicated to add that to the scheduler. I think a lot of the necessary scaffolding may already be there, for the topology handling?
I can think of a few metrics to gauge against: core performance is the obvious but not only factor. Others include code and data cache topologies per-core. Miscellaneous others include stack caches and latency of code cache comtents to avoid flushing.
Elaborate topology support can score major wins over conventional kerneles at the cost of dev time!
Is this the mac or a raspi or something else?
Impressive, we might get R1 on 3 or four architectures, depending on how you count x86 and amd64.
It’s an M1 Macbook Air
you can see the keyboard
It’s a bit tricky and very experimental as HaikuPorter is running mostly on Haiku.
However on Debian, I’ve been able to compile a first dependency “lz4” with some workaround.
These are very experimental steps for the moment on Debian to cross compile a package from Haiku Porter however maybe with some modification in HaikuPorter tool, it could be done:
1. Prerequisites
- Have built Haiku ARM64 from Debian (cross-tools + host tools generated)
- Clone haikuporter and haikuports
git clone https://github.com/haikuports/haikuporter.git
git clone https://github.com/haikuports/haikuports.git
2. Configuration ~/config/settings/haikuports.conf
TREE_PATH="/home/youruser/Documents/C/haikuports"
CROSS_TOOLS="/home/youruser/Documents/C/haiku/generated.arm64/cross-tools-arm64"
TARGET_ARCHITECTURE="arm64"
COMMAND_PACKAGE="/home/user/Documents/C/haiku/generated.arm64/objects/linux/x86_64/release/tools/package/package"
COMMAND_MIMESET="/home/user/Documents/C/haiku/generated.arm64/objects/linux/x86_64/release/tools/mimeset"
PACKAGER="Your Name <your@email.com>"
LICENSES_DIRECTORY="/home/youruser/licenses-haiku"
3. Enable cross-build mode
touch ~/Documents/C/haikuports/.cross
4. Collect licenses
mkdir -p ~/licenses-haiku
You need to put all the licenses files in this directory (to be detailled how to)
5. Patch haikuporter — add missing implicit provides
This is a dirty workaround and the idea is to patch haikuporter itself.
The file HaikuPorter/BuildPlatform.py contains a list of commands that haikuporter considers “already available” on the build host without needing a package. This list is called implicitBuildHostProvides.
By default it includes cmd:gcc, cmd:make, cmd:bash etc. but cmd:ar and cmd:g++ are missing,
The idea is to add all the missing entries (cmd:ar, cmd:g++) in the .py file
Note : you need to add in your PATH the folder “/home/sadmin/Documents/C/haiku/generated.arm64/cross-tools-arm64/bin” and copy the binary “aarch64-unknown-haiku-ar” to the simple name “ar” in this directory.
6. Copy bootstrap depencies packages (like zlib)
cp generated.arm64/download/zlib-1.2.13_bootstrap-1-arm64.hpkg haikuports/packages/
cp generated.arm64/download/zlib_devel-1.2.13_bootstrap-1-arm64.hpkg haikuports/packages/
7. Patch the lz4 recipe for cross-build
As variables like $libDir, $binDir are not recognized on Debian, you need to adapt the recipe file (app-arch/lz4/lz4-1.9.4.recipe):
Like :
- using DESTDIR=“$installDestDir”
- or replacing
$libDir/pkgconfig/liblz4.pcwith$installDestDir$libDir/pkgconfig/liblz4.pc)
8. Build lz4
python3 haikuporter.py \
--cross-tools ~/Documents/C/haiku/generated.arm64/cross-tools-arm64 \
--command-package ~/Documents/C/haiku/generated.arm64/objects/linux/x86_64/release/tools/package/package \
--command-mimeset ~/Documents/C/haiku/generated.arm64/objects/linux/x86_64/release/tools/mimeset \
--cross-devel-package ~/Documents/C/haiku/generated.arm64/objects/haiku/arm64/packaging/packages/haiku_devel.hpkg \
--no-package-obsoletion \
--all-dependencies \
-f \
-j$(nproc) \
lz4
The compilation will proceed but the next step will failed. Ignore the errors.
9. Create hpkg files manually
packageEntries and prepareInstalledDevelLibs fail in cross-build mode on Linux, so hpkg files must be created manually using the host package tool:
PACKAGE_TOOL=/home/user/Documents/C/haiku/generated.arm64/objects/linux/x86_64/release/tools/package/package
SYSROOT=/home/user/Documents/C/haikuports/app-arch/lz4/work-1.9.4/boot/cross-sysroot/arm64/packages/lz4-1.9.4-2/.self
# Create lz4.PackageInfo then:
$PACKAGE_TOOL create -C $SYSROOT -i /tmp/lz4.PackageInfo /tmp/lz4-1.9.4-2-arm64.hpkg
$PACKAGE_TOOL create -C $SYSROOT/develop -i /tmp/lz4_devel.PackageInfo /tmp/lz4_devel-1.9.4-2-arm64.hpkg
cp /tmp/lz4*.hpkg ~/Documents/C/haikuports/packages/
Example of PackageInfo :
cat > /tmp/lz4_devel.PackageInfo << 'EOF'
name lz4_devel
version 1.9.4-2
architecture arm64
summary "LZ4 development files"
description "LZ4 development headers and libraries."
packager "Do <digitalbox098@gmail.com>"
vendor "HaikuPorts"
licenses {
"BSD (2-clause)"
}
copyrights {
"Copyright (c) 2011-2020, Yann Collet"
}
provides {
lz4_devel = 1.9.4-2
devel:liblz4 = 1.9.4
}
requires {
lz4 == 1.9.4-2
}
EOF
10. Retrieve your lib
ls -l ../haikuports/packages/
As you can see it’s possible, however it’s very complicated for the moment as you need to do the job for each depency 
UPDATE : after checking in Haiku ARM64 Qemu, the cross compilation was wrong (missing sysroot and shell variables CC/CXX/AR not being exported). After somes additional fixes :
EDIT : simpler approach is to build a bootstrap image : Bootstrapping Haiku — Haiku internals documentation
12 Likes
How much package needed Haiku ARM64 architecture to reach that status to no more cross compiling needed, as Haiku on ARM64 can compile itself the packages ?
1 Like
You only need to cross-compile the packages in haikuports.cross
1 Like
Is it running natively?
I accessed the haikuports.cross/.cross thing.
It opened a tree view with many branches, that contained recipes for packages by categories. It’s very well organized, but …
I hoped for :
it is a file which enlist the packages, so it way if I clone the file I can see them, and with filtering the lines for package names and do a wc on it in commandline, I also could count them. ;-))
It may have such file somewhere, as sometimes I saw patches where some jam related files were updated for new version of packages, but I had not recorded those files to have written down to find it exactly now 
Nevermind, I expect at least some dozens this way, as we presumably need supporting libraries, programming languages besides the kernel and drivers/firmwares and both system programs and user applications, applets added with the OS.
Yes, it is running natively
Im guessing this won’t get very far on an M3 Pro?
Try and see?
Unfortunately, Apple changed some hardware between M2 and M3 and the Linux developers haven’t been able to get it working, Apple also changed some hardware between M4 and M5 so likely won’t boot on them either.
1 Like