Thanks Corey,
1. I agree that before reading through the code, it is better to first check if the BIOS guides are available. However I would still like the answer to my question if I wish to carry on with the investigation for now. 2. I am trying to work out an overview of the changes required for a start; a bird's eye view of what the changes could turn out to be. What is the best approach for this?
Please ignore any footer that comes along with this mail:).
Regards, Malcolm
________________________________ From: Corey Osgood [mailto:corey.osgood@gmail.com] Sent: Tuesday, August 09, 2011 4:56 AM To: Dsouza, Malcolm Cc: coreboot@coreboot.org Subject: Re: [coreboot] Modifying Coreboot to support a new processor
On Mon, Aug 8, 2011 at 8:33 AM, Dsouza, Malcolm <malcolm.dsouza@igatepatni.commailto:malcolm.dsouza@igatepatni.com> wrote: Hi Everyone,
I trust all are in the best of health. I am planning to use Coreboot as the BIOS for the new Intel 2nd Generation Processors. However Coreboot does not support this processor or its associated chipset. To better understand the efforts needed in the respective areas, I have hence begun comparing various features present in the datasheets of the Intel chipsets Coreboot presently supports with the chipset I plan to use. Based on these findings I am trying to come to the conclusion about the areas in the code that will require modifications. Is this the right approach? Or should I try differently? Please send me your suggestions.
Thanks and Regards!
Before you even bother looking into coreboot, contact your local Intel representative about getting the BIOS programming guides for the CPUs and chipsets you're interested in. They're covered by RS-NDA (Restriced Secret Non-Disclosure Agreement), and there's a pretty good chance they won't hand them out unless you've got a pretty darn good business case, especially given their involvement with EFI. Not to dissuade you from Coreboot, but I don't want to waste your time looking into it just to find out you can't get the info you need to make it work.
Also, footers proclaiming the email confidential on messages to mailing lists, especially publicly archived ones, are rather ridiculous ;)
-Corey
________________________________ Information contained and transmitted by this e-mail is confidential and proprietary to iGATE Patni and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailadmin@igatepatni.com. iGATE Patni does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE Patni. iGATE Patni is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE Patni has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE Patni please visit www.igatepatni.com.
* Dsouza, Malcolm malcolm.dsouza@igatepatni.com [110809 14:40]:
Thanks Corey,
- I agree that before reading through the code, it is better to first check if the BIOS guides are available. However I would still like the answer to my question if I wish to carry on with the investigation for now.
- I am trying to work out an overview of the changes required for a start; a bird’s eye view of what the changes could turn out to be. What is the best approach for this?
You will have to write "drivers" for all your components.
* Northbridge (integrated into CPU these days) * Southbridge * CPU * Super I/O / Embedded Controllers / Management Engine * ...
Starting a new chipset port for a chipset of that complexity is probably going to be 6 months to a year of work
You will also have to make sure that your NDAs don't keep you from releasing the code you are writing under the GPLv2.
Stefan
On Wed, Aug 10, 2011 at 6:51 PM, Stefan Reinauer < stefan.reinauer@coreboot.org> wrote:
- Dsouza, Malcolm malcolm.dsouza@igatepatni.com [110809 14:40]:
Thanks Corey,
- I agree that before reading through the code, it is better to first
check
if the BIOS guides are available. However I would still like the
answer to
my question if I wish to carry on with the investigation for now.
- I am trying to work out an overview of the changes required for a
start; a
bird’s eye view of what the changes could turn out to be. What is the
best
approach for this?
You will have to write "drivers" for all your components.
- Northbridge (integrated into CPU these days)
- Southbridge
- CPU
- Super I/O / Embedded Controllers / Management Engine
- ...
Starting a new chipset port for a chipset of that complexity is probably going to be 6 months to a year of work
I also seem to remember something about the iX CPUs having a different bus setup for the multiple northbridges, but I don't remember the specifics, and never looked into what changes might be needed to coreboot.
-Corey
On Tue, Aug 9, 2011 at 5:40 AM, Dsouza, Malcolm < malcolm.dsouza@igatepatni.com> wrote:
**
- I am trying to work out an overview of the changes required for a
start; a bird’s eye view of what the changes could turn out to be. What is the best approach for this?
As Stefan and Corey pointed out, the changes are non-trivial and the
knowledge to make those changes is difficult to get at.
If Coreboot is important for your project then I suggest considering an AMD platform. They actively support Coreboot for their latest processors and chipsets, so porting effort for your project is minimal.