Xavier NX 16 GB module flashed as 8 GB w/ L4T 32.7.1

Hi,

I’m trying to flash my Xavier NX 16 GB (P3668-0003) module. I have tried using both the SDK manager and the sample root system but it always shows up as a 8 GB module using “free -m” and through the system monitor. I am using the Boson for FRAMOS carrier board with JetPack 4.6.1 (L4T r32.7.1). The module is flashed without errors and works flawlessly except for the reduced memory. My host system is 18.04 and the Xavier shows up as a 16 GB module through lsusb (ID 0955:7e19).

After some debugging there seems to be a mismatch between the L4T source files and the documentation where the following two files relevant to the 16GB version are missing;
p3509-0000+p3668-0003-qspi-emmc.conf
p3509-0000+p3668-0003-qspi.conf

For reference:
L4T R32.7.1 Driver download.
L4T R32.7.1 Documentation.

As I have only flashed a few devkits previously it would be great if someone could point me in the right direction.

I don’t know how you prepared the driver package. But you can actually just use the one from sdkmanger.

It will be under~/nvidia if you didn’t change the path.

Thank you for the quick response!

I prepared the driver package through sdk manager with the setup;
Product category: Jetson
Hardware configuration: Host machine
Target Hardware: Jetson Xavier NX modules
Target operating system: JetPack 4.6.1
Additional SDKs: Noone selected.

This generates the driver package in ~/nvidia/nvidia_sdk/JetPack_4.6.1_Linux_JETSON_XAVIER_NX_TARGETS/Linux_for_Tegra/

After the Jetson OS image is ready I download the BSP from connecttech (NX L4T r32.7.1 BSP) and follow their instructions on how to flash the device.
cti-flashing
I sent an email to connecttech support asking if this could be related to their BSP and they said it should have no impact on this.

I have also tried JetPack 4.6.0 applying the Xavier 16GB patch/overlay but even then it is only recognized as 8GB.
During this attempt I prepared the driver package through SDK manager → installed the connecttech BSP → applied the patch by moving the files to the correct folder and running ./apply_binaries.sh.

The third method I have tried is downloading the L4T Driver Package (BSP) and Sample Root Filesystem manually, extracting them to the correct folders (following the manual), installed the BSP similar to what I did above and flashing the device.

Using all three methods the device is flashed and boots just fine, but is only recognized as a 8GB device. The only noticeable deviation between the method I have used and the manual is the path of the prepared image is created in
“~/nvidia/nvidia_sdk/JetPack_4.6.1_Linux_JETSON_XAVIER_NX_TARGETS
instead of
“~/nvidia/nvidia_sdk/JetPack_4.6.1_Linux_JETSON_XAVIER_NX_DEVKIT
I can’t however find an option to create an image specifically for the devkit, and I would recon this only changes the device tree binaries (as well as some drivers) and should have no impact on the module memory similar to the BSP from connecttech.

Please check the “Overlay to support Jetson Xavier NX 16GB” of below link and see if these files are still there after you apply the vendor’s BSP or not.

I didn’t ask you to put these tarball to your BSP. I just want you to check if these files are missing.

Those files are there in the JetPack 4.6.1 image installed through sdk manager after installing the BSP.
If i compare them directly with the files from the overlay (even though it is for JetPack 4.6) using “diff” then both the .cfg and .dtb files differ from the patch. Not sure if that is helpful though.

Edit: “… after installing the BSP”

No need to compare the bpmp dtb. Just the cfg should be sufficient.

So the cfg from the patch for JetPack 4.6 and the one in JetPack 4.6.1 should be the same?
Having a closer look the only difference seems to be a linespace on line 6225…

Here is the .cfg from the JetPack 4.6 overlay:
FROM_OVERLAY_4.6_tegra194-mb1-bct-memcfg-p3668-0001-a00.cfg (805.0 KB)

Here is the .cfg from JetPack 4.6.1:
FROM_JETPACK_4.6.1_tegra194-mb1-bct-memcfg-p3668-0001-a00.cfg (805.0 KB)

Just a comment wrt. the naming.

The P3668-0001 is the ID for the Xavier NX 8GB while the 16GB module should be P3668-0003. I can understand overwriting the 8GB memcfg as a patch for support of the 16GB module, but as JetPack 4.6.1 supports both I would expect there to be a separate memcfg-file for the 16GB module?

You can check the board config file under Linux_for_Tegra and it will indicate which mem cfg file is in use.

Our mem cfg file contains multiple DRAM spec. That is why that cfg file has SDRAM[0] ~ SDRAM[3].

And it will choose which DRAM parameters to use according to the hardware pin. Which we call the strap pin.

I mean there is one mem cfg file for multiple kind of jetson NX.

Alright, thank you for the explanation!

When flashing using the script from connecttech I use the following config:
fsm-imx335-4cam.conf (1.8 KB)

It contains the line;
source “${LK_DIR}/p3668.cti-base.conf”

Which is the file:
p3668.cti-base.common (6.2 KB)

This one uses the correct cfg file:
EMMC_BCT=“tegra194-mb1-bct-memcfg-p3668-0001-a00.cfg”

Different from the p3668.conf.common from the L4T it also hard codes RAMCODE=1 with the function;

process_board_version()
{
	local board_id="${1}";
	local board_version="${2}";
	local board_sku="${3}";
	local board_revision="${4}";
	local chiprev="${5}";

	if [ "${board_id}" = "3668" ] && [ "${board_version}" = "301" ]; then
		# Jetson Xavier NX A03 uses RAMCODE 1
		RAMCODE=1
	fi;
	echo "Board ID(${board_id}) version(${board_version}) sku(${board_sku}) revision(${board_revision})"
}

(The below function is the one in the L4T R32.7.1 p3668.conf.common for comparison.)

process_board_version()
{
	local board_id="${1}";
	local board_version="${2}";
	local board_sku="${3}";
	local board_revision="${4}";
	local chiprev="${5}";

	echo "Board ID(${board_id}) version(${board_version}) sku(${board_sku}) revision(${board_revision})"
}

Now I am not sure what “board version” the 16GB is or which version of the Xavier that is A03, but at least hard coding RAMCODE seems suspicious. Am I on to something? Would setting the RAMCODE to something different use another DRAM spec, and in that case, which one should I use for the 16GB module?

Hi,

The ramcode is the problem. Looks like your board vendor didn’t provide a BSP that is really from jp4.6.1 (32.7.1)…

Alright thank you, do you have a quick fix for this or should I continue the conversation with connecttech?

Follow what the original board config we provided in SDKM. At least remove that RAMCODE=1 from the cfg file.

1 Like

And “TRIM_DTB” is also needed to be removed, if I remember correctly.

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