[PATCH 1/1] Mark Gigabyte GA-6ETXDR as UNSUPPORTED so far

[Peter Lemenkov]

Here is a short flashrom log:

dev ~ # ~petro/flashrom/flashrom
flashrom v0.9.2-r1025 on Linux 2.6.18-164.15.1.el5 (i686), built with libpci 2.2.3, GCC 4.1.2 20080704 (Red Hat 4.1.2-48), little endian
flashrom is free software, get the source code at http://www.flashrom.org

Calibrating delay loop... OK.
No coreboot table found.
This chipset supports the following protocols: Non-SPI.
WARNING: No chipset found. Flash detection will most likely fail.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
dev ~ #

Signed-off-by: Peter Lemenkov 
---
 print.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/print.c b/print.c
index bf75990..bfe2dcb 100644
--- a/print.c
+++ b/print.c
@@ -334,6 +334,7 @@ const struct board_info boards_known[] = {
    B("GIGABYTE",	"GA-2761GXDK",		1, "http://www.computerbase.de/news/hardware/mainboards/amd-systeme/2007/mai/gig...", NULL),
    B("GIGABYTE",	"GA-6BXC",		1, "http://www.gigabyte.com/products/product-page.aspx?pid=1445", NULL),
    B("GIGABYTE",	"GA-6BXDU",		1, "http://www.gigabyte.com/products/product-page.aspx?pid=1429", NULL),
+	B("GIGABYTE",	"GA-6ETXDR",		0, "http://www.gigabyte.com/products/product-page.aspx?pid=992", NULL),
    B("GIGABYTE",	"GA-6ZMA",		1, "http://www.gigabyte.com/products/product-page.aspx?pid=1541", NULL),
    B("GIGABYTE",	"GA-7VT600",		1, "http://www.gigabyte.com/products/product-page.aspx?pid=1666", NULL),
    B("GIGABYTE",	"GA-7ZM",		1, "http://www.gigabyte.com/products/product-page.aspx?pid=1366", "Works fine if you remove jumper JP9 on the board and disable the flash protection BIOS option."),

[Carl-Daniel Hailfinger]

On 02.06.2010 20:25, Peter Lemenkov wrote:
> flashrom v0.9.2-r1025 on Linux 2.6.18-164.15.1.el5 (i686), built with libpci 2.2.3, GCC 4.1.2 20080704 (Red Hat 4.1.2-48), little endian
> flashrom is free software, get the source code at http://www.flashrom.org
>
> Calibrating delay loop... OK.
> No coreboot table found.
> This chipset supports the following protocols: Non-SPI.
> WARNING: No chipset found. Flash detection will most likely fail.
> No EEPROM/flash device found.
> Note: flashrom can never write if the flash chip isn't found automatically.
> dev ~ #
>
> Signed-off-by: Peter Lemenkov

NACK.

The only way is to detect the chipset and get this working.

Please send the output of
lspci -nnvvvxxx
superiotool -deV

Regards,
Carl-Daniel

[Carl-Daniel Hailfinger]

Hi Peter,

could you please send
lspci -nnvvvxxx
superiotool -deV
flashrom -V
for the Gigabyte GA-6ETXDR board? Some information about the flash chip
present on the board would also help tremendously.
I'm quite confident that we can get this board/chip supported.

On 02.06.2010 20:25, Peter Lemenkov wrote:
> flashrom v0.9.2-r1025 on Linux 2.6.18-164.15.1.el5 (i686), built with libpci 2.2.3, GCC 4.1.2 20080704 (Red Hat 4.1.2-48), little endian
> flashrom is free software, get the source code at http://www.flashrom.org
> Calibrating delay loop... OK.
> No coreboot table found.
> This chipset supports the following protocols: Non-SPI.
> WARNING: No chipset found. Flash detection will most likely fail.
> No EEPROM/flash device found.

Regards,
Carl-Daniel

[PATCH 1/1] Mark Gigabyte GA-6ETXDR as UNSUPPORTED so far

[Peter Lemenkov]

Hello Carl-Daniel!
Sorry, I completely overlooked your previous mail.

2010/9/14 Carl-Daniel Hailfinger :
> Hi Peter,
>
> could you please send
> lspci -nnvvvxxx
> superiotool -deV
> flashrom -V
> for the Gigabyte GA-6ETXDR board? Some information about the flash chip
> present on the board would also help tremendously.
> I'm quite confident that we can get this board/chip supported.

Yes, sure - see attached files.

[Carl-Daniel Hailfinger]

Hi Peter,

On 14.09.2010 09:24, Peter Lemenkov wrote:
> Sorry, I completely overlooked your previous mail.

No problem.
> 2010/9/14 Carl-Daniel Hailfinger :
> > Hi Peter,
> >
> > could you please send
> > lspci -nnvvvxxx
> > superiotool -deV
> > flashrom -V
> > for the Gigabyte GA-6ETXDR board? Some information about the flash chip
> > present on the board would also help tremendously.
> > I'm quite confident that we can get this board/chip supported.
>
> Yes, sure - see attached files.
>
> [flashrom.txt]
> [lspci.txt]
> [spoofer.c]

Could you please attach "superiotool -deV" output as well? And would it
be possible for you to take a look inside the machine to check which
flash chip it is? Thanks!

Decoded PCI IDs follow:
1166:006 Broadcom/ServerWorks CNB20HE Host Bridge
1166:0009 Broadcom/ServerWorks CNB20LE Host Bridge
8086:1229 Intel 82557/8/9/0/1 Ethernet Pro 100
8086:1229 Intel 82557/8/9/0/1 Ethernet Pro 100
1002:4752 ATI Rage XL
1166:0200 Broadcom/ServerWorks OSB4 South Bridge
1166:0211 Broadcom/ServerWorks OSB4 IDE Controller
1166:0220 Broadcom/ServerWorks OSB4/CSB5 OHCI USB Controller
1000:0021 NCR/LSI/Symbios 53c1010 66MHz Ultra3 SCSI Adapter
1000:0021 NCR/LSI/Symbios 53c1010 66MHz Ultra3 SCSI Adapter

BIOS download:
http://download.gigabyte.eu/FileList/BIOS/networking_6etxdr.f4.exe
(unzip needed). This is an AMI BIOS.

This is a missing chipset enable and/or board enable and/or chip support.

Regards,
Carl-Daniel

[PATCH 1/1] Mark Gigabyte GA-6ETXDR as UNSUPPORTED so far

[Peter Lemenkov]

2010/9/14 Carl-Daniel Hailfinger :
> Could you please attach "superiotool -deV" output as well?

Heh, seems that I attached wrong file by mistake. See attached file.
> And would it
> be possible for you to take a look inside the machine to check which
> flash chip it is? Thanks!

Nope, I cant look inside.

[Carl-Daniel Hailfinger]

On 14.09.2010 12:27, Peter Lemenkov wrote:
> 2010/9/14 Carl-Daniel Hailfinger :
> > Could you please attach "superiotool -deV" output as well?
>
> Heh, seems that I attached wrong file by mistake. See attached file.

Thanks.
It seems superiotool output is completely useless (not your fault). The
Super I/O seems to be unsupported by superiotool. The manual says this
is a NS PC97317VUL Super I/O Chip. Datasheet is here:
http://www.alldatasheet.com/datasheet-pdf/pdf/9317/NSC/PC87317.html
(look for SID to find the identification data).

The block diagram in the board manual suggests that the flash chip is a
4 Mbit device directly attached to the ISA bus.
> > And would it
> > be possible for you to take a look inside the machine to check which
> > flash chip it is? Thanks!
>
> Nope, I cant look inside.

OK. The board has a "JP1 firmware write protect" jumper, so writing
would probably be impossible without opening the case.
It _is_ possible that this jumper also prevents probing, but I'm not so
sure about that.

Regards,
Carl-Daniel

[PATCH 1/1] Mark Gigabyte GA-6ETXDR as UNSUPPORTED so far

[Joshua Roys]

Hello,

Attached is a patch that might get your flash chip to appear- a
chipset enable was put into place, and some flash chips were added
that could have been used in your board.  It's possible but unlikely
that write would work, mostly due to the following:

On Tue, Sep 14, 2010 at 7:33 AM, Carl-Daniel Hailfinger
 wrote:
> OK. The board has a "JP1 firmware write protect" jumper, so writing
> would probably be impossible without opening the case.
> It _is_ possible that this jumper also prevents probing, but I'm not so
> sure about that.

Apply the patch on the latest SVN.  Depending on when you try to
apply, it might need some changes.  (The diff was generated on r1171.)

Please let us know how it goes!

Josh

[PATCH 1/1] Mark Gigabyte GA-6ETXDR as UNSUPPORTED so far

[Peter Lemenkov]

Hello Joshua.

2010/9/15 Joshua Roys :
> Hello,
>
> Attached is a patch that might get your flash chip to appear- a
> chipset enable was put into place, and some flash chips were added
> that could have been used in your board.

Great work - now I can see the flashchip. Also, please, sed -i
s,read_memapped,read_memmapped,g in your patch. See flashrom's log
attached.

Tested-by:  Peter Lemenkov

[PATCH 1/1] Mark Gigabyte GA-6ETXDR as UNSUPPORTED so far

[Peter Lemenkov]

2010/9/15 Peter Lemenkov :
> Great work - now I can see the flashchip. Also, please, sed -i
> s,read_memapped,read_memmapped,g in your patch. See flashrom's log
> attached.

This was only probing and here is a log of successful read attempt (attached).
> Tested-by:  Peter Lemenkov

Likewise.

[Carl-Daniel Hailfinger]

On 15.09.2010 11:10, Joshua Roys wrote:
> Attached is a patch that might get your flash chip to appear- a
> chipset enable was put into place, and some flash chips were added
> that could have been used in your board.  It's possible but unlikely
> that write would work, mostly due to the following:
>
> On Tue, Sep 14, 2010 at 7:33 AM, Carl-Daniel Hailfinger
>  wrote:
> > OK. The board has a "JP1 firmware write protect" jumper, so writing
> > would probably be impossible without opening the case.
> > It _is_ possible that this jumper also prevents probing, but I'm not so
> > sure about that.
>
> Apply the patch on the latest SVN.  Depending on when you try to
> apply, it might need some changes.  (The diff was generated on r1171.)
>
> --- a/chipset_enable.c
> +++ b/chipset_enable.c
> @@ -802,6 +802,23 @@ static int enable_flash_ck804(struct pci_dev *dev, const char *name)
>    return 0;
>  }
>
> +static int enable_flash_osb4(struct pci_dev *dev, const char *name)
> +{
> uint8_t tmp;
> buses_supported = CHIP_BUSTYPE_PARALLEL;
> tmp = INB(0xc06);
> tmp |= 0x1;
> OUTB(tmp, 0xc06);
> tmp = INB(0xc6f);
> tmp |= 0x40;
> OUTB(tmp, 0xc6f);
> return 0;
>
> +}

