From owner-freebsd-hackers@FreeBSD.ORG Wed May 16 13:25:01 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96B861065670 for ; Wed, 16 May 2012 13:25:01 +0000 (UTC) (envelope-from eric@shadowsun.net) Received: from mail.atlantawebhost.com (dns1.atlantawebhost.com [66.223.40.39]) by mx1.freebsd.org (Postfix) with ESMTP id 3E58C8FC0A for ; Wed, 16 May 2012 13:25:01 +0000 (UTC) Received: (qmail 32239 invoked from network); 16 May 2012 09:24:55 -0400 Received: from c-71-192-38-198.hsd1.ma.comcast.net (HELO ?192.168.1.9?) (71.192.38.198) by mail.atlantawebhost.com with SMTP; 16 May 2012 09:24:55 -0400 Message-ID: <4FB3AAA6.3090708@shadowsun.net> Date: Wed, 16 May 2012 09:24:54 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120507 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <4FA95960.7090908@shadowsun.net> <4FB17B85.9080701@shadowsun.net> <201205151144.38123.jhb@freebsd.org> In-Reply-To: <201205151144.38123.jhb@freebsd.org> X-Enigmail-Version: 1.5pre Content-Type: multipart/mixed; boundary="------------050608040106050909000000" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: GSoC Project: EFI on amd64/i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 13:25:01 -0000 This is a multi-part message in MIME format. --------------050608040106050909000000 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/15/12 11:44, John Baldwin wrote: > The i386 kernel assumes it starts out with a flat 32-bit mode with > the kernel loaded into a contiguous memory region at a fixed > physical address. If we need a relocatable kernel (as Marcel > hinted at I think), then that adds a fair bit of complication. > > The amd64 kernel assumes it starts in long mode (the bootinfo64.c > bits in the loader setup initial page tables, etc.). I think the > amd64 kernel also has to be loaded into contiguous memory at a > fixed physical address currently. > Seems like an initial workaround could be to allocate a space big enough for all the necessary ELF segments, and split it up ourselves. Do the kernel and modules actually do anything that depends on being in a contiguous space in some way (ie some relocation trick)? Because it seems like it shouldn't really matter otherwise. > Nah, nothing in amd64 calls the BIOS (we don't support VM86). The > only thing I am aware of is the VESA bits but those use an > emulator, they don't let the CPU natively run BIOS routines. i386 > could be adopted to do the same, but it also doesn't make BIOS > calls on modern systems outside of the VESA driver (it used to use > VM86 to probe memory, but now it uses the SMAP passed in by the > loader if it exists and only falls back to VM86 calls if it > doesn't). Yeah, I've seen the x86emu code, when I was trying to track down a suspend/resume problem. The thing I'm wondering is if the BIOS info/code will even be there at all when EFI booting. I suppose the only way to really know is to get the kernel booting and see... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPs6qmAAoJENSCzbQ+koZ7JOUP+QF6XWyiTfiVmWQifzgkZWzi BaOzqeDsQjlMqvf6W8Xb0MzQNWdtqhtEEf3d5528UEWWzcKEji9ra9+CuBQZA3Iv kramgQgC6kSfS8GocTTmoY6VcigTBT4IJpTRRmX2juYV1X5pJe9wSklNh1Cj7/nG azy2eB5lAlAArtGPew7pDPuyiiTFkfZ6Zxcy64g+h/eQ8esJW6n9UN87swHmfcHH u3pX433fbFNOnLihpSzYP97bzZjwHJJZXEmlezOVIvxjoJfZIxeCl7KOwZUh3Q0Z +TbC+++WLGEdmpnDUYhu2/THP776Un/Jpkk4rRo1wPlXFRHv6T9aQJsju1onqG3C KruEUPBTA8TLNid2gY0JPx1MHkTerxMezdr5/6ycEw6Anr4JE5xGT7GKBKiLmxCB 7hZnDcvdqJ3MFVk5gdBuKC608Z96bG0akB2z77ich0f7A78cc6WoSY45ksZMEzt4 8CjDbmPlcLGqNlH29wveIMbE+nUyVc+oOrK3qTlvQPloGpKewEnC3bgYxAMgW2d2 KF1HuIfg9yqtyi8t2W6I1qhY1BufalcNOde8R01lRvCji1tZVbdq/+uydHPyO2Ie uJ99zT1o9Nq4p53+5l1cRjgOLjZnr01h94r35vT/q7Mni6SUZN/rmlLc7pyvxMg5 yS6VWWlwBgUV/UZiQSxn =tWkp -----END PGP SIGNATURE----- --------------050608040106050909000000--