Considering package management was merged in 2013, I think that things are stable enough at this point that we can safely revisit and revamp the bootstrap process 
7 Likes
I’d probably have a subset of bootstrap-raw that only built an image without adding packages. Then you probably would not have to unbootstrap at all. It is also quite convenient while you are fixing up the bootstrap packages.
Not something I will look into more right now though.
3 Likes
The original bootstrap process was designed for x86 where Haiku was already booting fine for a few years. It didn’t take the use case of new architectures into account at all. It is not really convenient to work with for that case.
I would love to have a go at this, but the jam files for haiku are extremely dense to try and get my head around. They were designed for a particular use case (with images, releases, packages) so breaking them apart has been quite difficult for me.
I tried last weekend to look at adding a more limited or even single bootstrap package (like in haiku ports) approach in there and got a lot of the way, but the package lists being pulled in for a minimum build still got me stuck. You basically build images with package lists, not a single hpkg, in the way that repo implements it.
This is all totally understandable given, as @PulkoMandy says, it was not aimed at easing builds on a new architecture, but it could do with a little refactoring to make this task easier. I’d happily pair with someone over zoom who understands jam + haiku bootstrap so I get a brain dump and can then work on it with a clearer mind, if anyone has time?
2 Likes
Hohoho, now I got an haiku-boostrap.image
26 Likes
Need to do some fun stuff with header and relocations:
acpi_init: found ACPI RSDP signature at 0x0000000048450000
acpi: found rsdp at 0x0000000048450000 oem id: BOCHS , rev 2
acpi: rsdp points to rsdt at 0x0
acpi: found valid XSDT at 0x0000000048440000
Welcome to the Haiku boot loader!
add_partitions_for(0x00000000462a1258, mountFS = no)
add_partitions_for(fd = 0, mountFS = no)
0x00000000462a12e0 Partition::Partition
0x00000000462a12e0 Partition::Scan()
check for partitioning_system: GUID Partition Map
check for partitioning_system: Intel Partition Map
priority: 810
check for partitioning_system: Intel Extended Partition
0x00000000462a14d0 Partition::Partition
0x00000000462a12e0 Partition::AddChild 0x00000000462a14d0
0x00000000462a14d0 Partition::SetParent 0x00000000462a12e0
new child partition!
0x00000000462a12e0 Partition::Scan(): scan child 0x00000000462a14d0 (start = 32256, size = 528450048, parent = 0x00000000462a12e0)!
0x00000000462a14d0 Partition::Scan()
check for partitioning_system: GUID Partition Map
check for partitioning_system: Intel Partition Map
check for partitioning_system: Intel Extended Partition
0x00000000462a12e0 Partition::~Partition
0x00000000462a14d0 Partition::SetParent 0x0000000000000000
0x00000000462a14d0 Partition::_Mount check for file_system: BFS Filesystem
0x00000000462a14d0 Partition::_Mount check for file_system: FAT32 Filesystem
0x00000000462a14d0 Partition::_Mount check for file_system: TAR Filesystem
0x00000000462a14d0 Partition::~Partition
add_partitions_for(0x00000000462a1288, mountFS = no)
add_partitions_for(fd = 0, mountFS = no)
0x00000000462a14d0 Partition::Partition
0x00000000462a14d0 Partition::Scan()
check for partitioning_system: GUID Partition Map
check for partitioning_system: Intel Partition Map
check for partitioning_system: Intel Extended Partition
0x00000000462a14d0 Partition::_Mount check for file_system: BFS Filesystem
PackageVolumeInfo::SetTo()
PackageVolumeInfo::_InitState(): failed to parse activated-packages: No such file or directory
load kernel kernel_arm64...
unhandled pheader type 0x6474e551
arch_elf_relocate_rela: unhandled relocation type 1026
relocating kernel failed: 80000010!
add_partitions_for(0x00000000462a1258, mountFS = yes)
add_partitions_for(fd = 2, mountFS = yes)
0x00000000462a5230 Partition::Partition
0x00000000462a5230 Partition::Scan()
check for partitioning_system: GUID Partition Map
check for partitioning_system: Intel Partition Map
priority: 810
check for partitioning_system: Intel Extended Partition
0x00000000462a54d0 Partition::Partition
0x00000000462a5230 Partition::AddChild 0x00000000462a54d0
0x00000000462a54d0 Partition::SetParent 0x00000000462a5230
new child partition!
0x00000000462a5230 Partition::Scan(): scan child 0x00000000462a54d0 (start = 32256, size = 528450048, parent = 0x00000000462a5230)!
0x00000000462a54d0 Partition::Scan()
check for partitioning_system: GUID Partition Map
check for partitioning_system: Intel Partition Map
check for partitioning_system: Intel Extended Partition
0x00000000462a54d0 Partition::~Partition
0x00000000462a5230 Partition::~Partition
PackageVolumeInfo::SetTo()
PackageVolumeInfo::_InitState(): failed to parse activated-packages: No such file or directory
PackageVolumeInfo::SetTo()
PackageVolumeInfo::_InitState(): failed to parse activated-packages: No such file or directory
PackageVolumeInfo::LoadOldStates(): failed to open administrative directory: No such file or directory
See the
load kernel kernel_arm64…
unhandled pheader type 0x6474e551
arch_elf_relocate_rela: unhandled relocation type 1026
relocating kernel failed: 80000010!
6 Likes
Now it is needed to enable generation of arm64 nightly builds like riscv64.
4 Likes
I’ll take a look at the kernel linker script first, but it should be done soon. I have some more fixes as well to push.
4 Likes
Not yet. @tqh since you made it to the bootstrap image, you can take the unbootstrap shell script and run it on your cross-compiled hpkg’s.
Once that is done, tar them all up and send them to me. Then I can make an initial build-packages repo for arm64.
At that point, you can forget about the whole --bootstrap dance until your port is booting. Then we’ll need to run through the (real) bootstrap process again to get the “compiled under haiku” build-packages.
@X512 we’ll need to do the same process for riscv64… however we need to finish merging your changes first 
6 Likes
I see no problem with doing 2 things in parallel.
About RISC-V: -mno-relax related problem should be fixed first. I am not GCC internals expert so I can’t help with proper patch.
1 Like
Also where is the correct place to add -finitarray thing, maybe should be in gcc config for arches?
I currently add it in GCC configure command parameters. It should be fine to add it for all architectures except gcc2 after adjusting boot loader and kernel linker scripts.
1 Like
Yes I think it would be better to have in gcc setup, so if we plan to change anything in gcc arch maybe we should add them.
Yes I am aware of that part. I just want to make sure gcc never uses ctors anymore.
You should be able to do a full build now if you comment out:
if [ -z "$secondaryArchSuffix" ]; then
pythonModuleEnabled=true
fi
in haikuports/dev-libs/libxml2/libxml2-2.9.12.recipe
Then with the efi.sh drive part changed to:
-drive file=fat:rw:disk,format=raw \
-drive file=haiku-bootstrap.image
You should get the same kind of log in console.
6 Likes
Found the bad pheader problem. We define it as PT_STACK header type, and in linker it is .note.GNU-stack. It marks executable permissions on the stack, which we should hopefully never want.
It was enabled due to a bad flag in our gcc-config which has been fixed in this commt: https://git.haiku-os.org/buildtools/log/?qt=range&q=5cccbfddbae2+^dcd0415ded94
If anyone is building, you have to rebuild the compiler and recompile. Since I also added the initarray flag by default (as a PR), you might want to wait until that has been sorted out: https://review.haiku-os.org/c/buildtools/+/4408
So where does this leaves us:
load kernel kernel_arm64...
arch_elf_relocate_rela: unhandled relocation type 1026
relocating kernel failed: 80000010!
Now we need to check what this relocation type is. If it should be there, we should handle it. If not figure out why it is there and remove it, either in gcc config, but more likely in the linker script.
9 Likes
I also became somewhat lazy so created a script for EFI: disk/startup.nsh:
fs0:haiku_loader.efi
Now I only need to press a key at the countdown.
8 Likes
The relocation type is R_AARCH64_JUMP_SLOT and we need to add handling of it and other types in src/system/kernel/arch/arm64/arch_elf.cpp.
The good thing is that there is already work done in previous efforts to document what relocation we need and what they should do: haiku/arch_elf.h at 8f16317a5b6db5c672f331814273e5857555020f · haiku/haiku · GitHub
3 Likes
You can look at riscv64 version for reference: https://git.haiku-os.org/haiku/log/src/system/kernel/arch/riscv64/arch_elf.cpp.
4 Likes