Introduction
The Linux SD card provided with a Sitara AMx EVM may be re-created from the Sitara Linux SDK. This guide describes the process for creating an SD card which be loaded with all the system collateral needed to boot and run a Linux system on a Sitara EVM. PLEASE READ AND UNDERSTAND THIS ENTIRE ARTICLE BEFORE RUNNING ANY OF THE SCRIPTS DESCRIBED HERE.
How Many Partitions Do I Need?
For AM35x EVM or AM37 EVM
These EVMs utilize 3 partitions. The card will have a small (~70M) bootable DOS partition for system binaries (x-loader, u-boot, uImage), an ext3 partition (~1G) for a Linux root file system, and another ext3 partition for a Linux installer executable and SDK source code. The third partition will take up the remainder of the card space, so if the card is a 2G card the third partition will be about 1G. If it is a 4G card then the third partition will be about 3G.
| Partition Name |
Type
| OS | Contents |
| Boot | FAT32 | Windows/Linux | Out of Box Demo; windows_user.htm |
| File System | EXT3 | Linux | Root File System |
| START_HERE | EXT3 | Linux | SDK Installer; setup.htm |
For AM180x EVM or AM1810 EVM
These EVMs utilize 2 partitions. There is an alternate script which will create a 2 partition card with only the boot and file system partitions. The boot and file system partition are the only ones necessary to boot the system from an SD card. The third partition is optional.
This process involves formatting and partitioning of drives. The user must be careful of the device names passed to the script used in this process. It is very possible to format and destroy the Linux host machine hard drive if the wrong device is passed to the script used here.
Hardware Assumptions
- Linux host machine with available USB ports for an SD card reader (virtual machines work well).
- USB SD card reader
- SD card (at least 4G recommended)
Software Assumptions
- Linux system binaries (x-loader, u-boot, uImage).
- Linux embedded system root filesystem
How to Make 3 Partition SD Card
The following procedures pertain to the following Sitara processors:
- AM35x
- AM37x
Prepare Script
Create a file on the Linux host named mk3PartSDCard. Copy the contents of the script (see below) to this file and save it. See the later section for the contents of the two partition script.
This script requires a single input parameter which must be the device which is connected to the USB card reader. DO NOT RUN THE SCRIPT IF YOU ARE NOT COMPLETELY SURE THAT YOU HAVE ENTERED THE CORRECT DEVICE TO USE. If you specify the device connect to the host machine hard drive instead of the SD card reader, you will destroy the hard drive of your host machine. The next section shows how to figure out which device is connected the SD card and which is connected to the hard drive.
#! /bin/sh
# mk3PartSDCard.sh v0.3
# Licensed under terms of GPLv2
DRIVE=$1
dd if=/dev/zero of=$DRIVE bs=1024 count=1024
SIZE=`fdisk -l $DRIVE | grep Disk | awk '{print $5}'`
echo DISK SIZE - $SIZE bytes
CYLINDERS=`echo $SIZE/255/63/512 | bc`
sfdisk -D -H 255 -S 63 -C $CYLINDERS $DRIVE << EOF
,9,0x0C,*
10,115,,-
126,,,-
EOF
mkfs.vfat -F 32 -n "boot" ${DRIVE}1
umount ${DRIVE}1
mkfs.ext3 -L "rootfs" ${DRIVE}2
umount ${DRIVE}2
mkfs.ext3 -L "START_HERE" ${DRIVE}3
Make the script executable with the following command
user@UbuntuVbox1004:~$ chmod 755 mk3PartSDCard
Examine Linux System
The script requires a single input parameter. This parameter must be the device that is used to connect to the USB SD card reader. The df -hT command can be used to examine the Linux system. See the example below.
user@UbuntuVbox1004:~$ df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/sda1 ext4 19G 16G 2.5G 87% / none devtmpfs 245M 308K 245M 1% /dev none tmpfs 249M 192K 249M 1% /dev/shm none tmpfs 249M 340K 249M 1% /var/run none tmpfs 249M 0 249M 0% /var/lock none tmpfs 249M 0 249M 0% /lib/init/rw /dev/sdb1 vfat 1.9G 4.0K 1.9G 1% /media/00F8-E7F0 user@UbuntuVbox1004:~$
The example above shows the result of the df command on a Linux system which has an SD card reader attach to device /dev/sdb. And the card that is in this reader is a 2G card with a standard Windows FAT formatted single partition. This is typical of an SD card purchased through a retail channel. More importantly to note here is that the Linux host partition (mounted on /) is on /dev/sda1. This indicates that the host machine has a SATA drive on /dev/sda. If the host machine had an older IDE drive, the device would be /dev/hda.
So now we know that the parameter which must be passed to the script is /dev/sdb. And we know that passing /dev/sda to the script would be disasterous. Passing the device associated with the hard drive of the host machine to this script will destroy the host machine hard drive.
Finally, the above details are just an example. Other systems may have hardware located on different devices in the system. Some systems may have more than one card reader. So there may be a card reader on /dev/sdb and another on /dev/sdc. It is also possible to have a system where the host is mounted on an IDE hard drive at /dev/hda and have a USB SD card reader on /dev/sda. In this case it would be proper to pass /dev/sda to the script. In any case, it is up to the user to determine which one to pass to the script.
Passing the device associated with the hard drive of the host machine to this script will destroy the host machine hard drive.
Finally, the above details are just an example. Other systems may have hardware located on different devices in the system. Some systems may have more than one card reader. So there may be a card reader on /dev/sdb and another on /dev/sdc. It is also possible to have a system where the host is mounted on an IDE hard drive at /dev/hda and have a USB SD card reader on /dev/sda. In this case it would be proper to pass /dev/sda to the script. In any case, it is up to the user to determine which one to pass to the script.
Passing the device associated with the hard drive of the host machine to this script will destroy the host machine hard drive.
Run Script
After verifying the correct device that you must send to the script, it is necessary to unmount any directory that is mounted to the device. In the example above, the directory /media/disk is mounted to /dev/sdb1. To unmount run the following command
user@Ubuntu1004:~$ umount /dev/sdb1
The script must be executed with supre-user permissions. In Ubuntu, this is done by pre-pending the command with "sudo". When prompted for a password by sudo, use the password of the user account.
user@Ubuntu1004:~$ sudo ./mk3PartSDCard /dev/sdb
On a successful execution the terminal will look something like the following. The error that may come from sfdisk (as shown below) can be safely ignired.
user@UbuntuVbox1004:~$ sudo ./mk3PartSD /dev/sdb [sudo] password for user: 1024+0 records in 1024+0 records out 1048576 bytes (1.0 MB) copied, 1.53109 s, 685 kB/s Disk /dev/sdb doesn't contain a valid partition table DISK SIZE - 1977614336 bytes Checking that no-one is using this disk right now ... OK Disk /dev/sdb: 240 cylinders, 255 heads, 63 sectors/track sfdisk: ERROR: sector 0 does not have an msdos signature /dev/sdb: unrecognized partition table type Old situation: No partitions found New situation: Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls #blocks Id System /dev/sdb1 * 0+ 8 9- 72261 c W95 FAT32 (LBA) /dev/sdb2 10 124 115 923737+ 83 Linux /dev/sdb3 126 239 114 915705 83 Linux /dev/sdb4 0 - 0 0 0 Empty Successfully wrote the new partition table Re-reading the partition table ... If you created or changed a DOS partition, /dev/foo7, say, then use dd(1) to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1 (See fdisk(8).) mkfs.vfat 3.0.7 (24 Dec 2009) umount: /dev/sdb1: not mounted mke2fs 1.41.11 (14-Mar-2010) Filesystem label=rootfs OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 57856 inodes, 230934 blocks 11546 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=239075328 8 block groups 32768 blocks per group, 32768 fragments per group 7232 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 20 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. umount: /dev/sdb2: not mounted mke2fs 1.41.11 (14-Mar-2010) Filesystem label=START_HERE OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 57232 inodes, 228926 blocks 11446 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=234881024 7 block groups 32768 blocks per group, 32768 fragments per group 8176 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840 Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 27 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.
The script will run until you see the default prompt on the Terminal again. At this point it may be necessary to unmount anything on /dev/sdb
user@Ubuntu1004:~$ umount /dev/sdb1 user@Ubuntu1004:~$ umount /dev/sdb2 user@Ubuntu1004:~$ umount /dev/sdb3
Now physically remove the SD card from the USB SD card reader and re-insert it. Ubuntu will automatically mount the new partitions. Running df -hT should result in the following:
user@Ubuntu1004:~$ df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/sda1 ext4 19G 16G 2.5G 87% / none devtmpfs 245M 360K 245M 1% /dev none tmpfs 249M 252K 249M 1% /dev/shm none tmpfs 249M 340K 249M 1% /var/run none tmpfs 249M 0 249M 0% /var/lock none tmpfs 249M 0 249M 0% /lib/init/rw /dev/sdb1 vfat 70M 512 70M 1% /media/boot /dev/sdb2 ext3 888M 18M 826M 3% /media/rootfs /dev/sdb3 ext3 881M 17M 819M 3% /media/START_HERE user@Ubuntu1004:~$
The boot partion is a bootable partition which (minimally) must contain x-loader (MLO), u-boot.bin and uImage.
The rootfs partition is the root file system for the system.
How to Make 2 Partition SD Card
The following procedures pertain to the following Sitara processors:
- AM180x
- AM1810
An SD card with two partitions can be made using a slightly modified script instead of the one above. Save the script below to a file called mk2PartSDCard. Use it with all of the same procedures and caution in the section above. Again this script is very dangerous if you don't know what you are doing.
After using this script the SD card will have a VFAT partition called "boot" with a size of 70M. A second Linux ext3 partition will be called "rootfs" and will take up the remainder of the card. This script works very well with 2G cards.
#! /bin/sh
# mk2PartSDCard.sh v0.1
# Licensed under terms of GPLv2
DRIVE=$1
dd if=/dev/zero of=$DRIVE bs=1024 count=1024
SIZE=`fdisk -l $DRIVE | grep Disk | awk '{print $5}'`
echo DISK SIZE - $SIZE bytes
CYLINDERS=`echo $SIZE/255/63/512 | bc`
sfdisk -D -H 255 -S 63 -C $CYLINDERS $DRIVE << EOF
,9,0x0C,*
10,114,,,
EOF
mkfs.vfat -F 32 -n "boot" ${DRIVE}1
umount ${DRIVE}1
mkfs.ext3 -L "rootfs" ${DRIVE}2
Copy Bootloaders, Linux Kernel and File System to SD card
After the card has been processed using the procedure above, the system files can be added to the card. Pre-built system files are included with the Sitara SDK. For AM35x/37x EVM's, bootloader and kernel image files can be placed in the boot partition of the SD card. For AM18x/181x EVM's only the kernel image should on the SD card because these boards must get a bootloader (u-boot) already stored in SPI flash. The bootloader and kernel files are typically in a sub-directory of the SDK installation folder called psp/prebuilt-images. The root filesystem is in a tarball in a sub-directory of the SDK installation folder called filesystem. The example below shows these locations for the AM37x SDK.
user@UbuntuVbox1004:~/ti-sdk-am37x-evm-4.0.1.0/filesystem$ ls -l total 10504 -rw-r--r-- 1 user user 10751480 2011-01-26 09:13 base-rootfs-am37x-evm.tar.gz drwxr-xr-x 18 user user 4096 2011-02-07 14:40 SDK_NFS user@UbuntuVbox1004:~/ti-sdk-am37x-evm-4.0.1.0/filesystem$ cd .. user@UbuntuVbox1004:~/ti-sdk-am37x-evm-4.0.1.0$ cd psp/prebuilt-images/ user@UbuntuVbox1004:~/ti-sdk-am37x-evm-4.0.1.0/psp/prebuilt-images$ ls -l total 51168 lrwxrwxrwx 1 user user 40 2011-02-11 16:09 MLO -> MLO-am37x-evm-1.46-psp03.00.01.06.sdk-r0 -rwxr-xr-x 1 user user 20060 2011-01-22 09:30 MLO-am37x-evm-1.46-psp03.00.01.06.sdk-r0 -rwxr-xr-x 1 user user 216572 2011-01-22 09:30 u-boot-am37x-evm-2009.11-psp03.00.01.06.sdk-r0.bin lrwxrwxrwx 1 user user 50 2011-02-11 16:09 u-boot.bin -> u-boot-am37x-evm-2009.11-psp03.00.01.06.sdk-r0.bin lrwxrwxrwx 1 user user 13 2011-02-11 16:09 uImage -> uImage-2.6.32 -rw-r--r-- 1 user user 2409528 2011-01-25 17:12 uImage-2.6.32 -rw-r--r-- 1 user user 49743774 2011-01-25 17:12 vmlinux-2.6.32 user@UbuntuVbox1004:~/ti-sdk-am37x-evm-4.0.1.0/psp/prebuilt-images$
For the AM18x/AM181x EVM, the board always boots u-boot out of SPI flash. Instructions for putting u-boot into SPI flash are here.
For the AM35x/37x EVM, the bootloader files are MLO and u-boot.bin. These two files must be copied to the boot partition of the SD card.
For all EVM's the kernel image is the file uImage. This file should be copied to the boot partition of the SD card.
The root filesystem must placed on the rootfs partition of the SD card. Tarball's containing a root filesystem are available in the SDK under the filesystem directory. There may actually two different tarball's. The example below shows how AM181x SDK contains two root filesystem tarball's. The one labeled with the prefix tisdk- is a tarball of the filesytem that comes with the retail EVM and provides the full out-of-the-boc experience with the Matrix GUI and all of the example apps. The other tarball is a "base" filesytem with no extra apps that can be used as a baseline Linux filesytem.
user@UbuntuVbox1004:~/ti-sdk-am181x-evm-4.0.1.0/filesystem$ ls -l total 75264 -rw-r--r-- 1 user user 11055454 2011-01-26 10:44 base-rootfs-am181x-evm.tar.gz -rw-r--r-- 1 user user 66010750 2011-01-26 10:44 tisdk-rootfs-am181x-evm.tar.gz user@UbuntuVbox1004:~/ti-sdk-am181x-evm-4.0.1.0/filesystem$
It is important to directly un-tar one of these filesystems to the rootfs partition of the SD card. Doing a simple "copy" or "drag-and-drop" of an existing filesystem will not work. This is because the tar command used to create the tarball in the SDK has preserved permissions, soft-links, and device/file nodes that are important in the filesystem. Also, these tarballs will not create a new sub-directory. They are designed to be extracted in place at the SD card rootfs partition. NOTE: You must use the sudo command when untarring the file system to allow creating the device node file correctly.
The best way to do the un-tar is to first change to the /media/rootfs directory (or wherever the card is mounted in the host system). Second, run the tar command that will extract the tarball into the current directory. And lastly, but maybe most important, is to run the sync command a couple of times after the root filesystem has been un-tarred to the SD card. This will flush data and ensure that everything has been written to the card. See the example below.
user@UbuntuVbox1004:~/ti-sdk-am181x-evm-4.0.1.0/filesystem$ cd /media/rootfs user@UbuntuVbox1004:/media/rootfs$ sudo tar -xzvf ~/ti-sdk-am181x-evm-4.0.1.0/filesystem/tisdk-rootfs-am181x-evm.tar.gz .... .... a lot scrolls by if you use the -v switch with tar .... user@UbuntuVbox1004:/media/rootfs$ sync user@UbuntuVbox1004:/media/rootfs$ sync
It is of course possible to put all of this in a script and this can be helpful if you are making more than one SD card. The example below shows a script made for copying system files for the AM37x SDK.
Before running the script the paths inside the script must edited.
Contents of script.
#! /bin/sh # cpSDCard v0.1 export PATH_TO_SDK=<path to SDK containing bootloaders, kernel, and filesystem> export PATH_TO_SDBOOT=<path to boot partition of SD card> export PATH_TO_SDROOTFS=<path to rootfs partition of SD card> cp $PATH_TO_SDK/psp/prebuilt-images/MLO $PATH_TO_SDBOOT cp $PATH_TO_SDK/psp/prebuilt-images/u-boot.bin $PATH_TO_SDBOOT cp $PATH_TO_SDK/psp/prebuilt-images/uImage $PATH_TO_SDBOOT cd $PATH_TO_SDROOTFS tar -xzvf $PATH_TO_SDK/filesystem/tisdk-rootfs-am37x-evm.tar.gz sync sync
Be sure to change the export PATH_TO_SDK... to match the location of the PSP installed within your SDK. Here is an example showing paths to the AM37 SDK and to the mounted SD card.
export PATH_TO_SDK=/home/user/ti-sdk-AM37x-evm-4.0.1.0 export PATH_TO_SDBOOT=/media/boot export PATH_TO_SDROOTFS=/media/rootfs
To run the cpSDCard script use ./cpSDCard in the Terminal.
Let the script run until you see the default prompt in the Terminal again. This will take some time to complete because the "tar" and "sync" commands can take several minutes.
