The document discusses the challenges of loading embedded systems from NAND flash memory and proposes a method to build the system on an SD card instead. It highlights the benefits of using an SD card, such as cost savings, ease of recovery, and the ability to update systems easily. Additionally, the document outlines the architecture, processes, and a shell script utility for fusing the boot loader, kernel, and file system onto the SD card.

1. Embedded System on SD
Vincent Chen
Annie Cheng
YuChin Huang
Jason Kung
2013-09-18

2. Motivation
Typically, most embedded systems load system from NAND flash on the target
device. That means the boot loader, kernel and file system are fused on the NAND
flash.
However, in the beginning stage of implementation, the NAND flash is totally empty,
which means, at least, we have to fuse boot loader into the NAND flash, and then
fuse kernel and file system to bring up the system.
To fuse the boot loader into NAND flash is not easy as just copy a file. We have to
use specific tools like chip programmer or JTAG. Some of these tools are
expensive or not easy to get. Users also need to wait patiently while programming
a NAND flash because it takes time. Frequently programming NAND flash also
impacts its endurance due to its physical character. Thus, if we can find a way to
build a system on other external storage device, like SD card, it would be save a lot
of time, cost, and even NAND flash life cycle.

3. Embedded System (boot from NAND)
SD I/F
Boot Loader
CPU
Memory
controller
NAND flash
controller
Kernel
Memory
NAND
File System

4. Embedded System (SD recovery mode)
SD I/F
Boot Loader
SD / SDHC
CPU
Memory
controller
NAND flash
controller
Kernel
Memory
NAND
File System

5. Embedded System (boot from SD)
SD I/F
Boot Loader
SD / SDHC
CPU
Memory
controller
NAND flash
controller
Kernel
Memory
NAND
File System

6. Purpose
- Build the embedded system on SD card
- Loading system from SD card completely without NAND flash support.
- The file system on SD card supports read and write facility.
- Implement a utility to fuse boot loader, kernel and file system to SD card easily.
Replace boot from NAND
Load u-boot
Loader Kernel
Load File system
File system readable / writable











7. Benefits
- System is easy to recover/update
just simply replace the SD card.
- Cost down
NAND/NOR flash become optional, not a necessary component anymore.
It saves BOM cost.
- Product in test stage
Modify/update codes easily.
- Multi-OS in one device
Switch OS among different SD cards.

8. Platform - DMA6410L
- AP: Samsung S3C6410XH-66, 667Mhz
- RAM: mDDR 128MB (64MB * 2)
- Ethernet I/F: DM9000AE
- Display: 4.3” TFT (480*272)
- UART: UART * 1 (for debug)
- SD card I/F: SD card slot * 1

9. How …
To achieve system on SD card, we will face the following issues,
- CPU supports boot from SD card. How does it work?
- An embedded system has three parts: u-boot (boot loader), kernel and file system.
We have to know the exact position in SD card.
- SD card has SDSC (Standard-Capacity), SDHC (High-Capacity) and SDXC
(eXtended-Capacity.) Does all of them can be supported by CPU?
- How to make the boot loader loads kernel and than kernel loads file system
exactly?

10. Boot Loader (u-boot)

11. S3C6410 iROM booting
S3C6410
ARM1176JZF-S
SDRAM
Controller
SDRAM
Booting Device
(SD/MMC Card,
OneNAND, Nand)
Stepping
Stone (8KB)
iROM(BL0)
(32KB)
OM=iROM Boot
HS-MMC
Controller
BL2
Kernel
OneNAND
Controller
D-TCM (16KB)
BL1
(8KB)
File
System
NAND
Controller
GPN[15:13]:Booting
device pin selection
1.iROM supports initial boot up
Initialize system clock, D-TCM,
device specific controller and
booting device.

