ARM64 Port Status

For completeness: sparc uses 8K and I already ran into some problems (and fixed them) because of it.
So, yes, stay with 4K for now if you can.

2 Likes

I saw your commits about page sizes and alignments and such for sparc, so rather avoid getting into that.

Just do the absolute minimum to get things going, then improve and add more.Right now I think that is to have serial out after exit bootservices (this donā€™t have to be in a clean way), setup exception-handlers and map memory for kernel.

6 Likes

Hello,

Which would be the resources to look at to have a smoother ramp up?
Have access to an A53 based board, fully u-boot supported.

For instance, to start somewhere:
Assuming u-boot would take care of all the enabling, and basic peripheral initialization, what is the element/binary that u-boot would load/jump into to DDR?

1 Like

The current process is that u-boot would load our stage2 bootloader, built as an EFI binary. It should be in generated/objects/haiku/arm64/release/system/boot/efi/haiku_loader.efi after compiling.

This requires an u-boot version with EFI support, on ARM64 this should be quite standard.

Then the bootloader will do its usual job: scan all boot devices using EFI services, and try to find a BFS partition with an Haiku install on it, and load the kernel from there. If it doesnā€™t find anything you will get to the boot menu (probably on the serial console, unless your uboot implements a framebuffer console/textmode and makes it available to EFI applications).

1 Like

u-boot have framebuffer with GOP support, see My progress on real RISC-V hardware - #277 by X512. But it is often not available on various platforms.

We don not require u-boot at all. We just need a UEFI firmware.

Thanks, It was not enbled by default, but after enabling I could:
setenv image haiku_loader.efi; run loadimage; run loadfdt ; bootefi ${loadaddr}

Looks that is the caseā€¦ I did not expect reaching this point with the board (neither such things out of an UART)

image002

Expected error as I reused the yocto ecosystem for final image creation, so there is no BFS partition (a linux ext4 rootfs instead).

My understanding is that next step for aligning myself is getting a ā€œhaiku-minimum.mmcā€ which can be dded to a partition. It got generated for the ARM targetā€¦ But it did not get generated for ARM64 target, is this expected? Anything I missed?

My only modification from the ARM guidelines:

../configure -j2 --cross-tools-source ../../buildtools --build-cross-tools arm64

13 Likes

Ooh is that real hw! Nice.

Currently the build needs fixes for zstd, I havnā€™t uploaded the zstd package yet. The minimal zstd used for booting fail on neon instructions. You are probably the first to try a non-bootstrap build so I guess you are on rev before zstd was added.

I think this is a problem with how we just use part of the zstd sources, but havnā€™t figured it out yet.

Other than that, my latest post on ARM64 is still where we standā€¦

3 Likes

What specific SBC are you using?

1 Like

It is a custom board, if by SBC you mean SoC, is this one. Not an accesible one, and by its specs, I am only pursuing a functional kernel, which other ports, or other SoC from that NxP family could benefit.

Indeed isā€¦ and with a JTAG interface waitingā€¦

I see some commits relating zstd from ~26th Oct, those are in my build.

But I could not understand if zstd is the reason not having a complete BFS image, or if I should have experienced some exception in the ā€œhaiku_loader.efiā€ itself given that minimal zstd instructions you mentionā€¦

Just trying to reproduce on my side any of the current ARM64 port roadblocksā€¦

I see I still have --use-gcc-graphite in my configure, probably should remove it and try.

Not making a difference, I do bootstrap builds and have zstd package, maybe that is the difference. I probably have more time to look into later but here is the beginning of the interesting errors:

In file included from build_packages/zstd_bootstrap_source-1.5.0-2-source/develop/sources/zstd_bootstrap-1.5.0-2/sources/lib/common/zstd_internal.h:23,
                 from build_packages/zstd_bootstrap_source-1.5.0-2-source/develop/sources/zstd_bootstrap-1.5.0-2/sources/lib/common/zstd_common.c:19:
build_packages/gcc_bootstrap_syslibs_devel-8.3.0_2021_09_21-1-arm64/develop/headers/gcc/include/arm_neon.h: In function 'vtrn_f16':
build_packages/gcc_bootstrap_syslibs_devel-8.3.0_2021_09_21-1-arm64/develop/headers/gcc/include/arm_neon.h:29273:10: error: missing braces around initializer [-Werror=missing-braces]
   return (float16x4x2_t) {vtrn1_f16 (__a, __b), vtrn2_f16 (__a, __b)};
          ^
                           {                                         }
2 Likes

Following your latest instructions in this post, experienced similar errors as others reported. Therefore sticked with ā€œminimum-mmcā€ as I am able to get some artifacts built.

After stubbing:

add-ons/kernel/bus_managers/config_manager/arch/arm64/config_manager_arch.c
add-ons/kernel/debugger/disasm/arm64/
bin/debug/ltrace/arch/arm64

I could see an BFS image generated, which is what I needed to setup the sdcard and go forward. Unfortunatelly such image is empty therefore I manually(only) copied the kernel & libroot.

In such situation looks partitions are scanned, BFS looks to be detected and so onā€¦

Afterwards I have evidences reaching arch_enter_kernel (but not any evidence that everything has gone properly until there).
Reaching this point since u-boot, takes suspiciously too long(~26s), and arch_enter_kernel fails into exception when:

// call the kernel
br		x4

Only question would be, How behind am I?

