This patch fixes the decoding of the IO address range 0x0820->0x0827 into the LPC device of the MCP55 southbridge, thus enabling flashrom access to the SPI interface of the IT8716 SIO chip. Changes : 1) - increase MAX_RESOURCES to 24 in device.h -> this was needed because some functions of a PNP device can have more than 12 resources (ex the GPIO function of IT8716f), in which case one could have an "array overflow" inside the device structure (yes gcc is stupid!..) and ultimately a disaster (fool pointer at device init time..) 2) - define resource masks for the GPIO function in src/superio/ite/it8716f/superio.c -> this is needed because otherwise the IO ranges which are set into the LPC bridge of the SB are very strange (f.ex.: 0x800->0x7ff and so on..). Problem: the PNP_IO0 resource is not defined for the GPIO function, thus we have to define a "fake" mask "{0,0}" to avoid mismatching by the init code 3) - enable the flash SPI interface into src/mainboard/gigabyte/m57sli/Config.lb (by enabling the corresponding resource into the GPIO function). I know that this is problematic because not all m57sli boards are SPI, but .. do anyone have a better idea how to handle this?..
Signed-off-by: Florentin Demetrescu echelon@free.fr
Patch file attached.
Thanks, Florentin
PS: By the way, with all due respect, Gentlemen, I think that keeping 2 (potentially incoherent) sets of resource definitions for PNP devices in 2 different places (<mobo>/Config.lb vs. <sio>/superio.c) is trully brain dammaging.. Juste my 2 (euro-)cents
On Thu, Jan 31, 2008 at 03:01:51AM +0100, Florentin Demetrescu wrote:
This patch fixes the decoding of the IO address range 0x0820->0x0827 into the LPC device of the MCP55 southbridge, thus enabling flashrom access to the SPI interface of the IT8716 SIO chip. Changes :
- increase MAX_RESOURCES to 24 in device.h -> this was needed because some
functions of a PNP device can have more than 12 resources (ex the GPIO function of IT8716f), in which case one could have an "array overflow" inside the device structure (yes gcc is stupid!..) and ultimately a disaster (fool pointer at device init time..) 2) - define resource masks for the GPIO function in src/superio/ite/it8716f/superio.c -> this is needed because otherwise the IO ranges which are set into the LPC bridge of the SB are very strange (f.ex.: 0x800->0x7ff and so on..). Problem: the PNP_IO0 resource is not defined for the GPIO function, thus we have to define a "fake" mask "{0,0}" to avoid mismatching by the init code 3) - enable the flash SPI interface into src/mainboard/gigabyte/m57sli/Config.lb (by enabling the corresponding resource into the GPIO function). I know that this is problematic because not all m57sli boards are SPI, but .. do anyone have a better idea how to handle this?..
Signed-off-by: Florentin Demetrescu echelon@free.fr
Patch file attached.
Great work! I can test this on Friday.
Thanks, Ward.
On Thu, Jan 31, 2008 at 03:01:51AM +0100, Florentin Demetrescu wrote:
This patch fixes the decoding of the IO address range 0x0820->0x0827 into the LPC device of the MCP55 southbridge, thus enabling flashrom access to the SPI interface of the IT8716 SIO chip. Changes :
- increase MAX_RESOURCES to 24 in device.h -> this was needed because some
functions of a PNP device can have more than 12 resources (ex the GPIO function of IT8716f), in which case one could have an "array overflow" inside the device structure (yes gcc is stupid!..) and ultimately a disaster (fool pointer at device init time..) 2) - define resource masks for the GPIO function in src/superio/ite/it8716f/superio.c -> this is needed because otherwise the IO ranges which are set into the LPC bridge of the SB are very strange (f.ex.: 0x800->0x7ff and so on..). Problem: the PNP_IO0 resource is not defined for the GPIO function, thus we have to define a "fake" mask "{0,0}" to avoid mismatching by the init code 3) - enable the flash SPI interface into src/mainboard/gigabyte/m57sli/Config.lb (by enabling the corresponding resource into the GPIO function). I know that this is problematic because not all m57sli boards are SPI, but .. do anyone have a better idea how to handle this?..
I have verified your patch on a v2 of this board (it works!) as well as on a v1 (plcc). It does not affect flashing on v1 nor have any averse side effects that I noticed, so I think this patch should go in.
Signed-off-by: Florentin Demetrescu echelon@free.fr
Acked-by: Ward Vandewege ward@gnu.org
If nobody objects I will commit this later tonight or tomorrow.
Thanks a lot! Ward.
On 01.02.2008 23:53, Ward Vandewege wrote:
On Thu, Jan 31, 2008 at 03:01:51AM +0100, Florentin Demetrescu wrote:
This patch fixes the decoding of the IO address range 0x0820->0x0827 into the LPC device of the MCP55 southbridge, thus enabling flashrom access to the SPI interface of the IT8716 SIO chip. Changes :
- increase MAX_RESOURCES to 24 in device.h -> this was needed because some
functions of a PNP device can have more than 12 resources (ex the GPIO function of IT8716f), in which case one could have an "array overflow" inside the device structure (yes gcc is stupid!..) and ultimately a disaster (fool pointer at device init time..) 2) - define resource masks for the GPIO function in src/superio/ite/it8716f/superio.c -> this is needed because otherwise the IO ranges which are set into the LPC bridge of the SB are very strange (f.ex.: 0x800->0x7ff and so on..). Problem: the PNP_IO0 resource is not defined for the GPIO function, thus we have to define a "fake" mask "{0,0}" to avoid mismatching by the init code 3) - enable the flash SPI interface into src/mainboard/gigabyte/m57sli/Config.lb (by enabling the corresponding resource into the GPIO function). I know that this is problematic because not all m57sli boards are SPI, but .. do anyone have a better idea how to handle this?..
I have verified your patch on a v2 of this board (it works!) as well as on a v1 (plcc). It does not affect flashing on v1 nor have any averse side effects that I noticed, so I think this patch should go in.
Signed-off-by: Florentin Demetrescu echelon@free.fr
Acked-by: Ward Vandewege ward@gnu.org
Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
If nobody objects I will commit this later tonight or tomorrow.
Please do.
Regards, Carl-Daniel
It rocks!.. Now after taking a little break (1-2 weeks), I will begin to tackle the problems of ACPI and/or the incorrect init of IRQs on lagacy PCI slots on this board.. (which one is most urgent?) This is my roadmap for the short-term.. For the long term, Id like to contribute to the porting of coreboot-v3 on this board.. (but firstly, I have to familiarize myself with the coreboot-v3 architecture..)
Florentin
Quoting Ward Vandewege ward@gnu.org:
On Thu, Jan 31, 2008 at 03:01:51AM +0100, Florentin Demetrescu wrote:
This patch fixes the decoding of the IO address range 0x0820->0x0827 into
the
LPC device of the MCP55 southbridge, thus enabling flashrom access to the
SPI
interface of the IT8716 SIO chip. Changes :
- increase MAX_RESOURCES to 24 in device.h -> this was needed because
some
functions of a PNP device can have more than 12 resources (ex the GPIO
function
of IT8716f), in which case one could have an "array overflow" inside the
device
structure (yes gcc is stupid!..) and ultimately a disaster (fool pointer at device init time..) 2) - define resource masks for the GPIO function in src/superio/ite/it8716f/superio.c -> this is needed because otherwise the
IO
ranges which are set into the LPC bridge of the SB are very strange (f.ex.: 0x800->0x7ff and so on..). Problem: the PNP_IO0 resource is not defined for
the
GPIO function, thus we have to define a "fake" mask "{0,0}" to avoid
mismatching
by the init code 3) - enable the flash SPI interface into src/mainboard/gigabyte/m57sli/Config.lb (by enabling the corresponding
resource
into the GPIO function). I know that this is problematic because not all
m57sli
boards are SPI, but .. do anyone have a better idea how to handle this?..
I have verified your patch on a v2 of this board (it works!) as well as on a v1 (plcc). It does not affect flashing on v1 nor have any averse side effects that I noticed, so I think this patch should go in.
Signed-off-by: Florentin Demetrescu echelon@free.fr
Acked-by: Ward Vandewege ward@gnu.org
If nobody objects I will commit this later tonight or tomorrow.
Thanks a lot! Ward.
-- Ward Vandewege ward@fsf.org Free Software Foundation - Senior System Administrator
On 02.02.2008 00:38, Florentin Demetrescu wrote:
Now after taking a little break (1-2 weeks), I will begin to tackle the problems of ACPI and/or the incorrect init of IRQs on lagacy PCI slots on this board.. (which one is most urgent?) This is my roadmap for the short-term..
I think there is some code in the tree which will generate ACPI tables almost automatically. IIRC Rudolf Marek was working on that.
For the long term, Id like to contribute to the porting of coreboot-v3 on this board.. (but firstly, I have to familiarize myself with the coreboot-v3 architecture..)
That would be great! Coreboot v3 is a lot easier to understand and its boot messages are mostly self-explaining. The qemu target should work just fine.
For anyone starting to work with v3, I have to ask you to write down any questions arising from unclear boot messages or badly commented/explained code. I hope the v3 codebase has none of these problems, but I have worked with that codebase for too long to be able to analyze it from an outsider's point of view.
Regards, Carl-Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I think there is some code in the tree which will generate ACPI tables almost automatically. IIRC Rudolf Marek was working on that.
Yep I got ACPI events working. (Pressing button will triger gnome logout screen) plus machine powers down when told so ;) I have even some very experimental suspend to RAM working. I have also ACPI IRQ routing working.
I started with this wiki page: http://www.coreboot.org/ACPI_in_coreboot
And someone contributed some tool for FADT table generation.
For example please look to ASUS A8V-E SE board directory. And of course ACPI specs ;) (http://www.acpi.info)
Although my time is very limited right now I think I can at least answer mails about the ACPI stuff if you need some help.
For the long term, Id like to contribute to the porting of coreboot-v3 on this board.. (but firstly, I have to familiarize myself with the coreboot-v3 architecture..)
That would be great! Coreboot v3 is a lot easier to understand and its boot messages are mostly self-explaining. The qemu target should work just fine.
Yep it would be cool. If you do the K8 stuff I will do the VIA chipset stuff porting.
Thanks, Rudolf
On 02.02.2008 00:58, Rudolf Marek wrote:
Although my time is very limited right now I think I can at least answer mails about the ACPI stuff if you need some help.
My time is very limited as well. I hope that this changes sometime in March.
For the long term, Id like to contribute to the porting of
coreboot-v3 on this
board.. (but firstly, I have to familiarize myself with the coreboot-v3 architecture..)
That would be great! Coreboot v3 is a lot easier to understand and its boot messages are mostly self-explaining. The qemu target should work just fine.
Yep it would be cool. If you do the K8 stuff I will do the VIA chipset stuff porting.
I'd say we first try to get the Alix.1C Geode LX working perfectly in v3 to better understand all issues in v3 hardware bringup. With luck, that will happen this weekend. Then I hope porting most Geode LX targets will be easy and give us a better feeling of what should be done in mainboard specific code vs. processor/chipset specific code. After that, porting K8 code would be the obvious next step, although I hope we can clean up the code a lot before moving it to v3.
My goal for the next 6 months is to obsolete all v2 Geode LX targets by supporting them in v3. That and the easier porting should move enough development resources to v3 for it to gain strong momentum and quite a bit of media coverage.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Florentin Demetrescu -
Rudolf Marek -
Ward Vandewege