It is all assumptions right now 
They need to be verified or reevaluated all the time.
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)
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 
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