Jump to content

Tips on speeding up boot process M1/Neo


Johhny Blue

Recommended Posts

Hi.

 

I am just wondering what the fastest time people have getting from plug in power to command prompt on something like the NanoPi M1 or Neo.

 

I use one of mine as an command line mp3 player (mpg123) and pretty much that;s all it does apart form some gpio buttons. It does not use network.

 

Are there any tips on speeding up boot so playback can commence faster?

 

I have never build a version of Armbian, but I am willing to give it a try - would a custom version be much faster?

 

Any thoughts would be greatly appreciated.

 

Are there any other images floating around that could demo a faster speed?

 

J.

Link to comment
Share on other sites

custom version + other images = not compatible

debian (armbian) + speeding up boot = not compatible

appliance (mp3 player) + debian = not compatible

custom + give a try = not compatible

 

A linux kernel needs about 2 seconds to init. I had stripped down a raspbian with a cam to make an appliance able to start in about that time. For that, you will find that you need to remove udev (and of course the init sytem (sysV, upstart, initng or systemd), which means that your system is no more compatible with any distro.

Link to comment
Share on other sites

The NEO is meant as an IoT node, we optimized settings for guaranteed low power (not exceeding certain tresholds) which affects boot times. How much I can't tell since I'm not interested in this kind of optimizations. But u-boot settings and cpufreq governor ensure that NEO remains below 2W consumption while booting and this will lead to lenghty boot times. Might be different with M1.

 

The setting in u-boot config is: CONFIG_SYS_CLK_FREQ=480000000 (boot with just 480 MHz)

 

Edit: LOL, the setting is gone with latest u-boot patches, don't know why (all the consumption optimization useless)

Link to comment
Share on other sites

custom version + other images = not compatible

debian (armbian) + speeding up boot = not compatible

appliance (mp3 player) + debian = not compatible

custom + give a try = not compatible

 

A linux kernel needs about 2 seconds to init. I had stripped down a raspbian with a cam to make an appliance able to start in about that time. For that, you will find that you need to remove udev (and of course the init sytem (sysV, upstart, initng or systemd), which means that your system is no more compatible with any distro.

 

That's just way too overgeneralized.

 

Of course it is possible to speed up boot time, use a custom kernel and custom u-boot, while staying compatible to the "distro", which is merely the whole userspace stuff.

 

Customizing a u-boot build, with ethernet and USB disabled will save the init tme for that. Removing the wait-time for user input gives another few seconds to save.

 

Just because a system has some init system installed by default doesn't mean one has to use it. One can always tell the kernel what to use as init (PID 1). That can be the required app, or a shell, or some rudimentary script to start some networking, damons and then an app.

 

One just has to be mindfull of what stuff needs to be started/required.

 

Simply saying that nothing is compatible is rather silly and counterproductive.

 

Greeting,

 

Chris

Link to comment
Share on other sites

To sum it up (I use NEO as example since there it's more obvious)

  1. NEO is supposed to start with just 480 MHz clockspeed (that setting got lost before 5.20 update but will be re-applied later). Reason: Limit max consumption while booting to 2W. Since default cpufreq governor in sun8i kernel is userspace this means that NEO will run with only 480 MHz until the init system starts cpufrequtils.
  2. Armbian's default u-boot settings are meant for users that have to solve problems from time to time, so we activate some stuff there to interact with u-boot and also have a short delay to stop auto-boot
  3. Armbian normally starts a whole init system that mike some time to finish until the distro's own mechanism to autostart things kicks in (be it a startup item or a call from /etc/rc.local)

To address 1) it's just setting a higher clockspeed. ATM I'm just too lazy to look whether it's ok to set 'CONFIG_SYS_CLK_FREQ=1200000000' there since this would also require u-boot to switch to the higher VDD_CPUX voltage on NanoPis (if the voltage remains at 1.1V then freezes/crashes might occur while booting -- we had that back with OPi One in February when I f*cked up settings for some time). In case no voltage switching happens in u-boot relying on the default 1008 MHz as we do now on all other H3 devices might already be wrong (@Zador?)

 

For 2) it's just disabling stuff in u-boot so that no time is wasted there waiting Ethernet, USB and keystrokes.

 

Examples for avoiding the usual init system are (N°3 above) are USBootPi or lima-memtester (see there the 'Compiling everything from sources' -- this is buildroot there and not Armbian at all).

 

Anyway: you need at least a serial console and a lot of knowledge (also how to avoid destroying your tweaks by the next regular Armbian updates).

 

So in case you find boot times annoying especially with NEO then the more simple variant would be to 

  • use the Armbian image for M1
  • replace /boot/script.bin with /boot/bin/nanopineo.bin (not just adjust the link but really overwrite it, doing it this way will ensure that next Armbian updates leave script.bin alone)
  • Adjust /etc/hostname

Booting with 480 MHz vs. 1008 MHz will already make a huge difference.

Link to comment
Share on other sites

To sum it up (I use NEO as example since there it's more obvious)

  1. NEO is supposed to start with just 480 MHz clockspeed (that setting got lost before 5.20 update but will be re-applied later). Reason: Limit max consumption while booting to 2W. Since default cpufreq governor in sun8i kernel is userspace this means that NEO will run with only 480 MHz until the init system starts cpufrequtils.
  2. Armbian's default u-boot settings are meant for users that have to solve problems from time to time, so we activate some stuff there to interact with u-boot and also have a short delay to stop auto-boot
  3. Armbian normally starts a whole init system that mike some time to finish until the distro's own mechanism to autostart things kicks in (be it a startup item or a call from /etc/rc.local)

To address 1) it's just setting a higher clockspeed. ATM I'm just too lazy to look whether it's ok to set 'CONFIG_SYS_CLK_FREQ=1200000000' there since this would also require u-boot to switch to the higher VDD_CPUX voltage on NanoPis (if the voltage remains at 1.1V then freezes/crashes might occur while booting -- we had that back with OPi One in February when I f*cked up settings for some time). In case no voltage switching happens in u-boot relying on the default 1008 MHz as we do now on all other H3 devices might already be wrong (@Zador?)

 

Hi,

Do you mean that the voltage is 1.1v (default) in the u-boot stage, and the 1.3v can only be obtained after booting using the software?

Thanks.

Link to comment
Share on other sites

Hi,

Do you mean that the voltage is 1.1v (default) in the u-boot stage, and the 1.3v can only be obtained after booting using the software?

Thanks.

 

Using CONFIG_SYS_CLK_FREQ=1200000000 in https://github.com/igorpecovnik/lib/blob/master/patch/u-boot/u-boot-sunxi/add-nanopi-neo.patch and the userspace governor in kernel, my NEO can boot.

Does uboot switch to 1.3v ? or the default voltage is 1.3v ? or 1200Mhz can boot with 1.1v which is the default ?

# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor 
userspace
# cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state 
120000 0
240000 0
312000 0
480000 0
624000 0
816000 0
1008000 0
1200000 161322
Link to comment
Share on other sites

Does uboot switch to 1.3v ?

 

Nope, that would only be possible on boards that use SY8106A voltage regulator. So it's pure luck that your boot suceeds.

 

We had this already in the beginning when starting to support OPi One. I made a mistake back then leaving VDD_CPUX always on 1.1V and while most people didn't complain some ran in serious stability problems. VDD_CPUX might also relate to input voltage (DC-IN) on the small H3 boards so that adds to variation.

 

Anyway: Don't exceed 1008 MHz in u-boot on these boards (and please don't encourage others to do so)

Link to comment
Share on other sites

Anyway: Don't exceed 1008 MHz in u-boot on these boards (and please don't encourage others to do so)

Thanks for your reply. That's just a test, not my final objectif.

I use  a NEO for audio streaming, so I want it use 480Mhz and 1.1v all the time, even without cpu-freq in kernel.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines