Using X1 Module on Different Embedded Board

We have our own embedded board that we are trying to use the X1 module on. I thought I would be able to program the module on my jetson dev board and then simply move it to the new board and it would work. However, it is hanging very early - even before u-boot starts. It appears that the TegraBoot bootloader may be jetson-dev-board-centric? Is there a way to configure the X1 bootloader and u-boot/kernel image to not assume it’s on a dev board? I’ve copied the console output below. You can see it mentions configuring a MAX77620 chip which exists on the dev board but not on our board. Thanks for any help.

[0000.167] [TegraBoot] (version 23.00.2015.14-mobile-1ef66670)
[0000.173] Processing in cold boot mode Bootloader 2
[0000.178] A01 Bootrom Patch rev = 31
[0000.181] Power-up reason: reset button
[0000.185] No Battery Present
[0000.187] Platform has Ddr4 type ram
[0000.191] max77620 disabling SD1 Remote Sense
[0000.195] Setting Ddr voltage to 1125mv
[0000.199] Serial Number of Pmic Max77663: 0x50ea4
[0000.207] Entering ramdump check
[0000.210] Get RamDumpCarveOut = 0x0
[0000.213] RamDumpCarveOut=0x0, RamDumperFlag=0xe59ff3f8
[0000.218] Last reboot was clean, booting normally!
[0000.223] Sdram initialization is successful
[0000.227] SecureOs Carveout Base=0xff800000 Size=0x00800000
[0000.233] GSC1 Carveout Base=0xff700000 Size=0x00100000
[0000.259] GSC2 Carveout Base=0xff600000 Size=0x00100000
[0000.285] GSC3 Carveout Base=0xff500000 Size=0x00100000
[0000.290] GSC4 Carveout Base=0xff400000 Size=0x00100000
[0000.295] GSC5 Carveout Base=0xff300000 Size=0x00100000
[0000.300] BpmpFw Carveout Base=0xff2c0000 Size=0x00040000
[0000.305] Lp0 Carveout Base=0xff2bf000 Size=0x00001000
[0000.321] RamDump Carveout Base=0xff23f000 Size=0x00080000
[0000.326] Platform-DebugCarveout: 0
[0000.330] Nck Carveout Base=0xff03f000 Size=0x00200000
[0000.380] Using GPT Primary to query partitions
[0000.385] Loading Tboot-CPU binary
[0000.435] Verifying bootloader in OdmNonSecureSBK mode
[0000.444] Bootloader load address is 0xa0000000, entry address is 0xa0000258
[0000.454] Bootloader downloaded successfully.
[0000.458] Downloaded Tboot-CPU binary to 0xa0000258
[0000.463] MAX77620_GPIO1 Configured.
[0000.467] MAX77620_GPIO5 Configured.
[0000.470] CPU power rail is up
[0000.473] CPU clock enabled
[0000.477] Performing RAM repair

All I can tell you is that the TX1 is very sensitive to proper power sequencing. Make sure you’re following Big N’s OEM guide.

You mean you developed your own carrier board and want to use X1 module board on it? If so, Max77620 chip is already on module board as the PMU of X1 chip, it can not be ignored.

@AlexP312: sounds like you are talking from personal experience. Can you share what happened in your case? I’ve been told we just provide 12V to the module and toggle the power button signal. Is there more that we should worry about?

@Trumany: yes, we thought the MAX77620 chip was on the dev kit board but realized after my post that it is actually on the module. Can you provide any insight on why it may be stuck at the “Performing RAM Repair” step? Or any advice on how to get more debug information from the COP boot process?

@Trumany: yes, we have developed our own carrier board and want to use the X1 module board on it.

Section 4.3 of the OEM guide details how power is to be delivered to the TX1. It’s not as simple as providing 12V.

dsillman,

A platform porting guide to describe what needs to be modified when adapting from Jetson dev board to your custom board will be included in our next r24.1 release. The release is targeted next 2-3 weeks. For a normal boot up process,

you should see tegraboot first as the message you listed out. U-boot will then be loaded and started. Finally kernel is ran. Here is some log info in my Jetson dev board for your reference,

