How to enable & use BOOT_CHAIN_SELECT in JAXi

We have tried to use BOOT_CHAIN_SELECT (SOC_GPIO33_PT0) in JAXi to see if we can select between QSPI boot and eMMC boot, but judging by the log messages from the debug uart, it makes no difference and only QSPI is attempted.

N.B. The fuses are not burned.

Anything related to JESP seems not to have details about anything other than JAOi… judging by this link: https://developer.nvidia.com/embedded/jetson/jetson-safety

Is there a path to apply for a JESP or equivalent for JAXi. Otherwise, could somebody explain how BOOT_CHAIN_SELECT is supposed to work?

Hi david.fernandez,

Are you using the devkit or custom board for AGX Xavier?
What’s your Jetpack version in use?

Could you share any documents or steps how you attempt to do this?

Hi Kevin,

We use a custom board, but pretty much a stripped down version of the devkit carrier board.

We use the BSP 32.7.1 currently… I wonder if a more recent version of the 32.7.x will solve the problem.

The steps to test it are pretty much:

  1. Set the SOC_GPIO33 to 1 or 0, depending of the state to test.
  2. power on the Jetson.
  3. Capture debug uart messages. There are a couple of them indicating boot chain and memory used to boot.

We expected one mode to boot OK, as the JAXi is flashed normally to boot from QSPI, and the other to fail boot or fall-back to QSPI, but the uart messages should be different, depending on the boot chain or memory used to boot.

Both pins states give the same debug messages.


[0000.034] I> MB1 (prd-version: 1.5.1.9-t194-41334769-73a9b7ef)
[0000.039] I> Boot-mode: Coldboot
[0000.042] I> Chip revision : A02P
[0000.045] I> Bootrom patch version : 15 (correctly patched)
[0000.050] I> ATE fuse revision : 0x200
[0000.054] I> Ram repair fuse : 0x0
[0000.057] I> Ram Code : 0x1
[0000.059] I> rst_source : 0x0
[0000.062] I> rst_level : 0x0
[0000.066] I> Boot-device: QSPI
[0000.068] I> Qspi flash params source = brbct
[0000.073] I> Qspi using bpmp-dma
[0000.075] I> Qspi clock source : pllp
[0000.079] I> QSPI Flash Size = 64 MB
[0000.082] I> Qspi initialized successfully
[0000.086] W> No valid slot number is found in scratch register
[0000.092] W> Return default slot: _a
[0000.095] I> Active Boot chain : 0
[0000.098] I> Boot-device: QSPI
[0000.101] I> Qspi flash params source = brbct
[0000.107] W> MB1_PLATFORM_CONFIG: device prod data is empty in MB1 BCT.
[0000.115] I> Temperature = 27000
[0000.118] W> Skipping boost for clk: BPMP_CPU_NIC
[0000.122] W> Skipping boost for clk: BPMP_APB
[0000.126] W> Skipping boost for clk: AXI_CBB
[0000.130] W> Skipping boost for clk: AON_CPU_NIC
[0000.134] W> Skipping boost for clk: CAN1
[0000.138] W> Skipping boost for clk: CAN2
[0000.142] I> Boot-device: QSPI
[0000.145] I> Boot-device: QSPI
[0000.148] I> Qspi flash params source = mb1bct
[0000.152] I> Qspi using bpmp-dma
[0000.155] I> Qspi clock source : pllc_out0
[0000.159] I> Qspi reinitialized
[0000.162] I> Qspi flash params source = mb1bct
[0000.167] I> Qspi flash params source = mb1bct
[0000.172] I> ECC region[0]: Start:0x80000000, End:0x780000000
[0000.177] I> ECC region[1]: Start:0x0, End:0x0
[0000.181] I> ECC region[2]: Start:0x0, End:0x0
[0000.185] I> ECC region[3]: Start:0x0, End:0x0
[0000.190] I> ECC region[4]: Start:0x0, End:0x0
[0000.194] I> Non-ECC region[0]: Start:0x0, End:0x0
[0000.198] I> Non-ECC region[1]: Start:0x0, End:0x0
[0000.203] I> Non-ECC region[2]: Start:0x0, End:0x0
[0000.207] I> Non-ECC region[3]: Start:0x0, End:0x0
[0000.212] I> Non-ECC region[4]: Start:0x0, End:0x0
[0000.217] E> FAILED: Thermal config
[0000.224] E> FAILED: MEMIO rail config
[0000.242] I> DRAM ECC Scrub Mode: staged
[0000.300] I> Boot-device: QSPI
[0000.303] I> Qspi flash params source = mb1bct
[0000.312] I> Qspi flash params source = mb1bct
[0000.324] I> Qspi flash params source = mb1bct
[0000.391] I> Qspi flash params source = mb1bct
[0000.400] I> Qspi flash params source = mb1bct
[0000.432] I> Qspi flash params source = mb1bct
[0000.444] I> MB1 done

