Re: [gentoo-embedded] coreboot + alix + startup times

[Peter Stuge]

Ed W wrote:
> >(Power-to-app in milliseconds, for example.)
>
> Can you please expand a little more on this with particular regard
> to the Alix2?

For ms to be possible, the app has to be simple enough that it does
not require a full operating system to be running. If that's the case
it can be linked against libpayload rather than glibc/other libc, and
the resulting binary is a payload that will be running quite quickly
after power on.

(This might not seem like too big a deal, but libpayload is maturing
and there are some apps available, although most are utilities
(coreinfo, the bayou menu) or demos. (the tint tetris game)
libpayload even has curses.)


> TinyBios already boots to the linux kernel in a couple of seconds,
> but I am personally having trouble getting the kernel to load in
> less than about 10-12 seconds (using a lightly tweaked 2.6 kernel).
> Shorter boot times would be quite desirable for my design...

Two concrete suggestions:

First, coreboot can load your kernel directly from boot flash if you
make a payload out of it. This means you're skipping the BIOS stage,
and the bootloader stage, which should save you 4-5 seconds.

The flash chip on all alix boards is 4Mbit == 512kbyte, so not large
enough for a kernel, but the LPC header allows you to use a larger
flash chip, and 16Mbit == 2Mbyte should be enough for an alix kernel.
(coreboot just needs 32kb or so.) The SST49LF160C should work and
comes in PLCC which fits the socket on the LPC.1A. (But LPC.1A stands
up from the alix board, so doesn't fit in the standard case. :\)

Second, tweak your kernel. This can save you another few seconds.

Third, init scripts. I understand OpenRC is snappy but I haven't
tried it. I'm using three super simple init scripts
(sysinit+boot+default) to cut the startup time.


> Also you have quite a lot of yellow in your support matrix.  Given
> I need all the features of the board for my design (pretty much),
> including the flashing lights and the optional buzzer, what
> problems am I going to run into with stuff not working?

There is a known bug with the LEDs. I do believe it's a relatively
easy fix, but noone has looked into it. AMD are good with data sheets
for the Geode so if you want to you can even get on fixing it
yourself right away. :)

As for optional buzzer, I don't believe anyone has tested that. It
may or may not work. I'm guessing it will not work, but on the other
hand I don't think it will be more difficult to fix than the LEDs.


> Am I likely to care that ACPI is unsupported?

For a serverish appliance I don't think so. ACPI is needed primarily
for suspend/resume things. Wake-on-LAN qualifies, but I think your
box wants to be always on.


> My design is basically a fancy router + mail server + couple of
> other embedded apps.

Cool.


> It's commercial so it would be useful to understand how to comply
> with the (GPL) licensing terms?

Yes, coreboot is GPL2. libpayload has a BSD license so that everyone
who wants to use it can link their apps against it.

coreboot is not combined with the payload by way of linking, so
the payload doesn't need to have a GPL-compatible license.

coreboot should not add any new licensing complications to your
product, as usual you just have to make sure that all your customers
who receive binaries built from GPL source also have a way to acquire
the source code for said binaries.

You could avoid the support issue completely by sending the source
along with the binaries in the first place. I usually burn a CD-R.

Other popular approaches are to put source online on a web site that
your customers (and ideally also everyone else, although AFAIK that
is not required at least by GPL2) can access, or to include an email
or postal address that processes source requests in the
documentation.


Hope this helps.

//Peter