Hello,
We currently have issues creating an img on the B01 (180-13448-DAAA-B01) production module w/ emmc rather than SD card memory:
-
We can flash NVIDIA’s stock img onto this emmc module and have it boot successfully. But we cannot flash our custom img. We are stuck on the splash screen whenever we try to flash our img.
-
We can also flash NVIDIA’s stock img AND our custom img onto the SD card module, and that boots successfully.
Given these two points, it stands to reason that something in our rootfs is not compatible for the emmc module. Upon further inspection, I found we follow this process for creating img’s:
- [./flash.sh jetson-nano-qspi-sd mmcblk0p1] to flash a preexisting img onto an SD card module.
- Download our drivers, internal services, and other SW changes onto the Nano rootfs.
- [ROOTFS_DIR=<MODIFIED_ROOTFS_PATH> ./jetson-disk-image-creator.sh -o 20200715.img -b jetson-nano -r 300] to create a new img with our custom rootfs.
- [cp 20200715.img ~/Linux_for_Tegra/bootloader/system.img] to use the newly made img.
- [./flash.sh -r jetson-nano-devkit-emmc mmcblk0p1] to flash our emmc board.
So we basically flash an SD card model with ./flash.sh, and then create a new img based off that.
So my question is: Would there be an issue creating the img from an SD card for emmc modules? In other words, is there a particular reason why the img from ‘jetson-disk-image-creator.sh’ would fail on emmc modules? I wouldn’t think the rootfs on the SD card module would be fundamentally different on the emmc module, so our process should work.
I have attached boot logs of several attempts below, but here is a snippet from our custom img on emmc booting. Thank you for your support:
U-Boot 2016.07-ge6da093be3 (Jun 25 2020 - 21:18:08 -0700)
TEGRA210
Model: NVIDIA P3450-Porg
Board: NVIDIA P3450-PORG
DRAM: 4 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
SF: Failed to get idcodes
*** Warning - spi_flash_probe() failed, using default environment
In: serial
Out: serial
Err: serial
Net: No ethernet found.
Card did not respond to voltage select!
** Bad device mmc 1 **
Hit any key to stop autoboot: 0
Card did not respond to voltage select!
switch to partitions #0, OK
mmc0(part 0) is current device
Failed to mount ext2 filesystem…
** Unrecognized filesystem type **
starting USB…
USB0: tegrausb: Invalid dr_mode 2 for host mode
probe failed, error -1
USB error: all controllers failed lowlevel init
PCI device eth_rtl8169: unknown chip version, assuming RTL-8169
PCI device: TxConfig = 0x4B100D00
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
DHCP client bound to address 192.168.0.20 (828 ms)
*** Warning: no boot file name; using ‘C0A80014.img’
Using eth_rtl8169 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.20
Filename ‘C0A80014.img’.
Load address: 0x83280000
07-23-2020_custom_img_on_emmc_fail.txt (30.2 KB) 07-23-2020_custom_img_on_sd_card_pass.txt (34.7 KB) 07-23-2020_stock_img_on_emmc_pass.txt (59.6 KB)
hello kevin.choi,
according to Flash Script Usage, -r option would reuse the existing system.img for flashing.
you should disable -r options in the flash commands since you’d update your customize system image,
i.e. sudo ./flash.sh jetson-nano-devkit-emmc mmcblk0p1
@JerryChang will differentiation of hardware be addressed if to flash the same image to diferent devices? or there will be overlaping withh device identifiers?
Given on computer A, Jetson A’ the sdkmanager has been used with slightly patched filesystem that created slightly modified system.img that gets written to A’.
Then we want to get the very same system but being flashed on Host PC B, to Jetson B’.
Which will be the correct way?
Just to transfer system.img/ system.raw & the flash.sh files to the Host PC B from Host PC A?
or the entire folder wil need to be transfered & sytem image recreated in order to address difference in hardware identifiers between Jetson A’ & B’?
Else?
Or maybe slight modifications to the filesystem to add support to custom carrier board could be added with patching with flash.sh the default image overriding default files in the filesystem? Is there a recipie for smth. like that?
Thanks
hello Andrey1984,
may I know what’s the difference between your Jetson-A and Jetson-B?
you may duplicate your images if these two Jetson platforms were based-on the same chip version, and they’re also sharing the same board configuration files.
you may refer to Jetson/Clone - eLinux.org for system image cloning and restoring it to other devices.
thanks
@JerryChang, Thank you fro your response
Jetson A & Jetson B will be same model of Jetsons modules installed on same model of custom carrier board. I understand that the system image could be produced one to be distributed to consumers devices somehow so that it will be similar to the nx/nano sdcard distribution image method.
I understand that two images will need to be created - one for production NX & one for production nano modules configuration. There will be no differences between Jetson A & Jetson B, other than they would either be both nanos production modules on custom carrier board or nxes. My concern ws to make sure the immage passed to consumers has fresh OS without any tails[unnecessary data about hardware identifiers as natwork mac addreesses etc] from the original system hthat is used to create the disk image initially.
Thank you very much!
I can’t offer much help, but if firewall or network device renaming occurs, then there is a chance that it will be in “/etc/udev/rules.d/”. You should consider simply examining any file there for hard coded MAC addresses. In most cases those files will simply use some sort of macro expansion and will not hard code any MAC address. There could be similar entries based on other specific hardware, but it should be fairly obvious through simple examination if this is the case.
Hi Andry1984,
Sorry to jump in. Are you trying to use same system image on 2 jetson but one is Nano while another one is NX?
Hi @WayneWWW,
Thank you for your question.
It seems more straightforward to have two images: one for NX and separate for nano.
I am looking to sort out how to implement an image creation for a custom carrier board, in a similar manner as the distribution of default NX& nano images is provided by nvidia with default OS images.
Hi Andrey1984,
Even jetson nano SD does not include all the components on sdmmc. Nano has some boot components on QSPI.
Back to your question, when you mentioned production module,it is based on emmc. All the components are on emmc.
Currently there is no method to create a all-in-one image file to install on emmc. You could system.img and bl payload updater to update those components. Unfortunately, flash.sh is still needed.
I think if I had to do this I would have a reference image to mount on “Linux_for_Tegra/rootfs/”, and expect this to have boot content modified. Prior to flash I’d run a custom script which is similar to the older “apply_binaries.sh”, and would simply overlay the reference with the content for that specific unit (and this could include overlay of device trees or other content in “bootloader/” or “kernel/”, not just content in “rootfs/”). Whatever the most recent overlay script were used could write a file to tell you what it was most recently updated to. Then flash normally.