initrd question

initrd question

[Gregory Nowak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all.

Is it possible to include the speech-dispatcher/speechd-up/espeak
binaries in an initrd, so that one has speech almost as early as with
a hardware synth? If this is doable, and will provide speech
significantly earlier in the boot process, (especially if I were to
build alsa into the kernel itself), then could someone familiar with
how to work with initrds please describe the steps I would need to
take in order to accomplish this on a debian system? Thanks in
advance.

Greg


- -- 
web site: http://www.romuald.net.eu.org
gpg public key: http://www.romuald.net.eu.org/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

- --
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGjeQX7s9z/XlyUyARAtZJAJsEs5IuKsVNNL1tODFuILRKiiljIwCg20ih
Cnptvy/Qt0IqIUggn6103Cw=
=q68h
-----END PGP SIGNATURE-----

Re: initrd question

[Doug Sutherland]

Greg,

This is an interesting question. Many embedded linux systems
use initrd as the permanent root file system loaded from flash.
What you are proposing should be possible, since relatively 
speaking you have gobs of memory to work with. Check 
out this big blue document on the topic

http://www.ibm.com/developerworks/linux/library/l-initrd.html

This useful too:
http://www.faqs.org/docs/evms/x3834.html

You'd need a large ramdisk to fit all that in there, but in 
theory at least it seems feasible. There is kernel parameter
initrd= where you can specify memory address and the 
ramdisk size, for example

initrd=0xa1500000,8M root=/dev/ram

  -- Doug




----- Original Message ----- 
From: "Gregory Nowak" <greg@romuald.net.eu.org>
To: <speakup@braille.uwo.ca>
Sent: Friday, July 06, 2007 1:41 AM
Subject: initrd question


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all.
> 
> Is it possible to include the speech-dispatcher/speechd-up/espeak
> binaries in an initrd, so that one has speech almost as early as with
> a hardware synth? If this is doable, and will provide speech
> significantly earlier in the boot process, (especially if I were to
> build alsa into the kernel itself), then could someone familiar with
> how to work with initrds please describe the steps I would need to
> take in order to accomplish this on a debian system? Thanks in
> advance.
> 
> Greg
> 
> 
> - -- 
> web site: http://www.romuald.net.eu.org
> gpg public key: http://www.romuald.net.eu.org/pubkey.asc
> skype: gregn1
> (authorization required, add me to your contacts list first)
> 
> - --
> Free domains: http://www.eu.org/ or mail dns-manager@EU.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> 
> iD8DBQFGjeQX7s9z/XlyUyARAtZJAJsEs5IuKsVNNL1tODFuILRKiiljIwCg20ih
> Cnptvy/Qt0IqIUggn6103Cw=
> =q68h
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup

Re: initrd question

[Gregory Nowak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the info Doug, I'll take a look at it. What concerns me the
most is whether speechd-up and speech-dispatcher are staticly built or
not. I already know that the espeak binary is staticly
linked I think, and being able to use play or aplay would eliminate the need for
libportaudio. My other concern is the amount of dependencies that the
speech-dispatcher debian package seems to have.

The other thing I wasn't sure about was what libraries I'd need to
copy over to have everything (I.E. speech-dispatcher and alsa)
working. My main goal after all would be to install a minimal
distribution (even just the debian base system would be too big), the
single purpose of which would be to boot, restore alsa parameters,
start speech-dispatcher/speechd-up, load up support for the
chipset/hard drive, and hand off control to the root fs, with software
speech already running, and speaking things such as e2fsck running,
and the rest of the boot process up until login and beyond of
course. I'm not even going to throw compiling all sound card modules
into the mix, the initial job of having this work would be hard enough
as it is with just knowing what sound card is going to be used.

I guess the other question to ask is would the initial amount of ram
required for something like this, be a good enough of a trade off to
have speech early enough in the boot process to hear the system on the
hd booting, but potentially not early enough to hear kernel panics?
Since the initrd ram does get released though, that may not be a big
deal with the amount of ram your typical pc has these days.

Some food for thought I guess. If I have time to work on this, and if
I manage to pull it off, I'll definitely post the steps for getting it
done. Of course, if someone else has the time, and wants to beat me to
it, feel free.

Greg



On Fri, Jul 06, 2007 at 10:31:48PM -0500, Doug Sutherland wrote:
> Greg,
> 
> This is an interesting question. Many embedded linux systems
> use initrd as the permanent root file system loaded from flash.
> What you are proposing should be possible, since relatively 
> speaking you have gobs of memory to work with. Check 
> out this big blue document on the topic
> 
> http://www.ibm.com/developerworks/linux/library/l-initrd.html
> 
> This useful too:
> http://www.faqs.org/docs/evms/x3834.html
> 
> You'd need a large ramdisk to fit all that in there, but in 
> theory at least it seems feasible. There is kernel parameter
> initrd= where you can specify memory address and the 
> ramdisk size, for example
> 
> initrd=0xa1500000,8M root=/dev/ram
> 
>   -- Doug
> 
> 
> 
> 

- -- 
web site: http://www.romuald.net.eu.org
gpg public key: http://www.romuald.net.eu.org/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

- --
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGjxzH7s9z/XlyUyARAoZmAJ9SlnZgRGd4me8PvDJryw6MxTiJxgCfdOfp
rCg1f2F2Nrf14uZE9kBmFhI=
=U9T2
-----END PGP SIGNATURE-----

Re: initrd question

[Doug Sutherland]

Greg,

> What concerns me the most is whether speechd-up 
> and speech-dispatcher are staticly built or  not.

You control this with compiler options -static and -shared.
You can determine this easily by checking the makefiles,
and change it if it's not the way you need it to be.

> My other concern is the amount of dependencies that the
> speech-dispatcher debian package seems to have.

I think you need to mess around with source if you want 
to achieve this goal. Build from source, examine the 
makefiles, and you'll know soon enough the dependencies.

> The other thing I wasn't sure about was what libraries I'd need to
> copy over to have everything (I.E. speech-dispatcher and alsa)
> working. 

This too becomes clear when building from source. I was
building alsa from source before it was included in kernel.
Now, the device drivers are in the kernel, but the libraries
are not, so alsa-driver is already done, you need the 
alsa-lib and alsa-conf. Alsa is a project, so there are many
things that may be available, the relevent question is what
is the minimal you need for your ramdisk. Don't think in 
terms of packages, build the core and check if what you
need works, add what's missing, there you'll find your 
dependencies. 

> My main goal after all would be to install a minimal
> distribution (even just the debian base system would be too big), the
> single purpose of which would be to boot, restore alsa parameters,
> start speech-dispatcher/speechd-up, load up support for the
> chipset/hard drive, and hand off control to the root fs, with software
> speech already running, and speaking things such as e2fsck running,
> and the rest of the boot process up until login and beyond of
> course.

Yeah, that's the best way to think of it. Rather than trying
to work on ramdisk first, work on the minimal distribution.
I would recommend make a partition to experiment with 
and build the minimal system there, once you have the 
various parts working it will be easy to determine how 
much space is required etc. Even if for some reason you
were not able to get it working as ramdisk you'd have a 
good rescue partition and could put that on all machines,
and also make a bootable iso file.

Handing off control to the real root fs is done with 
pivot root, which was designed for exactly this purpose.

> I'm not even going to throw compiling all sound card modules
> into the mix, the initial job of having this work would be hard enough
> as it is with just knowing what sound card is going to be used.

Well that's all kernel stuff, but it would be best to include
them all. What is a linux install disk? It's a ramdisk with 
generic kernel. That's the kind of kernel you want. It 
makes no sense to make it specific to your machine, 
you want a ramdisk that will boot on anything. That work
is already done, you can find a kernel set up that way, 
or use the config from one.
 
> I guess the other question to ask is would the initial amount of ram
> required for something like this, be a good enough of a trade off to
> have speech early enough in the boot process to hear the system on the
> hd booting but potentially not early enough to hear kernel panics?

The kernel cannot panic. Your alsa is a kernel driver. 
If it panics no sound. The annoying thing is that console 
output is available. Food for thought, if the goal is to be 
able to determine what went wrong, then a completely 
different approach would be to work on trapping that 
console output and putting it somewhere. Compared to
what you're proposing that is far less complex. Unix
was designed to be used from serial console. There 
must be a way to grab that output and log it somewhere
so you can find out what happened before you were 
able to hear it.

> Since the initrd ram does get released though, that may not be a big
> deal with the amount of ram your typical pc has these days.

Yeah, I have 1GB RAM and the entire linux system 
barely dents that.

If you really want to do this I would recommend looking
at the buildroot project. It builds root filesystems for 
booting linux from flash on embedded systems. It uses
uclibc instead of gcc since the latter is a huge beast. It
would be worth exploring exactly what and how this 
buildroot does what it does to better approach this 
problem. It might even be worthwhile actually using the
uclibc since you're talking ramdisk, you don't have 
anywhere near the constraints of embedded, in most 
cases there the entire root fs is within 4MB of flash.
How hard that might be depends on how much of 
glibc the speech dispatcher and such used. 

http://buildroot.uclibc.org/

Note the links on the page also to related sites. 
Busybox is one executable that provides trimmer 
versions of many of the linux tools. You'll find that
on most ramdisks, and there are trimmed c libs
(uclibc) and dhcp (udhcp) etc.

  -- Doug

Re: initrd question

[Gregory Nowak]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, Jul 07, 2007 at 02:07:55AM -0500, Doug Sutherland wrote:
> Well that's all kernel stuff, but it would be best to include
> them all. What is a linux install disk? It's a ramdisk with 
> generic kernel. That's the kind of kernel you want. It 
> makes no sense to make it specific to your machine, 
> you want a ramdisk that will boot on anything.

I only meant this for the initial stage to get things working. Once
that is done, it would be best of course to include support for all
sound cards, that would be trivial compared to the rest of the
process. I have played with creating ramdisks before, so I'm familiar
with the basics. I've also built alsa from source, but never looked at
it. If ./configure, make, make install worked, which they always did,
I just moved on, and never bothered looking at the results, because I
didn't need to, and because I wasn't interested.

Greg


- -- 
web site: http://www.romuald.net.eu.org
gpg public key: http://www.romuald.net.eu.org/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

- --
Free domains: http://www.eu.org/ or mail dns-manager@EU.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGjzNm7s9z/XlyUyARAur5AJ4tdkOlyFIEAnKuwJeFkJXdhfI1PACgwpoi
AGWKJMhoFzBGDTAKG9MFyAQ=
=mQ6i
-----END PGP SIGNATURE-----

Re: initrd question

[Doug Sutherland]

Greg,

Consider this: an embedded linux system loads a ramdisk
image built using buildroot, and its root fs is in ram and 
stays there. They have alsa up and running in seconds. 
Alsa is easy because it's in the kernel and can even be 
statically included in the kernel. The applications are more
difficult, but surely doable unless there is some weird 
limit to ramdisk size. Ram is way faster than disk, and 
flash on embedded is way slower than disk. Maybe 
some day we'll all be running huge ramdisks. If we had
enough memory, why not? It would be fast. As long as
my critical files, not the system but data, are on disk 
then who cares if the root fs is corrupted,  in fact, to 
reboot an embedded linux system you press a button, 
and voila, two seconds later you're whole root fs is 
brand new, just as it was because the buildroot makes 
a nice image that loads into ram on boot.  Another 
related interesting tool is uboot bootloader, another 
embedded tool but may be relevant here. With the
uboot, you can  use command line args to load a 
ramdisk. Now if only uboot could talk hehe.

  -- Doug

Re: initrd question

[Doug Sutherland]

I meant to say, buildroot uses uclibc instead of glibc.
Buildroot makes a ramdisk image identical to what 
you are trying to achieve but for different reasons ...

> If you really want to do this I would recommend looking
> at the buildroot project. It builds root filesystems for 
> booting linux from flash on embedded systems. It uses
> uclibc instead of gcc since the latter is a huge beast.