Flashing with tegrarcm

I was wondering if anyone is successfully using tegra-uboot-flasher-scripts, or, more specifically the tegrarcm flasher with the TK1?

I’m trying to use it instead of nvflash to flash a Jetson-TK1 and although no errors are reported, it looks like the bootloader isn’t actually flashed. Instead the Jetson boots as usual (with the previous u-boot flashed with nvflash).

During the supposed flashing with tegrarcm, nothing is sent to the serial console of TK1 - as opposed to flashing it with nvflash, which reports being in recovery mode and flash progress.

Output from tegra-uboot-flasher:

sudo ./tegra-uboot-flasher flash jetson-tk1  
+ cp /home/user/dev/tegra-uboot-flasher/_out/jetson-tk1/u-boot.dtb /tmp/tmpTHUA2e/u-boot-runflash.dtb
+ cd /tmp/tmpTHUA2e
+ fdtput -p -t x /tmp/tmpTHUA2e/u-boot-runflash.dtb /config bootdelay 0xfffffffe
bootcmd: echo >>> Verifying image in RAM... ; crc32 0x801be000 0x0007d200 0x80000000 ; if itest.l *0x80000000 != 0xf2eaf26a; then echo CRC MISMATCH of initial image; exit; fi ; echo >>> Selecting MMC device... ; mmc dev 0 1 ; echo >>> Writing image to MMC... ; mmc write 0x801be000 0 0x3e9 ; echo >>> Reading image back from MMC... ; mmc read 0x8023b200 0 0x3e9 ; echo >>> Verifying image from flash... ; crc32 0x8023b200 0x0007d200 0x80000000 ; if itest.l *0x80000000 != 0xf2eaf26a; then echo CRC MISMATCH of readback image; exit; fi ; echo >>> Setting up environment... ; env default -f -a ; saveenv ; echo >>> Flashing OK, rebooting... ; reset
+ cd /tmp/tmpTHUA2e
+ fdtput -p -t s /tmp/tmpTHUA2e/u-boot-runflash.dtb /config bootcmd echo >>> Verifying image in RAM... ; crc32 0x801be000 0x0007d200 0x80000000 ; if itest.l *0x80000000 != 0xf2eaf26a; then echo CRC MISMATCH of initial image; exit; fi ; echo >>> Selecting MMC device... ; mmc dev 0 1 ; echo >>> Writing image to MMC... ; mmc write 0x801be000 0 0x3e9 ; echo >>> Reading image back from MMC... ; mmc read 0x8023b200 0 0x3e9 ; echo >>> Verifying image from flash... ; crc32 0x8023b200 0x0007d200 0x80000000 ; if itest.l *0x80000000 != 0xf2eaf26a; then echo CRC MISMATCH of readback image; exit; fi ; echo >>> Setting up environment... ; env default -f -a ; saveenv ; echo >>> Flashing OK, rebooting... ; reset
+ cd /tmp/tmpTHUA2e
+ /tmp/tmpTHUA2e/flasher.sh
bct file: /home/user/dev/tegra-uboot-flasher/_out/jetson-tk1/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.bct
booloader file: /tmp/tmpTHUA2e/u-boot-flasher.bin
load addr 0x80108000
entry addr 0x80108000
device id: 0x7140
uid:  0x34001001740de102240000000bff8040
RCM version: 64.1
downloading miniloader to target at address 0x4000e000 (136920 bytes)...
miniloader downloaded successfully
Chip UID:                0x00000001740de102240000000bff8040
Chip ID:                 0x40
Chip ID Major Version:   0x1
Chip ID Minor Version:   0x1
Chip SKU:                0x81 (t124)
Boot ROM Version:        0x1
Boot Device:             0x2 (EMMC)
Operating Mode:          0x3 (developer mode)
Device Config Strap:     0x0
Device Config Fuse:      0x0
SDRAM Config Strap:      0x3
sending file: /home/user/dev/tegra-uboot-flasher/_out/jetson-tk1/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.bct
- 8192/8192 bytes sent
/home/user/dev/tegra-uboot-flasher/_out/jetson-tk1/PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.bct sent successfully
sending file: /tmp/tmpTHUA2e/u-boot-flasher.bin
/ 1257984/1257984 bytes sent
/tmp/tmpTHUA2e/u-boot-flasher.bin sent successfully

Has anyone encountered this behaviour?

Hello,
What version of u-boot you are using?
If you are using u-boot from TK1 L4T, please check the CONFIG_SPL_TEXT_BASE in u-boot source, and the offset in script tegra-uboot-flash ‘get_loadaddr’.
For example, u-boot for TK1 in R21, CONFIG_SPL_TEXT_BASE is defined @ include/configs/tegra124-common.h by 0x83D88000, so the offset in the script should be changed as:
def get_loadaddr():
# 0x00108000 is CONFIG_SPL_TEXT_BASE in U-Boot, minus RAM base

  • return soc[‘ram-base’] + 0x00108000
  • return soc[‘ram-base’] + 0x03D88000

You can see the updated u-boot is flashed and running.
In addition, you have to change/check the u-boot environment to boot kernel correctly.

(BTW: Tegra-uboot-flasher is set up to handle upstream/mainline U-Boot rather than L4T U-Boot.)

br
ChenJian

Hi Chen,
Thanks for your reply.

The failed attempts were made using the upstream version of U-Boot.
I followed the steps in https://github.com/NVIDIA/tegra-uboot-flasher-scripts/blob/master/README-developer.txt.
This pulls the latest U-Boot tree, where the load address matches, so I believe this is not the problem.

What is even more strange is that there is no output from the serial port. I expected to see some messages from the miniloader even before attempting to actually flash and execute U-Boot, am I getting this wrong?

Best regards,
Michael

There is no guarantee the up stream version of u-boot will work.

Nvidia have heavily customized u-boot for the Jetson.

I did a diff between u-boot latest and the Nvidia version once - too many diffs to get my head around.
Even if you diff the same version as the Nvidia versions is based on - there are many differences !

What are you looking for in u-boot ?

Same results here so far. Decided to try tegra-uboot-flasher-scripts since we struggle to make nvflash work on a custom board.

Even after correcting the loadaddr nothing happens. No output from miniloader, and nothing seems to be flashed. Same symptoms as OP.

No! I used CONFIG_SYS_TEXT_BASE instead of CONFIG_SPL_TEXT_BASE. When I fixed that, I got a print from u-boot.

Actually I don’t need the upstream version at the moment, but I assumed it should work because it is automatically pulled by tegra-uboot-flasher-scripts and the u-boot commit log shows quite a lot of activity by Nvidia for the relevant platforms - so I assumed it is tested.

The reason for trying tegrarcm is that we had some issues with on a custom board and I wanted to rule out problems with flashing u-boot by trying a different flasher other than nvflash.

To see if it works, I tried to flash the Jetson first.

BTW, The BCT files for the Jetson TK1 that come with L4T and those in cbootimage-configs are also not the same - could also be related, but I didn’t have time to investigate this.

Michael