coreboot

coreboot@coreboot.org

12 participants
39779 discussions

epia-m IRQ routing
by ron minnich 16 Apr '04

16 Apr '04

kernel 2.4.25 can't use the PIRQ table on epia-m. I think the table is right. Anyone know if the 2.4.25 kernel can handle this router on this board? This is the last hold-up: ethernet irq is not working out. 'No IRQ found ...' ron

2 2

答复: 答复: Broadcom NIC, MPTable and APIC ID for HDAMA [PMX:#]
by YhLu 16 Apr '04

16 Apr '04

The arima's PCI-X ioapic is poorly connected. -----邮件原件----- 发件人: Li-Ta Lo [mailto:ollie@lanl.gov] 发送时间: 2004年4月16日 14:42 收件人: YhLu 抄送: Eric Biederman; LinuxBIOS 主题: Re: 答复: Broadcom NIC, MPTable and APIC ID for HDAMA [PMX:#] On Fri, 2004-04-16 at 11:21, YhLu wrote: > That's decided by HW. > Do you mean even the device is behind the PCIX bridge, it's IRQ is not routed by the APIC on the bridge ? Ollie > YH > > -----邮件原件----- > 发件人: Li-Ta Lo [mailto:ollie@lanl.gov] > 发送时间: 2004年4月16日 10:07 > 收件人: Eric Biederman; LinuxBIOS > 主题: Broadcom NIC, MPTable and APIC ID for HDAMA > > Eric, > > The broadcom nic on hdama is connected behind the 8131. > So the IRQ should be routed by the APIC on 8131, right ? > But in the current mptable.c it is > > /* PCI Ints: Type Polarity > Trigger > Bus ID PCIDEVNUM|IRQ APIC ID PIN# */ > /* On board nics */ > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > bus_8131_1, (0x03<<2)|0, 0x02, 0x13); > smp_write_intsrc(mc, mp_INT, > MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, > bus_8131_1, > (0x04<<2)|0, 0x02, 0x13); > > The IRQ is routed by APIC #2 which is in 8111. Is it correct ? > Why is it still working ? > > Ollie > > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios > _______________________________________________ > Linuxbios mailing list > Linuxbios(a)clustermatic.org > http://www.clustermatic.org/mailman/listinfo/linuxbios >

1 0

答复: Broadcom NIC, MPTable and APIC ID for HDAMA
by YhLu 16 Apr '04

16 Apr '04

That's decided by HW. YH -----邮件原件----- 发件人: Li-Ta Lo [mailto:ollie@lanl.gov] 发送时间: 2004年4月16日 10:07 收件人: Eric Biederman; LinuxBIOS 主题: Broadcom NIC, MPTable and APIC ID for HDAMA Eric, The broadcom nic on hdama is connected behind the 8131. So the IRQ should be routed by the APIC on 8131, right ? But in the current mptable.c it is /* PCI Ints: Type Polarity Trigger Bus ID PCIDEVNUM|IRQ APIC ID PIN# */ /* On board nics */ smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x03<<2)|0, 0x02, 0x13); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x04<<2)|0, 0x02, 0x13); The IRQ is routed by APIC #2 which is in 8111. Is it correct ? Why is it still working ? Ollie _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

答复: 答复: epia-m IRQ routing
by YhLu 16 Apr '04

16 Apr '04

2.4.22 is the most stabe one. -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2004年4月16日 13:56 收件人: YhLu 抄送: linuxbios(a)clustermatic.org 主题: Re: 答复: epia-m IRQ routing On Fri, 16 Apr 2004, YhLu wrote: > Why just try 2.4.26? I'm stuck to this version for now. I can't try .26 ron

1 0

答复: epia-m IRQ routing
by YhLu 16 Apr '04

16 Apr '04

Why just try 2.4.26? Only tg3.c has problem in opteron MB. YH -----邮件原件----- 发件人: ron minnich [mailto:rminnich@lanl.gov] 发送时间: 2004年4月16日 12:22 收件人: linuxbios(a)clustermatic.org 主题: epia-m IRQ routing kernel 2.4.25 can't use the PIRQ table on epia-m. I think the table is right. Anyone know if the 2.4.25 kernel can handle this router on this board? This is the last hold-up: ethernet irq is not working out. 'No IRQ found ...' ron _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

Broadcom NIC, MPTable and APIC ID for HDAMA
by Li-Ta Lo 16 Apr '04

16 Apr '04

Eric, The broadcom nic on hdama is connected behind the 8131. So the IRQ should be routed by the APIC on 8131, right ? But in the current mptable.c it is /* PCI Ints: Type Polarity Trigger Bus ID PCIDEVNUM|IRQ APIC ID PIN# */ /* On board nics */ smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x03<<2)|0, 0x02, 0x13); smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_DEFAULT|MP_IRQ_POLARITY_DEFAULT, bus_8131_1, (0x04<<2)|0, 0x02, 0x13); The IRQ is routed by APIC #2 which is in 8111. Is it correct ? Why is it still working ? Ollie

