Where can I build the dtb file?

The name of this file is “tegra186-bpmp-p3636-0001-a00-00.dtb”.
Where can I build the dtb file? u-boot?

hello poke08121,

you cannot build this binary,
this is bpmp firmware, which we don’t public release the sources.

When I porting the module Device tree, I find out some COM port signal are conflicts with the DTB file that I listed(tegra186-bpmp-p3636-0001-a00-00.dtb).
It caused a lot of trouble for our mass production as we spend lots of time to find out the root cause.
I understand that DTB parts might be confidential,
is there any way that we can avoid this issue ( signal mutual exclusive)
EX: a signal table to allow us to check ?

You might want to add more details about what you mean that there is a conflict with a COM port. In Linux I’d call the hardware the serial UART, and the port the UART runs in “/dev/ttySOMETHING#”. It is unlikely that the boot power management actually has anything to do with which port a UART uses (later stages would tend to do this, although some of those stages are in bootloader stages after the BPMP starts).

Note: Typical integrated UART port legacy drivers show up with naming convention “/dev/ttyS#”. Typical integrated UART ports using the Tegra High Speed driver (which enables DMA) will use naming convention “/dev/ttyTHS#”. Typical FTDI external devices would use naming convention “/dev/ttyUSB#”. Another common manufacturer’s device files would show up as “/dev/ttyACM#”. The “#” just being a number starting at 0.

hello poke08121,

you should also access Jetson TX2 Series OEM Product Design Guide, and please check [13.3 UART] chapter to examine the UART connections.
you may download the pinmux spreadsheets to update the pinmux configuration applied by the software. please refer to developer guide, pinmux changes as see-also.
tanks

One more thought: The most common failures are from not using a 3.3V logic level, or else the port being set to the wrong speed at one end (each half of the UART connection must have matched settings, and the two ends have no ability to query the other, so they depend on being blindly configured correctly…there is a device tree related to default speed and other settings, but it isn’t the BPMP dtb).

Thanks for your reply, what I mean “conflict” is:

After I change the setting of BPMP, my com port start working.

I think i got to narrow down the question : how can I avoid this kind of " conflict" in future image building?

hello poke08121,

this port, uartc: serial@c280000, which is being used for output BPMP logs by default.
if you’re using that for other purpose then you should follow the steps to disable BPMP logs.

Where can I find this information in any documents?

hello poke08121,

you should look into the source release for details.
please download L4T Driver Package (BSP) Sources from https://developer.nvidia.com/embedded/linux-tegra.

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