12. S3C6410 iROM booting
(cont.)
S3C6410
ARM1176JZF-S
SDRAM
Controller
SDRAM
Booting Device
(SD/MMC Card,
OneNAND, Nand)
Stepping
Stone (8KB)
iROM(BL0)
(32KB)
OM=iROM Boot
HS-MMC
Controller
BL2
Kernel
OneNAND
Controller
D-TCM (16KB)
BL1
(8KB)
File
System
NAND
Controller
GPN[15:13]:Booting
device pin selection
2.iROM boot codes can load 8KB of
boot loader to stepping stone.
The 8 KB boot loader is called
BL1.

13. S3C6410 iROM booting
(cont.)
S3C6410
ARM1176JZF-S
SDRAM
Controller
SDRAM
Booting Device
(SD/MMC Card,
OneNAND, Nand)
Stepping
Stone (8KB)
iROM(BL0)
(32KB)
OM=iROM Boot
HS-MMC
Controller
BL2
Kernel
OneNAND
Controller
D-TCM (16KB)
BL1
(8KB)
File
System
NAND
Controller
GPN[15:13]:Booting
device pin selection
3.BL1 can initialize system clock,
UART, and SDRAM for user.
After initializing, BL1 will load the
remaining boot loader called BL2
to SDRAM.

14. S3C6410 iROM booting
(cont.)
S3C6410
ARM1176JZF-S
SDRAM
Controller
SDRAM
Booting Device
(SD/MMC Card,
OneNAND, Nand)
Stepping
Stone (8KB)
iROM(BL0)
(32KB)
OM=iROM Boot
HS-MMC
Controller
BL2
Kernel
OneNAND
Controller
D-TCM (16KB)
BL1
(8KB)
File
System
NAND
Controller
GPN[15:13]:Booting
device pin selection
4.Finally, jump to start address of
BL2. That will make good
environment to use system.

15. SD/SDHC Device Block Assignment
1 Block = 512 bytes
SD/MMC Device
File System
Kernel
BL2
BL1
Signature
Reserved
(4MB)
(256KB)
(8KB)
(512B)
(512B)
8192
512
16
1
1
Last
1 Block = 512 bytes
SDHC Device
File System
Kernel
(4MB)
BL2
(256KB)
8192
512
BL1 Signature
(8KB) (1024B)
16
2
Skipped
(512KB)
1024
Last

16. For Instance …
2 GB SD
4 GB SDHC
2,021,654,528 bytes
3,958,544 blocks
3,965,190,144 bytes
7,744,512 blocks
File System
File System
3,939,822
7,734,766
Kernel
Kernel
8,192 blocks
3,948,014
BL2
BL2
512 blocks
3,948,526
8,192 blocks
7,742,958
512 blocks
7,743,470
BL1
BL1
16 blocks
3,958,542
3,958,544
16 blocks
7,743,486
Last
2 blocks
1 Block = 512 bytes
7,744,488
7,744,512
Last
Skipped
2 blocks
1,024 blocks
1 Block = 512 bytes

17. Screenshot (boot from 2G SD)
2 GB SD
2,021,654,528 bytes
3,958,544 blocks
File System
2GB SD
3,939,822
Kernel
8,192 blocks
3,948,014
BL2
512 blocks
3,948,526
BL1
16 blocks
3,958,542
3,958,544
Last
2 blocks
1 Block = 512 bytes

18. Screenshot (boot from 4G SD)
4 GB SDHC
3,965,190,144 bytes
7,744,512 blocks
File System
4GB SD
7,734,766
Kernel
8,192 blocks
7,742,958
BL2
512 blocks
7,743,470
BL1
16 blocks
7,743,486
7,744,488
7,744,512
Last
Skipped
2 blocks
1,024 blocks
1 Block = 512 bytes

