Debison….or, Debian + Edison

Fingers crossed
I must begin by apologizing for the title of today’s post…I’ve been reading some weird Victorian-style literature and was trying my hand at naming things. Suffice to say it won’t be happening again………anytime soon.

Like I mentioned last time, I’m currently keeping busy with an Intel Edison Breakout for Arduino kit. The thing I needed to do was to get an OS up and running on the board. I’m glad to announce that I’ve succeeded (Igor, he’s alive!!!). Here’s how.
First off, the basic template for getting this done is available here. For some unfathomable reason, when you get to the part titled “Customize Kernel (Optional)”, things get weird. At least they did for me. YMMV. Note that if you simply want Debian on the Edison and are not infact customizing the kernel, then you need not worry about this part. Simply skip to here. If you’re taking the red pill customizing the kernel , step right this way.

First off, take a look at this, specifically points 1 and 2 as they could easily trip you up.
As per the instructions on the page, I ran the “bitbake virtual/kernel –c menuconfig” command, which did give me the kernel configuration screen. I customized the kernel to my heart’s content (I just enabled PPP support as described here) and saved my new kernel .config file. Next, I copied the new .config file over the base version as described and proceeded to rebuild the image. However, when I actually flashed the image to the board, I could find no traces of PPP support in the kernel! After some sleuthing, I theorized that my .config changes were seemingly overwritten with the base version again. That is, I’d made modifications, but when actually invoking a re-build of the image, my custom kernel modifications had been discarded.
Pffff.
After some searching, I found this page on the interweb (start from just below the last picture), stating that kernel modifications could be carried in one of two ways. One way was by overwriting the kernel default configuration (i386_edison_defconfig) in the Yocto Kernel source tree, which was the method the post utilized, which wasn’t working for me. The other method involved overwriting the default kernel configuration right in the Yocto source tree (called defconfig). I used this method instead, but be sure to make a backup first so you can return to a fresh slate if necessary. Next, as stated here (point 3), it is important to run the configure step as: “bitbake virtual/kernel -c configure -f –v” rather than “bitbake virtual/kernel -c configure –v” or the image build process seems to ignore the changes made to the kernel configuration. Once that’s done, everything else was as described in the original post.


This part is absolutely necessary whether or not you customized the kernel.

Once the build completes and you modify and subsequently run the create-debian-image.sh script, you should end up with a flashable Edison image in the /toFlash folder as described. I will now assume you’re currently within the toFlash/ folder.
Alas, its not over quite yet. Next, you actually need to navigate to the parent of the /toFlash folder, which is the /build folder. A simple “cd ..” should do the trick. Next, you should navigate to tmp/deploy/images/edison from the build folder i.e the path you should navigate to is: ………/out/linux64/build/tmp/deploy/images/edison. Within that folder is a file called modules-edison.tgz. For some reason, when the Debian image is created, most of the kernel modules (*.ko) don’t end up in the Edison rootfs image (edison-image-edison.ext4). . They’re actually in this file (modules-edison.tgz). So, you’ll need to find some way of getting them into the rootfs image. The easy way is to download the entire toFlash/ folder, actually flash the Edison, then download this file and extract it right in the root (/) of the filesystem. That way, the necessary files and folders are created (don’t forget to do that as root or using sudo). Once that’s done, run “sudo depmod –a” so that the kernel is aware of the new kernel modules, reboot, and that’s that.
However, a slightly more complicated way would be to mount the Edison rootfs image (edison-image-edison.ext4) on your build machine’s filesystem, extract the modules at the root of the mount point e.g if you mount the rootfs image in/on the /media/ directory, then copy the modules-edison.tgz file there, extract it using “sudo tar –xvzf modules-edison.tgz”, delete the modules-edison.tgz file, run a “sudo sync” (to actually write the filesystem changes to the mounted rootfs) then unmount the rootfs. One advantage to this is that you’ll be flashing a complete image when you finally flash the device. You will still need to run a “sudo depmod –a” though. This is left as an exercise to the reader. As an aside, you can make all manners of customizations using this mount-rootfs image technique……)
Once all of this is done, and you follow the flashing process, you should end up with an Edison running Debian Jessie. The rootfs is rather small though, so you may want to watch what you install in there. I will make my prebuilt (and experimental) (and suitably modified) image available over the next few days, so you should just be able to download and flash it to your device without needing to go through the hassle of building an image or meddling with kernel modules. Just remember to run a “sudo depmod –a” when the board boots the first time.
Next post will talk about compiling mjpg-streamer and MRAA.
*quakes with excitement*

EDIT: Image is up, available here.

Comments

  1. Is not better just to use upstream kernel and distribution?

    ReplyDelete
    Replies
    1. Hello Andy,
      I suppose it is. At the time I was doing this research though, I vaguely recall something about PWM or so still being a work in progress and Bluetooth being unavailable in the Mainline 4.8 kernel. There was also something in the thread about someone having trouble with using external SD cards, so I just opted to use the much older 3.10 based kernel with the Jessie rootfs.
      I should probably look into the progress of the mainline kernel...
      Aaaand I just realized you're the Mainline kernel developer :-)

      Delete

Post a Comment

Popular posts from this blog

Bitbanging SPI on the Raspberry Pi (via spi-gpio)

Getting Started with Logic Analyzers and Pulseview

Enabling SPI1 on the Raspberry Pi B+/Zero/2/3