From: "Alcantara, Paulo" <paulo.alc.cavalcanti@hp.com>
To: Rafael Machado <rafaelrodrigues.machado@gmail.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: Re: Question about OS initialization at UEFI firmware (x86)
Date: Thu, 5 Jan 2017 12:16:57 +0000 [thread overview]
Message-ID: <CS1PR84MB02304185AD724D0274DC9436AC600@CS1PR84MB0230.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CACgnt7__TmZQMVU4JkZZb47sdmSBK3ej9+7D8d9hXMM0Nq1nsA@mail.gmail.com>
> -----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
next prev parent reply other threads:[~2017-01-05 12:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-05 11:16 Question about OS initialization at UEFI firmware (x86) Rafael Machado
2017-01-05 11:59 ` Rafael Machado
2017-01-05 12:16 ` Alcantara, Paulo [this message]
2017-01-05 13:18 ` Laszlo Ersek
2017-01-07 21:14 ` Rafael Machado
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CS1PR84MB02304185AD724D0274DC9436AC600@CS1PR84MB0230.NAMPRD84.PROD.OUTLOOK.COM \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox