Regarding flashing u-boot and system.img

hi,

I am using flash.sh jetson-tx1 mmcblk0p1 to program by tegra tx1 board.

Is it possible to flash the exact replica of system.img in other APP partition and boot from it to make as a recovery image in emmc device.?

If you use the same size of partition and both partitions used u-boot, then they are interchangeable. So if you used “-S 14580MiB” on one and then “-S 14GiB” on another, the larger one obviously would not have room and would get truncated. Although you could do something similar with fastboot, there would be further limitations (all kernel boot parameters would need to be the same and kernels would need to be the same).

If you clone the APP partition, and then later have issues, you could use the “-r” option of flash.sh to restore this image and it should be an exact match from the time of the clone. You can even loopback mount a cloned partition and use standard tools like rsync to incrementally update the clone to your current system.

The clone information on the JTK1 is very similar to JTX1, some information is available here:
[url]http://elinux.org/Jetson/Cloning[/url]

Commands for clone from a JTX1 are here:
[url]https://devtalk.nvidia.com/default/topic/898999/jetson-tx1/tx1-r23-1-new-flash-structure-how-to-clone-/post/4784149/#4784149[/url]

Hi,

My reference board comes with 16 GB emmc device. But while i am using flash.sh script to partition, I am able to use the device upto 32 GB and I am able to boot using the file system from APP2 partition also.

I am quite confused with this. Can u explain regarding this?

Please explain what is tos.img also.

*** PARTITION LAYOUT(24 partitions) ***
[ BCT] BH 0 8191 4.0MiB
[ NVC] BH 8192 16383 4.0MiB nvtboot.bin
[ PPT] UH 0 4095 2.0MiB
[ GP1] UH 4096 8191 2.0MiB
[ APP] UH 8192 10493951 5120.0MiB system.img
[ TBC] UV 10493952 10498047 2.0MiB nvtboot_cpu.bin
[ EBT] UV 10498048 10506239 4.0MiB u-boot-dtb.bin
[ BPF] UV 10506240 10510335 2.0MiB bpmp.bin
[ WB0] UV 10510336 10522623 6.0MiB warmboot.bin
[ RP1] UV 10522624 10530815 4.0MiB tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
[ TOS] UV 10530816 10543103 6.0MiB tos.img
[ EKS] UV 10543104 10547199 2.0MiB
[ FX] UV 10547200 10551295 2.0MiB
[ SOS] UV 10551296 10592255 20.0MiB
[ EXI] UV 10592256 10723327 64.0MiB
[ LNX] UV 10723328 10854399 64.0MiB
[ DTB] UV 10854400 10862591 4.0MiB tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
[ NXT] UV 10862592 10866687 2.0MiB
[ MXB] UV 10866688 10878975 6.0MiB
[ MXP] UV 10878976 10891263 6.0MiB
[ USP] UV 10891264 10895359 2.0MiB
[ APP2] UV 10895360 21381119 5120.0MiB system.img
[ APP3] UV 21381120 61067263 19378.0MiB
[ GPT] UH 61067264 61071359 2.0MiB

I do not know what changes are for the reference board you are using. What it comes down to is that there are multiple partitions for things other than the obvious root partition. Some of the layout changes with boot loader, and may not even be required if u-boot is used (versus fastboot).

I cannot guarantee the following observations, but this may help clarify or lead to more detailed questions:…

Fastboot does not read file systems, e.g., fastboot does not have knowledge of what ext4 is, nor is it able to find or read files on ext4…fastboot only reads binary data directly from a partition. U-boot understands ext4, and can find files on ext4. Both u-boot and fastboot must read and load firmware (the dtb files) prior to handing off to the kernel…so a partition is reserved for dtb in the case of fastboot, but the partition is not used under u-boot…instead u-boot reads the file named in the “/boot/extlinux/extlinux.conf” file’s FDT parameter. Even so, the fastboot dtb partition is still there even when using u-boot. The same is true of the kernel, u-boot reads a file on ext4, while fastboot uses the LNX partition as binary data…even if u-boot is chosen as boot loader, the LNX partition is still there and not needed. Some of those partitions are artifacts of other software and do not have meaning. Partitions with meaning tend to be support for the boot process up to the point where the kernel is loaded.

I couldn’t tell you which partition does what, but those hidden partitions not directly related to the boot loader and handing off to the kernel manage complicated tasks like initial setup of clocks and power prior to the boot loader itself starting. You may find this URL useful:
[url]http://http.download.nvidia.com/tegra-public-appnotes/bct-overview.html[/url]

Hi,

My doubt regarding partitions is being cleared. I require your ideas on exporting u-boot env variables to kernel using fw_printenv and fw_setenv

In the config file of fw_config we have to add which partition and the offset and size.
I know only u-boot env size is 2000 and it is mentioned in code like mmc dev 0 2 partition, atlast it will save u-boot env.

I am not able to get the offset.Can anyone explain or help me to find that offset.?

I have gone through this and i am sure of the offset mentioned there.
https://devtalk.nvidia.com/default/topic/802197/?comment=4425615

Thanks in advance :-)

I have used the same approach mentioned in that thread on my TX1 and it works fine for me. You need to patch the two drivers so /dev/mmcblk0boot1 shows up and is writeable, then use the same fw_env.config file.

Hi,

Thanks for your reply.

