coreboot November 2007

coreboot@coreboot.org

75 participants
397 discussions

[LinuxBIOS] [PATH] irq routing on cs5530a/cs5536
by Nikolay Petukhov 26 Nov '07

26 Nov '07

Here patch to support IRQ routing by LinuxBios. This is necessary for the right setup on the unsupported Linux's chips. This functionality is include through macro PIRQ_ROUTE in Config.lb. Tested on iei/juki-511p(cs5530a) and iei/pcisa-lx(cs5536). Signed-off-by: Nikolay Petukhov <nikolay.petukhov(a)gmail.com> -- Nikolay

1 0

[LinuxBIOS] It's always fun to watch the very first boot on real hardware :-) (This is on alix 1c)
by ron minnich 26 Nov '07

26 Nov '07

LinuxBIOS-3.0.0 Sun Nov 25 19:26:24 PST 2007 starting... Choosing fallback boot. LAR: Attempting to open 'fallback/initram'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2 LAR: seen member normal/initram LAR: seen member bootblock LAR: NO FILE FOUND! LAR: Run file fallback/initram failed: No such file. Fallback failed. Try normal boot LAR: Attempting to open 'normal/initram'. LAR: Start 0xfff80000 len 0x80000 LAR: seen member normal/payload/segment0 LAR: seen member normal/payload/segment1 LAR: seen member normal/option_table LAR: seen member normal/stage2 LAR: seen member normal/initram LAR: CHECK normal/initram @ 0xfff93b80 start 0xfff93bc0 len 5092 reallen 5092 compression 0 entry 0x00000000 loadaddre0 where is 0xfff93bc0 Well, it did not work, as expected, but a LOT of stuff had to work to get this far ... note all the LAR members are there. The initram is not working, as expected, but hey ... I have a working one from v2, so we'll see how it goes. What DID happen is we got through CAR. Nice work, all you people who have been cleansing v3. I doubt it would have worked this well without your contributions. ron

1 0

[LinuxBIOS] r2986 build service
by LinuxBIOS information 25 Nov '07

25 Nov '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "uwe" checked in revision 2986 to the LinuxBIOS source repository and caused the following changes: Change Log: Dump support for SMSC FDC37C67x. Signed-off-by: Robinson P. Tryon <bishop.robinson(a)gmail.com> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of msi:ms9185 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2986&device=ms9185&vendor… Compilation of msi:ms9282 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2986&device=ms9282&vendor… Compilation of supermicro:h8dmr is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2986&device=h8dmr&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] superiotool - dump support for fdc37c672
by Robinson Tryon 25 Nov '07

25 Nov '07

Signed-off-by: Robinson P. Tryon <bishop.robinson(a)gmail.com> I also looked at the FDC37M707, which appears to have a chip id of 0x42, but in the table there is already {0x42, "FDC37B80x" ...}. Are these the same chip, or?

2 1

[LinuxBIOS] r2986 - trunk/util/superiotool
by svn＠openbios.org 25 Nov '07

25 Nov '07

Author: uwe Date: 2007-11-25 22:43:29 +0100 (Sun, 25 Nov 2007) New Revision: 2986 Modified: trunk/util/superiotool/smsc.c Log: Dump support for SMSC FDC37C67x. Signed-off-by: Robinson P. Tryon <bishop.robinson(a)gmail.com> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/util/superiotool/smsc.c =================================================================== --- trunk/util/superiotool/smsc.c 2007-11-25 03:49:43 UTC (rev 2985) +++ trunk/util/superiotool/smsc.c 2007-11-25 21:43:29 UTC (rev 2986) @@ -42,6 +42,37 @@ {0x30, "FDC37C93xAPM", { {EOT}}}, {0x40, "FDC37C67x", { /* E.g. FDC37C672. Chiprev: 0x01 */ + {NOLDN, NULL, + {0x03,0x20,0x21,0x22,0x23,0x24,0x26,0x27,0x2b,0x2c, + 0x2d,0x2e,0x2f,EOT}, + {0x03,0x40,NANA,0x00,0x00,0x04,MISC,MISC,NANA,NANA, + NANA,NANA,NANA,EOT}}, + {0x0, "Floppy", + {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,0xf2,0xf4,0xf5, + EOT}, + {0x00,0x03,0xf0,0x06,0x02,0x0e,0x00,0xff,0x00,0x00, + EOT}}, + {0x3, "Parallel port", + {0x30,0x60,0x61,0x70,0x74,0xf0,0xf1,EOT}, + {0x00,0x00,0x00,0x00,0x04,0x3c,0x00,EOT}}, + {0x4, "COM1", + {0x30,0x60,0x61,0x70,0xf0,EOT}, + {0x00,0x00,0x00,0x00,0x00,EOT}}, + {0x5, "COM2", + {0x30,0x60,0x61,0x62,0x63,0x70,0x74,0xf0,0xf1,0xf2, + EOT}, + {0x00,0x00,0x00,0x00,0x00,0x00,0x04,0x00,0x02,0x03, + EOT}}, + {0x7, "Keyboard", + {0x30,0x70,0x72,0xf0,EOT}, + {0x00,0x00,0x00,0x00,EOT}}, + {0x8, "Aux I/O", + {0x30,0xb4,0xb5,0xb6,0xb7,0xc0,0xc1,0xc2,0xc3,0xc4, + 0xf1,0xf2,0xf3,0xf4,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb, + EOT}, + {0x00,NANA,NANA,NANA,NANA,0x06,0x03,NANA,NANA,NANA, + 0x00,0x00,0x00,MISC,RSVD,RSVD,RSVD,RSVD,RSVD,RSVD, + EOT}}, {EOT}}}, {0x42, "FDC37B80x/FDC37M707", { {EOT}}},

