Jetson-tk1 u-boot doesn't search mmcblk0p1

Robotics & Edge Computing Jetson & Embedded Systems Jetson TK1
1

I reflashed my Jetson-tk1 with an existing system.img:

$ sudo ./flash.sh -r -L bootloader/ardbeg/u-boot.bin -S 14580MiB jetson-tk1 mmcblk0p1

I have an existing zImage in system.img:

On host:

$ mkdir ~/tegra/system_image
$ sudo mount -o loop bootloader/system.img ~/tegra/system_image/
[140918 17:09:32] gauthier@sobel:~/tegra/system_image $ ls ~/tegra/system_image/boot
jetson-tk1_extlinux.conf.emmc    tegra124-e1782_sku1100.dtb  tegra124-thor195.dtb             tegra124-tn8-p1761-battery-2gb.dtb
jetson-tk1_extlinux.conf.nfs     tegra124-e1791.dtb          tegra124-tn8-a03-00-battery.dtb  tegra124-tn8-p1761-battery.dtb
jetson-tk1_extlinux.conf.sdcard  tegra124-e1922.dtb          tegra124-tn8-a03-00.dtb          tegra124-tn8-p1761.dtb
jetson-tk1_extlinux.conf.usb     tegra124-e1923.dtb          tegra124-tn8-a03-01-battery.dtb  tegra124-vcm30_t124.dtb
tegra124-ardbeg-a03-00.dtb       tegra124-foster.dtb         tegra124-tn8-a03-01.dtb          vmlinux.uimg
tegra124-ardbeg.dtb              tegra124-laguna.dtb         tegra124-tn8-aio.dtb             zImage
tegra124-ardbeg_sata.dtb         tegra124-loki.dtb           tegra124-tn8-battery.dtb
tegra124-bonaire.dtb             tegra124-norrin.dtb         tegra124-tn8.dtb
tegra124-bonaire_sim.dtb         tegra124-pm375.dtb          tegra124-tn8-p1761-2gb.dtb

Note however that I haven’t put the zImage there myself (running on Grinch 19.3.6).

The target does not start, it is stuck in u-boot (bootloader/ardbeg/u-boot.img was the one I got from the instructions from Santyago there: [CustomKernel] The Grinch 19.3.8 for Jetson TK1 / developed - Jetson TK1 - NVIDIA Developer Forums , I haven’t recompiled or anything).

U-boot output looks like this:

U-Boot SPL 2014.04-rc2 (Jun 18 2014 - 11:16:32)

U-Boot 2014.04-rc2 (Jun 18 2014 - 11:16:32)

TEGRA124
Board: NVIDIA Jetson TK1
I2C:   ready
DRAM:  2 GiB
MMC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  0 
MMC: no card present
mmc0(part 0) is current device
Scanning mmc 0...
(Re)start USB...
USB0:   USB EHCI 1.10
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
       scanning usb for ethernet devices... 0 Ethernet Device(s) found

USB device 0: unknown device
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-tegra124
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
Tegra124 (Jetson TK1) #

The interesting stuff is, I guess:

MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1

and

MMC: no card present
mmc0(part 0) is current device
Scanning mmc 0...

The rest is just fallback.

My interpretation is that u-boot finds mmcblk0p0 and mmcblk0p1. But it says “no card present”, so I’m not sure.
Then it scans mmc0(part0), I suppose it means mmcblk0p0.
It does not scan mmcblk0p1, in that case.

What should I do? Flash to mmcblk0p0 instead of 0p1? Is there a mess in my partitions, what is happening?

2

Did you by chance skip the steps b2 and c1, 2, 3 from his fresh installation instructions before you built the system.img file? I don’t see the files from rootfs anywhere.

3

In addition to what javax is asking, try using “bootloader/u-boot.bin”, don’t use “bootloader/ardbeg/u-boot.bin”. I’ve been using the “bootloader/u-boot.bin” successfully (R19.3). I don’t know what the difference is between them, but they do have different checksums.

You are right that SD card should not be mentioned, as mmcblk0p1 is correct for normal eMMC. I’m suspicious of the alternate u-boot.bin perhaps being set up for SD card.

4

