[meta-intel] galileo

[Brendan Le Foll]

On 2018-03-11 at 17:10:35 -0400, Trevor Woerner wrote:
> Hi,
> 
> I realize that the Galileo board has been completely abandoned; I'm not
> looking for "official" information, but I'm hoping someone would be willing
> to provide some anecdotal information... perhaps offline?
> 
> I thought it would be a fun exercise to investigate updating the Linux
> image and arduino-IDE-toolchain for my Galileo Gen2 board. Unfortunately
> I've hit some walls and was looking for some ideas.

I hope you have some spare hair to throw away ;-)

> With its LOCKing problem[*1], projects like Yocto and Buildroot are natural
> homes for Galileo support. It looks as though Galileo support was added to
> The Yocto Project somewhere around Dylan [1.4] with
> https://github.com/intel/Galileo-Runtime.git. Using the sub-repositories
> found there and a virtual machine I'm able to build a working toolchain
> which I can install in my Arduino 1.8.5 IDE to build, upload, and run
> Blink. I can also build a rootfs image, but there isn't much in the way of
> guidance on how to get the resulting artifacts cobbled together onto an
> SDcard. But if I leave the SDcard slot empty, I can boot the default flash
> image that was shipped with the board (which is based on Dylan), and the
> IDE and sketches all work[*2].

So the 'firmware' on a galileo board (both versions are the same in this
reguard) - contains both the bios & the OS image in the 8MB SPI. That's
why uclibc was used and a very restraint kernel image. This is what
boots if no uSD card is found. Early 1.4 images for uSD cards where also
uclibc based to be compatible with the mingw/darwin/linux toolchain
embedded in the arduino IDE.

> After Dylan, Galileo-Runtime.git appears to have been abandoned (it's still
> stuck at Dylan) and meta-intel-quark and meta-intel-galileo appear... for
> Daisy [1.6]. Building with these layers (with everything setup for Daisy)
> doesn't work out-of-the-box due to some complaining about circular
> dependencies of initscripts on initscripts. I've tried several different
> things and combinations, but I can't successfully build an image or
> toolchain using these layers. These layers also have Dizzy [1.7] branches,
> so I gave those a whirl too without any success either.

Have a google for "Creating a Yocto image for the Intel® Galileo board
using split layers", the guide I wrote no longer exists on Intel
websites but was mirrored/cached. That should explain how to build for
1.7. Some sources may have moved/deleted so have a look here:
https://iotdk.intel.com/src/. This archive specifically:
https://iotdk.intel.com/src/3.5/galileo/iot-devkit-yp-poky-galileo-20160606.zip

Also just remove all the references to openjdk/java, building that is
another headache.

> After Dizzy, meta-intel-quark and meta-intel-galileo appear to have been
> abandoned and Quark/Galileo support migrated to meta-intel (and was
> subsequently removed after Rocko [2.4]). Along that path, the bootloader
> moved from grub0 to gummiboot to systemd-boot. The out-of-tree binutils
> -mquark-strip-lock patch was upstreamed as the -momit-lock-prefix option.
> The meta-intel layer included wic support making it dead-simple to create
> an SDcard from the build artifacts (yay!). Uclibc support died with Krogoth
> [2.1] (boo). And the suggested kernel for Quark moved from upstream
> linux-3.8 with about two dozen patches, to linux-intel-4.9 (as-is)... and
> this is where I'm stuck.

So on a galileo you need to load the modules required for I/O
manually. They are different on gen1 & gen2. I wasn't involved in that
kernel at all, I could never get the I/O to work personally although I
was told it 'should' - which I take with a large grain of salt.

> In the early days it doesn't seem like there was much distinction between
> Quark and Galileo, they were mostly synonymous. But by the time we get to
> Rocko, we find that the linux-intel kernel has support for Quark, but
> nothing for Galileo. When I boot the factory-installed Dylan image, I find
> loads of stuff under /sys/class/gpio, /sys/class/pwm, and
> /sys/class/platform which are what the Arduino code uses for identification
> and interaction with the Arduino headers. When I run linux-intel[*3] I have
> a /sys/class/gpio that only claims 8 gpios are available for use, none of
> which appear to relate to the Arduino headers. Was the Galileo support
> never "upstreamed"? Not even in Intel's own kernel fork?

The pca953x driver (used only on g2) changed when upstreamed and whilst
it *should* work, the only people I know who use it patch it to look
like the old driver on newer kernels. Others on this list should be able
to provide more info. G1 users GPIO chip/layout is much simpler and
should work out of the box with the cirrus logic but that's my guess.

> With Rocko I can build a bootable image (yay!!) but without proper kernel
> support for Galileo the Arduino code stops quite abruptly when it finds it
> can't find /sys/class/platform/GalileoGen2. At this point I started looking
> at mraa/upm as a replacement for the Arduino libraries, but they have a
> similar problem. When trying to run the "blink_onboard.c" example program
> (the mraa equivalent to Arduino's Blink program) it fails because it wants
> to use GPIO13 and 31, but the kernel says there are only 8 GPIOs available.

So here is what I would do, start from this BSP:
https://github.com/siemens/meta-iot2000

It includes a 4.4 kernel with patches to enable the I/O on something
*very* close to a gen2 galileo:
https://github.com/siemens/meta-iot2000/tree/master/meta-iot2000-bsp/recipes-kernel/linux/patches
This works in mraa. Also mraa is the backend for x86_64 (and maybe x86
totally not sure) for arduino libs now so if you manage to get off the
old galileo toolchain your arduino IDE/code could *just work* (TM).
You might be able to get binary images for those images or debian
binaries somewhere on the siemens site...

Good Luck!
Brendan