Thanks a lot for pushing this through ! I’m really excited to see some progress on the port (and my apologies for those typos I left in the gcc source )
I can’t access anything remotely looking like a dev environment these days, but I’d be very interested to get your insight on how virtual memory is set on other bootloaders. If I remember correctly most of them don’t bother with segment and only use BAT (at least at this stage)
I kinda remember disabling the set_segment_register and getting the bootloader to proceed on qemu (disabling data / instr address translation too ? it’s a bit fuzzy) which is a shame 'cause it’s a so easier to see progress on that early stage on virtual hardware (at least it is for me)…Anyway hope your exams went well !
Cheers,
If I remember correctly from the ARM port, the bootloader configures things so that all relevant areas (IO space, kernel code and data area) are identity mapped (virtual address == logical address) then enables the MMU. Then the kernel takes over, and can map any extra things it needs.
However, depending on the physical memory layout, this may not always work. In any case, the idea is that the kernel starts with the MMU already enabled and the basic things already mapped where they should be, then the kernel takes over from there and adds more mappings as needed.
Will it work correctly? Kernel usually use high virtual addresses, but boot loader is usually loaded at low addresses. So non-identity mapping is needed.
Qemu still hangs on set_sr after applying that, I have not tried that on real hardware
EDIT: I’ve tried it on a real mac, there it errors out with an invalid instruction access, maybe I’ve made a mistake somewhere
At least on real hardware, the boot loader actually detects the drives. It seems to scan the hard disk as well but there it can’t find a partition, even when the partition is marked as Be_BFS, so I’m guessing that it has trouble reading the apple partition map. However it does detect partitions on the cd drive and tries to boot from them (loading kernel kernel_ppc), however that fails with
Couldn't find both text and data segment
loading kernel failed: 80000010
Haiku itself doen’t yet support apple partition maps nor HFS(+), does it?
As far as I know, you could use openfirmware to access many basic devices (framebuffer, keyboard, mouse, even ethernet) if I understand correctly which would be slow though, as everything is interpreted
It does support Apple partition tables. On x86 this is availabne in the haiku_extras packages, but on ppc it can be added to the main package. However, I don’t think this affects the bootloader, it’s only for kernel support.
Does the bootloader need to parse that partition table by itself, or can it rely on openfirmware to do it?
This is because bootloaders elf loader needs the kernel to have both data and text sections mapped to their own segments (See elf.cpp « loader « boot « system « src - haiku - Haiku's main repository). On x86(_64) and arm64 it seems that the compiler/linker does it by default, on sparc this is done in linker script. @Yn0ga has a linker script with this added on his ppc-work branch on github.
@Yn0ga and me have played a bit with the PPC last week and gotten it a bit further, I think yn0ga got into the kernel _start already.
on PPC architecture in itself - without cross development ;))
Then we can reuse Power based Apple machines and their clones with Haiku …
Of course new HW as well, but for some of us those old ones more enchanting.
)