Funny. The 0xc6f access looks very similar to parts of the SB400 chipset
enable. (Side note: we should ask AMD if the SB400 chipset enable is
correct.)

Peter, could you please attach /proc/ioports and check if dmesg mentions
0xc06 or 0xc6f or anything close to that?

Joshua, I would like this in 0.9.3. Would it be OK for you to split the
patch in a chipset enable and a flash chip addition? If possible,
coordinate with Mattias to avoid conflicts in flashchips.[ch]

Regards,
Carl-Daniel

[PATCH 1/1] Mark Gigabyte GA-6ETXDR as UNSUPPORTED so far

[Peter Lemenkov]

Hello!

2010/9/15 Carl-Daniel Hailfinger :
> > --- a/chipset_enable.c
> > +++ b/chipset_enable.c
> > @@ -802,6 +802,23 @@ static int enable_flash_ck804(struct pci_dev *dev, const char *name)
> >       return 0;
> >  }
> >
> > +static int enable_flash_osb4(struct pci_dev *dev, const char *name)
> > +{
> > uint8_t tmp;
> > buses_supported = CHIP_BUSTYPE_PARALLEL;
> > tmp = INB(0xc06);
> > tmp |= 0x1;
> > OUTB(tmp, 0xc06);
> > tmp = INB(0xc6f);
> > tmp |= 0x40;
> > OUTB(tmp, 0xc6f);
> > return 0;
> >
> > +}
> Funny. The 0xc6f access looks very similar to parts of the SB400 chipset
> enable. (Side note: we should ask AMD if the SB400 chipset enable is
> correct.)
>
> Peter, could you please attach /proc/ioports and check if dmesg mentions
> 0xc06 or 0xc6f or anything close to that?

