UEFI Haiku boot loader for ARM

[Diver]

@X512

minimum-mmc don’t build because of missing mkimage, I can’t find it in repository and it fail to build from HaikuPorts.

This?

pkgman s cmd:mkimage
Status  Name          Description                            
-------------------------------------------------------------
        u_boot_tools  Utilities for working with 'Das U-Boot'

[X512]

Can’t find or build it on 32 bits.

[Diver]

Removing -MQ from Makefile:624 makes u_boot_tools build on 32 bits.

[tqh]

Very interesting progress, we decided to focus on ARM64, after problems with boot packages for ARM was compiled with hardfloat. UEFI for ARM say you can’t use FPU so you would need softfloat. But maybe it works when you specify A7.

[X512]

@tqh

we decided to focus on ARM64

It still not build if I remember.

[tqh]

No, I am slowly working on getting all boot packages building needed for Haiku to build. I just ran out of energy a while back. But ARM64 is a bit more standardized, and you are allowed to use FPU at boot. Still long way to go.

Issues I saw in ARM was logging giving back 0 as value instead of real values, and those looked to be due to fpu usage.

[X512]

Personally I want to work with RISC-V, because it has better documentation, easy peripheral access and simple emulator TinyEMU. I already have written disassembler for RISC-V (it work better that LLVM one and it is integrated with my executable format analyzer framework, sample output), small mini OS for experiments with RISC-V. It is currently able to output graphics, run threads with preemption (no SMP), handle interrupts, receive virtio-input events (tablet, keyboard), show stack traces.

[tqh]

I think you should be able to do that and it seems to have progressed to build and run bootloader somewhat. Talk to kallisti5. I still like the RPi4 for existing hw so want an ARM64 port first.

[X512]

It still fail to build for me:

[48/6650] BootstrapRepositoryFetchPackage1 /Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build/packages/gcc_bootstrap_syslibs_devel-8.3.0_2019_05_24-4-arm64.hpkg 
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
======================================================================
sys-devel::gcc_bootstrap-8.3.0_2019_05_24
======================================================================
requires "haiku" of package "gcc_bootstrap-8.3.0_2019_05_24" could not be resolved
Error: unable to resolve required or prerequired ports for build for gcc_bootstrap-8.3.0_2019_05_24
Error:  dependency-infos:
Error:          /Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build/repository/gcc_bootstrap-8.3.0_2019_05_24.DependencyInfo
Error:          /Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build/repository/gcc_bootstrap_syslibs-8.3.0_2019_05_24.DependencyInfo
Error:          /Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build/repository/gcc_bootstrap_syslibs_devel-8.3.0_2019_05_24.DependencyInfo
Error:          /Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build/repository/gcc_bootstrap_source-8.3.0_2019_05_24.DependencyInfo
Error:  repositories:
Error:          ['/Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build/packages', '/Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build/repository', '/boot/system/packages']
Error: 
Supposedly built package /Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build/packages/gcc_bootstrap_syslibs_devel-8.3.0_2019_05_24-4-arm64.hpkg does not exist; version mismatch?


package="/Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build/packages/gcc_bootstrap_syslibs_devel-8.3.0_2019_05_24-4-arm64.hpkg"
if [ -e "$package" ]; then
exit 0
fi


haikuCrossDevelPackage="objects/haiku/arm64/packaging/packages/haiku_cross_devel_sysroot_stage0_arm64.hpkg"
if [ "x$haikuCrossDevelPackage" = "x" ]; then
echo "$package does not have a cross-devel package defined!"
exit 1
fi

if [ "x$haikuCrossDevelPackage" = "x${haikuCrossDevelPackage#/}" ]; then
haikuCrossDevelPackage="`pwd`/$haikuCrossDevelPackage"
fi


secondaryCrossDevelPackages=
if [ -n  ]; then
for secondaryCrossDevelPackage in  ; do
if [ "x$secondaryCrossDevelPackage" = "x${secondaryCrossDevelPackage#/}" ]; then
secondaryCrossDevelPackage="`pwd`/$secondaryCrossDevelPackage"
fi
if [ -n "$secondaryCrossDevelPackages" ]; then
secondaryCrossDevelPackages="$secondaryCrossDevelPackages,$secondaryCrossDevelPackage"
else
secondaryCrossDevelPackages="--secondary-cross-devel-package=$secondaryCrossDevelPackage"
fi
done
fi


