Flash Sections

In document Openrg Programmer Guide 5.5 LATEST (Page 91-95)

Board Tailoring

6.2 Flash Sections

OpenRG defines the following Flash section types, as depicted in flash_layout.h:

typedef enum {

FLASH_SECT_BOOT = 0, FLASH_SECT_FACTORY = 1, FLASH_SECT_IMAGE = 2, FLASH_SECT_CONF = 3, } flash_section_type_t;

These Flash sections and their uses are described in the following sections.

6.2.1 Boot

The bootstrap and the boot loader share the same section (sectors), and must be written

together. The boot loader and bootstrap object code should be position independent. However, it is possible to avoid Position Independent Code (PIC) restrictions on some platforms. Refer to your Installation Guide for relevant platform-specific information. The bootstrap and boot loader Flash sections can be written at time. Because these sections are not backed up, run-time burning is done only as a last resort and these sections are not normally updated during the remote upgrade procedure.

6.2.2 Bootstrap

The bootstrap is the assembly code responsible for setting up the hardware. For example, it is responsible to set up the DRAM controller, clock settings and MMU settings. Some

architectures do not map Flash memory, making the CPU responsible for copying the bootstrap section to the Flash and running it. Therefore your bootstrap section should not occupy more than 4KB. After hardware initialization, the bootstrap loads the boot loader into the memory and jumps to it (or runs it directly if the Flash is memory-mapped). The boot loader code is written in 'C', so the bootstrap section must prepare the required run-time environment (stack pointer, etc.). On single image systems, the bootstrap also acts as a simple boot loader. Instead of running the boot loader, it loads a pre-defined image to the memory and jumps to it (or runs it directly if the Flash is memory-mapped). In this case, the bootstrap can be a part of the image itself.

6.2.3 Boot Loader

The boot loader is responsible for loading the software image. The boot record counter is used to identify the newest (active) image. The section whose counter has the greatest value is the active one. Before checking the counter's value, the checksum must be checked to verify the validity of the boot record and image. The boot loader then copies the image to the RAM (if needed) and jumps to the beginning of the image. The image Flash offset is passed to the kernel in one of the CPU registers. Some platforms do not have the RAM mapped in Flash memory. In this case, a platform-specific Flash read function should be implemented.

This function will translate Flash read operations with "virtual" Flash addresses to low level platform-dependent operations.

6.2.4 Factory Settings

The factory setting Flash section contains static vendor-specific information, such as MAC addresses or CableHome PS. Factory settings data is stored in a set tree. For more information on factory settings refer to Chapter 8.

6.2.5 Image #1 ... #N

In multi-image architectures, each image section contains information about an image and the image itself. A new image will automatically be loaded to an IMAGE section that has the least counter value. Note that when burning the new image using the flash load command, the target section can be selected manually, as in the following example:

OpenRG> flash load -u tftp://192.168.1.10/openrg.img -s <section's number>

After the image is burnt to the target section, its counter value is increased up to a number that is greater than the value of the previously highest counter by one.

6.2.6 rg_conf #1, #2 ... #N

This section contains the rg_conf settings. To learn more about the rg_conf file, refer to Section 18.1.

6.2.7 Creating a Section for Permanent File Storage Using JFFS2

After installing OpenRG, some platforms have enough space on their Flash memory for file storage. However, it will be difficult to save and manage files on the Flash, as long as it does not contain a file system. You can solve this problem by compiling an OpenRG image with the Journalling Flash File System version 2 (JFFS2). When this OpenRG image is burnt to the Flash, it creates an additional section containing the JFFS2 file system, in which you can permanently store files.

There are two procedures for adding a JFFS2-formatted section to the Flash. The following are guidelines for choosing the most suitable one for your platform:

Use the first procedure only if your distribution is based on Intel IXP425 (and has its own MTD module).

Use the second procedure if your distribution does not have its own MTD module (but uses the generic one instead).

Procedure 1:

1. Add the following string to rg/pkg/build/dist_config.c, under your distribution's section:

token_set("CONFIG_JFFS2_FS", "m");

