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 -- _______________________________________________ meta-intel mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-intel
