ALSO READ BLOGS:
This is the third part of my journey to build a vehicular robot using the Intel Edison board. Thus far, I’ve been able to get Debian Jessie running on it. Next, I need to configure WiFi and begin to install relevant packages. Before getting those tasks done, I came across a little problem.
The Intel Edison onboard flash memory is sized at 4GB. The rootfs space allocated in that flash memory is pegged at about 1.5GB, then the space used by the USB Mass Storage functionality is about 768MB, with the rest being apportioned for other purposes. All in all, only about 500MB is free/usable once Debian is installed. While it can be argued that this is not much of an issue, I prefer to have more space initially, then trim things down subsequently.
It is possible to move the root filesystem to external storage (i.e SD card), which offers the advantage of cheap and easy extension of memory, albeit at a slightly slower I/O rate (or that’s what I think anyway). Since my particular use case is not disk I/O intensive, this was acceptable. Thus, I decided to go in this direction first, and then go onto other things subsequently. The base steps to do this were obtained from here. The screenshots are also worth taking a look at.
From a bird’s eye perspective, this is what needed to be done:
- Obtain and format an SD card using the ext4 filesystem
- Transfer the contents of the root filesystem to the SD card
- Reconfigure the bootloader to use the SD card as the root filesystem, rather than the eMMC flash
I recommend reading through all the steps below (especially step 3) before attempting this process. I used the Serial debug connection and an external power supply throughout this process. The former was necessary to get to the bootloader. I don’t think the latter is necessary. Powering the board via the OTG port should work just as well.
I decided on an 8GB SD card and obtained one accordingly. I’m certain larger or smaller sizes could be used, but 8GB was sufficient for my purposes. Most (if not all) SD cards are pre-partitioned and formatted with the FAT32 filesystem. Hence, no further (re)partitioning step is required. All that needs to be done is to reformat the (currently) FAT32 partition as ext4. An easy way of doing this involves using The GParted (GNOME Partition Editor) program. Sadly I didn’t have access to GParted at the time, so I simply decided to use the Edison itself, since basically any Linux box would do just fine (in fact, I’d strongly recommend having one handy for the next step. An Ubuntu LiveCD also works nicely). After placing the SD card into the appropriate slot on the board (it was powered off at the time), I booted the board and got to the shell. I needed to first find out the device name for the SD card as provided by the OS, so I ran a dmesg | grep mmc . Here’s what I got on my computer:
From these lines, it was apparent that the SD card was called /dev/mmcblk1 and the FAT32 partition on the SD card was accordingly called /dev/mmcblk1p1. Armed with this knowledge, I ran sudo mkfs.ext4 /dev/mmcblk1p1. This command would format the SD card partition with the ext4 filesystem. The operation took completed successfully.
Step One, complete.
Next up, I needed to get the rootfs onto the SD card. The link earlier provided outlined the process as thus: mount the Edison-Image-Edison.ext4 image on the local computer, then copy all its contents over to the SD card. Note that the SD card itself must also be mounted somewhere on the local computer as well. Here’s an example of how this can be done:
sudo mkdir /media/rootfs #make a folder named rootfs in the /media folder
sudo mkdir /media/sdcard #make a folder named sdcard in the /media folder
sudo mount Edison-image-edison.ext4 /media/rootfs #mount the rootfs at the /media/rootfs folder
sudo mount /dev/mmcblk1p1 /media/sdcard #mount the SD card at the /media/sdcard folder
sudo cp –a /media/rootfs/* /media/sdcard #copy all the contents of the rootfs to the sd card
sudo sync #ensure the files are actually written to the SD card
sudo umount /media/rootfs #unmount the rootfs
sudo umount /media/sdcard #unmount the SD card
sudo rmdir /media/rootfs #delete the /media/rootfs folder
sudo rmdir /media/sdcard #delete the /media/sdcard folder
Theoretically speaking, it is also possible to copy over the contents of the current Edison rootfs to the SD card. That is, if there are already some files on the Edison’s flash memory such as installed packages or other files, it is technically possible to copy the rootfs to the SD card so that the transition from eMMC to SD card is seamless i.e no lost files, everything is as it was before the migration. All that should be necessary is the mounting of the SD card, then changing the source directory to be copied (in the copy command shown above) to be / rather than the mount directory of the rootfs image (naturally this would be done on the Edison itself, not on another computer). As an added bonus of using an SD card as the rootfs, starting over is as easy as possibly reformatting the SD card, then recopying the rootfs (fresh or prepopulated) into it.
Step Two, complete.
Now, the board’s bootloader needs to be reconfigured to use the rootfs on the SD card, rather than the one currently available in the eMMC flash memory. For this part I relied heavily on the instructions provided in the reference post/link from earlier. The process began from the paragraph starting with “BTRGBControl_...” so it is necessary to refer to it at this point.
In effect, the author was modifying the kernel boot command line (this is done on line 1) to rely on variables – most germane here was the myrootfs variable. This variable contained the name of the rootfs device to be used. Subsequently (line 2) the myrootfs variable was set to ‘/dev/mmcblk1p1’, which (from earlier) is the (now) ext4 partition on the SD card. On line 3, another variable called myrootfs_sdcard was defined, which pointed again to the SD card partition. On line 4, another variable called myrootfs_emmc was defined, which pointed to the eMMC partition on the flash memory designated for the root filesystem, albeit using its UUID (universally unique identifier, which is a value unique to every individual storage device and partition) rather than the devfs name (i.e names like /dev/mmcblk0, etc). While UUIDs are normally unique, I’ve realized that the UUID for the rootfs partition always seems to be 012b3303-34ac-284d-99b4-34e03a2335f4. This can be verified by running sudo blkid in the shell (this is why it’s a good idea to read these steps first before actually starting the process ;-) ), and looking for the partition whose label is “rootfs”. Should your partition UUID be different, then the assignment of the myrootfs_emmc variable should change accordingly to reflect this.
On lines 5 and 6, new commands/scripts were created, which, when executed, would assign the myrootfs variable to either the SD card (line 5) or the eMMC (line 6) then execute a boot. These commands are useful for switching between SD card and eMMC boot if needed. Strictly speaking, the job was done with lines 1 and 2. Lines 3 through 6 are added for purposes of ease and convenience if/when switching between SD card and eMMC boot. Line 7 sets the boot delay to 5 seconds, and line 8 saves the changes made to the bootloader’s variables. The final line triggers a boot from the SD card.
Personally, on lines 3 and 4, I enclosed the arguments (/dev/mmcblk1p1 and PARTUUID=… respectively) in single quotes to match line 2. In addition, you must make sure when entering each of these lines that you have a prompt that reads “boot>” without the quotes. Finally, I personally skipped editing the /etc/fstab file as described in the initial portion of the instructions - it didn’t seem necessary to me, and my /etc/fstab is much sparser than described. This does not seem to have caused any adverse effects whatsoever, but YMMV.
Once the boot completed, running df –h showed that I had 6.4GB of free space, indicating that the rootfs in use was definitely the one on the SD card.
Step Three, complete.
I will then continue onwards from here – configure the WiFi and install relevant packages. The next post will cover all of that.
Until next time!