coreboot October 2007

coreboot@coreboot.org

84 participants
481 discussions

[LinuxBIOS] filo and v3
by ron minnich 02 Oct '07

02 Oct '07

here is all I get: FILO version 0.5 (rminnich@xcpu) Tue Oct 2 08:19:34 PDT 2007 Can't get memory map from firmware. Using hardcoded default. This is a fresh checkout as of this morning, both v3 and filo. This did used to work. GRUB or not grub makes no difference. DEBUG_ALL=1 ron

2 4

[LinuxBIOS] r36 - in trunk/filo-0.5: i386 main
by svn＠openbios.org 02 Oct '07

02 Oct '07

Author: rminnich Date: 2007-10-02 19:04:57 +0200 (Tue, 02 Oct 2007) New Revision: 36 Modified: trunk/filo-0.5/i386/sys_info.c trunk/filo-0.5/main/linuxbios.c Log: 1. fix spelling error. 2. paranoid setting of info->memrange to 0 3. don't use malloc when it is not possible to use malloc. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/filo-0.5/i386/sys_info.c =================================================================== --- trunk/filo-0.5/i386/sys_info.c 2007-09-23 22:33:38 UTC (rev 35) +++ trunk/filo-0.5/i386/sys_info.c 2007-10-02 17:04:57 UTC (rev 36) @@ -11,6 +11,8 @@ { int i; unsigned long long total = 0; + /* this fake memory range covers the case that we can't find any LB structs. */ + static struct memrange fakememrange[2]; /* Pick up paramters given by bootloader to us */ info->boot_type = boot_ctx->eax; @@ -30,7 +32,12 @@ printf("Can't get memory map from firmware. " "Using hardcoded default.\n"); info->n_memranges = 2; - info->memrange = malloc(2 * sizeof(struct memrange)); + /* NOTE: DO NOT USE MALLOC HERE * + * malloc structs are not initialized until this information is filled in. + * Use of malloc will create a circular dependency. So use + * the static allocated above. + */ + info->memrange = fakememrange; info->memrange[0].base = 0; info->memrange[0].size = 640*1024; info->memrange[1].base = 1024*1024; Modified: trunk/filo-0.5/main/linuxbios.c =================================================================== --- trunk/filo-0.5/main/linuxbios.c 2007-09-23 22:33:38 UTC (rev 35) +++ trunk/filo-0.5/main/linuxbios.c 2007-10-02 17:04:57 UTC (rev 36) @@ -89,7 +89,7 @@ } if (head->header_bytes != sizeof(*head)) continue; - debug("Found canidate at: %p\n", head); + debug("Found candidate at: %p\n", head); if (ipchksum((uint16_t *)head, sizeof(*head)) != 0) continue; debug("header checksum o.k.\n"); @@ -114,6 +114,7 @@ struct lb_header *lb_table; int found; debug("Searching for LinuxBIOS tables...\n"); + info->memrange = NULL; found = 0; if (!found) { found = find_lb_table(phys_to_virt(0x00000), phys_to_virt(0x01000), &lb_table);

1 0

[LinuxBIOS] FILO
by ron minnich 02 Oct '07

02 Oct '07

ok, with the fixes I sent, and latest v3, filo works fine on bochs, fails on qemu. hmm :-) ron

1 0

Re: [LinuxBIOS] Two more CS5530 IRQ steering questions
by Jonathan Sturges 02 Oct '07

02 Oct '07

----- Original Message ---- From: Marc Jones <marc.jones(a)amd.com> To: Jonathan Sturges <jonathansturges(a)yahoo.com> Cc: LinuxBIOS mailing list <linuxbios(a)linuxbios.org> Sent: Tuesday, September 25, 2007 12:05:19 PM Subject: Re: [LinuxBIOS] Two more CS5530 IRQ steering questions Jonathan Sturges wrote: >>> Jonathan Sturges wrote: >>> Two additional questions about CS5530 IRQ steering: >>> 1) Comments from Uwe Hermann and Peter Stuge have indicated that it's really better for the kernel to setup the steering registers. Why is this? It sounds like the BIOS is a good place to set these. I assume that a knowledgeable OS could change them if necessary? At the very least, it does sound like we all agree that it's OK to have LB setup the steering until Linux is fixed. >>> >>> 2) Question about irq_tables.c. Many of the CS5536 systems have a write_pirq_routing_table() in irq_tables.c that sets the steering registers. I'd like to be able to set the steering registers in CS5530 systems too, but I'm not a software developer and I need some help. So in src/mainboard/artecgroup/dbe61/irq_tables.c, you have: >>> /* Set up chipset IRQ steering. */ >>> pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C; >>> chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA); >>> printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr, >>> chipset_irq_map); >>> outl(pciAddr & ~3, 0xCF8); >>> outl(chipset_irq_map, 0xCFC);My main question with this block of code is what the two outl() calls are for. It looks like pciAddr gets the address of the 0x5c steering register, and chipset_irq_map sets the right bits to set all 4 PIRQ lines. But I'd expect to see the chipset_irq_map written to pciAddr. >>> >>> As an alternative, Kenji Noguchi used this code block to set the registers in a CS5530 system he's working on (posted 5-May-2007): >>> device_t pdev; >>> //CS5530A >>> pdev = dev_find_slot(0, (0x12 << 3) + 0); >>> pci_write_config8(pdev, 0x5c, 0xab); >>> pci_write_config8(pdev, 0x5d, 0x09); >>> >>> >>> This block makes more sense to me. Obviously the register values could be set by >>> #defines, but it looks simpler to me. >>> >>> Bottom line is, before I implement IRQ steering for my CS5530 system, I want to understand what the first code block is doing, and if (or why) it's preferable over the 2nd code block. Any guidance is appreciated. >>> >>> thanks, >>> Jonathan >> >> >> outl(pciAddr & ~3, 0xCF8); >> outl(chipset_irq_map, 0xCFC) >> >> is basically the same as >> >> pci_write_config8(pdev, 0x5c, 0xab); >> pci_write_config8(pdev, 0x5d, 0x09); >> >> >> CFC/CF8 is the PCI config space. > > Ahhh... thanks Marc, that was the clarification I needed. > > With that in mind, that block of code should work directly with the CS5530 after defining CHIPSET_DEV_NUM appropriately. What about '0x80000000', is that a common base address applicable to all CS553x systems? > > thanks, > Jonathan DEV_NUM should be a constant for the 5530. It is always hooked up on the same IDSEL. The 0x80000000 is standard for all i/o based PCI config accesses. It indicates that it is a config access and not just a normal PCI i/o access. Marc Marc, I've implemented the CS5536-style IRQ steering register code from above in my CS5530 system. This is what I'm using: /* Set up chipset IRQ steering. */ pciAddr = 0x80000000 | (0x12 << 11) | 0x5C; chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA); printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr, chipset_irq_map); outl(pciAddr & ~3, 0xCF8); outl(chipset_irq_map, 0xCFC); However, it doesn't seem to have worked entirely. If it had worked, I assume I should be able to boot a standard Linux kernel and have IRQs worked for the devices in the PIRQ table. Instead, these devices don't work, unless I boot a kernel with the CS5530 IRQ router patch. In the LB output, you get this from write_pirq_routing_table(): write_pirq_routing_table(8000905C, 99BA) ...which I think is right. It doesn't seem like there's much that could be wrong here. Are the the steering bits reversed maybe? The high 8 bits are for PIRQD and C, so that would screw things up if they were written to 0x5C, which is the INTB/INTA register. Is there a reliable way to see the settings of the steering bits from a running system? thanks, Jonathan ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow

2 1

[LinuxBIOS] r2817 build service
by LinuxBIOS information 02 Oct '07

02 Oct '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "ward" checked in revision 2817 to the LinuxBIOS source repository and caused the following changes: Change Log: This patch aims to restructure SPI flash support in a more reasonable way. It introduces a generic SPI host driver for the IT8716F Super I/O which will enable easy SPI programming without having to care for the peculiarities of the SPI host. To activate probing for the IT8716F, you have to use the gigabyte:m57sli mainboard override. SPI support will then use the gathered SPI host data to access the SPI flash. This has been tested sucessfully by Ward Vandewege <ward(a)gnu.org> on the GA-M57SLI v2.0, which has a MX25L4005 SPI flash part. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Ward Vandewege <ward(a)gnu.org> Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=hdama&vendor=… Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=e325&vendor=i… Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=e326&vendor=i… Compilation of iei:juki-511p is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=juki-511p&ven… Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=dk8s2&vendor=… Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=dk8x&vendor=i… Compilation of newisys:khepri is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2817&device=khepri&vendor… If something broke during this checkin please be a pain in ward's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, LinuxBIOS automatic build system

