For a embedded product, the startup time of Tx1 ( custom board with Tx1 soc module) about 40 seconds is too long.
Is there a way to disable u-boot on Tx1 ?(I know it can be disabled on Tx2) .
Or ,is there anyone having optimized the boot time ?
Could you share it on the forum.
u-boot cannot be removed for TX1.
I have tried this on rel-28.1, not sure if it can be used on rel-24.2.1. Please give it a try in u-boot interactive mode.
setenv bootdelay 0
Thanks for your reply. I have learned that u-boot can’t be removed on Tx1.
The way to set bootdelay to 0 just shorts 3 seconds of u-boot interactive which I already achieved by rebuilding the u-boot source and setting bootdelay variable to 0.
I also cut the three seconds of boot menu which is used to select kernel (primary kernel or …),and disable PCIe in u-boot.
But it still takes about 5 seconds to finish u-boot boot. For a embedded device, it is intolerable.
Consequently, what I really want is to decrease Tx1 boot time !
Does the boot time of Tx1 can be reduced to 3 seconds ,or even 10 seconds ?
One thing I would do is use serial console to go to U-Boot command line and look at all environment variables:
Part of boot is scripted, and macro expansion occurs. An example is the default device search order. An example would be that if you don’t need to use SD card for a rootfs, then make the variable for device search order contain only eMMC/mmcblk0p1. There are many places where macro expansion could be turned into a single value without the need to expand.
Some things to look at:
boot_extlinux runs several expansions before getting to extlinux.conf. Hard wire those substitutions so there is no script and no expansion.
boot_target by default has five devices. For eMMC you only need mmc0.
bootcmd is sort of the “main()” entry point. This runs (expands) distro_bootcmd. distro_bootcmd itself is a loop of targets…get rid of it and just set bootcmd as “run bootcmd_mmc0” directly.
Every test for the existence of a device which you know already exists is expensive…it requires opening and reading eMMC.
You can make changes and they will have an effect for only that one boot. If you like the changes, then you can saveenv.
Thanks ,linuxdev. I’ll try it and hope that can save boot time more.
After I set u-boot bootdelay to 0, I can’t interrupt in the serial terminal and get into boot env setting because it is no wait for us to interrupt it.
Is there a way to get into u-boot env setting ,just press any key quickly on the keyboard before interrupt?
Or just flash u-boot again?
Hi , linuxdev.
I just reflash a u-boot and set boot_target mmc0 and set bootcmd run bootcmd_mmc0 , but it almost did’t reduce the u-boot boot time.
Possibly if you hold down the space bar or another key during boot it might interrupt. Basically any key press during the period it waits for input halts. I’m thinking that on the host PC where the serial console is running the auto-repeat of a held down space bar might be able to do this if there is still a tiny amount of time where input is accepted. Test and see.
I save boot logs for reference for every embedded system I have on every software release, and here is an observation about TX1 boot logs.
The “Starting CPU & Halting co-processor” occurs after about 0.8 seconds. You cannot change this, there is a lot of low level stuff going on and it wouldn’t matter which boot loader you are using. Jetsons in particular have a lot going on for boot because they are SoCs, and not just a micro-controller. At this stage EMC training still has not occurred. You only get memory clocks set up after about 1.2 seconds. Device tree load then occurs, and this takes total boot time to about 1.3 seconds. Only now do you get to cboot, and cboot may have some things you can optimize, but I wouldn’t bet on it making a big difference. The first place where particular drivers start loading is in cboot at around 1.4 seconds.
There are places in cboot where driver loading or probing fails…sometimes because a feature doesn’t exist. I’m not sure if it is possible to trim down what cboot does, e.g., why try to init an EEPROM if there is no EEPROM? Some i2c query is done in case of i2c hardware…why query if you know there is no hardware? But I have no idea if it is possible to trim unused steps in cboot which were intended to make the SoC flexible. You would need to use a serial console and log the boot from the very start to see the times and devices I am speaking of.
The first place where U-Boot gets to a fully customizable environment looks to me to be around the first echo of “Cmdline:”, which is about 3.2 seconds into boot. It is the time between this and starting the kernel which might be cut down, but timers do not show up during this stage so I can’t give you actual times. I suspect this is 2 to 3 seconds, and the boot delays you mention needing to get to interactive console are part of that. The last time which I see during U-Boot prior to interactive console being possible is a bit over 3.3 seconds. It would be very difficult to get any kernel loaded prior to this regardless of which boot loader you use.
Your typical micro controller does not have all of the peripheral hardware this SoC has. This isn’t really embedded hardware, it is a full motherboard in a tiny package. I think all of the truly relevant boot time savings will be from the moment the Linux kernel loads by cutting down what goes on once Linux starts init.
To really get the product you want you are going to have to define what it is you want Linux doing and what must run. Do you need the GUI? Do you need networking? Do you need the text mode consoles? Do you need audio? Do you need USB? Do you need PCIe? Do you need some specific indicator to be up, e.g, some GPIO needs to work in a particular way?
Yes, I just hold down the space bar or another key from the boot beginning to the end, but it don’t interrupt the boot process(except for where primary kernel…).
I also browse the web and almost all of the people suggest flash a new u-boot or rebuild the u-boot source with some function changed.
And I learn the time cost of different part of u-boot, but it is a little difficult to reduce the time again now. I’m trying to make a little progress.
It does sound like you will have to flash at least the boot loader binary to get back to the U-Boot prompt. Since waiting for a key was disabled I don’t think there is any way around this if you want to experiment with the U-Boot environment.
Do you connect display output in your test case?
I’m Sorry for later answer.
Yes, we connect display output in our test case.
The time includes the display output.
Now, it takes about 20 seconds from cold power-on to display our camera-based app.
We have some patch to boot up display init, but it is for rel-28.1. Would you mind moving to rel-28.1? (I think you might…)
Does rel-28.1 just match to Tx2?
I also browser some documentations from rel-28.1 such as driver_package documentation when I can’t figure out the problem properly.
That’s because I read documentation from rel-28.1 ,and I learned that rel-28.1 told that Tx2 can boot without u-boot. I have tried flashed Tx1 with it , but failed. So I create this topic.
It’s not practical for us now to change platform, because most of part of the product have been finished.
To low the startup time is also the feedback of customers who can’t accept the long time startup.
What’s more. Can the patch to boot up display init be transplanted to tx1 , even a little.
If it is possible,I can takes time to make a little progress in boot time.
rel-28.1 is for both tx1 and tx2 and part of kernel is shared (also for my patch). In Jetpack, you need to select different platform.
I am a little confused about your suggestions.
I can’t flash Tx1 with driver package of rel-28.1.
The jetpack just change version of cuda opencv … or rootfs. That’s easy to change.
Does it not change tx1 to tx2?
Because in previous comment you said “Does rel-28.1 just match to Tx2?”, I doubt you might use wrong package to flash your TX1.
“rel-28.1” is a branch for both TX1 and TX2, but we have two packages, one for tx1 and another for tx2. You need to download the correct one.
Thanks, I will have a try to change the platform to rel-28.1.
Is your init procedure in the documentation?
I just download the flash package right now and browser some scripts.
I learn that there is not much change on int package, just the volume of emmc is double.
It also can’t disable u-boot like Tx2.
Now the volume of emmc in my Tx1 is 16G. Is it ok to flash our Tx1 just by changing the number of the .conf?
I also feel it may not have too much promotion for my current case.
You can specify what size you want eMMC’s root partition in JetPack application while running it. If using command line, then after proper setup, the flash.sh “-S” argument sets rootfs partition size. The maximum size is:
# For TX1:
sudo ./flash.sh -S 14580MiB jetson-tx1 mmcblk0p1
# For TX2:
sudo ./flash.sh -S 29318MiB jetson-tx2 mmcblk0p1