UBootCmdGroupFlash < DULG

%SECTION0{name=UBootCmdGroupFlash}% Flash Memory Commands

%SECTION1{name=UBootCmdFlCp}% cp      - memory copy

%INCLUDE{DULGData_%BOARD%.UBootCpHelp}%

The =cp= command "knows" about flash memory areas and will automatically
invoke the necessary flash programming algorithm when the target area
is in flash memory.

%INCLUDE{DULGData_%BOARD%.UBootCpFlash}%

%X% Writing to flash memory may fail when the target area has not been
erased (see =erase= below), or if it is
write-protected (see =protect= below).

%INCLUDE{DULGData_%BOARD%.UBootCpFlashErrors}%

%X% Remember that the _count_ argument specifies the number of items
to copy. If you have a "length" instead (= byte count) you should use
=cp.b= or you will have to calculate the correct number of items.

%X% If the source address range and the target address range are both in
the same NOR flash device,please use a two step approach intstead:
first copy the data to RAM,then copy from RAM to NOR.

%SECTION1{name=UBootCmdFlFlinfo}% flinfo  - print FLASH memory information

The command =flinfo= (short: =fli=)
can be used to get information about the available flash memory. The
number of flash banks is printed with information about the size and
organization into flash "sectors" or _erase units_.
For all sectors the start addresses are printed; write-protected sectors 
are marked as read-only =(RO)=.
Some configurations of U-Boot also mark empty sectors with an =(E)=.

%INCLUDE{DULGData_%BOARD%.UBootFlinfo}%

%SECTION1{name=UBootCmdErase}% erase   - erase FLASH memory

%INCLUDE{DULGData_%BOARD%.UBootEraseHelp}%

The =erase= command (short: =era=)
is used to erase the contents of one or more sectors of the flash
memory. It is one of the more complex commands; the
=help= output shows this.

Probably the most frequent usage of this command is to pass the
start and end addresses of the area to be erased:

%INCLUDE{DULGData_%BOARD%.UBootEraseStartEnd}%

%X% Note that both the start and end addresses for this command
must point *exactly* at the start resp. end addresses of flash sectors.
Otherwise the command will not be executed.

Another way to select certain areas of the flash memory for the =erase=
command uses the notation of flash _banks_ and _sectors_:

Technically speaking, a _bank_ is an area of
memory implemented by one or more memory chips that are connected to
the same _chip select_ signal of the CPU, and a
flash _sector_ or _erase unit_
is the smallest area that can be erased in one operation.

For practical purposes it is sufficient to remember that with flash
memory a bank is something that eventually may be erased as a whole
in a single operation. This may be more efficient (faster) than
erasing the same area sector by sector.

[It depends on the actual type of flash chips used on the board if
such a fast bank erase algorithm exists, and on the implementation of
the flash device driver if is actually used.]

In U-Boot, flash banks are numbered starting with
=1=, while flash sectors start with
=0=.

To erase the same flash area as specified using start and end
addresses in the example above you could also type:

%INCLUDE{DULGData_%BOARD%.UBootEraseSectors}%

To erase a whole bank of flash memory you can use a command like this one:

%INCLUDE{DULGData_%BOARD%.UBootEraseBank}%

%X% Note that a warning message is printed because some
_write protected_ sectors exist in this flash bank
which were =not= erased.

With the command:

%INCLUDE{DULGData_%BOARD%.UBootEraseAll}%

the whole flash memory (except for the write-protected sectors) can
be erased.

%SECTION1{name=UBootCmdProtect}% protect - enable or disable FLASH write protection

%INCLUDE{DULGData_%BOARD%.UBootProtectHelp}%

The =protect= command is another complex one. It is used to set
certain parts of the flash memory to read-only mode or to make them
writable again. Flash memory that is "protected" (<nop>= read-only)
cannot be written (with the =cp= command) or erased (with the
=erase= command). Protected areas are marked as =(RO)= (for "read-only") in
the output of the =flinfo= command:

%INCLUDE{DULGData_%BOARD%.UBootProtect}%