1 0

[LinuxBIOS] r2817 - trunk/util/flashrom
by svn＠openbios.org 02 Oct '07

02 Oct '07

Author: ward Date: 2007-10-02 17:49:25 +0200 (Tue, 02 Oct 2007) New Revision: 2817 Modified: trunk/util/flashrom/board_enable.c trunk/util/flashrom/flash.h trunk/util/flashrom/flashchips.c Log: This patch aims to restructure SPI flash support in a more reasonable way. It introduces a generic SPI host driver for the IT8716F Super I/O which will enable easy SPI programming without having to care for the peculiarities of the SPI host. To activate probing for the IT8716F, you have to use the gigabyte:m57sli mainboard override. SPI support will then use the gathered SPI host data to access the SPI flash. This has been tested sucessfully by Ward Vandewege <ward(a)gnu.org> on the GA-M57SLI v2.0, which has a MX25L4005 SPI flash part. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Ward Vandewege <ward(a)gnu.org> Modified: trunk/util/flashrom/board_enable.c =================================================================== --- trunk/util/flashrom/board_enable.c 2007-10-01 18:32:00 UTC (rev 2816) +++ trunk/util/flashrom/board_enable.c 2007-10-02 15:49:25 UTC (rev 2817) @@ -30,6 +30,15 @@ #include <string.h> #include "flash.h" +#define ITE_SUPERIO_PORT1 0x2e +#define ITE_SUPERIO_PORT2 0x4e + +#define JEDEC_RDID {0x9f} +#define JEDEC_RDID_OUTSIZE 0x01 +#define JEDEC_RDID_INSIZE 0x03 + +static uint16_t it8716f_flashport = 0; + /* Generic Super I/O helper functions */ uint8_t regval(uint16_t port, uint8_t reg) { @@ -51,7 +60,7 @@ outb(0x87, port); outb(0x01, port); outb(0x55, port); - if (port == 0x2e) + if (port == ITE_SUPERIO_PORT1) outb(0x55, port); else outb(0xaa, port); @@ -96,35 +105,97 @@ return flashport; } -static void it8716_serial_rdid(uint16_t port) +/* The IT8716F only supports commands with length 1,2,4,5 bytes including + command byte and can not read more than 3 bytes from the device. + This function expects writearr[0] to be the first byte sent to the device, + whereas the IT8716F splits commands internally into address and non-address + commands with the address in inverse wire order. That's why the register + ordering in case 4 and 5 may seem strange. */ +static int it8716f_spi_command(uint16_t port, unsigned char writecnt, unsigned char readcnt, const unsigned char *writearr, unsigned char *readarr) { - uint8_t busy, data0, data1, data2; + uint8_t busy, writeenc; do { busy = inb(port) & 0x80; } while (busy); - /* RDID */ - outb(0x9f, port + 1); - /* Start IO, 33MHz, 3 input bytes, 0 output bytes*/ - outb((0x5<<4)|(0x3<<2)|(0x0), port); + if (readcnt > 3) { + printf("%s called with unsupported readcnt %i\n", + __FUNCTION__, readcnt); + return 1; + } + switch (writecnt) { + case 1: + outb(writearr[0], port + 1); + writeenc = 0x0; + break; + case 2: + outb(writearr[0], port + 1); + outb(writearr[1], port + 7); + writeenc = 0x1; + break; + case 4: + outb(writearr[0], port + 1); + outb(writearr[1], port + 4); + outb(writearr[2], port + 3); + outb(writearr[3], port + 2); + writeenc = 0x2; + break; + case 5: + outb(writearr[0], port + 1); + outb(writearr[1], port + 4); + outb(writearr[2], port + 3); + outb(writearr[3], port + 2); + outb(writearr[4], port + 7); + writeenc = 0x3; + break; + default: + printf("%s called with unsupported writecnt %i\n", + __FUNCTION__, writecnt); + return 1; + } + /* Start IO, 33MHz, readcnt input bytes, writecnt output bytes. Note: + We can't use writecnt directly, but have to use a strange encoding */ + outb((0x5 << 4) | ((readcnt & 0x3) << 2) | (writeenc), port); do { busy = inb(port) & 0x80; } while (busy); - data0 = inb(port + 5); - data1 = inb(port + 6); - data2 = inb(port + 7); - printf("RDID returned %02x %02x %02x\n", data0, data1, data2); - return; + readarr[0] = inb(port + 5); + readarr[1] = inb(port + 6); + readarr[2] = inb(port + 7); + return 0; } +static int it8716f_serial_rdid(uint16_t port, unsigned char *readarr) +{ + const unsigned char cmd[] = JEDEC_RDID; + + if (it8716f_spi_command(port, JEDEC_RDID_OUTSIZE, JEDEC_RDID_INSIZE, cmd, readarr)) + return 1; + printf("RDID returned %02x %02x %02x\n", readarr[0], readarr[1], readarr[2]); + return 0; +} + static int it87xx_probe_serial_flash(const char *name) { - uint16_t flashport; - flashport = find_ite_serial_flash_port(0x2e); - if (flashport) - it8716_serial_rdid(flashport); - flashport = find_ite_serial_flash_port(0x4e); - if (flashport) - it8716_serial_rdid(flashport); + it8716f_flashport = find_ite_serial_flash_port(ITE_SUPERIO_PORT1); + if (!it8716f_flashport) + it8716f_flashport = find_ite_serial_flash_port(ITE_SUPERIO_PORT2); + return (!it8716f_flashport); +} + +int probe_spi(struct flashchip *flash) +{ + unsigned char readarr[3]; + uint8_t manuf_id; + uint16_t model_id; + if (it8716f_flashport) { + it8716f_serial_rdid(it8716f_flashport, readarr); + manuf_id = readarr[0]; + model_id = (readarr[1] << 8) | readarr[2]; + printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, model_id); + if (manuf_id == flash->manufacture_id && model_id == flash->model_id) + return 1; + } + return 0; } Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2007-10-01 18:32:00 UTC (rev 2816) +++ trunk/util/flashrom/flash.h 2007-10-02 15:49:25 UTC (rev 2817) @@ -55,6 +55,8 @@ /* Please keep this list sorted alphabetically by manufacturer. The first * entry of each section should be the manufacturer ID, followed by the * list of devices from that manufacturer (sorted by device IDs). + * All LPC/FWH parts (parallel flash) have 8-bit device IDs. + * All SPI parts have 16-bit device IDs. */ #define AMD_ID 0x01 /* AMD */ @@ -68,8 +70,31 @@ #define AT_29C040A 0xA4 #define AT_29C020 0xDA +#define EON_ID 0x1C +/* EN25 chips are SPI, first byte of device id is memory type, + second byte of device id is log(bitsize)-9 */ +#define EN_25B05 0x2010 /* 2^19 kbit or 2^16 kByte */ +#define EN_25B10 0x2011 +#define EN_25B20 0x2012 +#define EN_25B40 0x2013 +#define EN_25B80 0x2014 +#define EN_25B16 0x2015 +#define EN_25B32 0x2016 + #define MX_ID 0xC2 /* Macronix (MX) */ #define MX_29F002 0xB0 +/* MX25L chips are SPI, first byte of device id is memory type, + second byte of device id is log(bitsize)-9 */ +#define MX_25L512 0x2010 /* 2^19 kbit or 2^16 kByte */ +#define MX_25L1005 0x2011 +#define MX_25L2005 0x2012 +#define MX_25L4005 0x2013 /* MX25L4005{,A} */ +#define MX_25L8005 0x2014 +#define MX_25L1605 0x2015 /* MX25L1605{,A,D} */ +#define MX_25L3205 0x2016 /* MX25L3205{,A} */ +#define MX_25L6405 0x2017 /* MX25L3205{,D} */ +#define MX_25L1635D 0x2415 +#define MX_25L3235D 0x2416 #define SHARP_ID 0xB0 /* Sharp */ #define SHARP_LHF00L04 0xCF @@ -182,6 +207,8 @@ int linuxbios_init(void); extern char *lb_part, *lb_vendor; +int probe_spi(struct flashchip *flash); + /* 82802ab.c */ int probe_82802ab(struct flashchip *flash); int erase_82802ab(struct flashchip *flash); Modified: trunk/util/flashrom/flashchips.c =================================================================== --- trunk/util/flashrom/flashchips.c 2007-10-01 18:32:00 UTC (rev 2816) +++ trunk/util/flashrom/flashchips.c 2007-10-02 15:49:25 UTC (rev 2817) @@ -38,6 +38,8 @@ probe_jedec, erase_chip_jedec, write_jedec}, {"Mx29f002", MX_ID, MX_29F002, 256, 64 * 1024, probe_29f002, erase_29f002, write_29f002}, + {"MX25L4005", MX_ID, MX_25L4005, 512, 4 * 1024, + probe_spi, NULL, NULL}, {"SST29EE020A", SST_ID, SST_29EE020A, 256, 128, probe_jedec, erase_chip_jedec, write_jedec}, {"SST28SF040A", SST_ID, SST_28SF040, 512, 256,