portSpec=`basename "$package" | sed 's@-.*@@'`

cd /Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build

export LIBRARY_PATH="$LIBRARY_PATH:/Haiku/data/packages/haiku/generated.arm64/objects/haiku_host/lib"
if [ -n "$secondaryCrossDevelPackages" ]; then
/Haiku/data/packages/haiku/generated.arm64/../../haikuporter/haikuporter  \
--all-dependencies  \
--cross-devel-package "$haikuCrossDevelPackage" \
"$secondaryCrossDevelPackages" $portSpec
else
/Haiku/data/packages/haiku/generated.arm64/../../haikuporter/haikuporter  \
--all-dependencies  \
--cross-devel-package "$haikuCrossDevelPackage" $portSpec
fi

if [ ! -e "$package" ]; then
echo "Supposedly built package $package does not exist; version mismatch?"
exit 1
fi

...failed BootstrapRepositoryFetchPackage1 /Haiku/data/packages/haiku/generated.arm64/objects/haiku/arm64/packaging/repositories/HaikuPortsCross-build/packages/gcc_bootstrap_syslibs_devel-8.3.0_2019_05_24-4-arm64.hpkg ...

BUILD FAILURE:
...failed updating 1 target(s)...
...skipped 13 target(s)...
...updated 47 target(s)...

Instructions from here are used. I have no idea what is happening and how to fix it. Updating HaikuPorts and HaikuPorter git tree don’t help.

Cast @kallisti5

[tqh]

I thought you wanted to work on RISC-V? For ARM64 you can not build yet. You need to bootstrap the platform before being able to build and that is not done yet.

[X512]

@tqh

You need to bootstrap the platform before being able to build and that is not done yet.

I don’t understand how bootstrapping work and how to do it. I can’t find documentation.

Haiku for RISC-V already compiles so working on port is possible.

[X512]

I am thinking to add haiku_loader platform support for TinyEMU instead of using EFI so it can be passed as “bios” argument like my mini OS. TinyEMU have no EFI support and I can’t find existing UEFI ROM images for QEMU. Also booting directly to ROM is amazingly fast and it speed up development, TianoCore EFI boot is slow. TinyEMU pass FDT pointer to firmware entry point by register.

I already copied Amiga platform to new “riscv” platform and register it in Jamfile’s so it compiles (but currently produce a lot of errors).

[tqh]

At the moment I don’t have the details to describe bootstrapping. You can speed up UEFI quite a bit by telling QEMU to use newer hw:
qemu-system-x86_64 -machine q35 …
Sounds like very interesting work, I’ll see if I can share some info later on. I think others might know more than me though.

[kallisti5]

Yeah, the cause is the lack of the arm64 bootstrap.
https://git.haiku-os.org/haiku/tree/build/jam/repositories/HaikuPorts/arm64

Y’all should learn the process since only a few people know it

You need the following git repositories checked out:

• haiku
• buildtools
• haikuporter
• haikuports
• haikuports.cross

1. mkdir generated.arm64-bootstrap; cd generated.arm64-bootstrap
2. ../configure --build-cross-tools arm64 --cross-tools-source ../../buildtools --bootstrap ../../haikuporter/haikuporter ../../haikuports.cross ../../haikuports
3. jam -q @bootstrap-raw

That will build the _bootstrap packages from haikuports.cross and build a Haiku image for the chosen architecture (arm64 in this case). Generally we don’t care early on if the final Haiku build fails… we’re just interested in the _bootstrap*.hpkg packages it generates via a cross-compile.

The idea is that you then boot the image on a arm64 system and compile all of the packages natively. This is a dumb idea since you’re unlikely to have a working system while bootstrapping a new architecture. Thus @pulkomandy made the “unbootstrap” tool to turn these _bootstrap packages into “real pretend packages” to let the architecture build in a non-bootstrap configuration.