%X% The actual level of protection depends on the flash chips used on
your hardware, and on the implementation of the flash device driver
for this board. In most cases U-Boot provides just a simple
software-protection, i. e. it prevents you from erasing or overwriting
important stuff by accident (like the U-Boot code itself or U-Boot's
environment variables), but it cannot prevent you from circumventing
these restrictions - a nasty user who is loading and running his own
flash driver code cannot and will not be stopped by this
mechanism. Also, in most cases this protection is only effective while
running U-Boot, i. e. any operating system will not know about
"protected" flash areas and will happily erase these if requested to
do so.

%IF{ "%HAVE_MTDPARTS%" eq "true" }%

%SECTION1{name=UBootCmdFlMtdparts}% mtdparts - define a Linux compatible MTD partition scheme

U-Boot implements two different approaches to define a MTD partition
scheme that can be shared easily with the linux kernel.

The first one is to define a single, static partition in your board
config file, for example:
<verbatim>
#undef CONFIG_JFFS2_CMDLINE
#define CONFIG_JFFS2_DEV               "nor0"
#define CONFIG_JFFS2_PART_SIZE         0xFFFFFFFF     /* use whole device */
#define CONFIG_JFFS2_PART_SIZE         0x00100000     /* use 1MB */
#define CONFIG_JFFS2_PART_OFFSET       0x00000000
</verbatim>
The second method uses the Linux kernel's =mtdparts= command line
option and dynamic partitioning:
<verbatim>
#define CONFIG_CMD_MTDPARTS
#define MTDIDS_DEFAULT      "nor1=zuma-1,nor2=zuma-2"
#define MTDPARTS_DEFAULT   "mtdparts=zuma-1:-(jffs2),zuma-2:-(user)"
</verbatim>
Command line of course produces bigger images, and may be
inappropriate for some targets, so by default it's off.

The =mtdparts= command offers an easy to use and powerful interface to define the contents of the environment variable of the same name that can be passed as boot argument to the Linux kernel:

%INCLUDE{DULGData_%BOARD%.UBootMtdPartsHelp}%

For example, on the %BOARDNAME% target system the =mtdparts= command
display this information:

%INCLUDE{DULGData_%BOARD%.UBootMtdParts}%

The partition table printed here obviously differs from the default value for the =mtdparts= variable printed in the last line. To verify this, we can check the current content of
this variable:
%INCLUDE{DULGData_%BOARD%.UBootMtdPartsPrint}%
and we can see that it exactly matches the partition table printed above.

Then we delete the last 2 partitions ...
%INCLUDE{DULGData_%BOARD%.UBootMtdPartsDelete}%
... and combine the free space into a singe big partition:
%INCLUDE{DULGData_%BOARD%.UBootMtdPartsAdd}%

Now let's switch back to the default settings:
%INCLUDE{DULGData_%BOARD%.UBootMtdPartsDefault}%

%ELSE%
%SECTION1{name=UBootCmdFlMtdparts}% mtdparts - define a Linux compatible MTD partition scheme

#UBootCmdFlMtdparts
U-Boot implements two different approaches to define a MTD partition
scheme that can be shared easily with the linux kernel.

The first one is to define a single, static partition in your board
config file, for example:
<verbatim>
#undef CONFIG_JFFS2_CMDLINE
#define CONFIG_JFFS2_DEV               "nor0"
#define CONFIG_JFFS2_PART_SIZE         0xFFFFFFFF     /* use whole device */
#define CONFIG_JFFS2_PART_SIZE         0x00100000     /* use 1MB */
#define CONFIG_JFFS2_PART_OFFSET       0x00000000
</verbatim>
The second method uses the Linux kernel's =mtdparts= command line
option and dynamic partitioning:
<verbatim>
#define CONFIG_JFFS2_CMDLINE
#define MTDIDS_DEFAULT      "nor1=zuma-1,nor2=zuma-2"
#define MTDPARTS_DEFAULT   "mtdparts=zuma-1:-(jffs2),zuma-2:-(user)"
</verbatim>
Command line of course produces bigger images, and may be
inappropriate for some targets, so by default it's off.

The =mtdparts= command offers an easy to use and powerful interface to define the contents of the environment variable of the same name that can be passed as boot argument to the Linux kernel:
<verbatim>
=> help mtdparts
mtdparts 
    - list partition table
