How to Make 3 Partition SD Card

From Texas Instruments Wiki
Jump to: navigation, search

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.



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.