Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 May 2012 09:24:54 -0400
From:      Eric McCorkle <eric@shadowsun.net>
To:        freebsd-hackers@freebsd.org
Subject:   Re: GSoC Project: EFI on amd64/i386
Message-ID:  <4FB3AAA6.3090708@shadowsun.net>
In-Reply-To: <201205151144.38123.jhb@freebsd.org>
References:  <4FA95960.7090908@shadowsun.net> <BA85B7AA-FEA5-40B0-A15A-B4E000206C59@xcllnt.net> <4FB17B85.9080701@shadowsun.net> <201205151144.38123.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FB3AAA6.3090708>