coreboot April 2009

coreboot@coreboot.org

69 participants
583 discussions

CBFS fix?
by Myles Watson 25 Apr '09

25 Apr '09

Are we going to move the location of the master header? I'd like to add an error to cbfstool when it overwrites code with its data. Thanks, Myles

5 13

[PATCH]es: fix cbfs payload compression, and activate it
by Patrick Georgi 25 Apr '09

25 Apr '09

Hi, again two patches. 20090424-3-selfboot-shuffle.patch moves decompression further down the code flow, so that - where possible - code is decompressed directly to the right place (instead of copying around, as before). The downside of this approach is that it's not possible (without API changes to the decompressors) to put partial segments into bounce buffers. So if a segment collides with coreboot _and_ is compressed, it's bounced entirely. But, this only brings back the copy we already had before, so the new worst case is better than the average before. It also fixes handling of compressed segments, but I'm too tired to split them into separate patches, sorry. 20090424-4-activate-cbfs-payload-compression.patch enables cbfs payload compression (the "l" flag) if payloads are supposed to be compressed (with lzma only, as cbfstool lacks nrv2b compression support) as usual, Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Patrick

2 1

Fwd: s2892 + CBFS strange failure
by ron minnich 24 Apr '09

24 Apr '09

Please excuse this blast. Here's the problem: CBFS is breaking something it can't break. If you turn on CBFS, then very early startup in the opteron code fails. this is verified across several mainboards. Any wild ideas welcome. I can't even figure out where to start ... ron Forwarded conversation Subject: s2892 + CBFS strange failure ------------------------ From: *Myles Watson* <mylesgw(a)gmail.com> Date: Wed, Apr 22, 2009 at 9:05 AM To: ron minnich <rminnich(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi <patrick.georgi(a)coresystems.de>, Marc Jones < marcj303(a)gmail.com> On Wed, Apr 22, 2009 at 9:56 AM, ron minnich <rminnich(a)gmail.com> wrote: > can I bring in patrick and stephan and marcj? This is getting too weird. :) Probably part of it is miscommunication on my part, but I'd be glad for any help. Here's the summary: With CONFIG_CBFS = 0 it works fine With CONFIG_CBFS = 1 I get (warm reset): INIT detected from --- { APICID = 00 NODEID = 00 COREID = 00} --- Issuing SOFT_RESET... Then nothing else. Post code 0xf0 With CONFIG_CBFS = 1 I get (cold reset): Nothing. Post code 0xf0 I've been inserting post codes, and it always makes it to real_main. It just doesn't make it out of init_cpus. On a warm reset I get the serial output. Otherwise there is none. We've tried using a different compiler. Same results. We've tried no payload and no VGA ROM. Thanks, Myles ---------- From: *ron minnich* <rminnich(a)gmail.com> Date: Wed, Apr 22, 2009 at 9:12 AM To: Myles Watson <mylesgw(a)gmail.com> Cc: Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi < patrick.georgi(a)coresystems.de>, Marc Jones <marcj303(a)gmail.com> Also, myles, this all works on serengeti, right? ron ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Wed, Apr 22, 2009 at 9:13 AM To: ron minnich <rminnich(a)gmail.com> Cc: Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi < patrick.georgi(a)coresystems.de>, Marc Jones <marcj303(a)gmail.com> I was in the middle of writing that :) I forgot an interesting point: The broken image works on SimNOW until it can't find the SMBUS. But it always gets far enough that there is some serial output. Thanks, Myles ---------- From: *Marc Jones* <marcj303(a)gmail.com> Date: Wed, Apr 22, 2009 at 10:28 AM To: Myles Watson <mylesgw(a)gmail.com> Cc: ron minnich <rminnich(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi <patrick.georgi(a)coresystems.de> That is very strange. can you attempt to track when it starts to fail? Does it have to boot all the way into linux before the reset stops working or does it happened before it loads any payloads? I can't think of anything that would cause that kind of problem. Can you narrow it down in cpu_init? Marc -- http://marcjonesconsulting.com ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Wed, Apr 22, 2009 at 10:48 AM To: Marc Jones <marcj303(a)gmail.com> Cc: ron minnich <rminnich(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi <patrick.georgi(a)coresystems.de> Sorry I was unclear again. I'll try to explain better. When I said it happens on warm reset, I meant from a working image. 1. boot a working image 2. switch to cbfs image 3. warm reset gives some output It seems like it hangs on the first call to printk that it reaches. I tried moving console_init ahead of init_cpus in real_main, but it didn't change the behavior. Thanks, Myles ---------- From: *ron minnich* <rminnich(a)gmail.com> Date: Wed, Apr 22, 2009 at 1:44 PM To: Myles Watson <mylesgw(a)gmail.com> Cc: Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi <patrick.georgi(a)coresystems.de> so cbfs works with qemu kontron (yes or no?I think yes) serengeit and it fails with this board. are these older CPUs? What stepping? I have to admit I'm stumped. ron ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Wed, Apr 22, 2009 at 1:47 PM To: ron minnich <rminnich(a)gmail.com> Cc: Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi <patrick.georgi(a)coresystems.de> I may have been chasing the wrong thing here. When I was helping Samuel with the the dl145 he said that somewhere after 4030 cold boot broke for him. He's bisecting now. Thanks, Myles ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Thu, Apr 23, 2009 at 6:15 AM To: ron minnich <rminnich(a)gmail.com> Cc: Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi <patrick.georgi(a)coresystems.de> Just to add a wrinkle my onboard graphics died. That's why things were flaky yesterday. It just stopped responding to config reads and gets disabled by coreboot. I added a video card and I'm back up. Cold boot works for me with 4193 (No CBFS), so the Config changes were fine. It's still broken for CBFS for me. Unless someone has an idea of how to track it down I'm just going to not use CBFS for now, even though I like the CBFS option much better. Thanks, Myles ---------- From: *ron minnich* <rminnich(a)gmail.com> Date: Thu, Apr 23, 2009 at 7:57 AM To: Myles Watson <mylesgw(a)gmail.com> Cc: Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi <patrick.georgi(a)coresystems.de> we really need to track this down because whatever this may be, it's unlikely to be cbfs. Not if you're not getting any prints at all. It would still be interesting if you could try the very first version where cbfs was introduced. ron ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Thu, Apr 23, 2009 at 12:04 PM To: ron minnich <rminnich(a)gmail.com> Cc: Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi <patrick.georgi(a)coresystems.de> There were some fixes put in pretty quickly. I just tried 4113 (the rename.) Which one would you suggest next? Thanks, Myles ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Thu, Apr 23, 2009 at 3:09 PM To: ron minnich <rminnich(a)gmail.com> 4061 fails with CBFS but not without. Thanks, Myles ---------- From: *ron minnich* <rminnich(a)gmail.com> Date: Fri, Apr 24, 2009 at 7:23 AM To: Myles Watson <mylesgw(a)gmail.com> no serial output and SPEW? ron ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Fri, Apr 24, 2009 at 7:38 AM To: ron minnich <rminnich(a)gmail.com> For a warm boot. Nothing from a cold boot. 4061 no CBFS works fine. Thanks, Myles ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Fri, Apr 24, 2009 at 7:40 AM To: ron minnich <rminnich(a)gmail.com> SPEW is definitely enabled for the working one. Thanks, Myles ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Fri, Apr 24, 2009 at 8:18 AM To: ron minnich <rminnich(a)gmail.com> Cc: Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi <patrick.georgi(a)coresystems.de> 4061 on my s2892 with SPEW: On my s2895 I am having problems with warm reset, and a cold boot powers itself off quickly with post code 0xf0. Thanks, Myles ---------- From: *ron minnich* <rminnich(a)gmail.com> Date: Fri, Apr 24, 2009 at 9:47 AM To: Myles Watson <mylesgw(a)gmail.com> Cc: Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Patrick Georgi <patrick.georgi(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org > OK, this is nuts. CBFS is in the ram code. It can't affect he ROM code, can it? And this is really early! Here are the only things I can think of: 1. CBFS changes layout somehow 2. Turning off ELFBOOT turned off something hidden 3. it's changing the way gcc works I just don't know. Somehow we've got to find this. I will set up my dbm board tonight. Patrick, Stefan, have you tested CBFS with the kontron? ron ---------- From: *Patrick Georgi* <patrick.georgi(a)coresystems.de> Date: Fri, Apr 24, 2009 at 9:49 AM To: ron minnich <rminnich(a)gmail.com> Cc: Myles Watson <mylesgw(a)gmail.com>, Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org> Am 24.04.2009 18:47, schrieb ron minnich: That's where my lzma.c patch came from. I'm debugging the bounce buffer code right now, it seems to copy correctly into the buffer, but I'm not convinced yet that it correctly copies back. Patrick ---------- From: *ron minnich* <rminnich(a)gmail.com> Date: Fri, Apr 24, 2009 at 9:55 AM To: Patrick Georgi <patrick.georgi(a)coresystems.de> Cc: Myles Watson <mylesgw(a)gmail.com>, Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org> but Myle's failure is WAY before any of that. His machine dies in the very earliest C code. I do not really like the bounce buffer ... it' just too fragile for my taste. If anything goes wrong, well, you're in assembly code with no way out. ron ---------- From: *Patrick Georgi* <patrick.georgi(a)coresystems.de> Date: Fri, Apr 24, 2009 at 10:35 AM To: ron minnich <rminnich(a)gmail.com> Cc: Myles Watson <mylesgw(a)gmail.com>, Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org> OK, this is nuts. CBFS is in the ram code. It can't affect he ROM I'm not quite sure at which point in the boot process the last message before the reboot comes up, so this is just a guess. Could it be that it tries to jump into the normal image? I'm not quite certain that we get that entirely correct (and the layout might change in that dark corner of the build system). Replacing that "jmp __normal_image" with "jmp __fallback_image" might help then (for testing). Patrick ---------- From: *ron minnich* <rminnich(a)gmail.com> Date: Fri, Apr 24, 2009 at 10:42 AM To: Patrick Georgi <patrick.georgi(a)coresystems.de> Cc: Myles Watson <mylesgw(a)gmail.com>, Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org> On Fri, Apr 24, 2009 at 10:35 AM, Patrick Georgi not *that* is a pretty smart guess. Myles, were you runinng fallback/normal? ron ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Fri, Apr 24, 2009 at 10:42 AM To: ron minnich <rminnich(a)gmail.com> Cc: Patrick Georgi <patrick.georgi(a)coresystems.de>, Marc Jones < marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org> fallback only. I'll try it. Thanks, Myles ---------- From: *ron minnich* <rminnich(a)gmail.com> Date: Fri, Apr 24, 2009 at 10:57 AM To: Myles Watson <mylesgw(a)gmail.com> Cc: Patrick Georgi <patrick.georgi(a)coresystems.de>, Marc Jones < marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org> src/lib/cbfs.c src/include/cbfs.h src/devices/pci_rom.c src/boot/selfboot.c src/boot/hardwaremain.c But none of these are involved in the early CAR code. There is another possibility: are we somehow messing up the HT configuration space? That would explain why you die after init_cpus. ron ---------- From: *ron minnich* <rminnich(a)gmail.com> Date: Fri, Apr 24, 2009 at 11:11 AM To: Myles Watson <mylesgw(a)gmail.com> Cc: Patrick Georgi <patrick.georgi(a)coresystems.de>, Marc Jones < marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org> well,this problem just became urgent. I've got no idea where to start and no time right now to work on it :-( And it doesn't break on simnow, right, myles? Patrick, any progress on kontron? oh, !@#$@!#$@!#$!@$# ron ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Fri, Apr 24, 2009 at 11:12 AM To: ron minnich <rminnich(a)gmail.com> Cc: Patrick Georgi <patrick.georgi(a)coresystems.de>, Marc Jones < marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org> And why there's only output on a warm reset. I don't know. I tried removing the normal image jump in cache_as_ram_auto.c. I guess I should have remembered that it got past there before init_cpus. Myles ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Fri, Apr 24, 2009 at 11:13 AM To: ron minnich <rminnich(a)gmail.com> Cc: Patrick Georgi <patrick.georgi(a)coresystems.de>, Marc Jones < marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org> Right. The serengeti image works fine, and the s2892 image runs until it notices it has a different chipset and dies with "SMBUS not found." Myles ---------- From: *ron minnich* <rminnich(a)gmail.com> Date: Fri, Apr 24, 2009 at 11:15 AM To: Myles Watson <mylesgw(a)gmail.com> Cc: Patrick Georgi <patrick.georgi(a)coresystems.de>, Marc Jones < marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de>, Ward Vandewege <ward(a)gnu.org> Anyone mind if I just take this to the list. ron ---------- From: *Ward Vandewege* <ward(a)gnu.org> Date: Fri, Apr 24, 2009 at 11:16 AM To: ron minnich <rminnich(a)gmail.com> Cc: Myles Watson <mylesgw(a)gmail.com>, Patrick Georgi < patrick.georgi(a)coresystems.de>, Marc Jones <marcj303(a)gmail.com>, Stefan Reinauer <stepan(a)coresystems.de> Please do. Thanks, Ward. -- Ward Vandewege <ward(a)fsf.org> Free Software Foundation - Senior Systems Administrator ---------- From: *Myles Watson* <mylesgw(a)gmail.com> Date: Fri, Apr 24, 2009 at 11:21 AM To: ron minnich <rminnich(a)gmail.com> No problem here. We probably should have done it a while ago. I just didn't want to make too big of a stink if we could fix it quickly. Thanks, Myles

3 5

[v2] r4206 - in trunk/coreboot-v2/src: lib stream
by svn＠coreboot.org 24 Apr '09

24 Apr '09

Author: oxygene Date: 2009-04-24 18:44:34 +0200 (Fri, 24 Apr 2009) New Revision: 4206 Modified: trunk/coreboot-v2/src/lib/Config.lb trunk/coreboot-v2/src/lib/lzma.c trunk/coreboot-v2/src/stream/rom_stream.c trunk/coreboot-v2/src/stream/serial_stream.c Log: Remove the inclusion of lzma.c (which really contains code) from another (rom_stream.c and others), instead linking it like any source file should be linked. The same should (and will) be done with nrv2b.c, but that has some deeper implications as various CAR implementations include that directly, and thus requires more care. It fixes an issue with the cbfs code. Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Acked-by: Ronald G. Minnich <rminnich(a)gmail.com> Modified: trunk/coreboot-v2/src/lib/Config.lb =================================================================== --- trunk/coreboot-v2/src/lib/Config.lb 2009-04-24 16:17:41 UTC (rev 4205) +++ trunk/coreboot-v2/src/lib/Config.lb 2009-04-24 16:44:34 UTC (rev 4206) @@ -31,3 +31,7 @@ if CONFIG_CBFS object cbfs.o end + +if CONFIG_COMPRESSED_PAYLOAD_LZMA + object lzma.o +end Modified: trunk/coreboot-v2/src/lib/lzma.c =================================================================== --- trunk/coreboot-v2/src/lib/lzma.c 2009-04-24 16:17:41 UTC (rev 4205) +++ trunk/coreboot-v2/src/lib/lzma.c 2009-04-24 16:44:34 UTC (rev 4206) @@ -11,9 +11,11 @@ */ #include "lzmadecode.c" +#include <console/console.h> +#include <string.h> -static unsigned long ulzma(unsigned char * src, unsigned char * dst) +unsigned long ulzma(unsigned char * src, unsigned char * dst) { unsigned char properties[LZMA_PROPERTIES_SIZE]; UInt32 outSize; Modified: trunk/coreboot-v2/src/stream/rom_stream.c =================================================================== --- trunk/coreboot-v2/src/stream/rom_stream.c 2009-04-24 16:17:41 UTC (rev 4205) +++ trunk/coreboot-v2/src/stream/rom_stream.c 2009-04-24 16:44:34 UTC (rev 4206) @@ -25,7 +25,7 @@ #error "You're defining more than one compression type, which is not allowed." #endif #define HAVE_UNCOMPRESSER 1 -#include "../lib/lzma.c" +unsigned long ulzma(unsigned char *src, unsigned char *dst); #endif #ifndef CONFIG_ROM_PAYLOAD_START Modified: trunk/coreboot-v2/src/stream/serial_stream.c =================================================================== --- trunk/coreboot-v2/src/stream/serial_stream.c 2009-04-24 16:17:41 UTC (rev 4205) +++ trunk/coreboot-v2/src/stream/serial_stream.c 2009-04-24 16:44:34 UTC (rev 4206) @@ -19,7 +19,7 @@ #error "You're defining more than one compression type, which is not allowed (of course)" #endif #define HAVE_UNCOMPRESSER 1 -#include "../lib/lzma.c" +unsigned long ulzma(unsigned char *src, unsigned char *dst); #endif #include "../lib/xmodem.c"

1 0

[PATCH] don't include lzma.c from another source file
by Patrick Georgi 24 Apr '09

24 Apr '09

Hi, the attached file removes the inclusion of lzma.c (which really contains code) from another (rom_stream.c and others), instead linking it like any source file should be linked. The same should (and will) be done with nrv2b.c, but that has some deeper implications as various CAR implementations include that directly, and thus requires more care. It fixes an issue with the cbfs code. As usual, it's Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Patrick

2 1

[v2] r4205 - trunk/util/flashrom
by svn＠coreboot.org 24 Apr '09

24 Apr '09

Author: uwe Date: 2009-04-24 18:17:41 +0200 (Fri, 24 Apr 2009) New Revision: 4205 Modified: trunk/util/flashrom/flash.h trunk/util/flashrom/flashrom.c Log: MAX may already be defined. Also, fix smaller cosmetics (trivial). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2009-04-24 10:23:56 UTC (rev 4204) +++ trunk/util/flashrom/flash.h 2009-04-24 16:17:41 UTC (rev 4205) @@ -512,15 +512,13 @@ extern flashbus_t flashbus; extern void *spibar; -/* debug.c */ -extern int verbose; -#define printf_debug(x...) { if (verbose) printf(x); } - /* physmap.c */ void *physmap(const char *descr, unsigned long phys_addr, size_t len); void physunmap(void *virt_addr, size_t len); /* flashrom.c */ +extern int verbose; +#define printf_debug(x...) { if (verbose) printf(x); } void map_flash_registers(struct flashchip *flash); /* layout.c */ @@ -529,7 +527,7 @@ int find_romentry(char *name); int handle_romentries(uint8_t *buffer, uint8_t *content); -/* lbtable.c */ +/* cbtable.c */ int coreboot_init(void); extern char *lb_part, *lb_vendor; Modified: trunk/util/flashrom/flashrom.c =================================================================== --- trunk/util/flashrom/flashrom.c 2009-04-24 10:23:56 UTC (rev 4204) +++ trunk/util/flashrom/flashrom.c 2009-04-24 16:17:41 UTC (rev 4205) @@ -242,7 +242,9 @@ return 0; } +#ifndef MAX #define MAX(a, b) ((a) > (b) ? (a) : (b)) +#endif #define POS_PRINT(x) do { pos += strlen(x); printf(x); } while (0) void print_supported_chips(void)

1 0

GeoCities is closing down... backups?
by Carl-Daniel Hailfinger 24 Apr '09

24 Apr '09

Hi, there are quite some resources useful for coreboot which are hosted at GeoCities. Since GeoCities will close down later this year (no exact date known), I fear we will lose that material. One web site I'm thinking of is http://www.geocities.com/mamanzip/ and I'd appreciate it if someone could mirror it. Is there any other valuable (for coreboot/flashrom) content at GeoCities? I'd appreciate pointers. Regards, Carl-Daniel -- http://www.hailfinger.org/

4 3

cbfstool and scan-build
by Myles Watson 24 Apr '09

24 Apr '09

If we make cbfs the default for a board (say qemu), will scan-build check the cbfs tools too? Thanks, Myles

2 2

[flashrom][PATCH] typo in Makefile
by stephan.guilloux＠free.fr 24 Apr '09

24 Apr '09

Hello, Found some typo in Makefile which was producing some "strange behaviours" while compiling pciutils rule. Patch is below and in attachment. Make good use of it ;-) Stephan. Signed-off-by: Stephan Guilloux <stephan.guilloux(a)free.fr> Index: flashrom-patch-Makefile/Makefile =================================================================== --- flashrom-patch-Makefile/Makefile (révision 4171) +++ flashrom-patch-Makefile/Makefile (copie de travail) @@ -65,7 +65,7 @@ echo "struct pci_access *pacc;"; \ echo "int main(int argc, char **argv)"; \ echo "{ pacc = pci_alloc(); return 0; }"; ) > .test.c ) - @$(CC) $(CFLAGS) .test.c -o .test $(LDFLAGS) &>/dev/null && \ + @$(CC) $(CFLAGS) .test.c -o .test $(LDFLAGS) >&/dev/null && \ echo "found." || ( echo "not found."; echo; \ echo "Please install pciutils-devel and zlib-devel."; \ echo "See README for more information."; echo; \

4 4

patch
by ron minnich 24 Apr '09

24 Apr '09

fix horrible bugs in cbfs. My bad. ron

5 7

← Newer
1
...
11
12
13
14
15
16
17
...
59
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 April 2009