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).
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.
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?
Any other opinions about firmware development on the Atom would be welcome ...
It seems like an American Arium ECM-XDP3 with SourcePoint would be well worth the price for a large porting effort such as this. (It will provide both assembly and C level JTAG debugging.) Is there a cheaper JTAG debugger that might be viable on Atom/Poulsbo?
The firmware will be stored on a SPI NOR flash via LPC and an embedded controller rather than FWH.
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.
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.
Sincerely,
Ken Fuchs
On 06.06.2008 00:37, Ken.Fuchs@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:
- 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.
- 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
-
Carl-Daniel Hailfinger -
Ken.Fuchs＠bench.com