I want to disable console on UART0 or change console port. I was able to do this for Linux, but uBoot is still using UART0 for its console. I was not able to change environment variables for “stdin, stdout, stderr” (Error “22”), since they are read-only.
I have not found any working solution on complete disabling console on UART0.
Is there any compiled uBoot.bin or some instructions on how to make UART0 free of console in/out?
This was how to accomplish that under R28.1/TX2, but there may have been enough changes that this no longer applies within R32.1/TX2:
[url]https://devtalk.nvidia.com/default/topic/1025894/jetson-tx2/uart1-acts-as-default-debug-port-on-tx2-r28-1/post/5220368/#5220368[/url]
If that doesn’t work someone will need to comment on U-Boot serial console in R32.1/TX2. It would be useful to know if this works or fails.
These instructions doesnt help for U-Boot. Ive made complete flashing and bootloader-only. Console is still working on UART0.
U-Boot is its own separate program, plus the Linux kernel takes over after it loads. So both must be disabled. When in Linux, what do you see from “cat /proc/cmdline”?
Some of what U-Boot does depends upon device tree, and it isn’t unusual for edits to not actually be put in place. The device tree used to be via a file in “/boot” (and U-Boot also now passes on some inherited command line from the device tree), but is now a partition (some boot stages from earlier than U-Boot now need that information and those stages cannot read ext4). If you changed a file in “/boot” for device tree, then this is why U-Boot did not change. What do you see from:
cat /proc/device-tree/chosen/bootargs
If updates were successful, then you will not see “console=ttyS0,115200n8”.
From “cat /proc/cmdline”:
root=/dev/mmcblk0p1 rw rootwait console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0xc280000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.983055.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
From “cat /proc/device-tree/chosen/bootargs”
root=/dev/mmcblk0p1 rw rootwait console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0xc280000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.983055.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4
As I can mention results are similar.
There is no “console=ttyS0,115200n8”.
So far as actual command line arguments go this would be enough. Other steps in the device tree are to change its use to/from the non-DMA driver and the DMA-capable driver.
Although the U-Boot stage is incapable of using the DMA version of the driver (and by default it uses the standard non-DMA version) this would not actually change an attempt by U-Boot or Linux to use the device. In the case of U-Boot the normal setup is to use the regular driver (which exists within U-Boot), and then when Linux takes over to continue to use the same non-DMA driver. It would be useful to know which stage(s) is using the UART.
Can you provide a boot log from the serial console connector to show what is still being printed?