Tegra Recovery Mode - Force GPT Alignment

Hello everyone,
I’ve been working on flashing Jetson Nano boards in several ways.

So far I have found success in doing so with the genimage package on revision a02 development modules.
I’ve also had success flashing the same a02 development module in recovery mode as well as a b00 module also in recovery mode (both of them connected to an a02 development kit).

The problem is that, unlike genimage, tegradevflash doesn’t respect the size specified in the config file (flash.xml) for the partition table (GP1 / GPT) or at least I haven’t found how to enforce this.
Is there any way to get the desired behavior with the tools provided by Nvidia (tegradevflash, tegrarcm, tegraflash.py) or do I have to make tools of my own for this?

Best Regards,
Juan Pablo.

Will your change take effect if you modify the flash_l4t_t210_emmc_p3448.xml or flash_l4t_t210_spi_sd_p3448.xml instead of flash.xml?

@WayneWWW, I’m using the following command

sudo ./tegraflash.py --bl cboot.bin --bct P3448_A00_4GB_Micron_4GB_lpddr4_204Mhz_P987.cfg --odmdata 0x84000 --bldtb custom_dtb.dtb --applet nvtboot_recovery.bin --cmd "flash; reboot" --cfg custom_layout.xml --chip 0x21 --bins "EBT cboot.bin; DTB custom_dtb.dtb"

Since I am calling things directly I would not expect things to change.
It also is strange that everything has the right size, except GP1 and GPT.

I will try your suggestion with flash_l4t_t210_spi_sd_p3448.xml, since that one would allow me to use nvidia standard configurations compatible with my board instead of my customized ones.

Best Regards,
Juan Pablo.

What do you mean “right size”?
Actually, cboot src also has one part of partition layout definition. Since the cboot source for nano will not be released, I think some partition size cannot be changed in xml.

@WayneWWW,
By right size I mean that tegraflash.py (and whatever is in the call chain) will respect the size of the value specified in <size> for partitions like EKS, TBC, EBT, LNX even if the file passed in <filename> is smaller. This however does not happen for GP1/GPT (which also has a size).

As an example, the three following partitions would have a size of 1MB each on the SD card

    <partition id="10" name="EKS" type="data">
        <allocation_policy> sequential </allocation_policy>
        <filesystem_type> basic </filesystem_type>
        <size> 1048576 </size>
        <file_system_attribute> 0 </file_system_attribute>
        <partition_attribute> 0 </partition_attribute>
        <allocation_attribute> 8 </allocation_attribute>
        <percent_reserved> 0 </percent_reserved>
        <filename> eks.img </filename>
        <description> **Optional.** Contains the encrypted keys. </description>
    </partition>

    <partition id="11" name="TBC" type="bootloader">
        <allocation_policy> sequential </allocation_policy>
        <filesystem_type> basic </filesystem_type>
        <size> 1048576 </size>
        <file_system_attribute> 0 </file_system_attribute>
        <allocation_attribute> 8 </allocation_attribute>
        <percent_reserved> 0 </percent_reserved>
        <filename> nvtboot_cpu.bin </filename>
        <description> **Required.** Contains TegraBoot CPU-side binary. </description>
    </partition>

    <partition id="13" name="TOS" type="data">
        <allocation_policy> sequential </allocation_policy>
        <filesystem_type> basic </filesystem_type>
        <size> 1048576 </size>
        <file_system_attribute> 0 </file_system_attribute>
        <partition_attribute> 0 </partition_attribute>
        <allocation_attribute> 8 </allocation_attribute>
        <percent_reserved> 0 </percent_reserved>
        <filename> tos-mon-only.img </filename>
        <description> **Required.** Contains TOS binary. </description>
    </partition>

However, this would only occupy about 17kB

    <partition id="9" name="GP1" type="GP1">
        <allocation_policy> sequential </allocation_policy>
        <filesystem_type> basic </filesystem_type>
        <size> 2097152 </size>
        <file_system_attribute> 0 </file_system_attribute>
        <allocation_attribute> 8 </allocation_attribute>
        <percent_reserved> 0 </percent_reserved>
        <description> **Required.** Contains primary GPT of the `sdcard` device. All
          partitions defined after this entry are configured in the kernel, and are accessible
          by standard partition tools such as gdisk and parted. </description>
    </partition>

