BSP 35.6.2 flashing for ROOTFS_AB=1 fails

david.fernandez · September 22, 2025, 4:43pm

I am flashinh a jAXi module.

Running the standard command:

ROOTFS_AB=1 sudo -E --preserve-env=ROOTFS_AB ./flash.sh jetson-agx-xavier-industrial mmcblk0p1

Fails with APPSIZE is too small.

Apparently, everything assumes that the rootfs would still fit in half the size of a devkit rootfs.

If I run the flash command like:

ROOTFS_AB=1 sudo -E --preserve-env=ROOTFS_AB ./flash.sh -S 56GiB jetson-agx-xavier-industrial mmcblk0p1

It still fails like:

...
[   1.0379 ] Updating mb1-bct with firmware information
[   1.0394 ] tegrabct_v2 --chip 0x19 --mb1bct mb1_cold_boot_bct_MB1.bct --updatefwinfo flash.xml.bin
[   1.0396 ] Start sector for recovery, expected >= 235276072, actual 0
Error: Return value 4
Command tegrabct_v2 --chip 0x19 --mb1bct mb1_cold_boot_bct_MB1.bct --updatefwinfo flash.xml.bin
Failed flashing t186ref.

That needs internal knowledge.

Also, given that in BSP-32.7.1 the nVidia provided sample rootfs fits in half the size, and all was fine, here it seems that we have another instance of something untested.

I stripped the rootfs to ~15GiB in size, but that’s all I can do for our use case.

If anybody knowing those nVidia utilities can help with this problem, that would be great.

All I can do is trace it to bootloader/tegraflash_internal.py:4362

    if tegraparser_values['--pt'] is not None:
        info_print('Updating mb1-bct with firmware information')
        command = exec_file('tegrabct')
        command.extend(['--chip', values['--chip']])
        command.extend(['--mb1bct', mb1bct_file])
        if bool(is_cold_boot_mb1_bct) == False:
            command.extend(['--recov'])
        command.extend(['--updatefwinfo', tegraparser_values['--pt']])
        run_command(command)

But what does tegrabct do exactly, and why does it not like whatever it is, no idea.

N.B. This suggestion: Jetson AGX Xavier Industrial SOM extend rootfs size failed

Mentions a change in some flash config, but also that you won’t be able to do OTA updates.

We need OTA updates.

The suggested change is to remove the start of a partition:

--- flash_l4t_t194_spi_emmc_jaxi.xml	2023-07-17 15:33:15.851251745 +0800
+++ flash_l4t_t194_spi_emmc_jaxi.xml	2023-07-17 15:31:30.415759099 +0800
@@ -690,7 +690,6 @@
         <partition name="RECNAME" type="kernel">
             <allocation_policy> sequential </allocation_policy>
             <filesystem_type> basic </filesystem_type>
-            <start_location> 0x70C100000 </start_location> <!-- aligned to 0x100000 -->
             <size> RECSIZE </size>
             <file_system_attribute> 0 </file_system_attribute>
             <allocation_attribute> 8 </allocation_attribute>

That value seems to be a bit after 28GiB… I wonder if it is just a matter of updating it for 56GiB…

david.fernandez · September 22, 2025, 5:13pm

Right, seems that in the new BSP 35.6.2, it comes to this partition:

        <partition name="recovery" type="kernel">
            <allocation_policy> sequential </allocation_policy>
            <filesystem_type> basic </filesystem_type>
            <size> 83886080 </size>
            <start_location> 0x70C100000 </start_location> <!-- aligned to 0x100000 -->
            <file_system_attribute> 0 </file_system_attribute>
            <allocation_attribute> 8 </allocation_attribute>
            <percent_reserved> 0 </percent_reserved>
            <filename> recovery.img </filename>
            <description> **Required.** Contains recovery image. </description>
        </partition>

I guess, we could modify it in the same way that APPSIZE is replaced by the ROOTFSSIZE value somewhere in flash.sh or dependent scripts…

The question is, Why use a fixed value here, instead of sequential with align_boundary?

Is that start location used somewhere else in some OTA script?

I can only find it in xml files used by OTA, like:

bootloader/t186ref/cfg/flash_l4t_t194_spi_emmc_jaxi_rootfs_ab_R35A_R35i.xml

