Jetson Thor (T5000) Custom Carrier Board Design: Power Architecture & EEPROM Configuration

Robotics & Edge Computing Jetson Systems Jetson Thor
,
1

Dear NVIDIA Technical Support / FAE Team,

Our team is currently in the early evaluation phase of developing a custom carrier board for the NVIDIA Jetson Thor (T5000) module. To ensure hardware reliability and compatibility with the Linux for Tegra (L4T) software stack, we would like to consult you on the following technical aspects:

1. Power Supply Design: Transitioning to USB Type-C (PD)

We are evaluating the feasibility of using a USB Type-C port as the primary power source instead of a traditional DC Jack.

  • PD Standards Support: Given the high power requirements of the T5000 module, do you recommend using USB PD 3.0 (100W) or PD 3.1 (EPR, 140W/240W)? Does NVIDIA have preferred PD Controller reference designs?

  • Transient Current Management: T5000 can exhibit significant transient current spikes during heavy compute workloads. Are there specific recommendations for bulk capacitance or filtering when using a PD-negotiated voltage (e.g., 20V or 28V)?

  • Power-up Sequencing: How should we ensure that the system meets the Thor module’s power-on sequence requirements before the USB PD negotiation (CC Handshake) is fully completed?

2. General Hardware Design Precautions

Beyond power architecture, we are looking for specific guidance on:

  • Thermal Management: Are there updated guidelines for TDP budget allocation and cooling solutions for the T5000 during the initial design phase?

  • Signal Integrity (SI): For high-speed interfaces like PCIe Gen5, are there updated PCB stack-up recommendations or trace routing constraints specific to this platform?

3. EEPROM Configuration (cvb_eeprom_read_size)

Regarding the carrier board EEPROM configuration in the Device Tree / MB1 BCT:

  • If set to <0x0>: If we choose not to include an EEPROM on our custom carrier board and set cvb_eeprom_read_size = <0x0>, will this cause any critical errors in the UEFI stage or prevent specific drivers (e.g., PCIe, Camera) from loading correctly?

  • If maintained at <0x100>: If we decide to retain the EEPROM for compatibility, what is the required data format (Board ID, SKU, Serial Number)? Are there specific I2C bus requirements we must adhere to?

4. Documentation & Tools Request

Could you please provide or point us to the latest revisions of the following resources?

  • Jetson Thor Series Product Design Guide

  • Carrier Board Design Checklists

  • EEPROM Layout Specification for Jetson Thor

Thank you for your time and professional support. We look forward to your feedback.

4

Please refer to these documents:

The Jetson Thor Developer Kit Carrier Board uses USB-C as its primary power source and the carrier board design files include NVIDIA’s reference design for the USB PD.

7

Dear ChrisB_NV

Thank you for your response regarding the EEPROM configuration (cvb_eeprom_read_size).

Regarding our custom carrier board design, we would like to align with the NVIDIA Reference Design by including an onboard EEPROM to store board-specific ID and configuration data.

Could you please confirm if this approach is fully supported? Specifically, we want to ensure that:
Compatibility: The MB1/CBoot (or UEFI) and the Linux kernel can correctly parse our EEPROM data using the standard cvb_eeprom_read mechanism.
Configuration: If we follow the reference schematic for the EEPROM (I2C address and circuit), will the default cvb_eeprom_read_size settings work without significant modifications to the BSP?

8

The Design Guide covers this topic in Chapter 4, as below. NVIDIA software does not support that usecase.

The ID EEPROM (AT24C02D – U501) is a feature that is used for NVIDIA internal
purposes, but not useful on a custom design. A similar function may be desired for a
custom design, but the NVIDIA software will not interact with these devices and the
I2C address used by the developer kit carrier board ID EEPROM on the I2C1 interface
(7’h56) should be avoided.

9

Dear ChrisB_NV

Thank you for your clarification regarding the ID EEPROM.

Some of our customers are requesting a “lite” or simplified version of the original reference carrier board.

If we decide to maintain the original hardware design by keeping the EEPROM on the I2C1 interface, would it be possible for NVIDIA to provide the EEPROM binary (.bin) file?