1 Like

Stubbing config_manager should not be needed, and confg_manager should be removed. It is only useful for m68k but somehow all arches are forced to depend on it. The others should not matter either, but it was some time since I checked.

You are were I was before build breakages. Question is why you donā€™t see zstd neon problems. I think it is because of fp16 type(see Half Precision Floating Point) is missing in our config, so have you configured -march when you build?

Anyway, inital MMU map is needed and setting up exceptions after kernel, and some way to print from kernel during the bringup. Once we get far enough it is time to start looking at device tree I guess.

2 Likes

For completeness: kubuntu20.04, 7d41530f6295effc1a1d284505bc7e65d49bd311:

../configure -j2 --cross-tools-source ../../buildtools --build-cross-tools arm64
jam -j2 -q @minimum-mmc

I see sudo apt install libzstd-dev in my history

Despite the code goes over several dprints and traces they donā€™t come out. Lasts ones I get are from u-boot. After u-boot handles the control, console_init / serial_init fail. I understand this is not your case. Iā€™d like to fix this to have an complete overview of how things have gone until hereā€¦ However it is confusing because the space_bar menu works perfectly when invokedā€¦

As I use Qemu and its qemu-efi-aarch64 package (debian) I have serial out through UEFI APIā€™s. I guess u-boot doesnā€™t support it.
Not sure why you donā€™t get zstd problems, maybe some local changes I have on build flags or because I still do bootstrap builds.

Good thing is these are real issues, so itā€™s work that needs to be done. Had some fun hitting this problem: 100854 ā€“ TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__

1 Like

As you might have realizedā€¦ I am not yet at the stage to be useful in the Build Process :frowning:

Correct, LocateProtocol(&sSerialIOProtocolGUID,ā€¦) fails, I see my uboot is not supporting this particular GUID (but it is supporting others EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL_GUID that could do the trickā€¦ ā†’ TODO).

However there is some ifdefed out code which allows as fallback to use the same method as it is used for the menu. Is there any strong reason to keep that portion out? It would have saved some debug timeā€¦

[...]
0x00000000f9cc15b8 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: 446616, currently used: 437496
kernel:
  text: 0xffffffff80000000, 0x190000
  data: 0xffffffff80190000, 0x7a000
  entry: 0xffffffff800801c8
Kernel stack at 0xffff00000241b000
System provided memory map:
  0x34000000-0x34800000  0x34000000 0x7 0x8
  0x80000000-0x8000f000  0x80000000 0x7 0x8
  0x8000f000-0x80020000  0x8000f000 0x0 0x8
  0x80020000-0x83000000  0x80020000 0x7 0x8
  0x83000000-0x83c00000  0x83000000 0x0 0x8
  0x83c00000-0x87f00000  0x83c00000 0x7 0x8
  0x87f00000-0x87f0c000  0x87f00000 0x4 0x8
  0x87f0c000-0xc0000000  0x87f0c000 0x7 0x8
  0xc0000000-0xc0400000  0xc0000000 0x0 0x8
  0xc0400000-0xd0000000  0xc0400000 0x7 0x8
  0xd0000000-0xd0400000  0xd0000000 0x0 0x8
  0xd0400000-0xf9697000  0xd0400000 0x7 0x8
  0xf9697000-0xfbcc1000  0xf9697000 0x2 0x8
  0xfbcc1000-0xfbd12000  0xfbcc1000 0x1 0x8
  0xfbd12000-0xfbd16000  0xfbd12000 0x0 0x8
  0xfbd16000-0xfbd17000  0xfbd16000 0x4 0x8
  0xfbd17000-0xfbd18000  0xfbd17000 0x6 0x8000000000000008
  0xfbd18000-0xfbd1a000  0xfbd18000 0x4 0x8
  0xfbd1a000-0xfbd1e000  0xfbd1a000 0x0 0x8
  0xfbd1e000-0xfbd20000  0xfbd1e000 0x4 0x8
  0xfbd20000-0xfbd21000  0xfbd20000 0x6 0x8000000000000008
  0xfbd21000-0xfbd24000  0xfbd21000 0x0 0x8
  0xfbd24000-0xfbd25000  0xfbd24000 0x6 0x8000000000000008
  0xfbd25000-0xfbd26000  0xfbd25000 0x0 0x8
  0xfbd26000-0xfcf30000  0xfbd26000 0x2 0x8
  0xfcf30000-0xfcf31000  0xfcf30000 0x0 0x8
  0xfcf31000-0xfcfc0000  0xfcf31000 0x2 0x8
  0xfcfc0000-0xfcfd0000  0xfcfc0000 0x5 0x8000000000000008
  0xfcfd0000-0xfe800000  0xfcfd0000 0x2 0x8
  0xfe800000-0x100000000  0xfe800000 0x4 0x8
  0x880000000-0x8e0000000  0x880000000 0x4 0x8
Calling ExitBootServices. So long, EFI!

The system memory reported looks matching the SRAM and DDR provided by the SoC, Still need to diggest the rest, will be looking into the kernel jump after thisā€¦

& THANKS!

6 Likes

It results in the traces being printed over the menu, and makes things a bit unreadable. So for the x86 version it is disabled by default. But for early debug when nothing else works, or when there is no serial port service available, it can be useful for other platforms.

1 Like

It doesnā€™t really make sense for a working platform to have that logging either.