Changes between Version 32 and Version 33 of linux/ubi


Ignore:
Timestamp:
09/18/2020 04:38:09 PM (6 weeks ago)
Author:
Tim Harvey
Comment:

add ubifs split details

Legend:

Unmodified
Added
Removed
Modified
  • linux/ubi

    v32 v33  
    596596
    597597Use the information in the section above for examples on how to load data in uboot from various sources such as network, mmc, usb.
     598
     599
    598600[=#SplitMethod]
    599601=== Updating UBI with low RAM devices
    600602For some devices, the size of the NAND flash exceeds the size of RAM. In this scenario the instructions from the prior section would fail as you would run out of RAM space before you could finish retrieving the file to program the NAND flash with.
    601603
    602 To work around this limitation Gateworks has created an installable U-Boot script that will apply UBI files containing a single partition image. This can be particularly useful for updating the firmware of a running target.
     604In order to flash a UBI in this situation within U-Boot you must either split the UBI image into chunks and transfer/flash each chunk, or you can use U-Boot to create a UBI volume and split the UBIFS and transfer/flash each chunk of the UBIFS. Flashing a UBI  has the disadvantage of erasing all the NAND wear leveling information the UBI has been tracking and won't support the special handling of bad blocks. Therefore it is recommended that you use the split UBIFS method which preserves wear leveling info and works with bad blocks.
     605
     606==== Split UBIFS flashing
     607The following example shows how you can take a UBIFS and split it into chunks that fit into low memory devices and flash them via U-Boot. The example uses tftp to transfer but you can easily replace that instruction with one that loads the chunks from removable storage:
     608
     6091. First you must split your ubifs image on your Linux development host and note the total size of the pre-split image which you will need during flashing. This example assumes a ~580MB ubifs that we will split into 200MB chunks to fit within a 256MB DRAM system:
     610{{{#!bash
     611$ ls -l focal-ventana_normal.ubifs
     612-rw-rw-r-- 1 gateworks user 581042176 Sep  9 14:56 focal-ventana_normal.ubifs
     613$ split -d -b 200M focal-ventana_normal.ubifs focal-ventana_normal.ubifs.part
     614$ ls -l focal-ventana_normal.ubifs*
     615-rw-rw-r-- 1 gateworks user 581042176 Sep  9 14:56 focal-ventana_normal.ubifs
     616-rw-rw-r-- 1 gateworks user 209715200 Sep  9 15:19
     617focal-ventana_normal.ubifs.part00
     618-rw-rw-r-- 1 gateworks user 209715200 Sep  9 15:19
     619focal-ventana_normal.ubifs.part01
     620-rw-rw-r-- 1 gateworks user 161611776 Sep  9 15:20
     621focal-ventana_normal.ubifs.part02
     622$ printf "0x%x\n" 581042176
     6230x22a20000
     624}}}
     6251. Now boot your target board and break into U-Boot. Use the {{{mtd}}} command to determine the MTD partition name that you wish to use for UBI. This is dictated by the {{{mtdids}}} and {{{mtdparts}}} env variables. The gateworks bootloader defaults the name of the MTD partition used for UBI to 'rootfs' as shown below:
     626{{{#!bash
     627Ventana > mtd
     628
     629device nand0 <nand>, # parts = 3
     630 #: name                size            offset          mask_flags
     631 0: uboot               0x01000000      0x00000000      0
     632 1: env                 0x00100000      0x01000000      0
     633 2: rootfs              0x7ef00000      0x01100000      0
     634
     635active partition: nand0,0 - (uboot) 0x01000000 @ 0x00000000
     636...
     637}}}
     6381. Use the {{{ubi}}} command to attach the {{{rootfs}}} MTD partition to the ubi layer. The {{{rootfs}}} name here must agree with the partition name from the MTD partition as described above... this is 'not' necessarily the name of your UBI 'volume' used below:
     639{{{#!bash
     640Ventana > ubi part rootfs
     641}}}
     6421. Use the {{{ubi info layout}}} command to inspect your UBI volumes. You will always have one volume named {{{layout volume}}} which holds the UBI volume information.
     643{{{#!bash
     644Ventana > ubi info layout
     645Volume information dump:
     646        vol_id          0
     647        reserved_pebs   15920
     648        alignment       1
     649        data_pad        0
     650        vol_type        3
     651        name_len        6
     652        usable_leb_size 126976
     653        used_ebs        15920
     654        used_bytes      2021457920
     655        last_eb_bytes   126976
     656        corrupted       0
     657        upd_marker      0
     658        name            rootfs
     659Volume information dump:
     660        vol_id          2147479551
     661        reserved_pebs   2
     662        alignment       1
     663        data_pad        0
     664        vol_type        3
     665        name_len        13
     666        usable_leb_size 126976
     667        used_ebs        2
     668        used_bytes      253952
     669        last_eb_bytes   2
     670        corrupted       0
     671        upd_marker      0
     672        name            layout volume
     673}}}
     674 * The above shows that there is one data volume named 'rootfs'
     6751. remove the existing volume (if you are operating on a blank UBI and only have {{{layout volume}}} skip this step):
     676{{{#!bash
     677Ventana > ubi remove rootfs
     678Remove UBI volume rootfs (id 0)
     679}}}
     6801. Create the new volume. Note that the volume name you use here is the name you would pass to the kernel for mounting. We typically call this 'rootfs' (which should not be confused with the MTD partition name).
     681{{{#!bash
     682Ventana > ubi create rootfs
     683No size specified -> Using max size (2021457920)
     684Creating dynamic volume rootfs of size 2021457920
     685}}}
     6861. Load your first chunk:
     687{{{#!bash
     688Ventana > tftpboot $loadaddr ventana/focal-ventana_normal.ubifs.part00
     689...
     690done
     691Bytes transferred = 209715200 (c800000 hex)
     692}}}
     693 * You could alternatively use the {{{load}}} command to load from removable storage such as microSD or USB Mass storage but you will need to set the {{{$filesize}}} variable appropriately.
     6941. Write your first chunk - this first chunk you need to provide the total size of the pre-split UBIFS image as the last argument in hex:
     695{{{#!bash
     696Ventana > ubi write.part $loadaddr rootfs $filesize 0x22a20000
     697209715200 bytes written to volume rootfs
     698}}}
     699 * Note the last argument {{{0x22a20000}}} which is the total size of the pre-split ubifs image in hex.
     7001. Continue the transfer and flash of your additional chunks, this time leaving off the last argument:
     701{{{#!bash
     702Ventana > tftpboot $loadaddr ventana/focal-ventana_normal.ubifs.part01
     703...
     704done
     705Bytes transferred = 209715200 (c800000 hex)
     706Ventana > ubi write.part $loadaddr rootfs $filesize
     707209715200 bytes written to volume rootfs
     708Ventana > tftpboot $loadaddr ventana/focal-ventana_normal.ubifs.part02
     709...
     710done
     711Bytes transferred = 161611776 (9a20000 hex)
     712Ventana > ubi write.part $loadaddr rootfs $filesize
     713161611776 bytes written to volume rootfs
     714}}}
     715
     716==== Split UBI flashing
     717Gateworks has created an installable U-Boot script that will apply UBI files containing a single partition image. This can be particularly useful for updating the firmware of a running target.
     718
     719This method does not work if you have bad blocks and also erases previous wear-leveling data that may be tracked by the previous UBI image. The split UBIFS method above is recommended instead.
    603720
    604721To update using a split UBI: