[coreboot] [LinuxBIOS] m57sli : debugging the flashrom problem when booting with LB

[Florentin Demetrescu]

By the way the LPC interface of the IT8716 version used by this mobo is not as
described into the DS. The LPC pads are as follows:
 - LCLK (PCICLK?) : 78
 - nLFRAME : 71
 - nLRST : 68
 - SERIRQ : 70
 - LAD[0] : 72
 - LAD[1] : 73
 - LAD[2] : 74
 - LAD[3] : 75
Lastly on can use the unpopulated TPM connector to solder a sniffer on the LPC
bus (where we see that at least sometimes the Trusted Computing can be usefull
at something.. ;-))

Quoting Florentin Demetrescu <echelon at free.fr>:

> Hi,
>
> I think we are close to fix the pb. of the flashrom under LB on the m57sli
> mobo
>
> There was indeed a problem with the IO address decoding into the PCI->LPC
> bridge..
>
> Facts:
> 1) after booting with LB : when reading @ the IO address 0x820 (where the SPI
> IF
> of the IT8715 SIO should be mapped), one gets 0xff (the value read is 0x0c
> after
> booting with the factory bios)
> 2) when probing the LPC bus with an oscilloscope, one can notice that a IO
> read
> @ 0x820 produces:
>  - under factory bios : a corect IO read cycle as expected with the address
> 0x820 and the SIO answers with the correct value;
>  - under LB : a WRITE IO cycle @ the address 0x0080! (yes is true!) This is
> what
> is seen on the bus (I tested many times..), even if the software operation
> really was a IO read;
> 3) the PCI register 0xa0 of the pci device 00:01.0 (the LPC bridge) holds the
> value:
>  - 0xc1100001 under factory bios;
>  - 0x30000001 under LB;
> 4) the IO range 0x0800->0x085f can be seen with the factory bios into the pci
> register 0xb4 of the same pci device; it don't appear with the actual version
> of
> LB
> 5) after booting with LB, and forcing the following registers of the lpc
> bridge
> with the following comands:
>  setpci -s 00:01.0 a0.l=c1100001
>  setpci -s 00:01.0 a4.l=0
>  setpci -s 00:01.0 a8.l=0
>  setpci -s 00:01.0 ac.l=0
>  setpci -s 00:01.0 b0.l=02f40295
>  setpci -s 00:01.0 b4.l=085f0800
> (force them at same values as in proprietary bios)
> the command "flashrom -m gigabyte:m57sli" do not hang anymore and correctly
> identifies the flash chip (I haven't tested yet a full flash programming)
>
> So a workaround is now possible as suggested in point (5).
>
> For a full coreboot patch, unfortunatelly I don't master the software
> architecture of coreboot enough to make a proposal.. Can someone help please?
>
> I would like to thank Yinghai for his advice (-> mcp55_lpc.c where I found
> the
> very interesting procedure "mcp55_lpc_enable_childrens_resources") which
> permited me to do this work..
>
> Florentin
>
> Quoting yhlu <yinghailu at gmail.com>:
>
> > On Jan 10, 2008 4:42 AM, Carl-Daniel Hailfinger
> > <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> > > On 10.01.2008 12:14, Florentin Demetrescu wrote:
> > > > Hi all,
> > > > For my part I continue to think that there is a problem with the IO
> > address
> > > > decoding into the PCI->LPC bridge in mcp55.. Yinghai, can you help
> > please?
> > > >
> > >
> > > Yinghai? Is there some mcp55 conf we need to change?
> >
> > that range is already decoded to LPC bridge ( enable_rom, or
> > cache_as_rom_auto, or mcp55_lpc.c)
> >
> > YH
> >
>
>
>
> --
> coreboot mailing list
> coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>