I’m working on a project which requires redundant u-boot parameter support, and more parameter space than the default tegra u-boot build. Based on the Default Partition Overview and the fact that the default flash_l4t_t186.xml layout has SMD located sequentially at size 4096 in mmcblk0boot0 offset 0x1F9000 I assumed I could use the space between SMD and the secondary_gpt for u-boot parameter storage starting at 0x1FA000 and through the end of the linear flash space at 0x800000 (minus the last sectors reserved for secondary_gpt). I originally allocated my uboot_env partition just before the secondary_gpt at offset 3928064 (0x3BF000 to 0x3FF000 in mmcblk0boot1). However, when attempting to turn on Bootloader Redundancy I found that my attempts to run nv_update_engine --install were all failing with this message
Slot could not be opened mb2 mb2 fail to write Writing to partitions failed.
I traced this application with strace and noticed the failure occurred because the application was attempting to open the mb2 area by partition id instead of directly accessing by offset.
[pid 5459] openat(AT_FDCWD, "/dev/disk/by-partlabel/mb2_b", O_RDWR) = -1 ENOENT (No such file or directory) [pid 5459] write(1, "Slot could not be opened mb2\n", 29Slot could not be opened mb2 ) = 29 [pid 5459] write(1, "mb2 fail to write \n", 19mb2 fail to write
I was able to make the problem go away if I copied the mmcblk0boot1 content from a stock tegraflash image over top of my image. I then compared strace of nv_update_engine --install between the two images and noticed in the successful case there was a read of mmcblk0boot1 address 4177408 (0x3FBE00) which read non-zero content on the stock tegraflash instance but 0 on my image (since it was located within the redundant uboot parameter storage area)
[pid 12780] openat(AT_FDCWD, "/dev/mmcblk0boot1", O_RDWR) = 3 [pid 12780] lseek(3, 4177408, SEEK_SET) = 4177408 [pid 12780] read(3, "4240205345713D0700h6667&31073n2M755630B456155+SA72Z"..., 2560) = 2560
I relocated my uboot environment from 0x2C0000 to 0x300000 to avoid this location and now redundant boot works as expected.
I’d like to understand more about the reserved space in mmcblk0boot1, and most importantly whether 0x2C0000 to 0x30000 is available for expanded u-boot redundant parameter storage or if there are other locations in the flash which would be better to use for this purpose. Are the SMD and other partitions listed in the default flash_l4t_t186.xml located in the addresses predicted by adding their sizes and rounding up to 4096 byte boundaries? Are there other areas not included in flash_l4t_t186.xml but reserved for use by existing or future software?