Best Regards,
Juan Pablo

@WayneWWW, I’ve confirmed that even with the configuration and commands provided by nvidia, the GP1 partition ends at sector 40 (20kB) instead of sector 4096 (2MB)

The steps to reproduce simply require running

sudo ./flash.sh -K EBT jetson-nano-qspi-sd mmcblk1p1

I have verified this behavior on L4T Jetson Nano and TX1 R32.4.2 Jetson Driver Package and L4T Jetson Nano R32.3.1 Jetson Driver Package

Best Regards,
Juan Pablo

Hi Juan,

Actually, cboot is handling the real size allocated on device. Maybe it is possible a hardcoded fixed value in cboot.
I can help your dig into the reason but need sometime.

I also want to know why do you want to change GP1 size? Does it affect your development?

Hi @WayneWWW

Ideally I would like to have the production module load an image from an sd card / usb drive and flash the emmc with that image with the change of a jumper (like you would on a fair amount of embedded systems).

However, from what I’ve read, the tegra only allows booting from it’s preferred location (mmc for production module / sd for development module) or with recovery mode.
Once in recovery mode, your scripts place cboot in RAM and do the flashing.

The main reason I want GP1 to have a fixed size is because it affects our development and our final implementation.
The second reason is that I want the flashing process to flash without additional restrictions.

I know this things take their time, so I will wait for you to check why and where this hard-coded behavior seems to be happening.

Alternatively, if you could provide steps on loading u-boot to RAM in recovery mode, that would solve this issue.

Hi @WayneWWW,
Here is a friendly reminder that I asked this a few months ago.
Has there been any progress on this issue?

Best Regards,
Juan Pablo.

Hi @WayneWWW,
I’m still waiting for an update on this since it has an undesired effect on our final product.

Best Regards,
Juan Pablo.

Hi,

Confirmed with our internal team, this value is fixed and cannot be changed.

Hi,
Since it’s software, I’ll just read “we’ve done it this way and we won’t change it”.

It still amazes me how Nvidia actively refuses to change anything that could ease the lives of developers working on their platforms and help make the product better.

Best Regards,
Juan Pablo.

Hi,

Actually I don’t get why you are trying to configure this partition size. Could you explain your usecase?

Hi @WayneWWW,
My use case involves having u-boot manage two firmware partitions, one for new firmware and another one for the “known good” firmware or “fallback” firmware, something similar to the following images.

Linux-Embedded-1

The thing is, in order to make this work (and it does work on our imx6 and am335x projects), you have to set the absolute memory address where you store u-boot environment variables required to boot from those partitions.
Now, in order to be able to use these absolute memory addresses, I need to be able to know the size for everything won’t change (we normally use images generated by genimage).
If any partition (GPT here) changes the size you set up on the configuration files, then the absolute addresses are going to be wrong and the system will not boot.

I understand Nvidia seems to be generating the GPT based on the xml file provided and does not allow passing the GPT as an independent file.
It’s also not possible to write partitions in an arbitrary fashion since I would have used that as a workaround for my use case.
In addition it doesn’t respect the size provided in field for the GP1 partition on the xml file.

On the development kit I was able to bypass this issue by directly writing the desired image using dd (I didn’t even notice the issue since I would not use flash.sh at all).
Unfortunately that’s not possible on the production module in a straightforward manner.

In conclusion, I would like to be able to write my image to emmc / sd in an arbitrary fashion since this would greatly simplify the process.
If that was found to be undesirable, being able to properly control the size for this partition would still help me.

Best Regards,
Juan Pablo.

Hi Juan,

What is exactly in this firmware? According to your image here, is it like backup partition for APP partition?

HI @WayneWWW,
Both partitions have a rootfs, where one is the currently active partition and the other is used for the next update.
When you perform an update, you try to boot from the new partition and do a fallback procedure if it won’t boot.
If the boot is successful, the new partition becomes the currently active one and the old partition is free for update+1.

The pictures where meant to abstract some details since the Nano has a lot of required partitions (required by Nvidia’s boot procedure, not by me).

Best Regards,
Juan Pablo.

Hi Juan,

Actually, what you are talking about is like APP_B partition. Many other forum users have requested this and it is in out future support plan.