How can I control the entry point and the address of the kernel stack using bootloader?

[flying-rind]

It's a little hard for me to understand the internal details of bootloader, i wonder if i can control the address of the kernel entry point and the kernel stack? And what would happen if I use a linker script to specify the segments.

[Freax13]

If you want to statically set the kernel stack address, you can set Mappings.kernel_stack. If you want the kernel to be loaded at a fixed address, you can compile the kernel with -C relocation-model=static and change the addresses of the segments in a linker script.

[flying-rind]

If you want to statically set the kernel stack address, you can set Mappings.kernel_stack. If you want the kernel to be loaded at a fixed address, you can compile the kernel with -C relocation-model=static and change the addresses of the segments in a linker script.

Thanks a lot, that worked, however, i am still a little confused about the virtual_address_offset in the bootloader output, is it the mapping.physical_memory? I set the mapping.physical_memory to 0xFFFF_8000_0000_000, however bootloader output shows the virtual_address_offset = 0x0, the bootloader output is shown below. As the same as my source code.

/// bootloader config
pub static BOOTLOADER_CONFIG: BootloaderConfig = {
    let mut config = BootloaderConfig::new_default();
    // PHYS_OFFSET = 0xFFFF_8000_0000_0000
    config.mappings.physical_memory = Some(Mapping::FixedAddress(PHYS_OFFSET as _));
    config.mappings.kernel_stack = Mapping::FixedAddress(KERNEL_STACK_ADDRESS as _);
    config
};

BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM00003 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM00001 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM00001 " from PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
INFO : Framebuffer info: FrameBufferInfo { byte_len: 3145728, width: 1024, height: 768, pixel_format: Bgr, bytes_per_pixel: 4, stride: 1024 }
INFO : UEFI bootloader started
INFO : Using framebuffer at 0xc0000000
INFO : Reading configuration from disk was successful
INFO : Trying to load ramdisk via Disk
INFO : Ramdisk not found.
TRACE: exiting boot services
TRACE: switching to new level 4 table
INFO : New page table at: PhysFrame[4KiB](0x2000)
INFO : Elf file loaded at 0x00000000bd860000
INFO : virtual_address_offset: 0x0
INFO : Handling Segment: Ph64(ProgramHeader64 { type_: Ok(Load), flags: Flags(4), offset: 1000, virtual_addr: ffffff0000000000, physical_addr: ffffff0000000000, file_size: 812c, mem_size: 812c, align: 1000 })
INFO : Handling Segment: Ph64(ProgramHeader64 { type_: Ok(Load), flags: Flags(5), offset: a000, virtual_addr: ffffff0000009000, physical_addr: ffffff0000009000, file_size: 509aa, mem_size: 509aa, align: 1000 })
INFO : Handling Segment: Ph64(ProgramHeader64 { type_: Ok(Load), flags: Flags(6), offset: 5b000, virtual_addr: ffffff000005a000, physical_addr: ffffff000005a000, file_size: 5670f0, mem_size: 5670f0, align: 1000 })
INFO : Handling Segment: Ph64(ProgramHeader64 { type_: Ok(Load), flags: Flags(6), offset: 5c3000, virtual_addr: ffffff00005c2000, physical_addr: ffffff00005c2000, file_size: 0, mem_size: 2622378, align: 1000 })
INFO : Mapping bss section
INFO : Entry point at: 0xffffff0000009020
INFO : Creating GDT at PhysAddr(0x33b0000)
INFO : Map framebuffer
INFO : Map physical memory
INFO : Allocate bootinfo
INFO : Create Memory Map
INFO : Create bootinfo
INFO : Jumping to kernel entry point at VirtAddr(0xffffff0000009020)

[Freax13]

virtual_address_offset is the base address for position-independent executables. If you're using a static binary, it's always zero.

FYI if your goal is to create a higher-half kernel, you may be interested in the higher_half test kernel.

[flying-rind]

virtual_address_offset is the base address for position-independent executables. If you're using a static binary, it's always zero.

FYI if your goal is to create a higher-half kernel, you may be interested in the higher_half test kernel.

OK, thanks a lot!

[phil-opp]

virtual_address_offset is the base address for position-independent executables. If you're using a static binary, it's always zero.

Maybe we should print it e.g. as PIC virtual address offset in the logs to avoid confusion?