Attached /proc/ioports and dmesg contents.

[Carl-Daniel Hailfinger]

On 15.09.2010 12:31, Peter Lemenkov wrote:
> Hello!
>
> 2010/9/15 Carl-Daniel Hailfinger :
> > > --- a/chipset_enable.c
> > > +++ b/chipset_enable.c
> > > @@ -802,6 +802,23 @@ static int enable_flash_ck804(struct pci_dev *dev, const char *name)
> > >       return 0;
> > >  }
> > >
> > > +static int enable_flash_osb4(struct pci_dev *dev, const char *name)
> > > +{
> > > uint8_t tmp;
> > > buses_supported = CHIP_BUSTYPE_PARALLEL;
> > > tmp = INB(0xc06);
> > > tmp |= 0x1;
> > > OUTB(tmp, 0xc06);
> > > tmp = INB(0xc6f);
> > > tmp |= 0x40;
> > > OUTB(tmp, 0xc6f);
> > > return 0;
> > >
> > > +}
> > Funny. The 0xc6f access looks very similar to parts of the SB400 chipset
> > enable. (Side note: we should ask AMD if the SB400 chipset enable is
> > correct.)
> >
> > Peter, could you please attach /proc/ioports and check if dmesg mentions
> > 0xc06 or 0xc6f or anything close to that?
>
> Attached /proc/ioports and dmesg contents.
>
> /proc/ioports:
> [...]
> 0c14-0c14 : pnp 00:02
> 0c49-0c49 : pnp 00:02
> 0c52-0c52 : pnp 00:02
> 0c6c-0c6c : pnp 00:02
> [...]

