Faster boot via disabling UART during MB1, MB2, and CBOOT

Hi, I read the related topic here and can’t get the MB1 -> MB2 -> CBOOT “combined uart” to be disabled.

We tried this in several of the .cfg files without success (the system locks up and appears to not finish booting… we’re using SSH to login):

enable_combined_uart = 0;

Instead, we manually disabled the UART (e.g., intercept the printing function) during CBOOT and during standard Jetpack 4.3 kernel bootup (by removing the “console=ttyTCU0” from the kernel commandline passed from CBOOT).

We also need to disable the UART during MB1, MB2, Trusty, SPE, CBOOT and any other IP Blocks which might use the UART during startup. Our goal is to boot faster. We are booting to eMMC without a display.

An example of the MB1 text output to the UART is shown below:

[0000.053] W> RATCHET: MB1 binary ratchet value 4 is too large than ratchet level 1 from HW fuses.
[0000.062] I> MB1 (prd-version:
[0000.067] I> Boot-mode: Coldboot
[0000.070] I> Chip revision : A02 
[0000.073] I> Bootrom patch version : 7 (correctly patched)
[0000.078] I> ATE fuse revision : 0x200
[0000.082] I> Ram repair fuse : 0x1
[0000.085] I> Ram Code : 0x0
[0000.087] I> rst_source : 0xb
[0000.090] I> rst_level : 0x1
[0000.094] I> Boot-device: eMMC
[0000.108] I> sdmmc DDR50 mode
[0000.113] W> No valid slot number is found in scratch register
[0000.118] W> Return default slot: _a
[0000.121] I> Active Boot chain : 0
[0000.125] I> Boot-device: eMMC
[0000.128] W> MB1_PLATFORM_CONFIG: device prod data is empty in MB1 BCT.
[0000.134] I> Temperature = 52500
[0000.138] W> Skipping boost for clk: BPMP_CPU_NIC
[0000.142] W> Skipping boost for clk: BPMP_APB
[0000.146] W> Skipping boost for clk: AXI_CBB
[0000.150] W> Skipping boost for clk: AON_CPU_NIC
[0000.154] W> Skipping boost for clk: CAN1
[0000.158] W> Skipping boost for clk: CAN2
[0000.162] I> Boot-device: eMMC
[0000.165] I> Boot-device: eMMC
[0000.174] I> Sdmmc: HS400 mode enabled
[0000.179] I> ECC region[0]: Start:0x0, End:0x0
[0000.183] I> ECC region[1]: Start:0x0, End:0x0
[0000.187] I> ECC region[2]: Start:0x0, End:0x0
[0000.191] I> ECC region[3]: Start:0x0, End:0x0
[0000.195] I> ECC region[4]: Start:0x0, End:0x0
[0000.199] I> Non-ECC region[0]: Start:0x80000000, End:0x100000000
[0000.205] I> Non-ECC region[1]: Start:0x0, End:0x0
[0000.210] I> Non-ECC region[2]: Start:0x0, End:0x0
[0000.214] I> Non-ECC region[3]: Start:0x0, End:0x0
[0000.218] I> Non-ECC region[4]: Start:0x0, End:0x0
[0000.224] E> FAILED: Thermal config
[0000.231] E> FAILED: MEMIO rail config
[0000.244] I> Boot-device: eMMC
[0000.254] I> sdmmc bdev is already initialized
[0000.320] I> MB1 done

Any ideas how to disable the UART usage further during bootup? Does Jetpack 4.4 help any of this, since we are currently using Jetpack 4.3?

Thank you.

hello andy.nicholas,

you may update below configuration file to disable bootloader messages;
i.e. $OUT/Linux_for_Tegra/bootloader/t186ref/BCT/tegra194-mb1-soft-fuses-l4t.cfg
please refer to Topic 145106 for more details.

That helped a huge amount, Thank you!

But there is still a significant amount of debugger output from some other IP Blocks that we would like to suppress. Any thoughts on what’s remaining below?

����main enter
SPE VERSION #: R01.00.14 Created: Sep 19 2018 @ 11:03:21
HW Function test
Start Scheduler.
in late init

welcome to lk
calling constructors
initializing heap
creating bootstrap completion thread
top of bootstrap2()
initializing platform
bpmp: platform_init
tag is c1b4e372932429f2737cf722e1219e71
tag_show initialized
dt initialized
mail initialized
chipid initialized
fuse initialized
sku initialized
speedo initialized
ec_get_ec_list: found 45 ecs
ec initialized
ec_mrq initialized
vmon_populate_monitors: found 3 monitors
vmon initialized
adc initialized
fmon_populate_monitors: found 73 monitors
fmon initialized
fmon_mrq initialized
reset initialized
nvhs initialized
392 clocks registered
WARNING: pll_c4 has no dyn ramp
clk_mrq_init: mrq handler registered
clk initialized
nvlink initialized
io_dpd initialized
io_dpd initialized
thermal initialized
i2c5 controller initialized
initialized i2c mrq handling
i2c initialized
regulator initialized
avfs_clk_platform initialized
soctherm initialized
aotag initialized
powergate initialized
dvs initialized
pm initialized
pg_late initialized
strap initialized
tag initialized
emc initialized
clk_dt initialized
avfs_ccplex_platform initialized
tj_max: dt node not found
tj_init initialized
uphy_mrq_init: mrq handler registered
uphy_dt initialized
uphy initialized
safereg initialized
  ��mrq initialized
fmon_post initialized
clk_dt_late initialized
machine_check initialized
pm_post initialized
dbells initialized
avfs_clk_platform_post initialized
dmce initialized
cvc initialized
ccplex_avfs_hw_init: nafll_cluster0: not monitored
ccplex_avfs_hw_init: nafll_cluster1: not monitored
ccplex_avfs_hw_init: nafll_cluster2: not monitored
ccplex_avfs_hw_init: nafll_cluster3: not monitored
avfs_clk_mach_post initialized
regulator_post initialized
rm initialized
sc7_diag initialized
thermal_test initialized
serial_late initialized
clk_post initialized
clk_dt_post initialized
mc_reg initialized
pg_post initialized
dyn_modules initialized
sku_debugfs initialized
speedo_debugfs initialized
adc_debugfs initialized
clk_debugfs initialized
emc_debugfs initialized
dvs_debugfs initialized
fmon_debugfs initialized
vmon_debugfs initialized
pg_debugfs initialized
profile_fs initialized
debugfs_cons initialized
mail_fs initialized
profile initialized
cvc_debugfs initialized
dmce_debugfs initialized
ec_debugfs initialized
rm_debugfs initialized
soctherm_debug initialized
gr_reader initialized
mods initialized
dt_fs initialized
debugfs_mrq initialized
debug_mrq initialized
debug_safereg initialized
initializing target
calling apps_init()
starting app shell
entering main console loop
] ��<hit enter to activate fiq debugger>
��WARNING: clk_get_rate: clk_power_ungate on gated domain 27 for gpcclk```

hello andy.nicholas,

that’s very early stage bootloader logs.
you may also refer to Topic 122047 to change the log levels.

Ok, I tried the suggestions from the other Topic 122047 and the results are not good:

debug.enable_log = 0;
Nothing changed.

spe_uart_instance = 0xFF;
After doing this change, the flashing system stopped halfway through the flash mechanism. After reverting the files back to “spe_uart_instance = 2” I was able to revert the changes and reflash to a working system (which still outputs the stuff above).

The items above look like they might originate from the SPE. Some of the SPE sources are available, but it doesn’t look like it is the “spe_combined_uart” so I’m not sure how to disable the UART text yet. We also run Trusty which could be emitting the messages maybe.

I looked through the SPE source code and the Trusty source code and neither one have most of the message text above. So I’m guessing it’s MB1 or MB2 text which is not properly silenced using “Verbosity=0”

hello andy.nicholas,

it correct by setting Verbosity=0 cannot disable MB1 and MB2 messages, you should further to modify the header file to update the log levels;
please access CBoot sources via download center, you might refer to post #18 in Topic 122047 to have changes to disable uart-message for MB2/cboot.

Hi Jerry, I downloaded and built the cboot sources and applied the changes in post #18 of Topic 122047. The result is the text above. Yes, the amount of text is greatly reduced, but it’s not near zero.

is there something you see which makes you think the text comes from cboot instead of mb2 or spe? For instance, I can’t find the word “speedo” in any of the cboot source code.

If I grep through the Nvidia Jetpack source and binaries for “speedo” I get this:

Binary file ./bootloader/bpmp.bin matches
Binary file ./bootloader/bpmp_t194.bin matches
Binary file ./bootloader/system.img.raw matches
Binary file ./bootloader/tegraparser_v2 matches
Binary file ./bootloader/boot.img matches
Binary file ./bootloader/system.img matches 

Is the source code to any of these available? If not, then an individual setting would need to disable the output. My guess would be “bpmp_t194.bin” is still sending output to the UART.

There is no update from you for a period, assuming this is not an issue any more.
Hence we are closing this topic. If need further support, please open a new one.

hello andy.nicholas,

may I know what’s the messages you seen after
(1) flashing the board with configuration to set Verbosity=0
(2) modify the header file to update the log levels;

may I have your confirmation,