The attached patch is a unified version of the current ports of the i82801 series currently in LinuxBIOS. Since most of the ports are nearly identical, I've taken for each file and chosen the cleanest or best version of the code, then checked over the datasheets to *some* of the series, including the aa, ba, ca, and db, to make sure that it would work. I've also made some changes here and there, mostly cleanup and clarification. The only things left to look at are the huge difference between this version's lpc init and the i82801er's, finding a better way to select which chip is present on the board, and gpl headers in all files. Anyways, comments, suggestions, even flames are welcome ;) Testing on other chips can be done at this point as well, this is tested and working on one model, the i82801aa.
-Corey
Corey Osgood wrote:
Testing on other chips can be done at this point as well, this is tested and working on one model, the i82801aa.
Whoops, forgot to mention, usage is pretty straightforward. In your mainboard's Options.lb, add
uses I82801_MODEL uses I82801<yourmodel>
default I82810_MODEL = I82801<yourmodel>
then in the devices section below use "southbridge/intel/i82801xx" instead of your model's name. Thanks!
-Corey
Quoting Corey Osgood corey_osgood@verizon.net:
The attached patch is a unified version of the current ports of the i82801 series currently in LinuxBIOS. Since most of the ports are nearly identical, I've taken for each file and chosen the cleanest or best version of the code, then checked over the datasheets to *some* of the series, including the aa, ba, ca, and db, to make sure that it would work. I've also made some changes here and there, mostly cleanup and clarification. The only things left to look at are the huge difference between this version's lpc init and the i82801er's, finding a better way to select which chip is present on the board, and gpl headers in all files. Anyways, comments, suggestions, even flames are welcome ;) Testing on other chips can be done at this point as well, this is tested and working on one model, the i82801aa.
-Corey
Looks great Corey! How soon can this be Acked??
Thanks - Joe
On Sun, Jun 03, 2007 at 10:34:26AM -0400, joe@smittys.pointclark.net wrote:
Looks great Corey! How soon can this be Acked??
Pretty soon, I guess. I'm looking over it, but we need to be careful to not break any existing boards. Also, at the very minimum the proper license headers have to be added/merged.
A more in-depth review will follow...
Uwe.
Uwe Hermann wrote:
On Sun, Jun 03, 2007 at 10:34:26AM -0400, joe@smittys.pointclark.net wrote:
Looks great Corey! How soon can this be Acked??
Pretty soon, I guess. I'm looking over it, but we need to be careful to not break any existing boards.
No boards will be broken, I don't intend to remove the old devices nor swap over any boards. I'm leaving that for people that actually have them and can test it to do.
Also, at the very minimum the proper license headers have to be added/merged.
Yeah, working on that right now. Anyone know who svn user magnanisj is? I think this person worked for Linux Networx or SuSE in late 2005, but I could be wrong. If they can't be identified, I've got to rewrite a couple files.
A more in-depth review will follow...
Uwe.
Thanks, Corey
Corey Osgood wrote:
Yeah, working on that right now. Anyone know who svn user magnanisj is? I think this person worked for Linux Networx or SuSE in late 2005, but I could be wrong. If they can't be identified, I've got to rewrite a couple files.
Hmm, browsing trac a little more seems that magnanisj also checked in the xe7501devkit as a port of the agami aruma, and the i82801ca was done for that board (http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/ma...) The header in acpi_tables.c says the port was done by Digital Design Corporation, does that ring any bells for anyone? If not, I'll see if they can dig up anything, it's the best lead I've come up with so far.
-Corey
Quoting Corey Osgood corey.osgood@gmail.com:
Corey Osgood wrote:
Yeah, working on that right now. Anyone know who svn user magnanisj is? I think this person worked for Linux Networx or SuSE in late 2005, but I could be wrong. If they can't be identified, I've got to rewrite a couple files.
Hmm, browsing trac a little more seems that magnanisj also checked in the xe7501devkit as a port of the agami aruma, and the i82801ca was done for that board (http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/ma...) The header in acpi_tables.c says the port was done by Digital Design Corporation, does that ring any bells for anyone? If not, I'll see if they can dig up anything, it's the best lead I've come up with so far.
-Corey
I also says in the header "written by Stefan Reinauer stepan@openbios.org" Is this true Stefan??
Thanks - Joe
* Joseph Smith joe@smittys.pointclark.net [070604 11:57]:
The header in acpi_tables.c says the port was done by Digital Design Corporation, does that ring any bells for anyone? If not, I'll see if they can dig up anything, it's the best lead I've come up with so far.
-Corey
I also says in the header "written by Stefan Reinauer stepan@openbios.org" Is this true Stefan??
The acpi_tables.c was just adapted by Steven, I originally wrote it for the Agami Aruma (which is an AMD board). I was not directly involved in the intel xe7501 port though
Stefan
On 04.06.2007 07:01, Corey Osgood wrote:
Corey Osgood wrote:
Yeah, working on that right now. Anyone know who svn user magnanisj is? I think this person worked for Linux Networx or SuSE in late 2005, but I could be wrong. If they can't be identified, I've got to rewrite a couple files.
Hmm, browsing trac a little more seems that magnanisj also checked in the xe7501devkit as a port of the agami aruma, and the i82801ca was done for that board (http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/ma...) The header in acpi_tables.c says the port was done by Digital Design Corporation, does that ring any bells for anyone? If not, I'll see if they can dig up anything, it's the best lead I've come up with so far.
Just in case you are still trying to find out who svn user magnanisj is, here is the solution: Steven J. Magnani
Regards, Carl-Daniel
Corey Osgood wrote:
The attached patch is a unified version of the current ports of the i82801 series currently in LinuxBIOS. Since most of the ports are nearly identical, I've taken for each file and chosen the cleanest or best version of the code, then checked over the datasheets to *some* of the series, including the aa, ba, ca, and db, to make sure that it would work. I've also made some changes here and there, mostly cleanup and clarification. The only things left to look at are the huge difference between this version's lpc init and the i82801er's, finding a better way to select which chip is present on the board, and gpl headers in all files. Anyways, comments, suggestions, even flames are welcome ;) Testing on other chips can be done at this point as well, this is tested and working on one model, the i82801aa.
Some ideas that could simplify the code: [..] +#elif I82801_MODEL == I82801ER +#define I82801_PCI 0x244e +#define I82801_LPC 0x24d0 +#define I82801_IDE 0x24db +#define I82801_SATA 0x24df [..]
You can also add several PCI driver structures in a driver, pointing to the same PCI ops.
+static struct pci_driver pci_driver __pci_driver = { + .ops = &pci_ops, + .vendor = PCI_VENDOR_ID_INTEL, + .device = I82801_PCI, +};
So you could add one of these for each supported component. Since each pci_driver struct is only 8 bytes, the driver could be made to completely autodetect which southbridge chip you are using without the need for any #defines.
The only non-pci_driver use of the _MODEL #define is in src/southbridge/intel/i82801xx/i82801xx_smbus.h which is for smbus_write_block() which does not seem to be used, yet.
So my suggestion is to put an unconditional #warning there so that code can be fixed if it should not work on a given ICH and is ever used.
Forgot to say: Good work! Really nice!
Stefan
Stefan Reinauer wrote:
Corey Osgood wrote:
The attached patch is a unified version of the current ports of the i82801 series currently in LinuxBIOS. Since most of the ports are nearly identical, I've taken for each file and chosen the cleanest or best version of the code, then checked over the datasheets to *some* of the series, including the aa, ba, ca, and db, to make sure that it would work. I've also made some changes here and there, mostly cleanup and clarification. The only things left to look at are the huge difference between this version's lpc init and the i82801er's, finding a better way to select which chip is present on the board, and gpl headers in all files. Anyways, comments, suggestions, even flames are welcome ;) Testing on other chips can be done at this point as well, this is tested and working on one model, the i82801aa.
Some ideas that could simplify the code: [..] +#elif I82801_MODEL == I82801ER +#define I82801_PCI 0x244e +#define I82801_LPC 0x24d0 +#define I82801_IDE 0x24db +#define I82801_SATA 0x24df [..]
You can also add several PCI driver structures in a driver, pointing to the same PCI ops.
+static struct pci_driver pci_driver __pci_driver = {
- .ops = &pci_ops,
- .vendor = PCI_VENDOR_ID_INTEL,
- .device = I82801_PCI,
+};
So you could add one of these for each supported component. Since each pci_driver struct is only 8 bytes, the driver could be made to completely autodetect which southbridge chip you are using without the need for any #defines.
Cool! I didn't even think about that, I'll rework it.
The only non-pci_driver use of the _MODEL #define is in src/southbridge/intel/i82801xx/i82801xx_smbus.h which is for smbus_write_block() which does not seem to be used, yet.
enable_smbus uses it as well, but both could be handled by using a static device instead of probing. As long as the code is used with an ICH-series, the smbus is always at the same location.
So my suggestion is to put an unconditional #warning there so that code can be fixed if it should not work on a given ICH and is ever used.
Forgot to say: Good work! Really nice!
Thanks!
-Corey
-
Carl-Daniel Hailfinger -
Corey Osgood -
Corey Osgood -
joe＠smittys.pointclark.net -
Joseph Smith
-
Stefan Reinauer -
Stefan Reinauer -
Uwe Hermann