Question about OS initialization at UEFI firmware (x86)

Question about OS initialization at UEFI firmware (x86)

[Rafael Machado]

Hi everyone

I was taking a look at how the OS boots after the firmware and bootloader
are done.

To understand this I started to take a look at the linux source code, and
the strange is that I saw some bios legacy interrupts being called.

The flow I checked is this:

void main(void)  -->  linux/arch/x86/boot/main.c
     int detect_memory(void) -->  linux/arch/x86/boot/memory.c
           static int detect_memory_e820(void) -->
linux/arch/x86/boot/memory.c
                   intcall(0x15, &ireg, &oreg) -->
linux/arch/x86/boot/memory.c


At the last call the value of ireg is this one:

ireg.ax  = 0xe820;
ireg.cx  = sizeof buf;
ireg.edx = SMAP;
ireg.di  = (size_t)&buf;


As we can see this is done so the OS knows the memory map, so the OS can do
all its magic.

Finally, my question is:

How could linux, or any other OS, boot on a system with UEFI firmware that
does not have CSM (compatibility support module) ?
I consider that some parts of the hypothetical OS need to be written to
call some UEFI protocols. Am I right ?

Thanks and Regards
Rafael R. Machado

Question about OS initialization at UEFI firmware (x86)

[Rafael Machado]

Hi everyone

I was taking a look at how the OS boots after the firmware and bootloader
are done.

To understand this I started to take a look at the linux source code, and
the strange is that I saw some bios legacy interrupts being called.

The flow I checked is this:

void main(void)  -->  linux/arch/x86/boot/main.c
     int detect_memory(void) -->  linux/arch/x86/boot/memory.c
           static int detect_memory_e820(void) -->
linux/arch/x86/boot/memory.c
                   intcall(0x15, &ireg, &oreg) -->
linux/arch/x86/boot/memory.c


At the last call the value of ireg is this one:

ireg.ax  = 0xe820;
ireg.cx  = sizeof buf;
ireg.edx = SMAP;
ireg.di  = (size_t)&buf;


As we can see this is done so the OS knows the memory map, so the OS can do
all its magic.

Finally, my question is:

How could linux, or any other OS, boot on a system with UEFI firmware that
does not have CSM (compatibility support module) ?
I consider that some parts of the hypothetical OS need to be written to
call some UEFI protocols. Am I right ?

Thanks and Regards
Rafael R. Machado

Re: Question about OS initialization at UEFI firmware (x86)

[Alcantara, Paulo]

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Rafael Machado
> Sent: quinta-feira, 5 de janeiro de 2017 10:00
> To: edk2-devel@lists.01.org
> Subject: [edk2] Question about OS initialization at UEFI firmware (x86)
> 
> Hi everyone
> 
> I was taking a look at how the OS boots after the firmware and bootloader
> are done.
> 
> To understand this I started to take a look at the linux source code, and the
> strange is that I saw some bios legacy interrupts being called.
> 
> The flow I checked is this:
> 
> void main(void)  -->  linux/arch/x86/boot/main.c
>      int detect_memory(void) -->  linux/arch/x86/boot/memory.c
>            static int detect_memory_e820(void) -->
> linux/arch/x86/boot/memory.c
>                    intcall(0x15, &ireg, &oreg) --> linux/arch/x86/boot/memory.c
> 
> 
> At the last call the value of ireg is this one:
> 
> ireg.ax  = 0xe820;
> ireg.cx  = sizeof buf;
> ireg.edx = SMAP;
> ireg.di  = (size_t)&buf;
> 
> 
> As we can see this is done so the OS knows the memory map, so the OS can
> do all its magic.
> 
> Finally, my question is:
> 
> How could linux, or any other OS, boot on a system with UEFI firmware that
> does not have CSM (compatibility support module) ?

The code you pasted above seems to be executed when booting Linux on
PC BIOS firmware. See below.

> I consider that some parts of the hypothetical OS need to be written to call
> some UEFI protocols. Am I right ?

As far as I know, there are currently two ways of booting Linux on
UEFI firmware:

1) The OS loader (bootloader as a PE/COFF image) uses the EFI handover
protocol to boot the Linux kernel image. What the loader does is
basically to find the entry point offset (handover_offset) in that
image and jump to it. The entry point conforms to ABI defined in UEFI
spec.

2) The kernel may be built as PE/COFF binary (UEFI image) so the firmware can
directly boot it at BDS without any external OS loader.

You might want to look at how OVMF boots up Linux through QEMU's command-line parameter "-kernel" by using EFI handover protocol.

-Paulo

Re: Question about OS initialization at UEFI firmware (x86)

[Laszlo Ersek]