19. smdk6410.h
Bootloaderu-bootincludeconfigssmdk6410.h
/***********************************************************
* Command definition
***********************************************************/
#define CONFIG_COMMANDS
(CONFIG_CMD_DFL
|
CFG_CMD_CACHE
|
CFG_CMD_USB
|
CFG_CMD_REGINFO
|
Add CFG_CMD_MOVINAND
CFG_CMD_LOADS
|
CFG_CMD_LOADB
|
to make u-boot supports
CFG_CMD_ENV
|
movinand (SD/MMC)
CFG_CMD_NAND
|
CFG_CMD_MOVINAND
|
CFG_CMD_RUN
|
CFG_CMD_DATE
|
CFG_CMD_PING
|
CFG_CMD_ELF)
& ~(CFG_CMD_AUTOSCRIPT
|
CFG_CMD_BOOTD
|
CFG_CMD_IMI
|
CFG_CMD_CONSOLE |
0)

20. smdk6410.h
(cont.)
Bootloaderu-bootincludeconfigssmdk6410.h
/* Boot configuration (define only one of next 3) */
//#define CONFIG_BOOT_NOR
// #define CONFIG_BOOT_NAND
Make u-boot boots from
#define CONFIG_BOOT_MOVINAND
movinand
//#define CONFIG_BOOT_ONENAND
//#define CONFIG_BOOT_ONENAND_IROM
#define CONFIG_NAND
//#define CONFIG_ONENAND
#define CONFIG_MOVINAND
//#define CONFIG_MMC
//#define CONFIG_MMC_S3C
//#define CFG_MMC_BASE
//#define CFG_MMC_BASE
1
1
0xff000000
0xf0000000
bootcmd setting
#elif defined(CONFIG_BOOT_MOVINAND)
#define CFG_ENV_IS_IN_MOVINAND
#define CONFIG_BOOTCOMMAND "movi read zImage c0008000;bootm c0008000"

21. movi.h
Bootloaderu-bootincludemovi.h
#if defined(CONFIG_S3C2450) || defined(CONFIG_S3C2416)
#define HSMMC_CHANNEL
1
Define HSMMC_CHANNEL
#else
#define HSMMC_CHANNEL
1
//0-->TF 1--> SD
#endif
/* offset information */
#define PART_UBOOT_OFFSET
#define PART_ZIMAGE_OFFSET
#define PART_ROOTFS_OFFSET
#define PART_EXTRA_OFFSET
/* movinand definitions */
#define MOVI_BLKSIZE
0x0
0x40000
0x440000
0x3200000
512
Offset in movinand (SD card)
**refer page 16
Block size definition
1 block = 512 bytes

22. movi.h
(cont.)
Bootloaderu-bootincludemovi.h
#define
#define
#define
#define
MOVI_LAST_BLKPOS
MOVI_BL1_BLKCNT
MOVI_ENV_BLKCNT
MOVI_BL2_BLKCNT
#define MOVI_ZIMAGE_BLKCNT
#define MOVI_BL2_POS
#define MOVI_ROOTFS_BLKCNT
(MOVI_TOTAL_BLKCNT - (eFUSE_SIZE / MOVI_BLKSIZE))
(SS_SIZE / MOVI_BLKSIZE)
(CFG_ENV_SIZE / MOVI_BLKSIZE)
(((PART_ZIMAGE_OFFSET - PART_UBOOT_OFFSET) /
MOVI_BLKSIZE) - MOVI_ENV_BLKCNT)
((PART_ROOTFS_OFFSET - PART_ZIMAGE_OFFSET) /
MOVI_BLKSIZE)
(MOVI_LAST_BLKPOS - MOVI_BL1_BLKCNT –
MOVI_BL2_BLKCNT - MOVI_ENV_BLKCNT)
8 * 1024 * 1024 / MOVI_BLKSIZE
//(PART_SIZE_ROOTFS / MOVI_BLKSIZE)
According to the formulas above, we can easily calculate the exact position of each
segment.
(you can check the following excel file to get more detailed information.)
**refer page 16

23. hs_mmc.c
Bootloaderu-bootcpus3c64xxhs_mmc.c
int hsmmc_init (void)
{
u32 reg;
uint width;
issue_command(MMC_GO_IDLE_STATE, 0x00, 0, 0);
issue_command(MMC_SEND_EXT_CSD, 0x000001AA, 0, MMC_RSP_R1);
Add this statement to initial
SDHC
/* MMC_SET_BLOCKLEN */
while (!issue_command(MMC_SET_BLOCKLEN, 512, 0, MMC_RSP_R1));
s3c_hsmmc_writew(0xffff, HM_NORINTSTS);
return 0;
}