I’ve been using the <bootloader/ardbeg/u-boot.bin> because it’s what is specified in the U-Boot section of the docs.

It has always worked fine with all the Grinches including 19.3.6.

However, it’s curious there is also a <bootloader/u-boot.bin>.

Here’s the relevant snippet from “The U-Boot Guide”:

5

L4T has evolved over time, and for example, u-boot used to use a .uimg format; I think some of the bootloader scripts are for this conversion. The /boot partition still contains (in R19.3) vmlinux.uimg. However, removing this file while running u-boot in R19.3 does has no effect on boot. The extlinux.conf script itself only names zImage.

It seems that since older u-boot used .uimg format, and that since the vmlinux.uimg file is still there, there may be parts of older boot scripts and configurations left over. It seems even more likely when you consider that Jetson is not the only L4T hardware out there…some of the other hardware may still use parts of L4T which Jetson dumped. Jetson is ardbeg, but is a new version created during flash dependent upon options? I’m really tempted to reflash my Jetson just to find out, but right now I can’t afford to test this.

Maybe someone else could test flash with both “bootloader/u-boot.bin” and “bootloader/ardbeg/u-boot.bin” in a full flash, noting file time stamps before and after full flash?

6

You’re right.

A <bootloader/u-boot.bin> is generated along with the system.img even though I used the <bootloader/ardbeg/u-boot.bin> arg.

7

So it seems possible that the ardbeg version has been “hard wired” for some options, and that the non-ardbeg version perhaps is required when u-boot itself has any options changed. I have not looked particularly close at the flash.sh in terms of how it creates u-boot.bin, I’ve really only explored system.img creation. Options which change boot loader location and boot device to transfer control to seem high on the list of options which might change u-boot.bin (non-ardbeg generated version). After all, if ardbeg version is causing the boot loader to look for SD card even when SD is not requested, it almost has to be the generated version which actually goes into a working flash…directly or indirectly.

8

I am not sure I understand. Where do you expect to see the files from rootfs?
After mount -o loop bootloader/system.img ~/tegra/system_image, I get:

gauthier@sobel:~/tegra/grinch/Linux_for_Tegra (master) $ ls rootfs
bin  boot  dev  etc  home  lib  media  mnt  opt  proc  README.txt  root  run  sbin  srv  sys  tmp  usr  var
gauthier@sobel:~/tegra/grinch/Linux_for_Tegra (master) $ ls ~/tegra/system_image
bin  boot  dev  etc  home  lib  lost+found  media  mnt  opt  proc  README.txt  root  run  sbin  srv  sys  tmp  usr  var

I then updated my mounted system.img via rsync from target, a couple of days ago.
I am now flashing with -r to reuse this existing system.img: “skip building and reuse existing system.img.”.

Something strange here? I rsync with --delete, do you mean some files are missing in system_image/boot?

Other than that, I’ll try to reflash with bootloader/u-boot.bin instead of bootloader/ardbeg/u-boot.bin and keep you updated.

9

Oh, this might be interesting:

gauthier@sobel:~ $ ls ~/tegra/grinch/Linux_for_Tegra/rootfs/boot
extlinux.conf                    tegra124-bonaire_sim.dtb    tegra124-pm375.dtb               tegra124-tn8-p1761-2gb.dtb
jetson-tk1_extlinux.conf.emmc    tegra124-e1782_sku1100.dtb  tegra124-thor195.dtb             tegra124-tn8-p1761-battery-2gb.dtb
jetson-tk1_extlinux.conf.nfs     tegra124-e1791.dtb          tegra124-tn8-a03-00-battery.dtb  tegra124-tn8-p1761-battery.dtb
jetson-tk1_extlinux.conf.sdcard  tegra124-e1922.dtb          tegra124-tn8-a03-00.dtb          tegra124-tn8-p1761.dtb
jetson-tk1_extlinux.conf.usb     tegra124-e1923.dtb          tegra124-tn8-a03-01-battery.dtb  tegra124-vcm30_t124.dtb
tegra124-ardbeg-a03-00.dtb       tegra124-foster.dtb         tegra124-tn8-a03-01.dtb          vmlinux.uimg
tegra124-ardbeg.dtb              tegra124-laguna.dtb         tegra124-tn8-aio.dtb             zImage
tegra124-ardbeg_sata.dtb         tegra124-loki.dtb           tegra124-tn8-battery.dtb
tegra124-bonaire.dtb             tegra124-norrin.dtb         tegra124-tn8.dtb