2. Remove the following string from rg/pkg/build/dist_config.c, under your distribution's section:

token_set("CONFIG_MTD_PHYSMAP", "y");

3. Add the following statement to rg/pkg/build/hw_config.c, under your distribution's section:

if (token_get("CONFIG_JFFS2_FS"))

token_set("CONFIG_IXP425_FLASH_USER_PART", "0x00100000");

/* In this case a 1MB space ("0x00100000") will be defined.*/

4. Define the new section in OpenRG's Flash layout, by adding the "User space" definition with a correct offset address to rg/build/pkg/perm_storage/flash_layout.c:

{

/* User space */

o f f s e t : 0x00F80000 ,

s i z e : 0x00100000 , / * 1MB */

type : FLASH_SECT_USER,

f l a g s : FLASH_SECT_NO_HEADER | FLASH_SECT_WRITE_WARNING, },

5. Format the 'user' partition by creating a file with all bits set to the same size as the 'user' partition. For example, assuming your new partition's size is 640Kb, create the file as follows:

cat /dev/zero | tr '\0' '\377' | dd count=640 bs=1k of=<640Kb_file>

6. Load the file to the 'user' partition, using the load command. For example:

load -u tftp://192.168.1.10/<640Kb_file> -s 7

7. Compile an OpenRG image and burn it to the board, as described at the end of this section.

Procedure 2:

1. Add the following string to rg/pkg/build/dist_config.c, under your distribution's section:

token_set("CONFIG_JFFS2_FS", "m");

2. Add the following string to rg/pkg/build/hw_config.c, under your distribution's section:

token_set_y("CONFIG_ZLIB_DEFLATE");

3. Define the new section in OpenRG's Flash layout, by adding the "User space" definition with a correct offset address to your platform's Flash layout file.

{

/* User space */

offset: 0x00F20000,

size: 0x000A0000, /* 640Kb */

type: FLASH_SECT_USER,

flags: FLASH_SECT_NO_HEADER | FLASH_SECT_WRITE_WARNING, },

The minimum size of this section equals the total size of two physical Flash blocks. For more information about the block size on your Flash, refer to the Flash chip specification document.

Note: The new section's space is created at the expense of one of the Flash sections.

4. When using Linux 2.4:

Add an MTD partition in os/linux-2.4/drivers/mtd/maps/physmap.c. The MTD partition must be of the same size and offset as the 'user' partition on the Flash.

{

Perform the following change in pkg/kernel/linux/boot/rg_prom.c. In function

openrg_commandline_parse(), specify the size@offset for the partition (which must be the same as in your flash layout):

sprintf(cmdline + strlen(cmdline),

"mtdparts=phys_mapped_flash:0x%x@0(%s),0x%lx@0x%p(%s),"

"0xa0000@0xf20000(JFFS2)", CONFIG_MTD_PHYSMAP_LEN, RG_PROD_STR,

Notes:

JFFS2 partitions must have a minimum of 5 erase blocks. For example, if the flash sector size is 128KB, the JFFS2 partition size must be at least 128KB*5=640KB.

The new partition must start and end in the erase block boundaries. For example, if the sector size is 128KB, the flash section start and end offset should be a 128KB multiply.

5. Format the 'user' partition by creating a file with all bits set to the same size as the 'user' partition. For example, assuming your new partition's size is 640Kb, create the file as follows:

cat /dev/zero | tr '\0' '\377' | dd count=640 bs=1k of=<640Kb_file>

6. Load the file to the 'user' partition, using the load command. For example:

load -u tftp://192.168.1.10/<640Kb_file> -s 7

To create an OpenRG image with either of the mentioned configurations, proceed as follows:

1. Clean the distribution:

$ make distclean

2. Reconfigure your development tree:

$ make config DIST=<distribution name in the upper case>

3. Build the new OpenRG image:

$ make

After the image is compiled, burn it to the board's Flash. When booting, OpenRG creates a mnt/jffs2 directory in the new section. This directory is the mount point of JFFS2. After the file system has been mounted, you can save files to the mnt/jffs2 directory.

In document Openrg Programmer Guide 5.5 LATEST (Page 91-95)