Hi,
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)
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?
Thanks!
Dan
Hi Wayne,
Thanks for the response.
I’ll try this offset but I expect it will work since I don’t see anything but zeros there based on the dd content of the mmcblk0boot1 partition.
Are you suggesting this offset because it’s the highest one not reserved for some other use? Or are you suggesting because offset 0x2C0000 to 0x300000 is currently used or planned to be used soon? I’m just trying to understand the urgency in updating the development systems I’m using now.
Thanks
In the initialization, the updater will try to read the secondary_gpt, which is at the end of /dev/mmcblk0boot1. Actually this part size is 512 + 128 *128=0x4200, so the offset is 0x3FBE00 (4177408)
Thank you Wayne, I can confirm this works with my setup.
The only deviation from your comment above
Could you try to allocate uboot_env partition from 0x3EB000 to 0x3FAFFF?
I needed to allocate at 0x3BB000 in order to end at 0x3FAFFF.
In case anyone finds it useful, here’s a spreadsheet which calculates relevant partition start offsets in hex and decimal for each area across boot0 and boot1 references:
The default locations of the VER_b and VER partitions moved to the end of the boot partition and in a place which overlaps with the uboot environment location suggested here (0x7E7FFF and 0x7F7FFF) , and a UBENV partition was added at 0x7D8000.
Is it OK to leave VER_b and VER partitions where they were located in R32.3.1? Or do I need to relocate them and relocate my uboot environment to be compatible with R32.4.3 and/or future releases?
Unfortunately it’s not easy to update devices already shipped (and without the possibility to tegraflash) to use new partitioning schemes.
Can you explain anything about why the relocation is necessary across 32.3.1 and 32.4.3 and later L4T releases? Are there NVIDIA software components which assume locations of these partitions VER_b and VER rather than using the partition table to locate them?
What is the goal you are trying to do here?
If you are looking into some latest release, I guess you want to do some upgrade, right?
If so, then why do you want to keep something unchanged (e.g. partition layout) when doing upgrade? Do you only want partial update? Then, could you tell us what are those you don’t want to change?
Actually, I don’t follow all the changes in partition layout for each release so cannot tell you the answer yet. But I could help check.
What is the goal you are trying to do here?
If you are looking into some latest release, I guess you want to do some upgrade, right?
Correct, I’d like to use an OTA update scheme (see mender tx2 update page) to upgrade between L4T releases.
If so, then why do you want to keep something unchanged (e.g. partition layout) when doing upgrade?
Good question. The reason not to change this is that it’s not possible to move data around without creating a possibility of bricking a device, if power/connectivity is lost at exactly the wrong moment. This means moving partitions (especially u-boot parameter storage) can introduce windows of time where losing power/connectivity during upgrades can result in a device which doesn’t boot anymore. This obviously has some negative implications for permanently mounted devices without access to USB/tegraflash or the ability to USB/tegraflash in the field (which is probably the case for most commercial embedded applications).
Then, could you tell us what are those you don’t want to change?
Ideally I don’t want to change anything about the partition layout we’ve used for r32.3.1, for the reasons I mentioned above and also because it will be more work for us to support, a larger amount of software to test, etc. This was my purpose for starting this thread in the first place, to avoid this scenario. Sorry if this wasn’t clear.
Actually, I don’t follow all the changes in partition layout for each release so cannot tell you the answer yet. But I could help check.
So you want to upgrade the system but don’t want to change the layout.
Have you ever tried the OTA method we provided? It would do the upgrade without usb/tegraflash. It would also upgrade the layout and we have some backup mechanism, so the losing power shall not cause data corruption.
Yes, and this is used for the update mechanism I mentioned, see the state scripts at this link. However, the NVIDIA provided mechanism does not support upgrading root filesystems. It also doesn’t support updating u-boot state to support loading different root filesystems. Both of these are accomplished with the mender scheme provided above. However, the support for a/b root filesystem requires u-boot variables to remain in the same location across upgrades, or at minimum to not be overwritten by partitions which have moved between L4T upgrades.
I don’t think it would be able to relocate uboot environment from the location that overlaps with new ver partitions without risking data corruption. If it does somehow, I’d like to understand more about how this is supposed to work and how it could be used with a uboot /ver and ver_b environment defined based on the instructions provided here for L4T r32.3.1. This level of detail is not included in the documentation.
If you want to use rel-32.3.1 layout + rel-32.4.3 components. You need to remove this patch from uboot because it would use the value from fixed location.
Thanks @WayneWWW in our case we already have patches here which setup the uboot environment correctly I believe. The main thing I’m trying to understand from this thread is whether I need to move the VER partitions, and this comment above:
Are there NVIDIA software components which assume locations of these partitions VER_b and VER rather than using the partition table to locate them?