1 0

epia-m 1/2 baud rate fix
by Dave Ashley 16 Apr '04

16 Apr '04

The post for fixing the 1/2 baud rate problem on epia-m is here: http://www.clustermatic.org/pipermail/linuxbios/2003-December/006207.html The earlier post mentioned probably had the setserial workaround but this is no good, you don't get 115200 baud or other baud rates that don't go into 57,600 exactly (like 38,400). I'm on vacation this past week in Florida so haven't been able to assist any on the epia-m work. One thing I noticed in Dmitri's patch is it seemed to cut out all my code to initialize the VT1211's hardware monitor (used for temperature + voltage monitoring). Other stuff seemed to be hacked and slashed out that I found necessary, but didn't appear to be replaced elsewhere. When I get back to the office hopefully I can do a cvs checkout of latest version and give it a shot and see if it works for me. It sounds like it is working for everyone else right now, which is good news, so congrats all around. So if it's this far along, it would be nice to get the SPD auto detection working. Maybe the path to that is integrate all these V1 changes into V2 and do it in V2. -Dave

5 10

"IP-Config: Failed to open eth0" on epia-m
by Larry Matter 16 Apr '04

16 Apr '04

sorry if this is off-topic for this list: I just started trying linuxbios because I am unhappy with how long it takes the standard bios to boot over pxe (though it does work nicely). I have built linuxbios from cvs from 8-apr and used etherboot 5.0.8 as the payload. This works and etherboot succesfully loads my kernel (2.4.22) from my tftp server. The kernel however, fails to open eth0 and so the nfs mount of my root parition fails, etc. The exact same kernel with (almost) identical command line, booted over pxe works just fine. I diff'd the output of the kernel startup and found a few things that might be significant: linuxBIOS/etherboot: via-rhine.c:v1.10-LK1.1.19 July-12-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html PCI: No IRQ known for interrupt pin A of device 00:12.0. Please try using pci=biosirq. eth0: VIA VT6102 Rhine-II at 0x1400, 00:40:63:d4:17:70, IRQ 0. eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1. Via BIOS/PXE: via-rhine.c:v1.10-LK1.1.19 July-12-2003 Written by Donald Becker http://www.scyld.com/network/via-rhine.html eth0: VIA VT6102 Rhine-II at 0xec00, 00:40:63:d4:17:70, IRQ 5. eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link 45e1. I say "almost" exact same command line because PXE appends "BOOT_IMA" to it, not sure why. I've googled as much as I know how and have not found anything relevent. If anyone has any ideas I would appreciate it. Thanks, Larry Matter

3 5

