Unable to add nvme partition to xml configuration

[steamedcotton]

I have a 128gb nvme ssd connected to a Jetson carrier board and I’m using the TX2NX SoM.

Following the instructions here I attempted to flash the device, and I’m getting the following error message:

...
[   0.9249 ]
[   0.9249 ] Updating mb1-bct with storage information
[   0.9268 ] tegrabct_v2 --chip 0x18 --mb1bct mb1_cold_boot_bct_MB1.bct --updatestorageinfo flash.xml.bin
[   0.9275 ] MB1-BCT version: 0xf
[   0.9277 ] There is no MB1-BCT device type corresponding to pt type: 9
[   0.9277 ]
Error: Return value 2
Command tegrabct_v2 --chip 0x18 --mb1bct mb1_cold_boot_bct_MB1.bct --updatestorageinfo flash.xml.bin
Failed flashing t186ref.

Here is my flash command:

sudo ROOTFS_AB=1 ./flash.sh jetson-xavier-nx-devkit-tx2-nx mmcblk0p1

And here’s what I added to the <partition_layout/> in bootloader/t186ref/cfg/flash_l4t_t186_rootfs_ab.xml:

<device type="nvme" instance="0" sector_size="512" num_sectors="250069680">
        <partition name="master_boot_record" type="protective_master_boot_record">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 512 </size>
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 8 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
            <description> **Required.** Contains protective MBR. </description>
        </partition>
        <partition name="primary_gpt" type="primary_gpt">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> PPTSIZE </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 `sdmmc_user` 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>
        <partition name="SMALLIMG" type="data">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 8388608 </size>
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 0x8 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
            <align_boundary> 4096 </align_boundary>
            <unique_guid> 80d55227-b8b1-48aa-ac95-5ffb2be7648f </unique_guid>
            <filename> smallimage.img </filename>
            <description> Just a very small partition. </description>
        </partition>
        <partition name="secondary_gpt" type="secondary_gpt">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 0xFFFFFFFFFFFFFFFF </size>
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 8 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
            <description> **Required.** Contains secondary GPT of the `sdmmc_user`
                device. </description>
        </partition>
    </device>

Is there something I’m missing?

[JerryChang]

hello steamedcotton,

are you going to create redundant root file systems? or, you would like to create another partition for NVMe?

[steamedcotton]

Currently, I’m just trying to create another partition on the NVMe. I can do this from a running rootfs, but it would be nice to have it created as part of the flash.sh setup.

We are still evaluating the best way to gain additional storage; unfortunately, the 16gb that comes on the device is not enough for what we are hoping to do.

[JerryChang]

hello steamedcotton,

are you using device with internal eMMC? may I know where is your root file system you’re expected?

you’ll need to check External Storage Device Partition and modify a partition configuration file,
after that, please perform the flash script and assign the -S options to change the partition size,
for example, $ sudo ./flash.sh -S <size> <board> <rootdev> .

BTW,
here’s developer guide Flashing to an NVMe Drive to booted from an NVMe storage device.
thanks

[steamedcotton]

Thank you for your response! Here are some answers to your comments:

are you using device with internal eMMC? may I know where is your root file system you’re expected?

Our rootfs (A and B) are on the TX2NX internal eMMC and this is where we are booting from.

you’ll need to check External Storage Device Partition and modify a partition configuration file

Please see my original post on this topic (I included the snippet of xml I added to the configuration file).

after that, please perform the flash script and assign the -S options to change the partition size

I’m not sure this would help for two reasons:

1. The addition to the bootloader/t186ref/cfg/flash_l4t_t186_rootfs_ab.xml file has the size is hardcoded to 8mb (This for just for testing, the real size will be much larger).
2. I believe that using the -S option in the flash.sh script would be ignored when we are flashing with ROOTFS_AB=1. The script overrides this value and sets it to 7GiB (in p3636.conf.common).

here’s developer guide Flashing to an NVMe Drive to booted from an NVMe storage device.

I can format and use the external NVMe drive from rootfs on the eMMC and we are currently not trying to boot from NVMe; just use it as extra storage.

I was hoping that I could add another section to the configuration xml and have flash.sh handle the partitioning and imaging of the external nvme, but it’s sounding like that is not possible?

[JerryChang]

hello steamedcotton,

you would like to extend the storage, for example, the total storage you expect is… 16GB internal eMMC + 128GB NVMe, right?
if yes,
you may need to mount the NVMe drive when system boot-up, you may have init script file for running this.

your use-case description isn’t sounds like RootFS A/B feature.
please see-also developer guide, root file system redundancy for reference.
thanks