How to use UART0 as normal uart port on R28.1?

Hi Richardzhr,

In fact, after rel-28.1, arguments are passed by dtb and update extlinux.conf is not valid way anymore.

I guess it means you still need to rebuild the dtb. Sorry for your inconvenience.

Thank you for ur reply!Can u give me more advice to change the dtb file? which file I can disable uart0 debug fun?

Please take a look at tegra186-quill-p3310-1000-a00-base.dts.

@WayneWWW,Thank you for ur reply! I follow ur guide and change tegra186-quill-p3310-1000-a00-base.dts file.

chosen {
		board-has-eeprom;
	        //bootargs ="console=ttyS0,115200";                             
		stdout-path = &uarta;
	};

I comment <bootargs =“console=ttyS0,115200”; > line, but all the same. How to change this file to take effect?

Hi Richardzhr,

if the removal is effective, the uart console should be disabled after kernel is up. Is this what you want??

Hi Richardzhr,

The bootargs will be replaced by the setting in “p2771-0000.conf.common” (under the same dir with flash.sh) if you follow the DTB update method in this page Jetson/TX2 DTB - eLinux.org.

CMDLINE_ADD="console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0";

If you diff the original dts and the “args appended” dts, you will get:

chosen {
+               bootargs = "root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0  ";
                board-has-eeprom;
-               bootargs = "console=ttyS0,115200";
                stdout-path = "/serial@3100000";
+
+               plugin-manager {
+
+                       odm-data {
+                               l4t;
+                       };
+               };
        };

So, if it’s not convenient for you to update the DTB in recovery mode, you can manually append the args like that (remove the console part as you wish), compile it to dtb, and dd the dtb into /dev/mmcblk0p15.

sudo dd if=tegra186-quill-p3310-1000-c03-00-base.dtb of=/dev/mmcblk0p15

Also remember to remove the “FDT” in extlinux.conf.

Hi,

We also want to disable serial console function and let uart0 to normal, but we need Local camera that not use J17, we also disable serial console like Richardzhr on R27.1, and it is working well.
Now for R28.1, we follow ZhangXin comment and try https://devtalk.nvidia.com/default/topic/1001264/tx2-uarts/?offset=29 link

what I do is like following:

  1. Create Test Environment
sudo apt-get install device-tree-compiler
mkdir tempDTS
cd tempDTS
sudo -s
  1. Decompile dtb to dts
dtc -I dtb -O dts -o extracted.dts /boot/tegra186-quill-p3310-1000-c03-00-base.dtb

2.Rewrite dts

chosen {
                bootargs = "root=/dev/mmcblk0p1 rw rootwait OS=l4t fbcon=map:0 net.ifnames=0  ";
                board-has-eeprom;
                stdout-path = "/serial@3100000";
 
                plugin-manager {
 
                        odm-data {
                                l4t;
                        };
                };
        };

3.Compile dtb from edited dts

dtc -I dts -o dtb /boot/modified_tegra186-quill-p3310-1000-c03-00-base.dtb extracted.dts

4.Add testing LABEL in /boot/extlinux/extlinux.conf

TIMEOUT 30
DEFAULT testing

MENU TITLE p2771-0000 eMMC boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

LABEL testing
      MENU LABEL test kernel
      LINUX /boot/Image
      FDT /boot/modified_tegra186-quill-p3310-1000-c03-00-base.dtb
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

but after that… console still not disable and TX2 Ethernet function not working,

We also try following, but still same with above:

TIMEOUT 30
DEFAULT primary

MENU TITLE p2771-0000 eMMC boot options
LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      FDT /boot/modified_tegra186-quill-p3310-1000-c03-00-base.dtb
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

Do I miss anything? or it should not be work?

Hi Arlen0615,

Please try to put the dtb into kernel-dtb area using dd on TX2:

sudo dd if=your_dtb.dtb of=/dev/mmcblk0p15

And remove the “FDT” line in the extlinux.conf.

I heard that the DTB will be used by both kernel and u-boot, so the “FDT” way doesn’t fully work as it can’t pass the DTB to u-boot.

Hi ZhangXin,

Thanks for your replying very much, it’s work, so let me update work solution…

Our request is totally disable console of UART0(we need local camera so not use J17), because we need “send” and “receive” data from another MCU board, following is working on JetPack 3.1 in my side:

0.Create Test Enviroment

sudo apt-get install device-tree-compiler
mkdir tempDTS
cd tempDTS
sudo -s

1.Decompile dtb to dts

dtc -I dtb -O dts -o extracted.dts /boot/tegra186-quill-p3310-1000-c03-00-base.dtb

2.Rewrite dts

sudo gedit extracted.dts

Find the string ‘bootargs’ and modify:

chosen {
           bootargs = "root=/dev/mmcblk0p1 rw rootwait console=19200n8 OS=l4t net.ifnames=0  ";
           board-has-eeprom;
           stdout-path = "/serial@3100000";
           plugin-manager {
                   odm-data {
                           l4t;
                   };
           };
        };

