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
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.
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…
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?
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?