We’re running 28.2, and have transitioned from the extlinux.conf boot method to a boot script (boot.scr). We’re now loading our .dtb file from rootfs, along with our kernel Image. We are doing this because we’ve implemented a safe fallback in the case of failed boot from an upgraded partition.
However, we have noticed a slowdown in general image processing at runtime when we’ve booted from the boot.scr vs the extlinux.conf (with .dtb in dedicated partition, as the TX1 is set up by default from the jetpack).
I’m unable to see what might be different, and what might cause the boot.scr system to run slower at runtime (it’s not keeping up with our image processing queue like it does with the extlinux.conf boot)… I imagined it might have something to do with where in memory the kernel Image and .dtb are loaded…, or not making use of IRAM?
The boot.scr contains logic, for selecting a rootfs partition, but boils down to basically this:
load mmc 0:1 $kernel_addr_r /boot/Image
load mmc 0:1 $fdt_addr_r /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
setenv bootargs $cbootargs root=/dev/mmcblk0p3 rw rootwait
booti $kernel_addr_r - $fdt_addr_r
The addresses are those that were pre-set up when we land in u-boot, and have not been modified.
Is there any reason why boot.scr-booted systems should run slower than extlinux.conf-booted systems?
Do you mean boot takes longer? You mention not keeping up with an image processing queue, but the script is from U-Boot, and so it sounds a bit confusing, as if you have an image processing queue running in U-Boot.
Perhaps you could print a timestamp before/after commands. I doubt I could help in U-Boot, but if you know which part of the script is taking longest, then you could narrow it down.
My guess is that the setenv must first read $cbootargs, and then write the environment, and that those two must be serialized, and so this takes longer. No way to know without timestamps.
Hi @linuxdev, nice to hear from you. No I actually mean that the system runs slower in normal runtime well after boot. We’re seeing reduced image processing times during our regular processing algorithms. It’s very confusing to us, as it has nothing to do with boot, beyond possibly loading images into incorrect/slower RAM, or not taking advantage of IRAM maybe?
I couldn’t say for sure, but you might see if your “cat /proc/cmdline” shows any difference other than perhaps the boot device. Knowing how “fast” verus “slow” compares in cmdline could offer a clue.
A serial console boot log would be useful as well, as it mentions some load addresses and clocks prior to Linux ever running. Just “dmesg” compared between the two would also be useful since timestamps are added. “dmesg” also lists some addresses, and it might be interesting to see if they are the same between “fast” and “slow”, e.g., the memory layout might be an interesting compare. It would look something like this:
[ 0.000000] Memory: 7190452K/8130560K available (15294K kernel code, 2934K rwdata, 6636K rodata, 8576K init, 609K bss, 186444K reserved, 753664K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffffff8000000000 - 0xffffff8008000000 ( 128 MB)
[ 0.000000] vmalloc : 0xffffff8008000000 - 0xffffffbebfff0000 ( 250 GB)
[ 0.000000] .text : 0xffffff8008080000 - 0xffffff8008f70000 ( 15296 KB)
[ 0.000000] .rodata : 0xffffff8008f70000 - 0xffffff80095f0000 ( 6656 KB)
[ 0.000000] .init : 0xffffff80095f0000 - 0xffffff8009e50000 ( 8576 KB)
[ 0.000000] .data : 0xffffff8009e50000 - 0xffffff800a12d808 ( 2935 KB)
[ 0.000000] .bss : 0xffffff800a12d808 - 0xffffff800a1c5f3c ( 610 KB)
[ 0.000000] fixed : 0xffffffbefe7fd000 - 0xffffffbefec00000 ( 4108 KB)
[ 0.000000] PCI I/O : 0xffffffbefee00000 - 0xff[ 0.000000] Memory: 7190452K/8130560K available (15294K kernel code, 2934K rwdata, 6636K rodata, 8576K init, 609K bss, 186444K reserved, 753664K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffffff8000000000 - 0xffffff8008000000 ( 128 MB)
[ 0.000000] vmalloc : 0xffffff8008000000 - 0xffffffbebfff0000 ( 250 GB)
[ 0.000000] .text : 0xffffff8008080000 - 0xffffff8008f70000 ( 15296 KB)
[ 0.000000] .rodata : 0xffffff8008f70000 - 0xffffff80095f0000 ( 6656 KB)
[ 0.000000] .init : 0xffffff80095f0000 - 0xffffff8009e50000 ( 8576 KB)
[ 0.000000] .data : 0xffffff8009e50000 - 0xffffff800a12d808 ( 2935 KB)
[ 0.000000] .bss : 0xffffff800a12d808 - 0xffffff800a1c5f3c ( 610 KB)
[ 0.000000] fixed : 0xffffffbefe7fd000 - 0xffffffbefec00000 ( 4108 KB)
[ 0.000000] PCI I/O : 0xffffffbefee00000 - 0xffffffbeffe00000 ( 16 MB)
[ 0.000000] vmemmap : 0xffffffbf00000000 - 0xffffffc000000000 ( 4 GB maximum)
[ 0.000000] 0xffffffbf00000000 - 0xffffffbf08000000 ( 128 MB actual)
[ 0.000000] memory : 0xffffffc000000000 - 0xffffffc200000000 ( 8192ffffbeffe00000 ( 16 MB)
[ 0.000000] vmemmap : 0xffffffbf00000000 - 0xffffffc000000000 ( 4 GB maximum)
[ 0.000000] 0xffffffbf00000000 - 0xffffffbf08000000 ( 128 MB actual)
[ 0.000000] memory : 0xffffffc000000000 - 0xffffffc200000000 ( 8192
Another question would be if the same exact filesystem is used, and if it is mounted with the same options. You could do a side-by-side comparison between “fast” and “slow” for the content of “/etc/mtab”. “mtab” is a psuedo file and not a real file. This file is a reflection of various mounted filesystems. Changes in how the filesystem is accessed could make a fairly large difference in the speed of eMMC access (not because of hardware, but because of software).