coreboot October 2008

coreboot@coreboot.org

84 participants
608 discussions

Re: [coreboot] r945 - in coreboot-v3: arch/x86 arch/x86/via include/arch/x86
by Peter Stuge 24 Oct '08

24 Oct '08

svn(a)coreboot.org wrote: > +#define __stringify_1(x) #x > +#define __stringify(x) __stringify_1(x) Next time please keep unused stuff out. //Peter

1 0

v3 multiboot warnings
by Myles Watson 24 Oct '08

24 Oct '08

This patch makes casting explicit to get rid of compiler warnings. I think it would be nice to remove the #if 0 code in archtables.c to make it more readable too. Objections? Signed-off-by: Myles Watson <mylesgw(a)gmail.com> Thanks, Myles

5 7

[PATCH] v3: die() if the PCI scan code is broken
by Carl-Daniel Hailfinger 24 Oct '08

24 Oct '08

Since revision 845, we had a really loud error message in the coreboot boot log at least on qemu: ERROR: pci_scan_bus called with incorrect bus->dev->path.type, path is PCI_DOMAIN: 0000 Since this means we completely ignore the static device tree, upgrade the error message to die(). A port with a bug in the PCI scan code should not be allowed to keep people scratching their heads about why the static device tree and associated settings are ignored. Instead, the boot should fail loudly. This will break booting at least on qemu. Try applying it if your target shows any PCI/HT related funnies. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: corebootv3-pci_scan_bus_die/device/pci_device.c =================================================================== --- corebootv3-pci_scan_bus_die/device/pci_device.c (Revision 951) +++ corebootv3-pci_scan_bus_die/device/pci_device.c (Arbeitskopie) @@ -1101,9 +1101,11 @@ printk(BIOS_DEBUG, "%s start bus %p, bus->dev %p\n", __func__, bus, bus->dev); - if (bus->dev->path.type != DEVICE_PATH_PCI_BUS) + if (bus->dev->path.type != DEVICE_PATH_PCI_BUS) { printk(BIOS_ERR, "ERROR: pci_scan_bus called with incorrect " "bus->dev->path.type, path is %s\n", dev_path(bus->dev)); + die("The PCI scan code is broken"); + } #if PCI_BUS_SEGN_BITS printk(BIOS_DEBUG, "PCI: pci_scan_bus for bus %04x:%02x\n", -- http://www.hailfinger.org/

3 2

r3692 build service
by coreboot information 24 Oct '08

24 Oct '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "uwe" checked in revision 3692 to the coreboot source repository and caused the following changes: Change Log: Add support for the ITE IT8661F/IT8770F, IT8673F, and IT8671F/IT8687R. They all use a different init sequence than the more modern ITE Super I/Os. For now we only use 0x370 as config port, but 0x3f0 or 0x3bd would also be valid. Contrary to other Super I/Os, the config port for these is _not_ hardcoded via hardware, instead it can be programmed by software, i.e. you get to choose whether you want to use 0x370, 0x3f0, or 0x3bd. Tested on IT8671F by Uwe Hermann and on IT8770F by Urja Rannikko. Signed-off-by: Urja Rannikko <urjaman(a)gmail.com> Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Urja Rannikko <urjaman(a)gmail.com> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of msi:ms9282 has been fixed If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

Using lar from payload
by Kevin O'Connor 24 Oct '08

24 Oct '08

Hi, I was looking through the coreboot code to see if I could access the lar directly from SeaBIOS. It looks like this is pretty straight forward, so I think I might end up trying it. However, I ran into one thing that looks like it will make things a little difficult. Currently, the lar code itself has the decompression code linked into it. If lar traversing code is added to SeaBIOS, it looks like it will also have to support the various decompress functions. That will lead to a notable increase in payload size. I seem to recall reading somewhere that the original plan for the lar was to put the decompressors in their own lar files. That would be ideal for the SeaBIOS case, because then it could invoke the decompress routines without having to duplicate them. Would it be possible to move the decompressors to their own lar files? Looking at the code it doesn't seem too difficult. If I've missed something, please let me know. -Kevin

3 5

[PATCH] superiotool: Add support for ITE IT8661F/IT8770F, IT8673F, and IT8671F/IT8687R
by Uwe Hermann 24 Oct '08

24 Oct '08

Hi, 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(a)gmail.com>' and I will commit. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

2 2

patch: unshare pci operations
by ron minnich 24 Oct '08

24 Oct '08

Unshare these, as we can not use them when buggy PCI expansion ROMS are active and are hiding ROM. attached. ron

7 15

r3692 - trunk/util/superiotool
by svn＠coreboot.org 24 Oct '08

24 Oct '08