[TegraBoot] (version 24.00.2015.42-mobile-d580f895)^M
[0000.163] Processing in cold boot mode Bootloader 2^M
[0000.168] A02 Bootrom Patch rev = 31^M
[0000.171] Power-up reason: reset button^M
[0000.175] No Battery Present^M
[0000.178] Platform has Ddr4 type ram^M
[0000.181] max77620 disabling SD1 Remote Sense^M
[0000.185] Setting Ddr voltage to 1125mv^M
[0000.190] Serial Number of Pmic Max77663: 0xe18a8^M
[0000.197] Entering ramdump check^M
[0000.200] Get RamDumpCarveOut = 0x0^M
[0000.203] RamDumpCarveOut=0x0, RamDumperFlag=0xe59ff3f8^M
[0000.209] Last reboot was clean, booting normally!^M
[0000.213] Sdram initialization is successful ^M
[0000.217] SecureOs Carveout Base=0xff800000 Size=0x00800000^M
[0000.223] GSC1 Carveout Base=0xff700000 Size=0x00100000^M
[0000.228] GSC2 Carveout Base=0xff600000 Size=0x00100000^M
[0000.233] GSC3 Carveout Base=0xff500000 Size=0x00100000^M
[0000.238] GSC4 Carveout Base=0xff400000 Size=0x00100000^M
[0000.243] GSC5 Carveout Base=0xff300000 Size=0x00100000^M
[0000.248] BpmpFw Carveout Base=0xff2c0000 Size=0x00040000^M
[0000.254] Lp0 Carveout Base=0xff2bf000 Size=0x00001000^M
[0000.269] RamDump Carveout Base=0xff23f000 Size=0x00080000^M
[0000.274] Platform-DebugCarveout: 0^M
[0000.278] Nck Carveout Base=0xff03f000 Size=0x00200000^M
[0000.318] Using GPT Primary to query partitions ^M
[0000.323] Loading Tboot-CPU binary^M
[0000.372] Verifying bootloader in OdmNonSecureSBK mode^M
[0000.382] Bootloader load address is 0xa0000000, entry address is 0xa0000258^M
[0000.391] Bootloader downloaded successfully.^M
[0000.396] Downloaded Tboot-CPU binary to 0xa0000258^M
[0000.401] MAX77620_GPIO1 Configured.^M
[0000.405] MAX77620_GPIO5 Configured.^M
[0000.408] CPU power rail is up^M
[0000.411] CPU clock enabled^M
[0000.415] Performing RAM repair^M
[0000.418] Updating A64 Warmreset Address to 0xa00002e9^M
[0000.435] Bootloader DTB Load Address: 0x83000000^M
[0000.451] Kernel DTB Load Address: 0x83080000^M
[0000.456] Loading cboot binary^M


U-Boot 2015.07-rc2-gc19a2f8 (Mar 15 2016 - 15:45:22 -0700)
TEGRA210
Model: NVIDIA P2371-2180
DRAM: 4 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1