Funny thing is that both APP & APP_b are sized as 56GiB in the xml files, so why not set the location up to 56GiB plus the previous partitions’ sizes?

Still there is the question of that location being hard-coded in some binary tegra utility that might fail if I update the xxx_rootfs_ab.xml files and OTA related ones to rootfs_ab.

Please @DaveYYY, @JerryChang, or anybody with knowledge on this, chip in and let me know what is the right way to fix this.

For all I know, adding all the previous partitions (and only one APP size, as both have to fit in it), I end up with 0xE0C0E5000 and aligning that to 1MiB, it makes 0xE0C100000, so that should be the value to use in A/B redundant systems… Can we just update the xml files for those? and will OTA work fine?

I guess that hopefully, everything should work for devices initially flashed with the modified xml files in the first place, and for devices coming from 32.x.x, perhaps it would work like a flash layout update?

Lots of questions…

JerryChang · September 23, 2025, 8:27am

hello david.fernandez,

here’s EXT_NUM_SECTORS and -S options to specify new root file system size.
please see-also Topic 321866 for reference.

david.fernandez · September 23, 2025, 5:40pm

Hi @JerryChang,

Seems that EXT_NUM_SECTORS is related to external storage. By the way, there seems to be the -T option to set that.

I am using eMMC flash and OTA to eMMC.