1 0

[LinuxBIOS] linuxbios support for thinkpads?
by Robinson Tryon 02 Oct '07

02 Oct '07

Hiya, I'm in the market for a new laptop on which to run Ubuntu, and Lenovo's Thinkpads look like a good choice. I like the idea of running an open BIOS, but looking at past posts to the mailing list, it appears that certain chipsets (such as those for the T60) are not supported: http://article.gmane.org/gmane.linux.bios/19651 I believe that certain (older) Thinkpad chipsets are supported, but what about the 945 or the 965 (for the T61) ? The "Supported Chipsets" page (below) hasn't had any updates in a couple of months -- is that the best place for me to determine if Linux BIOS is compatible with a particular chipset/system? http://linuxbios.org/index.php/Supported_Chipsets_and_Devices Thanks, -- Robinson

4 10

[LinuxBIOS] Enabling APIC 82801xx
by joe＠smittys.pointclark.net 02 Oct '07

02 Oct '07

OK, I have a new booting problem. LB dies on the i82801xx_enable_ioapic() function in 82801xx_lpc.c: void i82801xx_enable_ioapic(struct device *dev) { uint32_t reg32; volatile uint32_t *ioapic_index = (volatile uint32_t *)0xfec00000; volatile uint32_t *ioapic_data = (volatile uint32_t *)0xfec00010; reg32 = pci_read_config32(dev, GEN_CNTL); reg32 |= (3 << 7); /* Enable IOAPIC */ reg32 |= (1 << 13); /* Coprocessor error enable */ reg32 |= (1 << 1); /* Delayed transaction enable */ reg32 |= (1 << 2); /* DMA collection buffer enable */ pci_write_config32(dev, GEN_CNTL, reg32); printk_debug("IOAPIC Southbridge enabled %x\n", reg32); *ioapic_index = 0; *ioapic_data = (1 << 25); *ioapic_index = 0; reg32 = *ioapic_data; printk_debug("Southbridge APIC ID = %x\n", reg32); if (reg32 != (1 << 25)) die("APIC Error\n"); /* TODO: From i82801ca, needed/useful on other ICH? */ *ioapic_index = 3; // Select Boot Configuration register *ioapic_data = 1; // Use Processor System Bus to deliver interrupts } Initializing devices... Root Device init PCI: 00:00.0 init Northbridge init PCI: 00:1d.0 init PCI: 00:1d.1 init PCI: 00:1d.2 init PCI: 00:1d.7 init EHCI: Setting up controller.. done. PCI: 00:1e.0 init PCI: 00:1f.0 init IOAPIC Southbridge enabled 2186 Southbridge APIC ID = 0 APIC Error What is going on here? Why is *ioapic_data coming back as 0x0 after it has been set to 0x2000000 (1 << 25)? Help? Thanks - Joe

4 9

[LinuxBIOS] filo, qemu, v3
by ron minnich 02 Oct '07

02 Oct '07

I'm having poor luck with the latest v3 release, qemu, and filo. Any hints here? I have been away for a bit. I'm going to bite the bullet and try to get geode going, finally. ron

2 1

[LinuxBIOS] successfully flashed Asus M2A-VM,
by Rodney Crossman 01 Oct '07

01 Oct '07

just an fyi that I successfully flashed the bios on an Asus M2A-VM motherboard which has an amd 690G chipset. System has been power cycled and all is working. Thank you all for providing this extremely useful tool. # ./flashrom -wv m2a1301.bin Calibrating delay loop... ok No LinuxBIOS table found. WARNING: No chipset found. Flash detection will most likely fail. SST49LF080A found at physical address: 0xfff00000 Flash part is SST49LF080A (1024 KB) Flash image seems to be a legacy BIOS. Disabling checks. Programming Page: 0255 at address: 0x000ff000 Verifying flash - VERIFIED Rodney All outgoing messages have been checked for viruses by Etrust Antivirus.

3 2

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 October 2007