[PATCH v2 01/16] x86: Update the bootparam header

Andy Shevchenko andriy.shevchenko at linux.intel.com
Tue Sep 8 16:05:52 CEST 2020


On Tue, Sep 01, 2020 at 04:23:45PM +0800, Bin Meng wrote:
> On Sun, Aug 30, 2020 at 5:42 AM Simon Glass <sjg at chromium.org> wrote:
> >
> > This header is missing a few of the newer features from the specification.
> > Add these as well as a link to the spec. Also use the BIT() macros where
> > appropriate.

> > +/**
> > + * struct setup_header - Information needed by Linux to boot
> > + *
> > + * See https://www.kernel.org/doc/html/latest/x86/boot.html
> 
> Now I am confused. This kernel document says:
> 
> Protocol 2.14 BURNT BY INCORRECT COMMIT
> ae7e1238e68f2a472a125673ab506d49158c1889 (x86/boot: Add ACPI RSDP
> address to setup_header) DO NOT USE!!! ASSUME SAME AS 2.13.

Where did you get this "DO NOT USE!!! ASSUME SAME AS 2.13" from?


> However in U-Boot there was a commit from Andy saying that:
> 
> commit d905aa8a4277e200e11fdf6d73a7c76d0e6f34a4 (<=== U-Boot commit)
> Author: Andy Shevchenko <andriy.shevchenko at linux.intel.com>
> Date:   Fri Sep 13 18:42:00 2019 +0300
> 
>     x86: zImage: Propagate acpi_rsdp_addr to kernel via boot parameters
> 
> ...
> 
>     after upstream got eventually the Linux kernel
> 
>     commit e6e094e053af75cbc164e950814d3d084fb1e698
>     Author: Juergen Gross <jgross at suse.com>
>     Date:   Tue Nov 20 08:25:29 2018 +0100
> 
>         x86/acpi, x86/boot: Take RSDP address from boot params if available
> 
> So there are 2 commits in the Linux kernel that do the same thing, one
> in boot_params, the other one in setup_header?

I think this
384184044981 ("x86/boot: Mostly revert commit ae7e1238e68f2a ("Add ACPI RSDP address to setup_header")")
explains what happened.

> e6e094e053af75cbc164e950814d3d084fb1e698 : x86/acpi, x86/boot: Take
> RSDP address from boot params if available
> ae7e1238e68f2a472a125673ab506d49158c1889 : x86/boot: Add ACPI RSDP
> address to setup_header
> 
> > + */
> >  struct setup_header {
> >         __u8    setup_sects;
> >         __u16   root_flags;
> > @@ -43,15 +48,16 @@ struct setup_header {
> >         __u16   kernel_version;
> >         __u8    type_of_loader;
> >         __u8    loadflags;
> > -#define LOADED_HIGH    (1<<0)
> > -#define QUIET_FLAG     (1<<5)
> > -#define KEEP_SEGMENTS  (1<<6)
> > -#define CAN_USE_HEAP   (1<<7)
> > +#define LOADED_HIGH    BIT(0)
> > +#define KASLR_FLAG     BIT(1)
> > +#define QUIET_FLAG     BIT(5)
> > +#define KEEP_SEGMENTS  BIT(6)          /* Obsolete */
> > +#define CAN_USE_HEAP   BIT(7)
> >         __u16   setup_move_size;
> >         __u32   code32_start;
> >         __u32   ramdisk_image;
> >         __u32   ramdisk_size;
> > -       __u32   bootsect_kludge;
> > +       __u32   bootsect_kludge;        /* Obsolete */
> >         __u16   heap_end_ptr;
> >         __u8    ext_loader_ver;
> >         __u8    ext_loader_type;
> > @@ -59,7 +65,13 @@ struct setup_header {
> >         __u32   initrd_addr_max;
> >         __u32   kernel_alignment;
> >         __u8    relocatable_kernel;
> > -       __u8    _pad2[3];
> > +       u8      min_alignment;
> > +#define XLF_KERNEL_64                  BIT(0)
> > +#define XLF_CAN_BE_LOADED_ABOVE_4G     BIT(1)
> > +#define XLF_EFI_HANDOVER_32            BIT(2)
> > +#define XLF_EFI_HANDOVER_64            BIT(3)
> > +#define XLF_EFI_KEXEC                  BIT(4)
> > +       u16     xloadflags;
> >         __u32   cmdline_size;
> >         __u32   hardware_subarch;
> >         __u64   hardware_subarch_data;
> > @@ -69,6 +81,7 @@ struct setup_header {
> >         __u64   pref_address;
> >         __u32   init_size;
> >         __u32   handover_offset;
> > +       u32     kernel_info_offset;
> >  } __attribute__((packed));
> >
> >  struct sys_desc_table {
> 
> Regards,
> Bin

-- 
With Best Regards,
Andy Shevchenko




More information about the U-Boot mailing list