Jetson Nano early boot DeviceTree

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

Hello,

we observed a undesired behavior using custom device-trees (and custom carrier-boards). It seems that our device tree is only activated in a “late” boot phase, once the kernel is taking over. As I understand the documentation, the jetson first boots via the bpmp, shipping its own firmware / device tree – I recon this is also the one active in fc-recovery mode? Is it possible to somehow exchange this earliest boot device tree esp. the pinmux table of it → we would like to “silence” a few pins until later.

Best,

Axel

2

It is unlikely. As I remember the pinmux is handled in late stage on Jetson nano.

Only new platforms like TX2/Xavier/Orin handled the pinmux in earlier stage.

3

Hi Wayne,

thank you for the prompt answer. Just for making things explicit:

  1. you agree on my understanding of the used, distinct device trees (bpmp → u-boot → kernel)
  2. we may change the u-boot and kernel DTs, but will have a hard time with the bpmp on Nano / t210 platform

Best,

Axel

4

There is no “bpmp” on Jetson nano at all. It is nvtboot → cboot → uboot → kernel

5

So this documentation seems a little misleading: generic-no-api-public_r2
(I would assume nvtboot is part of the BPMP)

Now, from the documentation, cboot is responsible for initializing the BL device tree → is there a chance to modify this step? or do I misunderstand this part and the BL device tree already is the same as the u-boot DT?

6

Just to clarify. You cannot customize anything before uboot.

It does not matter what term it is. They are not open source and no configuration files for them to configure pinmux.

7

Thank you, I think I get the picture.

8

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