Preparing Image for custom carrier (Orin Nano)

Hi all

I am about to commence preparing an image for a custom carrier PCB.

I have no previous experience with Nvidia, my previous embedded experience is on Yocto.

So I need a bit of assistance to ensure I don’t go down the wrong path

In short, my carrier is a cut down version of the devKit plus a few changes to the pinmux xls…

I have changed the pinmux excel sheet and generated the three dts files

I am not going to refer to this guide, but it seems that guide talks about multiple different methods to achieve the same thing ….

I want to create an image that works with my new carrier…

Here’s the guide I will follow

https://docs.nvidia.com/jetson/archives/r35.3.1/DeveloperGuide/text/HR/JetsonModuleAdaptationAndBringUp/JetsonOrinNxNanoSeries.html?highlight=cvb

I have some questions;

  1. Do I prepare and then compile the new image with a production Orin nano plugged into the dev kit?

  2. Do we actually have to recompile the image after changing the 3 dtsi files ?

  3. In the section “Naming the board”, where is this actually done?

  4. The “root file system configuration” section talks about changes, what changes are needed ?

  5. The “MB1 configuration changes” section talks about making changes… What do I need to do here? Just drop in my new dtsi files?

  6. “Mem-BCT” - am I just leaving this as per the devKit image?

  7. “MB2-BCT” do I just leave this as it is? No need to change anything ?

  8. After performing the steps above, which I can narrow down (please confirm) to some conf file changes and then dropping in the dtsi files… what do I then do? Don’t I need to recompile the entire image (like I would have done with Yocto?)

  9. Lower down the guide, you mention this “ Porting the Linux Kernel Device Tree Files” - this seems to be just changing dts files and regenerating a new dtb…. Is this “instead of” what you describe above by using an entirely new dts file? Or as well as?

You can also do it on your x86 host PC.

If you only change the device tree, but not kernel code, then I think it’s not necessary.

Not sure about your question here. Do you mean where you will see this change take effect?

You can just use the sample rootfs provided by NVIDIA if you don’t plan to have a customized rootfs.

For Q5~7, I think you have to deep into the guide and see what changes you make to your custom board, which makes it different from our DevKit, and generate corresponding dtb files.

Is this one similar to Q2? Usually, recompiling kernel images are required when you want to use some peripheral devices, which needs to be enabled in kernel config. Note that kernel image and DTB files, which you need here, are two different things.

I think it’s just another perspective of how you start from the default device tree, and customize it to fit your need.

1 Like

Hi Dave

thanks for the info…

Q3 : Where do i rename the board in the files? what do i need to rename exactly?

Is renaming the board simply a process of creating a new .conf file ?

For Q5-7… : I am asking if this is where we put the new dtsi files generated by your pinmux tool, I am guessing in here:

/nvidia/nvidia_sdk/JetPack_5.1.1_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra

I then need to ensure the .conf files such as…

p3768-0000+p3767-0000.conf

now point ot the new .dtsi files

Is that correct?

I dont think i need to recompile the kernel, I am quite sure i only need to change the dtsi files and ensure that they are applied to the image upon boot…

When are tyhe .dtsi files compiled into .dtb files? is this handled by this script? Or do i need to do it manually?

$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1
-c tools/kernel_flash/flash_l4t_external.xml -p “-c bootloader/t186ref/cfg/flash_t234_qspi.xml”
–showlogs --network usb0 internal

Can anyone help with these steps?

I am at the stage where I have added the dtsi files to the locations indicated, so what’s next?

The guidance webpage is a little disjointed

I think the answer is yes.

Yes, but just make sure you are using the correct<board>.conf file, which is how you name your custom board.

You need to compile them yourself.

Ok

But then… what do i do with the compiled dtb files? Is there no guide at all for this?

All other vendors for embedded linux i used in the past always provide guides, where Nvidia are providing almost nothing at this stage…

We are designing a product we intend to manufactures in very high volume (50k units plus)… sure nvidia have more detailed documentation to assist with getting a custom carrier board working?

Hi,

I think you should just replace the default dtb files with the one you create, and flash to see if you can pass it or get any errors.

fair play dave :)

i like that approach…

but… the dtb files wont have the same names as the default ones… shall i rename the file and replace them you reckon?

Hi,

you should reflect changes in dtb files by specifying them in your <board>.conf file.
https://docs.nvidia.com/jetson/archives/r35.3.1/DeveloperGuide/text/HR/JetsonModuleAdaptationAndBringUp/JetsonOrinNxNanoSeries.html#flashing-the-build-image

You can also specify kernel dtb in /boot/extlinux/extlinux.conf, and it should be easier to replace it without re-flashing in case your kernel dtb fails to work.

1 Like

thanks Dave

i will have a go at both approaches…

For the “quick and dirty” appraoch, you are talking about changing this line to reflect the new .dtb i have compiled from the .dtsi from the pinmux file right?

Does this also handle the other .dtsi/dtb files generated from the pinmux excel sheet?

One more questio,n you say that the dtb must be manually compiled using a dtc compiler… if so, why do you not mention that here?

Your guide seems to imply that you simply need to copy the 3x .dtsi that are generated by the excel sheet into the locations, then alter the conf file created for the board…

then flash it…

Where does it mention that you need to use dtc to compile the .dtsi files before flashing?

Also, where does the xxx-gpio-defasult.dtsi get mentioned in the build scripts/conf files? I cannot see where you reference to it…

Does the modifed .conf script not handle all of the compilation including the .dtb compilation? I would assume so as you do not mention anywhere in the guide that you need to use dtc directly…? ?

Hi,

sorry for misleading, and please ignore my previous comments.

There is no need to manually compile dtb files.
You just need to replace the default dtsi files with the one you generate with our spreadsheet, and make sure your <board>.conf points to the right dtsi files.

1 Like

Thanks dave…

So just to clarify :)

I place the 3x dtsi files in the locations instructed here…

Note : I am going to be using the 8GB version production model in the product, so i need to flash that… I will be obviously using external nVME is storage…

So should i use the devkit carrier with the 8GB production (no SD slot) Orin Nano and a blank nVME SSD connected?

Then connect up and flash it with the modified .conf file ?

As follows…

image

One question, how come the gpio-default.dtsi isn’t mentioned in any of the .conf files? Is it automatically picked up?

The padvoltage.dtsi and pinmux.dtsi are specifically mentioned you see…

Hi,

it’s already included in the first pinmux dts file, so you don’t need to specify it.

So you want to like, emulate how it will do on your custom board with an official DevKit? I think it should do it.

gotcha ref the dtsi…

Well i just want to know the best way to actually flash the orin for my custom carrier…

Should i just connect the orin to my custom carrier, put it in force recovery, power up, then flash it connected to my custom carrier?

From your documents, it seemed to imply I needed to flash it using the devkit before connecting to the custom carrier as in your guide it states:

But i would think that flashing it once its connected to my custom carrier board is correct, isn’t it?

Yes, I think it should work.

1 Like

ill try a flash today on the devkit using the standard .dtsi and just try renaming the board to see if it is reflects in the rootfs file structure… then go for it on the custom carrier with the custom dtsi and cross my fingers :)

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.