CUDA porting effort?
Given that NVidia is releasing the CUDA platform source on a limited basis, is anyone actively working to port it to FreeBSD? The reason I ask is that to get access to the source, you have to submit a request explaining what you intend to use it for. It might be a good idea to get ahold of the source on behalf of FreeBSD, so that interested people could work on porting it. I could devote a small amount of time to such an effort; I'm wondering if there's interest from anyone else. signature.asc Description: OpenPGP digital signature
GSoC: EFI on intel
I'm assessing possible summer of code projects, and the EFI work caught my attention. I've been running FreeBSD on a macbook for a little under a year now, and booting on EFI is definitely an interest to me. Does anyone know if this is still a viable project proposal? I certainly have the skills to undertake it, I just want to make sure that it stands a chance of actually being selected. signature.asc Description: OpenPGP digital signature
Re: GSoC: EFI on intel
On 04/03/12 13:22, Doug Ambrisko wrote: > EFI is a good task. For generic PC's we need an X64 format. The current > version in FreeBSD is IA32 format. The X64 can boot i386/amd64. > Qemu can be used to test both IA32 and X64 formats. I added some > notes about this on the wiki at: > > http://wiki.freebsd.org/IdeasPage#EFI_support_for_FreeBSD.2BAC8-i386_and_FreeBSD.2BAC8-amd64_.28GSoC.29 > > Qemu is nice since it can runs an UEFI BIOS via the OVMF project > and emulate a DOS file system by pointing qemu to a directory. So > then it is easy to build something, toss it into a directory, start > qemu and test. > > Thanks, > > Doug A. I'm drafting an application right now. I emailed the listed contacts (Rui Paulo and Andrey Elsukov) a moment ago. I've done background research on this already, as part of getting FreeBSD to work on Mac hardware. QEMU caught my attention as a testbed. Also, I found out Apple EFI implementations are non-standard. They specifically look for an HFS+ partition and load a specific file. The workaround is pretty simple, of course: just wrap the boot loader in an HFS+ image and write it to a partition reserved for that purpose. Anyway, if I'm going to propose this, I need to list possible mentors. Skill-wise, I'm well equipped to take it on. I anticipate needing someone who's a committer, preferably with good knowledge of the kernel sources. -- Eric McCorkle Computer Science Ph.D Student e...@shadowsun.net signature.asc Description: OpenPGP digital signature
Re: GSoC: EFI on intel
On 04/03/12 13:22, Doug Ambrisko wrote: > Eric McCorkle writes: > | I'm assessing possible summer of code projects, and the EFI work caught > | my attention. I've been running FreeBSD on a macbook for a little under > | a year now, and booting on EFI is definitely an interest to me. Does > | anyone know if this is still a viable project proposal? I certainly > | have the skills to undertake it, I just want to make sure that it stands > | a chance of actually being selected. > > EFI is a good task. For generic PC's we need an X64 format. The current > version in FreeBSD is IA32 format. The X64 can boot i386/amd64. > Qemu can be used to test both IA32 and X64 formats. I added some > notes about this on the wiki at: > > http://wiki.freebsd.org/IdeasPage#EFI_support_for_FreeBSD.2BAC8-i386_and_FreeBSD.2BAC8-amd64_.28GSoC.29 Based on the feedback I've gotten, I've gone ahead and submitted the proposal. It should be available, and I can edit it up to the 6th. -- Eric McCorkle Computer Science Ph.D Student e...@shadowsun.net signature.asc Description: OpenPGP digital signature
Re: FreeBSD on MacBook
On 05/05/12 23:58, Alfred Zhong wrote: > Hi Dear Hackers, > > I tried to install FreeBSD on my MacBook. Bascially I followed this post > online. > http://www.glenbarber.us/2011/11/12/Dual-Booting-OS-X-and-FreeBSD-9.html > > And the tragedy happened. I do remember, as the post said, typed > gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 3 ada0 > > By the way, I did installed rEFIT on Mac OS > > After rebooting, I see neither my Mac boot option nor the FreeBSD boot > option. Even after holding Option key... > > The only stuff can boot is if I insert a CD (say, the FreeBSD live CD)... > > My installation was successful, but the boot loader was messed up! > > How can I fix this? > It is possible to install on a macbook (I've done it), though the process is a bit more intricate than any of the guides available suggest. Basically, you need to install an MBR and boot in legacy BIOS mode. Apple's EFI implementation does some funny things, and FreeBSD doesn't support EFI on i386 (yet, I'm actually working on adding support). I have a ZFS-only system, laid out as follows: there is an MBR with one partition, containing a BSDlabel. Inside that, there is a swap partition, and a single ZFS instance. When installing, you'll need to use dd to install the first part of zfsboot to the bsdlabel, and the remaining portion to the free space after the ZFS header (there's a guide on how to do that somewhere). -- Eric McCorkle Computer Science Ph.D Student e...@shadowsun.net signature.asc Description: OpenPGP digital signature
GSoC Project: EFI on amd64/i386
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everyone, I'm going to be working on EFI boot support on the amd64/i386 platforms as a GSoC project. The idea is to allow booting from EFI (as opposed to legacy BIOS) on these platforms, so that FreeBSD can continue to support a wide range of hardware as EFI begins to replace BIOS. I'd also like to start a discussion on the matter, since it seems there are several ways that this could be done. Also, I know Rui Paulo was working on this a while back. If anyone knows the approach he was taking, that would be helpful. The way IA-64 handles booting might also be helpful. Here are some specific points to be decided: * An EFI boot service could potentially function similarly to [zfs]loader. Alternatively, it could function like gpt[zfs]boot, though this might require modifying loader(8) since EFI boot services run in protected/long mode, and have different system information table formats. * How much of what EFI provides do we want to use? There are advantages and disadvantages both ways. * How much of the kernel needs to be changed to boot/run from an EFI boot? * It seems possible to support booting from legacy BIOS as well as EFI (install a protective MBR, and gpt[zfs]boot on a FreeBSD boot partition, install the EFI boot loader in a way that the EFI firmware will find it and load it, and the system itself on another partition). Is it worth trying to do this? Feel free to chime in with your opinions on these matters. - -- Eric McCorkle Computer Science Ph.D Student e...@shadowsun.net -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPqVlgAAoJENSCzbQ+koZ7CpYP/27NtM6Vz1069OLjV/+BRUt0 yxW4t8Tl5QXmMUroNAwhnABMKnFG7HAkYxa0twMLudalQVRxCPhyY3bANHQQt6Od mFWDdeeumNLjsOScT577zkFm7mgAdYzP4hO2C5BaxS6ZfWt5WwFm1WGUbY6GuybA jB3dLDLGWyprlxwTJz2cfhrpbVzRfysXzfbccpSVVkYJp9/UcrCh2bpmh7N0S1HC rRCzj8D1yafbjbyKEjOuVnIZMCoh/KFLbsuA2E0GUk2jfyhZKsX8wfFGKZ+53Dle pP8Hks8pOsaQcxy7vwj9Qf22TKnSrCNvUF/m3oNXi2W1DD4byOiNr6VRD2Zo1Ctw hq4mUAb4pe8P8bySjPrLrZWdk6OQuluvcB7g+8kL12EZEWG0QkVDrj7+noOKicqX ntxPAPEMAFt2imzOcrhmNl88qAb+13WDWFHusU+/pxFYJK9rpwCZN9f9gWh5eiW9 HTUiFapKgPkAW5xqU2Fn+LcT1ViBsBO0XHbuvXTVsJJj331OY+56ZgxnszFPhosV l1At9JBcOGJA5+Yq9BaIMv8kN9S617KW9egLEDL1RyhWzdsvpPzILO5moKARLGXo M+3B1PRUMw7a0zHI6mGa7i6ogP5f85Jp/vKlvYK688H9v68rx8sRQs5k9hMkB1JY YxOb+R6NM6AoEMsQ4loE =80fO -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: EFI on amd64/i386
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/10/12 07:45, Marcel Moolenaar wrote: > > On May 8, 2012, at 1:35 PM, Eric McCorkle wrote: > >> Here are some specific points to be decided: >> >> * An EFI boot service could potentially function similarly to >> [zfs]loader. Alternatively, it could function like >> gpt[zfs]boot, though this might require modifying loader(8) since >> EFI boot services run in protected/long mode, and have different >> system information table formats. It seems having the EFI boot service load the kernel directly is the way to go, based on Andrey's reply, the existing code, and my own intuition. I just wanted to ask, in case there was some compelling reason to have the EFI boot service load loader(8) instead. > Now, as for the FreeBSD boot loader: it's currently an EFI > program/image that can be run from within EFI and that uses the > boot- and runtime services to load the FreeBSD kernel from a file > system it knows about in some GPT partition. The loader is stored > in the EFI system partition so that it can be found and run. Sounds good. Also, Apple machines do things a bit differently, but it shouldn't be too much trouble to deal with. The Apple firmware looks for an HFS+ partition, and loads a specific file from it. A simple workaround is just to wrap the EFI boot program in an HFS+ filesystem. I have some half-finished code that does this on my hard drive. Also, the apple firmware starts in graphics (as opposed to text) mode. > >> * How much of what EFI provides do we want to use? There are >> advantages and disadvantages both ways. There are alot of features described in the EFI specification. It might be good to plan to use some of them, either now, or in the future. In particular, I noticed something about signing for boot services and drivers, which seems like it could be a great security feature (though not something I'd do this summer), though I haven't looked closely at it yet. On the other hand, I think it's a good idea to use libstand/libi386 whenever possible, even if it ends up calling through to EFI functions, as it keeps things standardized. >> * How much of the kernel needs to be changed to boot/run from an >> EFI boot? > > The hand-off will be different. In particular, a proper loader will > not load the kernel at some hardcoded address. Instead it will use > EFI's memory allocation routines to get available memory chunks and > load a kernel there. Since the kernel may not occupy a single > contiguous range in physical memory this way, you want the loader > to set up page tables as well. > > Put differently: the current state of affairs is that the EFI > loader we have loads a kernel, but can't boot it. Good to know. Here are some other questions/issues on my mind: If I understand things correctly, boot2 handles the switch to protected mode (as well as enabling A20), both loader(8) and the kernel begin their execution in a protected mode environment. Can I get an absolute confirmation on this? Obviously if this is not the case, then there will need to be another (protected mode) entry point into the kernel. I know some drivers rely on BIOS calls (vga, for instance, and I think some drivers for RAID cards do as well). These might (or might not) need to be modified. > You need to support both anyways. But not at the same time. The > machine either boots BIOS or EFI and depending on that will it use > the EFI loader or use the MBR to load boot code. There's nothing to > try. > > Key is to have a single kernel loadable and bootable by either the > EFI loader or using the "legacy" loader. Yes, I think it's prudent to make it possible for users to boot a given kernel with EFI or legacy BIOS, so that a bug doesn't leave early adopters "stuck" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPsXuEAAoJENSCzbQ+koZ7yaIP/1MGDIUCVN2HR9QOteKxg4U2 YeDZQ/C+s3xG5rnztfY5u5b5o9tEVoQJiBcvk+6+9JRW1cBhEUzAjgWnKDL5QMid RWql/rOPrg2jRhaRYQrh0dN9kkI0Dzdfm+N53Fmf0jat9fn11n5fYVzcA+WnFHTr eQ7IZNKGdJg7zzTC6+cDHz4wRjr+Lozp2Yk5hptsc4Xu3CkHus/7LRIoyfgEEc6r XwvjdBPYv9Jr6XirBFrZHjHNU/XvjUnD+bKyaEAhlUekLE/1J7Ge3oK0dqC3/zNh 5dP2ArQ0Xj91HzG2U8cDQs4SWp4AzIONygq5SdZeX+d78cpMJCzqzmxh3fdW2Aa9 oh40Aulqlj3BfeA7pak0Qe7SmDCi3OaZVI1z/HVbQD8utY4CxFmq7z6lnKBj6Y08 w9TyilE/px4AFy54nhjNke7eRfapu1g1Iz881oOHRtPcwecshTbjQWeBUQzc+3gV zE0L2NwUxUt5eWfw2jyC8bSK/mboMMBXpt4Zd4hBWjYKYcvbfaSSHS5Ys70Nlq30 GHjFphMz4MMpJbCO4ak/fMEJJPCDrDdoIT9QfUglyo3GjwI1BzUQF5iFoHFfqd/o hrcW+hgIVjb/qRT/Yr0qjEumoCnQLMHPcc8ylVVL1wt0qDyUL9XnjPiKRisQ4uqv lLNBhd+3V8SBV8V7sl0J =yyPA -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: EFI on amd64/i386
-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- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: EFI on amd64/i386
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/16/12 01:32, Andrey V. Elsukov wrote: > As i see we already have sys/boot/efi/libefi/efipart.c that uses > EFI BLOCK_IO_PROTOCOL to make "part" devsw. EFI BLOCK_IO_PROTOCOL > provides access to each disk and partition. AFAIK it supports only > GPT and MBR+EBR, so there might be some problems with ZFS support, > because we can use ZFS atop of BSD partition. > I'd need to take a look, but if the efi loaders are not directly calling the EFI_BLOCK_IO_PROTOCOL functions, then it should be easy to implement a layer that understands BSDlabels. IA64 might have a solution. Then again, is a BSDlabel really necessary on a GPT disk? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPtPziAAoJENSCzbQ+koZ7WZwQAKPN80f/I3obnwSNgSeJ9RyJ q14FYshFuOyaiPPm+HsRdJsv82rdOx9AWi5uuBLTjGADHQ7FdVZTk7fIvhSakUHN d6s/FTcxpLopnibNApXXPNla2fHi25qz8c4axd/4XyxoJ1EGIWnXJ3pQ8R/GCNhK olXDocZ+vylO6IW0ta2C4yq2rYFLNCKoR5+Kdoo4B/S+NEguqBCUW/DXTvWqeJw5 GJGzCTDmCKGaOp9LrSQ5jws4XmnqsoBFeL7Zd1Yu40KvS3QyhHpeh1GCZklq3ncG xdGcK4P7/rwrfR3zSf0tHFCbt1o7BJ0XNHL4MrZflbGuQFGvIbdReXNmLi4QDvKS 7QzqsbbtgnL6NrWfJ/Z4UqEZt0dKAj9wZNX5AVP+p2KJomSoV2NPnuuFKAtoiGfe 282daJ4q3D60fxfdo/rExdpA6k2usnxZDCyFM15hhg4jJQDnl32Yj9ym5bbTeDDU Uqoh1Ka/Oj/RtRXHLFdAdL34Jm4RyFgeaRUtVD7o7f5ASCHx0EuFFAh1eZTqFCEi yN1V1+z8FE7va0fQDO7a5S+2O8Hph9K+W8Dxcuq1g/Rg8mBZ8Klny6etWghP6vvR ISiqdMvLkfqqF3eVcB/EY9rLahHr14kabMtSWLRVurVjEPxZ/ju0+9342z3vcY75 xIQe8JfKjuOjkclmpioa =flEs -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: EFI on amd64/i386
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/17/12 10:36, John Baldwin wrote: >> 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. > > They are statically linked at a fixed address. Modules can be > wherever, but the kernel has to be at the physical address it is > linked for (unless you make the kernel relocatable). > Hmm. That would definitely be an issue. Are there any reasons inherent to the way the kernel runs that would prevent that from being done? Alternately, it seems you could set up page tables in the EFI loader, though getting the handoff right would be trick to say the least. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPtR6YAAoJENSCzbQ+koZ7JS4P+wfFfj4U/1OVy4cIyYc39XDt i+LDP1Eq/uSVnVB0Jj58yAMWR0ssrjA4/4DATN/59d5as42o4vN9alf6v+82o8CV mTIiaqynFvTGXaEdZE/tXz1TDshjt5zUMXjoBSMfkrVxHLhTvJNImmk6Zlc5lfQm GJ194X4rhiRK3BRyEWK0sHaGie88GYXcrZBr5iyLvi4MkqS6HnC5rV3ZaXQ4uqz3 po4eHbuIeU88INnL7qGULnGiZzGoTULaFdheDMxU7UtD++kGxpRfhqsCkJ3RbRb6 BxqI70CrKPBp/6CILSsaYqPKzn8Ew5xmG7qoxfBgmqLNOfoSyTsmybGXotRocxlO EQIG0BEcEu51OGAh5eDADBnfNw347cyGwdtr0HI7rPegK4CNedc5uf/OMoHlNz2F 9guzJLkG7Ruk6oIIyP5wn3m5uB1S5mJ0c5jow9Vxfie20TVzzHhZSNn6ipryt8iT FbN/sMReLudVlpEv5aQ2N1Y4YH2lt9Qqbg4h5qpQ6l89mGredGb4jOHJTKFchCLp N9B185r2O5emFV2jS6C/Nkcdqmp69hg/4jxn8aOVR2dmt//gBMy3KYlflLaBSIzQ r0Wzga+a/GOTX90ii1386q7HhQtAb0facBA3A0h0k9fb9BFra2LUO/vkXMLrxqUR +z8kQiLx8O0gFAanF7gN =sSDg -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: GSoC Project: EFI on amd64/i386
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/08/12 13:35, Eric McCorkle wrote: > Hello everyone, > > I'm going to be working on EFI boot support on the amd64/i386 > platforms as a GSoC project. The idea is to allow booting from > EFI (as opposed to legacy BIOS) on these platforms, so that FreeBSD > can continue to support a wide range of hardware as EFI begins to > replace BIOS. ... Just to bring this up, when was the last time anyone actually built the i386 EFI loader? There might be a bit of work to be done to bring it back into a buildable state. There most certainly *is* some work needed to be able to build on amd64. I spent last night poking around, and identified a few things, but I probably shouldn't go any farther until the 21st (or at least until I have a repository) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJPtSADAAoJENSCzbQ+koZ7ydYP/3g6pxpVfRxofDTtLH3MmElW TPMKuTJD4kZqbEjds0u7iXg2uweqUGajMQvOfHi6KXvmKriswrmortrLgMgJCI8P 5HoiS0WDrwRvdL38y5DpzpKZ1rc7RjWS0pEKpPYx3DQh0bps0sb1iAcI8gdPliNL /qRmeLNfiTcaYTOILgPcbWlLnIFYMmg5hmz7zjlIdZYWeBtVdKfrtw6hLCzJqoyz QfL4mzOrBNuXx4jw1yLk3qU7hxsrMkzN3Jm9HOJCb9D/4mDHvF3jmv/o0Jx9hacx Yt9gsYSd/Ot4hOQmB2d9KjOrZMrK5s+JhvknC1sMXz4UD7b6L/AItEpm0OiX1Ls6 2L1Fxob8V0VDZd4JJuZDFWAhqQ6dh9O5mQHrHxTCjEhYIDNPy367L9TdqLtggWN0 EMjVJqfg0XxLRP7vLopax/H6zpd0p8vXUGSxLiKXe4IHWIggPFgaWehslSzgTIu6 2xaETVkaBxt2JXo8ArAyfsvyW6JcZqYp2R2JAUXTNa/PX2Cn9iPFvnsqF7Ir3M5T /cabcrc69fARbRGCtL/vEY0ZHZ33b6K+ACJEmGuamZbDB0Xxe3dgRt+hSWFwjKfq 8+WP7xJ4dfkjICZ/+HXmO9n58myNd2hoBAWQwdG230p55YL2iuqGc2apqnZCsb5o KJVEWBn9VWYBxB/k7yoq =YxYV -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
EFI development tools
I've been working on EFI support for intel platforms. I've managed to build the EFI Development Kit (EDK II) and the IASL compiler for FreeBSD, which raises the possibility of integrating them either as ports, or possibly into the base system. Here is some background: Right now, there is only one EFI program that gets built in the entire system: loader.efi (for IA64, and in the future, i386 and amd64). This is done by building a standard ELF program with a custom linker script which produces code at a base address of 0x1000 (This is a trick to get the effects of compiling for position-independent code, as required by the PE format, as the actual .text section starts at that offset into the file). It then uses objcopy to translate to the PE executable format. I've had some strange behavior in some of the EFI interfaces (notably, ConOut), which smacks of some sort of subtle ABI issue. EDK seems to be made for development on a windows box, with marginal support for Darwing and some Linux distros added as an afterthought. It takes a bit of shoehorning to get it to build and run on FreeBSD, but I did get it to work. However, it would take a nontrivial effort to get it in shape for importation into the base FreeBSD system. It also relies on mingw32 binutils and gcc, as well as python (though it only uses python for build purposes; an effort to import it into the base system would probably remove all the python bits). The IASL compiler comes with a bunch of other ACPI components, some of which may very well be in the base system already. However, the EFI programs I produce using the EDK system work properly, and don't have the same issues as the ones I produce using what's in the base system. As for what to do with EDK and the IASL compiler, there seem to be two possibilities: 1) create ports for them, 2) plan on importing them into the base system. Here's the advantages and disadvantages as I see them: Port advantages: less work, doesn't mess with the base system, less need to change the EDK and IASL compiler sources and build tools, less work to keep up to date with releases Port disadvantages: won't be available for building EFI boot loaders Base system advantages: tools will be available for building boot loaders and other components, easier to maintain compliance with UEFI (EDK is published by Intel, and represents the official EFI toolchain), less likely to run into subtle ABI-related bugs in EFI programs, makes future EFI support efforts (ie on ARM) significantly easier. Base system disadvantages: more work, would require rewriting the build process to avoid dependence on python, gmake, mingw32, and others, adds more to the base system. I'd like to get some discussion/commentary on these options, to figure out which is the best way forward. Thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: EFI development tools
On 06/16/12 06:03, Andrey V. Elsukov wrote: > Hi, Eric. > > Did you try the GNU EFI toolchain? It contains a good descriptions > on how to build EFI application and we probably can use some > suggestions even without importing it. > > http://sourceforge.net/projects/gnu-efi/ > I did. It looks like what's in the base system now was adapted from that. Now that I can build OVMF, I have substantially more ability to figure out what's going wrong with the programs I build using that method. I can also compare the files and assembly coming out of EDK builds to what comes out of the GNU toolchain. I'd be willing to bet it's some sort of subtle ABI issue. There are a couple of very subtle differences between the PE (microsoft) and ELF ABIs. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: EFI development tools
On 6/15/12 6:44 PM, Eric McCorkle wrote:
However, the EFI programs I produce using the EDK system work
properly, and don't have the same issues as the ones I produce using
what's in the base system.
Okay, after a whole lot of slogging, I figured out the root of the
problems I've been seeing, and it needs to be addressed ASAP.
When I compile the following program:
#include
#include
#include
#include
int main() {
printf("%d\n", UINT64);
return 0;
}
as follows:
gcc -o test -O2 -m32 -I${HEAD}/sys/boot/efi/include
-I${HEAD}/sys/boot/efi/include/i386 -I${HEAD}/sys/boot/common test.c
and run it, the output is 4, not 8 as it should be. You can replace
UINT64 with uint64_t and see the same (erroneous) behavior. The -m32
flag seems to be the culprit; removing it fixes the problem.
This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE
were wrong.
In any case, this is a pretty serious error, and someone should try to
reproduce it and take a look at it.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: EFI development tools
On 6/17/12 6:45 PM, Eric McCorkle wrote:
On 6/15/12 6:44 PM, Eric McCorkle wrote:
int main() {
printf("%d\n", UINT64);
return 0;
}
Correction: it should be sizeof(UINT64)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: EFI development tools
On 6/17/12 8:26 PM, Adrian Chadd wrote: Hiya, don't suppose you could file a PR for this? Typing one up just now, after figuring out the root cause. The short version is this: __uint64_t gets defined in as unsigned long. This breaks when you use -m32, in which case sizeof(unsigned long) == 4. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: EFI development tools
On 6/17/12 8:43 PM, Mike Meyer wrote: Eric McCorkle wrote: The -m32 flag seems to be the culprit; removing it fixes the problem. This is why I was having problems, as the offsets in EFI_SYSTEM_TABLE were wrong. In any case, this is a pretty serious error, and someone should try to reproduce it and take a look at it. This is a known issue, and had been around for a long time. You can't reliably build 32 bit binaries (what the -m32 flag specifies) on a 64 bit system. The header files (and possibly other things) are wrong. Doesn't look like anyone has opened a PR for it. I just did. I'll keep that in mind, as I'm working on the 32-bit EFI implementation on a 64-bit machine. In the short term, I'll edit efibind.h (or wherever UINT64 is defined in the efi hierarchy) in my checkout and add a workaround. That should, in theory, hold. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Fwd: UEFI, Qemu and emulating the secure boot interfaces
Received this yesterday, about Linux's plans for supporting secure booting with EFI. I've looked into it as a possibility for FreeBSD, but I won't be in a position to do anything about it for some time. But the possibilities are enticing to say the least. Original Message Subject: UEFI, Qemu and emulating the secure boot interfaces Date: Wed, 27 Jun 2012 21:17:20 +0100 From: Alan Cox To: e...@freebsd.org I'm guessing this will be of some use to you and to the FreeBSD guys http://marc.info/?l=linux-kernel&m=134081867819972 It's a qemu Tianocore environment with the recent stuff including keysigning and "secure" boot. Not sure who else might want pointing at it but hopefully you can bounce it on wherever is useful in the project Alan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Clang, EFI and bad offsets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In the process of the EFI on intel work, I ran across a strange issue. The procedure for creating loader.efi goes something like this: 1) compile to ELF object files 2) generate an ELF executable with -Bsymbolic and a custom linker script that puts everything starting at 0x1000, and also appends some kind of data to the end of symbols (you can find this in sys/boot/i386/efi) 3) use objcopy to convert to PE format (BFD is ia32-efi-app) However, using clang for any of this seems to result in bad jump offsets being generated, which will cause the resulting program to fail. I haven't done a thorough investigation of the issues yet, but I wanted to bring it up to see if anyone has seen something similar, or has any insights. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJP/AsiAAoJENSCzbQ+koZ72N8QAL8zA/0MaHXkLpwTlNiEOZ5m a+73QS2O/uVw/Tsfge/yEcrJdXjGT0YmfmvTEKQPVSmMiZRf8KbG4FQYBKgWTHlO I/Thkw2JRj0iJOlhgp7VyOFpcLHyEdWDsst1D4Y5332j9dEa+JkIqtVTjwefSBbY OcoRkQ9Zznu3vF98BKmn1JTxdKASPMrELs5HMQ3GZop6/FMV8+SBdTFst/gvO1Wg Loe6S2IDMkcaXGYNSBrdqjkJY06wg2oSivlb44/DsSRzQSfKTkSBZ2i3r+LIUv13 cu0XFejjLd2mSPUkSgPGMwTu+PuScGY8Xe8kskJPl+F9NFzxeEdCUbYbpv8HoTJG 3xCXSun5CbkPwfSIfprUS59mAN7sBqWIOzeI5HDeboZv0WL1+7PfUJB27nAINg/D 3MocooMAZHrqsCADlsdgKrodvGp0ccG0vwrfsajho+/69JhNzRbOgllGp2Meqwfy npVBToxVrs7LtcYXkBsyshN3I9GBIjjtR+Ryn5KLCG7xJTvLP0XuYrn4XcNNXjBI ewMRCgUgdlhoS1vPItnmDkYPiIrb5SgowJSZ6Nzd/es7pTdLzRKYXkWzlTNwqY3z TtJLhzebrjfHDArvL2kHvIempyGda+ED4k4W0Ubr8Owzd1WJhRGEhgwVAeJ0hFnO CJOy14wJK32mVr2KFEjG =y2ee -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
