coreboot May 2008

coreboot@coreboot.org

79 participants
387 discussions

r3301 - trunk/util/flashrom
by svn＠coreboot.org 13 May '08

13 May '08

Author: hailfinger Date: 2008-05-13 16:01:22 +0200 (Tue, 13 May 2008) New Revision: 3301 Modified: trunk/util/flashrom/spi.c Log: Change the SPI parts of flashrom to prepare for a merge of ICH9 SPI support. In theory, this patch has no behaviour changes. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/util/flashrom/spi.c =================================================================== --- trunk/util/flashrom/spi.c 2008-05-12 21:19:53 UTC (rev 3300) +++ trunk/util/flashrom/spi.c 2008-05-13 14:01:22 UTC (rev 3301) @@ -32,47 +32,47 @@ #define ITE_SUPERIO_PORT2 0x4e /* Read Electronic ID */ -#define JEDEC_RDID {0x9f} +#define JEDEC_RDID 0x9f #define JEDEC_RDID_OUTSIZE 0x01 #define JEDEC_RDID_INSIZE 0x03 /* Write Enable */ -#define JEDEC_WREN {0x06} +#define JEDEC_WREN 0x06 #define JEDEC_WREN_OUTSIZE 0x01 #define JEDEC_WREN_INSIZE 0x00 /* Write Disable */ -#define JEDEC_WRDI {0x04} +#define JEDEC_WRDI 0x04 #define JEDEC_WRDI_OUTSIZE 0x01 #define JEDEC_WRDI_INSIZE 0x00 /* Chip Erase 0x60 is supported by Macronix/SST chips. */ -#define JEDEC_CE_60 {0x60}; +#define JEDEC_CE_60 0x60 #define JEDEC_CE_60_OUTSIZE 0x01 #define JEDEC_CE_60_INSIZE 0x00 /* Chip Erase 0xc7 is supported by ST/EON/Macronix chips. */ -#define JEDEC_CE_C7 {0xc7}; +#define JEDEC_CE_C7 0xc7 #define JEDEC_CE_C7_OUTSIZE 0x01 #define JEDEC_CE_C7_INSIZE 0x00 /* Block Erase 0x52 is supported by SST chips. */ -#define JEDEC_BE_52 {0x52}; +#define JEDEC_BE_52 0x52 #define JEDEC_BE_52_OUTSIZE 0x04 #define JEDEC_BE_52_INSIZE 0x00 /* Block Erase 0xd8 is supported by EON/Macronix chips. */ -#define JEDEC_BE_D8 {0xd8}; +#define JEDEC_BE_D8 0xd8 #define JEDEC_BE_D8_OUTSIZE 0x04 #define JEDEC_BE_D8_INSIZE 0x00 /* Sector Erase 0x20 is supported by Macronix/SST chips. */ -#define JEDEC_SE {0x20}; +#define JEDEC_SE 0x20 #define JEDEC_SE_OUTSIZE 0x04 #define JEDEC_SE_INSIZE 0x00 /* Read Status Register */ -#define JEDEC_RDSR {0x05}; +#define JEDEC_RDSR 0x05 #define JEDEC_RDSR_OUTSIZE 0x01 #define JEDEC_RDSR_INSIZE 0x01 #define JEDEC_RDSR_BIT_WIP (0x01 << 0) @@ -251,7 +251,7 @@ static int spi_rdid(unsigned char *readarr) { - const unsigned char cmd[] = JEDEC_RDID; + const unsigned char cmd[JEDEC_RDID_OUTSIZE] = {JEDEC_RDID}; if (spi_command(JEDEC_RDID_OUTSIZE, JEDEC_RDID_INSIZE, cmd, readarr)) return 1; @@ -261,7 +261,7 @@ void spi_write_enable() { - const unsigned char cmd[] = JEDEC_WREN; + const unsigned char cmd[JEDEC_WREN_OUTSIZE] = {JEDEC_WREN}; /* Send WREN (Write Enable) */ spi_command(JEDEC_WREN_OUTSIZE, JEDEC_WREN_INSIZE, cmd, NULL); @@ -269,7 +269,7 @@ void spi_write_disable() { - const unsigned char cmd[] = JEDEC_WRDI; + const unsigned char cmd[JEDEC_WRDI_OUTSIZE] = {JEDEC_WRDI}; /* Send WRDI (Write Disable) */ spi_command(JEDEC_WRDI_OUTSIZE, JEDEC_WRDI_INSIZE, cmd, NULL); @@ -310,7 +310,7 @@ uint8_t spi_read_status_register() { - const unsigned char cmd[] = JEDEC_RDSR; + const unsigned char cmd[JEDEC_RDSR_OUTSIZE] = {JEDEC_RDSR}; unsigned char readarr[1]; /* Read Status Register */ @@ -393,7 +393,7 @@ int spi_chip_erase_c7(struct flashchip *flash) { - const unsigned char cmd[] = JEDEC_CE_C7; + const unsigned char cmd[JEDEC_CE_C7_OUTSIZE] = {JEDEC_CE_C7}; spi_disable_blockprotect(); spi_write_enable(); @@ -414,7 +414,7 @@ */ int spi_block_erase_d8(const struct flashchip *flash, unsigned long addr) { - unsigned char cmd[JEDEC_BE_D8_OUTSIZE] = JEDEC_BE_D8; + unsigned char cmd[JEDEC_BE_D8_OUTSIZE] = {JEDEC_BE_D8}; cmd[1] = (addr & 0x00ff0000) >> 16; cmd[2] = (addr & 0x0000ff00) >> 8; @@ -433,7 +433,7 @@ /* Sector size is usually 4k, though Macronix eliteflash has 64k */ int spi_sector_erase(const struct flashchip *flash, unsigned long addr) { - unsigned char cmd[JEDEC_SE_OUTSIZE] = JEDEC_SE; + unsigned char cmd[JEDEC_SE_OUTSIZE] = {JEDEC_SE}; cmd[1] = (addr & 0x00ff0000) >> 16; cmd[2] = (addr & 0x0000ff00) >> 8; cmd[3] = (addr & 0x000000ff); @@ -479,7 +479,7 @@ */ void spi_write_status_register(int status) { - const unsigned char cmd[] = {JEDEC_WRSR, (unsigned char)status}; + const unsigned char cmd[JEDEC_WRSR_OUTSIZE] = {JEDEC_WRSR, (unsigned char)status}; /* Send WRSR (Write Status Register) */ spi_command(JEDEC_WRSR_OUTSIZE, JEDEC_WRSR_INSIZE, cmd, NULL);

1 0

Add support for SPI-Chips on ICH9 to flash rom / corrected
by Claus Gindhart 13 May '08

13 May '08

This patch adds support for the SPI Chips Atmel AT25DF32, ST M25P80, ST M25P16, M25P32, ST M25P64 attached to the ICH9. Because chipset plays an important role in communicating with these chips, it was not possible to integrate this support into the already existing spi.c This module was tested with the devices as mentioned above, but it should be easy to expand it for other SPI chips attached to an ICH. Signed-off-by: Claus Gindhart <claus.gindhart(a)kontron.com> --- The previous patch was buggy; there was a merging conflict in my local code repository, which was incuded into the patch; sorry for that. I did not yet set the test status flag to any TEST_OK for my supporting function, because yet i dont know, who has the permission to do that; is it the initiator of this code, or any acknowledging person ? Mit freundlichen Grüßen / Best regards Claus Gindhart SW R&D Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart@kontron.com http://www.kontron.com Kontron Modular Computers GmbH Geschaeftsfuehrer / Managing Directors: Ulrich Gehrmann, Thomas Sabisch Sitz der Gesellschaft / Registered Office: Kaufbeuren, Rechtsform / Legal: GmbH Amtsgericht / Local District Court Kempten, HRB Nr. / Trade Register No. 6195 The information contained in this document is CONFIDENTIAL and property of Kontron. Any unauthorized review, use, disclosure or distribution is prohibited without express written consent of Kontron. If you are not the intended recipient, please contact the sender and destroy all copies of the original message and enclosed attachments. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist Eigentum von Kontron. Die Verwendung und Weitergabe von jeglichen Inhalten ist ohne ausdrückliche schriftliche Genehmigung von Kontron strikt untersagt. Wenn Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten diese Mail und enthaltene Dokumente.

4 4

Add support for SPI-Chips on ICH9 to flash rom / corrected again
by Claus Gindhart 13 May '08

13 May '08