mtdparts delall
    - delete all partitions
mtdparts del part-id
    - delete partition (e.g. part-id = nand0,1)
mtdparts add <mtd-dev> <size>[@<offset>] [<name>] [ro]
    - add partition
mtdparts default
    - reset partition table to defaults

-----

this command uses three environment variables:

'partition' - keeps current partition identifier

partition  := <part-id>
<part-id>  := <dev-id>,part_num

'mtdids' - linux kernel mtd device id <-> u-boot device id mapping

mtdids=<idmap>[,<idmap>,...]

<idmap>    := <dev-id>=<mtd-id>
<dev-id>   := 'nand'|'nor'<dev-num>
<dev-num>  := mtd device number, 0...
<mtd-id>   := unique device tag used by linux kernel to find mtd device (mtd->name)

'mtdparts' - partition list

mtdparts=mtdparts=<mtd-def>[;<mtd-def>...]

<mtd-def>  := <mtd-id>:<part-def>[,<part-def>...]
<mtd-id>   := unique device tag used by linux kernel to find mtd device (mtd->name)
<part-def> := <size>[@<offset>][<name>][<ro-flag>]
<size>     := standard linux memsize OR '-' to denote all remaining space
<offset>   := partition start offset within the device
<name>     := '(' NAME ')'
<ro-flag>  := when set to 'ro' makes partition read-only (not used, passed to kernel)

</verbatim>
For example, on some target system the =mtdparts= command might
display this information:
<verbatim>
=> mtdparts

device nor0 <TQM5200-0>, # parts = 4
 #: name                        size            offset          mask_flags
 0: firmware            0x00100000      0x00000000      1
 1: kernel              0x00180000      0x00100000      0
 2: small-fs            0x00d80000      0x00280000      0
 3: big-fs              0x01000000      0x01000000      0

active partition: nor0,0 - (firmware) 0x00100000 @ 0x00000000

defaults:
mtdids  : nor0=TQM5200-0
mtdparts: mtdparts=TQM5200-0:1m(firmware),1536k(kernel),3584k(small-fs),2m(initrd),8m(misc),16m(big-fs)
</verbatim>
The partition table printed here obviously differs from the default value for the =mtdparts= variable printed in the last line. To verify this, we can check the current content of
this variable:
<verbatim>
=> print mtdparts
mtdparts=mtdparts=TQM5200-0:1024k(firmware)ro,1536k(kernel),13824k(small-fs),16m(big-fs)
</verbatim>
and we can see that it exactly matches the partition table printed above.

Now let's switch back to the default settings:
<verbatim>
=> mtdparts default
=> mtdparts

device nor0 <TQM5200-0>, # parts = 6
 #: name                        size            offset          mask_flags
 0: firmware            0x00100000      0x00000000      0
 1: kernel              0x00180000      0x00100000      0
 2: small-fs            0x00380000      0x00280000      0
 3: initrd              0x00200000      0x00600000      0
 4: misc                0x00800000      0x00800000      0
 5: big-fs              0x01000000      0x01000000      0

active partition: nor0,0 - (firmware) 0x00100000 @ 0x00000000

defaults:
mtdids  : nor0=TQM5200-0
mtdparts: mtdparts=TQM5200-0:1m(firmware),1536k(kernel),3584k(small-fs),2m(initrd),8m(misc),16m(big-fs)
=> print mtdparts
mtdparts=mtdparts=TQM5200-0:1m(firmware),1536k(kernel),3584k(small-fs),2m(initrd),8m(misc),16m(big-fs)
</verbatim>
Then we delete the last 4 partitions ("small-fs",
"initrd", "misc" and "big-fs") ...
<verbatim>
=> mtdparts del small-fs
=> mtdparts del initrd
=> mtdparts del misc  
=> mtdparts del big-fs  
=> mtdparts

device nor0 <TQM5200-0>, # parts = 2
 #: name                        size            offset          mask_flags
 0: firmware            0x00100000      0x00000000      0
 1: kernel              0x00180000      0x00100000      0

