The XU4 (Odroid) is the device with which I’ve replaced the AMD64 desktop. It’s a size reduction of about 20x. It’s a weight reduction of about 20 pounds. And, it’s an energy reduction of about 20x, plus or minus.
One of the first things I needed to do was to build an image for a USB thumbdrive, as a substitute (for most of the functionality) of the uSD that I normally use with the XU4. The SSD plan of action:
- The XU4 boots from the small DOS partition on the uSD.
- Instead of mounting the rootfs filesystem on the SD, it mounts the one on the USB thumbdrive. This image can be directly copied to an SSD.
In this scenario, booting speed is not enhanced. But, everything else proceeds with SSD speed. The USB thumbdrive image is being used only for image creation and testing purposes. The plan is to create the image, transfer it to a nice, fast, USB3/SATAIII SSD, and then expand it.
All the thumbdrive needs is a partition table and rootfs file partition. To start the process, I plugged the USB thumbdrive into a Linux PC, and launched gparted. With gparted, I created a normal partition table on the drive, as well as one Linux partition formatted to the filesystem type ext4. I pulled the drive out of the slot, and set it aside.
Next, I obtained a uSD that had already been loaded with the XU4 Linux image I’m using. This uSD has two partitions (1 – DOS partition for booting, and 2 – ext4 rootfs filesystem for running). I plugged this uSD into a slot on my FreeBSD powered PC.
I made a copy of the second partition on the uSD (the ext4 rootfs partition) and saved it to a file with the dd utility:
- dd if=/dev/da0s2 of=./partition2.img bs=1M
I unplugged the uSD, and set it aside.
I plugged the thumbdrive back into the FreeBSD powered PC, and copied the just obtained second partition (from the uSD), to the first partition offset on the thumbdrive:
- dd if=./partition2.img of=/dev/da0s1 bs=1M
I unplugged the thumbdrive from the FreeBSD powered PC, and plugged it into the Linux PC. Why switch back and forth between PCs, you ask? Well, I prefer to use FreeBSD, but it doesn’t support ext4 file systems. After insertion, the thumbdrive wanted to be mounted on the Linux PC. I let it mount. I checked the rootfs file system to make sure it was there. I saw it was OK, unplugged the thumbdrive, and set it aside.
I inserted the uSD card into a slot on the Linux PC, and launched gparted. In gparted, I selected the second partition on the uSD (ext4, rootfs) and clicked on the gparted option to change the UUID of the partition. Why? Because the boot.ini in the DOS partition won’t need to be changed, and since the thumbdrive contains the copied ext4 partition (copied from the uSD) – it will already have a UUID that matches the one in the boot.ini boot config file. By changing the UUID on the rootfs (ext4) partition on the uSD, that partition subsequently will NOT be the rootfs file system selected by the kernel, but instead the USB drive’s rootfs will be mounted. All this can be done with no cut-n-paste of UUIDs, but instead just a click to change the UUID of the uSD.
I unmounted and removed the uSD card from the Linux PC.
I inserted the uSD into the uSD slot on the XU4, and the thumbdrive into a USB slot on the XU4, and applied power to the board. The board “booted” from the uSD boot partition, but mounted the USB thumbdrive to use as the rootfs.
It was slow! My thumbdrive (the one selected for test purposes) was an eight year old device, and extremely slow. But, I could navigate the OS, get onto the internet, and so forth. It was not speedy, but I didn’t expect it to be fast. The uSD is (maybe) 5x faster than the old thumbdrive, and THAT’s saying something. The next step is to use “dd” to transfer the thumbdrive image over to the SSD …
To be continued …
Time flies by, and here we are again. The SSD is up and running, and it is FASSSTTTT! (Comparitively speaking, that is).
- SSD Read speed : 157 MB/s
- SSD Write speed : 135 MB/s
These number were obtained by using the “dd” utility to copy a 500 MB file.
I ended up re-creating the partition table and the first partition on the SSD device, in order to make the partition bigger. Then I added a second partition to the same SSD – as an archive data store. I used the “dd” utility to copy the original (partition2.img) thumbdrive rootfs partition into the new SSD’s first partition offset, and then used gparted to increase the size of the filesystem to be fully expanded within the partition. I don’t recommend this as a technique for others to use, but it worked OK for me.
It makes the XU4 seem, in many ways, on par with my AMD64 desktop. I didn’t bother to purchase an enclosure or case for the drives, and opted instead to use USB3/SATAIII adapter cables to connect the drives to ports on the XU4 (one of the USB3 ports, of which the naked XU4 has two).
The drives I used were the least expensive (AFAIK) SSD drives in existence. I wanted to know if they could hold up for awhile. Will they? Dunno, but I’ll post here on any worthy events relative to that issue.
What drives? I’m using a pair of the Kingston SUV400S37 128GB SSD SATA-III drives. Kingston is a well known company, but I am not affiliated with them in any way. The drives were purchased on Amazon for about $40 (each).
Note: The Odroid xU4 SoC/SBC board discussed here was originally purchased from Ameridroid – the american distributor for HardKernel (http:// http://www.hardkernel.com). FreeBSD is a trademark of the FreeBSD foundation, and they are not affiliated with this author or site in any way.
Note: the author does not have a recent, applicable background in circuit building, or battery related issues, so this is presented as the work of a hobbyist, and is not meant for duplication by others. Readers should look elsewhere for design advice and info.