gauthier@sobel:~ $ ls ~/tegra/system_image/boot
jetson-tk1_extlinux.conf.emmc    tegra124-e1782_sku1100.dtb  tegra124-thor195.dtb             tegra124-tn8-p1761-battery-2gb.dtb
jetson-tk1_extlinux.conf.nfs     tegra124-e1791.dtb          tegra124-tn8-a03-00-battery.dtb  tegra124-tn8-p1761-battery.dtb
jetson-tk1_extlinux.conf.sdcard  tegra124-e1922.dtb          tegra124-tn8-a03-00.dtb          tegra124-tn8-p1761.dtb
jetson-tk1_extlinux.conf.usb     tegra124-e1923.dtb          tegra124-tn8-a03-01-battery.dtb  tegra124-vcm30_t124.dtb
tegra124-ardbeg-a03-00.dtb       tegra124-foster.dtb         tegra124-tn8-a03-01.dtb          vmlinux.uimg
tegra124-ardbeg.dtb              tegra124-laguna.dtb         tegra124-tn8-aio.dtb             zImage
tegra124-ardbeg_sata.dtb         tegra124-loki.dtb           tegra124-tn8-battery.dtb
tegra124-bonaire.dtb             tegra124-norrin.dtb         tegra124-tn8.dtb
tegra124-bonaire_sim.dtb         tegra124-pm375.dtb          tegra124-tn8-p1761-2gb.dtb

There is no extlinux.conf in my system.img, while there is in rootfs. I thought that system.img was created from the rootfs directory?

10

/boot must have extlinux.conf for u-boot to internal eMMC on Jetson. This is originally copied from sample rootfs during build of system.img. I believe that this could possibly explain the unrequested SD card search based on failing to find eMMC configuration and moving on to the next boot device. There is a boot device search order in u-boot, but if it had found extlinux.conf it would not have used any boot device listing except what is there…which by default is /boot/zImage.

I’m not on my development system right now (no Jetson or linux access), but it seems that the rsync was probably incorrect. I use something like this from Jetson:

sudo rsync -avczr -e ssh --delete-before /boot root@my_host:/image_mount_point