This patch adds support for the SPI Chips Atmel AT25DF32, ST M25P80, ST M25P16, M25P32, ST M25P64 attached to the ICH9. Because chipset plays an important role in communicating with these chips, it was not possible to integrate this support into the already existing spi.c This module was tested with the devices as mentioned above, but it should be easy to expand it for other SPI chips attached to an ICH. Signed-off-by: Claus Gindhart <claus.gindhart(a)kontron.com> --- Fixed it to fulfil feedback of Uwe Hermann and Peter Stuge, related to coreboot coding conventions. Mit freundlichen Grüßen / Best regards Claus Gindhart SW R&D Kontron Modular Computers phone :++49 (0)8341-803-374 mailto:claus.gindhart@kontron.com http://www.kontron.com Kontron Modular Computers GmbH Geschaeftsfuehrer / Managing Directors: Ulrich Gehrmann, Thomas Sabisch Sitz der Gesellschaft / Registered Office: Kaufbeuren, Rechtsform / Legal: GmbH Amtsgericht / Local District Court Kempten, HRB Nr. / Trade Register No. 6195 The information contained in this document is CONFIDENTIAL and property of Kontron. Any unauthorized review, use, disclosure or distribution is prohibited without express written consent of Kontron. If you are not the intended recipient, please contact the sender and destroy all copies of the original message and enclosed attachments. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen und ist Eigentum von Kontron. Die Verwendung und Weitergabe von jeglichen Inhalten ist ohne ausdrückliche schriftliche Genehmigung von Kontron strikt untersagt. Wenn Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten diese Mail und enthaltene Dokumente.

2 1

PCI bus mastering
by Andrei Birjukov 13 May '08

13 May '08

Hello, I am writing to the CoreBoot mailing list concerning the PCI bus mastering issue that prevents Windows CE drivers from functioning. Artec DBE62 board has a VIA Velocity NIC, that requires bus mastering in order to perform DMA and function correctly. I noticed that nearly all Linux drivers set the bus mastering flag manually during init stage. Unfortunately, this is not the case with Windows CE drivers. I would be more than happy to do the same thing there, but the problem is, drivers for modern NICs are often supplied as pre-compiled binaries. And it is not always feasible to init the mastering flag in a CE board support packages. Provided that we want CoreBoot to set PCI bus mastering for a NIC, what is the most adequate way of doing it? 1. With DBE61, we had a dummy RTL8139 PCI driver under src/drivers/pci/rtl8139 that did some chip initialization. I believe that is not suitable for the mainline. 2. Another option would be to globally force the PCI_COMMAND_MASTER in pci_probe_dev(), if the base class is PCI_BASE_CLASS_NETWORK. 3. It must be also possible to find the PCI device during the mainboard-specific init and issue the mastering command from there. We have already implemented it as (2), please let me know if you want the patch. Regards, Andrei -- Andrei Birjukov Embedded Software Engineer Artec Design LLC Turi 10C, 11313, Tallinn, Estonia Phone: +3726718559 Fax: +3726718555 GSM: +37256908939 E-mail: andrei.birjukov(a)artecdesign.ee WWW: http://www.artecdesign.com

6 8

legacy bios support and coreboot
by aaron lwe 13 May '08

13 May '08

Hi kevin, Great job! Some comments below. > > I suspect the hardware detection and initialization does not have much > overlap with coreboot. The most important part of this section is the > IDE initialization and disk scan. (Some other code, for example > keyboard init, may be redundant when used with coreboot.) yes > > The option rom scan and execution allows the bios code to call out to > additional system roms. The "post" stage runs in 32bit mode, but the > option roms are called in 16bit mode - the "legacybios" code simply > transitions to/from 16bit mode to make these calls. The option rom > code is executed natively on the processor. I think this is redundant with coreboot, since coreboot will also run pci rom, eg. vga bios. > > The "pci init" code looks to be redundant with what coreboot already > provides. The code in "legacybios" seems to be intel > northbride/soutbridge specific. yes, these code could be omitted when used with coreboot. > Some old DOS programs make assumptions about specific memory locations > in the first 1Meg of ram. The "legacybios" code fills in these areas > to make these old programs happy - in short they are the "bios data > area" at 0x00000 - 0x00500, the "extended bios data area" at 0x9fc00 - > 0xa0000, and some hardcoded locations in the 0xf0000 bios segment > itself. The bios working storage areas (in bda and ebda) and the > 16bit interrupt vector table is also setup (part of the bda). I think this is necessary. > It is not clear to me how much of the acpi/mptable/smbios code is > reusable on real hardware. It is possible that most of the info in > these tables is irrelevant, and the "legacybios" code may therefore be > a good starting point. However, it may also be simpler to have > coreboot just pass these tables in. I don't think the acpi/mptable is reusable on real hardware, so have coreboot pass these tables in is better since coreboot developer should have a better understanding about the mainboard he/she is developing. > Some of the hardware accesses made by the "legacybios" code appear to > be specific to hardware in the emulator. The code attempts to enable > ram shadowing of the memory segment at 0xf00000 - it does this so that > it can put acpi/mptable/smbios tables into that area. After it is > complete, it attempts to disable writes to that region. The code > sequence looks to be specific to intel north/southbridges. It isn't > necessary to disable writes to 0xf0000 (though it would be nice), but > it is necessary to have the ability to alter that memory. This shadowing job should be left to coreboot, if someone is going to use legacybios, he should take care of this shadowing job in ram init code. I've written a loader for coreboot-v2 to load legacybios, it works well when used with qemu, I've booted freebsd with it. But on real hardware, via epia-cn, it hangs with a blank screen, the debug port value is 0x31, I'll take some time to see what's going wrong. I add a header for legacybios to become a payload, this is done by a utility createpayload. I've attached the loader and the utility. Signed-off-by: Aaron Lwe <aaron.lwe(a)gmail.com> Thanks,

6 17

simnow
by ron minnich 12 May '08

12 May '08

setting a breakpoint: Help says this: bx <address> [pass count] So I do this: bx 0x110000 And it says: usage: bx [pass count] or some such. Marc, how to set break point? ron

3 4

r3300 - trunk/util/flashrom
by svn＠coreboot.org 12 May '08

12 May '08

Author: hailfinger Date: 2008-05-12 23:19:53 +0200 (Mon, 12 May 2008) New Revision: 3300 Modified: trunk/util/flashrom/flash.h trunk/util/flashrom/flashchips.c Log: MX25L3205 and W25x40 have been confirmed to probe/read/erase/write OK by Harald Gutmann. SST39VF040 has been confirmed to probe OK by misi e. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2008-05-12 14:25:31 UTC (rev 3299) +++ trunk/util/flashrom/flash.h 2008-05-12 21:19:53 UTC (rev 3300) @@ -66,6 +66,7 @@ #define TEST_OK_READ (1<<1) #define TEST_OK_ERASE (1<<2) #define TEST_OK_WRITE (1<<3) +#define TEST_OK_PREW (TEST_OK_PROBE|TEST_OK_READ|TEST_OK_ERASE|TEST_OK_WRITE) #define TEST_OK_MASK 0x0f #define TEST_BAD_PROBE (1<<4) Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2008-05-12 14:25:31 UTC (rev 3299) +++ trunk/util/flashrom/flashchips.c 2008-05-12 21:19:53 UTC (rev 3300) @@ -49,7 +49,7 @@ {"Fujitsu", "MBM29F400TC", FUJITSU_ID, MBM29F400TC_STRANGE, 512, 64 * 1024, TEST_UNTESTED, probe_m29f400bt, erase_m29f400bt, write_coreboot_m29f400bt}, {"Intel", "82802AB", INTEL_ID, 173, 512, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, {"Intel", "82802AC", INTEL_ID, 172, 1024, 64 * 1024, TEST_UNTESTED, probe_82802ab, erase_82802ab, write_82802ab}, - {"Macronix", "MX25L3205", MX_ID, MX_25L3205, 4096, 256, TEST_UNTESTED, probe_spi, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, + {"Macronix", "MX25L3205", MX_ID, MX_25L3205, 4096, 256, TEST_OK_PREW, probe_spi, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, {"Macronix", "MX25L4005", MX_ID, MX_25L4005, 512, 256, TEST_UNTESTED, probe_spi, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, {"Macronix", "MX25L8005", MX_ID, MX_25L8005, 1024, 256, TEST_UNTESTED, probe_spi, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, {"Macronix", "MX29F002", MX_ID, MX_29F002, 256, 64 * 1024, TEST_UNTESTED, probe_29f002, erase_29f002, write_29f002}, @@ -76,7 +76,7 @@ {"SST", "SST39VF512", SST_ID, SST_39VF512, 64, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, {"SST", "SST39VF010", SST_ID, SST_39VF010, 128, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, {"SST", "SST39VF020", SST_ID, SST_39VF020, 256, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, - {"SST", "SST39VF040", SST_ID, SST_39VF040, 512, 4096, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_39sf020}, + {"SST", "SST39VF040", SST_ID, SST_39VF040, 512, 4096, TEST_OK_PROBE, probe_jedec, erase_chip_jedec, write_39sf020}, // assume similar to 004B, ignoring data sheet {"SST", "SST49LF002A/B", SST_ID, SST_49LF002A, 256, 16 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, {"SST", "SST49LF003A/B", SST_ID, SST_49LF003A, 384, 64 * 1024, TEST_UNTESTED, probe_sst_fwhub, erase_sst_fwhub, write_sst_fwhub}, @@ -119,7 +119,7 @@ {"SyncMOS", "S29C51004T", SYNCMOS_ID, S29C51004T, 512, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_49f002}, {"Winbond", "W25x10", WINBOND_NEX_ID, W_25X10, 128, 256, TEST_UNTESTED, probe_spi, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, {"Winbond", "W25x20", WINBOND_NEX_ID, W_25X20, 256, 256, TEST_UNTESTED, probe_spi, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, - {"Winbond", "W25x40", WINBOND_NEX_ID, W_25X40, 512, 256, TEST_UNTESTED, probe_spi, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, + {"Winbond", "W25x40", WINBOND_NEX_ID, W_25X40, 512, 256, TEST_OK_PREW, probe_spi, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, {"Winbond", "W25x80", WINBOND_NEX_ID, W_25X80, 1024, 256, TEST_UNTESTED, probe_spi, spi_chip_erase_c7, spi_chip_write, spi_chip_read}, {"Winbond", "W29C011", WINBOND_ID, W_29C011, 128, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec}, {"Winbond", "W29C020C", WINBOND_ID, W_29C020C, 256, 128, TEST_UNTESTED, probe_jedec, erase_chip_jedec, write_jedec},

