Some of you may know that I am the author of the Windows Embedded Board Support Package for the BeagleBone development board.

This board comes with a Texas Instruments AM335x Arm Cortex-A8 processor. I developed the BSP as an open source project with all the source code available online. I have had hundreds of downloads when the site was hosted on Codeplex. And now that I moved it to GitHub I continue to receive regular hits (see my previous post).

This made me wonder if it would possible to port Windows Embedded Core to the BeagleBone platform? It seems Microsoft prefers to work with the silicon vendors themselves with this type of endeavor, and obviously so, as who else knows the chips innards better than the creator. Undaunted, I decided to do a bit of research on my own. Here is what I found.

Documentation: The AM335x technical reference manual for the CPU chip is readily available from Texas Instrument’s download site. Be prepared, it over 3000 pages of nitty-gritty detail on every subsystem available on the chip. While doing the Windows Embedded Compact (WEC) BSP port, I found this information to be invaluable.

The Windows IoT Core documentation is another story. Microsoft publishes a lot of really good information on building IoT core images with its IoT Core manufacturing guide. This is good information for customizing images and doing things like adding or removing drivers etc. but it assumes and already developed base BSP. There are a few established BSP’s for the other, already supported, IoT Core platforms and these can be valuable templates to get started. BSP’s of note are the Raspberry Pi, Intel Joule and the Qualcomm DragonBoard 401C. The Joule is not an ARM platform so that leaves it out. The source for DragonBoard’s BSP was not available at the time I was looking. Maybe if you sign an NDA with Qualcomm …but good luck with that. Be aware some BSP’s are only available in compiled form. This means you can uses add and remove drivers but you don’t have access to the actual driver source code. Be warned, most vendors are quite protective of this information and if you ask for it, they will usually give you the runaround. I don’t know how many times I have asked the vendor for BSP information and they will say you have to go to Microsoft. If you ask Microsoft they will say you have to go to the vendor. There is a nasty term for this but I wont use it here. The one BSP that is a good reference and is available in source is the Raspberry Pi. The code is available here.

Boot Code: Windows IoT Core requires EFI start up code. EFI is kind of a universal start up code. You can describe it like a next generation version of U-Boot. UEFI as it is generally known is an open source project, started by Intel to support booting its x86 based products. It was originally designed as a replacement for BIOS which dates back to the original PC days. UEFI is also available for ARM and this is what is used to boot Raspberry Pi. The Raspberry Pi start up code is unique because the ARM A53 core is actually a slave processor of the video core processor. This leads to some weird start up code for the BMC2835 chip. The later generations based on the BMC2839 chip may have changed this a bit.

Can the BeagleBone use UEFI? Absolutely, but I don’t know if anyone has actually done a port. I know the original BeagleBoard (AM3730) does have a UFEI port, and a mater of fact, it is used as one of the reference platform showing how UEFI runs on ARM. Virtually all Linux/Android BeagleBone OS’s boot with U-Boot so you don’t see much interest in a UEFI port.\

Gotcha: So here is the blocker. The TI AM335x interrupt core is a TI design. TI did not use the standard ARM based Intellectual Property (IP) core for the interrupt controller, they decided to do the design themselves. This is not unusual, many vendors that have purchased the full ARM architectural license go their own way for one reason or another. They may have some special peripheral they need to interface to, maybe they felt they could just do it better, maybe the interrupt IP from ARM was not available at the time, or maybe they just did not want to purchase it. Who knows?

But here is the bottom line: Windows IoT Core’s interrupt processing is baked into the core OS code and it assumes the standard ARM’s IP for the interrupt controller. There is no way around this fact that I have found. It would require some fundamental rewiring of the Windows kernel to get this to work and only Microsoft would have the resources needed to do such a port. I see no desire on MS’s part to support a part that is already past its prime in light of the fact there are so many newer, more powerful, parts coming on the market every day.

If anyone knows how to overcome this hurtle please let me know.

In the mean time I am looking another platform as a possible candidate…..stay tuned.