Orin nano Developer kit takes long time to boot

What’s the UEFI branch using from GitHub?

I followd Build with docker · NVIDIA/edk2-nvidia Wiki · GitHub steps, check below two steps, please.

edk2_docker edkrepo manifest-repos add nvidia https://github.com/NVIDIA/edk2-edkrepo-manifest.git main nvidia
edk2_docker edkrepo clone nvidia-uefi NVIDIA-Jetson main

Any update for this case?

Please use r35.3.1-updates branch for JP5.1.1

$ edkrepo clone nvidia-uefi-r35.3.1-updates NVIDIA-Jetson r35.3.1-updates

@KevinFFF ,

I built UEFI with r35.3.1-updates, and flashed it into my board. I saw logo at about 20 seconds, this should be UEFI displaying its logo. But it still took about 59 seconds to reach the kernel boot logo and desktop screen. So this r35.3.1-updates branch should fix the issue that UEFI can’t display its logo, but the boot time is still too long as before.

Please refer to the following thread.
Optimizing UEFI boot time - #8 by ts01399984

If you don’t want network stack, you could remove them from .fdf.
Similarly other features too.

So r35.3.1-updates branch does not incude any change to reduce UEFI boot time?

As I replied you from another topic, we are still working on it.
Please try to remove the features what you don’t want to use to optimize the boot time at this moment.

Hi Harry,

There should be 4s improvement in boot up with Setup Early Mmu by ashishsingha · Pull Request #60 · NVIDIA/edk2-nvidia · GitHub.
You could just use latest r35.3.1-updates branch from GitHub for UEFI to verify.

OK. I will try it.

I tried the latest r35.3.1-updates, it did have 4s improvement in uefi boot. Will you continue to reduce the boot time since the whole boot time is about 50+ seconds to see desktop.

BTW, I also tried to remove some components in uefi like network, but I can’t see much improvement for those change, and I am afraid to remove much components because I dont know what is the side effect if I remove them.

With the latest r35.3.1-updates uefi, I found kernel oops as below. I did not see it in previous uefi.

See the attached dmesg log.
kernel_oops.txt (73.8 KB)

[ 12.808670] CPU:0, Error: cbb-fabric@0x13a00000, irq=25
[ 12.811439] ramoops: request mem region (ramoops:dmesg(519/157758) 0x10000@0x2070002) failed
[ 12.814057] **************************************
[ 12.822733] ramoops: persistent_ram_buffer_map: Failed to map 0x10000 pages at 0x2070002
[ 12.827641] CPU:0, Error:cbb-fabric, Errmon:2
[ 12.827647] Multiple type of errors reported
[ 12.827649] Error Code : SLAVE_ERR
[ 12.827651] Error Code : DECODE_ERR
[ 12.827651] Error Code : FIREWALL_ERR
[ 12.827652] Error Code : PWRDOWN_ERR
[ 12.827653] Overflow : Multiple SLAVE_ERR
[ 12.827654] Overflow : Multiple DECODE_ERR
[ 12.827655] Overflow : Multiple FIREWALL_ERR
[ 12.827655] Overflow : Multiple PWRDOWN_ERR

