The Galileo, which was intended to be an arduino enthusiasts board was really designed to boot Linux and not any other OS. On the SPI flash there is an image of GRUB legacy (https://www.gnu.org/software/grub/grub-legacy.html) which is set up by default to boot a couple "flavors" of the Linux kernel provided by Intel. This GRUB is automatically run by the BIOS on the Galileo firmware when the Galileo boots up.
Each of these images use a ram disk as the root file system and have the ability to mount the micro SD card for additional storage. Notice that this list does not contain "third party" operating systems like Xinu.
Problem #1 - The Galileo board does not and has no intention of ever supporting network booting (BOOTP, PXE, etc). In our previous setup, we had Dell workstation machines which we put a version of GRUB that supported network booting. On startup, this GRUB would contact the DHCP server and boot using BOOTP (https://en.wikipedia.org/wiki/Bootstrap_Protocol). When we wanted to run a new version of Xinu, we just copied the built image to the DHCP server and power-cycled the Dell workstation. On boot, GRUB would pick up the new image, load it, and run it.
When we first started looking into booting Xinu on the Galileo we thought since Xinu supports the multiboot protocol (https://www.gnu.org/software/grub/manual/multiboot/multiboot.html) as does GRUB legacy we could, for experimentation, put the Xinu image on the micro SD card (just like Linux image #2 above) and have the GRUB legacy that exists in the SPI flash boot Xinu right from the SD card. This wouldn't solve the network booting but it would at least allow us to start playing around with Xinu on the Galileo.
Problem #2 - The version of GRUB legacy that is in the SPI flash of the Galileo was changed by Intel to remove a whole bunch of features in order to save space in the SPI flash. One of those features was the multiboot support.
So now we can't boot Xinu directly from the micro SD card since the GRUB that exists in the SPI flash will ONLY boot Linux kernels.
Possible solution to Problem #2 - Rebuild our own GRUB legacy which includes the features we need and load it on the SPI flash. We really wanted to avoid having to change the "stock" SPI image provided by Intel for a couple reasons:
Implemented solution to Problem #2 - While the GRUB legacy does not support multiboot, it does support chainloading (loading another boot loader). So it was suggested that we have the GRUB legacy chainload another version of GRUB which does support the features we need, and along came bootia32.efi. This is an image of GRUB version 2 (https://www.gnu.org/software/grub/manual/grub.html) which the GRUB legacy chainloads and contains support for multiboot.
Now we can boot Xinu provided it is NOT a network boot (see problem #1).
To solve problem #1 we invented the idea of XBoot which we could customize to contain the network driver for the Galileo as well as all the BOOTP logic to read an image from our DHCP server. This is exactly what XBoot does. When Xinu is built for the Galileo there is a script which converts the ELF image generated by the compiler into a direct binary image. We then add a custom XBoot header to the binary image. This is then copied to the DHCP server.
After all of this we are left with the final boot process for Xinu on the Galileo:
include/quark_pdat.h system/quark_pdat.cYou can see how the ethernet driver uses these functions on line 199 of
device/eth/ethinit.cTom wrote a little routine to scan and print this platform data area. Apparently this stuff is in SPI flash, but mapped to memory address 0xFFF10000
PDAT entry id = 1 len = 2 ver = 0 desc = PlatformID data (hex) = 0800 Platform id = 8 PDAT entry id = 6 len = 39 ver = 1 desc = MrcParams data (hex) = 080002000000000000010101000300000200000101017c9200001027000010270000409c000006 PDAT entry id = 3 len = 6 ver = 0 desc = 1st MAC data (hex) = 984fee058571 PDAT entry id = 4 len = 6 ver = 0 desc = 2nd MAC data (hex) = 02ffffffff01So, only 4 entries. I was hoping to find a way to distinguish Gen 2 from Gen 1 Galileo units here. Perhaps the PlatformID value (set to "8" on my Gen 2 Galileo) does the trick, but I don't know because I have yet to see these values documented. In the absence of documentation, the descriptor strings are helpful, but no telling what MrcParams are supposed to be.
git clone https://github.com/01org/Galileo-Runtime.gitAlso the following document (38 page PDF) gives some instructions on how to use the tools and how the platform data is laid out in the SPI flash.
Tom's Computer Info / email@example.com