How to find which physical addresses are used by BOOTBOOT?

[antoni]

I'm porting my OS from GRUB to BOOTBOOT. GRUB's multiboot protocol is much more simple. GRUB, for example, does not setup paging nor long mode nor framebuffer etc.

So it's maybe harder to setup, but filling physical memory allocation linked list is easy, whole memory (except for your kernel and initrd, but their position and size is in MBI) is free at the beginning. Same thing with paging.

When it cames to BOOTBOOT, however, I don't know which memory segments are already used (and I should mark them reserved in my physical memory allocation system).

[Octocontrabass]

I would expect that information to be in the specification, but I didn't see it when I looked. You might need to submit an issue to have the documentation clarified.

[antoni]

It's not in documentation. Only there is description of virtual memory. This is enough to write bootstrap code, but in my operating system I need to manage the paging myself and for that I also need to manage the physical memory.

[thewrongchristian]

It's not in documentation. Only there is description of virtual memory. This is enough to write bootstrap code, but in my operating system I need to manage the paging myself and for that I also need to manage the physical memory.

The spec contains a section about "Memory Map Entries" (page 16), which I presume is the same sort of information as provided by e820 interface or UEFI.

Is that what you're after?

[nexos]

A glance at the EFI loader's source found this

Code: Select all

// failsafe, don't report our own structures as free
            if( mement->NumberOfPages==0 ||
                ((mement->PhysicalStart <= (UINT64)bootboot &&
                    mement->PhysicalStart+(mement->NumberOfPages*PAGESIZE) > (UINT64)bootboot) ||
                 (mement->PhysicalStart <= (UINT64)env.ptr &&
                    mement->PhysicalStart+(mement->NumberOfPages*PAGESIZE) > (UINT64)env.ptr) ||
                 (mement->PhysicalStart <= (UINT64)initrd.ptr &&
                    mement->PhysicalStart+(mement->NumberOfPages*PAGESIZE) > (UINT64)initrd.ptr) ||
                 (mement->PhysicalStart <= (UINT64)core.ptr &&
                    mement->PhysicalStart+(mement->NumberOfPages*PAGESIZE) > (UINT64)core.ptr) ||
                 (mement->PhysicalStart <= (UINT64)paging &&
                    mement->PhysicalStart+(mement->NumberOfPages*PAGESIZE) > (UINT64)paging)
                )) {
                    continue;
            }

I guess it just ignores the bootloader's structures and doesn't put them in the map if I'm not mistaken. Now, it would be best practice to do what Limine does and create entries specifically for this kind of memory, so that the kernel can reclaim some of it when its done using the bootloader.

Full source is at https://gitlab.com/bztsrc/bootboot/-/bl ... bootboot.c in case I missed something.

[antoni]

It's true. I checked few addresses that bootboot passed to me and found that they are outside of the memory reported as free. This is good.

It would be nice if I could possibly free up some of that memory, however, this topic I think is already closed.

[nexos]

To do that, you have three options:
No. 1 - look at the code and figure out which address BOOTBOOT uses, and statically free those address when done with them. I don't recommend this
No. 2 - open an issue in Gitlab for this to be changed
No. 3 - use a different bootloader

I would open an issue personally, as that would help people who will use BOOTBOOT in the future.