Hi,
My idea is to install deb packages inside the rootfs (I already have this), cross-compile things (like cmake, opencv with cuda support, grpc, protobuf etc), install some dependencies like netplan.io, remove networkmanager, create a user with password (I just saw the post Jetson Nano all USB ports suddenly stopped working - #37 by WayneWWW about creating a user thanks to @WayneWWW script l4t_create_default_user), apt-get upgrade, etc.
For now I succeed to install all the deb packages (cuda, deepstream, etc) from sdkmanager thanks to the sdkmanager jsons (I download them via cmdline) and install them via chroot, more or less like the apply_binaries.sh script.
I failed to cross-compile cmake and opencv, it made me crazy, so for now I compile them in a chroot, this is very slow…anyway
But my doubt is about oem-config, how can I run it in a chroot from my x86 desktop ubuntu? I’ve seen things like nvidia-l4t-apt-source.list that I guess is modified by the oem-config, but I don’t know how I could do what the oem-config does inside a chroot.
Anyone has already experience about preparing this kind of ready image?
thanks
1 Like
Hi,
May I know why you want to use oem-config with chroot? You want to create a image that already done the configuration?
1 Like
yes, I want to generate an image with everything installed, custom user created, some dependencies compiled (cross-compiled or via chroot+qemu), IP configured, and even maybe some programs running via systemd.
I don’t necessarily need oem-config, but I need to reproduce the steps oem-config is doing, just to have an image ready to use. Language step, IP, and user can be done easily, size of filesystem I guess too, when flashing, but I think there are more steps the oem-config is doing.
I think you could run oem-config on the device first and then use the clone method to create a cloned system.img.
https://elinux.org/Jetson/Clone
1 Like
I’m interested to do full clones, not only rootfs.
I’m reading an interesting post about this, for the TX2: Clone entire TX2
The part about cloning signed boot partitions seems strange to me because exchanging a SD card from one nano to another is working well.
I’d like to be able to generate a ready-to-use image without the use of any physical jetson. I’m decompressing the L4T file then the rootfs file, applying apply_binaries.sh and more things, and from there I’d like to be able to generate a ready-to-use image to record on SD card or emmc directly.
Hi,
Full clone will not work. Not all partitions support the cloning.
This is strange because with 2 nano devkits I can switch SD to another one with success. System is booting and running fine. Has it something to do with emmc vs SD?
I mean I installed the official image, grab it on a SD card, did the oem config on a jetson, and then move this SD card to another Jetson nano and it worked fine.
Hi,
Your example does not need to worry about other partitions.
The oem-config only applies to rootfs so clone APP partition will cover it.
Also, you have to know that part of bootloader is on the qspi but not sdcard. The reason you could directly put sdcard from one devkit to another is because both devkits are already fused by the factory in qspi.
Thanks for the answer.
Is there a list of what is doing oem-config? or is it open source somewhere?
I’d really like to do the same things without need of physical jetson to run it.
I know I could run it on a jetson and then dump the rootfs. But I’d like to prepare everything on a PC, from the original rootfs, so I can generate a rootfs without need of jetson, and without running oem-config at first startup because I want to preconfigure it with user created, deps compiled, timezone set up, IP configured, etc.
Hi,
NV customized oem-config cannot work for your case because it must run with UART.
But you could refer to the public oem-config.
https://packages.ubuntu.com/search?keywords=oem-config
@WayneWWW, thanks, I’ll have a look at oem-config.
Do you think I could configure oem-config to run all the steps (language, keyboard, rootfs partition size, user creation…) automatically at first startup without any user action?
Other question is about QSPI, I don’t find much information about it or what it contains. Am I right if I say that QSPI is to be able to boot to SD card? and that there is no QSPI in production version of the Nano SOM?
When you say “already fused” you mean that QSPI is already flashed by nvidia?
By this way I could prepare one SD card and clone it, and it would work in a Jetson that has never been flashed?
Hi,
Do you think I could configure oem-config to run all the steps (language, keyboard, rootfs partition size, user creation…) automatically at first startup without any user action?
I don’t know. We don’t try this case before.
Other question is about QSPI, I don’t find much information about it or what it contains. Am I right if I say that QSPI is to be able to boot to SD card? and that there is no QSPI in production version of the Nano SOM?
You could refer to below file under your driver package.
Linux_for_Tegra/bootloader/t210ref/cfg/flash_l4t_t210_spi_sd_p3448.xml
And you shall see some partitions are on the device “spi”
device type=“spi” instance=“0”
When you say “already fused” you mean that QSPI is already flashed by nvidia?
Yes, the factory should already flash the qspi image for every jetson Nano devkit device so that you guys could directly put the sdcard image and boot up without problem.
Thanks for the info.
I’ll take time to read the L4T documentation to understand better what are the partitions and how the boot process is working.
I’ll have a look at the oem-config, because my goal is to create a rootfs on a build computer, and from this PC create an image for SD, or flash production SOM, but without need of user interaction, I want to create one with a user already defined, IP configured etc, even with my programs running at first boot.
So right now I don’t know if I need or not oem-config, because I don’t know exactly all the steps that are done during oem-config on the nano. I just need to automize what is done in oem-config, so I could send a production nano flashed and directly operative to our clients. The clients would just have to connect the ethernet and power.
1 Like