Manually updating uboot in NAND for IMX6ULL from linux

Technical Support
, , , ,
1

Hi,

I am writing a custom uboot bootloader for the IMX6ULL colibri, and want to write it to the NAND flash from linux itself.

I know that I could use the Toradex EZ installer for this, but I want to manually be able to do this as well. What is the recommended procedure for this?

  • Do I need imx-kobs/ kobs-ng for this or not?

The mtds in linux look like this:

root@signco-baseboard:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00080000 00020000 "mx6ull-bcb"
mtd1: 00180000 00020000 "u-boot1"
mtd2: 00180000 00020000 "u-boot2"
mtd3: 00080000 00020000 "u-boot-env"
mtd4: 1fc00000 00020000 "ubi"
root@signco-baseboard:/#

And if I take a look at mtd1 and mtd2, it is clear u-boot is there at a 1kB offset.

The question is, is it OK for me to simply update these MTD partitions with my new uboot or not?
(The only reason I can think of that this is not OK, is that in the boot block (in BCB) the exact uboot size was passed along, which could lead to the IMX6ULL not fully copying all data into memory before booting.

Thanks in advance for your reply.

Kind regards,
Arnout

2

Please have a look at the following question:

3

Thanks, but this indeed shows how to overwrite the /dev/mtd’s with uboot.

It does not ask or check whether the full uboot image is copied to RAM by the IMX-ROM code. That code checks the BCB, which has information like “PagesInFirmware”. If this field is set to the smallest value possible for a given uboot, just updating the /dev/mtd might not be enough.

Hence the question, is this safe to do or not? And if not, what is the recommended procedure to also update the BCB?

4

Thanks, but this indeed shows how to overwrite the /dev/mtd’s with uboot.

No, you said from Linux itself which is exactly what it shows.

It does not ask or check whether the full uboot image is copied to RAM by the IMX-ROM code. That code checks the BCB, which has information like “PagesInFirmware”. If this field is set to the smallest value possible for a given uboot, just updating the /dev/mtd might not be enough.

Don’t worry, just assume it is all set to sane values.

Hence the question, is this safe to do or not?

Of course, this is safe to do.

And if not, what is the recommended procedure to also update the BCB?

There are tools like kobs-ng which is e.g. what the Toradex Easy Installer uses. However, as a regular user as long as you do not corrupt your BCB/FCB there is no need to ever re-write it.

5

“Don’t worry, just assume it is all set to sane values.”

Sure they are sane (it does boot …), but if you look at the code of kobs-ng, you will see that one of the values filled in is the “PagesInFirmware” or “m_uSectorsInFirmware”. In other words, if my uboot gets bigger than the ones previously flashed by the toradex ez installer, the BCB might be wrong still? (and hence unsafe)

6

Yes, we did look at it very thoroughly. We do set the size here to 3.5 megabytes which should be plenty enough for any kind of U-Boot even taking a few bad blocks and whatnot into account.

BTW: As follows the output of kobs-ng dump -v from within the Toradex Easy Installer running on a Colibri iMX6ULL:

/ # kobs-ng dump -v
WARNING: Parameter 'chip_count' is no longer used, ignoring
chip_0_size -> 3670016 (decimal), 0x380000 (hex)
search_exponent -> 1 (decimal), 0x1 (hex)
MTD CONFIG:
  chip_0_device_path = "/dev/mtd0"
  chip_0_size = 3670016
  chip_1_device_path = "(null)"
  search_exponent = 1
  data_setup_time = 80
  data_hold_time = 60
  address_setup_time = 25
  data_sample_time = 6
  row_address_size = 3
  column_address_size = 2
  read_command_code1 = 0
  read_command_code2 = 48
  boot_stream_major_version = 1
  boot_stream_minor_version = 0
  boot_stream_sub_version = 0
  ncb_version = 3
  boot_stream_1_address = 0
  boot_stream_2_address = 0
mtd: use new bch layout raw access mode
mtd: opening: "/dev/mtd0"
NFC geometry :
        ECC Strength       : 8
        Page Size in Bytes : 2110
        Metadata size      : 10
        ECC Chunk Size in byte : 512
        ECC Chunk count        : 4
        Block Mark Byte Offset : 1999
        Block Mark Bit Offset  : 0
====================================================
mtd: opened '/dev/mtd0' - '(null)'
mtd: partition #0
  type = 4
  flags = 1024
  size = 3670016
  erasesize = 131072
  writesize = 2048
  oobsize = 112
  blocks = 28
mtd: fingerprints mismatch @0:0x0
mtd: fingerprints mismatch @0:0x20000
mtd: NCB0 not found
mtd: fingerprints mismatch @0:0x40000
mtd: fingerprints mismatch @0:0x60000
mtd: NCB1 not found
mtd: neither NCB1 or NCB2 found ERROR
Unable to load boot structures

Anything else we may help you with today satisfying your ample curiosity?

7

I appreciate you looking further into this.
However, I am not convinced that the size is 3.5MB.
This is the “chip_size” parameter, which, as far as I can tell, just tells kobs-ng how far to look for the NCB’s.

The parameter I am interested in is the FCB - m_u32PagesInFirmware1. Aside from basic geometry of the NAND, the kobs-ng output you provided does not show any of this (and even seems to assume NCB (which it then does not find).

See the IMX6ULL Reference Manual at <8.5.2.3 Firmware configuration block> and friends for more information.

Sorry for persisting here, but I’d just like to be sure I wont run into any issue at some point with this.

8

Sorry for persisting here, but I’d just like to be sure I wont run into any issue at some point with this.

Which Issue, do you think, will you have? Which size has your u-boot?