Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Display u-boot slash early #267

Merged
merged 12 commits into from
Feb 15, 2022
Merged

Display u-boot slash early #267

merged 12 commits into from
Feb 15, 2022

Conversation

MaxKellermann
Copy link
Collaborator

@MaxKellermann MaxKellermann commented Feb 10, 2022 •
edited
Loading

Lots of u-boot optimizations, but the most important piece is "display OpenVario logo in preboot", which loads and displays the splash screen before scanning for USB devices and before the 2 second delay (waiting for "ov" to interrupt the boot process). This shows the splash screen less than a second after power-up.

@mihu-ov
Copy link
Member

mihu-ov commented Feb 10, 2022

Should we set bootdelay to -2 to boot without delay and not check for abort (see https://www.denx.de/wiki/view/DULG/UBootEnvVariables)? Or is there any need to check for abort other than for development?
IIRC if a device sends any data on the serial port during these 2 seconds this may stop the boot process.

@MaxKellermann
Copy link
Collaborator Author

I had the same idea, but wasn't sure why you have this 2 second delay. It is configured explicitly in u-boot, even with a custom key code, i.e. it's not left enabled by accident.
If I were to decide, I would disable this delay completely and instead let the Cubieboard2 on-board button interrupt the boot process. If you need to debug your OpenVario, I think it's okay to have to open the case to reach that button. Normal users will never debug on the u-boot command line (will anybody ever?), and normal users will enjoy 2 seconds faster booting.

Another 5 seconds of boot time is lost while scanning for USB devices. Such a long delay is very annoying, but this is necessary for USB stick recovery. I wish there was another way...

@linuxianer99
Copy link
Member

The 2 second delay and the special key code for interrupting the boot was intentionally.
But i agree fully with you, that nobody will debug at uboot, despite for the recovery boot (and this is a very rare case)

i agree with the proposal of Max:

  • Remove the boot delay completely
  • Use a button for interrupting the boot process

@mihu-ov
Copy link
Member

mihu-ov commented Feb 10, 2022

Re scanning of USB devices, slide 51 from https://elinux.org/images/9/99/Opdenacker-timing-boot-time-reduction-techniques-ELCE-2019.pdf identifies the same issue, "Waiting for 1.2 s for the USB camera to be enumerated. Any way around this USB asynchronousness issue?"
However, nothing is mentioned in (newer) https://bootlin.com/doc/training/boot-time/boot-time-slides.pdf

@MaxKellermann
Copy link
Collaborator Author

Another 5 seconds of boot time is lost while scanning for USB devices. Such a long delay is very annoying, but this is necessary for USB stick recovery. I wish there was another way...

btw. I was able to eliminate most of this by disabling the OHCI controller, see commit 9b3974a in this PR

We're down to 14 seconds from power on to ovmenu.

@MaxKellermann
Copy link
Collaborator Author 

# systemd-analyze      
Startup finished in 1.275s (kernel) + 5.785s (userspace) = 7.061s 
multi-user.target reached after 5.688s in userspace

@MaxKellermann
Copy link
Collaborator Author

Second measurement was 12 seconds.
My goal is less than 10 seconds from power on to XCSoar fully started and audio vario running.

@August2111
Copy link
Contributor

August2111 commented Feb 11, 2022 •
edited
Loading

For most users who have the OpenVario installed in their glider, the fastest possible boot time is a very important criterion, so everything Max is doing in this matter is to be supported!

@MaxKellermann
u-boot: support ${extra_bootargs}
f99d8ad 
Allows users to add more kernel parameters to config.uEnv.
@MaxKellermann
u-boot: un-inline "distro_bootcmd"
52d6f92
@MaxKellermann
u-boot: disable SATA/AHCI support
0bee16b 
No OpenVario boots from SATA hard disk.
@MaxKellermann
u-boot: disable EFI support
7d57215 
There's no EFI in any OpenVario.
@MaxKellermann
u-boot: disable USB gadget support
111014a 
The boot manager never needs to play USB gadget.
@MaxKellermann
u-boot: disable splash screen support
56d30ae 
We roll our own, dynamically, using an env variable.
@MaxKellermann
u-boot: redirect preboot to bootenv.ini
27ad7cd
@MaxKellermann
u-boot: display OpenVario logo in preboot
124d96d 
This shows the OpenVario logo within 1 seconds after powering on.
@MaxKellermann
u-boot: disable more unnecessary compile-time options
4b71935
@MaxKellermann
u-boot: disable the USB OHCI controller
c66420c 
This speeds up u-boot by 2 seconds.
@MaxKellermann
u-boot: disable the bootdelay
39afa55 
Nobody ever needs to access the u-boot command line.  Let's disable it
and save 2 seconds of boot time.
@MaxKellermann
u-boot: do not attempt to load uboot.env
86159e9 
We don't use the binary "uboot.env" file, and not attempting to load
it saves a few milliseconds.
@MaxKellermann MaxKellermann marked this pull request as ready for review February 14, 2022 07:39
linuxianer99
linuxianer99 approved these changes Feb 15, 2022
View reviewed changes
Copy link
Member

@linuxianer99 linuxianer99 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me !
Thanks Max for all this effort !!

kedder
kedder approved these changes Feb 15, 2022
View reviewed changes
Copy link
Member

@kedder kedder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@linuxianer99 linuxianer99 merged commit 0b3b21a into Openvario:master Feb 15, 2022
@MaxKellermann MaxKellermann deleted the early-splash branch February 15, 2022 14:00
@MaxKellermann
Copy link
Collaborator Author

Second measurement was 12 seconds. My goal is less than 10 seconds from power on to XCSoar fully started and audio vario running.

Latest measurement: 9.5 seconds from power on (cold boot) to OpenVarioMenu. More PRs to come.

@August2111
Copy link
Contributor

Max, this are really nice results! My guys in the club are already very excited about the result this year, after all some are still flying with the 2017 version because they don't really trust the innovations yet... But with XCSoar 7.23++ and the many improvements on OpenVario-Linux I think I can convince them of an update ;-)

@mihu-ov
Copy link
Member

mihu-ov commented Feb 15, 2022

Below 10s is almost like "power on" instead of "booting", And if I understand correctly all of this without detrimental (rather the opposite) impact on future maintainability. That´s great!

@MaxKellermann
Copy link
Collaborator Author

Below 10s is almost like "power on" instead of "booting"

Right, and next step: get rid of psplash and its progress bar. What's the point of a progress bar if it boots almost instantly? Loading this second splash screen only delays the boot process.

And if I understand correctly all of this without detrimental (rather the opposite) impact on future maintainability. That´s great!

Yes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@linuxianer99 linuxianer99 linuxianer99 approved these changes

@kedder kedder kedder approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@MaxKellermann @mihu-ov @linuxianer99 @August2111 @kedder