[gentoo-embedded] Embedded Not a Blog

[gentoo-embedded] Embedded Not a Blog

[Ned Ludd]

I like this list more than blogs and I'm in one of those sharing kinda
moods.

So every single day is a new adventure in the embedded world. I learn a
bit more and I share a bit more every day (mostly via IRC vs this list).
It's a fun an exciting time to be apart of Gentoo.

Anyway I geared up for winter and got 4 new embedded boards based mostly
around the sc324XX series (aka OpenMoko CPU) and a stk500(AVR). So
hopefully our handbooks board files will fill up a bit more..

We have a new dev in training on the embedded side named Angelo Arrifano
aka miknix that originated with the linwizard project who will be
joining our team to help out with PDA/CellPhone/GPE/OpenMoko alike
things. He started out as what Gentoo calls an 'AT' for amd64. But it
turns out he was one of the masterminds behind the porting of the
HTC-wizard to linux. So he is much more useful over here. It was during
the porting of the wizard that I noticed his skills and attention to
detail. Often finding and coming up with better fixes than me. So I
quite look fwd to him joining our team soon.

Crossdev is known to have a few problems building recently. Bails out on
headers on pretty much every arch. There are two workarounds for this
that I know of at the moment. One is to hack the ebuild and add
--disable-headers and the other is to simply let crossdev fail. Then
emerge -1O cross-$CHOST/gcc && crossdev -t $CHOST while making sure
nsl/iconv/locales are disabled. I'm sure spanky will fix that soon if he
has not already.

If you still have difficulty. There is http://tinderbox.dev.gentoo.org/
which provides binary pkgs for a lot of chosts and cross toolchains.

Is gentoo-embedded satisfying your basic/common needs? What more
can/should we do as a multi arch distro?

Random Good links:

http://www.sparkfun.com
http://www.soekris.com
http://www.elinux.org
http://www.lynxmotion.com
http://www.jameco.com
http://www.maxim-ic.com
http://www.digikey.com
http://www.arduino.cc
http://www.nslu2-linux.org
http://wiki.openembedded.net
http://embedded.gentoo.org
https://everything.else...



-- 
Ned Ludd <solar/gentoo.org>

[gentoo-embedded] Re: Embedded Not a Blog

[Ângelo Miguel Arrifano]

On Tue, 02 Sep 2008 21:57:37 -0700
Ned Ludd <solar@gentoo.org> wrote:

> We have a new dev in training on the embedded side named Angelo Arrifano
> aka miknix that originated with the linwizard project who will be
> joining our team to help out with PDA/CellPhone/GPE/OpenMoko alike
> things. He started out as what Gentoo calls an 'AT' for amd64. But it
> turns out he was one of the masterminds behind the porting of the
> HTC-wizard to linux. So he is much more useful over here. It was during
> the porting of the wizard that I noticed his skills and attention to
> detail. Often finding and coming up with better fixes than me. So I
> quite look fwd to him joining our team soon.
> 

The porting of linux to the HTC-wizard involved a lot of people. I
first joined the project when they already have the most difficult part
done - the Linux booting. Then was time to give focus to each
particular driver and building the userspace image. With the help of
the Vapier emerge cross-compile guide (at the time it was the only
guide available), I managed to get my first x-compiled gentoo root which
I used to build the linwizard userspace image. With crossdev, portage,
a good environment and lots of patience, cross-compiling has proved to
be reliable.
Later, solar entered into scene. He managed to build some more root
images and offered us a chroot on miranda where we could cook linwizard.
Now, with his help, we have a awesome x-compile environment on miranda
that builds stuff with relative minimal effort.

Gentoo is certainly the way to go..

Thanks all, specially Ned.
-- 
Angelo Arrifano AKA MiKNiX
Computation and Intelligent Systems
MsC Student at UBI, Portugal
http://miknix.homelinux.com
PGP Pubkey 0x3D92BB0B

Re: [gentoo-embedded] Embedded Not a Blog

[Peter Stuge]

Ned Ludd wrote:
> Random Good links:
> 
> http://www.soekris.com

http://pcengines.ch/alix.htm


//Peter

Re: [gentoo-embedded] Embedded Not a Blog

[Peter Stuge]

Peter Stuge wrote:
> http://pcengines.ch/alix.htm

Sorry, wanted to mention that they run very well with coreboot, an
open source replacement for the BIOS. You can do many really nice
things for embedded when you can control also the boot firmware.

(Power-to-app in milliseconds, for example.)


//Peter

Re: [gentoo-embedded] Embedded Not a Blog

[Matthijs Kooijman]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

Hi Peter,

> > http://pcengines.ch/alix.htm
> 
> Sorry, wanted to mention that they run very well with coreboot, an
> open source replacement for the BIOS. You can do many really nice
> things for embedded when you can control also the boot firmware.
It seems that these boards are shipped with TinyBIOS, which is also release
under an open license. Is coreboot so much faster/more open/better?