答复: FILO 0.4 [PMX:#]
by YhLu 16 Apr '04

16 Apr '04

I just find the fifo can boot the elfimage in the rom. If the etherboot is put in the beginning, Use boot:mem@0xfff80000 can load the Etherboot. Great... YH -----邮件原件----- 发件人: Greg Watson [mailto:gwatson@lanl.gov] 发送时间: 2004年4月12日 5:55 收件人: Stefan Reinauer 抄送: linuxbios(a)clustermatic.org 主题: Re: FILO 0.4 [PMX:#] Stefan, I think this is a great idea. I'll talk it over with Ron and Ollie this week and look at how it might be implemented. Greg On 05/04/2004, at 6:46 AM, Stefan Reinauer wrote: > * Eric W. Biederman <ebiederman(a)lnxi.com> [040405 05:02]: >> If we want to take a snapshot of the source tree of FILO or any other >> bootloader into the LinuxBIOS tree under util. Build that part of the >> build and build a complete romimage that works. I am fine >> with that. It is even reasonable to make it so you can drop in >> external trees like etherboot and have everything build together >> nicely. >> >> Actual linking things together instead of including them together >> is unacceptable. > > What about the following: > > Currently LinuxBIOS divides into 2 fundamental parts: > > 1) hardware initialization > 2) getting and starting the payload > > This second part consists of two parts, again: > > i) elfloader > ii) payload > > Note, this is only one possible design. Maybe, this design is bloated > for some application cases. > > Eric, you want to make a hard cut between what is LinuxBIOS and what is > not. This is generally a good idea, as it keeps the different > initialization steps distinct from reach other. What, if we add another > cut by dividing hardware initialization frin the payload-loader? > > Instead of packing stuff like filo to util, we could do: > > * create a directory loader which can hold all "loaders" > * move the elf loader with a Config.lb to a subdirectory in there > * create other directories for other "loaders" like filo. > > If done right, filo can still be compiled as a payload, or built in if > the win in size is noticable. A target config file could probably > choose > which method to use, without overhead. Also, syncing with other trees, > like Takeshi's filo tree could be fairly easy, too. > > I don't think we really have a conflict in direction here at all. > LinuxBIOS itself should be as small as possible, and the different > parts > should be as independent as possible. But we also want to be a lot more > flexible than the existing solutions.. > >> In addition we have had way to many questions of what is the right >> policy for a bootloader to implement, on this list. I refuse >> to couple that to the LinuxBIOS core. And I don't want some stupid >> policy in there like FILO's that would require me to upgrade >> my firmware just to upgrade my OS. > > Please explain, how is filo worse here than putting linux in flash? > > > Stefan > _______________________________________________ Linuxbios mailing list Linuxbios(a)clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios

2 1

LinuxBios "official" requirements and ROM building again
by Mathieu Deschamps 16 Apr '04

16 Apr '04

I've ty to build rom on a other Machine with RH9 Le mar 13/04/2004 à 15:47, Stefan Reinauer a écrit : > * Mathieu Deschamps <mdeschamps(a)mangrove-systems.com> [040409 15:53]: > > I've read several documentation on LinuxBios and related > > projects, though I didn't find out a LinuxBios requirements > > "true" paper. I still have the 2.4.xx kernel compiling oriented slab > > that is to say : GNU Make 3.77, ECGS 1.1.2 (GCC 2.91.66), > > Binutils 2.10, util-linux 2.10. > > egcs is pretty much outdated. I've been using: > make-3.80-179 > gcc-3.3.3-33 > binutils-2.15.90.0.1.1-30 > util-linux-2.12-59 > python-2.3.3-65 > But I just dipose: make -3.79.1 gcc 3.2.2 20030222 (Red Hat Linux 3.2.2-5) bintutils version 2.13.90.0.1 util-linux-2.11y Python 2.2.2 I got this output : ###################################################################### cp /home/root/projet/freebios/freebios2/src/arch/i386/config/crt0.base crt0.S gcc -no-gcc -x assembler-with-cpp -DASSEMBLY -E -I/home/root/projet/freebios/freebios2/src -D__ROMCC__=0 -D__ROMCC_MINOR__=38 -I/home/root/projet/freebios/freebios2/src/include -I/home/root/projet/freebios/freebios2/src/arch/i386/include -I -DARCH='i386' -DCROSS_COMPILE -DCC='gcc' -DHOSTCC='gcc' -DOBJCOPY='objcopy' -DLINUXBIOS_VERSION='1.1.6' -DLINUXBIOS_BUILD='mer avr 14 09:46:21 CEST 2004' -DLINUXBIOS_COMPILE_TIME='09:46:21' -DLINUXBIOS_COMPILE_BY='root' -DLINUXBIOS_COMPILE_HOST='Calliphara' -DLINUXBIOS_COMPILE_DOMAIN -DLINUXBIOS_COMPILER='version gcc 3.2.2 20030222 (Red Hat Linux 3.2.2-5)' -DLINUXBIOS_LINKER='GNU ld version 2.13.90.0.18 20030206' -DLINUXBIOS_ASSEMBLER='Version de l'assembleur GNU 2.13.90.0.18 (i386-redhat-linux) utilisant la version BFD 2.13.90.0.18 20030206' -DHAVE_FALLBACK_BOOT='1' -DROM_IMAGE_SIZE='0x10000' -DPAYLOAD_SIZE='0x10000' -D_ROMBASE='0xffff0000' -D_RESET='0xffff0000' -D_EXCEPTION_VECTORS='0xffff0100' -DSTACK_SIZE='0x4000' -DHEAP_SIZE='0x8000' -D_RAMBASE='0x4000' -DCONFIG_COMPRESS='1' -DCONFIG_UNCOMPRESSED='0' -DCONFIG_LB_MEM_TOPK='1024' -DHAVE_OPTION_TABLE='1' -DUSE_OPTION_TABLE='0' -DLB_CKS_RANGE_START='49' -DLB_CKS_RANGE_END='125' -DLB_CKS_LOC='126' -DCRT0='/home/root/projet/freebios/freebios2/src/arch/i386/config/crt0.base' -DDEBUG='1' -DCONFIG_CONSOLE_VGA='1' -DCONFIG_CONSOLE_LOGBUF='0' -DCONFIG_CONSOLE_SROM='0' -DCONFIG_CONSOLE_SERIAL8250='1' -DDEFAULT_CONSOLE_LOGLEVEL='7' -DMAXIMUM_CONSOLE_LOGLEVEL='7' -DCONFIG_SERIAL_POST='1' -DTTYS0_BASE='0x3f8' -DTTYS0_BAUD='19200' -DTTYS0_LCS='0x3' -DMAINBOARD='/home/root/projet/freebios/freebios2/src/mainboard/via/epia' -DMAINBOARD_PART_NUMBER='epia' -DMAINBOARD_VENDOR='via' -DCONFIG_SMP='0' -DCONFIG_MAX_CPUS='1' -DCONFIG_MAX_PHYSICAL_CPUS='1' -DCONFIG_LOGICAL_CPUS='0' -DCONFIG_IDE_STREAM='0' -DCONFIG_ROM_STREAM='1' -DCONFIG_ROM_STREAM_START='0xfffe0000' -DCONFIG_FS_STREAM='0' -DCONFIG_FS_EXT2='0' -DCONFIG_FS_ISO9660='0' -DCONFIG_FS_FAT='0' -DAUTOBOOT_DELAY='2' -DAUTOBOOT_CMDLINE='"hdc1:/vmlinuz root=/dev/hdc3 console=tty0 console=ttyS0,115200"' -DCONFIG_IDE='1' -DIDE_BOOT_DRIVE='0' -DIDE_OFFSET='0' -DHARD_RESET_BUS='1' -DHARD_RESET_DEVICE='5' -DHARD_RESET_FUNCTION='0' -DMAX_RE! BOOT_CNT='10' -DFAKE_SPDROM='0' -DHAVE_ACPI_TABLES='0' -DCONFIG_CHIP_CONFIGURE='1' -DCPU_FIXUP='1' -DCONFIG_UDELAY_TSC='0' -Di686='1' -Di586='1' -DINTEL_PPRO_MTRR='1' -DROM_SIZE='0x40000' -DFALLBACK_SIZE='0x20000' -DUSE_FALLBACK_IMAGE='1' -DLINUXBIOS_EXTRA_VERSION='.0Fallback' -DHAVE_MP_TABLE='0' -DHAVE_HARD_RESET='1' -DHAVE_PIRQ_TABLE='1' -DIRQ_SLOT_COUNT='5' -DROM_SECTION_SIZE='0x20000' -DROM_SECTION_OFFSET='0x20000' -DXIP_ROM_SIZE='0x10000' -DXIP_ROM_BASE='0xffff0000' /home/root/projet/freebios/freebios2/src/mainboard/via/epia/failover.c > ./failover.E #*#/bin/sh: -c: line 1: syntax error near unexpected token `(' #*#/bin/sh: -c: line 1: `gcc -no-gcc -x assembler-with-cpp -DASSEMBLY -E -I/home/root/projet/freebios/freebios2/src -D__ROMCC__=0 -D__ROMCC_MINOR__=38 -I/home/root/projet/freebios/freebios2/src/include -I/home/root/projet/freebios/freebios2/src/arch/i386/include -I -DARCH='i386' -DCROSS_COMPILE -DCC='gcc' -DHOSTCC='gcc' -DOBJCOPY='objcopy' -DLINUXBIOS_VERSION='1.1.6' -DLINUXBIOS_BUILD='mer avr 14 09:46:21 CEST 2004' -DLINUXBIOS_COMPILE_TIME='09:46:21' -DLINUXBIOS_COMPILE_BY='root' -DLINUXBIOS_COMPILE_HOST='Calliphara' -DLINUXBIOS_COMPILE_DOMAIN -DLINUXBIOS_COMPILER='version gcc 3.2.2 20030222 (Red Hat Linux 3.2.2-5)' -DLINUXBIOS_LINKER='GNU ld version 2.13.90.0.18 20030206' -DLINUXBIOS_ASSEMBLER='Version de l'assembleur GNU 2.13.90.0.18 (i386-redhat-linux) utilisant la version BFD 2.13.90.0.18 20030206' -DHAVE_FALLBACK_BOOT='1' -DROM_IMAGE_SIZE='0x10000' -DPAYLOAD_SIZE='0x10000' -D_ROMBASE='0xffff0000' -D_RESET='0xffff0000' -D_EXCEPTION_VECTORS='0xffff0100' -DSTACK_SIZE='0x4000' -DHEAP_SIZE='0x8000' -D_RAMBASE='0x4000' -DCONFIG_COMPRESS='1' -DCONFIG_UNCOMPRESSED='0' -DCONFIG_LB_MEM_TOPK='1024' -DHAVE_OPTION_TABLE='1' -DUSE_OPTION_TABLE='0' -DLB_CKS_RANGE_START='49' -DLB_CKS_RANGE_END='125' -DLB_CKS_LOC='126' -DCRT0='/home/root/projet/freebios/freebios2/src/arch/i386/config/crt0.base' -DDEBUG='1' -DCONFIG_CONSOLE_VGA='1' -DCONFIG_CONSOLE_LOGBUF='0' -DCONFIG_CONSOLE_SROM='0' -DCONFIG_CONSOLE_SERIAL8250='1' -DDEFAULT_CONSOLE_LOGLEVEL='7' -DMAXIMUM_CONSOLE_LOGLEVEL='7' -DCONFIG_SERIAL_POST='1' -DTTYS0_BASE='0x3f8' -DTTYS0_BAUD='19200' -DTTYS0_LCS='0x3' -DMAINBOARD='/home/root/projet/freebios/freebios2/src/mainboard/via/epia' -DMAINBOARD_PART_NUMBER='epia' -DMAINBOARD_VENDOR='via' -DCONFIG_SMP='0' -DCONFIG_MAX_CPUS='1' -DCONFIG_MAX_PHYSICAL_CPUS='1' -DCONFIG_LOGICAL_CPUS='0' -DCONFIG_IDE_STREAM='0' -DCONFIG_ROM_STREAM='1' -DCONFIG_ROM_STREAM_START='0xfffe0000' -DCONFIG_FS_STREAM='0' -DCONFIG_FS_EXT2='0' -DCONFIG_FS_ISO9660='0' -DCONFIG_FS_FAT='0' -DAUTOBOOT_DELAY='2' -DAUTOBOOT_CMDLINE='"hdc1:/vmlinuz root=/dev/hdc3 console=tty0 console=ttyS0,115200"' -DCONFIG_IDE='1' -DIDE_BOOT_DRIVE='0' -DIDE_OFFSET='0' -DHARD_RESET_BUS='1' -DHARD_RESET_DEVICE='5' -DHARD_RESET_FUNCTION='0' -DMAX_RE! BOOT_CNT='10' -DFAKE_SPDROM='0' -DHAVE_ACPI_TABLES='0' -DCONFIG_CHIP_CONFIGURE='1' -DCPU_FIXUP='1' -DCONFIG_UDELAY_TSC='0' -Di686='1' -Di586='1' -DINTEL_PPRO_MTRR='1' -DROM_SIZE='0x40000' -DFALLBACK_SIZE='0x20000' -DUSE_FALLBACK_IMAGE='1' -DLINUXBIOS_EXTRA_VERSION='.0Fallback' -DHAVE_MP_TABLE='0' -DHAVE_HARD_RESET='1' -DHAVE_PIRQ_TABLE='1' -DIRQ_SLOT_COUNT='5' -DROM_SECTION_SIZE='0x20000' -DROM_SECTION_OFFSET='0x20000' -DXIP_ROM_SIZE='0x10000' -DXIP_ROM_BASE='0xffff0000' /home/root/projet/freebios/freebios2/src/mainboard/via/epia/failover.c > ./failover.E' make: *** [failover.E] Erreur 2 ######################################################################### first the make process now recognize the make functions (it seems anyway) but second, I still have these errors, it seems like a bad parse isn't it ? Make v3.79 isn't good enough ? /bin/sh: -c: line 1: syntax error near unexpected token `(' /bin/sh: -c: line 1: `gcc -no-gcc -x assembler-with-cpp -DASSEMBLY -E Note : I've step deeper into fallback directory where make echo does this error which is correlate to the upper one : #######################################################" . . . HAVE_ACPI_TABLES=0 HAVE_FALLBACK_BOOT=1 HAVE_HARD_RESET=1 HAVE_MP_TABLE=0 HAVE_OPTION_TABLE=1 HAVE_PIRQ_TABLE=1 HEAP_SIZE=0x8000 HOSTCC=gcc IDE_BOOT_DRIVE=0 IDE_OFFSET=0 IDE_SWAB= INTEL_PPRO_MTRR=1 IRQ_SLOT_COUNT=5 ISA_IO_BASE= ISA_MEM_BASE= LB_CKS_LOC=126 LB_CKS_RANGE_END=125 LB_CKS_RANGE_START=49 /bin/sh: -c: line 1: syntax error near unexpected token `(' /bin/sh: -c: line 1: `echo LINUXBIOS_ASSEMBLER='Version de l'assembleur GNU 2.13.90.0.18 (i386-redhat-linux) utilisant la version BFD 2.13.90.0.18 20030206'' make: *** [echo] Erreur 2 ####################################################################" Makefile.settings export : export LINUXBIOS_ASSEMBLER:=$(shell touch dummy.s ; $(CC) -c -Wa,-v dummy.s 2>&1; rm -f dummy.s dummy.o ) well Ron ...I've got another one :) there must be another way to gain gcc -Wa version ... :/ > Also I had a quite old python version (1.1 or so), i got it updated > > to 2.2.3 when I've seen the python script insulted me while running > > buildtarget. > > Anything older than 2.1 won't work. endly, I get confused Stefan : you said you made it with python-2.3.3-65 and then you said "Anything older than 2.1 won't work." I must have dropped the purse before the coin would:)

2 1

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