PS:console=19200n8 set for my MCU board, please depends on yours

3.Compile dtb from edited dts

dtc -I dts -O dtb -o /boot/modified_tegra186-quill-p3310-1000-c03-00-base.dtb extracted.dts

4.Find kernel-dtb position
sudo gdisk -l /dev/mmcblk0 | grep -i ‘kernel-dtb’
PS:If first number show 15, it mean mmcblk0p15

  1. Put dtb file
sudo dd if=/boot/modified_tegra186-quill-p3310-1000-c03-00-base.dtb of=/dev/mmcblk0pxx

PS:mmcblk0pxx is depend on your JetPack version
JetPack 3.1 — L4T R28.1 : mmcblk0p15
JetPack 3.2 — L4T R28.2 : mmcblk0p25

6.reboot

2 Likes

Once boot is complete you can verify what command line was actually used via “cat /proc/cmdline”. You can also verify what device tree was actually used via:

dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree

It is possible that a change to serial console settings (such as in bootargs of the device tree) might or might not change serial console during the U-Boot stage. The settings seen from the running system (as extracted above) are not necessarily the settings which were active while U-Boot runs. I have not tried to disable serial console within U-Boot so I do not know for certain when and where settings must be changed to stop U-Boot serial console.

A typical issue if trying to use the serial console port for other uses is that boot would halt if any data is seen by U-Boot and mistaken for a key stroke.

Interesting. Given that “dd” is a binary clone/copy command, I’m wondering if the device “mmcblk0p15” maps to “/proc/device-tree”. Could someone elaborate?

I also notice that NVidia’s staff hasn’t yet endorsed the DT live-update approach. It seems the process may impact the boot stages of sequence. Perhaps it’s less clean than flash from the host. But the convenience overweighs the efforts. Hope the method could be officially verified soon.

“/proc/device-tree” is a symbolic link into “/sys”, which in turn is an in-memory image produced by the kernel and is not a real file system. Partition 15 (mmcblk0p15) has label “kernel-dtb” under R28.1/TX2, so this is the device tree binary (expect a partition size of 512*1024 bytes…an actual file may truncate before the end of this…usually extra bytes of such a partition are NULL byte padded).

What you see in “/proc” tells you what the kernel finally decided on for device tree…what you see in mmcblk0p15 is what the kernel was told to try to load. Should everything the kernel was told to do actually succeed I would expect the two to match; should there be an error, I would expect the in-memory version to be authoritative and the partition to need adjustment.

Will this approach work on a TX1 with L4T28.1 as well? Or does the TX1 use the same old /boot/ location for DT?

Edit: I just tested this. On TX1 it works by just changing the extlinux.conf and changing the dts file.

Hi linuxdev,

Based on folowing you told us:
“/proc/device-tree” is a symbolic link into “/sys”, which in turn is an in-memory image produced by the kernel and is not a real file system. Partition 15 (mmcblk0p15) has label “kernel-dtb” under R28.1/TX2,"

Could I possible know which Partition has kernel-dtb?

Could you give me some command to know about this?

Reason:
I try to backup and recovery my R28.1/TX2, but it’s not working on following command
sudo dd if=/boot/modified_tegra186-quill-p3310-1000-c03-00-base.dtb of=/dev/mmcblk0p15,
once I do this… I can not boot up.

I though this may cause by I use JetPack3.2 to backup and recovery image…

so I try to find which Partition has kernel-dtb and try it again…!

Thanks very much!

Keep in mind that a label doesn’t really guarantee what content is there, but it does say which partition a program using labels will use. Sometimes old labels may be there where nothing is actually relevant. That said, kernel-dtb is partition mmcblk0p15 in R28.1 of of a TX2. Verifiable via “sudo gdisk -l /dev/mmcblk0 | grep -i ‘kernel-dtb’”.

How these partitions are used and what is proper to fill them with depends on which L4T version, so mixing R28.1 and R27.1 for example usually causes boot failure.

I can verify though that if you use dd under R28.1 to copy the number of bytes in tegra186-quill-p3310-1000-c03-00-base.dtb (the byte size of the file used during a flash), that you will get an exact match to the original file. I can also verify that so long as your version of tegra186-quill-p3310-1000-c03-00-base.dtb fits within the size of the mmcblk0p15 partition that updating via placing the dtb in that partition via dd will also succeed as an alternative to flash.sh as a means of dtb update. It may be wise to make sure a single byte following the dd is NULL, but this is not likely required (NULL padding after placing a binary file in the partition is traditional, but unlike the C printf() function, NULL is not usually used to determine the end of the file…NULL bytes at the end does make it clear what you intended to place there).

The same procedure should apply to R28.1 on both the TX1 and TX2, but I have not verified that both use the same mmcblk0p15 with label kernel-dtb…perhaps they are the same, perhaps they are rearranged for a TX1. I also have not verified that this procedure works for other releases, but typically dtb is not a partition in earlier releases.