On 01/05/17 13:16, Alcantara, Paulo wrote:
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>> Rafael Machado
>> Sent: quinta-feira, 5 de janeiro de 2017 10:00
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] Question about OS initialization at UEFI firmware (x86)
>>
>> Hi everyone
>>
>> I was taking a look at how the OS boots after the firmware and bootloader
>> are done.
>>
>> To understand this I started to take a look at the linux source code, and the
>> strange is that I saw some bios legacy interrupts being called.
>>
>> The flow I checked is this:
>>
>> void main(void)  -->  linux/arch/x86/boot/main.c
>>      int detect_memory(void) -->  linux/arch/x86/boot/memory.c
>>            static int detect_memory_e820(void) -->
>> linux/arch/x86/boot/memory.c
>>                    intcall(0x15, &ireg, &oreg) --> linux/arch/x86/boot/memory.c
>>
>>
>> At the last call the value of ireg is this one:
>>
>> ireg.ax  = 0xe820;
>> ireg.cx  = sizeof buf;
>> ireg.edx = SMAP;
>> ireg.di  = (size_t)&buf;
>>
>>
>> As we can see this is done so the OS knows the memory map, so the OS can
>> do all its magic.
>>
>> Finally, my question is:
>>
>> How could linux, or any other OS, boot on a system with UEFI firmware that
>> does not have CSM (compatibility support module) ?
> 
> The code you pasted above seems to be executed when booting Linux on
> PC BIOS firmware. See below.
> 
>> I consider that some parts of the hypothetical OS need to be written to call
>> some UEFI protocols. Am I right ?
> 
> As far as I know, there are currently two ways of booting Linux on
> UEFI firmware:
> 
> 1) The OS loader (bootloader as a PE/COFF image) uses the EFI handover
> protocol to boot the Linux kernel image. What the loader does is
> basically to find the entry point offset (handover_offset) in that
> image and jump to it. The entry point conforms to ABI defined in UEFI
> spec.
> 
> 2) The kernel may be built as PE/COFF binary (UEFI image) so the firmware can
> directly boot it at BDS without any external OS loader.
> 
> You might want to look at how OVMF boots up Linux through QEMU's command-line parameter "-kernel" by using EFI handover protocol.

See also:

https://lwn.net/Articles/632528/

Re: Question about OS initialization at UEFI firmware (x86)

[Rafael Machado]

Thanks a lot guys.

Now things make sense.

Em qui, 5 de jan de 2017 às 11:18, Laszlo Ersek <lersek@redhat.com>
escreveu:

> On 01/05/17 13:16, Alcantara, Paulo wrote:
> >> -----Original Message-----
> >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> >> Rafael Machado
> >> Sent: quinta-feira, 5 de janeiro de 2017 10:00
> >> To: edk2-devel@lists.01.org
> >> Subject: [edk2] Question about OS initialization at UEFI firmware (x86)
> >>
> >> Hi everyone
> >>
> >> I was taking a look at how the OS boots after the firmware and
> bootloader
> >> are done.
> >>
> >> To understand this I started to take a look at the linux source code,
> and the
> >> strange is that I saw some bios legacy interrupts being called.
> >>
> >> The flow I checked is this:
> >>
> >> void main(void)  -->  linux/arch/x86/boot/main.c
> >>      int detect_memory(void) -->  linux/arch/x86/boot/memory.c
> >>            static int detect_memory_e820(void) -->
> >> linux/arch/x86/boot/memory.c
> >>                    intcall(0x15, &ireg, &oreg) -->
> linux/arch/x86/boot/memory.c
> >>
> >>
> >> At the last call the value of ireg is this one:
> >>
> >> ireg.ax  = 0xe820;
> >> ireg.cx  = sizeof buf;
> >> ireg.edx = SMAP;
> >> ireg.di  = (size_t)&buf;
> >>
> >>
> >> As we can see this is done so the OS knows the memory map, so the OS can
> >> do all its magic.
> >>
> >> Finally, my question is:
> >>
> >> How could linux, or any other OS, boot on a system with UEFI firmware
> that
> >> does not have CSM (compatibility support module) ?
> >
> > The code you pasted above seems to be executed when booting Linux on
> > PC BIOS firmware. See below.
> >
> >> I consider that some parts of the hypothetical OS need to be written to
> call
> >> some UEFI protocols. Am I right ?
> >
> > As far as I know, there are currently two ways of booting Linux on
> > UEFI firmware:
> >
> > 1) The OS loader (bootloader as a PE/COFF image) uses the EFI handover
> > protocol to boot the Linux kernel image. What the loader does is
> > basically to find the entry point offset (handover_offset) in that
> > image and jump to it. The entry point conforms to ABI defined in UEFI
> > spec.
> >
> > 2) The kernel may be built as PE/COFF binary (UEFI image) so the
> firmware can
> > directly boot it at BDS without any external OS loader.
> >
> > You might want to look at how OVMF boots up Linux through QEMU's
> command-line parameter "-kernel" by using EFI handover protocol.
>
> See also:
>
> https://lwn.net/Articles/632528/
>
>