From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4134A817E4 for ; Thu, 5 Jan 2017 05:18:03 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D0554804EF; Thu, 5 Jan 2017 13:18:03 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-100.phx2.redhat.com [10.3.116.100]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v05DI2YF002578; Thu, 5 Jan 2017 08:18:02 -0500 To: "Alcantara, Paulo" , Rafael Machado , "edk2-devel@lists.01.org" References: From: Laszlo Ersek Message-ID: Date: Thu, 5 Jan 2017 14:18:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 05 Jan 2017 13:18:03 +0000 (UTC) Subject: Re: Question about OS initialization at UEFI firmware (x86) X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:18:03 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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/