On 11/20/2012 04:34 PM, Yinghai Lu wrote:
> On Tue, Nov 20, 2012 at 4:32 PM, Yinghai Lu wrote:
>> On Tue, Nov 20, 2012 at 4:28 PM, H. Peter Anvin wrote:
>>> On 11/20/2012 04:20 PM, Yinghai Lu wrote:
> relocatable_kernel really should have been a flag, but it is now defined
> as
On Tue, Nov 20, 2012 at 4:32 PM, Yinghai Lu wrote:
> On Tue, Nov 20, 2012 at 4:28 PM, H. Peter Anvin wrote:
>> On 11/20/2012 04:20 PM, Yinghai Lu wrote:
>>>
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
On Tue, Nov 20, 2012 at 4:28 PM, H. Peter Anvin wrote:
> On 11/20/2012 04:20 PM, Yinghai Lu wrote:
>>
>>> 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 limi
On 11/20/2012 04:20 PM, Yinghai Lu wrote:
>
> 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.
>
No, read the below.
>>
>> On the other hand, the read flags in loadflags has not been
On Tue, Nov 20, 2012 at 1:12 PM, H. Peter Anvin wrote:
> On 11/20/2012 12:55 PM, Yinghai Lu wrote:
>>
>> On Tue, Nov 20, 2012 at 12:44 PM, H. Peter Anvin 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.
>>
>>
>>
On 11/20/2012 12:55 PM, Yinghai Lu wrote:
On Tue, Nov 20, 2012 at 12:44 PM, H. Peter Anvin 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 t
On Tue, Nov 20, 2012 at 12:44 PM, H. Peter Anvin 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 boo
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.
Yinghai Lu wrote:
>On Mon, Nov 19, 2012 at 4:39 PM, Yinghai Lu wrote:
>> On Mon, Nov 19, 2012 at 3:55 PM, H. Peter Anvin
>wrote:
>>> We probably should add a flag for those, but
On Mon, Nov 19, 2012 at 4:39 PM, Yinghai Lu wrote:
> On Mon, Nov 19, 2012 at 3:55 PM, H. Peter Anvin wrote:
>> We probably should add a flag for those, but that is more of a boot_flag...
>
> kernel_cap_bits:
> RAMDISK_ABOVE_4G = (1<<0)
> KERNEL_ABOVE_4G =(1<<2)
> CMD_LINE_ABOVE 4G = (1<<1)
>
On Mon, Nov 19, 2012 at 3:55 PM, H. Peter Anvin wrote:
> We probably should add a flag for those, but that is more of a boot_flag...
kernel_cap_bits:
RAMDISK_ABOVE_4G = (1<<0)
KERNEL_ABOVE_4G =(1<<2)
CMD_LINE_ABOVE 4G = (1<<1)
.long (RAMDISK_ABOVE_4G | CMD_LINE_ABOVE_4G | KERNE
We probably should add a flag for those, but that is more of a boot_flag...
Yinghai Lu wrote:
>On Mon, Nov 19, 2012 at 3:13 PM, H. Peter Anvin wrote:
>> On 11/19/2012 02:53 PM, Yinghai Lu wrote:
>>>
>>> any other field, in header struct field that we can use to tell
>>> bzImage could be used th
On Mon, Nov 19, 2012 at 3:13 PM, H. Peter Anvin wrote:
> On 11/19/2012 02:53 PM, Yinghai Lu wrote:
>>
>> any other field, in header struct field that we can use to tell
>> bzImage could be used that
>> 0x200 directly?
>>
>> hardware_subarch?
>>
>
> There isn't one... this dates back all the way to
On 11/19/2012 02:53 PM, Yinghai Lu wrote:
>>
>> We can't change the 0x200 value, ever, because there are already things
>> that use the 64-bit entry point. As such, these macros and the bzImage
>> fields are pointless; let's not bother and instead document the 0x200 as
>> the permanently fixed add
On Mon, Nov 19, 2012 at 2:42 PM, H. Peter Anvin wrote:
> On 11/17/2012 11:09 PM, Yinghai Lu wrote:
>> We will add one 64bit entry for bzImage in boot header struct.
>>
>> the contents in that field will be offset of startup_64.
>>
>> Add macro for offset of startup_64 to keep two places consistent
On 11/17/2012 11:09 PM, Yinghai Lu wrote:
> We will add one 64bit entry for bzImage in boot header struct.
>
> the contents in that field will be offset of startup_64.
>
> Add macro for offset of startup_64 to keep two places consistent.
>
> Signed-off-by: Yinghai Lu
> Cc: Matt Fleming
> ---
>
We will add one 64bit entry for bzImage in boot header struct.
the contents in that field will be offset of startup_64.
Add macro for offset of startup_64 to keep two places consistent.
Signed-off-by: Yinghai Lu
Cc: Matt Fleming
---
arch/x86/boot/compressed/head_64.S |2 +-
arch/x86/inclu
16 matches
Mail list logo
