Need help with Porting U-Boot for Platform Adaptation to a custom carrier board

Autonomous Machines Jetson & Embedded Systems Jetson Nano
,
1

Hi. We have a custom board that is built to support both the Nano. I have been following the Platform Adaptation Guide for bring up of our board. I am stuck at the part where I have to port U-Boot: Porting U-Boot

I have followed the guide up till “3.Copy arch/arm/dts/tegra210-p3450-porg.dts to arch/arm/dts/tegra210-.dts.” Now I am editing the arch/arm/dts/tegra210-<board>.dts.

In the kernel device tree the compatible string is used to bind a device with a driver. But in the root node of arch/arm/dts/tegra210-<board>.dts there is the following compatible string compatible = "nvidia,p3450-0000", "nvidia,tegra210";. The porting guide does not elaborate on what modifications need to be made to this property.

Should it be changed to compatible = "<vendor>,<board>", "nvidia,tegra210";? Or should it be left as it is?

3

Hi,

Actually, there is not necessary to customize uboot dtb in current release. The cboot and kernel dtb shall handle most of work. May I know why you want to customize the uboot dtb?

4

We are using the Yocto Build System to create a custom linux image for our custom carrier board. Our custom board has some differences in comparison with the B01 board. In Yocto we are using the meta-tegra layer to create an image for the B01 Devkit paired with the production emmc module. The meta-tegra layer comes with some machine configuration files that define the platform. This machine configuration file is responsible for various things, among which is defining the name of the defconfig that is supposed to be used by U-Boot. So, U-Boot is being used in the Boot process of the image.

Because our board different, I am using the Platform Adaptation Guide. I have added the pinmux related changes, and next step in the Platform Adaptation is to Port U-Boot. Now going through the tegra210-p3450-porg.dts I see that it enables Serial, USB, PCIe, GPIOs, I2C, SPI and Clocks among other things. Our board does not have some of these interfaces. So it seems like I should change the U-Boot to correctly reflect the hardware topology of our custom board.

Currently I am following the steps in the U-Boot Porting guide from the NVIDIA Developer Guide. I have linked the same in the first post. Because we have named our board differently, I have changed the name for the include/configs/.h in the U-Boot sources. In the same manner following the steps in the guide, I have renamed the DTS file and will rename the defconfig.

Now the step 4 of the Porting Guide says the following
Edit the set of enabled devices and their parameters (e.g. GPIO and IRQ IDs) in tegra210-<board>.dts as appropriate for your board.
And this make me wonder what the significance is of compatible = "nvidia,p3450-0000", "nvidia,tegra210"; property. Because it refers to the devkit board, it seems to me like it should change.

5

Hi,

I am still not sure if this is really needed to make your change to “uboot”. The pinmux setting has been already moved to cboot for quite time and I believe even if you are using “Yocto build system”, cboot is still there in the boot sequence.

Those interface in uboot dtb may only indicate those functions are in use/not in use in the “uboot”. It may not affect the function after entering kernel.

Also, I think you don’t need to worry about the “name” at this moment. Just make sure the original one can meet your requirement first…

We have lots of tutorial in the document says customers can modify the name to match their board. However, actually most of them are not needed. The worse thing is some of those “renaming” break some function.

6

Thanks for the quick replies.

Yup cboot is still present in the boot sequence.

Makes sense. But can having certain not connected interface enabled create some issue for U-Boot? Or maybe create some difficulty for U-Boot in loading the kernel?

The below code snippet is from the tegra210-p3450-porg.dts

sdhci@700b0000 {
	status = "okay";
	cd-gpios = <&gpio TEGRA_GPIO(Z, 1) GPIO_ACTIVE_LOW>;
	power-gpios = <&gpio TEGRA_GPIO(Z, 3) GPIO_ACTIVE_HIGH>;
	bus-width = <4>;
};

As can be seen in the snippet, it sets the state for some pins.I am new to board bring-up and device tree and u-boot. So I am learning as I go. I am not very sure as to what it is exactly doing, seems to be enabling the power for the mmc interface. We have quite a few changes in the GPIO configuration compared to the B01. Can leaving this node as it is be an issue?

Whoa! Thanks for the heads up. I am using the L4T 32.4.3 documentation as that is the release we have in our image. Have some of these documents been revised for the later versions? Or does any of the NVIDIA partner that makes custom carrier board for the Nano release any documentation for board bring-up?

7

Hi,

If you suspect some device should be disabled in those uboot dtb, then you can just set status to “disabled”.

The naming problem is not due to the bring up itself, it is more complicated. For example, from “bring-up” point of view, it is ok to just change the name. But for some userspace tool… they need to use the board name to tell which configuration to be used. To prevent sucn unnecessary issue, there is no need to change all the names…

BTW, most of other customers didn’t change their uboot when they make their own custom board either…

1 Like
8

Got it. I will give it a try and see. Thanks for the help.

10

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