24. Kernel (zImage)

25. Kernel Configuration

26. Kernel Configuration (cont.)

27. Kernel Configuration (cont.)

28. Kernel Configuration (cont.)

29. Environment Setting - bootcmd
setenv bootcmd “movi read zImage c0008000;bootm c0008000”
**refer page 21

30. File System

31. Environment Setting - bootargs
setenv bootargs “root=/dev/mmcblk0p2 rootfstype=ext3 rootdelay=3 init=/linuxrc
console=ttySAC0,115200”
**set bootargs at smdk6410.h

32. Screenshot
Note: The root file system is pre-built in SD card.

33. Fusing Tool

34. Fusing Tool
To fuse the boot loader (u-boot.bin), kernel (zImage), and file system (rootfs.tar) to
SD card automatically.
sdcard=$1
if [ "$sdcard" = "" ];then
echo " # Usage - ./sd.sh /dev/SDcardDevicename (ex. sd.sh /dev/sdc)"
echo " # prepare the necessary files(zImage,rootfs.tar,uboot.bin
rootfs.tar is a tar.bz2 file)"
echo " # and verify that the device is correct"
exit 0
.
mkdir /mnt1
mount ${sdcard}2 /mnt1
tar -jxvf rootfs.tar -C /mnt1
cp -rap /mnt/rootfs/* /mnt1
umount /mnt1
rm -rf /mnt1

35. How to use the fusing tool
root@Linux:~# ./sd4.sh /dev/sdc
1. Run the shell script “sd4.sh” as root.
2. Assign the block device where the SD card exists (ex. /dev/sdc).
3. The root file system has to be packed as rootfs.tar before running this shell
script.
4. The boot loader (u-boot.bin), kernel (zImage) and the file system (rootfs.tar)
must exist in the same folder.
5. The name of the files u-boot.bin, zImage, and rootfs.tar are fixed, casesensitive.

36. How the shell script works
step
command
1. Check the device user enters exists and make sure it is an SD card.
2. Partition the device (two partitions will be made).
fdisk
3. Format the second partition as ext3.
mkfs.ext3
4. Fuse the first 8k of u-boot.bin to the BL1 area of the SD card.
dd
5. Fuse the u-boot.bin to the BL2 area of he SD card.
(u-boot.bin has to be smaller than 256KB)
dd
6. Fuse the zImage to the kernel area of he SD card.
dd
7. Make a directory named /mnt1 as the mount point
mkdir
8. Mount the second partition (ext3) to the mount point (/mnt1).
mount
9. Extract rootfs.tar to /mnt1
Tar
10. Un-mount the mount point (/mnt1)
umount
11. Delete the mount point (/mnt1)
rm

37. Member Introduction

38. Member Introduction
Name
Education
Background
Tasks of the project
Working
Experience
Vincent Chen
(Team Leader)
Lan Yang Institute of Technology
BS. Electronics Engineering
- Kernel implement:
- MTD support
- MMC/SD card support
- Kernel logo display
- R&D Engineer
(Electric Meters)
- Field Application Engineer
Annie Cheng
Ming Hsin University of Science and
Technology
BS. In Electronic Engineering
- Hardware layout tracing for
SD/SDHC boot
- Documentation
- Senior Validation Engineer
(CPU Electrical / Margining)
- System Validation Test
Engineer
YiChin Huang
Chih Lee Institute of Technology
BS. in Information Management
- U-boot support SDHC
implement
- SD card fusing tool implement
Jason Kung
Texas A&M University - Commerce
MS. In Computer Science
MS. In Management
- U-boot support SD implement
- Kernel, File System
(ext3, readable/writable)on SD
- Field Application Engineer
(ARM Application Processor)
- Product Manager
(ARM Application Processor)

39. Thank You