coreboot June 2009

coreboot@coreboot.org

84 participants
500 discussions

Start a nNew thread

[Patch] Flashrom: Add gA-k8n-sli board enable.
by Luc Verhaegen 03 Jun '09

03 Jun '09

Still needs to be tested by alexander. Luc Verhaegen.

3 6

[flashrom] r568 - trunk
by svn＠coreboot.org 03 Jun '09

03 Jun '09

Author: libv Date: 2009-06-03 09:50:39 +0200 (Wed, 03 Jun 2009) New Revision: 568 Modified: trunk/board_enable.c Log: Board enable: Gigabyte GA K8N SLI. Raises bits 0 and 2 on offset 0xE1 in the system control area of the nvidia ck804 lpc. Signed-off-by: Luc Verhaegen <libv(a)skynet.be> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Alexander Gordeev <lasaine(a)lvk.cs.msu.su> Modified: trunk/board_enable.c =================================================================== --- trunk/board_enable.c 2009-06-02 19:54:22 UTC (rev 567) +++ trunk/board_enable.c 2009-06-03 07:50:39 UTC (rev 568) @@ -372,6 +372,31 @@ return 0; } +/** + * Suited for the Gigabyte GA-K8N-SLI: CK804 southbridge. + */ +static int board_ga_k8n_sli(const char *name) +{ + struct pci_dev *dev; + uint32_t base; + uint8_t tmp; + + dev = pci_dev_find(0x10DE, 0x0050); /* NVIDIA CK804 LPC */ + if (!dev) { + fprintf(stderr, "\nERROR: NVIDIA LPC bridge not found.\n"); + return -1; + } + + base = pci_read_long(dev, 0x64) & 0x0000FF00; /* System control area */ + + /* if anyone knows more about nvidia lpcs, feel free to explain this */ + tmp = inb(base + 0xE1); + tmp |= 0x05; + outb(tmp, base + 0xE1); + + return 0; +} + static int board_hp_dl145_g3_enable(const char *name) { /* Set GPIO lines in the Broadcom HT-1000 southbridge. */ @@ -670,6 +695,7 @@ {0x8086, 0x7110, 0, 0, 0x8086, 0x7190, 0, 0, "epox", "ep-bx3", "EPoX", "EP-BX3", board_epox_ep_bx3}, {0x1039, 0x0761, 0, 0, 0, 0, 0, 0, "gigabyte", "2761gxdk", "GIGABYTE", "GA-2761GXDK", it87xx_probe_spi_flash}, {0x1106, 0x3227, 0x1458, 0x5001, 0x10ec, 0x8139, 0x1458, 0xe000, NULL, NULL, "GIGABYTE", "GA-7VT600", board_biostar_p4m80_m4}, + {0x10DE, 0x0050, 0x1458, 0x0C11, 0x10DE, 0x005e, 0x1458, 0x5000, NULL, NULL, "GIGABYTE", "GA-K8N-SLI", board_ga_k8n_sli}, {0x10de, 0x0360, 0, 0, 0, 0, 0, 0, "gigabyte", "m57sli", "GIGABYTE", "GA-M57SLI-S4", it87xx_probe_spi_flash}, {0x10de, 0x03e0, 0, 0, 0, 0, 0, 0, "gigabyte", "m61p", "GIGABYTE", "GA-M61P-S3", it87xx_probe_spi_flash}, {0x1002, 0x4398, 0x1458, 0x5004, 0x1002, 0x4391, 0x1458, 0xb000, NULL, NULL, "GIGABYTE", "GA-MA78G-DS3H", it87xx_probe_spi_flash}, @@ -787,7 +813,6 @@ { "Boser", "HS-6637", }, { "DFI", "855GME-MGF", }, { "FIC", "VA-502", }, - { "GIGABYTE", "GA-K8N-SLI", }, { "MSI", "MS-6178", }, { "MSI", "MS-7260 (K9N Neo)", }, { "PCCHIPS", "M537DMA33", },

1 0

[patch]: a little error is fixed.
by Bao, Zheng 03 Jun '09

03 Jun '09

Modify it based on the RPR. 5.7.7. Switching GPPSB Configuration By Register Programming. Signed-off-by: Zheng Bao <zheng.bao(a)amd.com> Index: src/southbridge/amd/rs690/rs690_pcie.c =================================================================== --- src/southbridge/amd/rs690/rs690_pcie.c (revision 469) +++ src/southbridge/amd/rs690/rs690_pcie.c (working copy) @@ -148,7 +148,7 @@ /* waits until SB has trained to L0, poll for bit0-5 = 0x10 */ do { reg = nbpcie_p_read_index(sb_dev, PCIE_LC_STATE0); - reg &= 0x1f; /* remain LSB 5 bits */ + reg &= 0x3f; /* remain LSB [5:0] bits */ } while (LC_STATE_RECONFIG_GPPSB != reg); /* ensures that virtual channel negotiation is completed. poll for bit1 = 0 */

2 4

[v2] r4331 - trunk/coreboot-v2/src/southbridge/amd/rs690
by svn＠coreboot.org 03 Jun '09

03 Jun '09

Author: zbao Date: 2009-06-03 05:15:05 +0200 (Wed, 03 Jun 2009) New Revision: 4331 Modified: trunk/coreboot-v2/src/southbridge/amd/rs690/rs690_pcie.c Log: Modify it based on the RPR 5.7.7. Switching GGSP Configuration By Register Programming. Signed-off-by: Zheng Bao <zheng.bao(a)amd.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/coreboot-v2/src/southbridge/amd/rs690/rs690_pcie.c =================================================================== --- trunk/coreboot-v2/src/southbridge/amd/rs690/rs690_pcie.c 2009-06-02 23:49:00 UTC (rev 4330) +++ trunk/coreboot-v2/src/southbridge/amd/rs690/rs690_pcie.c 2009-06-03 03:15:05 UTC (rev 4331) @@ -148,7 +148,7 @@ /* waits until SB has trained to L0, poll for bit0-5 = 0x10 */ do { reg = nbpcie_p_read_index(sb_dev, PCIE_LC_STATE0); - reg &= 0x1f; /* remain LSB 5 bits */ + reg &= 0x3f; /* remain LSB [5:0] bits */ } while (LC_STATE_RECONFIG_GPPSB != reg); /* ensures that virtual channel negotiation is completed. poll for bit1 = 0 */

1 0

[RFC] Configuration Data File Format
by Carl-Daniel Hailfinger 03 Jun '09

03 Jun '09

Since the topic of optimal flash usage for configuration data comes up repeatedly, I'd like to propose a flash-friendly and LAR/CBFS compatible way to store and update configuration data. The CDFF data is stored inside an uncompressed LAR/CBFS archive member which occupies a full flash erase block, either with the start of the header at the start of the erase block or with the start of the data section at the start of the erase block. The CDFF file format is as follows: File Format header: 4 bytes magic header "CDFF" 4 bytes total length of CDFF area excluding file header Configuration Data header: 2 bytes magic header "CD" 2 bytes version number of configuration data, at least 0x0001 (0x0000 means invalid) 4 bytes total length of Configuration Data excluding Configuration Data header Configuration Item header (version 0x0001): 2 bytes magic header "CI" 2 bytes data type, must not be 0x0000 (which is reserved) 4 bytes length of Configuration Item n bytes of Configuration Item content Each header is aligned at a 4 byte boundary. The File Format header exists exactly once at the start. Directly after the File Format header, the first Configuration Data header starts. It is a "container" for multiple Configuration Items. The version number has to be at least 0x0001. To mark the Configuation Data as invalid, the version number is set to 0x0000 which is a flash-friendly operation possible without erase. If the version number is 0x0000, the reader skips over CD total length bytes starting after the header and looks for the next CD header aligned to the next 4 byte boundary. Directly after the Configuration Data header, the first Configuration Item header starts. It holds a single configuration item or its description. The CI data type MSB is 0 if the data is a value and 1 for the matching (null-terminated) name/description. After the data there is the next CI header aligned at the next 4 byte boundary. If you need to update the data, simply write a new CD container with CI data directly after the end of the last valid CD container. If the write was successful, mark the previous container as invalid. If not, the old container will still be valid and everything is OK. If there's not enough room left for a new CD container, erase the whole block and write a new CDFF header, CD header and all CIs. This scheme keeps flash wear at a minium, has safe updates (except in the case where all space is used up and the block has to be erased), is fast and easy to walk and extensible enough to last a lifetime. Example file: 0x43444646 (CDFF magic) 0x00000FF8 (eraseblockisze 4096 - headersize 8) 0x4344 (CD magic) 0x0001 (version) 0xbla (CD length) 0x4349 (CI magic) 0x0001 (data type, data) 0x00000013 (CI length) "hda1:/boot/vmlinux\0" (data) 0xff (padding) 0x4349 (CI magic) 0x8001 (data type, description) 0x00000009 (CI length) "bootfile\0" 0xffffff (padding) 0x4349 (CI magic) 0x0002 (data type, data) 0x00000018 (CI length) "acpi=off root=/dev/sda2\0" (data) 0x4349 (CI magic) 0x8002 (data type, description) 0x0000000B (CI length) "bootparams\0" 0xff (padding) Since the CI name is (optionally) stored along with the CI data, running out of data types is only possible if we have more than 32767 different CIs. Any config reader can just search for the name if it wants some data. The naming also avoids having a central registry about which data type has which number, an annoyance present with our current NVRAM scheme. A checksum is possible (even in a mostly flash-friendly way), but it would have cluttered this design doc. Regards, Carl-Daniel -- http://www.hailfinger.org/

1 0

[v2] r4330 - trunk/coreboot-v2/util/optionlist
by svn＠coreboot.org 02 Jun '09

02 Jun '09

Author: uwe Date: 2009-06-03 01:49:00 +0200 (Wed, 03 Jun 2009) New Revision: 4330 Modified: trunk/coreboot-v2/util/optionlist/Options-wiki.xsl Log: More compact format for wiki output at http://www.coreboot.org/Coreboot_Options (trivial). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/coreboot-v2/util/optionlist/Options-wiki.xsl =================================================================== --- trunk/coreboot-v2/util/optionlist/Options-wiki.xsl 2009-06-01 20:02:21 UTC (rev 4329) +++ trunk/coreboot-v2/util/optionlist/Options-wiki.xsl 2009-06-02 23:49:00 UTC (rev 4330) @@ -25,29 +25,22 @@ indent="yes" /> <xsl:template match="/"> -This is an automatically generated list of '''coreboot compile-time options'''. +This is an automatically generated list of '''coreboot v2 compile-time options'''. Last update: <xsl:value-of select="//creationdate"/>. -{| border="0" +{| border="0" style="font-size: smaller" |- bgcolor="#6699dd" ! align="left" | Option ! align="left" | Comment ! align="left" | Default ! align="left" | Export -! align="left" | Format<xsl:for-each select="options/option"> +! align="left" | Format +<xsl:for-each select="options/option"> |- bgcolor="#eeeeee" -| -<xsl:value-of select="@name"/> -| -<xsl:value-of select="comment"/> -| -<xsl:value-of select="default"/> -| -<xsl:value-of select="export"/> -| -<xsl:value-of select="format"/> +| <xsl:value-of select="@name"/> || <xsl:value-of select="comment"/> || <xsl:value-of select="default"/> || <xsl:value-of select="export"/> || <xsl:value-of select="format"/> </xsl:for-each> + |} </xsl:template>

1 0

broken tree error when building coreboot-v3 for qemu
by Robert 02 Jun '09

02 Jun '09

Hello, i am getting the following error when trying to compile coreboot-v3 for qemu: CC build/northbridge/intel/i440bxemulation/i440bx.o CC build/southbridge/intel/i82371eb/i82371eb.o DTC build/mainboard/emulation/qemu-x86/statictree.c DTC mainboard/emulation/qemu-x86/dts (dts->lb) CC build/mainboard/emulation/qemu-x86/statictree.o AR build/util/x86emu/libx86emu.a ar: /home/robert/app/coreboot/coreboot-v3/build/util/x86emu/libx86emu.a: No such file or directory make: *** [/home/robert/app/coreboot/coreboot-v3/build/util/x86emu/libx86emu.a] Error 1

3 2

Flashrom jedec probe patch + AT29C010A logs
by Maciej Pijanka 02 Jun '09

02 Jun '09

Hello Carl-Daniel pointed me to easy tasks list in wiki, i tried to prepare some patch that allow to add probe_timing information (int uS value) used by jedec_probe (patch attached) best regards Maciej Pijanka -- Maciej Pijanka, PLD-Linux Developer, Reg Linux user #133161 POE/Perl user

2 3

[FILO] #18: SD card support in FILO
by FILO 02 Jun '09

02 Jun '09

#18: SD card support in FILO ---------------------------------+------------------------------------------ Reporter: uwe | Owner: somebody Type: enhancement | Status: new Priority: major | Milestone: Component: FILO | Version: Keywords: | Dependencies: Patchstatus: there is no patch | ---------------------------------+------------------------------------------ Someone requested SD card support in FILO recently on IRC, let's add an issue for this so we don't forget about it. -- Ticket URL: <http://tracker.coreboot.org/trac/filo/ticket/18> FILO <http://www.coreboot.org/FILO>

1 0

[flashrom] r567 - trunk
by svn＠coreboot.org 02 Jun '09

02 Jun '09

Author: uwe Date: 2009-06-02 21:54:22 +0200 (Tue, 02 Jun 2009) New Revision: 567 Modified: trunk/chipset_enable.c trunk/dummyflasher.c trunk/flash.h trunk/flashrom.8 trunk/nic3com.c Log: Mark the 10b7:9058 3COM card (3C905B: Cyclone 10/100/BNC) as "OK", forgot this in the last commit. Also do some random cleanups while I'm at it. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/chipset_enable.c =================================================================== --- trunk/chipset_enable.c 2009-06-02 16:45:59 UTC (rev 566) +++ trunk/chipset_enable.c 2009-06-02 19:54:22 UTC (rev 567) @@ -781,15 +781,15 @@ static int enable_flash_nvidia_nforce2(struct pci_dev *dev, const char *name) { - uint8_t tmp; + uint8_t tmp; - pci_write_byte(dev, 0x92, 0); + pci_write_byte(dev, 0x92, 0); - tmp = pci_read_byte(dev, 0x6d); - tmp |= 0x01; - pci_write_byte(dev, 0x6d, tmp); + tmp = pci_read_byte(dev, 0x6d); + tmp |= 0x01; + pci_write_byte(dev, 0x6d, tmp); - return 0; + return 0; } static int enable_flash_ck804(struct pci_dev *dev, const char *name) Modified: trunk/dummyflasher.c =================================================================== --- trunk/dummyflasher.c 2009-06-02 16:45:59 UTC (rev 566) +++ trunk/dummyflasher.c 2009-06-02 19:54:22 UTC (rev 567) @@ -66,7 +66,7 @@ if (buses_supported == CHIP_BUSTYPE_NONE) printf_debug("Support for all flash bus types disabled.\n"); free(dummytype); - return 0; + return 0; } int dummy_shutdown(void) Modified: trunk/flash.h =================================================================== --- trunk/flash.h 2009-06-02 16:45:59 UTC (rev 566) +++ trunk/flash.h 2009-06-02 19:54:22 UTC (rev 567) @@ -346,8 +346,8 @@ #define EN_29F040A 0x7F04 #define EN_29LV010 0x7F6E #define EN_29LV040A 0x7F4F /* EN_29LV040(A) */ -#define EN_29F002T 0x7F92 -#define EN_29F002B 0x7F97 +#define EN_29F002T 0x7F92 /* Also EN29F002A */ +#define EN_29F002B 0x7F97 /* Also EN29F002AN */ #define FUJITSU_ID 0x04 /* Fujitsu */ #define MBM29F400BC 0xAB Modified: trunk/flashrom.8 =================================================================== --- trunk/flashrom.8 2009-06-02 16:45:59 UTC (rev 566) +++ trunk/flashrom.8 2009-06-02 19:54:22 UTC (rev 567) @@ -133,7 +133,7 @@ .sp .BR "* satasii" " (for flash ROMs on Silicon Image SATA/IDE controllers)" .sp -.BR "* it87spi" " (for flash ROMs behind a IT87xx SuperI/O LPC/SPI translation unit)" +.BR "* it87spi" " (for flash ROMs behind an ITE IT87xx Super I/O LPC/SPI translation unit)" .sp The dummy programmer has an optional parameter specifying the bus types it should support. For that you have to use the Modified: trunk/nic3com.c =================================================================== --- trunk/nic3com.c 2009-06-02 16:45:59 UTC (rev 566) +++ trunk/nic3com.c 2009-06-02 19:54:22 UTC (rev 567) @@ -46,7 +46,7 @@ {0x10b7, 0x9006, PCI_NT, "3COM", "3C90xB: PCI 10BASE-T/10BASE2 (TPC)" }, {0x10b7, 0x900a, PCI_NT, "3COM", "3C90xB: PCI 10BASE-FL" }, {0x10b7, 0x905a, PCI_NT, "3COM", "3C90xB: PCI 10BASE-FX" }, - {0x10b7, 0x9058, PCI_NT, "3COM", "3C905B: Cyclone 10/100/BNC" }, + {0x10b7, 0x9058, PCI_OK, "3COM", "3C905B: Cyclone 10/100/BNC" }, /* 3C905C */ {0x10b7, 0x9200, PCI_OK, "3COM", "3C905C: EtherLink 10/100 PCI (TX)" },

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot June 2009