ARM64 Port Status

Development OS
201

I see only ArchUARTPL011 in this commit, can we expect this to work for the mini-UART? (supposed to be 8250-compatible)

202

how did you prepare the SD card, what is the exact command?

I followed the steps here.

  1. Pre-req software(build jam)
  2. Create a Compiler Toolchain
  3. Building an MMC (SD Card) Image(jam -j2 -q @minimum-mmc)
  4. Creating an SD card image for real hardware
rune -b rpi4 -i haiku-mmc.image /home/sikkiladho/haiku-rpi4.mmc
dd if=/home/sikkiladho/haiku-rpi4.mmc of=/dev/sdc1

dd command took like 1.2 seconds, which it shouldnā€™t, and I was not able to mount the drive again. I got following error when mounting the sdcard.

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error.
       dmesg(1) may have more information after failed mount system call.

how does your config.txt look like?

I was not able to mount the sd card after dd, therefore couldnā€™t see the contents.

are you trying to boot Haiku with u-boot or TianoCore?

I used rune and followed the above building haiku guides? How will I be able to choose between u-boot and TianoCore? I can compiler uboot for rpi4 myself but I donā€™t how will I make rune to choose between the two.

203

You should write your mmc image to the whole device not partition.

dd if=/home/sikkiladho/haiku-rpi4.mmc of=/dev/sdc1

Wrong:

dd if=/home/sikkiladho/haiku-rpi4.mmc of=/dev/sdc

Ok :

Notice: ā€œ/sdcā€ without partition number.

204

Hi I am trying to build haiku for arm64 on ubuntu 20 x86. I am at the step to build mmc image using ā†’ jam -j2 -q @minimum-mmc
but build fails here is the output

205

The error message seems clear to me. This happens if you clone Haiku from github for example. Either clone from our official repository, or manually set HAIKU_REVISION as instructed.

206

ok I see now, youā€™re actually using the 32-bit arm port.
the suggestion from khallebal should work.

also forget about my quesions related to config.txt and TianoCore, these are more relevant for the 64-bit port.

once you prepare the sd-card, you should be able to see at least the early firmware initialization and u-boot startup messages on the UART. at this point probably not much more than that, so I donā€™t really expect meaningful output from the Haiku loader

207

beware of an other issue: the current head revision doesnā€™t build quite right.
the following additional change is needed: https://review.haiku-os.org/c/haiku/+/4429

which reminds me: probably we should update port status page for arm64 as currently itā€™s a bit too optimistic.

i was thinking of a status like this - what do you think?

  • QEMU (EFI) - bootloader: ongoing (or can we already say that itā€™s workin?), kernel: ongoing, usermode: not started
  • RPI4 - bootloader: ongoing, kernel: not started, usermode: not started
4 Likes
208

yeah you are right about arm32. I tried to build again for arm64. I couldnā€™t get the image being built. Iā€™m here to actually learn and contribute to Haiku for rpi4 or amr64 in general. I have experience with writing a simple hypervisor for rpi4, where I could modify the DTB passed to kernel, trap the exceptions, stage2 memory(still working on it). Iā€™ll try study the code and maybe help with it. Any directions would be appreciated.

4 Likes
209

Hi. While trying to study UART I came across header files defined in haiku/headers/private/kernel/arch/arm.

I see header file defined for bcm283X. RPI4 uses BCM2711. I donā€™t see any such header file targeting rpi4 in haiku/headers/private/kernel/arch/arm or Haiku/headers/private/kernel/arch/arm64. Should I add one by going through peripherals docs?

210

i did a full text search to see where bcm283X.h is includedā€¦ it seems to be used only in the frame buffer driver of the old (and currently broken) ā€œraw u-bootā€ loader:

src/system/boot/platform/u-boot/arch/arm/arch_mailbox_bcm2835.cpp:#include <arch/arm/bcm283X.h>
src/system/boot/platform/u-boot/arch/arm/arch_framebuffer_bcm2835.cpp:#include <arch/arm/bcm283X.h>

so probably we donā€™t really need anything similar for bcm2711 yet.

211

also some testing for the arm64 port on rpi4ā€¦

a few kludges are needed on top of hrev56013:

  • config-manager - actually we donā€™t have to stub it, the reference to config_manager_arch.c can be removed from the Jamfile in arch/arm64 folder as config_manager_scan_hardcoded() never seems to be invoked - merged
  • adjust build flags for ARMv8 - this is not a proper solution but seems to be good enough now to get some output
  • update linker script
  • donā€™t reuse TTBR1_EL1 in the EL2>EL1 transition
  • enable 8250 UART driver in the kernel - merged
  • and one more workaround for the missing /chosen/stdout-path node - this might get better once the ACPI is enabled in arm64 EFI loader

