One of the best parts of my job is that I'm continually getting new 'embedded' hardware to play around with in the mail. Over the past couple months I've received three new 'embedded' systems - a Crown Bay, a Jasper Forest, and a Sugar Bay, which taken together actually provide a good representation of the spectrum of machines that Yocto runs on (and that Intel considers 'embedded').
The first board I got up and running Yocto on was the Crown Bay, which is basically an E660 Atom processor with on-chip embedded graphics, coupled with a Top Cliff Platform Controller Hub (PCH). This is what I think of as a typical 'embedded' system - small formfactor, fanless CPU, etc. The on-board graphics is proprietary, which unfortunately forces some ugly (though straightforward and available to anyone) convolutions on the build process, but once built, the result is a nicely-running system with a beautiful graphics display. The BSP for this is pretty much finished and will actually be available as two separate BSPs, one that uses the proprietary graphics code (EMGD) and one that doesn't (using vesa).
The second 'embedded' system I got in the mail was a Jasper Forest system, which is a Xeon C5500 system with Ibex Peak PCH. I put 'embedded' in quotes here because, well, this is not exactly what you expect when you think of an 'embedded' system:
You might think that a system with 2 quad-core CPUs and steampunk dragster pipe fans would preclude a system from being called 'embedded', but not so - these are designed for 'deeply embedded' applications, such as packet processing for VoIP applications, accelerated RAID for storage applications, etc, and relatively speaking are low power consumers for what they do. The BSP for this system is also now in good working condition - the basic system works - X using vesa, networking, etc. With a system like this however, we'd like to go a step further and provide some support to take advantage of the unique capabilities of the platform and so I expect to be adding at least some special packet processing applications from the DPDK (Data Plane Development Kit) and some applications that take advantage of of the special RAID acceleration features of the Jasper Forest.
The third system is a Sugar Bay board, which is a Sandy Bridge DT processor with a Cougar Point PCH. This is pretty much a standard desktop system; I probably should have ordered the Huron River, which is more of a mobile platform and therefore seems more 'embedded' but as we saw with the Jasper Forest, 'embedded' is a relative term. The Sugar Bay should be just fine for the initial integration and it's possible that the same images may 'just work' on a Huron River. I've just started work on this one and already have it booting Yocto (though crashing and burning when starting X, totally as expected), so I don't expect too many headaches, especially considering that unlike the Crown Bay/EMGD, the Sandy Bridge graphics support is already upstream and isn't proprietary in any way. The graphics by the way are supposed to be stunning, so I'm really looking forward to getting this one up and running.
So over the past couple months and as a relative novice to both the hardware and the build system, I've managed to essentially get three new and widely different boards up and running Yocto from scratch (though it helps that they're all essentially the same architecture, I must admit), which I think is a testament to the maturity of the Yocto build system. The initial 80% of getting a new board up actually goes surprisingly quickly - what I've found so far is that most of the rest of the time is spent getting the remaining 20% working. Part of this is that I'm still learning the build system, part is that there's also some ramp-up time getting familiar with the hardware itself and part of it is getting familiar enough with the 20% that isn't working to fix it. I'd expect someone more familiar with the hardware and build system to be able to get new hardware up and running even more quickly. On average, though, I think pretty much anyone should be able to get a new BSP up and running in a relatively short amount of time i.e. if I can do it, anyone can.
In the process of writing these BSPs and as a parallel effort, myself and several other members of the Yocto team have essentially standardized, codified, and revamped the way BSPs are laid out in Yocto, with the goal of not only taking the guesswork out of the mechanics of writing a BSP, but with an eye as well towards making them self-contained enough that they can be useful on their own to several different types of users.
The simplest type of user to cater for in this way would be the user who may have just gotten some new hardware and simply wants to boot the system up and see if/how it works. This type of user could just go to the 'BSP Downloads' section (currently a work-in-progress) of the Yocto website and download the BSP tarball corresponding to the system they have; the BSP tarball for the system will contain a couple images, typically minimal and sdk 'live' images that can be directly burned onto a USB drive and booted.
Another type of user of self-contained BSP tarballs would be the system integrator or developer who doesn't necessarily want to (or can't, for various reasons) set up the full-fledged git-based Yocto development environment and would rather just download the latest Yocto release tarball e.g. 0.90/laverne (or use their own existing modified version of the build system) along with the self-contained BSP tarball for the hardware they're developing for. This type of user as well would download the BSP tarball, which in addition to the binary images mentioned above, would also contain the code for the BSP layer, which could directly be unpacked into their existing Yocto build system, and built as would be the case for any other layer.
For developers using the standard git-based Yocto development environment, the BSP tarballs would be of little use - all the code is available in the public Yocto repositories and can be directly pulled and used to build and modify any BSP.
We should soon have a set of self-contained BSPs matching the last major Yocto release (laverne) including, but not limited to the three platforms mentioned above (e.g. the eMenlow and n450 layers have also been recently converted over to use the new layout) up and available for download - we still need to work through a few logistical and legal questions regarding hosting the BSP binaries.
In the meantime, of course, the code for all the BSPs is and always has been publicly available in the various Yocto repositories, and the BSP Developer's Guide and Kernel Guide contain sections newly updated to match the current layout of the new BSPs - please take a look - input is welcome.