…note that --delete-before in rsync from Jetson to system.img only removes files on system.img which do not exist on Jetson. Also, naming source “/boot” to destination mount point of system.img places an exact copy of Jetson “/boot” onto system.img mount point…naming source “/boot/*” will not work correctly, as it would only copy files from Jetson, but not recognize extra non-existent files on system.img.

If your system.img is mounted on an Ubuntu system without a root user you would have to use something like this (I can’t test, I’m using fedora host which has a root account) to get remote ssh to ask for a pass (the “-t” option of ssh for sudo once into the system.img backup machine):

sudo rsync -avczr -e <b>"ssh -t sudo"</b> --delete-before /boot root@my_host:/image_mount_point

You would only need a custom /boot/extlinux.conf to boot multiple kernels beyond the first option. Can you copy the extlinux.conf from sample rootfs into system.img /boot and try flashing again? If rsync was incorrect this might not be everything needed, but it would be the place to start.

11

I think I got that right, but I cannot be sure that nothing tried to remove /boot/extlinux.conf before I rsynced.

I tried just that, but I am not sure of the result. I do not boot to the Ubuntu desktop, and I don’t see anything on RS232. This is surely due to a misconfiguration of the console in extlinux.conf, but I don’t see it yet. Here is the content of system_image/boot/extlinux.conf:

TIMEOUT 30
DEFAULT primary

MENU TITLE Jetson-TK1 eMMC boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX zImage
      FDT tegra124-pm375.dtb
      APPEND console=ttyS0,115200n8 console=tty1 no_console_suspend=1 lp0_vec=2064@0xf46ff000 video=tegrafb mem=1862M@2048M memtype=255 ddr_die=2048M@2048M section=256M pmuboard=0x0177:0x0000:0x02:0x43:0x00 vpr=151M@3945M tsec=32M@3913M otf_key=c75e5bb91eb3bd947560357b64422f85 usbcore.old_scheme_first=1 core_edp_mv=1150 core_edp_ma=4000 tegraid=40.1.1.0.0 debug_uartport=lsport,3 power_supply=Adapter audio_codec=rt5640 modem_id=0 android.kerneltype=normal usb_port_owner_info=0 fbcon=map:1 commchip_id=0 usb_port_owner_info=0 lane_owner_info=6 emc_max_dvfs=0 touch_id=0@0 tegra_fbmem=32899072@0xad012000 board_info=0x0177:0x0000:0x02:0x43:0x00 root=/dev/mmcblk0p1 rw rootwait tegraboot=sdmmc gpt

My kermit configuration on host:

set carrier-watch off
set line /dev/ttyS0
set speed 115200
set handshake none
set flow-control none
robust
set file type bin
set file name lit
set rec pack 1000
set send pack 1000
set window 5

I think my next step is to start again from scratch and generate a new system.img, see if that works with u-boot.bin.

12

So, reflashing the whole thing with -L bootloader/u-boot.bin worked (as expected), and modifying the kernel command line in /boot/extlinux.conf is a breeze. I don’t know why anyone would like to keep fastboot.bin, is it much smaller, faster?

I don’t know why copying over only extlinux.conf did not work in the first place, not even the RS232. Presumably there were other things missing. It might be so that I failed to save something important when I rsynced.

This is what I used to upload to host, can you see anything that would be missing after flashing with the resulting system_image? ~/tegra/system_image is the mount point to system.img.

rync --delete-before -avczr -e ssh /bin /boot /dev /etc /home /lib /media /mnt /opt /root /sbin /srv /usr /var gauthier@192.168.1.105:/home/gauthier/tegra/system_image
13

I think fastboot might be slightly smaller in size. There are also many production products you don’t want consumers to mess with the bootloader on. Perhaps even licensing is different. For development I see no advantage to fastboot.

It is looking like bootloader/ardbeg/u-boot.img is static and comes with the L4T source, while bootloader/u-boot.img is generated based on arguments during the system.img creation…which means ardbeg is designed for a default installation of some kind and incorrect as soon as something changes the boot environment. At least that seems to be the implication.

As for rsync failure, some files would fail copy if you lacked root authority on either system. I can only speculate on this since the command line looked good but extlinux.conf was deleted…it would seem that rsync deleted this because it thought it did not exist on Jetson end. I initially had trouble with some ssh based commands when I did not have the “-t” option and it wanted sudo password over remote ssh…this would not be an issue to Jetson if you were sudo on Jetson and already sudo, but my host is Fedora (not Ubuntu), so I don’t need the “-t” option when ssh goes from Jetson to host. My speculation is that one end of your rsync could not see extlinux.conf but the other end did so it thought one end was “extra” and deleted it.

I personally save an unmodified system.img for comparison, not sure if you did. I also have my generateSystemImage.sh if I want to regenerate system.img without an actual flash.

14

It looks like bootloader/u-boot.bin is not present before the first call to flash.sh. It appears while running the first flash. bootloader/ardbeg/u-boot.bin is there from extraction.

So run with the bootloader/ardbeg/u-boot.bin first, then from bootloader/u-boot.bin is a sensible approach, it would seem.

I had to play for a while with rsync before getting it right. It seems I need to be superuser on both ends, and actually change the command above to root@192.168.1.105. For this to work I also need to either permit ssh root login with password on my host (disabled by default in Ubuntu, which makes sense), or go with ssh keys.

Well, “for this to work”, I haven’t actually tried flashing back an existing system.img, yet.

15

And flashing back works, or at least it seems so. Some things may have changed a bit (for example I cannot shutdown anymore), I probably forgot to copy some folder?

Other than that, reflashing with an updated system.img worked, yay!

16

You could run strace on your shutdown command and see why it fails. LOTS of output, but the answer is usually near the end of an strace log.

17

After an aweful lot of tinkering (and trying the solution exposed here), i discovered that flashing from Ubuntu did it (i was using Arch).