search for: initrd_addr_max

On Mon, Jul 1, 2013 at 5:54 AM, Matt Fleming <matt at console-pimps.org> wrote: > On Sun, 30 Jun, at 12:56:32PM, Gene Cumm wrote: >> The following changes since commit d44ea657666e3a34d3859fc7262185e24c0b40fe: >> Matt Fleming (1): >> Merge tag 'syslinux-5.11-pre3' into firmware >> >> are available in the git repository at: >> >>

I have updated syslinux in Parted Magic's test version to the 5.10 release. With 4.06 I booted plop like this: LINUX /boot/plpbt/plpbt.bin Now it says /boot/plpbt/plpbt.bin... ok Booting kernel failed: Invalid argument Other "extras" like IPXE, HDT, memtest86+, chntpw, Super Grub Disk, etc... all work with 5.10. Revert to 4.06 and plop works again. Is this a problem with syslinux

...t; > Other "extras" like IPXE, HDT, memtest86+, chntpw, Super Grub Disk, etc... > all work with 5.10. Revert to 4.06 and plop works again. Could you try Syslinux 5.11-pre5? > Is this a problem with syslinux or plop? For some reason, the plpbt.bin file didn't have a valid initrd_addr_max field in its header, for some reason. Which caused the kernel loader to barf. Do you know why this field was zero? How did you build your kernel image? -- Matt Fleming, Intel Open Source Technology Center

The following changes since commit 9d4ab9d6ae3149465368e19334bf8f162cc36051: Matt Fleming (1): load_linux: validate sanity of 'initrd_addr_max' are available in the git repository at: git://github.com/geneC/syslinux.git doc-for-mfleming Gene Cumm (1): doc/ & txt/: Spelling fix doc/syslinux.txt | 5 +++-- txt/syslinux.cfg.txt | 6 +++--- 2 files changed, 6 insertions(+), 5 deletions(-)

...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 hardware_subarch; + uint64_t hardware_subarch_data; +} __attribute__((packed)); + +/* The so-called "zeropage" */ +struct boot_params { + uint8_t _pad0[0x1f1]; /* skip un...

...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 hardware_subarch; + uint64_t hardware_subarch_data; +} __attribute__((packed)); + +/* The so-called "zeropage" */ +struct boot_params { + uint8_t _pad0[0x1f1]; /* skip un...

...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 hardware_subarch; + uint64_t hardware_subarch_data; +} __attribute__((packed)); + +/* The so-called "zeropage" */ +struct boot_params { + uint8_t _pad0[0x1f1]; /* skip un...

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

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