I’m looking forward to seeing the porting guide because I know I will have to change the DTS file to better reflect our custom carrier board. And it sounds like I will also need a way to indicate that no board config eeprom is present. Hopefully this will all be covered in the porting guide.
The doc is not yet officially released but cut and paste the no-eeprom section here for your reference …
To flash with BOARDID if the design does not use EEPROM
BOARDID is either passed using an XML file during flashing or is read from EEPROM.
The flashing software uses the BOARDID from the XML file if provided; otherwise it
uses the EEPROM value. The file board_config_p2597-devkit.xml, shown below,
illustrates the XML file format.
Platform Adaptation and Bring-Up Guide
Platform Adaptation and Bring-Up Guide DA_07378-001_01 | 13
This flashing config file p2371-2180-devkit.conf passes the name of the XML file
as an option:
The file contains the processor module ID (type=“proc”), display board ID
(type=“display”), and power management unit ID (type=“pmu”). Since the
processor and PMU are on the same module in the development kit, they have the same
If you add new values for the board tag’s id property, you must add them to the list of
valid values in nvtboot.
We seem to have found one of the reasons for the boot failing-
the RESET_OUT#, when we originally designed our custom carrier, we assumed was an OUTPUT from the TX1 only.
We fed this signal into a FPGA. Since we did not need the RESET_OUT# signal anywhere in our logic, we did not program this pin. The Xilinx FPGA places a ~30Kohm pull-down resistor on unused pins, and this seems to be enough to drag the RESET_OUT# pin low enough to hold the TX1 in a reset state. When measured, the voltage was around 1.2-1.3V not 1.8.
We’ve now programmed the FPGA, and the board seems to boot fully-- some of the time. Other times, the system will still halt at the same Ram Repair message. In these cases, we’ll restart the system and the system boots.
If Nvidia has some specific requirements for timing of the Resets, and other signals- can you please provide, so that we can verify?
Did you try leaving RESET_OUT# float? Also ram repair could fail if JTAG_AP_TRST_L is pulled high.
The power up timing is described in Figure 3, chapter 4.3 of OEM design guide, if your power part design is same as TX1, the sequence will be same too.
Seems you connected some IOs to FPGA, have you checked if these FPGA pins status(PU/PD) are same as design guide?
What’s the main delta between your board and TX1?
1.What’s the VDD_CPU and VDD_Core voltage or total system current when the uart log stuck at “Performing RAM repair” , This is to check if there is suddenly shutdown.
2.The JTAG_AP_TRST_L is pull down on Module board, Do you have any connection on this signal to drive up the voltage, This may trigger the debug mode. please check the voltage on JTAG_AP_TRST_L.
We put a pull up resistor on JTAG_AP_TRST_L. When I removed it, the system boots consistently.
I don’t have access to VDD_CPU or VDD_Core, these are supplies on the Nvidia board, and i am debugging
our own custom carrier.
Trumany - I wanted to touch a bit more on this. I’ve got a new carrier board for the TX1 that I am starting bring up on which is not fully booting.
My power sequencing matches Figure 3 of section 4.3 in the Design Guide.
On this new carrier I have RESET_OUT# driving a gate of a BSS138 to turn on a LED. I thought it would be handy to see the state of the TX1 with an LED by looking at RESET_OUT#.
Is it possible this could have ill effects? IE not floating the RESET_OUT#?
Some vital signs I can see:
If I toggle POWER_BTN, I see the RESET_OUT# go high (my LED turns on)
–> After this I see more power draw (but not a lot) 160mA @ 12V.
If I toggle RESET_IN, I can see:
—> I see RESET_OUT# go low (my LED turns off momentarily)
—> I see my USB VBUS outputs from my USB power switches turn off (momentarily)
Per your info, the EN of BSS138 is high enable, right? If so, there should be a weak PD on the pin, what’s the value of this PD? Better to measure the voltage to see if it’s around 1.8V.
What you see the LED act related to POWER_BTN and RESET_IN shows it can work but need to measure the voltage of RESET_OUT#.
Yes BSS138 is high enable. I’ve de-populated the BSS138 so now RESET_OUT# is truly floating but the boot behaves the same, so the issue must be related to something else.
Only other thing “different” on this carrier is I do have local power rails that come up directly with VIN. (IE they don’t wait for CARRIER_PWR_ON, however I am still following the sequencing of Fig 3, sec 4.3.
Do you see that being an issue at all?
Here is what I am seeing (with RESET_OUT# floating).
- VIN comes up
- VIN_PWR_BAD# comes up to 5V about 20ms after VIN is stable
- CARRIER_PWR_ON and RESET_OUT# remain low at this time
- Board not booted yet (as intended, no POWER_BTN toggle yet)
- Power draw at VIN @12V is 40mA
- POWER_BTN is toggled
- CARRIER_PWR_ON goes up to +3.3V
- RESET_OUT# goes up to +1.8V (10ms after CARRIER_PWR_ON is up)
- However still not boot (but power draw on VIN @12V is 180mA)
Any other vitals to check? I seem to see to action from UART0 either
when we were stuck in boot up of our custom board-there were still characters coming out on the Tx line of the serial port. If you put a Oscope probe on the TX line, you should see toggling on the line after Pwr button toggles. I believe the messages coming out initially are from the PMIC used on the Tx1 board.
I am also designing my own custom carrier board for the TX1 and have been following the NVIDIA Jetson TX1 Product OEM Design Guide in my design.
Based on my reading of this thread, I am concerned that this document does not fully capture the requirements for a custom carrier board (for instance, I don’t recall ever reading about the need for an external EEPROM in the OEM guide). Can NVIDIA confirm that this is the case? When can we expect to see the release of the additional OEM requirements document?
That EEPROM in carrier board is not a must in Jetson.
The upcoming r24.1 release contains a platform porting guide. Should be on next Monday.
Did you find a reason of the stuck?
I have made a second carrier board and found the same behaviour. Previous one worked well.
I cannot understand a difference for a while.
I would appreciate if you could share the result of your investigation. It may help me a lot.
In our case it was mistake in JTAG circuits.