You say in the subject you link that -S value should be bigger than APPSIZE, but it seems that that value IS APPSIZE, and is replaced in the flash.xml (copy of the flash config after various replacements and processing.

Even doing that, I cannot flash with just the -S option (tried adding -T as well, but no difference as expected)… I get this message:

...
[   1.0379 ] Updating mb1-bct with firmware information
[   1.0394 ] tegrabct_v2 --chip 0x19 --mb1bct mb1_cold_boot_bct_MB1.bct --updatefwinfo flash.xml.bin
[   1.0396 ] Start sector for recovery, expected >= 235276072, actual 0
Error: Return value 4
Command tegrabct_v2 --chip 0x19 --mb1bct mb1_cold_boot_bct_MB1.bct --updatefwinfo flash.xml.bin
Failed flashing t186ref.

So the problem appears to be in that fixed <start_location> in the flash xml files, that is not compatible with APPSIZEs bigger than 28GiB.

I guess all my questions still stand.

david.fernandez · September 29, 2025, 12:46pm

@JerryChang, Gently reminder.

JerryChang · October 2, 2025, 7:00am

hello david.fernandez,

may I know what’s the actual use-case?
the rootfs size has to be equal to or smaller than the default one (i.e. 28GB).
for the t194 series, we fixed some partitions’ locations after the APP, so once the APP size exceeds that fixed location, then the flashing will be failed.

david.fernandez · October 2, 2025, 11:02am

Hi @JerryChang,

Not sure if you have read the previous posts here.

The use case is to flash the jAXi (64GiB eMMC) with redundant rootfs using BSP 35.6.2. That is, passing ROOTFS_AB=1

When you try that, it errors with APPSIZE is too small.

As the jAXI has a 64GiB eMMC, and the default APPSIZE is 28GiB, then I tried to use -S 56GiB, but then errors with

...
[   1.0379 ] Updating mb1-bct with firmware information
[   1.0394 ] tegrabct_v2 --chip 0x19 --mb1bct mb1_cold_boot_bct_MB1.bct --updatefwinfo flash.xml.bin
[   1.0396 ] Start sector for recovery, expected >= 235276072, actual 0
Error: Return value 4
Command tegrabct_v2 --chip 0x19 --mb1bct mb1_cold_boot_bct_MB1.bct --updatefwinfo flash.xml.bin
Failed flashing t186ref.

From the this issue: Jetson AGX Xavier Industrial SOM extend rootfs size failed

It appears that the problem is this section in the flash config:

--- flash_l4t_t194_spi_emmc_jaxi.xml	2023-07-17 15:33:15.851251745 +0800
+++ flash_l4t_t194_spi_emmc_jaxi.xml	2023-07-17 15:31:30.415759099 +0800
@@ -690,7 +690,6 @@
         <partition name="RECNAME" type="kernel">
             <allocation_policy> sequential </allocation_policy>
             <filesystem_type> basic </filesystem_type>
-            <start_location> 0x70C100000 </start_location> <!-- aligned to 0x100000 -->
             <size> RECSIZE </size>
             <file_system_attribute> 0 </file_system_attribute>
             <allocation_attribute> 8 </allocation_attribute>

which assumes a 32GiB eMMC.

In that same issue there are comments explaining that the OTA might be affected if changing that value.

If you read the previous posts here, I go through all that.

What is the solution? Can I modify those fixed locations safely for the jAXi, so the full 64GiB eMMC is used and still be able to OTA to it?

JerryChang · October 3, 2025, 6:14am

hello david.fernandez,

it’s the start location of recovery partition (0x70C100000) is aligned to 1MiB.
please remove that start_location for your use-case, for running OTA, please double check that you’re using the same partition layout to generate image-based OTA payload in the future.

david.fernandez · October 3, 2025, 10:05am

Hi @JerryChang,

Do I need to update it to 0xE0C100000, or just removing it is fine?

JerryChang · October 7, 2025, 5:04am

you may removing it for your use-case.

david.fernandez · October 7, 2025, 11:53am

Right, I’ll test flashing and OTA with it removed then.

david.fernandez · October 7, 2025, 6:07pm

Hi @JerryChang

While doing that… I wonder… Do I need to set <align_boundary> 0x100000 </align_boundary> for that partition instead?

Regards

JerryChang · October 8, 2025, 1:48am

hello david.fernandez,

nope, please only remove that start_location for flashing and OTA.

david.fernandez · October 8, 2025, 12:32pm

Hi @JerryChang,

OK, I’ll just remove it then for jAXis. Do you foresee any problem when OTAing from 32.7.1 to 35.6.2?

david.fernandez · October 8, 2025, 4:48pm

So far, modifying the relevant flash files with:

  sed -si -re '
    /^ +<start_location> 0x70C100000 <\/start_location>/ {
      s/    (<.+<\/start_location>)/<!--\1-->/
    }
  '   bootloader/t186ref/cfg/flash_l4t_t194_spi_emmc_jaxi_rootfs_ab*.xml

then flashing with:

ROOTFS_AB=1 sudo -E --preserve-env=ROOTFS_AB ./flash.sh -S 28GiB jetson-agx-xavier-industrial mmcblk0p1

works.

The -S 28GiB is because it overrides whatever the .conf files did, so it has to be the size of the APP or APP_b partition (as there will be 2 of them).

If modifying the p2822-0000+p2888-0008*.conf, then the ROOTFSSIZE should be set to 56GiB… When passing ROOTFS_AB=1, the script will half the ROOTFSSIZE value to be used in flash.sh if no -S option is provided.

When no ROOTFS_AB=1 is used, then the APP partition can be set up to -S 56GiB.

system · November 4, 2025, 6:33am

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Jetson AGX Xavier Industrial SOM extend rootfs size failed Jetson AGX Xavier nvbugs , storage	9	727	August 8, 2023
RFS A and B parition size increase with OTA update support Jetson AGX Xavier security , ota	8	303	June 27, 2024
Extend Rootfs size(with eMMC 64Gb) Jetson AGX Xavier kernel	2	393	October 18, 2021
Controlling APP size partition JetPack 5.1.2 Jetson AGX Xavier linux	4	1596	October 3, 2023
Changing ROOTFS Size with ROOTFS_AB enabled Jetson Orin Nano ubuntu , linux	8	226	July 21, 2025
No APP_b partition found! in Jetson Xavier NX 5.1.4 version Jetson Xavier NX	25	405	February 10, 2025
Jetson AGX INdustrial rootfs redundancy Jetson AGX Xavier linux	28	1385	August 24, 2022
Alter rootfs partition size Jetson AGX Xavier	1	591	April 2, 2019
Changing APPSIZE leads to tegraflash errors Jetson Xavier NX reflash	5	768	November 8, 2022
How to set APP partition 48G or more space with flash.sh on my xavier industrial(64G) Jetson AGX Xavier reflash	2	480	November 20, 2023

BSP 35.6.2 flashing for ROOTFS_AB=1 fails

Related topics