How to make a SW system.img file for production usage(flash the file to thousand of EMMC chips).

Autonomous Machines Jetson & Embedded Systems Jetson TK1
1

Targets:
Create a SW flash file(system.img), then flash the file to thousands of EMMC chips in factory with flash tools, the n finish SMT to create final K1 boards. I need to know how to create a good system.img file.

Background:
I have made a system.img file about 4G Byte size with flash.sh , follow this link: Jetson/Cloning - eLinux.org, and make a system.img.raw file about 15G bytes.
I can flash the system.img to TK1 PCBA boards with PC successfully, and the K1 board works well. So the K1 PCBA board hardware is OK.

Problem:
I have made a system.img.raw file about 15G Bytes. Flash this system.img.raw file to EMMC chips with EMMC flash tool(UPM-010e as below link: UPM-010e|UPM-010e拷贝机|UPM-010e编程器|UPM-010e烧录器-深圳市共顺智能科技有限公司 ). Then mount this EMMC chips to PCBA to instead of the original EMMC chips. Power on the k1 board, it can’t wake up. With the current K1 board, flash the 4G byte system.img file with PC, the board works well.

I want to konw how to make a good system.img file, which can be used in factory to flash to lots of EMMC chips before SMT.

I think it maybe configrable in flash.sh files, like:

Examples:

./flash.sh mmcblk0p1 - boot from eMMC

Optional Environment Variables:

BCTFILE ---------------- Boot control table configuration file to be used.

BOARDID ---------------- Pass boardid to override EEPROM value

BOOTLOADER ------------- Bootloader binary to be flashed

BOOTPARTLIMIT ---------- GPT data limit. (== Max BCT size + PPT size)

EMMCSIZE --------------- Size of target device eMMC (boot0+boot1+user).

FLASHAPP --------------- Flash application running in host machine.

FLASHER ---------------- Flash server running in target machine.

IGNOREFASTBOOTCMDLINE – Block fastboot from filling unspecified kernel。

Thanks!

2

hello haitzhu,

suspect the system image generated by EMMC flash tool is failed.

Power on the k1 board, it can’t wake up
could you share the uart logs, more details would be helpful.

3

Hi Jerry,
Thanks a lot!

suspect the system image generated by EMMC flash tool is failed.

I’m confused about your point:

  1. the system.img file created by flash.sh is wrong.
  2. Flash the EMMC chip with UPM flash tool failed.
    which one do you mean?

More info about the problem:

  1. Flash the system.img(4G byte)created by flash.sh CMD to K1 board, then unmount the EMMC chip from PCBA board, read the EMMC file with hardware tools to a new file----File1.
  2. The second file is system.img.raw(15G byte) created by flash.sh CMD — File2. Compare the File1 and File2, it shows that they are different. The data block arrange is different.

Thanks again for your help!

4

The system.img.raw file is uncompressed and used to create the system.img sparse file. You’d need the flash system to use the sparse/compressed file, the system.img.raw would work for the rootfs partition on eMMC. But this isn’t what you want.

See this for an expansion on the topic of partitions and cloning (and restore):
[url]http://elinux.org/Jetson/Cloning[/url]

There are many partitions other than the rootfs. Those partitions must work together at boot. What you want is to flash and set up your Jetson as you desire, and then clone “all” (the complete eMMC image) instead of just “app” (rootfs). The “all” clone is what you want.

It’s purely academic, but note that when you clone “all” you can use dd (if you know partition boundaries) to extract the equivalent of “app” from “all”…or to extract any partition. “all” is a contiguous single file spanning all partitions (mmcblk0 instead of mmcblk0p1). FYI, all of the partition boundaries are aligned at 4k offsets (e.g., run gdisk, and “l” to list partitions…offsets are listed by sector, and sector size is noted as 2048 bytes…all start sectors are divisible by 4096, all “end - start + 1” sectors are divisible by 4096). Since the flash app produces 4k-aligned images and assembles them onto the Jetson rather than as a single image you can’t just flash the images to chips one at a time without a possibility of error…cloning removes the error of sort order possibility, but technically, you could use dd and NULL-padding to create a single image from individual images (flash.sh pads some images on their tail with NULL prior to flashing the image).

Something I’ve never tested but which you might want to be aware of is that if you go into gdisk on a JTK1 and list all partitions you’ll note that the first partition does not start at the first sector. This implies that cloning everything requires cloning more than just partitions…it requires the metadata describing the GPT partitions, and this occurs at the start of the disk. I think cloning “all” clones this too, but I’ve never specifically tested. Measuring the exact size of clone “all” and comparing to the sum of the partition sizes should reveal the “all” image as being 94207 sectors larger (the first sector for a partition is 94207+1 at start…though I may be off by 1 sector on how I’m counting). If it turns out clone of “all” does not include metadata, then you might want to use “dd” to preserve those first 94207 sectors and prepend to the “all” clone…but I don’t think that would be necessary.