with these, I get the following output:

TODO: arch_smp_register_cpu()
TODO: arch_smp_register_cpu()
TODO: arch_smp_register_cpu()
TODO: arch_smp_register_cpu()
Welcome to the Haiku boot loader!
add_partitions_for(0x0000000037eca298, mountFS = no)
add_partitions_for(fd = 0, mountFS = no)
0x0000000037eca2f0 Partition::Partition
0x0000000037eca2f0 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
0x0000000037eca4e0 Partition::Partition
0x0000000037eca2f0 Partition::AddChild 0x0000000037eca4e0
0x0000000037eca4e0 Partition::SetParent 0x0000000037eca2f0
new child partition!
0x0000000037eca5f8 Partition::Partition
0x0000000037eca2f0 Partition::AddChild 0x0000000037eca5f8
0x0000000037eca5f8 Partition::SetParent 0x0000000037eca2f0
new child partition!
0x0000000037eca2f0 Partition::Scan(): scan child 0x0000000037eca4e0 (start = 20966400, size = 33554432, parent = 0x0000000037eca2f0)!
0x0000000037eca4e0 Partition::Scan()
check for partitioning_system: GUID Partition Map
check for partitioning_system: Intel Partition Map
check for partitioning_system: Intel Extended Partition
0x0000000037eca2f0 Partition::Scan(): scan child 0x0000000037eca5f8 (start = 54520832, size = 314572800, parent = 0x0000000037eca2f0)!
0x0000000037eca5f8 Partition::Scan()
check for partitioning_system: GUID Partition Map
check for partitioning_system: Intel Partition Map
check for partitioning_system: Intel Extended Partition
0x0000000037eca2f0 Partition::~Partition
0x0000000037eca4e0 Partition::SetParent 0x0000000000000000
0x0000000037eca5f8 Partition::SetParent 0x0000000000000000
0x0000000037eca4e0 Partition::_Mount check for file_system: BFS Filesystem
0x0000000037eca4e0 Partition::_Mount check for file_system: FAT32 Filesystem
0x0000000037eca4e0 Partition::_Mount check for file_system: TAR Filesystem
0x0000000037eca4e0 Partition::~Partition
0x0000000037eca5f8 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...
maximum boot loader heap usage: 446728, currently used: 437608
Chosen UART:
  kind: 8250
  regs: 0xfe215040, 0x40
  irq: 93
  clock: 0
Chosen interrupt controller:
kind: None!
kernel:
  text: 0xffffffff80000000, 0x199000
  data: 0xffffffff801a8000, 0x7b000
  entry: 0xffffffff80087bc0
Kernel stack at 0xffff000002454000
System provided memory map:
  phys: 0x0-0x1000, virt: 0x0-0x1000, size = 0x1000, type: ReservedMemoryType (0x0), attr: 0x8
  phys: 0x1000-0x7f00000, virt: 0x1000-0x7f00000, size = 0x7eff000, type: ConventionalMemory (0x7), attr: 0x8
  phys: 0x7f00000-0x7f10000, virt: 0x7f00000-0x7f10000, size = 0x10000, type: ACPIReclaimMemory (0x9), attr: 0x8
  phys: 0x7f10000-0x3784d000, virt: 0x7f10000-0x3784d000, size = 0x2f93d000, type: ConventionalMemory (0x7), attr: 0x8
  phys: 0x3784d000-0x37ec9000, virt: 0x3784d000-0x37ec9000, size = 0x67c000, type: LoaderData (0x2), attr: 0x8
  phys: 0x37ec9000-0x37eca000, virt: 0x37ec9000-0x37eca000, size = 0x1000, type: BootServicesData (0x4), attr: 0x8
  phys: 0x37eca000-0x39eca000, virt: 0x37eca000-0x39eca000, size = 0x2000000, type: LoaderData (0x2), attr: 0x8
  phys: 0x39eca000-0x39f23000, virt: 0x39eca000-0x39f23000, size = 0x59000, type: LoaderCode (0x1), attr: 0x8
  phys: 0x39f23000-0x39f28000, virt: 0x39f23000-0x39f28000, size = 0x5000, type: BootServicesData (0x4), attr: 0x8
  phys: 0x39f28000-0x39f29000, virt: 0x39f28000-0x39f29000, size = 0x1000, type: RuntimeServicesData (0x6), attr: 0x8000000000000008
  phys: 0x39f29000-0x39f2c000, virt: 0x39f29000-0x39f2c000, size = 0x3000, type: BootServicesData (0x4), attr: 0x8
  phys: 0x39f2c000-0x39f2f000, virt: 0x39f2c000-0x39f2f000, size = 0x3000, type: RuntimeServicesData (0x6), attr: 0x8000000000000008
  phys: 0x39f2f000-0x39f30000, virt: 0x39f2f000-0x39f30000, size = 0x1000, type: BootServicesData (0x4), attr: 0x8
  phys: 0x39f30000-0x39f34000, virt: 0x39f30000-0x39f34000, size = 0x4000, type: RuntimeServicesData (0x6), attr: 0x8000000000000008
  phys: 0x39f34000-0x39f40000, virt: 0x39f34000-0x39f40000, size = 0xc000, type: BootServicesData (0x4), attr: 0x8
  phys: 0x39f40000-0x3b350000, virt: 0x39f40000-0x3b350000, size = 0x1410000, type: LoaderData (0x2), attr: 0x8
  phys: 0x3b350000-0x3b360000, virt: 0x3b350000-0x3b360000, size = 0x10000, type: RuntimeServicesCode (0x5), attr: 0x8000000000000008
  phys: 0x3b360000-0x3b400000, virt: 0x3b360000-0x3b400000, size = 0xa0000, type: LoaderData (0x2), attr: 0x8
  phys: 0x3ef60000-0x3ef61000, virt: 0x3ef60000-0x3ef61000, size = 0x1000, type: ReservedMemoryType (0x0), attr: 0x8
  phys: 0x40000000-0xfc000000, virt: 0x40000000-0xfc000000, size = 0xbc000000, type: BootServicesData (0x4), attr: 0x8
  phys: 0xfe100000-0xfe101000, virt: 0xfe100000-0xfe101000, size = 0x1000, type: MMIO (0xb), attr: 0x8000000000000000
