coreboot September 2007

coreboot@coreboot.org

81 participants
367 discussions

[LinuxBIOS] r2782 - trunk/util/superiotool
by svn＠openbios.org 18 Sep '07

18 Sep '07

Author: uwe Date: 2007-09-19 01:30:24 +0200 (Wed, 19 Sep 2007) New Revision: 2782 Modified: trunk/util/superiotool/Makefile trunk/util/superiotool/smsc.c trunk/util/superiotool/superiotool.c trunk/util/superiotool/superiotool.h Log: Make the code a bit more generic (trivial). Different Super I/Os use different config ports. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/util/superiotool/Makefile =================================================================== --- trunk/util/superiotool/Makefile 2007-09-18 22:24:34 UTC (rev 2781) +++ trunk/util/superiotool/Makefile 2007-09-18 23:30:24 UTC (rev 2782) @@ -32,7 +32,7 @@ all: $(PROGRAM) -$(PROGRAM): $(OBJS) +$(PROGRAM): $(OBJS) superiotool.h $(CC) $(CFLAGS) -o $(PROGRAM) $(OBJS) install: $(PROGRAM) Modified: trunk/util/superiotool/smsc.c =================================================================== --- trunk/util/superiotool/smsc.c 2007-09-18 22:24:34 UTC (rev 2781) +++ trunk/util/superiotool/smsc.c 2007-09-18 23:30:24 UTC (rev 2782) @@ -53,7 +53,7 @@ } } -void probe_idregs_smsc(uint32_t port) +void probe_idregs_smsc(unsigned short port) { uint16_t id, rev; Modified: trunk/util/superiotool/superiotool.c =================================================================== --- trunk/util/superiotool/superiotool.c 2007-09-18 22:24:34 UTC (rev 2781) +++ trunk/util/superiotool/superiotool.c 2007-09-18 23:30:24 UTC (rev 2782) @@ -97,22 +97,18 @@ int main(int argc, char *argv[]) { + int i, j; + if (iopl(3) < 0) { perror("iopl"); exit(1); } - probe_idregs_simple(0x2e); - probe_idregs_simple(0x4e); + for (i = 0; i < ARRAY_SIZE(superio_ports_table); i++) { + for (j = 0; superio_ports_table[i].ports[j] != EOT; j++) + superio_ports_table[i].probe_idregs( + superio_ports_table[i].ports[j]); + } - probe_idregs_fintek(0x2e); - probe_idregs_fintek(0x4e); - - probe_idregs_ite(0x2e); - probe_idregs_ite(0x4e); - - probe_idregs_smsc(0x3f0); - probe_idregs_smsc(0x370); - return 0; } Modified: trunk/util/superiotool/superiotool.h =================================================================== --- trunk/util/superiotool/superiotool.h 2007-09-18 22:24:34 UTC (rev 2781) +++ trunk/util/superiotool/superiotool.h 2007-09-18 23:30:24 UTC (rev 2782) @@ -27,6 +27,8 @@ #include <stdint.h> #include <sys/io.h> +#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0])) + #define EOT -1 /* End Of Table */ #define NOLDN -2 /* NO LDN needed */ #define NANA -3 /* Not Available */ @@ -36,6 +38,7 @@ #define LDNSIZE (MAXLDN + 3) /* Biggest LDN + 0 + NOLDN + EOT */ #define MAXNUMIDX 70 /* Maximum number of indexes */ #define IDXSIZE (MAXNUMIDX + 1) +#define MAXNUMPORTS (2 + 1) /* Maximum number of Super I/O ports */ struct superio_registers { /* Yes, superio_id should be unsigned, but EOT has to be negative. */ @@ -69,6 +72,17 @@ /* smsc.c */ void dump_smsc(uint32_t port, uint32_t id); -void probe_idregs_smsc(uint32_t port); +void probe_idregs_smsc(unsigned short port); +/** Table of which config ports to probe on each Super I/O. */ +const static struct { + void (*probe_idregs) (unsigned short port); + signed short ports[MAXNUMPORTS]; /* Signed, as we need EOT. */ +} superio_ports_table[] = { + {probe_idregs_simple, {0x2e, 0x4e, EOT}}, + {probe_idregs_fintek, {0x2e, 0x4e, EOT}}, + {probe_idregs_ite, {0x2e, 0x4e, EOT}}, + {probe_idregs_smsc, {0x3f0, 0x370, EOT}}, +}; + #endif

1 0

[LinuxBIOS] r2781 build service
by LinuxBIOS information 18 Sep '07

18 Sep '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2781 to the LinuxBIOS source repository and caused the following changes: Change Log: Superiotool: Add support for the SMSC FDC37N769. Here's what a register dump looks like on my test system: No Super I/O chip found at 0x002e No Super I/O chip found at 0x004e No Super I/O chip found at 0x002e No Super I/O chip found at 0x004e No Super I/O chip found at 0x002e No Super I/O chip found at 0x004e Super I/O found at 0x03f0: id=0x28, rev=0x01 SMSC FDC37N769 idx 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f val 20 90 80 f4 00 00 ff 00 00 00 40 00 0e 28 01 00 00 00 00 00 02 00 01 03 00 00 00 00 00 00 80 00 00 00 00 00 00 ba 00 00 03 00 00 23 03 03 00 00 def 28 9c 88 70 00 00 ff 00 00 00 00 00 02 28 NA 00 00 80 RR RR NA NA NA 03 RR RR RR RR RR RR 80 00 3c RR RR 00 00 00 00 00 00 00 RR 00 00 03 00 00 Probing 0x0370, failed (0xff), data returns 0xff I'm self-acking this as it's pretty simple stuff, but please let me know if anything could be improved here, or if you think this is not trivial enough to warrant self-acking. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2781&device=hdama&vendor=… Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2781&device=e325&vendor=i… Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2781&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=2781&device=juki-511p&ven… Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2781&device=dk8s2&vendor=… Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2781&device=dk8x&vendor=i… Compilation of newisys:khepri is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2781&device=khepri&vendor… 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, LinuxBIOS automatic build system

1 0

[LinuxBIOS] r2781 - trunk/util/superiotool
by svn＠openbios.org 18 Sep '07

18 Sep '07

Author: uwe Date: 2007-09-19 00:24:34 +0200 (Wed, 19 Sep 2007) New Revision: 2781 Added: trunk/util/superiotool/smsc.c Modified: trunk/util/superiotool/Makefile trunk/util/superiotool/superiotool.c trunk/util/superiotool/superiotool.h Log: Superiotool: Add support for the SMSC FDC37N769. Here's what a register dump looks like on my test system: No Super I/O chip found at 0x002e No Super I/O chip found at 0x004e No Super I/O chip found at 0x002e No Super I/O chip found at 0x004e No Super I/O chip found at 0x002e No Super I/O chip found at 0x004e Super I/O found at 0x03f0: id=0x28, rev=0x01 SMSC FDC37N769 idx 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f val 20 90 80 f4 00 00 ff 00 00 00 40 00 0e 28 01 00 00 00 00 00 02 00 01 03 00 00 00 00 00 00 80 00 00 00 00 00 00 ba 00 00 03 00 00 23 03 03 00 00 def 28 9c 88 70 00 00 ff 00 00 00 00 00 02 28 NA 00 00 80 RR RR NA NA NA 03 RR RR RR RR RR RR 80 00 3c RR RR 00 00 00 00 00 00 00 RR 00 00 03 00 00 Probing 0x0370, failed (0xff), data returns 0xff I'm self-acking this as it's pretty simple stuff, but please let me know if anything could be improved here, or if you think this is not trivial enough to warrant self-acking. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/util/superiotool/Makefile =================================================================== --- trunk/util/superiotool/Makefile 2007-09-18 00:01:27 UTC (rev 2780) +++ trunk/util/superiotool/Makefile 2007-09-18 22:24:34 UTC (rev 2781) @@ -28,7 +28,7 @@ CFLAGS = -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing \ -Werror-implicit-function-declaration -OBJS = fintek.o ite.o nsc.o superiotool.o +OBJS = superiotool.o fintek.o ite.o nsc.o smsc.o all: $(PROGRAM) Added: trunk/util/superiotool/smsc.c =================================================================== --- trunk/util/superiotool/smsc.c (rev 0) +++ trunk/util/superiotool/smsc.c 2007-09-18 22:24:34 UTC (rev 2781) @@ -0,0 +1,89 @@ +/* + * This file is part of the LinuxBIOS project. + * + * Copyright (C) 2007 Uwe Hermann <uwe(a)hermann-uwe.de> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "superiotool.h" + +#define DEVICE_ID_REG 0x0d +#define DEVICE_REV_REG 0x0e + +const static struct superio_registers reg_table[] = { + {0x28, "FDC37N769", { + {NOLDN, + {0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09, + 0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,0x10,0x11,0x12,0x13, + 0x14,0x15,0x16,0x17,0x18,0x19,0x1a,0x1b,0x1c,0x1d, + 0x1e,0x1f,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27, + 0x28,0x29,0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,EOT}, + {0x28,0x9c,0x88,0x70,0x00,0x00,0xff,0x00,0x00,0x00, + 0x00,0x00,0x02,0x28,NANA,0x00,0x00,0x80,RSVD,RSVD, + NANA,NANA,NANA,0x03,RSVD,RSVD,RSVD,RSVD,RSVD,RSVD, + 0x80,0x00,0x3c,RSVD,RSVD,0x00,0x00,0x00,0x00,0x00, + 0x00,0x00,RSVD,0x00,0x00,0x03,0x00,0x00,EOT}}, + {EOT}}}, + {EOT} +}; + +/* Note: The actual SMSC ID is 16 bits, but we must pass 32 bits here. */ +void dump_smsc(uint32_t port, uint32_t id) +{ + switch (id) { + case 0x28: + dump_superio("SMSC", reg_table, port, id); + break; + default: + printf("Unknown SMSC chip, id=0x%02x\n", id); + break; + } +} + +void probe_idregs_smsc(uint32_t port) +{ + uint16_t id, rev; + + outb(0x55, port); /* Enter configuration mode. */ + + /* Read device ID. */ + id = regval(port, DEVICE_ID_REG); + if (id != 0x28) { /* TODO: Support for other SMSC chips. */ + if (inb(port) != 0xff) + printf("No Super I/O chip found at 0x%04x\n", port); + else + printf("Probing 0x%04x, failed (0x%02x), data returns 0x%02x\n", port, inb(port), inb(port + 1)); + return; + } + + /* Read chip revision. */ + rev = regval(port, DEVICE_REV_REG); + + printf("Super I/O found at 0x%04x: id=0x%02x, rev=0x%02x\n", + port, id, rev); + + switch (id) { + case 0x28: + dump_smsc(port, id); + break; + default: + printf("No dump for ID 0x%04x\n", id); + break; + } + + outb(0xaa, port); /* Exit configuration mode. */ +} + Modified: trunk/util/superiotool/superiotool.c =================================================================== --- trunk/util/superiotool/superiotool.c 2007-09-18 00:01:27 UTC (rev 2780) +++ trunk/util/superiotool/superiotool.c 2007-09-18 22:24:34 UTC (rev 2781) @@ -83,8 +83,10 @@ for (k = 0;; k++) { if (idx[k] == EOT) break; - if (idx[k] == NANA) + else if (idx[k] == NANA) printf("NA "); + else if (idx[k] == RSVD) + printf("RR "); else printf("%02x ", idx[k]); } @@ -93,13 +95,6 @@ } } -void probe_superio(unsigned short port) -{ - probe_idregs_simple(port); - probe_idregs_fintek(port); - probe_idregs_ite(port); -} - int main(int argc, char *argv[]) { if (iopl(3) < 0) { @@ -107,8 +102,17 @@ exit(1); } - probe_superio(0x2e); /* Try 0x2e. */ - probe_superio(0x4e); /* Try 0x4e. */ + probe_idregs_simple(0x2e); + probe_idregs_simple(0x4e); + probe_idregs_fintek(0x2e); + probe_idregs_fintek(0x4e); + + probe_idregs_ite(0x2e); + probe_idregs_ite(0x4e); + + probe_idregs_smsc(0x3f0); + probe_idregs_smsc(0x370); + return 0; } Modified: trunk/util/superiotool/superiotool.h =================================================================== --- trunk/util/superiotool/superiotool.h 2007-09-18 00:01:27 UTC (rev 2780) +++ trunk/util/superiotool/superiotool.h 2007-09-18 22:24:34 UTC (rev 2781) @@ -24,11 +24,13 @@ #include <stdio.h> #include <stdlib.h> +#include <stdint.h> #include <sys/io.h> #define EOT -1 /* End Of Table */ #define NOLDN -2 /* NO LDN needed */ #define NANA -3 /* Not Available */ +#define RSVD -4 /* Reserved */ #define MAXNAMELEN 20 /* Maximum Name Length */ #define MAXLDN 0xa /* Biggest LDN */ #define LDNSIZE (MAXLDN + 3) /* Biggest LDN + 0 + NOLDN + EOT */ @@ -39,7 +41,7 @@ /* Yes, superio_id should be unsigned, but EOT has to be negative. */ signed short superio_id; const char name[MAXNAMELEN]; - struct ite_ldnidx { + struct { signed short ldn; signed short idx[IDXSIZE]; signed short def[IDXSIZE]; @@ -65,4 +67,8 @@ void dump_ns8374(unsigned short port); void probe_idregs_simple(unsigned short port); +/* smsc.c */ +void dump_smsc(uint32_t port, uint32_t id); +void probe_idregs_smsc(uint32_t port); + #endif

1 0

[LinuxBIOS] LinuxBios with SuperIO Winbond W83627HG-AW
by Steffen D. 18 Sep '07

18 Sep '07

Dear Mailinglist, im trying to build a bios for GeodeLX cpu. I have a development board from LogicPC. Afaik this is the same board that was used for the development for OLCP. I try it with the svn version Linuxbios-3. I have made a image with make menuconfig and configured everything cleary for the geodelx board. I flash the rom with windows and a galep 5 flash device. Im very sure that the flashing works because i can clone the bios which comes with the board. I dont get any output over rs232. Im using SST 49LF004B roms with 4mbit. Maybe here is the problem? I have made linuxbios.rom with a target size of 2mb. I also tryed "cat linuxbios.rom linuxbios.rom > linuxbios4m.rom". I found this hin here in the ml. Every help is welcome! Regards, Steffen

3 4

Re: [LinuxBIOS] GA-m57SLI-S4
by ST 18 Sep '07

18 Sep '07

Hi Jerome > Thanks for your documentation on the GA-m57SLI-S4 dual PLCC bios, I was > wondering why you've soldered a PLCC socket rather than the PLCC eeprom > itself? Because if i screw up badly i can plug in a fresh backup plcc and boot again. Not that this happend, but it's like taking an umbrella with you to prevent it from raining :-). ST PS: Please post to linuxbios list so others can find answers to your question also.

