On Wed, 2 Jul 2014 10:23:45 -0400 Charles Devereaux coreboot@guylhem.net wrote:
Hello
Hi,
If anyone is interested, I could successfully replicate a similar boot time on a debian wheezy, with a "modern" coreboot chain loading to grub2, on a x60 tablet running at 1.66 GHz with a cheap SSD :
Great.
I did a simlar setup some time ago for a narrower use case: I needed extremly fast reflashing times. I only had: * A stock parabola(A GNU/Linux distro based on Arch) * Good kernel commandline(to reduce logging) * A well configured grub. * No password at all, even for getty.
- I had to add a sleep 3 before starting the web browser with an
actual site to get the site to load (due to dhcp/wpa_supplicant/etc)
You could gain a lot of time by obtimising DHCP [1]. I've no idea about wpa_supplicant though.
You could also replace the sleep by something better: you could look if you can get the status of the network connection somehow: * Maybe trough dbus, but using dbus may slow down the startup. * Else simply launch the browser with the right arguments once the network is there. You'll have to find the right arguments for that, so it remains usable if the network comes and go.
I use linux-3.10.45 and systemd-stable v210, and you can see the result from a systemd-analyze - about 2.8 seconds after coreboot+grub, which take about 3 seconds. Add the delay for the web browser and you're good.
How many miliseconds would be saved by putting grub.cfg directly inside grub's coreboot.cfg?
References: ----------- [1]http://cafbit.com/entry/rapid_dhcp_or_how_do
Denis.
Hello
Sorry for this late reply, I have been a bit busy lately.
On Thu, Oct 2, 2014 at 12:24 AM, Denis 'GNUtoo' Carikli GNUtoo@no-log.org wrote:
I did a simlar setup some time ago for a narrower use case: I needed extremly fast reflashing times. I only had:
- A stock parabola(A GNU/Linux distro based on Arch)
- Good kernel commandline(to reduce logging)
- A well configured grub.
- No password at all, even for getty.
This is a good idea. At the moment, for simple tests I have a busybox doing just that. Too minimal though :-)
You could gain a lot of time by obtimising DHCP [1].
Indeed. Since then, I have had the best results at the moment with dhcpcd and the following options added to the bottom of debian dhcpcd.conf:
ipv6rs #ipv6ra_own #ipv4only noipv4ll noarp
The latest 2 options are the most helpful for speed. The rest is for my IPv6 setup.
At the moment, only dnsmasq is a bit of a hassle (used by resolvconf to do local caching + forward request to the DNS servers given by DHCP), but I must say I'm still using debian native script which does ExecStart=/etc/init.d/dnsmasq systemd-exec so there's obviously a lot of optimization to do.
I've no idea about wpa_supplicant though.
In my case, using priority in the network blocks and the following options is enough: update_config=1 eapol_version=2 fast_reauth=1 ## Hidden SSIDs #ap_scan=1
You could also replace the sleep by something better: you could look if
you can get the status of the network connection somehow:
IMHO, the best idea is to start the browser, then when the connection is established, issue a command to the browser to open the given page.
Actually, it could be interesting to provide a minimal "demo linux distro" that would do just what we said, to demonstrate how fast a coreboot boot can be. Something based on parabola or debian, using systemd, dhcpcd, and xorg without any password (where one has to provide the right xorg.conf)
It could provide a good reference, a metric.
How many miliseconds would be saved by putting grub.cfg directly inside
grub's coreboot.cfg?
I don't know. I should run tests :-) I remember reading that disk access was faster.
[1]http://cafbit.com/entry/rapid_dhcp_or_how_do
There was also an interesting BSD SoC project to implement this RFC 4436 in a free software modern dhcp client, but they found nobody this year: http://www.openbsdfoundation.org/gsoc2014.html#rfc4436
-
Charles Devereaux -
Denis 'GNUtoo' Carikli