Thanks for the data.
Yay for crappy BIOS. The chipset I/O ranges touched by the chipset
enable are completely unreserved and other devices may live there.

Joshua, if you send the chipset patch and flash chip patch in separate
mails with a subject that allows easier identification, I will ack them
and commit. Side note: If you have any download URLs for the flash chip
datasheets you used, please mention them in the changelog.

Regards,
Carl-Daniel

[Michael Karcher]

Am Mittwoch, den 15.09.2010, 13:01 +0200 schrieb Carl-Daniel Hailfinger:
> > > Peter, could you please attach /proc/ioports and check if dmesg mentions
> > > 0xc06 or 0xc6f or anything close to that?
> >
> > Attached /proc/ioports and dmesg contents.
> >
> > /proc/ioports:
> > [...]
> > 0c14-0c14 : pnp 00:02
> > 0c49-0c49 : pnp 00:02
> > 0c52-0c52 : pnp 00:02
> > 0c6c-0c6c : pnp 00:02
> > [...]
>
> Thanks for the data.
> Yay for crappy BIOS. The chipset I/O ranges touched by the chipset
> enable are completely unreserved and other devices may live there.

Quite unlikely. ISA-like devices are usually not allocated to addresses
with (addr & 0x3ff) < 0x100, and PCI-like devices are only allocated to
areas where (addr & 0xff) is completely unoccopied. This makes 0xCxx a
very safe choice for chipset internal registers, as 0xCF8..0xCFF is
already occupied by PCI config, and thus the 0xC00..0xFFF range is
typically not allocated to PCI devices. And as stated above, ISAPnP-like
stuff is usually not allocated to 10-bit-aliases of 0x00..0xff.

I know this is all a bit vague without any proof, but this is how
resource allocation in PCs "works" since 30 years: Allocation by
convention. I consider the GPIO/system control areas allocated to 0x1000
much more evil than these ports, as they might cause conficts in
real-world systems. You might notice that the kernel detects these areas
in the PCI quirks but IIRC it does nothing about the 0xCxx I/O ports.
(didn't bother to look it up now, sorry)

Regards,
  Michael Karcher

[PATCH] Add Broadcom OSB4 chipset enable / parallel flash chips

[Joshua Roys]

Hello,

Awesome!  I'm glad you got it working.

On 09/15/2010 06:19 AM, Carl-Daniel Hailfinger wrote:
> Funny. The 0xc6f access looks very similar to parts of the SB400 chipset
> enable. (Side note: we should ask AMD if the SB400 chipset enable is
> correct.)

Yes, I noticed the same thing- hence the placement in chipset_enable.c.
> Joshua, I would like this in 0.9.3. Would it be OK for you to split the
> patch in a chipset enable and a flash chip addition? If possible,
> coordinate with Mattias to avoid conflicts in flashchips.[ch]

OK, attached are two separate patches and a diff...  if the chip #define
fixup gets applied first, then use the post-prefix-change.diff.txt and
squash it in with the flash chip patch.  Otherwise that patch will have
to be updated in order to account for these chips.  (I'll try to figure
out on IRC what order these will be in, and if needs be I can spin
another patch set.)

Thanks!

Signed-off-by: Joshua Roys

Josh

[PATCH] Add Broadcom OSB4 chipset enable / parallel flash chips

[Mattias Mattsson]

On Wed, Sep 15, 2010 at 16:34, Joshua Roys  wrote:
> Hello,
>
> Awesome!  I'm glad you got it working.
>
> On 09/15/2010 06:19 AM, Carl-Daniel Hailfinger wrote:
> > Funny. The 0xc6f access looks very similar to parts of the SB400 chipset
> > enable. (Side note: we should ask AMD if the SB400 chipset enable is
> > correct.)
>
> Yes, I noticed the same thing- hence the placement in chipset_enable.c.
> > Joshua, I would like this in 0.9.3. Would it be OK for you to split the
> > patch in a chipset enable and a flash chip addition? If possible,
> > coordinate with Mattias to avoid conflicts in flashchips.[ch]
>
> OK, attached are two separate patches and a diff...  if the chip #define
> fixup gets applied first, then use the post-prefix-change.diff.txt and
> squash it in with the flash chip patch.  Otherwise that patch will have
> to be updated in order to account for these chips.  (I'll try to figure
> out on IRC what order these will be in, and if needs be I can spin
> another patch set.)
>
> Thanks!
>
> Signed-off-by: Joshua Roys

Thanks!

Flash chip part
Acked-by: Mattias Mattsson

Fixed a small typo (TEST_PR -> TEST_OK_PR), added two more Bright chip
IDs and committed as r1176.

-mattias