From yinghailu at gmail.com  Sun Jan  1 00:16:54 2006
From: yinghailu at gmail.com (yhlu)
Date: Sat, 31 Dec 2005 15:16:54 -0800
Subject: [LinuxBIOS] Public request for a LinuxBIOS for VMware
In-Reply-To: <1187.1136068565@www71.gmx.net>
References: <1187.1136068565@www71.gmx.net>
Message-ID: <2ea3fae10512311516r1d9752c6hdbe5ec02fc57d3e1@mail.gmail.com>

Using VMware to debug BIOS?

Then it may need virtuallization layer like the real HW.

For AMD opteron platform, I can use SimNow to debug LinuxBIOS,
including RAM initializaition....

Also the LinuxBIOS rely on serial port, there is pipe in SimNow to
direct the serial port output....

YH

On 12/31/05, Borg No. One <borg_no.one at gmx.net> wrote:
> Hi.
>
> 1.)
> Is there someone who
> + already built a LinuxBIOS/OpenBIOS for VMware?
> + is interested in building a LinuxBIOS/OpenBIOS for VMware?
>
> then please let the LinuxBIOS/OpenBIOS community and me know about your
> work.
>
>
>
> 2.)
> If you think: "How to use 3rd party / modified BIOS in VMware"
> after reading the question(s) above, then you should check following links:
>
> http://www.vmware.com/community/message.jspa?messageID=103265#103265
> http://www.vmware.com/community/thread.jspa?threadID=28149&tstart=0
> http://www.wimsbios.com/phpBB2/viewtopic.php?p=33730&
> http://vmware.itst.org/viewtopic.php?p=10881
> http://www.google.de/search?q=bios440
>
> --
> DSL-Aktion wegen gro?er Nachfrage bis 28.2.2006 verl?ngert:
> GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
>
>
>
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
>



From mac68k at gmail.com  Sun Jan  1 09:11:19 2006
From: mac68k at gmail.com (unknown user)
Date: Sun, 1 Jan 2006 17:11:19 +0900
Subject: [LinuxBIOS] Is my Geode GX1 support?
Message-ID: <6350a3ab0601010011o24b8635cl@mail.gmail.com>

CPU: National Semiconductor Geode GX1 266Mhz
Mainboard Chipset: National Semiconductor CS5530A
I dunno what chipset use in SuperIO chipset. Sorry.

root at xxxx:~# lspci -vvv
0000:00:00.0 Host bridge: Cyrix Corporation PCI Master
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

0000:00:0e.0 Ethernet controller: National Semiconductor Corporation DP83815
(MacPhyter) Ethernet Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (63750ns min, 63750ns max)
        Interrupt: pin A routed to IRQ 15
        Region 0: I/O ports at f800 [size=256]
        Region 1: Memory at fedff000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled] [size=64K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=320mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME+

0000:00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] (rev 30)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64, Cache Line Size: 0x04 (16 bytes)

0000:00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua]
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Region 0: Memory at 40012000 (32-bit, non-prefetchable) [size=256]

0000:00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua] (prog-if 80
[Master])
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Region 4: I/O ports at fc00 [size=16]

0000:00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio
[Kahlua]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Region 0: Memory at 40011000 (32-bit, non-prefetchable) [size=128]

0000:00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video
[Kahlua] (prog-if 00 [VGA])
        Subsystem: Cyrix Corporation: Unknown device 0001
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Region 0: Memory at 40800000 (32-bit, non-prefetchable) [size=8M]

0000:00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB
(rev 06) (prog-if 10 [OHCI])
        Subsystem: Compaq Computer Corporation ZFMicro Chipset USB
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at fedfe000 (32-bit, non-prefetchable) [size=4K]

here is more infomation http://kil13r.info/hardware.html (crowled by lshw
util)

sorry for my poor english.

- Chae Jong-bin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060101/321fc58b/attachment.html>

From chris at suehsi.de  Sun Jan  1 12:13:17 2006
From: chris at suehsi.de (=?ISO-8859-1?Q?Christian_S=FChs?=)
Date: Sun, 01 Jan 2006 12:13:17 +0100
Subject: [LinuxBIOS] Is my Geode GX1 support?
In-Reply-To: <6350a3ab0601010011o24b8635cl@mail.gmail.com>
References: <6350a3ab0601010011o24b8635cl@mail.gmail.com>
Message-ID: <43B7B94D.9020609@suehsi.de>

unknown user schrieb:
> CPU: National Semiconductor Geode GX1 266Mhz
> Mainboard Chipset: National Semiconductor CS5530A
> I dunno what chipset use in SuperIO chipset. Sorry.
> 
Have a look at the  LinuxBios sources under amd.
AMD has take over the national semiconducter stuff.

The chipset and cpu should be nearly the same.

chris



From mac68k at gmail.com  Mon Jan  2 08:17:25 2006
From: mac68k at gmail.com (unknown user)
Date: Mon, 2 Jan 2006 16:17:25 +0900
Subject: [LinuxBIOS] Is my Geode GX1 support?
In-Reply-To: <43B7B94D.9020609@suehsi.de>
References: <6350a3ab0601010011o24b8635cl@mail.gmail.com>
	<43B7B94D.9020609@suehsi.de>
Message-ID: <6350a3ab0601012317r46408fa4o@mail.gmail.com>

Thanks for advice.

- Chae Jong-bin



From smithbone at gmail.com  Tue Jan  3 18:32:13 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 3 Jan 2006 11:32:13 -0600
Subject: [LinuxBIOS] Fwd: [Linux-fbdev-devel] gx1fb: (try to) play nicer
	with various BIOSes
In-Reply-To: <43BAA3E4.40802@arcom.com>
References: <43BAA3E4.40802@arcom.com>
Message-ID: <8a0c36780601030932r495ee4yd31c9d92cb4ca444@mail.gmail.com>

This came across the linux-fb-dev list.

I know some people are using the GX1 so I'm posting it here.

---------- Forwarded message ----------
From: David Vrabel <dvrabel at arcom.com>
Date: Jan 3, 2006 10:18 AM
Subject: [Linux-fbdev-devel] gx1fb: (try to) play nicer with various BIOSes
To: linux-fbdev-devel list <linux-fbdev-devel at lists.sourceforge.net>


Hi,

Seems that the CS5530A chip used in Geode GX1 systems has some crazy
feature that causes SMI traps when accessing the PCI configuration space
of the video device.  Various GX1 BIOSes seem to use this 'feature' to
hide the real BARs of the device.  This patch disables these traps (in
an  early PCI fixup) so that Linux sees the real, physical BARs and not
the virtual ones provided by the BIOS.

This should allow the GX1 framebuffer driver to work on more systems
that have different BIOSes as the driver no longer guesses at what the
virtual BARs mean.

I'm not entirely sure it the correct solution as I can neither test
regular VGA console nor the X's 'cyrix' video driver so there might be
some breakage there -- probably best to get some more testers before
applying it.

David Vrabel
--
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/


Index: linux-2.6-working/arch/i386/pci/fixup.c
===================================================================
--- linux-2.6-working.orig/arch/i386/pci/fixup.c        2006-01-03
08:46:51.000000000 +0000
+++ linux-2.6-working/arch/i386/pci/fixup.c     2006-01-03
15:59:54.000000000 +0000
@@ -442,3 +442,19 @@
 }
 DECLARE_PCI_FIXUP_ENABLE(PCI_VENDOR_ID_TI, 0x8032,
                         pci_post_fixup_toshiba_ohci1394);
+
+
+/*
+ * Prevent the BIOS trapping accesses to the Cyrix CS5530A video device
+ * configuration space.
+ */
+static void __devinit pci_early_fixup_cyrix_5530(struct pci_dev *dev)
+{
+       u8 r;
+       /* clear 'F4 Video Configuration Trap' bit */
+       pci_read_config_byte(dev, 0x42, &r);
+       r &= 0xfd;
+       pci_write_config_byte(dev, 0x42, r);
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_CYRIX, PCI_DEVICE_ID_CYRIX_5530_LEGACY,
+                       pci_early_fixup_cyrix_5530);
Index: linux-2.6-working/drivers/video/geode/gx1fb_core.c
===================================================================
--- linux-2.6-working.orig/drivers/video/geode/gx1fb_core.c    
2006-01-03 08:46:54.000000000 +0000
+++ linux-2.6-working/drivers/video/geode/gx1fb_core.c  2006-01-03
16:00:43.000000000 +0000
@@ -215,11 +215,11 @@
        if (ret < 0)
                return ret;

-       ret = pci_request_region(dev, 1, "gx1fb (video)");
+       ret = pci_request_region(dev, 0, "gx1fb (video)");
        if (ret < 0)
                return ret;
-       par->vid_regs = ioremap(pci_resource_start(dev, 1),
-                               pci_resource_len(dev, 1));
+       par->vid_regs = ioremap(pci_resource_start(dev, 0),
+                               pci_resource_len(dev, 0));
        if (!par->vid_regs)
                return -ENOMEM;

@@ -229,12 +229,9 @@
        if (!par->dc_regs)
                return -ENOMEM;

-       ret = pci_request_region(dev, 0, "gx1fb (frame buffer)");
-       if (ret < 0 )
-               return -EBUSY;
        if ((fb_len = gx1_frame_buffer_size()) < 0)
                return -ENOMEM;
-       info->fix.smem_start = pci_resource_start(dev, 0);
+       info->fix.smem_start = gx_base + 0x800000;
        info->fix.smem_len = fb_len;
        info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
        if (!info->screen_base)




--
Richard A. Smith

From yinghai.lu at amd.com  Tue Jan  3 20:31:47 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 3 Jan 2006 11:31:47 -0800
Subject: [LinuxBIOS] [Etherboot-developers] Universal boot disk etc...
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949AF@ssvlexmb2.amd.com>

Memory limitation?

We can set _RAMBASE to 1M above. I wonder if Etherboot can put the code
in RAM above 1M...

Otherway for universal boot: 
	Tiny kernel with all driver need ---- ramdisk or initramfs to
kexec other kernel....

YH




From ward at gnu.org  Wed Jan  4 00:38:32 2006
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 3 Jan 2006 18:38:32 -0500
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
In-Reply-To: <20051216043022.GA18934@io.pong.be>
References: <20051216043022.GA18934@io.pong.be>
Message-ID: <20060103233832.GA8073@io.pong.be>

Back from the holidays; hope you all enjoyed yours :)

I've been trying a couple more things to get beyond the linuxbios problems
I'm seeing. I've now compiled everything with Gcc 3.4.5, and that did not
solve the problem (previously I had compiled etherboot with Gcc 4/linuxbios
with 3.4.5).

I've also updated to the latest SVN tree (2148) - no changes there it seems
except for a few in the flashrom directory.

I'm attaching a new serial output which shows linuxbios just giving up
(resetting?) near the end of the boot sequence (right after the software raid
array is loaded, which immediately starts syncing; it is still dirty).
Compare with the serial log below that I added to my previous message; there
it got slightly further in the boot sequence than this time.

I'm intrigued by how LinuxBIOS seems to reset itself at the start of the boot
as well; is this normal? It doesn't do it always, I tried several times, and
sometimes it does, sometimes it doesn't.

Debugging suggestions welcome :)

Thanks,
Ward.

On Thu, Dec 15, 2005 at 11:30:22PM -0500, Ward Vandewege wrote:
> So, with some help from Yinghai today, I finally managed to make my own
> working LinuxBIOS image, and boot it on the s2881. Fantastic!
> 
> It cut boot time roughly in half - and that's without doing any optimizing of
> the init startup sequence, which now takes up the bulk of the bootup time.
> 
> Anyway. Once the system booted, I tested network access and a few other
> things, and everything seemed to work just fine.
> 
> But 10 minutes later the machine was no longer pingable, and I didn't get any
> response on the serial console anymore either.
> 
> I shut it down, and restarted with LinuxBIOS. At this point, it would not
> boot anymore - as you can see in the attached serial log, it just decides to
> restart its fallback image just after init starts, which then hangs the box.
> 
> Any clues? This is the latest svn revision (2145), with Etherboot 5.4.1 +
> FILO to boot from the local SATA drive.
> 
> I rebooted with the proprietary BIOS, which brought the box up just fine
> (after complaining that it had to reset the CMOS). It started re-syncing the
> software RAID array right after boot though, so maybe that is related to the
> linuxBIOS hang upon boot, which is right after the kernel starts the RAID
> devices?
> 
> I won't be able to work more on the box for the next week or two
> (holidays...), but I thought I'd better signal this now.
> 
> Thanks,
> Ward.
> 
> --
> Ward Vandewege <ward at fsf.org>
> Free Software Foundation - Senior System Administrator

> 
> 
> LinuxBIOS-1.1.8_s2881_Fallback Thu Dec 15 18:45:48 EST 2005 starting...
> (0,1) link=00
> (1,0) link=00
> 02 nodes initialized.
>  core0:  --- {  APICID = 02 NODEID = 01 COREID = 00} ---
> SBLink=02
> NC node|link=02
> ht reset -
> 
> 
> LinuxBIOS-1.1.8_s2881_Fallback Thu Dec 15 18:45:48 EST 2005 starting...
> (0,1) link=00
> (1,0) link=00
> 02 nodes initialized.
>  core0:  --- {  APICID = 02 NODEID = 01 COREID = 00} ---
> SBLink=02
> NC node|link=02
> Ram1.00
> Ram1.01
> Ram2.00
> Ram2.01
> Ram3
> Initializing memory:  done
> Initializing memory:  done
> Ram4
> v_esp=000cfd40
> cpu_reset = 00000000
> Clearing initial memory region: No cache as ram now - Use Ram as Stack now - done
> new_cpu_reset = 00000000
> Copying LinuxBIOS to ram.
> src=fffe0004
> dst=00004000
> linxbios_ram.bin length = 0001928c
> Jumping to LinuxBIOS.
> LinuxBIOS-1.1.8_s2881_Fallback Thu Dec 15 18:45:48 EST 2005 booting...
> Enumerating buses...
> APIC_CLUSTER: 0 enabled
> PCI_DOMAIN: 0000 enabled
>   PCI: 00:18.3 siblings=1
> CPU: APIC: 00 enabled
> CPU: APIC: 01 enabled
> PCI: 00:19.0 [1022/1100] enabled
> PCI: 00:19.1 [1022/1101] enabled
> PCI: 00:19.2 [1022/1102] enabled
> PCI: 00:19.3 [1022/1103] enabled
>   PCI: 00:19.3 siblings=1
> CPU: APIC: 02 enabled
> CPU: APIC: 03 enabled
> PCI: pci_scan_bus for bus 0
> PCI: 00:18.0 [1022/1100] enabled
> PCI: 00:18.1 [1022/1101] enabled
> PCI: 00:18.2 [1022/1102] enabled
> PCI: 00:18.3 [1022/1103] enabled
> PCI: 00:19.0 [1022/1100] enabled
> PCI: 00:19.1 [1022/1101] enabled
> PCI: 00:19.2 [1022/1102] enabled
> PCI: 00:19.3 [1022/1103] enabled
> PCI: 01:00.0 [1022/7450] enabled
> PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
> PCI: 01:00.0 [1022/7460] enabled
> PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
> PCI: pci_scan_bus for bus 1
> PCI: 01:01.0 [1022/7450] enabled
> PCI: 01:01.1 [1022/7451] enabled
> PCI: 01:02.0 [1022/7450] enabled
> PCI: 01:02.1 [1022/7451] enabled
> PCI: 01:03.0 [1022/7460] enabled
> PCI: 01:04.0 [1022/7468] enabled
> PCI: 01:04.1 [1022/7469] enabled
> PCI: 01:04.2 [1022/746a] enabled
> PCI: 01:04.3 [1022/746b] enabled
> PCI: pci_scan_bus for bus 2
> PCI: 02:09.0 [14e4/1648] enabled
> PCI: 02:09.1 [14e4/1648] enabled
> Disabling static device: PCI: 02:0a.0
> Disabling static device: PCI: 02:0a.1
> PCI: pci_scan_bus returning with max=02
> PCI: 02: 100MHz PCI-X
> PCI: pci_scan_bus for bus 3
> PCI: pci_scan_bus returning with max=03
> PCI: 03: 133MHz PCI-X
> PCI: pci_scan_bus for bus 4
> PCI: 04:00.0 [1022/7464] enabled
> PCI: 04:00.1 [1022/7464] enabled
> PCI: 04:05.0 [1095/3114] enabled
> PCI: 04:06.0 [1002/4752] enabled
> PCI: pci_scan_bus returning with max=04
> PNP: 002e.0 enabled
> PNP: 002e.1 disabled
> PNP: 002e.2 enabled
> PNP: 002e.3 disabled
> PNP: 002e.5 enabled
> PNP: 002e.6 disabled
> PNP: 002e.7 disabled
> PNP: 002e.8 disabled
> PNP: 002e.9 disabled
> PNP: 002e.a disabled
> PNP: 002e.b enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:50 enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:51 enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:52 enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:53 enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:54 enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:55 enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:56 enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:57 enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:2d enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:2a enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:49 enabled
> smbus: PCI: 01:04.3[0]->I2C: 01:4a enabled
> PCI: pci_scan_bus returning with max=04
> PCI: pci_scan_bus returning with max=04
> done
> Allocating resources...
> Reading resources...
> PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
> PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
> PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
> Done reading resources.
> Setting resources...
> PCI: 00:18.0 1ba <- [0x00fd300000 - 0x00fd2fffff] prefmem <node 0 link 2>
> PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000002fff] io <node 0 link 2>
> PCI: 00:18.0 1b2 <- [0x00fc000000 - 0x00fd2fffff] mem <node 0 link 2>
> PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 2 mem
> PCI: 02:09.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem64
> PCI: 02:09.0 18 <- [0x00fd110000 - 0x00fd11ffff] mem64
> PCI: 02:09.1 10 <- [0x00fd120000 - 0x00fd12ffff] mem64
> PCI: 02:09.1 18 <- [0x00fd130000 - 0x00fd13ffff] mem64
> PCI: 01:01.1 10 <- [0x00fd200000 - 0x00fd200fff] mem64
> PCI: 01:02.1 10 <- [0x00fd201000 - 0x00fd201fff] mem64
> PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io
> PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 mem
> PCI: 04:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem
> PCI: 04:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem
> PCI: 04:05.0 10 <- [0x0000001410 - 0x0000001417] io
> PCI: 04:05.0 14 <- [0x0000001430 - 0x0000001433] io
> PCI: 04:05.0 18 <- [0x0000001420 - 0x0000001427] io
> PCI: 04:05.0 1c <- [0x0000001440 - 0x0000001443] io
> PCI: 04:05.0 20 <- [0x0000001400 - 0x000000140f] io
> PCI: 04:05.0 24 <- [0x00fd003000 - 0x00fd0033ff] mem
> PCI: 04:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
> PCI: 04:06.0 14 <- [0x0000001000 - 0x00000010ff] io
> PCI: 04:06.0 18 <- [0x00fd002000 - 0x00fd002fff] mem
> PCI: 04:06.0 30 <- [0x00fff80000 - 0x00fff9ffff] romem
> PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
> PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
> PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
> PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
> PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
> PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
> PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
> PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
> PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq
> PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] io
> PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq
> PCI: 01:04.1 20 <- [0x0000002420 - 0x000000242f] io
> PCI: 01:04.2 10 <- [0x0000002400 - 0x000000241f] io
> PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io
> PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
> Done setting resources.
> Done allocating resources.
> Enabling resourcess...
> PCI: 00:18.0 cmd <- 140
> PCI: 01:01.0 bridge ctrl <- 0003
> PCI: 01:01.0 cmd <- 146
> PCI: 02:09.0 subsystem <- 10f1/2881
> PCI: 02:09.0 cmd <- 142
> PCI: 02:09.1 subsystem <- 10f1/2881
> PCI: 02:09.1 cmd <- 142
> PCI: 01:01.1 subsystem <- 10f1/2881
> PCI: 01:01.1 cmd <- 146
> PCI: 01:02.1 subsystem <- 10f1/2881
> PCI: 01:02.1 cmd <- 146
> PCI: 01:03.0 bridge ctrl <- 0003
> PCI: 01:03.0 cmd <- 147
> PCI: 04:00.0 subsystem <- 10f1/2881
> PCI: 04:00.0 cmd <- 142
> PCI: 04:00.1 subsystem <- 10f1/2881
> PCI: 04:00.1 cmd <- 142
> PCI: 04:05.0 subsystem <- 10f1/2881
> PCI: 04:05.0 cmd <- 143
> PCI: 04:06.0 subsystem <- 10f1/2881
> PCI: 04:06.0 cmd <- 1c3
> PCI: 01:04.0 subsystem <- 10f1/2881
> PCI: 01:04.0 cmd <- 14f
> w83627hf hwm smbus enabled
> PCI: 01:04.1 subsystem <- 10f1/2881
> PCI: 01:04.1 cmd <- 141
> PCI: 01:04.2 subsystem <- 10f1/2881
> PCI: 01:04.2 cmd <- 141
> PCI: 01:04.3 subsystem <- 10f1/2881
> PCI: 01:04.3 cmd <- 141
> PCI: 00:18.1 subsystem <- 10f1/2881
> PCI: 00:18.1 cmd <- 140
> PCI: 00:18.2 subsystem <- 10f1/2881
> PCI: 00:18.2 cmd <- 140
> PCI: 00:18.3 cmd <- 140
> PCI: 00:19.0 cmd <- 140
> PCI: 00:19.1 cmd <- 140
> PCI: 00:19.2 cmd <- 140
> PCI: 00:19.3 cmd <- 140
> done.
> Initializing devices...
> Root Device init
> APIC_CLUSTER: 0 init
> Initializing CPU #0
> CPU: vendor AMD device 20f12
> Enabling cache
> 
> Setting fixed MTRRs(0-88) type: UC
> Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
> Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
> DONE fixed MTRRs
> Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
> Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
> Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
> DONE variable MTRRs
> Clear out the extra MTRR's
> 
> MTRR check
> Fixed MTRRs   : Enabled
> Variable MTRRs: Enabled
> 
> microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
> microcode: patch id that want to apply= 0x0000004d
> microcode: updated to patch id = 0x0000004d  success
> Setting up local apic... apic_id: 0 done.
> Clearing memory 1024K - 2097152K: ------------------------------- done
> CPU #0 Initialized
> start_eip=0x00010000
> Initializing CPU #1
> CPU: vendor AMD device 20f12
> Enabling cache
> 
> Setting fixed MTRRs(0-88) type: UC
> Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
> Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
> DONE fixed MTRRs
> Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
> Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
> Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
> DONE variable MTRRs
> Clear out the extra MTRR's
> 
> MTRR check
> Fixed MTRRs   : Enabled
> Variable MTRRs: Enabled
> 
> microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
> microcode: patch id that want to apply= 0x0000004d
> microcode: updated to patch id = 0x0000004d  success
> Setting up local apic... apic_id: 1 done.
> CPU #1 Initialized
> start_eip=0x00010000
> Initializing CPU #2
> CPU: vendor AMD device 20f12
> Enabling cache
> 
> Setting fixed MTRRs(0-88) type: UC
> Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
> Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
> DONE fixed MTRRs
> Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
> Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
> Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
> DONE variable MTRRs
> Clear out the extra MTRR's
> 
> MTRR check
> Fixed MTRRs   : Enabled
> Variable MTRRs: Enabled
> 
> microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
> microcode: patch id that want to apply= 0x0000004d
> microcode: updated to patch id = 0x0000004d  success
> Setting up local apic... apic_id: 2 done.
> Clearing memory 2097152K - 5242880K: ----------------++++++++++++++++ done
> CPU #2 Initialized
> start_eip=0x00010000
> Initializing CPU #3
> Waiting for 1 CPUS to stop
> CPU: vendor AMD device 20f12
> Enabling cache
> 
> Setting fixed MTRRs(0-88) type: UC
> Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
> Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
> DONE fixed MTRRs
> Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
> Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
> Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
> DONE variable MTRRs
> Clear out the extra MTRR's
> 
> MTRR check
> Fixed MTRRs   : Enabled
> Variable MTRRs: Enabled
> 
> microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
> microcode: patch id that want to apply= 0x0000004d
> microcode: updated to patch id = 0x0000004d  success
> Setting up local apic... apic_id: 3 done.
> CPU #3 Initialized
> All AP CPUs stopped
> PCI: 00:18.0 init
> PCI: 01:01.0 init
> PCI: 02:09.0 init
> PCI: 02:09.1 init
> PCI: 01:03.0 init
> PCI: 04:05.0 init
> PCI: 04:06.0 init
> PCI: 01:04.0 init
> RTC Init
> Invalid CMOS LB checksum
> enabling HPET @0xfed00000
> PNP: 002e.0 init
> PNP: 002e.2 init
> PNP: 002e.5 init
> PNP: 002e.b init
> PCI: 01:04.1 init
> IDE1 IDE0 PCI: 01:04.3 init
> set power on after power fail
> smbus: PCI: 01:04.3[0]->I2C: 01:2d init
> PCI: 00:18.1 init
> PCI: 00:18.2 init
> PCI: 00:18.3 init
> NB: Function 3 Misc Control.. done.
> PCI: 00:19.0 init
> PCI: 00:19.1 init
> PCI: 00:19.2 init
> PCI: 00:19.3 init
> NB: Function 3 Misc Control.. done.
> Devices initialized
> Writing IRQ routing tables to 0xf0000...done.
> Wrote the mp table end at: 00000020 - 000001f4
> Moving GDT to 0x500...ok
> Wrote linuxbios table at: 00000530 - 00000e1c  checksum 2ea0
> 
> Welcome to elfboot, the open sourced starter.
> January 2002, Eric Biederman.
> Version 1.3
> 
>     33:stream_init() - rom_stream: 0xfffc0000 - 0xfffdffff
> Found ELF candiate at offset 0
> Loading Etherboot version: 5.4.1
> Dropping non PT_LOAD segment
> New segment addr 0x10000 size 0x49100 offset 0x0 filesize 0x9ac0
> (cleaned up) New segment addr 0x10000 size 0x49100 offset 0x0 filesize 0x9ac0
> Loading Segment: addr: 0x00000000bff8c000 memsz: 0x0000000000034000 filesz: 0x0000000000009ac0
> Clearing Segment: addr: 0x00000000bff95ac0 memsz: 0x000000000002a540
> Loading Segment: addr: 0x0000000000044000 memsz: 0x0000000000015100 filesz: 0x0000000000000000
> Clearing Segment: addr: 0x0000000000044000 memsz: 0x0000000000015100
> Jumping to boot code at 0x100b0
> CPU 2063 Mhz
> Etherboot 5.4.1 (GPL) http://etherboot.org
> Drivers: TG3 FILO   Images: NBI ELF   
> Protocols: DHCP TFTP 
> Relocating _text from: [000101b0,00059100) to [bfeb70b0,bff00000)
> Boot from (N)etwork (D)isk or (Q)uit? D
> 
> Probing pci disk...
> [FILO]FILO version 0.4.1 (root at countzero.vandewege.net) Thu Dec 15 18:44:50 EST 2005
> Press <Enter> for default boot, or <Esc> for boot prompt... 2 1 
> boot: hde1:/vmlinuz-2.6.12-9-amd64-generic initrd=/initrd.img-2.6.12-9-amd64-generic ro root=/dev/md3 console=tty0 console=ttyS0,115200n8
> hde: LBA48: WDC WD740GD-00FLC0                      
> hdf: LBA48: WDC WD740GD-00FLC0                      
> Mounted ext2fs
> Found Linux version 2.6.12-9-amd64-generic (buildd at king) #1 Mon Oct 10 13:27:39 BST 2005 bzImage.
> Loading kernel... ok
> Loading initrd... ok
> Jumping to entry point...
> [    0.000000] Bootdata ok (command line is ro root=/dev/md3 console=tty0 console=ttyS0,115200n8)
> [    0.000000] Linux version 2.6.12-9-amd64-generic (buildd at king) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 Mon Oct 10 13:27:39 BST 2005
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  BIOS-e820: 0000000000000000 - 0000000000000e7c type 16
> [    0.000000]  BIOS-e820: 0000000000000e7c - 00000000000a0000 (usable)
> [    0.000000]  BIOS-e820: 00000000000f0000 - 00000000000f0400 type 16
> [    0.000000]  BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
> [    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
> [    0.000000] ACPI: Unable to locate RSDP
> [    0.000000] Intel MultiProcessor Specification v1.4
> [    0.000000]     Virtual Wire compatibility mode.
> [    0.000000] OEM ID: TYAN     <6>Product ID: S2881        <6>APIC at: 0xFEE00000
> [    0.000000] Processor #0 15:1 APIC version 16
> [    0.000000] Processor #1 15:1 APIC version 16
> [    0.000000] WARNING: NR_CPUS limit of 1 reached. Processor ignored.
> [    0.000000] Processor #2 15:1 APIC version 16
> [    0.000000] WARNING: NR_CPUS limit of 1 reached. Processor ignored.
> [    0.000000] Processor #3 15:1 APIC version 16
> [    0.000000] WARNING: NR_CPUS limit of 1 reached. Processor ignored.
> [    0.000000] I/O APIC #4 Version 17 at 0xFEC00000.
> [    0.000000] I/O APIC #5 Version 17 at 0xFD200000.
> [    0.000000] I/O APIC #6 Version 17 at 0xFD201000.
> [    0.000000] Setting APIC routing to flat
> [    0.000000] Processors: 1
> [    0.000000] Allocating PCI resources starting at c0000000 (gap: c0000000:40000000)
> [    0.000000] Checking aperture...
> [    0.000000] CPU 0: aperture @ f8000000 size 64 MB
> [    0.000000] CPU 1: aperture @ f8000000 size 64 MB
> [    0.000000] Built 1 zonelists
> [    0.000000] Kernel command line: ro root=/dev/md3 console=tty0 console=ttyS0,115200n8
> [    0.000000] Initializing CPU#0
> [    0.000000] PID hash table entries: 4096 (order: 12, 131072 bytes)
> [    0.000000] time.c: Using 1.193182 MHz PIT timer.
> [    0.000000] time.c: Detected 1992.086 MHz processor.
> [   13.476890] time.c: Using PIT/TSC based timekeeping.
> [   13.477331] Console: colour dummy device 80x25
> [   13.697387] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
> [   13.712991] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
> [   13.789909] Memory: 4101416k/5242880k available (1620k kernel code, 92332k reserved, 997k data, 136k init)
> [   13.819815] Security Framework v1.0.0 initialized
> [   13.824992] SELinux:  Disabled at boot.
> [   13.829226] Mount-cache hash table entries: 256
> [   13.834275] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
> [   13.842538] CPU: L2 Cache: 1024K (64 bytes/line)
> [   13.847866] CPU:  stepping 02
> [   13.851414] checking if image is initramfs... it is
> [   14.188550] Using IO-APIC 4
> [   14.191771] Using IO-APIC 5
> [   14.194987] Using IO-APIC 6
> [   14.208302] Using local APIC timer interrupts.
> [   14.263629] Detected 12.450 MHz APIC timer.
> [   14.268446] testing NMI watchdog ... OK.
> [   14.282975] NET: Registered protocol family 16
> [   14.288476] PCI: Using configuration type 1
> [   14.293313] mtrr: v2.0 (20020519)
> [   14.297419] ACPI: Subsystem revision 20050729
> [   14.302456] ACPI: Interpreter disabled.
> [   14.306890] Linux Plug and Play Support v0.97 (c) Adam Belay
> [   14.313412] pnp: PnP ACPI: disabled
> [   14.317485] usbcore: registered new driver usbfs
> [   14.322838] usbcore: registered new driver hub
> [   14.328010] PCI: Probing PCI hardware
> [   14.332261] PCI: Probing PCI hardware (bus 00)
> [   14.338761] PCI: Discovered primary peer bus 01 [IRQ]
> [   14.344593] PCI: Using IRQ router default [1022/7468] at 0000:01:04.0
> [   14.352035] PCI->APIC IRQ transform: 0000:01:04.2[D] -> IRQ 19
> [   14.358802] PCI->APIC IRQ transform: 0000:02:09.0[A] -> IRQ 24
> [   14.365533] PCI->APIC IRQ transform: 0000:02:09.1[B] -> IRQ 25
> [   14.372248] PCI->APIC IRQ transform: 0000:04:00.0[D] -> IRQ 19
> [   14.379040] PCI->APIC IRQ transform: 0000:04:00.1[D] -> IRQ 19
> [   14.385808] PCI->APIC IRQ transform: 0000:04:05.0[A] -> IRQ 17
> [   14.392539] PCI->APIC IRQ transform: 0000:04:06.0[A] -> IRQ 18
> [   14.399347] PCI-DMA: Disabling AGP.
> [   14.403460] PCI-DMA: aperture base @ f8000000 size 65536 KB
> [   14.409947] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
> [   14.417699] IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
> [   14.426219] audit: initializing netlink socket (disabled)
> [   14.432466] audit: initialized
> [   14.436078] VFS: Disk quotas dquot_6.5.1
> [   14.440654] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> [   14.448113] devfs: 2004-01-31 Richard Gooch (rgooch at atnf.csiro.au)
> [   14.455261] devfs: boot_options: 0x0
> [   14.459445] Initializing Cryptographic API
> [   14.464203] PCI: MSI quirk detected. pci_msi_quirk set.
> [   14.470274] PCI: MSI quirk detected. pci_msi_quirk set.
> [   14.490389] Linux agpgart interface v0.101 (c) Dave Jones
> [   14.496711] PNP: No PS/2 controller found. Probing ports directly.
> [   14.505346] serio: i8042 AUX port at 0x60,0x64 irq 12
> [   14.511273] serio: i8042 KBD port at 0x60,0x64 irq 1
> [   14.516994] Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
> [   14.526203] ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> [   14.533322] io scheduler noop registered
> [   14.537861] io scheduler anticipatory registered
> [   14.543217] io scheduler deadline registered
> [   14.548185] io scheduler cfq registered
> [   14.552892] RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
> [   14.561690] NET: Registered protocol family 2
> [   14.576640] IP: routing cache hash table of 65536 buckets, 512Kbytes
> [   14.584455] TCP established hash table entries: 524288 (order: 10, 4194304 bytes)
> [   14.596145] TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
> [   14.604232] TCP: Hash tables configured (established 524288 bind 65536)
> [   14.611945] NET: Registered protocol family 8
> [   14.616960] NET: Registered protocol family 20
> [   14.622278] Freeing unused kernel memory: 136k freed
> Loading, please wait...
> Begin: Loading modules ...
> [   14.645287] input: AT Translated Set 2 keyboard on isa0060/serio0
> [   14.657083] Capability LSM initialized
> [   14.669870] NET: Registered protocol family 1
> [   14.686443] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> [   14.693755] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> [   14.707909] AMD8111: IDE controller at PCI slot 0000:01:04.1
> [   14.714477] AMD8111: chipset revision 3
> [   14.718933] AMD8111: not 100% native mode: will probe irqs later
> [   14.725869] AMD8111: 0000:01:04.1 (rev 03) UDMA133 controller
> [   14.732469]     ide0: BM-DMA at 0x2420-0x2427, BIOS settings: hda:pio, hdb:pio
> [   14.740909]     ide1: BM-DMA at 0x2428-0x242f, BIOS settings: hdc:pio, hdd:pio
> [   15.881489] hdd: CD-224E, ATAPI CD/DVD-ROM drive
> [   15.937874] ide1 at 0x170-0x177,0x376 on irq 15
> [   18.513088] hdd: ATAPI 24X CD-ROM drive, 128kB Cache
> [   18.518889] Uniform CD-ROM driver Revision: 3.20
> [   18.772153] tg3.c:v3.31 (June 8, 2005)
> [   18.780608] eth0: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:30:a5:24
> [   18.794116] eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] 
> [   18.803789] eth0: dma_rwctrl[769f4000]
> [   18.818576] eth1: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:30:a5:25
> [   18.832075] eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
> [   18.841730] eth1: dma_rwctrl[769f4000]
> [   18.854427] ohci_hcd 0000:04:00.0: Advanced Micro Devices [AMD] AMD-8111 USB
> [   18.862741] ohci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 1
> [   18.871275] ohci_hcd 0000:04:00.0: irq 19, io mem 0xfd000000
> [   18.930659] hub 1-0:1.0: USB hub found
> [   18.935018] hub 1-0:1.0: 3 ports detected
> [   18.942617] ohci_hcd 0000:04:00.1: Advanced Micro Devices [AMD] AMD-8111 USB (#2)
> [   18.951303] ohci_hcd 0000:04:00.1: new USB bus registered, assigned bus number 2
> [   18.959848] ohci_hcd 0000:04:00.1: irq 19, io mem 0xfd001000
> [   19.018622] hub 2-0:1.0: USB hub found
> [   19.022997] hub 2-0:1.0: 3 ports detected
> [   19.040635] SCSI subsystem initialized
> [   19.047043] ata1: SATA max UDMA/100 cmd 0xFFFFC20000014080 ctl 0xFFFFC2000001408A bmdma 0xFFFFC20000014000 irq 17
> [   19.058983] ata2: SATA max UDMA/100 cmd 0xFFFFC200000140C0 ctl 0xFFFFC200000140CA bmdma 0xFFFFC20000014008 irq 17
> [   19.070913] ata3: SATA max UDMA/100 cmd 0xFFFFC20000014280 ctl 0xFFFFC2000001428A bmdma 0xFFFFC20000014200 irq 17
> [   19.082807] ata4: SATA max UDMA/100 cmd 0xFFFFC200000142C0 ctl 0xFFFFC200000142CA bmdma 0xFFFFC20000014208 irq 17
> [   19.449906] ata1: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
> [   19.458221] ata1: dev 0 configured for UDMA/100
> [   19.463445] scsi0 : sata_sil
> [   19.821814] ata2: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
> [   19.830068] ata2: dev 0 configured for UDMA/100
> [   19.835281] scsi1 : sata_sil
> [   20.193734] ata3: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
> [   20.202017] ata3: dev 0 configured for UDMA/100
> [   20.207255] scsi2 : sata_sil
> [   20.565656] ata4: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
> [   20.573948] ata4: dev 0 configured for UDMA/100
> [   20.579205] scsi3 : sata_sil
> [   20.582618]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
> [   20.589939]   Type:   Direct-Access                      ANSI SCSI revision: 05
> [   20.598797]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
> [   20.606107]   Type:   Direct-Access                      ANSI SCSI revision: 05
> [   20.614984]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
> [   20.622302]   Type:   Direct-Access                      ANSI SCSI revision: 05
> [   20.631150]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
> [   20.638484]   Type:   Direct-Access                      ANSI SCSI revision: 05
> [   22.664450] SCSI device sda: 145226112 512-byte hdwr sectors (74356 MB)
> [   22.672077] SCSI device sda: drive cache: write back
> [   22.677847] SCSI device sda: 145226112 512-byte hdwr sectors (74356 MB)
> [   22.685509] SCSI device sda: drive cache: write back
> [   22.691291]  /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4
> [   22.706480] Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
> [   22.713735] SCSI device sdb: 145226112 512-byte hdwr sectors (74356 MB)
> [   22.721369] SCSI device sdb: drive cache: write back
> [   22.727153] SCSI device sdb: 145226112 512-byte hdwr sectors (74356 MB)
> [   22.734791] SCSI device sdb: drive cache: write back
> [   22.740529]  /dev/scsi/host1/bus0/target0/lun0: p1 p2 p3 p4
> [   22.758728] Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
> [   22.765981] SCSI device sdc: 145226112 512-byte hdwr sectors (74356 MB)
> [   22.773675] SCSI device sdc: drive cache: write back
> [   22.779461] SCSI device sdc: 145226112 512-byte hdwr sectors (74356 MB)
> [   22.787123] SCSI device sdc: drive cache: write back
> [   22.792871]  /dev/scsi/host2/bus0/target0/lun0: p1 p2 p3 p4
> [   22.812560] Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0
> [   22.819822] SCSI device sdd: 145226112 512-byte hdwr sectors (74356 MB)
> [   22.827507] SCSI device sdd: drive cache: write back
> [   22.833316] SCSI device sdd: 145226112 512-byte hdwr sectors (74356 MB)
> [   22.841024] SCSI device sdd: drive cache: write back
> [   22.846788]  /dev/scsi/host3/bus0/target0/lun0: p1 p2 p3 p4
> [   22.867064] Attached scsi disk sdd at scsi3, channel 0, id 0, lun 0
> Done.
> Begin: Initializing /dev ...
> Done.
> Begin: Running /scripts/init-premount ...
> FATAL: Error inserting fan (/lib/modules/2.6.12-9-amd64-generic/kernel/drivers/acpi/fan.ko): No such device
> FATAL: Error inserting thermal (/lib/modules/2.6.12-9-amd64-generic/kernel/drivers/acpi/thermal.ko): No such device
> Done.
> Begin: Mounting root file system ...
> Begin: Running /scripts/local-top ...
> [   23.224330] md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
> [   23.233979] md: raid1 personality registered as nr 3
> [   23.249716] raid5: automatically using best checksumming function: generic_sse
> [   23.262592]    generic_sse:  6044.000 MB/sec
> [   23.267530] raid5: using function: generic_sse (6044.000 MB/sec)
> [   23.275210] md: raid5 personality registered as nr 4
> [   23.601260] devfs_mk_dev: could not append to parent for md/0
> [   23.609757] md: md0 stopped.
> [   23.614044] md: bind<sdb1>
> [   23.617323] md: bind<sdc1>
> [   23.620564] md: bind<sdd1>
> [   23.623805] md: bind<sda1>
> [   23.626995] raid1: raid set md0 active with 4 out of 4 mirrors
> mdadm: /dev/md0 has been started with 4 drives.
> [   23.641055] devfs_mk_dev: could not append to parent for md/1
> [   23.649588] md: md1 stopped.
> [   23.653883] md: bind<sdb2>
> [   23.657143] md: bind<sdc2>
> [   23.660419] md: bind<sdd2>
> [   23.663659] md: bind<sda2>
> [   23.666829] raid5: device sda2 operational as raid disk 0
> [   23.673104] raid5: device sdd2 operational as raid disk 3
> [   23.679316] raid5: device sdc2 operational as raid disk 2
> [   23.685598] raid5: device sdb2 operational as raid disk 1
> [   23.692275] raid5: allocated 4270kB for md1
> [   23.697098] raid5: raid level 5 set md1 active with 4 out of 4 devices, algorithm 2
> [   23.705958] RAID5 conf printout:
> [   23.709709]  --- rd:4 wd:4 fd:0
> [   23.713348]  disk 0, o:1, dev:sda2
> [   23.717272]  disk 1, o:1, dev:sdb2
> [   23.721214]  disk 2, o:1, dev:sdc2
> [   23.725140]  disk 3, o:1, dev:sdd2
> mdadm: /dev/md1 has been started with 4 drives.
> [   23.740660] devfs_mk_dev: could not append to parent for md/2
> [   23.749195] md: md2 stopped.
> [   23.753499] md: bind<sdb3>
> [   23.756782] md: bind<sdc3>
> [   23.760050] md: bind<sdd3>
> [   23.763323] md: bind<sda3>
> [   23.766489] raid5: device sda3 operational as raid disk 0
> [   23.772723] raid5: device sdd3 operational as raid disk 3
> [   23.778971] raid5: device sdc3 operational as raid disk 2
> [   23.785209] raid5: device sdb3 operational as raid disk 1
> [   23.791895] raid5: allocated 4270kB for md2
> [   23.796733] raid5: raid level 5 set md2 active with 4 out of 4 devices, algorithm 2
> [   23.805597] RAID5 conf printout:
> [   23.809358]  --- rd:4 wd:4 fd:0
> [   23.812987]  disk 0, o:1, dev:sda3
> [   23.816945]  disk 1, o:1, dev:sdb3
> [   23.820871]  disk 2, o:1, dev:sdc3
> [   23.824795]  disk 3, o:1, dev:sdd3
> mdadm: /dev/md2 has been started with 4 drives.
> [   23.844303] devfs_mk_dev: could not append to parent for md/3
> [   23.852907] md: md3 stopped.
> [   23.857209] md: bind<sdb4>
> [   23.860491] md: bind<sdc4>
> [   23.863751] md: bind<sdd4>
> [   23.867023] md: bind<sda4>
> [   23.870187] md: md3: raid array is not clean -- starting background reconstruction
> [   23.878970] raid5: device sda4 operational as raid disk 0
> [   23.885236] raid5: device sdd4 operational as raid disk 3
> [   23.891492] raid5: device sdc4 operational as raid disk 2
> [   23.897764] raid5: device sdb4 operational as raid disk 1
> [   23.904458] raid5: allocated 4270kB for md3
> [   23.909322] raid5: raid level 5 set md3 active with 4 out of 4 devices, algorithm 2
> [   23.918195] RAID5 conf printout:
> [   23.921952]  --- rd:4 wd:4 fd:0
> [   23.925610]  disk 0, o:1, dev:sda4
> [   23.929560]  disk 1, o:1, dev:sdb4
> [   23.933493]  disk 2, o:1, dev:sdc4
> [   23.937443]  disk 3, o:1, dev:sdd4
> [   23.941428] ....<6>md: syncing RAID array md3
> [   23.946502] md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
> [   23.954669] md: using maximum available idle IO bandwith (but not more than 200000 KB/sec) for reconstruction.
> [   23.966246] md: using 128k window, over a total of 67657664 blocks.
> mdadm: /dev/md3 has been started with 4 drives.
> Done.
> Begin: Running /scripts/local-premount ...
> [   24.000782] Attempting manual resume
> [   24.006995] swsusp: Suspend partition has wrong signature?
> Done.
> [   24.115879] kjournald starting.  Commit interval 5 seconds
> [   24.122230] EXT3-fs: mounted filesystem with ordered data mode.
> Begin: Running /scripts/local-bottom ...
> Done.
> Done.
> Begin: Running /scripts/init-bottom ...
> Done.
>  * version 2.86 booting
>  * Starting RAID devices...        [ ok ]
>  * Starting hardware event daemon...        [ ok ]
>  * Creating initial device nodes...        
> 
> LinuxBIOS-1.1.8_s2881_Fallback Thu Dec 15 18:45:48 EST 2005 starting...
> (0,1) link=00
> (1,0) link=00
> 02 nodes initialized.
>  core0:  --- {  APICID = 02 NODEID = 01 COREID = 00} ---
> SBLink=02
> NC node|link=02

--
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------
LinuxBIOS-1.1.8_s2881_Fallback Tue Jan  3 17:36:16 EST 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
 core0:  --- {  APICID = 02 NODEID = 01 COREID = 00} ---
SBLink=02
NC node|link=02
ht reset -


LinuxBIOS-1.1.8_s2881_Fallback Tue Jan  3 17:36:16 EST 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
 core0:  --- {  APICID = 02 NODEID = 01 COREID = 00} ---
SBLink=02
NC node|link=02
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Ram4
v_esp=000cfd40
cpu_reset = 00000000
Clearing initial memory region: No cache as ram now - Use Ram as Stack now - done
new_cpu_reset = 00000000
Copying LinuxBIOS to ram.
src=fffe0004
dst=00004000
linxbios_ram.bin length = 0001928c
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8_s2881_Fallback Tue Jan  3 17:36:16 EST 2006 booting...
Enumerating buses...
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 enabled
  PCI: 00:18.3 siblings=1
CPU: APIC: 00 enabled
CPU: APIC: 01 enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] enabled
  PCI: 00:19.3 siblings=1
CPU: APIC: 02 enabled
CPU: APIC: 03 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] enabled
PCI: 01:00.0 [1022/7450] enabled
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:00.0 [1022/7460] enabled
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] enabled
PCI: 01:03.0 [1022/7460] enabled
PCI: 01:04.0 [1022/7468] enabled
PCI: 01:04.1 [1022/7469] enabled
PCI: 01:04.2 [1022/746a] enabled
PCI: 01:04.3 [1022/746b] enabled
PCI: pci_scan_bus for bus 2
PCI: 02:09.0 [14e4/1648] enabled
PCI: 02:09.1 [14e4/1648] enabled
Disabling static device: PCI: 02:0a.0
Disabling static device: PCI: 02:0a.1
PCI: pci_scan_bus returning with max=02
PCI: 02: 100MHz PCI-X
PCI: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: 03: 133MHz PCI-X
PCI: pci_scan_bus for bus 4
PCI: 04:00.0 [1022/7464] enabled
PCI: 04:00.1 [1022/7464] enabled
PCI: 04:05.0 [1095/3114] enabled
PCI: 04:06.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=04
PNP: 002e.0 enabled
PNP: 002e.1 disabled
PNP: 002e.2 enabled
PNP: 002e.3 disabled
PNP: 002e.5 enabled
PNP: 002e.6 disabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
PNP: 002e.b enabled
smbus: PCI: 01:04.3[0]->I2C: 01:50 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:51 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:52 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:53 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:54 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:55 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:56 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:57 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:2d enabled
smbus: PCI: 01:04.3[0]->I2C: 01:2a enabled
smbus: PCI: 01:04.3[0]->I2C: 01:49 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:4a enabled
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus returning with max=04
done
Allocating resources...
Reading resources...
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
Done reading resources.
Setting resources...
PCI: 00:18.0 1ba <- [0x00fd300000 - 0x00fd2fffff] prefmem <node 0 link 2>
PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000002fff] io <node 0 link 2>
PCI: 00:18.0 1b2 <- [0x00fc000000 - 0x00fd2fffff] mem <node 0 link 2>
PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 2 mem
PCI: 02:09.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem64
PCI: 02:09.0 18 <- [0x00fd110000 - 0x00fd11ffff] mem64
PCI: 02:09.1 10 <- [0x00fd120000 - 0x00fd12ffff] mem64
PCI: 02:09.1 18 <- [0x00fd130000 - 0x00fd13ffff] mem64
PCI: 01:01.1 10 <- [0x00fd200000 - 0x00fd200fff] mem64
PCI: 01:02.1 10 <- [0x00fd201000 - 0x00fd201fff] mem64
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 mem
PCI: 04:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem
PCI: 04:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem
PCI: 04:05.0 10 <- [0x0000001410 - 0x0000001417] io
PCI: 04:05.0 14 <- [0x0000001430 - 0x0000001433] io
PCI: 04:05.0 18 <- [0x0000001420 - 0x0000001427] io
PCI: 04:05.0 1c <- [0x0000001440 - 0x0000001443] io
PCI: 04:05.0 20 <- [0x0000001400 - 0x000000140f] io
PCI: 04:05.0 24 <- [0x00fd003000 - 0x00fd0033ff] mem
PCI: 04:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 04:06.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 04:06.0 18 <- [0x00fd002000 - 0x00fd002fff] mem
PCI: 04:06.0 30 <- [0x00fff80000 - 0x00fff9ffff] romem
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] io
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq
PCI: 01:04.1 20 <- [0x0000002420 - 0x000000242f] io
PCI: 01:04.2 10 <- [0x0000002400 - 0x000000241f] io
PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
Done setting resources.
Done allocating resources.
Enabling resourcess...
PCI: 00:18.0 cmd <- 140
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 146
PCI: 02:09.0 subsystem <- 10f1/2881
PCI: 02:09.0 cmd <- 142
PCI: 02:09.1 subsystem <- 10f1/2881
PCI: 02:09.1 cmd <- 142
PCI: 01:01.1 subsystem <- 10f1/2881
PCI: 01:01.1 cmd <- 146
PCI: 01:02.1 subsystem <- 10f1/2881
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 0003
PCI: 01:03.0 cmd <- 147
PCI: 04:00.0 subsystem <- 10f1/2881
PCI: 04:00.0 cmd <- 142
PCI: 04:00.1 subsystem <- 10f1/2881
PCI: 04:00.1 cmd <- 142
PCI: 04:05.0 subsystem <- 10f1/2881
PCI: 04:05.0 cmd <- 143
PCI: 04:06.0 subsystem <- 10f1/2881
PCI: 04:06.0 cmd <- 1c3
PCI: 01:04.0 subsystem <- 10f1/2881
PCI: 01:04.0 cmd <- 14f
w83627hf hwm smbus enabled
PCI: 01:04.1 subsystem <- 10f1/2881
PCI: 01:04.1 cmd <- 141
PCI: 01:04.2 subsystem <- 10f1/2881
PCI: 01:04.2 cmd <- 141
PCI: 01:04.3 subsystem <- 10f1/2881
PCI: 01:04.3 cmd <- 141
PCI: 00:18.1 subsystem <- 10f1/2881
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 10f1/2881
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
PCI: 00:19.0 cmd <- 140
PCI: 00:19.1 cmd <- 140
PCI: 00:19.2 cmd <- 140
PCI: 00:19.3 cmd <- 140
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device 20f12
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 0 done.
Clearing memory 1024K - 2097152K: ------------------------------- done
CPU #0 Initialized
start_eip=0x00010000
Initializing CPU #1
CPU: vendor AMD device 20f12
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
start_eip=0x00010000
Initializing CPU #2
CPU: vendor AMD device 20f12
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 2 done.
Clearing memory 2097152K - 5242880K: ----------------++++++++++++++++ done
CPU #2 Initialized
start_eip=0x00010000
Initializing CPU #3
Waiting for 1 CPUS to stop
CPU: vendor AMD device 20f12
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 3 done.
CPU #3 Initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 01:01.0 init
PCI: 02:09.0 init
PCI: 02:09.1 init
PCI: 01:03.0 init
PCI: 04:05.0 init
PCI: 04:06.0 init
PCI: 01:04.0 init
RTC Init
Invalid CMOS LB checksum
enabling HPET @0xfed00000
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 01:04.1 init
IDE1 IDE0 PCI: 01:04.3 init
set power on after power fail
smbus: PCI: 01:04.3[0]->I2C: 01:2d init
PCI: 00:18.1 init
PCI: 00:18.2 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:19.0 init
PCI: 00:19.1 init
PCI: 00:19.2 init
PCI: 00:19.3 init
NB: Function 3 Misc Control.. done.
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 000001f4
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000e10  checksum 54d5

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffc0000 - 0xfffdffff
Found ELF candiate at offset 0
Loading Etherboot version: 5.4.1
Dropping non PT_LOAD segment
New segment addr 0x10000 size 0x49180 offset 0x0 filesize 0x9c90
(cleaned up) New segment addr 0x10000 size 0x49180 offset 0x0 filesize 0x9c90
Loading Segment: addr: 0x00000000bff8c000 memsz: 0x0000000000034000 filesz: 0x0000000000009c90
Clearing Segment: addr: 0x00000000bff95c90 memsz: 0x000000000002a370
Loading Segment: addr: 0x0000000000044000 memsz: 0x0000000000015180 filesz: 0x0000000000000000
Clearing Segment: addr: 0x0000000000044000 memsz: 0x0000000000015180
Jumping to boot code at 0x100b0
CPU 2064 Mhz
Etherboot 5.4.1 (GPL) http://etherboot.org
Drivers: TG3 FILO   Images: NBI ELF   
Protocols: DHCP TFTP 
Relocating _text from: [000101b0,00059180) to [bfeb7030,bff00000)
Boot from (N)etwork (D)isk or (Q)uit? D

Probing pci disk...
[FILO]FILO version 0.4.1 (root at countzero.vandewege.net) Tue Jan  3 17:32:29 EST 2006
Press <Enter> for default boot, or <Esc> for boot prompt... 2 1 timed out
boot: hde1:/vmlinuz-2.6.12-9-amd64-generic initrd=/initrd.img-2.6.12-9-amd64-generic ro root=/dev/md3 console=tty0 console=ttyS0,115200n8
hde: LBA48: WDC WD740GD-00FLC0                      
hdf: LBA48: WDC WD740GD-00FLC0                      
Mounted ext2fs
Found Linux version 2.6.12-9-amd64-generic (buildd at king) #1 Mon Oct 10 13:27:39 BST 2005 bzImage.
Loading kernel... ok
Loading initrd... ok
Jumping to entry point...
[    0.000000] Bootdata ok (command line is ro root=/dev/md3 console=tty0 console=ttyS0,115200n8)
[    0.000000] Linux version 2.6.12-9-amd64-generic (buildd at king) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 Mon Oct 10 13:27:39 BST 2005
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 0000000000000e7c type 16
[    0.000000]  BIOS-e820: 0000000000000e7c - 00000000000a0000 (usable)
[    0.000000]  BIOS-e820: 00000000000f0000 - 00000000000f0400 type 16
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
[    0.000000] ACPI: Unable to locate RSDP
[    0.000000] Intel MultiProcessor Specification v1.4
[    0.000000]     Virtual Wire compatibility mode.
[    0.000000] OEM ID: TYAN     <6>Product ID: S2881        <6>APIC at: 0xFEE00000
[    0.000000] Processor #0 15:1 APIC version 16
[    0.000000] Processor #1 15:1 APIC version 16
[    0.000000] WARNING: NR_CPUS limit of 1 reached. Processor ignored.
[    0.000000] Processor #2 15:1 APIC version 16
[    0.000000] WARNING: NR_CPUS limit of 1 reached. Processor ignored.
[    0.000000] Processor #3 15:1 APIC version 16
[    0.000000] WARNING: NR_CPUS limit of 1 reached. Processor ignored.
[    0.000000] I/O APIC #4 Version 17 at 0xFEC00000.
[    0.000000] I/O APIC #5 Version 17 at 0xFD200000.
[    0.000000] I/O APIC #6 Version 17 at 0xFD201000.
[    0.000000] Setting APIC routing to flat
[    0.000000] Processors: 1
[    0.000000] Allocating PCI resources starting at c0000000 (gap: c0000000:40000000)
[    0.000000] Checking aperture...
[    0.000000] CPU 0: aperture @ f8000000 size 64 MB
[    0.000000] CPU 1: aperture @ f8000000 size 64 MB
[    0.000000] Built 1 zonelists
[    0.000000] Kernel command line: ro root=/dev/md3 console=tty0 console=ttyS0,115200n8
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 4096 (order: 12, 131072 bytes)
[    0.000000] time.c: Using 1.193182 MHz PIT timer.
[    0.000000] time.c: Detected 1991.567 MHz processor.
[   13.382487] time.c: Using PIT/TSC based timekeeping.
[   13.382927] Console: colour dummy device 80x25
[   13.602936] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[   13.618545] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[   13.695497] Memory: 4101416k/5242880k available (1620k kernel code, 92332k reserved, 997k data, 136k init)
[   13.725327] Security Framework v1.0.0 initialized
[   13.730503] SELinux:  Disabled at boot.
[   13.734726] Mount-cache hash table entries: 256
[   13.739776] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   13.748068] CPU: L2 Cache: 1024K (64 bytes/line)
[   13.753397] CPU:  stepping 02
[   13.756953] checking if image is initramfs... it is
[   14.094094] Using IO-APIC 4
[   14.097350] Using IO-APIC 5
[   14.100593] Using IO-APIC 6
[   14.113926] Using local APIC timer interrupts.
[   14.169306] Detected 12.447 MHz APIC timer.
[   14.174168] testing NMI watchdog ... OK.
[   14.188739] NET: Registered protocol family 16
[   14.194273] PCI: Using configuration type 1
[   14.199124] mtrr: v2.0 (20020519)
[   14.203233] ACPI: Subsystem revision 20050729
[   14.208291] ACPI: Interpreter disabled.
[   14.212726] Linux Plug and Play Support v0.97 (c) Adam Belay
[   14.219295] pnp: PnP ACPI: disabled
[   14.223386] usbcore: registered new driver usbfs
[   14.228755] usbcore: registered new driver hub
[   14.233943] PCI: Probing PCI hardware
[   14.238176] PCI: Probing PCI hardware (bus 00)
[   14.244682] PCI: Discovered primary peer bus 01 [IRQ]
[   14.250557] PCI: Using IRQ router default [1022/7468] at 0000:01:04.0
[   14.258038] PCI->APIC IRQ transform: 0000:01:04.2[D] -> IRQ 19
[   14.264805] PCI->APIC IRQ transform: 0000:02:09.0[A] -> IRQ 24
[   14.271568] PCI->APIC IRQ transform: 0000:02:09.1[B] -> IRQ 25
[   14.278315] PCI->APIC IRQ transform: 0000:04:00.0[D] -> IRQ 19
[   14.285099] PCI->APIC IRQ transform: 0000:04:00.1[D] -> IRQ 19
[   14.291873] PCI->APIC IRQ transform: 0000:04:05.0[A] -> IRQ 17
[   14.298639] PCI->APIC IRQ transform: 0000:04:06.0[A] -> IRQ 18
[   14.305469] PCI-DMA: Disabling AGP.
[   14.309565] PCI-DMA: aperture base @ f8000000 size 65536 KB
[   14.316026] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[   14.323800] IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
[   14.332310] audit: initializing netlink socket (disabled)
[   14.338571] audit: initialized
[   14.342183] VFS: Disk quotas dquot_6.5.1
[   14.346741] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[   14.354242] devfs: 2004-01-31 Richard Gooch (rgooch at atnf.csiro.au)
[   14.361388] devfs: boot_options: 0x0
[   14.365554] Initializing Cryptographic API
[   14.370320] PCI: MSI quirk detected. pci_msi_quirk set.
[   14.376390] PCI: MSI quirk detected. pci_msi_quirk set.
[   14.396511] Linux agpgart interface v0.101 (c) Dave Jones
[   14.402839] PNP: No PS/2 controller found. Probing ports directly.
[   14.411607] serio: i8042 AUX port at 0x60,0x64 irq 12
[   14.417510] serio: i8042 KBD port at 0x60,0x64 irq 1
[   14.423273] Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
[   14.432480] ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   14.439569] io scheduler noop registered
[   14.444130] io scheduler anticipatory registered
[   14.449492] io scheduler deadline registered
[   14.454450] io scheduler cfq registered
[   14.459156] RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
[   14.467995] NET: Registered protocol family 2
[   14.482953] IP: routing cache hash table of 65536 buckets, 512Kbytes
[   14.490780] TCP established hash table entries: 524288 (order: 10, 4194304 bytes)
[   14.502485] TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
[   14.510542] TCP: Hash tables configured (established 524288 bind 65536)
[   14.518280] NET: Registered protocol family 8
[   14.523312] NET: Registered protocol family 20
[   14.528620] Freeing unused kernel memory: 136k freed
Loading, please wait...
Begin: Loading modules ...
[   14.552088] input: AT Translated Set 2 keyboard on isa0060/serio0
[   14.563428] Capability LSM initialized
[   14.576238] NET: Registered protocol family 1
[   14.592822] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[   14.600210] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[   14.614405] AMD8111: IDE controller at PCI slot 0000:01:04.1
[   14.620961] AMD8111: chipset revision 3
[   14.625398] AMD8111: not 100% native mode: will probe irqs later
[   14.632349] AMD8111: 0000:01:04.1 (rev 03) UDMA133 controller
[   14.639007]     ide0: BM-DMA at 0x2420-0x2427, BIOS settings: hda:pio, hdb:pio
[   14.647392]     ide1: BM-DMA at 0x2428-0x242f, BIOS settings: hdc:pio, hdd:pio
[   15.787445] hdd: CD-224E, ATAPI CD/DVD-ROM drive
[   15.843814] ide1 at 0x170-0x177,0x376 on irq 15
[   18.418214] hdd: ATAPI 24X CD-ROM drive, 128kB Cache
[   18.424029] Uniform CD-ROM driver Revision: 3.20
[   18.679200] tg3.c:v3.31 (June 8, 2005)
[   18.687669] eth0: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:30:a5:24
[   18.701222] eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] 
[   18.710911] eth0: dma_rwctrl[769f4000]
[   18.725706] eth1: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:30:a5:25
[   18.739240] eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
[   18.748945] eth1: dma_rwctrl[769f4000]
[   18.761726] ohci_hcd 0000:04:00.0: Advanced Micro Devices [AMD] AMD-8111 USB
[   18.770030] ohci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 1
[   18.778603] ohci_hcd 0000:04:00.0: irq 19, io mem 0xfd000000
[   18.837669] hub 1-0:1.0: USB hub found
[   18.842018] hub 1-0:1.0: 3 ports detected
[   18.849623] ohci_hcd 0000:04:00.1: Advanced Micro Devices [AMD] AMD-8111 USB (#2)
[   18.858342] ohci_hcd 0000:04:00.1: new USB bus registered, assigned bus number 2
[   18.866917] ohci_hcd 0000:04:00.1: irq 19, io mem 0xfd001000
[   18.925606] hub 2-0:1.0: USB hub found
[   18.929958] hub 2-0:1.0: 3 ports detected
[   18.947609] SCSI subsystem initialized
[   18.954053] ata1: SATA max UDMA/100 cmd 0xFFFFC20000014080 ctl 0xFFFFC2000001408A bmdma 0xFFFFC20000014000 irq 17
[   18.965952] ata2: SATA max UDMA/100 cmd 0xFFFFC200000140C0 ctl 0xFFFFC200000140CA bmdma 0xFFFFC20000014008 irq 17
[   18.977888] ata3: SATA max UDMA/100 cmd 0xFFFFC20000014280 ctl 0xFFFFC2000001428A bmdma 0xFFFFC20000014200 irq 17
[   18.989796] ata4: SATA max UDMA/100 cmd 0xFFFFC200000142C0 ctl 0xFFFFC200000142CA bmdma 0xFFFFC20000014208 irq 17
[   19.356748] ata1: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
[   19.365079] ata1: dev 0 configured for UDMA/100
[   19.370326] scsi0 : sata_sil
[   19.728542] ata2: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
[   19.736868] ata2: dev 0 configured for UDMA/100
[   19.742125] scsi1 : sata_sil
[   20.100343] ata3: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
[   20.108673] ata3: dev 0 configured for UDMA/100
[   20.113919] scsi2 : sata_sil
[   20.472138] ata4: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
[   20.480443] ata4: dev 0 configured for UDMA/100
[   20.485690] scsi3 : sata_sil
[   20.489092]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
[   20.496427]   Type:   Direct-Access                      ANSI SCSI revision: 05
[   20.505313]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
[   20.512607]   Type:   Direct-Access                      ANSI SCSI revision: 05
[   20.521467]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
[   20.528815]   Type:   Direct-Access                      ANSI SCSI revision: 05
[   20.537688]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
[   20.544977]   Type:   Direct-Access                      ANSI SCSI revision: 05
[   22.570354] SCSI device sda: 145226112 512-byte hdwr sectors (74356 MB)
[   22.578060] SCSI device sda: drive cache: write back
[   22.583874] SCSI device sda: 145226112 512-byte hdwr sectors (74356 MB)
[   22.591514] SCSI device sda: drive cache: write back
[   22.597270]  /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4
[   22.614922] Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
[   22.622193] SCSI device sdb: 145226112 512-byte hdwr sectors (74356 MB)
[   22.629880] SCSI device sdb: drive cache: write back
[   22.635684] SCSI device sdb: 145226112 512-byte hdwr sectors (74356 MB)
[   22.643346] SCSI device sdb: drive cache: write back
[   22.649102]  /dev/scsi/host1/bus0/target0/lun0: p1 p2 p3 p4
[   22.665362] Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
[   22.672632] SCSI device sdc: 145226112 512-byte hdwr sectors (74356 MB)
[   22.680274] SCSI device sdc: drive cache: write back
[   22.686053] SCSI device sdc: 145226112 512-byte hdwr sectors (74356 MB)
[   22.693715] SCSI device sdc: drive cache: write back
[   22.699471]  /dev/scsi/host2/bus0/target0/lun0: p1 p2 p3 p4
[   22.717266] Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0
[   22.724550] SCSI device sdd: 145226112 512-byte hdwr sectors (74356 MB)
[   22.732228] SCSI device sdd: drive cache: write back
[   22.738015] SCSI device sdd: 145226112 512-byte hdwr sectors (74356 MB)
[   22.745679] SCSI device sdd: drive cache: write back
[   22.751417]  /dev/scsi/host3/bus0/target0/lun0: p1 p2 p3 p4
[   22.769228] Attached scsi disk sdd at scsi3, channel 0, id 0, lun 0
Done.
Begin: Initializing /dev ...
Done.
Begin: Running /scripts/init-premount ...
FATAL: Error inserting fan (/lib/modules/2.6.12-9-amd64-generic/kernel/drivers/acpi/fan.ko): No such device
FATAL: Error inserting thermal (/lib/modules/2.6.12-9-amd64-generic/kernel/drivers/acpi/thermal.ko): No such device
Done.
Begin: Mounting root file system ...
Begin: Running /scripts/local-top ...
[   23.126611] md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
[   23.136234] md: raid1 personality registered as nr 3
[   23.152012] raid5: automatically using best checksumming function: generic_sse
[   23.165265]    generic_sse:  6040.000 MB/sec
[   23.170211] raid5: using function: generic_sse (6040.000 MB/sec)
[   23.177911] md: raid5 personality registered as nr 4
[   23.503175] devfs_mk_dev: could not append to parent for md/0
[   23.511685] md: md0 stopped.
[   23.515982] md: bind<sdb1>
[   23.519240] md: bind<sdc1>
[   23.522491] md: bind<sdd1>
[   23.525746] md: bind<sda1>
[   23.528967] raid1: raid set md0 active with 4 out of 4 mirrors
mdadm: /dev/md0 has been started with 4 drives.
[   23.543059] devfs_mk_dev: could not append to parent for md/1
[   23.551594] md: md1 stopped.
[   23.555871] md: bind<sdb2>
[   23.559153] md: bind<sdc2>
[   23.562397] md: bind<sdd2>
[   23.565675] md: bind<sda2>
[   23.568817] raid5: device sda2 operational as raid disk 0
[   23.575076] raid5: device sdd2 operational as raid disk 3
[   23.581314] raid5: device sdc2 operational as raid disk 2
[   23.587560] raid5: device sdb2 operational as raid disk 1
[   23.594243] raid5: allocated 4270kB for md1
[   23.599081] raid5: raid level 5 set md1 active with 4 out of 4 devices, algorithm 2
[   23.607952] RAID5 conf printout:
[   23.611689]  --- rd:4 wd:4 fd:0
[   23.615320]  disk 0, o:1, dev:sda2
[   23.619244]  disk 1, o:1, dev:sdb2
[   23.623168]  disk 2, o:1, dev:sdc2
[   23.627127]  disk 3, o:1, dev:sdd2
mdadm: /dev/md1 has been started with 4 drives.
[   23.642617] devfs_mk_dev: could not append to parent for md/2
[   23.651168] md: md2 stopped.
[   23.655459] md: bind<sdb3>
[   23.658725] md: bind<sdc3>
[   23.661974] md: bind<sdd3>
[   23.665248] md: bind<sda3>
[   23.668406] raid5: device sda3 operational as raid disk 0
[   23.674639] raid5: device sdd3 operational as raid disk 3
[   23.680917] raid5: device sdc3 operational as raid disk 2
[   23.687201] raid5: device sdb3 operational as raid disk 1
[   23.693862] raid5: allocated 4270kB for md2
[   23.698703] raid5: raid level 5 set md2 active with 4 out of 4 devices, algorithm 2
[   23.707572] RAID5 conf printout:
[   23.711314]  --- rd:4 wd:4 fd:0
[   23.714961]  disk 0, o:1, dev:sda3
[   23.718893]  disk 1, o:1, dev:sdb3
[   23.722817]  disk 2, o:1, dev:sdc3
[   23.726741]  disk 3, o:1, dev:sdd3
mdadm: /dev/md2 has been started with 4 drives.
[   23.746129] devfs_mk_dev: could not append to parent for md/3
[   23.754702] md: md3 stopped.
[   23.758992] md: bind<sdb4>
[   23.762253] md: bind<sdc4>
[   23.765497] md: bind<sdd4>
[   23.768768] md: bind<sda4>
[   23.771904] md: md3: raid array is not clean -- starting background reconstruction
[   23.780703] raid5: device sda4 operational as raid disk 0
[   23.786935] raid5: device sdd4 operational as raid disk 3
[   23.793198] raid5: device sdc4 operational as raid disk 2
[   23.799451] raid5: device sdb4 operational as raid disk 1
[   23.806115] raid5: allocated 4270kB for md3
[   23.810973] raid5: raid level 5 set md3 active with 4 out of 4 devices, algorithm 2
[   23.819860] RAID5 conf printout:
[   23.823599]  --- rd:4 wd:4 fd:0
[   23.827238]  disk 0, o:1, dev:sda4
[   23.831179]  disk 1, o:1, dev:sdb4
[   23.835121]  disk 2, o:1, dev:sdc4
[   23.839074]  disk 3, o:1, dev:sdd4
[   23.843036] ....<6>md: syncing RAID array md3
[   23.848123] md: minimum _guaranteed_ reconstruction speed: 1000 KB/sec/disc.
[   23.856300] md: using maximum available idle IO bandwith (but not more than 200000 KB/sec) for reconstruction.
[   23.867911] md: using 128k window, over a total of 67657664 blocks.
mdadm: /dev/md3 has been started with 4 drives.
Done.
Begin: Running /scripts/local-premount ..[   23.902163] Attempting manual resume
.
[   23.910134] swsusp: Suspend partition has wrong signature?
Done.


LinuxBIOS-1.1.8_s2881_Fallback Tue Jan  3 17:36:16 EST 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
 core0:  --- {  APICID = 02 NODEID = 01 COREID = 00} ---
SBLink=02
NC node|link=02

From rminnich at lanl.gov  Wed Jan  4 00:59:59 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 03 Jan 2006 16:59:59 -0700
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
In-Reply-To: <20060103233832.GA8073@io.pong.be>
References: <20051216043022.GA18934@io.pong.be>
	<20060103233832.GA8073@io.pong.be>
Message-ID: <43BB0FFF.5060209@lanl.gov>

Ward, ollie will be back tomorrow, we are doing builds for this board so 
will take a look.

ron



From yinghai.lu at amd.com  Wed Jan  4 01:50:39 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 3 Jan 2006 16:50:39 -0800
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949B0@ssvlexmb2.amd.com>

Can you try with single HD instead of RAID5?

YH




From mark at cubeman.org  Wed Jan  4 05:23:32 2006
From: mark at cubeman.org (Mark Longridge)
Date: Tue, 3 Jan 2006 23:23:32 -0500
Subject: [LinuxBIOS] Tyan Tiger 100 S1832
In-Reply-To: <8a0c36780512160825q60ef7d3x8e68231655723390@mail.gmail.com>
References: <200512160055.14321.mark@cubeman.org>
	<8a0c36780512160825q60ef7d3x8e68231655723390@mail.gmail.com>
Message-ID: <200601032323.32869.mark@cubeman.org>

Hi Richard,

I still have a lot to learn, but the idea of a speedy boot process 
appeals to me. 

The problem is the motherboard manual doesn't really tell me
exactly which chip(s) the "National 309 Super IO chipset" is or
where it's located on the board.

The manual does refer to LM75 and LM79 chips which I believe
are temperature sensors. I can read them via the lm-sensors package.
For some reason the LM79 sensor was put beside PCI slot #5.
Oops, looks like it's actually a "lm79-isa-0290" and it's reporting a
nice cool 24 degrees C. I don't have any ISA cards anyways :)

ChipDocs has datasheets for the pc87309 and it's described as
 "Super I/O Plug and Play Compatible Chip in Compact 100-Pin 
VLJ Packaging" but I have to subscribe to download the datasheets.

Checking on tyan.com I can see that Tyan does test it's boards to 
work with Redhat and SUSE and I must say the old Tiger 100 board
has worked great on my Linux server. It would be really nice if
some manufacture shipped boards with Linux BIOS on them... I 
wonder if anyone actually does that.
 

On December 16, 2005 11:25 am, Richard Smith wrote:
> > ?Intel 440BX AGPset.> ?Intel PIIX4e controller.> ?National 309 Super I/O
> > chipset.>> Guess it's pretty old but I'd still like to try to put a linux
> > bios> on it.>
>
> How are your hacking skills?

Meager but improving ....

> LinuxBIOS V1:Supports the 440BX but it dosen't know anything about SMP or
> AGP andyou would probally need ADLO to make the video bios work.By 309 I'm
> guessing that the pc87309Oo superIO?  V1 seems to have reallybasic support
> for enableing that on boot but the comments say itsspecific to a particular
> mainbord.  So some work is needed there aswell. LinuxBIOS V2I have a set of
> patches vs an old version of V2 that add the frameworkfor 440BX and was
> enough to make our product come up and say stuff outof the serial port.
> (pc87351)  However I got stopped trying to readthe RAM info via the SMbus. 
> For some reason I always got back zeros(or FF's I dont' remember). 
> Unfortunatly that product never made itbeyond prototype and so I didn't
> continue to try and transition fromV1 to V2. If you are interested in
> working on it I can fixup my patches againstthe latest SVN tree and submit
> them.  There's a lot of coding workthat still needs to be done after that
> though. I have somewhat of an interest in this as I have a Dual P3
> machinewith a 440 chipset on it that can't use newer larger hardrives
> becausethe BIOS chokes and I also have some of the prototypes from
> ourproduct that could be used for something

A couple of years back I flashed the BIOS so I haven't had any
problems with big hard drives on the Tiger 100. My server runs a 
20 gig and a 40 gig.

If you want to upload your patches I'll keep plugging away at it although
perhaps there are already cheap Tyan boards on ebay that are well supported
already? 

> I just don't have a lot 
> oftime to allocate to this.  But I could test things in the evenings
> andweekends. It would be really nice to have full V2 support for the 440
> family. There are tons of old cheap mainboards with these chips on them
> andwould be great for hobbiest or personal type stuff. --Richard A. Smith

Maybe I can buy another Tiger 100 to experiment on. I'm still running 
my server 24/7 with the one I have now.

Mark



From smithbone at gmail.com  Thu Jan  5 16:53:34 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 5 Jan 2006 09:53:34 -0600
Subject: [LinuxBIOS] Tyan Tiger 100 S1832
In-Reply-To: <200601042138.25830.mark@cubeman.org>
References: <200512160055.14321.mark@cubeman.org>
	<200601032323.32869.mark@cubeman.org>
	<8a0c36780601040740t6bd15414g97f57593f8e7976e@mail.gmail.com>
	<200601042138.25830.mark@cubeman.org>
Message-ID: <8a0c36780601050753o6b414c93q17a4995efb5ca4a6@mail.gmail.com>

> Thanks for the datasheet. On my Tyan S1832 board I can report that
> the chip says

> "PC87309-IBW/VLJ"
> On my system:
> dmesg -s 1000000 | grep PC87
> gives
> FDC 0 is a National Semiconductor PC87306
>
> I'm assuming that Linux is incorrectly detecting the chipset
> but it's close enough to the 309 that it still works.

A lot of the NS superIO's are very similar.  The cases I've seen so
far are just  addition/subtraction of all the "special" features. 
Like fan control, power control stuff, special purpose gpio.  The FDC
between the 2 may be identical.

> > sides, pins will be pretty close together.  Willlook similar to this:
> > http://www.topline.tv/qfp.html
>
> Found it... looked exactly as you described.
>
> > I can't go past 40 or it locks and there aren't any newer updates for my
> > MB.
>
> I assume it's a different one and not a S1832?

Yeah.  It just has a 440bx chipset on it.

> > An additional board would be pretty much a requirement for doing thedev
> > work.  You will need some method of programming the flash chips aswell.
> > Either a programmer/ bios savior or ZIF socket so you can dohotswap
> > programming. --Richard A. Smith
>
> A BIOS savior sounds like a good insurance in any case! I'll try to find
> a duplicate MB.

Good choice. The only thing better than a bios savior is a ROM
emulator but it's lots more expensive.  Make sure when you order your
replacement flash that its supported by flashrom.  Most are but check
to make sure.  You don't have to get the exact brand of flash thats in
the board since the factory part may be hard to find.  Only the size
and speed (and supply voltage of course) needs to match.

If you have any doubts about what chips will work just post up the
part number (The one _under_ the sticker) on your bios chip and we
should be able to cross it for you.

--
Richard A. Smith

From talbotx at comcast.net  Thu Jan  5 17:15:35 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Thu, 05 Jan 2006 08:15:35 -0800
Subject: [LinuxBIOS] Support for the EBC3610-f
Message-ID: <43BD4627.5060904@comcast.net>

Is there any support for the EBC3610-f
http://www.bcmcom.com/bcm_product_ebc3610f.htm

I see that linuxbos supports the VT8601North bridge. How close it that 
to the VT8606?
-Adam Talbot



From yinghai.lu at amd.com  Fri Jan  6 01:30:05 2006
From: yinghai.lu at amd.com (Yinghai Lu)
Date: Thu, 5 Jan 2006 16:30:05 -0800
Subject: [LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch
In-Reply-To: <20060103044632.GA4969@in.ibm.com>
References: <20060103044632.GA4969@in.ibm.com>
Message-ID: <86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>

the patch is good.

I tried LinuxBIOS with kexec.

without this patch: I need to disable acpi in kernel. otherwise the
kernel with acpi support can boot the second kernel, but the second
kernel will hang after

time.c: Using 14.318180 MHz HPET timer.
time.c: Detected 2197.663 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )


YH

On 1/2/06, Vivek Goyal <vgoyal at in.ibm.com> wrote:
> Hi Andi,
>
> Can you please include the following patch. This patch has already been pushed
> by Andrew.
>
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch
>
> This patch is regarding remembering at boot up time where i8259 is connected
> and restore the APIC settings back during kexec boot or kdump boot. This
> enables getting timer interrupts in new kernel in legacy mode.
>
> This patch is needed to make kexec and kdump work on some systems,
> especially opteron boxes. Otherwise the second kernel does not receive
> timer interrupts during early boot hence hangs.
>
> I understand, that you are inclined towards remembering all the APIC states
> and simply restore it back instead of putting hooks. This will work
> well for kexec but not for kdump because in kdump system can crash on
> non-boot cpu.
>
> Restoring BIOS APIC state can make sure that BIOS designated boot cpu will
> always be able to see timer interrupts in legacy mode but same does not
> hold good if new kernel boots on some other cpu as is the case with kdump.
>
> In case of kexec boot, we relocate to boot cpu but in case of kdump we
> don't because it was suggested that in some extreme cases of crash, boot cpu
> might not respond even to NMI and relocation to boot cpu will not be
> possible.
>
> Can you please re-consider this patch for inclusion.
>
> Thanks
> Vivek
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



From akpm at osdl.org  Fri Jan  6 01:38:48 2006
From: akpm at osdl.org (Andrew Morton)
Date: Thu, 5 Jan 2006 16:38:48 -0800
Subject: [LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch
In-Reply-To: <86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>
References: <20060103044632.GA4969@in.ibm.com>
	<86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>
Message-ID: <20060105163848.3275a220.akpm@osdl.org>

Yinghai Lu <yinghai.lu at amd.com> wrote:
>
> the patch is good.
> 
> I tried LinuxBIOS with kexec.
> 
> without this patch: I need to disable acpi in kernel. otherwise the
> kernel with acpi support can boot the second kernel, but the second
> kernel will hang after
> 
> time.c: Using 14.318180 MHz HPET timer.
> time.c: Detected 2197.663 MHz processor.
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )
> 
> 

Please don't top-post.

> 
> On 1/2/06, Vivek Goyal <vgoyal at in.ibm.com> wrote:
> > Hi Andi,
> >
> > Can you please include the following patch. This patch has already been pushed
> > by Andrew.
> >
> > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch

IIRC, I dropped this patch because of discouraging noises from Andi and
because underlying x86_64 changes broke it in ugly ways.  It needs to be
redone and Andi's objections (whatever they were) need to be addressed or
argued about.

Right now the patch is rather dead.



From yhlu.kernel at gmail.com  Fri Jan  6 03:04:04 2006
From: yhlu.kernel at gmail.com (yhlu)
Date: Thu, 5 Jan 2006 18:04:04 -0800
Subject: [LinuxBIOS] x86_64: calibrate_delay_direct and apic id lift for
	BSP
In-Reply-To: <200510282053.07608.ak@suse.de>
References: <86802c440510281142i11771f25o3f6667869b4d614e@mail.gmail.com>
	<200510282053.07608.ak@suse.de>
Message-ID: <86802c440601051804n23017262v9afe2d0c8643fb49@mail.gmail.com>

On 10/28/05, Andi Kleen <ak at suse.de> wrote:
>
> They change when interrupt 0 fires. So it's probably misrouted
> or similar.

the problem fixed, on the AMD 8111 based MB, if lift the bsp apic id,
the LinuxBIOS need to set the dest processor apic id in the 8111 io
apic reg setup for IRQ0.

Thanks.

YH



From vgoyal at in.ibm.com  Fri Jan  6 05:50:26 2006
From: vgoyal at in.ibm.com (Vivek Goyal)
Date: Fri, 6 Jan 2006 10:20:26 +0530
Subject: [LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch
In-Reply-To: <20060105163848.3275a220.akpm@osdl.org>
References: <20060103044632.GA4969@in.ibm.com>
	<86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>
	<20060105163848.3275a220.akpm@osdl.org>
Message-ID: <20060106045026.GA4928@in.ibm.com>

On Thu, Jan 05, 2006 at 04:38:48PM -0800, Andrew Morton wrote:
> Yinghai Lu <yinghai.lu at amd.com> wrote:
> >
> > the patch is good.
> > 
> > I tried LinuxBIOS with kexec.
> > 
> > without this patch: I need to disable acpi in kernel. otherwise the
> > kernel with acpi support can boot the second kernel, but the second
> > kernel will hang after
> > 
> > time.c: Using 14.318180 MHz HPET timer.
> > time.c: Detected 2197.663 MHz processor.
> > Console: colour VGA+ 80x25
> > Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> > Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> > Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )
> > 
> > 
> 
> Please don't top-post.
> 
> > 
> > On 1/2/06, Vivek Goyal <vgoyal at in.ibm.com> wrote:
> > > Hi Andi,
> > >
> > > Can you please include the following patch. This patch has already been pushed
> > > by Andrew.
> > >
> > > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch
> 
> IIRC, I dropped this patch because of discouraging noises from Andi and
> because underlying x86_64 changes broke it in ugly ways.  It needs to be
> redone and Andi's objections (whatever they were) need to be addressed or
> argued about.
> 

Andrew, as per my information this patch has not broken anything. It was
other patch which tried to initialize ioapics early which had broken some
sysmtems and that patch has already been dropped.

Andi's main concern with this patch is that it has got special case
knowledge of 8259 and legacy stuff. He would rather prefer, saving all the
APIC states early during boot and restore it back during reboot.

This shall work well for kexec but will not work for kdump as we might
crash on a non-boot cpu and second kernel will come up on a non-boot cpu.
Just restoring the APIC states shall ensure that kernel can boot well on
BIOS designated boot cpu but it does not hold good for other cpus. One
example is that other cpus will not receive timer interrupts during early
boot.

Hence there does not seem to be any escape route except relocate
to boot cpu after crash and second kernel comes up on BIOS designated
boot cpu. But after crash relocating to boot cpu might not be a very
reliable thing to do.

Thanks
Vivek



From ebiederm at xmission.com  Fri Jan  6 09:02:16 2006
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 06 Jan 2006 01:02:16 -0700
Subject: [LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch
In-Reply-To: <20060105163848.3275a220.akpm@osdl.org> (Andrew Morton's
	message of "Thu, 5 Jan 2006 16:38:48 -0800")
References: <20060103044632.GA4969@in.ibm.com>
	<86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>
	<20060105163848.3275a220.akpm@osdl.org>
Message-ID: <m164ox6ayf.fsf@ebiederm.dsl.xmission.com>

Andrew Morton <akpm at osdl.org> writes:
>
> Please don't top-post.
>
>> 
>> On 1/2/06, Vivek Goyal <vgoyal at in.ibm.com> wrote:
>> > Hi Andi,
>> >
>> > Can you please include the following patch. This patch has already been
> pushed
>> > by Andrew.
>> >
>> >
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch
>
> IIRC, I dropped this patch because of discouraging noises from Andi and
> because underlying x86_64 changes broke it in ugly ways.

Ok.  I just as extensively as I could and I can't find the under laying
x86_64 changes that Andi mentioned he was working on.  I have looked
in current -mm and in Andi merge and experimental quilt trees.  It
could be that I'm  blind but I looked and I did not see them.

Even in the discussion where this was mentioned there never was a 
semantic conflict.  But rather two patches passing so close they
touched the same or neighboring lines of code.

> It needs to be
> redone and Andi's objections (whatever they were) need to be addressed or
> argued about.

The difference was one of approach.  Andi wanted us to treat the apics
as black boxes and save and restore register values with no regard as
to what the registers did.  This is theoretically more future proof,
but it looses flexibility.

My approach is to treat the apics as something we understand, and
simply save off the one small piece of information from the boot
time state that we can't discover any other way.

The x86_64-ioapic-virtual-wire-mode-fix.patch in 2.6.15-mm1 actually
takes advantage of the fact we understand what the apics are doing
to change the destination cpu, in the kexec on panic case.  This
is something that cannot be done if we simply saved off the registers.
     
> Right now the patch is rather dead.

Current the referred to patch applies just fine, to 2.6.15,
and except for a conflict with the above mentioned patch which
applies fine to 2.6.15-mm1 as well.

Putting the apics in a state where we can use them if fundamental
so to booting a kernel so this is something we need to resolve
if we want kexec to be usable.

A revived version of the patch that applies without patch
follows.


Eric




From ebiederm at xmission.com  Fri Jan  6 09:14:16 2006
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 06 Jan 2006 01:14:16 -0700
Subject: [LinuxBIOS] [PATCH] i386 io_apic: Use correct index variable when
 computing the apic that is in ExtInt mode.
In-Reply-To: <20060105163848.3275a220.akpm@osdl.org> (Andrew Morton's
	message of "Thu, 5 Jan 2006 16:38:48 -0800")
References: <20060103044632.GA4969@in.ibm.com>
	<86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>
	<20060105163848.3275a220.akpm@osdl.org>
Message-ID: <m11wzl6aef.fsf_-_@ebiederm.dsl.xmission.com>


Somehow in all of the chaos this one line bug fix got merged with
the another patch and was then discarded when issues were found
with that other patch.

 From: Vivek Goyal <vgoyal at in.ibm.com>

  A minor fix to the patch which remembers the location of where i8259 is
  connected.  Now counter i has been replaced by apic.  counter i is having
  some junk value which was leading to non-detection of i8259 connected to
  IOAPIC.

---

 arch/i386/kernel/io_apic.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

b5a215b462de26a1e6c21f607677796f0bb446aa
diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
index 7554f8f..f2dd218 100644
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -1649,7 +1649,7 @@ static void __init enable_IO_APIC(void)
 	for(apic = 0; apic < nr_ioapics; apic++) {
 		int pin;
 		/* See if any of the pins is in ExtINT mode */
-		for(pin = 0; pin < nr_ioapic_registers[i]; pin++) {
+		for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) {
 			struct IO_APIC_route_entry entry;
 			spin_lock_irqsave(&ioapic_lock, flags);
 			*(((int *)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin);



From ebiederm at xmission.com  Fri Jan  6 09:20:35 2006
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 06 Jan 2006 01:20:35 -0700
Subject: [LinuxBIOS] [PATCH] x86_64 io_apic: memorize at bootup where the
	i8259 is
In-Reply-To: <20060105163848.3275a220.akpm@osdl.org> (Andrew Morton's
	message of "Thu, 5 Jan 2006 16:38:48 -0800")
References: <20060103044632.GA4969@in.ibm.com>
	<86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>
	<20060105163848.3275a220.akpm@osdl.org>
Message-ID: <m1wthd4vjg.fsf_-_@ebiederm.dsl.xmission.com>


Currently we attempt to restore virtual wire mode on reboot, which only
works if we can figure out where the i8259 is connected.  This is very
useful when we are kexec another kernel and likely helpful to an peculiar
BIOS that make assumptions about how the system is setup.

Since the acpi MADT table does not provide the location where the i8259 is
connected we have to look at the hardware to figure it out.

Most systems have the i8259 connected the local apic of the cpu so won't be
affected but people running Opteron and some serverworks chipsets should be
able to use kexec now.

In addition this patch removes the hard coded assumption that the io_apic
that delivers isa interrups is always known to the kernel as io_apic 0.
There does not appear to be anything to guarantee that assumption is true.

This patch does not do a blind save and restore of ioapci registers
as that looses the flexibility that is present when you understand what
the registers actually do.  Currently in the kexec on panic case we actually
use that flexibility to route interrupts all interrupts to the cpu we
are rebooting on.

---

 arch/x86_64/kernel/io_apic.c |  143 ++++++++++++++++++++++++++++++++----------
 1 files changed, 108 insertions(+), 35 deletions(-)

6a51f08f75e2087c50d088c8af21fb98f0ae87a6
diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index ac7a273..de4ad4e 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -46,6 +46,9 @@ static int no_timer_check;
 
 int disable_timer_pin_1 __initdata;
 
+/* Where if anywhere is the i8259 connect in external int mode */
+static struct { int pin, apic; } ioapic_i8259 = { -1, -1 };
+
 static DEFINE_SPINLOCK(ioapic_lock);
 
 /*
@@ -360,7 +363,7 @@ static int find_irq_entry(int apic, int 
 /*
  * Find the pin to which IRQ[irq] (ISA) is connected
  */
-static int find_isa_irq_pin(int irq, int type)
+static int __init find_isa_irq_pin(int irq, int type)
 {
 	int i;
 
@@ -378,6 +381,31 @@ static int find_isa_irq_pin(int irq, int
 	return -1;
 }
 
+static int __init find_isa_irq_apic(int irq, int type)
+{
+	int i;
+
+	for (i = 0; i < mp_irq_entries; i++) {
+		int lbus = mp_irqs[i].mpc_srcbus;
+
+		if ((mp_bus_id_to_type[lbus] == MP_BUS_ISA ||
+		     mp_bus_id_to_type[lbus] == MP_BUS_EISA ||
+		     mp_bus_id_to_type[lbus] == MP_BUS_MCA) &&
+		    (mp_irqs[i].mpc_irqtype == type) &&
+		    (mp_irqs[i].mpc_srcbusirq == irq))
+			break;
+	}
+	if (i < mp_irq_entries) {
+		int apic;
+		for(apic = 0; apic < nr_ioapics; apic++) {
+			if (mp_ioapics[apic].mpc_apicid == mp_irqs[i].mpc_dstapic)
+				return apic;
+		}
+	}
+
+	return -1;
+}
+
 /*
  * Find a specific PCI IRQ entry.
  * Not an __init, possibly needed by modules
@@ -871,7 +899,7 @@ static void __init setup_IO_APIC_irqs(vo
  * Set up the 8259A-master output pin as broadcast to all
  * CPUs.
  */
-static void __init setup_ExtINT_IRQ0_pin(unsigned int pin, int vector)
+static void __init setup_ExtINT_IRQ0_pin(unsigned int apic, unsigned int pin, int vector)
 {
 	struct IO_APIC_route_entry entry;
 	unsigned long flags;
@@ -905,8 +933,8 @@ static void __init setup_ExtINT_IRQ0_pin
 	 * Add it to the IO-APIC irq-routing table:
 	 */
 	spin_lock_irqsave(&ioapic_lock, flags);
-	io_apic_write(0, 0x11+2*pin, *(((int *)&entry)+1));
-	io_apic_write(0, 0x10+2*pin, *(((int *)&entry)+0));
+	io_apic_write(apic, 0x11+2*pin, *(((int *)&entry)+1));
+	io_apic_write(apic, 0x10+2*pin, *(((int *)&entry)+0));
 	spin_unlock_irqrestore(&ioapic_lock, flags);
 
 	enable_8259A_irq(0);
@@ -1185,7 +1213,8 @@ void __apicdebuginit print_PIC(void)
 static void __init enable_IO_APIC(void)
 {
 	union IO_APIC_reg_01 reg_01;
-	int i;
+	int i8259_apic, i8259_pin;
+	int i, apic;
 	unsigned long flags;
 
 	for (i = 0; i < PIN_MAP_SIZE; i++) {
@@ -1199,11 +1228,48 @@ static void __init enable_IO_APIC(void)
 	/*
 	 * The number of IO-APIC IRQ registers (== #pins):
 	 */
-	for (i = 0; i < nr_ioapics; i++) {
+	for (apic = 0; apic < nr_ioapics; apic++) {
 		spin_lock_irqsave(&ioapic_lock, flags);
-		reg_01.raw = io_apic_read(i, 1);
+		reg_01.raw = io_apic_read(apic, 1);
 		spin_unlock_irqrestore(&ioapic_lock, flags);
-		nr_ioapic_registers[i] = reg_01.bits.entries+1;
+		nr_ioapic_registers[apic] = reg_01.bits.entries+1;
+	}
+	for(apic = 0; apic < nr_ioapics; apic++) {
+		int pin;
+		/* See if any of the pins is in ExtINT mode */
+		for (pin = 0; pin < nr_ioapic_registers[apic]; pin++) {
+			struct IO_APIC_route_entry entry;
+			spin_lock_irqsave(&ioapic_lock, flags);
+			*(((int *)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
+			*(((int *)&entry) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
+			spin_unlock_irqrestore(&ioapic_lock, flags);
+
+
+			/* If the interrupt line is enabled and in ExtInt mode
+			 * I have found the pin where the i8259 is connected.
+			 */
+			if ((entry.mask == 0) && (entry.delivery_mode == dest_ExtINT)) {
+				ioapic_i8259.apic = apic;
+				ioapic_i8259.pin  = pin;
+				goto found_i8259;
+			}
+		}
+	}
+ found_i8259:
+	/* Look to see what if the MP table has reported the ExtINT */
+	i8259_pin  = find_isa_irq_pin(0, mp_ExtINT);
+	i8259_apic = find_isa_irq_apic(0, mp_ExtINT);
+	/* Trust the MP table if nothing is setup in the hardware */
+	if ((ioapic_i8259.pin == -1) && (i8259_pin >= 0)) {
+		printk(KERN_WARNING "ExtINT not setup in hardware but reported by MP table\n");
+		ioapic_i8259.pin  = i8259_pin;
+		ioapic_i8259.apic = i8259_apic;
+	}
+	/* Complain if the MP table and the hardware disagree */
+	if (((ioapic_i8259.apic != i8259_apic) || (ioapic_i8259.pin != i8259_pin)) &&
+		(i8259_pin >= 0) && (ioapic_i8259.pin >= 0))
+	{
+		printk(KERN_WARNING "ExtINT in hardware and MP table differ\n");
 	}
 
 	/*
@@ -1217,7 +1283,6 @@ static void __init enable_IO_APIC(void)
  */
 void disable_IO_APIC(void)
 {
-	int pin;
 	/*
 	 * Clear the IO-APIC before rebooting:
 	 */
@@ -1228,8 +1293,7 @@ void disable_IO_APIC(void)
 	 * Put that IOAPIC in virtual wire mode
 	 * so legacy interrupts can be delivered.
 	 */
-	pin = find_isa_irq_pin(0, mp_ExtINT);
-	if (pin != -1) {
+	if (ioapic_i8259.pin != -1) {
 		struct IO_APIC_route_entry entry;
 		unsigned long flags;
 
@@ -1240,7 +1304,7 @@ void disable_IO_APIC(void)
 		entry.polarity        = 0; /* High */
 		entry.delivery_status = 0;
 		entry.dest_mode       = 0; /* Physical */
-		entry.delivery_mode   = 7; /* ExtInt */
+		entry.delivery_mode   = dest_ExtINT; /* ExtInt */
 		entry.vector          = 0;
 		entry.dest.physical.physical_dest =
 					GET_APIC_ID(apic_read(APIC_ID));
@@ -1249,12 +1313,14 @@ void disable_IO_APIC(void)
 		 * Add it to the IO-APIC irq-routing table:
 		 */
 		spin_lock_irqsave(&ioapic_lock, flags);
-		io_apic_write(0, 0x11+2*pin, *(((int *)&entry)+1));
-		io_apic_write(0, 0x10+2*pin, *(((int *)&entry)+0));
+		io_apic_write(ioapic_i8259.apic, 0x11+2*ioapic_i8259.pin,
+			*(((int *)&entry)+1));
+		io_apic_write(ioapic_i8259.apic, 0x10+2*ioapic_i8259.pin,
+			*(((int *)&entry)+1));
 		spin_unlock_irqrestore(&ioapic_lock, flags);
 	}
 
-	disconnect_bsp_APIC(pin != -1);
+	disconnect_bsp_APIC(ioapci_i8259.pin != -1);
 }
 
 /*
@@ -1623,20 +1689,21 @@ static void setup_nmi (void)
  */
 static inline void unlock_ExtINT_logic(void)
 {
-	int pin, i;
+	int apic, pin, i;
 	struct IO_APIC_route_entry entry0, entry1;
 	unsigned char save_control, save_freq_select;
 	unsigned long flags;
 
-	pin = find_isa_irq_pin(8, mp_INT);
+	pin  = find_isa_irq_pin(8, mp_INT);
+	apic = find_isa_irq_apic(8, mp_INT);
 	if (pin == -1)
 		return;
 
 	spin_lock_irqsave(&ioapic_lock, flags);
-	*(((int *)&entry0) + 1) = io_apic_read(0, 0x11 + 2 * pin);
-	*(((int *)&entry0) + 0) = io_apic_read(0, 0x10 + 2 * pin);
+	*(((int *)&entry0) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
+	*(((int *)&entry0) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
 	spin_unlock_irqrestore(&ioapic_lock, flags);
-	clear_IO_APIC_pin(0, pin);
+	clear_IO_APIC_pin(apic, pin);
 
 	memset(&entry1, 0, sizeof(entry1));
 
@@ -1649,8 +1716,8 @@ static inline void unlock_ExtINT_logic(v
 	entry1.vector = 0;
 
 	spin_lock_irqsave(&ioapic_lock, flags);
-	io_apic_write(0, 0x11 + 2 * pin, *(((int *)&entry1) + 1));
-	io_apic_write(0, 0x10 + 2 * pin, *(((int *)&entry1) + 0));
+	io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&entry1) + 1));
+	io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&entry1) + 0));
 	spin_unlock_irqrestore(&ioapic_lock, flags);
 
 	save_control = CMOS_READ(RTC_CONTROL);
@@ -1668,11 +1735,11 @@ static inline void unlock_ExtINT_logic(v
 
 	CMOS_WRITE(save_control, RTC_CONTROL);
 	CMOS_WRITE(save_freq_select, RTC_FREQ_SELECT);
-	clear_IO_APIC_pin(0, pin);
+	clear_IO_APIC_pin(apic, pin);
 
 	spin_lock_irqsave(&ioapic_lock, flags);
-	io_apic_write(0, 0x11 + 2 * pin, *(((int *)&entry0) + 1));
-	io_apic_write(0, 0x10 + 2 * pin, *(((int *)&entry0) + 0));
+	io_apic_write(apic, 0x11 + 2 * pin, *(((int *)&entry0) + 1));
+	io_apic_write(apic, 0x10 + 2 * pin, *(((int *)&entry0) + 0));
 	spin_unlock_irqrestore(&ioapic_lock, flags);
 }
 
@@ -1684,7 +1751,7 @@ static inline void unlock_ExtINT_logic(v
  */
 static inline void check_timer(void)
 {
-	int pin1, pin2;
+	int apic1, pin1, apic2, pin2;
 	int vector;
 
 	/*
@@ -1705,10 +1772,13 @@ static inline void check_timer(void)
 	init_8259A(1);
 	enable_8259A_irq(0);
 
-	pin1 = find_isa_irq_pin(0, mp_INT);
-	pin2 = find_isa_irq_pin(0, mp_ExtINT);
+	pin1  = find_isa_irq_pin(0, mp_INT);
+	apic1 = find_isa_irq_apic(0, mp_INT);
+	pin2  = ioapic_i8259.pin;
+	apic2 = ioapic_i8259.apic;
 
-	apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X pin1=%d pin2=%d\n", vector, pin1, pin2);
+	apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X apic1=%d pin1=%d apic2=%d pin2=%d\n",
+		vector, apic1, pin1, apic2, pin2);
 
 	if (pin1 != -1) {
 		/*
@@ -1726,17 +1796,20 @@ static inline void check_timer(void)
 				clear_IO_APIC_pin(0, pin1);
 			return;
 		}
-		clear_IO_APIC_pin(0, pin1);
-		apic_printk(APIC_QUIET,KERN_ERR "..MP-BIOS bug: 8254 timer not connected to IO-APIC\n");
+		clear_IO_APIC_pin(apic1, pin1);
+		apic_printk(APIC_QUIET,KERN_ERR "..MP-BIOS bug: 8254 timer not "
+				"connected to IO-APIC\n");
 	}
 
-	apic_printk(APIC_VERBOSE,KERN_INFO "...trying to set up timer (IRQ0) through the 8259A ... ");
+	apic_printk(APIC_VERBOSE,KERN_INFO "...trying to set up timer (IRQ0) "
+				"through the 8259A ... ");
 	if (pin2 != -1) {
-		apic_printk(APIC_VERBOSE,"\n..... (found pin %d) ...", pin2);
+		apic_printk(APIC_VERBOSE,"\n..... (found apic %d pin %d) ...",
+			apic2, pin2);
 		/*
 		 * legacy devices should be connected to IO APIC #0
 		 */
-		setup_ExtINT_IRQ0_pin(pin2, vector);
+		setup_ExtINT_IRQ0_pin(apic2, pin2, vector);
 		if (timer_irq_works()) {
 			printk("works.\n");
 			nmi_watchdog_default();
@@ -1748,7 +1821,7 @@ static inline void check_timer(void)
 		/*
 		 * Cleanup, just in case ...
 		 */
-		clear_IO_APIC_pin(0, pin2);
+		clear_IO_APIC_pin(apic2, pin2);
 	}
 	printk(" failed.\n");
 




From ebiederm at xmission.com  Fri Jan  6 09:24:31 2006
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 06 Jan 2006 01:24:31 -0700
Subject: [LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch
In-Reply-To: <86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>
	(Yinghai Lu's message of "Thu, 5 Jan 2006 16:30:05 -0800")
References: <20060103044632.GA4969@in.ibm.com>
	<86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>
Message-ID: <m1sls14vcw.fsf@ebiederm.dsl.xmission.com>

Yinghai Lu <yinghai.lu at amd.com> writes:

> the patch is good.
>
> I tried LinuxBIOS with kexec.
>
> without this patch: I need to disable acpi in kernel. otherwise the
> kernel with acpi support can boot the second kernel, but the second
> kernel will hang after
>
> time.c: Using 14.318180 MHz HPET timer.
> time.c: Detected 2197.663 MHz processor.
> Console: colour VGA+ 80x25
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> Memory: 1009152k/1048576k available (2967k kernel code, 39036k reserved, 1186k )

Yes. This is the reason the patch was written.  Every bios that
implements acpi has this problem.

Eric



From ward at gnu.org  Fri Jan  6 16:21:35 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 6 Jan 2006 10:21:35 -0500
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
In-Reply-To: <43BB0FFF.5060209@lanl.gov>
References: <20051216043022.GA18934@io.pong.be>
	<20060103233832.GA8073@io.pong.be> <43BB0FFF.5060209@lanl.gov>
Message-ID: <20060106152135.GA9448@io.pong.be>

On Tue, Jan 03, 2006 at 04:59:59PM -0700, Ronald G Minnich wrote:
> Ward, ollie will be back tomorrow, we are doing builds for this board so 
> will take a look.

Thanks Ron. Looking forward to what you can find out. I'm going to try a few
more things today to see if I can pinpoint the problem more accurately.

Ward.

--
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From ward at gnu.org  Fri Jan  6 16:49:32 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 6 Jan 2006 10:49:32 -0500
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A42030949B0@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949B0@ssvlexmb2.amd.com>
Message-ID: <20060106154932.GA11826@io.pong.be>

On Tue, Jan 03, 2006 at 04:50:39PM -0800, Lu, Yinghai wrote:
> Can you try with single HD instead of RAID5?

I haven't tried that yet, but I just tried after having the raid array
rebuilt running the proprietary BIOS.

The serial log is attached. It took longer now to crash, just as I observed
the first time I succesfully booted LinuxBIOS. I got a login prompt and
things worked fine for a few minutes. After that, the same thing: serial log
shows that the fallback image is being restarted, and the machine just hangs.

In other words, heavy disk activity (sw-raid5 rebuilding) seems to trigger the
crashes more quickly than otherwise.

Thanks,
Ward.

--
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator
-------------- next part --------------


LinuxBIOS-1.1.8_s2881_Fallback Tue Jan  3 17:36:16 EST 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
 core0:  --- {  APICID = 02 NODEID = 01 COREID = 00} ---
SBLink=02
NC node|link=02
ht reset -


LinuxBIOS-1.1.8_s2881_Fallback Tue Jan  3 17:36:16 EST 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
 core0:  --- {  APICID = 02 NODEID = 01 COREID = 00} ---
SBLink=02
NC node|link=02
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory:  done
Initializing memory:  done
Ram4
v_esp=000cfd40
cpu_reset = 00000000
Clearing initial memory region: No cache as ram now - Use Ram as Stack now - done
new_cpu_reset = 00000000
Copying LinuxBIOS to ram.
src=fffe0004
dst=00004000
linxbios_ram.bin length = 0001928c
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8_s2881_Fallback Tue Jan  3 18:10:55 EST 2006 booting...
Enumerating buses...
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 enabled
  PCI: 00:18.3 siblings=1
CPU: APIC: 00 enabled
CPU: APIC: 01 enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] enabled
  PCI: 00:19.3 siblings=1
CPU: APIC: 02 enabled
CPU: APIC: 03 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] enabled
PCI: 01:00.0 [1022/7450] enabled
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:00.0 [1022/7460] enabled
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] enabled
PCI: 01:03.0 [1022/7460] enabled
PCI: 01:04.0 [1022/7468] enabled
PCI: 01:04.1 [1022/7469] enabled
PCI: 01:04.2 [1022/746a] enabled
PCI: 01:04.3 [1022/746b] enabled
PCI: pci_scan_bus for bus 2
PCI: 02:09.0 [14e4/1648] enabled
PCI: 02:09.1 [14e4/1648] enabled
Disabling static device: PCI: 02:0a.0
Disabling static device: PCI: 02:0a.1
PCI: pci_scan_bus returning with max=02
PCI: 02: 100MHz PCI-X
PCI: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: 03: 133MHz PCI-X
PCI: pci_scan_bus for bus 4
PCI: 04:00.0 [1022/7464] enabled
PCI: 04:00.1 [1022/7464] enabled
PCI: 04:05.0 [1095/3114] enabled
PCI: 04:06.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=04
PNP: 002e.0 enabled
PNP: 002e.1 disabled
PNP: 002e.2 enabled
PNP: 002e.3 disabled
PNP: 002e.5 enabled
PNP: 002e.6 disabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
PNP: 002e.b enabled
smbus: PCI: 01:04.3[0]->I2C: 01:50 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:51 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:52 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:53 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:54 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:55 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:56 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:57 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:2d enabled
smbus: PCI: 01:04.3[0]->I2C: 01:2a enabled
smbus: PCI: 01:04.3[0]->I2C: 01:49 enabled
smbus: PCI: 01:04.3[0]->I2C: 01:4a enabled
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus returning with max=04
done
Allocating resources...
Reading resources...
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 4 prefmem
Done reading resources.
Setting resources...
PCI: 00:18.0 1ba <- [0x00fd300000 - 0x00fd2fffff] prefmem <node 0 link 2>
PCI: 00:18.0 1c2 <- [0x0000001000 - 0x0000002fff] io <node 0 link 2>
PCI: 00:18.0 1b2 <- [0x00fc000000 - 0x00fd2fffff] mem <node 0 link 2>
PCI: 01:01.0 20 <- [0x00fd100000 - 0x00fd1fffff] bus 2 mem
PCI: 02:09.0 10 <- [0x00fd100000 - 0x00fd10ffff] mem64
PCI: 02:09.0 18 <- [0x00fd110000 - 0x00fd11ffff] mem64
PCI: 02:09.1 10 <- [0x00fd120000 - 0x00fd12ffff] mem64
PCI: 02:09.1 18 <- [0x00fd130000 - 0x00fd13ffff] mem64
PCI: 01:01.1 10 <- [0x00fd200000 - 0x00fd200fff] mem64
PCI: 01:02.1 10 <- [0x00fd201000 - 0x00fd201fff] mem64
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 4 io
PCI: 01:03.0 20 <- [0x00fc000000 - 0x00fd0fffff] bus 4 mem
PCI: 04:00.0 10 <- [0x00fd000000 - 0x00fd000fff] mem
PCI: 04:00.1 10 <- [0x00fd001000 - 0x00fd001fff] mem
PCI: 04:05.0 10 <- [0x0000001410 - 0x0000001417] io
PCI: 04:05.0 14 <- [0x0000001430 - 0x0000001433] io
PCI: 04:05.0 18 <- [0x0000001420 - 0x0000001427] io
PCI: 04:05.0 1c <- [0x0000001440 - 0x0000001443] io
PCI: 04:05.0 20 <- [0x0000001400 - 0x000000140f] io
PCI: 04:05.0 24 <- [0x00fd003000 - 0x00fd0033ff] mem
PCI: 04:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 04:06.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 04:06.0 18 <- [0x00fd002000 - 0x00fd002fff] mem
PCI: 04:06.0 30 <- [0x00fff80000 - 0x00fff9ffff] romem
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.5 72 <- [0x000000000c - 0x000000000c] irq
PNP: 002e.b 60 <- [0x0000000290 - 0x0000000297] io
PNP: 002e.b 70 <- [0x0000000005 - 0x0000000005] irq
PCI: 01:04.1 20 <- [0x0000002420 - 0x000000242f] io
PCI: 01:04.2 10 <- [0x0000002400 - 0x000000241f] io
PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io
PCI: 00:18.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f8000000 - 0x00fbffffff] mem <gart>
Done setting resources.
Done allocating resources.
Enabling resourcess...
PCI: 00:18.0 cmd <- 140
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 146
PCI: 02:09.0 subsystem <- 10f1/2881
PCI: 02:09.0 cmd <- 142
PCI: 02:09.1 subsystem <- 10f1/2881
PCI: 02:09.1 cmd <- 142
PCI: 01:01.1 subsystem <- 10f1/2881
PCI: 01:01.1 cmd <- 146
PCI: 01:02.1 subsystem <- 10f1/2881
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 0003
PCI: 01:03.0 cmd <- 147
PCI: 04:00.0 subsystem <- 10f1/2881
PCI: 04:00.0 cmd <- 142
PCI: 04:00.1 subsystem <- 10f1/2881
PCI: 04:00.1 cmd <- 142
PCI: 04:05.0 subsystem <- 10f1/2881
PCI: 04:05.0 cmd <- 143
PCI: 04:06.0 subsystem <- 10f1/2881
PCI: 04:06.0 cmd <- 1c3
PCI: 01:04.0 subsystem <- 10f1/2881
PCI: 01:04.0 cmd <- 14f
w83627hf hwm smbus enabled
PCI: 01:04.1 subsystem <- 10f1/2881
PCI: 01:04.1 cmd <- 141
PCI: 01:04.2 subsystem <- 10f1/2881
PCI: 01:04.2 cmd <- 141
PCI: 01:04.3 subsystem <- 10f1/2881
PCI: 01:04.3 cmd <- 141
PCI: 00:18.1 subsystem <- 10f1/2881
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 10f1/2881
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
PCI: 00:19.0 cmd <- 140
PCI: 00:19.1 cmd <- 140
PCI: 00:19.2 cmd <- 140
PCI: 00:19.3 cmd <- 140
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device 20f12
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 0 done.
Clearing memory 1024K - 2097152K: ------------------------------- done
CPU #0 Initialized
start_eip=0x00010000
Initializing CPU #1
CPU: vendor AMD device 20f12
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
start_eip=0x00010000
Initializing CPU #2
CPU: vendor AMD device 20f12
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 2 done.
Clearing memory 2097152K - 5242880K: ----------------++++++++++++++++ done
CPU #2 Initialized
start_eip=0x00010000
Initializing CPU #3
Waiting for 1 CPUS to stop
CPU: vendor AMD device 20f12
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 4096MB, type WB
Setting variable MTRR 1, base: 4096MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range: 1024MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

microcode: equivalent processor rev id  = 0x0210, patch id = 0x00000000
microcode: patch id that want to apply= 0x0000004d
microcode: updated to patch id = 0x0000004d  success
Setting up local apic... apic_id: 3 done.
CPU #3 Initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 01:01.0 init
PCI: 02:09.0 init
PCI: 02:09.1 init
PCI: 01:03.0 init
PCI: 04:05.0 init
PCI: 04:06.0 init
PCI: 01:04.0 init
RTC Init
RTC: Checksum invalid zeroing cmos
Invalid CMOS LB checksum
enabling HPET @0xfed00000
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 01:04.1 init
IDE1 IDE0 PCI: 01:04.3 init
set power on after power fail
smbus: PCI: 01:04.3[0]->I2C: 01:2d init
PCI: 00:18.1 init
PCI: 00:18.2 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:19.0 init
PCI: 00:19.1 init
PCI: 00:19.2 init
PCI: 00:19.3 init
NB: Function 3 Misc Control.. done.
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 000001f4
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000e10  checksum 58d9

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffc0000 - 0xfffdffff
Found ELF candiate at offset 0
Loading Etherboot version: 5.4.1
Dropping non PT_LOAD segment
New segment addr 0x10000 size 0x49160 offset 0x0 filesize 0x9c20
(cleaned up) New segment addr 0x10000 size 0x49160 offset 0x0 filesize 0x9c20
Loading Segment: addr: 0x00000000bff8c000 memsz: 0x0000000000034000 filesz: 0x0000000000009c20
Clearing Segment: addr: 0x00000000bff95c20 memsz: 0x000000000002a3e0
Loading Segment: addr: 0x0000000000044000 memsz: 0x0000000000015160 filesz: 0x0000000000000000
Clearing Segment: addr: 0x0000000000044000 memsz: 0x0000000000015160
Jumping to boot code at 0x100b0
CPU 2063 Mhz
Etherboot 5.4.1 (GPL) http://etherboot.org
Drivers: TG3 FILO   Images: NBI ELF   
Protocols: DHCP TFTP 
Relocating _text from: [000101b0,00059160) to [bfeb7050,bff00000)
Boot from (N)etwork (D)isk or (Q)uit? D

Probing pci disk...
[FILO]FILO version 0.4.1 (root at countzero.vandewege.net) Tue Jan  3 18:09:58 EST 2006
Press <Enter> for default boot, or <Esc> for boot prompt... 2 1 
boot: hde1:/vmlinuz-2.6.12-9-amd64-generic initrd=/initrd.img-2.6.12-9-amd64-generic ro root=/dev/md3 console=tty0 console=ttyS0,115200n8
hde: LBA48: WDC WD740GD-00FLC0                      
hdf: LBA48: WDC WD740GD-00FLC0                      
Mounted ext2fs
Found Linux version 2.6.12-9-amd64-generic (buildd at king) #1 Mon Oct 10 13:27:39 BST 2005 bzImage.
Loading kernel... ok
Loading initrd... ok
Jumping to entry point...
[    0.000000] Bootdata ok (command line is ro root=/dev/md3 console=tty0 console=ttyS0,115200n8)
[    0.000000] Linux version 2.6.12-9-amd64-generic (buildd at king) (gcc version 3.4.5 20050809 (prerelease) (Ubuntu 3.4.4-6ubuntu8)) #1 Mon Oct 10 13:27:39 BST 2005
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 0000000000000e7c type 16
[    0.000000]  BIOS-e820: 0000000000000e7c - 00000000000a0000 (usable)
[    0.000000]  BIOS-e820: 00000000000f0000 - 00000000000f0400 type 16
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
[    0.000000] ACPI: Unable to locate RSDP
[    0.000000] Intel MultiProcessor Specification v1.4
[    0.000000]     Virtual Wire compatibility mode.
[    0.000000] OEM ID: TYAN     <6>Product ID: S2881        <6>APIC at: 0xFEE00000
[    0.000000] Processor #0 15:1 APIC version 16
[    0.000000] Processor #1 15:1 APIC version 16
[    0.000000] WARNING: NR_CPUS limit of 1 reached. Processor ignored.
[    0.000000] Processor #2 15:1 APIC version 16
[    0.000000] WARNING: NR_CPUS limit of 1 reached. Processor ignored.
[    0.000000] Processor #3 15:1 APIC version 16
[    0.000000] WARNING: NR_CPUS limit of 1 reached. Processor ignored.
[    0.000000] I/O APIC #4 Version 17 at 0xFEC00000.
[    0.000000] I/O APIC #5 Version 17 at 0xFD200000.
[    0.000000] I/O APIC #6 Version 17 at 0xFD201000.
[    0.000000] Setting APIC routing to flat
[    0.000000] Processors: 1
[    0.000000] Allocating PCI resources starting at c0000000 (gap: c0000000:40000000)
[    0.000000] Checking aperture...
[    0.000000] CPU 0: aperture @ f8000000 size 64 MB
[    0.000000] CPU 1: aperture @ f8000000 size 64 MB
[    0.000000] Built 1 zonelists
[    0.000000] Kernel command line: ro root=/dev/md3 console=tty0 console=ttyS0,115200n8
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 4096 (order: 12, 131072 bytes)
[    0.000000] time.c: Using 1.193182 MHz PIT timer.
[    0.000000] time.c: Detected 1991.609 MHz processor.
[   15.789028] time.c: Using PIT/TSC based timekeeping.
[   15.789466] Console: colour dummy device 80x25
[   16.009484] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[   16.025086] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[   16.102002] Memory: 4101416k/5242880k available (1620k kernel code, 92332k reserved, 997k data, 136k init)
[   16.131881] Security Framework v1.0.0 initialized
[   16.137053] SELinux:  Disabled at boot.
[   16.141278] Mount-cache hash table entries: 256
[   16.146327] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   16.154621] CPU: L2 Cache: 1024K (64 bytes/line)
[   16.159985] CPU:  stepping 02
[   16.163541] checking if image is initramfs... it is
[   16.500658] Using IO-APIC 4
[   16.503890] Using IO-APIC 5
[   16.507108] Using IO-APIC 6
[   16.520431] Using local APIC timer interrupts.
[   16.575813] Detected 12.447 MHz APIC timer.
[   16.580685] testing NMI watchdog ... OK.
[   16.595291] NET: Registered protocol family 16
[   16.600792] PCI: Using configuration type 1
[   16.605662] mtrr: v2.0 (20020519)
[   16.609777] ACPI: Subsystem revision 20050729
[   16.614825] ACPI: Interpreter disabled.
[   16.619279] Linux Plug and Play Support v0.97 (c) Adam Belay
[   16.625858] pnp: PnP ACPI: disabled
[   16.629948] usbcore: registered new driver usbfs
[   16.635310] usbcore: registered new driver hub
[   16.640488] PCI: Probing PCI hardware
[   16.644748] PCI: Probing PCI hardware (bus 00)
[   16.651252] PCI: Discovered primary peer bus 01 [IRQ]
[   16.657113] PCI: Using IRQ router default [1022/7468] at 0000:01:04.0
[   16.664603] PCI->APIC IRQ transform: 0000:01:04.2[D] -> IRQ 19
[   16.671369] PCI->APIC IRQ transform: 0000:02:09.0[A] -> IRQ 24
[   16.678135] PCI->APIC IRQ transform: 0000:02:09.1[B] -> IRQ 25
[   16.684899] PCI->APIC IRQ transform: 0000:04:00.0[D] -> IRQ 19
[   16.691684] PCI->APIC IRQ transform: 0000:04:00.1[D] -> IRQ 19
[   16.698441] PCI->APIC IRQ transform: 0000:04:05.0[A] -> IRQ 17
[   16.705205] PCI->APIC IRQ transform: 0000:04:06.0[A] -> IRQ 18
[   16.712023] PCI-DMA: Disabling AGP.
[   16.716116] PCI-DMA: aperture base @ f8000000 size 65536 KB
[   16.722570] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[   16.730353] IA32 emulation $Id: sys_ia32.c,v 1.32 2002/03/24 13:02:28 ak Exp $
[   16.738906] audit: initializing netlink socket (disabled)
[   16.745160] audit: initialized
[   16.748789] VFS: Disk quotas dquot_6.5.1
[   16.753340] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[   16.760849] devfs: 2004-01-31 Richard Gooch (rgooch at atnf.csiro.au)
[   16.768036] devfs: boot_options: 0x0
[   16.772212] Initializing Cryptographic API
[   16.776971] PCI: MSI quirk detected. pci_msi_quirk set.
[   16.783022] PCI: MSI quirk detected. pci_msi_quirk set.
[   16.803174] Linux agpgart interface v0.101 (c) Dave Jones
[   16.809515] PNP: No PS/2 controller found. Probing ports directly.
[   16.818289] serio: i8042 AUX port at 0x60,0x64 irq 12
[   16.824205] serio: i8042 KBD port at 0x60,0x64 irq 1
[   16.829965] Serial: 8250/16550 driver $Revision: 1.90 $ 48 ports, IRQ sharing enabled
[   16.839199] ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   16.846317] io scheduler noop registered
[   16.850899] io scheduler anticipatory registered
[   16.856246] io scheduler deadline registered
[   16.861220] io scheduler cfq registered
[   16.865936] RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
[   16.874765] NET: Registered protocol family 2
[   16.889556] IP: routing cache hash table of 65536 buckets, 512Kbytes
[   16.897361] TCP established hash table entries: 524288 (order: 10, 4194304 bytes)
[   16.909069] TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
[   16.917142] TCP: Hash tables configured (established 524288 bind 65536)
[   16.924890] NET: Registered protocol family 8
[   16.929946] NET: Registered protocol family 20
[   16.935254] Freeing unused kernel memory: 136k freed
Loading, please wait...
Begin: Loading modules ...
[   16.961226] input: AT Translated Set 2 keyboard on isa0060/serio0
[   16.970128] Capability LSM initialized
[   16.982946] NET: Registered protocol family 1
[   16.999595] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[   17.006968] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[   17.021176] AMD8111: IDE controller at PCI slot 0000:01:04.1
[   17.027770] AMD8111: chipset revision 3
[   17.032208] AMD8111: not 100% native mode: will probe irqs later
[   17.039170] AMD8111: 0000:01:04.1 (rev 03) UDMA133 controller
[   17.045853]     ide0: BM-DMA at 0x2420-0x2427, BIOS settings: hda:pio, hdb:pio
[   17.054257]     ide1: BM-DMA at 0x2428-0x242f, BIOS settings: hdc:pio, hdd:pio
[   18.195137] hdd: CD-224E, ATAPI CD/DVD-ROM drive
[   18.251509] ide1 at 0x170-0x177,0x376 on irq 15
[   20.826116] hdd: ATAPI 24X CD-ROM drive, 128kB Cache
[   20.831922] Uniform CD-ROM driver Revision: 3.20
[   21.084960] tg3.c:v3.31 (June 8, 2005)
[   21.093457] eth0: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:30:a5:24
[   21.106983] eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] 
[   21.116663] eth0: dma_rwctrl[769f4000]
[   21.131439] eth1: Tigon3 [partno(BCM95704A6) rev 2003 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:30:a5:25
[   21.145003] eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1] 
[   21.154707] eth1: dma_rwctrl[769f4000]
[   21.167480] ohci_hcd 0000:04:00.0: Advanced Micro Devices [AMD] AMD-8111 USB
[   21.175810] ohci_hcd 0000:04:00.0: new USB bus registered, assigned bus number 1
[   21.184402] ohci_hcd 0000:04:00.0: irq 19, io mem 0xfd000000
[   21.243617] hub 1-0:1.0: USB hub found
[   21.247983] hub 1-0:1.0: 3 ports detected
[   21.255572] ohci_hcd 0000:04:00.1: Advanced Micro Devices [AMD] AMD-8111 USB (#2)
[   21.264281] ohci_hcd 0000:04:00.1: new USB bus registered, assigned bus number 2
[   21.272849] ohci_hcd 0000:04:00.1: irq 19, io mem 0xfd001000
[   21.331560] hub 2-0:1.0: USB hub found
[   21.335922] hub 2-0:1.0: 3 ports detected
[   21.353597] SCSI subsystem initialized
[   21.360029] ata1: SATA max UDMA/100 cmd 0xFFFFC20000014080 ctl 0xFFFFC2000001408A bmdma 0xFFFFC20000014000 irq 17
[   21.371953] ata2: SATA max UDMA/100 cmd 0xFFFFC200000140C0 ctl 0xFFFFC200000140CA bmdma 0xFFFFC20000014008 irq 17
[   21.383881] ata3: SATA max UDMA/100 cmd 0xFFFFC20000014280 ctl 0xFFFFC2000001428A bmdma 0xFFFFC20000014200 irq 17
[   21.395817] ata4: SATA max UDMA/100 cmd 0xFFFFC200000142C0 ctl 0xFFFFC200000142CA bmdma 0xFFFFC20000014208 irq 17
[   21.762751] ata1: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
[   21.771110] ata1: dev 0 configured for UDMA/100
[   21.776357] scsi0 : sata_sil
[   22.134595] ata2: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
[   22.142925] ata2: dev 0 configured for UDMA/100
[   22.148172] scsi1 : sata_sil
[   22.506431] ata3: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
[   22.514789] ata3: dev 0 configured for UDMA/100
[   22.520054] scsi2 : sata_sil
[   22.878265] ata4: dev 0 ATA, max UDMA/133, 145226112 sectors: lba48
[   22.886625] ata4: dev 0 configured for UDMA/100
[   22.891888] scsi3 : sata_sil
[   22.895300]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
[   22.902593]   Type:   Direct-Access                      ANSI SCSI revision: 05
[   22.911474]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
[   22.918766]   Type:   Direct-Access                      ANSI SCSI revision: 05
[   22.927652]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
[   22.934968]   Type:   Direct-Access                      ANSI SCSI revision: 05
[   22.943852]   Vendor: ATA       Model: WDC WD740GD-00FL  Rev: 33.0
[   22.951164]   Type:   Direct-Access                      ANSI SCSI revision: 05
[   24.976733] SCSI device sda: 145226112 512-byte hdwr sectors (74356 MB)
[   24.984417] SCSI device sda: drive cache: write back
[   24.990223] SCSI device sda: 145226112 512-byte hdwr sectors (74356 MB)
[   24.997882] SCSI device sda: drive cache: write back
[   25.003646]  /dev/scsi/host0/bus0/target0/lun0: p1 p2 p3 p4
[   25.022643] Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
[   25.029931] SCSI device sdb: 145226112 512-byte hdwr sectors (74356 MB)
[   25.037608] SCSI device sdb: drive cache: write back
[   25.043406] SCSI device sdb: 145226112 512-byte hdwr sectors (74356 MB)
[   25.051087] SCSI device sdb: drive cache: write back
[   25.056833]  /dev/scsi/host1/bus0/target0/lun0: p1 p2 p3 p4
[   25.077402] Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
[   25.084688] SCSI device sdc: 145226112 512-byte hdwr sectors (74356 MB)
[   25.092375] SCSI device sdc: drive cache: write back
[   25.098180] SCSI device sdc: 145226112 512-byte hdwr sectors (74356 MB)
[   25.105836] SCSI device sdc: drive cache: write back
[   25.111591]  /dev/scsi/host2/bus0/target0/lun0: p1 p2 p3 p4
[   25.128052] Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0
[   25.135323] SCSI device sdd: 145226112 512-byte hdwr sectors (74356 MB)
[   25.143009] SCSI device sdd: drive cache: write back
[   25.148804] SCSI device sdd: 145226112 512-byte hdwr sectors (74356 MB)
[   25.156485] SCSI device sdd: drive cache: write back
[   25.162241]  /dev/scsi/host3/bus0/target0/lun0: p1 p2 p3 p4
[   25.181580] Attached scsi disk sdd at scsi3, channel 0, id 0, lun 0
Done.
Begin: Initializing /dev ...
Done.
Begin: Running /scripts/init-premount ...
FATAL: Error inserting fan (/lib/modules/2.6.12-9-amd64-generic/kernel/drivers/acpi/fan.ko): No such device
FATAL: Error inserting thermal (/lib/modules/2.6.12-9-amd64-generic/kernel/drivers/acpi/thermal.ko): No such device
Done.
Begin: Mounting root file system ...
Begin: Running /scripts/local-top ...
[   25.540318] md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
[   25.550112] md: raid1 personality registered as nr 3
[   25.565836] raid5: automatically using best checksumming function: generic_sse
[   25.578673]    generic_sse:  6040.000 MB/sec
[   25.583639] raid5: using function: generic_sse (6040.000 MB/sec)
[   25.591334] md: raid5 personality registered as nr 4
[   25.927657] devfs_mk_dev: could not append to parent for md/0
[   25.936162] md: md0 stopped.
[   25.940462] md: bind<sdb1>
[   25.943738] md: bind<sdc1>
[   25.946990] md: bind<sdd1>
[   25.950255] md: bind<sda1>
[   25.953462] raid1: raid set md0 active with 4 out of 4 mirrors
mdadm: /dev/md0 has been started with 4 drives.
[   25.967558] devfs_mk_dev: could not append to parent for md/1
[   25.976102] md: md1 stopped.
[   25.980400] md: bind<sdb2>
[   25.983674] md: bind<sdc2>
[   25.986936] md: bind<sdd2>
[   25.990189] md: bind<sda2>
[   25.993342] raid5: device sda2 operational as raid disk 0
[   25.999618] raid5: device sdd2 operational as raid disk 3
[   26.005887] raid5: device sdc2 operational as raid disk 2
[   26.012143] raid5: device sdb2 operational as raid disk 1
[   26.018818] raid5: allocated 4270kB for md1
[   26.023664] raid5: raid level 5 set md1 active with 4 out of 4 devices, algorithm 2
[   26.032562] RAID5 conf printout:
[   26.036311]  --- rd:4 wd:4 fd:0
[   26.039959]  disk 0, o:1, dev:sda2
[   26.043909]  disk 1, o:1, dev:sdb2
[   26.047860]  disk 2, o:1, dev:sdc2
[   26.051794]  disk 3, o:1, dev:sdd2
mdadm: /dev/md1 has been started with 4 drives.
[   26.067231] devfs_mk_dev: could not append to parent for md/2
[   26.075803] md: md2 stopped.
[   26.080070] md: bind<sdb3>
[   26.083343] md: bind<sdc3>
[   26.086620] md: bind<sdd3>
[   26.089893] md: bind<sda3>
[   26.093060] raid5: device sda3 operational as raid disk 0
[   26.099310] raid5: device sdd3 operational as raid disk 3
[   26.105575] raid5: device sdc3 operational as raid disk 2
[   26.111844] raid5: device sdb3 operational as raid disk 1
[   26.118514] raid5: allocated 4270kB for md2
[   26.123352] raid5: raid level 5 set md2 active with 4 out of 4 devices, algorithm 2
[   26.132249] RAID5 conf printout:
[   26.135982]  --- rd:4 wd:4 fd:0
[   26.139635]  disk 0, o:1, dev:sda3
[   26.143570]  disk 1, o:1, dev:sdb3
[   26.147529]  disk 2, o:1, dev:sdc3
[   26.151469]  disk 3, o:1, dev:sdd3
mdadm: /dev/md2 has been started with 4 drives.
[   26.170930] devfs_mk_dev: could not append to parent for md/3
[   26.179527] md: md3 stopped.
[   26.183835] md: bind<sdb4>
[   26.187109] md: bind<sdc4>
[   26.190370] md: bind<sdd4>
[   26.193633] md: bind<sda4>
[   26.196791] raid5: device sda4 operational as raid disk 0
[   26.203049] raid5: device sdd4 operational as raid disk 3
[   26.209313] raid5: device sdc4 operational as raid disk 2
[   26.215584] raid5: device sdb4 operational as raid disk 1
[   26.222267] raid5: allocated 4270kB for md3
[   26.227125] raid5: raid level 5 set md3 active with 4 out of 4 devices, algorithm 2
[   26.236029] RAID5 conf printout:
[   26.239771]  --- rd:4 wd:4 fd:0
[   26.243427]  disk 0, o:1, dev:sda4
[   26.247395]  disk 1, o:1, dev:sdb4
[   26.251354]  disk 2, o:1, dev:sdc4
[   26.255294]  disk 3, o:1, dev:sdd4
mdadm: /dev/md3 has been started with 4 drives.
Done.
Begin: Running /scripts/local-premount ...
[   26.282462] Attempting manual resume
[   26.286764] swsusp: Suspend partition has wrong signature?
Done.
[   26.314393] kjournald starting.  Commit interval 5 seconds
[   26.320772] EXT3-fs: mounted filesystem with ordered data mode.
Begin: Running /scripts/local-bottom ...
Done.
Done.
Begin: Running /scripts/init-bottom ...
Done.
 * version 2.86 booting
 * Starting RAID devices...        [ ok ]
 * Starting hardware event daemon...        [ ok ]
 * Creating initial device nodes...        [ ok ]
 * Setting disc parameters...        [ ok ]
[   28.695254] Adding 8795320k swap on /dev/md2.  Priority:-1 extents:1
 * Checking root file system...        /: clean, 64494/25378816 files, 1048481/50743248 blocks
[ ok ]
[   28.797027] EXT3 FS on md3, internal journal
 * Initializing modules...        [ ok ]
 * Cleaning up ifupdown...        [ ok ]
 * Calculating module dependencies...        [ ok ]
 * Loading modules...        [   30.288337] lp: driver loaded but no devices found
[   30.307846] mice: PS/2 mouse device common for all mice
[   30.361307] Real Time Clock Driver v1.12
[ ok ]
 * Setting the system clock...        [   30.737620] input: ImExPS/2 Generic Explorer Mouse on isa0060/serio1
[   31.048255] ts: Compaq touchscreen protocol output
[ ok ]
[   32.962431] device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel at redhat.com
 * Setting up LVM Volume Groups...        [ ok ]
 * Starting Enterprise Volume Management System...        [   33.450594] hdd: packet command error: status=0x51 { DriveReady SeekComplete Error }
[   33.459629] hdd: packet command error: error=0x54 { AbortedCommand LastFailedSense=0x05 }
[   33.469122] ide: failed opcode was: unknown
[   33.474623] cdrom: open failed.
[ ok ]
 * Checking all file systems...        /boot: clean, 30/32064 files, 16118/64128 blocks
/tmp: clean, 11/732960 files, 55826/1463856 blocks
[ ok ]
 * Mounting local filesystems...        [   34.160015] kjournald starting.  Commit interval 5 seconds
[   34.167366] EXT3 FS on md0, internal journal
[   34.172313] EXT3-fs: mounted filesystem with ordered data mode.
[   34.179498] kjournald starting.  Commit interval 5 seconds
[   34.187118] EXT3 FS on md1, internal journal
[   34.192088] EXT3-fs: mounted filesystem with ordered data mode.
/dev/md0 on /boot type ext3 (rw)
/dev/md1 on /tmp type ext3 (rw)
[ ok ]
 * Restoring resolver state...        [ ok ]
 * Setting up networking...        [ ok ]
 * Starting hotplug subsystem...        [ ok ]
 * Configuring network interfaces...        [ ok ]
 * Waiting for network interface to come up...        [   38.131168] NET: Registered protocol family 17
[   39.716558] tg3: eth0: Link is up at 100 Mbps, full duplex.
[   39.723012] tg3: eth0: Flow control is on for TX and on for RX.


[ ok ]
 * Setting up ALSA...        [ ok ]
 * Setting the system clock...        [ ok ]
 * Synchronizing clock to ntp.ubuntulinux.org...        [   62.153430] NET: Registered protocol family 10
[   62.158691] Disabled Privacy Extensions on device ffffffff8035a5a0(lo)
[   62.166405] IPv6 over IPv4 tunneling driver
[ ok ]
 * Initializing random number generator...        [ ok ]
 * Entering runlevel: 2
 * Starting system log daemon...        [ ok ]
 * Starting kernel log daemon...        [ ok ]
 * Starting OpenBSD Secure Shell server...        [ ok ]
 * Starting RAID monitoring services...        [ ok ]
 * Starting deferred execution scheduler...        [ ok ]
 * Starting periodic command scheduler...        [ ok ]
 * Id "T0" respawning too fast: disabled for 5 minutes
Debian GNU/Linux ttyS0 115200 (DIRECT)
**EMSI_REQA77E              
chimera.gnu.org login: 

LinuxBIOS-1.1.8_s2881_Fallback Tue Jan  3 17:36:16 EST 2006 starting...
(0,1) link=00
(1,0) link=00
02 nodes initialized.
 core0:  --- {  APICID = 02 NODEID = 01 COREID = 00} ---
SBLink=02
NC node|link=02

From yinghai.lu at amd.com  Fri Jan  6 19:24:26 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 6 Jan 2006 10:24:26 -0800
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C2@ssvlexmb2.amd.com>

I'm thinking the way that you can use
1. use LinuxBIOS to boot tiny kernel
2. use RAID5 support in Tiny Kernel and kexec to boot the final kernel.


I wonder if the SW RAID access in FILO is a problem....

YH

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Ward Vandewege
Sent: Friday, January 06, 2006 7:50 AM
To: LinuxBIOS
Subject: Re: [LinuxBIOS] tyan s2881 - partial success (update)

On Tue, Jan 03, 2006 at 04:50:39PM -0800, Lu, Yinghai wrote:
> Can you try with single HD instead of RAID5?

I haven't tried that yet, but I just tried after having the raid array
rebuilt running the proprietary BIOS.

The serial log is attached. It took longer now to crash, just as I
observed
the first time I succesfully booted LinuxBIOS. I got a login prompt and
things worked fine for a few minutes. After that, the same thing: serial
log
shows that the fallback image is being restarted, and the machine just
hangs.

In other words, heavy disk activity (sw-raid5 rebuilding) seems to
trigger the
crashes more quickly than otherwise.

Thanks,
Ward.

--
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator




From yinghai.lu at amd.com  Fri Jan  6 20:33:11 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 6 Jan 2006 11:33:11 -0800
Subject: [LinuxBIOS] small 64bit initrd
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>

Any progress about small size 64bit initrd?

I'm using suse 91 rescure initrd, it is about 18M (gzip -9)...

YH




From ward at gnu.org  Fri Jan  6 21:46:04 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 6 Jan 2006 15:46:04 -0500
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C2@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C2@ssvlexmb2.amd.com>
Message-ID: <20060106204604.GA6549@io.pong.be>

On Fri, Jan 06, 2006 at 10:24:26AM -0800, Lu, Yinghai wrote:
> I'm thinking the way that you can use
> 1. use LinuxBIOS to boot tiny kernel
> 2. use RAID5 support in Tiny Kernel and kexec to boot the final kernel.
> 
> I wonder if the SW RAID access in FILO is a problem....

I'm not sure why FILO would care. I now boot off (a drive of) a RAID1
partition, which is a perfectly normal drive partition as far as FILO is
concerned. When the kernel is loaded, it has the sw-raid drivers and hence it
can deal with the RAID5 array. 

Ward.

--
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Fri Jan  6 21:57:24 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 6 Jan 2006 12:57:24 -0800
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C8@ssvlexmb2.amd.com>

Where is the driver module for MD, is it in initrd.img?

YH

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Ward Vandewege
Sent: Friday, January 06, 2006 12:46 PM
To: LinuxBIOS
Subject: Re: [LinuxBIOS] tyan s2881 - partial success (update)

On Fri, Jan 06, 2006 at 10:24:26AM -0800, Lu, Yinghai wrote:
> I'm thinking the way that you can use
> 1. use LinuxBIOS to boot tiny kernel
> 2. use RAID5 support in Tiny Kernel and kexec to boot the final
kernel.
> 
> I wonder if the SW RAID access in FILO is a problem....

I'm not sure why FILO would care. I now boot off (a drive of) a RAID1
partition, which is a perfectly normal drive partition as far as FILO is
concerned. When the kernel is loaded, it has the sw-raid drivers and
hence it
can deal with the RAID5 array. 

Ward.

--
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator

-- 
LinuxBIOS mailing list
LinuxBIOS at openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From ward at gnu.org  Fri Jan  6 22:59:23 2006
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 6 Jan 2006 16:59:23 -0500
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C8@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C8@ssvlexmb2.amd.com>
Message-ID: <20060106215923.GA8999@io.pong.be>

On Fri, Jan 06, 2006 at 12:57:24PM -0800, Lu, Yinghai wrote:
> Where is the driver module for MD, is it in initrd.img?

That's right. It could also be directly in the kernel image.

Ward.

--
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From yinghai.lu at amd.com  Sat Jan  7 01:44:02 2006
From: yinghai.lu at amd.com (Yinghai Lu)
Date: Fri, 6 Jan 2006 16:44:02 -0800
Subject: [LinuxBIOS] [PATCH] x86_64 io_apic: memorize at bootup where
	the i8259 is
In-Reply-To: <m1wthd4vjg.fsf_-_@ebiederm.dsl.xmission.com>
References: <20060103044632.GA4969@in.ibm.com>
	<86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>
	<20060105163848.3275a220.akpm@osdl.org>
	<m1wthd4vjg.fsf_-_@ebiederm.dsl.xmission.com>
Message-ID: <86802c440601061644s18813b1dj25f2b49f3a46a867@mail.gmail.com>

On 1/6/06, Eric W. Biederman <ebiederm at xmission.com> wrote:
>
>@@ -1249,12 +1313,14 @@ void disable_IO_APIC(void)
>                * Add it to the IO-APIC irq-routing table:
>                */
>               spin_lock_irqsave(&ioapic_lock, flags);
>-               io_apic_write(0, 0x11+2*pin, *(((int *)&entry)+1));
>-               io_apic_write(0, 0x10+2*pin, *(((int *)&entry)+0));
>+               io_apic_write(ioapic_i8259.apic, 0x11+2*ioapic_i8259.pin,
>+                       *(((int *)&entry)+1));
>+               io_apic_write(ioapic_i8259.apic, 0x10+2*ioapic_i8259.pin,
>+                       *(((int *)&entry)+1));
>               spin_unlock_irqrestore(&ioapic_lock, flags);
>       }
>
>-       disconnect_bsp_APIC(pin != -1);
>+       disconnect_bsp_APIC(ioapci_i8259.pin != -1);
> }

There is a typo

+               io_apic_write(ioapic_i8259.apic, 0x10+2*ioapic_i8259.pin,
+                       *(((int *)&entry)+1));

===>

+               io_apic_write(ioapic_i8259.apic, 0x10+2*ioapic_i8259.pin,
+                       *(((int *)&entry)+0));

YH



From ak at muc.de  Fri Jan  6 19:59:04 2006
From: ak at muc.de (Andi Kleen)
Date: 6 Jan 2006 19:59:04 +0100
Subject: [LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch
In-Reply-To: <m164ox6ayf.fsf@ebiederm.dsl.xmission.com>
References: <20060103044632.GA4969@in.ibm.com>
	<86802c440601051630i4d52aa2fj1a2990acf858cd63@mail.gmail.com>
	<20060105163848.3275a220.akpm@osdl.org>
	<m164ox6ayf.fsf@ebiederm.dsl.xmission.com>
Message-ID: <20060106185904.GC39582@muc.de>

On Fri, Jan 06, 2006 at 01:02:16AM -0700, Eric W. Biederman wrote:
> Andrew Morton <akpm at osdl.org> writes:
> >
> > Please don't top-post.
> >
> >> 
> >> On 1/2/06, Vivek Goyal <vgoyal at in.ibm.com> wrote:
> >> > Hi Andi,
> >> >
> >> > Can you please include the following patch. This patch has already been
> > pushed
> >> > by Andrew.
> >> >
> >> >
> > http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm3/broken-out/x86_64-io_apicc-memorize-at-bootup-where-the-i8259-is.patch
> >
> > IIRC, I dropped this patch because of discouraging noises from Andi and
> > because underlying x86_64 changes broke it in ugly ways.
> 
> Ok.  I just as extensively as I could and I can't find the under laying
> x86_64 changes that Andi mentioned he was working on.  I have looked
> in current -mm and in Andi merge and experimental quilt trees.  It
> could be that I'm  blind but I looked and I did not see them.
> 
> Even in the discussion where this was mentioned there never was a 
> semantic conflict.  But rather two patches passing so close they
> touched the same or neighboring lines of code.
> 
> > It needs to be
> > redone and Andi's objections (whatever they were) need to be addressed or
> > argued about.
> 
> The difference was one of approach.  Andi wanted us to treat the apics
> as black boxes and save and restore register values with no regard as
> to what the registers did.  This is theoretically more future proof,
> but it looses flexibility.

Well I still think it would be better to do it in the generic way,
but i'm not feeling very strongly about it anymore.

> to change the destination cpu, in the kexec on panic case.  This
> is something that cannot be done if we simply saved off the registers.
>      
> > Right now the patch is rather dead.
> 
> Current the referred to patch applies just fine, to 2.6.15,
> and except for a conflict with the above mentioned patch which
> applies fine to 2.6.15-mm1 as well.


It conflicts with the x86-64 timer routing rewrite I did, but that's currently
on hold because it has some other issues.  I can merge them later, no problem.

-Andi



From yhlu.kernel at gmail.com  Sat Jan  7 22:41:11 2006
From: yhlu.kernel at gmail.com (yhlu)
Date: Sat, 7 Jan 2006 13:41:11 -0800
Subject: [LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch
In-Reply-To: <m17j9b3jse.fsf@ebiederm.dsl.xmission.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949CB@ssvlexmb2.amd.com>
	<86802c440601061832m4898e20fw4c9a8360e85cfa17@mail.gmail.com>
	<86802c440601062238r1b304cd4j2d9c8e14a8324618@mail.gmail.com>
	<86802c440601062320r597d6970i3b120ec90f96abce@mail.gmail.com>
	<86802c440601070143v44ee9f4dua2dcef2a536d4c73@mail.gmail.com>
	<m1ek3k2ojo.fsf@ebiederm.dsl.xmission.com>
	<86802c440601071136n14a0851we97f6db04f940d68@mail.gmail.com>
	<m17j9b3jse.fsf@ebiederm.dsl.xmission.com>
Message-ID: <86802c440601071341g415ac092t575e3535db52316b@mail.gmail.com>

does stefan put the mptable in first 1K?

good way is put mptable 0xf0000:0x100000.

YH

On 1/7/06, Eric W. Biederman <ebiederm at xmission.com> wrote:
> yhlu <yhlu.kernel at gmail.com> writes:
>
> > MPTABLE in LinuxBIOS is put from 0x20, if the system has too many cpu
> > and devices (slots)  the mptable will get bigger than 0x464, so it
> > will use 0x40:67....
>
> Then you or someone moved it.  The base in low memory was originally
> at 0x500, to avoid just these kinds of problems.
>
> > We need to put mptable to [0xf0000:0x100000] together with acpi
> > tables.
>
> Or move it up a few bytes.
>
> > and if it is bigger than 64k, then we have to put it on special
> > postion ...from 1K, and pass the posstion of mptable to the kernel via
> > command line.
> >
> > I will update the code in LinuxBIOS.
>
> Thanks.  It is always a good idea not to assign legacy regions of the
> address space new meanings.
>
> Eric
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



From ebiederm at xmission.com  Sun Jan  8 04:03:35 2006
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Sat, 07 Jan 2006 20:03:35 -0700
Subject: [LinuxBIOS] Inclusion of x86_64 memorize ioapic at bootup patch
In-Reply-To: <86802c440601071341g415ac092t575e3535db52316b@mail.gmail.com>
	(yhlu.kernel@gmail.com's
	message of "Sat, 7 Jan 2006 13:41:11 -0800")
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949CB@ssvlexmb2.amd.com>
	<86802c440601061832m4898e20fw4c9a8360e85cfa17@mail.gmail.com>
	<86802c440601062238r1b304cd4j2d9c8e14a8324618@mail.gmail.com>
	<86802c440601062320r597d6970i3b120ec90f96abce@mail.gmail.com>
	<86802c440601070143v44ee9f4dua2dcef2a536d4c73@mail.gmail.com>
	<m1ek3k2ojo.fsf@ebiederm.dsl.xmission.com>
	<86802c440601071136n14a0851we97f6db04f940d68@mail.gmail.com>
	<m17j9b3jse.fsf@ebiederm.dsl.xmission.com>
	<86802c440601071341g415ac092t575e3535db52316b@mail.gmail.com>
Message-ID: <m13bjz2zg8.fsf@ebiederm.dsl.xmission.com>

yhlu <yhlu.kernel at gmail.com> writes:

> does stefan put the mptable in first 1K?
>
> good way is put mptable 0xf0000:0x100000.

Nothing wrong with that either.  In freebios v1 when all of
that code was introduced we had a lot of boards that did
not map ram in the 0xa0000-0xfffff window.  Which is probably
why everything wound up so low.  If I recall correctly even things
that look for the linuxbios table can find it in the higher
range as well.

Regardless the important thing is not to stomp in the legacy
memory region below 0x500.

Eric




From yinghailu at gmail.com  Sun Jan  8 06:38:12 2006
From: yinghailu at gmail.com (yhlu)
Date: Sat, 7 Jan 2006 21:38:12 -0800
Subject: [LinuxBIOS] Fwd: [issue55] move mptable to 960k to 1M
In-Reply-To: <1136698534.04.0.000645176555041.issue55@openbios.org>
References: <1136698534.04.0.000645176555041.issue55@openbios.org>
Message-ID: <2ea3fae10601072138g47fc197oc9fd85a14c5f1b3b@mail.gmail.com>

Please check the patch.

It will move the mptable to 960k-1M

YH

---------- Forwarded message ----------
From: Yinghai Lu <lxbios at openbios.org>
Date: Jan 7, 2006 9:35 PM
Subject: [issue55] move mptable to 960k to 1M
To: yinghailu at gmail.com



New submission from Yinghai Lu <yinghailu at gmail.com>:

move mptable to high

----------
files: 010706_mv_mptable_high.diff
messages: 311
nosy: yhlu
priority: critical
status: unread
title: move mptable to 960k to 1M

________________________________________________
LinuxBIOS issue tracker <lxbios at openbios.org>
<https://openbios.org/roundup/linuxbios/issue55>
________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 010706_mv_mptable_high.diff
Type: text/x-patch
Size: 5745 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060107/fe2c49e0/attachment.diff>

From cro_marmot at comcast.net  Sun Jan  8 10:10:30 2006
From: cro_marmot at comcast.net (David Hendricks)
Date: Sun, 8 Jan 2006 09:10:30 +0000
Subject: [LinuxBIOS] Public request for a LinuxBIOS for VMware
In-Reply-To: <1187.1136068565@www71.gmx.net>
References: <1187.1136068565@www71.gmx.net>
Message-ID: <20060108091030.0a274ca3@sunder>

I have not yet tested LinuxBIOS with VMWare, but LinuxBIOS has worked
with Xen. Check out Ron Minnich's work with Xen and Plan9.

On Sat, 31 Dec 2005 23:36:05 +0100 (MET)
"Borg No. One" <borg_no.one at gmx.net> wrote:

> Hi.
> >
> 1.)
> Is there someone who
> + already built a LinuxBIOS/OpenBIOS for VMware?
> + is interested in building a LinuxBIOS/OpenBIOS for VMware?
> 
> then please let the LinuxBIOS/OpenBIOS community and me know about
> your work.
> 
> 
> 
> 2.)
> If you think: "How to use 3rd party / modified BIOS in VMware"
> after reading the question(s) above, then you should check following
> links:
> 
> http://www.vmware.com/community/message.jspa?messageID=103265#103265
> http://www.vmware.com/community/thread.jspa?threadID=28149&tstart=0
> http://www.wimsbios.com/phpBB2/viewtopic.php?p=33730&
> http://vmware.itst.org/viewtopic.php?p=10881
> http://www.google.de/search?q=bios440
> 



--David



From rminnich at lanl.gov  Sun Jan  8 17:22:47 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 08 Jan 2006 09:22:47 -0700
Subject: [LinuxBIOS] Fwd: [issue55] move mptable to 960k to 1M
In-Reply-To: <2ea3fae10601072138g47fc197oc9fd85a14c5f1b3b@mail.gmail.com>
References: <1136698534.04.0.000645176555041.issue55@openbios.org>
	<2ea3fae10601072138g47fc197oc9fd85a14c5f1b3b@mail.gmail.com>
Message-ID: <43C13C57.40604@lanl.gov>

is this in the issue tracker or not? We're slipping again. I want things 
in the issue tracker. This is a big patch.

ron



From yinghailu at gmail.com  Sun Jan  8 18:41:30 2006
From: yinghailu at gmail.com (yhlu)
Date: Sun, 8 Jan 2006 09:41:30 -0800
Subject: [LinuxBIOS] Fwd: [issue55] move mptable to 960k to 1M
In-Reply-To: <43C13C57.40604@lanl.gov>
References: <1136698534.04.0.000645176555041.issue55@openbios.org>
	<2ea3fae10601072138g47fc197oc9fd85a14c5f1b3b@mail.gmail.com>
	<43C13C57.40604@lanl.gov>
Message-ID: <2ea3fae10601080941o164a572fia15b44de10b4052c@mail.gmail.com>

issue 55.

I knew it a big patch.

i wonder if we can still use 0x20-0x466 range....

YH

On 1/8/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> is this in the issue tracker or not? We're slipping again. I want things
> in the issue tracker. This is a big patch.
>
> ron
>



From smithbone at gmail.com  Mon Jan  9 07:45:01 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 9 Jan 2006 00:45:01 -0600
Subject: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp
Message-ID: <8a0c36780601082245i5f53315eo4aaa2e027222936c@mail.gmail.com>

While merging in my 440bx patchs to the latest revision I got
unresolved references to the
copy_secondary_start_to_1m_below() function.

if CONFIG_SMP != 1 then this function never gets defined but
initialize_cpus() calls it regardless.

Will copy_secondary_start_to_1m_below() ever be used in the non-smp
case?  If so then it needs a CONFIG_SMP wrapper or needs to get
defined as empty in the #else case of CONFIG_SMP.

--
Richard A. Smith

From smithbone at gmail.com  Mon Jan  9 07:46:44 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 9 Jan 2006 00:46:44 -0600
Subject: [LinuxBIOS] CAR and PIII celeron?
Message-ID: <8a0c36780601082246u118d60e8h60f9e10e496dd87c@mail.gmail.com>

What do I need to do to see if CAR will work on the PIII celeron?

--
Richard A. Smith

From stepan at openbios.org  Mon Jan  9 10:51:22 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon, 9 Jan 2006 10:51:22 +0100
Subject: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp
In-Reply-To: <8a0c36780601082245i5f53315eo4aaa2e027222936c@mail.gmail.com>
References: <8a0c36780601082245i5f53315eo4aaa2e027222936c@mail.gmail.com>
Message-ID: <20060109095121.GA15781@openbios.org>

* Richard Smith <smithbone at gmail.com> [060109 07:45]:
> While merging in my 440bx patchs to the latest revision I got
> unresolved references to the
> copy_secondary_start_to_1m_below() function.

This went bad in r2142. See 
http://snapshots.linuxbios.org/stats/commit-LinuxBIOSv2-2142.log
and http://snapshots.linuxbios.org/stats/abuild-LinuxBIOSv2-2142.log
for more details.

Author: yhlu
Date: 2005-12-14 03:39:33 +0100 (Wed, 14 Dec 2005)
New Revision: 2142

Modified:
   trunk/LinuxBIOSv2/src/config/linuxbios_ram.ld
   trunk/LinuxBIOSv2/src/cpu/amd/car/clear_1m_ram.c
   trunk/LinuxBIOSv2/src/cpu/amd/car/post_cache_as_ram.c
   trunk/LinuxBIOSv2/src/cpu/amd/model_fxx/init_cpus.c
   trunk/LinuxBIOSv2/src/cpu/x86/lapic/lapic_cpu_init.c
   trunk/LinuxBIOSv2/src/cpu/x86/lapic/secondary.S
   trunk/LinuxBIOSv2/src/cpu/x86/pae/pgtbl.c
Log:
issue 51 and 52: set mtrr for ap before stop it, and _RAMBASE above 1M
support and pgtbl after 1M support

Stefan



From nick.barker9 at btinternet.com  Mon Jan  9 11:47:50 2006
From: nick.barker9 at btinternet.com (Nick Barker)
Date: Mon, 9 Jan 2006 10:47:50 -0000
Subject: [LinuxBIOS] any chance to get X fbdev driver to work ?
In-Reply-To: <8a0c36780512291151r19fa6a61i71f1d791a06b9ddd@mail.gmail.com>
Message-ID: <LBEPJONEBEDMPPCKLBBICECMCDAA.nick.barker9@btinternet.com>



-----Original Message-----
From:  Richard Smith
Sent: 29 December 2005 19:52

> And there was much rejoicing.

> Still un-answered is _what_ was trashing parts of the 0x0c0000 area. 
> We have fixed the symptom but not the cause.

Just to add more meat to the knowledge about the Via vga bios, and about what 'might' be going on here:

We do know that the Via vga bios is not entirely 'self sufficient', and makes proprietory calls into the main BIOS through software interrupt 21

During Linuxbios boot and vga initialisation we cater for this by providing an interrupt 21 handler in the Linuxbios code

However I do believe that this bios also makes these int 21 calls during a mode set call, as I believe is done by the various fb drivers, and ceratinly by the Vesa X server. But of course once the kernel is booted the int 21 handler of Linuxbios will have vapourised, although the page 0 vectors to these functions still exist. Consequently any such call will end up wandering around random code, and it is highly probable that this is the cause of the corruption noted.

I have managed to trace the Vesa X server sufficiently to know that it crashes / locks up with its instruction pointer in the 0xf000 segment, where in theory there is no code under Linuxbios, but presumably there is with a stock bios.

Thus the epia M/MII/ML port is not currently VESA compatible - i.e. you can't do a bios call to set the current display mode.

That leaves us with native CLE266 chipset drivers. On my test bed I quite happily run X using the Via X driver for CLE266. I don't have a need for fbdev, and so can't vouch for that.

On my test bed I run either an old homebrew linux built using the Linux 

From rminnich at lanl.gov  Mon Jan  9 16:29:52 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 09 Jan 2006 08:29:52 -0700
Subject: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp
In-Reply-To: <20060109095121.GA15781@openbios.org>
References: <8a0c36780601082245i5f53315eo4aaa2e027222936c@mail.gmail.com>
	<20060109095121.GA15781@openbios.org>
Message-ID: <43C28170.6040109@lanl.gov>

Stefan Reinauer wrote:
> * Richard Smith <smithbone at gmail.com> [060109 07:45]:
> 
>>While merging in my 440bx patchs to the latest revision I got
>>unresolved references to the
>>copy_secondary_start_to_1m_below() function.
> 
> 
> This went bad in r2142. See 
> http://snapshots.linuxbios.org/stats/commit-LinuxBIOSv2-2142.log
> and http://snapshots.linuxbios.org/stats/abuild-LinuxBIOSv2-2142.log
> for more details.
> 
> Author: yhlu
> Date: 2005-12-14 03:39:33 +0100 (Wed, 14 Dec 2005)
> New Revision: 2142
> 
> Modified:
>    trunk/LinuxBIOSv2/src/config/linuxbios_ram.ld
>    trunk/LinuxBIOSv2/src/cpu/amd/car/clear_1m_ram.c
>    trunk/LinuxBIOSv2/src/cpu/amd/car/post_cache_as_ram.c
>    trunk/LinuxBIOSv2/src/cpu/amd/model_fxx/init_cpus.c
>    trunk/LinuxBIOSv2/src/cpu/x86/lapic/lapic_cpu_init.c
>    trunk/LinuxBIOSv2/src/cpu/x86/lapic/secondary.S
>    trunk/LinuxBIOSv2/src/cpu/x86/pae/pgtbl.c
> Log:
> issue 51 and 52: set mtrr for ap before stop it, and _RAMBASE above 1M
> support and pgtbl after 1M support
> 
> Stefan
> 

Yh Lu, this is your patch that broke things, I assume you will fix?

thanks

ron



From rminnich at lanl.gov  Mon Jan  9 16:30:21 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 09 Jan 2006 08:30:21 -0700
Subject: [LinuxBIOS] CAR and PIII celeron?
In-Reply-To: <8a0c36780601082246u118d60e8h60f9e10e496dd87c@mail.gmail.com>
References: <8a0c36780601082246u118d60e8h60f9e10e496dd87c@mail.gmail.com>
Message-ID: <43C2818D.60907@lanl.gov>

Richard Smith wrote:
> What do I need to do to see if CAR will work on the PIII celeron?

I'm almost certain that Eswar's code will work fine for that CPU. I 
would just give it a shot.

ron



From smithbone at gmail.com  Mon Jan  9 17:23:41 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 9 Jan 2006 10:23:41 -0600
Subject: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp
In-Reply-To: <43C28170.6040109@lanl.gov>
References: <8a0c36780601082245i5f53315eo4aaa2e027222936c@mail.gmail.com>
	<20060109095121.GA15781@openbios.org> <43C28170.6040109@lanl.gov>
Message-ID: <8a0c36780601090823o5c326aber684deac4123534da@mail.gmail.com>

>
> Yh Lu, this is your patch that broke things, I assume you will fix?
>

I don't mind fixing it. (I already have for my tree) I just don't know
which fix is prefered.  Either add a wrapper around the call or pull
the definition out and make it compile to a empty function like it
does when _RAMBASE is set to a large value.

--
Richard A. Smith

From stepan at openbios.org  Mon Jan  9 18:02:15 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon, 9 Jan 2006 18:02:15 +0100
Subject: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp
In-Reply-To: <8a0c36780601090823o5c326aber684deac4123534da@mail.gmail.com>
References: <8a0c36780601082245i5f53315eo4aaa2e027222936c@mail.gmail.com>
	<20060109095121.GA15781@openbios.org> <43C28170.6040109@lanl.gov>
	<8a0c36780601090823o5c326aber684deac4123534da@mail.gmail.com>
Message-ID: <20060109170215.GA5107@openbios.org>

* Richard Smith <smithbone at gmail.com> [060109 17:23]:
> >
> > Yh Lu, this is your patch that broke things, I assume you will fix?
> >
> 
> I don't mind fixing it. (I already have for my tree) I just don't know
> which fix is prefered.  Either add a wrapper around the call or pull
> the definition out and make it compile to a empty function like it
> does when _RAMBASE is set to a large value.
 
IMHO the second one would be fine, we did that a couple of times in the
tree.  Both would be fine though I guess. Basically the fix that fixes
the other broken motherboards as well is the preferred one ;-)

Stefan



From yinghai.lu at amd.com  Mon Jan  9 18:14:12 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 9 Jan 2006 09:14:12 -0800
Subject: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949CD@ssvlexmb2.amd.com>

I agree.

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Richard Smith
Sent: Sunday, January 08, 2006 10:45 PM
To: LinuxBIOS
Subject: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp

While merging in my 440bx patchs to the latest revision I got
unresolved references to the
copy_secondary_start_to_1m_below() function.

if CONFIG_SMP != 1 then this function never gets defined but
initialize_cpus() calls it regardless.

Will copy_secondary_start_to_1m_below() ever be used in the non-smp
case?  If so then it needs a CONFIG_SMP wrapper or needs to get
defined as empty in the #else case of CONFIG_SMP.

--
Richard A. Smith
-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From yinghai.lu at amd.com  Mon Jan  9 18:18:24 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 9 Jan 2006 09:18:24 -0800
Subject: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949CE@ssvlexmb2.amd.com>

I want to use wrapper one...

#if CONFIG_SMP==1
copy.....
#endif

YH

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Richard Smith
Sent: Monday, January 09, 2006 8:24 AM
To: LinuxBIOS
Subject: Re: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp

>
> Yh Lu, this is your patch that broke things, I assume you will fix?
>

I don't mind fixing it. (I already have for my tree) I just don't know
which fix is prefered.  Either add a wrapper around the call or pull
the definition out and make it compile to a empty function like it
does when _RAMBASE is set to a large value.

--
Richard A. Smith
-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From yinghailu at gmail.com  Mon Jan  9 18:20:52 2006
From: yinghailu at gmail.com (yhlu)
Date: Mon, 9 Jan 2006 09:20:52 -0800
Subject: [LinuxBIOS] CAR and PIII celeron?
In-Reply-To: <8a0c36780601082246u118d60e8h60f9e10e496dd87c@mail.gmail.com>
References: <8a0c36780601082246u118d60e8h60f9e10e496dd87c@mail.gmail.com>
Message-ID: <2ea3fae10601090920o2f332569jb99efbd1a328e1a4@mail.gmail.com>

check the tyan/s2735 and s2895...

YH

On 1/8/06, Richard Smith <smithbone at gmail.com> wrote:
> What do I need to do to see if CAR will work on the PIII celeron?
>
> --
> Richard A. Smith
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From smithbone at gmail.com  Mon Jan  9 20:04:43 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 9 Jan 2006 13:04:43 -0600
Subject: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A42030949CE@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949CE@ssvlexmb2.amd.com>
Message-ID: <8a0c36780601091104n54925c3cm5333d36ff5b08699@mail.gmail.com>

On 1/9/06, Lu, Yinghai <yinghai.lu at amd.com> wrote:
> I want to use wrapper one...
>
> #if CONFIG_SMP==1
> copy.....
> #endif

Ok.  Thats the current fix I have.

--
Richard A. Smith

From smithbone at gmail.com  Mon Jan  9 20:07:44 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 9 Jan 2006 13:07:44 -0600
Subject: [LinuxBIOS] CAR and PIII celeron?
In-Reply-To: <2ea3fae10601090920o2f332569jb99efbd1a328e1a4@mail.gmail.com>
References: <8a0c36780601082246u118d60e8h60f9e10e496dd87c@mail.gmail.com>
	<2ea3fae10601090920o2f332569jb99efbd1a328e1a4@mail.gmail.com>
Message-ID: <8a0c36780601091107g1646efan23e032e6e8b9ea2e@mail.gmail.com>

On 1/9/06, yhlu <yinghailu at gmail.com> wrote:

> check the tyan/s2735 and s2895...
>

Ok.  I'll work on this after I get it what I have working.

--
Richard A. Smith

From yinghailu at gmail.com  Mon Jan  9 22:05:23 2006
From: yinghailu at gmail.com (yhlu)
Date: Mon, 9 Jan 2006 13:05:23 -0800
Subject: [LinuxBIOS] Fwd: [issue55] move mptable to 960k to 1M
In-Reply-To: <1136840672.39.0.0814090818186.issue55@openbios.org>
References: <1136840672.39.0.0814090818186.issue55@openbios.org>
Message-ID: <2ea3fae10601091305x2d261282qbf2a1558f4d066fe@mail.gmail.com>

---------- Forwarded message ----------
From: Yinghai Lu <lxbios at openbios.org>
Date: Jan 9, 2006 1:04 PM
Subject: [issue55] move mptable to 960k to 1M
To: ollie at lanl.gov, rminnich at lanl.gov, stepan at openbios.org, yinghailu at gmail.com



Yinghai Lu <yinghailu at gmail.com> added the comment:

1. check if mptable cross 0x467
2a. the mpc small than 64k, will move that to 960K-1M
2b. if mpc big than 64k, will move that from 0x500
3. mpf will put on low table, so the kernel can find it.

Please use this one instead of 010706_mv_mptable_high.diff

----------
status: unread -> chatting

________________________________________________
LinuxBIOS issue tracker <lxbios at openbios.org>
<https://openbios.org/roundup/linuxbios/issue55>
________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01092006_mptable_cross_0x467.diff
Type: text/x-patch
Size: 7518 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060109/67c5156e/attachment.diff>

From yinghai.lu at amd.com  Mon Jan  9 22:05:44 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Mon, 9 Jan 2006 13:05:44 -0800
Subject: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949D4@ssvlexmb2.amd.com>

Commited.

-----Original Message-----
From: Richard Smith [mailto:smithbone at gmail.com] 
Sent: Monday, January 09, 2006 11:05 AM
To: Lu, Yinghai
Cc: LinuxBIOS
Subject: Re: [LinuxBIOS] copy_secondary_start_to_1m_below() and non-smp

On 1/9/06, Lu, Yinghai <yinghai.lu at amd.com> wrote:
> I want to use wrapper one...
>
> #if CONFIG_SMP==1
> copy.....
> #endif

Ok.  Thats the current fix I have.

--
Richard A. Smith




From aissaoui_hacen at yahoo.fr  Wed Jan 11 11:52:37 2006
From: aissaoui_hacen at yahoo.fr (Hacen Aissaoui)
Date: Wed, 11 Jan 2006 11:52:37 +0100
Subject: [LinuxBIOS] Anybody having success with EPIA 800? (was Re: EPIA
 halting after vt8601 init?)
In-Reply-To: <13426df10512170804l573f99chd4caeb4d261b1e1e@mail.gmail.com>
References: <43A3DA6F.9020708@yahoo.fr>
	<13426df10512170804l573f99chd4caeb4d261b1e1e@mail.gmail.com>
Message-ID: <43C4E375.7020002@yahoo.fr>

Hello Ron,

Following your previous email, I am coming to the news regarding the 
EPIA 800.
Anything new ? Or perhaps is it too soon ...

hacen

ron minnich wrote:
> I'm going to be trying epia 800 and sc520 in january after vacation. 
> THe 8601 is a problem chipset, and most attempts to make it more 
> flexible generally result in the chipset locknig up in other 
> scenarios. My original, crude code was pretty reliable, the most 
> reliable code in fact. But it would still be nice to have LB more 
> flexible with this chipset.
>  
> ron
>
>  

	
	
		
___________________________________________________________________________ 
Nouveau : t?l?phonez moins cher avec Yahoo! Messenger. Appelez le monde entier ? partir de 0,012 ?/minute ! 
T?l?chargez sur http://fr.messenger.yahoo.com




From rminnich at lanl.gov  Wed Jan 11 16:30:04 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 11 Jan 2006 08:30:04 -0700
Subject: [LinuxBIOS] Anybody having success with EPIA 800? (was Re: EPIA
 halting after vt8601 init?)
In-Reply-To: <43C4E375.7020002@yahoo.fr>
References: <43A3DA6F.9020708@yahoo.fr>	<13426df10512170804l573f99chd4caeb4d261b1e1e@mail.gmail.com>
	<43C4E375.7020002@yahoo.fr>
Message-ID: <43C5247C.6090805@lanl.gov>

Hacen Aissaoui wrote:
> Hello Ron,
> 
> Following your previous email, I am coming to the news regarding the 
> EPIA 800.
> Anything new ? Or perhaps is it too soon ...

I am finishing a firefighting exercise and then hope to get back to this 
problem.

ron



From talbotx at comcast.net  Wed Jan 11 21:33:26 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Wed, 11 Jan 2006 12:33:26 -0800
Subject: [LinuxBIOS] The full "How to"
Message-ID: <43C56B96.2040700@comcast.net>

So I have my new embedded board.  It is running a chip set that is not 
supported, yet.  I have all the doc's, that I think I will need.  I 
would like to start trying to add support for the vt8605/vt8606 based 
board(s). 
Looking for some doc's on the linuxbios web page about were to start and 
what files tie in to the build, and where.  Can some one point me to 
such a doc, or can we build such a doc. 
What files do I need to mod/build?
What order should I work on them?
What kind of response should I be looking for from the console to tell 
me if that step is working?  Stating that I can get console running I 
the first place, yes my superIO is supported.
Is there any "How to" that covers this, or is it time to build one.
-Adam



From mikey at wirelabs.net  Wed Jan 11 21:42:51 2006
From: mikey at wirelabs.net (Michal Szwaczko)
Date: Wed, 11 Jan 2006 21:42:51 +0100
Subject: [LinuxBIOS] The full "How to"
In-Reply-To: <43C56B96.2040700@comcast.net>
References: <43C56B96.2040700@comcast.net>
Message-ID: <20060111204251.GA18150@tokyo>

On Wed, Jan 11, 2006 at 12:33:26PM -0800, Adam Talbot wrote:

> Looking for some doc's on the linuxbios web page about were to start and 
> what files tie in to the build, and where.  Can some one point me to 
> such a doc, or can we build such a doc. 
> What files do I need to mod/build?
> What order should I work on them?

There's Ron's article on porting to AMD SC520 in LJ. Should be a good start 
in general terms.
<URL:http://www.linuxjournal.com/article/8120>
HTH

-- 
[ .O. | Micha? 'Mikey' Szwaczko  | GPG Key#:0x653CBD53 ]
[ ..O | Developer/Troubleshooter | GNU Generation Now! ]
[ OOO | EMACS - Eight Megs And Constantly Swapping.    ]



From rminnich at lanl.gov  Wed Jan 11 21:40:54 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 11 Jan 2006 13:40:54 -0700
Subject: [LinuxBIOS] The full "How to"
In-Reply-To: <43C56B96.2040700@comcast.net>
References: <43C56B96.2040700@comcast.net>
Message-ID: <43C56D56.3010103@lanl.gov>

you could try the linux journal articles for a start. Did you see them?

ron



From ebiederman at lnxi.com  Wed Jan 11 21:51:34 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed, 11 Jan 2006 13:51:34 -0700
Subject: [LinuxBIOS] small 64bit initrd
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>
	(Yinghai Lu's message of "Fri, 6 Jan 2006 11:33:11 -0800")
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>
Message-ID: <m3d5iywkrt.fsf@maxwell.lnxi.com>

"Lu, Yinghai" <yinghai.lu at amd.com> writes:

> Any progress about small size 64bit initrd?
>
> I'm using suse 91 rescure initrd, it is about 18M (gzip -9)...

Which is clearly painful, and way overkill.  

First you asked the wrong question looking from an initrd with a 64bit
user space.  Even for a 64bit kernel you don't need a 64bit user space
and 32bit is smaller and more common.

Second you looked in the wrong place.
What you want is: http://kboot.sourceforge.net/

The intro page lists kboot-9 as being only 39K.  I think that is just
the kboot part but it might be the entire initrd.  Using uclibc I am
certain it is below 1M.  Unfortunately I haven't had a chance to build
it yet.  (Sorry Werner).

Check it out just skimming through the documentation it looks like it
has already surpassed FILO in capabilities.

Eric




From yinghai.lu at amd.com  Wed Jan 11 21:54:48 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 11 Jan 2006 12:54:48 -0800
Subject: [LinuxBIOS] The full "How to"
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949D8@ssvlexmb2.amd.com>

The sc520 one.

-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Ronald G Minnich
Sent: Wednesday, January 11, 2006 12:41 PM
To: Adam Talbot
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] The full "How to"

you could try the linux journal articles for a start. Did you see them?

ron

-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From yinghai.lu at amd.com  Wed Jan 11 22:00:55 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 11 Jan 2006 13:00:55 -0800
Subject: [LinuxBIOS] small 64bit initrd
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949D9@ssvlexmb2.amd.com>

Good, I will look at the kboot.

Is it ok that first kernel is 64 bit and kboot is 32bit? Or in other
words the initrd is 32 bit and kexec tools is 32 bit?

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Wednesday, January 11, 2006 12:52 PM
To: Lu, Yinghai
Cc: linuxbios at openbios.org; Fastboot mailing list;
kboot-general at lists.sourceforge.net
Subject: Re: small 64bit initrd

"Lu, Yinghai" <yinghai.lu at amd.com> writes:

> Any progress about small size 64bit initrd?
>
> I'm using suse 91 rescure initrd, it is about 18M (gzip -9)...

Which is clearly painful, and way overkill.  

First you asked the wrong question looking from an initrd with a 64bit
user space.  Even for a 64bit kernel you don't need a 64bit user space
and 32bit is smaller and more common.

Second you looked in the wrong place.
What you want is: http://kboot.sourceforge.net/

The intro page lists kboot-9 as being only 39K.  I think that is just
the kboot part but it might be the entire initrd.  Using uclibc I am
certain it is below 1M.  Unfortunately I haven't had a chance to build
it yet.  (Sorry Werner).

Check it out just skimming through the documentation it looks like it
has already surpassed FILO in capabilities.

Eric






From rminnich at lanl.gov  Wed Jan 11 22:29:31 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 11 Jan 2006 14:29:31 -0700
Subject: [LinuxBIOS] small 64bit initrd
In-Reply-To: <m3d5iywkrt.fsf@maxwell.lnxi.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>
	<m3d5iywkrt.fsf@maxwell.lnxi.com>
Message-ID: <43C578BB.2010406@lanl.gov>

Eric W. Biederman wrote:

> Check it out just skimming through the documentation it looks like it
> has already surpassed FILO in capabilities.

I think kboot and tinykernels and such could get us back to the original 
vision of linuxbios from years ago -- linux is the bios. Let's hope.

ron



From ebiederman at lnxi.com  Wed Jan 11 23:02:10 2006
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed, 11 Jan 2006 15:02:10 -0700
Subject: [LinuxBIOS] small 64bit initrd
In-Reply-To: <43C578BB.2010406@lanl.gov> (Ronald G. Minnich's message of
	"Wed, 11 Jan 2006 14:29:31 -0700")
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>
	<m3d5iywkrt.fsf@maxwell.lnxi.com> <43C578BB.2010406@lanl.gov>
Message-ID: <m3ace2e84d.fsf@maxwell.lnxi.com>

Ronald G Minnich <rminnich at lanl.gov> writes:

> Eric W. Biederman wrote:
>
>> Check it out just skimming through the documentation it looks like it
>> has already surpassed FILO in capabilities.
>
> I think kboot and tinykernels and such could get us back to the original vision
> of linuxbios from years ago -- linux is the bios. Let's hope.

One step at a time.

A lot of the tiny kernel work has been merged into linus's tree
for 2.6.16.

I think the interesting linuxbios related kboot activities are.
1) Hook mkelfImage into the build so we will easily have an image
   that we can use with linuxbios.
2) Figure out how to use kboot on host nodes :)  Video now works on a good day.

And then there is my very evil plan spam the kboot list on topic discussion :)

Eric



From rminnich at lanl.gov  Wed Jan 11 23:56:19 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 11 Jan 2006 15:56:19 -0700
Subject: [LinuxBIOS] [Kboot-general] Re:  small 64bit initrd
In-Reply-To: <20060111194159.W1174@almesberger.net>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>
	<m3d5iywkrt.fsf@maxwell.lnxi.com> <43C578BB.2010406@lanl.gov>
	<20060111194159.W1174@almesberger.net>
Message-ID: <43C58D13.10509@lanl.gov>

Werner Almesberger wrote:

> Yeah, that would be nice. It would also avoid depending on a
> "traditional" first-stage boot loader to load things from disk.
> (That is, in a standard configuration. kboot doesn't really care
> how you load it.)

note that some of us are trying to go this way in the Plan 9 world too. 
Although it's been easier to do this in Plan 9 for some time -- the Plan 
9 equivalent of kexec went in in 2000, so a kboot-like thing is pretty 
easy. In fact, Werner, I'll probably try to steal as many kboot ideas as 
I can :-)


> 
> By the way, how much flash is in modern x86 motherboards these
> days ?  2 MB would be great for kboot, 

2 MB? dream on :-(

Getting 1 MB is as good as we can do for now.

But, thank Intel for EFI, since that will give us 16 MB ...

ron



From yinghai.lu at amd.com  Thu Jan 12 00:19:27 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 11 Jan 2006 15:19:27 -0800
Subject: [LinuxBIOS] small 64bit initrd
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DA@ssvlexmb2.amd.com>

For LinuxBIOS support, besides mkelfImage, We still need cmos_util...

We may can separate these stuff in two location
1. kernel + initrd( with busybox as shell) --- with this we can access
all media. (I don't want to use udev)
2. final kernel. mkelfImage. Cmos_util....

YH

-----Original Message-----
From: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
Sent: Wednesday, January 11, 2006 2:02 PM
To: Ronald G Minnich
Cc: Lu, Yinghai; linuxbios at openbios.org; Fastboot mailing list;
kboot-general at lists.sourceforge.net
Subject: Re: [LinuxBIOS] small 64bit initrd

Ronald G Minnich <rminnich at lanl.gov> writes:

> Eric W. Biederman wrote:
>
>> Check it out just skimming through the documentation it looks like it
>> has already surpassed FILO in capabilities.
>
> I think kboot and tinykernels and such could get us back to the
original vision
> of linuxbios from years ago -- linux is the bios. Let's hope.

One step at a time.

A lot of the tiny kernel work has been merged into linus's tree
for 2.6.16.

I think the interesting linuxbios related kboot activities are.
1) Hook mkelfImage into the build so we will easily have an image
   that we can use with linuxbios.
2) Figure out how to use kboot on host nodes :)  Video now works on a
good day.

And then there is my very evil plan spam the kboot list on topic
discussion :)

Eric





From smithbone at gmail.com  Thu Jan 12 00:22:19 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 11 Jan 2006 17:22:19 -0600
Subject: [LinuxBIOS] [Kboot-general] Re: small 64bit initrd
In-Reply-To: <43C58D13.10509@lanl.gov>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>
	<m3d5iywkrt.fsf@maxwell.lnxi.com> <43C578BB.2010406@lanl.gov>
	<20060111194159.W1174@almesberger.net> <43C58D13.10509@lanl.gov>
Message-ID: <8a0c36780601111522j469be905gd145333f9f348943@mail.gmail.com>

> >
> > By the way, how much flash is in modern x86 motherboards these
> > days ?  2 MB would be great for kboot,
>
> 2 MB? dream on :-(
>
> Getting 1 MB is as good as we can do for now.
>

Speaking of this has anyone played with Ingo's set of patchs that
remove forced inlineing?

Lwn.net reports he claims a 5% size reduction in his kernel. (over
just the -s compile)  The "allyesconfig" got a 25% reduction.

That + tinykernel might get you in the ballpark.

--
Richard A. Smith

From talbotx at comcast.net  Thu Jan 12 02:09:08 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Wed, 11 Jan 2006 17:09:08 -0800
Subject: [LinuxBIOS] The full "How to"
In-Reply-To: <20060111204251.GA18150@tokyo>
References: <43C56B96.2040700@comcast.net> <20060111204251.GA18150@tokyo>
Message-ID: <43C5AC34.1050708@comcast.net>

Cool, I will start there.  Thank you
-Adam


Michal Szwaczko wrote:

>On Wed, Jan 11, 2006 at 12:33:26PM -0800, Adam Talbot wrote:
>
>  
>
>>Looking for some doc's on the linuxbios web page about were to start and 
>>what files tie in to the build, and where.  Can some one point me to 
>>such a doc, or can we build such a doc. 
>>What files do I need to mod/build?
>>What order should I work on them?
>>    
>>
>
>There's Ron's article on porting to AMD SC520 in LJ. Should be a good start 
>in general terms.
><URL:http://www.linuxjournal.com/article/8120>
>HTH
>
>  
>




From werner at almesberger.net  Wed Jan 11 23:28:56 2006
From: werner at almesberger.net (Werner Almesberger)
Date: Wed, 11 Jan 2006 19:28:56 -0300
Subject: [LinuxBIOS] [Kboot-general] Re: small 64bit initrd
In-Reply-To: <m3d5iywkrt.fsf@maxwell.lnxi.com>;
	from ebiederman@lnxi.com on Wed, Jan 11, 2006 at 01:51:34PM -0700
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>
	<m3d5iywkrt.fsf@maxwell.lnxi.com>
Message-ID: <20060111192856.V1174@almesberger.net>

Eric W. Biederman wrote:
> The intro page lists kboot-9 as being only 39K.

That's just the tar ball. It pulls in (downloads) lots of other
things. A realistic size for the initramfs (compressed) is about
400-500 kB with uclibc. Depending on what you need and how much
time you want to spend tweaking things, you can reduce this some
more, e.g., by dropping things like dropbear.

I once had a complete kboot system (kernel with networking plus
initramfs) on a 1.44MB floppy. I don't remember the exact
feature set, though. It was used to load the initial Gentoo
tarball over the network onto an OQO which had stubbornly
refused from anything but that ancient USB floppy.

> Unfortunately I haven't had a chance to build it yet.  (Sorry Werner).

Lately, I've had a bit of a time shortage myself :-( I expect
kboot to pick up some more speed towards the end of the month,
though.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina     werner at almesberger.net /
/_http://www.almesberger.net/____________________________________________/



From werner at almesberger.net  Wed Jan 11 23:41:59 2006
From: werner at almesberger.net (Werner Almesberger)
Date: Wed, 11 Jan 2006 19:41:59 -0300
Subject: [LinuxBIOS] [Kboot-general] Re:  small 64bit initrd
In-Reply-To: <43C578BB.2010406@lanl.gov>;
	from rminnich@lanl.gov on Wed, Jan 11, 2006 at 02:29:31PM -0700
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>
	<m3d5iywkrt.fsf@maxwell.lnxi.com> <43C578BB.2010406@lanl.gov>
Message-ID: <20060111194159.W1174@almesberger.net>

Ronald G Minnich wrote:
> I think kboot and tinykernels and such could get us back to the original 
> vision of linuxbios from years ago -- linux is the bios. Let's hope.

Yeah, that would be nice. It would also avoid depending on a
"traditional" first-stage boot loader to load things from disk.
(That is, in a standard configuration. kboot doesn't really care
how you load it.)

By the way, how much flash is in modern x86 motherboards these
days ?  2 MB would be great for kboot, more would certainly
invite creative abuse (animated splash screens ;-), 1.5 MB would
be just enough while constantly hitting the ceiling, 1 MB may be
too small to do anything useful.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina     werner at almesberger.net /
/_http://www.almesberger.net/____________________________________________/



From werner at almesberger.net  Thu Jan 12 01:45:13 2006
From: werner at almesberger.net (Werner Almesberger)
Date: Wed, 11 Jan 2006 21:45:13 -0300
Subject: [LinuxBIOS] [Kboot-general] Re:  small 64bit initrd
In-Reply-To: <43C58D13.10509@lanl.gov>;
	from rminnich@lanl.gov on Wed, Jan 11, 2006 at 03:56:19PM -0700
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>
	<m3d5iywkrt.fsf@maxwell.lnxi.com> <43C578BB.2010406@lanl.gov>
	<20060111194159.W1174@almesberger.net> <43C58D13.10509@lanl.gov>
Message-ID: <20060111214513.Z1174@almesberger.net>

Ronald G Minnich wrote:
> In fact, Werner, I'll probably try to steal as many kboot ideas as 
> I can :-)

Good. After all, plagiarism is the most honest form of flattery :-)

> 2 MB? dream on :-(
> 
> Getting 1 MB is as good as we can do for now.

Hmm, that'll get awfully tight :-(

> But, thank Intel for EFI, since that will give us 16 MB ...

Great ! logo.avi, anyone ? :-)

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina     werner at almesberger.net /
/_http://www.almesberger.net/____________________________________________/



From smithbone at gmail.com  Thu Jan 12 04:40:26 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 11 Jan 2006 21:40:26 -0600
Subject: [LinuxBIOS] [Kboot-general] Re: small 64bit initrd
In-Reply-To: <20060111214513.Z1174@almesberger.net>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949C4@ssvlexmb2.amd.com>
	<m3d5iywkrt.fsf@maxwell.lnxi.com> <43C578BB.2010406@lanl.gov>
	<20060111194159.W1174@almesberger.net> <43C58D13.10509@lanl.gov>
	<20060111214513.Z1174@almesberger.net>
Message-ID: <8a0c36780601111940h274a3056n949fc825171ef988@mail.gmail.com>

> >
> > Getting 1 MB is as good as we can do for now.
>
> Hmm, that'll get awfully tight :-(

Its tight but can be done.  I've build a embedded system that booted
out of 1Meg of flash.  2.4 kernel+initrd that loaded a pcmcia module
for the wireless adapter in the system dhcp'ed up the network and then
pulled down a larger ramfs and kexec'ed into it.
I had to build a custom version of the pcmcia tools with uclibc only
doing the absolute minimum to get the wireless interface up.

IIRC I only had a couple of  Kb left over.

--
Richard A. Smith

From yinghai.lu at AMD.COM  Thu Jan 12 18:17:35 2006
From: yinghai.lu at AMD.COM (Lu, Yinghai)
Date: Thu, 12 Jan 2006 09:17:35 -0800
Subject: [LinuxBIOS] [Kboot-general] Re: small 64bit initrd
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>

Kexec support 2.4?

YH

-----Original Message-----
From: Richard Smith [mailto:smithbone at gmail.com] 
Sent: Wednesday, January 11, 2006 7:40 PM
To: Werner Almesberger
Cc: Ronald G Minnich; kboot-general at lists.sourceforge.net;
linuxbios at openbios.org; Fastboot mailing list; Lu, Yinghai
Subject: Re: [LinuxBIOS] [Kboot-general] Re: small 64bit initrd

> >
> > Getting 1 MB is as good as we can do for now.
>
> Hmm, that'll get awfully tight :-(

Its tight but can be done.  I've build a embedded system that booted
out of 1Meg of flash.  2.4 kernel+initrd that loaded a pcmcia module
for the wireless adapter in the system dhcp'ed up the network and then
pulled down a larger ramfs and kexec'ed into it.
I had to build a custom version of the pcmcia tools with uclibc only
doing the absolute minimum to get the wireless interface up.

IIRC I only had a couple of  Kb left over.

--
Richard A. Smith




From smithbone at gmail.com  Thu Jan 12 18:56:08 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 12 Jan 2006 11:56:08 -0600
Subject: [LinuxBIOS] [Kboot-general] Re: small 64bit initrd
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>
Message-ID: <8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>

On 1/12/06, Lu, Yinghai <yinghai.lu at amd.com> wrote:
> Kexec support 2.4?
>

Back when Eric started it did.  2.6.x was still very new.   This was
several years ago.

--
Richard A. Smith

From ebiederm at xmission.com  Fri Jan 13 01:04:42 2006
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Thu, 12 Jan 2006 17:04:42 -0700
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
 initrd
In-Reply-To: <8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>
	(Richard Smith's message of "Thu, 12 Jan 2006 11:56:08 -0600")
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>
	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>
Message-ID: <m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>

Richard Smith <smithbone at gmail.com> writes:

> On 1/12/06, Lu, Yinghai <yinghai.lu at amd.com> wrote:> Kexec support 2.4?>
> Back when Eric started it did.  2.6.x was still very new.  This wasseveral years
> ago.

2.4 is still fairly easy to get going.  The problem is all of the related
hardware fixes which are hard to identify and back port.

Eric



From steve at nexpath.com  Fri Jan 13 20:03:54 2006
From: steve at nexpath.com (Steve Gehlbach)
Date: Fri, 13 Jan 2006 11:03:54 -0800
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
	initrd
In-Reply-To: <m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>
	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>
Message-ID: <43C7F99A.30705@nexpath.com>

If you could provide a roadmap on how to do this, or even better have a 
chance to do it yourself for 2.4.27+ (2.4.32 would be great), that would 
_really_ be useful.

2.4 is a smaller kernel than 2.6, and for supporting legacy systems that 
only boot from floppies, I regularly use it on a single boot floppy, 
using uclibc and busybox, along with e2fs tools and also dialog, for 
lots of support software we develop.  I guess we have a thing about 
getting it all on one floppy, but it would be helpful if we could jump 
into a 2.6 kernel on CD, for some situations.  Legacy systems won't boot 
from CD in most cases.

Steve G.




Eric W. Biederman wrote:

>Richard Smith <smithbone at gmail.com> writes:
>
>  
>
>>On 1/12/06, Lu, Yinghai <yinghai.lu at amd.com> wrote:> Kexec support 2.4?>
>>Back when Eric started it did.  2.6.x was still very new.  This wasseveral years
>>ago.
>>    
>>
>
>2.4 is still fairly easy to get going.  The problem is all of the related
>hardware fixes which are hard to identify and back port.
>
>Eric
>
>  
>




From smithbone at gmail.com  Fri Jan 13 20:01:04 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 13 Jan 2006 13:01:04 -0600
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
	initrd
In-Reply-To: <43C7F99A.30705@nexpath.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>
	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>
	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>
	<43C7F99A.30705@nexpath.com>
Message-ID: <8a0c36780601131101x6a72d511oaf4f6782e9ca0a6b@mail.gmail.com>

On 1/13/06, Steve Gehlbach <steve at nexpath.com> wrote:

> If you could provide a roadmap on how to do this, or even better have a
> chance to do it yourself for 2.4.27+ (2.4.32 would be great), that would
> _really_ be useful.
>
> 2.4 is a smaller kernel than 2.6, and for supporting legacy systems that
> only boot from floppies, I regularly use it on a single boot floppy,
> using uclibc and busybox, along with e2fs tools and also dialog, for

Is is smaller than a linux tiny kernel?

--
Richard A. Smith

From steve at nexpath.com  Fri Jan 13 21:12:38 2006
From: steve at nexpath.com (Steve Gehlbach)
Date: Fri, 13 Jan 2006 12:12:38 -0800
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
	initrd
In-Reply-To: <8a0c36780601131101x6a72d511oaf4f6782e9ca0a6b@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>	
	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>	
	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>	
	<43C7F99A.30705@nexpath.com>
	<8a0c36780601131101x6a72d511oaf4f6782e9ca0a6b@mail.gmail.com>
Message-ID: <43C809B6.40007@nexpath.com>

Not sure, I am not familiar with that.  But 2.4.32 comes in at around 
948K with ext2/3, isofs, dosfs, usb/ms, and about a dozen network card 
drivers.  Busybox with most programs enabled along with dialog, mke2fs 
and e2fsck spliced in as addons, is about 720K (uncompressed), and the 
whole thing with a few of our shell scripts is about 40K under the 1.44M 
limit.

Steve G.


Richard Smith wrote:

>On 1/13/06, Steve Gehlbach <steve at nexpath.com> wrote:
>
>  
>
>>If you could provide a roadmap on how to do this, or even better have a
>>chance to do it yourself for 2.4.27+ (2.4.32 would be great), that would
>>_really_ be useful.
>>
>>2.4 is a smaller kernel than 2.6, and for supporting legacy systems that
>>only boot from floppies, I regularly use it on a single boot floppy,
>>using uclibc and busybox, along with e2fs tools and also dialog, for
>>    
>>
>
>Is is smaller than a linux tiny kernel?
>
>--
>Richard A. Smith
>  
>




From smithbone at gmail.com  Fri Jan 13 21:16:27 2006
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 13 Jan 2006 14:16:27 -0600
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
	initrd
In-Reply-To: <43C809B6.40007@nexpath.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>
	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>
	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>
	<43C7F99A.30705@nexpath.com>
	<8a0c36780601131101x6a72d511oaf4f6782e9ca0a6b@mail.gmail.com>
	<43C809B6.40007@nexpath.com>
Message-ID: <8a0c36780601131216u4a4acb61i48d94ce80c0d74ef@mail.gmail.com>

On 1/13/06, Steve Gehlbach <steve at nexpath.com> wrote:

> Not sure, I am not familiar with that.  But 2.4.32 comes in at around
> 948K with ext2/3, isofs, dosfs, usb/ms, and about a dozen network card

Linux-tiny may be able to  beat that.  The number in the orginal paper
was a TCP/IP, ext2, PCI and 1 network card in 363k.

Give it a whirl and report back your results.

http://www.selenic.com/linux-tiny/

--
Richard A. Smith

From ebiederm at xmission.com  Fri Jan 13 21:35:30 2006
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 13 Jan 2006 13:35:30 -0700
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
 initrd
In-Reply-To: <43C7F99A.30705@nexpath.com> (Steve Gehlbach's message of "Fri,
	13 Jan 2006 11:03:54 -0800")
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>
	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>
	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>
	<43C7F99A.30705@nexpath.com>
Message-ID: <m1r77blvcd.fsf@ebiederm.dsl.xmission.com>

Steve Gehlbach <steve at nexpath.com> writes:

> If you could provide a roadmap on how to do this, or even better have a chance
> to do it yourself for 2.4.27+ (2.4.32 would be great), that would _really_ be
> useful.
>
> 2.4 is a smaller kernel than 2.6, and for supporting legacy systems that only
> boot from floppies, I regularly use it on a single boot floppy, using uclibc and
> busybox, along with e2fs tools and also dialog, for lots of support software we
> develop.  I guess we have a thing about getting it all on one floppy, but it
> would be helpful if we could jump into a 2.6 kernel on CD, for some situations.
> Legacy systems won't boot from CD in most cases.

I did some measurements in early 2.6.  Using the patches from the linux tiny
tree.  2.6 was comparable with 2.2 and noticeably smaller than  2.4.

Basically my conclusion is that 2.6 was only bigger because it had more
stuff in it by default and almost all of that stuff is configurable.

Eric



From yinghailu at gmail.com  Fri Jan 13 21:45:27 2006
From: yinghailu at gmail.com (yhlu)
Date: Fri, 13 Jan 2006 12:45:27 -0800
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
	initrd
In-Reply-To: <m1r77blvcd.fsf@ebiederm.dsl.xmission.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>
	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>
	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>
	<43C7F99A.30705@nexpath.com>
	<m1r77blvcd.fsf@ebiederm.dsl.xmission.com>
Message-ID: <2ea3fae10601131245v74f0297ci338cd23aee78fbcc@mail.gmail.com>

Eric,

are you sure the linux tiny will be in 2.6.16?

YH



From steve at nexpath.com  Fri Jan 13 22:29:14 2006
From: steve at nexpath.com (Steve Gehlbach)
Date: Fri, 13 Jan 2006 13:29:14 -0800
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
	initrd
In-Reply-To: <m1r77blvcd.fsf@ebiederm.dsl.xmission.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>	<43C7F99A.30705@nexpath.com>
	<m1r77blvcd.fsf@ebiederm.dsl.xmission.com>
Message-ID: <43C81BAA.8070600@nexpath.com>

Thanks for the info.  I will give it a try.  I actually had linux-tiny 
in my list of links to get to and read, and hadn't got there yet.  A few 
months ago I just took a straight forward approach of clicking the same 
things I had in 2.4 for 2.6, and it built out at about 1300K.  It was so 
far from 900K that I didn't look any further.  Things that I need that 
add a lot are for example usb mass storage and also ext3 but I am not 
sure how much that adds.

I might also mention that I have always left out module support, and 
linked in 5-10 most popular network drivers.  There seems to be no 
savings in space since you would need all the modules on the disk 
anyway.  Never had any problems in the drivers finding their card or 
conflicting.  The idea is that it can be used on a wide variety of 
hardware without configuration.  Maybe others have a better approach I 
am open for ideas.

Steve G.


Eric W. Biederman wrote:

>I did some measurements in early 2.6.  Using the patches from the linux tiny
>tree.  2.6 was comparable with 2.2 and noticeably smaller than  2.4.
>
>Basically my conclusion is that 2.6 was only bigger because it had more
>stuff in it by default and almost all of that stuff is configurable.
>
>Eric
>  
>




From ebiederm at xmission.com  Fri Jan 13 22:41:57 2006
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Fri, 13 Jan 2006 14:41:57 -0700
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
 initrd
In-Reply-To: <43C81BAA.8070600@nexpath.com> (Steve Gehlbach's message of
	"Fri, 13 Jan 2006 13:29:14 -0800")
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>
	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>
	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>
	<43C7F99A.30705@nexpath.com>
	<m1r77blvcd.fsf@ebiederm.dsl.xmission.com>
	<43C81BAA.8070600@nexpath.com>
Message-ID: <m1k6d3ls9m.fsf@ebiederm.dsl.xmission.com>

Steve Gehlbach <steve at nexpath.com> writes:

> Thanks for the info.  I will give it a try.  I actually had linux-tiny in my
> list of links to get to and read, and hadn't got there yet.  A few months ago I
> just took a straight forward approach of clicking the same things I had in 2.4
> for 2.6, and it built out at about 1300K.  It was so far from 900K that I didn't
> look any further.  Things that I need that add a lot are for example usb mass
> storage and also ext3 but I am not sure how much that adds.
>
> I might also mention that I have always left out module support, and linked in
> 5-10 most popular network drivers.  There seems to be no savings in space since
> you would need all the modules on the disk anyway.  Never had any problems in
> the drivers finding their card or conflicting.  The idea is that it can be used
> on a wide variety of hardware without configuration.  Maybe others have a better
> approach I am open for ideas.

The two interesting pieces for your style of configuration are:
1) The -Os work that has been going on recently, I think I have
   heard 10% reduction for that.
2) Careful selection of which compiler you are using as that makes
   a noticeable difference.
3) Look under CONFIG_EMBEDDED and possibly elsewhere for options
   you don't need and can turn off.  CONFIG_EMBEDDED also has some
   smaller alternatives for some of the common features.

You might also grab ext2 instead of ext3.  When clean either will
work.

Eric



From talbotx at comcast.net  Sat Jan 14 03:23:00 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Fri, 13 Jan 2006 18:23:00 -0800
Subject: [LinuxBIOS] Compile error
Message-ID: <43C86084.4080000@comcast.net>

Still trying to build Linux bios on my new board.  Have solved allot of 
compile errors, but this one had me stuck. "undefined reference to 
`northbridge_via_vt8605_6_ops`".  As best I can tell this is coming from 
c_start.s.  The only peace of code I have with that line in it is 
/root/LinuxBIOSv2-2158/src/northbridge/via/vt8605_6/chip.h.  
Here is my current tree.
http://www.batbuilds.com/webfolders/linuxbios/
Any ideas?
-Adam



linuxbios_ram.ld linuxbios_ram.o
linuxbios_ram.o: In function `write_tables':
: undefined reference to `write_pirq_routing_table'
linuxbios_ram.o: In function `_idt_end':
/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0x9b4): 
undefined reference to `northbridge_via_vt8605_6_ops'
/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0xc54): 
undefined reference to `northbridge_via_vt8605_6_ops'
/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0xef4): 
undefined reference to `northbridge_via_vt8605_6_ops'
/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0x11b4): 
undefined reference to `northbridge_via_vt8605_6_ops'
/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0x1454): 
undefined reference to `northbridge_via_vt8605_6_ops'
linuxbios_ram.o:/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0x16f4): 
more undefined references to `northbridge_via_vt8605_6_ops' follow
collect2: ld returned 1 exit status
make[1]: *** [linuxbios_ram] Error 1
make[1]: Leaving directory 
`/root/LinuxBIOSv2-2158/targets/bcm/ebc3610/ebc3610/normal'
make: *** [normal/linuxbios.rom] Error 1




From yinghai.lu at amd.com  Sat Jan 14 03:48:59 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Fri, 13 Jan 2006 18:48:59 -0800
Subject: [LinuxBIOS] Compile error
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949E3@ssvlexmb2.amd.com>

http://www.batbuilds.com/webfolders/linuxbios/src/northbridge/via/vt8605
_6/northbridge.c


struct chip_operations northbridge_via_vt8601_ops = {
	CHIP_NAME("VIA vt8601 Northbridge")
	.enable_dev = enable_dev, 
};

===>

struct chip_operations northbridge_via_vt8605_6_ops = {
	CHIP_NAME("VIA vt8605_6 Northbridge")
	.enable_dev = enable_dev, 
};


-----Original Message-----
From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Adam Talbot
Sent: Friday, January 13, 2006 6:23 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] Compile error

Still trying to build Linux bios on my new board.  Have solved allot of 
compile errors, but this one had me stuck. "undefined reference to 
`northbridge_via_vt8605_6_ops`".  As best I can tell this is coming from

c_start.s.  The only peace of code I have with that line in it is 
/root/LinuxBIOSv2-2158/src/northbridge/via/vt8605_6/chip.h.  
Here is my current tree.
http://www.batbuilds.com/webfolders/linuxbios/
Any ideas?
-Adam



linuxbios_ram.ld linuxbios_ram.o
linuxbios_ram.o: In function `write_tables':
: undefined reference to `write_pirq_routing_table'
linuxbios_ram.o: In function `_idt_end':
/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0x9b4): 
undefined reference to `northbridge_via_vt8605_6_ops'
/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0xc54): 
undefined reference to `northbridge_via_vt8605_6_ops'
/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0xef4): 
undefined reference to `northbridge_via_vt8605_6_ops'
/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0x11b4): 
undefined reference to `northbridge_via_vt8605_6_ops'
/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0x1454): 
undefined reference to `northbridge_via_vt8605_6_ops'
linuxbios_ram.o:/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.dat
a+0x16f4): 
more undefined references to `northbridge_via_vt8605_6_ops' follow
collect2: ld returned 1 exit status
make[1]: *** [linuxbios_ram] Error 1
make[1]: Leaving directory 
`/root/LinuxBIOSv2-2158/targets/bcm/ebc3610/ebc3610/normal'
make: *** [normal/linuxbios.rom] Error 1


-- 
linuxbios mailing list
linuxbios at linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios





From talbotx at comcast.net  Sat Jan 14 03:56:04 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Fri, 13 Jan 2006 18:56:04 -0800
Subject: [LinuxBIOS] Compile error
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A42030949E3@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949E3@ssvlexmb2.amd.com>
Message-ID: <43C86844.3040004@comcast.net>

Cool.  Thank you... 

Lu, Yinghai wrote:

>http://www.batbuilds.com/webfolders/linuxbios/src/northbridge/via/vt8605
>_6/northbridge.c
>
>
>struct chip_operations northbridge_via_vt8601_ops = {
>	CHIP_NAME("VIA vt8601 Northbridge")
>	.enable_dev = enable_dev, 
>};
>
>===>
>
>struct chip_operations northbridge_via_vt8605_6_ops = {
>	CHIP_NAME("VIA vt8605_6 Northbridge")
>	.enable_dev = enable_dev, 
>};
>
>
>-----Original Message-----
>From: linuxbios-bounces at linuxbios.org
>[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Adam Talbot
>Sent: Friday, January 13, 2006 6:23 PM
>To: linuxbios at openbios.org
>Subject: [LinuxBIOS] Compile error
>
>Still trying to build Linux bios on my new board.  Have solved allot of 
>compile errors, but this one had me stuck. "undefined reference to 
>`northbridge_via_vt8605_6_ops`".  As best I can tell this is coming from
>
>c_start.s.  The only peace of code I have with that line in it is 
>/root/LinuxBIOSv2-2158/src/northbridge/via/vt8605_6/chip.h.  
>Here is my current tree.
>http://www.batbuilds.com/webfolders/linuxbios/
>Any ideas?
>-Adam
>
>
>
>linuxbios_ram.ld linuxbios_ram.o
>linuxbios_ram.o: In function `write_tables':
>: undefined reference to `write_pirq_routing_table'
>linuxbios_ram.o: In function `_idt_end':
>/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0x9b4): 
>undefined reference to `northbridge_via_vt8605_6_ops'
>/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0xc54): 
>undefined reference to `northbridge_via_vt8605_6_ops'
>/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0xef4): 
>undefined reference to `northbridge_via_vt8605_6_ops'
>/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0x11b4): 
>undefined reference to `northbridge_via_vt8605_6_ops'
>/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.data+0x1454): 
>undefined reference to `northbridge_via_vt8605_6_ops'
>linuxbios_ram.o:/root/LinuxBIOSv2-2158/src/arch/i386/lib/c_start.S:(.dat
>a+0x16f4): 
>more undefined references to `northbridge_via_vt8605_6_ops' follow
>collect2: ld returned 1 exit status
>make[1]: *** [linuxbios_ram] Error 1
>make[1]: Leaving directory 
>`/root/LinuxBIOSv2-2158/targets/bcm/ebc3610/ebc3610/normal'
>make: *** [normal/linuxbios.rom] Error 1
>
>
>  
>




From steve at nexpath.com  Sat Jan 14 21:40:08 2006
From: steve at nexpath.com (steve)
Date: Sat, 14 Jan 2006 12:40:08 -0800
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
	initrd
In-Reply-To: <m1k6d3ls9m.fsf@ebiederm.dsl.xmission.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>	<43C7F99A.30705@nexpath.com>	<m1r77blvcd.fsf@ebiederm.dsl.xmission.com>	<43C81BAA.8070600@nexpath.com>
	<m1k6d3ls9m.fsf@ebiederm.dsl.xmission.com>
Message-ID: <43C961A8.8030805@nexpath.com>

Thanks hugely for the suggestions.  I need ext3 since this build is also 
used for rebuilding or fixing filesystems but you make a good point.

One of the errors that I made previously, and I appreciate everyone 
pointing out that 2.6 was not necessarily larger than 2.4, is that I did 
not carefully go down each tree in the menuconfig.  At the time I did 
not realize that 2.6 had so many options and buried menus.

I put in the linux-tiny patch for 2.6.14, and after working on the 
config for an hour or so, I got it down to 1020K with gcc-3.3.  Based on 
Eric's suggestions, I took the same config and put it on a system with 
gcc-4.0, put in the -Os option, and got a size of 814K!  This is with 
all I need in the kernel and the kexec option.  If you recall my limit 
is about 950K-960K so this is perfect.  I am assuming the kexec tools 
needs clib so I will have to splice this into busybox somehow but 
hopefully it won't add too much.

I haven't made sure it all works yet, but it is close enough to start 
debugging.  Thanks tremendously for all the help.

Steve G.

Eric W. Biederman wrote:

>
>The two interesting pieces for your style of configuration are:
>1) The -Os work that has been going on recently, I think I have
>   heard 10% reduction for that.
>2) Careful selection of which compiler you are using as that makes
>   a noticeable difference.
>3) Look under CONFIG_EMBEDDED and possibly elsewhere for options
>   you don't need and can turn off.  CONFIG_EMBEDDED also has some
>   smaller alternatives for some of the common features.
>
>You might also grab ext2 instead of ext3.  When clean either will
>work.
>
>Eric
>  
>




From smithbone at gmail.com  Sat Jan 14 23:47:08 2006
From: smithbone at gmail.com (Richard Smith)
Date: Sat, 14 Jan 2006 16:47:08 -0600
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
	initrd
In-Reply-To: <43C961A8.8030805@nexpath.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>
	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>
	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>
	<43C7F99A.30705@nexpath.com>
	<m1r77blvcd.fsf@ebiederm.dsl.xmission.com>
	<43C81BAA.8070600@nexpath.com>
	<m1k6d3ls9m.fsf@ebiederm.dsl.xmission.com>
	<43C961A8.8030805@nexpath.com>
Message-ID: <8a0c36780601141447y65619e1bm8a31d697ec4db007@mail.gmail.com>

> gcc-4.0, put in the -Os option, and got a size of 814K!  This is with
> all I need in the kernel and the kexec option.  If you recall my limit
> is about 950K-960K so this is perfect.  I am assuming the kexec tools
> needs clib so I will have to splice this into busybox somehow but
> hopefully it won't add too much.

If you want to try and go further then:

http://redhat.com/~mingo/debloating-patches/

They are for 2.6.16 though so you will need to go into developent
territory.  Ingo claims a extra  5% or 6% size reduction.  Its not
clear if this is with or irrespective of the tiny patches.

--
Richard A. Smith

From kratchkov at inbox.lv  Sun Jan 15 02:03:17 2006
From: kratchkov at inbox.lv (kratchkov)
Date: Sun, 15 Jan 2006 02:03:17 +0100
Subject: [LinuxBIOS] ALi M1489 & M1487 Chipset
Message-ID: <43C99F55.6010608@inbox.lv>

Hello everyone,

I found a strange board (get some pictures from
http://bram.dhis.org/pub/ror1000/) which has the following chips
on it:
- AMD AM486DX5-133 processor
- ALI M1487 and ALI M1489 chipsets
- BASIS Communications (ex-Cirrus Logic) CL-PD6729 PCMCIA controller
	with two PCMCIA slots
- AMD PCnet-FAST III network controller
- EPIC Ei-16C550 serial FIFO UART - with one serial connector

There is no keyboard plug, no graphiccard, no PCI, no ISA.

All these chips are supported by linux (to my knowledge, correct me if I'm wrong).

Further, there are 4MB RAM (two GM71V18163CJ6 with 1M-words each), and 512kB
FlashROM (Hy29F040AC-90; PLCC32 outline). The latter seems to be like a BIOS,
including the original firmware.

The board is from a ORiNOCO ROR-1000 wireless accesspoint, and works with the
original firmware, but there is not much I can do with, since I do not have a
pcmcia wireless card.

Trying to find a way to put linux on it, I stumbled on LinuxBIOS, and wondered
if it was possible to replace the firmware with it.

Is the ALi chipset supported? Are there any special problems which could be
encountered by using LinuxBIOS on such a small board?

Thanks in advance.

Greetings from switzerland,

Matthias



From ebiederm at xmission.com  Sun Jan 15 03:34:50 2006
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Sat, 14 Jan 2006 19:34:50 -0700
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
 initrd
In-Reply-To: <43C961A8.8030805@nexpath.com> (steve@nexpath.com's message of
	"Sat, 14 Jan 2006 12:40:08 -0800")
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>
	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>
	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>
	<43C7F99A.30705@nexpath.com>
	<m1r77blvcd.fsf@ebiederm.dsl.xmission.com>
	<43C81BAA.8070600@nexpath.com>
	<m1k6d3ls9m.fsf@ebiederm.dsl.xmission.com>
	<43C961A8.8030805@nexpath.com>
Message-ID: <m13bjqrzg5.fsf@ebiederm.dsl.xmission.com>

steve <steve at nexpath.com> writes:

> I put in the linux-tiny patch for 2.6.14, and after working on the config for an
> hour or so, I got it down to 1020K with gcc-3.3.  Based on Eric's suggestions, I
> took the same config and put it on a system with gcc-4.0, put in the -Os option,
> and got a size of 814K!  This is with all I need in the kernel and the kexec
> option.  If you recall my limit is about 950K-960K so this is perfect.  I am
> assuming the kexec tools needs clib so I will have to splice this into busybox
> somehow but hopefully it won't add too much.

It looks like Werner already has it working against uclibc.
/sbin/kexec is not especially demanding of libc.

Eric



From steve at nexpath.com  Sun Jan 15 19:53:35 2006
From: steve at nexpath.com (steve)
Date: Sun, 15 Jan 2006 10:53:35 -0800
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
	initrd
In-Reply-To: <m13bjqrzg5.fsf@ebiederm.dsl.xmission.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>	<43C7F99A.30705@nexpath.com>	<m1r77blvcd.fsf@ebiederm.dsl.xmission.com>	<43C81BAA.8070600@nexpath.com>	<m1k6d3ls9m.fsf@ebiederm.dsl.xmission.com>	<43C961A8.8030805@nexpath.com>
	<m13bjqrzg5.fsf@ebiederm.dsl.xmission.com>
Message-ID: <43CA9A2F.5040209@nexpath.com>

kexec compiles fine under uclibc tool chain with about 196K dynamic 
exec. That compresses to 61K so I think it will fit.

Steve G.

Eric W. Biederman wrote:

>steve <steve at nexpath.com> writes:
>
>  
>
>>I put in the linux-tiny patch for 2.6.14, and after working on the config for an
>>hour or so, I got it down to 1020K with gcc-3.3.  Based on Eric's suggestions, I
>>took the same config and put it on a system with gcc-4.0, put in the -Os option,
>>and got a size of 814K!  This is with all I need in the kernel and the kexec
>>option.  If you recall my limit is about 950K-960K so this is perfect.  I am
>>assuming the kexec tools needs clib so I will have to splice this into busybox
>>somehow but hopefully it won't add too much.
>>    
>>
>
>It looks like Werner already has it working against uclibc.
>/sbin/kexec is not especially demanding of libc.
>
>Eric
>  
>




From c-d.hailfinger.devel.2006 at gmx.net  Mon Jan 16 02:58:46 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 16 Jan 2006 02:58:46 +0100
Subject: [LinuxBIOS] LinuxBIOS support for nvidia CK804 northbridge?
Message-ID: <43CAFDD6.5070904@gmx.net>

Hi,

in the process of trying to find any motherboard with more than
3 PCI-Express slots and LinuxBIOS support, I failed miserably.
It seems such boards only exist with nVidia CK804 northbridges
for which I couldn't find any code in the LinuxBIOS source code.
Section 2.9 of the LinuxBIOS FAQ suggests to send lspci -vvv
to this list for closer inspection.

One of those systems with 4 PCIe slots is the Asus K8N-SLI Deluxe.
The lspci below contains four PCIe gigabit ethernet controllers
at 0000:01:00.0, 0000:02:00.0, 0000:03:00.0 and 0000:04:00.0.
It's the only motherboard with this northbridge I have access to
at the moment.

switch:~ # lspci -vvv
0000:00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
        Subsystem: ASUSTeK Computer Inc.: Unknown device 815a
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [44] #08 [01e0]
        Capabilities: [e0] #08 [a801]

0000:00:01.0 ISA bridge: nVidia Corporation: Unknown device 0050 (rev a3)
        Subsystem: ASUSTeK Computer Inc.: Unknown device 815a
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

0000:00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
        Subsystem: ASUSTeK Computer Inc.: Unknown device 815a
        Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at e400 [size=32]
        Region 4: I/O ports at 4c00 [size=64]
        Region 5: I/O ports at 4c40 [size=64]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI])
        Subsystem: ASUSTeK Computer Inc.: Unknown device 815a
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin A routed to IRQ 201
        Region 0: Memory at d3004000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI])
        Subsystem: ASUSTeK Computer Inc.: Unknown device 815a
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin B routed to IRQ 177
        Region 0: Memory at d3005000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [44] #0a [2098]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
        Subsystem: ASUSTeK Computer Inc.: Unknown device 812a
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (500ns min, 1250ns max)
        Interrupt: pin A routed to IRQ 10
        Region 0: I/O ports at dc00 [size=256]
        Region 1: I/O ports at e000 [size=256]
        Region 2: Memory at d3003000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2) (prog-if 8a [Master SecP PriP])
        Subsystem: ASUSTeK Computer Inc.: Unknown device 815a
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Region 4: I/O ports at f000 [size=16]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3) (prog-if 85 [Master SecO PriO])
        Subsystem: ASUSTeK Computer Inc.: Unknown device 815a
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin A routed to IRQ 177
        Region 0: I/O ports at 09f0 [size=8]
        Region 1: I/O ports at 0bf0 [size=4]
        Region 2: I/O ports at 0970 [size=8]
        Region 3: I/O ports at 0b70 [size=4]
        Region 4: I/O ports at d800 [size=16]
        Region 5: Memory at d3002000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3) (prog-if 85 [Master SecO PriO])
        Subsystem: ASUSTeK Computer Inc.: Unknown device 815a
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (750ns min, 250ns max)
        Interrupt: pin A routed to IRQ 185
        Region 0: I/O ports at 09e0 [size=8]
        Region 1: I/O ports at 0be0 [size=4]
        Region 2: I/O ports at 0960 [size=8]
        Region 3: I/O ports at 0b60 [size=4]
        Region 4: I/O ports at c400 [size=16]
        Region 5: Memory at d3001000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 01 [Subtractive decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=05, subordinate=05, sec-latency=128
        I/O behind bridge: 0000a000-0000afff
        Memory behind bridge: ce000000-d0ffffff
        Prefetchable memory behind bridge: c0000000-c7ffffff
        BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-

0000:00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
        Subsystem: ASUSTeK Computer Inc.: Unknown device 8141
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0 (250ns min, 5000ns max)
        Interrupt: pin A routed to IRQ 193
        Region 0: Memory at d3000000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at b000 [size=8]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, cache line size 08
        Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
        I/O behind bridge: 00009000-00009fff
        Memory behind bridge: cc000000-cdffffff
        Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
        BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [58] #08 [a800]
        Capabilities: [80] #10 [0141]

0000:00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, cache line size 08
        Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
        I/O behind bridge: 00008000-00008fff
        Memory behind bridge: ca000000-cbffffff
        Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
        BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [58] #08 [a800]
        Capabilities: [80] #10 [0141]

0000:00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, cache line size 08
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 00007000-00007fff
        Memory behind bridge: c8000000-c9ffffff
        Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
        BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [58] #08 [a800]
        Capabilities: [80] #10 [0141]

0000:00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, cache line size 08
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 00006000-00006fff
        Memory behind bridge: d1000000-d2ffffff
        Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
        BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [48] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [58] #08 [a800]
        Capabilities: [80] #10 [0141]

0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Capabilities: [80] #08 [2101]

0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

0000:01:00.0 Ethernet controller: SysKonnect SK-9Exx 10/100/1000Base-T Adapter (rev 10)
        Subsystem: SysKonnect SK-9E21D 10/100/1000Base-T Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR-
        Latency: 0, cache line size 08
        Interrupt: pin A routed to IRQ 233
        Region 0: Memory at d2000000 (64-bit, non-prefetchable) [size=16K]
        Region 2: I/O ports at 6000 [size=256]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data
        Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [e0] #10 [0011]

0000:02:00.0 Ethernet controller: SysKonnect SK-9Exx 10/100/1000Base-T Adapter (rev 10)
        Subsystem: SysKonnect SK-9E21D 10/100/1000Base-T Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR-
        Latency: 0, cache line size 08
        Interrupt: pin A routed to IRQ 225
        Region 0: Memory at c9000000 (64-bit, non-prefetchable) [size=16K]
        Region 2: I/O ports at 7000 [size=256]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data
        Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [e0] #10 [0011]

0000:03:00.0 Ethernet controller: SysKonnect SK-9Exx 10/100/1000Base-T Adapter (rev 10)
        Subsystem: SysKonnect SK-9E21D 10/100/1000Base-T Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR-
        Latency: 0, cache line size 08
        Interrupt: pin A routed to IRQ 217
        Region 0: Memory at cb000000 (64-bit, non-prefetchable) [size=16K]
        Region 2: I/O ports at 8000 [size=256]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data
        Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [e0] #10 [0011]

0000:04:00.0 Ethernet controller: SysKonnect SK-9Exx 10/100/1000Base-T Adapter (rev 10)
        Subsystem: SysKonnect SK-9E21D 10/100/1000Base-T Adapter
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR-
        Latency: 0, cache line size 08
        Interrupt: pin A routed to IRQ 209
        Region 0: Memory at cd000000 (64-bit, non-prefetchable) [size=16K]
        Region 2: I/O ports at 9000 [size=256]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data
        Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [e0] #10 [0011]

0000:05:06.0 VGA compatible controller: nVidia Corporation NV18 [GeForce4 MX 4000 AGP 8x] (rev c1) (prog-if 00 [VGA])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 12
        Region 0: Memory at ce000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at c0000000 (32-bit, prefetchable) [size=128M]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:05:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
        Subsystem: ASUSTeK Computer Inc.: Unknown device 808b
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (500ns min, 1000ns max), cache line size 08
        Interrupt: pin A routed to IRQ 12
        Region 0: Memory at d0008000 (32-bit, non-prefetchable) [size=2K]
        Region 1: Memory at d0000000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

0000:05:0c.0 Ethernet controller: Marvell Technology Group Ltd. Gigabit Ethernet Controller (rev 13)
        Subsystem: ASUSTeK Computer Inc. Marvell 88E8001 Gigabit Ethernet Controller (Asus)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (5750ns min, 7750ns max), cache line size 08
        Interrupt: pin A routed to IRQ 209
        Region 0: Memory at d0004000 (32-bit, non-prefetchable) [size=16K]
        Region 1: I/O ports at a000 [size=256]
        Capabilities: [48] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [50] Vital Product Data

The only references to something similar were a post archived at
http://www.mail-archive.com/linuxbios at openbios.org/msg00792.html
but the thread seemed to end inconclusive and another post at
http://www.mail-archive.com/linuxbios at openbios.org/msg01023.html

Is there any support for that nvidia northbridge underway?


Regards,
Carl-Daniel



From yinghailu at gmail.com  Mon Jan 16 03:32:55 2006
From: yinghailu at gmail.com (yhlu)
Date: Sun, 15 Jan 2006 18:32:55 -0800
Subject: [LinuxBIOS] LinuxBIOS support for nvidia CK804 northbridge?
In-Reply-To: <43CAFDD6.5070904@gmx.net>
References: <43CAFDD6.5070904@gmx.net>
Message-ID: <2ea3fae10601151832o6303a3fdh18d0439600c301a8@mail.gmail.com>

CK804 is a southbridge and the support is in src/southbridge/nvidia/ck804

Please refer to MB Tyan s2895 to create your MB support code.

YH



From c-d.hailfinger.devel.2006 at gmx.net  Mon Jan 16 12:47:53 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 16 Jan 2006 12:47:53 +0100
Subject: [LinuxBIOS] LinuxBIOS support for nvidia CK804 northbridge?
In-Reply-To: <2ea3fae10601151832o6303a3fdh18d0439600c301a8@mail.gmail.com>
References: <43CAFDD6.5070904@gmx.net>
	<2ea3fae10601151832o6303a3fdh18d0439600c301a8@mail.gmail.com>
Message-ID: <43CB87E9.7060502@gmx.net>

On 2006-01-16, yhlu wrote:
> CK804 is a southbridge and the support is in src/southbridge/nvidia/ck804

Ah thanks.

> Please refer to MB Tyan s2895 to create your MB support code.

So the Tyan s2865 (most similar to the board I have) has the same northbridge
and southbridge as the s2895? That's good.
I hope it will be easier for me to get the s2865 running than a mainboard
from a different vendor.

On 2005-08-17, yhlu wrote:
> You need to talk to Tyan to see if they want to release the source
> code for s2865 support.

Did there anything come out of these efforts?


Regards,
Carl-Daniel



From yinghailu at gmail.com  Mon Jan 16 21:11:22 2006
From: yinghailu at gmail.com (yhlu)
Date: Mon, 16 Jan 2006 12:11:22 -0800
Subject: [LinuxBIOS] LinuxBIOS support for nvidia CK804 northbridge?
In-Reply-To: <43CB87E9.7060502@gmx.net>
References: <43CAFDD6.5070904@gmx.net>
	<2ea3fae10601151832o6303a3fdh18d0439600c301a8@mail.gmail.com>
	<43CB87E9.7060502@gmx.net>
Message-ID: <2ea3fae10601161211k4dca21adm55df0cd85eaba8ff@mail.gmail.com>

what's your MB brand and model?

YH



From c-d.hailfinger.devel.2006 at gmx.net  Mon Jan 16 21:50:17 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Mon, 16 Jan 2006 21:50:17 +0100
Subject: [LinuxBIOS] LinuxBIOS support for nvidia CK804 northbridge?
In-Reply-To: <2ea3fae10601161211k4dca21adm55df0cd85eaba8ff@mail.gmail.com>
References: <43CAFDD6.5070904@gmx.net>	<2ea3fae10601151832o6303a3fdh18d0439600c301a8@mail.gmail.com>	<43CB87E9.7060502@gmx.net>
	<2ea3fae10601161211k4dca21adm55df0cd85eaba8ff@mail.gmail.com>
Message-ID: <43CC0709.7020500@gmx.net>

yhlu wrote:
> what's your MB brand and model?

It's an Asus A8N-SLI Deluxe.
Data (mostly guessed or searched on the web):
Northbridge: NVIDIA nForce4 SLI
Southbridge: NVIDIA CK804 (says lspci) / NVIDIA nForce4 SLI (says the doc)
Socket 939
Award 4Mb Flash EEPROM
Supports Athlon 64; Athlon 64 FX; Opteron 1xx for Socket 939

I hope you can find some more usable information at
http://www.asus.com/products4.aspx?l1=3&l2=15&l3=0&model=375&modelmenu=1
http://www.asus.com/products4.aspx?modelmenu=2&model=375&l1=3&l2=15&l3=0

The things making this motherboard attractive for me:
- 8 SATA ports
- 4 PCIe slots
- 4 MB Flash EEPROM (should be big enough for LinuxBIOS)
- 2 GBit LAN ports

The PCIe slots are most important because I plan to build some
routers with half a dozen gigabit interfaces each and using PCI
would severely limit performance.

Regards,
Carl-Daniel



From yinghailu at gmail.com  Mon Jan 16 22:16:50 2006
From: yinghailu at gmail.com (yhlu)
Date: Mon, 16 Jan 2006 13:16:50 -0800
Subject: [LinuxBIOS] LinuxBIOS support for nvidia CK804 northbridge?
In-Reply-To: <43CC0709.7020500@gmx.net>
References: <43CAFDD6.5070904@gmx.net>
	<2ea3fae10601151832o6303a3fdh18d0439600c301a8@mail.gmail.com>
	<43CB87E9.7060502@gmx.net>
	<2ea3fae10601161211k4dca21adm55df0cd85eaba8ff@mail.gmail.com>
	<43CC0709.7020500@gmx.net>
Message-ID: <2ea3fae10601161316y51c50b91p1b85ee902180abf4@mail.gmail.com>

I don't know what is the Superio in the MB...

the only problem maybe the memory man only support one dimm, (the
current K8 code in the tree)

Are you going to look at some opteron and ck804 based MB or Opteron
and Serverworks MB?

YH



From jerj at coplanar.net  Tue Jan 17 00:17:38 2006
From: jerj at coplanar.net (Jeremy Jackson)
Date: Mon, 16 Jan 2006 18:17:38 -0500
Subject: [LinuxBIOS] LinuxBIOS support for nvidia CK804 northbridge?
In-Reply-To: <43CB87E9.7060502@gmx.net>
References: <43CAFDD6.5070904@gmx.net>
	<2ea3fae10601151832o6303a3fdh18d0439600c301a8@mail.gmail.com>
	<43CB87E9.7060502@gmx.net>
Message-ID: <43CC2992.3090006@coplanar.net>

Carl-Daniel Hailfinger wrote:

>On 2005-08-17, yhlu wrote:
>  
>
>>You need to talk to Tyan to see if they want to release the source
>>code for s2865 support.
>>    
>>
>
>Did there anything come out of these efforts?
>  
>
There was some activity, but I didn't get an answer.  Perhaps I should 
send another email.

-- 
Jeremy Jackson
Coplanar Networks
W:(519)489-4903
MSN: jerj at coplanar.net
ICQ: 43937409
http://www.coplanar.net




From c-d.hailfinger.devel.2006 at gmx.net  Tue Jan 17 02:17:50 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 17 Jan 2006 02:17:50 +0100
Subject: [LinuxBIOS] LinuxBIOS support for nvidia CK804 northbridge?
In-Reply-To: <2ea3fae10601161316y51c50b91p1b85ee902180abf4@mail.gmail.com>
References: <43CAFDD6.5070904@gmx.net>	<2ea3fae10601151832o6303a3fdh18d0439600c301a8@mail.gmail.com>	<43CB87E9.7060502@gmx.net>	<2ea3fae10601161211k4dca21adm55df0cd85eaba8ff@mail.gmail.com>	<43CC0709.7020500@gmx.net>
	<2ea3fae10601161316y51c50b91p1b85ee902180abf4@mail.gmail.com>
Message-ID: <43CC45BE.7090409@gmx.net>

yhlu schrieb:
> I don't know what is the Superio in the MB...
> 
> the only problem maybe the memory man only support one dimm, (the
> current K8 code in the tree)

That wouldn't be such a big problem for me.

> Are you going to look at some opteron and ck804 based MB or Opteron
> and Serverworks MB?

Yes, opteron and ck804 based MBs are an option as long as they have
enough PCI-Express slots and don't cost a fortune. AFAIK Serverworks
based motherboards don't support PCIe.

However, right now I'm trying to find a reasonably cheap (as student
at an university I don't have too much money to spend) platform
for experiments which won't force me to re-do everything once I need
better performance or decide to establish a business in that area
after graduating. So spending ~300$ for a decent Athlon64/PCIe MB
combination is already at the upper end. Most Opteron MBs are above
300$ and then I still have to buy the processors.

Side note:
I think LinuxBIOS is very cool and will enable some really exciting
possibilities to use computers, faster booting being one of the
smaller aspects. Unfortunately the monetary entry barrier is quite
high right now for hobbyists. If we had 50$ MBs with support for
LinuxBIOS, there might be a lot more hackers able to contribute.
Of course contributing to LinuxBIOS needs a lot more skill than
for other projects, but some hackers will have that skill.

<dream>
The next time slashdot or some other site mentions LinuxBIOS,
people will be able to download image files for all modern MBs,
flash them and be proud like iPod owners.
Tuning freaks will notice that BIOS initialization can be done in
3 seconds instead of 30 and will want to use LinuxBIOS, too.
Instant-on will get a whole new meaning where people complain that
their cellphones boot slower than their desktops.
Suspend-to-{Disk,RAM} will work out of the box because the BIOS
does the right thing (tm).
Security-aware admins can be sure there are no more generic BIOS
passwords/backdoors.
Multiple vendors will start to ship boards with LinuxBIOS at the
same price as boards with proprietary BIOS.
High-end audio professionals will admire the fact that there are
no SMM traps killing their low latency requirements.
High-end storage servers will be able boot directly from Linux
RAID devices even if some of the disks have failed.
Some board manufacturers will switch completely to LinuxBIOS,
saving a load of money on proprietary BIOS.
</dream>


Regards,
Carl-Daniel



From joep at frog.nl  Tue Jan 17 15:59:54 2006
From: joep at frog.nl (Joep Jansen)
Date: Tue, 17 Jan 2006 15:59:54 +0100
Subject: [LinuxBIOS] VIA VT8605 support
Message-ID: <43CD066A.6020602@frog.nl>

I would like to port Linux BIOS to an embedded CPU board: the Kontron 
ETX-P3M.

The board has a 400 MHz Celeron CPU,  VIA VT8605  northbridge, and VIA 
VT82C686B southbridge.
I would like to know if anybody has some experience with LinuxBIOS and 
these or similar chips.
What  would be a good starting point? Is the vt8605 similar to the 
(supported) vt8601?

What about the vt82c686b?

Thanks,

Joep

On Wed, Jan 11, 2006 at 12:33:26PM -0800, Adam Talbot wrote:

>So I have my new embedded board.  It is running a chip set that is not 
>supported, yet.  I have all the doc's, that I think I will need.  I 
>would like to start trying to add support for the vt8605/vt8606 based 
>board(s). 
>





From rminnich at lanl.gov  Tue Jan 17 17:20:58 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 17 Jan 2006 09:20:58 -0700
Subject: [LinuxBIOS] I'm back
Message-ID: <43CD196A.8030108@lanl.gov>


I am going to start trying to catch up our svn info.

Will those of you have a mobo working, please send me:
the mobo name
the xvn revision

so I can fill out the table.

ron



From talbotx at comcast.net  Tue Jan 17 18:24:52 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Tue, 17 Jan 2006 09:24:52 -0800
Subject: [LinuxBIOS] VIA VT8605 support
In-Reply-To: <43CD066A.6020602@frog.nl>
References: <43CD066A.6020602@frog.nl>
Message-ID: <43CD2864.3060704@comcast.net>

-Joep
Yes, I have started work on vt8605.  The north bridge is close to the 
vt8601, but there are some differences.  I am currently setting up a new 
part of the tree for my board and chip sets. That part is done, I am 
just fixing compile errors currently.   The south bridge on the other 
hand is a whole different chip.  It is nothing like any other south 
bridge that is currently supported in the tree.  That will take some work.
If you would like I can send you a copy of my tree.
Our boards are close in nature, just a different CPU and NIC.
-Adam


Joep Jansen wrote:

> I would like to port Linux BIOS to an embedded CPU board: the Kontron 
> ETX-P3M.
>
> The board has a 400 MHz Celeron CPU,  VIA VT8605  northbridge, and VIA 
> VT82C686B southbridge.
> I would like to know if anybody has some experience with LinuxBIOS and 
> these or similar chips.
> What  would be a good starting point? Is the vt8605 similar to the 
> (supported) vt8601?
>
> What about the vt82c686b?
>
> Thanks,
>
> Joep
>
> On Wed, Jan 11, 2006 at 12:33:26PM -0800, Adam Talbot wrote:
>
>> So I have my new embedded board.  It is running a chip set that is 
>> not supported, yet.  I have all the doc's, that I think I will need.  
>> I would like to start trying to add support for the vt8605/vt8606 
>> based board(s).
>
>
>
>




From steve at nexpath.com  Tue Jan 17 19:40:25 2006
From: steve at nexpath.com (Steve Gehlbach)
Date: Tue, 17 Jan 2006 10:40:25 -0800
Subject: [LinuxBIOS] [Fastboot] Re: [Kboot-general] Re: small 64bit
	initrd
In-Reply-To: <8a0c36780601131216u4a4acb61i48d94ce80c0d74ef@mail.gmail.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A42030949DD@ssvlexmb2.amd.com>	
	<8a0c36780601120956g78df0e34qd8ef187d5df3653d@mail.gmail.com>	
	<m13bjtm1r9.fsf@ebiederm.dsl.xmission.com>	
	<43C7F99A.30705@nexpath.com>	
	<8a0c36780601131101x6a72d511oaf4f6782e9ca0a6b@mail.gmail.com>	
	<43C809B6.40007@nexpath.com>
	<8a0c36780601131216u4a4acb61i48d94ce80c0d74ef@mail.gmail.com>
Message-ID: <43CD3A19.9040808@nexpath.com>

Well, linux-tiny does do better, but so far it seems to have too many 
bugs in 2.6.14 for serious work.  Many config setting I tried give 
compile errors, which seem to be related to unenforced dependencies, and 
even when I can get it to compile I have never had it actually work, 
erroring out in the boot process with "bad gzip magic number".  But I 
have gotten unpatched 2.6.14 to work, with kexec, and successfully 
jumped into knoppix from a single floppy boot with all the tools I 
need.  Thanks for the help, right now the -Os compile switch gets me 
there, and I will keep monitoring linux-tiny for additional progress.

Steve G.


Richard Smith wrote:

>On 1/13/06, Steve Gehlbach <steve at nexpath.com> wrote:
>
>  
>
>>Not sure, I am not familiar with that.  But 2.4.32 comes in at around
>>948K with ext2/3, isofs, dosfs, usb/ms, and about a dozen network card
>>    
>>
>
>Linux-tiny may be able to  beat that.  The number in the orginal paper
>was a TCP/IP, ext2, PCI and 1 network card in 363k.
>
>Give it a whirl and report back your results.
>
>http://www.selenic.com/linux-tiny/
>
>--
>Richard A. Smith
>  
>




From c-d.hailfinger.devel.2006 at gmx.net  Tue Jan 17 20:36:36 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 17 Jan 2006 20:36:36 +0100
Subject: [LinuxBIOS] LinuxBIOS support for nvidia CK804 northbridge?
In-Reply-To: <2ea3fae10601161316y51c50b91p1b85ee902180abf4@mail.gmail.com>
References: <43CAFDD6.5070904@gmx.net>	<2ea3fae10601151832o6303a3fdh18d0439600c301a8@mail.gmail.com>	<43CB87E9.7060502@gmx.net>	<2ea3fae10601161211k4dca21adm55df0cd85eaba8ff@mail.gmail.com>	<43CC0709.7020500@gmx.net>
	<2ea3fae10601161316y51c50b91p1b85ee902180abf4@mail.gmail.com>
Message-ID: <43CD4744.5000300@gmx.net>

[sorry for the resend]

yhlu wrote:
> I don't know what is the Superio in the MB...

According to sensors-detect it's an "ITE 8712F Super IO Sensors".
This http://tinyurl.com/beaw8 photo seems to suggest an ITE 8712F-A.
Specs are at
http://www.ite.com.tw/product_info/PC/Brief-IT8712_2.asp

The BIOS chip is SST49LF004A/B (says flashrom). Looks like
a PLCC chip. I wonder whether I can replace this 4M chip
with an 8M chip to have more space for LinuxBIOS.


Regards,
Carl-Daniel




From rminnich at lanl.gov  Tue Jan 17 21:44:39 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 17 Jan 2006 13:44:39 -0700
Subject: [LinuxBIOS] failure to execute via/epia with rev 2158
Message-ID: <43CD5737.1080606@lanl.gov>


malloc Enter, size 668, free_mem_ptr 00018000
malloc 0x00018000
Capability: 0x07 @ 0x80
Capability: 0x08 @ 0x80
Capability: 0x10 @ 0x80
PCI: 00:01.0 [1106/8601] enabled
PCI: devfn 0x10, bad id 0xffffffff
PCI: devfn 0x18, bad id 0xffffffff
PCI: devfn 0x20, bad id 0xffffffff
PCI: devfn 0x28, bad id 0xffffffff
PCI: devfn 0x30, bad id 0xffffffff
PCI: devfn 0x38, bad id 0xffffffff
PCI: devfn 0x40, bad id 0xffffffff
PCI: devfn 0x48, bad id 0xffffffff
PCI: devfn 0x50, bad id 0xffffffff
PCI: devfn 0x58, bad id 0xffffffff
PCI: devfn 0x60, bad id 0xffffffff
PCI: devfn 0x68, bad id 0xffffffff
PCI: devfn 0x70, bad id 0xffffffff
PCI: devfn 0x78, bad id 0xffffffff
PCI: devfn 0x80, bad id 0xffffffff
PCI: 00:11.0 [1106/8231] bus ops
PCI: 00:11.0 [1106/8231] enabled
PCI: 00:11.1 [1106/0571] ops
PCI: 00:11.1 [1106/0571] enabled
PCI: 00:11.2 [1106/3038] disabled
PCI: 00:11.3 [1106/3038] disabled
PCI: 00:11.4 [1106/8235] ops
PCI: 00:11.4 [1106/8235] disabled
PCI: 00:11.5 [1106/3058] disabled
PCI: 00:11.6 [1106/3068] enabled
PCI: devfn 0x8f, bad id 0xffffffff
PCI: 00:12.0 [1106/3065] ops
PCI: 00:12.0 [1106/3065] enabled
PCI: devfn 0x98, bad id 0xffffffff
PCI: devfn 0xa0, bad id 0xffffffff
PCI: devfn 0xa8, bad id 0xffffffff
PCI: devfn 0xb0, bad id 0xffffffff
PCI: devfn 0xb8, bad id 0xffffffff
PCI: devfn 0xc0, bad id 0xffffffff
PCI: devfn 0xc8, bad id 0xffffffff
PCI: devfn 0xd0, bad id 0xffffffff
PCI: devfn 0xd8, bad id 0xffffffff
PCI: devfn 0xe0, bad id 0xffffffff
PCI: devfn 0xe8, bad id 0xffffffff
PCI: devfn 0xf0, bad id 0xffffffff
PCI: devfn 0xf8, bad id 0xffffffff
PCI: 00:00.1
PCI: Left over static devices.  Check your Config.lb

This is probably failing due to the check, which IIRC is new.
But I'm not sure, anyone else seeing this?

ron



From yinghai.lu at amd.com  Tue Jan 17 22:04:09 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Tue, 17 Jan 2006 13:04:09 -0800
Subject: [LinuxBIOS] failure to execute via/epia with rev 2158
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949E6@ssvlexmb2.amd.com>

You may need to remove the 
Device pci 0.1 on end # AGP bridge

YH




From rminnich at lanl.gov  Tue Jan 17 22:45:43 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 17 Jan 2006 14:45:43 -0700
Subject: [LinuxBIOS] via/epia
Message-ID: <43CD6587.5030804@lanl.gov>

OK, I had to remove the AGP entry from Config.lb (*why*)

Now, at some point, part way through, the baud rate pops to 115200 from 
19200. Any guesses here? Somebody mess with baud rate and not tell us?

Finally, IDE no longer works.

ron



From rminnich at lanl.gov  Tue Jan 17 23:02:32 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 17 Jan 2006 15:02:32 -0700
Subject: [LinuxBIOS] setting up COM1: a subtle point
Message-ID: <43CD6978.6060809@lanl.gov>


I see that (*probably my fault*?) there was a
				register "com1" = "{1}"

in the Config.lb for via/epia. This is actually a bad idea, since you 
can't control the baud rate. What you want to do is this:
				register "com1" = "{TTYS0_BAUD}"

ron



From rminnich at lanl.gov  Wed Jan 18 17:15:50 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 18 Jan 2006 09:15:50 -0700
Subject: [LinuxBIOS] confirmed: via epia IDE now broken
Message-ID: <43CE69B6.7090409@lanl.gov>

somewhere, somebody busted something somehow.

anybody wanna guess?

boot: hda1:/vmlinuz-normal initrd=hda1:/initrd-normal.gz  root=/dev/ram0 
consol0
ide_probe: ide_probe: drive 0
ide_probe: ide_probe: base 0x0xnide_bus_floating: reg 0x1f7 status 0x50
ide_software_reset: Waiting for ide0 to become ready for reset... ok
IDE time out
No drive detected on IDE channel 0

That base 0x0 look suspicious to me.

I'm looking at this now. Except for this problem, epia is working ok, 
though I have not (re) tested vga yet.

I see a LOT of issue tracker stuff from yhlu (12 items!) in chatting or 
testing. Can we get these cleaned up  please?

Also, what's the state of jason schildt's issue 30, 'testing'?

APIC cluster auto-probing? Stepan?

There are almost 20 items 1 month old!

Please, folks, let's get this stuff put to bed.

There's more work to be done, and this kind of old issue just drags us down.

thanks

ron



From smithbone at gmail.com  Wed Jan 18 18:59:54 2006
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 18 Jan 2006 11:59:54 -0600
Subject: [LinuxBIOS] confirmed: via epia IDE now broken
In-Reply-To: <43CE69B6.7090409@lanl.gov>
References: <43CE69B6.7090409@lanl.gov>
Message-ID: <8a0c36780601180959h158e2faamc1abdd15fb48f2fd@mail.gmail.com>

On 1/18/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> somewhere, somebody busted something somehow.
>
> anybody wanna guess?
>
> boot: hda1:/vmlinuz-normal initrd=hda1:/initrd-normal.gz  root=/dev/ram0
> consol0
> ide_probe: ide_probe: drive 0
> ide_probe: ide_probe: base 0x0xnide_bus_floating: reg 0x1f7 status 0x50
> ide_software_reset: Waiting for ide0 to become ready for reset... ok
> IDE time out
> No drive detected on IDE channel 0

Search the archives.. I think this has come up before.  I remember
someone haveing trouble with thier base address ending up as zero but
I don't remember if it was epia.

--
Richard A. Smith

From rminnich at lanl.gov  Wed Jan 18 20:19:53 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 18 Jan 2006 12:19:53 -0700
Subject: [LinuxBIOS] confirmed: via epia IDE now broken
In-Reply-To: <8a0c36780601180959h158e2faamc1abdd15fb48f2fd@mail.gmail.com>
References: <43CE69B6.7090409@lanl.gov>
	<8a0c36780601180959h158e2faamc1abdd15fb48f2fd@mail.gmail.com>
Message-ID: <43CE94D9.8020202@lanl.gov>

Richard Smith wrote:
> On 1/18/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> 
>>somewhere, somebody busted something somehow.
>>
>>anybody wanna guess?
>>
>>boot: hda1:/vmlinuz-normal initrd=hda1:/initrd-normal.gz  root=/dev/ram0
>>consol0
>>ide_probe: ide_probe: drive 0
>>ide_probe: ide_probe: base 0x0xnide_bus_floating: reg 0x1f7 status 0x50
>>ide_software_reset: Waiting for ide0 to become ready for reset... ok
>>IDE time out
>>No drive detected on IDE channel 0
> 
> 
> Search the archives.. I think this has come up before.  I remember
> someone haveing trouble with thier base address ending up as zero but
> I don't remember if it was epia.
> 
> --
> Richard A. Smith

it may actually be ok. I am trying a tiny linux now for fun, filo is a 
little limiting.

ron



From rminnich at lanl.gov  Wed Jan 18 21:22:43 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 18 Jan 2006 13:22:43 -0700
Subject: [LinuxBIOS] trying to load a linux-tiny kernel on epia
Message-ID: <43CEA393.3060209@lanl.gov>

I build a linux-tiny with serial console and do this:

  mkelfImage --command-line="console=ttyS0,19200 " 
arch/i386/boot/bzImage /tmp/linux.elf



Build the image, boot, get this:


     33:stream_init() - rom_stream: 0xfff80000 - 0xfffeffff
Found ELF candiate at offset 0
header_offset is 0
Try to load at offset 0x0
n_type: 00000001 n_name(8): ELFBoot  n_desc(6): Linux
n_type: 00000002 n_name(8): ELFBoot  n_desc(76): 2.6.9-tiny1tiny 
(rminnich at q.cc6
malloc Enter, size 20, free_mem_ptr 0001829c
malloc 0x0001829c
n_type: 00000003 n_name(8): ELFBoot  n_desc(2): h.
Dropping non PT_LOAD segment
malloc Enter, size 32, free_mem_ptr 000182b0
malloc 0x000182b0
New segment addr 0x10000 size 0x121c4 offset 0x148 filesize 0x116c
(cleaned up) New segment addr 0x10000 size 0x121c4 offset 0x148 filesize 
0x116c
lb: [0x0000000000004000, 0x000000000001c000)
segment: [0x0000000000010000, 0x000000000001116c, 0x00000000000221c4)
malloc Enter, size 32, free_mem_ptr 000182d0
malloc 0x000182d0
    late: [0x000000000001c000, 0x000000000001c000, 0x00000000000221c4)
  bounce: [0x000000000ffdc000, 0x000000000ffdd16c, 0x000000000ffe8000)
malloc Enter, size 32, free_mem_ptr 000182f0
malloc 0x000182f0
New segment addr 0x91000 size 0x70 offset 0x12b4 filesize 0x0
(cleaned up) New segment addr 0x91000 size 0x70 offset 0x12b4 filesize 0x0
lb: [0x0000000000004000, 0x000000000001c000)
malloc Enter, size 32, free_mem_ptr 00018310
malloc 0x00018310
New segment addr 0x100000 size 0x700000 offset 0x12b4 filesize 0x618bc
(cleaned up) New segment addr 0x100000 size 0x700000 offset 0x12b4 
filesize 0x6c
lb: [0x0000000000004000, 0x000000000001c000)
Loading Segment: addr: 0x000000000ffdc000 memsz: 0x000000000000c000 
filesz: 0x0c
[ 0x000000000ffdc000, 000000000ffdd16c, 0x000000000ffe8000) <- 
0000000000000148
Clearing Segment: addr: 0x000000000ffdd16c memsz: 0x000000000000ae94
Loading Segment: addr: 0x0000000000091000 memsz: 0x0000000000000070 
filesz: 0x00
[ 0x0000000000091000, 0000000000091000, 0x0000000000091070) <- 
00000000000012b4
Clearing Segment: addr: 0x0000000000091000 memsz: 0x0000000000000070
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000700000 
filesz: 0x0c
[ 0x0000000000100000, 00000000001618bc, 0x0000000000800000) <- 
00000000000012b4
Clearing Segment: addr: 0x00000000001618bc memsz: 0x000000000069e744
Loading Segment: addr: 0x000000000001c000 memsz: 0x00000000000061c4 
filesz: 0x00
[ 0x000000000001c000, 000000000001c000, 0x00000000000221c4) <- 
0000000000062b70
Clearing Segment: addr: 0x000000000001c000 memsz: 0x00000000000061c4
Loaded segments
verified segments
closed down stream
Jumping to boot code at 0x10000
entry    = 0x00010000
lb_start = 0x00004000
lb_size  = 0x00018000
adjust   = 0x0ffe4000
buffer   = 0x0ffd0000
      elf_boot_notes = 0x00011aa0
adjusted_boot_notes = 0x0fff5aa0
Firmware type: LinuxBIOS

and that's it. Seems all the segments load, but then ... no dice.

EARLY_PRINTK is enabled.

OK, anyone beat me to doing this? What have you seen?

thanks

ron



From a.mimms at f5.com  Wed Jan 18 21:59:06 2006
From: a.mimms at f5.com (Alan Mimms)
Date: Wed, 18 Jan 2006 12:59:06 -0800
Subject: [LinuxBIOS] Serverworks HT1000/HT2000?
Message-ID: <7D7AEA925A7F724194B1521C75E622DC0172D163@exchfive.olympus.f5net.com>

I noticed a bunch of motherboard vendors are starting to ship with
products based on Serverworks (Broadcom) HT1000 and HT2000 chips.  Does
anyone have a project in progress to support these chips in LinuxBIOS at
this point?  If not, is the reason due to some limitation Serverworks
has on its support in GPLed BIOS code?  What about the following
generation of parts from Serverworks?


Thanks.

 

Alan Mimms, Senior Architect
F5 Networks, Inc.  Spokane Development Center
1322 North Whitman Lane
Liberty Lake, Washington   99019

v: 509-343-3524   f: 509-343-3501

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060118/bfbad4af/attachment.html>

From yinghai.lu at amd.com  Wed Jan 18 23:43:04 2006
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 18 Jan 2006 14:43:04 -0800
Subject: [LinuxBIOS] Serverworks HT1000/HT2000?
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A42030949EE@ssvlexmb2.amd.com>

I have finished the porting last year. And we are working on paper work
with broadcom. 

 

I guess the code could to be released to public tree next a few days.

 

YH

 

________________________________

From: linuxbios-bounces at linuxbios.org
[mailto:linuxbios-bounces at linuxbios.org] On Behalf Of Alan Mimms
Sent: Wednesday, January 18, 2006 12:59 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] Serverworks HT1000/HT2000?

 

I noticed a bunch of motherboard vendors are starting to ship with
products based on Serverworks (Broadcom) HT1000 and HT2000 chips.  Does
anyone have a project in progress to support these chips in LinuxBIOS at
this point?  If not, is the reason due to some limitation Serverworks
has on its support in GPLed BIOS code?  What about the following
generation of parts from Serverworks?


Thanks.

 

Alan Mimms, Senior Architect
F5 Networks, Inc.  Spokane Development Center
1322 North Whitman Lane
Liberty Lake, Washington   99019

v: 509-343-3524   f: 509-343-3501

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060118/35c80abc/attachment.html>

From rminnich at lanl.gov  Thu Jan 19 05:20:50 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 18 Jan 2006 21:20:50 -0700
Subject: [LinuxBIOS] changing how ldscript is made
Message-ID: <43CF13A2.90005@lanl.gov>

currently, the default makefile generates this for ldscript.ld
[rminnich at q fallback]$ more ../normal/ldscript.ld
INCLUDE ldoptions
INCLUDE /home/rminnich/src/LinuxBIOSv2/src/arch/i386/init/ldscript.lb
INCLUDE /home/rminnich/src/LinuxBIOSv2/src//cpu/x86/16bit/entry16.lds
INCLUDE /home/rminnich/src/LinuxBIOSv2/src//cpu/x86/32bit/entry32.lds
INCLUDE /home/rminnich/src/LinuxBIOSv2/src//cpu/x86/32bit/reset32.lds
INCLUDE /home/rminnich/src/LinuxBIOSv2/src//arch/i386/lib/id.lds


I find this intensely annoying, and there is no reason for it. I can 
just as easily have the makefile do the include via 'cat', and then you 
can see what the ldscript actually looks like. All the dependencies 
still work fine as well. I just tested this here.

Any objection if I change the makefile so that you get something like this:

HAVE_MOVNTI = 0;
CONFIG_USE_INIT = 0;
HAVE_FALLBACK_BOOT = 1;
ROM_IMAGE_SIZE = 0x10000;
PAYLOAD_SIZE = 0x10000;
_ROMBASE = 0xffff0000;
_RESET = 0xffff0000;

.
.
.
TARGET(binary)
INPUT(linuxbios_ram.rom)
SECTIONS
{

.
.
.
SECTIONS {
         . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
         .id (.): {
                 *(.id)
          }
}


so you can actually see the script?

If not, I'll put this in the issue tracker.

ron



From yinghailu at gmail.com  Thu Jan 19 06:54:55 2006
From: yinghailu at gmail.com (yhlu)
Date: Wed, 18 Jan 2006 21:54:55 -0800
Subject: [LinuxBIOS] changing how ldscript is made
In-Reply-To: <43CF13A2.90005@lanl.gov>
References: <43CF13A2.90005@lanl.gov>
Message-ID: <2ea3fae10601182154k3d4c1fd7k720143379219dbaa@mail.gmail.com>

i'm ok, but please add

/* from src/arch/i386/lib/id.lds */

for each including.

YH

On 1/18/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> currently, the default makefile generates this for ldscript.ld
> [rminnich at q fallback]$ more ../normal/ldscript.ld
> INCLUDE ldoptions
> INCLUDE /home/rminnich/src/LinuxBIOSv2/src/arch/i386/init/ldscript.lb
> INCLUDE /home/rminnich/src/LinuxBIOSv2/src//cpu/x86/16bit/entry16.lds
> INCLUDE /home/rminnich/src/LinuxBIOSv2/src//cpu/x86/32bit/entry32.lds
> INCLUDE /home/rminnich/src/LinuxBIOSv2/src//cpu/x86/32bit/reset32.lds
> INCLUDE /home/rminnich/src/LinuxBIOSv2/src//arch/i386/lib/id.lds
>
>
> I find this intensely annoying, and there is no reason for it. I can
> just as easily have the makefile do the include via 'cat', and then you
> can see what the ldscript actually looks like. All the dependencies
> still work fine as well. I just tested this here.
>
> Any objection if I change the makefile so that you get something like this:
>
> HAVE_MOVNTI = 0;
> CONFIG_USE_INIT = 0;
> HAVE_FALLBACK_BOOT = 1;
> ROM_IMAGE_SIZE = 0x10000;
> PAYLOAD_SIZE = 0x10000;
> _ROMBASE = 0xffff0000;
> _RESET = 0xffff0000;
>
> .
> .
> .
> TARGET(binary)
> INPUT(linuxbios_ram.rom)
> SECTIONS
> {
>
> .
> .
> .
> SECTIONS {
>          . = (_ROMBASE + ROM_IMAGE_SIZE - 0x10) - (__id_end - __id_start);
>          .id (.): {
>                  *(.id)
>           }
> }
>
>
> so you can actually see the script?
>
> If not, I'll put this in the issue tracker.
>
> ron
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From rminnich at lanl.gov  Thu Jan 19 19:04:22 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 19 Jan 2006 11:04:22 -0700
Subject: [LinuxBIOS] via epia status
Message-ID: <43CFD4A6.0@lanl.gov>

ok, I have a filo that is working, and linux is up ...


with cache off


and, apparently, no enet interrupts (or interrupts of any kind? not sure 
yet)

ron



From okajima at digitalinfra.co.jp  Thu Jan 19 19:36:38 2006
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Fri, 20 Jan 2006 03:36:38 +0900
Subject: [LinuxBIOS] via epia status
In-Reply-To: <43CFD4A6.0@lanl.gov>
References: <43CFD4A6.0@lanl.gov>
Message-ID: <200601191836.AA00654@bbb-jz5c7z9hn9y.digitalinfra.co.jp>


And, VGA is working?
And, the boot speed is fast?

          --- Okajima, Jun. Tokyo, Japan.



>ok, I have a filo that is working, and linux is up ...
>
>
>with cache off
>
>
>and, apparently, no enet interrupts (or interrupts of any kind? not sure 
>yet)
>
>



From rminnich at lanl.gov  Thu Jan 19 21:02:03 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 19 Jan 2006 13:02:03 -0700
Subject: [LinuxBIOS] via epia status
In-Reply-To: <200601191836.AA00654@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <43CFD4A6.0@lanl.gov>
	<200601191836.AA00654@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <43CFF03B.7030906@lanl.gov>

Jun OKAJIMA wrote:
> And, VGA is working?
> And, the boot speed is fast?
> 
>           --- Okajima, Jun. Tokyo, Japan.
> 


what has happened is that people put changes in and did not test them. 
Also there are a few poorly designed bits that came in (uart8250) that I 
have had to work with. The cache is not back yet, due to some problem I 
don't yet understand. Other changes for the -m and -mII broke other 
stuff. Ethernet is not back yet-- I'm still working that one.

We'll get there, but it's been a bit of work.

ron



From rminnich at lanl.gov  Thu Jan 19 22:42:33 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 19 Jan 2006 14:42:33 -0700
Subject: [LinuxBIOS] via epia
Message-ID: <43D007C9.3040603@lanl.gov>

ethernet not working.

So, here is what I see: I can send packets. I can get interrupts on 
recieve packets. What I don't get is the packets into the nic itself. 
The packets on send are received, and responded to, by a dhcp server.

this sounds like phy to me. any ideas?

This is the bad output:
Using /lib/modules/2.6.14-i386/kernel/drivers/net/via-rhine.ko
via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker
PCI: Found IRQ 11 for device 0000:00:12.0
eth0: VIA Rhine II at 0xfec00000, 00:40:63:d3:4f:61, IRQ 11.
eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.


This is the good:

Using 
/lib/modules/2.6.14-i386/kernel/drivers/netvia-rhine.c:v1.10-LK1.2.0-2.6 
June-10-2004 Written by Donald Becker
PCI: Found IRQ 11 for device 0000:00:12.0

eth0: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.


ron



From smithbone at gmail.com  Thu Jan 19 22:58:50 2006
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 19 Jan 2006 15:58:50 -0600
Subject: [LinuxBIOS] via epia
In-Reply-To: <43D007C9.3040603@lanl.gov>
References: <43D007C9.3040603@lanl.gov>
Message-ID: <8a0c36780601191358w55c12445l1f9683b22335b4e5@mail.gmail.com>

>
> So, here is what I see: I can send packets. I can get interrupts on
> recieve packets. What I don't get is the packets into the nic itself.

Are you _really_ sure you get interrupts on receive?  I had a similar
problem when the PCI INT routing was not correct.

--
Richard A. Smith

From rminnich at lanl.gov  Thu Jan 19 22:58:28 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 19 Jan 2006 14:58:28 -0700
Subject: [LinuxBIOS] via epia
In-Reply-To: <8a0c36780601191358w55c12445l1f9683b22335b4e5@mail.gmail.com>
References: <43D007C9.3040603@lanl.gov>
	<8a0c36780601191358w55c12445l1f9683b22335b4e5@mail.gmail.com>
Message-ID: <43D00B84.8020005@lanl.gov>

Richard Smith wrote:
>>So, here is what I see: I can send packets. I can get interrupts on
>>recieve packets. What I don't get is the packets into the nic itself.
> 
> 
> Are you _really_ sure you get interrupts on receive?  I had a similar
> problem when the PCI INT routing was not correct.
> 


I am really sure I am not getting that interrupt. Her'es the weird part:

/ # cat /proc/interrupts
            CPU0
   0:     790617          XT-PIC  timer
   2:          0          XT-PIC  cascade
   4:       4592          XT-PIC  serial
  11:      11599          XT-PIC  eth0
  14:        175          XT-PIC  ide0
NMI:          0
LOC:          0
ERR:          0
MIS:          0


lotsa interrupts (apparently) on 11.

this is weird.

ron



From rminnich at lanl.gov  Thu Jan 19 23:04:00 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 19 Jan 2006 15:04:00 -0700
Subject: [LinuxBIOS] via epia
In-Reply-To: <8a0c36780601191358w55c12445l1f9683b22335b4e5@mail.gmail.com>
References: <43D007C9.3040603@lanl.gov>
	<8a0c36780601191358w55c12445l1f9683b22335b4e5@mail.gmail.com>
Message-ID: <43D00CD0.10906@lanl.gov>

Richard Smith wrote:
>>So, here is what I see: I can send packets. I can get interrupts on
>>recieve packets. What I don't get is the packets into the nic itself.
> 
> 
> Are you _really_ sure you get interrupts on receive?  I had a similar
> problem when the PCI INT routing was not correct.


oh, I forgot: why I might be getting ints.

The reject packet count on eth0 is through the roof. For ever packet 
sent to it, it increments the reject count.

This sounds like badly setup enet hardware to me.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Thu Jan 19 23:01:16 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 19 Jan 2006 23:01:16 +0100
Subject: [LinuxBIOS] 16 MBit BIOS chips
Message-ID: <43D00C2C.3010407@gmx.net>

Hi,

I just saw the ST M50FW016 (a 16 Mbit FWH BIOS chip) and
wanted to use it for LinuxBIOS development.

However, it is only (public) available in a TSOP40 package,
while most mainboard BIOS chips have a PLCC32 package.
Looking at the data sheet, it seems it should be reasonably
easy to build a PLCC32/TSOP40 adaptor with a TSOP40 ZIF
socket. Another chance would be to find somebody who orders
a large enough quantity of the PLCC32 version (that is
available only "on demand").

Has somebody tried or is planning to build such an adaptor?

Advantages:
* With a ZIF socket, you can't break anything
* It would remove the need for the BIOS savior
* 16 MBit is HUGE

So... anybody interested?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From rminnich at lanl.gov  Thu Jan 19 23:53:44 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 19 Jan 2006 15:53:44 -0700
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
In-Reply-To: <20060103233832.GA8073@io.pong.be>
References: <20051216043022.GA18934@io.pong.be>
	<20060103233832.GA8073@io.pong.be>
Message-ID: <43D01878.1030105@lanl.gov>

ward, did you ever get the system up or not?

ron



From ward at gnu.org  Fri Jan 20 00:01:11 2006
From: ward at gnu.org (Ward Vandewege)
Date: Thu, 19 Jan 2006 18:01:11 -0500
Subject: [LinuxBIOS] tyan s2881 - partial success (update)
In-Reply-To: <43D01878.1030105@lanl.gov>
References: <20051216043022.GA18934@io.pong.be>
	<20060103233832.GA8073@io.pong.be> <43D01878.1030105@lanl.gov>
Message-ID: <20060119230110.GA29562@io.pong.be>

On Thu, Jan 19, 2006 at 03:53:44PM -0700, Ronald G Minnich wrote:
> ward, did you ever get the system up or not?

No, still the same issue. Do you have ideas on how to proceed?

I have been writing some documentation about the process though, which I will
put in the linuxbios wiki once it is done.

Thanks,
Ward.

--
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior System Administrator



From rminnich at lanl.gov  Thu Jan 19 23:58:24 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 19 Jan 2006 15:58:24 -0700
Subject: [LinuxBIOS] via/epia -- I'm out of time
Message-ID: <43D01990.8000603@lanl.gov>

I've just run out of time to screw with this. Somehow, the sum total of 
changes people made have broken it. I hope someone can take a look at it 
in its current state.

ron



From rminnich at lanl.gov  Fri Jan 20 00:07:33 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 19 Jan 2006 16:07:33 -0700
Subject: [LinuxBIOS] one last note
Message-ID: <43D01BB5.40804@lanl.gov>

if anyone out there has a copy of a version of the  v2 repo that can 
build a working via epia, hopefully recent, I'm willing to work with that.

Current problem, btw, is that the via epia samuel 2 cpu hangs up in the 
mtrr init code. I suspect someone updated that, for -m or -m2,  in such 
a way that it broke older cpus.

if I comment out mtrr init, i.e.


Index: src/cpu/via/model_centaur/model_centaur_init.c
===================================================================
--- src/cpu/via/model_centaur/model_centaur_init.c      (revision 2158)
+++ src/cpu/via/model_centaur/model_centaur_init.c      (working copy)
@@ -15,7 +15,7 @@
  {
         /* Turn on caching if we haven't already */
         x86_enable_cache();
-       x86_setup_mtrrs(36);
+//     x86_setup_mtrrs(36);
         x86_mtrr_check();

         /* Enable the local cpu apics */

then it will come up -- with no working cache. And the enet problem then 
occurs.

I could use some help and perspetive here. I know some of you have epias 
-- could you take a look?

But I have other, newer things to do, and fixing an old CPU just can not 
take priority. Sorry.

ron



From kratchkov at inbox.lv  Sun Jan 22 14:55:41 2006
From: kratchkov at inbox.lv (kratchkov)
Date: Sun, 22 Jan 2006 14:55:41 +0100
Subject: [LinuxBIOS] ALi M1487/M1489
Message-ID: <43D38EDD.7@inbox.lv>

Hello everybody

I have a board with a ALi M1487 and M1489 chipset.

Is this chipset supported by LinuxBIOS?

Greetings,

Matthias



From talbotx at comcast.net  Mon Jan 23 04:52:05 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Sun, 22 Jan 2006 19:52:05 -0800
Subject: [LinuxBIOS] Easy compile error
Message-ID: <43D452E5.4030301@comcast.net>

Humm, So I have the irq_table.c in src/mainboard/bcm/ebc3610 am I 
missing something, some where else? Where should I look.
-Adam Talbot


linuxbios_ram.o: In function `write_tables':
: undefined reference to `write_pirq_routing_table'
collect2: ld returned 1 exit status
make[1]: *** [linuxbios_ram] Error 1
make[1]: Leaving directory 
`/home/adam/LinuxBIOSv2-2158/targets/bcm/ebc3610/ebc3610/normal'
make: *** [normal/linuxbios.rom] Error 1




From talbotx at comcast.net  Mon Jan 23 04:57:32 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Sun, 22 Jan 2006 19:57:32 -0800
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D01BB5.40804@lanl.gov>
References: <43D01BB5.40804@lanl.gov>
Message-ID: <43D4542C.1030308@comcast.net>

-Ron
LinuxBIOSv2-2158 can compile the epia, but I do not know it it boots, 
have no such board to test on. If this helps any, here is my tree. The 
epia-m does not compile.
http://www.batbuilds.com/webfolders/LinuxBIOSv2-2158.tar.bz2
-Adam


Ronald G Minnich wrote:

>if anyone out there has a copy of a version of the  v2 repo that can 
>build a working via epia, hopefully recent, I'm willing to work with that.
>
>Current problem, btw, is that the via epia samuel 2 cpu hangs up in the 
>mtrr init code. I suspect someone updated that, for -m or -m2,  in such 
>a way that it broke older cpus.
>
>if I comment out mtrr init, i.e.
>
>
>Index: src/cpu/via/model_centaur/model_centaur_init.c
>===================================================================
>--- src/cpu/via/model_centaur/model_centaur_init.c      (revision 2158)
>+++ src/cpu/via/model_centaur/model_centaur_init.c      (working copy)
>@@ -15,7 +15,7 @@
>  {
>         /* Turn on caching if we haven't already */
>         x86_enable_cache();
>-       x86_setup_mtrrs(36);
>+//     x86_setup_mtrrs(36);
>         x86_mtrr_check();
>
>         /* Enable the local cpu apics */
>
>then it will come up -- with no working cache. And the enet problem then 
>occurs.
>
>I could use some help and perspetive here. I know some of you have epias 
>-- could you take a look?
>
>But I have other, newer things to do, and fixing an old CPU just can not 
>take priority. Sorry.
>
>ron
>
>  
>




From rminnich at lanl.gov  Mon Jan 23 05:11:47 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 22 Jan 2006 21:11:47 -0700
Subject: [LinuxBIOS] Easy compile error
In-Reply-To: <43D452E5.4030301@comcast.net>
References: <43D452E5.4030301@comcast.net>
Message-ID: <43D45783.8070702@lanl.gov>

Adam Talbot wrote:
> Humm, So I have the irq_table.c in src/mainboard/bcm/ebc3610 am I 
> missing something, some where else? Where should I look.
> -Adam Talbot
> 
> 
> linuxbios_ram.o: In function `write_tables':
> : undefined reference to `write_pirq_routing_table'
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios_ram] Error 1
> make[1]: Leaving directory 
> `/home/adam/LinuxBIOSv2-2158/targets/bcm/ebc3610/ebc3610/normal'
> make: *** [normal/linuxbios.rom] Error 1
> 
> 

you have to write your own. Take a look at the via/epia irq_table.c to 
see what it looks like. This became necessary because of all the 
variations between boards .

What is the ebc3610 again?

I forget.

ron



From rminnich at lanl.gov  Mon Jan 23 05:12:49 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 22 Jan 2006 21:12:49 -0700
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D4542C.1030308@comcast.net>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
Message-ID: <43D457C1.8010902@lanl.gov>

Thanks, adam!

if this works, I've got a starting point.

BTW, anyone out there interested in GX2? We're starting work this week, 
actually meaning Hamish is going to show us how it's done :-)

ron



From rminnich at lanl.gov  Mon Jan 23 05:18:17 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 22 Jan 2006 21:18:17 -0700
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D4542C.1030308@comcast.net>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
Message-ID: <43D45909.4020308@lanl.gov>

Can someone out there please confirm that epia-m works for them, with 
verison 2100, and see if it works with the latest?

thanks

ron



From talbotx at comcast.net  Mon Jan 23 05:20:15 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Sun, 22 Jan 2006 20:20:15 -0800
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D457C1.8010902@lanl.gov>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
	<43D457C1.8010902@lanl.gov>
Message-ID: <43D4597F.508@comcast.net>

Currently trying to port the EBC3410, but if I could find a small GX2 
board for a good price I would switch. My project is all about boot time 
and that built in DDR memory controler REALY speeds things up.
My current board.
http://www.bcmcom.com/bcm_product_ebc3410.htm
-Adam Talbot
P.S.  irq table fixed, thank you.


Ronald G Minnich wrote:

> Thanks, adam!
>
> if this works, I've got a starting point.
>
> BTW, anyone out there interested in GX2? We're starting work this 
> week, actually meaning Hamish is going to show us how it's done :-)
>
> ron
>




From rminnich at lanl.gov  Mon Jan 23 05:24:38 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 22 Jan 2006 21:24:38 -0700
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D4597F.508@comcast.net>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
	<43D457C1.8010902@lanl.gov> <43D4597F.508@comcast.net>
Message-ID: <43D45A86.4070803@lanl.gov>

Adam Talbot wrote:
> Currently trying to port the EBC3410, but if I could find a small GX2 
> board for a good price I would switch. My project is all about boot time 
> and that built in DDR memory controler REALY speeds things up.
> My current board.
> http://www.bcmcom.com/bcm_product_ebc3410.htm

Adam, if you do this port, it will help gx2.

What are you doing about the VSA stuff?

The geode has some real IP baggage .... I'm trying to talk to AMD about 
this, as it dates back to the NSC days. If we go with Geode, and we want 
(e.g.) VGA, we're going to have a huge binary blob of proprietary code 
in the middle of linuxbios. Hmm, not that much different than VGA, eh? 
But, you get the big blob from these guys: 
http://www.insydetech.com/productcenter/amd/geodesite/index.cfm

i.e., a proprietary BIOS vendor seems to be the control point for the 
AMD geode code, although the code seems to be freely available in some 
form or another. This is kind of weird. I don't quite know why it is 
done this way.

ron



From talbotx at comcast.net  Mon Jan 23 05:33:49 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Sun, 22 Jan 2006 20:33:49 -0800
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D45A86.4070803@lanl.gov>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
	<43D457C1.8010902@lanl.gov> <43D4597F.508@comcast.net>
	<43D45A86.4070803@lanl.gov>
Message-ID: <43D45CAD.9040207@comcast.net>

-Ron
To day I will sound like a n00b.  VSA?
-Adam

Ronald G Minnich wrote:

> Adam Talbot wrote:
>
>> Currently trying to port the EBC3410, but if I could find a small GX2 
>> board for a good price I would switch. My project is all about boot 
>> time and that built in DDR memory controler REALY speeds things up.
>> My current board.
>> http://www.bcmcom.com/bcm_product_ebc3410.htm
>
>
> Adam, if you do this port, it will help gx2.
>
> What are you doing about the VSA stuff?
>
> The geode has some real IP baggage .... I'm trying to talk to AMD 
> about this, as it dates back to the NSC days. If we go with Geode, and 
> we want (e.g.) VGA, we're going to have a huge binary blob of 
> proprietary code in the middle of linuxbios. Hmm, not that much 
> different than VGA, eh? But, you get the big blob from these guys: 
> http://www.insydetech.com/productcenter/amd/geodesite/index.cfm
>
> i.e., a proprietary BIOS vendor seems to be the control point for the 
> AMD geode code, although the code seems to be freely available in some 
> form or another. This is kind of weird. I don't quite know why it is 
> done this way.
>
> ron
>




From rminnich at lanl.gov  Mon Jan 23 05:40:27 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 22 Jan 2006 21:40:27 -0700
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D45CAD.9040207@comcast.net>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
	<43D457C1.8010902@lanl.gov> <43D4597F.508@comcast.net>
	<43D45A86.4070803@lanl.gov> <43D45CAD.9040207@comcast.net>
Message-ID: <43D45E3B.9030605@lanl.gov>

Adam Talbot wrote:
> -Ron
> To day I will sound like a n00b.  VSA?

A strange piece of software that is installed and acts like hardware -- 
certain ops trap to it, I think.

really odd. I can't find a good writeup on it, since it is mostly 
proprietary.

ron



From talbotx at comcast.net  Mon Jan 23 06:22:16 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Sun, 22 Jan 2006 21:22:16 -0800
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D45E3B.9030605@lanl.gov>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
	<43D457C1.8010902@lanl.gov> <43D4597F.508@comcast.net>
	<43D45A86.4070803@lanl.gov> <43D45CAD.9040207@comcast.net>
	<43D45E3B.9030605@lanl.gov>
Message-ID: <43D46808.8090305@comcast.net>

-Ron
Well, I just got my code compiling.  But I have nothing on the console.  
What settings/files would you advise I check. Serial debug is set at 9, 
but I am seeing nothing. Ideas?
-Adam


Ronald G Minnich wrote:

> Adam Talbot wrote:
>
>> -Ron
>> To day I will sound like a n00b.  VSA?
>
>
> A strange piece of software that is installed and acts like hardware 
> -- certain ops trap to it, I think.
>
> really odd. I can't find a good writeup on it, since it is mostly 
> proprietary.
>
> ron
>




From rminnich at lanl.gov  Mon Jan 23 07:04:43 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 22 Jan 2006 23:04:43 -0700
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D46808.8090305@comcast.net>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
	<43D457C1.8010902@lanl.gov> <43D4597F.508@comcast.net>
	<43D45A86.4070803@lanl.gov> <43D45CAD.9040207@comcast.net>
	<43D45E3B.9030605@lanl.gov> <43D46808.8090305@comcast.net>
Message-ID: <43D471FB.2030406@lanl.gov>

Adam Talbot wrote:
> -Ron
> Well, I just got my code compiling.  But I have nothing on the console.  
> What settings/files would you advise I check. Serial debug is set at 9, 
> but I am seeing nothing. Ideas?

First step: boot fuctory bios and make sure minicom works for you. Check 
settings on the chips under fuctory bios.

do you have a post card?

Beep won't work, I think, since no VSA in there yet.

do you have a POST card?

ron



From stuge-linuxbios at cdy.org  Mon Jan 23 13:14:41 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 23 Jan 2006 13:14:41 +0100
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D45E3B.9030605@lanl.gov>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
	<43D457C1.8010902@lanl.gov> <43D4597F.508@comcast.net>
	<43D45A86.4070803@lanl.gov> <43D45CAD.9040207@comcast.net>
	<43D45E3B.9030605@lanl.gov>
Message-ID: <20060123121441.6353.qmail@cdy.org>

On Sun, Jan 22, 2006 at 09:40:27PM -0700, Ronald G Minnich wrote:
> Adam Talbot wrote:
> > -Ron
> > To day I will sound like a n00b.  VSA?
> 
> A strange piece of software that is installed and acts like hardware
> -- certain ops trap to it, I think.
> 
> really odd. I can't find a good writeup on it, since it is mostly 
> proprietary.

VSA=Virtual System Architecture
VSM=VSA module

The BIOS inits VSA and all available VSMs. A VSM claims IO or int
resources.

VSA uses SMM to run VSMs when the OS accesses those resources.
(outb(xx,0x220) in kernel -> smint -> dispatched to audio VSM)

NSC had two documents describing it:
"VSA/BIOS Porting Guide"
and
"Virtual System Architecture BIOS Porting Guide"

Don't ask how they differ, I don't remember.


//Peter



From stuge-linuxbios at cdy.org  Mon Jan 23 13:19:33 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 23 Jan 2006 13:19:33 +0100
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D471FB.2030406@lanl.gov>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
	<43D457C1.8010902@lanl.gov> <43D4597F.508@comcast.net>
	<43D45A86.4070803@lanl.gov> <43D45CAD.9040207@comcast.net>
	<43D45E3B.9030605@lanl.gov> <43D46808.8090305@comcast.net>
	<43D471FB.2030406@lanl.gov>
Message-ID: <20060123121933.7016.qmail@cdy.org>

On Sun, Jan 22, 2006 at 11:04:43PM -0700, Ronald G Minnich wrote:
> Beep won't work, I think, since no VSA in there yet.

^G doesn't work but programming PIT2 to make some sound should work.


> do you have a POST card?

Definately the way to go, unless you have a logic analyzer nearby.


//Peter



From smithbone at gmail.com  Mon Jan 23 14:29:03 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 23 Jan 2006 07:29:03 -0600
Subject: [LinuxBIOS] one last note
In-Reply-To: <43D457C1.8010902@lanl.gov>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
	<43D457C1.8010902@lanl.gov>
Message-ID: <8a0c36780601230529y7887d961s5da63a237797ae5b@mail.gmail.com>

>
> BTW, anyone out there interested in GX2? We're starting work this week,
> actually meaning Hamish is going to show us how it's done :-)
>

Bitworks has been interested in using the GX2 as a replacement for our
STPC based stuff.  However its faceing _strong_ competition from the
newer 32 bit ARM micros we are also playing with.  The ARMS are
cheaper, they boot (a kernel) in a hearbeat, no legacy bios crap and
one test shows that even with software float emulation the performance
for our apps is just as good as the STPC.

The GX2 of course would be a much higher performance part but we
aren't quite convinced we need that yet.

I really dislike the thought of dealing with all that VSA crap.

--
Richard A. Smith

From stepan at openbios.org  Mon Jan 23 15:10:03 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon, 23 Jan 2006 15:10:03 +0100
Subject: [LinuxBIOS] one last note
In-Reply-To: <8a0c36780601230529y7887d961s5da63a237797ae5b@mail.gmail.com>
References: <43D01BB5.40804@lanl.gov> <43D4542C.1030308@comcast.net>
	<43D457C1.8010902@lanl.gov>
	<8a0c36780601230529y7887d961s5da63a237797ae5b@mail.gmail.com>
Message-ID: <20060123141003.GA14005@openbios.org>

* Richard Smith <smithbone at gmail.com> [060123 14:29]:
> The GX2 of course would be a much higher performance part but we
> aren't quite convinced we need that yet.
> 
> I really dislike the thought of dealing with all that VSA crap.

We should remember there was a VSA implementation floating around
lately that has not been approved by AMD yet.

The question is whether a VSA loader helps any since it probably won't
allow us to put VSA modules in our source tree anyways. Are those
modules owned by legacy bios vendors, similar to ACPI?

Stefan





From hamish at prodigi.ch  Mon Jan 23 17:31:07 2006
From: hamish at prodigi.ch (Hamish Guthrie)
Date: Mon, 23 Jan 2006 17:31:07 +0100
Subject: [LinuxBIOS] one last note
In-Reply-To: <20060123141003.GA14005@openbios.org>
References: <43D01BB5.40804@lanl.gov>
	<43D4542C.1030308@comcast.net>	<43D457C1.8010902@lanl.gov>	<8a0c36780601230529y7887d961s5da63a237797ae5b@mail.gmail.com>
	<20060123141003.GA14005@openbios.org>
Message-ID: <43D504CB.7010309@prodigi.ch>

Just to clarify how the VSA stuff works - I am using it sucessfully with 
GX1 and the code for GX2 is very similar.

Firstly, the VSA code is supplied in binary form only, and the code is 
owned by AMD, and AMD are quite happy for this to be included with a 
LinuxBIOS implementation (this has been cleared with them). Also, the 
VGA BIOS written by Elpin systems can be used royalty free on the Geode 
processors (also been cleared with AMD).

The issue is that each VSA module (there are a number of them), has 
real-mode initialization code which has to be called in real mode (well 
it is actually best to do it in flat mode), but it is 16-bit code. Also, 
the VGA BIOS REQUIRES that the VGA VSA module is loaded. Also, the 
framebuffer driver and the X drivers use calls to the VGA BIOS, so to 
get all of that stuff running without the VSA is a no-no.

As a dirty hack I have done an implementation for the GX1 which uses a 
thing called Xpress Loader - this is loader code which basically gets 
all the hardware running - detects RAM and loads all of the VSA modules. 
Xpress Loader was written by National Semiconductor and now belongs to 
AMD, and is provided free of charge to anyone who wants to use it. This 
has also been cleared with AMD.

All I have then done is to create a stripped down version of LinuxBIOS 
in the V2 tree which skips all of the low-level init, does the PCI 
enumerations etc., and then uses whatever loader you want to load the 
kernel and boot into Linux.

The boot process is therefore as follows:

Initial boot vectors to the modified Xpress Loader code.
Xpress loader inits RAM, a couple of other bits and pieces, installs the 
VSA modules, initializes the VSA modules, installs the VGA bios, and 
enters text mode.
Finally Xpress Loader vectors to the stripped down LinuxBIOS which 
switches into protected mode and then does it's magic.

Hamish

Stefan Reinauer wrote:
> * Richard Smith <smithbone at gmail.com> [060123 14:29]:
> 
>>The GX2 of course would be a much higher performance part but we
>>aren't quite convinced we need that yet.
>>
>>I really dislike the thought of dealing with all that VSA crap.
> 
> 
> We should remember there was a VSA implementation floating around
> lately that has not been approved by AMD yet.
> 
> The question is whether a VSA loader helps any since it probably won't
> allow us to put VSA modules in our source tree anyways. Are those
> modules owned by legacy bios vendors, similar to ACPI?
> 
> Stefan
> 
> 
> 

-- 
Hamish Guthrie
Guthrie Consulting
Bueglgrond 86
7550 Scuol
Switzerland
TEL: +41 81 862 2613
FAX: +41 81 862 2640
EMAIL: hamish at prodigi.ch




From talbotx at comcast.net  Mon Jan 23 23:28:05 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Mon, 23 Jan 2006 14:28:05 -0800
Subject: [LinuxBIOS] No console, yet... Ideas?
Message-ID: <43D55875.5000704@comcast.net>

Console is working.  Fully tested. 
Post card... There are no PCI/ISA slots on this board, all I have is 1 
pc/104 slot and no jtag.  The superIO is controled by a via vt1211.  I 
think I have that part of my config correct. (see below) But I am not 
sure how to figure out the pnp address. 
-Adam

 chip superio/via/vt1211
                                        device pnp 2e.2 on      #  Com1
                                           io 0x60 = 0x3f8
                                          irq 0x70 = 4
                                        end

Adam Talbot wrote:

> -Ron
> Well, I just got my code compiling.  But I have nothing on the 
> console.  What settings/files would you advise I check. Serial debug 
> is set at 9, but I am seeing nothing. Ideas?


First step: boot fuctory bios and make sure minicom works for you. Check 
settings on the chips under fuctory bios.

do you have a post card?

Beep won't work, I think, since no VSA in there yet.

do you have a POST card?

ron



From smithbone at gmail.com  Tue Jan 24 00:03:01 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 23 Jan 2006 17:03:01 -0600
Subject: [LinuxBIOS] No console, yet... Ideas?
In-Reply-To: <43D55875.5000704@comcast.net>
References: <43D55875.5000704@comcast.net>
Message-ID: <8a0c36780601231503t25b9083dvb6d4d77bed7346@mail.gmail.com>

> pc/104 slot and no jtag.  The superIO is controled by a via vt1211.  I
> think I have that part of my config correct. (see below) But I am not
> sure how to figure out the pnp address.

Normally the superIO will have the address set in hardware by a pin
strapping.  Get the datasheet on the superIO and look at the options. 
Then verify by some simple IO testing to the data register.  You
should be able to write a value to the data register and then read it
back.

--
Richard A. Smith

From rminnich at lanl.gov  Tue Jan 24 00:04:50 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 23 Jan 2006 16:04:50 -0700
Subject: [LinuxBIOS] No console, yet... Ideas?
In-Reply-To: <43D55875.5000704@comcast.net>
References: <43D55875.5000704@comcast.net>
Message-ID: <43D56112.4070308@lanl.gov>

Adam Talbot wrote:
> Console is working.  Fully tested. 
> Post card... There are no PCI/ISA slots on this board, all I have is 1 
> pc/104 slot and no jtag.  The superIO is controled by a via vt1211.  I 
> think I have that part of my config correct. (see below) But I am not 
> sure how to figure out the pnp address. 
> -Adam
> 
>  chip superio/via/vt1211
>                                         device pnp 2e.2 on      #  Com1
>                                            io 0x60 = 0x3f8
>                                           irq 0x70 = 4
>                                         end
> 
> Adam Talbot wrote:
> 
> 

as richard says:

main(){
	iopl(3);

	inb(0x2e);

	/* and print that out, see if it is 0xff */
	inb(0x4e); // or whatever

}

in other words, from a c program, just try to recreate what linuxbios 
does for I/o to superio, and see what works.

ron



From talbotx at comcast.net  Tue Jan 24 00:22:18 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Mon, 23 Jan 2006 15:22:18 -0800
Subject: [LinuxBIOS] No console, yet... Ideas?
In-Reply-To: <43D56112.4070308@lanl.gov>
References: <43D55875.5000704@comcast.net> <43D56112.4070308@lanl.gov>
Message-ID: <43D5652A.6000905@comcast.net>

I am missing an inclue or define statment...

3_5_proto#gcc test.c
/tmp/ccwX6c0l.o: In function `main':
test.c:(.text+0x24): undefined reference to `inb'
test.c:(.text+0x30): undefined reference to `inb'
collect2: ld returned 1 exit status


Ronald G Minnich wrote:

> Adam Talbot wrote:
>
>> Console is working.  Fully tested. Post card... There are no PCI/ISA 
>> slots on this board, all I have is 1 pc/104 slot and no jtag.  The 
>> superIO is controled by a via vt1211.  I think I have that part of my 
>> config correct. (see below) But I am not sure how to figure out the 
>> pnp address. -Adam
>>
>>  chip superio/via/vt1211
>>                                         device pnp 2e.2 on      #  Com1
>>                                            io 0x60 = 0x3f8
>>                                           irq 0x70 = 4
>>                                         end
>>
>> Adam Talbot wrote:
>>
>>
>
> as richard says:
>
> main(){
>     iopl(3);
>
>     inb(0x2e);
>
>     /* and print that out, see if it is 0xff */
>     inb(0x4e); // or whatever
>
> }
>
> in other words, from a c program, just try to recreate what linuxbios 
> does for I/o to superio, and see what works.
>
> ron
>




From smithbone at gmail.com  Tue Jan 24 01:09:04 2006
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 23 Jan 2006 18:09:04 -0600
Subject: [LinuxBIOS] No console, yet... Ideas?
In-Reply-To: <43D5652A.6000905@comcast.net>
References: <43D55875.5000704@comcast.net> <43D56112.4070308@lanl.gov>
	<43D5652A.6000905@comcast.net>
Message-ID: <8a0c36780601231609o1a81fad9o89feee13172521f6@mail.gmail.com>

On 1/23/06, Adam Talbot <talbotx at comcast.net> wrote:

> I am missing an inclue or define statment...
>
> 3_5_proto#gcc test.c
> /tmp/ccwX6c0l.o: In function `main':
> test.c:(.text+0x24): undefined reference to `inb'
> test.c:(.text+0x30): undefined reference to `inb'
> collect2: ld returned 1 exit status

#include <sys/io.h>

You also have to compile with -O or -O2 otherwise you will get link
errors.  IO is implemented as macros and they don't get linked in
unless optimizations are turned on.



--
Richard A. Smith

From rminnich at lanl.gov  Tue Jan 24 01:06:24 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 23 Jan 2006 17:06:24 -0700
Subject: [LinuxBIOS] No console, yet... Ideas?
In-Reply-To: <43D5652A.6000905@comcast.net>
References: <43D55875.5000704@comcast.net> <43D56112.4070308@lanl.gov>
	<43D5652A.6000905@comcast.net>
Message-ID: <43D56F80.90103@lanl.gov>

Adam Talbot wrote:
> I am missing an inclue or define statment...
>
oh, that code I sent is crap.

I did not know you wanted the full thing.

#include <stdio.h>
#include <asm/io.h>

main(){
	uchar c;

	c = inb(0x2e);
	printf("c %02x\n", c);
}

be sure to cc -O2 or the damned asm junk won't get inlined, and you'll 
get link-time errors.

ron




From talbotx at comcast.net  Tue Jan 24 01:44:52 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Mon, 23 Jan 2006 16:44:52 -0800
Subject: [LinuxBIOS] No console, yet... Ideas?
In-Reply-To: <43D56F80.90103@lanl.gov>
References: <43D55875.5000704@comcast.net> <43D56112.4070308@lanl.gov>
	<43D5652A.6000905@comcast.net> <43D56F80.90103@lanl.gov>
Message-ID: <43D57884.5090500@comcast.net>

-Ron
Just a guess.  uchar = unsigned char???
-Adam

Ronald G Minnich wrote:

> Adam Talbot wrote:
>
>> I am missing an inclue or define statment...
>>
> oh, that code I sent is crap.
>
> I did not know you wanted the full thing.
>
> #include <stdio.h>
> #include <asm/io.h>
>
> main(){
>     uchar c;
>
>     c = inb(0x2e);
>     printf("c %02x\n", c);
> }
>
> be sure to cc -O2 or the damned asm junk won't get inlined, and you'll 
> get link-time errors.
>
> ron
>
>




From talbotx at comcast.net  Tue Jan 24 01:52:07 2006
From: talbotx at comcast.net (Adam Talbot)
Date: Mon, 23 Jan 2006 16:52:07 -0800
Subject: [LinuxBIOS] No console, yet... Ideas?
In-Reply-To: <43D57884.5090500@comcast.net>
References: <43D55875.5000704@comcast.net>
	<43D56112.4070308@lanl.gov>	<43D5652A.6000905@comcast.net>
	<43D56F80.90103@lanl.gov> <43D57884.5090500@comcast.net>
Message-ID: <43D57A37.1030008@comcast.net>

-Ron
Little bug fix's and its working
# ./a.out
c ff

#include <stdio.h>
#include <asm/io.h>

main(){
        unsigned char c;
        ioperm(0x2E, 1, 1);

        c = inb(0x2e);
        printf("c %02x\n", c);
}
-Adam

Adam Talbot wrote:

>-Ron
>Just a guess.  uchar = unsigned char???
>-Adam
>
>Ronald G Minnich wrote:
>
>  
>
>>Adam Talbot wrote:
>>
>>    
>>
>>>I am missing an inclue or define statment...
>>>
>>>      
>>>
>>oh, that code I sent is crap.
>>
>>I did not know you wanted the full thing.
>>
>>#include <stdio.h>
>>#include <asm/io.h>
>>
>>main(){
>>    uchar c;
>>
>>    c = inb(0x2e);
>>    printf("c %02x\n", c);
>>}
>>
>>be sure to cc -O2 or the damned asm junk won't get inlined, and you'll 
>>get link-time errors.
>>
>>ron
>>
>>
>>    
>>
>
>
>  
>




From rminnich at lanl.gov  Tue Jan 24 03:05:11 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 23 Jan 2006 19:05:11 -0700
Subject: [LinuxBIOS] No console, yet... Ideas?
In-Reply-To: <43D57884.5090500@comcast.net>
References: <43D55875.5000704@comcast.net> <43D56112.4070308@lanl.gov>
	<43D5652A.6000905@comcast.net> <43D56F80.90103@lanl.gov>
	<43D57884.5090500@comcast.net>
Message-ID: <43D58B57.4020208@lanl.gov>

Adam Talbot wrote:
> -Ron
> Just a guess.  uchar = unsigned char???


yeah

ron



From rminnich at lanl.gov  Tue Jan 24 03:06:01 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Mon, 23 Jan 2006 19:06:01 -0700
Subject: [LinuxBIOS] No console, yet... Ideas?
In-Reply-To: <43D57A37.1030008@comcast.net>
References: <43D55875.5000704@comcast.net>
	<43D56112.4070308@lanl.gov>	<43D5652A.6000905@comcast.net>
	<43D56F80.90103@lanl.gov> <43D57884.5090500@comcast.net>
	<43D57A37.1030008@comcast.net>
Message-ID: <43D58B89.6010508@lanl.gov>

Adam Talbot wrote:
> -Ron
> Little bug fix's and its working
> # ./a.out
> c ff
> 
> #include <stdio.h>
> #include <asm/io.h>
> 
> main(){
>        unsigned char c;
>        ioperm(0x2E, 1, 1);


warning to all: iopl(3) is safer since on some arch's (most recently 
x86_64) ioperm won't do the right thing. just fyi.

ron



From a.borisov at tesv.tmb.ru  Tue Jan 24 06:15:37 2006
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Tue, 24 Jan 2006 08:15:37 +0300
Subject: [LinuxBIOS] one last note for epia
In-Reply-To: <43D01BB5.40804@lanl.gov>
References: <43D01BB5.40804@lanl.gov>
Message-ID: <20060124081537.2fcd4672.a.borisov@tesv.tmb.ru>

On Thu, 19 Jan 2006 16:07:33 -0700
Ronald G Minnich <rminnich at lanl.gov> wrote:

> if anyone out there has a copy of a version of the  v2 repo that can 
> build a working via epia, hopefully recent, I'm willing to work with that.
> 
> Current problem, btw, is that the via epia samuel 2 cpu hangs up in the 
> mtrr init code. I suspect someone updated that, for -m or -m2,  in such 
> a way that it broke older cpus.

Ron, my board is epia-m 10k. cpuid = 0x695. It works fine with v2080 (Barker's patch applied). And it perfectly
boots and does poweroffs with v2161 and v2163. So I see no problems with that.

-- 
Sincerely, Anton Borisov



From rminnich at gmail.com  Tue Jan 24 07:10:14 2006
From: rminnich at gmail.com (ron minnich)
Date: Mon, 23 Jan 2006 23:10:14 -0700
Subject: [LinuxBIOS] one last note for epia
In-Reply-To: <20060124081537.2fcd4672.a.borisov@tesv.tmb.ru>
References: <43D01BB5.40804@lanl.gov>
	<20060124081537.2fcd4672.a.borisov@tesv.tmb.ru>
Message-ID: <13426df10601232210j36acedc6g9f7d626fb41c8092@mail.gmail.com>

So you have vga and all the other features as well? What board vendor/model
is this? I'd like to put it on the web page.

thanks

ron


On 1/23/06, Anton Borisov <a.borisov at tesv.tmb.ru> wrote:
>
> On Thu, 19 Jan 2006 16:07:33 -0700
> Ronald G Minnich <rminnich at lanl.gov> wrote:
>
> > if anyone out there has a copy of a version of the  v2 repo that can
> > build a working via epia, hopefully recent, I'm willing to work with
> that.
> >
> > Current problem, btw, is that the via epia samuel 2 cpu hangs up in the
> > mtrr init code. I suspect someone updated that, for -m or -m2,  in such
> > a way that it broke older cpus.
>
> Ron, my board is epia-m 10k. cpuid = 0x695. It works fine with v2080
> (Barker's patch applied). And it perfectly
> boots and does poweroffs with v2161 and v2163. So I see no problems with
> that.
>
> --
> Sincerely, Anton Borisov
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060123/02fb0684/attachment.html>

From smithbone at gmail.com  Tue Jan 24 16:46:15 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 24 Jan 2006 09:46:15 -0600
Subject: [LinuxBIOS] one last note for epia
In-Reply-To: <13426df10601232210j36acedc6g9f7d626fb41c8092@mail.gmail.com>
References: <43D01BB5.40804@lanl.gov>
	<20060124081537.2fcd4672.a.borisov@tesv.tmb.ru>
	<13426df10601232210j36acedc6g9f7d626fb41c8092@mail.gmail.com>
Message-ID: <8a0c36780601240746w2bd7e8cdgf8beba385bc86f61@mail.gmail.com>

On 1/24/06, ron minnich <rminnich at gmail.com> wrote:
> So you have vga and all the other features as well? What board vendor/model
> is this? I'd like to put it on the web page.

Anton,

I thought you had to make some changes that were not compatible with
the epia m tree as it stands.  The action stefan and I thought best
was to create a new mainboard directory.  I don't believe thats
happened yet.

We probally want to get this all fixed up before any success reports
show up on the webpage or we will just have to deal with a lot of
failure reports on the list.

IIRC the issues were that your board does not have a device that the
current tree probes for and this caused a long delay in booting as the
code loops through looking for all devices on all busses.  Then there
was some VGA wierdness that I think was solved by write protecting the
legacy VGA bios range.

--
Richard A. Smith

From MSamet at ea.com  Tue Jan 24 20:41:53 2006
From: MSamet at ea.com (Samet, Matt)
Date: Tue, 24 Jan 2006 11:41:53 -0800
Subject: [LinuxBIOS] VIA/EPIA Question
Message-ID: <9D3D7CEF3A236243AF0335652672E34805E05B72@maxis-mb1.max.ad.ea.com>

Hi list,

 

Longtime reader, first poster :-)  I and many others appreciate
everything you guys are doing here.

 

I wanted to inquire about the status of the VIA VT8237 southbridge... I
know some of you may be working on it and was just curious how far it's
gotten.

I'm interested in doing some work to support an EPIA board which has a
CLE266 northbridge and VT8237 southbridge (and a VIA Eden CPU).  Since
the Epia(-M) platform exists already, approximately how hard would it be
to make a target for Eden / CLE266 / VT8237?  The board's name is Epia
MS and the specification sheet can be found here: 

 

http://www.via.com.tw/en/products/mainboards/mini_itx/epia_ms/

 

It looks very similar to the Epia M.

 

I suppose you guys would recommend I post the lspci -vvv output? :-)

 

Thanks much,

-=matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060124/90f059e2/attachment.html>

From rminnich at lanl.gov  Tue Jan 24 20:46:42 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 24 Jan 2006 12:46:42 -0700
Subject: [LinuxBIOS] VIA/EPIA Question
In-Reply-To: <9D3D7CEF3A236243AF0335652672E34805E05B72@maxis-mb1.max.ad.ea.com>
References: <9D3D7CEF3A236243AF0335652672E34805E05B72@maxis-mb1.max.ad.ea.com>
Message-ID: <43D68422.60202@lanl.gov>

how about URLs for chipset docs.

If I can get chipset docs, i want to start posting them at 
linuxbios.org, since sometimes they go away.

NOTE: we only will post docs that are freely available, so don't send me 
ANY docs; send me URLS.

ron



From c-d.hailfinger.devel.2006 at gmx.net  Wed Jan 25 00:24:11 2006
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 25 Jan 2006 00:24:11 +0100
Subject: [LinuxBIOS] Chipset docs for IT8712 SuperIO (found on ASUS A8N-SLI
	Deluxe)
Message-ID: <43D6B71B.1010205@gmx.net>

Hi,

chipset docs for the IT8712 SuperIO can be found at
http://www.ite.com.tw/product_info/PC/Brief-IT8712_2.asp
This SuperIO chip is used on the Asus A8N-SLI Deluxe board.

Unfortunately, their webserver has some problems and I
had to restart the download 30 times before I got the
complete documents. If you have trouble downloading them,
tell me and I'll send them via private mail.

Ronald, would you be so kind and post these docs at
linuxbios.org?

Another question: How difficult would it be to get a
mainboard with this SuperIO up and running?

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/



From smithbone at gmail.com  Wed Jan 25 06:58:01 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 24 Jan 2006 23:58:01 -0600
Subject: [LinuxBIOS] Subtree? [Re:  one last note for epia]
In-Reply-To: <8a0c36780601242150l742b3c84x39477233eacde812@mail.gmail.com>
References: <20060125083632.0ff7b90a.a.borisov@tesv.tmb.ru>
	<8a0c36780601242150l742b3c84x39477233eacde812@mail.gmail.com>
Message-ID: <8a0c36780601242158n52211c00p74d60ccd274f42c@mail.gmail.com>

The cc: to the list got dropped.  Here's the result of the discussion.

=======================
> If you consider creating new subtree for epia-m then let it be, though I don't think
> it should be done actually. Vanilla images (2161, 2163) seems to be working for my
> box quite well. Of course, others should also report it's O'k with them too - I remember

My bad.  I had you confused with Christian S?hs.  He is using the
epia-ML.  The ML is the board that needed the changes and needs a new
mainboard directory.  Sorry.  Carry on and post that success report.
=======================

--
Richard A. Smith

From chris at suehsi.de  Wed Jan 25 09:09:48 2006
From: chris at suehsi.de (=?UTF-8?B?Q2hyaXN0aWFuIFPDvGhz?=)
Date: Wed, 25 Jan 2006 09:09:48 +0100
Subject: [LinuxBIOS] Subtree? [Re:  one last note for epia]
In-Reply-To: <8a0c36780601242158n52211c00p74d60ccd274f42c@mail.gmail.com>
References: <20060125083632.0ff7b90a.a.borisov@tesv.tmb.ru>	<8a0c36780601242150l742b3c84x39477233eacde812@mail.gmail.com>
	<8a0c36780601242158n52211c00p74d60ccd274f42c@mail.gmail.com>
Message-ID: <43D7324C.4050203@suehsi.de>

Richard Smith schrieb:
> The cc: to the list got dropped.  Here's the result of the discussion.
> 
> =======================
> 
>>If you consider creating new subtree for epia-m then let it be, though I don't think
>>it should be done actually. Vanilla images (2161, 2163) seems to be working for my
>>box quite well. Of course, others should also report it's O'k with them too - I remember
> 
> 
> My bad.  I had you confused with Christian S?hs.  He is using the
> epia-ML.  The ML is the board that needed the changes and needs a new
> mainboard directory.  Sorry.  Carry on and post that success report.
> =======================
> 
> --
> Richard A. Smith

What's going on :D

I'm still back from holiday and read my name ;)

Ok, first I must read all mailinglist entrys.

So long

chris




From Jeff.Young at gd-ais.com  Wed Jan 25 12:21:12 2006
From: Jeff.Young at gd-ais.com (Young, Jeff S.)
Date: Wed, 25 Jan 2006 05:21:12 -0600
Subject: [LinuxBIOS] tyan s2895 build question
Message-ID: <0CA0904277689E458CC4130BDDFDF26706EA12@MNBM01-MAIL01.ad.gd-ais.com>

 
Howdy folks,
            I have been trying to build the tyan s2895 board with gcc
3.3 on SuSE 10.0
It doesn't build.  The loader tries to overlap some sections.  I got
around this by
laying out my own ldscript.lb file (similarly to what Ron wants to do).
After this, both
the fallback and normal builds result in the following error:
 
 
nm -n linuxbios_ram | sort > linuxbios_ram.map
objcopy --gap-fill 0xff -O binary linuxbios_ram linuxbios_ram.bin
./nrv2b e linuxbios_ram.bin linuxbios_ram.nrv2b
input/output = 164944/55295 = 2.983
cp linuxbios_ram.nrv2b linuxbios_ram.rom
gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld
crt0.o init.o
nm -n linuxbios | sort > linuxbios.map
objcopy --gap-fill 0xff -O binary linuxbios linuxbios.strip
./buildrom linuxbios.strip linuxbios.rom
../../../../payloads/forcedeth--filo_hda2_vga.zelf 0x20000 0x40000
../../../../payloads/forcedeth--filo_hda2_vga.zelf: No such file or
directory
 
 
            What does this mean?  Also, is there a writeup on just what
buildrom does?
 
Thanks,
Jeff Young
 
 
 
PS:       Can anyone actually build the S2895 without any errors today?
If so, exactly how do you
            do it.  (Note that I have tried several snapshots from 2007
-> 2163 without success.)
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060125/045c44d0/attachment.html>

From stepan at openbios.org  Wed Jan 25 12:40:13 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 25 Jan 2006 12:40:13 +0100
Subject: [LinuxBIOS] tyan s2895 build question
In-Reply-To: <0CA0904277689E458CC4130BDDFDF26706EA12@MNBM01-MAIL01.ad.gd-ais.com>
References: <0CA0904277689E458CC4130BDDFDF26706EA12@MNBM01-MAIL01.ad.gd-ais.com>
Message-ID: <20060125114013.GA31670@openbios.org>

* Young, Jeff S. <Jeff.Young at gd-ais.com> [060125 12:21]:
> objcopy --gap-fill 0xff -O binary linuxbios linuxbios.strip
> 
> ./buildrom linuxbios.strip linuxbios.rom ../../../../payloads/
> forcedeth--filo_hda2_vga.zelf 0x20000 0x40000
> 
> ../../../../payloads/forcedeth--filo_hda2_vga.zelf: No such file or directory
 
It does not find your payload image. 

try using an absolute path in your target configuration file


You said you are using gcc 3.3 in suse 10. Did you install this compiler
yourself? I use the same distribution, but I have gcc 4 installed.

> PS:       Can anyone actually build the S2895 without any errors
> today?  If so, exactly how do you do it.  (Note that I have tried 
> several snapshots from 2007 -> 2163 without success.)

It builds fine here, see build log
http://snapshots.linuxbios.org/stats/abuild-LinuxBIOSv2-2163.log

Your gcc might make things larger than gcc 4 which is why you saw the
overlap error. increasing ROM_IMAGE_SIZE(?) should help without changing
the LD script.

Also I am pretty sure you get your image compiling when you fix your
payload path above..

Stefan









From rminnich at lanl.gov  Wed Jan 25 16:58:24 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Wed, 25 Jan 2006 08:58:24 -0700
Subject: [LinuxBIOS] tyan s2895 build question
In-Reply-To: <0CA0904277689E458CC4130BDDFDF26706EA12@MNBM01-MAIL01.ad.gd-ais.com>
References: <0CA0904277689E458CC4130BDDFDF26706EA12@MNBM01-MAIL01.ad.gd-ais.com>
Message-ID: <43D7A020.9090308@lanl.gov>

Young, Jeff S. wrote:
>  
> 
> Howdy folks,
> 
>             I have been trying to build the tyan s2895 board with gcc 
> 3.3 on SuSE 10.0
> 
> It doesn?t build.  The loader tries to overlap some sections.  I got 
> around this by
> 
> laying out my own ldscript.lb file (similarly to what Ron wants to do).  

sorry for this confusion, but what you did and what I am doing are 
totally unrelated.

I am merely proposing to mod the standard LinuxBIOS makefile so that the 
ldscript.ld is not a sequence of INCLUDE statements, but instead a 
sequence of ld commands. (Sorry, folks, I have not done this yet)

What you did is hack the ldscript.ld script to make things fit. This is 
going to burn you big time next time you need to run buildtarget -- you 
will lose those changes. You need to set proper options in your 
targets/tyan/s2895/Config.lb -- for best results, however, make your own 
copy of that file.

Please see my linux journal web article, wherein the way you size rom 
images is explained.

Sorry you are having trouble, we are looking at this board too and will 
try to make sure it works.

thanks

ron



From yinghailu at gmail.com  Fri Jan 27 13:44:52 2006
From: yinghailu at gmail.com (yhlu)
Date: Fri, 27 Jan 2006 20:44:52 +0800
Subject: [LinuxBIOS] tyan s2895 build question
In-Reply-To: <43D7A020.9090308@lanl.gov>
References: <0CA0904277689E458CC4130BDDFDF26706EA12@MNBM01-MAIL01.ad.gd-ais.com>
	<43D7A020.9090308@lanl.gov>
Message-ID: <2ea3fae10601270444o6a3dc7c3kf6786156932674e3@mail.gmail.com>

I guess We may need to defined our tool chain version....

YH

On 1/25/06, Ronald G Minnich <rminnich at lanl.gov> wrote:
> Young, Jeff S. wrote:
> >
> >
> > Howdy folks,
> >
> >             I have been trying to build the tyan s2895 board with gcc
> > 3.3 on SuSE 10.0
> >
> > It doesn't build.  The loader tries to overlap some sections.  I got
> > around this by
> >
> > laying out my own ldscript.lb file (similarly to what Ron wants to do).
>
> sorry for this confusion, but what you did and what I am doing are
> totally unrelated.
>
> I am merely proposing to mod the standard LinuxBIOS makefile so that the
> ldscript.ld is not a sequence of INCLUDE statements, but instead a
> sequence of ld commands. (Sorry, folks, I have not done this yet)
>
> What you did is hack the ldscript.ld script to make things fit. This is
> going to burn you big time next time you need to run buildtarget -- you
> will lose those changes. You need to set proper options in your
> targets/tyan/s2895/Config.lb -- for best results, however, make your own
> copy of that file.
>
> Please see my linux journal web article, wherein the way you size rom
> images is explained.
>
> Sorry you are having trouble, we are looking at this board too and will
> try to make sure it works.
>
> thanks
>
> ron
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From Jeff.Young at gd-ais.com  Fri Jan 27 16:20:06 2006
From: Jeff.Young at gd-ais.com (Young, Jeff S.)
Date: Fri, 27 Jan 2006 09:20:06 -0600
Subject: [LinuxBIOS] tyan s2895 build question - again
Message-ID: <0CA0904277689E458CC4130BDDFDF26706EA1A@MNBM01-MAIL01.ad.gd-ais.com>

 
Howdy again,
            Things are getting better now, so I wanted to keep everyone
up to date with what I had
To do in order to get as far as I have.
 
            System:            Tyan s2895 with 2 Dual Core AMDs and 8GB
memory
            BIOS:               Using RD1 Bios savior (4mbit)
            OS:                  Linux - SuSE 10.0 stock (ie, gcc 4)
 
            Build issues:     when building, there was an overlapping
section.  I created the following
                                    Section and it fixes it:
 
                                    .rodata. : {
                                                *(.rodata.str1.*);
                                    }
 
                                    This was placed after .rom section
 
                                    Payload not found.  It wasn't clear
from the writeup that I had to get the
                                    Payload from the web site.  Stefan
was an immense help in this arena.
                                    Maybe the payload directory should
be bundled with the snapshots because
                                    You need it anyway.
 
            Run issues:       I build the s2895 bios (fallback and
normal) and flash the RD1.  I don't know
                                    If the fact that the RD1 is 4mbit
and the original chip was 8mbit will cause any
                                    Problems.  The BIOS starts up just
fine until the time comes to enable the cache 
                                    The second time around.  (This is
after the device enumeration and is in the
                                    Initialization stuff.)  It hangs
right after the code gets cr0 to update it.
 
 
            I get the impression that I am the only one seeing these
issues.  It seems that everyone else
Can just build and run.  Is this really true?   If you just grab
snapshot 2163, untar it, and buildtarget tyan/s2895
Cd tyan/s2895/s2895, and make, it does it just fine???
 
            Any ideas on the cache enable?
 
Thanks,
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060127/afd921cb/attachment.html>

From rminnich at lanl.gov  Sat Jan 28 00:09:31 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Fri, 27 Jan 2006 16:09:31 -0700
Subject: [LinuxBIOS] tyan s2895 build question
In-Reply-To: <2ea3fae10601270444o6a3dc7c3kf6786156932674e3@mail.gmail.com>
References: <0CA0904277689E458CC4130BDDFDF26706EA12@MNBM01-MAIL01.ad.gd-ais.com>	
	<43D7A020.9090308@lanl.gov>
	<2ea3fae10601270444o6a3dc7c3kf6786156932674e3@mail.gmail.com>
Message-ID: <43DAA82B.5030105@lanl.gov>

yhlu wrote:
> I guess We may need to defined our tool chain version....
> 


I am hoping CAR + a new linuxbios image builder will fix this.

ron



From pada at chemonline.de  Mon Jan 30 14:32:01 2006
From: pada at chemonline.de (Daniel Parthey)
Date: Mon, 30 Jan 2006 14:32:01 +0100
Subject: [LinuxBIOS] VIA EPIA-ML6000EA VGA Problem and Kernel Panic
Message-ID: <20060130133200.GA11842@daniel.localdomain>

Dear List Members,

I tried to get LinuxBIOS Rev 2163 running on an VIA EPIA-ML6000EA Board
using the EPIA-M target. The kernel is on /dev/hda1 of an IDE harddisk.

After building the rom image vgabios+linuxbios[filo] I did the following:

Boot factory BIOS
Remove BIOS chip
Insert Test chip
Write linuxbios.rom image to flash
Reboot, it booted, network worked, but vga output failed
Reboot, it booted, network worked, but vga output failed
Switched off power
Switched on power
Graphic output totally fails and kernel panic occurs,
my LinuxBIOS.rom does not boot on its own anymore.

Maybe this has something to do with the VGA Bios, but I don't know
what the reason could be?

I extracted the VGA Bios from the running system with original BIOS
with the following command and get an video.bios.bin with the 55 aa in
the first two bytes:
dd if=/dev/mem of=/video.bios.bin bs=65536 count=1 skip=12
At some other location I read something about other weird dd parameters.

The resulting vga image from /dev/mem looked as follows:

$ ls -l video.bios.bin 
-rw-r--r--  1 pada pada 65536 2006-01-23 10:31 video.bios.bin

$ file video.bios.bin
video.bios.bin: BIOS (ia32) ROM Ext. IBM comp. Video (118*512)

$ hd video.bios.bin | head
00000000  55 aa 76 e9 ac 89 90 1b  82 ea 74 8d 00 00 00 00  |Uv....t.....|
00000010  00 00 00 00 00 00 00 00  44 00 a5 37 c5 00 49 42  |........D.7.IB|
00000020  4d 20 43 4f 4d 50 41 54  49 42 4c 45 42 43 50 4f  |M COMPATIBLEBCPO|
00000030  53 54 00 00 18 00 30 34  2f 30 38 2f 30 34 00 09  |ST....04/08/04..|
00000040  00 c0 c6 00 50 43 49 52  06 11 22 31 00 00 18 00  |..PCIR.."1....|
00000050  00 00 00 03 40 00 51 01  00 80 00 00 00 01 20 20  |.... at .Q.......  |
00000060  20 56 49 41 20 54 65 63  68 2e 20 49 6e 63 2e 20  | VIA Tech. Inc. |
00000070  56 54 33 31 32 33 20 20  20 4d 6f 62 69 6c 65 20  |VT3123   Mobile |
00000080  20 56 54 31 36 32 32 90  c2 00 40 56 65 72 34 30  | VT1622.. at Ver40|
00000090  20 20 20 20 20 20 20 20  20 20 20 20 00 00 00 00  |            ....|

Is this VGA Bios Image correct?
I hacked the Makefile to prepend vga.bios.bin to the bios image
(as described in the VIA EPIA-M howto)

Now I get a kernel panic with the following output on ttyS0
and the system hangs.

And Ideas what I could try to prevent the kernel panic?

Here's the full console output from null modem connection on ttyS0:

LinuxBIOS-1.1.8.0Fallback Mon Jan 23 11:24:51 CET 2006 starting...
 Enabling mainboard devices
 Enabling shadow ram
vt8623 init starting
Detecting Memory
Number of Banks 04
Number of Rows 0d
Priamry DRAM width08
No Columns 0a
MA type e0
Bank 0 (*16 Mb) 10
No Physical Banks 02
Total Memory (*16 Mb) 20
CAS Supported 2.5 
Cycle time at CL X     (nS)50
Cycle time at CL X-0.5 (nS)00
Cycle time at CL X-1   (nS)00
Starting at CAS 2.5
tRP 48
tRCD 48
tRAS 28
Low Bond 00  High Bondc3  Setting DQS delay82vt8623 done
00:06 11 23 31 06 00 30 22 00 00 00 06 00 00 00 00 
10:08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 
20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 
40:00 18 88 80 82 44 00 00 18 99 88 80 82 44 00 00 
50:c8 de cf 88 e0 07 00 00 e0 00 10 20 20 20 00 00 
60:02 ff 00 30 e6 32 01 24 42 2d 43 58 84 55 00 00 
70:82 48 00 01 01 08 50 00 01 00 00 00 00 00 12 02 
80:0f 64 00 00 80 00 00 00 02 00 00 00 00 00 00 00 
90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
a0:02 c0 20 00 07 02 00 1f 04 00 00 00 2f 02 04 00 
b0:00 00 00 00 80 00 00 00 48 00 00 04 00 00 00 00 
c0:01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 
d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
e0:00 dd 00 01 00 00 01 00 40 00 00 00 00 00 00 00 
f0:00 00 00 00 00 00 12 13 00 00 00 00 00 00 00 00 
AGP
 Doing MTRR init.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.8.0Fallback Mon Jan 23 11:24:51 CET 2006 booting...
clocks_per_usec: 1495
Enumerating buses...
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123] enabled
PCI: 00:01.0 [1106/b091] enabled
Disabling static device: PCI: 00:0a.0
Disabling static device: PCI: 00:0a.1
In vt8235_enable 1106 3038.
PCI: 00:10.0 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.1 [1106/3038] enabled
In vt8235_enable 1106 3038.
PCI: 00:10.2 [1106/3038] enabled
In vt8235_enable 1106 3104.
PCI: 00:10.3 [1106/3104] enabled
In vt8235_enable 1106 3177.
Initialising Devices
PCI: 00:11.0 [1106/3177] enabled
In vt8235_enable 1106 0571.
PCI: 00:11.1 [1106/0571] enabled
In vt8235_enable 1106 3059.
PCI: 00:11.5 [1106/3059] enabled
In vt8235_enable ffff ffff.
In vt8235_enable 1106 3065.
PCI: 00:12.0 [1106/3065] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1106/3122] enabled
PCI: pci_scan_bus returning with max=01
vt1211 enabling PNP devices.
PNP: 002e.0 enabled
vt1211 enabling PNP devices.
PNP: 002e.1 enabled
vt1211 enabling PNP devices.
PNP: 002e.2 enabled
vt1211 enabling PNP devices.
PNP: 002e.3 enabled
vt1211 enabling PNP devices.
PNP: 002e.b enabled
PCI: pci_scan_bus returning with max=01
done
Allocating resources...
Reading resources...
Done reading resources.
Setting resources...
I would set ram size to 0x80000 Kbytes
PCI: 00:10.0 20 <- [0x0000001800 - 0x000000181f] io
PCI: 00:10.1 20 <- [0x0000001820 - 0x000000183f] io
PCI: 00:10.2 20 <- [0x0000001840 - 0x000000185f] io
PCI: 00:10.3 10 <- [0x00febff000 - 0x00febff0ff] mem
PNP: 002e.0 60 <- [0x00000003f0 - 0x00000003f7] io
PNP: 002e.0 70 <- [0x0000000006 - 0x0000000006] irq
PNP: 002e.0 74 <- [0x0000000002 - 0x0000000002] drq
PNP: 002e.1 60 <- [0x0000000378 - 0x000000037f] io
PNP: 002e.1 70 <- [0x0000000007 - 0x0000000007] irq
PNP: 002e.1 74 <- [0x0000000003 - 0x0000000003] drq
PNP: 002e.2 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.2 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.3 60 <- [0x00000002f8 - 0x00000002ff] io
PNP: 002e.3 70 <- [0x0000000003 - 0x0000000003] irq
PNP: 002e.b 60 <- [0x000000ec00 - 0x000000ecff] io
PCI: 00:11.1 20 <- [0x0000001860 - 0x000000186f] io
PCI: 00:11.5 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:12.0 10 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:12.0 14 <- [0x00fec00000 - 0x00fec000ff] mem
Done setting resources.
Done allocating resources.
Enabling resourcess...
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 bridge ctrl <- 000f
PCI: 00:01.0 cmd <- 147
PCI: 01:00.0 cmd <- 140
PCI: 00:10.0 subsystem <- 00/00
PCI: 00:10.0 cmd <- 141
PCI: 00:10.1 subsystem <- 00/00
PCI: 00:10.1 cmd <- 141
PCI: 00:10.2 subsystem <- 00/00
PCI: 00:10.2 cmd <- 141
PCI: 00:10.3 subsystem <- 00/00
PCI: 00:10.3 cmd <- 142
PCI: 00:11.0 cmd <- 147
PNP: 002e.0 - enabling
PNP: 002e.1 - enabling
PNP: 002e.2 - enabling
PNP: 002e.3 - enabling
PNP: 002e.b - enabling
PCI: 00:11.1 cmd <- 147
PCI: 00:11.5 subsystem <- 00/00
PCI: 00:11.5 cmd <- 141
PCI: 00:12.0 cmd <- 1c3
done.
Initializing devices...
Root Device init
PCI: 00:10.0 init
PCI: 00:10.1 init
PCI: 00:10.2 init
PCI: 00:10.3 init
PCI: 00:11.0 init
vt8235 init
RTC Init
Invalid CMOS LB checksum
pci_routing_fixup: dev is 00011040
setting firewire
setting usb
Assigning IRQ 5 to 0:10.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.1
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:10.2
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 5 to 0:10.3
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vt8235
Assigning IRQ 5 to 0:11.1
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
Assigning IRQ 9 to 0:11.5
  Readback = 9
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting ethernet
Assigning IRQ 5 to 0:12.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting vga
Assigning IRQ 5 to 1:0.0
  Readback = 5
pci_level_irq: lower order bits are wrong: want 0x0, got 0x20
setting pci slot
setting cardbus slot
setting riser slot
PNP: 002e.0 init
PNP: 002e.1 init
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.b init
PCI: 00:11.1 init
Enabling VIA IDE.
ide_init: enabling compatibility IDE addresses
enables in reg 0x42 0x0
enables in reg 0x42 read back as 0x0
enables in reg 0x40 0x13
enables in reg 0x40 read back as 0x13
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
PCI: 00:11.5 init
PCI: 00:12.0 init
Configuring VIA Rhine LAN
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor Centaur device 698
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  256MB, type WB
Setting variable MTRR 1, base:  256MB, range:  128MB, type WB
Setting variable MTRR 2, base:  384MB, range:   64MB, type WB
Setting variable MTRR 3, base:  448MB, range:   32MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Disabling local apic...done.
CPU #0 Initialized
PCI: 00:00.0 init
VT8623 random fixup ...
Frame buffer at d0000000
PCI: 00:01.0 init
VT8623 AGP random fixup ...
PCI: 01:00.0 init
VGA random fixup ...
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1106, did=3122
rom base, size: fffc0000
write_protect_vgabios
bus/devfn = 0x100
biosint: # 0x6, eax 0x5f53 ebx 0x101 ecx 0x19f88 edx 0xe093
biosint: ebp 0x19090 esp 0x39d8 edi 0xfa90 esi 0x1a539
biosint: ip 0xc763 cs 0xf000 flags 0x202
biosint: Oops, exception 6
biosint: Bailing out
biosint: # 0x10, eax 0x4f14 ebx 0x18003 ecx 0x1 edx 0x0
biosint: ebp 0x19fa8 esp 0xffa edi 0x0 esi 0xffff725e
biosint: ip 0x8f7e cs 0x0 flags 0x46
BIOSINT: Unsupport int #0x10
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
done.
ACPI: Writing ACPI tables at f0400...
ACPI:     * FACS
ACPI:     * DSDT @ 000f049e Length 3f0
ACPI:     * FADT
ACPI: added table 1/5 Length now 40
ACPI: done.
Moving GDT to 0x500...ok
Wrote linuxbios table at: 00000530 - 00000b5c  checksum bcdc

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

    33:stream_init() - rom_stream: 0xfffd0000 - 0xfffeffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x23fc0 offset 0xc0 filesize 0x9f48
(cleaned up) New segment addr 0x100000 size 0x23fc0 offset 0xc0 filesize 0x9f48
New segment addr 0x123fc0 size 0x48 offset 0xa020 filesize 0x48
(cleaned up) New segment addr 0x123fc0 size 0x48 offset 0xa020 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000023fc0 filesz: 0x0000000000009f48
Clearing Segment: addr: 0x0000000000109f48 memsz: 0x000000000001a078
Loading Segment: addr: 0x0000000000123fc0 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x107c80
FILO version 0.4.2 (pada at vranx) Mon Jan 23 10:46:07 CET 2006
boot: hda1:/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,115200
hda: LBA 6499MB: IBM-DHEA-36481                          
hdb: ATAPI: TOSHIBA CD-ROM XM-6602B                 
Mounted ext2fs
Found Linux version 2.6.14.2static (pada at vranx) #3 Thu Jan 26 12:43:13 CET 2006 bzImage.
Loading kernel... ok
Jumping to entry point...
Linux version 2.6.14.2static (pada at vranx) (gcc-Version 3.3.5 (Debian 1:3.3.5-13)) #3 Thu Jan 26 12:43:13 CET 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000ba4 - 00000000000a0000 (usable)
 BIOS-e820: 0000000000100000 - 000000001e000000 (usable)
480MB LOWMEM available.
DMI not present.
ACPI: PM-Timer IO Port: 0x408
Allocating PCI resources starting at 20000000 (gap: 1e000000:e2000000)
Built 1 zonelists
Kernel command line: root=/dev/hda1 console=tty0 console=ttyS0,115200
No local APIC present or hardware disabled
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 666.401 MHz processor.
Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 480144k/491520k available (4492k kernel code, 10892k reserved, 1495k data, 248k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1334.55 BogoMIPS (lpj=2669102)
Mount-cache hash table entries: 512
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
mtrr: v2.0 (20020519)
CPU: Centaur VIA Nehemiah stepping 08
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0020 (from 0220)
NET: Registered protocol family 16
ACPI: bus type pci registered
Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c00fa955
*pde = 00000000
Oops: 0000 [#1]
CPU:    0
EIP:    0060:[<c00fa955>]    Not tainted VLI
EFLAGS: 00010046   (2.6.14.2static) 
EIP is at 0xc00fa955
eax: 49435000   ebx: 000f0000   ecx: 0400d5b4   edx: 0000a960
esi: 00000000   edi: c0675d64   ebp: 49435024   esp: c149ff32
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 1, threadinfo=c149e000 task=c144aa50)
Stack: 54ba0046 0060c044 00010000 1b080000 000ac073 02960000 42db0000 a4a0c012 
       0000c00f 00000000 00000000 553f0000 5024c044 674e4943 4f6ac010 f240c010 
       0000c00e 00000000 00000000 00000000 00000000 00000000 007b0000 a4a00000 
Call Trace:
Code: 00 00 32 c0 66 9d cb 3d 24 50 43 49 77 17 0a db 75 17 bb 00 00 0f 00 ba 60 a9 00 00 b9 b4 d5 00 04 32 c0 eb 06 b0 80 eb 02 b0 81 <6e> 9d cb 87 db 87 db 87 db 87 db 66 9c fa 3c 01 75 0a e8 9c 00 
 <0>Kernel panic - not syncing: Attempted to kill init!

Thanks for any help,
Daniel



From pdegler at rumms.uni-mannheim.de  Tue Jan 31 15:32:13 2006
From: pdegler at rumms.uni-mannheim.de (Philipp Degler)
Date: Tue, 31 Jan 2006 15:32:13 +0100
Subject: [LinuxBIOS] IWILL DK8-HTX
Message-ID: <1138717933.12044.24.camel@localhost>

Hi greg,

coming back on your thread-entry. We would like to get the 
IWILL DK8-HTX Rev. 1.0 running. Is it possible to use devbios 
or mtd to access the bios or is the hardware flash programmer
the only possible (better) way?

The board uses an AMIbios, SVR 2000, AA46 (6827) with the following
layout:

		(x7)

	  ,  ,  ,  ,  ,  ,  ,
	-		     -
	-		     -
	-		     -
	-		     -
	-		     -    (x9)
	-		     -
	-		     -
	-		     -
	-		     -
	  ,  ,  ,  ,  ,  ,  ,

What hardware flash programmer would you suggest to get started?


thx a lot 

-- phil
 

On Fri, Dec 09, 2005 at 08:24:34AM -0600, Young, Jeff wrote:
> 
> > 	I see that the Iwill board dk82s is supported?  Does anyone know
> > if the dk8-hkt board will work?  It
> > is interesting because it has an HTK connector on it.
> 
> Do you mean the DK8-HTX ? If so, we ran LinuxBios during initial
> bring-up of this board, and I believe we contributed back the changes
> we needed for it.
> 
> 
> -- greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060131/ecc7b512/attachment.sig>

From stuge-linuxbios at cdy.org  Tue Jan 31 12:12:31 2006
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 31 Jan 2006 12:12:31 +0100
Subject: [LinuxBIOS] IWILL DK8-HTX
In-Reply-To: <1138717933.12044.24.camel@localhost>
References: <1138717933.12044.24.camel@localhost>
Message-ID: <20060131111231.11786.qmail@cdy.org>

On Tue, Jan 31, 2006 at 03:32:13PM +0100, Philipp Degler wrote:
> The board uses an AMIbios, SVR 2000, AA46 (6827) with the following
> layout:
> 
> 		(x7)
> 
> 	  ,  ,  ,  ,  ,  ,  ,
> 	-		     -
> 	-		     -
> 	-		     -
> 	-		     -
> 	-		     -    (x9)
> 	-		     -
> 	-		     -
> 	-		     -
> 	-		     -
> 	  ,  ,  ,  ,  ,  ,  ,
> 
> What hardware flash programmer would you suggest to get started?

To give reliable advice it would be good to know the flash part
number of this PLCC32 chip. Try gently peeling off the AMIbios
sticker to see a logo and model number on the black plastic part
itself.


//Peter



From stepan at openbios.org  Tue Jan 31 12:13:02 2006
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 31 Jan 2006 12:13:02 +0100
Subject: [LinuxBIOS] IWILL DK8-HTX
In-Reply-To: <1138717933.12044.24.camel@localhost>
References: <1138717933.12044.24.camel@localhost>
Message-ID: <20060131111302.GA16240@openbios.org>

* Philipp Degler <pdegler at rumms.uni-mannheim.de> [060131 15:32]:
> coming back on your thread-entry. We would like to get the 
> IWILL DK8-HTX Rev. 1.0 running. Is it possible to use devbios 
> or mtd to access the bios or is the hardware flash programmer
> the only possible (better) way?

Is your bios chip in a socket, ie. can it be removed with a chip gripper?

Use flashbios from the LinuxBIOS source tree (util/...) 

devbios is obsolete, I will put further development into flashbios
instead.

> The board uses an AMIbios, SVR 2000, AA46 (6827) with the following
> layout:

[..] 

> What hardware flash programmer would you suggest to get started?

You might find the bios savior useful. Generally most hw flash
programmers are pretty expensive if they're supposed to work for more
than a chip type.

You need to find out what flash chip you have (ie. look at the ID
beneath the AMI sticker. It's probably an SST49LF040)

Cheapest and quickest solution is to get a backup chip and and exchange
the AMI chip after booting the system to burn the new one. 

Stefan





From smithbone at gmail.com  Tue Jan 31 15:03:22 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 31 Jan 2006 08:03:22 -0600
Subject: [LinuxBIOS] VIA EPIA-ML6000EA VGA Problem and Kernel Panic
In-Reply-To: <20060130133200.GA11842@daniel.localdomain>
References: <20060130133200.GA11842@daniel.localdomain>
Message-ID: <8a0c36780601310603t238db095h2cbc63e44b67e66f@mail.gmail.com>

On 1/30/06, Daniel Parthey <pada at chemonline.de> wrote:
> Dear List Members,
>
> I tried to get LinuxBIOS Rev 2163 running on an VIA EPIA-ML6000EA Board
> using the EPIA-M target. The kernel is on /dev/hda1 of an IDE harddisk.

Daniel,

I'm swamped this week or I'd try to help you further.  The ML has some
issues.  Search the archives starting from December around Xmas time. 
There is a series of exchanges between myself and Christian S?hs.  He
has the ML on his board and he has it up and going with X even.

Christian,  can you whip up a patch for your changes vs the tree and post them?

--
Richard A. Smith

From rminnich at lanl.gov  Tue Jan 31 16:06:44 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 31 Jan 2006 08:06:44 -0700
Subject: [LinuxBIOS] IWILL DK8-HTX
In-Reply-To: <1138717933.12044.24.camel@localhost>
References: <1138717933.12044.24.camel@localhost>
Message-ID: <43DF7D04.8080200@lanl.gov>

to start, for a test, get linuxbios v2 on your node, build flashrom, and 
run it with no arguments. If it prints out the flash type, you're in 
pretty good shape to start.

ron



From rminnich at lanl.gov  Tue Jan 31 16:07:36 2006
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 31 Jan 2006 08:07:36 -0700
Subject: [LinuxBIOS] IWILL DK8-HTX
In-Reply-To: <20060131111231.11786.qmail@cdy.org>
References: <1138717933.12044.24.camel@localhost>
	<20060131111231.11786.qmail@cdy.org>
Message-ID: <43DF7D38.20006@lanl.gov>

Peter Stuge wrote:

> To give reliable advice it would be good to know the flash part
> number of this PLCC32 chip. Try gently peeling off the AMIbios
> sticker to see a logo and model number on the black plastic part
> itself.

we generally use those holographic bios labels for more picturesque 
uses, such as those electronic valves you see on toilets nowadays. Looks 
nice.

ron



From smithbone at gmail.com  Tue Jan 31 18:50:08 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 31 Jan 2006 12:50:08 -0500
Subject: [LinuxBIOS] Fwd: [Linux-fbdev-devel] [patch] Framebuffer driver for
	Geode GX
In-Reply-To: <43DF9C09.30806@arcom.com>
References: <43DF9C09.30806@arcom.com>
Message-ID: <8a0c36780601310950i406fe747rdb3cfb1ca0ef5dc6@mail.gmail.com>

This may be of interest to some people working with the Geode GX

---------- Forwarded message ----------
From: David Vrabel <dvrabel at arcom.com>
Date: Jan 31, 2006 12:19 PM
Subject: [Linux-fbdev-devel] [patch] Framebuffer driver for Geode GX
To: linux-fbdev-devel list <linux-fbdev-devel at lists.sourceforge.net>


A framebuffer driver for the display controller in AMD Geode GX
processors (Geode GX533, Geode GX500 etc.).  Tested at 640x480, 800x600,
1024x768 and 1280x1024 at 8, 16, and 24 bpp with both CRT and TFT.  No
accelerated features currently implemented and compression remains disabled.

This driver requires that the BIOS (or the SoftVG/Firmbase code in the
BIOS) has created an appropriate virtual PCI header.

Signed-off-by: David Vrabel <dvrabel at arcom.com>
--
David Vrabel, Design Engineer

Arcom, Clifton Road           Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK         Web: http://www.arcom.com/


Index: linux-2.6-working/drivers/video/geode/Kconfig
===================================================================
--- linux-2.6-working.orig/drivers/video/geode/Kconfig  2006-01-31
16:59:20.000000000 +0000
+++ linux-2.6-working/drivers/video/geode/Kconfig       2006-01-31
16:59:51.000000000 +0000
@@ -8,6 +8,21 @@
          Say 'Y' here to allow you to select framebuffer drivers for
          the AMD Geode family of processors.

+config FB_GEODE_GX
+       tristate "AMD Geode GX framebuffer support (EXPERIMENTAL)"
+       depends on FB_GEODE && EXPERIMENTAL
+       select FB_CFB_FILLRECT
+       select FB_CFB_COPYAREA
+       select FB_CFB_IMAGEBLIT
+       ---help---
+         Framebuffer driver for the display controller integrated into the
+         AMD Geode GX processors.
+
+         To compile this driver as a module, choose M here: the module will be
+         called gxfb.
+
+         If unsure, say N.
+
 config FB_GEODE_GX1
        tristate "AMD Geode GX1 framebuffer support (EXPERIMENTAL)"
        depends on FB_GEODE && EXPERIMENTAL
Index: linux-2.6-working/drivers/video/geode/Makefile
===================================================================
--- linux-2.6-working.orig/drivers/video/geode/Makefile 2006-01-31
16:59:20.000000000 +0000
+++ linux-2.6-working/drivers/video/geode/Makefile      2006-01-31
16:59:51.000000000 +0000
@@ -1,5 +1,7 @@
 # Makefile for the Geode family framebuffer drivers

 obj-$(CONFIG_FB_GEODE_GX1) += gx1fb.o
+obj-$(CONFIG_FB_GEODE_GX)  += gxfb.o

-gx1fb-objs             := gx1fb_core.o display_gx1.o video_cs5530.o
+gx1fb-objs := gx1fb_core.o display_gx1.o video_cs5530.o
+gxfb-objs  := gxfb_core.o display_gx.o video_gx.o
Index: linux-2.6-working/drivers/video/geode/display_gx.c
===================================================================
--- /dev/null   1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-working/drivers/video/geode/display_gx.c  2006-01-31
16:59:51.000000000 +0000
@@ -0,0 +1,156 @@
+/*
+ * Geode GX display controller.
+ *
+ *   Copyright (C) 2005 Arcom Control Systems Ltd.
+ *
+ *   Portions from AMD's original 2.4 driver:
+ *     Copyright (C) 2004 Advanced Micro Devices, Inc.
+ *
+ *   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.
+ */
+#include <linux/spinlock.h>
+#include <linux/fb.h>
+#include <linux/delay.h>
+#include <asm/io.h>
+#include <asm/div64.h>
+#include <asm/delay.h>
+
+#include "geodefb.h"
+#include "display_gx.h"
+
+int gx_frame_buffer_size(void)
+{
+       /* Assuming 16 MiB. */
+       return 16*1024*1024;
+}
+
+int gx_line_delta(int xres, int bpp)
+{
+       /* Must be a multiple of 8 bytes. */
+       return (xres * (bpp >> 3) + 7) & ~0x7;
+}
+
+static void gx_set_mode(struct fb_info *info)
+{
+       struct geodefb_par *par = info->par;
+       u32 gcfg, dcfg;
+       int hactive, hblankstart, hsyncstart, hsyncend, hblankend, htotal;
+       int vactive, vblankstart, vsyncstart, vsyncend, vblankend, vtotal;
+
+       /* Unlock the display controller registers. */
+       readl(par->dc_regs + DC_UNLOCK);
+       writel(DC_UNLOCK_CODE, par->dc_regs + DC_UNLOCK);
+
+       gcfg = readl(par->dc_regs + DC_GENERAL_CFG);
+       dcfg = readl(par->dc_regs + DC_DISPLAY_CFG);
+
+       /* Disable the timing generator. */
+       dcfg &= ~(DC_DCFG_TGEN);
+       writel(dcfg, par->dc_regs + DC_DISPLAY_CFG);
+
+       /* Wait for pending memory requests before disabling the FIFO load. */
+       udelay(100);
+
+       /* Disable FIFO load and compression. */
+       gcfg &= ~(DC_GCFG_DFLE | DC_GCFG_CMPE | DC_GCFG_DECE);
+       writel(gcfg, par->dc_regs + DC_GENERAL_CFG);
+
+       /* Setup DCLK and its divisor. */
+       par->vid_ops->set_dclk(info);
+
+       /*
+        * Setup new mode.
+        */
+
+       /* Clear all unused feature bits. */
+       gcfg &= DC_GCFG_YUVM | DC_GCFG_VDSE;
+       dcfg = 0;
+
+       /* Set FIFO priority (default 6/5) and enable. */
+       /* FIXME: increase fifo priority for 1280x1024 and higher modes? */
+       gcfg |= (6 << DC_GCFG_DFHPEL_POS) | (5 << DC_GCFG_DFHPSL_POS)
| DC_GCFG_DFLE;
+
+       /* Framebuffer start offset. */
+       writel(0, par->dc_regs + DC_FB_ST_OFFSET);
+
+       /* Line delta and line buffer length. */
+       writel(info->fix.line_length >> 3, par->dc_regs + DC_GFX_PITCH);
+       writel(((info->var.xres * info->var.bits_per_pixel/8) >> 3) + 2,
+              par->dc_regs + DC_LINE_SIZE);
+
+       /* Enable graphics and video data and unmask address lines. */
+       dcfg |= DC_DCFG_GDEN | DC_DCFG_VDEN | DC_DCFG_A20M | DC_DCFG_A18M;
+
+       /* Set pixel format. */
+       switch (info->var.bits_per_pixel) {
+       case 8:
+               dcfg |= DC_DCFG_DISP_MODE_8BPP;
+               break;
+       case 16:
+               dcfg |= DC_DCFG_DISP_MODE_16BPP;
+               dcfg |= DC_DCFG_16BPP_MODE_565;
+               break;
+       case 32:
+               dcfg |= DC_DCFG_DISP_MODE_24BPP;
+               dcfg |= DC_DCFG_PALB;
+               break;
+       }
+
+       /* Enable timing generator. */
+       dcfg |= DC_DCFG_TGEN;
+
+       /* Horizontal and vertical timings. */
+       hactive = info->var.xres;
+       hblankstart = hactive;
+       hsyncstart = hblankstart + info->var.right_margin;
+       hsyncend =  hsyncstart + info->var.hsync_len;
+       hblankend = hsyncend + info->var.left_margin;
+       htotal = hblankend;
+
+       vactive = info->var.yres;
+       vblankstart = vactive;
+       vsyncstart = vblankstart + info->var.lower_margin;
+       vsyncend =  vsyncstart + info->var.vsync_len;
+       vblankend = vsyncend + info->var.upper_margin;
+       vtotal = vblankend;
+
+       writel((hactive - 1)     | ((htotal - 1) << 16),   
par->dc_regs + DC_H_ACTIVE_TIMING);
+       writel((hblankstart - 1) | ((hblankend - 1) << 16),
par->dc_regs + DC_H_BLANK_TIMING);
+       writel((hsyncstart - 1)  | ((hsyncend - 1) << 16), 
par->dc_regs + DC_H_SYNC_TIMING);
+
+       writel((vactive - 1)     | ((vtotal - 1) << 16),   
par->dc_regs + DC_V_ACTIVE_TIMING);
+       writel((vblankstart - 1) | ((vblankend - 1) << 16),
par->dc_regs + DC_V_BLANK_TIMING);
+       writel((vsyncstart - 1)  | ((vsyncend - 1) << 16), 
par->dc_regs + DC_V_SYNC_TIMING);
+
+       /* Write final register values. */
+       writel(dcfg, par->dc_regs + DC_DISPLAY_CFG);
+       writel(gcfg, par->dc_regs + DC_GENERAL_CFG);
+
+       par->vid_ops->configure_display(info);
+
+       /* Relock display controller registers */
+       writel(0, par->dc_regs + DC_UNLOCK);
+}
+
+static void gx_set_hw_palette_reg(struct fb_info *info, unsigned regno,
+                                  unsigned red, unsigned green, unsigned blue)
+{
+       struct geodefb_par *par = info->par;
+       int val;
+
+       /* Hardware palette is in RGB 8-8-8 format. */
+       val  = (red   << 8) & 0xff0000;
+       val |= (green)      & 0x00ff00;
+       val |= (blue  >> 8) & 0x0000ff;
+
+       writel(regno, par->dc_regs + DC_PAL_ADDRESS);
+       writel(val, par->dc_regs + DC_PAL_DATA);
+}
+
+struct geode_dc_ops gx_dc_ops = {
+       .set_mode        = gx_set_mode,
+       .set_palette_reg = gx_set_hw_palette_reg,
+};
Index: linux-2.6-working/drivers/video/geode/display_gx.h
===================================================================
--- /dev/null   1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-working/drivers/video/geode/display_gx.h  2006-01-31
16:59:51.000000000 +0000
@@ -0,0 +1,96 @@
+/*
+ * Geode GX display controller
+ *
+ * Copyright (C) 2006 Arcom Control Systems Ltd.
+ *
+ * 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.
+ */
+#ifndef __DISPLAY_GX_H__
+#define __DISPLAY_GX_H__
+
+int gx_frame_buffer_size(void);
+int gx_line_delta(int xres, int bpp);
+
+extern struct geode_dc_ops gx_dc_ops;
+
+/* Display controller registers */
+
+#define DC_UNLOCK 0x00
+#  define DC_UNLOCK_CODE 0x00004758
+
+#define DC_GENERAL_CFG 0x04
+#  define DC_GCFG_DFLE       0x00000001
+#  define DC_GCFG_CURE       0x00000002
+#  define DC_GCFG_ICNE       0x00000004
+#  define DC_GCFG_VIDE       0x00000008
+#  define DC_GCFG_CMPE       0x00000020
+#  define DC_GCFG_DECE       0x00000040
+#  define DC_GCFG_VGAE       0x00000080
+#  define DC_GCFG_DFHPSL_MASK 0x00000F00
+#  define DC_GCFG_DFHPSL_POS          8
+#  define DC_GCFG_DFHPEL_MASK 0x0000F000
+#  define DC_GCFG_DFHPEL_POS         12
+#  define DC_GCFG_STFM       0x00010000
+#  define DC_GCFG_FDTY       0x00020000
+#  define DC_GCFG_VGAFT              0x00040000
+#  define DC_GCFG_VDSE       0x00080000
+#  define DC_GCFG_YUVM       0x00100000
+#  define DC_GCFG_VFSL       0x00800000
+#  define DC_GCFG_SIGE       0x01000000
+#  define DC_GCFG_SGRE       0x02000000
+#  define DC_GCFG_SGFR       0x04000000
+#  define DC_GCFG_CRC_MODE    0x08000000
+#  define DC_GCFG_DIAG       0x10000000
+#  define DC_GCFG_CFRW       0x20000000
+
+#define DC_DISPLAY_CFG 0x08
+#  define DC_DCFG_TGEN            0x00000001
+#  define DC_DCFG_GDEN            0x00000008
+#  define DC_DCFG_VDEN            0x00000010
+#  define DC_DCFG_TRUP            0x00000040
+#  define DC_DCFG_DISP_MODE_MASK  0x00000300
+#  define DC_DCFG_DISP_MODE_8BPP  0x00000000
+#  define DC_DCFG_DISP_MODE_16BPP 0x00000100
+#  define DC_DCFG_DISP_MODE_24BPP 0x00000200
+#  define DC_DCFG_16BPP_MODE_MASK 0x00000c00
+#  define DC_DCFG_16BPP_MODE_565  0x00000000
+#  define DC_DCFG_16BPP_MODE_555  0x00000100
+#  define DC_DCFG_16BPP_MODE_444  0x00000200
+#  define DC_DCFG_DCEN            0x00080000
+#  define DC_DCFG_PALB            0x02000000
+#  define DC_DCFG_FRLK            0x04000000
+#  define DC_DCFG_VISL            0x08000000
+#  define DC_DCFG_FRSL            0x20000000
+#  define DC_DCFG_A18M            0x40000000
+#  define DC_DCFG_A20M            0x80000000
+
+#define DC_FB_ST_OFFSET 0x10
+
+#define DC_LINE_SIZE 0x30
+#  define DC_LINE_SIZE_FB_LINE_SIZE_MASK  0x000007ff
+#  define DC_LINE_SIZE_FB_LINE_SIZE_POS            0
+#  define DC_LINE_SIZE_CB_LINE_SIZE_MASK  0x007f0000
+#  define DC_LINE_SIZE_CB_LINE_SIZE_POS           16
+#  define DC_LINE_SIZE_VID_LINE_SIZE_MASK 0xff000000
+#  define DC_LINE_SIZE_VID_LINE_SIZE_POS          24
+
+#define DC_GFX_PITCH 0x34
+#  define DC_GFX_PITCH_FB_PITCH_MASK 0x0000ffff
+#  define DC_GFX_PITCH_FB_PITCH_POS           0
+#  define DC_GFX_PITCH_CB_PITCH_MASK 0xffff0000
+#  define DC_GFX_PITCH_CB_PITCH_POS          16
+
+#define DC_H_ACTIVE_TIMING 0x40
+#define DC_H_BLANK_TIMING  0x44
+#define DC_H_SYNC_TIMING   0x48
+#define DC_V_ACTIVE_TIMING 0x50
+#define DC_V_BLANK_TIMING  0x54
+#define DC_V_SYNC_TIMING   0x58
+
+#define DC_PAL_ADDRESS 0x70
+#define DC_PAL_DATA    0x74
+
+#endif /* !__DISPLAY_GX1_H__ */
Index: linux-2.6-working/drivers/video/geode/gxfb_core.c
===================================================================
--- /dev/null   1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-working/drivers/video/geode/gxfb_core.c   2006-01-31
17:00:19.000000000 +0000
@@ -0,0 +1,423 @@
+/*
+ * Geode GX framebuffer driver.
+ *
+ *   Copyright (C) 2006 Arcom Control Systems Ltd.
+ *
+ *   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 driver assumes that the BIOS has created a virtual PCI device header
+ * for the video device. The PCI header is assumed to contain the following
+ * BARs:
+ *
+ *    BAR0 - framebuffer memory
+ *    BAR1 - graphics processor registers
+ *    BAR2 - display controller registers
+ *    BAR3 - video processor and flat panel control registers.
+ *
+ * 16 MiB of framebuffer memory is assumed to be available.
+ */
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/mm.h>
+#include <linux/tty.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+#include <linux/fb.h>
+#include <linux/init.h>
+#include <linux/pci.h>
+
+#include "geodefb.h"
+#include "display_gx.h"
+#include "video_gx.h"
+
+static char mode_option[32] = "640x480-16 at 60";
+
+/* Modes relevant to the GX (taken from modedb.c) */
+static const struct fb_videomode __initdata gx_modedb[] = {
+       /* 640x480-60 VESA */
+       { NULL, 60, 640, 480, 39682,  48, 16, 33, 10, 96, 2,
+         0, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 640x480-75 VESA */
+       { NULL, 75, 640, 480, 31746, 120, 16, 16, 01, 64, 3,
+         0, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 640x480-85 VESA */
+       { NULL, 85, 640, 480, 27777, 80, 56, 25, 01, 56, 3,
+         0, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 800x600-60 VESA */
+       { NULL, 60, 800, 600, 25000, 88, 40, 23, 01, 128, 4,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 800x600-75 VESA */
+       { NULL, 75, 800, 600, 20202, 160, 16, 21, 01, 80, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 800x600-85 VESA */
+       { NULL, 85, 800, 600, 17761, 152, 32, 27, 01, 64, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1024x768-60 VESA */
+       { NULL, 60, 1024, 768, 15384, 160, 24, 29, 3, 136, 6,
+         0, FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1024x768-75 VESA */
+       { NULL, 75, 1024, 768, 12690, 176, 16, 28, 1, 96, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1024x768-85 VESA */
+       { NULL, 85, 1024, 768, 10582, 208, 48, 36, 1, 96, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1280x960-60 VESA */
+       { NULL, 60, 1280, 960, 9259, 312, 96, 36, 1, 112, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1280x960-85 VESA */
+       { NULL, 85, 1280, 960, 6734, 224, 64, 47, 1, 160, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1280x1024-60 VESA */
+       { NULL, 60, 1280, 1024, 9259, 248, 48, 38, 1, 112, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1280x1024-75 VESA */
+       { NULL, 75, 1280, 1024, 7407, 248, 16, 38, 1, 144, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1280x1024-85 VESA */
+       { NULL, 85, 1280, 1024, 6349, 224, 64, 44, 1, 160, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1600x1200-60 VESA */
+       { NULL, 60, 1600, 1200, 6172, 304, 64, 46, 1, 192, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1600x1200-75 VESA */
+       { NULL, 75, 1600, 1200, 4938, 304, 64, 46, 1, 192, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+       /* 1600x1200-85 VESA */
+       { NULL, 85, 1600, 1200, 4357, 304, 64, 46, 1, 192, 3,
+         FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT,
+         FB_VMODE_NONINTERLACED, FB_MODE_IS_VESA },
+};
+
+static int gxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+       if (var->xres > 1600 || var->yres > 1200)
+               return -EINVAL;
+       if ((var->xres > 1280 || var->yres > 1024) && var->bits_per_pixel > 16)
+               return -EINVAL;
+
+       if (var->bits_per_pixel == 32) {
+               var->red.offset   = 16; var->red.length   = 8;
+               var->green.offset =  8; var->green.length = 8;
+               var->blue.offset  =  0; var->blue.length  = 8;
+       } else if (var->bits_per_pixel == 16) {
+               var->red.offset   = 11; var->red.length   = 5;
+               var->green.offset =  5; var->green.length = 6;
+               var->blue.offset  =  0; var->blue.length  = 5;
+       } else if (var->bits_per_pixel == 8) {
+               var->red.offset   = 0; var->red.length   = 8;
+               var->green.offset = 0; var->green.length = 8;
+               var->blue.offset  = 0; var->blue.length  = 8;
+       } else
+               return -EINVAL;
+       var->transp.offset = 0; var->transp.length = 0;
+
+       /* Enough video memory? */
+       if (gx_line_delta(var->xres, var->bits_per_pixel) * var->yres
> info->fix.smem_len)
+               return -EINVAL;
+
+       /* FIXME: Check timing parameters here? */
+
+       return 0;
+}
+
+static int gxfb_set_par(struct fb_info *info)
+{
+       struct geodefb_par *par = info->par;
+
+       if (info->var.bits_per_pixel > 8) {
+               info->fix.visual = FB_VISUAL_TRUECOLOR;
+               fb_dealloc_cmap(&info->cmap);
+       } else {
+               info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
+               fb_alloc_cmap(&info->cmap, 1<<info->var.bits_per_pixel, 0);
+       }
+
+       info->fix.line_length = gx_line_delta(info->var.xres,
info->var.bits_per_pixel);
+
+       par->dc_ops->set_mode(info);
+
+       return 0;
+}
+
+static inline u_int chan_to_field(u_int chan, struct fb_bitfield *bf)
+{
+       chan &= 0xffff;
+       chan >>= 16 - bf->length;
+       return chan << bf->offset;
+}
+
+static int gxfb_setcolreg(unsigned regno, unsigned red, unsigned green,
+                          unsigned blue, unsigned transp,
+                          struct fb_info *info)
+{
+       struct geodefb_par *par = info->par;
+
+       if (info->var.grayscale) {
+               /* grayscale = 0.30*R + 0.59*G + 0.11*B */
+               red = green = blue = (red * 77 + green * 151 + blue * 28) >> 8;
+       }
+
+       /* Truecolor has hardware independent palette */
+       if (info->fix.visual == FB_VISUAL_TRUECOLOR) {
+               u32 *pal = info->pseudo_palette;
+               u32 v;
+
+               if (regno >= 16)
+                       return -EINVAL;
+
+               v  = chan_to_field(red, &info->var.red);
+               v |= chan_to_field(green, &info->var.green);
+               v |= chan_to_field(blue, &info->var.blue);
+
+               pal[regno] = v;
+       } else {
+               if (regno >= 256)
+                       return -EINVAL;
+
+               par->dc_ops->set_palette_reg(info, regno, red, green, blue);
+       }
+
+       return 0;
+}
+
+static int gxfb_blank(int blank_mode, struct fb_info *info)
+{
+       struct geodefb_par *par = info->par;
+
+       return par->vid_ops->blank_display(info, blank_mode);
+}
+
+static int __init gxfb_map_video_memory(struct fb_info *info, struct
pci_dev *dev)
+{
+       struct geodefb_par *par = info->par;
+       int fb_len;
+       int ret;
+
+       ret = pci_enable_device(dev);
+       if (ret < 0)
+               return ret;
+
+       ret = pci_request_region(dev, 3, "gxfb (video processor)");
+       if (ret < 0)
+               return ret;
+       par->vid_regs = ioremap(pci_resource_start(dev, 3),
+                               pci_resource_len(dev, 3));
+       if (!par->vid_regs)
+               return -ENOMEM;
+
+       ret = pci_request_region(dev, 2, "gxfb (display controller)");
+       if (ret < 0)
+               return ret;
+       par->dc_regs = ioremap(pci_resource_start(dev, 2),
pci_resource_len(dev, 2));
+       if (!par->dc_regs)
+               return -ENOMEM;
+
+       ret = pci_request_region(dev, 0, "gxfb (framebuffer)");
+       if (ret < 0)
+               return ret;
+       if ((fb_len = gx_frame_buffer_size()) < 0)
+               return -ENOMEM;
+       info->fix.smem_start = pci_resource_start(dev, 0);
+       info->fix.smem_len = fb_len;
+       info->screen_base = ioremap(info->fix.smem_start, info->fix.smem_len);
+       if (!info->screen_base)
+               return -ENOMEM;
+
+       dev_info(&dev->dev, "%d Kibyte of video memory at 0x%lx\n",
+                info->fix.smem_len / 1024, info->fix.smem_start);
+
+       return 0;
+}
+
+static struct fb_ops gxfb_ops = {
+       .owner          = THIS_MODULE,
+       .fb_check_var   = gxfb_check_var,
+       .fb_set_par     = gxfb_set_par,
+       .fb_setcolreg   = gxfb_setcolreg,
+       .fb_blank       = gxfb_blank,
+       /* No HW acceleration for now. */
+       .fb_fillrect    = cfb_fillrect,
+       .fb_copyarea    = cfb_copyarea,
+       .fb_imageblit   = cfb_imageblit,
+};
+
+static struct fb_info * __init gxfb_init_fbinfo(struct device *dev)
+{
+       struct geodefb_par *par;
+       struct fb_info *info;
+
+       /* Alloc enough space for the pseudo palette. */
+       info = framebuffer_alloc(sizeof(struct geodefb_par) +
sizeof(u32) * 16, dev);
+       if (!info)
+               return NULL;
+
+       par = info->par;
+
+       strcpy(info->fix.id, "Geode GX");
+
+       info->fix.type          = FB_TYPE_PACKED_PIXELS;
+       info->fix.type_aux      = 0;
+       info->fix.xpanstep      = 0;
+       info->fix.ypanstep      = 0;
+       info->fix.ywrapstep     = 0;
+       info->fix.accel         = FB_ACCEL_NONE;
+
+       info->var.nonstd        = 0;
+       info->var.activate      = FB_ACTIVATE_NOW;
+       info->var.height        = -1;
+       info->var.width = -1;
+       info->var.accel_flags = 0;
+       info->var.vmode = FB_VMODE_NONINTERLACED;
+
+       info->fbops             = &gxfb_ops;
+       info->flags             = FBINFO_DEFAULT;
+       info->node              = -1;
+
+       info->pseudo_palette    = (void *)par + sizeof(struct geodefb_par);
+
+       info->var.grayscale     = 0;
+
+       return info;
+}
+
+static int __init gxfb_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
+{
+       struct geodefb_par *par;
+       struct fb_info *info;
+       int ret;
+
+       info = gxfb_init_fbinfo(&pdev->dev);
+       if (!info)
+               return -ENOMEM;
+       par = info->par;
+
+       /* GX display controller and GX video device. */
+       par->dc_ops  = &gx_dc_ops;
+       par->vid_ops = &gx_vid_ops;
+
+       if ((ret = gxfb_map_video_memory(info, pdev)) < 0) {
+               dev_err(&pdev->dev, "failed to map frame buffer or
controller registers\n");
+               goto err;
+       }
+
+       ret = fb_find_mode(&info->var, info, mode_option,
+                          gx_modedb, ARRAY_SIZE(gx_modedb), NULL, 16);
+       if (ret == 0 || ret == 4) {
+               dev_err(&pdev->dev, "could not find valid video mode\n");
+               ret = -EINVAL;
+               goto err;
+       }
+
+        /* Clear the frame buffer of garbage. */
+        memset_io(info->screen_base, 0, info->fix.smem_len);
+
+       gxfb_check_var(&info->var, info);
+       gxfb_set_par(info);
+
+       if (register_framebuffer(info) < 0) {
+               ret = -EINVAL;
+               goto err;
+       }
+       pci_set_drvdata(pdev, info);
+       printk(KERN_INFO "fb%d: %s frame buffer device\n", info->node,
info->fix.id);
+       return 0;
+
+  err:
+       if (info->screen_base) {
+               iounmap(info->screen_base);
+               pci_release_region(pdev, 0);
+       }
+       if (par->vid_regs) {
+               iounmap(par->vid_regs);
+               pci_release_region(pdev, 3);
+       }
+       if (par->dc_regs) {
+               iounmap(par->dc_regs);
+               pci_release_region(pdev, 2);
+       }
+
+       pci_disable_device(pdev);
+
+       if (info)
+               framebuffer_release(info);
+       return ret;
+}
+
+static void gxfb_remove(struct pci_dev *pdev)
+{
+       struct fb_info *info = pci_get_drvdata(pdev);
+       struct geodefb_par *par = info->par;
+
+       unregister_framebuffer(info);
+
+       iounmap((void __iomem *)info->screen_base);
+       pci_release_region(pdev, 0);
+
+       iounmap(par->vid_regs);
+       pci_release_region(pdev, 3);
+
+       iounmap(par->dc_regs);
+       pci_release_region(pdev, 2);
+
+       pci_disable_device(pdev);
+       pci_set_drvdata(pdev, NULL);
+
+       framebuffer_release(info);
+}
+
+static struct pci_device_id gxfb_id_table[] = {
+       { PCI_VENDOR_ID_NS, PCI_DEVICE_ID_NS_CS5535_VIDEO,
+         PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY << 16,
+         0xff0000, 0 },
+       { 0, }
+};
+
+MODULE_DEVICE_TABLE(pci, gxfb_id_table);
+
+static struct pci_driver gxfb_driver = {
+       .name           = "gxfb",
+       .id_table       = gxfb_id_table,
+       .probe          = gxfb_probe,
+       .remove         = gxfb_remove,
+};
+
+static int __init gxfb_init(void)
+{
+#ifndef MODULE
+       if (fb_get_options("gxfb", NULL))
+               return -ENODEV;
+#endif
+       return pci_register_driver(&gxfb_driver);
+}
+
+static void __exit gxfb_cleanup(void)
+{
+       pci_unregister_driver(&gxfb_driver);
+}
+
+module_init(gxfb_init);
+module_exit(gxfb_cleanup);
+
+module_param_string(mode, mode_option, sizeof(mode_option), 0444);
+MODULE_PARM_DESC(mode, "video mode (<x>x<y>[-<bpp>][@<refr>])");
+
+MODULE_DESCRIPTION("Framebuffer driver for the AMD Geode GX");
+MODULE_LICENSE("GPL");
Index: linux-2.6-working/drivers/video/geode/video_gx.c
===================================================================
--- /dev/null   1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-working/drivers/video/geode/video_gx.c    2006-01-31
17:00:54.000000000 +0000
@@ -0,0 +1,217 @@
+/*
+ * Geode GX video processor device.
+ *
+ *   Copyright (C) 2006 Arcom Control Systems Ltd.
+ *
+ *   Portions from AMD's original 2.4 driver:
+ *     Copyright (C) 2004 Advanced Micro Devices, Inc.
+ *
+ *   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.
+ */
+#include <linux/fb.h>
+#include <linux/delay.h>
+#include <asm/io.h>
+#include <asm/delay.h>
+#include <asm/msr.h>
+
+#include "geodefb.h"
+#include "video_gx.h"
+
+
+/*
+ * Tables of register settings for various DOTCLKs.
+ */
+struct gx_pll_entry {
+       long pixclock; /* ps */
+       u32 sys_rstpll_bits;
+       u32 dotpll_value;
+};
+
+#define POSTDIV3 ((u32)MSR_GLCP_SYS_RSTPLL_DOTPOSTDIV3)
+#define PREMULT2 ((u32)MSR_GLCP_SYS_RSTPLL_DOTPREMULT2)
+#define PREDIV2  ((u32)MSR_GLCP_SYS_RSTPLL_DOTPOSTDIV3)
+
+struct gx_pll_entry gx_pll_table_48MHz[] = {
+       { 40123, POSTDIV3,          0x00000BF2 },       /*  24.9230 */
+       { 39721, 0,                 0x00000037 },       /*  25.1750 */
+       { 35308, POSTDIV3|PREMULT2, 0x00000B1A },       /*  28.3220 */
+       { 31746, POSTDIV3,          0x000002D2 },       /*  31.5000 */
+       { 27777, POSTDIV3|PREMULT2, 0x00000FE2 },       /*  36.0000 */
+       { 26666, POSTDIV3,          0x0000057A },       /*  37.5000 */
+       { 25000, POSTDIV3,          0x0000030A },       /*  40.0000 */
+       { 22271, 0,                 0x00000063 },       /*  44.9000 */
+       { 20202, 0,                 0x0000054B },       /*  49.5000 */
+       { 20000, 0,                 0x0000026E },       /*  50.0000 */
+       { 19860, PREMULT2,          0x00000037 },       /*  50.3500 */
+       { 18518, POSTDIV3|PREMULT2, 0x00000B0D },       /*  54.0000 */
+       { 17777, 0,                 0x00000577 },       /*  56.2500 */
+       { 17733, 0,                 0x000007F7 },       /*  56.3916 */
+       { 17653, 0,                 0x0000057B },       /*  56.6444 */
+       { 16949, PREMULT2,          0x00000707 },       /*  59.0000 */
+       { 15873, POSTDIV3|PREMULT2, 0x00000B39 },       /*  63.0000 */
+       { 15384, POSTDIV3|PREMULT2, 0x00000B45 },       /*  65.0000 */
+       { 14814, POSTDIV3|PREMULT2, 0x00000FC1 },       /*  67.5000 */
+       { 14124, POSTDIV3,          0x00000561 },       /*  70.8000 */
+       { 13888, POSTDIV3,          0x000007E1 },       /*  72.0000 */
+       { 13426, PREMULT2,          0x00000F4A },       /*  74.4810 */
+       { 13333, 0,                 0x00000052 },       /*  75.0000 */
+       { 12698, 0,                 0x00000056 },       /*  78.7500 */
+       { 12500, POSTDIV3|PREMULT2, 0x00000709 },       /*  80.0000 */
+       { 11135, PREMULT2,          0x00000262 },       /*  89.8000 */
+       { 10582, 0,                 0x000002D2 },       /*  94.5000 */
+       { 10101, PREMULT2,          0x00000B4A },       /*  99.0000 */
+       { 10000, PREMULT2,          0x00000036 },       /* 100.0000 */
+       {  9259, 0,                 0x000007E2 },       /* 108.0000 */
+       {  8888, 0,                 0x000007F6 },       /* 112.5000 */
+       {  7692, POSTDIV3|PREMULT2, 0x00000FB0 },       /* 130.0000 */
+       {  7407, POSTDIV3|PREMULT2, 0x00000B50 },       /* 135.0000 */
+       {  6349, 0,                 0x00000055 },       /* 157.5000 */
+       {  6172, 0,                 0x000009C1 },       /* 162.0000 */
+       {  5787, PREMULT2,          0x0000002D },       /* 172.798  */
+       {  5698, 0,                 0x000002C1 },       /* 175.5000 */
+       {  5291, 0,                 0x000002D1 },       /* 189.0000 */
+       {  4938, 0,                 0x00000551 },       /* 202.5000 */
+       {  4357, 0,                 0x0000057D },       /* 229.5000 */
+};
+
+static void gx_set_dclk_frequency(struct fb_info *info)
+{
+       struct gx_pll_entry *pll_table;
+       int i, best_i;
+       long min, diff;
+       u64 dotpll, sys_rstpll;
+       int timeout = 1000;
+
+       /* FIXME: Handle rev 1 Geode GXs with a 14 MHz reference clock */
+       pll_table = gx_pll_table_48MHz;
+
+       /* Search the table for the closest pixclock. */
+       best_i = 0;
+       min = pll_table[0].pixclock - info->var.pixclock;
+       if (min < 0) min = -min;
+       for (i = 1; i < ARRAY_SIZE(gx_pll_table_48MHz); i++) {
+               diff = pll_table[i].pixclock - info->var.pixclock;
+               if (diff < 0L) diff = -diff;
+               if (diff < min) {
+                       min = diff;
+                       best_i = i;
+               }
+       }
+
+       rdmsrl(MSR_GLCP_SYS_RSTPLL, sys_rstpll);
+       rdmsrl(MSR_GLCP_DOTPLL, dotpll);
+
+       /* Program new M, N and P. */
+       dotpll &= 0x00000000ffffffffull;
+       dotpll |= (u64)pll_table[best_i].dotpll_value << 32;
+       dotpll |= MSR_GLCP_DOTPLL_DOTRESET;
+       dotpll &= ~MSR_GLCP_DOTPLL_BYPASS;
+
+       wrmsrl(MSR_GLCP_DOTPLL, dotpll);
+
+       /* Program dividers. */
+       sys_rstpll &= ~( MSR_GLCP_SYS_RSTPLL_DOTPREDIV2
+                        | MSR_GLCP_SYS_RSTPLL_DOTPREMULT2
+                        | MSR_GLCP_SYS_RSTPLL_DOTPOSTDIV3 );
+       sys_rstpll |= pll_table[best_i].sys_rstpll_bits;
+
+       wrmsrl(MSR_GLCP_SYS_RSTPLL, sys_rstpll);
+
+       /* Clear reset bit to start PLL. */
+       dotpll &= ~(MSR_GLCP_DOTPLL_DOTRESET);
+       wrmsrl(MSR_GLCP_DOTPLL, dotpll);
+
+       /* Wait for LOCK bit. */
+       do {
+               rdmsrl(MSR_GLCP_DOTPLL, dotpll);
+       } while (timeout-- && !(dotpll & MSR_GLCP_DOTPLL_LOCK));
+}
+
+static void gx_configure_display(struct fb_info *info)
+{
+       struct geodefb_par *par = info->par;
+       u32 dcfg, fp_pm;
+
+       dcfg = readl(par->vid_regs + GX_DCFG);
+
+       /* Clear bits from existing mode. */
+       dcfg &= ~(GX_DCFG_CRT_SYNC_SKW_MASK
+                 | GX_DCFG_CRT_HSYNC_POL   | GX_DCFG_CRT_VSYNC_POL
+                 | GX_DCFG_VSYNC_EN        | GX_DCFG_HSYNC_EN);
+
+       /* Set default sync skew.  */
+       dcfg |= GX_DCFG_CRT_SYNC_SKW_DFLT;
+
+       /* Enable hsync and vsync. */
+       dcfg |= GX_DCFG_HSYNC_EN | GX_DCFG_VSYNC_EN;
+
+       /* Sync polarities. */
+       if (info->var.sync & FB_SYNC_HOR_HIGH_ACT)
+               dcfg |= GX_DCFG_CRT_HSYNC_POL;
+       if (info->var.sync & FB_SYNC_VERT_HIGH_ACT)
+               dcfg |= GX_DCFG_CRT_VSYNC_POL;
+
+       writel(dcfg, par->vid_regs + GX_DCFG);
+
+       /* Power on flat panel. */
+       fp_pm = readl(par->vid_regs + GX_FP_PM);
+       fp_pm |= GX_FP_PM_P;
+       writel(fp_pm, par->vid_regs + GX_FP_PM);
+}
+
+static int gx_blank_display(struct fb_info *info, int blank_mode)
+{
+       struct geodefb_par *par = info->par;
+       u32 dcfg, fp_pm;
+       int blank, hsync, vsync;
+
+       /* CRT power saving modes. */
+       switch (blank_mode) {
+       case FB_BLANK_UNBLANK:
+               blank = 0; hsync = 1; vsync = 1;
+               break;
+       case FB_BLANK_NORMAL:
+               blank = 1; hsync = 1; vsync = 1;
+               break;
+       case FB_BLANK_VSYNC_SUSPEND:
+               blank = 1; hsync = 1; vsync = 0;
+               break;
+       case FB_BLANK_HSYNC_SUSPEND:
+               blank = 1; hsync = 0; vsync = 1;
+               break;
+       case FB_BLANK_POWERDOWN:
+               blank = 1; hsync = 0; vsync = 0;
+               break;
+       default:
+               return -EINVAL;
+       }
+       dcfg = readl(par->vid_regs + GX_DCFG);
+       dcfg &= ~(GX_DCFG_DAC_BL_EN
+                 | GX_DCFG_HSYNC_EN | GX_DCFG_VSYNC_EN);
+       if (!blank)
+               dcfg |= GX_DCFG_DAC_BL_EN;
+       if (hsync)
+               dcfg |= GX_DCFG_HSYNC_EN;
+       if (vsync)
+               dcfg |= GX_DCFG_VSYNC_EN;
+       writel(dcfg, par->vid_regs + GX_DCFG);
+
+       /* Power on/off flat panel. */
+       fp_pm = readl(par->vid_regs + GX_FP_PM);
+       if (blank_mode == FB_BLANK_POWERDOWN)
+               fp_pm &= ~GX_FP_PM_P;
+       else
+               fp_pm |= GX_FP_PM_P;
+       writel(fp_pm, par->vid_regs + GX_FP_PM);
+
+       return 0;
+}
+
+struct geode_vid_ops gx_vid_ops = {
+       .set_dclk          = gx_set_dclk_frequency,
+       .configure_display = gx_configure_display,
+       .blank_display     = gx_blank_display,
+};
Index: linux-2.6-working/drivers/video/geode/video_gx.h
===================================================================
--- /dev/null   1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-working/drivers/video/geode/video_gx.h    2006-01-31
16:59:51.000000000 +0000
@@ -0,0 +1,47 @@
+/*
+ * Geode GX video device
+ *
+ * Copyright (C) 2006 Arcom Control Systems Ltd.
+ *
+ * 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.
+ */
+#ifndef __VIDEO_GX_H__
+#define __VIDEO_GX_H__
+
+extern struct geode_vid_ops gx_vid_ops;
+
+/* Geode GX video processor registers */
+
+#define GX_DCFG                0x0008
+#  define GX_DCFG_CRT_EN               0x00000001
+#  define GX_DCFG_HSYNC_EN             0x00000002
+#  define GX_DCFG_VSYNC_EN             0x00000004
+#  define GX_DCFG_DAC_BL_EN            0x00000008
+#  define GX_DCFG_CRT_HSYNC_POL                0x00000100
+#  define GX_DCFG_CRT_VSYNC_POL                0x00000200
+#  define GX_DCFG_CRT_SYNC_SKW_MASK    0x0001C000
+#  define GX_DCFG_CRT_SYNC_SKW_DFLT    0x00010000
+#  define GX_DCFG_VG_CK                        0x00100000
+#  define GX_DCFG_GV_GAM               0x00200000
+#  define GX_DCFG_DAC_VREF             0x04000000
+
+/* Geode GX flat panel display control registers */
+#define GX_FP_PM 0x410
+#  define GX_FP_PM_P 0x01000000
+
+/* Geode GX clock control MSRs */
+
+#define MSR_GLCP_SYS_RSTPLL    0x4c000014
+#  define MSR_GLCP_SYS_RSTPLL_DOTPREDIV2       (0x0000000000000002ull)
+#  define MSR_GLCP_SYS_RSTPLL_DOTPREMULT2      (0x0000000000000004ull)
+#  define MSR_GLCP_SYS_RSTPLL_DOTPOSTDIV3      (0x0000000000000008ull)
+
+#define MSR_GLCP_DOTPLL                0x4c000015
+#  define MSR_GLCP_DOTPLL_DOTRESET             (0x0000000000000001ull)
+#  define MSR_GLCP_DOTPLL_BYPASS               (0x0000000000008000ull)
+#  define MSR_GLCP_DOTPLL_LOCK                 (0x0000000002000000ull)
+
+#endif /* !__VIDEO_GX_H__ */




--
Richard A. Smith

From ollie at lanl.gov  Tue Jan 31 20:08:56 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 31 Jan 2006 12:08:56 -0700
Subject: [LinuxBIOS] Fwd: [Linux-fbdev-devel] [patch] Framebuffer	driver
	for Geode GX
In-Reply-To: <8a0c36780601310950i406fe747rdb3cfb1ca0ef5dc6@mail.gmail.com>
References: <43DF9C09.30806@arcom.com>
	<8a0c36780601310950i406fe747rdb3cfb1ca0ef5dc6@mail.gmail.com>
Message-ID: <1138734537.6032.1.camel@logarithm.lanl.gov>

On Tue, 2006-01-31 at 12:50 -0500, Richard Smith wrote:
> This may be of interest to some people working with the Geode GX
> 

AMD has their own kernel patch available from their web page. Do you 
know if this has anything to do with that?

 
> ---------- Forwarded message ----------
> From: David Vrabel <dvrabel at arcom.com>
> Date: Jan 31, 2006 12:19 PM
> Subject: [Linux-fbdev-devel] [patch] Framebuffer driver for Geode GX
> To: linux-fbdev-devel list <linux-fbdev-devel at lists.sourceforge.net>
> 
> 
> A framebuffer driver for the display controller in AMD Geode GX
> processors (Geode GX533, Geode GX500 etc.).  Tested at 640x480, 800x600,
> 1024x768 and 1280x1024 at 8, 16, and 24 bpp with both CRT and TFT.  No
> accelerated features currently implemented and compression remains disabled.
> 
> This driver requires that the BIOS (or the SoftVG/Firmbase code in the
> BIOS) has created an appropriate virtual PCI header.
> 

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From smithbone at gmail.com  Tue Jan 31 21:24:11 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 31 Jan 2006 15:24:11 -0500
Subject: [LinuxBIOS] Fwd: [Linux-fbdev-devel] [patch] Framebuffer driver
	for Geode GX
In-Reply-To: <1138734537.6032.1.camel@logarithm.lanl.gov>
References: <43DF9C09.30806@arcom.com>
	<8a0c36780601310950i406fe747rdb3cfb1ca0ef5dc6@mail.gmail.com>
	<1138734537.6032.1.camel@logarithm.lanl.gov>
Message-ID: <8a0c36780601311224y23d1d56fx9a95a14513b4c74a@mail.gmail.com>

On 1/31/06, Li-Ta Lo <ollie at lanl.gov> wrote:
> On Tue, 2006-01-31 at 12:50 -0500, Richard Smith wrote:
> > This may be of interest to some people working with the Geode GX
> >
>
> AMD has their own kernel patch available from their web page. Do you
> know if this has anything to do with that?
>

The code claims that potions of it are from the AMD 2.4 driver.  Is
the AMD patch  for 2.6?

Unless AMD starts sending things to the fbdevel list for comment I
doubt thier driver will ever be accepted mainline.

--
Richard A. Smith

From ollie at lanl.gov  Tue Jan 31 21:49:55 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 31 Jan 2006 13:49:55 -0700
Subject: [LinuxBIOS] Fwd: [Linux-fbdev-devel] [patch] Framebuffer	driver
	for Geode GX
In-Reply-To: <8a0c36780601311224y23d1d56fx9a95a14513b4c74a@mail.gmail.com>
References: <43DF9C09.30806@arcom.com>
	<8a0c36780601310950i406fe747rdb3cfb1ca0ef5dc6@mail.gmail.com>
	<1138734537.6032.1.camel@logarithm.lanl.gov>
	<8a0c36780601311224y23d1d56fx9a95a14513b4c74a@mail.gmail.com>
Message-ID: <1138740595.6032.4.camel@logarithm.lanl.gov>

On Tue, 2006-01-31 at 15:24 -0500, Richard Smith wrote:
> On 1/31/06, Li-Ta Lo <ollie at lanl.gov> wrote:
> > On Tue, 2006-01-31 at 12:50 -0500, Richard Smith wrote:
> > > This may be of interest to some people working with the Geode GX
> > >
> >
> > AMD has their own kernel patch available from their web page. Do you
> > know if this has anything to do with that?
> >
> 
> The code claims that potions of it are from the AMD 2.4 driver.  Is
> the AMD patch  for 2.6?
> 

Yes. They have patch file for 2.6.11.

> Unless AMD starts sending things to the fbdevel list for comment I
> doubt thier driver will ever be accepted mainline.
> 

Than why do they bother to port the 2.4 driver from AMD?

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From smithbone at gmail.com  Tue Jan 31 22:46:38 2006
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 31 Jan 2006 16:46:38 -0500
Subject: [LinuxBIOS] Fwd: [Linux-fbdev-devel] [patch] Framebuffer driver
	for Geode GX
In-Reply-To: <1138740595.6032.4.camel@logarithm.lanl.gov>
References: <43DF9C09.30806@arcom.com>
	<8a0c36780601310950i406fe747rdb3cfb1ca0ef5dc6@mail.gmail.com>
	<1138734537.6032.1.camel@logarithm.lanl.gov>
	<8a0c36780601311224y23d1d56fx9a95a14513b4c74a@mail.gmail.com>
	<1138740595.6032.4.camel@logarithm.lanl.gov>
Message-ID: <8a0c36780601311346i1455b3b6w466545d89d74ef5@mail.gmail.com>

>
> Yes. They have patch file for 2.6.11.

Whats the URL?

> > Unless AMD starts sending things to the fbdevel list for comment I
> > doubt thier driver will ever be accepted mainline.
>
> Than why do they bother to port the 2.4 driver from AMD?

The driver says portions were _derrived_ from the 2.4 driver.  Its not
a straight port.

I've asked the author to comment on what the differences are.

--
Richard A. Smith

From ollie at lanl.gov  Tue Jan 31 22:51:35 2006
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 31 Jan 2006 14:51:35 -0700
Subject: [LinuxBIOS] Fwd: [Linux-fbdev-devel] [patch] Framebuffer	driver
	for Geode GX
In-Reply-To: <8a0c36780601311346i1455b3b6w466545d89d74ef5@mail.gmail.com>
References: <43DF9C09.30806@arcom.com>
	<8a0c36780601310950i406fe747rdb3cfb1ca0ef5dc6@mail.gmail.com>
	<1138734537.6032.1.camel@logarithm.lanl.gov>
	<8a0c36780601311224y23d1d56fx9a95a14513b4c74a@mail.gmail.com>
	<1138740595.6032.4.camel@logarithm.lanl.gov>
	<8a0c36780601311346i1455b3b6w466545d89d74ef5@mail.gmail.com>
Message-ID: <1138744295.6032.9.camel@logarithm.lanl.gov>

On Tue, 2006-01-31 at 16:46 -0500, Richard Smith wrote:

> >
> > Yes. They have patch file for 2.6.11.
> 
> Whats the URL?
> 


http://www.amd.com/us-
en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_11363,00.html


> > > Unless AMD starts sending things to the fbdevel list for comment I
> > > doubt thier driver will ever be accepted mainline.
> >
> > Than why do they bother to port the 2.4 driver from AMD?
> 
> The driver says portions were _derrived_ from the 2.4 driver.  Its not
> a straight port.
> 
> I've asked the author to comment on what the differences are.
> 
> --
> Richard A. Smith

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20060131/17032efb/attachment.html>