Starting kernel …
[ 0.000000] Initializing cgroup subsys cpu^M
[ 0.000000] Initializing cgroup subsys cpuacct^M
[ 0.000000] Linux version 3.10.96-tegra (chuang@dhcp-172-17-154-240) (gcc version 4.9.x-google 20140827 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Mar 15 15:49:28 PDT 2016^M
[ 0.000000] CPU: Cortex A57 Processor [411fd071] revision 1^M
[ 0.000000] alternative: enabling workaround for ARM erratum 832075^M
[ 0.000000] Machine: jetson_cv^M
[ 0.000000] bootconsole [earlycon0] enabled^

Hi Chijen,
I’m the hardware designer responsible for the board that Dsillman has been working on.
Does your reply mean that there are some customizations that are required in order for a custom carrier board to boot successfully?

As for the power up sequence, specified in figure3 of section 4.3 of your OEM design guide- Does the power management system require a state change on RESET_OUT# for the system to complete boot? In our system, we have a pull up to the power on the carrier board. Is there a specific timing requirement for when this state change occurs?

additionally- Reset_out# is listed as an output in other parts of your documentation- can you clarify whether it is an input or output?

Thanks-

@Chijen,
Thanks for you listing. However, this same X1 module works fine on our Jetson carrier board and I can see the normal, successful, serial console output there. We are trying to figure out why it hangs at the ram repair statement on our custom carrier board when using the same module. Do we need to program the module differently? I would not expect the tegra bootloader to require details about the carrier board but the serial output stops even before it gets to u-boot. Since tegra-boot is closed source, it’s hard to figure out what the reasons are that it might stop there.

Generally RESET_OUT# is controlled internally by module, also it can be set to short to GND on carrier board manually for entering Boundary Scan test mode, that’s why it can be regarded as an output from carrier board.

Just remind, did you put BOARDID EEPROM (chip U11) on your own carrier board same as Jetson TX1? If not, you can try connecting that of Jetson TX1 to your board.

We don’t have that chip since it was not called out as a requirement in the OEM Design Guide. Could this be causing our issue? Is there a spec on what data needs to go in there? Is this really required? It will be difficult to add it onto our board now. Is there a way to work around the need for this chip - like a modified bootloader?
Thanks,
Debby

It is not mandatory, as you can uncomment the ‘BOARDID’ in the jetson-tk1.conf file. Did you check if it’s uncommented?

We are using the X1 module (NOT the K1). There is a jetson-tx1.conf file in the root directory that is a soft link to the p2371-2180-devkit.conf file. It does not have anything in it called ‘BOARDID’. I’ve copied the contents below:

#
# p2371-2180-devkit.conf: configuration for Jetson-TX1 devkit                                                                                                                                                                         

ODMDATA=0x84000;
NET_BSF=;
EMMC_BSF=;
EMMC_BCT=P2180_A00_LP4_DSC_204Mhz.cfg;
EMMC_CFG=gnu_linux_tegraboot_emmc_full.xml;
BOOTPARTSIZE=8388608;
EMMCSIZE=31276924928;
ITS_FILE=;
SYSBOOTFILE=p2371-2180-devkit/extlinux.conf;
DTB_FILE=tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
DFLT_KERNEL=Image;
ROOTFSSIZE=14GiB;
CMDLINE_ADD="fbcon=map:0";
UBOOT_TEXT_BASE=0x8010e000;
UIMAGE_LABEL="Linux-tegra21";
target_board="t210ref";
ROOT_DEV="mmcblk0p1 ------------ internal eMMC.                                                                                                                                                                                       
        sda1 ----------------- external USB devices. (USB memory stick, HDD)                                                                                                                                                          
        eth0 ----------------- nfsroot via RJ45 Ethernet port.                                                                                                                                                                        
        eth1 ----------------- nfsroot via USB Ethernet interface.";
TEGRABOOT="bootloader/${target_board}/nvtboot.bin";
SOSFILE="bootloader/nvtboot_recovery.bin";
WB0BOOT="bootloader/${target_board}/warmboot.bin";
FLASHAPP="bootloader/tegraflash.py";
FLASHER="bootloader/${target_board}/cboot.bin";
BOOTLOADER="bootloader/${target_board}/p2371-2180/u-boot-dtb.bin";
UBOOT_WITH_TBOOT=yes;
BCFFILE="bootloader/${target_board}/cfg/board_config_p2597-devkit.xml";
INITRD="bootloader/l4t_initrd.img";
TBCFILE="bootloader/nvtboot_cpu.bin";
BPFFILE="bootloader/bpmp.bin";
TOSFILE="bootloader/tos.img";
EKSFILE="bootloader/eks.img";
FBFILE="bootloader/reserved_fb.xml";

[/code]

Sorry for mixing TX1 with TK1, this is a setting thread for TK1 from other topic, you can ignore this.

dsillman,
"I would not expect the tegra bootloader to require details about the carrier board but the serial output stops even before it gets to u-boot.
=> you are correct.

After RAM repair message, it should show
“[0000.418] Updating A64 Warmreset Address to 0xa00002e9” which is displayed by NvTbootConfigureCpuResetMode(). After that, boot process should transfer to cboot as you indicated.

I am checking why it would stop at ram repair code with dev knowing tx1 module is good and custom carrier board. What are the main delta with your boar comparing with Jetson carrier board?

Sorry cboot should be u-boot for L4T BSP.

For tx1 boot process, not sure if you are aware of the info in the wiki,
ftp://download.nvidia.com/tegra-public-appnotes/t210-nvtboot-flow.html

cboot is cpu boot and is u-boot for L4T as you know.
For tx1 boot process, not sure if you are aware of the info in the wiki,
ftp://download.nvidia.com/tegra-public-appnotes/t210-nvtboot-flow.html

cboot is cpu boot and is u-boot for L4T as you know.
For tx1 boot process, not sure if you are aware of the info in the wiki,

ftp://download.nvidia.com/tegra-public-appnotes/t210-nvtboot-flow.html

The porting guide I mentioned earlier is mainly to review and change pinmux, device tree and configuration header files to reflect your board design. The issue you currently have seems still inside tboot.