1 0

Re: [coreboot] sony vaio pcg sr1k
by Carl-Daniel Hailfinger 12 May '08

12 May '08

On 11.05.2008 14:51, misi e wrote: > woooou... thanks... you guys are quite responsive.... > You're welcome. The patch has been checked in, can you retry? > if it helps you I have another 440BX/ZX/DX based old machine, I could send > you output and test for you. > That would be cool. Regards, Carl-Daniel

2 3

Question about mailing list..
by Marc Karasek 12 May '08

12 May '08

What or who is coreboot-bounces(a)coreboot.org? It is responsible for my multiple emails per posting. I receive one from the poster and one from this email address. Anyone know how to turn this off, get it to stop sending me duplicate emails?? -- ********************* Marc Karasek MTS Sun Microsystems mailto:marc.karasek@sun.com ph:770.360.6415 *********************

2 1

[RFC] flashrom: Add feature bitfield
by Carl-Daniel Hailfinger 12 May '08

12 May '08

Hi, SPI flash on some chipsets (ICH9 and others) poses a real challenge: There are multiple write and erase commands, but each flash chip may support only a subset of them and each chipset may also only support a subset due to in-chipset command filtering. With our current approach (hardcoding erase commands etc.) a command may fail because it is not in the common subset although there would be an equivalent command in the common subset. I'd like to introduce another field into struct flashchip: u32 flags. flags would hold a bit for every supported (and important) opcode and one bit for every variant of a supported opcode. Example follows: #define SPIFLAG_CHIP_ERASE_60 (1<<0) #define SPIFLAG_CHIP_ERASE_C7 (1<<1) #define SPIFLAG_BLOCK_ERASE_52 (1<<2) #define SPIFLAG_BLOCK_ERASE_D8 (1<<3) #define SPIFLAG_SECTOR_ERASE_20 (1<<4) #define SPIFLAG_BYTE_PROGRAM_BYTE (1<<16) //only one byte per command #define SPIFLAG_BYTE_PROGRAM_PAGE (1<<17) //256 bytes per command We could fill in this bitfield for chipset drivers as well and use only those commands/variants which are set in the bitwise AND of supported chip+chipset commands. Regards, Carl-Daniel

3 4

← Newer
1
...
23
24
25
26
27
28
29
...
39
Older →

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 May 2008