[ 12.835979] ramoops 2.ramoops_carveout: failed to request dmesg mem region (0x10000@0x2070002): -12
[ 12.840436] Error Code : DECODE_ERR
[ 12.840438] MASTER_ID : CCPLEX
[ 12.840439] Address : 0x0
[ 12.840441] Cache : 0x1 – Bufferable
[ 12.840443] Protection : 0x2 – Unprivileged, Non-Secure, Data Access
[ 12.840446] Access_Type : Read
[ 12.846718] ramoops: probe of 2.ramoops_carveout failed with error -12
[ 12.848939] Access_ID : 0x17
[ 12.848940] Fabric : cbb-fabric
[ 12.848941] Slave_Id : 0x36
[ 12.848942] Burst_length : 0x3
[ 12.848943] Burst_type : 0x1
[ 12.848944] Beat_size : 0x4
[ 12.848945] VQC : 0x0
[ 12.848945] GRPSEC : 0x7e
[ 12.848947] FALCONSEC : 0x0
[ 12.848949] **************************************
[ 12.848976] ------------[ cut here ]------------
[ 12.956345] WARNING: CPU: 0 PID: 0 at drivers/soc/tegra/cbb/tegra234-cbb.c:577 tegra234_cbb_isr+0x130/0x170
[ 12.966352] Modules linked in: ramoops(E) reed_solomon(E) loop(E) input_leds(E) aes_ce_blk(E) crypto_simd(E) snd_soc_tegra186_asrc(E) cryptd(E) snd_soc_tegra186_dspk(E) snd_soc_tegra210_ope(E) snd_soc_tegra210_mvc(E) snd_soc_tegra186_arad(E) snd_soc_tegra210_iqc(E) aes_ce_cipher(E) snd_soc_tegra210_afc(E) ghash_ce(E) snd_soc_tegra210_adx(E) snd_soc_tegra210_dmic(E) r8168(E) snd_soc_tegra210_amx(E) sha2_ce(E) snd_soc_tegra210_admaif(E) snd_soc_tegra210_i2s(E) snd_soc_tegra210_mixer(E) snd_soc_tegra210_adsp(E) snd_soc_tegra210_sfc(E) sha256_arm64(E) snd_soc_tegra_pcm(E) snd_soc_tegra_machine_driver(E) sha1_ce(E) snd_soc_tegra_utils(E) snd_hda_codec_hdmi(E) snd_soc_simple_card_utils(E) snd_soc_spdif_tx(E) snd_hda_tegra(E) nvadsp(E) snd_hda_codec(E) snd_soc_tegra210_ahub(E) tegra_bpmp_thermal(E) nvidia(OE) tegra210_adma(E) userspace_alert(E) nv_imx219(E) snd_hda_core(E) spi_tegra114(E) binfmt_misc(E) ina3221(E) pwm_fan(E) nvgpu(E) nvmap(E) ip_tables(E) x_tables(E)
[ 12.966458] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE 5.10.104-tegra #3
[ 12.966461] Hardware name: Unknown NVIDIA Orin Nano Developer Kit/NVIDIA Orin Nano Developer Kit, BIOS r35.3.1-9eede60 06/13/2023
[ 12.966465] pstate: 60400089 (nZCv daIf +PAN -UAO -TCO BTYPE=–)
[ 12.966468] pc : tegra234_cbb_isr+0x130/0x170
[ 12.966470] lr : tegra234_cbb_isr+0x10c/0x170
[ 12.966472] sp : ffff800010003e10
[ 12.966473] x29: ffff800010003e10 x28: ffffad6ea06e2440
[ 12.966476] x27: 0000000000000001 x26: 0000000000000080
[ 12.966479] x25: ffffad6ea010fc48 x24: ffffad6ea0a443c0
[ 12.966482] x23: ffffad6ea03f7000 x22: 0000000000000019
[ 12.966485] x21: ffffad6ea086a020 x20: 0000000000000002
[ 12.966487] x19: ffffad6ea086a010 x18: 0000000000000060
[ 12.966490] x17: 0000000000000000 x16: 0000000000000000
[ 12.966493] x15: ffffad6ea06e29a8 x14: ffffffffffffffff
[ 12.966496] x13: ffffad6ea09f23e8 x12: ffffad6ea09f201c
[ 12.966499] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f
[ 12.966501] x9 : ffff800010003c30 x8 : 2a2a2a2a2a2a2a2a
[ 12.966504] x7 : 2a2a2a2a2a2a2a2a x6 : 00000000248cef98
[ 12.966507] x5 : ffff0518283b9b18 x4 : 00000000fffff3a1
[ 12.966512] x3 : 0000000000000000 x2 : ffffad6e9ec17300
[ 12.966514] x1 : ffffad6ea06e2440 x0 : 0000000100010001
[ 12.966519] Call trace:
[ 12.966524] tegra234_cbb_isr+0x130/0x170
[ 12.966532] __handle_irq_event_percpu+0x68/0x2a0
[ 12.966534] handle_irq_event_percpu+0x40/0xa0
[ 12.966536] handle_irq_event+0x50/0xf0
[ 12.966539] handle_fasteoi_irq+0xc0/0x170
[ 12.966541] generic_handle_irq+0x40/0x60
[ 12.966543] __handle_domain_irq+0x70/0xd0
[ 12.966548] gic_handle_irq+0x68/0x134
[ 12.966550] el1_irq+0xd0/0x180
[ 12.966558] cpuidle_enter_state+0xb8/0x410
[ 12.966560] cpuidle_enter+0x40/0x60
[ 12.966565] call_cpuidle+0x44/0x80
[ 12.966567] do_idle+0x208/0x270
[ 12.966569] cpu_startup_entry+0x2c/0x70
[ 12.966576] rest_init+0xdc/0xe8
[ 12.966585] arch_call_rest_init+0x18/0x20
[ 12.966587] start_kernel+0x514/0x54c
[ 12.966589] —[ end trace afab66115a97abf9 ]—

It’s unrelated to the change of 4s improvement in UEFI.

It is OS complaining of memory allocation, and it doesn’t matter.

When I built the latest r35.3.1-updates branch, the latest commit on this branch is below:
commit 9eede609c24e5bbfafce2bc44a27b5cbc45a2987 (HEAD → r35.3.1-updates, origin/r35.3.1-updates)
Author: Ashish Singhal ashishsingha@nvidia.com
Date: Wed Jun 7 16:55:23 2023 -0600

feat: Setup MMU early in PrePi

Add MMU mapping earlier in PrePI.
The DTB parsing takes a while without it.

Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>

I flashed this uefi bootloader to my board, I can see the kernel oops error.

then I built r35.3.1-updates branch on this commit( not latest ):
commit 5ac7c42a66ac55634f3cdff1e3b07599f9cd03b1
Author: Girish Mahadevan gmahadevan@nvidia.com
Date: Sat May 27 14:28:49 2023 +0000

feat: add type19 table to jetson

Add type19 table generatoin to jetson targets.

Change-Id: I54907446f7af306a611c6307b97847cd0e61b863
Signed-off-by: Girish Mahadevan <gmahadevan@nvidia.com>

Then I flashed this uefi bootloader into my board, I can’t see kernel oops.

I did not change others, just the uefi bootloader bin file.

It might be caused from that you are using R35.3.1 with this change, and it should be no these errors with the next formal release(JP5.1.2).

@KevinFFF ,

Is there any new change to reduce more time in boot?

Sorry, there’s no other change to reduce the boot up time so far.
You may optimize the boot up time by removing some configs/modules in bootloader/kernel according to the custom usage.

So you have stopped the work to reduce UEFI boot time right now?

The following instruction is the official suggestion to optimize the boot time, and it’s directly relating to customer’s use case.
Boot Time Optimization — Jetson Linux Developer Guide documentation (nvidia.com)

@KevinFFF

The link you provide above is to reduce kernel boot time. But for now UEFI boot time is still too long.