[Arm-netbook] Debian boots in 0.87 seconds

[joem]

Debian boots in 0.87 seconds:

http://linuxgizmos.com/headless-arm9-sbc-boots-linux-in-less-than-one-seconds/
http://www.embeddedarm.com/products/board-detail.php?product=TS-7250-V2

Good if this could be force marched to happen EOMA / Allwinner CPU.

A complete world game changer and a lot of funds will get
released for dormant projects that need fast boot + linux.

Crowd funding world would go beserk :)

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.ph

[Luke Kenneth Casson Leighton]

... not quite. they say it boots to a busybox shell in 0.87 seconds,
and they can *supply* debian wheezy for it. they most likely boot
direct rather than use u-boot. or if they use u-boot it's also been
configured to minimal settings.

Post by joem
http://linuxgizmos.com/headless-arm9-sbc-boots-linux-in-less-than-one-seconds/
http://www.embeddedarm.com/products/board-detail.php?product=TS-7250-V2
Good if this could be force marched to happen EOMA / Allwinner CPU.
A complete world game changer and a lot of funds will get
released for dormant projects that need fast boot + linux.

it's doable - it's quite a committment in time and effort which i'd
prefer (personally) to see an advance financial committment matched to
it.

to get any OS (such as debian) to boot very very fast you need to
make some quite significant modifications. udev has to go (entirely)
in favour of a static set of /dev/* entries, for example. the kernel
has to be customised to minimise the number of extra pseudo ttys.
initrd has to go: everything must be in a static monstrously-large
kernel (which itself becomes problematic as that adversely affects
load time).

so it's a balancing act that has already moved outside of the
mainstream debian (or other OS) infrastructure and purpose, that then
needs maintaining.

all of which takes time, hence why i would (personally) like to see
some up-front payment before committing time to such an idea.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp.co

[joem]

Post by Luke Kenneth Casson Leighton
... not quite. they say it boots to a busybox shell in 0.87 seconds,

Good enough to run a program that puts up a background?

Post by Luke Kenneth Casson Leighton
and they can *supply* debian wheezy for it. they most likely boot
direct rather than use u-boot. or if they use u-boot it's also been
configured to minimal settings.

Post by joem
http://linuxgizmos.com/headless-arm9-sbc-boots-linux-in-less-than-one-seconds/
http://www.embeddedarm.com/products/board-detail.php?product=TS-7250-V2
Good if this could be force marched to happen EOMA / Allwinner CPU.
A complete world game changer and a lot of funds will get
released for dormant projects that need fast boot + linux.

it's doable - it's quite a committment in time and effort which i'd
prefer (personally) to see an advance financial committment matched to
it.
to get any OS (such as debian) to boot very very fast you need to
make some quite significant modifications. udev has to go (entirely)
in favour of a static set of /dev/* entries, for example. the kernel
has to be customised to minimise the number of extra pseudo ttys.
initrd has to go: everything must be in a static monstrously-large
kernel (which itself becomes problematic as that adversely affects
load time).
so it's a balancing act that has already moved outside of the
mainstream debian (or other OS) infrastructure and purpose, that then
needs maintaining.

What about an open sourced script that can do this feat?
Everybody throws in their know how.

Post by Luke Kenneth Casson Leighton
all of which takes time, hence why i would (personally) like to see
some up-front payment before committing time to such an idea.

Name a figure.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phcomp

[Luke Kenneth Casson Leighton]

Post by joem

Post by Luke Kenneth Casson Leighton
... not quite. they say it boots to a busybox shell in 0.87 seconds,

Good enough to run a program that puts up a background?

yeah indeed. if you only have one program to run then it's
fantastic to have it starting up in like one or two seconds. i
remember compiling up webkit for a very special ARM9 processor (with
access to1666mhz DDR3 RAM!!) and that was starting up in seconds: i
just never got round to optimising the OS [it was a research
project....]

Post by joem

Post by Luke Kenneth Casson Leighton
so it's a balancing act that has already moved outside of the
mainstream debian (or other OS) infrastructure and purpose, that then
needs maintaining.

What about an open sourced script that can do this feat?

there was an article a while back published by.. ahh who was it...
montavista or redhat... it was 6 or 7 years ago.... there is quite a
lot that needs to be done.

Post by joem

Post by Luke Kenneth Casson Leighton
all of which takes time, hence why i would (personally) like to see
some up-front payment before committing time to such an idea.

Name a figure.

me? GBP 400 a day, minimum 5 days to get something reasonably quick
(low-hanging fruit so to speak), going beyond the easiest stuff i'd be
happy to continue for up to 3-4 weeks to tackle some of the
harder/more-complex stuff.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-net

[joem]

Post by Luke Kenneth Casson Leighton

Post by joem

Post by Luke Kenneth Casson Leighton
... not quite. they say it boots to a busybox shell in 0.87 seconds,

Good enough to run a program that puts up a background?

yeah indeed. if you only have one program to run then it's
fantastic to have it starting up in like one or two seconds.

Perfect for hand held gadgets we build that are wanting an Android like
colour touch interface program written in Gambas3 to start up
and run in under 3 seconds.

Post by Luke Kenneth Casson Leighton

Post by joem

Post by Luke Kenneth Casson Leighton
so it's a balancing act that has already moved outside of the
mainstream debian (or other OS) infrastructure and purpose, that then
needs maintaining.

What about an open sourced script that can do this feat?

there was an article a while back published by.. ahh who was it...
montavista or redhat... it was 6 or 7 years ago.... there is quite a
lot that needs to be done.

Post by joem

Post by Luke Kenneth Casson Leighton
all of which takes time, hence why i would (personally) like to see
some up-front payment before committing time to such an idea.

Name a figure.

me? GBP 400 a day, minimum 5 days to get something reasonably quick
(low-hanging fruit so to speak), going beyond the easiest stuff i'd be
happy to continue for up to 3-4 weeks to tackle some of the
harder/more-complex stuff.

I'll band a 10k figure about to see if anyone bites.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-netboo

[Luke Kenneth Casson Leighton]

Post by joem

Post by Luke Kenneth Casson Leighton

Post by joem

Post by Luke Kenneth Casson Leighton
... not quite. they say it boots to a busybox shell in 0.87 seconds,

Good enough to run a program that puts up a background?

yeah indeed. if you only have one program to run then it's
fantastic to have it starting up in like one or two seconds.

Perfect for hand held gadgets we build that are wanting an Android like
colour touch interface program written in Gambas3 to start up
and run in under 3 seconds.

exactly. but as peter says, for the "simplistic" solutions: go
beyond the exact requirements and it gets... complicated.

Post by joem
I'll band a 10k figure about to see if anyone bites.

star. i will be able to do something half-way decent that will cope
with a lot more scenarios for that.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-***@files.phco

[peter green]

Post by joem
What about an open sourced script that can do this feat?
Everybody throws in their know how.

The problem is getting a fast boot time is really a matter of deciding
what you can live without or at least start asyncronously after your
main application has started, then ruthlessly optimising what is left
for your specific case.

So the result is a system that boots to a specific application very
quickly but may be horriblly broken if the application or hardware used
changes.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachment

[Luke Kenneth Casson Leighton]

Post by joem
What about an open sourced script that can do this feat?
Everybody throws in their know how.

The problem is getting a fast boot time is really a matter of deciding what
you can live without or at least start asyncronously after your main
application has started, then ruthlessly optimising what is left for your
specific case.
So the result is a system that boots to a specific application very quickly
but may be horriblly broken if the application or hardware used changes.

there's a parallel init system i worked with that i adapted in 2006
to boot a 1.5ghz single-core pentium 3 system to x-windows in around
20 seconds. shutdown was under *three* seconds. instead of replacing
udev i split the udevadm startup into two "settle" sections: one
critical (disks, network, first 10 pseudo-ttys) and
one-for-everything-else. x-windows and ssh were dependent on the
one-for-everything-else, and networking, disk mounting etc were
dependent on the critical one.

the only problem you've got with parallel init systems is that they
rely on the processor being "modern" i.e. to have decent
context-switching. an ARM9 is *NOT* a modern processor. every
context-switch THROWS AWAY the cache. a Cortex A7 / A9 we might have
better luck

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachment

[joem]

Post by peter green

Post by joem
What about an open sourced script that can do this feat?
Everybody throws in their know how.

The problem is getting a fast boot time is really a matter of deciding
what you can live without or at least start asyncronously after your
main application has started, then ruthlessly optimising what is left
for your specific case.
So the result is a system that boots to a specific application very
quickly but may be horriblly broken if the application or hardware used
changes.

Idea:
(As a fan of Gambas I am led to believe its 1.5x faster than python.)
So a gambas GUI program with lots of visual basic like scripts
can cobble a workable configurable GUI per board
and then you would just check a list of features that must work,
and it goes off and creates an almighty bash script to hack
a fresh install of Debian down to its minimal innards.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachment

[Wookey]

Post by Luke Kenneth Casson Leighton
to get any OS (such as debian) to boot very very fast you need to
make some quite significant modifications. udev has to go (entirely)
in favour of a static set of /dev/* entries, for example. the kernel
has to be customised to minimise the number of extra pseudo ttys.
initrd has to go: everything must be in a static monstrously-large
kernel (which itself becomes problematic as that adversely affects
load time).

Exatly. fast booting is a direct trade-off between generality and
speed. Nearly everything you do to make a standard image that will
boot on anything, also makes the boot slower. Nearly everything you do
to make it go faster involves removing options, removing detection
code and pre-configuring things. Thus whilst it is indeed
possible to make linux boot very fast indeed (see numerous Embedded
Linux Conference talks on the subject) it comes by making very
hardware/case-specific optimisations.

That is often worth the effort for specific cases, but always involves
divergence for a binary distro (less so for a source distro) that you
then need to maintain if you want to keep that feature working on new
releases.

All that said, I'm sure that study of Debian and options for having
standardised ways of improving boottime would be worthwhile. I bet
there are things we could do to at least make this easier and possibly
make things go faster _without_ undue loss of generality, especially
as there has been a pile of change recently in the boot process (don't
mention the war! :-)

Wookey

[Luke Kenneth Casson Leighton]

Post by Wookey
All that said, I'm sure that study of Debian and options for having
standardised ways of improving boottime would be worthwhile. I bet
there are things we could do to at least make this easier and possibly
make things go faster _without_ undue loss of generality, especially
as there has been a pile of change recently in the boot process (don't
mention the war! :-)

... whatever you do, don't mention ze war :)

yes. wookey, there is *definitely* something that can be done,
unfortunately i lost the work back in 2006 (and would have to recreate
it). basically udev right now creates hundreds of nodes and has to
"settle".

this "settling" *can* be sub-divided into at least two groups. you
can look in the udev event trigger location (somewhere in /sys) and
instead of "is empty subdirectory" use "grep sd* net* tty?" and other
tricks.

in this way it's possible to have (at the very least) mounting and
networking come up a good few seconds *before* everything else. you
*do not* need to delay networking or early mount just because 768
pseudo-ttys have to be created.

and it _does_ take a long time because of udev spawning bash/dash
scripts, which then spawn more bash scripts... back in 2004 i think i
saw a stack of bash scripts *THIRTY DEEP* on a old Pentium 90 system -
it was something like *2 MINUTES* for udev to stop f******g about.

whilst there have been many improvements in hardware
context-switching for x86 systems, other processor architectures *do
not* have such good context-switching (extreme case: ARM9 as you well
know) so on such systems the effects of the assumptions "everything
works fine on x86" are much more marked.

l.

_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachments to arm-net

[Stefan Monnier]

Post by Luke Kenneth Casson Leighton
it). basically udev right now creates hundreds of nodes and has to
"settle".

If you want it really fast, devtmpfs is probably the answer.


Stefan


_______________________________________________
arm-netbook mailing list arm-***@lists.phcomp.co.uk
http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook
Send large attachmen