I followed the steps in the link and able to discover the hidden partition.
But i observed one wierd behaviour like, i was able to read my u-boot env from linux, but if i set or create new variable , the board stops booting.

It stopped in Starting Kernel. Print.

Are you sure of the config file? Itz like i am reading and writing in the reserved memory.

/dev/mmcblk0boot1 0x3fe000 0x2000

Can u help please.

Hello, Sherin:

But i observed one wierd behaviour like, i was able to read my u-boot env from linux, but if i set or create new variable , the board stops booting.

Do you mean you set u-boot env in linux kernel by direct overwirte EMMC?

You can set env in u-boot and saveenv.
If that still does not work, would you please describe the detail env you’ve changed?

Back to your original question, you can check the u-boot env and track down the ‘bootcmd’

br
ChenJian

I am also trying to read the uboot environment from the live Jetson Tx1 dev-kit. I tried the steps in Problem solved: support for uboot tools fw_printenv/fw_setenv on Linux For Tegra - Jetson TK1 - NVIDIA Developer Forums but they do not appear to be working for me.

I’ve applied the first of the patches and I can see /dev/mmcblk0boot1 but fw_printenv has this output:

:~$ sudo ./fw_printenv 
Warning: Bad CRC, using default environment
...

'cat /proc/partitions` tells me that /dev/mmcblk0boot1 is only 4096 bytes (I think):

179        0   15388672 mmcblk0
 179        1   14680064 mmcblk0p1
 179        2       2048 mmcblk0p2
 179        3       4096 mmcblk0p3
 179        4       2048 mmcblk0p4
 179        5       6144 mmcblk0p5
 179        6       4096 mmcblk0p6
 179        7       6144 mmcblk0p7
 179        8       2048 mmcblk0p8
 179        9       2048 mmcblk0p9
 179       10      20480 mmcblk0p10
 179       11      65536 mmcblk0p11
 179       12      65536 mmcblk0p12
 179       13       4096 mmcblk0p13
 179       14       2048 mmcblk0p14
 179       15       6144 mmcblk0p15
 259        0       6144 mmcblk0p16
 259        1       2048 mmcblk0p17
 259        2     507870 mmcblk0p18
 179       32       4096 mmcblk0boot1
 179       16       4096 mmcblk0boot0
 179       64  126745600 mmcblk1
 179       65  126729216 mmcblk1p1

I built fw_printenv with this command from the r24.1 tag:

make HOSTCC=arm-linux-gnueabihf-gcc env

I’m not sure what I’m doing wrong. madisox, since you’ve gotten this working did you have to do anything extra?

Edit(1):

Hm… perhaps this is actually working. According to the info about the error message on this page it seems like the warning is just saying that it can’t load/save the environment to EEPROM. Since the environment is actually stored on the emmc (same partition as uboot itself) I guess this is a red-herring. After applying the second patch, it seems that variables written with fw_setenv persist.

Edit(2):

Well, setting an environment variable with fw_setenv is visible with a subsequent fw_printenv… however now my system wont boot. I only added a new environment variable, so this is a bit surprising.

Edit(3):

Debugging over uart… uboot seems to be pretty happy. I can see my added environment variable using printenv. uboot seems to find my /boot/extlinux.conf but the system hangs when starting the kernel.

Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
953 bytes read in 68 ms (13.7 KiB/s)
p2371-2180 eMMC boot options
1:	primary kernel
Enter choice: 1:	primary kernel
Retrieving file: /boot/Image
19349608 bytes read in 513 ms (36 MiB/s)
append: fbcon=map:0 console=tty0 console=ttyS0,115200n8 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff2bf000 nvdumper_reserved=0xff23f000 core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 root=/dev/mmcblk0p1 rw rootwait
Retrieving file: /boot/dts/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
263932 bytes read in 71 ms (3.5 MiB/s)
## Flattened Device Tree blob at 82000000
   Booting using the fdt blob at 0x82000000
   reserving fdt memory region: addr=80000000 size=20000
   Loading Device Tree to 00000000fcbde000, end 00000000fcc216fb ... OK

Starting kernel ...

Hi Josh_sky,
The problem because the kernel stopped booting is that the below mentioned variables will be changed by kernel somehow, If u revert back these changes in u-boot after using fw_setenv, u can get the system to be booted.

fdt_high=ffffffffffffffff
initrd_high=ffffffffffffffff

U can check this by comparing u-boot env and fw_printenv output after setting a variable using fw_setenv.

My simple solution is use saveenv in u-boot, and then u do whatever change or add variable in kernel will not affect the system boot.

Add saveenv before bootcmd is executed.

CRC check error can also be cleared via this approach.

Have a good day.

Hi Josh_sky,
The problem because the kernel stopped booting is that the below mentioned variables will be changed by kernel somehow, If u revert back these changes in u-boot after using fw_setenv, u can get the system to be booted.

fdt_high=ffffffffffffffff
initrd_high=ffffffffffffffff

U can check this by comparing u-boot env and fw_printenv output after setting a variable using fw_setenv.

My simple solution is use saveenv in u-boot, and then u do whatever change or add variable in kernel will not affect the system boot.

Add saveenv before bootcmd is executed.

CRC check error can also be cleared via this approach.

Have a good day.

Thanks Sherin. Also thanks madisox for pointing me to: tools/env/fw_env.h: Correct include order · OE4T/u-boot-tegra@9f64e48 · GitHub

It seems the issue is that