1 0

[LinuxBIOS] [PATCH] v3: improve LAR comments, fix possible access to uninitialized memory
by Carl-Daniel Hailfinger 25 Nov '07

25 Nov '07

Fix a corner case access to uninitialized memory (NULL pointer dereference or worse) in case the archive length is exactly sizeof(struct lar_header). Such an archive is invalid because the filename directly after the LAR header is always dereferenced and has to be at least 1 byte in the "empty filename" case (only terminating \0). Improve LAR code documentation and reorder variables in one assignment to make the code more obvious and readable. This will help people understand what the code does when they look at it half a year from now. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> --- Index: LinuxBIOSv3/include/lar.h =================================================================== --- LinuxBIOSv3/include/lar.h (Revision 505) +++ LinuxBIOSv3/include/lar.h (Arbeitskopie) @@ -52,10 +52,9 @@ #include <types.h> -/* see note in lib/lar.c as to why this is ARCHIVE and not LARCHIVE */ #define MAGIC "LARCHIVE" #define MAX_PATHLEN 1024 -/* NOTE -- This and the user-mode lar.h are NOT IN SYNC. Be careful. */ +/* NOTE -- This and the user-mode lar.h may NOT be IN SYNC. Be careful. */ struct lar_header { char magic[8]; u32 len; Index: LinuxBIOSv3/lib/lar.c =================================================================== --- LinuxBIOSv3/lib/lar.c (Revision 505) +++ LinuxBIOSv3/lib/lar.c (Arbeitskopie) @@ -49,7 +49,7 @@ * Given a file name in the LAR , search for it, and fill out a return struct with the * result. * @param archive A descriptor for current archive. This is actually a mem_file type, - * which is a machine-dependent representation of hte actual archive. In particular, + * which is a machine-dependent representation of the actual archive. In particular, * things like u32 are void * in the mem_file struct. * @param filename filename to find * @param result pointer to mem_file struct which is filled in if the file is found @@ -65,30 +65,43 @@ printk(BIOS_SPEW, "LAR: Start %p len 0x%x\n", archive->start, archive->len); - if (archive->len < sizeof(struct lar_header)) - printk(BIOS_ERR, "Error: truncated archive (%d bytes); minimum possible size is %d bytes\n", - archive->len, sizeof(struct lar_header)); + /* Why check for sizeof(struct lar_header) + 1? The code below expects + * a filename to follow directly after the LAR header and will + * dereference the address directly after the header. However, if + * archive->len == sizeof(struct lar_header), printing the filename + * will dereference memory outside the archive. Without looking at the + * filename, the only thing we can check is that there is at least room + * for an empty filename (only the terminating \0). + */ + if (archive->len < sizeof(struct lar_header) + 1) + printk(BIOS_ERR, "Error: truncated archive (%d bytes); minimum" + " possible size is %d bytes\n", + archive->len, sizeof(struct lar_header) + 1); - /* Getting this for loop right is harder than it looks. All quantities are - * unsigned. The LAR stretches from (e.g.) 0xfff0000 for 0x100000 - * bytes, i.e. to address ZERO. - * As a result, 'walk', can wrap to zero and keep going (this has been - * seen in practice). Recall that these are unsigned; walk can - * wrap to zero; so, question, when is walk less than any of these: - * archive->start - * Answer: once walk wraps to zero, it is < archive->start - * archive->start + archive->len - * archive->start + archive->len - 1 - * Answer: In the case that archive->start + archive->len == 0, ALWAYS! - * A lot of expressions have been tried and all have been wrong. - * So what would work? Simple: - * test for walk < archive->start + archive->len - 1 to cover the case - * that the archive does NOT occupy ALL of the top of memory and - * wrap to zero; - * and test for walk >= archive->start, - * to cover the case that you wrapped to zero. - * Unsigned pointer arithmetic that wraps to zero can be messy. - */ + /* Getting this for loop right is harder than it looks. All quantities + * are unsigned. The LAR stretches from (e.g.) 0xfff0000 for 0x100000 + * bytes, i.e. to address ZERO. + * As a result, 'walk', can wrap to zero and keep going (this has been + * seen in practice). Recall that these are unsigned; walk can + * wrap to zero; so, question, when is walk less than any of these: + * archive->start + * Answer: once walk wraps to zero, it is < archive->start + * archive->start + archive->len + * archive->start + archive->len - 1 + * Answer: In the case that archive->start + archive->len == 0, ALWAYS! + * A lot of expressions have been tried and all have been wrong. + * So what would work? Simple: + * test for walk < archive->start + archive->len - sizeof(lar_header) + * to cover the case that the archive does NOT occupy ALL of the + * top of memory and wrap to zero; RESIST the temptation to change + * that comparison to <= because if a header did terminate the + * archive, the filename (stored directly after the header) would + * be outside the archive and you'd get a nice NULL pointer for + * the filename + * and test for walk >= archive->start, + * to cover the case that you wrapped to zero. + * Unsigned pointer arithmetic that wraps to zero can be messy. + */ for (walk = archive->start; (walk < (char *)(archive->start + archive->len - sizeof(struct lar_header))) && (walk >= (char *)archive->start); walk += 16) { @@ -98,7 +111,7 @@ header = (struct lar_header *)walk; fullname = walk + sizeof(struct lar_header); - printk(BIOS_SPEW, "LAR: search for %s\n", fullname); + printk(BIOS_SPEW, "LAR: seen member %s\n", fullname); // FIXME: check checksum if (strcmp(fullname, filename) == 0) { @@ -115,11 +128,20 @@ result->compression, result->entry, result->loadaddress); return 0; } - // skip file - walk += (ntohl(header->len) + ntohl(header->offset) - - 1) & 0xfffffff0; + /* skip file: + * The next iteration of the for loop will add 16 to walk, so + * we now add offset (from header start to data start) and len + * (member length), subtract 1 (to get the address of the last + * byte of the member) and round this down to the next 16 byte + * boundary. + * In the case of consecutive archive members with header- + * before-member structure, the next iteration of the loop will + * start exactly at the beginning of the next header. + */ + walk += (ntohl(header->offset) + ntohl(header->len) - 1) + & 0xfffffff0; } - printk(BIOS_SPEW, "NO FILE FOUND\n"); + printk(BIOS_SPEW, "LAR: NO FILE FOUND\n"); return 1; } @@ -157,7 +179,7 @@ * the loadaddress pointer in the mem_file struct. * @param archive A descriptor for current archive. * @param filename filename to find - * returns 0 on success, -1 otherwise + * returns entry on success, (void*)-1 otherwise */ void *load_file(struct mem_file *archive, const char *filename) Index: LinuxBIOSv3/util/lar/lar.h =================================================================== --- LinuxBIOSv3/util/lar/lar.h (Revision 505) +++ LinuxBIOSv3/util/lar/lar.h (Arbeitskopie) @@ -61,13 +61,15 @@ typedef uint32_t u32; typedef uint8_t u8; -/* NOTE -- This and the linuxbios lar.h are NOT IN SYNC. Be careful. */ +/* NOTE -- This and the user-mode lar.h may NOT be IN SYNC. Be careful. */ struct lar_header { char magic[8]; u32 len; u32 reallen; u32 checksum; u32 compchecksum; + /* Filenames are limited to 2^31-1-sizeof(lar_header)-1 bytes. + * "Nobody will ever need more than 640k" */ u32 offset; /* Compression: * 0 = no compression Index: LinuxBIOSv3/arch/x86/stage1.c =================================================================== --- LinuxBIOSv3/arch/x86/stage1.c (Revision 505) +++ LinuxBIOSv3/arch/x86/stage1.c (Arbeitskopie) @@ -69,7 +69,7 @@ } /* - * This function is called from assembler code whith its argument on the + * This function is called from assembler code with its argument on the * stack. Force the compiler to generate always correct code for this case. */ void __attribute__((stdcall)) stage1_main(u32 bist) @@ -140,7 +140,7 @@ } else { printk(BIOS_DEBUG, "Choosing fallback boot.\n"); ret = execute_in_place(&archive, "fallback/initram"); - /* Try a normal boot if fallback doesn't exists in the lar. + /* Try a normal boot if fallback doesn't exist in the lar. * TODO: There are other ways to do this. * It could be ifdef or the boot flag could be forced. */

