[coreboot] [RFC] Porting coreboot to Intel Atom (Silverthorne) & SCH US15W (Poulsbo) chipset

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Fri Jun 6 03:49:11 CEST 2008


On 06.06.2008 00:37, Ken.Fuchs at bench.com wrote:
> Thanks to everyone suggesting AMD processor
> alternatives (Geode LX) a while back.  However,
> we have decided to stay with Intel Atom (due to
> its much faster clock speed as well low power
> requirements).
>   

Sure.

> Which version of coreboot (v2 or v3) would be
> better to port to Intel Atom?  We want a fast
> boot up to both Linux and at least one Microsoft
> OS (maybe CE).  Based on Carl-Daniel Hailfinger's
> recent post regarding "Open Firmware", v3 would
> probably be much faster than v2.
>   

IIRC you are trying to use coreboot for commercial purposes, so the
needed development time is probably more important than 200 milliseconds
more or less during boot. Luckily, v3 offers vastly easier development,
probably reducing time-to-market significantly, while facilitating
debugging and improving boot speed at the same time.
Unless there's lots of code in v2 which you can leverage for Atom
porting, may I strongly suggest you try v3?

> I helped do an (Opteron) nVidia nForce4 LinuxBIOS
> port a few years ago, but I don't think it will be
> much help in porting coreboot to the Intel Atom.
> Which coreboot chipset might be the best starting
> point for a port to Intel Atom?
>   

IMO the most important thing would be getting CAR up and running. AFAICS
neither v2 nor v3 have CAR code which has been tested with Atom. Stefan
Reinauer has been working on recent Intel chipsets, so he would know
best, though I'm not sure how related Atom and other processors are. The
SCH US15W looks similar to the ICH6, but I could be totally wrong here.

> Any other opinions about firmware development
> on the Atom would be welcome ...
>   

> The firmware will be stored on a SPI NOR flash
> via LPC and an embedded controller rather than
> FWH.
>   

The embedded controller will be a challenge on its own unless you can
leverage existing (commercial?) code for it.

> I have two major concerns about this port:
>
> 1) I may not have enough time/resources to complete
>    it.  So I may end up optimizing a commercial UEFI
>    solution.
>   

IIRC UEFI can be stacked on top of coreboot, but I'm not sure about the
current state of that project. It should be possible to leave the
lowlevel hardware init to coreboot and pass control to an UEFI
implementation afterwards.

> 2) I'm not sure I will be able to contribute my
>    source code changes back to the coreboot project
>    due to NDA restrictions/ambiguities.
>   

I'm afraid that's pretty much a showstopper. Please try to work out the
details of these restrictions. There are some NDAs which don't have a
problem with publishing code after review, some others are OK with
publishing code as long as it doesn't have any comments mentioning the
docs, ...
Writing code for which the legal status is unclear is usually a lost
effort, especially if you're under time pressure. Having partial code is
better for the project than no code, so if you decide to tackle this,
please check what could be done from public docs and submit these parts
in any case.

Regards,
Carl-Daniel




More information about the coreboot mailing list