Jeremy Fitzhardinge wrote: > > Just to clarify: > > In my proposal is that we have bzImage structured something like (where > "|" is concatenation, and "()" is a blob containing stuff): > > bzImage = 16-bit setup | ELF file (decompressor, compressed kernel) > > > With the intention that 32-bit only bootloader always loads the ELF file > as-is and just runs it. Aside from the fact that its an ELF file, > there's nothing else about it which really concerns the bootloader, > since once its loaded and running, it does all its own setup. Its not > clear that code32_start really means much in this case, though I guess > it could point to the same place as the ELF file's entrypoint. > It would have to, because of the way code32_start is defined to work. We don't get control again after its use as a hook. > Whereas you're proposing: > > bzImage = 16-bit setup | decompressor | compressed kernel (ELF file) > > > where code32_start points to the decompressor, and some other pointer > points to the compressed kernel data. And your intent is that an > external bootloader could also interpret the compressed kernel image, > and identify what format its in and handle it appropriately from > outside. Right? Correct. > In both cases, it seems to me that we need an extra boot_param pointer > to point to the offset of the payload blob (ELF file in my case, > compressed kernel in yours). Yes? Indeed. -hpa _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
