[coreboot] [PATCH] superiotool: Add support for ITE IT8661F/IT8770F, IT8673F, and IT8671F/IT8687R

Uwe Hermann uwe at hermann-uwe.de
Thu Oct 23 12:12:50 CEST 2008


On Tue, Oct 21, 2008 at 02:33:49AM +0300, Urja Rannikko wrote:
> > Do you have an IT8770F datasheet? I haven't been able to find one.
> > I assume you know that it has the same ID as IT8661F because you
> > have a board with an IT8770F? Which one is that?
> A PCchips M741LMRT clone. It returned the same id,0x8661 (rev 0x6). but the marking on the superio chip says IT8770F. I could only find an 8661F datasheet. (i googled for IT8770F and found notes of it being identical to IT8661F and just gave it a try).

OK, sounds good.

> >> enter_conf_mode_ite (and if it succeeds, skip other enables).
> >> 0x3F0 is added to the ITE scanned ports because the 8661/8770 can be
> >> programmed to 0x3F0,0x370 or 0x3BD only
> >> (gets programmed by the test function).
> >
> > This is an interesting question -- is the config port hardcoded for each
> > board (and you have to use the correct one), or do you actually _choose_
> > the config port using the sequence below?
> yes, the probing sequence tries to program the I/O address given in port to the chip (3 different addresses valid), so its programmable. At the moment it would program it to first valid address probed (that returned the proper ID), though i was lazy and added only one to the list of probed addresses.

Yep, indeed. I tested on a board with IT8671F (which is similar, see
patch) and I can put it to whatever port I want, i.e. it's not hardcoded.

> >> +     outb(0x55,isapnp_addr);
> >> +     outb(0x55,isapnp_addr); /* Reset key check logic */
> >
> > Why 0x55 here? Couldn't find that piece of information in the
> > (IT8661F) datasheet, I think.
> >
> There only reads that 2 writes (propably of the same value, since 1st wrong value resets it and there's no 2 same sequentially in the isapnp key) to the address port would reset the key check logic. I chose 0x55 in random (and it seemed to be an invalid value for being a part of the key).

I dropped this part for now, the datasheets are very unclear what should
be done here. In some other ITE document which explains how to init the
Super I/Os I didn't see any such two writes either, and I also tested on
my hardware that the detection works fine without them.

> >> Index: superiotool.h
> >> ===================================================================
> >> --- superiotool.h     (revision 3667)
> >> +++ superiotool.h     (working copy)
> >> @@ -118,7 +118,7 @@
> >>  } superio_ports_table[] = {
> >>       {probe_idregs_ali,      {0x3f0, 0x370, EOT}},
> >>       {probe_idregs_fintek,   {0x2e, 0x4e, EOT}},
> >> -     {probe_idregs_ite,      {0x2e, 0x4e, EOT}},
> >> +     {probe_idregs_ite,      {0x2e, 0x4e, 0x3f0, EOT}},
> >
> > Shouldn't 0x370 and 0x3bd also be added here then?
> >
> Maybe they could/should; i'm not sure, maybe to make sure that the SuperI/O is detected even if something occupies 0x3F0, but as said, its programmable to any of the 3 addresses...

Yeah, let's just use 0x370 for now (0x3f0 could be floppy).

Please check if my reworked patch below also works for you. I have
documented a few more quirks of these chips, as well as restructured
the code and added support for similar chips such as the IT8673F, and
IT8671F/IT8687R while I was at it.

It's tested on my IT8671F board, please post a 'superiotool -dV' of your
board if this patch works for you. If so, please send a mail with
'Acked-by: Urja Rannikko <urjaman at gmail.com>' and I will commit.

http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: superiotool_ite_various.patch
Type: text/x-diff
Size: 5536 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081023/73892346/attachment.bin>

More information about the coreboot mailing list