Jeremy Fitzhardinge wrote:
>
> So the bzImage structure is currently:
>
> 1. old-style boot sector
> 2. old-style boot info, followed by 0xaa55 at the end of the sector
> 3. the HdrS boot param block
> 4. setup.S boot code
> 5. the self-decompressing kernel
>
> If we make 5 actually an ELF file, containing properly formed Ehdr,
> Phdrs (for all the mappings required), and the actual kernel
> decompressor, relocator and compressed kernel data, then it would be
> easy for the Xen domain builder to find that and use it as a basis for
> loading. I think it would just require the bzImage boot param block to
> contain an offset of the start of the ELF file. The contents of the ELF
> file would be in a form where the normal boot code could just jump over
> the ELF headers, directly into the segment data itself.
>
> ie:
>
> 1. old-style boot sector
> 2. old-style boot info, followed by 0xaa55 at the end of the sector
> 3. the HdrS boot param block
> 4. setup.S boot code (jumps directly into 5.3)
> 5. 32-bit self-decompressing kernel:
> 1. Ehdr
> 2. Phdrs for all necessary mappings
> 3. decompressor/relocator .text
> 4. compressed kernel data
>
> Does that sound reasonable?
>
I don't know if that would break any programs that are currently
bypassing the setup. The existing setup protocol definitely allows
invoking an entry point which isn't 0x100000 (rather, the 32-bit
entrypoint is defined by code32_start); I'm not sure how Eric's
relocatable kernel patches (2.05 protocol) affect that, mostly because I
haven't seen any boot loaders which actually use it so I can't comment
on what their code looks like.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
