search for: code32_start

>That address seems to come from >here: https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/arch/x86/boot/pm.c#L124 > >``` >protected_mode_jump(boot_params.hdr.code32_start, > (u32)&boot_params + (ds() << 4)); >``` > >That boot_params.hdr.code32_start field is probably either invalid (bad reloc or something else causing the bootloader to >calculate the wrong address) or valid but the thing it thinks it is pointing to wasn't loaded (missi...

>I have just checked it, the startup.elf and realmode.elf are fine. Only few changes are required for mainline kernel and one >commit has to be reverted from lld and a few patches have to be applied. > >The only step when I have used BFD is linking vmlinux. I have manually set LD variable in vmlinux_link() function. The vmlinux >produced by lld doesn't work yet. I will compare

>>That boot_params.hdr.code32_start field is probably either invalid (bad reloc or something else causing the bootloader to >>calculate the wrong address) or valid but the thing it thinks it is pointing to wasn't loaded (missing PT_LOAD etc.). >boot_params.hdr.code32_start field is valid :) It is 0x100000, like expected...

OK, here's another go-around. This patch leaves the bzImage itself unmodified, but it changes the payload into an ELF file. That is, the 32-bit decompression/relocation+compressed kernel is now a properly formed ELF file. One thing that fell out of this is that code32_start end up being a pointer to the ELF header rather than an entrypoint. Rather than reproducing Vivek's (?) hack of making the ELF header itself executable, I changed the 16-bit code to check for an ELF magic number at code32_start and use the e_entry to get the actual entrypoint. This seems like...

OK, here's another go-around. This patch leaves the bzImage itself unmodified, but it changes the payload into an ELF file. That is, the 32-bit decompression/relocation+compressed kernel is now a properly formed ELF file. One thing that fell out of this is that code32_start end up being a pointer to the ELF header rather than an entrypoint. Rather than reproducing Vivek's (?) hack of making the ELF header itself executable, I changed the 16-bit code to check for an ELF magic number at code32_start and use the e_entry to get the actual entrypoint. This seems like...

...lly determined location, that code will be moved to the next available location. However, beginning with commit 8f470e7b, the code is moved to the initially determined location instead of the next available location because prot_mode_base is no longer updated to the correct location. Since whdr->code32_start is updated, it is pointing to the wrong execution start location, random code is executed and the machine is rebooted. Restore the old behavior by assigning prot_mode_base the value of base. Tested on a machine that exposed this behavior. Signed-off-by: Scot Doyle <lkml14 at scotdoyle.com>...

Correct base's type to match its initialization from prot_mode_base and passage to syslinux_memmap_find(). Tested with extlinux. Signed-off-by: Scot Doyle <lkml14 at scotdoyle.com> --- com32/lib/syslinux/load_linux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c index 06ae2a9..ac73729 100644 ---

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

This series: 1. Updates the boot protocol to version 2.07 2. Clean up the existing build process, to get rid of tools/build and make the linker do more heavy lifting 3. Make the bzImage payload an ELF file. The bootloader can extract this as a naked ELF file by skipping over boot_params.setup_sects worth of 16-bit setup code. 4. Update the boot_params to 2.07, and update the

...ON(h,l) (((h)<<8) | (l)) + uint32_t realmode_swtch; + uint16_t start_sys; + uint16_t kernel_version; + uint8_t type_of_loader; + uint8_t loadflags; +#define LOADED_HIGH (1<<0) +#define KEEP_SEGMENTS (1<<6) +#define CAN_USE_HEAP (1<<7) + uint16_t setup_move_size; + uint32_t code32_start; + uint32_t ramdisk_image; + uint32_t ramdisk_size; + uint32_t bootsect_kludge; + uint16_t heap_end_ptr; + uint16_t _pad1; + uint32_t cmd_line_ptr; + uint32_t initrd_addr_max; + uint32_t kernel_alignment; + uint8_t relocatable_kernel; + uint8_t _pad2[3]; + uint32_t cmdline_size; + uint32_t hardwa...

...ON(h,l) (((h)<<8) | (l)) + uint32_t realmode_swtch; + uint16_t start_sys; + uint16_t kernel_version; + uint8_t type_of_loader; + uint8_t loadflags; +#define LOADED_HIGH (1<<0) +#define KEEP_SEGMENTS (1<<6) +#define CAN_USE_HEAP (1<<7) + uint16_t setup_move_size; + uint32_t code32_start; + uint32_t ramdisk_image; + uint32_t ramdisk_size; + uint32_t bootsect_kludge; + uint16_t heap_end_ptr; + uint16_t _pad1; + uint32_t cmd_line_ptr; + uint32_t initrd_addr_max; + uint32_t kernel_alignment; + uint8_t relocatable_kernel; + uint8_t _pad2[3]; + uint32_t cmdline_size; + uint32_t hardwa...

...ON(h,l) (((h)<<8) | (l)) + uint32_t realmode_swtch; + uint16_t start_sys; + uint16_t kernel_version; + uint8_t type_of_loader; + uint8_t loadflags; +#define LOADED_HIGH (1<<0) +#define KEEP_SEGMENTS (1<<6) +#define CAN_USE_HEAP (1<<7) + uint16_t setup_move_size; + uint32_t code32_start; + uint32_t ramdisk_image; + uint32_t ramdisk_size; + uint32_t bootsect_kludge; + uint16_t heap_end_ptr; + uint16_t _pad1; + uint32_t cmd_line_ptr; + uint32_t initrd_addr_max; + uint32_t kernel_alignment; + uint8_t relocatable_kernel; + uint8_t _pad2[3]; + uint32_t cmdline_size; + uint32_t hardwa...

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which adds fields to specify the hardware subarchitecture and some

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which

[ This patch depends on the cross-architecture ELF cleanup patch. ] This series updates the boot protocol to 2.07 and uses it to implement paravirtual booting. This allows the bootloader to tell the kernel what kind of hardware/pseudo-hardware environment it's coming up under, and the kernel can use the appropriate boot sequence code. Specifically: - Update the boot protocol to 2.07, which