Jetson Nano aarch64

I built a BeOS machine way back when and just found Haiku. I’d like to start experimenting with building Haiku on/for my Nvidia Jetson Nano so I can have a Haiku robot. Maybe one day it will autonomously navigate the halls spouting actual haiku poetry. I cannot do that until the build tools at least have a configure option for aarch64 64bit ARM architecture. I’ve seen Nvidia engineers on forums actively seeking out projects to support. Its a $99 5v 10w machine with Maxwell GPU, 40pin RPi IO, camera input, micro SD boot drive, and a growing community to support it. Nvidia wrote all the binary blobs for Ubuntu. I’d be happy to see Haiku devs catch that wave. I know its a lot of work in a new direction and that can distract from current work, so I understand if it doesn’t happen. FWIW, you have my vote for aarch64

1 Like

Have you told them to consider supporting Haiku? Because they got the expertise, the docs and all the stuff to do it properly. If you havent done that yet, consider it.

1 Like

Wilco. I also just noticed this https://review.haiku-os.org/c/buildtools/+/1808/1/binutils/bfd/config.bfd, so its in the works, just not in web documentation yet.

1 Like

Well ARM is one platform we are slowly porting Haiku to, but it’s not the main focus. If you want to contribute you can help :slight_smile:

1 Like

An up to date, end to end howto on getting and building Haiku, running using QEMU, and using Rune to set up for real hardware would go a long way. ARM stuff is about all I do. But I can’t work out how to get anything happening with ARM and Haiku. The documentation is fragmented, out of date, and has gaps.
It doesn’t need to be a masterpiece. People can’t work on it if they spend all their time trying to get it to build and run.

1 Like

Many of the ARM platforms have implemented a 40 pin interface to memory mapped GPIO, SPI, I2C, I2S like the Raspberry Pi. A polished software interface to it could be the “killer app”. Could anyone point me to Haiku code implementing a non-usb memory mapped driver?
I’m not expecting it to work, just looking for guidance on the way core developers would like this sort of interface handled.

Most of this is just the basic workflow for building haiku. This article is complete except for the qemu section which is out of date…

https://www.haiku-os.org/guides/building/compiling-arm

If you’ve dealt with arm, here are our fundamentals…

  1. I’m moving our bootloader from a native u-boot loader (haiku_loader.ub) to an EFI binary (haiku_loader.efi). The reasoning is the EFI BIOS services allow us to not pack a bunch of kernel drivers and fdt parsing code within our bootloader. The status here is our bootloader runs under QEMU + Tianocore EFI, but jumping into our kernel isn’t working. see https://twitter.com/kallisti5/status/1291038304633335811 if you want to help out :slight_smile:

  2. Rune is a tool I wrote to “post-process” our generic arm images for various target boards. The post-processing is mostly grabbing pre-compiled u-boot binaries + SoC blobs and injecting them into our sd card in various places. https://github.com/haiku/rune

Essentially on ARM:

  • Native EFI bios? (not many platforms outside of qemu + tianocore)
    • qemu-system-arm -m 1024 -M virt -bios /usr/share/edk2/arm/QEMU_EFI.fd -device virtio-gpu -hda haiku-mmc.image -hdb haiku-minimum.mmc
      • two disks because our root filesystem isn’t getting appended within haiku-mmc.image by the build system like it’s supposed to be… known issue.
    • haiku-mmc.image boots without any additional modification. (doesn’t need rune tool)
    • qemu -> tianocore -> /EFI/BOOT/BOOTARM.EFI
  • Raspberry Pi, Rockchip. Allwinner, etc, etc?
    • End user uses rune to provision the generic arm image for their own personal hardware.
    • u-boot has a built-in FDT our bootloader will need to get and pass to the kernel. Details need more investigation
    • SoC -> u-boot -> bootefi /EFI/BOOT/BOOTARM.EFI

I threw together a diagram of the various processes used to boot Haiku here:
https://github.com/haiku/rune/blob/master/docs/HaikuMMCLayout.png

1 Like

why don’t you put your .efi files into Haiku specific folder under \efi, say \efi\haikuorg\arm? note, the path you use is a “resort” method and it is optional for non-removable storages. UEFI may not check it out - it’s left to the implementation. this also won’t work, if there are other, normal Load Options (multi OS environment). in both edk2 and uboot UEFI, using your own place for your OSL, won’t give you problems, - you just put it in a FAT volume (the only required FS to be supported by UEFI). and use “load from file” option in a full UEFI FW or using bootefi in uboot.

What’s the best place to converse about that? Why is there any THUMB code at all? While I’ve done booting from U-Boot but never EFI, I really can’t grasp what is going on there. I need context.

Where did you see thumb code?

1 Like

there is no “thumb code” in the aarch64 execution state, only a64 ISA. in aarch32, thumb (a so called t32 ISA) is not prohibited by UEFI, but I wouldn’t mess with it; pure a32 ISA in aarch32 is the best, imo.

uboot has some sort of UEFI support. starting UEFI OSL from its console isn’t any harder, than using other methods (mostly linux biased) it offers (bootm, booti, bootz). after you shadowed your .efi image into memory, and .dtb as well (load mmc X:Y 0xb16b00b5 /bla/bla/bla), you do bootefi addr1 addr2, where the first is the address of an .efi image (where you put it, not its base), and the second is the .dtb file address. iirc, but you can type help bootefi to get the right format.

also uboot kind of should support UEFI BootXXXX variables (they hold Load Option Descriptors). don’t know about that, didn’t try it yet, but nevertheless, would be cool if it did; it needs yet to get a proper UEFI Boot Manager, before being able to behave as a real UEFI FW in this respect. but using bootefi surely works.

Indeed it does :slight_smile:. Loading our EFI haiku_loader via u-boot is the plan for “real hardware” and seems to work in qemu (you have to manually “load” our bootloader, there is a known bug in our u-boot boot.scr under qemu where it locks up)

qemu-system-arm -bios ~/Downloads/u-boot.bin -M virt -m 2048 -hda haiku-mmc.image -hdb haiku-minimum.mmc --device virtio-gpu

uboot-efi-1
uboot-efi-2

There is a method to my madness… it’s just taking a while :slight_smile:

Well… known to me. In-case I get hit by a bus I opened https://dev.haiku-os.org/ticket/16499

e: If there is no transition between ARM and THUMB, why is bx being used?
The following instructions would be valid in THUMB too. But they are 4 bytes long. I didn’t notice that before.

1. (gdb) disassemble 0x47830650, 0x47830698
2. Dump of assembler code from 0x47830650 to 0x47830698:
3. 0x47830650: bx lr
4. 0x47830654: wfi
5. 0x47830658: bx lr
   0x4783065c:	andeq	r0, r0, r0

Edit again: I’m a big thickie. Bootloader is in haiku/src/system/boot/platform/efi/arch/arm/

What are you looking at at these addresses? Is that where PC is pointing when it crashes or something?

Those were taken from the pastebins that were linked to in the tweet that was linked to by kallisti5
earlier on.

Anyway this is totally the wrong place for all this. I will say that tonight I built the tools and mmc image using my Jetson Nano. So that at least ties it all together.

Hmm, I think we should use an OpenFirmware payload and bootof instead :exploding_head: