NVIDIA Jetson Xavier NX Booting issue on Custom Carrier Board

Hi folks ,

I am trying to compare my booting logs with devkit booting logs.
Below are the logs point which i am not getting in my Jetson Xavier NX Custom board booting process

  1. in CPU-BL Params @ 0xf2820000 below 2 base address not configured in my booting process
    → Base:0xf2000000 Size:0x00200000
    → Base:0xf1200000 Size:0x00200000

(this things observe 2-3 times then in 4th continuous auto reboot it will come proper
([0000.996] I> Cboot Version: t194-9efcbc4f
[0000.998] I> CPU-BL Params @ 0xf2820000
[0001.002] I> 0) Base:0x00000000 Size:0x00000000
[0001.006] I> 1) Base:0xf1100000 Size:0x00100000
[0001.011] I> 2) Base:0xf2000000 Size:0x00200000
[0001.015] I> 3) Base:0xf1200000 Size:0x00200000
)

  1. Booting stuck after
    [0001.998] I> sdmmc SDR mode
    [0002.012] I> -0 params source =

  2. after shucking in case 2 its start below booting process which are different from DevKit
    [0000.024] W> RATCHET: MB1 binary ratchet value 4 is too large than ratchet level 2 from HW fuses.
    [0000.033] I> MB1 (prd-version: 1.5.1.7-t194-41334769-98030a79)
    [0000.038] I> Boot-mode: Coldboot
    [0000.041] I> Chip revision : A02P
    [0000.044] I> Bootrom patch version : 15 (correctly patched)
    [0000.049] I> ATE fuse revision : 0x200
    [0000.053] I> Ram repair fuse : 0x0
    [0000.056] I> Ram Code : 0x0
    [0000.058] I> rst_source : 0x0
    [0000.061] I> rst_level : 0x0
    [0000.065] I> Boot-device: QSPI
    [0000.067] I> Qspi flash params source = brbct
    [0000.071] I> Qspi using bpmp-dma
    [0000.074] I> Qspi clock source : pllp
    [0000.078] I> QSPI Flash Size = 32 MB
    [0000.081] I> Qspi initialized successfully
    [0000.085] I> Active Boot chain : 0
    [0000.088] I> Boot-device: QSPI
    [0000.091] I> Qspi flash params source = brbct
    [0000.097] W> MB1_PLATFORM_CONFIG: device prod data is empty in MB1 BCT.
    [0000.105] I> Temperature = 25500
    [0000.108] W> Skipping boost for clk: BPMP_CPU_NIC
    [0000.112] W> Skipping boost for clk: BPMP_APB
    [0000.116] W> Skipping boost for clk: AXI_CBB
    [0000.120] W> Skipping boost for clk: AON_CPU_NIC
    [0000.124] W> Skipping boost for clk: CAN1
    [0000.128] W> Skipping boost for clk: CAN2
    [0000.132] I> Boot-device: QSPI
    [0000.135] I> Boot-device: QSPI
    [0000.138] I> Qspi flash params source = mb1bct
    [0000.142] I> Qspi using bpmp-dma
    [0000.145] I> Qspi clock source : pllc_out0
    [0000.149] I> Qspi reinitialized
    [0000.152] I> Qspi flash params source = mb1bct
    [0000.157] I> ECC region[0]: Start:0x0, End:0x0
    [0000.161] I> ECC region[1]: Start:0x0, End:0x0
    [0000.165] I> ECC region[2]: Start:0x0, End:0x0
    [0000.170] I> ECC region[3]: Start:0x0, End:0x0
    [0000.174] I> ECC region[4]: Start:0x0, End:0x0
    [0000.178] I> Non-ECC region[0]: Start:0x80000000, End:0x100000000
    [0000.184] I> Non-ECC region[1]: Start:0x0, End:0x0
    [0000.188] I> Non-ECC region[2]: Start:0x0, End:0x0
    [0000.192] I> Non-ECC region[3]: Start:0x0, End:0x0
    [0000.197] I> Non-ECC region[4]: Start:0x0, End:0x0
    [0000.202] E> FAILED: Thermal config
    [0000.210] E> FAILED: MEMIO rail config
    [0000.220] I> Boot-device: QSPI
    [0000.223] I> Qspi flash params source = mb1bct
    [0000.232] I> Qspi flash params source = mb1bct
    [0000.243] I> Qspi flash params source = mb1bct
    [0000.310] I> Qspi flash params source = mb1bct
    [0000.319] I> Qspi flash params source = mb1bct
    [0000.347] I> Qspi flash params source = mb1bct
    [0000.359] I> MB1 done

Please provide your suggestion if any
thank you in advance

How about sharing the full log instead of do the comparison by yourself?

JetCarrier_log_01 (9.6 MB)

one more input related to power up sequence ,
at the time of power ON power sequence looks similar with devKit , but after some time we observe continuous POWER_EN low pulse of 4.3uSec(continuous low pulse after some time of interval may be at that time reboot our system ) , that will drop 5.2V input to 4.8V at a fraction of time only.

Hi,

Please move to emmc module too since sdcard module is only for evaluation. For custom board, we suggest to test with emmc module.

Hi Wayne,

Actually we do same circuit in our carrier board as DeviKit , and we are testing with same SOM module which provided on DevKit .

is there any extra design guide we have to consider while designing Carrier board of Nvidia Jetson Xavier Nx / Nano ?

in our Carrier Board design there is no option for EMMC other then that we have below connection in our Carrier board .

  1. USB3.1 Signals are connected on USB3.1 USB Hub .
  2. USB2 signals connected on USB2 HUB .
  3. PCIe0 x4 signals connected with PCIe Switch and have x1 , x4 , x16 , M.2Key-M Socket connection as end point .
  4. PCIe1 x1 connected with M.2 Key-E .

Please suggest suitable booting option which option can work for me other then eMMC .

It is not regarding to your board. It is regarding to the module.

We have two kinds of module. Sdcard module is sold along with devkit and only for evaluation. For product and custom board, you should use the emmc module. And refer to the design guide document.

Yes , sorry for the mistake
eMMC16GB provided on SOM module .
i will try that option and provide update .

Hi Wayne,

can devkit SOM module test with custom carrier board , just for ensuring our production SOM module work at the time of our product run .
i ordered Production SOM module but it will take some time to arrive , can you please help me to boot devkit SOM module booting on Custom carrier board ?

in the same carrier board we are able to boot Nano SOM module (which is used in NANO DevKit) .

For devkit, it can boot both sd module and emmc module.

You should review your hardware design with the document. Nano can boot on your board does not mean your hardware design is ok for NX.

Hi Wayne,

Can you please give me some basic hit on which Hardware section i have to look more in details .
is there any thing interface level logs are present in booting sequence ?

can i get SOM schematic for my reference ?

I don’t work on hardware side so cannot give you any hint.

You can download the schematic on the download center.

Ok , you have any idea related to “https://opensource.antmicro.com/projects/jetson-nano-baseboard” Base Board similar design we implement in our design .

Thank you

No, I don’t know detail about custom board.

Ok thank you for prompt replay .

Just want to know, do you have devkit on your side? You can firstly compare your log on devkit and custom board.

It is pointless to file another topic without any new info shared.

Yes

I2C related logs difference

NX SOM + Dev Kit

I2C 0 : 0x50 [SOM EEPROM: 200 J) , 0x57 (NX Dev Kit EEPROM : 100 G)
I2C 1 : 0x50 [ Not known : XXXX]

================================================================================

NX SOM + JC96(Custom Carrier board )

I2C 0 : 0x50 [SOM EEPROM: 200 J] , 0x57 (JC96 Kit EEPROM : XXXX)
I2C 1 : 0x50 [ Device Not found ]

[0001.535] I> Adding plugin-manager/ids/3668-0000-200=/i2c@3160000:module@0x50
[0001.543] W> “i2c@3160000” doesn’t exist, creating
[0001.547] W> “module@0x50” doesn’t exist, creating
[0001.552] I> Adding plugin-manager/ids/3509-0000-100=/i2c@3160000:module@0x57
[0001.559] W> “module@0x57” doesn’t exist, creating
[0001.563] I> Adding plugin-manager/ids/XXXX-XXXX-XXX=/i2c@c240000:module@0x50

In Custom Carrier board reboot happen after “:regulator ‘vdd-sdmmc1-sw’ already enabled”

[0001.827] I> config: mem-type:ff,power-config:ff,misc-config:ff,modem-config:ff,touch-config:ff,display-config:ff, len: 93
[0001.838] I> Found sdcard
[0001.843] I> enabling ‘vdd-sdmmc1-sw’ regulator
[0001.849] I> regulator ‘vdd-sdmmc1-sw’ already enabled
ÿâ

( ---- ReBoot --------)
[0000.024] W> RATCHET: MB1 binary ratchet value 4 is too large than ratchet level 2 from HW fuses.

Is there any SD card Speed gread selection in CBoot code ?
I believe this will reboot in Cboot mode logs right ?

Before doing any comparison of the logs, just want to recap some basic concepts here.

If your SOM is able to boot up fine on the devkit, and then fails to boot up on custom board with same software installed, then you need to check your hardware design. Read the design guide document. This is more helpful than checking the logs.

For example, if you suspect sdcard speed selection code in cboot, then why does same software can boot up fine on devkit? The answer is obvious due to different hardware board.

And back to the log you paste.

The eeprom looks has nothing to do with your issue. If the SOM eeprom is able to get read fine, then there should be no other eeprom info needed.

For that sdcard problem, if you want to dig into, my suggestion is you can download the cboot source code, go to that file where prints the “Found sdcard” and add some debug print to see why it fails somewhere.

Yes we are trying to add cboot logs and will update you.

regarding EPROM logs ,

why in custom board logs “3509-0000-100-G” not present ?

in Devkit logs we have :-
[0001.754] I> create_pm_ids: id: 3668-0000-200-J, len: 15
[0001.759] I> config: mem-type:00,power-config:00,misc-config:00,modem-config:00,touch-config:00,display-config:00, len: 93
[0001.770] I> create_pm_ids: id: 3509-0000-100-G, len: 15
[0001.775] I> config: mem-type:00,power-config:00,misc-config:00,modem-config:00,touch-config:00,display-config:00, len: 93
[0001.786] I> create_pm_ids: id: XXXX-XXXX-XXX-X, len: 15
[0001.791] I> config: mem-type:ff,power-config:ff,misc-config:ff,modem-config:ff,touch-config:ff,display-config:ff, len: 93

in Carrier logs we have :-
create_pm_ids: id: 3668-0000-200-J, len: 15
config: mem-type:00,power-config:00,misc-config:00,modem-config:00,touch-config:00,display-config:00, len: 93
create_pm_ids: id: XXXX-XXXX-XXX-X, len: 15
config: mem-type:ff,power-config:ff,misc-config:ff,modem-config:ff,touch-config:ff,display-config:ff, len: 93
Adding plugin-manager/ids/3668-0000-200=/i2c@3160000:module@0x50

is there any dependency on I2C0 line Address 0x57 internal EEPROM in Booting process of Xavier NX ?

There are two eeporm on the devkit, 0x50 is the SOM module. 0x57 is the carrier board eeprom.

p3668 is the id of SOM and p3509 is the carrier board id.

Only the SOM info is needed and will affect the boot. The carrier board eeprom will not.

Take this more easier to understand, you are not the only one who would make custom boards here. Other vendors also don’t make eeprom on their board. So this does not matter.