1 0

Re: [LinuxBIOS] Missing IRQ table entries; irq_tables.c problem?
by Jonathan Sturges 18 Sep '07

18 Sep '07

My apologies, forgot to update the subject line! >> One thing I'd like to investigate as well is initializing the IRQ router in >> LB. I've seen some discussion about this in the past, and I've come to the >> conclusion that for Geode GX1/CS5530 systems, it should be initialized in >> LB rather than Linux. It also seems like some LB ports do this, and others >> do not. > >Linux does not know the CS5530 as an IRQ router. So it does not change >anything in its registers settings. For this chipset Linux relies on the >BIOS. Or you must patch the kernel. How to make LB fill in the routing >registers with usefull values? > >Juergen Looking at newer Geode targets, some of the CS5536 systems seem to update the IRQ steering registers; see write_pirq_routing_table() in src/mainboard/artecgroup/dbe61/irq_tables.c. I think that block of code could be adapted to the CS5530. Is it pretty much understood that setting the IRQ steering registers within that function is the right place? -Jonathan ____________________________________________________________________________________ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433 ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC

2 1

Re: [LinuxBIOS] Missing IRQ table entries; irq_tables.c problem?
by Jonathan Sturges 18 Sep '07

18 Sep '07

>On Sun, Sep 16, 2007 at 06:56:55PM -0700, Jonathan Sturges wrote: >> Thanks Uwe, >> That was it! I added 'option IRQ_SLOT_COUNT=3' to the Config.lb in the target directory of my board, and >>that did the trick. I now get IRQs assigned to all 3 devices I intended to. Very nice! > >Nice, indeed! Does everything else work on your board? >Either way, please post a patch so we can add it to the repository. Tested: serial port (well, 1 of them, for console of course), IDE, Ethernet, USB OHCI, and Mini-PCI. Untested are VGA and audio (it's a Geode and I haven't dug into using VSA or the alternatives), as well as PS/2 kbd. and mouse. It is extremely stable under Fedora Core 5 and kernel 2.6.20. This winterm is a great embedded system, if you don't need the VGA or audio. It's working well enough to commit to the repository, I just need to read up on how to properly create a new mainboard and target first. One thing I'd like to investigate as well is initializing the IRQ router in LB. I've seen some discussion about this in the past, and I've come to the conclusion that for Geode GX1/CS5530 systems, it should be initialized in LB rather than Linux. It also seems like some LB ports do this, and others do not. Is there an official position on this from the core maintainers? -Jonathan ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/