Efi loader symbols offset: 0x39eca000:
Current Exception Level EL2
TTBR0: 3b3f0000 TTBRx: 3b3f0000 SCTLR: 30c51835 TCR: 8081351c
MMU Enabled, Granularity 4KB, bits 36
Kernel entry accessibility W: 0 R: 0
Calling ExitBootServices. So long, EFI!
Switched to legacy serial output
Welcome to kernel debugger output!
Haiku revision: hrev56009+5, debug level: 2
PANIC: error allocating early page!

Welcome to Kernel Debugging Land...
Running on CPU 0
Current thread pointer is 0xffffffff801f7500, which is an address we can't read from.

i think this is pretty much what we can expect now, consistent with the behavior on qemu and rpi3.

edit: I just noticed that Iā€™m still using an older kernel hrev56009+5 but actually this should not be an issue as the workarounds above are done in the bootloader anyway, only exception is adding the 8250 driver to the kernel.

6 Likes
212

config-manager should be removed. It is not needed on any platform other than Atari ST IIRCā€¦

213

the implementation is empty even on the atari.
it declares a static struct of ā€œhardcoded devicesā€ but then it doesnā€™t do anything with it, just returns a B_OK.

static struct hardcoded_device gHardcodedDevices[] = {
...some stuff here...
};

status_t
atari_hardcoded(struct device_info **info, int32 *count)
{
        return B_OK;
}
1 Like
214

The pull request for 8250 serial driver has been merged so should be in tree as well now.

3 Likes
215

When can you start testing a compiled image hrev?. I have a:

  • Black Beagle
  • Rpi 4 4GB
  • Odroid C2 2GB
  • NanoPI (allwinner)
  • Rock Pi

And Iā€™am so excited wait for your progres with ARM

2 Likes
216

Please, just delete the whole config manager. It is not needed or used on any architecture and it contains nothing. Why do people insist on building hacks upon hacks for it? :sob:

1 Like
217

The idea was to add some hardcoded devices there. But it would be better to use an FDT for this (we can define one for the peripherals on the Atari machines). mmu_man already agreed that this would be better. But somehow no one actually does the jobs, and hours of work are wasted in figuring out what it is and what it is supposed to do, over and over again. Just delete it so everyone can forget about it and spend their efforts on more useful things.

218

It is on my todo-list. I just didnā€™t want ARM and ARM64 to need to wait for that. Also not sure if the PR we discussed it earlier ever was finished. Anyway, Iā€™ll clean it up so you can focus on other things.

219

config_manager can be useful to store fixed x86 devices (PS/2, COM/LPT ports, PCI host controller) instead of hardcoding registers in each driver.

220

Why? This could be done with an FDT describing the hardware, which is easier than hardcoding it in a C++ file.

2 Likes