2 3

[LinuxBIOS] [PATCH] superiotool: Use 'static const' instead of 'const static'
by Uwe Hermann 25 Nov '07

25 Nov '07

See patch. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

2 3

[LinuxBIOS] "Trivial" patches
by Carl-Daniel Hailfinger 25 Nov '07

25 Nov '07

Hi, various big code changes/additions have been committed as trivial by others in the past, so I am considering to follow the same policy and declare all of my future patches as trivial and commit them instantly if I feel like it. That would surely speed up development for me. Comments/Flames/Applause welcome. Regards, Carl-Daniel

8 14

[LinuxBIOS] [ADMIN] Mail headers: random variations?
by Carl-Daniel Hailfinger 25 Nov '07

25 Nov '07

Hi, (yes, I read mail headers.) I have noticed that mails I receive via the list can have two differing Return-Paths, depending on some random circumstances. Both of the following header lines have been seen for mails sent 3 seconds after each other, differing in amost nothing except the Return-Path: Return-Path: <linuxbios-bounces+c-d.hailfinger.devel.2006=gmx.net(a)linuxbios.org> Return-Path: <linuxbios-bounces(a)linuxbios.org> The Return-Path variation is independent of the original sender, I have seen it for autogenerated commit mails as well as mails for every single person I checked. Is anybody else seeing this? Regards, Carl-Daniel From - Thu Nov 22 19:16:34 2007 X-Account-Key: account3 X-UIDL: 7704a18f6aed6e11e08e98be09d88b73 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: <linuxbios-bounces+c-d.hailfinger.devel.2006=gmx.net(a)linuxbios.org> X-Flags: 1001 Delivered-To: GMX delivery to c-d.hailfinger.devel.2006(a)gmx.net Received: (qmail invoked by alias); 22 Nov 2007 18:10:41 -0000 Received: from khepri.openbios.org (EHLO khepri.openbios.org) [80.190.231.112] by mx0.gmx.net (mx021) with SMTP; 22 Nov 2007 19:10:41 +0100 Received: from localhost ([127.0.0.1] helo=khepri.openbios.org) by khepri.openbios.org with esmtp (Exim 4.68) (envelope-from <linuxbios-bounces+c-d.hailfinger.devel.2006=gmx.net(a)linuxbios.org>) id 1IvGVc-0006xO-K2 for c-d.hailfinger.devel.2006(a)gmx.net; Thu, 22 Nov 2007 19:10:40 +0100 Received: from mail.gmx.net ([213.165.64.20]) by khepri.openbios.org with smtp (Exim 4.68) (envelope-from <c-d.hailfinger.devel.2006(a)gmx.net>) id 1IvGV5-0006kb-To for linuxbios(a)linuxbios.org; Thu, 22 Nov 2007 19:10:15 +0100 Received: (qmail invoked by alias); 22 Nov 2007 18:10:07 -0000 Received: from stud215072.studentenheim.uni-tuebingen.de (EHLO [172.16.252.128]) [134.2.215.72] by mail.gmx.net (mp007) with SMTP; 22 Nov 2007 19:10:07 +0100 X-Authenticated: #31060655 Message-ID: <47444315.90702(a)gmx.net> Date: Wed, 21 Nov 2007 15:39:17 +0100 From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20070803 SUSE/1.1.5-0.1 SeaMonkey/1.1.5 MIME-Version: 1.0 To: LinuxBIOS <linuxbios(a)linuxbios.org> X-Spam-Score: -0.1 (/) Subject: [LinuxBIOS] [PATCH] v3: duplicate less code X-BeenThere: linuxbios(a)linuxbios.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The LinuxBIOS project mailing list <linuxbios.linuxbios.org> List-Unsubscribe: <http://www.linuxbios.org/mailman/listinfo/linuxbios>, <mailto:linuxbios-request@linuxbios.org?subject=unsubscribe> List-Archive: <http://www.linuxbios.org/pipermail/linuxbios> List-Post: <mailto:linuxbios@linuxbios.org> List-Help: <mailto:linuxbios-request@linuxbios.org?subject=help> List-Subscribe: <http://www.linuxbios.org/mailman/listinfo/linuxbios>, <mailto:linuxbios-request@linuxbios.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: linuxbios-bounces+c-d.hailfinger.devel.2006=gmx.net(a)linuxbios.org Errors-To: linuxbios-bounces+c-d.hailfinger.devel.2006=gmx.net(a)linuxbios.org X-Duff: Orig. Duff, Duff Lite, Duff Dry, Duff Dark, Raspberry Duff, Lady Duff, Red Duff, Tartar Control Duff X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Sender is in whitelist: c-d.hailfinger.devel.2006(a)gmx.net) X-GMX-UID: tvF3dpFZIyd0cYqXrWZrykNaa2FkZtXJ From - Thu Nov 22 19:16:34 2007 X-Account-Key: account3 X-UIDL: fceb6e1f02120862aab3a48797356394 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: <linuxbios-bounces(a)linuxbios.org> X-Flags: 1001 Delivered-To: GMX delivery to c-d.hailfinger.devel.2006(a)gmx.net Received: (qmail invoked by alias); 22 Nov 2007 18:11:34 -0000 Received: from khepri.openbios.org (EHLO khepri.openbios.org) [80.190.231.112] by mx0.gmx.net (mx007) with SMTP; 22 Nov 2007 19:11:34 +0100 Received: from localhost ([127.0.0.1] helo=khepri.openbios.org) by khepri.openbios.org with esmtp (Exim 4.68) (envelope-from <linuxbios-bounces(a)linuxbios.org>) id 1IvGWP-0007HZ-6O; Thu, 22 Nov 2007 19:11:29 +0100 Received: from mail.gmx.net ([213.165.64.20]) by khepri.openbios.org with smtp (Exim 4.68) (envelope-from <c-d.hailfinger.devel.2006(a)gmx.net>) id 1IvGV9-0006lP-1h for linuxbios(a)linuxbios.org; Thu, 22 Nov 2007 19:10:21 +0100 Received: (qmail invoked by alias); 22 Nov 2007 18:10:10 -0000 Received: from stud215072.studentenheim.uni-tuebingen.de (EHLO [172.16.252.128]) [134.2.215.72] by mail.gmx.net (mp021) with SMTP; 22 Nov 2007 19:10:10 +0100 X-Authenticated: #31060655 Message-ID: <47444F30.8070900(a)gmx.net> Date: Wed, 21 Nov 2007 16:30:56 +0100 From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20070803 SUSE/1.1.5-0.1 SeaMonkey/1.1.5 MIME-Version: 1.0 To: LinuxBIOS <linuxbios(a)linuxbios.org> X-Spam-Score: 0.3 (/) Subject: [LinuxBIOS] Vendor contacts - how to proceed X-BeenThere: linuxbios(a)linuxbios.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The LinuxBIOS project mailing list <linuxbios.linuxbios.org> List-Unsubscribe: <http://www.linuxbios.org/mailman/listinfo/linuxbios>, <mailto:linuxbios-request@linuxbios.org?subject=unsubscribe> List-Archive: <http://www.linuxbios.org/pipermail/linuxbios> List-Post: <mailto:linuxbios@linuxbios.org> List-Help: <mailto:linuxbios-request@linuxbios.org?subject=help> List-Subscribe: <http://www.linuxbios.org/mailman/listinfo/linuxbios>, <mailto:linuxbios-request@linuxbios.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: linuxbios-bounces(a)linuxbios.org Errors-To: linuxbios-bounces(a)linuxbios.org X-Duff: Orig. Duff, Duff Lite, Duff Dry, Duff Dark, Raspberry Duff, Lady Duff, Red Duff, Tartar Control Duff X-GMX-Antivirus: -1 (not scanned, may not use virus scanner) X-GMX-Antispam: 0 (Sender is in whitelist: c-d.hailfinger.devel.2006(a)gmx.net) X-GMX-UID: AaM3Z7JseSE4K86RsnUhhl52IGRvb4AE

4 3

[LinuxBIOS] r2985 build service
by LinuxBIOS information 25 Nov '07

25 Nov '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "cozzie" checked in revision 2985 to the LinuxBIOS source repository and caused the following changes: Change Log: More abuild fixes, the previous ones weren't enough. Hopefully this covers everything. Signed-off-by: Corey Osgood <corey.osgood(a)gmail.com> Acked-by: Corey Osgood <corey.osgood(a)gmail.com> Build Log: Compilation of amd:serengeti_cheetah has been fixed Compilation of iwill:dk8_htx has been fixed Compilation of msi:ms9185 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2985&device=ms9185&vendor… Compilation of msi:ms9282 is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2985&device=ms9282&vendor… Compilation of supermicro:h8dmr is still broken See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2985&device=h8dmr&vendor=… If something broke during this checkin please be a pain in cozzie'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
...
11
12
13
14
15
16
17
...
40
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 November 2007