NOTE: The dts produced if extracting “/proc/device-tree” is a combination of a number of dtb files where one is loaded and might overwrite or extend parts of another at different stages of boot. “/proc/device-tree” is a final effect, and not from a single file.

1 Like

Hi linuxdev,

Thanks very much and Happy new year!

I use "sudo gdisk -l /dev/mmcblk0 | grep -i ‘kernel-dtb’ to find kernel-dtb in JetPack 3.2 — L4T R28.2

This is mmcblk0p25 in JetPack 3.2 — L4T R28.2, I dd with /dev/mmcblk0p25 and it can boot and work normally.

PS: I make a mistake that use JetPack 3.2 environment host to backup my TX2 mmcblk0p1 with JetPack 3.1 R28.1, and then use JetPack 3.2 environment host to flash my TX2… even I flash with wrong version, it seems all is work~! All my software like tensorflow, caffe and wifi setup is same and work. But in the last step I found serial port is not work because kernel-dtb is not same with old one, so I “dd” the fixed dtb to mmcblk0p15, but it makes system not boot. Finally, follow your command to find labels of kernel-dtb, change to mmcblk0p25 and it’s work now.

I also update my procedure with old comment in this loop, but I am not so clear following you said…
It may be wise to make sure a single byte following the dd is NULL, but this is not likely required (NULL padding after placing a binary file in the partition is traditional, but unlike the C printf() function, NULL is not usually used to determine the end of the file…NULL bytes at the end does make it clear what you intended to place there

I worry about my process may not so suitable or make some function fail…

On 28.1 I have tried the following to deploy a DTS to the kernel without using the flash utility with success.

if you build a DTB the way described in the developer guide and then flash a unit with the image created using the flash utility you will notice a difference between the dtb on the unit (dd if=/dev/mmcblk0p15 of=mydtb.dtb) the dtb in your kernel build output upon disassembly. The dtb from the kernel build will have something like

chosen {
		bootargs = "console=ttyS0,115200";
		stdout-path = "/serial@3100000";
	};

while the on unit dtb has something like

chosen {
  bootargs = "root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0  ";
  stdout-path = "/serial@3100000";

  plugin-manager {
      odm-data {
      l4t;
    };
  };
};

This appears to be added during flashing when the image is being compiled. So to change the device tree of a unit without using the flash utility I would recommend:

  1. Compile your dtb from your dts adding in the above plugin-manager portions and additional bootargs as described above
  2. Then on the unit zero out the mmcblk0p15 partition. This is to ensure no part of the old dtb remains in case your new dtb is smaller than than the original. On my system this can be done by running dd bs=1 count=524288 if=/dev/zero of=/dev/mmcblk0p15
  3. Write your newly created dtb to mmcblk0p15 (dd if=mydtb.dtb of=mmcblk0p15)

2 and 3 are permanent operations so make sure you know what you’re doing because it will brick a unit. Also this only changes the dtb used by the kernel. If you need to change pinmuxing or pad voltages (i.e. things in mb1 or uboot) this will not work.

1 Like

I missed a detail in a previous post…

“truncate” can be used to enlarge a file…it can do more than shrink a file. Try it out on a small text file, verified with a hex editor before and after.

Note that if a serial console has any bytes of activity at all it will pause boot and wait for either a boot selection or go into the U-Boot shell. Should it look like serial console is halting something, then it might be that part of it put out an extraneous byte somewhere.

Just for curiosity…

When looking at the kernel-dtb partition versus what shows up after boot in “/proc/device-tree/” versus what is in any individual dtb file used during flash it might be useful to know that U-Boot itself uses a device tree, but that this device tree may differ from the kernel device tree. Some parts of drivers are in common between U-Boot and the kernel, while U-Boot may have its own driver in some cases. U-Boot definitely does not initialize as much as the full Linux kernel as well. Some of the hardware will be initialized and put into some state before Linux runs…U-Boot puts the device tree from the kernel-dtb partition into RAM along with the Linux kernel (and any initrd), and then Linux runs (essentially overwriting U-Boot). I don’t know if U-Boot does any editing of the kernel-dtb before it goes into RAM, but it might…and certainly there could be some state inherited by Linux which U-Boot left even though the parameter is not specified. Parts of what you see in device tree code may end up ignored by the Linux stage…parts of what is purely for U-Boot might cause some hardware to inherit this state.

1 Like

I want to update my Jetson TX2’s (l4t 32.3.1) device tree without using flash.sh. Examining the partition table I see that both partitions 30 and 31 match when I search for “kernel-dtb”

sudo gdisk -l /dev/mmcblk0 | grep -i 'kernel-dtb'
  30        59804024        59805047   512.0 KiB   0700  kernel-dtb
  31        59805048        59806071   512.0 KiB   0700  kernel-dtb_b

I notice this is a pretty old thread and I’m wondering if anyone else tried this with l4t-32.3.1?