Also, I don't see any removable flash chip on the boards. Does this mean that
if^H^Hwhen you brick the board, it's over, or is there some backdoor?

Gr.

Matthijs

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-embedded] Embedded Not a Blog

[Marius Schäfer]

Am Donnerstag 04 September 2008 17:39:57 schrieb Matthijs Kooijman:

I have one Alix as my firewall / router / server, works very well!

> It seems that these boards are shipped with TinyBIOS, which is also release
> under an open license. Is coreboot so much faster/more open/better?
>
> Also, I don't see any removable flash chip on the boards. Does this mean
> that if^H^Hwhen you brick the board, it's over, or is there some backdoor?
>
From the documentation:
'- Header for LPC bus (use for flash recovery or I/O expansion)'

Marius

Re: [gentoo-embedded] Embedded Not a Blog

[Peter Stuge]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

Hi Matthijs,

Matthijs Kooijman wrote:
> > > http://pcengines.ch/alix.htm
> > 
> > coreboot
> 
> It seems that these boards are shipped with TinyBIOS, which is also
> release under an open license. Is coreboot so much faster/more
> open/better?

I certainly think so, but as a coreboot developer I will be biased. :)

TinyBIOS is a light and lean BIOS while coreboot has another focus.
coreboot doesn't want to be a BIOS, it only does very early hardware
initialization and then it hands over to another program (the payload
in coreboot terms) which can be a bootloader (FILO for kernels on
disk, EtherBoot/gPXE network etc) or a Linux kernel or even an
application using the C library libpayload. There is also an open
source BIOS payload called SeaBIOS. The payload goes with coreboot
into the flash chip.


> Also, I don't see any removable flash chip on the boards. Does this
> mean that if^H^Hwhen you brick the board, it's over, or is there
> some backdoor?

As was mentioned, the LPC bus is available on a pin header, and
PC Engines offer the LPC.1A product for those who want to experiment
with firmware: http://pcengines.ch/lpc1a.htm

It's not available in the order form, but just send them an email,
they are very friendly.

Of course you can also hook up a ROM emulator to the LPC bus. There
are a few different products available, more or less commercial. One
open source solution called the FLASH-PLAICE just uses the Xilinx
Spartan 3E FPGA eval board.

PC Engines also make pinouts and many schematics available online
which warms the hardware hacker hearts. :)


//Peter

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-embedded] Embedded Not a Blog

[Ed W]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

Peter Stuge wrote:
> Peter Stuge wrote:
>   
>> http://pcengines.ch/alix.htm
>>     
>
> Sorry, wanted to mention that they run very well with coreboot, an
> open source replacement for the BIOS. You can do many really nice
> things for embedded when you can control also the boot firmware.
>
> (Power-to-app in milliseconds, for example.)
>
>   

Can you please expand a little more on this with particular regard to 
the Alix2?

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...

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?  Am I likely to care that 
ACPI is unsupported?

My design is basically a fancy router + mail server + couple of other 
embedded apps.  It's commercial so it would be useful to understand how 
to comply with the (GPL) licensing terms?

Ed W




[-- Attachment #2: Type: text/html, Size: 1722 bytes --]

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

Re: [gentoo-embedded] Embedded Not a Blog

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Wednesday 03 September 2008, Ned Ludd wrote:
> Crossdev is known to have a few problems building recently. Bails out on
> headers on pretty much every arch. There are two workarounds for this
> that I know of at the moment. One is to hack the ebuild and add
> --disable-headers and the other is to simply let crossdev fail. Then
> emerge -1O cross-$CHOST/gcc && crossdev -t $CHOST while making sure
> nsl/iconv/locales are disabled.

not sure why people think they need to hack things.  the crossdev 
flag --without-headers works exactly the same.

i seem to have some free time atm to catch up on some things ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [gentoo-embedded] Embedded Not a Blog

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

On Sunday 26 October 2008, Mike Frysinger wrote:
> On Wednesday 03 September 2008, Ned Ludd wrote:
> > Crossdev is known to have a few problems building recently. Bails out on
> > headers on pretty much every arch. There are two workarounds for this
> > that I know of at the moment. One is to hack the ebuild and add
> > --disable-headers and the other is to simply let crossdev fail. Then
> > emerge -1O cross-$CHOST/gcc && crossdev -t $CHOST while making sure
> > nsl/iconv/locales are disabled.
>
> not sure why people think they need to hack things.  the crossdev
> flag --without-headers works exactly the same.
>
> i seem to have some free time atm to catch up on some things ...

all the low hanging fruit should be squashed now.  at least on my G5, i was 
able to install these targets with crossdev:
arm: glibc-2.8 / gcc-4.3.2
sh4: glibc-2.8 / gcc-4.3.2
i686: glibc-2.8 / gcc-4.3.2
powerpc64: glibc-2.8 / gcc-4.3.2
i686: uclibc-0.9.30 / gcc-4.3.2

peace out
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]