Author: uwe Date: 2008-10-24 01:33:18 +0200 (Fri, 24 Oct 2008) New Revision: 3692 Modified: trunk/util/superiotool/README trunk/util/superiotool/ite.c trunk/util/superiotool/superiotool.c trunk/util/superiotool/superiotool.h Log: Add support for the ITE IT8661F/IT8770F, IT8673F, and IT8671F/IT8687R. They all use a different init sequence than the more modern ITE Super I/Os. For now we only use 0x370 as config port, but 0x3f0 or 0x3bd would also be valid. Contrary to other Super I/Os, the config port for these is _not_ hardcoded via hardware, instead it can be programmed by software, i.e. you get to choose whether you want to use 0x370, 0x3f0, or 0x3bd. Tested on IT8671F by Uwe Hermann and on IT8770F by Urja Rannikko. Signed-off-by: Urja Rannikko <urjaman(a)gmail.com> Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Urja Rannikko <urjaman(a)gmail.com> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/util/superiotool/README =================================================================== --- trunk/util/superiotool/README 2008-10-23 12:22:24 UTC (rev 3691) +++ trunk/util/superiotool/README 2008-10-23 23:33:18 UTC (rev 3692) @@ -95,5 +95,6 @@ Ronald Minnich <rminnich(a)gmail.com> Stefan Reinauer <stepan(a)coresystems.de> Ulf Jordan <jordan(a)chalmers.se> +Urja Rannikko <urjaman(a)gmail.com> Uwe Hermann <uwe(a)hermann-uwe.de> Ward Vandewege <ward(a)gnu.org> Modified: trunk/util/superiotool/ite.c =================================================================== --- trunk/util/superiotool/ite.c 2008-10-23 12:22:24 UTC (rev 3691) +++ trunk/util/superiotool/ite.c 2008-10-23 23:33:18 UTC (rev 3692) @@ -23,12 +23,11 @@ #define CHIP_ID_BYTE1_REG 0x20 #define CHIP_ID_BYTE2_REG 0x21 - #define CHIP_VERSION_REG 0x22 +#define ISA_PNP_ADDR 0x279 static const struct superio_registers reg_table[] = { - {0x8661, "IT8661F", { - /* TODO: Needs different init sequence. */ + {0x8661, "IT8661F/IT8770F", { {NOLDN, NULL, {0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x20,0x21,0x22, 0x23,0x24,EOT}, @@ -61,6 +60,10 @@ 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,EOT}}, {EOT}}}, + {0x8673, "IT8673F", { + {EOT}}}, + {0x8681, "IT8671F/IT8687R", { + {EOT}}}, {0x8702, "IT8702F", { {EOT}}}, {0x8705, "IT8705F/AF / IT8700F", { @@ -436,22 +439,53 @@ {EOT} }; +/* Works for: IT8661F/IT8770F */ +static const uint8_t initkey_it8661f[][4] = { + {0x86, 0x61, 0x55, 0x55}, /* 0x3f0 */ + {0x86, 0x61, 0x55, 0xaa}, /* 0x3bd */ + {0x86, 0x61, 0xaa, 0x55}, /* 0x370 */ +}; + +/* Works for: IT8671F/IT8687R, IT8673F */ +static const uint8_t initkey_it8671f[][4] = { + {0x86, 0x80, 0x55, 0x55}, /* 0x3f0 */ + {0x86, 0x80, 0x55, 0xaa}, /* 0x3bd */ + {0x86, 0x80, 0xaa, 0x55}, /* 0x370 */ +}; + +/* Works for: IT8661F/IT8770F, IT8671F/IT8687R, IT8673F. */ +static const uint8_t initkey_mbpnp[] = { + 0x6a, 0xb5, 0xda, 0xed, 0xf6, 0xfb, 0x7d, 0xbe, 0xdf, 0x6f, 0x37, + 0x1b, 0x0d, 0x86, 0xc3, 0x61, 0xb0, 0x58, 0x2c, 0x16, 0x8b, 0x45, + 0xa2, 0xd1, 0xe8, 0x74, 0x3a, 0x9d, 0xce, 0xe7, 0x73, 0x39, +}; + +/* Works for: IT8661F/IT8770F, IT8671F/IT8687R, IT8673F. */ +static void enter_conf_mode_ite_legacy(uint16_t port, const uint8_t init[][4]) +{ + int i, idx; + + /* Determine Super I/O config port. */ + idx = (port == 0x3f0) ? 0 : ((port == 0x3bd) ? 1 : 2); + for (i = 0; i < 4; i++) + outb(init[idx][i], ISA_PNP_ADDR); + + /* Sequentially write the 32 MB PnP init values. */ + for (i = 0; i < 32; i++) + outb(initkey_mbpnp[i], port); +} + /** * IT871[01]F and IT8708F use 0x87, 0x87 * IT8761F uses 0x87, 0x61, 0x55, 0x55/0xaa * IT86xxF series uses different ports - * IT8661F uses 0x86, 0x61, 0x55/0xaa, 0x55/0xaa and 32 more writes - * IT8673F uses 0x86, 0x80, 0x55/0xaa, 0x55/0xaa and 32 more writes */ static void enter_conf_mode_ite(uint16_t port) { outb(0x87, port); outb(0x01, port); outb(0x55, port); - if (port == 0x2e) - outb(0x55, port); - else - outb(0xaa, port); + outb((port == 0x2e) ? 0x55 : 0xaa, port); } static void exit_conf_mode_ite(uint16_t port) @@ -498,13 +532,23 @@ void probe_idregs_ite(uint16_t port) { - enter_conf_mode_ite(port); - probe_idregs_ite_helper("(init=0x87,0x01,0x55,0x55/0xaa) ", port); - exit_conf_mode_ite(port); + if (port == 0x3f0 || port == 0x3bd || port == 0x370) { + enter_conf_mode_ite_legacy(port, initkey_it8661f); + probe_idregs_ite_helper("(init=legacy/it8661f) ", port); + exit_conf_mode_ite(port); - enter_conf_mode_winbond_fintek_ite_8787(port); - probe_idregs_ite_helper("(init=0x87,0x87) ", port); - exit_conf_mode_winbond_fintek_ite_8787(port); + enter_conf_mode_ite_legacy(port, initkey_it8671f); + probe_idregs_ite_helper("(init=legacy/it8671f) ", port); + exit_conf_mode_ite(port); + } else { + enter_conf_mode_ite(port); + probe_idregs_ite_helper("(init=0x87,0x01,0x55,0x55/0xaa) ", port); + exit_conf_mode_ite(port); + + enter_conf_mode_winbond_fintek_ite_8787(port); + probe_idregs_ite_helper("(init=0x87,0x87) ", port); + exit_conf_mode_winbond_fintek_ite_8787(port); + } } void print_ite_chips(void) Modified: trunk/util/superiotool/superiotool.c =================================================================== --- trunk/util/superiotool/superiotool.c 2008-10-23 12:22:24 UTC (rev 3691) +++ trunk/util/superiotool/superiotool.c 2008-10-23 23:33:18 UTC (rev 3692) @@ -32,7 +32,7 @@ uint8_t regval(uint16_t port, uint8_t reg) { outb(reg, port); - return inb(port + 1); + return inb(port + ((port == 0x3bd) ? 2 : 1)); /* 0x3bd is special. */ } void regwrite(uint16_t port, uint8_t reg, uint8_t val) Modified: trunk/util/superiotool/superiotool.h =================================================================== --- trunk/util/superiotool/superiotool.h 2008-10-23 12:22:24 UTC (rev 3691) +++ trunk/util/superiotool/superiotool.h 2008-10-23 23:33:18 UTC (rev 3692) @@ -118,7 +118,8 @@ } superio_ports_table[] = { {probe_idregs_ali, {0x3f0, 0x370, EOT}}, {probe_idregs_fintek, {0x2e, 0x4e, EOT}}, - {probe_idregs_ite, {0x2e, 0x4e, EOT}}, + /* Only use 0x370 for ITE, but 0x3f0 or 0x3bd would also be valid. */ + {probe_idregs_ite, {0x2e, 0x4e, 0x370, EOT}}, {probe_idregs_nsc, {0x2e, 0x4e, 0x15c, EOT}}, {probe_idregs_smsc, {0x2e, 0x4e, 0x162e, 0x164e, 0x3f0, 0x370, EOT}}, {probe_idregs_winbond, {0x2e, 0x4e, 0x3f0, 0x370, 0x250, EOT}},

1 0

[PATCH] v2: Add missing license header to sb600_smbus.c
by Uwe Hermann 23 Oct '08

23 Oct '08

See patch. I've added the same license header as all the other sb600 files have (copyright AMD, 2008, GPLv2). Ron has already added the same header when porting the file to v3, but v2 doesn't have that header. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

1 1

Re: [coreboot] r950 - coreboot-v3/northbridge/amd/k8
by Myles Watson 23 Oct '08

23 Oct '08

> - switch((base >> 8) & 7) { > - case 0: return "No interleave"; > - case 1: return "2 nodes"; > - case 3: return "4 nodes"; > - case 7: return "8 nodes"; > - default: return "Reserved"; > + /* TODO: Are these fallthroughs intentional? */ I don't think they'll fall through because of the return statements. Thanks, Myles

2 1

← Newer
1
...
17
18
19
20
21
22
23
...
61
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2008