使用thor模组进行开发，我们按照上电时序开发了mcu代码，已经通过示波器观测到thor发出SYS_RESET_N为高电平，但是lsusb没有检测到设备，dp也没有识别到显示信号，请问英伟达有其他调试手段吗？比如串口打印日志之类的，当前我们无法判断是bootloader问题还是硬件问题。
Hi,
Yes, UART log is always present on every Jetson board. Please refer to the design guide doc for the corresponding pin.
Thor模组在bootloader阶段不会打印任何信息吗？
This doc might be relevant? jetson_thor_tuningguide
3.3 UART
3.3.1 Overview
UARTs in the NVIDIA Jetson Thor Module support both 16450- and 16550-compatible
modes and all are identical in feature set. The maximum baud rate is 12.5 Mbps.
3.3.2 Required Equipment
The following equipment is required:
> Oscilloscope and Probe: Any oscilloscope and high impedance probe with a
bandwidth of 100 MHz or greater
> Software tool: devmem2 for Linux
3.3.3 Measurement
Measurement consists of the following steps:
1. Attach the probes to the DUT, as close to the end point as possible—nearest to the
receiver side.
2. Power on the DUT and check to see if the system has started properly.
3. Configure the DUT to drive traffic. Start sending data to the specified UART port.
4. Check waveforms on the scope and modify the register if the output signal does not
meet specifications and signal integrity requirements.
NVIDIA Jetson Thor Series Modules I/O Functional Verification Guide DA-12308-001_v1.1 | 23
3.3.4 UART Signal Drive Strength Control
The following table lists UART instances in Thor Module and related Drive Strength
Control registers.
Table 3-4. UART Drive Strength Control Registers
UART
Instance Address Drive Strength Control Register
CFG_CAL_
DRVUP
Bit field
CFG_CAL_
DRVDN
Bit field
UART0 0x0c7a302c PADCTL_SYS_AO_2_CFG2TMC_UART0_TX_0 [23:20] [15:12]
UART0 0x0c7a3034 PADCTL_SYS_AO_2_CFG2TMC_UART0_RX_0 [23:20] [15:12]
UART4 0x810c2870cc PADCTL_G4_CFG2TMC_UART4_TX_0 [23:20] [15:12]
UART4 0x810c2870c4 PADCTL_G4_CFG2TMC_UART4_RX_0 [23:20] [15:12]
UART4 0x810c2870bc PADCTL_G4_CFG2TMC_UART4_RTS_N_0 [23:20] [15:12]
UART4 0x810c2870b4 PADCTL_G4_CFG2TMC_UART4_CTS_N_0 [23:20] [15:12]
UART5 0x810c281074 PADCTL_G2_CFG2TMC_UART5_TX_0 [23:20] [15:12]
UART5 0x810c28106c PADCTL_G2_CFG2TMC_UART5_RX_0 [23:20] [15:12]
UART5 0x810c281064 PADCTL_G2_CFG2TMC_UART5_RTS_N_0 [23:20] [15:12]
UART5 0x810c28105c PADCTL_G2_CFG2TMC_UART5_CTS_N_0 [23:20] [15:12]
UART9 0x810c28206c PADCTL_G3_CFG2TMC_UART9_TX_0 [23:20] [15:12]
UART9 0x810c282064 PADCTL_G3_CFG2TMC_UART9_RX_0 [23:20] [15:12]
UART9 0x810c28205c PADCTL_G3_CFG2TMC_UART9_RTS_N_0 [23:20] [15:12]
UART9 0x810c282054 PADCTL_G3_CFG2TMC_UART9_CTS_N_0 [23:20] [15:12]
UART10 0x810c28102c PADCTL_G2_CFG2TMC_UART10_TX_0 [23:20] [15:12]
UART10 0x810c281024 PADCTL_G2_CFG2TMC_UART10_RX_0 [23:20] [15:12]
UART10 0x810c28101c PADCTL_G2_CFG2TMC_UART10_RTS_N_0 [23:20] [15:12]
UART10 0x810c281014 PADCTL_G2_CFG2TMC_UART10_CTS_N_0 [23:20] [15:12]
3.3.5 Drive Strength Adjustment
UART drive strength adjustment is achieved by providing offsets to the pull-up and pull-
down pads. For example, UART0_TX pad pull-up and pull-down drive strength controls
are mapped at 0x0c7a302c.
Steps:
1. Set up an oscilloscope to probe UART0 signals.
2. Boot up the DUT and open a command console through UART or over ethernet from
the DUT.
3. Start sending data on UART0_TX. UART0 is used for Thor serial console and USB
debug on developer system. UART0_TX on the developer system has a pull-up
resistor and will be at logic high initially.
NVIDIA Jetson Thor Series Modules I/O Functional Verification Guide DA-12308-001_v1.1 | 24
4. Check waveform and modify the register if the signal does not meet specifications.
Linux
(a) # devmem2 0x0c7a302c
(b) Modify bits [23:20] and [15:12] in the register value read at (a)
(c) # devmem2 0x0c7a302c <new value generated at (b)>
5. The tuning is complete when the signal meets specifications and signal integrity
requirements.
Note: Make sure that the final calibrated codes do not overflow when adjusting drive
strength.
In addition, make sure that the values of CFG_CAL_DRV_UP/CFG_CAL_DRV_DN are within
the range 0xF and 0x0.
jetson-thor-series-modules-designguide-dg12084001-v1.3.pdf
17.2.2 Debug UART
Jetson Thor provides UART3_DEBUG for debug purposes. The connections are described
in the following table.
Table 17-3. Debug UART Connections
Module Pin Name Type Termination Description
UART3_TX_DEBUG O UART Transmit: Connect to RX pin of serial device
UART3_RX_DEBUG I If level shifter is implemented, 100 kΩ
pull-up to supply on the non-Thor module side of the device.
UART Receive: Connect to TX pin of serial device
UART3 is correct for the debug UART. Do you have TX/RX mapped correctly, e.g. THOR_UART3_TX_DEBUG net connected to the RX of the other side?
Is this a custom carrier board or the Jetson Thor Dev Kit? If a custom board, have you used an oscilloscope to verify it follows the Power-On Sequence in section 5.1.1 of the Jetson Thor Series Modules Interface Design Guide?
thanks，我们已经定位出串口无打印的原因，是因为flash没有固件，因此我们使用官方jetson thor agx kit底板对我们的模组进行烧录后，再使用自研的底板启动，仍然启动失败，请帮忙分析以下原因，谢谢。我们底板没有使用eeprom，按照
修改cvb_eeprom_read_size = <0x0> 之后仍然无法烧录
以下是串口打印日志：
error.log (420.7 KB)
cd LinuxforTegra
sudo grep -Rns "cvb_eeprom_read_size" bootloader | grep tegra264
# Edit and change all <0x100> to <0x0>
bootloader/tegra264-mb2-bct-common.dtsi:106: cvb_eeprom_read_size = <0x100>;
bootloader/generic/BCT/tegra264-mb2-bct-common.dtsi:106: cvb_eeprom_read_size = <0x100>;
bootloader/generic/BCT/tegra264-mb2-bct-misc-p3834-0008-p3740-0002.dts:51: cvb_eeprom_read_size = <0x100>;
I think you may need to
sudo rm -rf tools/kernel_flash/images
sudo rm bootloader/flashcmd.txt bootloader/tegraflash*.log
May I ask if these two BCTs have exactly the same content but different purposes? Is it actually using the bootloader directory?
Linux_for_Tegra/bootloader/generic/BCT/tegra264-mb2-bct-common.dtsi
Linux_for_Tegra/bootloader/tegra264-mb2-bct-common.dtsi
It might be prudent to modify the 3 dtsi files
The two tegra264-mb2-bct-common.dtsi files are identical. I have not been able to determine if either file has a distinct purpose. It looks like the one that is most clearl used is Linux_for_Tegra/bootloader/generic/BCT/tegra264-mb2-bct-common.dtsi.
It gets harder to follow when looking at binary file bootloader/tegrabct_v2 and its a copy here unified_flash/tools/flashtools/flash/tegrabct_v2; that also contain “cvb_eeprom_read_size“.
And these python files also execute tegrabct_v2
unified_flash/tools/flashtools/flash/tegraflash_impl_t234.py:92: 'tegrabct': 'tegrabct_v2',
unified_flash/tools/flashtools/bootburn_t264_py/bootburn_bct.py:849: # Execute tegrabct_v2 to generate BCT
unified_flash/tools/flashtools/bootburn_t264_py/target_config.py:731: self.flashUtils.f_TegraBct = os.path.join(flashToolsOutDir, "tegrabct_v2-hostcc"
unified_flash/tools/flashtools/bootburn_t264_py/flash_utilities.py:32: f_TegraBct = "tegrabct_v2"
bootloader/tegraflash_impl_t264.py:88: 'tegrabct': 'tegrabct_v2',
bootloader/tegraflash_internal.py:61:tegraflash_binaries_v2 = { 'tegrabct':'tegrabct_v2'
These files include tegra264-mb2-bct-common.conf
Linux_for_Tegra$ sudo grep "tegra264-mb2-bct-common" . -irHn
./bootloader/generic/BCT/tegra264-mb2-bct-misc-p3834-xxxx-p4071-0008.dts:42:#include "tegra264-mb2-bct-common.dtsi"
./bootloader/generic/BCT/tegra264-mb2-bct-misc-p3834-xxxx-p4071-0000.dts:42:#include "tegra264-mb2-bct-common.dtsi"
./bootloader/generic/BCT/tegra264-mb2-bct-misc-p3834-0008-p3740-0002.dts:42:#include "tegra264-mb2-bct-common.dtsi"
./bootloader/generic/BCT/tegra264-mb2-bct-misc-p3834-xxxx-p3971-0000.dts:42:#include "tegra264-mb2-bct-common.dtsi"
# And these #include those files
Linux_for_Tegra$ sudo grep "tegra264-mb2-bct-misc-p3834-xxxx-p4071-000" . -irHn
./p3834-0008-p4071-0008-ufs.conf:58:MB2_BCT="tegra264-mb2-bct-misc-p3834-xxxx-p4071-0008.dts";
./p3834-0008-p4071-0000-nvme.conf:58:MB2_BCT="tegra264-mb2-bct-misc-p3834-xxxx-p4071-0000.dts";
Hi,
I have the same failture
Modified the 3 dtsi files is not work for me
but it works by add “SKIP_EEPROM_CHECK=1“ when flash
What’s the different?
我修改Linux_for_Tegra/bootloader/tegra264-mb2-bct-common.dtsi 之后问题解决了，我不是很清楚你的硬件设计。首先使用已烧录镜像的thor模组插入你的基板，然后串口抓取日志，需要确认问题确实是eeprom error导致，以上dtsi的修改才有效。