[0000.452] I> Welcome to MB2(TBoot-BPMP) (version: 00.00.2018.32-mobile-6fc80c72)
[0000.453] I> DMA Heap @ [0x526fa000 - 0x52ffa000]
[0000.453] I> Default Heap @ [0xd486400 - 0xd48a400]
[0000.454] E> DEVICE_PROD: Invalid value data = 70030000, size = 0.
[0000.460] W> device prod register failed
[0000.463] I> gpio framework initialized
[0000.467] I> tegrabl_gpio_driver_register: register 'nvidia,tegra194-gpio' driver
[0000.474] I> tegrabl_gpio_driver_register: register 'nvidia,tegra194-gpio-aon' driver
[0000.482] I> No valid sdcard_params in mb1_bct
[0000.486] I> Boot-device: QSPI
[0000.489] I> Boot_device: QSPI_FLASH instance: 0
[0000.494] I> QSPI Flash Size = 64 MB
[0000.497] I> Qspi initialized successfully
[0000.501] I> qspi flash-0 params source = boot args
[0000.844] I> sdmmc DDR50 mode
[0000.855] I> sdmmc-3 params source = safe params
[0000.860] I> Found 51 partitions in QSPI_FLASH (instance 0)
[0000.877] W> Cannot find any partition table for 00000003
[0000.893] I> Found 11 partitions in SDMMC_USER (instance 3)
[0000.893] I> Staged scrubbing
[0001.102] W> No valid slot number is found in scratch register
[0001.103] W> Return default slot: _a
[0001.103] I> Active Boot chain : 0

Yes, I would suggest updating to the latest R32.7.4 to verify.

Are you using AGX Xavier or AGX Xavier Industrial?

Is you current requirement booting from internal eMMC?

I am using Jetson AGX Xavier Industrial (JAXi).

Looking at the flash configuration it has most of the partitions that used to be in SDMMC_BOOT in the QSPI now.

It will take me some time to update to 32.7.4… so if you have anything we can check in the meantime, that would be good.

Could you share flash log from your host and also the full serial console log from your board?

Hi Kevin,

Sorry for the delay.

Here you are the logs.

Regards
2023-10-10 host flash.sh log.txt (74.8 KB)
2023-10-10 jetson debug log during flash.txt (48.4 KB)
2023-10-10 boot log with boot_chain_select=0.txt (34.9 KB)
2023-10-10 boot log with boot_chain_select=1.txt (34.9 KB)

Do you have any custom layout changed in XML?

[0013.571] I> Boot-device: QSPI

It is expected result because we put bootloader in QSPI for JAXi.

Do you mean the following GPIO?

Why would you expect this pin changing the boot chain?

Yes, I know JAXi has the boot partitions in the QSPI and that is how it normally boots.

And yes, the GPIO you quote is the SOC_GPIO33 that I am referring to… as it says in your little table photo.

The pin is mentioned in the “Jetson AGX Xavier Series Interface Comparison and Migration” application note DA-10566-001v1.2

In page 8 (Safety MCU interfaces) referred tot GPIO12 pin pin as BOOT_CHAIN_SELECT strap.
In page 9 Figure 3 (Safety MCU Connections), referss to SOC_GPIO33/GPIO12/E10 as BOOT_CHAIN_SELECT.
In page 10 Table 3 (Connector Pin Function Differences) describes the JAXi usage for pin E10/GPIO12/SOC_GPIO33 as “GPIO. Also boot chain support for Safety enabled designs.”

Also, in the Fuse specification, it is saied: “Jetson AGX Xavier is supplied as configured to boot from straps.”

So that is why I expect it to work, but by all means let me knwo how to actually make i work and test it, please.

I’ve checked this topic with internal.
Boot chain select is used to switch between boot chains but does not switch boot device (QSPI and eMMC).

I’m checking the usage for this pin(SOC_GPIO33/GPIO12/E10).

The Jetson AGX Xavier Series Fuse Specification says in page 10:

Skip Boot Device Selection Straps
This fuse determines if the boot device selection is determined by the straps or by the
fuse settings.

So the question is, which is the strap that selects the device then, as this fuse (Boot Selection: FUSE_RESERVED_SW [2:0]) selects between eMMC and QSPI.

FUSE_RESERVED_SW seems not relating to BOOT_CHAIN_SELECT, and there’s no QSPI option for this config.

There IS an option for QSPI… please look at this:

Given that the spec says there are straps instead of fuses, which are they?

hello david.fernandez,

This fuse determines if the boot device selection is determined by the straps, or by the fuse settings.
it’s FUSE_BOOT_DEVICE_INFO=0x3 (default value) with bootstrap=true.

1 Like

Right, so when boot device selection is set to be determined by the straps… which are the straps (GPIOs or other) that select the boot device?

hello david.fernandez,

they’re reserved bits (i.e. Bit [2:0] Boot Device Select) for software (which read by Boot ROM) to identifies the OS image boot device.

Yes, I understand that if fuses are set to identify a valid boot device, they will work as such, and read by the BootROM.

What I am asking is, if the fuses are not set to identify a boot device, which is how we have them at the moment. What STRAPS do identofy the boot device?

hello david.fernandez,

please refer to pinmux spreadsheets, for those pins with *_STRAP.

Right, I can see those as GPIO3_PH3 | GPIO3_PH5, so I give those a go, and see what happens.

I take PH3=0 PH5=0 is eMMC and PH3=0 PH5=1 is QSPI?

boot mode select and boot_chain_select are two different thing.
Boot_chain_select is backup boot or default boot bins to be used. L4T by default provide to boot with default boot chain using MB1 bct config files.

Boot Mode select will not break the boot because JSEP software is developed for only QSPI primary boot. EMMC is only used for secondary storage.