active partition: nor0,0 - (firmware) 0x00100000 @ 0x00000000

defaults:
mtdids  : nor0=TQM5200-0
mtdparts: mtdparts=TQM5200-0:1m(firmware),1536k(kernel),3584k(small-fs),2m(initrd),8m(misc),16m(big-fs)
</verbatim>
... and combine the free space into a singe big partition:
<verbatim>
=> mtdparts add nor0 - new-part
=> mtdparts

device nor0 <TQM5200-0>, # parts = 3
 #: name                        size            offset          mask_flags
 0: firmware            0x00100000      0x00000000      0
 1: kernel              0x00180000      0x00100000      0
 2: new-part            0x01d80000      0x00280000      0

active partition: nor0,0 - (firmware) 0x00100000 @ 0x00000000

defaults:
mtdids  : nor0=TQM5200-0
mtdparts: mtdparts=TQM5200-0:1m(firmware),1536k(kernel),3584k(small-fs),2m(initrd),8m(misc),16m(big-fs)
=> print mtdparts
mtdparts=mtdparts=TQM5200-0:1m(firmware),1536k(kernel),30208k(new-part)
</verbatim>
%ENDIF%

%IF{ "%HAVE_UBI%" eq "true"}%
%SECTION1{name=UBootCmdFlUBI}% UBI Usage in U-Boot

As in Linux, UBI access in U-Boot refers to MTD partitions, either
through their partition number (like "nand0,%UBI_NAND_PART%") or partition name (like
%UBI_NAND_NAME%).  So let's first check the partitions on the device:

%INCLUDE{DULGData_%BOARD%.UBootUbiMtdParts}%

U-Boot provides the following command line interface to UBI:

%INCLUDE{DULGData_%BOARD%.UBootUbiHelp}%

To make a UBI device available to U-Boot it needs to be attached.
This is done using the "ubi part" command. If an UBI device exists on
the specified MTD partition it will be attached, otherwise a new UBI
device will be created.

** WARNING ** "ubi part" will, without any warning, overwrite any
              existing data and create a new UBI device if you run it
              on a partition that does not contain an UBI device yet.

Let's attach the %UBI_NAND_NAME% partition to UBI:

%INCLUDE{DULGData_%BOARD%.UBootUbiPartNand}%

Now that the UBI device is attached, this device can be accessed
using the following commands:
<pre>
ubi info        Display volume and ubi layout information
ubi createvol   Create UBI volume on UBI device
ubi removevol   Remove UBI volume from UBI device
ubi read        Read data from UBI volume to memory
ubi write       Write data from memory to UBI volume
</pre>

For example display volume and ubi layout information with ubi info:

%INCLUDE{DULGData_%BOARD%.UBootUbiInfoNand}%

There is another set of commands to access UBIFS file systems:

<pre>
ubifsmount - mount UBIFS volume
ubifsls    - list files in a directory
ubifsload  - load file from an UBIFS filesystem
</pre>

First, we have to mount the UBIFS file system:

%INCLUDE{DULGData_%BOARD%.UBootUbiMountNand}%

after successfully mounted we can access it:

%INCLUDE{DULGData_%BOARD%.UBootUbiAccessNand}%

** NOTE ** In U-Boot, there is no clean way to detach an UBI device;
           all you can do is to attach a different device - assuming
           there is another one; alternatively, you can give a
           non-existent partition name: this will give an error, but
           it will detach the previously attached UBI device:

%INCLUDE{DULGData_%BOARD%.UBootUbiDetach}%

Update of an UBI Volume using U-Boot:

%INCLUDE{DULGData_%BOARD%.UBootUbiUpdateNand}%

Useful definitions:
<pre>
update_data=ubi part data;tftp %RAM_ADDR% %BOARDNAME%/image-data.ubifs;ubi write %RAM_ADDR% data ${filesize}
update_user=ubi part user;tftp %RAM_ADDR% %BOARDNAME%/image-user.ubifs;ubi write %RAM_ADDR% user ${filesize}
</pre>

%ENDIF%
5.9.2. Memory Commands		1. Abstract		5.9.4. Execution Control Commands
Prev		Home		Next