So… to unbootstrap you install the package and package_repo tools on your local system, ensure the build tool libraries are in your LD_LIBRARY_PATH, and then run the unbootstrap tool (https://git.haiku-os.org/haiku/tree/3rdparty/pulkomandy/unbootstrap.sh) to “convert” the cross-compiled bootstrap packages into “normal packages”

These “normal packages” are then uploaded to our server as “build-packages” that are pulled during the build process via these instructions: https://git.haiku-os.org/haiku/tree/docs/develop/build/repositories/README.md

Easy!

This all obviously needs reworked and improved… a lot of edge cases were flat-out ignored when the initial package management stuff was outlined. Then again, bootstrapping software is never easy.

[PulkoMandy]

@kallisti5

This is a dumb idea since you’re unlikely to have a working system while bootstrapping a new architecture.

The “bootstrap” process was originally developped to get from non-packaged to packaged versions of Haiku. In that situation, we already had Haiku running on the target architecture, and just wanted to build packages.

Ideally, you could just work in “bootstrap” mode when working on a new architecture. Just configure things in bootstrap mode, and you can already build the bootloader and kernel, and even a bootable bootstrap image. However, this process builds a lot of things from sources (no binary packages are used in this case), and due to dependency management problems, it re-runs a lot of steps that shouldn’t need to, everytime you run jam.

This is why we have written the unboostrap script (I wrote the script but I was not the only person involved in designing it). It is a hack and allows to do some work on porting to a new system without having to do a bootstrap build everytime, saving some time in the development process. But, the bootstrap packages are built from different recipes (because they are cross-compiled from Linux) and have some features disabled, so, eventually, a “real” bootstrap will still be needed when we have Haiku booting on a new CPU.

[SamuraiCrow]

Thanks for working on this, all of you. As I pointed out in the graphics acceleration thread, it may be easier to find SoC graphics drivers as a stop-gap measure until we get proper discrete graphics on the PC. AArch64 has several SoC machines with open drivers such as my Cubox.

[pengphei]

Finally after some hacking, I add some code to the “frame_buffer_console” module:

status_t
frame_buffer_console_early_init(kernel_args* args)
{
	if (!args->frame_buffer.enabled)
		return B_OK;
	sConsole.early_stage = 1;

	// disable mutex in early stage
	//mutex_init(&sConsole.lock, "console_lock");

	frame_buffer_update((addr_t)args->frame_buffer.physical_buffer.start, args->frame_buffer.width,
		args->frame_buffer.height, args->frame_buffer.depth,
		args->frame_buffer.bytes_per_row);

	console_clear(0x8); // worked, clear the splash 
    console_move_cursor(20,20) // worked, show a white box cursor
	render_glyph(10, 10, 'A', 0x10); // not work, show nothing
	render_glyph(120, 120, 'B', 0x10); // notwork

	return B_OK;
}

and trying to replace the putchar of arch_serial_debug().
But it show nothing when rendering ascii text.

Maybe I have missed something? or maybe the framebuffer mode in kernel is different to the operation in efi mode?

[X512]

I managed to build RAW haiku_loader.riscv firmware image for riscv64 target.

Following devices will be needed for boot loader:

• virtio_console for boot menu.
• virtio_block for reading boot disk.
• framebuffer for boot spash and for passing it to kernel and app_server.
• PLIC – interrupt controller.
• CLINT – timer for system_time etc.

[tqh]

I’m not sure what you are trying to do with frame_buffer_console. If you want serial output, I’d recommend use a hacked in serial output to QEMU serial instead. And on kernel side this is probably what you look for: https://github.com/haiku/haiku/blob/5b113c01c211f0b18a049bcdfeedf1783b98d160/src/system/kernel/arch/arm/arch_debug_console.cpp#L102

[pengphei]

@tqh I have already hacked the debug console with pl011, while it doesn’t work(AFAIK it’s caused by mmu somehow, the address is not 0x9000000), and will hang all the kernel launching process. That’s why I want to debug with framebuffer showing the boot message to screen.

UEFI Haiku boot loader for ARM

I have managed to launch haiku uefi on opensuse: qemu-system-arm -bios /usr/share/qemu/qemu-uefi-aarch32.bin -M virt -cpu cortex-a7 -m 1024 -cdrom haiku-mmc.image --device ramfb -serial stdio And Now the kernel is launched, showing the gray icons: [2021-04-13 21-55-09屏幕截图] And I have add the test code as @X512 mentioned showing the blue screen, now it freezed when setup pl011 uart device. ArchUARTPL011::InitEarly() { // Perform special hardware UART configuration Barrier(); // ** Loopb…