Messages in this thread | | | Date | Tue, 20 Nov 2012 16:20:55 -0800 | Subject | Re: [PATCH v2 03/13] x86: Add macro for 64bit entry startup_64 | From | Yinghai Lu <> |
| |
On Tue, Nov 20, 2012 at 1:12 PM, H. Peter Anvin <hpa@zytor.com> wrote: > On 11/20/2012 12:55 PM, Yinghai Lu wrote: >> >> On Tue, Nov 20, 2012 at 12:44 PM, H. Peter Anvin <hpa@zytor.com> 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 ?
| |