3 2

Re: [LinuxBIOS] linuxbios Digest, Vol 31, Issue 85
by Jonathan Sturges 18 Sep '07

18 Sep '07

>> One thing I'd like to investigate as well is initializing the IRQ router in >> LB. I've seen some discussion about this in the past, and I've come to the >> conclusion that for Geode GX1/CS5530 systems, it should be initialized in >> LB rather than Linux. It also seems like some LB ports do this, and others >> do not. > >Linux does not know the CS5530 as an IRQ router. So it does not change >anything in its registers settings. For this chipset Linux relies on the >BIOS. Or you must patch the kernel. How to make LB fill in the routing >registers with usefull values? > >Juergen Looking at newer Geode targets, some of the CS5536 systems seem to update the IRQ steering registers; see write_pirq_routing_table() in src/mainboard/artecgroup/dbe61/irq_tables.c. I think that block of code could be adapted to the CS5530. Is it pretty much understood that setting the IRQ steering registers within that function is the right place? -Jonathan ____________________________________________________________________________________ Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list&sid=396545433

1 0

Re: [LinuxBIOS] Missing IRQ table entries; irq_tables.c problem?
by Jonathan Sturges 17 Sep '07

17 Sep '07

Thanks Uwe, That was it! I added 'option IRQ_SLOT_COUNT=3' to the Config.lb in the target directory of my board, and that did the trick. I now get IRQs assigned to all 3 devices I intended to. Very nice! As a side note, I noticed that only 2 boards came with IRQ_SLOT_COUNT in their Config.lb's. Was this option recently made mandatory? If so, we need a sweep to update the LBv2 Config.lb files. thanks! -Jonathan ----- Original Message ---- From: Uwe Hermann <uwe(a)hermann-uwe.de> To: Jonathan Sturges <jonathansturges(a)yahoo.com> Cc: LinuxBIOS mailing list <linuxbios(a)linuxbios.org> Sent: Sunday, September 16, 2007 5:31:13 PM Subject: Re: [LinuxBIOS] Missing IRQ table entries; irq_tables.c problem? On Sun, Sep 16, 2007 at 12:31:09PM -0700, Jonathan Sturges wrote: > Hi, > I'm missing something obvious and need someone to point me in the right direction. > > I'm finishing up mapping IRQs on a CS5530 winterminal board I've got. I know the IRQ mappings of each on-board device and slot, and I put together my irq_tables.c accordingly. However, only the first 2 entries get written to the IRQ table, even though the file designates 3. Then, when I boot the LB image, I get this warning: > Inconsistent IRQ routing table size (0x40/0x50) > > The 0x50 makes sense; that's the "32+16*3" from my irq_tables.c. But where is the size being set to 0x40? It seems there's a configuration I missed somewhere. There's default IRQ_SLOT_COUNT=2 (or similar) in the Options.lb of your board. > const struct irq_routing_table intel_irq_routing_table = { > PIRQ_SIGNATURE, /* u32 signature */ > PIRQ_VERSION, /* u16 version */ > 32+16*3, /* there can be total 3 devices on the bus */ So this should be 32+16*IRQ_SLOT_COUNT This may or may not fix your issue. Please report back if it does. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org ____________________________________________________________________________________ Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos. http://autos.yahoo.com/index.html

3 2

[LinuxBIOS] r2780 build service
by LinuxBIOS information 17 Sep '07

17 Sep '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2780 to the LinuxBIOS source repository and caused the following changes: Change Log: Add a README for superiotool (trivial). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of arima:hdama is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2780&device=hdama&vendor=… Compilation of ibm:e325 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2780&device=e325&vendor=i… Compilation of ibm:e326 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2780&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=2780&device=juki-511p&ven… Compilation of iwill:dk8s2 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2780&device=dk8s2&vendor=… Compilation of iwill:dk8x is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2780&device=dk8x&vendor=i… Compilation of newisys:khepri is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2780&device=khepri&vendor… 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, LinuxBIOS automatic build system

1 0

← Newer
1
...
16
17
18
19
20
21
22
...
37
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 September 2007