|Boot Console up and running!|
I put the Galileo Gen 2 boot log into a github gist since it's pretty long, but there are some very interesting tidbits in there. First, it's using Grub Legacy as the bootloader! Another place where the PC background shows up. I've usually seen U-Boot being used as bootloader in embedded systems, but for booting Linux on x86 platform, Grub is as good as any, I suppose. The other thing that I found interesting is that there doesn't seem to be a typical PC "BIOS" as we know it. In an embedded system where you don't need to discover hardware, it makes sense to drop some of the legacy features that are not likely to be used. Looking at the Galileo board schematics and the Quark X1000 datasheet, you can see that there's 8MB serial SPI flash (part W25Q64FV) being used as the boot memory. In Quark Datasheet Table 50, it shows reset vector being mapped into "Legacy Bridge" which has support for one SPI serial flash to store boot firmware (section 21.1).
The references to the SPI flash shows up throughout the boot log. Grub bootloader is located there, as well as the Linux kernel image. There are mentions of different elements being signed, though since Galileo supports booting from SD card, I probably wouldn't mess too much with the SPI flash anyway to reduce the risk of possibly bricking the board necessitating finding a JTAG programmer somewhere.
When booting without a SD card, the root filesystem seems to be initramfs loaded into memory, which explains lack of persistence between boots. When booting from the SD card, the ext3 filesystem is loaded allowing changes to persist between boots, including previous sketches automatically being reloaded.
Since Arduino tool allows firmware to be upgraded, I rummaged around the Arduino installation directory and found "sysimage-galileo-1.0.2.cap" file in hardware\tools\x86\bin directory, which is about the right size to fit in 8MB SPI flash. Opening up the file also has some right strings showing up, so that might be a quick way to figure out what exactly is in the different SPI segments.
There's plenty more to poke around, but to show what you can do by having direct access to the underlying Linux, here's a simple shell script version of the Arduino blink example on Galileo Gen 2 board.
It seems like there are faster ways to access GPIOs, but for normal access, the Arduino wrapper seems to use the sysfs gpio interface. We're simply exporting the GPIO pin in question - the arduino pin number to GPIO number was reverse engineered by looking at the g_APinDescription table in x86/variants/galileo_fab_g/variant.cpp file - and setting the value to be 0 or 1, making the LED blink.
We've peeled back one layer of abstraction, but I'm sure there are plenty more layers hiding underneath it all!