On Wed, 14 May 2008 00:14:22 +0200, svn@coreboot.org wrote:
Author: stepan Date: 2008-05-14 00:14:21 +0200 (Wed, 14 May 2008) New Revision: 3304
Added: trunk/util/inteltool/ trunk/util/inteltool/Makefile trunk/util/inteltool/inteltool.8 trunk/util/inteltool/inteltool.c Removed: trunk/util/inteltools/ Log: Add new revised inteltool that dumps all kinds of chipset information and drop old gpio_dump utility.
Signed-off-by: Stefan Reinauer stepan@coresystems.de Acked-by: Peter Stuge peter@stuge.se
Wow, slow down. I really like all the new stuff Stefan. But is it compatable with all the ICH's per datasheets? I see the ICH7 is the only tested one. The old gpio_dump was not exactly pretty but it did the job, and should have worked on all ICH's per datasheets. Are you sure we should have dropped it? If you like in the next day or two I can test it out on the ICH4, so it can be added?
Joseph Smith wrote:
Wow, slow down. I really like all the new stuff Stefan. But is it compatable with all the ICH's per datasheets? I see the ICH7 is the only tested one. The old gpio_dump was not exactly pretty but it did the job, and should have worked on all ICH's per datasheets. Are you sure we should have dropped it? If you like in the next day or two I can test it out on the ICH4, so it can be added
ICH4 will require very few lines of additional code. But basically the gpio dump function did not change much. Except now it also prints the register names. If those changed, older ICHs will need an additional register description, or they will print the wrong names. No big magic.
I think we should not implicitly go with "all PCI IDs below this number follow the old scheme" heuristics, but instead add those ICHs that we checked explicitly. The infrastructure for doing that is quite in place.
Also, there's a mechanism to disable dumping for example the MCHBAR on those chipsets that don't have one.
But please, do test this and add the few missing lines to make it work on your chipset.
Stefan
On Wed, 14 May 2008 03:51:49 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
Wow, slow down. I really like all the new stuff Stefan. But is it compatable with all the ICH's per datasheets? I see the ICH7 is the only tested one. The old gpio_dump was not exactly pretty but it did the job, and should have worked on all ICH's per datasheets. Are you sure we
should
have dropped it? If you like in the next day or two I can test it out on the ICH4, so it can be added
ICH4 will require very few lines of additional code. But basically the gpio dump function did not change much. Except now it also prints the register names. If those changed, older ICHs will need an additional register description, or they will print the wrong names. No big magic.
I think we should not implicitly go with "all PCI IDs below this number follow the old scheme" heuristics, but instead add those ICHs that we checked explicitly. The infrastructure for doing that is quite in place.
Also, there's a mechanism to disable dumping for example the MCHBAR on those chipsets that don't have one.
But please, do test this and add the few missing lines to make it work on your chipset.
The research that I have done for i82801xx(I'm sure Corey & Uwe can back me on this) is that most of the register settings for ICH -> ICH5 are the same and ICH6 -> ICH9 are a little bit different. inteltool may get a little more complicated now that you have the northbridge involved also. I am pretty sure the nothbridge registers very dramaticly from chip to chip. But, I will give it a shot, and at least get a few more chips added :-)
Joseph Smith wrote:
The research that I have done for i82801xx(I'm sure Corey & Uwe can back me on this) is that most of the register settings for ICH -> ICH5 are the same and ICH6 -> ICH9 are a little bit different. inteltool may get a little more complicated now that you have the northbridge involved also. I am pretty sure the nothbridge registers very dramaticly from chip to chip. But, I will give it a shot, and at least get a few more chips added :-)
From what I could see the older ICHs have PMBASE and GPIOs but no RCBA for example. This should be fairly easy to handle. It might be safe to add the PCI IDs from the i82801xx_lpc.c driver. For the in-firmware part this tends to look different for different steppings of the same chip, so we need to be careful there. The dumping utility is quite simple as it doesn't need to know about chipset revision errata.
As long as you don't add the northbridge to the dumping functions, it will bail out with a message like "this is not supported (yet) on your northbridge".
On Wed, 14 May 2008 04:06:55 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
The research that I have done for i82801xx(I'm sure Corey & Uwe can back
me
on this) is that most of the register settings for ICH -> ICH5 are the
same
and ICH6 -> ICH9 are a little bit different. inteltool may get a little more complicated now that you have the northbridge involved also. I am pretty sure the nothbridge registers very dramaticly from chip to chip. But, I will give it a shot, and at least get a few more chips added :-)
From what I could see the older ICHs have PMBASE and GPIOs but no RCBA for example. This should be fairly easy to handle. It might be safe to add the PCI IDs from the i82801xx_lpc.c driver. For the in-firmware part this tends to look different for different steppings of the same chip, so we need to be careful there. The dumping utility is quite simple as it doesn't need to know about chipset revision errata.
As long as you don't add the northbridge to the dumping functions, it will bail out with a message like "this is not supported (yet) on your northbridge".
i82801xx_lpc.c is a perfect example. In that one we decided to say if the PCI ID is lower than ICH5 than do this.... And if it is equal to or greater than ICH6 than do this.... This is what I did for gpio_dump. I think it is a great approach for seperating various differences for inteltool. What do you think?
Joseph Smith wrote:
On Wed, 14 May 2008 04:06:55 +0200, Stefan Reinauer stepan@coresystems.de wrote:
Joseph Smith wrote:
The research that I have done for i82801xx(I'm sure Corey & Uwe can back
me
on this) is that most of the register settings for ICH -> ICH5 are the
same
and ICH6 -> ICH9 are a little bit different. inteltool may get a little more complicated now that you have the northbridge involved also. I am pretty sure the nothbridge registers very dramaticly from chip to chip. But, I will give it a shot, and at least get a few more chips added :-)
From what I could see the older ICHs have PMBASE and GPIOs but no RCBA for example. This should be fairly easy to handle. It might be safe to add the PCI IDs from the i82801xx_lpc.c driver. For the in-firmware part this tends to look different for different steppings of the same chip, so we need to be careful there. The dumping utility is quite simple as it doesn't need to know about chipset revision errata.
As long as you don't add the northbridge to the dumping functions, it will bail out with a message like "this is not supported (yet) on your northbridge".
i82801xx_lpc.c is a perfect example. In that one we decided to say if the PCI ID is lower than ICH5 than do this.... And if it is equal to or greater than ICH6 than do this....
If you read the specs to the end, you will find out that for ICH6 and above, there are so many things different that the driver would become unreadable, if one tried to make it actually work. That is why the pci_driver scheme was invented to begin with. It safes us all those pci id compares in coreboot. Instead, there should be 2 functions, one associated with all PCI IDs up to ICH5, and one or more for the newer chips.
This is what I did for gpio_dump. I think it is a great approach for seperating various differences for inteltool. What do you think?
In inteltool, this is just a big case statement...
so let's do this instead:
case PCI_DEVICE_ID_ICH0: case PCI_DEVICE_ID_ICH1: case PCI_DEVICE_ID_ICH2: case PCI_DEVICE_ID_ICH3: case PCI_DEVICE_ID_ICH4: case PCI_DEVICE_ID_ICH5: ..... break; case PCI_DEVICE_ID_ICH6: case PCI_DEVICE_ID_ICH7: case PCI_DEVICE_ID_ICH8: ... break;
so we don't have to rely on heuristics in case the LPC device would get a different number in future chipsets.
-
Joseph Smith -
Stefan Reinauer