On 06.06.2008 00:37, [EMAIL PROTECTED] 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 -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
