On Tue, Nov 20, 2012 at 1:12 PM, H. Peter Anvin <[email protected]> wrote:
> On 11/20/2012 12:55 PM, Yinghai Lu wrote:
>>
>> On Tue, Nov 20, 2012 at 12:44 PM, H. Peter Anvin <[email protected]> wrote:
>>>
>>> I don't see any point in three flags here. Let's stick to one flag; then
>>> it fits in the existing boot_flags field.
>>
>>
>> the magic AA55
>>
>> boot/header.S:boot_flag: .word 0xAA55
>>
>> if change that to other value, would it break existing boot loader?
>> aka old boot loader could boot the new bzImage anymore.
>>
>
> Sorry, I meant loadflags.
>
> This is a read flag and so should be low, bit 1 presumably.
yes.
Field name: loadflags
Type: modify (obligatory)
Offset/size: 0x211/1
Protocol: 2.00+
This field is a bitmask.
Bit 0 (read): LOADED_HIGH
- If 0, the protected-mode code is loaded at 0x10000.
- If 1, the protected-mode code is loaded at 0x100000.
Bit 5 (write): QUIET_FLAG
- If 0, print early messages.
- If 1, suppress early messages.
This requests to the kernel (decompressor and early
kernel) to not write early messages that require
accessing the display hardware directly.
Bit 6 (write): KEEP_SEGMENTS
Protocol: 2.07+
- If 0, reload the segment registers in the 32bit entry point.
- If 1, do not reload the segment registers in the 32bit entry point.
Assume that %cs %ds %ss %es are all set to flat segments with
a base of 0 (or the equivalent for their environment).
Bit 7 (write): CAN_USE_HEAP
Set this bit to 1 to indicate that the value entered in the
heap_end_ptr is valid. If this field is clear, some setup code
functionality will be disabled.
So will have
Bit 1 (read): LOADED_ABOVE_4G
- If 1, code, boot_param, cmdline, ramdisk could be loaded above 4G,
will update the patches accordingly.
>
> On the other hand, the read flags in loadflags has not been modified for a
> very long time, and there is a serious risk that some broken bootloader
> might be doing a full byte comparison.
>
> relocatable_kernel really should have been a flag, but it is now defined as
> a comparison with zero. As such, and in an effort to minimize the growth of
> struct setup_header (it is limited to little over 128 bytes long) I suggest
> we redefine the 16-byte field at offset 0x236 as a new flags field. We
> still only need one flag, though.
>
> Backwards compatibility is so much fun.
yes. try to make it ready for future is fun too.
are you going to have pointer for ext_header ?
--
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/
