Skip to main content.
Navigation:
DENX
>
DULG
>
UBootCmdGroupFlash
Translations:
Edit
|
Attach
|
Raw
|
Ref-By
|
Printable
|
More
DULG
Sections of this site:
DENX Home
|
DULG
|
ELDK-5
|
Know
|
Training
|
U-Boot
|
U-Bootdoc
Topics
DULG Home
BoardSelect
Manual
FAQ
Application Notes
Changes
Index
List of pages in DULG
Search
%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