FreeBSD as a platform for UEFI application development?

asteriskRoss

asteriskRoss

I'm developing UEFI applications and have been using Ubuntu GNU/Linux with UDK2010.SR1 and GCC 4.4. I would prefer to be using FreeBSD and Clang. When I first started, I did try adapting UDK2010.SR1 to get it running on FreeBSD, but I didn't find it straightforward and decided the pragmatic approach was to choose a platform that the UDK2010 documentation stated it supported. I see from the FreeBSD wiki page that UEFI development on FreeBSD has moved on a lot. Is FreeBSD now ready as a UEFI development platform? Can anyone confirm that they have UD2010 or UDK2014 configured and running on FreeBSD? Tips/patches would be very welcome.
 
asteriskRoss said:
I see from the FreeBSD wiki page that UEFI development on FreeBSD has moved on a lot. Is FreeBSD now ready as a UEFI development platform?
Click to expand...
I don't think so. We can't even UEFI boot yet so I doubt there's enough to do some development. That said, I'm sure they can use some help getting FreeBSD to UEFI boot.
 
I think the UEFI boot is working, although I'm not sure about the status of secure boot or whether the changes are included on snapshots yet. I do not have a UEFI system that can be used for testing, so have not tried it myself.
 
Thanks for your replies. I should give it another go and see where I get, at least to achieve UEFI application compilation with UDK2010 or UDK2014 (stable releases of the UEFI Development Kit, validated by Intel) and GCC 4.4 or GCC 4.8 respectively on FreeBSD rather than Ubuntu. If I have better success it should be possible to create ports, though I was hoping someone else might already have done the hard work :)

It's not necessary to have a UEFI capable system in order to do UEFI development as emulators/qemu can boot a UEFI BIOS image with something called OVMF. It's not ideal, particularly for development relating to hardware. There is also something called DUET, which is a software layer that provides UEFI services on top of hardware that doesn't support UEFI. I must admit that I have avoided it as I wanted to be debugging my own code rather than DUET's and instead bought myself a shiny new laptop with UEFI BIOS... which of course means that sometimes it is instead the laptop manufacturer's implementation that causes debugging headaches!

Contacting the FreeBSD developers working on UEFI and UEFI Secure Boot is a good idea as I'm sure at the very least a greater variety of hardware to test on is always welcomed. The approach taken on the latter for FreeBSD will be interesting... but that's probably a discussion for another post.
 
I have spent a bit of time trying to set up a UDK2014 build environment on FreeBSD. It is proving as troublesome as I remember. I focused on using GCC 4.8 for native compilation on amd64 (that is, ignoring trying to to get cross-compiling working for the moment). The good news is that the required tools are either part of the base system or available as existing ports. It requires GNU make (devel/gmake), Python 2.7 (lang/python27) and bash (shells/bash). Whilst starting to make changes to the source code, I stumbled upon Bill Paul's notes for compiling OVMF on EDK II, which would have been useful sooner. Unfortunately, UDK2014 requires more work to get up and running than the notes cover, I suspect due to code changes since the notes were written. I haven't yet given up.
 
I now have the UDK2014 building UEFI applications on FreeBSD 9.2 with GCC 4.8 :) After a little more testing and some time reading the porter's handbook I'll try to make it available as a port. The way the filesystem is structured, as a developer you need to insert your project into the development kit directory tree, which feels quite untidy. It would be an ideal candidate for a union file system, but the bugs section of the mount_unionfs(8) man page has put me off that particular idea:
THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK)
AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN
RISK. BEWARE OF DOG. SLIPPERY WHEN WET. BATTERIES NOT INCLUDED.
Click to expand...
 
Having climbed a steep learning curve, I now have beta ports for UDK2014 and the binary OVMF images. Would people be kind enough to have a look at them? UDK2014 has an "interesting" structure. I tried shoehorning it into something sensible but then decided to stick with the existing structure, warts and all. An issue with the UDK2014 port I know about is that it doesn't set the default target or toolchain properly (or indeed at all) depending on the port options. Any steer with that would be much appreciated as conditionals have been causing me quite a bit of angst. It's not a show-stopper but it would be good to get it working before publishing the ports. Thanks in particular to @ljboiler for answering a couple of my posts when I was beginning to despair :)

Edit: Links removed; see later post.
tianocore-ovmf-ia32.tar.gz
tianocore-ovmf-x64.tar.gz
tianocore-udk2014.tar.gz
 
Last edited by a moderator:
wblock@ said:
I think the UEFI boot is working, although I'm not sure about the status of secure boot or whether the changes are included on snapshots yet.
Click to expand...

The latest snapshots indeed include UEFI boot support, and the plan is to merge it back in time for FreeBSD 10.1-RELEASE. There is no support for secure boot right now.
 
asteriskRoss said:
Having climbed a steep learning curve, I now have beta ports for UDK2014 and the binary OVMF images.
Click to expand...

Great - thanks for this. I'll try to have a look at them in the near future.
 
I've fixed the issue with the port options and the latest versions of my proposed ports are available here: Edit: Link removed for tianocore-beta-ports.tar.gz, containing:
Comments and suggestions are very welcome. I plan to submit them formally within the next week and get back to some work that might actually pay the bills ;) I would be particularly interested in anyone who can create a working toolchain with Clang. It should be possible since Clang is used with UDK2014/EDK2 on Mac OS X.

Still on the cards are potentially:
Expressions of interest might hurry me along.
 
Thanks to those who have been in touch. I have found and fixed issues in tools_def.template to include all the information required for GCC v4.9 and v4.10, as well as fixing another hard-coded CXX buried in one of the makefiles. Since these are minor, I haven't published a new tarball for download. I've also started porting UDK2010.SR1.UP1.P1, which is pretty similar but needs some additional patches.
 
Here is [Edit: link removed]my latest version of my proposed tianocore-* ports (tianocore-ports-rc1.tar.gz). Testing and comments continue to be welcome, though note that the maintainer email address isn't yet functional, so please contact me via this forum.

An overview of changes:
  • Restructured documentation directories
  • Further patches for hard-coded makefile references
  • Fixed the packing list
  • Removed ARM and IPF related options
  • Default to lang/gcc
  • Toolchain definition fixes.

I tested out cross-compiling using lang/mingw32-gcc and lang/mingw32-binutils. These aren't working out-of-the-box. GCC 4.6, 4.7 and 4.8 are working for me. GCC 4.9 and 4.10 failed to compile all the packages that form MdeModulePkg. Despite making reference to ARM, UDK2014 appears to be missing some key files so I have removed the related options.
 
You must log in or register to reply here.
Back
Top