meta-mender-tegra: dunfell nano development board partition layout fixes #188
Conversation
To maintain compatibility with the layout of the NVIDIA partitions in the SPI flash for L4T R32.4.3+ and still keep the U-Boot environment start at the same offset in SPI flash we've been using, we need to reduce the size of the environment to allow it to fit into the available space. To do this, set BOOTENV_SIZE on SPI flash-equipped tegra210 platforms to 64KiB instead of the Mender default of 128KiB. Signed-off-by: Matt Madison <[email protected]> Signed-off-by: Dan Walkes <[email protected]>
The flashing tools and flash layout for the QSPI-equipped Nanos were updated in L4T R32.4.3, and our existing layout file generates an error during USB flashing because the updated tools think the VER partition runs off the end of the flash. Either we added up the sizes incorrectly, or there's a bug in the tools. This patch updates the flash layout to keep the U-Boot environment area we reserve in the QSPI flash at the same location and with the same size. The VER_b and VER partitions that follow are reduced in size to prevent the flashing tools from complaining. This should retain compatibility for an OTA upgrade that updates the SPI flash without having to save and restore the U-Boot environment. The VER partitions are smaller than the default L4T settings (which were also reduced in R32.4.3), but still plenty large enough to hold the version information. Signed-off-by: Matt Madison <[email protected]>
dwalkes
force-pushed
the
dunfell-nano-partition-layout-updates
branch
from
5acc581 to
b320108
Compare
What will happen if you do not do this and just deploy an update with a Mender Artifact ( |
Good point @mirzak. Since we do not yet support bootloader updates on Nano I don't think anyone just performing mender updates will notice this change. I think the only way they might be able to get confused would be if they updated the SDCard using the I've updated the description. |
Per discussion at OE4T#5
As of r32.3.1 (or possibly earlier) NVIDIA has defined a UBENV partition at offset 0x3D8000 for
jetson-nano-qspi-sdpartition layout, which is the layout used for the Nano development board with SD card. Previously this area was defined as aPADpartition and we had stored our uboot environment in that location. However, we'd also accidentally overflowed into theVER_blocation with our definition of uboot storage environment from 0x3B0000 to 0x3F0000. This might be a problem if/when we add support for Nano redundant boot for bootloader components.The area defined by NVIDIA for
UBENVis too small to store dual redundant copies of mender variables, so we need to stretch our area back into what was known as thePADpartition on previous releases and the unused space betweenNXC_RandVER_bpartitions.After some discussion in the previously mentioned thread, we've settled on keeping the
UBENVstarting at0x3B0000and reducing the size to 131072 bytes instead of 262144 of so we could continue to make the first uboot environment boundary at the same start location and complete both copies of uboot environment before theVER_bsector starts. This means the u-boot environment for existing sdcard based Nano builds on the dunfell branch will move on the next tegraflash ordosdcard.shbased update. In the cvase of adosdcard.shbased update the existing SPI flash u-boot environment will be invalid and replaced with defaults.This alignment will be shared with the Jetson Nano 2GB hardware which will be brought in during gatesgarth/L4T+next (unless someone volunteers to add and backport it sooner in OE4T#4) and the patches here were rebased from those in the above linked PR.
I've started a sheet at this link which I plan to try to update with each new release and platform to make sure we don't miss these layout changes going forward with new L4T releases.
I've completed the uboot integration tests at this link for
jetson-nano-qspi-sdwith these changes.