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
