From svn at openbios.org  Fri Jun  1 06:41:42 2007
From: svn at openbios.org (svn at openbios.org)
Date: Fri,  1 Jun 2007 06:41:42 +0200
Subject: [LinuxBIOS] r339 - LinuxBIOSv3/lib
Message-ID: <mailman.367.1355071117.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-06-01 06:41:42 +0200 (Fri, 01 Jun 2007)
New Revision: 339

Modified:
   LinuxBIOSv3/lib/ram.c
Log:
This fixes ram.c correctly for cases where we link instead of
including .c files.

The mem controller is an opaque type. This code is called with a
pointer and a count of mem controllers.

I have serious doubts about the value of this code. It is so generic,
and does so little, that it
may be useless. It may be useful for documentation, however, as it
shows people the sequence of operations for spd.

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: LinuxBIOSv3/lib/ram.c
===================================================================
--- LinuxBIOSv3/lib/ram.c	2007-05-28 14:34:05 UTC (rev 338)
+++ LinuxBIOSv3/lib/ram.c	2007-06-01 04:41:42 UTC (rev 339)
@@ -40,12 +40,12 @@
  * of making it an empty function.
  *
  * @param controllers How many memory controllers there are.
- * @param ctrl Pointer to the mem control structure.
- * @param sysinfo Not used on all targets. NULL if not used. This function
- * 	  does nothing with sysinfo but pass it on.
+ * @param ctrl Pointer to the mem control structure. This is a generic pointer, since the 
+ *    structure is wholly chip-dependent, and a survey of all the types makes it clear that a common 
+ *    struct is not possible. We can not use the device tree here as this code is run before the device tree
+ *    is available. 
  */
-void ram_initialize(int controllers, const struct mem_controller *ctrl,
-		    void *sysinfo)
+void ram_initialize(int controllers, void *ctrl)
 {
 	int i;
 
@@ -53,21 +53,21 @@
 	for (i = 0; i < controllers; i++) {
 		printk(BIOS_INFO,
 		       "Setting registers of RAM controller %d\n", i);
-		ram_set_registers(ctrl + i, sysinfo);
+		ram_set_registers(ctrl, i);
 	}
 
 	/* Now setup those things we can auto detect. */
 	for (i = 0; i < controllers; i++) {
 		printk(BIOS_INFO,
 		  "Setting SPD based registers of RAM controller %d\n", i);
-		ram_set_spd_registers(ctrl + i, sysinfo);
+		ram_set_spd_registers(ctrl, i);
 	}
 
 	/* Now that everything is setup enable the RAM. Some chipsets do
 	 * the work for us while on others we need to it by hand.
 	 */
 	printk(BIOS_DEBUG, "Enabling RAM\n");
-	ram_enable(controllers, ctrl, sysinfo);
+	ram_enable(controllers, ctrl);
 
 	/* RAM initialization is done. */
 	printk(BIOS_DEBUG, "RAM enabled successfully\n");




From citizenr at gmail.com  Fri Jun  1 02:58:02 2007
From: citizenr at gmail.com (RusH)
Date: Fri, 1 Jun 2007 02:58:02 +0200
Subject: [LinuxBIOS] using Graphics card ram as actual ram?
In-Reply-To: <200705311820.30245.juergen127@kreuzholzen.de>
References: <3df49b7b0705300957l3d063c50p404ed2cb07b8bd9@mail.gmail.com>
	<200705311820.30245.juergen127@kreuzholzen.de>
Message-ID: <3df49b7b0705311758h1027a019h9a033993ac96e1d1@mail.gmail.com>

On 5/31/07, Juergen Beisert <juergen127 at kreuzholzen.de> wrote:
> On Wednesday 30 May 2007 18:57, RusH wrote:
> > Currently LinuxBios is using CAR for ram. What about using Video card
> > memory? is that feasible? Can you setup Video memory as stack?
>
> It would be possible, but this memory also is disabled after reset. To use it
> as RAM you must enable graphic controller's SDRAM controller first. And to
> enable graphic controller's SDRAM controller, you must init its PCI
> configurations space first, otherwise you can't access its registers....

thanks, so it looks like that 'magic hot swap testing program' is not
a bios replacement. Earlier I was under the impression they wrote the
whole thing as close to the bare metal as possible.

-- 
Who logs in to gdm? Not I, said the duck.



From dieter at bloms.de  Fri Jun  1 07:21:08 2007
From: dieter at bloms.de (Dieter Bloms)
Date: Fri, 1 Jun 2007 07:21:08 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
References: <20070531194024.GB3955@bloms.de>
	<20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
Message-ID: <20070601052108.GB3251@bloms.de>

Hi,

On Thu, May 31, joe at smittys.pointclark.net wrote:

> Here is a copy of the change log that I have made to the i82801db. I  
> am still working on my northbridge and have not been able to test it.  
> Can someone make the changes and test for me?

it does compile, but I can not see anything on the serial console.
So I think there is something wrong with my config, because about 5
seconds after power on it beeps and beeps and beeps .... two time per
second.

I don't know where I have to look now :(


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070601/0cc71f46/attachment.sig>

From mjd at e-nspect.com  Fri Jun  1 14:19:24 2007
From: mjd at e-nspect.com (Mike Dilworth)
Date: Fri, 1 Jun 2007 05:19:24 -0700
Subject: [LinuxBIOS] which motherboard would be the better choice
Message-ID: <b610d37e10684a8689d4eae88c06b2f1@mx243m.mysite4now.com>



hi all

I am soon to buy a new motherboard and I have narrowed my choice down to 2.  I am very interested in the LinuxBios project and am eager to "have a go".  My question is whihc of these two motherbords would be better to use for LinuxBios:

MS-7327 K9AGM2-FIH  http://global.msi.com.tw/index.php?func=proddesc&maincat_no=1&cat2_no=&cat3_no=&prod_no=1165

or the 

Abit AN-M2HD http://www.abit.com.tw/page/uk/motherboard/motherboard_detail.php?pMODEL_NAME=AN-M2HD&fMTYPE=Socket+AM2

as you can tell I need the HDMI feature.  

Other information:

On both I will use the AMD Athlon X2 3800+ AM2 CPU

MS-7327

uses AMI BIOS 
AMD 690G Northbridge and SB600 Southbridge
integrated ATi Radeon X1250 videocard 
Realtek High Definition Audio Driver
ATI System Drivers for RS480/RS482/RC410/SB600
AMD HDMI Audio Drivers
Realtek 10/100 LAN Drivers
ATI SB600 IDE RAID Driver
Realtek Gigabit Ethernet Drivers
from the photos it looks like this uses ??? its nt clear DIP BIOS???

Abit AN-M2HD
NVIDIA? GeForce?7050PV/nForce 630a 
from the pictures i think this uses a PLCC: Plastic Leaded Chip Carrier 

 this is about all i have to go on. Any pointers would be great.

tia

mike


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

From otavio.junior at gmail.com  Fri Jun  1 16:44:13 2007
From: otavio.junior at gmail.com (=?ISO-8859-1?Q?Ot=E1vio_Alc=E2ntara?=)
Date: Fri, 1 Jun 2007 11:44:13 -0300
Subject: [LinuxBIOS] Problem with FILO
Message-ID: <751d98080706010744h25bddc0fj854ec1d45c6737c3@mail.gmail.com>

Hello,

         I've setup a linuxbios rom, based on norwich board support, for a
board with Geode LX + CS5536. I works right until starting the Linux with
FILO. FILO claims that can't recognize my filesystem. I've setup the option
FSYS_EXT2FS = 1 on Config file of Filo, and my image is EXT2 formatted.
          Is there any other option that need to be setted? Is possible to
choose more than one file system, I mean, FAT and EXT2?

Best Regards,

-- 
Ot?vio Alc?ntara
"I'll never cross to the Dark Side."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070601/4cad38b4/attachment.html>

From andi.mundt at web.de  Fri Jun  1 16:41:06 2007
From: andi.mundt at web.de (Andreas B. Mundt)
Date: Fri, 1 Jun 2007 16:41:06 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
Message-ID: <20070601144106.GA5671@flashgordon>

Hello,

thanks for all suggestions so far. I can now boot the board (and my CPU, a "Brisbane") 
with the following modifications: 

Index: src/cpu/amd/model_fxx/model_fxx_init.c
===================================================================
--- src/cpu/amd/model_fxx/model_fxx_init.c      (revision 2699)
+++ src/cpu/amd/model_fxx/model_fxx_init.c      (working copy)
@@ -615,6 +615,7 @@
        { X86_VENDOR_AMD, 0x40f82 },            /*        S1g1:Turion64 x2 */
         { X86_VENDOR_AMD, 0x40ff2 }, /* DH-F2      Socket AM2: Athlon64 */
         { X86_VENDOR_AMD, 0x50ff2 }, /* DH-F2      Socket AM2: Athlon64 */
+        { X86_VENDOR_AMD, 0x60fb1 }, /* DH-F2???   Socket AM2: Athlon64 Brisbane*/
         { X86_VENDOR_AMD, 0x40fc2 },            /*        S1g1:Turion64 */
         { X86_VENDOR_AMD, 0x40f13 }, /* JH-F3      Socket F (1207): Opteron Dual Core */
         { X86_VENDOR_AMD, 0x40f33 },            /*        AM2 : Opteron Dual Core/Athlon64 x2/ Athlon64 FX Dual Core */


I do not know if this is enough or if some other parameters should be adapted.
Some issues remain:

-powernow does not work, and the cpu freq. is at 2.5 GHz (proprietary BIOS: max cpu freq. 2.6 GHz)

-having booted with linuxbios, flashroom fails to erase (and therefore flash) any other BIOS

-some problems with X: with the proprietary BIOS the machine freezes using the free nv driver 
(02:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GS]). It works with linuxbios, but 
I have to log in twice with no cursor the first time. The nvidia driver does not work with linuxbios.

-I had to use the delay in filo.c (cmp. http://www.linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial)

-it takes quite long to load vmlinuz and the initrd.img. Probably due to: IDE_DISK_POLL_DELAY = 1 (?)

-still the "Fallback" bios is booted, although I could not find any difference in the configuration of standard and 
fallback BIOS. The same file.elf was used.  
  
Any suggestions and ideas are wellcome!

Thanks,

	Andi



Below find the serial output:
====================================

LinuxBIOS-2.0.0_m57sli_Fallback Fri May 25 16:32:21 CEST 2007 starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
core0 started: 
started ap apicid:  01
SBLink=00
NC node|link=00
begin msr fid, vid 3107121207110202
set fid failed for apicid =00
end   msr fid, vid 3107120707110210
mcp55_num:01
ht reset -


LinuxBIOS-2.0.0_m57sli_Fallback Fri May 25 16:32:21 CEST 2007 starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
core0 started: 
started ap apicid:  01
SBLink=00
NC node|link=00
begin msr fid, vid 3107120707110210
set fid failed for apicid =00
end   msr fid, vid 3107120707110210
mcp55_num:01
Ram1.00
Ram2.00
Unbuffered
333Mhz
Interleaved
RAM: 0x00400000 KB
Ram3
	dimm_mask = 00000033
	x4_mask = 00000000
	x16_mask = 00000000
	single_rank_mask = 00000000
	ODC = 00111322
	Addr Timing= 002b2220
Initializing memory:  done
RAM: 0x00500000 KB
Setting variable MTRR 2, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 3, base: 2048MB, range: 1024MB, type WB
set DQS timing:RcvrEn:Pass1: 00 CTLRMaxDelay=14 done
set DQS timing:DQSPos: 00 done
set DQS timing:RcvrEn:Pass2: 00 CTLRMaxDelay=34 done
Total DQS Training : tsc [00]=000000004599b8b0
Total DQS Training : tsc [01]=00000000475a1098
Total DQS Training : tsc [02]=00000000a33aa32a
Total DQS Training : tsc [03]=00000000a57e3581
Ram4
v_esp=000cee78
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: Done
Copying LinuxBIOS to RAM.
src=fffdf000
dst=00100000
linxbios_ram.nrv2b length = 0000d633
linxbios_ram.bin   length = 00022550
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0_m57sli_Fallback Sun May 27 21:19:37 CEST 2007 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: pci_scan_bus for bus 00
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:00.0 [10de/0369] enabled
PCI: 00:00.0 [10de/0369] enabled next_unitid: 0010
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [10de/0369] enabled
PCI: 00:01.0 [10de/0360] enabled
PCI: 00:01.1 [10de/0368] enabled
PCI: 00:01.2 [10de/036a] enabled
PCI: 00:01.3 [10de/036b] enabled
PCI: 00:02.0 [10de/036c] enabled
PCI: 00:02.1 [10de/036d] enabled
PCI: 00:04.0 [10de/036e] enabled
PCI: 00:05.0 [10de/037f] enabled
PCI: 00:05.1 [10de/037f] enabled
PCI: 00:05.2 [10de/037f] enabled
PCI: 00:06.0 [10de/0370] enabled
PCI: 00:06.1 [10de/0371] enabled
PCI: 00:08.0 [10de/0373] enabled
PCI: 00:0a.0 [10de/0376] enabled
PCI: 00:0b.0 [10de/0374] enabled
PCI: 00:0c.0 [10de/0374] enabled
PCI: 00:0d.0 [10de/0378] enabled
PCI: 00:0e.0 [10de/0375] enabled
PCI: 00:0f.0 [10de/0377] enabled
PNP: 002e.0 disabled
PNP: 002e.1 enabled
PNP: 002e.2 disabled
PNP: 002e.3 disabled
PNP: 002e.4 enabled
PNP: 002e.5 enabled
PNP: 002e.6 enabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
smbus: PCI: 00:01.1[0]->I2C: 01:50 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:51 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:52 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:53 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:54 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:55 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:56 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:57 enabled
smbus: PCI: 00:01.1[1]->I2C: 02:51 enabled
PCI: pci_scan_bus for bus 01
PCI: pci_scan_bus returning with max=001
PCI: pci_scan_bus for bus 02
PCI: pci_scan_bus returning with max=002
PCI: pci_scan_bus for bus 03
PCI: pci_scan_bus returning with max=003
PCI: pci_scan_bus for bus 04
PCI: pci_scan_bus returning with max=004
PCI: pci_scan_bus for bus 05
PCI: pci_scan_bus returning with max=005
PCI: pci_scan_bus for bus 06
PCI: pci_scan_bus returning with max=006
PCI: pci_scan_bus for bus 07
PCI: 07:00.0 [10de/0392] enabled
PCI: pci_scan_bus returning with max=007
PCI: pci_scan_bus returning with max=007
PCI: pci_scan_bus returning with max=007
done
Allocating resources...
Reading resources...
PCI: 00:06.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io
PCI: 00:06.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem
PCI: 00:06.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 01 mem
PCI: 00:0a.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 02 io
PCI: 00:0a.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 02 prefmem
PCI: 00:0a.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 02 mem
PCI: 00:0b.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 03 io
PCI: 00:0b.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 03 prefmem
PCI: 00:0b.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 03 mem
PCI: 00:0c.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 04 io
PCI: 00:0c.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 04 prefmem
PCI: 00:0c.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 04 mem
PCI: 00:0d.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 05 io
PCI: 00:0d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 05 prefmem
PCI: 00:0d.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 05 mem
PCI: 00:0e.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 06 io
PCI: 00:0e.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 06 prefmem
PCI: 00:0e.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 06 mem
Done reading resources.
Allocating VGA resource PCI: 07:00.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:0f.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
VGA: PCI: 00:18.0 (aka node 0) link 0 has VGA device
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0>
PCI: 00:18.0 1b8 <- [0x00e0000000 - 0x00efffffff] prefmem <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00f4000000 - 0x00f61fffff] mem <node 0 link 0>
PCI: 00:01.0 14 <- [0x00f6144000 - 0x00f6144fff] mem
PNP: 002e.1 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.1 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.4 60 <- [0x0000000290 - 0x0000000297] io
PNP: 002e.4 62 <- [0x0000000230 - 0x0000000237] io
PNP: 002e.4 70 <- [0x0000000009 - 0x0000000009] irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.6 70 <- [0x000000000c - 0x000000000c] irq
PCI: 00:01.1 10 <- [0x0000002c00 - 0x0000002c3f] io
PCI: 00:01.1 20 <- [0x0000002c40 - 0x0000002c7f] io
PCI: 00:01.1 24 <- [0x0000002c80 - 0x0000002cbf] io
PCI: 00:01.1 60 <- [0x0000002000 - 0x00000020ff] io
PCI: 00:01.1 64 <- [0x0000002400 - 0x00000024ff] io
PCI: 00:01.1 68 <- [0x0000002800 - 0x00000028ff] io
PCI: 00:01.3 10 <- [0x00f6100000 - 0x00f613ffff] mem
PCI: 00:02.0 10 <- [0x00f6145000 - 0x00f6145fff] mem
PCI: 00:02.1 10 <- [0x00f614a000 - 0x00f614a0ff] mem
PCI: 00:04.0 20 <- [0x0000002cc0 - 0x0000002ccf] io
PCI: 00:05.0 10 <- [0x0000003000 - 0x0000003007] io
PCI: 00:05.0 14 <- [0x0000003070 - 0x0000003073] io
PCI: 00:05.0 18 <- [0x0000003010 - 0x0000003017] io
PCI: 00:05.0 1c <- [0x0000003080 - 0x0000003083] io
PCI: 00:05.0 20 <- [0x0000002cd0 - 0x0000002cdf] io
PCI: 00:05.0 24 <- [0x00f6146000 - 0x00f6146fff] mem
PCI: 00:05.1 10 <- [0x0000003020 - 0x0000003027] io
PCI: 00:05.1 14 <- [0x0000003090 - 0x0000003093] io
PCI: 00:05.1 18 <- [0x0000003030 - 0x0000003037] io
PCI: 00:05.1 1c <- [0x00000030a0 - 0x00000030a3] io
PCI: 00:05.1 20 <- [0x0000002ce0 - 0x0000002cef] io
PCI: 00:05.1 24 <- [0x00f6147000 - 0x00f6147fff] mem
PCI: 00:05.2 10 <- [0x0000003040 - 0x0000003047] io
PCI: 00:05.2 14 <- [0x00000030b0 - 0x00000030b3] io
PCI: 00:05.2 18 <- [0x0000003050 - 0x0000003057] io
PCI: 00:05.2 1c <- [0x00000030c0 - 0x00000030c3] io
PCI: 00:05.2 20 <- [0x0000002cf0 - 0x0000002cff] io
PCI: 00:05.2 24 <- [0x00f6148000 - 0x00f6148fff] mem
PCI: 00:06.1 10 <- [0x00f6140000 - 0x00f6143fff] mem
PCI: 00:08.0 10 <- [0x00f6149000 - 0x00f6149fff] mem
PCI: 00:08.0 14 <- [0x0000003060 - 0x0000003067] io
PCI: 00:08.0 18 <- [0x00f614b000 - 0x00f614b0ff] mem
PCI: 00:08.0 1c <- [0x00f614c000 - 0x00f614c00f] mem
PCI: 00:0f.0 1c <- [0x0000001000 - 0x0000001fff] bus 07 io
PCI: 00:0f.0 24 <- [0x00e0000000 - 0x00efffffff] bus 07 prefmem
PCI: 00:0f.0 20 <- [0x00f4000000 - 0x00f60fffff] bus 07 mem
PCI: 07:00.0 10 <- [0x00f4000000 - 0x00f4ffffff] mem
PCI: 07:00.0 14 <- [0x00e0000000 - 0x00efffffff] prefmem64
PCI: 07:00.0 1c <- [0x00f5000000 - 0x00f5ffffff] mem64
PCI: 07:00.0 24 <- [0x0000001000 - 0x000000107f] io
PCI: 07:00.0 30 <- [0x00f6000000 - 0x00f601ffff] romem
PCI: 00:18.3 94 <- [0x00f0000000 - 0x00f3ffffff] mem <gart>
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:18.0 cmd <- 140
PCI: 00:00.0 subsystem <- 1022/2b80
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 subsystem <- 1022/2b80
PCI: 00:01.0 cmd <- 14f
mcp55 lpc decode:PNP: 002e.1, base=0x000003f8, end=0x000003ff
mcp55 lpc decode:PNP: 002e.4, base=0x00000290, end=0x00000297
mcp55 lpc decode:PNP: 002e.4, base=0x00000230, end=0x00000237
mcp55 lpc decode:PNP: 002e.5, base=0x00000060, end=0x00000060
mcp55 lpc decode:PNP: 002e.5, base=0x00000064, end=0x00000064
PCI: 00:01.1 subsystem <- 1022/2b80
PCI: 00:01.1 cmd <- 141
PCI: 00:01.2 cmd <- 540
PCI: 00:01.3 cmd <- 142
PCI: 00:02.0 subsystem <- 1022/2b80
PCI: 00:02.0 cmd <- 142
PCI: 00:02.1 subsystem <- 1022/2b80
PCI: 00:02.1 cmd <- 142
PCI: 00:04.0 subsystem <- 1022/2b80
PCI: 00:04.0 cmd <- 141
PCI: 00:05.0 subsystem <- 1022/2b80
PCI: 00:05.0 cmd <- 143
PCI: 00:05.1 subsystem <- 1022/2b80
PCI: 00:05.1 cmd <- 143
PCI: 00:05.2 subsystem <- 1022/2b80
PCI: 00:05.2 cmd <- 143
PCI: 00:06.0 bridge ctrl <- 0a03
PCI: 00:06.0 cmd <- 144
PCI: 00:06.1 subsystem <- 1022/2b80
PCI: 00:06.1 cmd <- 142
PCI: 00:08.0 subsystem <- 1022/2b80
PCI: 00:08.0 cmd <- 143
PCI: 00:0a.0 bridge ctrl <- 0003
PCI: 00:0a.0 cmd <- 140
PCI: 00:0b.0 bridge ctrl <- 0003
PCI: 00:0b.0 cmd <- 140
PCI: 00:0c.0 bridge ctrl <- 0003
PCI: 00:0c.0 cmd <- 140
PCI: 00:0d.0 bridge ctrl <- 0003
PCI: 00:0d.0 cmd <- 140
PCI: 00:0e.0 bridge ctrl <- 0003
PCI: 00:0e.0 cmd <- 140
PCI: 00:0f.0 bridge ctrl <- 000b
PCI: 00:0f.0 cmd <- 147
PCI: 07:00.0 cmd <- 143
PCI: 00:18.1 subsystem <- 1022/2b80
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 1022/2b80
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
start_eip=0x00006000, offset=0x00110000, code_size=0x0000005b
Initializing CPU #0
CPU: vendor AMD device 60fb1
CPU: family 0f, model 6b, stepping 01
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

CPU model AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
Setting up local apic... apic_id: 0x00 done.
ECC Disabled
CPU #0 Initialized
Initializing CPU #1
Waiting for 1 CPUS to stop
CPU: vendor AMD device 60fb1
CPU: family 0f, model 6b, stepping 01
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

CPU model AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
Setting up local apic... apic_id: 0x01 done.
CPU #1 Initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 00:01.0 init
set power on after power fail
RTC Init
Invalid CMOS LB checksum
PNP: 002e.1 init
PNP: 002e.4 init
FAN_CTL: reg = 0x02a9, read value = 0x50
FAN_CTL: reg = 0x02a9, writing value = 0xd7
PNP: 002e.5 init
PNP: 002e.6 init
PCI: 00:01.1 init
PCI: 00:02.1 init
PCI: 00:04.0 init
IDE0
PCI: 00:05.0 init
SATA S 	SATA P 
PCI: 00:05.1 init
SATA S 	SATA P 
PCI: 00:05.2 init
SATA S 	SATA P 
PCI: 00:06.0 init
dev_root mem base = 0x00e0000000
[0x50] <-- 0xe0000000
PCI: 00:06.1 init
base = f6140000
codec_mask = 01
codec viddid: 10ec0883
No verb!
PCI: 00:08.0 init
MCP55 MAC PHY ID 0x01410c00 PHY ADDR 1
PCI: 00:0a.0 init
PCI: 00:0b.0 init
PCI: 00:0c.0 init
PCI: 00:0d.0 init
PCI: 00:0e.0 init
PCI: 00:0f.0 init
PCI: 00:18.1 init
PCI: 00:18.2 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:01.2 init
PCI: 00:01.3 init
PCI: 07:00.0 init
rom address for PCI: 07:00.0 = f6000000
copying VGA ROM Image from 0xf6000000 to 0xc0000, 0xf600 bytes
entering emulator
halt_sys: file /home/andi/freeBIOS/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 00000274
Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000 
Adjust rom_table_end from 0x000f0400 to 0x00100000 
Wrote linuxbios table at: 00000530 - 00000df8  checksum cbc3

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

rom_stream: 0xfffc0000 - 0xfffdefff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
New segment addr 0x100000 size 0x3b960 offset 0xc0 filesize 0x11948
(cleaned up) New segment addr 0x100000 size 0x3b960 offset 0xc0 filesize 0x11948
New segment addr 0x13b960 size 0x48 offset 0x11a20 filesize 0x48
(cleaned up) New segment addr 0x13b960 size 0x48 offset 0x11a20 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x00000000bff80000 memsz: 0x000000000003b960 filesz: 0x0000000000011948
Clearing Segment: addr: 0x00000000bff91948 memsz: 0x000000000002a018
Loading Segment: addr: 0x00000000bffbb960 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x10d184
FILO version 0.5 (andi at flashgordon) Sun May 27 20:47:38 CEST 2007
menu: hde5:/boot/grub/menu.lst
hde: LBA48 250GB: SAMSUNG SP2504C                         
Mounted ext2fs
Press any key to continue.
Press any key to continue.
Press any key to continue.

                                  FILO 0.5

+-------------------------------------------------------------------------+||||||||||||||||||||||||+-------------------------------------------------------------------------+
      Use the ^ and v keys to select which entry is highlighted.
      Press enter to boot the selected OS, 'e' to edit the
      commands before booting, 'a' to modify the kernel arguments
      before booting, or 'c' for a command-line.  Debian GNU/Linux, kernel 2.6.18-4-amd64                                  Debian GNU/Linux, kernel 2.6.18-4-amd64 (single-user mode)               Debian GNU/Linux Lenny, kernel 2.6.18-amd64                              Debian GNU/Linux Sid, kernel 2.6.21-amd64                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        The highlighted entry will be booted automatically in 5 seconds.    The highlighted entry will be booted automatically in 4 seconds.    The highlighted entry will be booted automatically in 3 seconds.    The highlighted entry will be booted automatically in 2 seconds.    The highlighted entry will be booted automatically in 1 seconds.      Booting 'Debian GNU/Linux Lenny, kernel 2.6.18-amd64'

root     (hd4,4)
kernel     /boot/vmlinuz-2.6.18-4-amd64 root=/dev/sda2 ro acpi_use_timer_overri
de console=tty0 console=ttyS0,115200 vga=791
initrd          /boot/initrd.img-2.6.18-4-amd64
boot

Booting 'hde5:/boot/vmlinuz-2.6.18-4-amd64 root=/dev/sda2 ro acpi_use_timer_ove
rride console=tty0 console=ttyS0,115200 vga=791 initrd=/boot/initrd.img-2.6.18-
4-amd64'
Found Linux version 2.6.18-4-amd64 (unknown at Debian) #1 SMP Mon Mar 26 11:36:53 CEST 2007 bzImage.
Loading kernel... ok
Loading initrd... ok
Jumping to entry point...
Bootdata ok (command line is root=/dev/sda2 ro acpi_use_timer_override console=tty0 console=ttyS0,115200 vga=791)
Linux version 2.6.18-4-amd64 (Debian 2.6.18.dfsg.1-12) (waldi at debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Mon Mar 26 11:36:53 CEST 2007
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
DMI not present or invalid.
ACPI: Unable to locate RSDP
Scanning NUMA topology in Northbridge 24
Number of nodes 1
Node 0 MemBase 0000000000000000 Limit 0000000140000000
Using node hash shift of 63
Bootmem setup node 0 0000000000000000-0000000140000000
Nvidia board detected. Ignoring ACPI timer override.
Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: GIGABYTE Product ID: M57SLI       APIC at: 0xFEE00000
Processor #0 15:11 APIC version 16
Processor #1 15:11 APIC version 16
I/O APIC #2 Version 17 at 0xF6144000.
Setting APIC routing to physical flat
Processors: 2
Allocating PCI resources starting at c4000000 (gap: c0000000:40000000)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
Built 1 zonelists.  Total pages: 1029672
Kernel command line: root=/dev/sda2 ro acpi_use_timer_override console=tty0 console=ttyS0,115200 vga=791
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Using 1.193182 MHz WALL PIT GTOD PIT/TSC timer.
time.c: Detected 2400.010 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking aperture...
CPU 0: aperture @ f0000000 size 64 MB
Memory: 4107000k/5242880k available (1930k kernel code, 86916k reserved, 868k data, 176k init)
Calibrating delay using timer specific routine.. 4808.82 BogoMIPS (lpj=9617640)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/0 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
Using IO-APIC 2
GSI 16 sharing vector 0x91 and IRQ 16
GSI 17 sharing vector 0x99 and IRQ 17
GSI 18 sharing vector 0xA1 and IRQ 18
GSI 19 sharing vector 0xA9 and IRQ 19
GSI 20 sharing vector 0xB1 and IRQ 20
GSI 21 sharing vector 0xB9 and IRQ 21
GSI 22 sharing vector 0xC1 and IRQ 22
GSI 23 sharing vector 0xC9 and IRQ 23
Using local APIC timer interrupts.
result 12500064
Detected 12.500 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4800.35 BogoMIPS (lpj=9600714)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ stepping 01
CPU 1: Syncing TSC to CPU 0.
CPU 1: synchronized TSC with CPU 0 (last diff 0 cycles, maxerr 687 cycles)
Brought up 2 CPUs
testing NMI watchdog ... OK.
migration_cost=187
checking if image is initramfs... it is
Freeing initrd memory: 5292k freed
NET: Registered protocol family 16
PCI: Using configuration type 1
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Probing PCI hardware
PCI: Using IRQ router default [10de/0370] at 0000:00:06.0
PCI->APIC IRQ transform: 0000:00:01.1[A] -> IRQ 10
PCI->APIC IRQ transform: 0000:00:01.3[B] -> IRQ 10
PCI->APIC IRQ transform: 0000:00:02.0[A] -> IRQ 193
PCI->APIC IRQ transform: 0000:00:02.1[B] -> IRQ 201
PCI->APIC IRQ transform: 0000:00:05.0[A] -> IRQ 177
PCI->APIC IRQ transform: 0000:00:05.1[B] -> IRQ 201
PCI->APIC IRQ transform: 0000:00:05.2[C] -> IRQ 185
PCI->APIC IRQ transform: 0000:00:06.1[B] -> IRQ 201
PCI->APIC IRQ transform: 0000:00:08.0[A] -> IRQ 193
PCI->APIC IRQ transform: 0000:07:00.0[A] -> IRQ 153
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ f0000000 size 65536 KB
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
PCI: Bridge: 0000:00:06.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0a.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0b.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0f.0
  IO window: 1000-1fff
  MEM window: f4000000-f60fffff
  PREFETCH window: e0000000-efffffff
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1180702708.720:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pcie_portdrv_probe->Dev[0376:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
pcie_portdrv_probe->Dev[0374:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
pcie_portdrv_probe->Dev[0374:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
pcie_portdrv_probe->Dev[0378:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
pcie_portdrv_probe->Dev[0375:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
pcie_portdrv_probe->Dev[0377:10de] has invalid IRQ. Check vendor BIOS
assign_interrupt_mode Found MSI capability
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.101 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 8
NET: Registered protocol family 20
Freeing unused kernel memory: 176k freed
Loading, please wait...
input: AT Translated Set 2 keyboard as /class/input/input0
Begin: Loading essential drivers... ...
Done.
Begin: Running /scripts/init-premount ...
FATAL: Error inserting fan (/lib/modules/2.6.18-4-amd64/kernel/drivers/acpi/fan.ko): No such device
FATAL: Error inserting thermal (/lib/modules/2.6.18-4-amd64/kernel/drivers/acpi/thermal.ko): No such device
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ehci_hcd 0000:00:02.1: EHCI Host Controller
ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:02.1: debug port 1
ehci_hcd 0000:00:02.1: irq 201, io mem 0xf614a000
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 10 ports detected
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56.
NFORCE-MCP55: IDE controller at PCI slot 0000:00:04.0
NFORCE-MCP55: chipset revision 161
NFORCE-MCP55: not 100% native mode: will probe irqs later
NFORCE-MCP55: 0000:00:04.0 (rev a1) UDMA133 controller
    ide0: BM-DMA at 0x2cc0-0x2cc7, BIOS settings: hda:pio, hdb:pio
usb 1-2: new high speed USB device using ehci_hcd and address 3
hda: Optiarc DVD RW AD-7173A, ATAPI CD/DVD-ROM drive
usb 1-2: configuration #1 chosen from 1 choice
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:02.0: irq 193, io mem 0xf6145000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 10 ports detected
SCSI subsystem initialized
ata1: SATA max UDMA/133 cmd 0x3000 ctl 0x3072 bmdma 0x2CD0 irq 177
ata2: SATA max UDMA/133 cmd 0x3010 ctl 0x3082 bmdma 0x2CD8 irq 177
scsi0 : sata_nv
Initializing USB Mass Storage driver...
scsi2 : SCSI emulation for USB Mass Storage devices
usb 2-1: new low speed USB device using ohci_hcd and address 2
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7, max UDMA7, 488395055 sectors: LBA48 NCQ (depth 0/32)
usb 2-1: configuration #1 chosen from 1 choice
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver hiddev
ata1.00: configured for UDMA/133
scsi1 : sata_nv
input: HID 1241:1166 as /class/input/input1
input: USB HID v1.00 Mouse [HID 1241:1166] on usb-0000:00:02.0-1
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
ata2: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x3017
  Vendor: ATA       Model: SAMSUNG SP2504C   Rev: VT10
  Type:   Direct-Access                      ANSI SCSI revision: 05
ata3: SATA max UDMA/133 cmd 0x3020 ctl 0x3092 bmdma 0x2CE0 irq 201
ata4: SATA max UDMA/133 cmd 0x3030 ctl 0x30A2 bmdma 0x2CE8 irq 201
scsi3 : sata_nv
ata3: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x3027
scsi4 : sata_nv
ata4: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x3037
ata5: SATA max UDMA/133 cmd 0x3040 ctl 0x30B2 bmdma 0x2CF0 irq 185
ata6: SATA max UDMA/133 cmd 0x3050 ctl 0x30C2 bmdma 0x2CF8 irq 185
scsi5 : sata_nv
ata5: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x3047
scsi6 : sata_nv
ata6: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x3057
forcedeth: using HIGHDMA
eth0: forcedeth.c: subsystem: 01022:2b80 bound to 0000:00:08.0
hda: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB)
sda: Write Protect is off
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3 sda4 < sda5 >
sd 0:0:0:0: Attached scsi disk sda
Done.
Begin: Mounting root file system... ...
Begin: Running /scripts/local-top ...
Done.
Begin: Running /scripts/local-premount ...
kinit: name_to_dAttempting manual resume
ev_t(/dev/sda1) = sda1(8,1)
kinit: trying to resume from /dev/sda1
kinit: No resume image, doing normal boot...
Done.
kjournald starting.  Commit interval 5 seconds
Begin: Running /EXT3-fs: mounted filesystem with ordered data mode.
scripts/local-bottom ...
Done.
Done.
Begin: Running /scripts/init-bottom ...
Done.
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...ts: Compaq touchscreen protocol output
i2c_adapter i2c-0: nForce2 SMBus adapter at 0x2c40
i2c_adapter i2c-1: nForce2 SMBus adapter at 0x2c80
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
  Vendor: cnmemory  Model: cnmemory          Rev: 6.50
  Type:   Direct-Access                      ANSI SCSI revision: 00
SCSI device sdb: 1970175 512-byte hdwr sectors (1009 MB)
input: PC Speaker as /class/input/input2
sdb: Write Protect is off
sdb: assuming drive cache: write through
SCSI device sdb: 1970175 512-byte hdwr sectors (1009 MB)
sdb: Write Protect is off
sdb: assuming drive cache: write through
 sdb: sdb1
sd 2:0:0:0: Attached scsi removable disk sdb
hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...
done.
GActivating swap...Adding 7815580k swap on /dev/sda1.  Priority:-1 extents:1 across:7815580k
done.
Checking root file system...fsck 1.40-WIP (14-Nov-2006)
/dev/sda2: clean, 168003/2443200 files, 1208371/EXT3 FS on sda2, 4883760 blocks
internal journal
done.
Setting the system clock..
Cleaning up ifupdown....
Loading kernel modules...loop: loaded (max 8 devices)
ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1)
ieee1394: sbp2: Try serialize_io=0 for better performance
powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ processors (version 2.00.00)
powernow-k8: MP systems not supported by PSB BIOS structure
powernow-k8: MP systems not supported by PSB BIOS structure
done.
Loading device-mapper supportdevice-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel at redhat.com
.
Checking file systems...fsck 1.40-WIP (14-Nov-2006)
/dev/sda3: clean, 11920/4889248 files, 232043/9765511 blocks
/dev/sda5: clean, 28582/1281696 files, 207890/2560351 blocks
done.
Setting kernel variables...done.
Mounting local filesystems...kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
done.
Activating swapfile swap...done.
Detecting hardware...Setting up networking....
Configuring network interfaces...done.
Starting portmap daemon....
Setting sensors limits: done.
Setting console screen modes and fonts.
RSetting console screen modes and fonts.
Setting up ALSA...done.
INIT: Entering runlevel: 2
Starting system log daemon....
Starting kernel log daemon....
Starting virtual private network daemon:.
Starting portmap daemon...Already running..
Starting HP Linux Printing and Imaging System: hpiod hpssd.
Starting BitTorrent tracker: disabled in /etc/default/bittorrent.
Starting console-log:Couldnt get a file descriptor referring to the console
E: openvt failed. headless system?...failed.
Starting Common Unix Printing System: cupsdlp: driver loaded but no devices found
ppdev: user-space parallel port driver
.
Starting system message bus: dbus.
Starting Hardware abstraction layer: hald.
Starting DHCP D-Bus daemon: dhcdbd.
Starting network connection manager: NetworkManager.
Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
Starting network events dispatcher: NetworkManagerDispatcher.
Starting DirMngr: dirmngr.
Starting MTA: exim4.
Starting LAN Information Server: lisa.
Starting internet superserver: inetd.
Starting powernowd: required sysfs objects not found!
	Read /usr/share/doc/powernowd/README.Debian for more information.
Starting file alteration monitor: FAM.
Starting GNOME Display Manager: gdm.
Starting NFS common utilities: statd.
Starting NTP server: ntpd.
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
Starting anac(h)ronistic cron: anacron.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler: crond.
mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
Not starting K Display Manager (kdm); it is not the default display manager.
mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended

================================================



From ward at gnu.org  Fri Jun  1 17:14:55 2007
From: ward at gnu.org (Ward Vandewege)
Date: Fri, 1 Jun 2007 11:14:55 -0400
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070601144106.GA5671@flashgordon>
References: <20070601144106.GA5671@flashgordon>
Message-ID: <20070601151455.GA7454@countzero.vandewege.net>

Hi Andreas,

On Fri, Jun 01, 2007 at 04:41:06PM +0200, Andreas B. Mundt wrote:
> thanks for all suggestions so far. I can now boot the board (and my CPU, a "Brisbane") 
> with the following modifications: 
> 
> Index: src/cpu/amd/model_fxx/model_fxx_init.c
> ===================================================================
> --- src/cpu/amd/model_fxx/model_fxx_init.c      (revision 2699)
> +++ src/cpu/amd/model_fxx/model_fxx_init.c      (working copy)
> @@ -615,6 +615,7 @@
>         { X86_VENDOR_AMD, 0x40f82 },            /*        S1g1:Turion64 x2 */
>          { X86_VENDOR_AMD, 0x40ff2 }, /* DH-F2      Socket AM2: Athlon64 */
>          { X86_VENDOR_AMD, 0x50ff2 }, /* DH-F2      Socket AM2: Athlon64 */
> +        { X86_VENDOR_AMD, 0x60fb1 }, /* DH-F2???   Socket AM2: Athlon64 Brisbane*/
>          { X86_VENDOR_AMD, 0x40fc2 },            /*        S1g1:Turion64 */
>          { X86_VENDOR_AMD, 0x40f13 }, /* JH-F3      Socket F (1207): Opteron Dual Core */
>          { X86_VENDOR_AMD, 0x40f33 },            /*        AM2 : Opteron Dual Core/Athlon64 x2/ Athlon64 FX Dual Core */

Very interesting. What CPU do you have?

> I do not know if this is enough or if some other parameters should be adapted.
> Some issues remain:
> 
> -powernow does not work, and the cpu freq. is at 2.5 GHz (proprietary BIOS: max cpu freq. 2.6 GHz)

Yeah, this is probably due to the lack of acpi.

> -having booted with linuxbios, flashroom fails to erase (and therefore flash) any other BIOS

Confirmed. I have the same problem here, but have not been able to find out
why yet. Flashrom will *sometimes* work, but most of the time it won't. You
can tell during the flash if it is going to work or not; the speed of writing
will be too slow or too fast, or it will vary greatly. The writing speed for
a successful flash is uniform and moderately fast.

> -some problems with X: with the proprietary BIOS the machine freezes using the free nv driver 
> (02:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GS]). It works with linuxbios, but 
> I have to log in twice with no cursor the first time. The nvidia driver does not work with linuxbios.

Did you add the i2c workaround in xorg.conf? I have not tried the proprietary
nvidia driver. The nv driver works for me.

> -I had to use the delay in filo.c (cmp. http://www.linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial)

Yes.

> -it takes quite long to load vmlinuz and the initrd.img. Probably due to: IDE_DISK_POLL_DELAY = 1 (?)

Yes. Peter Stuge was working on a patch to speedup FILO. We should revisit
that.

> -still the "Fallback" bios is booted, although I could not find any difference in the configuration of standard and 
> fallback BIOS. The same file.elf was used.  

You can fix that with the lxbios tool; the fallback is just the default.

Thanks,
Ward.

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



From juergen127 at kreuzholzen.de  Fri Jun  1 17:59:10 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Fri, 1 Jun 2007 17:59:10 +0200
Subject: [LinuxBIOS] Question about protect mode?
In-Reply-To: <a9951d2a0705300226x504dcaedsa24f0c5691d95be0@mail.gmail.com>
References: <2386d0e70705281950q7aef237bp89a388789c2cfc6a@mail.gmail.com>
	<a9951d2a0705300226x504dcaedsa24f0c5691d95be0@mail.gmail.com>
Message-ID: <200706011759.10441.juergen127@kreuzholzen.de>

On Wednesday 30 May 2007 11:26, Rogelio Serrano wrote:
> protected mode is good; real mode is bad.

Sounds good :-))

Juergen



From svn at openbios.org  Sat Jun  2 01:13:15 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sat,  2 Jun 2007 01:13:15 +0200
Subject: [LinuxBIOS] r340 - LinuxBIOSv3/doc/design
Message-ID: <mailman.368.1355071117.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-06-02 01:13:15 +0200 (Sat, 02 Jun 2007)
New Revision: 340

Modified:
   LinuxBIOSv3/doc/design/newboot.lyx
Log:
More information, we are on the next step, which is smbus support for
dram. Per the discussion on v3 list, I am self-acking this one.

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Modified: LinuxBIOSv3/doc/design/newboot.lyx
===================================================================
--- LinuxBIOSv3/doc/design/newboot.lyx	2007-06-01 04:41:42 UTC (rev 339)
+++ LinuxBIOSv3/doc/design/newboot.lyx	2007-06-01 23:13:15 UTC (rev 340)
@@ -2077,6 +2077,8 @@
 \end_layout
 
 \begin_layout LyX-Code
+
+\size tiny
 /home/rminnich/src/bios/LinuxBIOSv3/mainboard/amd/norwich/initram.c: In function
  'spd_read_byte': /home/rminnich/src/bios/LinuxBIOSv3/mainboard/amd/norwich/init
 ram.c:30: error: implicit declaration of function 'smbus_read_byte' /home/rminnic
@@ -2122,5 +2124,320 @@
  
 \end_layout
 
+\begin_layout Paragraph
+Hold on.
+ What are we doing here? 
+\end_layout
+
+\begin_layout Standard
+We need to create an initram file for the LAR.
+ This initram file is going to set up DRAM.
+ LinuxBIOS supplies a skeleton function, which we show below, and the programmer
+ needs to supply some functions for their chipsets, so that this function
+ can work.
+ 
+\end_layout
+
+\begin_layout Standard
+What code is needed? A few things.
+ The northbridge code must supply register set functions.
+ The southbridge or superio must supply smbus read functions.
+ The basic sdram setup is found in lib/ram.c, and is dead simple:
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+void ram_initialize(int controllers, void *ctrl) {      
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+  int i;
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+       /* Set the registers we can set once to reasonable values.
+ */
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+        for (i = 0; i < controllers; i++) {
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+                printk(BIOS_INFO,
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+                       "Setting registers of RAM controller %d
+\backslash
+n", i);
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+                ram_set_registers(ctrl, i);
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+        }
+\end_layout
+
+\begin_layout LyX-Code
+
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+        /* Now setup those things we can auto detect.
+ */
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+        for (i = 0; i < controllers; i++) {
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+                printk(BIOS_INFO,
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+                  "Setting SPD based registers of RAM controller %d
+\backslash
+n", i);
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+                ram_set_spd_registers(ctrl, i);
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+        }
+\end_layout
+
+\begin_layout LyX-Code
+
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+        /* Now that everything is setup enable the RAM.
+ Some chipsets do
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+         * the work for us while on others we need to it by hand.
+          */
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+        printk(BIOS_DEBUG, "Enabling RAM
+\backslash
+n");
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+        ram_enable(controllers, ctrl);
+\end_layout
+
+\begin_layout LyX-Code
+
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+        /* RAM initialization is done.
+ */
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+        printk(BIOS_DEBUG, "RAM enabled successfully
+\backslash
+n");
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+}
+\end_layout
+
+\begin_layout Standard
+Ram_initialize is a core function of initram.
+ When it is called, RAM is not working; after it is called, RAM is working.
+ This function in turn calls functions in the northbridge code (or, in some
+ cases, CPU code; it depends on the part).
+ The basic idea is that this code is called with a pointer to an opaque
+ type (ctlr *), and an int indicating how many controllers, dram slots,
+ or whatever 
+\begin_inset Quotes eld
+\end_inset
+
+things
+\begin_inset Quotes erd
+\end_inset
+
+ there are, where a 
+\begin_inset Quotes eld
+\end_inset
+
+thing
+\begin_inset Quotes erd
+\end_inset
+
+ is totally chipset dependent.
+ The lib/ram.c code sets hardcoded settings, then sets dynamic settings by
+ querying the SPD bus, then enables the RAM.
+ This basic cycle has been refined now for eight years and has worked well
+ on many systems.
+ 
+\end_layout
+
+\begin_layout Standard
+The northbridge code has to provide three basic functions.
+ The first function, ram_set_registers, sets up basic parameters.
+ It will be called for each of the ram 
+\begin_inset Quotes eld
+\end_inset
+
+things
+\begin_inset Quotes erd
+\end_inset
+
+, where, as described above, 
+\begin_inset Quotes eld
+\end_inset
+
+thing
+\begin_inset Quotes erd
+\end_inset
+
+ can be just about anything, depending on the chipset.
+ The function will be called with the ctlr pointer, and in index in the
+ range 0..controllers-1.
+ The second function, ram_set_spd_registers, is called to tell the northbridge
+ code that it should do spd setup for 
+\begin_inset Quotes eld
+\end_inset
+
+thing
+\begin_inset Quotes erd
+\end_inset
+
+ i.
+ Finally, the northbridge-provided enable function is called.
+ 
+\end_layout
+
+\begin_layout Standard
+Any or all of these functions may be empty.
+ In the common case, they all do something.
+ These functions, in turn, may require other functions from other chipset
+ parts.
+ The most important, and common, set of functions reads SPD values using
+ the SMBUS.
+ The mainboard must configure, as part of stage2, a file to be compiled
+ which provides these functions.
+ The simplest function is called smbus_read_byte(unsigned device, unsigned
+ address).
+ This function should do any needed initialization, to keep life simple
+ for the northbridge code, and then read from SMBUS device 'device' at address
+ 'address'.
+ Typically, the device address range is 0xa0 up to 0xa8.
+ The address depends on the DRAM technology.
+ 
+\end_layout
+
+\begin_layout Standard
+All of the LinuxBIOS code that is run after this point uses the device tree;
+ none of the initram code uses the device tree.
+ The reason is simple: the device tree lives in RAM.
+ This bootstrap code is intentionally simple and does not use the device
+ tree.
+ 
+\end_layout
+
+\begin_layout Standard
+We will start by providing SMBUS functions.
+ The SMBUS for this board is supported on the AMD CS5536 chip.
+ The file we create will be in southbridge/amd/cs5536/smbus_initram.c.
+ 
+\end_layout
+
+\begin_layout Standard
+The revision numbers skip a bit here, since others are also working on V3.
+ We start with revision 339.
+ 
+\end_layout
+
+\begin_layout Subsubsection
+R339
+\end_layout
+
+\begin_layout Standard
+Get the old code:
+\end_layout
+
+\begin_layout LyX-Code
+cp LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536_early_smbus.c southbridge/amd/cs
+5536/smbus_initram.c 
+\end_layout
+
+\begin_layout Standard
+Then we need to set up the mainboard Makefile to include this file in the
+ mainboard stage2.
+ This is pretty easy: add the .o for this file to the INITRAM_OBJ in the
+ mainboard Makefile: 
+\end_layout
+
+\begin_layout LyX-Code
+
+\size tiny
+INITRAM_OBJ=$(obj)/stage0.init $(obj)/stage0.o $(obj)/mainboard/$(MAINBOARDDIR)/in
+itram.o $(obj)/southbridge/amd/cs5536/smbus_initram.o 
+\end_layout
+
+\begin_layout Standard
+Now we get lots more errors, so off we go to fix them!
+\end_layout
+
+\begin_layout Standard
+
+\end_layout
+
 \end_body
 \end_document




From bingxunshi at gmail.com  Sat Jun  2 02:51:34 2007
From: bingxunshi at gmail.com (bxshi)
Date: Sat, 2 Jun 2007 08:51:34 +0800
Subject: [LinuxBIOS] MSI interrupts
In-Reply-To: <2ea3fae10705310915q4a480cc3nab5fe071dccd0012@mail.gmail.com>
References: <f7085c470705300540x6ebbd17dyb585fe3eaea9b342@mail.gmail.com>
	<2ea3fae10705300917q77e2e593q40ecece529260ac3@mail.gmail.com>
	<f7085c470705310317p483edc83xfd5bddc1f3a0b232@mail.gmail.com>
	<2ea3fae10705310915q4a480cc3nab5fe071dccd0012@mail.gmail.com>
Message-ID: <dcdcf0740706011751s38b87764rac2f013950d2bf69@mail.gmail.com>

>
> the NIC should work, and only some problem with sata, but someone sent
> patch for sata already. or merged?


yes. Sata is Ok for broadcom/bcm5785.

bxshi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070602/50916a68/attachment.html>

From joe at smittys.pointclark.net  Sat Jun  2 03:17:39 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Fri, 01 Jun 2007 21:17:39 -0400
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070601052108.GB3251@bloms.de>
References: <20070531194024.GB3955@bloms.de>
	<20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
	<20070601052108.GB3251@bloms.de>
Message-ID: <20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>

Quoting Dieter Bloms <dieter at bloms.de>:

> Hi,
>
> On Thu, May 31, joe at smittys.pointclark.net wrote:
>
>> Here is a copy of the change log that I have made to the i82801db. I
>> am still working on my northbridge and have not been able to test it.
>> Can someone make the changes and test for me?
>
> it does compile, but I can not see anything on the serial console.
> So I think there is something wrong with my config, because about 5
> seconds after power on it beeps and beeps and beeps .... two time per
> second.
>
> I don't know where I have to look now :(
>
>
> --
> Gru?
>
>   Dieter
>
> --

Dieter,
Sounds like maybe the superio is not quite working. What kind of chip is it?

Thanks - Joe





From fengyuning1984 at gmail.com  Sat Jun  2 10:25:23 2007
From: fengyuning1984 at gmail.com (Yu-ning Feng)
Date: Sat, 2 Jun 2007 16:25:23 +0800
Subject: [LinuxBIOS] Question about protect mode?
In-Reply-To: <200705311456.32413.juergen127@kreuzholzen.de>
References: <2386d0e70705281950q7aef237bp89a388789c2cfc6a@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B1729FE34@sbjgexmb1.amd.com>
	<a505dc9d0705310200i12a3251ew16b5c8d6c968a5d9@mail.gmail.com>
	<200705311456.32413.juergen127@kreuzholzen.de>
Message-ID: <a505dc9d0706020125g2818b670p219ae47e55f1c3d8@mail.gmail.com>

2007/5/31, Juergen Beisert <juergen127 at kreuzholzen.de>:
>
> > Maybe a silly question: Isn't it that PCI needs initialization before
> > we could access it? How could we get there when the processor is
> > fetching the 1st instruction?
>
> In this case the ROM device is connected to the PCI bus, but not connected
> _as_ a PCI device!. It shares the PCI bus address/data lines only to save an
> additional bus.
> If you reuse (or misuse?) the AD[31...0] lines you can connect up to a 16MiB
> ROM device with 8 bit data width (AD[31...8] as addressbus, AD[7..0] as data
> bus). Add also three separate additional lines (read, write, chip select) and
> you are done. Whenever the chipset generates a ROM device access cycle, it
> does not generate a valid PCI cycle as it only uses the AD[31...0] lines! So
> this does not hurt any other *real* PCI device on the same bus.
> But this may work only at system start. Later on some PCI master devices could
> inhibit this mode. But it doesn't matter: At this point of time the ROM
> content runs from system RAM, so there is no more need to access the real ROM
> device (maybe only to reprogramm it).
>
> Hope it helps.
>
> Juergen
>

Please check whether I have understood correctly.

The processor lauches a cycle with address = 0xFFFF_FFF0. The north
bridge chipset explains this address. In this case, it signals the
read line and chip select line which connect the ROM device, and
select an address of the ROM device through PCI bus AD[31..8]. To the
north bridge, the ROM device is like a common BIOS ROM except that it
uses PCI bus to exchange information. Then the ROM device uses
AD[7..0] to send 1 byte of data back to the north bridge. That 1 byte
of data is a portion of the 1st instruction.

Thanks.

Yu-ning



From stepan at coresystems.de  Sat Jun  2 11:03:15 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 2 Jun 2007 11:03:15 +0200
Subject: [LinuxBIOS] LinuxBIOS at the Linux Tag 2007 in Berlin
Message-ID: <20070602090315.GA15078@coresystems.de>

Hi there,

The LinuxBIOS booth at the Linux Tag in Berlin is a great success. Thank
you very much to all people contributing their time and effort here at
the booth to make this possible, and thank you very much to all
visitors. It has been a couple of very nice and successful days for the
LinuxBIOS project. Thank you everyone.

See the pictures: http://www.stefan-reinauer.de/?p=9

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From corey_osgood at verizon.net  Sat Jun  2 12:48:05 2007
From: corey_osgood at verizon.net (Corey Osgood)
Date: Sat, 02 Jun 2007 06:48:05 -0400
Subject: [LinuxBIOS] LinuxBIOS at the Linux Tag 2007 in Berlin
In-Reply-To: <20070602090315.GA15078@coresystems.de>
References: <20070602090315.GA15078@coresystems.de>
Message-ID: <46614AE5.8050703@verizon.net>

Stefan Reinauer wrote:
> Hi there,
> 
> The LinuxBIOS booth at the Linux Tag in Berlin is a great success. Thank
> you very much to all people contributing their time and effort here at
> the booth to make this possible, and thank you very much to all
> visitors. It has been a couple of very nice and successful days for the
> LinuxBIOS project. Thank you everyone.
> 
> See the pictures: http://www.stefan-reinauer.de/?p=9
> 
> Stefan
> 

Great to hear things went well! Wish I could have been there

-Corey



From darmawan.salihun at gmail.com  Sat Jun  2 13:00:55 2007
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Sat, 02 Jun 2007 18:00:55 +0700
Subject: [LinuxBIOS] LinuxBIOS at the Linux Tag 2007 in Berlin
In-Reply-To: <20070602090315.GA15078@coresystems.de>
References: <20070602090315.GA15078@coresystems.de>
Message-ID: <46614DE7.1070107@gmail.com>

Ha..ha..ha..., I saw my book there :P. You put it right there  Stepan 
:LoL: 
I wonder if some visitors take a look at it ;-).

Anyway, nice setup there. I hope someday I can attend LinuxBIOS events.

Darmawan

Stefan Reinauer wrote:
> Hi there,
>
> The LinuxBIOS booth at the Linux Tag in Berlin is a great success. Thank
> you very much to all people contributing their time and effort here at
> the booth to make this possible, and thank you very much to all
> visitors. It has been a couple of very nice and successful days for the
> LinuxBIOS project. Thank you everyone.
>
> See the pictures: http://www.stefan-reinauer.de/?p=9
>
> Stefan
>
>   




From corey_osgood at verizon.net  Sat Jun  2 13:54:41 2007
From: corey_osgood at verizon.net (Corey Osgood)
Date: Sat, 02 Jun 2007 07:54:41 -0400
Subject: [LinuxBIOS] [RFC] i82801 generic patch
Message-ID: <46615A81.9080509@verizon.net>

The attached patch is a unified version of the current ports of the
i82801 series currently in LinuxBIOS. Since most of the ports are nearly
identical, I've taken for each file and chosen the cleanest or best
version of the code, then checked over the datasheets to *some* of the
series, including the aa, ba, ca, and db, to make sure that it would
work. I've also made some changes here and there, mostly cleanup and
clarification. The only things left to look at are the huge difference
between this version's lpc init and the i82801er's, finding a better way
to select which chip is present on the board, and gpl headers in all
files. Anyways, comments, suggestions, even flames are welcome ;)
Testing on other chips can be done at this point as well, this is tested
and working on one model, the i82801aa.

-Corey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i82801_generic.patch
Type: text/x-patch
Size: 38744 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070602/af58f48b/attachment.patch>

From corey_osgood at verizon.net  Sat Jun  2 14:00:04 2007
From: corey_osgood at verizon.net (Corey Osgood)
Date: Sat, 02 Jun 2007 08:00:04 -0400
Subject: [LinuxBIOS] [RFC] i82801 generic patch
In-Reply-To: <46615A81.9080509@verizon.net>
References: <46615A81.9080509@verizon.net>
Message-ID: <46615BC4.3020102@verizon.net>

Corey Osgood wrote:
> Testing on other chips can be done at this point as well, this is tested
> and working on one model, the i82801aa.

Whoops, forgot to mention, usage is pretty straightforward. In your
mainboard's Options.lb, add

uses I82801_MODEL
uses I82801<yourmodel>

default I82810_MODEL = I82801<yourmodel>

then in the devices section below use "southbridge/intel/i82801xx"
instead of your model's name. Thanks!

-Corey



From svn at openbios.org  Sat Jun  2 14:28:58 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sat,  2 Jun 2007 14:28:58 +0200
Subject: [LinuxBIOS] r341 - in LinuxBIOSv3: . arch/x86
Message-ID: <mailman.369.1355071117.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-02 14:28:58 +0200 (Sat, 02 Jun 2007)
New Revision: 341

Modified:
   LinuxBIOSv3/Makefile
   LinuxBIOSv3/arch/x86/Makefile
Log:
Cosmetic fixes (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: LinuxBIOSv3/Makefile
===================================================================
--- LinuxBIOSv3/Makefile	2007-06-01 23:13:15 UTC (rev 340)
+++ LinuxBIOSv3/Makefile	2007-06-02 12:28:58 UTC (rev 341)
@@ -45,7 +45,7 @@
 HOSTCC     := gcc
 HOSTCXX    := g++
 HOSTCFLAGS := -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer \
-	      -Wno-unused -Wno-sign-compare 
+	      -Wno-unused -Wno-sign-compare
 
 LEX        := flex
 LYX        := lyx

Modified: LinuxBIOSv3/arch/x86/Makefile
===================================================================
--- LinuxBIOSv3/arch/x86/Makefile	2007-06-01 23:13:15 UTC (rev 340)
+++ LinuxBIOSv3/arch/x86/Makefile	2007-06-02 12:28:58 UTC (rev 341)
@@ -29,12 +29,12 @@
 #
 # Build the ROM Image / LAR archive
 #
-# LinuxBIOS v3 is completely modular. One module, the bootblock (stage0), 
-# is mandatory. All modules are packed together in a LAR archive. 
+# LinuxBIOS v3 is completely modular. One module, the bootblock (stage0),
+# is mandatory. All modules are packed together in a LAR archive.
 # The LAR archive may contain any number of stages, payloads and option ROMs.
 #
 
-ROM_SIZE := $(shell expr $(CONFIG_LINUXBIOS_ROMSIZE_KB) \* 1024 )
+ROM_SIZE := $(shell expr $(CONFIG_LINUXBIOS_ROMSIZE_KB) \* 1024)
 
 $(obj)/linuxbios.rom: $(obj)/linuxbios.bootblock $(obj)/util/lar/lar lzma $(obj)/linuxbios.initram $(obj)/linuxbios.stage2 $(obj)/option_table payload
 	$(Q)rm -rf $(obj)/lar.tmp
@@ -64,17 +64,18 @@
 
 STAGE0_LIB_OBJ       = uart8250.o mem.o elfboot.o lar.o delay.o vtxprintf.o \
 		       vsprintf.o console.o
-STAGE0_ARCH_X86_OBJ  = cachemain.o serial.o archelfboot.o speaker.o udelay_io.o mc146818rtc.o
+STAGE0_ARCH_X86_OBJ  = cachemain.o serial.o archelfboot.o speaker.o \
+		       udelay_io.o mc146818rtc.o
 
 ifeq ($(CONFIG_CPU_I586),y)
 	STAGE0_CAR_OBJ = stage0_i586.o
-else 
+else
 ifeq ($(CONFIG_CPU_AMD_GEODELX),y)
 	STAGE0_CAR_OBJ = stage0_amd_geodelx.o
 else
 	STAGE0_CAR_OBJ = stage0_i586.o
-endif 
 endif
+endif
 
 
 STAGE0_OBJ := $(patsubst %,$(obj)/lib/%,$(STAGE0_LIB_OBJ)) \
@@ -82,13 +83,13 @@
 	      $(patsubst %,$(obj)/arch/x86/%,$(STAGE0_CAR_OBJ))
 
 $(obj)/stage0.init: $(STAGE0_OBJ)
-	$(Q)# We need to be careful. If stage0.o gets bigger than 
-	$(Q)# 0x4000 - 0x100, we will end up with a 4 gig file. 
+	$(Q)# We need to be careful. If stage0.o gets bigger than
+	$(Q)# 0x4000 - 0x100, we will end up with a 4 gig file.
 	$(Q)# I wonder if that behavior is on purpose.
 
 	$(Q)# Note: we invoke gcc (instead of ld directly) here, as we hit
-	$(Q)# strange problems in the past. It seems that only gcc knows how to
-	$(Q)# properly invoke ld.
+	$(Q)# strange problems in the past. It seems that only gcc knows how
+	$(Q)# to properly invoke ld.
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(CC) -nostdlib -static -T $(src)/arch/x86/ldscript.ld \
 		$(STAGE0_OBJ) -o $(obj)/stage0.o
@@ -109,10 +110,11 @@
 # TODO: This should be compressed with the default compressor.
 #
 
-STAGE2_LIB_OBJ       = stage2.o clog2.o mem.o malloc.o tables.o delay.o compute_ip_checksum.o
+STAGE2_LIB_OBJ       = stage2.o clog2.o mem.o malloc.o tables.o delay.o \
+		       compute_ip_checksum.o
 
 STAGE2_ARCH_X86_OBJ  = archtables.o linuxbios_table.o udelay_io.o
-STAGE2_ARCH_X86_OBJ += pci_ops_auto.o pci_ops_conf1.o pci_ops_conf2.o 
+STAGE2_ARCH_X86_OBJ += pci_ops_auto.o pci_ops_conf1.o pci_ops_conf2.o
 STAGE2_ARCH_X86_OBJ += keyboard.o i8259.o isa-dma.o
 
 STAGE2_DYNAMIC_OBJ   = statictree.o
@@ -139,7 +141,7 @@
 	$(Q)# leave a .o with full symbols in it for debugging.
 	$(Q)printf "  LD      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(LD) -R $(obj)/stage0.o -Ttext 0x1000 --entry=stage2 \
-		  -o $(obj)/linuxbios.stage2.o $(STAGE2_OBJ) 
+		  -o $(obj)/linuxbios.stage2.o $(STAGE2_OBJ)
 	$(Q)printf "  OBJCOPY $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(OBJCOPY) -O binary $(obj)/linuxbios.stage2.o $(obj)/linuxbios.stage2
 
@@ -174,8 +176,8 @@
 $(obj)/arch/x86/stage0%.o: $(src)/arch/x86/stage0%.S
 	$(Q)printf "  CC      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(CC) -E $(LINUXBIOSINCLUDE) $< \
-		-o $(obj)/arch/x86/stage0_asm.s -DBOOTBLK=0x1f00 -DRESRVED=0xf0 \
-		-DDATE=\"`date +%Y/%m/%d`\"
+		-o $(obj)/arch/x86/stage0_asm.s -DBOOTBLK=0x1f00 \
+		-DRESRVED=0xf0 -DDATE=\"`date +%Y/%m/%d`\"
 	$(Q)printf "  AS      $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)$(AS) $(obj)/arch/x86/stage0_asm.s -o $@
 




From dieter at bloms.de  Sat Jun  2 14:35:42 2007
From: dieter at bloms.de (Dieter Bloms)
Date: Sat, 2 Jun 2007 14:35:42 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
References: <20070531194024.GB3955@bloms.de>
	<20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
	<20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
Message-ID: <20070602123541.GD3251@bloms.de>

Hi,

On Fri, Jun 01, joe at smittys.pointclark.net wrote:

> Quoting Dieter Bloms <dieter at bloms.de>:
> 
> Sounds like maybe the superio is not quite working. What kind of chip is it?

it is a winbond W83627HF-AW


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070602/92cda261/attachment.sig>

From juergen127 at kreuzholzen.de  Sat Jun  2 15:54:12 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Sat, 2 Jun 2007 15:54:12 +0200
Subject: [LinuxBIOS] Question about protect mode?
In-Reply-To: <a505dc9d0706020125g2818b670p219ae47e55f1c3d8@mail.gmail.com>
References: <2386d0e70705281950q7aef237bp89a388789c2cfc6a@mail.gmail.com>
	<200705311456.32413.juergen127@kreuzholzen.de>
	<a505dc9d0706020125g2818b670p219ae47e55f1c3d8@mail.gmail.com>
Message-ID: <200706021554.12443.juergen127@kreuzholzen.de>

On Saturday 02 June 2007 10:25, Yu-ning Feng wrote:
> Please check whether I have understood correctly.
>
> The processor lauches a cycle with address = 0xFFFF_FFF0. The north
> bridge chipset explains this address. In this case, it signals the
> read line and chip select line which connect the ROM device, and
> select an address of the ROM device through PCI bus AD[31..8]. To the
> north bridge, the ROM device is like a common BIOS ROM except that it
> uses PCI bus to exchange information. Then the ROM device uses
> AD[7..0] to send 1 byte of data back to the north bridge. That 1 byte
> of data is a portion of the 1st instruction.

This could be a valid scenario, yes.

Juergen



From joe at smittys.pointclark.net  Sat Jun  2 16:17:21 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sat, 02 Jun 2007 10:17:21 -0400
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070602123541.GD3251@bloms.de>
References: <20070531194024.GB3955@bloms.de>
	<20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
	<20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
Message-ID: <20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>



> Hi,
>
> On Fri, Jun 01, joe at smittys.pointclark.net wrote:
>
>> Quoting Dieter Bloms <dieter at bloms.de>:
>>
>> Sounds like maybe the superio is not quite working. What kind of chip is it?
>
> it is a winbond W83627HF-AW
>
>

Hmm, on the LB website there is a big ? next to the winbond W83627HF,  
Has anyone else had sucess wih this chip?

Thanks - Joe




From jerj at coplanar.net  Sat Jun  2 20:25:59 2007
From: jerj at coplanar.net (Jeremy Jackson)
Date: Sat, 02 Jun 2007 14:25:59 -0400
Subject: [LinuxBIOS] Question about protect mode?
In-Reply-To: <a505dc9d0706020125g2818b670p219ae47e55f1c3d8@mail.gmail.com>
References: <2386d0e70705281950q7aef237bp89a388789c2cfc6a@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B1729FE34@sbjgexmb1.amd.com>
	<a505dc9d0705310200i12a3251ew16b5c8d6c968a5d9@mail.gmail.com>
	<200705311456.32413.juergen127@kreuzholzen.de>
	<a505dc9d0706020125g2818b670p219ae47e55f1c3d8@mail.gmail.com>
Message-ID: <1180808759.8397.27.camel@ragnarok>

Juergen,

Can you please explain which chipset northbridge does this?  I've never
seen one that uses the PCI bus in this fashion, but I'd like to know if
there is one.

http://www.intel.com/design/chipsets/440/documentation.htm

Everyone, please look at Intel 440BX chipset docs for a clear
explanation.  It's an older chipset but that helps to explain the
history of some things.

Northbridge 440BX

http://www.intel.com/design/chipsets/datashts/290633.htm

Page 1-2 has an excellent system diagram.

The CPU reset vector is 0xFFFF_FFF0.  After reset the Intel i82443BX
northbridge decodes everything to PCI.  The southbridge will also
respond to aliases below 16M and 1M.  The usual sequence of the BIOS is
then to configure RAM and enable decoding.  At that point, the alias
below 1M disappears (going to RAM now), and possibly the one below 16M
depending on how much RAM there is.

After that, it is possible to copy BIOS to RAM, and write-protect it for
"shadowing" and legacy support of BIOS at 0xF0000.  

It is also possible to enable a memory "hole" from 15M to 16M and access
the BIOS from there.

Page 4-5 explains:

High BIOS Area (FFE0_0000h ?FFFF_FFFFh)

The top 2 MB of the Extended Memory Region is reserved for System BIOS
(High BIOS),
extended BIOS for PCI devices, and the A20 alias of the system BIOS. CPU
begins execution from
the High BIOS after reset. This region is mapped to PCI so that...


Southbridge PIIX4E:

http://www.intel.com/design/intarch/datashts/290562.htm

Page 12 has another useful system diagram showing the BIOS.

The PIIX4E i82371EB claims the 0xFFFF_FFF0 cycle, and aliases to top of
X-bus (1M and 16M) which is where the BIOS rom is connected.  This is
done after reset, even without PCI configuration, as a special case to
allow booting.

Page 155 gives the details.

Regards,

Jeremy

On Sat, 2007-06-02 at 16:25 +0800, Yu-ning Feng wrote:
> 2007/5/31, Juergen Beisert <juergen127 at kreuzholzen.de>:
> >
> > > Maybe a silly question: Isn't it that PCI needs initialization before
> > > we could access it? How could we get there when the processor is
> > > fetching the 1st instruction?
> >
> > In this case the ROM device is connected to the PCI bus, but not connected
> > _as_ a PCI device!. It shares the PCI bus address/data lines only to save an
> > additional bus.
> > If you reuse (or misuse?) the AD[31...0] lines you can connect up to a 16MiB
> > ROM device with 8 bit data width (AD[31...8] as addressbus, AD[7..0] as data
> > bus). Add also three separate additional lines (read, write, chip select) and
> > you are done. Whenever the chipset generates a ROM device access cycle, it
> > does not generate a valid PCI cycle as it only uses the AD[31...0] lines! So
> > this does not hurt any other *real* PCI device on the same bus.
> > But this may work only at system start. Later on some PCI master devices could
> > inhibit this mode. But it doesn't matter: At this point of time the ROM
> > content runs from system RAM, so there is no more need to access the real ROM
> > device (maybe only to reprogramm it).
> >
> > Hope it helps.
> >
> > Juergen
> >
> 
> Please check whether I have understood correctly.
> 
> The processor lauches a cycle with address = 0xFFFF_FFF0. The north
> bridge chipset explains this address. In this case, it signals the
> read line and chip select line which connect the ROM device, and
> select an address of the ROM device through PCI bus AD[31..8]. To the
> north bridge, the ROM device is like a common BIOS ROM except that it
> uses PCI bus to exchange information. Then the ROM device uses
> AD[7..0] to send 1 byte of data back to the north bridge. That 1 byte
> of data is a portion of the 1st instruction.
> 
> Thanks.
> 
> Yu-ning
> 




From jerj at coplanar.net  Sat Jun  2 21:29:08 2007
From: jerj at coplanar.net (Jeremy Jackson)
Date: Sat, 02 Jun 2007 15:29:08 -0400
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux
	compatable	BIOS programmer ?]
In-Reply-To: <4300973D.4020601@linuxmachines.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<200508130547.j7D5l8D30326@ecstasy1.winternet.com>
	<42FF0E53.4010902@linuxmachines.com>
	<200508151056.38490.p.millar@physics.gla.ac.uk>
	<4300973D.4020601@linuxmachines.com>
Message-ID: <1180812548.8397.30.camel@ragnarok>

Sorry to jump in a bit late here, but for parallel flash, what about
using a NIC with a boot ROM socket?  I've used that for both PLCC32 and
DIP32 parts.

Regards,

Jeremy




From juergen127 at kreuzholzen.de  Sat Jun  2 22:25:55 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Sat, 2 Jun 2007 22:25:55 +0200
Subject: [LinuxBIOS] Question about protect mode?
In-Reply-To: <1180808759.8397.27.camel@ragnarok>
References: <2386d0e70705281950q7aef237bp89a388789c2cfc6a@mail.gmail.com>
	<a505dc9d0706020125g2818b670p219ae47e55f1c3d8@mail.gmail.com>
	<1180808759.8397.27.camel@ragnarok>
Message-ID: <200706022225.56454.juergen127@kreuzholzen.de>

Hi Jeremy,

On Saturday 02 June 2007 20:25, Jeremy Jackson wrote:
> Can you please explain which chipset northbridge does this?  I've never
> seen one that uses the PCI bus in this fashion, but I'd like to know if
> there is one.

Sorry, I had no special x86 chipset in mind. This is only a possible scenario 
one can use to save an additional bus mostly used at system start up only.

I only know a PowerPC (405GP if I remember right, its a SoC) processor that 
supports such kind of ROM device addressing/connecting.

> http://www.intel.com/design/chipsets/440/documentation.htm
>
> Everyone, please look at Intel 440BX chipset docs for a clear
> explanation.  It's an older chipset but that helps to explain the
> history of some things.
>
> Northbridge 440BX
>
> http://www.intel.com/design/chipsets/datashts/290633.htm
>
> Page 1-2 has an excellent system diagram.

And it shows the ROM is connected to the ISA bus, behind the southbridge. 
Nothing PCI specific.

> Southbridge PIIX4E:
>
> http://www.intel.com/design/intarch/datashts/290562.htm
>
> Page 12 has another useful system diagram showing the BIOS.
>
> The PIIX4E i82371EB claims the 0xFFFF_FFF0 cycle, and aliases to top of
> X-bus (1M and 16M) which is where the BIOS rom is connected.  This is
> done after reset, even without PCI configuration, as a special case to
> allow booting.
>
> Page 155 gives the details.

Seems also the ISA bus is where the ROM device is connected to. And to reach 
the ISA bus, you must reach the southbridge first. So that's why the PCI bus 
is relevant here. But not to access the ROM device itself.

So it does not match my scenario where the ROM device is directly connected to 
PCI lines.

Juergen



From andi.mundt at web.de  Sat Jun  2 17:34:40 2007
From: andi.mundt at web.de (Andreas B. Mundt)
Date: Sat, 2 Jun 2007 17:34:40 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070601151455.GA7454@countzero.vandewege.net>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
Message-ID: <20070602153439.GA3413@flashgordon>

Hi Ward, 

On Fri, Jun 01, 2007 at 11:14:55AM -0400, Ward Vandewege wrote:
> >          { X86_VENDOR_AMD, 0x50ff2 }, /* DH-F2      Socket AM2: Athlon64 */
> > +        { X86_VENDOR_AMD, 0x60fb1 }, /* DH-F2???   Socket AM2: Athlon64 Brisbane*/
> >          { X86_VENDOR_AMD, 0x40fc2 },            /*        S1g1:Turion64 */
> 
> Very interesting. What CPU do you have?
> 
The CPU is a "AMD Athlon 64 X2 4800+" EE 65W (Brisbane, 65nm). Seems to be
not very common (http://en.wikipedia.org/wiki/Athlon_64_X2  -> "This led to 
only a small number of the Socket AM2 Athlon 64 X2 4000+, 4400+, 4800+ and 
5200+ models being produced."...?)   
> 
> > -some problems with X: with the proprietary BIOS the machine freezes using the free nv driver 
> > (02:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GS]). It works with linuxbios, but 
> > I have to log in twice with no cursor the first time. The nvidia driver does not work with linuxbios.
> 
> Did you add the i2c workaround in xorg.conf? I have not tried the proprietary
> nvidia driver. The nv driver works for me.
>
I checked this by now, but see no difference. However, there seems to be
something strange with my video card or monitor unrelated to the BIOS.
After some time the Xserver uses 100% CPU and freezes, in advance graphic
errors appear (only nv driver). Perhaps the graphics chip gets too hot which 
does not happen with the closed nvidia driver (better power management?).
I placed a fan now near the (passively cooled) card, and up to now it works
fine. Could you send me your xorg.conf? It may help getting nv working with the
proprietary BIOS.
> 
> > -still the "Fallback" bios is booted, although I could not find any difference in the configuration of standard and 
> > fallback BIOS. The same file.elf was used.  
> 
> You can fix that with the lxbios tool; the fallback is just the default.
> 
Thanks for that tip! I already downloaded it-

Regards,

	Andi
 



From nikolaypetukhov at gmail.com  Sat Jun  2 20:20:10 2007
From: nikolaypetukhov at gmail.com (Nikolay Petukhov)
Date: Sun, 3 Jun 2007 00:20:10 +0600
Subject: [LinuxBIOS] new target iei juki-511p/rocky-512
Message-ID: <e24af7500706021120nbfb8062kbde1a1c498aaeded@mail.gmail.com>

Hi,

Here's a one patch for IEI JUKI-511P and IEI ROCKY-512 half-size boards.
This boards are little difference, that's why it has one patch.

Linux with patchs from Juergen Beisert
(http://www.linuxbios.org/pipermail/linuxbios/2007-May/020932.html)
boots and work fine(ide, usb, ethernet, serial, keyboard and sound
work normally).

Problems:
Filo load bzImage only from ide0.
Video don't work, no any monitor output.

JUKI-511P ? PCISA half?size board:
Specification:
CPU: Geode GX1 300Mhz
System Chipset: cs5530
SuperIO: Winbond w83977f-a
Ethernet: rtl8100B
Memory: one DIMM
AC97: AD1881

ROCKY-512 ? ISA half?size board:
Specification:
CPU: Geode GX1 300Mhz
System Chipset: cs5530
SuperIO: Winbond w83977f-a
Ethernet: rtl8100B
Memory: 64MB on board and one DIMM
AC97: no sound chip

Here's also dmesg output.

-- 
Nikolay
-------------- next part --------------
diff -Nru LinuxBIOSv2-2700/src/mainboard/iei/juki511p/auto.c LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/auto.c
--- LinuxBIOSv2-2700/src/mainboard/iei/juki511p/auto.c	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/auto.c	2007-06-02 20:02:10.000000000 +0600
@@ -0,0 +1,67 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define ASSEMBLY 1
+
+#include <stdint.h>
+#include <device/pci_def.h>
+#include <arch/io.h>
+#include <device/pnp_def.h>
+#include <arch/romcc_io.h>
+#include <arch/hlt.h>
+#include "pc80/serial.c"
+#include "arch/i386/lib/console.c"
+#include "ram/ramtest.c"
+#include "superio/winbond/w83977fa/w83977fa_early_serial.c"
+#include "cpu/x86/bist.h"
+
+#define SERIAL_DEV PNP_DEV(0x3f0, W83977FA_SP1)
+
+#include "northbridge/amd/gx1/raminit.c"
+
+void udelay(int usecs) 
+{
+	int i;
+	for(i = 0; i < usecs; i++)
+		outb(i&0xff, 0x80);
+}
+#include "lib/delay.c"
+
+static void main(unsigned long bist)
+{
+	/* Initialize the serial console. */
+	w83977fa_enable_serial(SERIAL_DEV, TTYS0_BASE);
+
+	uart_init();
+	console_init();
+
+	/* Halt if there was a built in self test failure. */
+	report_bist_failure(bist);
+
+	/* Disable Watchdog Timer. */
+	inb(0x043);
+	inb(0x843);
+
+	/* Initialize RAM. */
+	sdram_init();
+
+	/* Check RAM. */
+	/* ram_check(0x00000000, 640 * 1024); */
+}
diff -Nru LinuxBIOSv2-2700/src/mainboard/iei/juki511p/chip.h LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/chip.h
--- LinuxBIOSv2-2700/src/mainboard/iei/juki511p/chip.h	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/chip.h	2007-06-02 19:06:20.000000000 +0600
@@ -0,0 +1,25 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+extern struct chip_operations mainboard_iei_juki511p_ops;
+
+struct mainboard_iei_juki511p_config {
+	int nothing;
+};
diff -Nru LinuxBIOSv2-2700/src/mainboard/iei/juki511p/cmos.layout LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/cmos.layout
--- LinuxBIOSv2-2700/src/mainboard/iei/juki511p/cmos.layout	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/cmos.layout	2007-05-15 13:11:09.000000000 +0600
@@ -0,0 +1,73 @@
+entries
+
+#start-bit length  config config-ID    name
+#0            8       r       0        seconds
+#8            8       r       0        alarm_seconds
+#16           8       r       0        minutes
+#24           8       r       0        alarm_minutes
+#32           8       r       0        hours
+#40           8       r       0        alarm_hours
+#48           8       r       0        day_of_week
+#56           8       r       0        day_of_month
+#64           8       r       0        month
+#72           8       r       0        year
+#80           4       r       0        rate_select
+#84           3       r       0        REF_Clock
+#87           1       r       0        UIP
+#88           1       r       0        auto_switch_DST
+#89           1       r       0        24_hour_mode
+#90           1       r       0        binary_values_enable
+#91           1       r       0        square-wave_out_enable
+#92           1       r       0        update_finished_enable
+#93           1       r       0        alarm_interrupt_enable
+#94           1       r       0        periodic_interrupt_enable
+#95           1       r       0        disable_clock_updates
+#96         288       r       0        temporary_filler
+0          384       r       0        reserved_memory
+384          1       e       4        boot_option
+385          1       e       4        last_boot
+386          1       e       1        ECC_memory
+388          4       r       0        reboot_bits
+392          3       e       5        baud_rate
+400          1       e       1        power_on_after_fail
+412          4       e       6        debug_level
+416          4       e       7        boot_first
+420          4       e       7        boot_second
+424          4       e       7        boot_third
+428          4       h       0        boot_index
+432	     8       h       0        boot_countdown
+1008         16      h       0        check_sum
+
+enumerations
+
+#ID value   text
+1     0     Disable
+1     1     Enable
+2     0     Enable
+2     1     Disable
+4     0     Fallback
+4     1     Normal
+5     0     115200
+5     1     57600
+5     2     38400
+5     3     19200
+5     4     9600
+5     5     4800
+5     6     2400
+5     7     1200
+6     6     Notice
+6     7     Info
+6     8     Debug
+6     9     Spew
+7     0     Network
+7     1     HDD
+7     2     Floppy
+7     8     Fallback_Network
+7     9     Fallback_HDD
+7     10    Fallback_Floppy
+#7     3     ROM
+
+checksums
+
+checksum 392 1007 1008
+
diff -Nru LinuxBIOSv2-2700/src/mainboard/iei/juki511p/Config.lb LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/Config.lb
--- LinuxBIOSv2-2700/src/mainboard/iei/juki511p/Config.lb	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/Config.lb	2007-06-02 19:04:47.000000000 +0600
@@ -0,0 +1,165 @@
+##
+## Compute the location and size of where this firmware image
+## (linuxBIOS plus bootloader) will live in the boot rom chip.
+##
+default ROM_SIZE = 256 * 1024 
+default ROM_SECTION_SIZE   = ROM_SIZE
+default ROM_SECTION_OFFSET = 0
+
+##
+## Compute the start location and size size of
+## The linuxBIOS bootloader.
+##
+default PAYLOAD_SIZE            = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE )
+default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1)
+
+##
+## Compute where this copy of linuxBIOS will start in the boot rom
+##
+default _ROMBASE      = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE )
+
+##
+## Compute a range of ROM that can cached to speed up linuxBIOS,
+## execution speed.
+##
+## XIP_ROM_SIZE must be a power of 2.
+## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE
+##
+default XIP_ROM_SIZE=65536
+default XIP_ROM_BASE = ( _ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE )
+
+##
+## Set all of the defaults for an x86 architecture
+##
+
+arch i386 end
+
+##
+## Build the objects we have code for in this directory.
+##
+
+driver mainboard.o
+
+if HAVE_PIRQ_TABLE object irq_tables.o end
+#object reset.o
+
+##
+## Romcc output
+##
+makerule ./failover.E
+	depends "$(MAINBOARD)/failover.c ./romcc" 
+	action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/failover.c -o $@"
+end
+
+makerule ./failover.inc
+	depends "$(MAINBOARD)/failover.c ./romcc"
+	action "./romcc    -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/failover.c -o $@"
+end
+
+makerule ./auto.E 
+	depends	"$(MAINBOARD)/auto.c option_table.h ./romcc" 
+	action	"./romcc -E -mcpu=i386 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
+end
+makerule ./auto.inc 
+	depends "$(MAINBOARD)/auto.c option_table.h ./romcc"
+	action	"./romcc    -mcpu=i386 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
+end
+
+##
+## Build our 16 bit and 32 bit linuxBIOS entry code
+##
+mainboardinit cpu/x86/16bit/entry16.inc
+mainboardinit cpu/x86/32bit/entry32.inc
+ldscript /cpu/x86/16bit/entry16.lds
+ldscript /cpu/x86/32bit/entry32.lds
+
+##
+## Build our reset vector (This is where linuxBIOS is entered)
+##
+mainboardinit cpu/x86/16bit/reset16.inc 
+ldscript /cpu/x86/16bit/reset16.lds 
+
+### Should this be in the northbridge code?
+mainboardinit arch/i386/lib/cpu_reset.inc
+
+##
+## Include an id string (For safe flashing)
+##
+mainboardinit arch/i386/lib/id.inc
+ldscript /arch/i386/lib/id.lds
+
+###
+### O.k. We aren't just an intermediary anymore!
+###
+
+##
+## Setup RAM
+##
+mainboardinit cpu/x86/fpu/enable_fpu.inc
+mainboardinit cpu/amd/model_gx1/cpu_setup.inc
+mainboardinit cpu/amd/model_gx1/gx_setup.inc
+mainboardinit ./auto.inc
+
+##
+## Include the secondary Configuration files 
+##
+#dir /pc80
+#config chip.h
+
+chip northbridge/amd/gx1
+  device pci_domain 0 on 
+    device pci 0.0 on end
+      chip southbridge/amd/cs5530
+
+        device pci 12.0 on
+          chip superio/winbond/w83977fa
+            device pnp 3f0.0 on		# FDC
+              irq 0x70 = 6
+            end
+            device pnp 3f0.1 on		# Parallel Port
+                io 0x60 = 0x378
+               irq 0x70 = 7
+            end
+            device pnp 3f0.2 on		# COM1
+               io 0x60 = 0x3f8
+              irq 0x70 = 4
+            end
+            register "com1" = "{115200}"
+            device pnp 3f0.3 on		# COM2
+                io 0x60 = 0x2f8
+               irq 0x70 = 3
+            end
+            register "com2" = "{115200}"
+            device pnp 3f0.4 on		# RTC
+            end
+            device pnp 3f0.5 on		# Keyboard
+               io 0x60 = 0x60
+               io 0x62 = 0x64
+              irq 0x70 = 0x01     # int  1 for PS/2 keyboard
+              irq 0x72 = 0x0c     # int 12 for PS/2 mouse
+            end
+            device pnp 3f0.6 off	# IR
+            end
+            device pnp 3f0.7 off	# GPIO1
+            end
+            device pnp 3f0.8 off	# GPIO
+            end
+          end
+        device pci 12.1 on  end		# SMI
+        device pci 12.2 on  end		# IDE
+        device pci 12.3 on  end 	# Audio
+      	device pci 12.4 on  end		# VGA onboard
+       
+      end
+
+      device pci 0e.0 on  end		# ETH0
+      device pci 13.0 on end		# USB
+      
+    end
+  end
+
+  chip cpu/amd/model_gx1
+  end
+
+end
+
diff -Nru LinuxBIOSv2-2700/src/mainboard/iei/juki511p/failover.c LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/failover.c
--- LinuxBIOSv2-2700/src/mainboard/iei/juki511p/failover.c	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/failover.c	2007-06-02 18:48:33.000000000 +0600
@@ -0,0 +1,53 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define ASSEMBLY 1
+
+#include <stdint.h>
+#include <device/pci_def.h>
+#include <device/pci_ids.h>
+#include <arch/io.h>
+#include "arch/romcc_io.h"
+#include "pc80/mc146818rtc_early.c"
+
+static unsigned long main(unsigned long bist)
+{
+	/* This is the primary cpu how should I boot? */
+	if (do_normal_boot()) {
+		goto normal_image;
+	}
+	else {
+		goto fallback_image;
+	}
+ normal_image:
+	asm volatile ("jmp __normal_image" 
+		: /* outputs */ 
+		: "a" (bist) /* inputs */
+		: /* clobbers */
+		);
+ cpu_reset:
+	asm volatile ("jmp __cpu_reset"
+		: /* outputs */ 
+		: "a"(bist) /* inputs */
+		: /* clobbers */
+		);
+ fallback_image:
+	return bist;
+}
diff -Nru LinuxBIOSv2-2700/src/mainboard/iei/juki511p/irq_tables.c LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/irq_tables.c
--- LinuxBIOSv2-2700/src/mainboard/iei/juki511p/irq_tables.c	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/irq_tables.c	2007-06-02 19:49:59.000000000 +0600
@@ -0,0 +1,102 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+#include <arch/pirq_routing.h>
+
+#define IRQ_BITMAP_LINK0 0x0800		/* chipset's INTA# input should be routed to IRQ11 */
+#define IRQ_BITMAP_LINK1 0x0400		/* chipset's INTB# input should be routed to IRQ10 */
+#define IRQ_BITMAP_LINK2 0x0000		/* chipset's INTC# input should be routed to nothing (disabled) */
+#define IRQ_BITMAP_LINK3 0x0000		/* chipset's INTD# input should be routed to nothing (disabled) */
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,  /* u32 signature */
+	PIRQ_VERSION,    /* u16 version   */
+	32+16*2,	 /* There can be total 6 devices on the bus */
+	0x00,		 /* Where the interrupt router lies (bus) */
+	(0x12<<3)|0x0,   /* Where the interrupt router lies (dev) */
+	0xc00,		 /* IRQs devoted exclusively to PCI usage */
+	0x1078,		 /* Vendor */
+	0x2,		 /* Device */
+	0,		 /* Crap (miniport) */
+	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
+	0x57,		 /* u8 checksum. This has to be set to some
+			    value that would give 0 after the sum of all
+			    bytes for this structure (including checksum) */
+
+	.slots = {
+		[0] = {
+			.slot = 0x0,	/* should be 0 when it is no real slot. My device is soldered */
+			.bus = 0x00,
+			.devfn = (0x13<<3)|0x0,	/* 0x13 is my USB OHCI */
+			.irq = {
+				[0] = {	/* <-- 0 means this is INTA# output from the device or slot */
+					.link = 0x01,			/* 0x01 means its connected to INTA# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK0
+				},
+				[1] = {	/* <-- 1 means this is INTB# output from the device or slot */
+					.link = 0x02,			/* 0x02 means its connected to INTB# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK1
+				},
+				[2] = {	/* <-- 2 means this is INTC# output from the device or slot */
+					.link = 0x03,			/* 0x03 means its connected to INTC# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK2
+				},
+				[3] = {	/* <-- 3 means this is INTD# output from the device or slot */
+					.link = 0x04,			/* 0x04 means its connected to INTD# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK3
+				}
+			}
+		},
+
+		[1] = {
+			.slot = 0x0,	/* means also "on board" */
+			.bus = 0x00,
+			.devfn = (0x0e<<3)|0x0,	/* 0x0e is my Realtek Network device */
+			.irq = {
+				[0] = {	/* <-- 0 means this is INTA# output from the device or slot */
+					.link = 0x02,			/* 0x02 means its connected to INTB# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK1
+				},
+				[1] = {	/* <-- 1 means this is INTB# output from the device or slot */
+					.link = 0x03,			/* 0x03 means its connected to INTC# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK2
+				},
+				[2] = {	/* <-- 2 means this is INTC# output from the device or slot */
+					.link = 0x04,			/* 0x04 means its connected to INTD# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK3
+				},
+				[3] = {	/* <-- 3 means this is INTD# output from the device or slot */
+					.link = 0x01,			/* 0x01 means its connected to INTA# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK0
+				}
+			}
+		}
+	}
+};
+
+/**
+ * Copy the IRQ routing table to memory.
+ *
+ * @param addr Destination address (between 0xF0000...0x100000).
+ * @return The end address of the pirq routing table in memory.
+ **/
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+        return copy_pirq_routing_table(addr);
+}
diff -Nru LinuxBIOSv2-2700/src/mainboard/iei/juki511p/mainboard.c LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/mainboard.c
--- LinuxBIOSv2-2700/src/mainboard/iei/juki511p/mainboard.c	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/mainboard.c	2007-06-02 19:06:40.000000000 +0600
@@ -0,0 +1,31 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <arch/io.h>
+#include "chip.h"
+
+struct chip_operations mainboard_iei_juki511p_ops = {
+	CHIP_NAME("IEI JUKI-511P Mainboard")
+};
diff -Nru LinuxBIOSv2-2700/src/mainboard/iei/juki511p/Options.lb LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/Options.lb
--- LinuxBIOSv2-2700/src/mainboard/iei/juki511p/Options.lb	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/Options.lb	2007-05-31 16:16:37.000000000 +0600
@@ -0,0 +1,147 @@
+uses HAVE_MP_TABLE
+uses HAVE_PIRQ_TABLE
+uses USE_FALLBACK_IMAGE
+uses HAVE_FALLBACK_BOOT
+uses HAVE_HARD_RESET
+uses CONFIG_UDELAY_IO
+uses HAVE_OPTION_TABLE
+uses USE_OPTION_TABLE
+uses CONFIG_COMPRESS
+uses CONFIG_COMPRESSED_PAYLOAD_NRV2B
+uses CONFIG_COMPRESSED_PAYLOAD_LZMA
+uses CONFIG_PRECOMPRESSED_PAYLOAD
+uses CONFIG_ROM_PAYLOAD
+uses IRQ_SLOT_COUNT
+uses MAINBOARD
+uses MAINBOARD_VENDOR
+uses MAINBOARD_PART_NUMBER
+uses LINUXBIOS_EXTRA_VERSION
+uses ARCH
+uses FALLBACK_SIZE
+uses STACK_SIZE
+uses HEAP_SIZE
+uses ROM_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_IMAGE_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_SECTION_OFFSET
+uses CONFIG_ROM_PAYLOAD_START
+uses PAYLOAD_SIZE
+uses _ROMBASE
+uses _RAMBASE
+uses XIP_ROM_SIZE
+uses XIP_ROM_BASE
+uses HAVE_MP_TABLE
+uses CROSS_COMPILE
+uses CC
+uses HOSTCC
+
+uses OBJCOPY
+
+uses CONFIG_CONSOLE_SERIAL8250
+uses DEFAULT_CONSOLE_LOGLEVEL
+uses MAXIMUM_CONSOLE_LOGLEVEL
+
+uses TTYS0_BAUD
+uses TTYS0_BASE
+uses TTYS0_LCS
+
+
+## ROM_SIZE is the size of boot ROM that this board will use.
+default ROM_SIZE  = 256*1024
+
+###
+### Build options
+###
+
+##
+## Build code for the fallback boot
+##
+default HAVE_FALLBACK_BOOT=1
+
+##
+## no MP table
+##
+default HAVE_MP_TABLE=0
+
+##
+## Build code to reset the motherboard from linuxBIOS
+##
+default HAVE_HARD_RESET=0
+
+default CONFIG_UDELAY_IO=1
+##
+## Build code to export a programmable irq routing table
+##
+default HAVE_PIRQ_TABLE=0
+default IRQ_SLOT_COUNT=2
+#object irq_tables.o
+
+##
+## Build code to export a CMOS option table
+##
+default HAVE_OPTION_TABLE=0
+
+###
+### LinuxBIOS layout values
+###
+
+## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy.
+default ROM_IMAGE_SIZE = 65536
+default FALLBACK_SIZE = 131072
+
+##
+## Use a small 8K stack
+##
+default STACK_SIZE=0x2000
+
+##
+## Use a small 16K heap
+##
+default HEAP_SIZE=0x4000
+
+##
+## Only use the option table in a normal image
+##
+#default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE
+default USE_OPTION_TABLE = 0
+
+default _RAMBASE = 0x00004000
+
+default CONFIG_ROM_PAYLOAD     = 1
+
+##
+## The Serial Console
+##
+
+# To Enable the Serial Console
+default CONFIG_CONSOLE_SERIAL8250=1
+default  DEFAULT_CONSOLE_LOGLEVEL=8
+default  MAXIMUM_CONSOLE_LOGLEVEL=8
+
+## Select the serial console baud rate
+default TTYS0_BAUD=115200
+#default TTYS0_BAUD=57600
+#default TTYS0_BAUD=38400
+#default TTYS0_BAUD=19200
+#default TTYS0_BAUD=9600
+#default TTYS0_BAUD=4800
+#default TTYS0_BAUD=2400
+#default TTYS0_BAUD=1200
+
+# Select the serial console base port
+default TTYS0_BASE=0x3f8
+
+# Select the serial protocol
+# This defaults to 8 data bits, 1 stop bit, and no parity
+default TTYS0_LCS=0x3
+
+##
+## The default compiler
+##
+default CROSS_COMPILE=""
+default CC="$(CROSS_COMPILE)gcc -m32"
+default HOSTCC="gcc"
+
+end
+
diff -Nru LinuxBIOSv2-2700/src/northbridge/amd/gx1/raminit.c LinuxBIOSv2-2700-juki/src/northbridge/amd/gx1/raminit.c
--- LinuxBIOSv2-2700/src/northbridge/amd/gx1/raminit.c	2005-07-06 23:11:02.000000000 +0600
+++ LinuxBIOSv2-2700-juki/src/northbridge/amd/gx1/raminit.c	2007-05-31 16:06:40.000000000 +0600
@@ -324,6 +324,7 @@
 	outb(0x70, 0x80);
 
 	setGX1Mem(GX_BASE + MC_MEM_CNTRL2, 0x000007d8); /* Disable all CLKS, Shift = 3 */
+//	setGX1Mem(GX_BASE + MC_MEM_CNTRL1, 0x92080000); /* MD_DS=2, MA_DS=2, CNTL_DS=2 SDCLKRATE=2.5 */
 	setGX1Mem(GX_BASE + MC_MEM_CNTRL1, 0x92140000); /* MD_DS=2, MA_DS=2, CNTL_DS=2 SDCLKRATE=4 */
 	setGX1Mem(GX_BASE + MC_BANK_CFG,   0x00700070); /* No DIMMS installed */
 	setGX1Mem(GX_BASE + MC_SYNC_TIM1,  0x3a733225); /* LTMODE=3, RC=10, RAS=7, RP=3, RCD=3, RRD=2, DPL=2 */
diff -Nru LinuxBIOSv2-2700/src/superio/winbond/w83977fa/chip.h LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/chip.h
--- LinuxBIOSv2-2700/src/superio/winbond/w83977fa/chip.h	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/chip.h	2007-06-02 18:52:57.000000000 +0600
@@ -0,0 +1,9 @@
+#include <pc80/keyboard.h>
+#include <uart8250.h>
+
+extern struct chip_operations superio_winbond_w83977fa_ops;
+
+struct superio_winbond_w83977fa_config {
+	struct uart8250 com1, com2;
+	struct pc_keyboard keyboard;
+};
diff -Nru LinuxBIOSv2-2700/src/superio/winbond/w83977fa/Config.lb LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/Config.lb
--- LinuxBIOSv2-2700/src/superio/winbond/w83977fa/Config.lb	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/Config.lb	2007-06-02 18:52:28.000000000 +0600
@@ -0,0 +1,2 @@
+config chip.h
+object superio.o
diff -Nru LinuxBIOSv2-2700/src/superio/winbond/w83977fa/superio.c LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/superio.c
--- LinuxBIOSv2-2700/src/superio/winbond/w83977fa/superio.c	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/superio.c	2007-06-02 19:04:17.000000000 +0600
@@ -0,0 +1,122 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ * Adapted from w83977tf
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <arch/io.h>
+#include <device/device.h>
+#include <device/pnp.h>
+#include <console/console.h>
+#include <string.h>
+#include <bitops.h>
+#include <uart8250.h>
+#include <pc80/keyboard.h>
+#include "chip.h"
+#include "w83977fa.h"
+
+static void w83977fa_enter_ext_func_mode(device_t dev) 
+{
+        outb(0x87, dev->path.u.pnp.port);
+        outb(0x87, dev->path.u.pnp.port);
+}
+static void w83977fa_exit_ext_func_mode(device_t dev) 
+{
+        outb(0xaa, dev->path.u.pnp.port);
+}
+
+static void w83977fa_init(device_t dev)
+{
+	struct superio_winbond_w83977fa_config *conf;
+	struct resource *res0, *res1;
+	/* Wishlist handle well known programming interfaces more
+	 * generically.
+	 */
+	if (!dev->enabled) {
+		return;
+	}
+	conf = dev->chip_info;
+	switch(dev->path.u.pnp.device) {
+	case W83977FA_SP1: 
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		init_uart8250(res0->base, &conf->com1);
+		break;
+	case W83977FA_SP2:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		init_uart8250(res0->base, &conf->com2);
+		break;
+	case W83977FA_KBC:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		res1 = find_resource(dev, PNP_IDX_IO1);
+		init_pc_keyboard(res0->base, res1->base, &conf->keyboard);
+		break;
+	}
+}
+
+static void w83977fa_set_resources(device_t dev)
+{
+	w83977fa_enter_ext_func_mode(dev);
+	pnp_set_resources(dev);
+	w83977fa_exit_ext_func_mode(dev);
+}
+
+static void w83977fa_enable_resources(device_t dev)
+{
+	w83977fa_enter_ext_func_mode(dev);
+	pnp_enable_resources(dev);
+	w83977fa_exit_ext_func_mode(dev);
+}
+
+static void w83977fa_enable(device_t dev)
+{
+	w83977fa_enter_ext_func_mode(dev);   
+	pnp_enable(dev);
+	w83977fa_exit_ext_func_mode(dev);  
+}
+
+
+static struct device_operations ops = {
+	.read_resources   = pnp_read_resources,
+	.set_resources    = w83977fa_set_resources,
+	.enable_resources = w83977fa_enable_resources,
+	.enable           = w83977fa_enable,
+	.init             = w83977fa_init,
+};
+
+static struct pnp_info pnp_dev_info[] = {
+        { &ops, W83977FA_FDC,  PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, },
+        { &ops, W83977FA_PP,   PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, },
+        { &ops, W83977FA_SP1,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+        { &ops, W83977FA_SP2,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+        { &ops, W83977FA_RTC },
+        { &ops, W83977FA_KBC,  PNP_IO0 | PNP_IO1 | PNP_IRQ0 | PNP_IRQ1, { 0x7ff, 0 }, { 0x7ff, 0x4}, },
+        { &ops, W83977FA_IR, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+        { &ops, W83977FA_GPIO1 },
+        { &ops, W83977FA_GPIO2 },
+};
+
+static void enable_dev(device_t dev)
+{
+	pnp_enable_devices(dev, &ops,
+		sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info);
+}
+
+struct chip_operations superio_winbond_w83977fa_ops = {
+	CHIP_NAME("Winbond W83977F-A Super I/O")
+	.enable_dev = enable_dev,
+};
diff -Nru LinuxBIOSv2-2700/src/superio/winbond/w83977fa/w83977fa_early_serial.c LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/w83977fa_early_serial.c
--- LinuxBIOSv2-2700/src/superio/winbond/w83977fa/w83977fa_early_serial.c	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/w83977fa_early_serial.c	2007-06-02 19:03:33.000000000 +0600
@@ -0,0 +1,25 @@
+#include <arch/romcc_io.h>
+#include "w83977fa.h"
+
+static inline void pnp_enter_ext_func_mode(device_t dev)
+{
+	unsigned int port = dev >> 8;
+	outb(0x87, port);
+	outb(0x87, port);
+}
+
+static void pnp_exit_ext_func_mode(device_t dev)
+{
+	unsigned int port = dev >> 8;
+	outb(0xaa, port);
+}
+
+static void w83977fa_enable_serial(device_t dev, unsigned int iobase)
+{
+	pnp_enter_ext_func_mode(dev);
+	pnp_set_logical_device(dev);
+	pnp_set_enable(dev, 0);
+	pnp_set_iobase(dev, PNP_IDX_IO0, iobase);
+	pnp_set_enable(dev, 1);
+	pnp_exit_ext_func_mode(dev);
+}
diff -Nru LinuxBIOSv2-2700/src/superio/winbond/w83977fa/w83977fa.h LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/w83977fa.h
--- LinuxBIOSv2-2700/src/superio/winbond/w83977fa/w83977fa.h	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/w83977fa.h	2007-06-02 19:03:07.000000000 +0600
@@ -0,0 +1,10 @@
+#define W83977FA_FDC              0   /* Floppy */
+#define W83977FA_PP               1   /* Parallel Port */
+#define W83977FA_SP1              2   /* Com1 */
+#define W83977FA_SP2              3   /* Com2 */
+#define W83977FA_RTC              4   /* RTC */
+#define W83977FA_KBC              5   /* Keyboard & Mouse */
+#define W83977FA_IR               6   /* Infrared Port */
+#define W83977FA_GPIO1            7   /* General Purpose I/O 1 */
+#define W83977FA_GPIO2            8   /* General Purpose I/O 2 */
+
diff -Nru LinuxBIOSv2-2700/targets/iei/juki511p/Config.lb LinuxBIOSv2-2700-juki/targets/iei/juki511p/Config.lb
--- LinuxBIOSv2-2700/targets/iei/juki511p/Config.lb	1970-01-01 05:00:00.000000000 +0500
+++ LinuxBIOSv2-2700-juki/targets/iei/juki511p/Config.lb	2007-06-02 19:07:21.000000000 +0600
@@ -0,0 +1,20 @@
+# Config file for the IEI juki511p motherboard
+# This will make a target directory of juki511p
+
+target juki511p
+mainboard iei/juki511p
+
+option ROM_SIZE=256*1024
+
+option HAVE_PIRQ_TABLE=1
+
+option CONFIG_COMPRESS=0
+option CONFIG_PRECOMPRESSED_PAYLOAD=0
+
+romimage "image" 
+	option ROM_IMAGE_SIZE=64*1024
+	option LINUXBIOS_EXTRA_VERSION="-filo"
+	payload ../../filo.elf
+end
+
+buildrom ./linuxbios.rom ROM_SIZE "image"
-------------- next part --------------
[    0.000000] Linux version 2.6.21-juki (nikola at localhost) (gcc version 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10)) #20 Thu May 31 17:43:37 YEKST 2007
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] sanitize start
[    0.000000] sanitize end
[    0.000000] copy_e820_map() start: 0000000000001000 size: 00000000000ef000 end: 00000000000f0000 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000] copy_e820_map() lies in range...
[    0.000000] copy_e820_map() start < 0xA0000ULL
[    0.000000] copy_e820_map() end <= 0x100000ULL
[    0.000000] copy_e820_map() start: 0000000000100000 size: 0000000007b00000 end: 0000000007c00000 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000]  BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
[    0.000000]  BIOS-e820: 0000000000100000 - 0000000007c00000 (usable)
[    0.000000] 124MB LOWMEM available.
[    0.000000] Entering add_active_range(0, 0, 31744) 0 entries of 256 used
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   Normal       4096 ->    31744
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:        0 ->    31744
[    0.000000] On node 0 totalpages: 31744
[    0.000000]   DMA zone: 32 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 4064 pages, LIFO batch:0
[    0.000000]   Normal zone: 216 pages used for memmap
[    0.000000]   Normal zone: 27432 pages, LIFO batch:7
[    0.000000] DMI not present or invalid.
[    0.000000] Allocating PCI resources starting at 10000000 (gap: 07c00000:f8400000)
[    0.000000] Built 1 zonelists.  Total pages: 31496
[    0.000000] Kernel command line: syscrtc=/dev/hda1 clocksource=pit video=gx1fb:monitor:800x600 at 60,mode:800x600-8 at 60,crt:1 ide=nodma ide-delay=2 hdc=none console=ttyS0,115200 ide1=noprobe
[    0.000000] ide_setup: ide=nodma : Prevented DMA
[    0.000000] ide_setup: ide-delay=2 : Delay set to 2ms
[    0.000000] ide_setup: hdc=none
[    0.000000] ide_setup: ide1=noprobe
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[    0.000000] Detected 300.691 MHz processor.
[    0.000000] Console: colour dummy device 80x25
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 121968k/126976k available (1676k kernel code, 4460k reserved, 414k data, 184k init, 0k highmem)
[    0.000000] virtual kernel memory layout:
[    0.000000]     fixmap  : 0xffffd000 - 0xfffff000   (   8 kB)
[    0.000000]     vmalloc : 0xc8800000 - 0xffffb000   ( 887 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc7c00000   ( 124 MB)
[    0.000000]       .init : 0xc030e000 - 0xc033c000   ( 184 kB)
[    0.000000]       .data : 0xc02a30f6 - 0xc030a94c   ( 414 kB)
[    0.000000]       .text : 0xc0100000 - 0xc02a30f6   (1676 kB)
[    0.000000] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[    0.160000] Calibrating delay using timer specific routine.. 602.26 BogoMIPS (lpj=3011311)
[    0.160000] Mount-cache hash table entries: 512
[    0.170000] CPU: After generic identify, caps: 00808131 01818131 00000000 00000000 00000000 00000000 00000000
[    0.170000] Working around Cyrix MediaGX virtual DMA bugs.
[    0.180000] Enable Memory-Write-back mode on Cyrix/NSC processor.
[    0.180000] Enable Memory access reorder on Cyrix/NSC processor.
[    0.180000] Enable Incrementor on Cyrix/NSC processor.
[    0.190000] CPU: After all inits, caps: 00808131 00818131 00000000 00000001 00000000 00000000 00000000
[    0.190000] CPU: NSC Geode(TM) Integrated Processor by National Semi stepping 02
[    0.200000] Checking 'hlt' instruction... OK.
[    0.240000] NET: Registered protocol family 16
[    0.240000] PCI: Using configuration type 1
[    0.250000] Setting up standard PCI resources
[    0.260000] usbcore: registered new interface driver usbfs
[    0.260000] usbcore: registered new interface driver hub
[    0.270000] usbcore: registered new device driver usb
[    0.270000] PCI: Probing PCI hardware
[    0.280000] PCI: Probing PCI hardware (bus 00)
[    0.280000] Boot video device is 0000:00:12.4
[    0.280000] PCI: Scanning for ghost devices on bus 0
[    0.280000] PCI: IRQ init
[    0.280000] PCI: Interrupt Routing Table found at 0xc00f0000
[    0.280000] 00:13 slot=00 0:01/0800 1:02/0400 2:03/0000 3:04/0000
[    0.280000] 00:0e slot=00 0:02/0400 1:03/0000 2:04/0000 3:01/0800
[    0.280000] PCI: Attempting to find IRQ router for 1078:0002
[    0.280000] PCI: Using IRQ router NatSemi [1078/0100] at 0000:00:12.0
[    0.290000] PCI: IRQ fixup
[    0.290000] IRQ for 0000:00:0e.0[A] -> PIRQ 02, mask 0400, excl 0c00 -> newirq=0 ... failed
[    0.290000] IRQ for 0000:00:13.0[A] -> PIRQ 01, mask 0800, excl 0c00 -> newirq=0 ... failed
[    0.290000] PCI: Allocating resources
[    0.290000] PCI: Resource 00001000-000010ff (f=101, d=0, p=0)
[    0.300000] PCI: Resource febfd000-febfd0ff (f=200, d=0, p=0)
[    0.310000] PCI: Resource febfe000-febfe0ff (f=200, d=0, p=0)
[    0.310000] PCI: Resource 000001f0-000001f7 (f=110, d=0, p=0)
[    0.320000] PCI: Resource 000003f6-000003f6 (f=110, d=0, p=0)
[    0.320000] PCI: Resource 00000170-00000177 (f=110, d=0, p=0)
[    0.330000] PCI: Resource 00000376-00000376 (f=110, d=0, p=0)
[    0.330000] PCI: Resource 00001400-0000147f (f=101, d=0, p=0)
[    0.340000] PCI: Resource febff000-febff07f (f=200, d=0, p=0)
[    0.350000] PCI: Resource febfb000-febfbfff (f=200, d=0, p=0)
[    0.350000] PCI: Resource febfc000-febfcfff (f=200, d=0, p=0)
[    0.360000] PCI: Ignore bogus resource 6 [0:0] of 0000:00:12.4
[    0.360000] NET: Registered protocol family 2
[    0.370000] Time: pit clocksource has been installed.
[    0.460000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.460000] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.470000] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[    0.480000] TCP: Hash tables configured (established 4096 bind 4096)
[    0.480000] TCP reno registered
[    0.520000] Unpacking initramfs... done
[    1.100000] Freeing initrd memory: 824k freed
[    1.100000] Geode GX1: 00,9c,c8,bb,01,05
[    1.100000] Geode GX1: Internal IOBASE at 0x40000000
[    1.110000] Geode GX1: SMM is disabled
[    1.110000] Geode GX1: Suspend on HLT feature enabled
[    1.120000] Geode GX1: Write through between 640kiB/1MiB is enabled
[    1.130000] Geode GX1: Reordering between 0x00000000/0x3fffffff is disabled
[    1.130000] Geode GX1: Reordering between 0x40000000/0x7fffffff is disabled
[    1.140000] Geode GX1: Reordering between 0x80000000/0xbfffffff is enabled
[    1.150000] Geode GX1: Reordering between 0xc0000000/0xffffffff is enabled
[    1.150000] Geode GX1: FPU fast mode enabled
[    1.160000] Geode GX1: DTE cache enabled
[    1.160000] Geode GX1: Memory Read Bypass enabled
[    1.170000] Geode GX1: IO Recovery Time is 6 clocks
[    1.170000] Geode GX1: MMX instructions are enabled
[    1.180000] Geode GX1 Chipset Support (c) Juergen Beisert 2007 juergen at kreuzholzen.de
[    1.180000] Geode GX1: Forcing round robin policy due to active video
[    1.190000] Geode GX1: 0x00701520, 0x92162008, 0x00000018, 0x3A733225
[    1.200000] Geode GX1: Memory base clock is one fourth the CPU clock
[    1.200000] Geode GX1: Memory refresh rate is 2048 cpu clocks
[    1.210000] Geode GX1: SDCLOCK shift is 1.5 clocks
[    1.210000] Geode GX1: Read Data Phase is 1 clocks
[    1.220000] Geode GX1: CAS latency: 3 clocks
[    1.220000] Geode GX1: RFSH to RFSH/ACT Period: 11 clocks
[    1.230000] Geode GX1: ACT to PRE Period: 8 clocks
[    1.230000] Geode GX1: PRE to ACT Period: 3 clocks
[    1.240000] Geode GX1: ACT to Read/Write Delay: 3 clocks
[    1.240000] Geode GX1: ACT(0) to ACT(1) Period: 2 clocks
[    1.250000] Geode GX1: Data-in to PRE Period: 2 clocks
[    1.250000] Geode GX1: XBUS round robin: active
[    1.260000] Geode GX1: Scratch Pad Ram and Video Instructions disabled
[    1.270000] Geode GX1: Full memory size is 131072kiB
[    1.270000] Geode GX1: Top of memory is at 0x07BFFFFF
[    1.280000] Geode GX1: Video memory size is 4096kiB
[    1.280000] Cyrix Kahlua SMI Support (c) Juergen Beisert 2006 juergen at kreuzholzen.de
[    1.290000] Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
[    1.300000] io scheduler noop registered (default)
[    1.300000] PCI: Fixup for MediaGX/Geode Slave Disconnect Boundary (0x41=0x10)
[    1.310000] Geode GX1 Framebuffer 0000:00:12.4: geode_gx1_video_probe called
[    1.310000] Geode GX1 Framebuffer 0000:00:12.4: gx1fb_init_fbinfo called
[    1.310000] Geode GX1 Framebuffer 0000:00:12.4: geode_map_areas called
[    1.310000] Geode GX1 Framebuffer 0000:00:12.4: 4096 Kibyte of video memory at 0x40800000
[    1.320000] Geode GX1 Framebuffer 0000:00:12.4: parse_panel_option called
[    1.320000] Geode FB: Searching for Monitor 800x600 at 60
[    1.320000] Geode FB: Creating generic monitor
[    1.320000] Geode GX1 Framebuffer 0000:00:12.4: gx1fb_init_fbinfo left
[    1.320000] Geode GX1 Framebuffer 0000:00:12.4: Searching for mode 800x600-8 at 60
[    1.320000] Geode GX1 Framebuffer 0000:00:12.4: gx1fb_check_var called
[    1.320000] Geode GX1 Framebuffer 0000:00:12.4: Mode 800x600 at 8 possible
[    1.330000] Geode GX1 Framebuffer 0000:00:12.4: gx1fb_check_var called
[    1.330000] Geode GX1 Framebuffer 0000:00:12.4: Mode 800x600 at 8 possible
[    1.340000] Geode GX1 Framebuffer 0000:00:12.4: gx1fb_set_par called
[    1.340000] Geode GX1 Framebuffer 0000:00:12.4: Geode GX1: switch to 800 x 600 (virtual 800 x 600 : 0, 0)
[    1.340000]  With line length of 800 (accel = off )
[    1.340000] Geode GX1 Framebuffer 0000:00:12.4: geode_gx1_prepare_blt entered, set to 0x00000000
[    1.360000] Console: switching to colour frame buffer device 100x37
[    1.390000] Geode GX1 Framebuffer 0000:00:12.4: fb0: Geode GX1 frame buffer device
[    1.780000] Real Time Clock Driver v1.12ac
[    1.780000] Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
[    1.790000] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[    1.800000] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[    1.800000] 8139too Fast Ethernet driver 0.9.28
[    1.810000] IRQ for 0000:00:0e.0[A] -> PIRQ 02, mask 0400, excl 0c00 -> newirq=10 -> assigning IRQ 10<7>PCI: setting IRQ 10 as level-triggered
[    1.810000]  -> edge ... OK
[    1.810000] PCI: Assigned IRQ 10 for device 0000:00:0e.0
[    1.810000] eth0: RealTek RTL8139 at 0x1000, 00:08:9b:58:74:da, IRQ 10
[    1.820000] eth0:  Identified 8139 chip type 'RTL-8139C'
[    1.820000] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[    1.830000] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
[    1.840000] CS5530: IDE controller at PCI slot 0000:00:12.2
[    1.840000] CS5530: chipset revision 0
[    1.850000] CS5530: not 100% native mode: will probe irqs later
[    1.850000] PCI: Setting latency timer of device 0000:00:12.0 to 64
[    1.850000] PCI: Setting latency timer of device 0000:00:12.2 to 64
[    1.850000]     ide0: BM-DMA at 0x1400-0x1407, BIOS settings: hda:pio, hdb:pio
[    1.860000]     ide1: BM-DMA at 0x1408-0x140f, BIOS settings: hdc:pio, hdd:pio
[    1.870000] Probing IDE interface ide0...
[    2.120000] hda: TRANSCEND, CFA DISK drive
[    2.240000] Clocksource tsc unstable (delta = -352701812 ns)
[    2.360000] hda: cs5530_set_xfer_mode(PIO 1)
[    2.360000] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
[    2.360000] hda: max request size: 128KiB
[    2.360000] hda: 506016 sectors (259 MB) w/1KiB Cache, CHS=502/16/63
[    2.370000]  hda: hda1
[    2.380000] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
[    2.380000] IRQ for 0000:00:13.0[A] -> PIRQ 01, mask 0800, excl 0c00 -> newirq=11 -> assigning IRQ 11<7>PCI: setting IRQ 11 as level-triggered
[    2.380000]  -> edge ... OK
[    2.380000] PCI: Assigned IRQ 11 for device 0000:00:13.0
[    2.380000] ohci_hcd 0000:00:13.0: OHCI Host Controller
[    2.390000] ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 1
[    2.400000] ohci_hcd 0000:00:13.0: irq 11, io mem 0xfebfc000
[    2.460000] usb usb1: configuration #1 chosen from 1 choice
[    2.460000] hub 1-0:1.0: USB hub found
[    2.470000] hub 1-0:1.0: 2 ports detected
[    2.580000] serio: i8042 KBD port at 0x60,0x64 irq 1
[    2.580000] serio: i8042 AUX port at 0x60,0x64 irq 12
[    2.590000] mice: PS/2 mouse device common for all mice
[    2.590000] input: PC Speaker as /class/input/input0
[    2.600000] Advanced Linux Sound Architecture Driver Version 1.0.14rc3 (Wed Mar 14 07:25:50 2007 UTC).
[    2.620000] Cyrix Kahlua native port XpressAudio support (c) Juergen Beisert 2007 juergen at kreuzholzen.de
[    2.630000] Found Chip at 0xFEBFF000, mapped to 0xc8812000
[    2.640000] Enabling Kahlua AC97 support
[    2.640000] PCI: Setting latency timer of device 0000:00:12.3 to 64
[    2.650000] snd_cs5530_pcm called
[    2.660000] ALSA device list:
[    2.660000]   #0: cs5530 at 0x4273991680 irq -1
[    2.670000] TCP cubic registered
[    2.670000] NET: Registered protocol family 1
[    2.680000] NET: Registered protocol family 17
[    2.680000] Using IPI Shortcut mode
[    2.690000] Freeing unused kernel memory: 184k freed
[    2.700000] input: AT Translated Set 2 keyboard as /class/input/input1
[    3.050000] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
[   24.780000] EXT2-fs warning: maximal mount count reached, running e2fsck is recommended
[   37.390000] usb 1-2: new low speed USB device using ohci_hcd and address 2
[   37.580000] usb 1-2: configuration #1 chosen from 1 choice
[   45.030000] usb 1-2: USB disconnect, address 2

From uwe at hermann-uwe.de  Sun Jun  3 01:51:56 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 3 Jun 2007 01:51:56 +0200
Subject: [LinuxBIOS] [PATCH] v3: Kconfig payload options and README
	improvements
In-Reply-To: <20070530234343.GD24702@coresystems.de>
References: <20070530204616.GC10622@greenwood>
	<20070530234343.GD24702@coresystems.de>
Message-ID: <20070602235156.GB17654@greenwood>

On Thu, May 31, 2007 at 01:43:43AM +0200, Stefan Reinauer wrote:
> > Index: Makefile
> > ===================================================================
> > --- Makefile	(Revision 338)
> > +++ Makefile	(Arbeitskopie)
> >  doxygen:
> >  	$(Q)$(DOXYGEN) util/doxygen/Doxyfile.LinuxBIOS
> >  
> > +payload:
> > +	$(Q)printf "Not yet implemented. This will invoke a helper tool.\n"
> > +
> 
> I'd wait checking this stuff in until we really do something here.

OK, it's commented now.

 
> > -	$(Q)cp $(CONFIG_PAYLOAD) $(obj)/lar.tmp/normal/payload
> > +	$(Q)# TODO: Copy no payload or empty payload if CONFIG_PAYLOAD_NONE.
> > +	$(Q)cp $(CONFIG_PAYLOAD_FILE) $(obj)/lar.tmp/normal/payload
> 
> maybe something like 
> if [ -r $(CONFIG_PAYLOAD_FILE) ]; then cp .... ; fi

Yep, done.


> > -STAGE2_LIB_OBJ       = stage2.o clog2.o mem.o malloc.o tables.o delay.o compute_ip_checksum.o
> > +STAGE2_LIB_OBJ       = stage2.o clog2.o mem.o malloc.o tables.o delay.o \
> > +		       compute_ip_checksum.o
>  
> Uh oh, lots of unrelated whitespace stuff in this patch.

True, it's gone now. I made an extra commit out of that.


Updated patch attached.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v3_payload_handling.patch
Type: text/x-diff
Size: 9949 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070603/c299fb36/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070603/c299fb36/attachment.sig>

From svn at openbios.org  Sun Jun  3 01:55:17 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  3 Jun 2007 01:55:17 +0200
Subject: [LinuxBIOS] r2706 - trunk/LinuxBIOSv2/src/southbridge/amd/cs5536
Message-ID: <mailman.370.1355071117.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-03 01:55:17 +0200 (Sun, 03 Jun 2007)
New Revision: 2706

Modified:
   trunk/LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c
Log:
The UART disable code was causing a hang and was worked around with a
return that skipped the disable code. This patch removes the return and
fixes the UART disable code.

The problem was that the disable code was ORing bits into the Legacy_IO
MSR causing issues with the LPC SIOs init code that would manifest as a
hang because the IO would not be decoded correctly. ANDing to clear the
bits fixes the issue.

Signed-off-by: Marc Jones <marc.jones at amd.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c	2007-05-29 19:26:37 UTC (rev 2705)
+++ trunk/LinuxBIOSv2/src/southbridge/amd/cs5536/cs5536.c	2007-06-02 23:55:17 UTC (rev 2706)
@@ -316,9 +316,6 @@
 
 	} else {
 		/* Reset and disable COM1 */
-		printk_err("Not disabling COM1 due to a bug ...\n");
-		/* for now, don't do this! */
-		return;
 		msr = rdmsr(MDD_UART1_CONF);
 		msr.lo = 1;	// reset
 		wrmsr(MDD_UART1_CONF, msr);
@@ -327,7 +324,7 @@
 
 		/* Disable the IRQ */
 		msr = rdmsr(MDD_LEG_IO);
-		msr.lo |= ~(0xF << 16);
+		msr.lo &= ~(0xF << 16);
 		wrmsr(MDD_LEG_IO, msr);
 	}
 
@@ -391,7 +388,7 @@
 
 		/* Disable the IRQ */
 		msr = rdmsr(MDD_LEG_IO);
-		msr.lo |= ~(0xF << 20);
+		msr.lo &= ~(0xF << 20);
 		wrmsr(MDD_LEG_IO, msr);
 	}
 }




From uwe at hermann-uwe.de  Sun Jun  3 01:59:26 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 3 Jun 2007 01:59:26 +0200
Subject: [LinuxBIOS] [Patch] AMD cs5536 uart disable
In-Reply-To: <13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
References: <465E0E52.6040400@amd.com>
	<13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
Message-ID: <20070602235926.GC17654@greenwood>

On Thu, May 31, 2007 at 07:14:00AM -0700, ron minnich wrote:
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>

Yep, looks good. Committed in r2706. Thanks for the fix Marc!

Two minor issues, though:

 - Please run 'svn diff' at the top-level directory (easier to see
   which files shall be patched).

 - Please put the explanations and sign-off into the patch file itself
   (not in the email body). That makes it easier to handle things when
   you have 20 patches in your $HOME and you don't want to switch
   back to the mail-client all the time to check the sign-off/explanations...


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070603/50f304d1/attachment.sig>

From juergen127 at kreuzholzen.de  Sun Jun  3 09:34:29 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Sun, 3 Jun 2007 09:34:29 +0200
Subject: [LinuxBIOS] Question about protect mode?
In-Reply-To: <200706022225.56454.juergen127@kreuzholzen.de>
References: <2386d0e70705281950q7aef237bp89a388789c2cfc6a@mail.gmail.com>
	<1180808759.8397.27.camel@ragnarok>
	<200706022225.56454.juergen127@kreuzholzen.de>
Message-ID: <200706030934.29778.juergen127@kreuzholzen.de>

On Saturday 02 June 2007 22:25, Juergen Beisert wrote:
> I only know a PowerPC (405GP if I remember right, its a SoC) processor that
> supports such kind of ROM device addressing/connecting.

And the PowerPC MPC5200 does it in such a way, as it shares lines between PCI 
and local bus. Nothing x86 specific.

Juergen



From stepan at coresystems.de  Sun Jun  3 13:57:41 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 3 Jun 2007 13:57:41 +0200
Subject: [LinuxBIOS] new target iei juki-511p/rocky-512
In-Reply-To: <e24af7500706021120nbfb8062kbde1a1c498aaeded@mail.gmail.com>
References: <e24af7500706021120nbfb8062kbde1a1c498aaeded@mail.gmail.com>
Message-ID: <20070603115741.GA24986@coresystems.de>

Dear Nikolay,

* Nikolay Petukhov <nikolaypetukhov at gmail.com> [070602 20:20]:
> Here's a one patch for IEI JUKI-511P and IEI ROCKY-512 half-size boards.
> This boards are little difference, that's why it has one patch.
> 
> Linux with patchs from Juergen Beisert
> (http://www.linuxbios.org/pipermail/linuxbios/2007-May/020932.html)
> boots and work fine(ide, usb, ethernet, serial, keyboard and sound
> work normally).

Thank you very much for your nice work!

Please sign off the patch according to
http://www.linuxbios.org/Development_Guidelines#Sign-off_Procedure
so we can check this patch in!


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From juergen127 at kreuzholzen.de  Sun Jun  3 14:37:02 2007
From: juergen127 at kreuzholzen.de (Juergen Beisert)
Date: Sun, 3 Jun 2007 14:37:02 +0200
Subject: [LinuxBIOS] new target iei juki-511p/rocky-512
In-Reply-To: <e24af7500706021120nbfb8062kbde1a1c498aaeded@mail.gmail.com>
References: <e24af7500706021120nbfb8062kbde1a1c498aaeded@mail.gmail.com>
Message-ID: <200706031437.02296.juergen127@kreuzholzen.de>

On Saturday 02 June 2007 20:20, Nikolay Petukhov wrote:
> Here's a one patch for IEI JUKI-511P and IEI ROCKY-512 half-size boards.
> This boards are little difference, that's why it has one patch.
>
> Linux with patchs from Juergen Beisert
> (http://www.linuxbios.org/pipermail/linuxbios/2007-May/020932.html)
> boots and work fine(ide, usb, ethernet, serial, keyboard and sound
> work normally).

Sound works? Don't try it with higher system load. It will crash your system. 
The SMI polling routine must run at higher priority. No time to fix it, yet.

> Problems:
> Filo load bzImage only from ide0.
> Video don't work, no any monitor output.

As your dmesg output shows, the graphical console is active. I missed 
something to setup correctly. When my LinuxBIOS activates the VGA the linux 
console runs as expected. Without it, everything seems ok, but no output 
occures. I don't know why, yet.

Juergen



From graemebrett.houston at btopenworld.com  Sun Jun  3 16:30:24 2007
From: graemebrett.houston at btopenworld.com (Graeme Brett Houston BSc)
Date: Sun, 3 Jun 2007 15:30:24 +0100
Subject: [LinuxBIOS] BBS
Message-ID: <000601c7a5eb$b992c610$6401a8c0@dell>

Hi justr a request for Feature:

make LinuxBIOS part of the Bios Boot spec so that a addon card like a RTL8139B could carry LinuxBIOS on the ROM and allow rapid development without replacing mainboard bios until sure that it will power up system.

thanks Graeme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070603/1235d6f2/attachment.html>

From joe at smittys.pointclark.net  Sun Jun  3 16:34:26 2007
From: joe at smittys.pointclark.net (joe at smittys.pointclark.net)
Date: Sun, 03 Jun 2007 10:34:26 -0400
Subject: [LinuxBIOS] [RFC] i82801 generic patch
In-Reply-To: <46615A81.9080509@verizon.net>
References: <46615A81.9080509@verizon.net>
Message-ID: <20070603103426.erxn0qyu4gg08o0s@www.smittys.pointclark.net>

Quoting Corey Osgood <corey_osgood at verizon.net>:

> The attached patch is a unified version of the current ports of the
> i82801 series currently in LinuxBIOS. Since most of the ports are nearly
> identical, I've taken for each file and chosen the cleanest or best
> version of the code, then checked over the datasheets to *some* of the
> series, including the aa, ba, ca, and db, to make sure that it would
> work. I've also made some changes here and there, mostly cleanup and
> clarification. The only things left to look at are the huge difference
> between this version's lpc init and the i82801er's, finding a better way
> to select which chip is present on the board, and gpl headers in all
> files. Anyways, comments, suggestions, even flames are welcome ;)
> Testing on other chips can be done at this point as well, this is tested
> and working on one model, the i82801aa.
>
> -Corey
>

Looks great Corey! How soon can this be Acked??

Thanks - Joe




From uwe at hermann-uwe.de  Sun Jun  3 18:35:49 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 3 Jun 2007 18:35:49 +0200
Subject: [LinuxBIOS] new target iei juki-511p/rocky-512
In-Reply-To: <e24af7500706021120nbfb8062kbde1a1c498aaeded@mail.gmail.com>
References: <e24af7500706021120nbfb8062kbde1a1c498aaeded@mail.gmail.com>
Message-ID: <20070603163549.GA15426@greenwood>

Hi Nikolay,

thanks a lot for your great work and the patch!

As Stefan said, please resend with a Signed-off-by so we can commit, see
http://linuxbios.org/Development_Guidelines#Sign-off_Procedure

Here are a few more comments on the patch:

On Sun, Jun 03, 2007 at 12:20:10AM +0600, Nikolay Petukhov wrote:
> Problems:
> Filo load bzImage only from ide0.

What does not work? ide1? AFAICS the boards only have one IDE port!?


> JUKI-511P ? PCISA half?size board:
> Specification:
> CPU: Geode GX1 300Mhz
> System Chipset: cs5530

CS5530A according to the website/manual for both boards, but it's mostly
the same as CS5530. We should at some point check whether there are
differences we need to take care of in LinuxBIOS, though.

(this will not hold up your patch, just a sidenote for later...)


> diff -Nru LinuxBIOSv2-2700/src/mainboard/iei/juki511p/auto.c LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/auto.c
> --- LinuxBIOSv2-2700/src/mainboard/iei/juki511p/auto.c	1970-01-01 05:00:00.000000000 +0500
> +++ LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/auto.c	2007-06-02 20:02:10.000000000 +0600

Please rename the directory to 'juki-511p' if possible, as that seems to be
the canonical (lowercase'd) name used by the vendor.


> +#include "superio/winbond/w83977fa/w83977fa_early_serial.c"

Maybe this should be 'w83977f' (without the 'a')? IIRC, we omitted any
'-A' or '-AW' suffix from other Super I/Os, too. Comments anyone?


> +void udelay(int usecs) 
> +{
> +	int i;
> +	for(i = 0; i < usecs; i++)
> +		outb(i&0xff, 0x80);
> +}

Is this needed? There's a global implementation in the repository
already.


> +            device pnp 3f0.4 on		# RTC
> +            end

Is this ok if left empty?

My 'lspnp -v' (on another mainboard) says:

00:04 PNP0b00 AT real-time clock
    state = active
        io 0x70-0x71
        irq 8

So maybe something like

  device pnp 3f0.4 on              # RTC
    io 0x60 = 0x70
    irq 0x70 = 8
  end

is needed here? I'm just guessing, though, please correct me if I'm
wrong.


> +            device pnp 3f0.5 on		# Keyboard
> +               io 0x60 = 0x60
> +               io 0x62 = 0x64
> +              irq 0x70 = 0x01     # int  1 for PS/2 keyboard
> +              irq 0x72 = 0x0c     # int 12 for PS/2 mouse

Why not like this? Easier to read, IMHO:

  irq 0x70 = 1     # int  1 for PS/2 keyboard
  irq 0x72 = 12    # int 12 for PS/2 mouse


> +const struct irq_routing_table intel_irq_routing_table = {
> +	PIRQ_SIGNATURE,  /* u32 signature */
> +	PIRQ_VERSION,    /* u16 version   */
> +	32+16*2,	 /* There can be total 6 devices on the bus */
                                               ^
typo? --->                                     2?

Maybe even

  32+16*IRQ_SLOT_COUNT,         /* There can be IRQ_SLOT_COUNT devices on the bus */


> diff -Nru LinuxBIOSv2-2700/src/northbridge/amd/gx1/raminit.c LinuxBIOSv2-2700-juki/src/northbridge/amd/gx1/raminit.c
> --- LinuxBIOSv2-2700/src/northbridge/amd/gx1/raminit.c	2005-07-06 23:11:02.000000000 +0600
> +++ LinuxBIOSv2-2700-juki/src/northbridge/amd/gx1/raminit.c	2007-05-31 16:06:40.000000000 +0600
> @@ -324,6 +324,7 @@
>  	outb(0x70, 0x80);
>  
>  	setGX1Mem(GX_BASE + MC_MEM_CNTRL2, 0x000007d8); /* Disable all CLKS, Shift = 3 */
> +//	setGX1Mem(GX_BASE + MC_MEM_CNTRL1, 0x92080000); /* MD_DS=2, MA_DS=2, CNTL_DS=2 SDCLKRATE=2.5 */
>  	setGX1Mem(GX_BASE + MC_MEM_CNTRL1, 0x92140000); /* MD_DS=2, MA_DS=2, CNTL_DS=2 SDCLKRATE=4 */
>  	setGX1Mem(GX_BASE + MC_BANK_CFG,   0x00700070); /* No DIMMS installed */
>  	setGX1Mem(GX_BASE + MC_SYNC_TIM1,  0x3a733225); /* LTMODE=3, RC=10, RAS=7, RP=3, RCD=3, RRD=2, DPL=2 */

OK, not sure what we should do with this. Will it break other GX1-based
mainboards? Or is it generic for all GX1s?


> diff -Nru LinuxBIOSv2-2700/src/superio/winbond/w83977fa/chip.h LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/chip.h
> --- LinuxBIOSv2-2700/src/superio/winbond/w83977fa/chip.h	1970-01-01 05:00:00.000000000 +0500
> +++ LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/chip.h	2007-06-02 18:52:57.000000000 +0600

Please provide an extra patch for the addition of the new Super I/O,
this is independant of the mainboards...


> diff -Nru LinuxBIOSv2-2700/targets/iei/juki511p/Config.lb LinuxBIOSv2-2700-juki/targets/iei/juki511p/Config.lb
> --- LinuxBIOSv2-2700/targets/iei/juki511p/Config.lb	1970-01-01 05:00:00.000000000 +0500
> +++ LinuxBIOSv2-2700-juki/targets/iei/juki511p/Config.lb	2007-06-02 19:07:21.000000000 +0600

Please add a copyright header to this file, too.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070603/77770374/attachment.sig>

From svn at openbios.org  Sun Jun  3 18:57:27 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  3 Jun 2007 18:57:27 +0200
Subject: [LinuxBIOS] r2707 - trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb
Message-ID: <mailman.371.1355071117.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-03 18:57:27 +0200 (Sun, 03 Jun 2007)
New Revision: 2707

Modified:
   trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb.h
   trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_ide.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_smbus.c
Log:
Intel 82371EB: Some code simplifications (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb.h
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb.h	2007-06-02 23:55:17 UTC (rev 2706)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb.h	2007-06-03 16:57:27 UTC (rev 2707)
@@ -26,7 +26,6 @@
 void i82371eb_enable(device_t dev);
 #endif
 
-#define PCICMD		0x04	/* PCI Command Register */
 #define XBCS		0x4e	/* X-Bus Chip Select register */
 
 /* SMBus */

Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c	2007-06-02 23:55:17 UTC (rev 2706)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_early_smbus.c	2007-06-03 16:57:27 UTC (rev 2707)
@@ -49,9 +49,9 @@
 	pci_write_config8(dev, SMBHSTCFG, reg8);
 
 	/* Enable access to the SMBus I/O space. */
-	reg16 = pci_read_config16(dev, PCICMD);
+	reg16 = pci_read_config16(dev, PCI_COMMAND);
 	reg16 |= IOSE;
-	pci_write_config16(dev, PCICMD, reg16);
+	pci_write_config16(dev, PCI_COMMAND, reg16);
 
 	/* Clear any lingering errors, so the transaction will run. */
 	outb(inb(SMBUS_IO_BASE + SMBHST_STATUS), SMBUS_IO_BASE + SMBHST_STATUS);

Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_ide.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_ide.c	2007-06-02 23:55:17 UTC (rev 2706)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_ide.c	2007-06-03 16:57:27 UTC (rev 2707)
@@ -35,10 +35,8 @@
 static void ide_init(struct device *dev)
 {
 	uint16_t reg;
-	struct southbridge_intel_i82371eb_config *conf;
+	struct southbridge_intel_i82371eb_config *conf = dev->chip_info;
 
-	conf = dev->chip_info;
-
 	/* Enable/disable the primary IDE interface. */
 	reg = pci_read_config16(dev, IDETIM_PRI);
 	if (conf->ide0_enable) {
@@ -62,18 +60,13 @@
 	pci_write_config16(dev, IDETIM_SEC, reg);
 }
 
-/* There are no subsystem IDs on the Intel 82371EB. */
-static struct pci_operations lops_pci = {
-	// .set_subsystem = 0,
-};
-
 static struct device_operations ide_ops = {
 	.read_resources		= pci_dev_read_resources,
 	.set_resources		= pci_dev_set_resources,
 	.enable_resources	= pci_dev_enable_resources,
 	.init			= ide_init,
 	.scan_bus		= 0,
-	.ops_pci		= &lops_pci,
+	.ops_pci		= 0, /* No subsystem IDs on 82371EB! */
 };
 
 static struct pci_driver ide_driver __pci_driver = {

Modified: trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_smbus.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_smbus.c	2007-06-02 23:55:17 UTC (rev 2706)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82371eb/i82371eb_smbus.c	2007-06-03 16:57:27 UTC (rev 2707)
@@ -27,11 +27,6 @@
 static struct smbus_bus_operations lops_smbus_bus = {
 };
 
-/* There are no subsystem IDs on the Intel 82371EB. */
-static struct pci_operations lops_pci = {
-	// .set_subsystem = 0,
-};
-
 static struct device_operations smbus_ops = {
 	.read_resources		= pci_dev_read_resources,
 	.set_resources		= pci_dev_set_resources,
@@ -39,7 +34,7 @@
 	.init			= 0,
 	.scan_bus		= scan_static_bus,
 	// .enable		= i82371eb_enable,	// TODO: Needed?
-	.ops_pci		= &lops_pci,
+	.ops_pci		= 0, /* No subsystem IDs on 82371EB! */
 	.ops_smbus_bus		= &lops_smbus_bus,
 };
 




From stepan at coresystems.de  Sun Jun  3 21:31:15 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 3 Jun 2007 21:31:15 +0200
Subject: [LinuxBIOS] [PATCH] Tyan S1846: Device tree fixes
In-Reply-To: <20070529043721.GJ21947@greenwood>
References: <20070529043721.GJ21947@greenwood>
Message-ID: <20070603193115.GA9658@coresystems.de>

* Uwe Hermann <uwe at hermann-uwe.de> [070529 06:37]:
> The static device tree of the Tyan S1846 was, um... totally bogus.
> 
> I'm using the ide0_enble/ide1_enable variables now to enable IDE.
> Hm, what happens if those variables are not set at all in a Confib.lb
> file of some mainboard? Do they default to zero?
> 
> 
> Uwe.
> -- 
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

> Fix the static device tree of the Tyan S1846. Especially the
> Super I/O part was incorrect.
> 
> Also, add ide0_enable/ide1_enable variables, and enable both the
> primary and secondary IDE interface per default.
> 

> Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>

I dont have the board, but I think it makes sense. Please someone else
intervent otherwise. I say:

Acked-by: Stefan Reinauer <stepan at coresystems.de>


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From uwe at hermann-uwe.de  Sun Jun  3 21:31:23 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 3 Jun 2007 21:31:23 +0200
Subject: [LinuxBIOS] [RFC] i82801 generic patch
In-Reply-To: <20070603103426.erxn0qyu4gg08o0s@www.smittys.pointclark.net>
References: <46615A81.9080509@verizon.net>
	<20070603103426.erxn0qyu4gg08o0s@www.smittys.pointclark.net>
Message-ID: <20070603193123.GB15426@greenwood>

On Sun, Jun 03, 2007 at 10:34:26AM -0400, joe at smittys.pointclark.net wrote:
> Looks great Corey! How soon can this be Acked??

Pretty soon, I guess. I'm looking over it, but we need to be careful to
not break any existing boards. Also, at the very minimum the proper
license headers have to be added/merged.

A more in-depth review will follow...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070603/a6904b13/attachment.sig>

From stepan at coresystems.de  Sun Jun  3 21:33:22 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 3 Jun 2007 21:33:22 +0200
Subject: [LinuxBIOS] [PATCH] Lower 440BX RAM init delays
In-Reply-To: <1180389384.13099.22.camel@localhost2.localdomain>
References: <20070528004010.GE19499@greenwood>
	<1180389384.13099.22.camel@localhost2.localdomain>
Message-ID: <20070603193322.GB9658@coresystems.de>

* roger <roger at eskimo.com> [070528 23:56]:
> On Mon, 2007-05-28 at 02:40 +0200, Uwe Hermann wrote:
> > See patch.
> > 
> > Tested on Tyan S1846, works fine.
> > 
> > 
> > Uwe.

> Tested here on my (buggy) DFI P2XBL.
> 
> I'm too getting into the execution of Filo as well after using this
> patch.
 
Acked-by: Stefan Reinauer <stepan at coresystems.de>

Stefan


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From uwe at hermann-uwe.de  Sun Jun  3 21:38:27 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 3 Jun 2007 21:38:27 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
References: <20070531194024.GB3955@bloms.de>
	<20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
	<20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
Message-ID: <20070603193827.GC15426@greenwood>

On Sat, Jun 02, 2007 at 10:17:21AM -0400, joe at smittys.pointclark.net wrote:
> > it is a winbond W83627HF-AW
> 
> Hmm, on the LB website there is a big ? next to the winbond W83627HF,  
> Has anyone else had sucess wih this chip?

I'm pretty confident that it should work, haven't tried it myself
though.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070603/b5dce1a9/attachment.sig>

From uwe at hermann-uwe.de  Sun Jun  3 21:40:54 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 3 Jun 2007 21:40:54 +0200
Subject: [LinuxBIOS] Problem with FILO
In-Reply-To: <751d98080706010744h25bddc0fj854ec1d45c6737c3@mail.gmail.com>
References: <751d98080706010744h25bddc0fj854ec1d45c6737c3@mail.gmail.com>
Message-ID: <20070603194054.GD15426@greenwood>

On Fri, Jun 01, 2007 at 11:44:13AM -0300, Ot?vio Alc?ntara wrote:
> Hello,
> 
>         I've setup a linuxbios rom, based on norwich board support, for a
> board with Geode LX + CS5536. I works right until starting the Linux with
> FILO. FILO claims that can't recognize my filesystem. I've setup the option
> FSYS_EXT2FS = 1 on Config file of Filo, and my image is EXT2 formatted.
>          Is there any other option that need to be setted? Is possible to
> choose more than one file system, I mean, FAT and EXT2?

Yes, there's an option in FILO's 'Config' file for that.

Where's your ext2-formatted disk? /dev/hda1?

Please post the 'Config' file from FILO you were using as well as the
exact error message (or better: full boot log) you get.


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070603/8bc7f724/attachment.sig>

From uwe at hermann-uwe.de  Sun Jun  3 21:55:52 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 3 Jun 2007 21:55:52 +0200
Subject: [LinuxBIOS] which motherboard would be the better choice
In-Reply-To: <b610d37e10684a8689d4eae88c06b2f1@mx243m.mysite4now.com>
References: <b610d37e10684a8689d4eae88c06b2f1@mx243m.mysite4now.com>
Message-ID: <20070603195552.GE15426@greenwood>

Hi Mike,

On Fri, Jun 01, 2007 at 05:19:24AM -0700, Mike Dilworth wrote:
> as you can tell I need the HDMI feature.  

Hm, I don't know much about HDMI. Would that need some special init in
the BIOS? Do we have support for such things in LinuxBIOS?


> On both I will use the AMD Athlon X2 3800+ AM2 CPU
> 
> MS-7327
> 
> uses AMI BIOS 
> AMD 690G Northbridge and SB600 Southbridge
> integrated ATi Radeon X1250 videocard 
> Realtek High Definition Audio Driver
> ATI System Drivers for RS480/RS482/RC410/SB600
> AMD HDMI Audio Drivers
> Realtek 10/100 LAN Drivers
> ATI SB600 IDE RAID Driver
> Realtek Gigabit Ethernet Drivers
> from the photos it looks like this uses ??? its nt clear DIP BIOS???
> 
> Abit AN-M2HD
> NVIDIA? GeForce?7050PV/nForce 630a 
> from the pictures i think this uses a PLCC: Plastic Leaded Chip Carrier 

Both mainbaords are not yet supported, sorry. Neither are the chipsets
they use, so it'd be pretty much work to support them.

If you are willing to buy some other mainboard, one of the supported
ones (http://linuxbios.org/Supported_Motherboards) would be a good
choice, or have a look at the ones listed here:

http://linuxbios.org/Desktops

These mainboards are _not_ yet supported, but making them work would be a
lot easier as they use already-supported chipsets.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070603/c36c54e1/attachment.sig>

From corey_osgood at verizon.net  Sun Jun  3 22:14:36 2007
From: corey_osgood at verizon.net (Corey Osgood)
Date: Sun, 03 Jun 2007 16:14:36 -0400
Subject: [LinuxBIOS] [RFC] i82801 generic patch
In-Reply-To: <20070603193123.GB15426@greenwood>
References: <46615A81.9080509@verizon.net>
	<20070603103426.erxn0qyu4gg08o0s@www.smittys.pointclark.net>
	<20070603193123.GB15426@greenwood>
Message-ID: <4663212C.5050004@verizon.net>

Uwe Hermann wrote:
> On Sun, Jun 03, 2007 at 10:34:26AM -0400, joe at smittys.pointclark.net wrote:
>> Looks great Corey! How soon can this be Acked??
> 
> Pretty soon, I guess. I'm looking over it, but we need to be careful to
> not break any existing boards. 

No boards will be broken, I don't intend to remove the old devices nor
swap over any boards. I'm leaving that for people that actually have
them and can test it to do.

> Also, at the very minimum the proper
> license headers have to be added/merged.

Yeah, working on that right now. Anyone know who svn user magnanisj is?
I think this person worked for Linux Networx or SuSE in late 2005, but I
could be wrong. If they can't be identified, I've got to rewrite a
couple files.

> A more in-depth review will follow...
> 
> 
> Uwe.
> 

Thanks,
Corey



From svn at openbios.org  Sun Jun  3 22:39:47 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  3 Jun 2007 22:39:47 +0200
Subject: [LinuxBIOS] r2708 - trunk/LinuxBIOSv2/src/mainboard/tyan/s1846
Message-ID: <mailman.372.1355071118.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-03 22:39:47 +0200 (Sun, 03 Jun 2007)
New Revision: 2708

Modified:
   trunk/LinuxBIOSv2/src/mainboard/tyan/s1846/Config.lb
Log:
Fix the static device tree of the Tyan S1846. Especially the
Super I/O part was incorrect.

Also, add ide0_enable/ide1_enable variables, and enable both the
primary and secondary IDE interface per default.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s1846/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/tyan/s1846/Config.lb	2007-06-03 16:57:27 UTC (rev 2707)
+++ trunk/LinuxBIOSv2/src/mainboard/tyan/s1846/Config.lb	2007-06-03 20:39:47 UTC (rev 2708)
@@ -125,38 +125,46 @@
 dir /pc80
 config chip.h
 
-# TODO.
-chip northbridge/intel/i440bx # Northbridge
-	device pci_domain 0 on 
-		device pci 0.0 on end # Host bridge
-		device pci 1.0 off end # PCI bridge  TODO: AGP bridge?
-		# device pci 7.0 on end # ISA bridge
-		chip southbridge/intel/i82371eb # Southbridge
-			device pci 7.0 on # ISA bridge ???
-				chip superio/nsc/pc87309 # Super I/O
-					device pnp 2e.0 on end # Floppy
-					device pnp 2e.1 on end # Parallel port
-					device pnp 2e.2 on end # Com2
-					device pnp 2e.3 on # Com1
-						io 0x60 = 0x3f8
-						irq 0x70 = 4
-					end
-					device pnp 2e.4 on end # Power mgmt.
-					device pnp 2e.5 on end # Mouse
-					device pnp 2e.6 on # Keyboard
-						io 0x60 = 0x60
-						io 0x62 = 0x64
-						irq 0x70 = 1
-						irq 0x72 = 12 # ???
-					end
-				end
-				device pci 7.1 on end # IDE
-				device pci 7.2 on end # USB
-				device pci 7.3 on end # ACPI
-			end
-		end
-	end
-	chip cpu/intel/slot_2
-	end
+chip northbridge/intel/i440bx		# Northbridge
+  device pci_domain 0 on
+    device pci 0.0 on end		# Host bridge
+    device pci 1.0 on end		# AGP bridge
+    chip southbridge/intel/i82371eb	# Southbridge
+      device pci 7.0 on			# ISA bridge
+        chip superio/nsc/pc87309	# Super I/O
+          device pnp 2e.5 on		# Keyboard + Mouse
+            io 0x60 = 0x60
+            io 0x62 = 0x64
+            irq 0x70 = 1
+            irq 0x72 = 12
+          end
+          device pnp 2e.b on		# Com1
+            io 0x60 = 0x3f8
+            irq 0x70 = 4
+          end
+          device pnp 2e.c on		# Com2 / IR
+            io 0x60 = 0x2f8
+            irq 0x70 = 3
+          end
+          device pnp 2e.d on		# Parallel port
+            io 0x60 = 0x378
+            irq 0x70 = 7
+          end
+          device pnp 2e.f on		# Floppy
+            io 0x60 = 0x3f0
+            irq 0x70 = 6
+            drq 0x74 = 2
+          end
+        end
+      end
+      device pci 7.1 on end		# IDE
+      device pci 7.2 on end		# USB
+      device pci 7.3 on end		# ACPI
+      register "ide0_enable" = "1"
+      register "ide1_enable" = "1"
+    end
+  end
+  chip cpu/intel/slot_2			# CPU
+  end
 end
 




From uwe at hermann-uwe.de  Sun Jun  3 22:40:24 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Sun, 3 Jun 2007 22:40:24 +0200
Subject: [LinuxBIOS] [PATCH] Tyan S1846: Device tree fixes
In-Reply-To: <20070603193115.GA9658@coresystems.de>
References: <20070529043721.GJ21947@greenwood>
	<20070603193115.GA9658@coresystems.de>
Message-ID: <20070603204024.GF15426@greenwood>

On Sun, Jun 03, 2007 at 09:31:15PM +0200, Stefan Reinauer wrote:
> Acked-by: Stefan Reinauer <stepan at coresystems.de>

Thanks, r2708.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070603/63658dd1/attachment.sig>

From svn at openbios.org  Sun Jun  3 23:57:55 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sun,  3 Jun 2007 23:57:55 +0200
Subject: [LinuxBIOS] r2709 - trunk/LinuxBIOSv2/src/mainboard/tyan/s1846
Message-ID: <mailman.373.1355071118.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-03 23:57:55 +0200 (Sun, 03 Jun 2007)
New Revision: 2709

Modified:
   trunk/LinuxBIOSv2/src/mainboard/tyan/s1846/Config.lb
Log:
Tyan S1846: Minor fixes in static device tree (trivial):

 - Linux booted with the proprietary BIOS reports 2e.f as PS/2 mouse
   in the output of 'lspnp -v'.

 - The floppy on 2e.f was a typo, should have been 2e.e from the beginning.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/LinuxBIOSv2/src/mainboard/tyan/s1846/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/tyan/s1846/Config.lb	2007-06-03 20:39:47 UTC (rev 2708)
+++ trunk/LinuxBIOSv2/src/mainboard/tyan/s1846/Config.lb	2007-06-03 21:57:55 UTC (rev 2709)
@@ -132,11 +132,11 @@
     chip southbridge/intel/i82371eb	# Southbridge
       device pci 7.0 on			# ISA bridge
         chip superio/nsc/pc87309	# Super I/O
-          device pnp 2e.5 on		# Keyboard + Mouse
+          device pnp 2e.5 on		# PS/2 keyboard (+ mouse?)
             io 0x60 = 0x60
             io 0x62 = 0x64
             irq 0x70 = 1
-            irq 0x72 = 12
+            # irq 0x72 = 12
           end
           device pnp 2e.b on		# Com1
             io 0x60 = 0x3f8
@@ -150,11 +150,14 @@
             io 0x60 = 0x378
             irq 0x70 = 7
           end
-          device pnp 2e.f on		# Floppy
+          device pnp 2e.e on		# Floppy
             io 0x60 = 0x3f0
             irq 0x70 = 6
             drq 0x74 = 2
           end
+          device pnp 2e.f on		# PS/2 mouse
+            irq 0x70 = 12
+          end
         end
       end
       device pci 7.1 on end		# IDE




From svn at openbios.org  Mon Jun  4 01:19:19 2007
From: svn at openbios.org (svn at openbios.org)
Date: Mon,  4 Jun 2007 01:19:19 +0200
Subject: [LinuxBIOS] r2710 - trunk/LinuxBIOSv2/targets/tyan/s1846
Message-ID: <mailman.374.1355071118.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-04 01:19:19 +0200 (Mon, 04 Jun 2007)
New Revision: 2710

Modified:
   trunk/LinuxBIOSv2/targets/tyan/s1846/Config.lb
Log:
Switch the Tyan S1846 to a fallback-only boot per default to allow
bigger payloads (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/LinuxBIOSv2/targets/tyan/s1846/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/targets/tyan/s1846/Config.lb	2007-06-03 21:57:55 UTC (rev 2709)
+++ trunk/LinuxBIOSv2/targets/tyan/s1846/Config.lb	2007-06-03 23:19:19 UTC (rev 2710)
@@ -22,15 +22,15 @@
 mainboard tyan/s1846
 
 option ROM_SIZE = 256 * 1024
-# option FALLBACK_SIZE = 256 * 1024
+option FALLBACK_SIZE = ROM_SIZE
 
-romimage "normal"
-	option USE_FALLBACK_IMAGE = 0
-	option ROM_IMAGE_SIZE = 56 * 1024
-	option LINUXBIOS_EXTRA_VERSION = ".0Normal"
-	payload /tmp/filo.elf
-	# payload /tmp/memtest
-end
+# romimage "normal"
+# 	option USE_FALLBACK_IMAGE = 0
+# 	option ROM_IMAGE_SIZE = 56 * 1024
+# 	option LINUXBIOS_EXTRA_VERSION = ".0Normal"
+# 	payload /tmp/filo.elf
+# 	# payload /tmp/memtest
+# end
 
 romimage "fallback"
 	option USE_FALLBACK_IMAGE = 1
@@ -40,5 +40,5 @@
 	# payload /tmp/memtest
 end
 
-buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"
-# buildrom ./linuxbios.rom ROM_SIZE "fallback"
+# buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"
+buildrom ./linuxbios.rom ROM_SIZE "fallback"




From jordan.crouse at amd.com  Mon Jun  4 05:44:00 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Sun, 3 Jun 2007 21:44:00 -0600
Subject: [LinuxBIOS] AMD cs5536 uart disable
In-Reply-To: <20070602235926.GC17654@greenwood>
References: <465E0E52.6040400@amd.com>
	<13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
	<20070602235926.GC17654@greenwood>
Message-ID: <20070604034400.GA8716@cosmic.amd.com>

On 03/06/07 01:59 +0200, Uwe Hermann wrote:
>  - Please run 'svn diff' at the top-level directory (easier to see
>    which files shall be patched).

Not sure what you mean by that - are you looking for the diffstat?

Jordan

---
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>





From corey.osgood at gmail.com  Mon Jun  4 07:01:29 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Mon, 04 Jun 2007 01:01:29 -0400
Subject: [LinuxBIOS] [RFC] i82801 generic patch (anyone know magnanisj?)
In-Reply-To: <4663212C.5050004@verizon.net>
References: <46615A81.9080509@verizon.net>
	<20070603103426.erxn0qyu4gg08o0s@www.smittys.pointclark.net>
	<20070603193123.GB15426@greenwood> <4663212C.5050004@verizon.net>
Message-ID: <46639CA9.6010206@gmail.com>

Corey Osgood wrote:
> Yeah, working on that right now. Anyone know who svn user magnanisj is?
> I think this person worked for Linux Networx or SuSE in late 2005, but I
> could be wrong. If they can't be identified, I've got to rewrite a
> couple files.

Hmm, browsing trac a little more seems that magnanisj also checked in
the xe7501devkit as a port of the agami aruma, and the i82801ca was done
for that board
(http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit?rev=2030)
The header in acpi_tables.c says the port was done by Digital Design
Corporation, does that ring any bells for anyone? If not, I'll see if
they can dig up anything, it's the best lead I've come up with so far.

-Corey




From mjd at e-nspect.com  Mon Jun  4 08:36:16 2007
From: mjd at e-nspect.com (Mike Dilworth)
Date: Sun, 3 Jun 2007 23:36:16 -0700
Subject: [LinuxBIOS] which motherboard would be the better choice
Message-ID: <08712cf9979c4330a524a248d52eecc4@mx243m.mysite4now.com>


hi Uwe

thanks for the reply.  I suspected that perhaps i would not be taking the most well trodden path.  I suppose HDMI will need some form of special init but as yet I havent looked into it in any great detail. 

I want to build my own media center which is why I want the HDMI feature and there aint a lot of choice. I also want my media box to behave more like an appliance (to keep the wife happy ;-) )  which is how i came to stumble on the LinuxBios project and it looks pretty cool.

Amongst other things I am a c/c++ programmer and I would be very interested in dabble in Linux Bios however I have almost no free time these days.  In your opinion how much work is needed. Consider I know pretty much zero about LinuxBios but rate highly as a c programmer, I am also a fast learner, and that I could perhaps give the effort about 10-15hrs a week. How many weeks do you think its going to take?

mike

----------------------------------------

From: Uwe Hermann <uwe at hermann-uwe.de>
Sent: 03 June 2007 12:56
To: Mike Dilworth <mjd at e-nspect.com>
Subject: Re: [LinuxBIOS] which motherboard would be the better choice 

Hi Mike,

On Fri, Jun 01, 2007 at 05:19:24AM -0700, Mike Dilworth wrote:
> as you can tell I need the HDMI feature. 

Hm, I don't know much about HDMI. Would that need some special init in
the BIOS? Do we have support for such things in LinuxBIOS?

> On both I will use the AMD Athlon X2 3800+ AM2 CPU 
> 
> MS-7327 
> 
> uses AMI BIOS 
> AMD 690G Northbridge and SB600 Southbridge 
> integrated ATi Radeon X1250 videocard 
> Realtek High Definition Audio Driver 
> ATI System Drivers for RS480/RS482/RC410/SB600 
> AMD HDMI Audio Drivers 
> Realtek 10/100 LAN Drivers 
> ATI SB600 IDE RAID Driver 
> Realtek Gigabit Ethernet Drivers 
> from the photos it looks like this uses ??? its nt clear DIP BIOS??? 
> 
> Abit AN-M2HD 
> NVIDIA? GeForce?7050PV/nForce 630a 
> from the pictures i think this uses a PLCC: Plastic Leaded Chip Carrier 

Both mainbaords are not yet supported, sorry. Neither are the chipsets
they use, so it'd be pretty much work to support them.

If you are willing to buy some other mainboard, one of the supported
ones (http://linuxbios.org/Supported_Motherboards) would be a good
choice, or have a look at the ones listed here:

http://linuxbios.org/Desktops

These mainboards are _not_ yet supported, but making them work would be a
lot easier as they use already-supported chipsets.

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

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


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

From uwe at hermann-uwe.de  Mon Jun  4 08:48:39 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 4 Jun 2007 08:48:39 +0200
Subject: [LinuxBIOS] AMD cs5536 uart disable
In-Reply-To: <20070604034400.GA8716@cosmic.amd.com>
References: <465E0E52.6040400@amd.com>
	<13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
	<20070602235926.GC17654@greenwood>
	<20070604034400.GA8716@cosmic.amd.com>
Message-ID: <20070604064839.GA7478@greenwood>

On Sun, Jun 03, 2007 at 09:44:00PM -0600, Jordan Crouse wrote:
> On 03/06/07 01:59 +0200, Uwe Hermann wrote:
> >  - Please run 'svn diff' at the top-level directory (easier to see
> >    which files shall be patched).
> 
> Not sure what you mean by that - are you looking for the diffstat?

Ah, no, sorry for being unclear.

Running 'svn diff > foo.patch' in a subdirectory, e.g. in
src/southbridge/amd/cs5536, will produce a patch with entries in the
following format:

Index: cs5536.c
===================================================================
--- cs5536.c    (revision 2705)
+++ cs5536.c    (working copy)

Running 'svn diff > foo.patch' at the top-level directory of the svn
working copy will produce entries such as the following:

Index: src/southbridge/amd/cs5536/cs5536.c
===================================================================
--- src/southbridge/amd/cs5536/cs5536.c (revision 2708)
+++ src/southbridge/amd/cs5536/cs5536.c (working copy)

I.e., the "full" relative path to the file being modified is included
in the patch, so you can 'patch -p0 < ~/foo.patch' at the top-level to
apply the patch.

The first version is harder to deal with, as you have to know in which
directory the file 'cs5536.c' resides, cd into that directory and run
'patch -p0 < ~/foo.patch' there.

Not too hard for cs5536.c, but imagine a patch which changes a file
which can be located just about anywhere (e.g. Config.lb). We'd have to
guess or ask the patch submitter to which file the patch must be applied.

Hence -> 'svn diff' at the top-level directory is easier to handle for us.


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070604/18f8148a/attachment.sig>

From Libo.Feng at amd.com  Mon Jun  4 11:22:44 2007
From: Libo.Feng at amd.com (Feng, Libo)
Date: Mon, 4 Jun 2007 17:22:44 +0800
Subject: [LinuxBIOS] Linux can't run.
In-Reply-To: <13426df10705310722p51f2b84dl710345509c21eff1@mail.gmail.com>
References: <DD1CC71B621B004FA76856E5129D6B172A0022@sbjgexmb1.amd.com>
	<13426df10705310722p51f2b84dl710345509c21eff1@mail.gmail.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B172E41DA@sbjgexmb1.amd.com>

Hi, Mr. Ron Minnich,

Do you mean the IRQ table? We use the irq_tables.c under Broadcom/blast. We just thought Explosion has the same interrupt routing with Blast. We will try a new IRQ table generated by getpir utility. 

Thanks.

Best Regards

??? Feng Libo @ AMD  Ext: 20906
Mobile Phone: 13683249071
Office Phone: 0086-010-62801406

-----Original Message-----
From: ron minnich [mailto:rminnich at gmail.com] 
Sent: Thursday, May 31, 2007 10:22 PM
To: Feng, Libo
Cc: linuxbios at linuxbios.org; Bao, Zheng; Xie, Michael
Subject: Re: [LinuxBIOS] Linux can't run.

Your interrupts are flat out wrong. Is it the table or some aspect of hardware setup? How did you generate the mp table? Could that be the problem?

You need to see what's going on with interrupts.

thanks

ron







From Libo.Feng at amd.com  Mon Jun  4 11:28:07 2007
From: Libo.Feng at amd.com (Feng, Libo)
Date: Mon, 4 Jun 2007 17:28:07 +0800
Subject: [LinuxBIOS] How many tables exist in BIOS?
Message-ID: <DD1CC71B621B004FA76856E5129D6B172E41E8@sbjgexmb1.amd.com>

Hi, all, 

Who can tell me a general question about BIOS: how many tables exist in BIOS, which will be used by Operating System later? As far as I know, there are the IRQ table, MP table, ACPI table. Any others?


Best Regards

??? Feng Libo @ AMD  Ext: 20906
Mobile Phone: 13683249071
Office Phone: 0086-010-62801406

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

From joe at smittys.pointclark.net  Mon Jun  4 11:57:45 2007
From: joe at smittys.pointclark.net (Joseph Smith)
Date: Mon, 04 Jun 2007 05:57:45 -0400
Subject: [LinuxBIOS] [RFC] i82801 generic patch (anyone know	magnanisj?)
In-Reply-To: <46639CA9.6010206@gmail.com>
References: <46615A81.9080509@verizon.net>
	<20070603103426.erxn0qyu4gg08o0s@www.smittys.pointclark.net>
	<20070603193123.GB15426@greenwood> <4663212C.5050004@verizon.net>
	<46639CA9.6010206@gmail.com>
Message-ID: <20070604055745.j10itxftgk4cgwcs@www.smittys.pointclark.net>

Quoting Corey Osgood <corey.osgood at gmail.com>:

> Corey Osgood wrote:
>> Yeah, working on that right now. Anyone know who svn user magnanisj is?
>> I think this person worked for Linux Networx or SuSE in late 2005, but I
>> could be wrong. If they can't be identified, I've got to rewrite a
>> couple files.
>
> Hmm, browsing trac a little more seems that magnanisj also checked in
> the xe7501devkit as a port of the agami aruma, and the i82801ca was done
> for that board
> (http://tracker.linuxbios.org/trac/LinuxBIOS/browser/trunk/LinuxBIOSv2/src/mainboard/intel/xe7501devkit?rev=2030)
> The header in acpi_tables.c says the port was done by Digital Design
> Corporation, does that ring any bells for anyone? If not, I'll see if
> they can dig up anything, it's the best lead I've come up with so far.
>
> -Corey
>
>
I also says in the header "written by Stefan Reinauer <stepan at openbios.org>"
Is this true Stefan??


Thanks - Joe



From stepan at coresystems.de  Mon Jun  4 15:42:34 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 4 Jun 2007 15:42:34 +0200
Subject: [LinuxBIOS] How many tables exist in BIOS?
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B172E41E8@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B172E41E8@sbjgexmb1.amd.com>
Message-ID: <20070604134234.GA1551@coresystems.de>

* Feng, Libo <Libo.Feng at amd.com> [070604 11:28]:
> Hi, all,
> 
> Who can tell me a general question about BIOS: how many tables exist in BIOS,
> which will be used by Operating System later? As far as I know, there are the
> IRQ table, MP table, ACPI table. Any others?

LinuxBIOS also has the "LinuxBIOS table", which will at some point be
the base table which might allow you to create IRQ, MP and ACPI
automatically. This is only a concept so far and has not even been
designed, nor implemented.

Otherwise, those three table types are all you need to cope with. There
is also DMI/SMBIOS, but that is not required

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Mon Jun  4 16:06:24 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 4 Jun 2007 16:06:24 +0200
Subject: [LinuxBIOS] [RFC] i82801 generic patch (anyone know	magnanisj?)
In-Reply-To: <20070604055745.j10itxftgk4cgwcs@www.smittys.pointclark.net>
References: <46615A81.9080509@verizon.net>
	<20070603103426.erxn0qyu4gg08o0s@www.smittys.pointclark.net>
	<20070603193123.GB15426@greenwood>
	<4663212C.5050004@verizon.net> <46639CA9.6010206@gmail.com>
	<20070604055745.j10itxftgk4cgwcs@www.smittys.pointclark.net>
Message-ID: <20070604140624.GA10474@coresystems.de>

* Joseph Smith <joe at smittys.pointclark.net> [070604 11:57]:
> > The header in acpi_tables.c says the port was done by Digital Design
> > Corporation, does that ring any bells for anyone? If not, I'll see if
> > they can dig up anything, it's the best lead I've come up with so far.
> >
> > -Corey
> >
> >
> I also says in the header "written by Stefan Reinauer <stepan at openbios.org>"
> Is this true Stefan??

The acpi_tables.c was just adapted by Steven, I originally wrote it for
the Agami Aruma (which is an AMD board). I was not directly involved in
the intel xe7501 port though

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From jordan.crouse at amd.com  Mon Jun  4 16:44:36 2007
From: jordan.crouse at amd.com (Jordan Crouse)
Date: Mon, 4 Jun 2007 08:44:36 -0600
Subject: [LinuxBIOS] AMD cs5536 uart disable
In-Reply-To: <20070604064839.GA7478@greenwood>
References: <465E0E52.6040400@amd.com>
	<13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
	<20070602235926.GC17654@greenwood>
	<20070604034400.GA8716@cosmic.amd.com>
	<20070604064839.GA7478@greenwood>
Message-ID: <20070604144436.GC5442@cosmic.amd.com>

On 04/06/07 08:48 +0200, Uwe Hermann wrote:
> I.e., the "full" relative path to the file being modified is included
> in the patch, so you can 'patch -p0 < ~/foo.patch' at the top-level to
> apply the patch.

-p0?  Is that seriously the standard here?  Can I ask why?

> Hence -> 'svn diff' at the top-level directory is easier to handle for us.

I thought Marc used quilt - which should do the right thing in this regard.
I'll follow up with him.

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>





From stepan at coresystems.de  Mon Jun  4 17:14:15 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 4 Jun 2007 17:14:15 +0200
Subject: [LinuxBIOS] AMD cs5536 uart disable
In-Reply-To: <20070604144436.GC5442@cosmic.amd.com>
References: <465E0E52.6040400@amd.com>
	<13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
	<20070602235926.GC17654@greenwood>
	<20070604034400.GA8716@cosmic.amd.com>
	<20070604064839.GA7478@greenwood>
	<20070604144436.GC5442@cosmic.amd.com>
Message-ID: <20070604151415.GA2518@coresystems.de>

* Jordan Crouse <jordan.crouse at amd.com> [070604 16:44]:
> On 04/06/07 08:48 +0200, Uwe Hermann wrote:
> > I.e., the "full" relative path to the file being modified is included
> > in the patch, so you can 'patch -p0 < ~/foo.patch' at the top-level to
> > apply the patch.
> 
> -p0?  Is that seriously the standard here?  Can I ask why?

Purely convenience of the patch reviewers / people doing the check-ins.
Then you don't have to check manually which directory the patch goes
into. Don't worry about it. We will figure this out either way. It just
might make our life easier (thus speeding up check-ins)

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From svn at openbios.org  Mon Jun  4 17:15:06 2007
From: svn at openbios.org (svn at openbios.org)
Date: Mon,  4 Jun 2007 17:15:06 +0200
Subject: [LinuxBIOS] r342 - LinuxBIOSv3/include
Message-ID: <mailman.375.1355071118.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-06-04 17:15:05 +0200 (Mon, 04 Jun 2007)
New Revision: 342

Modified:
   LinuxBIOSv3/include/console.h
Log:
no more linker hacks in v3, except for the .S parts.

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Modified: LinuxBIOSv3/include/console.h
===================================================================
--- LinuxBIOSv3/include/console.h	2007-06-02 12:28:58 UTC (rev 341)
+++ LinuxBIOSv3/include/console.h	2007-06-04 15:15:05 UTC (rev 342)
@@ -45,12 +45,6 @@
 	int (*tst_byte)(void);
 };
 
-#define __console	__attribute__((used, __section__ (".rodata.console_drivers")))
-
-/* Defined by the linker... */
-extern struct console_driver console_drivers[];
-extern struct console_driver econsole_drivers[];
-
 // 
 int printk(int msg_level, const char *fmt, ...);
 




From segher at kernel.crashing.org  Mon Jun  4 17:27:47 2007
From: segher at kernel.crashing.org (Segher Boessenkool)
Date: Mon, 4 Jun 2007 17:27:47 +0200
Subject: [LinuxBIOS] AMD cs5536 uart disable
In-Reply-To: <20070604151415.GA2518@coresystems.de>
References: <465E0E52.6040400@amd.com>
	<13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
	<20070602235926.GC17654@greenwood>
	<20070604034400.GA8716@cosmic.amd.com>
	<20070604064839.GA7478@greenwood>
	<20070604144436.GC5442@cosmic.amd.com>
	<20070604151415.GA2518@coresystems.de>
Message-ID: <9ea556971cc803e69f749add76b8d784@kernel.crashing.org>

>>> I.e., the "full" relative path to the file being modified is included
>>> in the patch, so you can 'patch -p0 < ~/foo.patch' at the top-level 
>>> to
>>> apply the patch.
>>
>> -p0?  Is that seriously the standard here?  Can I ask why?
>
> Purely convenience of the patch reviewers / people doing the check-ins.
> Then you don't have to check manually which directory the patch goes
> into. Don't worry about it. We will figure this out either way. It just
> might make our life easier (thus speeding up check-ins)

I'm sure you mean you want -p1 patches, instead?


Segher




From stuge-linuxbios at cdy.org  Mon Jun  4 17:39:37 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 4 Jun 2007 17:39:37 +0200
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux
	compatable	BIOS programmer ?]
In-Reply-To: <1180812548.8397.30.camel@ragnarok>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<200508130547.j7D5l8D30326@ecstasy1.winternet.com>
	<42FF0E53.4010902@linuxmachines.com>
	<200508151056.38490.p.millar@physics.gla.ac.uk>
	<4300973D.4020601@linuxmachines.com>
	<1180812548.8397.30.camel@ragnarok>
Message-ID: <20070604153938.32310.qmail@cdy.org>

On Sat, Jun 02, 2007 at 03:29:08PM -0400, Jeremy Jackson wrote:
> Sorry to jump in a bit late here, but for parallel flash, what
> about using a NIC with a boot ROM socket?  I've used that for both
> PLCC32 and DIP32 parts.

You mean for salvaging flash parts? They're usually small. 128kb.

The flash chip on those cards isn't reachable until after PCI init
has set an address for it so it's not that handy for booting.

Sorry - what are you suggesting? :)


//Peter



From stuge-linuxbios at cdy.org  Mon Jun  4 17:46:41 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 4 Jun 2007 17:46:41 +0200
Subject: [LinuxBIOS] LinuxBIOS at the Linux Tag 2007 in Berlin
In-Reply-To: <20070602090315.GA15078@coresystems.de>
References: <20070602090315.GA15078@coresystems.de>
Message-ID: <20070604154641.1425.qmail@cdy.org>

On Sat, Jun 02, 2007 at 11:03:15AM +0200, Stefan Reinauer wrote:
> Thank you very much to all people contributing their time and
> effort here at the booth to make this possible

I second that. Many thanks to Carsten, Stefan, Uwe and Jens!

Also a big thank you to the LinuxTag organizers working with the
open source projects! (Marko, Wolfgang and all your co-workers.)

LinuxTag will be in Berlin also next year sometime in May/June.
I am already looking forward to it. :)


//Peter



From rminnich at gmail.com  Mon Jun  4 17:52:34 2007
From: rminnich at gmail.com (ron minnich)
Date: Mon, 4 Jun 2007 08:52:34 -0700
Subject: [LinuxBIOS] LinuxBIOS at the Linux Tag 2007 in Berlin
In-Reply-To: <20070604154641.1425.qmail@cdy.org>
References: <20070602090315.GA15078@coresystems.de>
	<20070604154641.1425.qmail@cdy.org>
Message-ID: <13426df10706040852x16860831o69136633879e0ef7@mail.gmail.com>

I have to try to get to that one in berlin next year.

That's wonderful stuff, folks, thanks to you all. You had a soldering
iron in the booth! Neat!

thanks

ron



From stepan at coresystems.de  Mon Jun  4 17:58:51 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 4 Jun 2007 17:58:51 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070601151455.GA7454@countzero.vandewege.net>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
Message-ID: <20070604155851.GB21661@coresystems.de>

* Ward Vandewege <ward at gnu.org> [070601 17:14]:
> > -it takes quite long to load vmlinuz and the initrd.img. Probably due to: IDE_DISK_POLL_DELAY = 1 (?)
> 
> Yes. Peter Stuge was working on a patch to speedup FILO. We should revisit
> that.
 
Is it working? Can't test at the moment...


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stuge-linuxbios at cdy.org  Mon Jun  4 17:58:51 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 4 Jun 2007 17:58:51 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070601151455.GA7454@countzero.vandewege.net>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
Message-ID: <20070604155851.4065.qmail@cdy.org>

On Fri, Jun 01, 2007 at 11:14:55AM -0400, Ward Vandewege wrote:
> > -I had to use the delay in filo.c (cmp.
> > http://www.linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial)
> 
> Yes.
> 
> > -it takes quite long to load vmlinuz and the initrd.img. Probably
> > due to: IDE_DISK_POLL_DELAY = 1 (?)
> 
> Yes. Peter Stuge was working on a patch to speedup FILO. We should
> revisit that.

I would appreciate any feedback I can get on the patch. It needs more
testing.

As far as I know, it has been confirmed to work on M57SLI by Ward and
fail on VMware by Corey.

It should apply cleanly to svn FILO.

Please enable DEBUG_TIMER, _BLOCKDEV, _IDE and _EXT2 in Config if it
does not work and send the output to the list.


//Peter
-------------- next part --------------
Index: include/fs.h
===================================================================
--- include/fs.h	(revision 34)
+++ include/fs.h	(working copy)
@@ -7,6 +7,7 @@
 
 #ifdef IDE_DISK
 int ide_probe(int drive);
+int ide_readmany(int drive, sector_t sector, sector_t num_sectors, void *buffer);
 int ide_read(int drive, sector_t sector, void *buffer);
 #endif
 
@@ -22,6 +23,7 @@
 int devopen(const char *name, int *reopen);
 int devread(unsigned long sector, unsigned long byte_offset,
 	unsigned long byte_len, void *buf);
+int devreadmany(void *buf, unsigned long first_sector, unsigned long num_sectors);
 
 int file_open(const char *filename);
 int file_read(void *buf, unsigned long len);
Index: defconfig
===================================================================
--- defconfig	(revision 34)
+++ defconfig	(working copy)
@@ -25,6 +25,10 @@
 # Driver for hard disk, CompactFlash, and CD-ROM on IDE bus
 IDE_DISK = 1
 
+# Use 32-bit PIO for increased transfer speed
+# Not supported by all IDE controllers
+IDE_32BIT_PIO = 1
+
 # Add a short delay when polling status registers 
 # (required on some broken SATA controllers)
 # NOTE: Slows down access significantly, so disable 
@@ -90,4 +94,5 @@
 #DEBUG_IDE = 1
 #DEBUG_USB = 1
 #DEBUG_ELTORITO = 1
+#DEBUG_EXT2 = 1
 
Index: fs/fsys_ext2fs.c
===================================================================
--- fs/fsys_ext2fs.c	(revision 34)
+++ fs/fsys_ext2fs.c	(working copy)
@@ -1,6 +1,9 @@
 /*
- *  GRUB  --  GRand Unified Bootloader
+ *  FILO ext2fs driver
+ *
+ *  Mostly code from GRUB  --  GRand Unified Bootloader
  *  Copyright (C) 1999, 2001  Free Software Foundation, Inc.
+ *  Copyright (C) 2007  Peter Stuge <peter at stuge.se>
  *
  *  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
@@ -22,6 +25,9 @@
 #include "shared.h"
 #include "filesys.h"
 
+#define DEBUG_THIS DEBUG_EXT2
+#include <debug.h>
+
 static int mapblock1, mapblock2;
 
 /* sizes are always in bytes, BLOCK values are always in DEV_BSIZE (sectors) */
@@ -386,6 +392,8 @@
     [logical_block & (EXT2_ADDR_PER_BLOCK (SUPERBLOCK) - 1)];
 }
 
+#define E2_BSIZE (EXT2_BLOCK_SIZE (SUPERBLOCK))
+
 /* preconditions: all preconds of ext2fs_block_map */
 int
 ext2fs_read (char *buf, int len)
@@ -395,26 +403,96 @@
   int map;
   int ret = 0;
   int size = 0;
+  int manylen, manypos, blocks, firstmapped = 0;
 
-#ifdef E2DEBUG
-  static char hexdigit[] = "0123456789abcdef";
-  unsigned char *i;
-  for (i = (unsigned char *) INODE;
-       i < ((unsigned char *) INODE + sizeof (struct ext2_inode));
-       i++)
+  /* read one full or partial block */
+  int ext2fs_read_one(void) {
+    int res;
+    debug ("block  %d  offset=%d len=%d ret=%d\n", map, offset, len, ret);
+    if (map < 0)
+      return 1;
+    size = E2_BSIZE;
+    size -= offset;
+    if (size > len)
+      size = len;
+    disk_read_func = disk_read_hook;
+    res = devread (map * (E2_BSIZE/DEV_BSIZE), offset, size, buf);
+    disk_read_func = NULL;
+    if (!res)
+      return 1;
+    buf += size;
+    len -= size;
+    filepos += size;
+    ret += size;
+    return 0;
+  }
+
+  /* read many fs blocks at once */
+  int ext2fs_read_many(int first_block, int num_blocks) {
+    int first_devblock, num_devblocks, res;
+    debug ("%3d block%c  %d - %d  len=%d ret=%d\n", num_blocks, 1 == num_blocks ? ' ' : 's', first_block, first_block + num_blocks - 1, len, ret);
+    if (offset)
+      debug ("can't read many blocks with non-zero offset %d\n", offset);
+    if (first_block < 0 || num_blocks < 0 || offset)
+      return 1;
+    if (!num_blocks)
+      return 0;
+    first_devblock = first_block * (E2_BSIZE/DEV_BSIZE);
+    num_devblocks = num_blocks * (E2_BSIZE/DEV_BSIZE);
+    disk_read_func = disk_read_hook;
+    res = devreadmany (buf, first_devblock, num_devblocks);
+    disk_read_func = NULL;
+    if (!res)
+      return 1;
+    size = num_blocks * E2_BSIZE;
+    buf += size;
+    len -= size;
+    filepos += size;
+    ret += size;
+    return 0;
+  }
+
+  /* read many blocks at once? */
+  if (len > E2_BSIZE)
     {
-      printf ("%c", hexdigit[*i >> 4]);
-      printf ("%c", hexdigit[*i % 16]);
-      if (!((i + 1 - (unsigned char *) INODE) % 16))
-	{
-	  printf ("\n");
-	}
-      else
-	{
-	  printf (" ");
-	}
+      offset = filepos & (E2_BSIZE-1);
+      if (offset)
+        {
+          logical_block = filepos >> EXT2_BLOCK_SIZE_BITS(SUPERBLOCK);
+          map = ext2fs_block_map (logical_block);
+          if (ext2fs_read_one ())
+            goto err;
+          offset = 0;
+        }
+      while (len > 0)
+        {
+          manylen = len;
+          manypos = filepos;
+          for (blocks = 0; manylen > 0; blocks++)
+            {
+              map = ext2fs_block_map (manypos >> EXT2_BLOCK_SIZE_BITS (SUPERBLOCK));
+              if (blocks > 0 && map != firstmapped + blocks)
+                break;
+              if (!blocks)
+                firstmapped = map;
+              if (manylen < E2_BSIZE)
+                continue;
+              manypos += E2_BSIZE;
+              manylen -= E2_BSIZE;
+            }
+          if (ext2fs_read_many (firstmapped, blocks))
+            goto err;
+        }
+      if (len < 0)
+        {
+          debug ("discarding %d surplus bytes\n", -len);
+          ret += len;
+          filepos += len;
+          len = 0;
+        }
+      debug ("done reading many  len=%d ret=%d\n", len, ret);
     }
-#endif /* E2DEBUG */
+
   while (len > 0)
     {
       /* find the (logical) block component of our location */
@@ -424,27 +502,14 @@
 #ifdef E2DEBUG
       printf ("map=%d\n", map);
 #endif /* E2DEBUG */
-      if (map < 0)
-	break;
+      if (ext2fs_read_one ())
+        break;
+    }
 
-      size = EXT2_BLOCK_SIZE (SUPERBLOCK);
-      size -= offset;
-      if (size > len)
-	size = len;
+err:
+  if (len)
+    debug ("returning %d with len=%d ret=%d errnum=%d\n", errnum ? 0 : ret, len, ret, errnum);
 
-      disk_read_func = disk_read_hook;
-
-      devread (map * (EXT2_BLOCK_SIZE (SUPERBLOCK) / DEV_BSIZE),
-	       offset, size, buf);
-
-      disk_read_func = NULL;
-
-      buf += size;
-      len -= size;
-      filepos += size;
-      ret += size;
-    }
-
   if (errnum)
     ret = 0;
 
Index: fs/blockdev.c
===================================================================
--- fs/blockdev.c	(revision 34)
+++ fs/blockdev.c	(working copy)
@@ -335,6 +335,58 @@
     return 0;
 }
 
+/* reads many sectors from opened device into memory */
+static unsigned long read_manysectors(char *buf, unsigned long first_sector, unsigned long num_sectors)
+{
+    int n;
+
+    /* If reading memory, just copy it */
+    if (dev_type == DISK_MEM) {
+	unsigned long phys = first_sector << 9;
+	char *virt;
+	//debug("mem: %#lx\n", phys);
+	virt = phys_to_virt(phys);
+	memcpy(buf, virt, num_sectors * 512);
+	return num_sectors;
+    }
+
+    switch (dev_type) {
+#ifdef IDE_DISK
+    case DISK_IDE:
+	do {
+	    n = num_sectors <= 256 ? num_sectors : 256;
+	    if (ide_readmany(dev_drive, first_sector, n, buf) != 0)
+		goto readerr;
+	    first_sector += n;
+	    num_sectors -= n;
+	    buf += 512 * n;
+	} while (num_sectors);
+	break;
+#endif
+#ifdef USB_DISK
+    case DISK_USB:
+	while (num_sectors) {
+	    if (usb_read(dev_drive, first_sector, buf) != 0)
+		goto readerr;
+	    first_sector++;
+	    num_sectors--;
+	    buf += 512;
+	}
+	break;
+#endif
+    default:
+	printf("read_manysectors: device not open\n");
+	return 0;
+    }
+    return 1;
+
+readerr:
+    printf("Disk readmany error dev=%d drive=%d first_sector=%lu num_sectors=%lu\n",
+	    dev_type, dev_drive, first_sector, num_sectors);
+    dev_name[0] = '\0'; /* force re-open the device next time */
+    return 0;
+}
+
 int devread(unsigned long sector, unsigned long byte_offset,
 	unsigned long byte_len, void *buf)
 {
@@ -369,3 +421,22 @@
     }
     return 1;
 }
+
+/* reads many sectors from opened partition into memory */
+int devreadmany(void *buf,unsigned long first_sector, unsigned long num_sectors)
+{
+    char *dest = buf;
+    unsigned long last_sector = first_sector + num_sectors - 1;
+
+    if (last_sector > part_length) {
+	printf("Attempt to readmany out of device/partition\n");
+	debug("part_length=%lu last_sector=%lu\n", part_length, last_sector);
+	return 0;
+    }
+
+    debug("sectors %lu - %lu (%3lu) to %p\n", first_sector, last_sector, num_sectors, buf);
+    if (!read_manysectors (dest, part_start + first_sector, num_sectors))
+	return 0;
+
+    return 1;
+}
Index: i386/timer.c
===================================================================
--- i386/timer.c	(revision 34)
+++ i386/timer.c	(working copy)
@@ -44,7 +44,7 @@
 
 /* Timers tick over at this rate */
 #define CLOCK_TICK_RATE	1193180U
-#define	TICKS_PER_MS	(CLOCK_TICK_RATE/1000)
+#define	TICKS_PER_MS	1
 
 /* Parallel Peripheral Controller Port B */
 #define	PPC_PORTB	0x61
Index: i386/include/timer.h
===================================================================
--- i386/include/timer.h	(revision 34)
+++ i386/include/timer.h	(working copy)
@@ -37,8 +37,9 @@
 #define	BCD_COUNT	0x01
 
 /* Timers tick over at this rate */
-#define CLOCK_TICK_RATE	1193180U
-#define	TICKS_PER_MS	(CLOCK_TICK_RATE/1000)
+#define	CLOCK_TICK_RATE	1193180U
+#define	TICKS_PER_MS	1
+#define	TICKS_PER_SEC	(1000*TICKS_PER_MS)
 
 /* Parallel Peripheral Controller Port B */
 #define	PPC_PORTB	0x61
@@ -54,6 +55,4 @@
 extern void mdelay(unsigned int msecs);
 extern unsigned long currticks(void);
 
-#define TICKS_PER_SEC 1000
-
 #endif	/* TIMER_H */
Index: drivers/ide.c
===================================================================
--- drivers/ide.c	(revision 34)
+++ drivers/ide.c	(working copy)
@@ -1,4 +1,7 @@
-/* Derived from Etherboot 5.1 */
+/*
+ * FILO IDE driver
+ * Derived from Etherboot 5.1
+ */
 
 #include <lib.h>
 #include <fs.h>
@@ -19,6 +22,7 @@
  *   UBL, The Universal Talkware Boot Loader 
  *    Copyright (C) 2000 Universal Talkware Inc.
  *    Copyright (C) 2002 Eric Biederman
+ *    Copyright (C) 2007 Peter Stuge <peter at stuge.se>
  *
  *   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
@@ -39,6 +43,7 @@
 struct controller {
 	uint16_t cmd_base;
 	uint16_t ctrl_base;
+	uint8_t stat;
 };
 
 struct harddisk_info {
@@ -227,24 +232,26 @@
 
 static unsigned char ide_buffer[IDE_SECTOR_SIZE];
 
-static int await_ide(int (*done)(struct controller *ctrl), 
-	struct controller *ctrl, unsigned long timeout)
+static int bsy(struct controller *ctrl);
+static int drq(struct controller *ctrl);
+static int not_bsy(struct controller *ctrl);
+
+#define AWAIT_IDE(done, ctrl, timeout) await_ide(done, #done, ctrl, timeout)
+static int await_ide(int (*done)(struct controller *ctrl),
+	const char donename[], struct controller *ctrl, unsigned long timeout)
 {
 	int result;
-	for(;;) {
+	unsigned long start = currticks();
+	do {
 		result = done(ctrl);
 #if IDE_DISK_POLL_DELAY
 		mdelay(1);
 #endif
-		if (result) {
+		if (result)
 			return 0;
-		}
-		//poll_interruptions();
-		if ((timeout == 0) || (currticks() > timeout)) {
-			break;
-		}
-	}
-	printf("IDE time out\n");
+	} while ((timeout != 0) && (currticks() < start + timeout));
+
+	printf("IDE timeout after %lu ms while waiting for %s()\n", (timeout / TICKS_PER_MS), donename);
 	return -1;
 }
 
@@ -252,21 +259,30 @@
  * So if any IDE commands takes this long we know we have problems.
  */
 #define IDE_TIMEOUT (32*TICKS_PER_SEC)
+#define IDE_TIMEOUT_50ms (TICKS_PER_SEC/20)
 
 static int not_bsy(struct controller *ctrl)
 {
-	return !(inb(IDE_REG_STATUS(ctrl)) & IDE_STATUS_BSY);
+	ctrl->stat = inb(IDE_REG_ALTSTATUS(ctrl));
+	return !(ctrl->stat & IDE_STATUS_BSY);
 }
 
 /* IDE drives assert BSY bit within 400 nsec when SRST is set.
  * Use 2 msec since our tick is 1 msec */
-#define IDE_RESET_PULSE (2*TICKS_PER_SEC / 1000)
+#define IDE_RESET_PULSE (TICKS_PER_SEC)
 
 static int bsy(struct controller *ctrl)
 {
-	return inb(IDE_REG_STATUS(ctrl)) & IDE_STATUS_BSY;
+	ctrl->stat = inb(IDE_REG_STATUS(ctrl));
+	return ctrl->stat & IDE_STATUS_BSY;
 }
 
+static int drq(struct controller *ctrl)
+{
+	ctrl->stat = inb(IDE_REG_STATUS(ctrl));
+	return ctrl->stat & IDE_STATUS_DRQ;
+}
+
 #if  !BSY_SET_DURING_SPINUP
 static int timeout(struct controller *ctrl)
 {
@@ -292,7 +308,7 @@
 	 */
 	debug("Waiting for ide%d to become ready for reset... ",
 			ctrl - controllers);
-	if (await_ide(not_bsy, ctrl, currticks() + IDE_TIMEOUT) < 0) {
+	if (AWAIT_IDE(not_bsy, ctrl, IDE_TIMEOUT) < 0) {
 		debug("failed\n");
 		return -1;
 	}
@@ -302,12 +318,12 @@
 	outb(IDE_CTRL_HD15 | IDE_CTRL_SRST | IDE_CTRL_NIEN, 
 		IDE_REG_DEVICE_CONTROL(ctrl));
 	/* If BSY bit is not asserted within 400ns, no device there */
-	if (await_ide(bsy, ctrl, currticks() + IDE_RESET_PULSE) < 0) {
+	if (AWAIT_IDE(bsy, ctrl, IDE_RESET_PULSE) < 0) {
 		return -1;
 	}
 	outb(IDE_CTRL_HD15 | IDE_CTRL_NIEN, IDE_REG_DEVICE_CONTROL(ctrl));
 	mdelay(2);
-	if (await_ide(not_bsy, ctrl, currticks() + IDE_TIMEOUT) < 0) {
+	if (AWAIT_IDE(not_bsy, ctrl, IDE_TIMEOUT) < 0) {
 		return -1;
 	}
 	return 0;
@@ -348,13 +364,15 @@
 static int pio_non_data(struct controller *ctrl, const struct ide_pio_command *cmd)
 {
 	/* Wait until the busy bit is clear */
-	if (await_ide(not_bsy, ctrl, currticks() + IDE_TIMEOUT) < 0) {
+	if (AWAIT_IDE(not_bsy, ctrl, IDE_TIMEOUT) < 0) {
+		debug("Device not ready before sending command\n");
 		return -1;
 	}
 
 	pio_set_registers(ctrl, cmd);
 	ndelay(400);
-	if (await_ide(not_bsy, ctrl, currticks() + IDE_TIMEOUT) < 0) {
+	if (AWAIT_IDE(not_bsy, ctrl, IDE_TIMEOUT) < 0) {
+		debug("Device not ready after sending command\n");
 		return -1;
 	}
 	/* FIXME is there more error checking I could do here? */
@@ -364,31 +382,59 @@
 static int pio_data_in(struct controller *ctrl, const struct ide_pio_command *cmd,
 	void *buffer, size_t bytes)
 {
+	int drive;
+	size_t count;
 	unsigned int status;
 
-	/* FIXME handle commands with multiple blocks */
+	for(drive = 0; drive < IDE_MAX_DRIVES; drive++)
+		if(ctrl == harddisk_info[drive].ctrl)
+			break;
+	if(IDE_MAX_DRIVES == drive) {
+		debug("Invalid controller, not used for any drive\n");
+		return -1;
+	}
+
 	/* Wait until the busy bit is clear */
-	if (await_ide(not_bsy, ctrl, currticks() + IDE_TIMEOUT) < 0) {
+	if (AWAIT_IDE(not_bsy, ctrl, IDE_TIMEOUT) < 0) {
+		debug("Device not ready before sending command\n");
 		return -1;
 	}
 
 	/* How do I tell if INTRQ is asserted? */
 	pio_set_registers(ctrl, cmd);
 	ndelay(400);
-	if (await_ide(not_bsy, ctrl, currticks() + IDE_TIMEOUT) < 0) {
-		return -1;
-	}
-	status = inb(IDE_REG_STATUS(ctrl));
-	if (!(status & IDE_STATUS_DRQ)) {
-		print_status(ctrl);
-		return -1;
-	}
-	insw(IDE_REG_DATA(ctrl), buffer, bytes/2);
-	status = inb(IDE_REG_STATUS(ctrl));
-	if (status & IDE_STATUS_DRQ) {
-		print_status(ctrl);
-		return -1;
-	}
+
+	/* multi block capable logic inspired by OpenBIOS ide.c
+	 * ob_ide_pio_data_in() */
+	do {
+		count = bytes;
+		if (count > harddisk_info[drive].hw_sector_size)
+			count = harddisk_info[drive].hw_sector_size;
+		if (AWAIT_IDE(not_bsy, ctrl, IDE_TIMEOUT) < 0) {
+			debug("Device not ready before reading data\n");
+			return -1;
+		}
+		if (ctrl->stat & (IDE_STATUS_WFT | IDE_STATUS_ERR)) {
+			debug("IDE error before reading data\n");
+			print_status(ctrl);
+			return -1;
+		}
+		if (!(ctrl->stat & IDE_STATUS_DRQ))
+			if (AWAIT_IDE(drq, ctrl, IDE_TIMEOUT_50ms) < 0) {
+				debug("No DRQ from device after read command\n");
+				print_status(ctrl);
+				return -1;
+			}
+#ifdef IDE_32BIT_PIO
+		insl(IDE_REG_DATA(ctrl), buffer, count/4);
+#else
+		insw(IDE_REG_DATA(ctrl), buffer, count/2);
+#endif
+		buffer += count;
+		bytes -= count;
+		ndelay(400);
+	} while (bytes);
+
 	return 0;
 }
 
@@ -402,7 +448,7 @@
 	memset(&cmd, 0, sizeof(cmd));
 
 	/* Wait until the busy bit is clear */
-	if (await_ide(not_bsy, info->ctrl, currticks() + IDE_TIMEOUT) < 0) {
+	if (AWAIT_IDE(not_bsy, info->ctrl, IDE_TIMEOUT) < 0) {
 		return -1;
 	}
 
@@ -413,7 +459,7 @@
 	cmd.command = IDE_CMD_PACKET;
 	pio_set_registers(info->ctrl, &cmd);
 	ndelay(400);
-	if (await_ide(not_bsy, info->ctrl, currticks() + IDE_TIMEOUT) < 0) {
+	if (AWAIT_IDE(not_bsy, info->ctrl, IDE_TIMEOUT) < 0) {
 		return -1;
 	}
 	status = inb(IDE_REG_STATUS(info->ctrl));
@@ -426,7 +472,7 @@
 	/* Send the packet */
 	outsw(IDE_REG_DATA(info->ctrl), packet, packet_len/2);
 
-	if (await_ide(not_bsy, info->ctrl, currticks() + IDE_TIMEOUT) < 0) {
+	if (AWAIT_IDE(not_bsy, info->ctrl, IDE_TIMEOUT) < 0) {
 		return -1;
 	}
 	status = inb(IDE_REG_STATUS(info->ctrl));
@@ -445,19 +491,27 @@
 		return -1;
 	}
 
+#ifdef IDE_32BIT_PIO
+	insl(IDE_REG_DATA(info->ctrl), buffer, buffer_len/4);
+#else
 	insw(IDE_REG_DATA(info->ctrl), buffer, buffer_len/2);
-
+#endif
 	status = inb(IDE_REG_STATUS(info->ctrl));
 	if (status & IDE_STATUS_DRQ) {
+#ifdef IDE_32BIT_PIO
+		debug("drq after insl\n");
+#else
 		debug("drq after insw\n");
+#endif
 		print_status(info->ctrl);
 		return -1;
 	}
 	return 0;
 }
 
-static inline int ide_read_sector_chs(
-	struct harddisk_info *info, void *buffer, unsigned long sector)
+static inline int ide_read_sectors_chs(
+	struct harddisk_info *info, void *buffer, unsigned long sector,
+	unsigned long num_sectors)
 {
 	struct ide_pio_command cmd;
 	unsigned int track;
@@ -465,8 +519,11 @@
 	unsigned int cylinder;
 		
 	memset(&cmd, 0, sizeof(cmd));
-	cmd.sector_count = 1;
 
+	if (num_sectors > 256)
+		return -1;
+	cmd.sector_count = 256 == num_sectors ? 0 : num_sectors;
+
 	//debug("ide_read_sector_chs: sector= %ld.\n",sector);
 
 	track = sector / info->sectors_per_track;
@@ -481,16 +538,20 @@
 		info->slave |
 		IDE_DH_CHS;
 	cmd.command = IDE_CMD_READ_SECTORS;
-	return pio_data_in(info->ctrl, &cmd, buffer, IDE_SECTOR_SIZE);
+	return pio_data_in(info->ctrl, &cmd, buffer, IDE_SECTOR_SIZE * num_sectors);
 }
 
-static inline int ide_read_sector_lba(
-	struct harddisk_info *info, void *buffer, unsigned long sector)
+static inline int ide_read_sectors_lba(
+	struct harddisk_info *info, void *buffer, unsigned long sector,
+	unsigned long num_sectors)
 {
 	struct ide_pio_command cmd;
 	memset(&cmd, 0, sizeof(cmd));
 
-	cmd.sector_count = 1;
+	if (num_sectors > 256)
+		return -1;
+	cmd.sector_count = 256 == num_sectors ? 0 : num_sectors;
+
 	cmd.lba_low = sector & 0xff;
 	cmd.lba_mid = (sector >> 8) & 0xff;
 	cmd.lba_high = (sector >> 16) & 0xff;
@@ -500,17 +561,20 @@
 		IDE_DH_LBA;
 	cmd.command = IDE_CMD_READ_SECTORS;
 	//debug("%s: sector= %ld, device command= 0x%x.\n",__FUNCTION__,(unsigned long) sector, cmd.device);
-	return pio_data_in(info->ctrl, &cmd, buffer, IDE_SECTOR_SIZE);
+	return pio_data_in(info->ctrl, &cmd, buffer, IDE_SECTOR_SIZE * num_sectors);
 }
 
-static inline int ide_read_sector_lba48(
-	struct harddisk_info *info, void *buffer, sector_t sector)
+static inline int ide_read_sectors_lba48(
+	struct harddisk_info *info, void *buffer, sector_t sector, sector_t num_sectors)
 {
 	struct ide_pio_command cmd;
 	memset(&cmd, 0, sizeof(cmd));
 	//debug("ide_read_sector_lba48: sector= %ld.\n",(unsigned long) sector);
 
-	cmd.sector_count = 1;
+	if (num_sectors > 256)
+		return -1;
+	cmd.sector_count = 256 == num_sectors ? 0 : num_sectors;
+
 	cmd.lba_low = sector & 0xff;
 	cmd.lba_mid = (sector >> 8) & 0xff;
 	cmd.lba_high = (sector >> 16) & 0xff;
@@ -519,7 +583,7 @@
 	cmd.lba_high2 = (sector >> 40) & 0xff;
 	cmd.device =  info->slave | IDE_DH_LBA;
 	cmd.command = IDE_CMD_READ_SECTORS_EXT;
-	return pio_data_in(info->ctrl, &cmd, buffer, IDE_SECTOR_SIZE);
+	return pio_data_in(info->ctrl, &cmd, buffer, IDE_SECTOR_SIZE * num_sectors);
 }
 
 static inline int ide_read_sector_packet(
@@ -567,27 +631,39 @@
 	return 0;
 }
 
-int ide_read(int drive, sector_t sector, void *buffer)
+int ide_readmany(int drive, sector_t first_sector, sector_t num_sectors, void *buffer)
 {
 	struct harddisk_info *info = &harddisk_info[drive];
 	int result;
+	sector_t i, last_sector = first_sector + num_sectors - 1;
 
-	//debug("drive=%d, sector=%ld\n",drive,(unsigned long) sector);
-	/* Report the buffer is empty */
-	if (sector > info->sectors) {
+	if (0 == num_sectors) {
+		debug("0 sectors requested, nothing read\n");
+		return 0;
+	}
+	if (1 == num_sectors)
+		debug("sector %Lu to 0x%p\n", first_sector, buffer);
+	else
+		debug("sectors %Lu - %Lu (%3Lu) to 0x%p\n", first_sector, last_sector, num_sectors, buffer);
+	if (last_sector > info->sectors) {
+		debug("attempt to read past end of device");
 		return -1;
 	}
 	if (info->address_mode == ADDRESS_MODE_CHS) {
-		result = ide_read_sector_chs(info, buffer, sector);
+		result = ide_read_sectors_chs(info, buffer, first_sector, num_sectors);
 	}
 	else if (info->address_mode == ADDRESS_MODE_LBA) {
-		result = ide_read_sector_lba(info, buffer, sector);
+		result = ide_read_sectors_lba(info, buffer, first_sector, num_sectors);
 	}
 	else if (info->address_mode == ADDRESS_MODE_LBA48) {
-		result = ide_read_sector_lba48(info, buffer, sector);
+		result = ide_read_sectors_lba48(info, buffer, first_sector, num_sectors);
 	}
 	else if (info->address_mode == ADDRESS_MODE_PACKET) {
-		result = ide_read_sector_packet(info, buffer, sector);
+		for(i = 0; i < num_sectors; i++) {
+			result = ide_read_sector_packet(info, buffer, first_sector + i);
+			if (-1 == result)
+				return result;
+		}
 	}
 	else {
 		result = -1;
@@ -595,6 +671,11 @@
 	return result;
 }
 
+int ide_read(int drive, sector_t sector, void *buffer)
+{
+	return ide_readmany(drive, sector, 1, buffer);
+}
+
 static int init_drive(struct harddisk_info *info, struct controller *ctrl,
 		int slave, int drive, unsigned char *buffer, int ident_command)
 {
@@ -864,7 +945,7 @@
 	 * 
 	 */
 #if !BSY_SET_DURING_SPINUP
-	if (await_ide(timeout, ctrl, currticks() + IDE_TIMEOUT) < 0) {
+	if (AWAIT_IDE(timeout, ctrl, IDE_TIMEOUT) < 0) {
 		return -1;
 	}
 #endif

From nikolaypetukhov at gmail.com  Mon Jun  4 14:15:17 2007
From: nikolaypetukhov at gmail.com (Nikolay Petukhov)
Date: Mon, 4 Jun 2007 18:15:17 +0600
Subject: [LinuxBIOS] new target iei juki-511p/rocky-512
Message-ID: <e24af7500706040515j3e2e7ef7k5e86485e81d9555f@mail.gmail.com>

Hi,

2007/6/3, Stefan Reinauer <stepan at coresystems.de>:
> Please sign off the patch according to
> http://www.linuxbios.org/Development_Guidelines#Sign-off_Procedure
> so we can check this patch in!


Add sign-off.


2007/6/3, Juergen Beisert <juergen127 at kreuzholzen.de>:
> As your dmesg output shows, the graphical console is active. I missed
> something to setup correctly. When my LinuxBIOS activates the VGA the linux
> console runs as expected. Without it, everything seems ok, but no output
> occures. I don't know why, yet.


How You activates VGA in LinuxBios?


2007/6/3, Uwe Hermann <uwe at hermann-uwe.de>:
> On Sun, Jun 03, 2007 at 12:20:10AM +0600, Nikolay Petukhov wrote:
> > Problems:
> > Filo load bzImage only from ide0.
>
> What does not work? ide1? AFAICS the boards only have one IDE port!?


The this boards has two IDE ports. IDE0 has 40-pin IDE connector. IDE1
has CF connector.


> > diff -Nru LinuxBIOSv2-2700/src/mainboard/iei/juki511p/auto.c LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/auto.c
> > --- LinuxBIOSv2-2700/src/mainboard/iei/juki511p/auto.c        1970-01-01 05:00:00.000000000 +0500
> > +++ LinuxBIOSv2-2700-juki/src/mainboard/iei/juki511p/auto.c   2007-06-02 20:02:10.000000000 +0600
>
> Please rename the directory to 'juki-511p' if possible, as that seems to be
> the canonical (lowercase'd) name used by the vendor.


I had change directory name to 'juki_511p'.


> > +#include "superio/winbond/w83977fa/w83977fa_early_serial.c"
>
> Maybe this should be 'w83977f' (without the 'a')? IIRC, we omitted any
> '-A' or '-AW' suffix from other Super I/Os, too. Comments anyone?


I agree. I did it.


>
>
> > +void udelay(int usecs)
> > +{
> > +     int i;
> > +     for(i = 0; i < usecs; i++)
> > +             outb(i&0xff, 0x80);
> > +}
>
> Is this needed? There's a global implementation in the repository
> already.
>


I removed it.


>
> > +            device pnp 3f0.4 on              # RTC
> > +            end
>
> Is this ok if left empty?
>
> My 'lspnp -v' (on another mainboard) says:
>
> 00:04 PNP0b00 AT real-time clock
>     state = active
>         io 0x70-0x71
>         irq 8
>
> So maybe something like
>
>   device pnp 3f0.4 on              # RTC
>     io 0x60 = 0x70
>     irq 0x70 = 8
>   end
>
> is needed here? I'm just guessing, though, please correct me if I'm
> wrong.
>
>
> > +            device pnp 3f0.5 on              # Keyboard
> > +               io 0x60 = 0x60
> > +               io 0x62 = 0x64
> > +              irq 0x70 = 0x01     # int  1 for PS/2 keyboard
> > +              irq 0x72 = 0x0c     # int 12 for PS/2 mouse
>
> Why not like this? Easier to read, IMHO:
>
>   irq 0x70 = 1     # int  1 for PS/2 keyboard
>   irq 0x72 = 12    # int 12 for PS/2 mouse


> > +const struct irq_routing_table intel_irq_routing_table = {
> > +     PIRQ_SIGNATURE,  /* u32 signature */
> > +     PIRQ_VERSION,    /* u16 version   */
> > +     32+16*2,         /* There can be total 6 devices on the bus */
>                                                ^
> typo? --->                                     2?
>
> Maybe even
>
>   32+16*IRQ_SLOT_COUNT,         /* There can be IRQ_SLOT_COUNT devices on the bus */


I corrected it.


> > diff -Nru LinuxBIOSv2-2700/src/northbridge/amd/gx1/raminit.c LinuxBIOSv2-2700-juki/src/northbridge/amd/gx1/raminit.c
> > --- LinuxBIOSv2-2700/src/northbridge/amd/gx1/raminit.c        2005-07-06 23:11:02.000000000 +0600
> > +++ LinuxBIOSv2-2700-juki/src/northbridge/amd/gx1/raminit.c   2007-05-31 16:06:40.000000000 +0600
> > @@ -324,6 +324,7 @@
> >       outb(0x70, 0x80);
> >
> >       setGX1Mem(GX_BASE + MC_MEM_CNTRL2, 0x000007d8); /* Disable all CLKS, Shift = 3 */
> > +//   setGX1Mem(GX_BASE + MC_MEM_CNTRL1, 0x92080000); /* MD_DS=2, MA_DS=2, CNTL_DS=2 SDCLKRATE=2.5 */
> >       setGX1Mem(GX_BASE + MC_MEM_CNTRL1, 0x92140000); /* MD_DS=2, MA_DS=2, CNTL_DS=2 SDCLKRATE=4 */
> >       setGX1Mem(GX_BASE + MC_BANK_CFG,   0x00700070); /* No DIMMS installed */
> >       setGX1Mem(GX_BASE + MC_SYNC_TIM1,  0x3a733225); /* LTMODE=3, RC=10, RAS=7, RP=3, RCD=3, RRD=2, DPL=2 */
>
> OK, not sure what we should do with this. Will it break other GX1-based
> mainboards? Or is it generic for all GX1s?


I removed it.


> > diff -Nru LinuxBIOSv2-2700/src/superio/winbond/w83977fa/chip.h LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/chip.h
> > --- LinuxBIOSv2-2700/src/superio/winbond/w83977fa/chip.h      1970-01-01 05:00:00.000000000 +0500
> > +++ LinuxBIOSv2-2700-juki/src/superio/winbond/w83977fa/chip.h 2007-06-02 18:52:57.000000000 +0600
>
> Please provide an extra patch for the addition of the new Super I/O,
> this is independant of the mainboards...
>
>
> > diff -Nru LinuxBIOSv2-2700/targets/iei/juki511p/Config.lb LinuxBIOSv2-2700-juki/targets/iei/juki511p/Config.lb
> > --- LinuxBIOSv2-2700/targets/iei/juki511p/Config.lb   1970-01-01 05:00:00.000000000 +0500
> > +++ LinuxBIOSv2-2700-juki/targets/iei/juki511p/Config.lb      2007-06-02 19:07:21.000000000 +0600
>
> Please add a copyright header to this file, too.

Signed-off-by: Nikolay Petukhov  <nikolay.petukhov at gmail.com>

-- 
Nikolay

-----------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LinuxBIOSv2-2700-w83977f.040607.diff
Type: text/x-patch
Size: 10407 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070604/0e012987/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LinuxBIOSv2-2700-juki.040607.diff
Type: text/x-patch
Size: 23854 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070604/0e012987/attachment-0001.diff>

From stuge-linuxbios at cdy.org  Mon Jun  4 18:11:31 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 4 Jun 2007 18:11:31 +0200
Subject: [LinuxBIOS] Question about protect mode?
In-Reply-To: <1180808759.8397.27.camel@ragnarok>
References: <2386d0e70705281950q7aef237bp89a388789c2cfc6a@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B1729FE34@sbjgexmb1.amd.com>
	<a505dc9d0705310200i12a3251ew16b5c8d6c968a5d9@mail.gmail.com>
	<200705311456.32413.juergen127@kreuzholzen.de>
	<a505dc9d0706020125g2818b670p219ae47e55f1c3d8@mail.gmail.com>
	<1180808759.8397.27.camel@ragnarok>
Message-ID: <20070604161131.6865.qmail@cdy.org>

On Sat, Jun 02, 2007 at 02:25:59PM -0400, Jeremy Jackson wrote:
> Can you please explain which chipset northbridge does this?  I've
> never seen one that uses the PCI bus in this fashion, but I'd like
> to know if there is one.

Southbridge. See ICH7 and/or ICH8.


//Peter



From yinghailu at gmail.com  Mon Jun  4 18:21:31 2007
From: yinghailu at gmail.com (yhlu)
Date: Mon, 4 Jun 2007 09:21:31 -0700
Subject: [LinuxBIOS] Linux can't run.
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B172E41DA@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B172A0022@sbjgexmb1.amd.com>
	<13426df10705310722p51f2b84dl710345509c21eff1@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B172E41DA@sbjgexmb1.amd.com>
Message-ID: <2ea3fae10706040921r3b5dcbd8jb2d4eac8c1491a18@mail.gmail.com>

please try to use latest kernel, and fix your mptable in LinuxBIOS
according to your schematic and chipset data sheet about irq routing.

YH



From stuge-linuxbios at cdy.org  Mon Jun  4 18:22:11 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 4 Jun 2007 18:22:11 +0200
Subject: [LinuxBIOS] BBS
In-Reply-To: <000601c7a5eb$b992c610$6401a8c0@dell>
References: <000601c7a5eb$b992c610$6401a8c0@dell>
Message-ID: <20070604162211.8505.qmail@cdy.org>

On Sun, Jun 03, 2007 at 03:30:24PM +0100, Graeme Brett Houston BSc wrote:
> make LinuxBIOS part of the Bios Boot spec so that a addon card like
> a RTL8139B could carry LinuxBIOS on the ROM and allow rapid
> development without replacing mainboard bios until sure that it
> will power up system.

I'm afraid this is difficult to do since by the time LinuxBIOS would
be called by the system BIOS a lot of extra work might be required to
undo what the system BIOS has done.

There is less confusion and uncertainty immediately after power-on,
even though that isn't perfect either.


//Peter



From stuge-linuxbios at cdy.org  Mon Jun  4 18:29:30 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 4 Jun 2007 18:29:30 +0200
Subject: [LinuxBIOS] Problem with FILO
In-Reply-To: <751d98080706010744h25bddc0fj854ec1d45c6737c3@mail.gmail.com>
References: <751d98080706010744h25bddc0fj854ec1d45c6737c3@mail.gmail.com>
Message-ID: <20070604162930.9708.qmail@cdy.org>

On Fri, Jun 01, 2007 at 11:44:13AM -0300, Ot?vio Alc?ntara wrote:
> Is possible to choose more than one file system, I mean, FAT and
> EXT2?

Yes, that should work just fine.

Please try the patch I sent to the list a while ago and send back the
debug output you get.

Thanks!


//Peter



From stuge-linuxbios at cdy.org  Mon Jun  4 18:42:31 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 4 Jun 2007 18:42:31 +0200
Subject: [LinuxBIOS] which motherboard would be the better choice
In-Reply-To: <08712cf9979c4330a524a248d52eecc4@mx243m.mysite4now.com>
References: <08712cf9979c4330a524a248d52eecc4@mx243m.mysite4now.com>
Message-ID: <20070604164231.11702.qmail@cdy.org>

On Sun, Jun 03, 2007 at 11:36:16PM -0700, Mike Dilworth wrote:
> 


Your email software (it looks like a webmail) sends messages with
incorrect line endings. Perhaps you could ask your provider to update
the software.


> Amongst other things I am a c/c++ programmer and I would be very
> interested in dabble in Linux Bios however I have almost no free
> time these days.  In your opinion how much work is needed. Consider
> I know pretty much zero about LinuxBios but rate highly as a c
> programmer, I am also a fast learner, and that I could perhaps give
> the effort about 10-15hrs a week. How many weeks do you think its
> going to take?

Writing the code is not all that hard. A bold guess is 20 hours for
a port with all new components.

Acquiring documentation and knowledge required to actually write that
code is probably more like 200-400 hours however. :\


//Peter



From marc.jones at amd.com  Mon Jun  4 18:41:39 2007
From: marc.jones at amd.com (Marc Jones)
Date: Mon, 04 Jun 2007 10:41:39 -0600
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
 but ...
In-Reply-To: <20070603193827.GC15426@greenwood>
References: <20070531194024.GB3955@bloms.de>
	<20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
	<20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood>
Message-ID: <466440C3.6040809@amd.com>



Uwe Hermann wrote:
> On Sat, Jun 02, 2007 at 10:17:21AM -0400, joe at smittys.pointclark.net wrote:
>>> it is a winbond W83627HF-AW
>> Hmm, on the LB website there is a big ? next to the winbond W83627HF,  
>> Has anyone else had sucess wih this chip?
> 
> I'm pretty confident that it should work, haven't tried it myself
> though.
> 
> 
> Uwe.

The W83627HF code works for me. I have 2 out of 3 platforms that use it 
working. The third platform has a problem on the serial lines. I am 99% 
sure that this is a hardware issue. I think that serial power supply is 
out of spec.

Marc


-- 
Marc Jones
Senior Software Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





From stuge-linuxbios at cdy.org  Mon Jun  4 19:04:02 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 4 Jun 2007 19:04:02 +0200
Subject: [LinuxBIOS] AMD cs5536 uart disable
In-Reply-To: <9ea556971cc803e69f749add76b8d784@kernel.crashing.org>
References: <465E0E52.6040400@amd.com>
	<13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
	<20070602235926.GC17654@greenwood>
	<20070604034400.GA8716@cosmic.amd.com>
	<20070604064839.GA7478@greenwood>
	<20070604144436.GC5442@cosmic.amd.com>
	<20070604151415.GA2518@coresystems.de>
	<9ea556971cc803e69f749add76b8d784@kernel.crashing.org>
Message-ID: <20070604170402.15717.qmail@cdy.org>

On Mon, Jun 04, 2007 at 05:27:47PM +0200, Segher Boessenkool wrote:
> >> -p0?  Is that seriously the standard here?  Can I ask why?
> >
> > Purely convenience of the patch reviewers / people doing the check-ins.
> 
> I'm sure you mean you want -p1 patches, instead?

Are -p0 and -p1 equivalent if the patch has a relative filename as
opposed to an absolute? This is only academia anyway.

Please send patches generated from the root of the svn tree; the
LinuxBIOSv2 or v3 subdirectory.


//Peter



From dieter at bloms.de  Mon Jun  4 19:36:03 2007
From: dieter at bloms.de (Dieter Bloms)
Date: Mon, 4 Jun 2007 19:36:03 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <466440C3.6040809@amd.com>
References: <20070531194024.GB3955@bloms.de>
	<20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
	<20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
Message-ID: <20070604173602.GE3251@bloms.de>

Hi,

> The W83627HF code works for me. I have 2 out of 3 platforms that use it 
> working. The third platform has a problem on the serial lines. I am 99% 
> sure that this is a hardware issue. I think that serial power supply is 
> out of spec.

the serial console works, when I boot linux.
I think I made a mistake while write the Config.lb or auto.c file.

When should I see anything on the console ?
Must all chips already be up, so the northbridge i855gm may be the
problem, or is the winbond the only chip, which should be up to the
anything on the console ?

I don't know where to search now.


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070604/a82d698a/attachment.sig>

From libv at skynet.be  Mon Jun  4 20:42:56 2007
From: libv at skynet.be (Luc Verhaegen)
Date: Mon, 4 Jun 2007 20:42:56 +0200
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux
	compatable	BIOS programmer ?]
In-Reply-To: <20070604153938.32310.qmail@cdy.org>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<200508130547.j7D5l8D30326@ecstasy1.winternet.com>
	<42FF0E53.4010902@linuxmachines.com>
	<200508151056.38490.p.millar@physics.gla.ac.uk>
	<4300973D.4020601@linuxmachines.com>
	<1180812548.8397.30.camel@ragnarok>
	<20070604153938.32310.qmail@cdy.org>
Message-ID: <20070604184256.GA7451@skynet.be>

On Mon, Jun 04, 2007 at 05:39:37PM +0200, Peter Stuge wrote:
> On Sat, Jun 02, 2007 at 03:29:08PM -0400, Jeremy Jackson wrote:
> > Sorry to jump in a bit late here, but for parallel flash, what
> > about using a NIC with a boot ROM socket?  I've used that for both
> > PLCC32 and DIP32 parts.
> 
> You mean for salvaging flash parts? They're usually small. 128kb.
> 
> The flash chip on those cards isn't reachable until after PCI init
> has set an address for it so it's not that handy for booting.
> 
> Sorry - what are you suggesting? :)
> 
> 
> //Peter

Well, this is just for flashrom i think, you only tend to run flashrom 
when running an operating system :)

This is a good idea, and somebody on irc recently brought it up (too?).  

ctflasher has some (oddly licensed) code to this end, and there is no 
need to copy this code, as the actual functionality is limited to 
knowing which BAR to use and what offset address. ctflasher and author 
should of course be mentioned for good measure.

Now, the code in there is for:
* via rhine
* 3com vortex
* those intel 100base cards
* those common realtek chips.

I currently have all but the intel cards, and these sadly all have DIP
roms, but this should be enough to get such an implementation started.

Also, uniflash has some code for some graphics cards. I sadly only have 
one graphics card with a PLCC flash, and i'm not sure if flashing 
through that is supported by the hardware, let alone me finding out how 
to pull it off. But i will hopefully, in time, be able to add support 
for many graphics cards.

If somebody wants to have a crack at implementing any of this before me, 
please, by all means, do, i have so many things piling up now that it 
ain't fun any more :)

Also, implementation wise, we might want flashrom to take in a pcitag 
for this sort of flashing to be enabled. This is a reasonably idiot 
proof solution as to not accidentally flash the wrong rom to the wrong 
place.

Luc Verhaegen.



From ben at hewson-venieri.com  Mon Jun  4 20:50:37 2007
From: ben at hewson-venieri.com (Ben Hewson)
Date: Mon, 04 Jun 2007 19:50:37 +0100
Subject: [LinuxBIOS] epia patch
Message-ID: <46645EFD.2030502@hewson-venieri.com>

Here is a patch to hopefully fix the random hangs that occur with the 
EPIA board.


There is a comment that says

    // Set bit 6 of 0x40, because Award does it (IO recovery time)
    // IMPORTANT FIX - EISA 0x4d0 decoding must be on so that PCI
    // interrupts can be properly marked as level triggered.

however somewhere in the translation from V1 to V2  it appears the 
relevant bit
of code was removed or deleted.


Signed-off-by: Ben Hewson <ben at hewson-venieri.com>

-------------------------------------------------------------------------------------------------------------


I can't say for sure this has fixed the issue. should I get any more 
hangs though I will post a note.
I have a feeling though this may be the cause as hangs seem to mostly 
occur during heavy IO port access.
Mostly in the SMBus routines where inb() is used for a delay.

Ben




From ben at hewson-venieri.com  Mon Jun  4 20:51:19 2007
From: ben at hewson-venieri.com (Ben Hewson)
Date: Mon, 04 Jun 2007 19:51:19 +0100
Subject: [LinuxBIOS] epia patch
Message-ID: <46645F27.9060609@hewson-venieri.com>

Here is a patch to hopefully fix the random hangs that occur with the
EPIA board.


There is a comment that says

    // Set bit 6 of 0x40, because Award does it (IO recovery time)
    // IMPORTANT FIX - EISA 0x4d0 decoding must be on so that PCI
    // interrupts can be properly marked as level triggered.

however somewhere in the translation from V1 to V2  it appears the
relevant bit
of code was removed or deleted.


Signed-off-by: Ben Hewson <ben at hewson-venieri.com>

-------------------------------------------------------------------------------------------------------------



I can't say for sure this has fixed the issue. should I get any more
hangs though I will post a note.
I have a feeling though this may be the cause as hangs seem to mostly
occur during heavy IO port access.
Mostly in the SMBus routines where inb() is used for a delay.

Ben

and I forgot the patch again

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: epia_hang.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070604/30aa48aa/attachment.ksh>

From corey.osgood at gmail.com  Mon Jun  4 20:54:09 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Mon, 04 Jun 2007 14:54:09 -0400
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070604155851.4065.qmail@cdy.org>
References: <20070601144106.GA5671@flashgordon>	<20070601151455.GA7454@countzero.vandewege.net>
	<20070604155851.4065.qmail@cdy.org>
Message-ID: <46645FD1.8090808@gmail.com>

Peter Stuge wrote:
> On Fri, Jun 01, 2007 at 11:14:55AM -0400, Ward Vandewege wrote:
>   
>>> -I had to use the delay in filo.c (cmp.
>>> http://www.linuxbios.org/GIGABYTE_GA-M57SLI-S4_Build_Tutorial)
>>>       
>> Yes.
>>
>>     
>>> -it takes quite long to load vmlinuz and the initrd.img. Probably
>>> due to: IDE_DISK_POLL_DELAY = 1 (?)
>>>       
>> Yes. Peter Stuge was working on a patch to speedup FILO. We should
>> revisit that.
>>     
>
> I would appreciate any feedback I can get on the patch. It needs more
> testing.
>
> As far as I know, it has been confirmed to work on M57SLI by Ward and
> fail on VMware by Corey.
Wasn't me! You mean Ceri, I think. I'll be testing it soon on the i810.

-Corey



From stuge-linuxbios at cdy.org  Mon Jun  4 21:11:37 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 4 Jun 2007 21:11:37 +0200
Subject: [LinuxBIOS] epia patch
In-Reply-To: <46645F27.9060609@hewson-venieri.com>
References: <46645F27.9060609@hewson-venieri.com>
Message-ID: <20070604191137.6565.qmail@cdy.org>

On Mon, Jun 04, 2007 at 07:51:19PM +0100, Ben Hewson wrote:
> I can't say for sure this has fixed the issue. should I get any
> more hangs though I will post a note.

Give it a few days, if no hang let's commit.


//Peter



From stuge-linuxbios at cdy.org  Mon Jun  4 21:14:30 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 4 Jun 2007 21:14:30 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <46645FD1.8090808@gmail.com>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
	<20070604155851.4065.qmail@cdy.org> <46645FD1.8090808@gmail.com>
Message-ID: <20070604191431.7108.qmail@cdy.org>

On Mon, Jun 04, 2007 at 02:54:09PM -0400, Corey Osgood wrote:
> > I would appreciate any feedback I can get on the patch. It needs
> > more testing.
> >
> > As far as I know, it has been confirmed to work on M57SLI by Ward
> > and fail on VMware by Corey.
> 
> Wasn't me! You mean Ceri, I think.

Sorry about the accusation. :)

I meant Joe Pub.


> I'll be testing it soon on the i810.

Great!


//Peter



From segher at kernel.crashing.org  Mon Jun  4 21:23:51 2007
From: segher at kernel.crashing.org (Segher Boessenkool)
Date: Mon, 4 Jun 2007 21:23:51 +0200
Subject: [LinuxBIOS] AMD cs5536 uart disable
In-Reply-To: <20070604170402.15717.qmail@cdy.org>
References: <465E0E52.6040400@amd.com>
	<13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
	<20070602235926.GC17654@greenwood>
	<20070604034400.GA8716@cosmic.amd.com>
	<20070604064839.GA7478@greenwood>
	<20070604144436.GC5442@cosmic.amd.com>
	<20070604151415.GA2518@coresystems.de>
	<9ea556971cc803e69f749add76b8d784@kernel.crashing.org>
	<20070604170402.15717.qmail@cdy.org>
Message-ID: <cc5c2d95e14f55f1642342c54b2fc76f@kernel.crashing.org>

>>>> -p0?  Is that seriously the standard here?  Can I ask why?
>>>
>>> Purely convenience of the patch reviewers / people doing the 
>>> check-ins.
>>
>> I'm sure you mean you want -p1 patches, instead?
>
> Are -p0 and -p1 equivalent if the patch has a relative filename as
> opposed to an absolute? This is only academia anyway.

No, they are never equivalent; -p1 strips everything up
to and including the first slash from every pathname,
-p0 doesn't.  You *always* need to use one of -p0 and
-p1 fwiw.

> Please send patches generated from the root of the svn tree; the
> LinuxBIOSv2 or v3 subdirectory.

Sounds advice.  For some reason "svn diff" seems to
generate -p0 style patches; every sane tool in the world
uses -p1.  Oh who cares, either style is trivial to
deal with.


Segher




From stepan at coresystems.de  Mon Jun  4 21:37:08 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 4 Jun 2007 21:37:08 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070604173602.GE3251@bloms.de>
References: <20070531194024.GB3955@bloms.de>
	<20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
	<20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
Message-ID: <20070604193708.GB9114@coresystems.de>

* Dieter Bloms <dieter at bloms.de> [070604 19:36]:
> When should I see anything on the console ?
> Must all chips already be up, so the northbridge i855gm may be the
> problem, or is the winbond the only chip, which should be up to the
> anything on the console ?

Is your target using the correct superio driver in auto.c? It's not
enough to set it in Config.lb (unfortunately)

Is the SuperIO maybe listening on 4e instead of 2e?

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From uwe at hermann-uwe.de  Mon Jun  4 22:24:26 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 4 Jun 2007 22:24:26 +0200
Subject: [LinuxBIOS] AMD cs5536 uart disable
In-Reply-To: <20070604144436.GC5442@cosmic.amd.com>
References: <465E0E52.6040400@amd.com>
	<13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
	<20070602235926.GC17654@greenwood>
	<20070604034400.GA8716@cosmic.amd.com>
	<20070604064839.GA7478@greenwood>
	<20070604144436.GC5442@cosmic.amd.com>
Message-ID: <20070604202425.GB22826@greenwood>

On Mon, Jun 04, 2007 at 08:44:36AM -0600, Jordan Crouse wrote:
> On 04/06/07 08:48 +0200, Uwe Hermann wrote:
> > I.e., the "full" relative path to the file being modified is included
> > in the patch, so you can 'patch -p0 < ~/foo.patch' at the top-level to
> > apply the patch.
> 
> -p0?  Is that seriously the standard here?  Can I ask why?

No standard (or rather: not really), it's just what you get when you do
'svn diff > foo.patch' at the top-level.

Either -p0 or -p1 is fine, I don't care.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070604/9b7a8540/attachment.sig>

From uwe at hermann-uwe.de  Mon Jun  4 22:26:22 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Mon, 4 Jun 2007 22:26:22 +0200
Subject: [LinuxBIOS] AMD cs5536 uart disable
In-Reply-To: <cc5c2d95e14f55f1642342c54b2fc76f@kernel.crashing.org>
References: <465E0E52.6040400@amd.com>
	<13426df10705310714h50ea44f5pf530efbb971e7287@mail.gmail.com>
	<20070602235926.GC17654@greenwood>
	<20070604034400.GA8716@cosmic.amd.com>
	<20070604064839.GA7478@greenwood>
	<20070604144436.GC5442@cosmic.amd.com>
	<20070604151415.GA2518@coresystems.de>
	<9ea556971cc803e69f749add76b8d784@kernel.crashing.org>
	<20070604170402.15717.qmail@cdy.org>
	<cc5c2d95e14f55f1642342c54b2fc76f@kernel.crashing.org>
Message-ID: <20070604202622.GC22826@greenwood>

On Mon, Jun 04, 2007 at 09:23:51PM +0200, Segher Boessenkool wrote:
> Sounds advice.  For some reason "svn diff" seems to
> generate -p0 style patches; every sane tool in the world
> uses -p1.

Why? What's so special about -p1? Why should -p0 be worse?
Just curios...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070604/24ccbe6f/attachment.sig>

From dieter at bloms.de  Mon Jun  4 23:42:44 2007
From: dieter at bloms.de (Dieter Bloms)
Date: Mon, 4 Jun 2007 23:42:44 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070604193708.GB9114@coresystems.de>
References: <20070531194024.GB3955@bloms.de>
	<20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
	<20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
Message-ID: <20070604214244.GA3257@bloms.de>

Hi Stefan,

On Mon, Jun 04, Stefan Reinauer wrote:

> * Dieter Bloms <dieter at bloms.de> [070604 19:36]:
> > When should I see anything on the console ?
> > Must all chips already be up, so the northbridge i855gm may be the
> > problem, or is the winbond the only chip, which should be up to the
> > anything on the console ?
> 
> Is your target using the correct superio driver in auto.c? It's not
> enough to set it in Config.lb (unfortunately)

for now my auto.c looks like:

--snip--
#define ASSEMBLY 1
#define ASM_CONSOLE_LOGLEVEL 8
#include <stdint.h>
#include <device/pci_def.h>
#include <arch/io.h>
#include <device/pnp_def.h>
#include <arch/romcc_io.h>
#include <arch/hlt.h>
#include "option_table.h"
#include "pc80/mc146818rtc_early.c"
#include "pc80/serial.c"
#include "arch/i386/lib/console.c"
#include "ram/ramtest.c"
#include "cpu/x86/mtrr/earlymtrr.c"
#include "cpu/x86/bist.h"

#include "superio/winbond/w83627hf/w83627hf.h"
#include "superio/winbond/w83627hf/w83627hf_early_serial.c"
#include "superio/winbond/w83627hf/w83627hf_early_init.c"

#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1)

static void main(unsigned long bist)
{
        /* Setup the console */
        w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE);
        uart_init();
        console_init();
        print_err("Hello\n");
}
--snip--

> Is the SuperIO maybe listening on 4e instead of 2e?

where can I see where the superio is listening on ?

I've changed the address from 2e to 4e in auto.c and Config.lb, but it
didn't change anything.


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070604/80aae39d/attachment.sig>

From stepan at coresystems.de  Mon Jun  4 23:48:46 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 4 Jun 2007 23:48:46 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070604214244.GA3257@bloms.de>
References: <20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
	<20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
Message-ID: <20070604214846.GA14123@coresystems.de>

* Dieter Bloms <dieter at bloms.de> [070604 23:42]:
> #include "superio/winbond/w83627hf/w83627hf.h"
> #include "superio/winbond/w83627hf/w83627hf_early_serial.c"
> #include "superio/winbond/w83627hf/w83627hf_early_init.c"
> 
> #define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1)
                             ^^^^ 

> w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE);
 
> > Is the SuperIO maybe listening on 4e instead of 2e?
> 
> where can I see where the superio is listening on ?
 
Is your SuperIO a Winbond W83627HF? (Search the board for a chip close
to bios chip and the ports)

> I've changed the address from 2e to 4e in auto.c and Config.lb, but it
> didn't change anything.
 
Ok. This is bad. To some extent. Your southbridge is an ICH4, right?
I will go read the ICH4 data sheet some more on thursday to figure
something out.

I have a very similar problem with a very similar board, but I did not
try 4e yet. Chances are that it's a similar problem.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From stepan at coresystems.de  Mon Jun  4 23:50:32 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 4 Jun 2007 23:50:32 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070604214846.GA14123@coresystems.de>
References: <20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
	<20070604214846.GA14123@coresystems.de>
Message-ID: <20070604215032.GA17613@coresystems.de>

* Stefan Reinauer <stepan at coresystems.de> [070604 23:48]:
> Ok. This is bad. To some extent. Your southbridge is an ICH4, right?
> I will go read the ICH4 data sheet some more on thursday to figure
> something out.
> 
> I have a very similar problem with a very similar board, but I did not
> try 4e yet. Chances are that it's a similar problem.

Do you have a post card?

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From dieter at bloms.de  Tue Jun  5 00:02:49 2007
From: dieter at bloms.de (Dieter Bloms)
Date: Tue, 5 Jun 2007 00:02:49 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070604215032.GA17613@coresystems.de>
References: <20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
	<20070604214846.GA14123@coresystems.de>
	<20070604215032.GA17613@coresystems.de>
Message-ID: <20070604220248.GB3257@bloms.de>

Hi,

On Mon, Jun 04, Stefan Reinauer wrote:

> * Stefan Reinauer <stepan at coresystems.de> [070604 23:48]:
> > Ok. This is bad. To some extent. Your southbridge is an ICH4, right?
> > I will go read the ICH4 data sheet some more on thursday to figure
> > something out.
> > 
> > I have a very similar problem with a very similar board, but I did not
> > try 4e yet. Chances are that it's a similar problem.
> 
> Do you have a post card?

do you mean a pci or isa card, with two digit display ?
A friend of me has an isa card, but my board doesn't have any isa slot.
It only has one pci slot (ok two with a riser card).

So I don't have a post card.


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070605/e69126f0/attachment.sig>

From andi.mundt at web.de  Tue Jun  5 01:36:03 2007
From: andi.mundt at web.de (Andreas B. Mundt)
Date: Tue, 5 Jun 2007 01:36:03 +0200
Subject: [LinuxBIOS]  trying to boot Gigabyte M575SLI
In-Reply-To: <20070604155851.4065.qmail@cdy.org>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
	<20070604155851.4065.qmail@cdy.org>
Message-ID: <20070604233603.GA3421@flashgordon>

On Mon, Jun 04, 2007 at 05:58:51PM +0200, Peter Stuge wrote:
> 
> I would appreciate any feedback I can get on the patch. It needs more
> testing.
> 

Hi Peter,

tried your patch. It seems to work for the Kernel, but fails with the
inird.img (?). I cut some "identical" lines to keep the mail shorter, 
if the full output is necessary just let me know.

Remark: I used only a delay(1) in main/filo.c, which was enought before 
the patch has been applied (Ward, perhaps this can be added to your Wiki).  

............
............
Wrote linuxbios table at: 00000530 - 00000dd4  checksum 7022

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

rom_stream: 0xfffc0000 - 0xfffdefff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
New segment addr 0x100000 size 0x3ce00 offset 0xc0 filesize 0x12de8
(cleaned up) New segment addr 0x100000 size 0x3ce00 offset 0xc0 filesize 0x12de8
New segment addr 0x13ce00 size 0x48 offset 0x12ec0 filesize 0x48
(cleaned up) New segment addr 0x13ce00 size 0x48 offset 0x12ec0 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x00000000bff80000 memsz: 0x000000000003ce00 filesz: 0x0000000000012de8
Clearing Segment: addr: 0x00000000bff92de8 memsz: 0x000000000002a018
Loading Segment: addr: 0x00000000bffbce00 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x10df28
FILO version 0.5 (andi at flashgordon) Mon Jun  4 20:13:51 CEST 2007
setup_timers: CPU 2400 MHz
menu: hde5:/boot/grub/menu.lst
find_ide_controller: found PCI IDE controller 10de:037f prog_if=0x85
find_ide_controller: primary channel: native PCI mode
find_ide_controller: cmd_base=0x3000 ctrl_base=0x3070
ide_software_reset: Waiting for ide2 to become ready for reset... ok
init_drive: Testing for hde
init_drive: Probing for hde
init_drive: LBA mode, sectors=268435455
init_drive: LBA48 mode, sectors=488395055
init_drive: Init device params... ok
hde: LBA48 250GB: SAMSUNG SP2504C                         
init_drive: Testing for hdf
init_drive: Probing for hdf
IDE timeout after 50 ms while waiting for drq()
pio_data_in: No DRQ from device after read command
print_status: IDE: status=0x0, err=0x0
init_drive: Testing for hdf
init_drive: Probing for hdf
IDE timeout after 50 ms while waiting for drq()
pio_data_in: No DRQ from device after read command
print_status: IDE: status=0x0, err=0x0
ide_readmany: sector 0 to 0x00117c00
ide_readmany: sector 132825420 to 0x00119400
ide_readmany: sector 132825485 to 0x00119600
ide_readmany: sector 132825486 to 0x00119800
Mounted ext2fs
ide_readmany: sector 132825491 to 0x0011a200
..............cut...........................
ext2fs_read_one: block  438273  offset=1210 len=1 ret=0
ext2fs_read_one: block  438273  offset=1211 len=1 ret=0
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
Press any key to continue.
ext2fs_read_one: block  438273  offset=1212 len=1 ret=0
ext2fs_read_one: block  438273  offset=1213 len=1 ret=0
......................cut..............................
ext2fs_read_one: block  438274  offset=518 len=1 ret=0
ext2fs_read_one: block  438274  offset=519 len=1 ret=0
ext2fs_read_one: block  438274  offset=520 len=1 ret=0
ide_readmany: sector 132825491 to 0x0011a200
ide_readmany: sector 132825492 to 0x0011a400
ide_readmany: sector 132825493 to 0x0011a600
ide_readmany: sector 132825494 to 0x0011a800
ide_readmany: sector 132825495 to 0x0011aa00
ide_readmany: sector 132825496 to 0x0011ac00
ide_readmany: sector 132825497 to 0x0011ae00
ide_readmany: sector 132825498 to 0x0011b000
ide_readmany: sector 132825515 to 0x0011d200
ide_readmany: sector 132825516 to 0x0011d400
ide_readmany: sector 132825517 to 0x0011d600
ide_readmany: sector 132825518 to 0x0011d800
ide_readmany: sector 132825519 to 0x0011da00
ide_readmany: sector 132825520 to 0x0011dc00
ide_readmany: sector 132825521 to 0x0011de00
ide_readmany: sector 132825522 to 0x0011e000
ide_readmany: sector 136233387 to 0x0011d200
ide_readmany: sector 136233388 to 0x0011d400
ide_readmany: sector 136233389 to 0x0011d600
ide_readmany: sector 136233390 to 0x0011d800
ide_readmany: sector 136233391 to 0x0011da00
ide_readmany: sector 136233392 to 0x0011dc00
ide_readmany: sector 136233393 to 0x0011de00
ide_readmany: sector 136233394 to 0x0011e000
ide_readmany: sector 136298891 to 0x00119200
ide_readmany: sector 136298892 to 0x00119400
ide_readmany: sector 136298893 to 0x00119600
ide_readmany: sector 136298894 to 0x00119800
ide_readmany: sector 136298895 to 0x00119a00
ide_readmany: sector 136298896 to 0x00119c00
ide_readmany: sector 136298897 to 0x00119e00
ide_readmany: sector 136298898 to 0x0011a000
ext2fs_read_one: block  452608  offset=0 len=52 ret=0
ide_readmany: sector 136446347 to 0x00119200
ide_readmany: sector 132825515 to 0x0011d200
ide_readmany: sector 132825516 to 0x0011d400
ide_readmany: sector 132825517 to 0x0011d600
ide_readmany: sector 132825518 to 0x0011d800
ide_readmany: sector 132825519 to 0x0011da00
ide_readmany: sector 132825520 to 0x0011dc00
ide_readmany: sector 132825521 to 0x0011de00
ide_readmany: sector 132825522 to 0x0011e000
ide_readmany: sector 136233387 to 0x0011d200
ide_readmany: sector 136233388 to 0x0011d400
ide_readmany: sector 136233389 to 0x0011d600
ide_readmany: sector 136233390 to 0x0011d800
ide_readmany: sector 136233391 to 0x0011da00
ide_readmany: sector 136233392 to 0x0011dc00
ide_readmany: sector 136233393 to 0x0011de00
ide_readmany: sector 136233394 to 0x0011e000
ide_readmany: sector 136298891 to 0x00119200
ext2fs_read_one: block  452608  offset=0 len=560 ret=0
ide_readmany: sector 136446347 to 0x00119200
ide_readmany: sector 136446348 to 0x00119400
Found Linuxblock  452609  offset=1099 len=256 ret=0
ide_readmany: sector 136446357 to 0x0011a600
 version 2.6.21-1-amd64 (unknown at Debian) #1 SMP Fri May 18 23:28:21 CEST 2007 bzImage.
Loading kernel... sector 136446443 to 0x0011d200
ide_readmany: sector 136446444 to 0x0011d400
ide_readmany: sector 136446445 to 0x0011d600
ide_readmany: sector 136446446 to 0x0011d800
ide_readmany: sector 136446447 to 0x0011da00
ide_readmany: sector 136446448 to 0x0011dc00
ide_readmany: sector 136446449 to 0x0011de00
ide_readmany: sector 136446450 to 0x0011e000
ext2fs_read_many:  10 blocks  452610 - 452619  len=1561450 ret=0
ide_readmany: sectors 136446363 - 136446442 ( 80) to 0x4023ce50
ext2fs_read_many: 372 blocks  452621 - 452992  len=1520490 ret=40960
ide_readmany: sectors 136446451 - 136446706 (256) to 0x40246e50
ide_readmany: sectors 136446707 - 136446962 (256) to 0x40266e50
ide_readmany: sectors 136446963 - 136447218 (256) to 0x40286e50
ide_readmany: sectors 136447219 - 136447474 (256) to 0x402a6e50
ide_readmany: sectors 136447475 - 136447730 (256) to 0x402c6e50
ide_readmany: sectors 136447731 - 136447986 (256) to 0x402e6e50
ide_readmany: sectors 136447987 - 136448242 (256) to 0x40306e50
ide_readmany: sectors 136448243 - 136448498 (256) to 0x40326e50
ide_readmany: sectors 136448499 - 136448754 (256) to 0x40346e50
ide_readmany: sectors 136448755 - 136449010 (256) to 0x40366e50
ide_readmany: sectors 136449011 - 136449266 (256) to 0x40386e50
ide_readmany: sectors 136449267 - 136449426 (160) to 0x403a6e50
ext2fs_read: discarding 3222 surplus bytes
ext2fs_read: done reading many  len=0 ret=1561450
ok
ide_readmany: sector 132825493 to 0x0011a600
ide_readmany: sector 132825515 to 0x0011d200
ide_readmany: sector 132825516 to 0x0011d400
ide_readmany: sector 132825517 to 0x0011d600
ide_readmany: sector 132825518 to 0x0011d800
ide_readmany: sector 132825519 to 0x0011da00
ide_readmany: sector 132825520 to 0x0011dc00
ide_readmany: sector 132825521 to 0x0011de00
ide_readmany: sector 132825522 to 0x0011e000
File not found
Can't open initrd: /initrd.img




From stuge-linuxbios at cdy.org  Tue Jun  5 02:45:21 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 5 Jun 2007 02:45:21 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070604233603.GA3421@flashgordon>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
	<20070604155851.4065.qmail@cdy.org>
	<20070604233603.GA3421@flashgordon>
Message-ID: <20070605004521.27823.qmail@cdy.org>

On Tue, Jun 05, 2007 at 01:36:03AM +0200, Andreas B. Mundt wrote:
> On Mon, Jun 04, 2007 at 05:58:51PM +0200, Peter Stuge wrote:
> > 
> > I would appreciate any feedback I can get on the patch. It needs more
> > testing.
> 
> Hi Peter,
> 
> tried your patch.

Great!


> It seems to work for the Kernel, but fails with the inird.img (?).

Did you specify a drive also for initrd.img? /initrd.img is not
enough, it should be hde1:/initrd.img if hde1 is the right partition.


> I cut some "identical" lines to keep the mail shorter, 
> if the full output is necessary just let me know.

Not this time, but unless they are truly identical lines please do
not remove them, and even if they are it may be useful to know how
many they were.


> Remark: I used only a delay(1) in main/filo.c, which was enought
> before the patch has been applied (Ward, perhaps this can be added
> to your Wiki).  

Do you still need an extra delay(1) with the patch applied?


Thanks for testing!


> ide_readmany: sector 0 to 0x00117c00
> ide_readmany: sector 132825420 to 0x00119400
> ide_readmany: sector 132825485 to 0x00119600
> ide_readmany: sector 132825486 to 0x00119800
> Mounted ext2fs
> ide_readmany: sector 132825491 to 0x0011a200
> ..............cut...........................
> ext2fs_read_one: block  438273  offset=1210 len=1 ret=0
> ext2fs_read_one: block  438273  offset=1211 len=1 ret=0
> Press any key to continue.
> Press any key to continue.
> Press any key to continue.
> Press any key to continue.
> Press any key to continue.
> Press any key to continue.
> ext2fs_read_one: block  438273  offset=1212 len=1 ret=0
> ext2fs_read_one: block  438273  offset=1213 len=1 ret=0
> ......................cut..............................
> ext2fs_read_one: block  438274  offset=518 len=1 ret=0
> ext2fs_read_one: block  438274  offset=519 len=1 ret=0
> ext2fs_read_one: block  438274  offset=520 len=1 ret=0
> ide_readmany: sector 132825491 to 0x0011a200
> ide_readmany: sector 132825492 to 0x0011a400
> ide_readmany: sector 132825493 to 0x0011a600
> ide_readmany: sector 132825494 to 0x0011a800
> ide_readmany: sector 132825495 to 0x0011aa00

Sigh.. ext2 code in FILO is really simple.


//Peter



From Libo.Feng at amd.com  Tue Jun  5 04:05:40 2007
From: Libo.Feng at amd.com (Feng, Libo)
Date: Tue, 5 Jun 2007 10:05:40 +0800
Subject: [LinuxBIOS] Linux can't run.
In-Reply-To: <2ea3fae10706040921r3b5dcbd8jb2d4eac8c1491a18@mail.gmail.com>
References: <DD1CC71B621B004FA76856E5129D6B172A0022@sbjgexmb1.amd.com>
	<13426df10705310722p51f2b84dl710345509c21eff1@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B172E41DA@sbjgexmb1.amd.com>
	<2ea3fae10706040921r3b5dcbd8jb2d4eac8c1491a18@mail.gmail.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B172E4312@sbjgexmb1.amd.com>

Hi, Mr Lu,

Can we boot Linux with the propriety BIOS and then run getpir utility to get irq routing? We don't have the Explosion schematic.


Best Regards

??? Feng Libo @ AMD  Ext: 20906
Mobile Phone: 13683249071
Office Phone: 0086-010-62801406

-----Original Message-----
From: yhlu [mailto:yinghailu at gmail.com] 
Sent: Tuesday, June 05, 2007 12:22 AM
To: Feng, Libo
Cc: ron minnich; linuxbios at linuxbios.org
Subject: Re: [LinuxBIOS] Linux can't run.

please try to use latest kernel, and fix your mptable in LinuxBIOS according to your schematic and chipset data sheet about irq routing.

YH







From yinghailu at gmail.com  Tue Jun  5 06:19:59 2007
From: yinghailu at gmail.com (yhlu)
Date: Mon, 4 Jun 2007 21:19:59 -0700
Subject: [LinuxBIOS] Linux can't run.
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B172E4312@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B172A0022@sbjgexmb1.amd.com>
	<13426df10705310722p51f2b84dl710345509c21eff1@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B172E41DA@sbjgexmb1.amd.com>
	<2ea3fae10706040921r3b5dcbd8jb2d4eac8c1491a18@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B172E4312@sbjgexmb1.amd.com>
Message-ID: <2ea3fae10706042119v3865e56y8722bae0a24cd587@mail.gmail.com>

On 6/4/07, Feng, Libo <Libo.Feng at amd.com> wrote:
> Hi, Mr Lu,
>
> Can we boot Linux with the propriety BIOS and then run getpir utility to get irq routing? We don't have the Explosion schematic.

with smp enabled only mptable is used if acpi is not there. irqtable
is only usefull for peer root bus discovery.

you could get Explosion schematic under NDA.

YH



From dieter at bloms.de  Tue Jun  5 08:01:19 2007
From: dieter at bloms.de (Dieter Bloms)
Date: Tue, 5 Jun 2007 08:01:19 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070604214846.GA14123@coresystems.de>
References: <20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
	<20070604214846.GA14123@coresystems.de>
Message-ID: <20070605060119.GA3225@bloms.de>

Hi Stefan,

On Mon, Jun 04, Stefan Reinauer wrote:

> Is your SuperIO a Winbond W83627HF? (Search the board for a chip close
> to bios chip and the ports)

from the manual it is a winbond W83627HF-AW, but I can't find any chip
with those characters on it.
I found two chips, which may be a superio controller:

"AL0655 4C229T1 5012D" and "ICS UA 831293 0436 950211BF"

> > I've changed the address from 2e to 4e in auto.c and Config.lb, but it
> > didn't change anything.
>  
> Ok. This is bad. To some extent. Your southbridge is an ICH4, right?

yes:

--snip--
video:~# lspci
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
01:0c.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
01:0c.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05)
01:0c.2 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05)
01:0c.4 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] (rev 05)
01:0d.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
01:0f.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
--snip--

> I will go read the ICH4 data sheet some more on thursday to figure
> something out.
> 
> I have a very similar problem with a very similar board, but I did not
> try 4e yet. Chances are that it's a similar problem.

hopefully.

Many thanks for your support !


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070605/d4a15670/attachment.sig>

From corey.osgood at gmail.com  Tue Jun  5 08:23:51 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 05 Jun 2007 02:23:51 -0400
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
 but ...
In-Reply-To: <20070605060119.GA3225@bloms.de>
References: <20070601052108.GB3251@bloms.de>	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>	<20070602123541.GD3251@bloms.de>	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>	<20070603193827.GC15426@greenwood>
	<466440C3.6040809@amd.com>	<20070604173602.GE3251@bloms.de>	<20070604193708.GB9114@coresystems.de>	<20070604214244.GA3257@bloms.de>	<20070604214846.GA14123@coresystems.de>
	<20070605060119.GA3225@bloms.de>
Message-ID: <46650177.9090205@gmail.com>

Dieter Bloms wrote:
> Hi Stefan,
>
> On Mon, Jun 04, Stefan Reinauer wrote:
>
>   
>> Is your SuperIO a Winbond W83627HF? (Search the board for a chip close
>> to bios chip and the ports)
>>     
>
> from the manual it is a winbond W83627HF-AW, but I can't find any chip
> with those characters on it.
> I found two chips, which may be a superio controller:
>
> "AL0655 4C229T1 5012D" and "ICS UA 831293 0436 950211BF"
>   

Neither of these are it, the first one I think you meant "ALC", which is
an audio controller, and the other is a p4 timing chip. Keep looking,
here's some popular manufacturers of Super IOs (which would be named on
the chip):

Winbond
SMSC
ITE
NSC
Fintek

These are just the ones with support in LBv2 and are very common, but
there are more out there.

-Corey



From andi.mundt at web.de  Tue Jun  5 08:29:54 2007
From: andi.mundt at web.de (Andreas B. Mundt)
Date: Tue, 5 Jun 2007 08:29:54 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070605004521.27823.qmail@cdy.org>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
	<20070604155851.4065.qmail@cdy.org>
	<20070604233603.GA3421@flashgordon>
	<20070605004521.27823.qmail@cdy.org>
Message-ID: <20070605062954.GA3602@flashgordon>

On Tue, Jun 05, 2007 at 02:45:21AM +0200, Peter Stuge wrote:
> 
> Did you specify a drive also for initrd.img? /initrd.img is not
> enough, it should be hde1:/initrd.img if hde1 is the right partition.
> 

Hi Peter,

I use the grub menu to boot. Find below my filo Config and grub menu.lst.
Where do I have to specify the drive? Both, /vmlinuz and /initrd.img are
symlinks, could this cause the problem? Both are fetched from sda5 when 
booted, the root filesystem itself is on sda2 ("linux notation").

Thanks 

	Andi



---------filo   Config--------------------
# Use grub instead of autoboot?
USE_GRUB = 1
# Grub menu.lst path
MENULST_FILE = "hde5:/boot/grub/menu.lst"
#MENULST_FILE = "uda1:/boot/grub/menu.lst"
# Driver for hard disk, CompactFlash, and CD-ROM on IDE bus
IDE_DISK = 1
DEBUG_TIMER = 1
DEBUG _BLOCKDEV = 1
DEBUG_IDE = 1
DEBUG_EXT2 = 1
# Add a short delay when polling status registers
# (required on some broken SATA controllers)
IDE_DISK_POLL_DELAY = 1
# Driver for USB Storage
USB_DISK = 1
# VGA text console
VGA_CONSOLE = 1
PC_KEYBOARD = 1
# Enable the serial console
SERIAL_CONSOLE = 1
# Serial console; real external serial port
SERIAL_IOBASE = 0x3f8
SERIAL_SPEED = 115200
# Filesystems
FSYS_EXT2FS = 1
FSYS_ISO9660 = 1
# Support for boot disk image in bootable CD-ROM (El Torito)
ELTORITO = 1
# PCI support
SUPPORT_PCI = 1
# Enable this to scan PCI busses above bus 0
# AMD64 based boards do need this.
PCI_BRUTE_SCAN = 1
# Loader for standard Linux kernel image, a.k.a. /vmlinuz
LINUX_LOADER = 1
----------------------------
-------------menu.lst   entry to boot -------

title   	Debian GNU/Linux Lenny, kernel 2.6.21-amd64
root    	(hd4,4)
kernel    	/vmlinuz root=/dev/sda2 ro console=ttyS0,115200
initrd          /initrd.img
savedefault
boot




From joe at smittys.pointclark.net  Tue Jun  5 09:08:08 2007
From: joe at smittys.pointclark.net (Joseph Smith)
Date: Tue, 05 Jun 2007 03:08:08 -0400
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <46650177.9090205@gmail.com>
References: <20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de> <20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
	<20070604214846.GA14123@coresystems.de>
	<20070605060119.GA3225@bloms.de> <46650177.9090205@gmail.com>
Message-ID: <20070605030808.oqwdr43728sgoc8s@www.smittys.pointclark.net>

Quoting Corey Osgood <corey.osgood at gmail.com>:

> Dieter Bloms wrote:
>> Hi Stefan,
>>
>> On Mon, Jun 04, Stefan Reinauer wrote:
>>
>>
>>> Is your SuperIO a Winbond W83627HF? (Search the board for a chip close
>>> to bios chip and the ports)
>>>
>>
>> from the manual it is a winbond W83627HF-AW, but I can't find any chip
>> with those characters on it.
>> I found two chips, which may be a superio controller:
>>
>> "AL0655 4C229T1 5012D" and "ICS UA 831293 0436 950211BF"
>>
>
> Neither of these are it, the first one I think you meant "ALC", which is
> an audio controller, and the other is a p4 timing chip. Keep looking,
> here's some popular manufacturers of Super IOs (which would be named on
> the chip):
>
> Winbond
> SMSC
> ITE
> NSC
> Fintek
>
> These are just the ones with support in LBv2 and are very common, but
> there are more out there.
>
> -Corey
>
Most likely it is eithor a Winbond or SMSC, I have found these are the  
most popular on Intel P4 boards.

Thanks - Joe



From corey.osgood at gmail.com  Tue Jun  5 11:26:31 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 05 Jun 2007 05:26:31 -0400
Subject: [LinuxBIOS] [PATCH] Add generic Intel i82801 support
Message-ID: <46652C47.4030808@gmail.com>

See patch. I'm still waiting on a response from Steve just to confirm
GPLv2 on a couple files, and I'd like Yinghai to make sure those details
are correct as well (ie were you working for Tyan at the time, and is
that the right email address to use?). Other than that, it's as done as
I'm getting it. BTW, i810 will be on its way again soon, I'm trying to
get vga working first.

-Corey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i82801_generic.patch
Type: text/x-patch
Size: 52752 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070605/701c3dd5/attachment.patch>

From stuge-linuxbios at cdy.org  Tue Jun  5 11:46:23 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 5 Jun 2007 11:46:23 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070605062954.GA3602@flashgordon>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
	<20070604155851.4065.qmail@cdy.org>
	<20070604233603.GA3421@flashgordon>
	<20070605004521.27823.qmail@cdy.org>
	<20070605062954.GA3602@flashgordon>
Message-ID: <20070605094623.14347.qmail@cdy.org>

Hi,

On Tue, Jun 05, 2007 at 08:29:54AM +0200, Andreas B. Mundt wrote:
> I use the grub menu to boot. Find below my filo Config and grub
> menu.lst.

Oh, ok. I don't know much details about grub and how FILO deals with
menu.lst.


> Where do I have to specify the drive? Both, /vmlinuz and
> /initrd.img are symlinks, could this cause the problem?

That's quite possible. I don't know if the FILO ext2 driver tries to
resolve symlinks.


> Both are fetched from sda5 when booted, the root filesystem itself
> is on sda2 ("linux notation").

And even if it does, symlinks across partitions are not likely to be
supported.

Try specifying hde5:.. paths for both the kernel and initrd directly
to FILO, bypassing the menu.lst file, or possibly doing so within the
menu.lst file.


//Peter



From svn at openbios.org  Tue Jun  5 12:13:24 2007
From: svn at openbios.org (svn at openbios.org)
Date: Tue,  5 Jun 2007 12:13:24 +0200
Subject: [LinuxBIOS] r343 - LinuxBIOSv3/southbridge/amd/cs5536
Message-ID: <mailman.376.1355071118.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-05 12:13:24 +0200 (Tue, 05 Jun 2007)
New Revision: 343

Added:
   LinuxBIOSv3/southbridge/amd/cs5536/cs5536.h
Log:
Add header file for the AMD Geode CS5536 Companion Device.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Added: LinuxBIOSv3/southbridge/amd/cs5536/cs5536.h
===================================================================
--- LinuxBIOSv3/southbridge/amd/cs5536/cs5536.h	                        (rev 0)
+++ LinuxBIOSv3/southbridge/amd/cs5536/cs5536.h	2007-06-05 10:13:24 UTC (rev 343)
@@ -0,0 +1,444 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 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 version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef SOUTHBRIDGE_AMD_CS5536_CS5536_H
+#define SOUTHBRIDGE_AMD_CS5536_CS5536_H
+
+/* Vendor/device identification */
+#define CS5536_ID			0x208F1022
+
+/* Port of the southbridge */
+#define CS5536_GLINK_PORT_NUM		0x02
+
+/* NB GLPCI is in the same location on all Geodes. */
+#define NB_PCI				((2 << 29) + (4 << 26))
+
+/* Address to the southbridge */
+#define MSR_SB				((CS5536_GLINK_PORT_NUM << 23) + NB_PCI)
+
+/* 29 -> 26 -> 23 -> 20... When making a SB address use this shift. */
+#define SB_SHIFT			20
+
+/* Default PCI device number for CS5536 */
+#define CS5536_DEV_NUM			0x0F
+
+/* I/O base addresses */
+#define SMBUS_IO_BASE			0x6000
+#define GPIO_IO_BASE			0x6100
+#define MFGPT_IO_BASE			0x6200
+#define ACPI_IO_BASE			0x9C00
+#define PMS_IO_BASE			0x9D00
+
+/* IDSEL = AD25, device #15 */
+#define CS5536_IDSEL			0x02000000
+#define CHIPSET_DEV_NUM			15
+#define IDSEL_BASE			11	/* Bit 11 = device 1 */
+
+/* Port 0 (GLIU): 51024xxx or 510*xxxx - fake out just like GL0 on CPU. */
+#define MSR_SB_GLIU			((9 << 14) + MSR_SB)
+
+/* Port 1 (GLPCI): 5100xxxx - don't go to the GLIU. */
+#define MSR_SB_GLPCI			(MSR_SB)
+
+/* Port 2 (USB Controller #2): 5120xxxx */
+#define MSR_SB_USB2			((2 << SB_SHIFT) + MSR_SB)
+
+/* Port 3 (ATA-5 Controller): 5130xxxx */
+#define MSR_SB_ATA			((3 << SB_SHIFT) + MSR_SB)
+
+/* Port 4 (MDD): 5140xxxx, a.k.a. DIVIL = Diverse Integrated Logic device. */
+#define MSR_SB_MDD			((4 << SB_SHIFT) + MSR_SB)
+
+/* Port 5 (AC97): 5150xxxx */
+#define MSR_SB_AC97			((5 << SB_SHIFT) + MSR_SB)
+
+/* Port 6 (USB Controller #1): 5160xxxx */
+#define MSR_SB_USB1			((6 << SB_SHIFT) + MSR_SB)
+
+/* Port 7 (GLCP): 5170xxxx */
+#define MSR_SB_GLCP			((7 << SB_SHIFT) + MSR_SB)
+
+/* GLIU */
+#define GLIU_SB_GLD_MSR_CAP		(MSR_SB_GLIU + 0x00)
+#define GLIU_SB_GLD_MSR_CONF		(MSR_SB_GLIU + 0x01)
+#define GLIU_SB_GLD_MSR_PM		(MSR_SB_GLIU + 0x04)
+
+/* USB1 */
+#define USB1_SB_GLD_MSR_CAP		(MSR_SB_USB1 + 0x00)
+#define USB1_SB_GLD_MSR_CONF		(MSR_SB_USB1 + 0x01)
+#define USB1_SB_GLD_MSR_PM		(MSR_SB_USB1 + 0x04)
+
+/* USB2 */
+#define USB2_SB_GLD_MSR_CAP		(MSR_SB_USB2 + 0x00)
+#define USB2_SB_GLD_MSR_CONF		(MSR_SB_USB2 + 0x01)
+/* Bit 35 (i.e., bit 3 of the upper 32-bit half of this 64-bit register). */
+#define USB2_UPPER_SSDEN_SET		(1 << 3)
+#define USB2_SB_GLD_MSR_PM		(MSR_SB_USB2 + 0x04)
+#define USB2_SB_GLD_MSR_DIAG		(MSR_SB_USB2 + 0x05)
+#define USB2_SB_GLD_MSR_OHCI_BASE	(MSR_SB_USB2 + 0x08)
+#define USB2_SB_GLD_MSR_EHCI_BASE	(MSR_SB_USB2 + 0x09)
+#define USB2_SB_GLD_MSR_DEVCTL_BASE	(MSR_SB_USB2 + 0x0A)
+#define USB2_SB_GLD_MSR_UOC_BASE	(MSR_SB_USB2 + 0x0B)
+
+/* ATA */
+#define ATA_SB_GLD_MSR_CAP		(MSR_SB_ATA + 0x00)
+#define ATA_SB_GLD_MSR_CONF		(MSR_SB_ATA + 0x01)
+#define ATA_SB_GLD_MSR_ERR		(MSR_SB_ATA + 0x03)
+#define ATA_SB_GLD_MSR_PM		(MSR_SB_ATA + 0x04)
+
+/* AC97 */
+#define AC97_SB_GLD_MSR_CAP		(MSR_SB_AC97 + 0x00)
+#define AC97_SB_GLD_MSR_CONF		(MSR_SB_AC97 + 0x01)
+#define AC97_SB_GLD_MSR_PM		(MSR_SB_AC97 + 0x04)
+
+/* GLPCI */
+#define GLPCI_SB_GLD_MSR_CAP		(MSR_SB_GLPCI + 0x00)
+#define GLPCI_SB_GLD_MSR_CONF		(MSR_SB_GLPCI + 0x01)
+#define GLPCI_SB_GLD_MSR_PM		(MSR_SB_GLPCI + 0x04)
+#define GLPCI_SB_CTRL			(MSR_SB_GLPCI + 0x10)
+#define GLPCI_CRTL_PPIDE_SET		(1 << 17)
+
+/* GLCP */
+#define GLCP_SB_GLD_MSR_CAP		(MSR_SB_GLCP + 0x00)
+#define GLCP_SB_GLD_MSR_CONF		(MSR_SB_GLCP + 0x01)
+#define GLCP_SB_GLD_MSR_PM		(MSR_SB_GLCP + 0x04)
+#define GLCP_SB_CLKOFF			(MSR_SB_GLCP + 0x10)
+
+/* MDD */
+#define MDD_SB_GLD_MSR_CAP		(MSR_SB_MDD + 0x00)
+#define MDD_SB_GLD_MSR_CONF		(MSR_SB_MDD + 0x01)
+#define MDD_SB_GLD_MSR_PM		(MSR_SB_MDD + 0x04)
+#define LBAR_EN				0x01
+#define IO_MASK				0x1f
+#define MEM_MASK			0x0FFFFF
+#define MDD_LBAR_IRQ			(MSR_SB_MDD + 0x08)
+#define MDD_LBAR_KEL1			(MSR_SB_MDD + 0x09)
+#define MDD_LBAR_KEL2			(MSR_SB_MDD + 0x0A)
+#define MDD_LBAR_SMB			(MSR_SB_MDD + 0x0B)
+#define MDD_LBAR_GPIO			(MSR_SB_MDD + 0x0C)
+#define MDD_LBAR_MFGPT			(MSR_SB_MDD + 0x0D)
+#define MDD_LBAR_ACPI			(MSR_SB_MDD + 0x0E)
+#define MDD_LBAR_PMS			(MSR_SB_MDD + 0x0F)
+#define MDD_LBAR_FLSH0			(MSR_SB_MDD + 0x10)
+#define MDD_LBAR_FLSH1			(MSR_SB_MDD + 0x11)
+#define MDD_LBAR_FLSH2			(MSR_SB_MDD + 0x12)
+#define MDD_LBAR_FLSH3			(MSR_SB_MDD + 0x13)
+#define MDD_LEG_IO			(MSR_SB_MDD + 0x14)
+#define MDD_PIN_OPT			(MSR_SB_MDD + 0x15)
+#define MDD_SOFT_IRQ			(MSR_SB_MDD + 0x16)
+#define MDD_SOFT_RESET			(MSR_SB_MDD + 0x17)
+#define MDD_NORF_CNTRL			(MSR_SB_MDD + 0x18)
+#define MDD_NORF_T01			(MSR_SB_MDD + 0x19)
+#define MDD_NORF_T23			(MSR_SB_MDD + 0x1A)
+#define MDD_NANDF_DATA			(MSR_SB_MDD + 0x1B)
+#define MDD_NADF_CNTL			(MSR_SB_MDD + 0x1C)
+#define MDD_AC_DMA			(MSR_SB_MDD + 0x1E)
+#define MDD_KEL_CNTRL			(MSR_SB_MDD + 0x1F)
+#define MDD_IRQM_YLOW			(MSR_SB_MDD + 0x20)
+#define MDD_IRQM_YHIGH			(MSR_SB_MDD + 0x21)
+#define MDD_IRQM_ZLOW			(MSR_SB_MDD + 0x22)
+#define MDD_IRQM_ZHIGH			(MSR_SB_MDD + 0x23)
+#define MDD_IRQM_PRIM			(MSR_SB_MDD + 0x24)
+#define MDD_IRQM_LPC			(MSR_SB_MDD + 0x25)
+#define MDD_IRQM_LXIRR			(MSR_SB_MDD + 0x26)
+#define MDD_IRQM_HXIRR			(MSR_SB_MDD + 0x27)
+#define MDD_MFGPT_IRQ			(MSR_SB_MDD + 0x28)
+#define MDD_MFGPT_NR			(MSR_SB_MDD + 0x29)
+#define MDD_MFGPT_RES0			(MSR_SB_MDD + 0x2A)
+#define MDD_MFGPT_RES1			(MSR_SB_MDD + 0x2B)
+#define MDD_FLOP_S3F2			(MSR_SB_MDD + 0x30)
+#define MDD_FLOP_S3F7			(MSR_SB_MDD + 0x31)
+#define MDD_FLOP_S372			(MSR_SB_MDD + 0x32)
+#define MDD_FLOP_S377			(MSR_SB_MDD + 0x33)
+#define MDD_PIC_S			(MSR_SB_MDD + 0x34)
+#define MDD_PIT_S			(MSR_SB_MDD + 0x36)
+#define MDD_PIT_CNTRL			(MSR_SB_MDD + 0x37)
+#define MDD_UART1_MOD			(MSR_SB_MDD + 0x38)
+#define MDD_UART1_DON			(MSR_SB_MDD + 0x39)
+#define MDD_UART1_CONF			(MSR_SB_MDD + 0x3A)
+#define MDD_UART2_MOD			(MSR_SB_MDD + 0x3C)
+#define MDD_UART2_DON			(MSR_SB_MDD + 0x3D)
+#define MDD_UART2_CONF			(MSR_SB_MDD + 0x3E)
+#define MDD_DMA_MAP			(MSR_SB_MDD + 0x40)
+#define MDD_DMA_SHAD1			(MSR_SB_MDD + 0x41)
+#define MDD_DMA_SHAD2			(MSR_SB_MDD + 0x42)
+#define MDD_DMA_SHAD3			(MSR_SB_MDD + 0x43)
+#define MDD_DMA_SHAD4			(MSR_SB_MDD + 0x44)
+#define MDD_DMA_SHAD5			(MSR_SB_MDD + 0x45)
+#define MDD_DMA_SHAD6			(MSR_SB_MDD + 0x46)
+#define MDD_DMA_SHAD7			(MSR_SB_MDD + 0x47)
+#define MDD_DMA_SHAD8			(MSR_SB_MDD + 0x48)
+#define MDD_DMA_SHAD9			(MSR_SB_MDD + 0x49)
+#define MDD_LPC_EADDR			(MSR_SB_MDD + 0x4C)
+#define MDD_LPC_ESTAT			(MSR_SB_MDD + 0x4D)
+#define MDD_LPC_SIRQ			(MSR_SB_MDD + 0x4E)
+#define MDD_LPC_RES			(MSR_SB_MDD + 0x4F)
+#define MDD_PML_TMR			(MSR_SB_MDD + 0x50)
+#define MDD_RTC_RAM_LO_CK		(MSR_SB_MDD + 0x54)
+#define MDD_RTC_DOMA_IND		(MSR_SB_MDD + 0x55)
+#define MDD_RTC_MONA_IND		(MSR_SB_MDD + 0x56)
+#define MDD_RTC_CENTURY_OFFSET		(MSR_SB_MDD + 0x57)
+
+/* SMBus */
+#define SMB_SDA				0x00
+#define SMB_STS				0x01
+#define SMB_STS_SLVSTP			(1 << 7)
+#define SMB_STS_SDAST			(1 << 6)
+#define SMB_STS_BER			(1 << 5)
+#define SMB_STS_NEGACK			(1 << 4)
+#define SMB_STS_STASTR			(1 << 3)
+#define SMB_STS_NMATCH			(1 << 2)
+#define SMB_STS_MASTER			(1 << 1)
+#define SMB_STS_XMIT			(1 << 0)
+#define SMB_CTRL_STS			0x02
+#define SMB_CSTS_TGSCL			(1 << 5)
+#define SMB_CSTS_TSDA			(1 << 4)
+#define SMB_CSTS_GCMTCH			(1 << 3)
+#define SMB_CSTS_MATCH			(1 << 2)
+#define SMB_CSTS_BB			(1 << 1)
+#define SMB_CSTS_BUSY			(1 << 0)
+#define SMB_CTRL1			0x03
+#define SMB_CTRL1_STASTRE		(1 << 7)
+#define SMB_CTRL1_NMINTE		(1 << 6)
+#define SMB_CTRL1_GCMEN			(1 << 5)
+#define SMB_CTRL1_ACK			(1 << 4)
+#define SMB_CTRL1_RSVD			(1 << 3)
+#define SMB_CTRL1_INTEN			(1 << 2)
+#define SMB_CTRL1_STOP			(1 << 1)
+#define SMB_CTRL1_START			(1 << 0)
+#define SMB_ADD				0x04
+#define SMB_ADD_SAEN			(1 << 7)
+#define SMB_CTRL2			0x05
+#define SMB_CTRL2_ENABLE		(1 << 0)
+#define SMB_CTRL3			0x06
+
+/* GPIO */
+#define GPIOL_0_SET			(1 << 0)
+#define GPIOL_1_SET			(1 << 1)
+#define GPIOL_2_SET			(1 << 2)
+#define GPIOL_3_SET			(1 << 3)
+#define GPIOL_4_SET			(1 << 4)
+#define GPIOL_5_SET			(1 << 5)
+#define GPIOL_6_SET			(1 << 6)
+#define GPIOL_7_SET			(1 << 7)
+#define GPIOL_8_SET			(1 << 8)
+#define GPIOL_9_SET			(1 << 9)
+#define GPIOL_10_SET			(1 << 10)
+#define GPIOL_11_SET			(1 << 11)
+#define GPIOL_12_SET			(1 << 12)
+#define GPIOL_13_SET			(1 << 13)
+#define GPIOL_14_SET			(1 << 14)
+#define GPIOL_15_SET			(1 << 15)
+#define GPIOL_0_CLEAR			(1 << 16)
+#define GPIOL_1_CLEAR			(1 << 17)
+#define GPIOL_2_CLEAR			(1 << 18)
+#define GPIOL_3_CLEAR			(1 << 19)
+#define GPIOL_4_CLEAR			(1 << 20)
+#define GPIOL_5_CLEAR			(1 << 21)
+#define GPIOL_6_CLEAR			(1 << 22)
+#define GPIOL_7_CLEAR			(1 << 23)
+#define GPIOL_8_CLEAR			(1 << 24)
+#define GPIOL_9_CLEAR			(1 << 25)
+#define GPIOL_10_CLEAR			(1 << 26)
+#define GPIOL_11_CLEAR			(1 << 27)
+#define GPIOL_12_CLEAR			(1 << 28)
+#define GPIOL_13_CLEAR			(1 << 29)
+#define GPIOL_14_CLEAR			(1 << 30)
+#define GPIOL_15_CLEAR			(1 << 31)
+#define GPIOH_16_SET			(1 << 0)
+#define GPIOH_17_SET			(1 << 1)
+#define GPIOH_18_SET			(1 << 2)
+#define GPIOH_19_SET			(1 << 3)
+#define GPIOH_20_SET			(1 << 4)
+#define GPIOH_21_SET			(1 << 5)
+#define GPIOH_22_SET			(1 << 6)
+#define GPIOH_23_SET			(1 << 7)
+#define GPIOH_24_SET			(1 << 8)
+#define GPIOH_25_SET			(1 << 9)
+#define GPIOH_26_SET			(1 << 10)
+#define GPIOH_27_SET			(1 << 11)
+#define GPIOH_28_SET			(1 << 12)
+#define GPIOH_29_SET			(1 << 13)
+#define GPIOH_30_SET			(1 << 14)
+#define GPIOH_31_SET			(1 << 15)
+#define GPIOH_16_CLEAR			(1 << 16)
+#define GPIOH_17_CLEAR			(1 << 17)
+#define GPIOH_18_CLEAR			(1 << 18)
+#define GPIOH_19_CLEAR			(1 << 19)
+#define GPIOH_20_CLEAR			(1 << 20)
+#define GPIOH_21_CLEAR			(1 << 21)
+#define GPIOH_22_CLEAR			(1 << 22)
+#define GPIOH_23_CLEAR			(1 << 23)
+#define GPIOH_24_CLEAR			(1 << 24)
+#define GPIOH_25_CLEAR			(1 << 25)
+#define GPIOH_26_CLEAR			(1 << 26)
+#define GPIOH_27_CLEAR			(1 << 27)
+#define GPIOH_28_CLEAR			(1 << 28)
+#define GPIOH_29_CLEAR			(1 << 29)
+#define GPIOH_30_CLEAR			(1 << 30)
+#define GPIOH_31_CLEAR			(1 << 31)
+
+/* GPIO Low Bank Bit Registers */
+#define GPIOL_OUTPUT_VALUE		0x00
+#define GPIOL_OUTPUT_ENABLE		0x04
+#define GPIOL_OUT_OPENDRAIN		0x08
+#define GPIOL_OUTPUT_INVERT_ENABLE	0x0C
+#define GPIOL_OUT_AUX1_SELECT		0x10
+#define GPIOL_OUT_AUX2_SELECT		0x14
+#define GPIOL_PULLUP_ENABLE		0x18
+#define GPIOL_PULLDOWN_ENABLE		0x1C
+#define GPIOL_INPUT_ENABLE		0x20
+#define GPIOL_INPUT_INVERT_ENABLE	0x24
+#define GPIOL_IN_FILTER_ENABLE		0x28
+#define GPIOL_IN_EVENTCOUNT_ENABLE	0x2C
+#define GPIOL_READ_BACK			0x30
+#define GPIOL_IN_AUX1_SELECT		0x34
+#define GPIOL_EVENTS_ENABLE		0x38
+#define GPIOL_LOCK_ENABLE		0x3C
+#define GPIOL_IN_POSEDGE_ENABLE		0x40
+#define GPIOL_IN_NEGEDGE_ENABLE		0x44
+#define GPIOL_IN_POSEDGE_STATUS		0x48
+#define GPIOL_IN_NEGEDGE_STATUS		0x4C
+
+/* GPIO High Bank Bit Registers */
+#define GPIOH_OUTPUT_VALUE		0x80
+#define GPIOH_OUTPUT_ENABLE		0x84
+#define GPIOH_OUT_OPENDRAIN		0x88
+#define GPIOH_OUTPUT_INVERT_ENABLE	0x8C
+#define GPIOH_OUT_AUX1_SELECT		0x90
+#define GPIOH_OUT_AUX2_SELECT		0x94
+#define GPIOH_PULLUP_ENABLE		0x98
+#define GPIOH_PULLDOWN_ENABLE		0x9C
+#define GPIOH_INPUT_ENABLE		0xA0
+#define GPIOH_INPUT_INVERT_ENABLE	0xA4
+#define GPIOH_IN_FILTER_ENABLE		0xA8
+#define GPIOH_IN_EVENTCOUNT_ENABLE	0xAC
+#define GPIOH_READ_BACK			0xB0
+#define GPIOH_IN_AUX1_SELECT		0xB4
+#define GPIOH_EVENTS_ENABLE		0xB8
+#define GPIOH_LOCK_ENABLE		0xBC
+#define GPIOH_IN_POSEDGE_ENABLE		0xC0
+#define GPIOH_IN_NEGEDGE_ENABLE		0xC4
+#define GPIOH_IN_POSEDGE_STATUS		0xC8
+#define GPIOH_IN_NEGEDGE_STATUS		0xCC
+
+/* Input Conditioning Function Registers */
+#define GPIO_00_FILTER_AMOUNT		0x50
+#define GPIO_00_FILTER_COUNT		0x52
+#define GPIO_00_EVENT_COUNT		0x54
+#define GPIO_00_EVENTCOMPARE_VALUE	0x56
+#define GPIO_01_FILTER_AMOUNT		0x58
+#define GPIO_01_FILTER_COUNT		0x5A
+#define GPIO_01_EVENT_COUNT		0x5C
+#define GPIO_01_EVENTCOMPARE_VALUE	0x5E
+#define GPIO_02_FILTER_AMOUNT		0x60
+#define GPIO_02_FILTER_COUNT		0x62
+#define GPIO_02_EVENT_COUNT		0x64
+#define GPIO_02_EVENTCOMPARE_VALUE	0x66
+#define GPIO_03_FILTER_AMOUNT		0x68
+#define GPIO_03_FILTER_COUNT		0x6A
+#define GPIO_03_EVENT_COUNT		0x6C
+#define GPIO_03_EVENTCOMPARE_VALUE	0x6E
+#define GPIO_04_FILTER_AMOUNT		0x70
+#define GPIO_04_FILTER_COUNT		0x72
+#define GPIO_04_EVENT_COUNT		0x74
+#define GPIO_04_EVENTCOMPARE_VALUE	0x76
+#define GPIO_05_FILTER_AMOUNT		0x78
+#define GPIO_05_FILTER_COUNT		0x7A
+#define GPIO_05_EVENT_COUNT		0x7C
+#define GPIO_05_EVENTCOMPARE_VALUE	0x7E
+#define GPIO_06_FILTER_AMOUNT		0xD0
+#define GPIO_06_FILTER_COUNT		0xD2
+#define GPIO_06_EVENT_COUNT		0xD4
+#define GPIO_06_EVENTCOMPARE_VALUE	0xD6
+#define GPIO_07_FILTER_AMOUNT		0xD8
+#define GPIO_07_FILTER_COUNT		0xDA
+#define GPIO_07_EVENT_COUNT		0xDC
+#define GPIO_07_EVENTCOMPARE_VALUE	0xDE
+
+/* R/W GPIO Interrupt & PME Mapper Registers */
+#define GPIO_MAPPER_X			0xE0
+#define GPIO_MAPPER_Y			0xE4
+#define GPIO_MAPPER_Z			0xE8
+#define GPIO_MAPPER_W			0xEC
+#define GPIO_FE_SELECT_0		0xF0
+#define GPIO_FE_SELECT_1		0xF1
+#define GPIO_FE_SELECT_2		0xF2
+#define GPIO_FE_SELECT_3		0xF3
+#define GPIO_FE_SELECT_4		0xF4
+#define GPIO_FE_SELECT_5		0xF5
+#define GPIO_FE_SELECT_6		0xF6
+#define GPIO_FE_SELECT_7		0xF7
+
+/* Event Counter Decrement Registers */
+#define GPIOL_IN_EVENT_DECREMENT	0xF8
+#define GPIOH_IN_EVENT_DECREMENT	0xFC
+
+/* PMC register */
+#define PM_SSD				0x00
+#define PM_SCXA				0x04
+#define PM_SCYA				0x08
+#define PM_SODA				0x0C
+#define PM_SCLK				0x10
+#define PM_SED				0x14
+#define PM_SCXD				0x18
+#define PM_SCYD				0x1C
+#define PM_SIDD				0x20
+#define PM_WKD				0x30
+#define PM_WKXD				0x34
+#define PM_RD				0x38
+#define PM_WKXA				0x3C
+#define PM_FSD				0x40
+#define PM_TSD				0x44
+#define PM_PSD				0x48
+#define PM_NWKD				0x4C
+#define PM_AWKD				0x50
+#define PM_SSC				0x54
+
+/* Flash type macros */
+#define FLASH_TYPE_NONE			0	/* No flash device installed */
+#define FLASH_TYPE_NAND 		1	/* NAND device */
+#define FLASH_TYPE_NOR			2	/* NOR device */
+
+/* Memory or memory-mapped I/O interface for flash device */
+#define FLASH_IF_MEM			1
+
+/* I/O interface for flash device */
+#define FLASH_IF_IO			2
+
+/* Flash Memory Mask values */
+#define FLASH_MEM_DEFAULT		0x00000000
+#define FLASH_MEM_4K			0xFFFFF000
+#define FLASH_MEM_8K			0xFFFFE000
+#define FLASH_MEM_16K			0xFFFFC000
+#define FLASH_MEM_128K			0xFFFE0000
+#define FLASH_MEM_512K			0xFFFC0000
+#define FLASH_MEM_4M			0xFFC00000
+#define FLASH_MEM_8M			0xFF800000
+#define FLASH_MEM_16M			0xFF000000
+
+/* Flash I/O Mask values */
+#define FLASH_IO_DEFAULT		0x00000000
+#define FLASH_IO_16B			0x0000FFF0
+#define FLASH_IO_32B			0x0000FFE0
+#define FLASH_IO_64B			0x0000FFC0
+#define FLASH_IO_128B			0x0000FF80
+#define FLASH_IO_256B			0x0000FF00
+
+#endif				/* SOUTHBRIDGE_AMD_CS5536_CS5536_H */




From svn at openbios.org  Tue Jun  5 12:28:39 2007
From: svn at openbios.org (svn at openbios.org)
Date: Tue,  5 Jun 2007 12:28:39 +0200
Subject: [LinuxBIOS] r2711 - trunk/LinuxBIOSv2/util/flashrom
Message-ID: <mailman.377.1355071118.16123.coreboot@coreboot.org>

Author: stepan
Date: 2007-06-05 12:28:39 +0200 (Tue, 05 Jun 2007)
New Revision: 2711

Modified:
   trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c
Log:
Add support for BCM HT1000 chipset to flashrom. Tested on IBM x3455.
(trivial)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Modified: trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c
===================================================================
--- trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c	2007-06-03 23:19:19 UTC (rev 2710)
+++ trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c	2007-06-05 10:28:39 UTC (rev 2711)
@@ -387,6 +387,28 @@
 
 }
 
+
+static int enable_flash_ht1000(struct pci_dev *dev, char *name)
+{
+	unsigned char byte;
+
+	/* Set the 4MB enable bit */
+	byte = pci_read_byte(dev, 0x41);
+	byte |= 0x0e;
+	pci_write_byte(dev, 0x41, byte);
+
+	byte = pci_read_byte(dev, 0x43);
+	byte |= (1<<4);
+	pci_write_byte(dev, 0x43, byte);
+
+	/* Some magic. Comment me if you can */
+	outb(0x45, 0xcd6);
+	byte = inb(0xcd7);
+	outb(reg8|0x20, 0xcd7);
+
+	return 0;
+}
+
 typedef struct penable {
 	unsigned short vendor, device;
 	char *name;
@@ -444,6 +466,8 @@
 	{0x10de, 0x0367, "NVIDIA MCP55", enable_flash_mcp55},	/* Pro */
 
 	{0x1002, 0x4377, "ATI SB400", enable_flash_sb400},	/* ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) */
+
+	{0x1166, 0x0205, "BCM HT1000", enable_flash_ht1000},
 };
 
 /*




From nuessle at uni-mannheim.de  Tue Jun  5 13:57:28 2007
From: nuessle at uni-mannheim.de (Mondrian Nuessle)
Date: Tue, 05 Jun 2007 13:57:28 +0200
Subject: [LinuxBIOS] r2711 - trunk/LinuxBIOSv2/util/flashrom
In-Reply-To: <20070605102932.686A231CC5@mail-r83.rz.uni-mannheim.de>
References: <20070605102932.686A231CC5@mail-r83.rz.uni-mannheim.de>
Message-ID: <46654FA8.5070103@uni-mannheim.de>

Great to get HT1000 support into the tree.

One small remark. I believe that the "magic" on port cd6h and cd7h
modifies general purpose I/Os of the HT1000; in the case of the x3455
board you probably deactivate write protection for the flash pin.

We are currently working on a different HT1000 based board, and have a
similar patch ready, with the difference that we set different GPIOs...
so this access is board dependant.

I think the CD6/CD7 access should move into a x3455 board enable function.

Regards,
Mondrian


svn at openbios.org wrote:
> Author: stepan
> Date: 2007-06-05 12:28:39 +0200 (Tue, 05 Jun 2007)
> New Revision: 2711
> 
> Modified:
>    trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c
> Log:
> Add support for BCM HT1000 chipset to flashrom. Tested on IBM x3455.
> (trivial)
> 
> Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
> Acked-by: Stefan Reinauer <stepan at coresystems.de>
> 
> 
> Modified: trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c
> ===================================================================
> --- trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c	2007-06-03 23:19:19 UTC (rev 2710)
> +++ trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c	2007-06-05 10:28:39 UTC (rev 2711)
> @@ -387,6 +387,28 @@
>  
>  }
>  
> +
> +static int enable_flash_ht1000(struct pci_dev *dev, char *name)
> +{
> +	unsigned char byte;
> +
> +	/* Set the 4MB enable bit */
> +	byte = pci_read_byte(dev, 0x41);
> +	byte |= 0x0e;
> +	pci_write_byte(dev, 0x41, byte);
> +
> +	byte = pci_read_byte(dev, 0x43);
> +	byte |= (1<<4);
> +	pci_write_byte(dev, 0x43, byte);
> +
> +	/* Some magic. Comment me if you can */
> +	outb(0x45, 0xcd6);
> +	byte = inb(0xcd7);
> +	outb(reg8|0x20, 0xcd7);
> +
> +	return 0;
> +}
> +
>  typedef struct penable {
>  	unsigned short vendor, device;
>  	char *name;
> @@ -444,6 +466,8 @@
>  	{0x10de, 0x0367, "NVIDIA MCP55", enable_flash_mcp55},	/* Pro */
>  
>  	{0x1002, 0x4377, "ATI SB400", enable_flash_sb400},	/* ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) */
> +
> +	{0x1166, 0x0205, "BCM HT1000", enable_flash_ht1000},
>  };
>  
>  /*
> 
> 

-- 
 Mondrian Nuessle                 University of Mannheim
 Phone: +49 621 181 2717          Computer Architecture Group
 Fax:   +49 621 181 2713          http://ra.ti.uni-mannheim.de
 mailto:nuessle at uni-mannheim.de




From stepan at coresystems.de  Tue Jun  5 14:17:13 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 5 Jun 2007 14:17:13 +0200
Subject: [LinuxBIOS] r2711 - trunk/LinuxBIOSv2/util/flashrom
In-Reply-To: <46654FA8.5070103@uni-mannheim.de>
References: <20070605102932.686A231CC5@mail-r83.rz.uni-mannheim.de>
	<46654FA8.5070103@uni-mannheim.de>
Message-ID: <20070605121713.GB14755@coresystems.de>

* Mondrian Nuessle <nuessle at uni-mannheim.de> [070605 13:57]:
> One small remark. I believe that the "magic" on port cd6h and cd7h
> modifies general purpose I/Os of the HT1000; in the case of the x3455
> board you probably deactivate write protection for the flash pin.

Ok, then this should probably go into a x3455 board specific code
instead. I saw Yinghai made a lot of io to those ports in the ht1000
specific code, so I assumed thats southbridge specific code.

The weird thing is that I could overwrite some parts of the flash
without that code (0x70000 to 0x80000), so it's probably not the flash
write line.

Or, it might be the FPGA on board catches the area from 0x70000 to
0x80000 and decides whether to switch or not. I have no information on
that, unfortunately, and I doubt I will be able to get it in a timely
manner.

> We are currently working on a different HT1000 based board, and have a
> similar patch ready, with the difference that we set different GPIOs...
> so this access is board dependant.
 
I will prepare something to make this board dependent. Thank you very
much for the feedback.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From stepan at coresystems.de  Tue Jun  5 14:25:19 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 5 Jun 2007 14:25:19 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070605094623.14347.qmail@cdy.org>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
	<20070604155851.4065.qmail@cdy.org>
	<20070604233603.GA3421@flashgordon>
	<20070605004521.27823.qmail@cdy.org>
	<20070605062954.GA3602@flashgordon>
	<20070605094623.14347.qmail@cdy.org>
Message-ID: <20070605122518.GA18101@coresystems.de>

* Peter Stuge <stuge-linuxbios at cdy.org> [070605 11:46]:
> > Where do I have to specify the drive? Both, /vmlinuz and
> > /initrd.img are symlinks, could this cause the problem?
> 
> That's quite possible. I don't know if the FILO ext2 driver tries to
> resolve symlinks.

It does, but it might not be too good at it. 

Does the same scenario with the same menu.lst work with legacy bios and
grub?
 
> > Both are fetched from sda5 when booted, the root filesystem itself
> > is on sda2 ("linux notation").
> 
> And even if it does, symlinks across partitions are not likely to be
> supported.
 
yes. they are definitely not.

> Try specifying hde5:.. paths for both the kernel and initrd directly
> to FILO, bypassing the menu.lst file, or possibly doing so within the
> menu.lst file.

And please try bypassing the symlinks first by putting the names of the real
files into menu.lst. So we know whether its a symlink issue.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From svn at openbios.org  Tue Jun  5 14:51:53 2007
From: svn at openbios.org (svn at openbios.org)
Date: Tue,  5 Jun 2007 14:51:53 +0200
Subject: [LinuxBIOS] r2712 - trunk/LinuxBIOSv2/util/flashrom
Message-ID: <mailman.378.1355071118.16123.coreboot@coreboot.org>

Author: stepan
Date: 2007-06-05 14:51:52 +0200 (Tue, 05 Jun 2007)
New Revision: 2712

Modified:
   trunk/LinuxBIOSv2/util/flashrom/board_enable.c
   trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c
Log:
Move GPIO settings to board specific code for IBM x3455

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/LinuxBIOSv2/util/flashrom/board_enable.c
===================================================================
--- trunk/LinuxBIOSv2/util/flashrom/board_enable.c	2007-06-05 10:28:39 UTC (rev 2711)
+++ trunk/LinuxBIOSv2/util/flashrom/board_enable.c	2007-06-05 12:51:52 UTC (rev 2712)
@@ -246,6 +246,18 @@
 	return 0;
 }
 
+static int board_ibm_x3455(const char *name)
+{
+	uint8_t byte;
+
+	/* Set GPIO lines in HT1000 southbridge */
+	outb(0x45, 0xcd6);
+	byte = inb(0xcd7);
+	outb(byte|0x20, 0xcd7);
+
+	return 0;
+}
+
 /*
  * We use 2 sets of ids here, you're free to choose which is which. This
  * to provide a very high degree of certainty when matching a board on
@@ -290,6 +302,8 @@
 	 NULL, NULL, "ASUS A7V8-MX SE", board_asus_a7v8x_mx},
 	{0x10B9, 0x1541, 0x0000, 0x0000, 0x10B9, 0x1533, 0x0000, 0x0000,
 	 "asus", "p5a", "ASUS P5A", board_asus_p5a},
+	{0x1166, 0x0205, 0x1014, 0x0347, 0x0000, 0x0000, 0x0000, 0x0000,
+	 "ibm", "x3455", "IBM x3455", board_ibm_x3455},
 	{0, 0, 0, 0, 0, 0, 0, 0, NULL, NULL}	/* Keep this */
 };
 

Modified: trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c
===================================================================
--- trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c	2007-06-05 10:28:39 UTC (rev 2711)
+++ trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c	2007-06-05 12:51:52 UTC (rev 2712)
@@ -401,11 +401,6 @@
 	byte |= (1<<4);
 	pci_write_byte(dev, 0x43, byte);
 
-	/* Some magic. Comment me if you can */
-	outb(0x45, 0xcd6);
-	byte = inb(0xcd7);
-	outb(reg8|0x20, 0xcd7);
-
 	return 0;
 }
 




From nuessle at uni-mannheim.de  Tue Jun  5 14:53:50 2007
From: nuessle at uni-mannheim.de (Mondrian Nuessle)
Date: Tue, 05 Jun 2007 14:53:50 +0200
Subject: [LinuxBIOS] r2711 - trunk/LinuxBIOSv2/util/flashrom
In-Reply-To: <20070605121713.GB14755@coresystems.de>
References: <20070605102932.686A231CC5@mail-r83.rz.uni-mannheim.de>
	<46654FA8.5070103@uni-mannheim.de>
	<20070605121713.GB14755@coresystems.de>
Message-ID: <46655CDE.1060906@uni-mannheim.de>

> Ok, then this should probably go into a x3455 board specific code
> instead. I saw Yinghai made a lot of io to those ports in the ht1000
> specific code, so I assumed thats southbridge specific code.
these regs are also used for other things; but these two accesses are GPIOs.


> The weird thing is that I could overwrite some parts of the flash
> without that code (0x70000 to 0x80000), so it's probably not the flash
> write line.
The flash has two signals regarding write protection, WP# und TBL#,
write protect  und top boot lock, one protecting the lower parts of the
device, the other protecting the high part; so maybe only part of the
flash is protected here...

> Or, it might be the FPGA on board catches the area from 0x70000 to
> 0x80000 and decides whether to switch or not. I have no information on
> that, unfortunately, and I doubt I will be able to get it in a timely
> manner.
ok that is the other possibility

> I will prepare something to make this board dependent. Thank you very
> much for the feedback.
we'll then also start posting patches for the board we are working on

Regards,
Mondrian
-- 
 Mondrian Nuessle                 University of Mannheim
 Phone: +49 621 181 2717          Computer Architecture Group
 Fax:   +49 621 181 2713          http://ra.ti.uni-mannheim.de
 mailto:nuessle at uni-mannheim.de





From stepan at coresystems.de  Tue Jun  5 14:55:41 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 5 Jun 2007 14:55:41 +0200
Subject: [LinuxBIOS] r2711 - trunk/LinuxBIOSv2/util/flashrom
In-Reply-To: <46655CDE.1060906@uni-mannheim.de>
References: <20070605102932.686A231CC5@mail-r83.rz.uni-mannheim.de>
	<46654FA8.5070103@uni-mannheim.de>
	<20070605121713.GB14755@coresystems.de>
	<46655CDE.1060906@uni-mannheim.de>
Message-ID: <20070605125540.GA6595@coresystems.de>

* Mondrian Nuessle <nuessle at uni-mannheim.de> [070605 14:53]:
> > I will prepare something to make this board dependent. Thank you very
> > much for the feedback.
> we'll then also start posting patches for the board we are working on

Please do. I made the changes.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From svn at openbios.org  Tue Jun  5 17:02:18 2007
From: svn at openbios.org (svn at openbios.org)
Date: Tue,  5 Jun 2007 17:02:18 +0200
Subject: [LinuxBIOS] r2713 - trunk/LinuxBIOSv2/util/flashrom
Message-ID: <mailman.379.1355071118.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-05 17:02:18 +0200 (Tue, 05 Jun 2007)
New Revision: 2713

Modified:
   trunk/LinuxBIOSv2/util/flashrom/README
   trunk/LinuxBIOSv2/util/flashrom/board_enable.c
   trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c
Log:
flashrom: Document the newly supported IBM x3455 board and the
now-supported Broadcom HT-1000 chipset (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/LinuxBIOSv2/util/flashrom/README
===================================================================
--- trunk/LinuxBIOSv2/util/flashrom/README	2007-06-05 12:51:52 UTC (rev 2712)
+++ trunk/LinuxBIOSv2/util/flashrom/README	2007-06-05 15:02:18 UTC (rev 2713)
@@ -53,6 +53,7 @@
 * IWILL DK8-HTX: use -m iwill:dk8_htx
 * Agami Aruma: use -m AGAMI:ARUMA
 * ASUS P5A: use -m asus:p5a
+* IBM x3455: use -m ibm:x3455
 
 
 ROM Layout Support
@@ -153,6 +154,7 @@
 AMD Geode SC1100
 AMD AMD-8111
 ATI SB400
+Broadcom HT-1000
 Intel ICH0-ICH8 (all variations)
 Intel PIIX4/PIIX4E/PIIX4M
 NVIDIA CK804

Modified: trunk/LinuxBIOSv2/util/flashrom/board_enable.c
===================================================================
--- trunk/LinuxBIOSv2/util/flashrom/board_enable.c	2007-06-05 12:51:52 UTC (rev 2712)
+++ trunk/LinuxBIOSv2/util/flashrom/board_enable.c	2007-06-05 15:02:18 UTC (rev 2713)
@@ -250,10 +250,10 @@
 {
 	uint8_t byte;
 
-	/* Set GPIO lines in HT1000 southbridge */
+	/* Set GPIO lines in the Broadcom HT-1000 southbridge. */
 	outb(0x45, 0xcd6);
 	byte = inb(0xcd7);
-	outb(byte|0x20, 0xcd7);
+	outb(byte | 0x20, 0xcd7);
 
 	return 0;
 }

Modified: trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c
===================================================================
--- trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c	2007-06-05 12:51:52 UTC (rev 2712)
+++ trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c	2007-06-05 15:02:18 UTC (rev 2713)
@@ -387,12 +387,11 @@
 
 }
 
-
 static int enable_flash_ht1000(struct pci_dev *dev, char *name)
 {
-	unsigned char byte;
+	uint8_t byte;
 
-	/* Set the 4MB enable bit */
+	/* Set the 4MB enable bit. */
 	byte = pci_read_byte(dev, 0x41);
 	byte |= 0x0e;
 	pci_write_byte(dev, 0x41, byte);
@@ -462,7 +461,7 @@
 
 	{0x1002, 0x4377, "ATI SB400", enable_flash_sb400},	/* ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) */
 
-	{0x1166, 0x0205, "BCM HT1000", enable_flash_ht1000},
+	{0x1166, 0x0205, "Broadcom HT-1000", enable_flash_ht1000},
 };
 
 /*




From andi.mundt at web.de  Tue Jun  5 18:04:03 2007
From: andi.mundt at web.de (Andreas B. Mundt)
Date: Tue, 5 Jun 2007 18:04:03 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070605122518.GA18101@coresystems.de>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
	<20070604155851.4065.qmail@cdy.org>
	<20070604233603.GA3421@flashgordon>
	<20070605004521.27823.qmail@cdy.org>
	<20070605062954.GA3602@flashgordon>
	<20070605094623.14347.qmail@cdy.org>
	<20070605122518.GA18101@coresystems.de>
Message-ID: <20070605160403.GA3927@siddhartha.sunshine>


Hi all,

On Tue, Jun 05, 2007 at 02:25:19PM +0200, Stefan Reinauer wrote:
> 
> Does the same scenario with the same menu.lst work with legacy bios and
> grub?
>  
The setup works fine with linuxbios and Ward's time delay added to filo.c. 

> > > Both are fetched from sda5 when booted, the root filesystem itself
> > > is on sda2 ("linux notation").
> > 
> > And even if it does, symlinks across partitions are not likely to be
> > supported.
>  
> yes. they are definitely not.
> 
I should clearify that: it's not a "symlink across partitions", just the
root file system is on that other partition, like a separated boot/root 
partition setup.
>
> > Try specifying hde5:.. paths for both the kernel and initrd directly
> > to FILO, bypassing the menu.lst file, or possibly doing so within the
> > menu.lst file.
> 
I did this now and got a bit further. The Kernel seems to be loaded fine
(I kept the symlinks so far), but it fails to mount the root partition. Perhaps it 
has to be specified also in filo notation or the initrd.img is not loaded and 
needed to mount the ext3 root partion ...

I'm going to investigate that....

Thanks,

	Andi 
  



LinuxBIOS-2.0.0_m57sli_Fallback Sun Jun  3 18:19:58 CEST 2007 starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
core0 started: 
started ap apicid:  01
SBLink=00
NC node|link=00
begin msr fid, vid 3107121207110202
set fid failed for apicid =00
end   msr fid, vid 3107120707110210
mcp55_num:01
ht reset -


LinuxBIOS-2.0.0_m57sli_Fallback Sun Jun  3 18:19:58 CEST 2007 starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
core0 started: 
started ap apicid:  01
SBLink=00
NC node|link=00
begin msr fid, vid 3107120707110210
set fid failed for apicid =00
end   msr fid, vid 3107120707110210
mcp55_num:01
Ram1.00
Ram2.00
Unbuffered
333Mhz
Interleaved
RAM: 0x00400000 KB
Ram3
	dimm_mask = 00000033
	x4_mask = 00000000
	x16_mask = 00000000
	single_rank_mask = 00000000
	ODC = 00111322
	Addr Timing= 002b2220
Initializing memory:  done
RAM: 0x00500000 KB
Setting variable MTRR 2, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 3, base: 2048MB, range: 1024MB, type WB
set DQS timing:RcvrEn:Pass1: 00 CTLRMaxDelay=14 done
set DQS timing:DQSPos: 00 done
set DQS timing:RcvrEn:Pass2: 00 CTLRMaxDelay=34 done
Total DQS Training : tsc [00]=0000000045996bea
Total DQS Training : tsc [01]=00000000475a61d8
Total DQS Training : tsc [02]=000000009ff4ca11
Total DQS Training : tsc [03]=00000000a23a37b8
Ram4
v_esp=000cee78
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: Done
Copying LinuxBIOS to RAM.
src=fffdf000
dst=00100000
linxbios_ram.nrv2b length = 0000d633
linxbios_ram.bin   length = 00022510
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0_m57sli_Fallback Tue Jun  5 17:34:18 CEST 2007 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: pci_scan_bus for bus 00
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:00.0 [10de/0369] enabled
PCI: 00:00.0 [10de/0369] enabled next_unitid: 0010
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [10de/0369] enabled
PCI: 00:01.0 [10de/0360] enabled
PCI: 00:01.1 [10de/0368] enabled
PCI: 00:01.2 [10de/036a] enabled
PCI: 00:01.3 [10de/036b] enabled
PCI: 00:02.0 [10de/036c] enabled
PCI: 00:02.1 [10de/036d] enabled
PCI: 00:04.0 [10de/036e] enabled
PCI: 00:05.0 [10de/037f] enabled
PCI: 00:05.1 [10de/037f] enabled
PCI: 00:05.2 [10de/037f] enabled
PCI: 00:06.0 [10de/0370] enabled
PCI: 00:06.1 [10de/0371] enabled
PCI: 00:08.0 [10de/0373] enabled
PCI: 00:0a.0 [10de/0376] enabled
PCI: 00:0b.0 [10de/0374] enabled
PCI: 00:0c.0 [10de/0374] enabled
PCI: 00:0d.0 [10de/0378] enabled
PCI: 00:0e.0 [10de/0375] enabled
PCI: 00:0f.0 [10de/0377] enabled
PNP: 002e.0 disabled
PNP: 002e.1 enabled
PNP: 002e.2 disabled
PNP: 002e.3 disabled
PNP: 002e.4 enabled
PNP: 002e.5 enabled
PNP: 002e.6 enabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
smbus: PCI: 00:01.1[0]->I2C: 01:50 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:51 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:52 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:53 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:54 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:55 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:56 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:57 enabled
smbus: PCI: 00:01.1[1]->I2C: 02:51 enabled
PCI: pci_scan_bus for bus 01
PCI: pci_scan_bus returning with max=001
PCI: pci_scan_bus for bus 02
PCI: pci_scan_bus returning with max=002
PCI: pci_scan_bus for bus 03
PCI: pci_scan_bus returning with max=003
PCI: pci_scan_bus for bus 04
PCI: pci_scan_bus returning with max=004
PCI: pci_scan_bus for bus 05
PCI: pci_scan_bus returning with max=005
PCI: pci_scan_bus for bus 06
PCI: pci_scan_bus returning with max=006
PCI: pci_scan_bus for bus 07
PCI: 07:00.0 [10de/0392] enabled
PCI: pci_scan_bus returning with max=007
PCI: pci_scan_bus returning with max=007
PCI: pci_scan_bus returning with max=007
done
Allocating resources...
Reading resources...
PCI: 00:06.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io
PCI: 00:06.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem
PCI: 00:06.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 01 mem
PCI: 00:0a.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 02 io
PCI: 00:0a.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 02 prefmem
PCI: 00:0a.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 02 mem
PCI: 00:0b.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 03 io
PCI: 00:0b.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 03 prefmem
PCI: 00:0b.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 03 mem
PCI: 00:0c.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 04 io
PCI: 00:0c.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 04 prefmem
PCI: 00:0c.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 04 mem
PCI: 00:0d.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 05 io
PCI: 00:0d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 05 prefmem
PCI: 00:0d.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 05 mem
PCI: 00:0e.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 06 io
PCI: 00:0e.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 06 prefmem
PCI: 00:0e.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 06 mem
Done reading resources.
Allocating VGA resource PCI: 07:00.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:0f.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
VGA: PCI: 00:18.0 (aka node 0) link 0 has VGA device
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0>
PCI: 00:18.0 1b8 <- [0x00e0000000 - 0x00efffffff] prefmem <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00f4000000 - 0x00f61fffff] mem <node 0 link 0>
PCI: 00:01.0 14 <- [0x00f6144000 - 0x00f6144fff] mem
PNP: 002e.1 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.1 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.4 60 <- [0x0000000290 - 0x0000000297] io
PNP: 002e.4 62 <- [0x0000000230 - 0x0000000237] io
PNP: 002e.4 70 <- [0x0000000009 - 0x0000000009] irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.6 70 <- [0x000000000c - 0x000000000c] irq
PCI: 00:01.1 10 <- [0x0000002c00 - 0x0000002c3f] io
PCI: 00:01.1 20 <- [0x0000002c40 - 0x0000002c7f] io
PCI: 00:01.1 24 <- [0x0000002c80 - 0x0000002cbf] io
PCI: 00:01.1 60 <- [0x0000002000 - 0x00000020ff] io
PCI: 00:01.1 64 <- [0x0000002400 - 0x00000024ff] io
PCI: 00:01.1 68 <- [0x0000002800 - 0x00000028ff] io
PCI: 00:01.3 10 <- [0x00f6100000 - 0x00f613ffff] mem
PCI: 00:02.0 10 <- [0x00f6145000 - 0x00f6145fff] mem
PCI: 00:02.1 10 <- [0x00f614a000 - 0x00f614a0ff] mem
PCI: 00:04.0 20 <- [0x0000002cc0 - 0x0000002ccf] io
PCI: 00:05.0 10 <- [0x0000003000 - 0x0000003007] io
PCI: 00:05.0 14 <- [0x0000003070 - 0x0000003073] io
PCI: 00:05.0 18 <- [0x0000003010 - 0x0000003017] io
PCI: 00:05.0 1c <- [0x0000003080 - 0x0000003083] io
PCI: 00:05.0 20 <- [0x0000002cd0 - 0x0000002cdf] io
PCI: 00:05.0 24 <- [0x00f6146000 - 0x00f6146fff] mem
PCI: 00:05.1 10 <- [0x0000003020 - 0x0000003027] io
PCI: 00:05.1 14 <- [0x0000003090 - 0x0000003093] io
PCI: 00:05.1 18 <- [0x0000003030 - 0x0000003037] io
PCI: 00:05.1 1c <- [0x00000030a0 - 0x00000030a3] io
PCI: 00:05.1 20 <- [0x0000002ce0 - 0x0000002cef] io
PCI: 00:05.1 24 <- [0x00f6147000 - 0x00f6147fff] mem
PCI: 00:05.2 10 <- [0x0000003040 - 0x0000003047] io
PCI: 00:05.2 14 <- [0x00000030b0 - 0x00000030b3] io
PCI: 00:05.2 18 <- [0x0000003050 - 0x0000003057] io
PCI: 00:05.2 1c <- [0x00000030c0 - 0x00000030c3] io
PCI: 00:05.2 20 <- [0x0000002cf0 - 0x0000002cff] io
PCI: 00:05.2 24 <- [0x00f6148000 - 0x00f6148fff] mem
PCI: 00:06.1 10 <- [0x00f6140000 - 0x00f6143fff] mem
PCI: 00:08.0 10 <- [0x00f6149000 - 0x00f6149fff] mem
PCI: 00:08.0 14 <- [0x0000003060 - 0x0000003067] io
PCI: 00:08.0 18 <- [0x00f614b000 - 0x00f614b0ff] mem
PCI: 00:08.0 1c <- [0x00f614c000 - 0x00f614c00f] mem
PCI: 00:0f.0 1c <- [0x0000001000 - 0x0000001fff] bus 07 io
PCI: 00:0f.0 24 <- [0x00e0000000 - 0x00efffffff] bus 07 prefmem
PCI: 00:0f.0 20 <- [0x00f4000000 - 0x00f60fffff] bus 07 mem
PCI: 07:00.0 10 <- [0x00f4000000 - 0x00f4ffffff] mem
PCI: 07:00.0 14 <- [0x00e0000000 - 0x00efffffff] prefmem64
PCI: 07:00.0 1c <- [0x00f5000000 - 0x00f5ffffff] mem64
PCI: 07:00.0 24 <- [0x0000001000 - 0x000000107f] io
PCI: 07:00.0 30 <- [0x00f6000000 - 0x00f601ffff] romem
PCI: 00:18.3 94 <- [0x00f0000000 - 0x00f3ffffff] mem <gart>
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:18.0 cmd <- 140
PCI: 00:00.0 subsystem <- 1022/2b80
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 subsystem <- 1022/2b80
PCI: 00:01.0 cmd <- 14f
mcp55 lpc decode:PNP: 002e.1, base=0x000003f8, end=0x000003ff
mcp55 lpc decode:PNP: 002e.4, base=0x00000290, end=0x00000297
mcp55 lpc decode:PNP: 002e.4, base=0x00000230, end=0x00000237
mcp55 lpc decode:PNP: 002e.5, base=0x00000060, end=0x00000060
mcp55 lpc decode:PNP: 002e.5, base=0x00000064, end=0x00000064
PCI: 00:01.1 subsystem <- 1022/2b80
PCI: 00:01.1 cmd <- 141
PCI: 00:01.2 cmd <- 540
PCI: 00:01.3 cmd <- 142
PCI: 00:02.0 subsystem <- 1022/2b80
PCI: 00:02.0 cmd <- 142
PCI: 00:02.1 subsystem <- 1022/2b80
PCI: 00:02.1 cmd <- 142
PCI: 00:04.0 subsystem <- 1022/2b80
PCI: 00:04.0 cmd <- 141
PCI: 00:05.0 subsystem <- 1022/2b80
PCI: 00:05.0 cmd <- 143
PCI: 00:05.1 subsystem <- 1022/2b80
PCI: 00:05.1 cmd <- 143
PCI: 00:05.2 subsystem <- 1022/2b80
PCI: 00:05.2 cmd <- 143
PCI: 00:06.0 bridge ctrl <- 0a03
PCI: 00:06.0 cmd <- 144
PCI: 00:06.1 subsystem <- 1022/2b80
PCI: 00:06.1 cmd <- 142
PCI: 00:08.0 subsystem <- 1022/2b80
PCI: 00:08.0 cmd <- 143
PCI: 00:0a.0 bridge ctrl <- 0003
PCI: 00:0a.0 cmd <- 140
PCI: 00:0b.0 bridge ctrl <- 0003
PCI: 00:0b.0 cmd <- 140
PCI: 00:0c.0 bridge ctrl <- 0003
PCI: 00:0c.0 cmd <- 140
PCI: 00:0d.0 bridge ctrl <- 0003
PCI: 00:0d.0 cmd <- 140
PCI: 00:0e.0 bridge ctrl <- 0003
PCI: 00:0e.0 cmd <- 140
PCI: 00:0f.0 bridge ctrl <- 000b
PCI: 00:0f.0 cmd <- 147
PCI: 07:00.0 cmd <- 143
PCI: 00:18.1 subsystem <- 1022/2b80
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 1022/2b80
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
start_eip=0x00006000, offset=0x00110000, code_size=0x0000005b
Initializing CPU #0
CPU: vendor AMD device 60fb1
CPU: family 0f, model 6b, stepping 01
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

CPU model AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
Setting up local apic... apic_id: 0x00 done.
ECC Disabled
CPU #0 Initialized
Initializing CPU #1
Waiting for 1 CPUS to stop
CPU: vendor AMD device 60fb1
CPU: family 0f, model 6b, stepping 01
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

CPU model AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
Setting up local apic... apic_id: 0x01 done.
CPU #1 Initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 00:01.0 init
set power on after power fail
RTC Init
Invalid CMOS LB checksum
PNP: 002e.1 init
PNP: 002e.4 init
FAN_CTL: reg = 0x02a9, read value = 0x50
FAN_CTL: reg = 0x02a9, writing value = 0xd7
PNP: 002e.5 init
PNP: 002e.6 init
PCI: 00:01.1 init
PCI: 00:02.1 init
PCI: 00:04.0 init
IDE0
PCI: 00:05.0 init
SATA S 	SATA P 
PCI: 00:05.1 init
SATA S 	SATA P 
PCI: 00:05.2 init
SATA S 	SATA P 
PCI: 00:06.0 init
dev_root mem base = 0x00e0000000
[0x50] <-- 0xe0000000
PCI: 00:06.1 init
base = f6140000
codec_mask = 01
codec viddid: 10ec0883
No verb!
PCI: 00:08.0 init
MCP55 MAC PHY ID 0x01410c00 PHY ADDR 1
PCI: 00:0a.0 init
PCI: 00:0b.0 init
PCI: 00:0c.0 init
PCI: 00:0d.0 init
PCI: 00:0e.0 init
PCI: 00:0f.0 init
PCI: 00:18.1 init
PCI: 00:18.2 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:01.2 init
PCI: 00:01.3 init
PCI: 07:00.0 init
rom address for PCI: 07:00.0 = f6000000
copying VGA ROM Image from 0xf6000000 to 0xc0000, 0xf600 bytes
entering emulator
halt_sys: file /home/andi/freeBIOS/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 00000274
Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000 
Adjust rom_table_end from 0x000f0400 to 0x00100000 
Wrote linuxbios table at: 00000530 - 00000dd4  checksum 611c

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

rom_stream: 0xfffc0000 - 0xfffdefff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
New segment addr 0x100000 size 0x31220 offset 0xc0 filesize 0xbd88
(cleaned up) New segment addr 0x100000 size 0x31220 offset 0xc0 filesize 0xbd88
New segment addr 0x131220 size 0x48 offset 0xbe60 filesize 0x48
(cleaned up) New segment addr 0x131220 size 0x48 offset 0xbe60 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x00000000bff80000 memsz: 0x0000000000031220 filesz: 0x000000000000bd88
Clearing Segment: addr: 0x00000000bff8bd88 memsz: 0x0000000000025498
Loading Segment: addr: 0x00000000bffb1220 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x109618
FILO version 0.5 (andi at flashgordon) Tue Jun  5 17:33:50 CEST 2007
setup_timers: CPU 2400 MHz
Press <Enter> for default boot, or <Esc> for boot prompt... 2 1 timed out
boot: hde5:/vmlinuz hde5:/initrd.img root=/dev/sda2 ro console=ttyS0,115200
find_ide_controller: found PCI IDE controller 10de:037f prog_if=0x85
find_ide_controller: primary channel: native PCI mode
find_ide_controller: cmd_base=0x3000 ctrl_base=0x3070
ide_software_reset: Waiting for ide2 to become ready for reset... ok
init_drive: Testing for hde
init_drive: Probing for hde
init_drive: LBA mode, sectors=268435455
init_drive: LBA48 mode, sectors=488395055
init_drive: Init device params... ok
hde: LBA48 250GB: SAMSUNG SP2504C                         
init_drive: Testing for hdf
init_drive: Probing for hdf
IDE timeout after 50 ms while waiting for drq()
pio_data_in: No DRQ from device after read command
print_status: IDE: status=0x0, err=0x0
init_drive: Testing for hdf
init_drive: Probing for hdf
IDE timeout after 50 ms while waiting for drq()
pio_data_in: No DRQ from device after read command
print_status: IDE: status=0x0, err=0x0
ide_readmany: sector 0 to 0x0010c020
ide_readmany: sector 132825420 to 0x0010d820
ide_readmany: sector 132825485 to 0x0010da20
ide_readmany: sector 132825486 to 0x0010dc20
Mounted ext2fs
ide_readmany: sector 132825491 to 0x0010e620
ide_readmany: sector 132825492 to 0x0010e820
ide_readmany: sector 132825493 to 0x0010ea20
ide_readmany: sector 132825494 to 0x0010ec20
ide_readmany: sector 132825495 to 0x0010ee20
ide_readmany: sector 132825496 to 0x0010f020
ide_readmany: sector 132825497 to 0x0010f220
ide_readmany: sector 132825498 to 0x0010f420
ide_readmany: sector 132825515 to 0x00111620
ide_readmany: sector 132825516 to 0x00111820
ide_readmany: sector 132825517 to 0x00111a20
ide_readmany: sector 132825518 to 0x00111c20
ide_readmany: sector 132825519 to 0x00111e20
ide_readmany: sector 132825520 to 0x00112020
ide_readmany: sector 132825521 to 0x00112220
ide_readmany: sector 132825522 to 0x00112420
ide_readmany: sector 132829571 to 0x0010c620
ide_readmany: sector 132829572 to 0x0010c820
ide_readmany: sector 132829573 to 0x0010ca20
ide_readmany: sector 132829574 to 0x0010cc20
ide_readmany: sector 132829575 to 0x0010ce20
ide_readmany: sector 132829576 to 0x0010d020
ide_readmany: sector 132829577 to 0x0010d220
ide_readmany: sector 132829578 to 0x0010d420
ide_readmany: sector 136233387 to 0x00111620
ide_readmany: sector 136233388 to 0x00111820
ide_readmany: sector 136233389 to 0x00111a20
ide_readmany: sector 136233390 to 0x00111c20
ide_readmany: sector 136233391 to 0x00111e20
ide_readmany: sector 136233392 to 0x00112020
ide_readmany: sector 136233393 to 0x00112220
ide_readmany: sector 136233394 to 0x00112420
ide_readmany: sector 136298891 to 0x0010d620
ide_readmany: sector 136298892 to 0x0010d820
ide_readmany: sector 136298893 to 0x0010da20
ide_readmany: sector 136298894 to 0x0010dc20
ide_readmany: sector 136298895 to 0x0010de20
ide_readmany: sector 136298896 to 0x0010e020
ide_readmany: sector 136298897 to 0x0010e220
ide_readmany: sector 136298898 to 0x0010e420
ext2fs_read_one: block  452608  offset=0 len=52 ret=0
ide_readmany: sector 136446347 to 0x0010d620
ide_readmany: sector 132825515 to 0x00111620
ide_readmany: sector 132825516 to 0x00111820
ide_readmany: sector 132825517 to 0x00111a20
ide_readmany: sector 132825518 to 0x00111c20
ide_readmany: sector 132825519 to 0x00111e20
ide_readmany: sector 132825520 to 0x00112020
ide_readmany: sector 132825521 to 0x00112220
ide_readmany: sector 132825522 to 0x00112420
ide_readmany: sector 136233387 to 0x00111620
ide_readmany: sector 136233388 to 0x00111820
ide_readmany: sector 136233389 to 0x00111a20
ide_readmany: sector 136233390 to 0x00111c20
ide_readmany: sector 136233391 to 0x00111e20
ide_readmany: sector 136233392 to 0x00112020
ide_readmany: sector 136233393 to 0x00112220
ide_readmany: sector 136233394 to 0x00112420
ide_readmany: sector 136298891 to 0x0010d620
ext2fs_read_one: block  452608  offset=0 len=560 ret=0
ide_readmany: sector 136446347 to 0x0010d620
ide_readmany: sector 136446348 to 0x0010d820
Found Linuxblock  452609  offset=1099 len=256 ret=0
ide_readmany: sector 136446357 to 0x0010ea20
 version 2.6.21-1-amd64 (unknown at Debian) #1 SMP Fri May 18 23:28:21 CEST 2007 bzImage.
Loading kernel... sector 136446443 to 0x00111620
ide_readmany: sector 136446444 to 0x00111820
ide_readmany: sector 136446445 to 0x00111a20
ide_readmany: sector 136446446 to 0x00111c20
ide_readmany: sector 136446447 to 0x00111e20
ide_readmany: sector 136446448 to 0x00112020
ide_readmany: sector 136446449 to 0x00112220
ide_readmany: sector 136446450 to 0x00112420
ext2fs_read_many:  10 blocks  452610 - 452619  len=1561450 ret=0
ide_readmany: sectors 136446363 - 136446442 ( 80) to 0x40231270
ext2fs_read_many: 372 blocks  452621 - 452992  len=1520490 ret=40960
ide_readmany: sectors 136446451 - 136446706 (256) to 0x4023b270
ide_readmany: sectors 136446707 - 136446962 (256) to 0x4025b270
ide_readmany: sectors 136446963 - 136447218 (256) to 0x4027b270
ide_readmany: sectors 136447219 - 136447474 (256) to 0x4029b270
ide_readmany: sectors 136447475 - 136447730 (256) to 0x402bb270
ide_readmany: sectors 136447731 - 136447986 (256) to 0x402db270
ide_readmany: sectors 136447987 - 136448242 (256) to 0x402fb270
ide_readmany: sectors 136448243 - 136448498 (256) to 0x4031b270
ide_readmany: sectors 136448499 - 136448754 (256) to 0x4033b270
ide_readmany: sectors 136448755 - 136449010 (256) to 0x4035b270
ide_readmany: sectors 136449011 - 136449266 (256) to 0x4037b270
ide_readmany: sectors 136449267 - 136449426 (160) to 0x4039b270
ext2fs_read: discarding 3222 surplus bytes
ext2fs_read: done reading many  len=0 ret=1561450
ok
Jumping to entry point...
Linux version 2.6.21-1-amd64 (Debian 2.6.21-2) (waldi at debian.org) (gcc version 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)) #1 SMP Fri May 18 23:28:21 CEST 2007
Command line: hde5:/initrd.img root=/dev/sda2 ro console=ttyS0,115200
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
end_pfn_map = 1310720
DMI not present or invalid.
Scanning NUMA topology in Northbridge 24
Number of nodes 1
Node 0 MemBase 0000000000000000 Limit 0000000140000000
Using node hash shift of 63
Bootmem setup node 0 0000000000000000-0000000140000000
Zone PFN ranges:
  DMA             1 ->     4096
  DMA32        4096 ->  1048576
  Normal    1048576 ->  1310720
early_node_map[4] active PFN ranges
    0:        1 ->      160
    0:      192 ->      240
    0:      256 ->   786432
    0:  1048576 ->  1310720
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
Intel MultiProcessor Specification v1.4
MPTABLE: OEM ID: GIGABYTE MPTABLE: Product ID: M57SLI       MPTABLE: APIC at: 0xFEE00000
Processor #0 (Bootup-CPU)
Processor #1
I/O APIC #2 at 0xF6144000.
Setting APIC routing to physical flat
Processors: 2
Nosave address range: 00000000000a0000 - 00000000000c0000
Nosave address range: 00000000000f0000 - 0000000000100000
Nosave address range: 00000000c0000000 - 0000000100000000
Allocating PCI resources starting at c4000000 (gap: c0000000:40000000)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 37504 bytes of per cpu data
Built 1 zonelists.  Total pages: 1029631
Kernel command line: hde5:/initrd.img root=/dev/sda2 ro console=ttyS0,115200
Unknown boot option `hde5:/initrd.img': ignoring
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Detected 2400.010 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking aperture...
CPU 0: aperture @ f0000000 size 64 MB
Memory: 4112116k/5242880k available (1975k kernel code, 81992k reserved, 931k data, 296k init)
Calibrating delay using timer specific routine.. 4803.83 BogoMIPS (lpj=9607665)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/0 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables [20070126]
ACPI: Unable to load the System Description Tables
Using local APIC timer interrupts.
result 12500063
Detected 12.500 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4800.26 BogoMIPS (lpj=9600531)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ stepping 01
Brought up 2 CPUs
migration_cost=205
NET: Registered protocol family 16
PCI: Using configuration type 1
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Using IRQ router default [10de/0370] at 0000:00:06.0
PCI->APIC IRQ transform: 0000:00:01.1[A] -> IRQ 10
PCI->APIC IRQ transform: 0000:00:01.3[B] -> IRQ 10
PCI->APIC IRQ transform: 0000:00:02.0[A] -> IRQ 22
PCI->APIC IRQ transform: 0000:00:02.1[B] -> IRQ 23
PCI->APIC IRQ transform: 0000:00:05.0[A] -> IRQ 20
PCI->APIC IRQ transform: 0000:00:05.1[B] -> IRQ 23
PCI->APIC IRQ transform: 0000:00:05.2[C] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:06.1[B] -> IRQ 23
PCI->APIC IRQ transform: 0000:00:08.0[A] -> IRQ 22
PCI->APIC IRQ transform: 0000:07:00.0[A] -> IRQ 17
NET: Registered protocol family 8
NET: Registered protocol family 20
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ f0000000 size 65536 KB
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
PCI: Bridge: 0000:00:06.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0a.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0b.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0f.0
  IO window: 1000-1fff
  MEM window: f4000000-f60fffff
  PREFETCH window: e0000000-efffffff
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 131072 (order: 9, 3145728 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1181058107.360:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.102 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Cannot open root device "sda2" or unknown-block(0,0)
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)



From yinghailu at gmail.com  Tue Jun  5 18:20:39 2007
From: yinghailu at gmail.com (yhlu)
Date: Tue, 5 Jun 2007 09:20:39 -0700
Subject: [LinuxBIOS] [PATCH] Add generic Intel i82801 support
In-Reply-To: <46652C47.4030808@gmail.com>
References: <46652C47.4030808@gmail.com>
Message-ID: <2ea3fae10706050920k3474b62ejd5a7d6d3734b2d26@mail.gmail.com>

On 6/5/07, Corey Osgood <corey.osgood at gmail.com> wrote:
> See patch. I'm still waiting on a response from Steve just to confirm
> GPLv2 on a couple files, and I'd like Yinghai to make sure those details
> are correct as well (ie were you working for Tyan at the time, and is
> that the right email address to use?).

yeah, that email should be always work. except someday google try to
charge for that.

YH



From svn at openbios.org  Tue Jun  5 19:04:59 2007
From: svn at openbios.org (svn at openbios.org)
Date: Tue,  5 Jun 2007 19:04:59 +0200
Subject: [LinuxBIOS] r344 - LinuxBIOSv3/southbridge/amd/cs5536
Message-ID: <mailman.380.1355071118.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-06-05 19:04:59 +0200 (Tue, 05 Jun 2007)
New Revision: 344

Added:
   LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c
Log:
SMBus support for the AMD Geode CS5536. This code can initialize
the SMBus and basically provides one public funtion which can be used
by other code (e.g. in the northbridge): smbus_read_byte().

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Added: LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c
===================================================================
--- LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c	                        (rev 0)
+++ LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c	2007-06-05 17:04:59 UTC (rev 344)
@@ -0,0 +1,331 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 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 version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console.h>
+#include <io.h>
+#include "cs5536.h"
+
+#define SMBUS_ERROR			-1
+#define SMBUS_WAIT_UNTIL_READY_TIMEOUT	-2
+#define SMBUS_WAIT_UNTIL_DONE_TIMEOUT	-3
+#define SMBUS_TIMEOUT			1000
+
+/**
+ * Enable the SMBus.
+ *
+ * Basically, set the enable bit in the controller. This can be (and is)
+ * called multiple times.
+ */
+static void smbus_enable(void)
+{
+	/* Set the Serial Clock Line (SCL) frequency and enable the SMBus
+	 * controller. 0x20 is one possible frequency. For DRAM we use 0x7f,
+	 * probably because it is a slower and presumably more reliable clock.
+	 */
+	/* outb((0x20 << 1) | SMB_CTRL2_ENABLE, smbus_io_base + SMB_CTRL2); */
+	outb((0x7F << 1) | SMB_CTRL2_ENABLE, SMBUS_IO_BASE + SMB_CTRL2);
+}
+
+/**
+ * Initialize the SMBus controller.
+ *
+ * Basically, set the enable bit in the controller and set the host
+ * controller address. Code can call this more than once, but the effect of
+ * doing so is uncertain due to SMBus address set.
+ */
+static void smbus_init(void)
+{
+	smbus_enable();
+
+	/* Setup SMBus host controller address to 0xEF. This is not an
+	 * I/O port address but an SMBus address.
+	 */
+	outb((0xEF | SMB_ADD_SAEN), SMBUS_IO_BASE + SMB_ADD);
+}
+
+/**
+ * Fixed delay for the SMBus controller.
+ *
+ * Currently, this is a no-op. No delay. We are going to leave it here as it
+ * indicates where a delay might be needed, for future chipset issues that
+ * might happen. And if such issues might happen, they usually do.
+ */
+static void smbus_delay(void)
+{
+	/* inb(0x80); */
+}
+
+/**
+ * Wait for the SMBus controller to become ready.
+ *
+ * There are three ways this can happen. Either the controller becomes
+ * ready (good); or we get an error (bad), in which case we return the
+ * error; or, we time out and give up, in which case we return
+ * SMBUS_WAIT_UNTIL_READY_TIMEOUT (very bad).
+ *
+ * @param smbus_io_base The SMBus I/O base.
+ * @return The error code, or 0 on success.
+ */
+static int smbus_wait(u16 smbus_io_base)
+{
+	u8 val;
+	unsigned long loops = SMBUS_TIMEOUT;
+
+	do {
+		smbus_delay();
+		val = inb(smbus_io_base + SMB_STS);
+		if ((val & SMB_STS_SDAST) != 0)
+			break;
+		if (val & (SMB_STS_BER | SMB_STS_NEGACK)) {
+			printk(BIOS_DEBUG, "SMBus WAIT ERROR %x\n", val);
+			return SMBUS_ERROR;
+		}
+	} while (--loops);
+
+	return loops ? 0 : SMBUS_WAIT_UNTIL_READY_TIMEOUT;
+}
+
+/**
+ * Generate an SMBus start condition.
+ *
+ * Kick off the SMBus. At this point we will own the bus and can issue an
+ * address or other part of the transaction. This code can either exit
+ * immediately due to a bus conflict, returning SMBUS_ERROR, or it will,
+ * once the bus is started, return the error code (or success!) from
+ * smbus_wait().
+ *
+ * @param smbus_io_base The SMBus I/O base.
+ * @return The error code, or 0 on success.
+ */
+static int smbus_start_condition(u16 smbus_io_base)
+{
+	u8 val;
+
+	/* Issue a start condition. */
+	val = inb(smbus_io_base + SMB_CTRL1);
+	outb(val | SMB_CTRL1_START, smbus_io_base + SMB_CTRL1);
+
+	/* Check for bus conflict. */
+	val = inb(smbus_io_base + SMB_STS);
+	if ((val & SMB_STS_BER) != 0)
+		return SMBUS_ERROR;
+
+	return smbus_wait(smbus_io_base);
+}
+
+/**
+ * Check the SMBus stop condition.
+ *
+ * Wait until the SDA status is set, indicating that data has been returned.
+ *
+ * @param smbus_io_base The SMBus I/O base.
+ * @return The error code, or 0 on success.
+ */
+static int smbus_check_stop_condition(u16 smbus_io_base)
+{
+	u8 val;
+	unsigned long loops = SMBUS_TIMEOUT;
+
+	/* Check for SDA status. */
+	do {
+		smbus_delay();
+		val = inb(smbus_io_base + SMB_CTRL1);
+		if ((val & SMB_CTRL1_STOP) == 0) {
+			break;
+		}
+		smbus_enable();
+	} while (--loops);
+
+	return loops ? 0 : SMBUS_WAIT_UNTIL_READY_TIMEOUT;
+}
+
+/**
+ * Stop the SMBus and wait for the stop to be acknowledged by the
+ * hardware, using smbus_wait() to wait.
+ *
+ * @param smbus_io_base The SMBus I/O base.
+ * @return The error code, or 0 on success.
+ */
+static int smbus_stop_condition(u16 smbus_io_base)
+{
+	outb(SMB_CTRL1_STOP, smbus_io_base + SMB_CTRL1);
+	return smbus_wait(smbus_io_base);
+}
+
+/**
+ * Acknowledge the SMBus.
+ *
+ * Always succeeds. Always sends the ack.
+ *
+ * @param smbus_io_base The SMBus I/O base.
+ */
+static void smbus_ack(u16 smbus_io_base)
+{
+	u8 val = inb(smbus_io_base + SMB_CTRL1);
+	outb(val | SMB_CTRL1_ACK, smbus_io_base + SMB_CTRL1);
+}
+
+/**
+ * Set the slave address (e.g. 0x50 for DRAM socket 0) into the SMBus packet.
+ * 
+ * @param smbus_io_base The SMBus I/O base.
+ * @param device The device.
+ * @return The error code, or 0 on success.
+ */
+static int smbus_send_slave_address(u16 smbus_io_base, u8 device)
+{
+	u8 val;
+
+	/* Send the slave address. */
+	outb(device, smbus_io_base + SMB_SDA);
+
+	/* Check for bus conflict and NACK. */
+	val = inb(smbus_io_base + SMB_STS);
+	if (((val & SMB_STS_BER) != 0) || ((val & SMB_STS_NEGACK) != 0)) {
+		printk(BIOS_DEBUG, "SEND SLAVE ERROR (%x)\n", val);
+		return SMBUS_ERROR;
+	}
+
+	return smbus_wait(smbus_io_base);
+}
+
+/**
+ * Issue an SMBus command.
+ *
+ * This can fail if there is a bus conflict. The chipset will indicate
+ * an error.
+ *
+ * @param smbus_io_base The SMBus I/O base.
+ * @param command The command.
+ * @return The error code, or 0 on success.
+ */
+static int smbus_send_command(u16 smbus_io_base, u8 command)
+{
+	u8 val;
+
+	/* Send the command. */
+	outb(command, smbus_io_base + SMB_SDA);
+
+	/* Check for bus conflict and NACK. */
+	val = inb(smbus_io_base + SMB_STS);
+	if (((val & SMB_STS_BER) != 0) || ((val & SMB_STS_NEGACK) != 0))
+		return SMBUS_ERROR;
+
+	return smbus_wait(smbus_io_base);
+}
+
+/**
+ * Get the data from the returned SMBus packet.
+ *
+ * @param smbus_io_base The SMBus I/O base.
+ * @return The data from the SMBus packet area.
+ */
+static u8 smbus_get_result(u16 smbus_io_base)
+{
+	return inb(smbus_io_base + SMB_SDA);
+}
+
+/**
+ * Read a byte from the SMBus.
+ *
+ * All the previous functions exist to support this one. Read a byte from
+ * device 'device' at address 'address'.
+ *
+ * @param smbus_io_base The SMBus I/O base.
+ * @param device The device.
+ * @param command The command.
+ * @return The data from the SMBus packet area.
+ */
+static u8 do_smbus_read_byte(u16 smbus_io_base, u8 device, u8 address)
+{
+	char *error = NULL;
+	int errno;
+
+	if (smbus_check_stop_condition(smbus_io_base)) {
+		error = "smbus_check_stop_condition timed out";
+		goto err
+	}
+
+	if (errno = smbus_start_condition(smbus_io_base)) {
+		error = "smbus_start_condition";
+		goto err;
+	}
+
+	if (errno = smbus_send_slave_address(smbus_io_base, device)) {
+		error = "smbus_send_slave_address";
+		goto err;
+	}
+
+	smbus_ack(smbus_io_base);
+
+	if (errno = smbus_send_command(smbus_io_base, address)) {
+		error = "smbus_send_command";
+		goto err;
+	}
+
+	if (errno = smbus_start_condition(smbus_io_base)) {
+		error = "smbus_start_condition";
+		goto err;
+	}
+
+	if (errno = smbus_send_slave_address(smbus_io_base, device | 0x01)) {
+		error = "smbus_send_slave_address";
+		goto err;
+	}
+
+	if (errno = smbus_stop_condition(smbus_io_base)) {
+		error = "second smbus_stop_condition";
+		goto err;
+	}
+
+	return smbus_get_result(smbus_io_base);
+
+err:
+	printk(BIOS_ERR, "SMBus READ ERROR: %s; device %02x", error, device);
+	/* Stop, clean up the error, and leave. */
+	smbus_stop_condition(smbus_io_base);
+	outb(inb(smbus_io_base + SMB_STS), smbus_io_base + SMB_STS);
+	outb(0x0, smbus_io_base + SMB_STS);
+
+	return 0xFF;
+}
+
+/**
+ * Read a byte from the SMBus.
+ *
+ * All other functions in this file are static and support this one function.
+ * Since we are using gcc now, we use a static variable to tell us whether
+ * to enable the SMBus. Thus the northbridge code need only worry about
+ * one thing -- calling this function to read DRAM parameters.
+ *
+ * @param device The device.
+ * @param command The command.
+ * @return The data from the SMBus packet area or an error of 0xff (i.e. -1).
+ */
+int smbus_read_byte(u16 device, u8 address)
+{
+	static int first_time = 1;
+
+	if (first_time) {
+		smbus_init();
+		first_time = 0;
+	}
+
+	return do_smbus_read_byte(SMBUS_IO_BASE, device, address);
+}




From stuge-linuxbios at cdy.org  Tue Jun  5 19:23:15 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 5 Jun 2007 19:23:15 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070605160403.GA3927@siddhartha.sunshine>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
	<20070604155851.4065.qmail@cdy.org>
	<20070604233603.GA3421@flashgordon>
	<20070605004521.27823.qmail@cdy.org>
	<20070605062954.GA3602@flashgordon>
	<20070605094623.14347.qmail@cdy.org>
	<20070605122518.GA18101@coresystems.de>
	<20070605160403.GA3927@siddhartha.sunshine>
Message-ID: <20070605172315.16916.qmail@cdy.org>

On Tue, Jun 05, 2007 at 06:04:03PM +0200, Andreas B. Mundt wrote:
> boot: hde5:/vmlinuz hde5:/initrd.img root=/dev/sda2 ro console=ttyS0,115200

There is at least initrd= missing before hde5:/initrd.img

But should the initrd path actually be in FILO notation?

Does FILO load the initrd for the kernel, or does the kernel load it
on it's own? If so, use root=/dev/sda5 initrd=/initrd.img


> VFS: Cannot open root device "sda2" or unknown-block(0,0)

This kernel doesn't see any storage controllers, neither IDE nor
SATA.. :(


//Peter



From svn at openbios.org  Tue Jun  5 19:40:18 2007
From: svn at openbios.org (svn at openbios.org)
Date: Tue,  5 Jun 2007 19:40:18 +0200
Subject: [LinuxBIOS] r345 - LinuxBIOSv3/southbridge/amd/cs5536
Message-ID: <mailman.381.1355071118.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-06-05 19:40:18 +0200 (Tue, 05 Jun 2007)
New Revision: 345

Added:
   LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c
Log:
Early setup support for the initram phase.

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Added: LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c
===================================================================
--- LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c	                        (rev 0)
+++ LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c	2007-06-05 17:40:18 UTC (rev 345)
@@ -0,0 +1,257 @@
+/*
+* This file is part of the LinuxBIOS project.
+*
+* Copyright (C) 2007 Advanced Micro Devices
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 as
+* published by the Free Software Foundation.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+*/
+
+/*
+ * cs5536_early_setup.c:Early chipset initialization for CS5536 companion device
+ * This code is needed for setting up ram, since we need SMBUS working as 
+ * well as serial port. 
+ * This file implements the initialization sequence documented in section 4.2 of
+ * AMD Geode GX Processor CS5536 Companion Device GoedeROM Porting Guide.
+ */
+
+/**
+ * @brief Set up GLINK routing for this part. The routing is controlled by an MSR. 
+ */
+static void cs5536_setup_extmsr(void)
+{
+	msr_t msr;
+
+	/* forward MSR access to CS5536_GLINK_PORT_NUM to CS5536_DEV_NUM */
+	msr.hi = msr.lo = 0x00000000;
+	if (CS5536_GLINK_PORT_NUM <= 4) {
+		msr.lo = CS5536_DEV_NUM << 
+			(unsigned char)((CS5536_GLINK_PORT_NUM - 1) * 8);
+	} else {
+		msr.hi = CS5536_DEV_NUM << 
+			(unsigned char)((CS5536_GLINK_PORT_NUM - 5) * 8);
+	}
+	wrmsr(GLPCI_ExtMSR, msr);
+}
+
+/**
+ * @brief Setup PCI IDSEL for CS5536
+ */
+static void cs5536_setup_idsel(void)
+{
+	/* write IDSEL to the write once register at address 0x0000 */
+	outl(0x1 << (CS5536_DEV_NUM + 10), 0);
+}
+
+/**
+ * @brief Need to get a good explanation of what this is.
+ */
+static void cs5536_usb_swapsif(void)
+{
+	msr_t msr;
+
+	msr = rdmsr(USB1_SB_GLD_MSR_CAP + 0x5);
+	//USB Serial short detect bit.
+	if (msr.hi & 0x10) {
+		/* We need to preserve bits 32,33,35 and not clear any BIST
+		 * error, but clear the SERSHRT error bit */
+
+		msr.hi &= 0xFFFFFFFB;
+		wrmsr(USB1_SB_GLD_MSR_CAP + 0x5, msr);
+	}
+}
+
+/**
+ * @brief Set up IO bases for SMBUS, GPIO, MFGPT, ACPI, and PM. 
+ * These can be changed by Linux later. We set some initial value so 
+ * that the resources are there as needed. 
+ * The values are hardcoded because, this early in the process, fancy
+ * allocation can do more harm than good. 
+ */
+static void cs5536_setup_iobase(void)
+{
+	msr_t msr;
+	/* setup LBAR for SMBus controller */
+	msr.hi = 0x0000f001;
+	msr.lo = SMBUS_IO_BASE;
+	wrmsr(MDD_LBAR_SMB, msr);
+
+	/* setup LBAR for GPIO */
+	msr.hi = 0x0000f001;
+	msr.lo = GPIO_IO_BASE;
+	wrmsr(MDD_LBAR_GPIO, msr);
+
+	/* setup LBAR for MFGPT */
+	msr.hi = 0x0000f001;
+	msr.lo = MFGPT_IO_BASE;
+	wrmsr(MDD_LBAR_MFGPT, msr);
+
+	/* setup LBAR for ACPI */
+	msr.hi = 0x0000f001;
+	msr.lo = ACPI_IO_BASE;
+	wrmsr(MDD_LBAR_ACPI, msr);
+
+	/* setup LBAR for PM Support */
+	msr.hi = 0x0000f001;
+	msr.lo = PMS_IO_BASE;
+	wrmsr(MDD_LBAR_PMS, msr);
+}
+
+/**
+ * @brief Set up the power button for operation. 
+ */
+static void cs5536_setup_power_button(void)
+{
+	/*      Power Button Setup */
+	outl(0x40020000, PMS_IO_BASE + 0x40);
+
+	/* setup GPIO24, it is the external signal for 5536 vsb_work_aux
+	 * which controls all voltage rails except Vstandby & Vmem.
+	 * We need to enable, OUT_AUX1 and OUTPUT_ENABLE in this order.
+	 * If GPIO24 is not enabled then soft-off will not work. 
+	 */
+	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUT_AUX1_SELECT);
+	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUTPUT_ENABLE);
+
+}
+
+/**
+ * @brief Set the various GPIOs. An unknown question at this point is 
+ * how general this is to all mainboards. 
+ */
+static void cs5536_setup_gpio(void)
+{
+	uint32_t val;
+
+	/* setup GPIO pins 14/15 for SDA/SCL */
+	val = GPIOL_15_SET | GPIOL_14_SET;
+	/* Output Enable */
+	outl(val, GPIO_IO_BASE + GPIOL_OUT_AUX1_SELECT);
+	/* Output AUX1 */
+	outl(val, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
+	/* Input Enable */
+	outl(val, GPIO_IO_BASE + GPIOL_IN_AUX1_SELECT);
+	/* Input AUX1 */
+	outl(val, GPIO_IO_BASE + GPIOL_INPUT_ENABLE);
+}
+
+/**
+ * @brief Disable the internal UART. 
+ * Different boards have different UARTs for COM1. 
+ */
+static void cs5536_disable_internal_uart(void)
+{
+	msr_t msr;
+	/* The UARTs default to enabled.
+	 * Disable and reset them and configure them later. (SIO init) 
+	 */
+	msr = rdmsr(MDD_UART1_CONF);
+	msr.lo = 1;		// reset
+	wrmsr(MDD_UART1_CONF, msr);
+	msr.lo = 0;		// disabled
+	wrmsr(MDD_UART1_CONF, msr);
+
+	msr = rdmsr(MDD_UART2_CONF);
+	msr.lo = 1;		// reset
+	wrmsr(MDD_UART2_CONF, msr);
+	msr.lo = 0;		// disabled
+	wrmsr(MDD_UART2_CONF, msr);
+}
+
+/**
+ * @brief Set up the cs5536 CIS interface to CPU  interface to match modes. 
+ */
+static void cs5536_setup_cis_mode(void)
+{
+	msr_t msr;
+
+	/* setup CPU interface serial to mode B to match CPU */
+	msr = rdmsr(GLPCI_SB_CTRL);
+	msr.lo &= ~0x18;
+	msr.lo |= 0x10;
+	wrmsr(GLPCI_SB_CTRL, msr);
+}
+
+/**
+ * @brief Enable the on chip UART. 
+ */
+/* see page 412 of the cs5536 companion book */
+static void cs5536_setup_onchipuart(void)
+{
+	msr_t msr;
+
+	/* Setup early for polling only mode.
+	 * 1. Eanble GPIO 8 to OUT_AUX1, 9 to IN_AUX1
+	 *        GPIO LBAR + 0x04, LBAR + 0x10, LBAR + 0x20, LBAR + 34
+	 * 2. Enable UART IO space in MDD
+	 *        MSR 0x51400014 bit 18:16
+	 * 3. Enable UART controller
+	 *        MSR 0x5140003A bit 0, 1
+	 */
+
+	/* GPIO8 - UART1_TX */
+	/* Set: Output Enable  (0x4) */
+	outl(GPIOL_8_SET, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
+	/* Set: OUTAUX1 Select (0x10) */
+	outl(GPIOL_8_SET, GPIO_IO_BASE + GPIOL_OUT_AUX1_SELECT);
+	/* GPIO9 - UART1_RX */
+	/* Set: Input Enable   (0x20) */
+	outl(GPIOL_9_SET, GPIO_IO_BASE + GPIOL_INPUT_ENABLE);
+	/* Set: INAUX1 Select  (0x34) */
+	outl(GPIOL_9_SET, GPIO_IO_BASE + GPIOL_IN_AUX1_SELECT);
+
+	/* set address to 3F8 */
+	msr = rdmsr(MDD_LEG_IO);
+	msr.lo |= 0x7 << 16;
+	wrmsr(MDD_LEG_IO, msr);
+
+	/*      Bit 1 = DEVEN (device enable)
+	 *      Bit 4 = EN_BANKS (allow access to the upper banks
+	 */
+	msr.lo = (1 << 4) | (1 << 1);
+	msr.hi = 0;
+
+	/* enable COM1 */
+	wrmsr(MDD_UART1_CONF, msr);
+}
+
+
+/**
+ * @brief Board setup. Known to work on norwich and digitial logic boards. 
+ * Note we do NOT do any UART
+ * setup here -- this is done later by the mainboard setup, 
+ * since UART usage is not universal. 
+ */
+static void cs5536_early_setup(void)
+{
+	msr_t msr;
+
+	/* note: you can't do prints in here in most cases,
+	 * and we don't want to hang on serial, so they are
+	 * commented out
+ 	*/
+	cs5536_setup_extmsr();
+	cs5536_setup_cis_mode();
+
+	msr = rdmsr(GLCP_SYS_RSTPLL);
+	if (msr.lo & (0x3f << 26)) {
+		/* PLL is already set and we are reboot from PLL reset */
+		return;
+	}
+	cs5536_setup_idsel();
+	cs5536_usb_swapsif();
+	cs5536_setup_iobase();
+	cs5536_setup_gpio();
+	cs5536_enable_smbus();
+	cs5536_setup_power_button();
+}




From stuge-linuxbios at cdy.org  Tue Jun  5 19:45:32 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 5 Jun 2007 19:45:32 +0200
Subject: [LinuxBIOS] r345 - LinuxBIOSv3/southbridge/amd/cs5536
Message-ID: <20070605174532.21212.qmail@cdy.org>

On Tue, Jun 05, 2007 at 07:40:18PM +0200, svn at openbios.org wrote:
> New Revision: 345
> 
> Added:
>    LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c
> Log:
> Early setup support for the initram phase.

Not sure I like this.

The important part is of course being 100% generic for any 5536
design.

Comments?


//Peter



From rminnich at gmail.com  Tue Jun  5 19:51:26 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 5 Jun 2007 10:51:26 -0700
Subject: [LinuxBIOS] r345 - LinuxBIOSv3/southbridge/amd/cs5536
In-Reply-To: <20070605174532.21212.qmail@cdy.org>
References: <20070605174532.21212.qmail@cdy.org>
Message-ID: <13426df10706051051y3ae84f5cw2cf061502dbbb4c4@mail.gmail.com>

Peter, will do another patch with your comments taken into account.

There are bugs anyway.

thanks

ron



From stuge-linuxbios at cdy.org  Tue Jun  5 19:56:10 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 5 Jun 2007 19:56:10 +0200
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux
	compatable	BIOS programmer ?]
In-Reply-To: <20070604184256.GA7451@skynet.be>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<200508130547.j7D5l8D30326@ecstasy1.winternet.com>
	<42FF0E53.4010902@linuxmachines.com>
	<200508151056.38490.p.millar@physics.gla.ac.uk>
	<4300973D.4020601@linuxmachines.com>
	<1180812548.8397.30.camel@ragnarok>
	<20070604153938.32310.qmail@cdy.org>
	<20070604184256.GA7451@skynet.be>
Message-ID: <20070605175610.23148.qmail@cdy.org>

On Mon, Jun 04, 2007 at 08:42:56PM +0200, Luc Verhaegen wrote:
> On Mon, Jun 04, 2007 at 05:39:37PM +0200, Peter Stuge wrote:
> > On Sat, Jun 02, 2007 at 03:29:08PM -0400, Jeremy Jackson wrote:
> > > Sorry to jump in a bit late here, but for parallel flash, what
> > > about using a NIC with a boot ROM socket?  I've used that for
> > > both PLCC32 and DIP32 parts.
> > 
> > Sorry - what are you suggesting? :)
> 
> Well, this is just for flashrom i think, you only tend to run
> flashrom when running an operating system :)
> 
> This is a good idea, and somebody on irc recently brought it up (too?).  

Ah yes, for flashing chips! Great idea!


> ctflasher has some (oddly licensed) code to this end, and there is
> no need to copy this code, as the actual functionality is limited
> to knowing which BAR to use and what offset address. ctflasher and
> author should of course be mentioned for good measure.
> 
> Now, the code in there is for:
> * via rhine
> * 3com vortex
> * those intel 100base cards
> * those common realtek chips.

A good start I think.


> Also, implementation wise, we might want flashrom to take in a
> pcitag for this sort of flashing to be enabled. This is a
> reasonably idiot proof solution as to not accidentally flash the
> wrong rom to the wrong place.

Mh. I would prefer to probe and do something sane by default.

Of course -w is always required to actually write.

For disambiguating if there are several PCI devices that could be
used to flash I think as you say -p is a good idea.

I guess the ISA bridge is one of them too.

flashrom should list the PCI devices it sees that can be used to
flash.


//Peter



From andi.mundt at web.de  Tue Jun  5 20:19:26 2007
From: andi.mundt at web.de (Andreas B. Mundt)
Date: Tue, 5 Jun 2007 20:19:26 +0200
Subject: [LinuxBIOS] trying to boot Gigabyte M575SLI
In-Reply-To: <20070605172315.16916.qmail@cdy.org>
References: <20070601144106.GA5671@flashgordon>
	<20070601151455.GA7454@countzero.vandewege.net>
	<20070604155851.4065.qmail@cdy.org>
	<20070604233603.GA3421@flashgordon>
	<20070605004521.27823.qmail@cdy.org>
	<20070605062954.GA3602@flashgordon>
	<20070605094623.14347.qmail@cdy.org>
	<20070605122518.GA18101@coresystems.de>
	<20070605160403.GA3927@siddhartha.sunshine>
	<20070605172315.16916.qmail@cdy.org>
Message-ID: <20070605181925.GA3641@flashgordon>

So, here now the booting with standard filo (just the delay(1) patched)
which works fine and the completely patched filo (same Config).
Unfortunately the initrd is not found in the later case :(  

Thanks,

	Andi

standard filo:
=============================
LinuxBIOS-2.0.0_m57sli_Fallback Tue Jun  5 19:38:44 CEST 2007 starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
core0 started: 
started ap apicid:  01
SBLink=00
NC node|link=00
begin msr fid, vid 3107121207110202
set fid failed for apicid =00
end   msr fid, vid 3107120707110210
mcp55_num:01
ht reset -


LinuxBIOS-2.0.0_m57sli_Fallback Tue Jun  5 19:38:44 CEST 2007 starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
core0 started: 
started ap apicid:  01
SBLink=00
NC node|link=00
begin msr fid, vid 3107120707110210
set fid failed for apicid =00
end   msr fid, vid 3107120707110210
mcp55_num:01
Ram1.00
Ram2.00
Unbuffered
333Mhz
Interleaved
RAM: 0x00400000 KB
Ram3
	dimm_mask = 00000033
	x4_mask = 00000000
	x16_mask = 00000000
	single_rank_mask = 00000000
	ODC = 00111322
	Addr Timing= 002b2220
Initializing memory:  done
RAM: 0x00500000 KB
Setting variable MTRR 2, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 3, base: 2048MB, range: 1024MB, type WB
set DQS timing:RcvrEn:Pass1: 00 CTLRMaxDelay=13 done
set DQS timing:DQSPos: 00 done
set DQS timing:RcvrEn:Pass2: 00 CTLRMaxDelay=34 done
Total DQS Training : tsc [00]=00000000459aab84
Total DQS Training : tsc [01]=000000004753ffde
Total DQS Training : tsc [02]=000000009cc8465f
Total DQS Training : tsc [03]=000000009f127ae6
Ram4
v_esp=000cee78
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: Done
Copying LinuxBIOS to RAM.
src=fffdf000
dst=00100000
linxbios_ram.nrv2b length = 0000d634
linxbios_ram.bin   length = 00022510
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0_m57sli_Fallback Tue Jun  5 19:38:44 CEST 2007 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: pci_scan_bus for bus 00
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:00.0 [10de/0369] enabled
PCI: 00:00.0 [10de/0369] enabled next_unitid: 0010
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [10de/0369] enabled
PCI: 00:01.0 [10de/0360] enabled
PCI: 00:01.1 [10de/0368] enabled
PCI: 00:01.2 [10de/036a] enabled
PCI: 00:01.3 [10de/036b] enabled
PCI: 00:02.0 [10de/036c] enabled
PCI: 00:02.1 [10de/036d] enabled
PCI: 00:04.0 [10de/036e] enabled
PCI: 00:05.0 [10de/037f] enabled
PCI: 00:05.1 [10de/037f] enabled
PCI: 00:05.2 [10de/037f] enabled
PCI: 00:06.0 [10de/0370] enabled
PCI: 00:06.1 [10de/0371] enabled
PCI: 00:08.0 [10de/0373] enabled
PCI: 00:0a.0 [10de/0376] enabled
PCI: 00:0b.0 [10de/0374] enabled
PCI: 00:0c.0 [10de/0374] enabled
PCI: 00:0d.0 [10de/0378] enabled
PCI: 00:0e.0 [10de/0375] enabled
PCI: 00:0f.0 [10de/0377] enabled
PNP: 002e.0 disabled
PNP: 002e.1 enabled
PNP: 002e.2 disabled
PNP: 002e.3 disabled
PNP: 002e.4 enabled
PNP: 002e.5 enabled
PNP: 002e.6 enabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
smbus: PCI: 00:01.1[0]->I2C: 01:50 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:51 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:52 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:53 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:54 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:55 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:56 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:57 enabled
smbus: PCI: 00:01.1[1]->I2C: 02:51 enabled
PCI: pci_scan_bus for bus 01
PCI: pci_scan_bus returning with max=001
PCI: pci_scan_bus for bus 02
PCI: pci_scan_bus returning with max=002
PCI: pci_scan_bus for bus 03
PCI: pci_scan_bus returning with max=003
PCI: pci_scan_bus for bus 04
PCI: pci_scan_bus returning with max=004
PCI: pci_scan_bus for bus 05
PCI: pci_scan_bus returning with max=005
PCI: pci_scan_bus for bus 06
PCI: pci_scan_bus returning with max=006
PCI: pci_scan_bus for bus 07
PCI: 07:00.0 [10de/0392] enabled
PCI: pci_scan_bus returning with max=007
PCI: pci_scan_bus returning with max=007
PCI: pci_scan_bus returning with max=007
done
Allocating resources...
Reading resources...
PCI: 00:06.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io
PCI: 00:06.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem
PCI: 00:06.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 01 mem
PCI: 00:0a.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 02 io
PCI: 00:0a.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 02 prefmem
PCI: 00:0a.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 02 mem
PCI: 00:0b.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 03 io
PCI: 00:0b.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 03 prefmem
PCI: 00:0b.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 03 mem
PCI: 00:0c.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 04 io
PCI: 00:0c.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 04 prefmem
PCI: 00:0c.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 04 mem
PCI: 00:0d.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 05 io
PCI: 00:0d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 05 prefmem
PCI: 00:0d.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 05 mem
PCI: 00:0e.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 06 io
PCI: 00:0e.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 06 prefmem
PCI: 00:0e.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 06 mem
Done reading resources.
Allocating VGA resource PCI: 07:00.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:0f.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
VGA: PCI: 00:18.0 (aka node 0) link 0 has VGA device
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0>
PCI: 00:18.0 1b8 <- [0x00e0000000 - 0x00efffffff] prefmem <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00f4000000 - 0x00f61fffff] mem <node 0 link 0>
PCI: 00:01.0 14 <- [0x00f6144000 - 0x00f6144fff] mem
PNP: 002e.1 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.1 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.4 60 <- [0x0000000290 - 0x0000000297] io
PNP: 002e.4 62 <- [0x0000000230 - 0x0000000237] io
PNP: 002e.4 70 <- [0x0000000009 - 0x0000000009] irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.6 70 <- [0x000000000c - 0x000000000c] irq
PCI: 00:01.1 10 <- [0x0000002c00 - 0x0000002c3f] io
PCI: 00:01.1 20 <- [0x0000002c40 - 0x0000002c7f] io
PCI: 00:01.1 24 <- [0x0000002c80 - 0x0000002cbf] io
PCI: 00:01.1 60 <- [0x0000002000 - 0x00000020ff] io
PCI: 00:01.1 64 <- [0x0000002400 - 0x00000024ff] io
PCI: 00:01.1 68 <- [0x0000002800 - 0x00000028ff] io
PCI: 00:01.3 10 <- [0x00f6100000 - 0x00f613ffff] mem
PCI: 00:02.0 10 <- [0x00f6145000 - 0x00f6145fff] mem
PCI: 00:02.1 10 <- [0x00f614a000 - 0x00f614a0ff] mem
PCI: 00:04.0 20 <- [0x0000002cc0 - 0x0000002ccf] io
PCI: 00:05.0 10 <- [0x0000003000 - 0x0000003007] io
PCI: 00:05.0 14 <- [0x0000003070 - 0x0000003073] io
PCI: 00:05.0 18 <- [0x0000003010 - 0x0000003017] io
PCI: 00:05.0 1c <- [0x0000003080 - 0x0000003083] io
PCI: 00:05.0 20 <- [0x0000002cd0 - 0x0000002cdf] io
PCI: 00:05.0 24 <- [0x00f6146000 - 0x00f6146fff] mem
PCI: 00:05.1 10 <- [0x0000003020 - 0x0000003027] io
PCI: 00:05.1 14 <- [0x0000003090 - 0x0000003093] io
PCI: 00:05.1 18 <- [0x0000003030 - 0x0000003037] io
PCI: 00:05.1 1c <- [0x00000030a0 - 0x00000030a3] io
PCI: 00:05.1 20 <- [0x0000002ce0 - 0x0000002cef] io
PCI: 00:05.1 24 <- [0x00f6147000 - 0x00f6147fff] mem
PCI: 00:05.2 10 <- [0x0000003040 - 0x0000003047] io
PCI: 00:05.2 14 <- [0x00000030b0 - 0x00000030b3] io
PCI: 00:05.2 18 <- [0x0000003050 - 0x0000003057] io
PCI: 00:05.2 1c <- [0x00000030c0 - 0x00000030c3] io
PCI: 00:05.2 20 <- [0x0000002cf0 - 0x0000002cff] io
PCI: 00:05.2 24 <- [0x00f6148000 - 0x00f6148fff] mem
PCI: 00:06.1 10 <- [0x00f6140000 - 0x00f6143fff] mem
PCI: 00:08.0 10 <- [0x00f6149000 - 0x00f6149fff] mem
PCI: 00:08.0 14 <- [0x0000003060 - 0x0000003067] io
PCI: 00:08.0 18 <- [0x00f614b000 - 0x00f614b0ff] mem
PCI: 00:08.0 1c <- [0x00f614c000 - 0x00f614c00f] mem
PCI: 00:0f.0 1c <- [0x0000001000 - 0x0000001fff] bus 07 io
PCI: 00:0f.0 24 <- [0x00e0000000 - 0x00efffffff] bus 07 prefmem
PCI: 00:0f.0 20 <- [0x00f4000000 - 0x00f60fffff] bus 07 mem
PCI: 07:00.0 10 <- [0x00f4000000 - 0x00f4ffffff] mem
PCI: 07:00.0 14 <- [0x00e0000000 - 0x00efffffff] prefmem64
PCI: 07:00.0 1c <- [0x00f5000000 - 0x00f5ffffff] mem64
PCI: 07:00.0 24 <- [0x0000001000 - 0x000000107f] io
PCI: 07:00.0 30 <- [0x00f6000000 - 0x00f601ffff] romem
PCI: 00:18.3 94 <- [0x00f0000000 - 0x00f3ffffff] mem <gart>
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:18.0 cmd <- 140
PCI: 00:00.0 subsystem <- 1022/2b80
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 subsystem <- 1022/2b80
PCI: 00:01.0 cmd <- 14f
mcp55 lpc decode:PNP: 002e.1, base=0x000003f8, end=0x000003ff
mcp55 lpc decode:PNP: 002e.4, base=0x00000290, end=0x00000297
mcp55 lpc decode:PNP: 002e.4, base=0x00000230, end=0x00000237
mcp55 lpc decode:PNP: 002e.5, base=0x00000060, end=0x00000060
mcp55 lpc decode:PNP: 002e.5, base=0x00000064, end=0x00000064
PCI: 00:01.1 subsystem <- 1022/2b80
PCI: 00:01.1 cmd <- 141
PCI: 00:01.2 cmd <- 540
PCI: 00:01.3 cmd <- 142
PCI: 00:02.0 subsystem <- 1022/2b80
PCI: 00:02.0 cmd <- 142
PCI: 00:02.1 subsystem <- 1022/2b80
PCI: 00:02.1 cmd <- 142
PCI: 00:04.0 subsystem <- 1022/2b80
PCI: 00:04.0 cmd <- 141
PCI: 00:05.0 subsystem <- 1022/2b80
PCI: 00:05.0 cmd <- 143
PCI: 00:05.1 subsystem <- 1022/2b80
PCI: 00:05.1 cmd <- 143
PCI: 00:05.2 subsystem <- 1022/2b80
PCI: 00:05.2 cmd <- 143
PCI: 00:06.0 bridge ctrl <- 0a03
PCI: 00:06.0 cmd <- 144
PCI: 00:06.1 subsystem <- 1022/2b80
PCI: 00:06.1 cmd <- 142
PCI: 00:08.0 subsystem <- 1022/2b80
PCI: 00:08.0 cmd <- 143
PCI: 00:0a.0 bridge ctrl <- 0003
PCI: 00:0a.0 cmd <- 140
PCI: 00:0b.0 bridge ctrl <- 0003
PCI: 00:0b.0 cmd <- 140
PCI: 00:0c.0 bridge ctrl <- 0003
PCI: 00:0c.0 cmd <- 140
PCI: 00:0d.0 bridge ctrl <- 0003
PCI: 00:0d.0 cmd <- 140
PCI: 00:0e.0 bridge ctrl <- 0003
PCI: 00:0e.0 cmd <- 140
PCI: 00:0f.0 bridge ctrl <- 000b
PCI: 00:0f.0 cmd <- 147
PCI: 07:00.0 cmd <- 143
PCI: 00:18.1 subsystem <- 1022/2b80
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 1022/2b80
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
start_eip=0x00006000, offset=0x00110000, code_size=0x0000005b
Initializing CPU #0
CPU: vendor AMD device 60fb1
CPU: family 0f, model 6b, stepping 01
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

CPU model AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
Setting up local apic... apic_id: 0x00 done.
ECC Disabled
CPU #0 Initialized
Initializing CPU #1
Waiting for 1 CPUS to stop
CPU: vendor AMD device 60fb1
CPU: family 0f, model 6b, stepping 01
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

CPU model AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
Setting up local apic... apic_id: 0x01 done.
CPU #1 Initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 00:01.0 init
set power on after power fail
RTC Init
RTC: Checksum invalid zeroing cmos
Invalid CMOS LB checksum
PNP: 002e.1 init
PNP: 002e.4 init
FAN_CTL: reg = 0x02a9, read value = 0x50
FAN_CTL: reg = 0x02a9, writing value = 0xd7
PNP: 002e.5 init
PNP: 002e.6 init
PCI: 00:01.1 init
PCI: 00:02.1 init
PCI: 00:04.0 init
IDE0
PCI: 00:05.0 init
SATA S 	SATA P 
PCI: 00:05.1 init
SATA S 	SATA P 
PCI: 00:05.2 init
SATA S 	SATA P 
PCI: 00:06.0 init
dev_root mem base = 0x00e0000000
[0x50] <-- 0xe0000000
PCI: 00:06.1 init
base = f6140000
codec_mask = 01
codec viddid: 10ec0883
No verb!
PCI: 00:08.0 init
MCP55 MAC PHY ID 0x01410c00 PHY ADDR 1
PCI: 00:0a.0 init
PCI: 00:0b.0 init
PCI: 00:0c.0 init
PCI: 00:0d.0 init
PCI: 00:0e.0 init
PCI: 00:0f.0 init
PCI: 00:18.1 init
PCI: 00:18.2 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:01.2 init
PCI: 00:01.3 init
PCI: 07:00.0 init
rom address for PCI: 07:00.0 = f6000000
copying VGA ROM Image from 0xf6000000 to 0xc0000, 0xf600 bytes
entering emulator
halt_sys: file /home/andi/freeBIOS/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 00000274
Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000 
Adjust rom_table_end from 0x000f0400 to 0x00100000 
Wrote linuxbios table at: 00000530 - 00000dd4  checksum 5c17

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

rom_stream: 0xfffc0000 - 0xfffdefff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
New segment addr 0x100000 size 0x30700 offset 0xc0 filesize 0xb268
(cleaned up) New segment addr 0x100000 size 0x30700 offset 0xc0 filesize 0xb268
New segment addr 0x130700 size 0x48 offset 0xb340 filesize 0x48
(cleaned up) New segment addr 0x130700 size 0x48 offset 0xb340 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x00000000bff80000 memsz: 0x0000000000030700 filesz: 0x000000000000b268
Clearing Segment: addr: 0x00000000bff8b268 memsz: 0x0000000000025498
Loading Segment: addr: 0x00000000bffb0700 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x108e64
FILO version 0.5 (andi at flashgordon) Tue Jun  5 19:36:25 CEST 2007
setup_timers: CPU 2400 MHz
Press <Enter> for default boot, or <Esc> for boot prompt... 5 4 3 2 1 timed out
boot: hde5:/vmlinuz initrd=hde5:/boot/initrd.img-2.6.21-1-amd64 root=/dev/sda2 ro console=ttyS0,115200
find_ide_controller: found PCI IDE controller 10de:037f prog_if=0x85
find_ide_controller: primary channel: native PCI mode
find_ide_controller: cmd_base=0x3000 ctrl_base=0x3070
ide_software_reset: Waiting for ide2 to become ready for reset... ok
init_drive: Testing for hde
init_drive: Probing for hde
init_drive: LBA mode, sectors=268435455
init_drive: LBA48 mode, sectors=488395055
init_drive: Init device params... ok
hde: LBA48 250GB: SAMSUNG SP2504C                         
init_drive: Testing for hdf
init_drive: Probing for hdf
print_status: IDE: status=0x0, err=0x0
init_drive: Testing for hdf
init_drive: Probing for hdf
print_status: IDE: status=0x0, err=0x0
Mounted ext2fs
Found Linux version 2.6.21-1-amd64 (unknown at Debian) #1 SMP Fri May 18 23:28:21 CEST 2007 bzImage.
Loading kernel... ok
Loading initrd... ok
Jumping to entry point...
Linux version 2.6.21-1-amd64 (Debian 2.6.21-2) (waldi at debian.org) (gcc version 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)) #1 SMP Fri May 18 23:28:21 CEST 2007
Command line: root=/dev/sda2 ro console=ttyS0,115200
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000c0000 - 00000000000f0000 (usable)
 BIOS-e820: 0000000000100000 - 00000000c0000000 (usable)
 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
end_pfn_map = 1310720
DMI not present or invalid.
Scanning NUMA topology in Northbridge 24
Number of nodes 1
Node 0 MemBase 0000000000000000 Limit 0000000140000000
Using node hash shift of 63
Bootmem setup node 0 0000000000000000-0000000140000000
Zone PFN ranges:
  DMA             1 ->     4096
  DMA32        4096 ->  1048576
  Normal    1048576 ->  1310720
early_node_map[4] active PFN ranges
    0:        1 ->      160
    0:      192 ->      240
    0:      256 ->   786432
    0:  1048576 ->  1310720
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
Intel MultiProcessor Specification v1.4
MPTABLE: OEM ID: GIGABYTE MPTABLE: Product ID: M57SLI       MPTABLE: APIC at: 0xFEE00000
Processor #0 (Bootup-CPU)
Processor #1
I/O APIC #2 at 0xF6144000.
Setting APIC routing to physical flat
Processors: 2
Nosave address range: 00000000000a0000 - 00000000000c0000
Nosave address range: 00000000000f0000 - 0000000000100000
Nosave address range: 00000000c0000000 - 0000000100000000
Allocating PCI resources starting at c4000000 (gap: c0000000:40000000)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 37504 bytes of per cpu data
Built 1 zonelists.  Total pages: 1029631
Kernel command line: root=/dev/sda2 ro console=ttyS0,115200
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
time.c: Detected 2400.010 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking aperture...
CPU 0: aperture @ f0000000 size 64 MB
Memory: 4106608k/5242880k available (1975k kernel code, 87500k reserved, 931k data, 296k init)
Calibrating delay using timer specific routine.. 4803.89 BogoMIPS (lpj=9607797)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0/0 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives: switching to UP code
ACPI: Core revision 20070126
ACPI Exception (tbxface-0618): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables [20070126]
ACPI: Unable to load the System Description Tables
Using local APIC timer interrupts.
result 12500064
Detected 12.500 MHz APIC timer.
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1
Calibrating delay using timer specific routine.. 4800.35 BogoMIPS (lpj=9600704)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1/1 -> Node 0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ stepping 01
Brought up 2 CPUs
migration_cost=203
NET: Registered protocol family 16
PCI: Using configuration type 1
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Using IRQ router default [10de/0370] at 0000:00:06.0
PCI->APIC IRQ transform: 0000:00:01.1[A] -> IRQ 10
PCI->APIC IRQ transform: 0000:00:01.3[B] -> IRQ 10
PCI->APIC IRQ transform: 0000:00:02.0[A] -> IRQ 22
PCI->APIC IRQ transform: 0000:00:02.1[B] -> IRQ 23
PCI->APIC IRQ transform: 0000:00:05.0[A] -> IRQ 20
PCI->APIC IRQ transform: 0000:00:05.1[B] -> IRQ 23
PCI->APIC IRQ transform: 0000:00:05.2[C] -> IRQ 21
PCI->APIC IRQ transform: 0000:00:06.1[B] -> IRQ 23
PCI->APIC IRQ transform: 0000:00:08.0[A] -> IRQ 22
PCI->APIC IRQ transform: 0000:07:00.0[A] -> IRQ 17
NET: Registered protocol family 8
NET: Registered protocol family 20
PCI-DMA: Disabling AGP.
PCI-DMA: aperture base @ f0000000 size 65536 KB
PCI-DMA: using GART IOMMU.
PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
PCI: Bridge: 0000:00:06.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0a.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0b.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0f.0
  IO window: 1000-1fff
  MEM window: f4000000-f60fffff
  PREFETCH window: e0000000-efffffff
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 131072 (order: 9, 3145728 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 5507k freed
audit: initializing netlink socket (disabled)
audit(1181065315.696:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
assign_interrupt_mode Found MSI capability
Real Time Clock Driver v1.12ac
Linux agpgart interface v0.102 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: 296k freed
Loading, please wait...
input: AT Translated Set 2 keyboard as /class/input/input0
Begin: Loading essential drivers... ...
Done.
Begin: Running /scripts/init-premount ...
FATAL: Error inserting fan (/lib/modules/2.6.21-1-amd64/kernel/drivers/acpi/fan.ko): No such device
WARNING: Error ithermal: Unknown symbol acpi_processor_set_thermal_limit
nserting processor (/lib/modules/2.6.21-1-amd64/kernel/drivers/acpi/processor.ko): No such device
FATAL: Error inserting thermal (/lib/modules/2.6.21-1-amd64/kernel/drivers/acpi/thermal.ko): Unknown symbol in module, or unknown parameter (see dmesg)
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:02.0: irq 22, io mem 0xf6145000
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.60.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 10 ports detected
ehci_hcd 0000:00:02.1: EHCI Host Controller
ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
ehci_hcd 0000:00:02.1: debug port 1
ehci_hcd 0000:00:02.1: irq 23, io mem 0xf614a000
ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 10 ports detected
NFORCE-MCP55: IDE controller at PCI slot 0000:00:04.0
NFORCE-MCP55: chipset revision 161
NFORCE-MCP55: not 100% native mode: will probe irqs later
NFORCE-MCP55: 0000:00:04.0 (rev a1) UDMA133 controller
    ide0: BM-DMA at 0x2cc0-0x2cc7, BIOS settings: hda:pio, hdb:pio
hda: Optiarc DVD RW AD-7173A, ATAPI CD/DVD-ROM drive
usb 1-2: new low speed USB device using ohci_hcd and address 2
usb 1-2: configuration #1 chosen from 1 choice
usbcore: registered new interface driver hiddev
input: HID 1241:1166 as /class/input/input1
input: USB HID v1.00 Mouse [HID 1241:1166] on usb-0000:00:02.0-2
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
SCSI subsystem initialized
forcedeth: using HIGHDMA
eth0: forcedeth.c: subsystem: 01022:2b80 bound to 0000:00:08.0
ata1: SATA max UDMA/133 cmd 0x0000000000013000 ctl 0x0000000000013072 bmdma 0x0000000000012cd0 irq 20
ata2: SATA max UDMA/133 cmd 0x0000000000013010 ctl 0x0000000000013082 bmdma 0x0000000000012cd8 irq 20
scsi0 : sata_nv
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7: SAMSUNG SP2504C, VT100-50, max UDMA7
ata1.00: 488395055 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/133
scsi1 : sata_nv
ata2: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x0000000000013017
scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG SP2504C  VT10 PQ: 0 ANSI: 5
ata3: SATA max UDMA/133 cmd 0x0000000000013020 ctl 0x0000000000013092 bmdma 0x0000000000012ce0 irq 23
ata4: SATA max UDMA/133 cmd 0x0000000000013030 ctl 0x00000000000130a2 bmdma 0x0000000000012ce8 irq 23
scsi2 : sata_nv
ata3: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x0000000000013027
scsi3 : sata_nv
ata4: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x0000000000013037
ata5: SATA max UDMA/133 cmd 0x0000000000013040 ctl 0x00000000000130b2 bmdma 0x0000000000012cf0 irq 21
ata6: SATA max UDMA/133 cmd 0x0000000000013050 ctl 0x00000000000130c2 bmdma 0x0000000000012cf8 irq 21
scsi4 : sata_nv
ata5: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x0000000000013047
scsi5 : sata_nv
ata6: SATA link down (SStatus 0 SControl 300)
ATA: abnormal status 0x7F on port 0x0000000000013057
SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB)
sda: Write Protect is off
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
SCSI device sda: 488395055 512-byte hdwr sectors (250058 MB)
sda: Write Protect is off
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3 sda4 <<6>hda: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
 sda5 >
sd 0:0:0:0: Attached scsi disk sda
Done.
Begin: Mounting root file system... ...
Begin: Running /scripts/local-top ...
Done.
Begin: Running /scripts/local-premount ...
kinit: name_to_dAttempting manual resume
ev_t(/dev/sda1) = sda1(8,1)
kinit: trying to resume from /dev/sda1
kinit: No resume image, doing normal boot...
Done.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Begin: Running /scripts/local-bottom ...
Done.
Done.
Begin: Running /scripts/init-bottom ...
Done.
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...i2c_adapter i2c-0: nForce2 SMBus adapter at 0x2c40
i2c_adapter i2c-1: nForce2 SMBus adapter at 0x2c80
input: PC Speaker as /class/input/input2
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...
done.
GActivating swap...Adding 7815580k swap on /dev/sda1.  Priority:-1 extents:1 across:7815580k
done.
Checking root file system...fsck 1.40-WIP (14-Nov-2006)
/dev/sda2: clean, 170121/2443200 files, 1253024/EXT3 FS on sda2, 4883760 blocks
internal journal
done.
Setting the system clock..
Cleaning up ifupdown....
Loading kernel modules...loop: loaded (max 8 devices)
powernow_k8: Unknown symbol acpi_processor_notify_smm
powernow_k8: Unknown symbol acpi_processor_unregister_performance
powernow_k8: Unknown symbol acpi_processor_register_performance
it87: Found IT8716F chip at 0x290, revision 0
it87: in3 is VCC (+5V)
it87: in7 is VCCH (+5V Stand-By)
done.
Loading device-mapper supportdevice-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel at redhat.com
.
Checking file systems...fsck 1.40-WIP (14-Nov-2006)
/dev/sda3: clean, 14349/4889248 files, 238250/9765511 blocks
/dev/sda5: clean, 28584/1281696 files, 207922/2560351 blocks (check after next mount)
done.
Setting kernel variables...done.
Mounting local filesystems...kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
done.
Activating swapfile swap...done.
Detecting hardware...Setting up networking....
Configuring network interfaces...done.
Starting portmap daemon....
Setting sensors limits: done.
Setting console screen modes and fonts.
RSetting console screen modes and fonts.
Setting up ALSA...done.
INIT: Entering runlevel: 2
Starting system log daemon....
Starting kernel log daemon....
Starting virtual private network daemon:.
Starting portmap daemon...Already running..
Starting HP Linux Printing and Imaging System: hpiod hpssd.
Starting BitTorrent tracker: disabled in /etc/default/bittorrent.
Starting console-log:Couldnt get a file descriptor referring to the console
E: openvt failed. headless system?...failed.
Starting Common Unix Printing System: cupsdlp: driver loaded but no devices found
ppdev: user-space parallel port driver
.
Starting system message bus: dbus.
Starting network connection manager: NetworkManager.
Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
Starting network events dispatcher: NetworkManagerDispatcher.
Starting DirMngr: dirmngr.
Starting MTA: exim4.
Starting LAN Information Server: lisa.
Starting internet superserver: inetd.
Starting powernowd: required sysfs objects not found!
	Read /usr/share/doc/powernowd/README.Debian for more information.
Starting OpenBSD Secure Shell server: sshdNET: Registered protocol family 10
lo: Disabled Privacy Extensions
.
Starting file alteration monitor: FAM.
Starting GNOME Display Manager: gdm.
Starting NFS common utilities: statd.
Starting NTP server: ntpd.
Starting DHCP D-Bus daemon: dhcdbdmtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
.
Starting Hardware abstraction layer: hald.
Starting anac(h)ronistic cron: anacron.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler: crond.
Not starting K Display Manager (kdm); it is not the default display manager.
mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
==============================
==============================


fast filo:


==============================
LinuxBIOS-2.0.0_m57sli_Fallback Tue Jun  5 19:47:22 CEST 2007 starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
core0 started: 
started ap apicid:  01
SBLink=00
NC node|link=00
begin msr fid, vid 3107121207110202
set fid failed for apicid =00
end   msr fid, vid 3107120707110210
mcp55_num:01
ht reset -


LinuxBIOS-2.0.0_m57sli_Fallback Tue Jun  5 19:47:22 CEST 2007 starting...
*sysinfo range: [000cf000,000cf730)
bsp_apicid=00
core0 started: 
started ap apicid:  01
SBLink=00
NC node|link=00
begin msr fid, vid 3107120707110210
set fid failed for apicid =00
end   msr fid, vid 3107120707110210
mcp55_num:01
Ram1.00
Ram2.00
Unbuffered
333Mhz
Interleaved
RAM: 0x00400000 KB
Ram3
	dimm_mask = 00000033
	x4_mask = 00000000
	x16_mask = 00000000
	single_rank_mask = 00000000
	ODC = 00111322
	Addr Timing= 002b2220
Initializing memory:  done
RAM: 0x00500000 KB
Setting variable MTRR 2, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 3, base: 2048MB, range: 1024MB, type WB
set DQS timing:RcvrEn:Pass1: 00 CTLRMaxDelay=14 done
set DQS timing:DQSPos: 00 done
set DQS timing:RcvrEn:Pass2: 00 CTLRMaxDelay=34 done
Total DQS Training : tsc [00]=00000000459a078a
Total DQS Training : tsc [01]=000000004754aa55
Total DQS Training : tsc [02]=0000000094ce9001
Total DQS Training : tsc [03]=00000000971778f5
Ram4
v_esp=000cee78
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: Done
Copying LinuxBIOS to RAM.
src=fffdf000
dst=00100000
linxbios_ram.nrv2b length = 0000d634
linxbios_ram.bin   length = 00022510
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0_m57sli_Fallback Tue Jun  5 19:47:22 CEST 2007 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: pci_scan_bus for bus 00
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:00.0 [10de/0369] enabled
PCI: 00:00.0 [10de/0369] enabled next_unitid: 0010
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [10de/0369] enabled
PCI: 00:01.0 [10de/0360] enabled
PCI: 00:01.1 [10de/0368] enabled
PCI: 00:01.2 [10de/036a] enabled
PCI: 00:01.3 [10de/036b] enabled
PCI: 00:02.0 [10de/036c] enabled
PCI: 00:02.1 [10de/036d] enabled
PCI: 00:04.0 [10de/036e] enabled
PCI: 00:05.0 [10de/037f] enabled
PCI: 00:05.1 [10de/037f] enabled
PCI: 00:05.2 [10de/037f] enabled
PCI: 00:06.0 [10de/0370] enabled
PCI: 00:06.1 [10de/0371] enabled
PCI: 00:08.0 [10de/0373] enabled
PCI: 00:0a.0 [10de/0376] enabled
PCI: 00:0b.0 [10de/0374] enabled
PCI: 00:0c.0 [10de/0374] enabled
PCI: 00:0d.0 [10de/0378] enabled
PCI: 00:0e.0 [10de/0375] enabled
PCI: 00:0f.0 [10de/0377] enabled
PNP: 002e.0 disabled
PNP: 002e.1 enabled
PNP: 002e.2 disabled
PNP: 002e.3 disabled
PNP: 002e.4 enabled
PNP: 002e.5 enabled
PNP: 002e.6 enabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
smbus: PCI: 00:01.1[0]->I2C: 01:50 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:51 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:52 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:53 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:54 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:55 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:56 enabled
smbus: PCI: 00:01.1[0]->I2C: 01:57 enabled
smbus: PCI: 00:01.1[1]->I2C: 02:51 enabled
PCI: pci_scan_bus for bus 01
PCI: pci_scan_bus returning with max=001
PCI: pci_scan_bus for bus 02
PCI: pci_scan_bus returning with max=002
PCI: pci_scan_bus for bus 03
PCI: pci_scan_bus returning with max=003
PCI: pci_scan_bus for bus 04
PCI: pci_scan_bus returning with max=004
PCI: pci_scan_bus for bus 05
PCI: pci_scan_bus returning with max=005
PCI: pci_scan_bus for bus 06
PCI: pci_scan_bus returning with max=006
PCI: pci_scan_bus for bus 07
PCI: 07:00.0 [10de/0392] enabled
PCI: pci_scan_bus returning with max=007
PCI: pci_scan_bus returning with max=007
PCI: pci_scan_bus returning with max=007
done
Allocating resources...
Reading resources...
PCI: 00:06.0 1c <- [0x000000f000 - 0x000000efff] bus 01 io
PCI: 00:06.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 01 prefmem
PCI: 00:06.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 01 mem
PCI: 00:0a.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 02 io
PCI: 00:0a.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 02 prefmem
PCI: 00:0a.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 02 mem
PCI: 00:0b.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 03 io
PCI: 00:0b.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 03 prefmem
PCI: 00:0b.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 03 mem
PCI: 00:0c.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 04 io
PCI: 00:0c.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 04 prefmem
PCI: 00:0c.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 04 mem
PCI: 00:0d.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 05 io
PCI: 00:0d.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 05 prefmem
PCI: 00:0d.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 05 mem
PCI: 00:0e.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 06 io
PCI: 00:0e.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 06 prefmem
PCI: 00:0e.0 20 <- [0x00fff00000 - 0x00ffefffff] bus 06 mem
Done reading resources.
Allocating VGA resource PCI: 07:00.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:0f.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:18.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
VGA: PCI: 00:18.0 (aka node 0) link 0 has VGA device
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000003fff] io <node 0 link 0>
PCI: 00:18.0 1b8 <- [0x00e0000000 - 0x00efffffff] prefmem <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00f4000000 - 0x00f61fffff] mem <node 0 link 0>
PCI: 00:01.0 14 <- [0x00f6144000 - 0x00f6144fff] mem
PNP: 002e.1 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.1 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.4 60 <- [0x0000000290 - 0x0000000297] io
PNP: 002e.4 62 <- [0x0000000230 - 0x0000000237] io
PNP: 002e.4 70 <- [0x0000000009 - 0x0000000009] irq
PNP: 002e.5 60 <- [0x0000000060 - 0x0000000060] io
PNP: 002e.5 62 <- [0x0000000064 - 0x0000000064] io
PNP: 002e.5 70 <- [0x0000000001 - 0x0000000001] irq
PNP: 002e.6 70 <- [0x000000000c - 0x000000000c] irq
PCI: 00:01.1 10 <- [0x0000002c00 - 0x0000002c3f] io
PCI: 00:01.1 20 <- [0x0000002c40 - 0x0000002c7f] io
PCI: 00:01.1 24 <- [0x0000002c80 - 0x0000002cbf] io
PCI: 00:01.1 60 <- [0x0000002000 - 0x00000020ff] io
PCI: 00:01.1 64 <- [0x0000002400 - 0x00000024ff] io
PCI: 00:01.1 68 <- [0x0000002800 - 0x00000028ff] io
PCI: 00:01.3 10 <- [0x00f6100000 - 0x00f613ffff] mem
PCI: 00:02.0 10 <- [0x00f6145000 - 0x00f6145fff] mem
PCI: 00:02.1 10 <- [0x00f614a000 - 0x00f614a0ff] mem
PCI: 00:04.0 20 <- [0x0000002cc0 - 0x0000002ccf] io
PCI: 00:05.0 10 <- [0x0000003000 - 0x0000003007] io
PCI: 00:05.0 14 <- [0x0000003070 - 0x0000003073] io
PCI: 00:05.0 18 <- [0x0000003010 - 0x0000003017] io
PCI: 00:05.0 1c <- [0x0000003080 - 0x0000003083] io
PCI: 00:05.0 20 <- [0x0000002cd0 - 0x0000002cdf] io
PCI: 00:05.0 24 <- [0x00f6146000 - 0x00f6146fff] mem
PCI: 00:05.1 10 <- [0x0000003020 - 0x0000003027] io
PCI: 00:05.1 14 <- [0x0000003090 - 0x0000003093] io
PCI: 00:05.1 18 <- [0x0000003030 - 0x0000003037] io
PCI: 00:05.1 1c <- [0x00000030a0 - 0x00000030a3] io
PCI: 00:05.1 20 <- [0x0000002ce0 - 0x0000002cef] io
PCI: 00:05.1 24 <- [0x00f6147000 - 0x00f6147fff] mem
PCI: 00:05.2 10 <- [0x0000003040 - 0x0000003047] io
PCI: 00:05.2 14 <- [0x00000030b0 - 0x00000030b3] io
PCI: 00:05.2 18 <- [0x0000003050 - 0x0000003057] io
PCI: 00:05.2 1c <- [0x00000030c0 - 0x00000030c3] io
PCI: 00:05.2 20 <- [0x0000002cf0 - 0x0000002cff] io
PCI: 00:05.2 24 <- [0x00f6148000 - 0x00f6148fff] mem
PCI: 00:06.1 10 <- [0x00f6140000 - 0x00f6143fff] mem
PCI: 00:08.0 10 <- [0x00f6149000 - 0x00f6149fff] mem
PCI: 00:08.0 14 <- [0x0000003060 - 0x0000003067] io
PCI: 00:08.0 18 <- [0x00f614b000 - 0x00f614b0ff] mem
PCI: 00:08.0 1c <- [0x00f614c000 - 0x00f614c00f] mem
PCI: 00:0f.0 1c <- [0x0000001000 - 0x0000001fff] bus 07 io
PCI: 00:0f.0 24 <- [0x00e0000000 - 0x00efffffff] bus 07 prefmem
PCI: 00:0f.0 20 <- [0x00f4000000 - 0x00f60fffff] bus 07 mem
PCI: 07:00.0 10 <- [0x00f4000000 - 0x00f4ffffff] mem
PCI: 07:00.0 14 <- [0x00e0000000 - 0x00efffffff] prefmem64
PCI: 07:00.0 1c <- [0x00f5000000 - 0x00f5ffffff] mem64
PCI: 07:00.0 24 <- [0x0000001000 - 0x000000107f] io
PCI: 07:00.0 30 <- [0x00f6000000 - 0x00f601ffff] romem
PCI: 00:18.3 94 <- [0x00f0000000 - 0x00f3ffffff] mem <gart>
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:18.0 cmd <- 140
PCI: 00:00.0 subsystem <- 1022/2b80
PCI: 00:00.0 cmd <- 146
PCI: 00:01.0 subsystem <- 1022/2b80
PCI: 00:01.0 cmd <- 14f
mcp55 lpc decode:PNP: 002e.1, base=0x000003f8, end=0x000003ff
mcp55 lpc decode:PNP: 002e.4, base=0x00000290, end=0x00000297
mcp55 lpc decode:PNP: 002e.4, base=0x00000230, end=0x00000237
mcp55 lpc decode:PNP: 002e.5, base=0x00000060, end=0x00000060
mcp55 lpc decode:PNP: 002e.5, base=0x00000064, end=0x00000064
PCI: 00:01.1 subsystem <- 1022/2b80
PCI: 00:01.1 cmd <- 141
PCI: 00:01.2 cmd <- 540
PCI: 00:01.3 cmd <- 142
PCI: 00:02.0 subsystem <- 1022/2b80
PCI: 00:02.0 cmd <- 142
PCI: 00:02.1 subsystem <- 1022/2b80
PCI: 00:02.1 cmd <- 142
PCI: 00:04.0 subsystem <- 1022/2b80
PCI: 00:04.0 cmd <- 141
PCI: 00:05.0 subsystem <- 1022/2b80
PCI: 00:05.0 cmd <- 143
PCI: 00:05.1 subsystem <- 1022/2b80
PCI: 00:05.1 cmd <- 143
PCI: 00:05.2 subsystem <- 1022/2b80
PCI: 00:05.2 cmd <- 143
PCI: 00:06.0 bridge ctrl <- 0a03
PCI: 00:06.0 cmd <- 144
PCI: 00:06.1 subsystem <- 1022/2b80
PCI: 00:06.1 cmd <- 142
PCI: 00:08.0 subsystem <- 1022/2b80
PCI: 00:08.0 cmd <- 143
PCI: 00:0a.0 bridge ctrl <- 0003
PCI: 00:0a.0 cmd <- 140
PCI: 00:0b.0 bridge ctrl <- 0003
PCI: 00:0b.0 cmd <- 140
PCI: 00:0c.0 bridge ctrl <- 0003
PCI: 00:0c.0 cmd <- 140
PCI: 00:0d.0 bridge ctrl <- 0003
PCI: 00:0d.0 cmd <- 140
PCI: 00:0e.0 bridge ctrl <- 0003
PCI: 00:0e.0 cmd <- 140
PCI: 00:0f.0 bridge ctrl <- 000b
PCI: 00:0f.0 cmd <- 147
PCI: 07:00.0 cmd <- 143
PCI: 00:18.1 subsystem <- 1022/2b80
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 1022/2b80
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
start_eip=0x00006000, offset=0x00110000, code_size=0x0000005b
Initializing CPU #0
CPU: vendor AMD device 60fb1
CPU: family 0f, model 6b, stepping 01
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

CPU model AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
Setting up local apic... apic_id: 0x00 done.
ECC Disabled
CPU #0 Initialized
Initializing CPU #1
Waiting for 1 CPUS to stop
CPU: vendor AMD device 60fb1
CPU: family 0f, model 6b, stepping 01
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

CPU model AMD Athlon(tm) 64 X2 Dual Core Processor 4800+
Setting up local apic... apic_id: 0x01 done.
CPU #1 Initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 00:01.0 init
set power on after power fail
RTC Init
RTC: Checksum invalid zeroing cmos
Invalid CMOS LB checksum
PNP: 002e.1 init
PNP: 002e.4 init
FAN_CTL: reg = 0x02a9, read value = 0x50
FAN_CTL: reg = 0x02a9, writing value = 0xd7
PNP: 002e.5 init
PNP: 002e.6 init
PCI: 00:01.1 init
PCI: 00:02.1 init
PCI: 00:04.0 init
IDE0
PCI: 00:05.0 init
SATA S 	SATA P 
PCI: 00:05.1 init
SATA S 	SATA P 
PCI: 00:05.2 init
SATA S 	SATA P 
PCI: 00:06.0 init
dev_root mem base = 0x00e0000000
[0x50] <-- 0xe0000000
PCI: 00:06.1 init
base = f6140000
codec_mask = 01
codec viddid: 10ec0883
No verb!
PCI: 00:08.0 init
MCP55 MAC PHY ID 0x01410c00 PHY ADDR 1
PCI: 00:0a.0 init
PCI: 00:0b.0 init
PCI: 00:0c.0 init
PCI: 00:0d.0 init
PCI: 00:0e.0 init
PCI: 00:0f.0 init
PCI: 00:18.1 init
PCI: 00:18.2 init
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:01.2 init
PCI: 00:01.3 init
PCI: 07:00.0 init
rom address for PCI: 07:00.0 = f6000000
copying VGA ROM Image from 0xf6000000 to 0xc0000, 0xf600 bytes
entering emulator
halt_sys: file /home/andi/freeBIOS/LinuxBIOSv2/src/devices/emulator/x86emu/ops.c, line 4387
Devices initialized
Writing IRQ routing tables to 0xf0000...done.
Wrote the mp table end at: 00000020 - 00000274
Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000 
Adjust rom_table_end from 0x000f0400 to 0x00100000 
Wrote linuxbios table at: 00000530 - 00000dd4  checksum 601b

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

rom_stream: 0xfffc0000 - 0xfffdefff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
New segment addr 0x100000 size 0x31240 offset 0xc0 filesize 0xbda8
(cleaned up) New segment addr 0x100000 size 0x31240 offset 0xc0 filesize 0xbda8
New segment addr 0x131240 size 0x48 offset 0xbe80 filesize 0x48
(cleaned up) New segment addr 0x131240 size 0x48 offset 0xbe80 filesize 0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x00000000bff80000 memsz: 0x0000000000031240 filesz: 0x000000000000bda8
Clearing Segment: addr: 0x00000000bff8bda8 memsz: 0x0000000000025498
Loading Segment: addr: 0x00000000bffb1240 memsz: 0x0000000000000048 filesz: 0x0000000000000048
Jumping to boot code at 0x109618
FILO version 0.5 (andi at flashgordon) Tue Jun  5 19:45:50 CEST 2007
setup_timers: CPU 2400 MHz
Press <Enter> for default boot, or <Esc> for boot prompt... 5 4 3 2 1 timed out
boot: hde5:/vmlinuz initrd=hde5:/boot/initrd.img-2.6.21-1-amd64 root=/dev/sda2 ro console=ttyS0,115200
find_ide_controller: found PCI IDE controller 10de:037f prog_if=0x85
find_ide_controller: primary channel: native PCI mode
find_ide_controller: cmd_base=0x3000 ctrl_base=0x3070
ide_software_reset: Waiting for ide2 to become ready for reset... ok
init_drive: Testing for hde
init_drive: Probing for hde
init_drive: LBA mode, sectors=268435455
init_drive: LBA48 mode, sectors=488395055
init_drive: Init device params... ok
hde: LBA48 250GB: SAMSUNG SP2504C                         
init_drive: Testing for hdf
init_drive: Probing for hdf
IDE timeout after 50 ms while waiting for drq()
pio_data_in: No DRQ from device after read command
print_status: IDE: status=0x0, err=0x0
init_drive: Testing for hdf
init_drive: Probing for hdf
IDE timeout after 50 ms while waiting for drq()
pio_data_in: No DRQ from device after read command
print_status: IDE: status=0x0, err=0x0
ide_readmany: sector 0 to 0x0010c040
ide_readmany: sector 132825420 to 0x0010d840
ide_readmany: sector 132825485 to 0x0010da40
ide_readmany: sector 132825486 to 0x0010dc40
Mounted ext2fs
ide_readmany: sector 132825491 to 0x0010e640
ide_readmany: sector 132825492 to 0x0010e840
ide_readmany: sector 132825493 to 0x0010ea40
ide_readmany: sector 132825494 to 0x0010ec40
ide_readmany: sector 132825495 to 0x0010ee40
ide_readmany: sector 132825496 to 0x0010f040
ide_readmany: sector 132825497 to 0x0010f240
ide_readmany: sector 132825498 to 0x0010f440
ide_readmany: sector 132825515 to 0x00111640
ide_readmany: sector 132825516 to 0x00111840
ide_readmany: sector 132825517 to 0x00111a40
ide_readmany: sector 132825518 to 0x00111c40
ide_readmany: sector 132825519 to 0x00111e40
ide_readmany: sector 132825520 to 0x00112040
ide_readmany: sector 132825521 to 0x00112240
ide_readmany: sector 132825522 to 0x00112440
ide_readmany: sector 132829571 to 0x0010c640
ide_readmany: sector 132829572 to 0x0010c840
ide_readmany: sector 132829573 to 0x0010ca40
ide_readmany: sector 132829574 to 0x0010cc40
ide_readmany: sector 132829575 to 0x0010ce40
ide_readmany: sector 132829576 to 0x0010d040
ide_readmany: sector 132829577 to 0x0010d240
ide_readmany: sector 132829578 to 0x0010d440
ide_readmany: sector 136233387 to 0x00111640
ide_readmany: sector 136233388 to 0x00111840
ide_readmany: sector 136233389 to 0x00111a40
ide_readmany: sector 136233390 to 0x00111c40
ide_readmany: sector 136233391 to 0x00111e40
ide_readmany: sector 136233392 to 0x00112040
ide_readmany: sector 136233393 to 0x00112240
ide_readmany: sector 136233394 to 0x00112440
ide_readmany: sector 136298891 to 0x0010d640
ide_readmany: sector 136298892 to 0x0010d840
ide_readmany: sector 136298893 to 0x0010da40
ide_readmany: sector 136298894 to 0x0010dc40
ide_readmany: sector 136298895 to 0x0010de40
ide_readmany: sector 136298896 to 0x0010e040
ide_readmany: sector 136298897 to 0x0010e240
ide_readmany: sector 136298898 to 0x0010e440
ext2fs_read_one: block  452608  offset=0 len=52 ret=0
ide_readmany: sector 136446347 to 0x0010d640
ide_readmany: sector 132825515 to 0x00111640
ide_readmany: sector 132825516 to 0x00111840
ide_readmany: sector 132825517 to 0x00111a40
ide_readmany: sector 132825518 to 0x00111c40
ide_readmany: sector 132825519 to 0x00111e40
ide_readmany: sector 132825520 to 0x00112040
ide_readmany: sector 132825521 to 0x00112240
ide_readmany: sector 132825522 to 0x00112440
ide_readmany: sector 136233387 to 0x00111640
ide_readmany: sector 136233388 to 0x00111840
ide_readmany: sector 136233389 to 0x00111a40
ide_readmany: sector 136233390 to 0x00111c40
ide_readmany: sector 136233391 to 0x00111e40
ide_readmany: sector 136233392 to 0x00112040
ide_readmany: sector 136233393 to 0x00112240
ide_readmany: sector 136233394 to 0x00112440
ide_readmany: sector 136298891 to 0x0010d640
ext2fs_read_one: block  452608  offset=0 len=560 ret=0
ide_readmany: sector 136446347 to 0x0010d640
ide_readmany: sector 136446348 to 0x0010d840
Found Linuxblock  452609  offset=1099 len=256 ret=0
ide_readmany: sector 136446357 to 0x0010ea40
 version 2.6.21-1-amd64 (unknown at Debian) #1 SMP Fri May 18 23:28:21 CEST 2007 bzImage.
Loading kernel... sector 136446443 to 0x00111640
ide_readmany: sector 136446444 to 0x00111840
ide_readmany: sector 136446445 to 0x00111a40
ide_readmany: sector 136446446 to 0x00111c40
ide_readmany: sector 136446447 to 0x00111e40
ide_readmany: sector 136446448 to 0x00112040
ide_readmany: sector 136446449 to 0x00112240
ide_readmany: sector 136446450 to 0x00112440
ext2fs_read_many:  10 blocks  452610 - 452619  len=1561450 ret=0
ide_readmany: sectors 136446363 - 136446442 ( 80) to 0x40231290
ext2fs_read_many: 372 blocks  452621 - 452992  len=1520490 ret=40960
ide_readmany: sectors 136446451 - 136446706 (256) to 0x4023b290
ide_readmany: sectors 136446707 - 136446962 (256) to 0x4025b290
ide_readmany: sectors 136446963 - 136447218 (256) to 0x4027b290
ide_readmany: sectors 136447219 - 136447474 (256) to 0x4029b290
ide_readmany: sectors 136447475 - 136447730 (256) to 0x402bb290
ide_readmany: sectors 136447731 - 136447986 (256) to 0x402db290
ide_readmany: sectors 136447987 - 136448242 (256) to 0x402fb290
ide_readmany: sectors 136448243 - 136448498 (256) to 0x4031b290
ide_readmany: sectors 136448499 - 136448754 (256) to 0x4033b290
ide_readmany: sectors 136448755 - 136449010 (256) to 0x4035b290
ide_readmany: sectors 136449011 - 136449266 (256) to 0x4037b290
ide_readmany: sectors 136449267 - 136449426 (160) to 0x4039b290
ext2fs_read: discarding 3222 surplus bytes
ext2fs_read: done reading many  len=0 ret=1561450
ok
ide_readmany: sector 132825493 to 0x0010ea40
ide_readmany: sector 132825515 to 0x00111640
ide_readmany: sector 132825516 to 0x00111840
ide_readmany: sector 132825517 to 0x00111a40
ide_readmany: sector 132825518 to 0x00111c40
ide_readmany: sector 132825519 to 0x00111e40
ide_readmany: sector 132825520 to 0x00112040
ide_readmany: sector 132825521 to 0x00112240
ide_readmany: sector 132825522 to 0x00112440
File not found
Can't open initrd: hde5:/boot/initrd.img-2.6.21-1-amd64




From ben at hewson-venieri.com  Tue Jun  5 20:56:52 2007
From: ben at hewson-venieri.com (Ben Hewson)
Date: Tue, 05 Jun 2007 19:56:52 +0100
Subject: [LinuxBIOS] yet more EPIA  issues
Message-ID: <4665B1F4.4020908@hewson-venieri.com>

Looking through the early code for EPIA init, I have noticed
that shadow ram for 0xf0000-000xfffff is enabled for read/write.

Should this be done before the ram is initialized ?

Ben



From stepan at coresystems.de  Tue Jun  5 20:59:01 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 5 Jun 2007 20:59:01 +0200
Subject: [LinuxBIOS] yet more EPIA  issues
In-Reply-To: <4665B1F4.4020908@hewson-venieri.com>
References: <4665B1F4.4020908@hewson-venieri.com>
Message-ID: <20070605185901.GA10749@coresystems.de>

* Ben Hewson <ben at hewson-venieri.com> [070605 20:56]:
> Looking through the early code for EPIA init, I have noticed
> that shadow ram for 0xf0000-000xfffff is enabled for read/write.
> 
> Should this be done before the ram is initialized ?

This does not make a difference, the area is not used during LinuxBIOS
runtime.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From corey.osgood at gmail.com  Tue Jun  5 21:11:52 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 05 Jun 2007 15:11:52 -0400
Subject: [LinuxBIOS] [PATCH] Add generic Intel i82801 support
In-Reply-To: <2ea3fae10706050920k3474b62ejd5a7d6d3734b2d26@mail.gmail.com>
References: <46652C47.4030808@gmail.com>
	<2ea3fae10706050920k3474b62ejd5a7d6d3734b2d26@mail.gmail.com>
Message-ID: <4665B578.40309@gmail.com>

yhlu wrote:
> On 6/5/07, Corey Osgood <corey.osgood at gmail.com> wrote:
>> See patch. I'm still waiting on a response from Steve just to confirm
>> GPLv2 on a couple files, and I'd like Yinghai to make sure those details
>> are correct as well (ie were you working for Tyan at the time, and is
>> that the right email address to use?).
>
> yeah, that email should be always work. except someday google try to
> charge for that.
>
> YH
>
Alright, thanks. Steve has emailed me back and confirmed the rest of the
info, so the headers should be all good.

-Corey



From hawke at hawkesnest.net  Tue Jun  5 21:25:11 2007
From: hawke at hawkesnest.net (Alex Mauer)
Date: Tue, 05 Jun 2007 14:25:11 -0500
Subject: [LinuxBIOS] epia patch
In-Reply-To: <20070604191137.6565.qmail@cdy.org>
References: <46645F27.9060609@hewson-venieri.com>
	<20070604191137.6565.qmail@cdy.org>
Message-ID: <f44dao$r3s$1@sea.gmane.org>

Peter Stuge wrote:
> On Mon, Jun 04, 2007 at 07:51:19PM +0100, Ben Hewson wrote:
>> I can't say for sure this has fixed the issue. should I get any
>> more hangs though I will post a note.
> 
> Give it a few days, if no hang let's commit.

For me this patch is a big improvement, but does not remove hangs
entirely.  Note that these hangs are only during the very early boot
process (RAM detection) and not at later runtime.

-Alex Mauer "hawke"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070605/7c0ef076/attachment.sig>

From libv at skynet.be  Tue Jun  5 21:44:47 2007
From: libv at skynet.be (Luc Verhaegen)
Date: Tue, 5 Jun 2007 21:44:47 +0200
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux
	compatable	BIOS programmer ?]
In-Reply-To: <20070605175610.23148.qmail@cdy.org>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<200508130547.j7D5l8D30326@ecstasy1.winternet.com>
	<42FF0E53.4010902@linuxmachines.com>
	<200508151056.38490.p.millar@physics.gla.ac.uk>
	<4300973D.4020601@linuxmachines.com>
	<1180812548.8397.30.camel@ragnarok>
	<20070604153938.32310.qmail@cdy.org>
	<20070604184256.GA7451@skynet.be>
	<20070605175610.23148.qmail@cdy.org>
Message-ID: <20070605194447.GA14101@skynet.be>

On Tue, Jun 05, 2007 at 07:56:10PM +0200, Peter Stuge wrote:
> 
> > Also, implementation wise, we might want flashrom to take in a
> > pcitag for this sort of flashing to be enabled. This is a
> > reasonably idiot proof solution as to not accidentally flash the
> > wrong rom to the wrong place.
> 
> Mh. I would prefer to probe and do something sane by default.
> 
> Of course -w is always required to actually write.
> 
> For disambiguating if there are several PCI devices that could be
> used to flash I think as you say -p is a good idea.
> 
> I guess the ISA bridge is one of them too.
> 
> flashrom should list the PCI devices it sees that can be used to
> flash.


Well, my view is that the default behaviour should be to use the 
motherboard.

Yes, good idea, flashrom should list the possible devices:
-p without arguments could scan all pci devices and list the ones it can 
use and list the rom id.

When using -w, a pci tag argument should be required to avoid mistakes. 
-r with -p can happen if only one possible device is found.

Luc Verhaegen.



From marc.jones at amd.com  Tue Jun  5 22:48:21 2007
From: marc.jones at amd.com (Marc Jones)
Date: Tue, 05 Jun 2007 14:48:21 -0600
Subject: [LinuxBIOS] r345 - LinuxBIOSv3/southbridge/amd/cs5536
In-Reply-To: <13426df10706051051y3ae84f5cw2cf061502dbbb4c4@mail.gmail.com>
References: <20070605174532.21212.qmail@cdy.org>
	<13426df10706051051y3ae84f5cw2cf061502dbbb4c4@mail.gmail.com>
Message-ID: <4665CC15.8090101@amd.com>

ron minnich wrote:
> Peter, will do another patch with your comments taken into account.
> 
I didn't understand the comment unless it was in regard to the gpio 
setup function.

+ * @brief Set the various GPIOs. An unknown question at this point is
+ * how general this is to all mainboards.
+ */
+static void cs5536_setup_gpio(void)
+{

I think that the name should be changes to cs5536_setup_smbus_gpio(). It 
would be difficult to move this to early mainboard (car_auto) because 
the IObase needs to be setup first and then SMBus setup would be 
optional etc. I think that any platform that uses the SMBus GPIOs for 
something other than SMBus will need a lot of customization anyway and 
they would have to override the generic file. I understand the desire to 
make everything generic but that really over complicates 99% of the 
designs.

Other GPIO/AUX setup should be done in mainboard since it can typically 
be done after memory init.


> There are bugs anyway.
> 

Can you be specific? Is there something I can fix?
Marc

-- 
Marc Jones
Senior Software Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





From marc.jones at amd.com  Tue Jun  5 22:56:29 2007
From: marc.jones at amd.com (Marc Jones)
Date: Tue, 05 Jun 2007 14:56:29 -0600
Subject: [LinuxBIOS] r345 - LinuxBIOSv3/southbridge/amd/cs5536
In-Reply-To: <20070605174033.327E934005B@mail61-sin.bigfish.com>
References: <20070605174033.327E934005B@mail61-sin.bigfish.com>
Message-ID: <4665CDFD.5030403@amd.com>

Ron,
Thanks for adding all these comments. This makes the code much better.
Marc


svn at openbios.org wrote:
> Author: rminnich
> Date: 2007-06-05 19:40:18 +0200 (Tue, 05 Jun 2007)
> New Revision: 345
> 
> Added:
>    LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c
> Log:
> Early setup support for the initram phase.
> 
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
> Acked-by: Stefan Reinauer <stepan at coresystems.de>
> 
> 
> Added: LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c
> ===================================================================
> --- LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c	                        (rev 0)
> +++ LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c	2007-06-05 17:40:18 UTC (rev 345)
> @@ -0,0 +1,257 @@
> +/*
> +* This file is part of the LinuxBIOS project.
> +*
> +* Copyright (C) 2007 Advanced Micro Devices
> +*
> +* This program is free software; you can redistribute it and/or modify
> +* it under the terms of the GNU General Public License version 2 as
> +* published by the Free Software Foundation.
> +*
> +* This program is distributed in the hope that it will be useful,
> +* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +* GNU General Public License for more details.
> +*
> +* You should have received a copy of the GNU General Public License
> +* along with this program; if not, write to the Free Software
> +* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
> +*/
> +
> +/*
> + * cs5536_early_setup.c:Early chipset initialization for CS5536 companion device
> + * This code is needed for setting up ram, since we need SMBUS working as 
> + * well as serial port. 
> + * This file implements the initialization sequence documented in section 4.2 of
> + * AMD Geode GX Processor CS5536 Companion Device GoedeROM Porting Guide.
> + */
> +
> +/**
> + * @brief Set up GLINK routing for this part. The routing is controlled by an MSR. 
> + */
> +static void cs5536_setup_extmsr(void)
> +{
> +	msr_t msr;
> +
> +	/* forward MSR access to CS5536_GLINK_PORT_NUM to CS5536_DEV_NUM */
> +	msr.hi = msr.lo = 0x00000000;
> +	if (CS5536_GLINK_PORT_NUM <= 4) {
> +		msr.lo = CS5536_DEV_NUM << 
> +			(unsigned char)((CS5536_GLINK_PORT_NUM - 1) * 8);
> +	} else {
> +		msr.hi = CS5536_DEV_NUM << 
> +			(unsigned char)((CS5536_GLINK_PORT_NUM - 5) * 8);
> +	}
> +	wrmsr(GLPCI_ExtMSR, msr);
> +}
> +
> +/**
> + * @brief Setup PCI IDSEL for CS5536
> + */
> +static void cs5536_setup_idsel(void)
> +{
> +	/* write IDSEL to the write once register at address 0x0000 */
> +	outl(0x1 << (CS5536_DEV_NUM + 10), 0);
> +}
> +
> +/**
> + * @brief Need to get a good explanation of what this is.
> + */
> +static void cs5536_usb_swapsif(void)
> +{
> +	msr_t msr;
> +
> +	msr = rdmsr(USB1_SB_GLD_MSR_CAP + 0x5);
> +	//USB Serial short detect bit.
> +	if (msr.hi & 0x10) {
> +		/* We need to preserve bits 32,33,35 and not clear any BIST
> +		 * error, but clear the SERSHRT error bit */
> +
> +		msr.hi &= 0xFFFFFFFB;
> +		wrmsr(USB1_SB_GLD_MSR_CAP + 0x5, msr);
> +	}
> +}
> +
> +/**
> + * @brief Set up IO bases for SMBUS, GPIO, MFGPT, ACPI, and PM. 
> + * These can be changed by Linux later. We set some initial value so 
> + * that the resources are there as needed. 
> + * The values are hardcoded because, this early in the process, fancy
> + * allocation can do more harm than good. 
> + */
> +static void cs5536_setup_iobase(void)
> +{
> +	msr_t msr;
> +	/* setup LBAR for SMBus controller */
> +	msr.hi = 0x0000f001;
> +	msr.lo = SMBUS_IO_BASE;
> +	wrmsr(MDD_LBAR_SMB, msr);
> +
> +	/* setup LBAR for GPIO */
> +	msr.hi = 0x0000f001;
> +	msr.lo = GPIO_IO_BASE;
> +	wrmsr(MDD_LBAR_GPIO, msr);
> +
> +	/* setup LBAR for MFGPT */
> +	msr.hi = 0x0000f001;
> +	msr.lo = MFGPT_IO_BASE;
> +	wrmsr(MDD_LBAR_MFGPT, msr);
> +
> +	/* setup LBAR for ACPI */
> +	msr.hi = 0x0000f001;
> +	msr.lo = ACPI_IO_BASE;
> +	wrmsr(MDD_LBAR_ACPI, msr);
> +
> +	/* setup LBAR for PM Support */
> +	msr.hi = 0x0000f001;
> +	msr.lo = PMS_IO_BASE;
> +	wrmsr(MDD_LBAR_PMS, msr);
> +}
> +
> +/**
> + * @brief Set up the power button for operation. 
> + */
> +static void cs5536_setup_power_button(void)
> +{
> +	/*      Power Button Setup */
> +	outl(0x40020000, PMS_IO_BASE + 0x40);
> +
> +	/* setup GPIO24, it is the external signal for 5536 vsb_work_aux
> +	 * which controls all voltage rails except Vstandby & Vmem.
> +	 * We need to enable, OUT_AUX1 and OUTPUT_ENABLE in this order.
> +	 * If GPIO24 is not enabled then soft-off will not work. 
> +	 */
> +	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUT_AUX1_SELECT);
> +	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUTPUT_ENABLE);
> +
> +}
> +
> +/**
> + * @brief Set the various GPIOs. An unknown question at this point is 
> + * how general this is to all mainboards. 
> + */
> +static void cs5536_setup_gpio(void)
> +{
> +	uint32_t val;
> +
> +	/* setup GPIO pins 14/15 for SDA/SCL */
> +	val = GPIOL_15_SET | GPIOL_14_SET;
> +	/* Output Enable */
> +	outl(val, GPIO_IO_BASE + GPIOL_OUT_AUX1_SELECT);
> +	/* Output AUX1 */
> +	outl(val, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
> +	/* Input Enable */
> +	outl(val, GPIO_IO_BASE + GPIOL_IN_AUX1_SELECT);
> +	/* Input AUX1 */
> +	outl(val, GPIO_IO_BASE + GPIOL_INPUT_ENABLE);
> +}
> +
> +/**
> + * @brief Disable the internal UART. 
> + * Different boards have different UARTs for COM1. 
> + */
> +static void cs5536_disable_internal_uart(void)
> +{
> +	msr_t msr;
> +	/* The UARTs default to enabled.
> +	 * Disable and reset them and configure them later. (SIO init) 
> +	 */
> +	msr = rdmsr(MDD_UART1_CONF);
> +	msr.lo = 1;		// reset
> +	wrmsr(MDD_UART1_CONF, msr);
> +	msr.lo = 0;		// disabled
> +	wrmsr(MDD_UART1_CONF, msr);
> +
> +	msr = rdmsr(MDD_UART2_CONF);
> +	msr.lo = 1;		// reset
> +	wrmsr(MDD_UART2_CONF, msr);
> +	msr.lo = 0;		// disabled
> +	wrmsr(MDD_UART2_CONF, msr);
> +}
> +
> +/**
> + * @brief Set up the cs5536 CIS interface to CPU  interface to match modes. 
> + */
> +static void cs5536_setup_cis_mode(void)
> +{
> +	msr_t msr;
> +
> +	/* setup CPU interface serial to mode B to match CPU */
> +	msr = rdmsr(GLPCI_SB_CTRL);
> +	msr.lo &= ~0x18;
> +	msr.lo |= 0x10;
> +	wrmsr(GLPCI_SB_CTRL, msr);
> +}
> +
> +/**
> + * @brief Enable the on chip UART. 
> + */
> +/* see page 412 of the cs5536 companion book */
> +static void cs5536_setup_onchipuart(void)
> +{
> +	msr_t msr;
> +
> +	/* Setup early for polling only mode.
> +	 * 1. Eanble GPIO 8 to OUT_AUX1, 9 to IN_AUX1
> +	 *        GPIO LBAR + 0x04, LBAR + 0x10, LBAR + 0x20, LBAR + 34
> +	 * 2. Enable UART IO space in MDD
> +	 *        MSR 0x51400014 bit 18:16
> +	 * 3. Enable UART controller
> +	 *        MSR 0x5140003A bit 0, 1
> +	 */
> +
> +	/* GPIO8 - UART1_TX */
> +	/* Set: Output Enable  (0x4) */
> +	outl(GPIOL_8_SET, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
> +	/* Set: OUTAUX1 Select (0x10) */
> +	outl(GPIOL_8_SET, GPIO_IO_BASE + GPIOL_OUT_AUX1_SELECT);
> +	/* GPIO9 - UART1_RX */
> +	/* Set: Input Enable   (0x20) */
> +	outl(GPIOL_9_SET, GPIO_IO_BASE + GPIOL_INPUT_ENABLE);
> +	/* Set: INAUX1 Select  (0x34) */
> +	outl(GPIOL_9_SET, GPIO_IO_BASE + GPIOL_IN_AUX1_SELECT);
> +
> +	/* set address to 3F8 */
> +	msr = rdmsr(MDD_LEG_IO);
> +	msr.lo |= 0x7 << 16;
> +	wrmsr(MDD_LEG_IO, msr);
> +
> +	/*      Bit 1 = DEVEN (device enable)
> +	 *      Bit 4 = EN_BANKS (allow access to the upper banks
> +	 */
> +	msr.lo = (1 << 4) | (1 << 1);
> +	msr.hi = 0;
> +
> +	/* enable COM1 */
> +	wrmsr(MDD_UART1_CONF, msr);
> +}
> +
> +
> +/**
> + * @brief Board setup. Known to work on norwich and digitial logic boards. 
> + * Note we do NOT do any UART
> + * setup here -- this is done later by the mainboard setup, 
> + * since UART usage is not universal. 
> + */
> +static void cs5536_early_setup(void)
> +{
> +	msr_t msr;
> +
> +	/* note: you can't do prints in here in most cases,
> +	 * and we don't want to hang on serial, so they are
> +	 * commented out
> + 	*/
> +	cs5536_setup_extmsr();
> +	cs5536_setup_cis_mode();
> +
> +	msr = rdmsr(GLCP_SYS_RSTPLL);
> +	if (msr.lo & (0x3f << 26)) {
> +		/* PLL is already set and we are reboot from PLL reset */
> +		return;
> +	}
> +	cs5536_setup_idsel();
> +	cs5536_usb_swapsif();
> +	cs5536_setup_iobase();
> +	cs5536_setup_gpio();
> +	cs5536_enable_smbus();
> +	cs5536_setup_power_button();
> +}
> 
> 

-- 
Marc Jones
Senior Software Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors





From svn at openbios.org  Tue Jun  5 23:01:05 2007
From: svn at openbios.org (svn at openbios.org)
Date: Tue,  5 Jun 2007 23:01:05 +0200
Subject: [LinuxBIOS] r346 - LinuxBIOSv3/southbridge/amd/cs5536
Message-ID: <mailman.382.1355071118.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-06-05 23:01:05 +0200 (Tue, 05 Jun 2007)
New Revision: 346

Modified:
   LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c
   LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c
Log:
Add comments, correct warnings, add a note by Marc Jones, 
and change a name per Marc Jone's suggestion.
Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>




Modified: LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c
===================================================================
--- LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c	2007-06-05 17:40:18 UTC (rev 345)
+++ LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c	2007-06-05 21:01:05 UTC (rev 346)
@@ -16,47 +16,59 @@
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 */
-
+#include <console.h>
+#include <io.h>
+#include <msr.h>
+#include <amd_geodelx.h>
+#include "cs5536.h"
 /*
  * cs5536_early_setup.c:Early chipset initialization for CS5536 companion device
- * This code is needed for setting up ram, since we need SMBUS working as 
- * well as serial port. 
+ * This code is needed for setting up ram, since we need SMBUS working as
+ * well as serial port.
  * This file implements the initialization sequence documented in section 4.2 of
  * AMD Geode GX Processor CS5536 Companion Device GoedeROM Porting Guide.
  */
 
 /**
- * @brief Set up GLINK routing for this part. The routing is controlled by an MSR. 
+ * @brief Set up GLINK routing for this part. The routing is controlled by an MSR.
+ * This appears to be the
+ * same on all boards.
+ * If you don't know what GLINK routing is, there is no way to explain it here.
  */
-static void cs5536_setup_extmsr(void)
+void cs5536_setup_extmsr(void)
 {
 	msr_t msr;
 
 	/* forward MSR access to CS5536_GLINK_PORT_NUM to CS5536_DEV_NUM */
 	msr.hi = msr.lo = 0x00000000;
-	if (CS5536_GLINK_PORT_NUM <= 4) {
-		msr.lo = CS5536_DEV_NUM << 
-			(unsigned char)((CS5536_GLINK_PORT_NUM - 1) * 8);
-	} else {
-		msr.hi = CS5536_DEV_NUM << 
-			(unsigned char)((CS5536_GLINK_PORT_NUM - 5) * 8);
-	}
+#if  CS5536_GLINK_PORT_NUM <= 4
+	msr.lo = CS5536_DEV_NUM <<
+		(unsigned char)((CS5536_GLINK_PORT_NUM - 1) * 8);
+#else
+	msr.hi = CS5536_DEV_NUM <<
+		(unsigned char)((CS5536_GLINK_PORT_NUM - 5) * 8);
+#endif
 	wrmsr(GLPCI_ExtMSR, msr);
 }
 
 /**
- * @brief Setup PCI IDSEL for CS5536
+ * @brief Setup PCI IDSEL for CS5536. There is a Magic Register that must be
+ * written so that the chip appears at the expected place in the PCI tree.
  */
-static void cs5536_setup_idsel(void)
+void cs5536_setup_idsel(void)
 {
 	/* write IDSEL to the write once register at address 0x0000 */
 	outl(0x1 << (CS5536_DEV_NUM + 10), 0);
 }
 
 /**
- * @brief Need to get a good explanation of what this is.
+ * @brief Magic Bits for undocumented register.
+ * You don' t need to see those papers.
+ * These are not the bits you're looking for.
+ * You can go about your business.
+ * Move along, move along.
  */
-static void cs5536_usb_swapsif(void)
+void cs5536_usb_swapsif(void)
 {
 	msr_t msr;
 
@@ -72,13 +84,13 @@
 }
 
 /**
- * @brief Set up IO bases for SMBUS, GPIO, MFGPT, ACPI, and PM. 
- * These can be changed by Linux later. We set some initial value so 
- * that the resources are there as needed. 
+ * @brief Set up IO bases for SMBUS, GPIO, MFGPT, ACPI, and PM.
+ * These can be changed by Linux later. We set some initial value so
+ * that the resources are there as needed.
  * The values are hardcoded because, this early in the process, fancy
- * allocation can do more harm than good. 
+ * allocation can do more harm than good.
  */
-static void cs5536_setup_iobase(void)
+void cs5536_setup_iobase(void)
 {
 	msr_t msr;
 	/* setup LBAR for SMBus controller */
@@ -108,30 +120,28 @@
 }
 
 /**
- * @brief Set up the power button for operation. 
+ * @brief Power Button Setup
+ * setup GPIO24, it is the external signal for 5536 vsb_work_aux
+ * which controls all voltage rails except Vstandby & Vmem.
+ * We need to enable, OUT_AUX1 and OUTPUT_ENABLE in this order.
+ * If GPIO24 is not enabled then soft-off will not work.
  */
-static void cs5536_setup_power_button(void)
+void cs5536_setup_power_button(void)
 {
-	/*      Power Button Setup */
 	outl(0x40020000, PMS_IO_BASE + 0x40);
-
-	/* setup GPIO24, it is the external signal for 5536 vsb_work_aux
-	 * which controls all voltage rails except Vstandby & Vmem.
-	 * We need to enable, OUT_AUX1 and OUTPUT_ENABLE in this order.
-	 * If GPIO24 is not enabled then soft-off will not work. 
-	 */
 	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUT_AUX1_SELECT);
 	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUTPUT_ENABLE);
 
 }
 
 /**
- * @brief Set the various GPIOs. An unknown question at this point is 
- * how general this is to all mainboards. 
+ * @brief Set the various GPIOs. An unknown question at this point is
+ * how general this is to all mainboards. At the same time, many
+ * boards seem to follow this particular reference spec.
  */
-static void cs5536_setup_gpio(void)
+void cs5536_setup_smbus_gpio(void)
 {
-	uint32_t val;
+	u32 val;
 
 	/* setup GPIO pins 14/15 for SDA/SCL */
 	val = GPIOL_15_SET | GPIOL_14_SET;
@@ -146,14 +156,14 @@
 }
 
 /**
- * @brief Disable the internal UART. 
- * Different boards have different UARTs for COM1. 
+ * @brief Disable the internal UART.
+ * Different boards have different UARTs for COM1.
  */
-static void cs5536_disable_internal_uart(void)
+void cs5536_disable_internal_uart(void)
 {
 	msr_t msr;
 	/* The UARTs default to enabled.
-	 * Disable and reset them and configure them later. (SIO init) 
+	 * Disable and reset them and configure them later. (SIO init)
 	 */
 	msr = rdmsr(MDD_UART1_CONF);
 	msr.lo = 1;		// reset
@@ -169,9 +179,11 @@
 }
 
 /**
- * @brief Set up the cs5536 CIS interface to CPU  interface to match modes. 
+ * @brief Set up the cs5536 CIS interface to CPU  interface to match modes.
+ * The CIS is related to the interrupt system. It is important to match the
+ * south and the cpu chips. At the same time, they always seem to use mode B.
  */
-static void cs5536_setup_cis_mode(void)
+void cs5536_setup_cis_mode(void)
 {
 	msr_t msr;
 
@@ -183,10 +195,9 @@
 }
 
 /**
- * @brief Enable the on chip UART. 
+ * @brief Enable the on chip UART.see page 412 of the cs5536 companion book
  */
-/* see page 412 of the cs5536 companion book */
-static void cs5536_setup_onchipuart(void)
+void cs5536_setup_onchipuart(void)
 {
 	msr_t msr;
 
@@ -227,12 +238,30 @@
 
 
 /**
- * @brief Board setup. Known to work on norwich and digitial logic boards. 
+ * @brief Board setup. Known to work on norwich and digitial logic boards.
+ * The extmsr and cis_mode are common for sure.
+ * The RSTPLL check is mandatory.
+ * IDSEl of course is required, so the chip appears in PCI config space,
+ * and the swapsif covers a necessary chip fix.
+ * Finally, the iobase is needed for DRAM, the GPIOs
+ * are likely common to all boards, and the power button
+ * seems to be the same on all. At the same time,
+ * we may need to move gpio and power button
+ * out as developments demand.
  * Note we do NOT do any UART
- * setup here -- this is done later by the mainboard setup, 
- * since UART usage is not universal. 
+ * setup here -- this is done later by the mainboard setup,
+ * since UART usage is not universal.
+ * A comment from Marc Jones:
+	"It
+	would be difficult to move this to early mainboard (car_auto) because
+	the IObase needs to be setup first and then SMBus setup would be
+	optional etc. I think that any platform that uses the SMBus GPIOs for
+	something other than SMBus will need a lot of customization anyway and
+	they would have to override the generic file. I understand the desire to
+	make everything generic but that really over complicates 99% of the
+	designs."
  */
-static void cs5536_early_setup(void)
+void cs5536_early_setup(void)
 {
 	msr_t msr;
 
@@ -251,7 +280,7 @@
 	cs5536_setup_idsel();
 	cs5536_usb_swapsif();
 	cs5536_setup_iobase();
-	cs5536_setup_gpio();
-	cs5536_enable_smbus();
+	cs5536_setup_smbus_gpio();
+	/* cs5536_enable_smbus(); -- leave this out for now */
 	cs5536_setup_power_button();
 }

Modified: LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c
===================================================================
--- LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c	2007-06-05 17:40:18 UTC (rev 345)
+++ LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c	2007-06-05 21:01:05 UTC (rev 346)
@@ -259,37 +259,37 @@
 
 	if (smbus_check_stop_condition(smbus_io_base)) {
 		error = "smbus_check_stop_condition timed out";
-		goto err
+		goto err;
 	}
 
-	if (errno = smbus_start_condition(smbus_io_base)) {
+	if ((errno = smbus_start_condition(smbus_io_base))) {
 		error = "smbus_start_condition";
 		goto err;
 	}
 
-	if (errno = smbus_send_slave_address(smbus_io_base, device)) {
+	if ((errno = smbus_send_slave_address(smbus_io_base, device))) {
 		error = "smbus_send_slave_address";
 		goto err;
 	}
 
 	smbus_ack(smbus_io_base);
 
-	if (errno = smbus_send_command(smbus_io_base, address)) {
+	if ((errno = smbus_send_command(smbus_io_base, address))) {
 		error = "smbus_send_command";
 		goto err;
 	}
 
-	if (errno = smbus_start_condition(smbus_io_base)) {
+	if ((errno = smbus_start_condition(smbus_io_base))) {
 		error = "smbus_start_condition";
 		goto err;
 	}
 
-	if (errno = smbus_send_slave_address(smbus_io_base, device | 0x01)) {
+	if ((errno = smbus_send_slave_address(smbus_io_base, device | 0x01))) {
 		error = "smbus_send_slave_address";
 		goto err;
 	}
 
-	if (errno = smbus_stop_condition(smbus_io_base)) {
+	if ((errno = smbus_stop_condition(smbus_io_base))) {
 		error = "second smbus_stop_condition";
 		goto err;
 	}




From ben at hewson-venieri.com  Tue Jun  5 23:26:02 2007
From: ben at hewson-venieri.com (Ben Hewson)
Date: Tue, 05 Jun 2007 22:26:02 +0100
Subject: [LinuxBIOS] compilation issue
Message-ID: <4665D4EA.4040007@hewson-venieri.com>

in the process of getting ACPI working on EPIA I have just noticed the 
following error at the end of the compile.

gcc -m32 -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../../i686-pc-linux-gnu/bin/ld: 
linuxbios: section .data lma 0xffff6f04 overlaps previous sections

I assume this wasn't there before so maybe the code has got to big, 
although I dont think it is to big to fit as I get the following

./buildrom linuxbios.strip linuxbios.rom payload 0x10000 0x20000
Payload: 25736 LinuxBIOS: 65536 ROM size: 131072 Left space: 39800

I am including both normal and fallback, so if I include ACPI will this 
mean I will just have to go with the fallback option,
not that it matters as both just do the same thing anyway.

thanks
Ben




From rminnich at gmail.com  Tue Jun  5 23:30:22 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 5 Jun 2007 14:30:22 -0700
Subject: [LinuxBIOS] compilation issue
In-Reply-To: <4665D4EA.4040007@hewson-venieri.com>
References: <4665D4EA.4040007@hewson-venieri.com>
Message-ID: <13426df10706051430r78cc77cau1e8109aa737a39d8@mail.gmail.com>

do a readelf -a, and I bet the .data is 0, or some zero-lenght thing
overlaps it.

There are so many "issues" in gnubin. This is one more.

FWIW, Juergen has some nice fixes which we are looking at bringing in
to V3 -- he's done some very nice work.

ron



From ben at hewson-venieri.com  Tue Jun  5 23:40:32 2007
From: ben at hewson-venieri.com (Ben Hewson)
Date: Tue, 05 Jun 2007 22:40:32 +0100
Subject: [LinuxBIOS] compilation issue
In-Reply-To: <13426df10706051430r78cc77cau1e8109aa737a39d8@mail.gmail.com>
References: <4665D4EA.4040007@hewson-venieri.com>
	<13426df10706051430r78cc77cau1e8109aa737a39d8@mail.gmail.com>
Message-ID: <4665D850.2090609@hewson-venieri.com>

ron minnich wrote:
> do a readelf -a, and I bet the .data is 0, or some zero-lenght thing
> overlaps it.
>
> There are so many "issues" in gnubin. This is one more.
>
> FWIW, Juergen has some nice fixes which we are looking at bringing in
> to V3 -- he's done some very nice work.
>
> ron
>
doing readelf -a on linuxbios.rom (I assume that is what you meant) 
gives this.

not sure if there is a problem there though.
I did notice if I I change the unsigned char array used for the acpi 
stuff to a const unsigned char array
it does shift the address of the error slightly.


ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x1041d8
  Start of program headers:          52 (bytes into file)
  Start of section headers:          25336 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         5
  Size of section headers:           40 (bytes)
  Number of section headers:         10
  Section header string table index: 9

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg 
Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      
0   0  0
  [ 1] .note             NOTE            00100000 0000e0 00007c 00   A  
0   0 32
  [ 2] .text             PROGBITS        0010007c 00015c 0051c8 00 WAX  
0   0  4
  [ 3] .rodata           PROGBITS        00105260 005340 000cc9 00   A  
0   0 32
  [ 4] .eh_frame         PROGBITS        00105f2c 00600c 000058 00   A  
0   0  4
  [ 5] .data             PROGBITS        00105fa0 006080 0001c8 00  WA  
0   0 32
  [ 6] .bss              NOBITS          00106180 006248 019f80 00  WA  
0   0 32
  [ 7] .initctx          PROGBITS        00120100 006260 000048 00  WA  
0   0 32
  [ 8] .note.GNU-stack   PROGBITS        00000000 0062a8 000000 00   X  
0   0  1
  [ 9] .shstrtab         STRTAB          00000000 0062a8 00004d 00      
0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x0000e0 0x00100000 0x00100000 0x06168 0x20100 RWE 0x20
  LOAD           0x006260 0x00120100 0x00120100 0x00048 0x00048 RW  0x20
  NOTE           0x0000e0 0x00100000 0x00100000 0x0007c 0x0007c R   0x20
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
  PAX_FLAGS      0x000000 0x00000000 0x00000000 0x00000 0x00000     0x4

 Section to Segment mapping:
  Segment Sections...
   00     .note .text .rodata .eh_frame .data .bss
   01     .initctx
   02     .note
   03    
   04    

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Notes at offset 0x000000e0 with length 0x0000007c:
  Owner         Data size       Description
  ELFBoot               0x00000005      NT_VERSION (version)
  ELFBoot               0x00000032      NT_ARCH (architecture)
  ELFBoot               0x00000002      Unknown note type: (0x00000003)




From stepan at coresystems.de  Wed Jun  6 02:27:25 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 6 Jun 2007 02:27:25 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070605060119.GA3225@bloms.de>
References: <20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
	<20070604214846.GA14123@coresystems.de>
	<20070605060119.GA3225@bloms.de>
Message-ID: <20070606002724.GB12985@coresystems.de>

* Dieter Bloms <dieter at bloms.de> [070605 08:01]:
> > I will go read the ICH4 data sheet some more on thursday to figure
> > something out.
> > 
> > I have a very similar problem with a very similar board, but I did not
> > try 4e yet. Chances are that it's a similar problem.
> 
> hopefully.
> 
> Many thanks for your support !
 
Ok, I have something for a quick try. Can you add the following code to
auto.c and try enabling serial once with 2e and once with 4e afterwards?

You might have to adapt the PCI ID of the south bridge's LPC interface
device (24cc in the below example)

The code won't patch, but it should serve as a template

Just so we see whether this makes it work.

+++ auto.c      (working copy)
@@ -69,6 +69,8 @@
                },
        };

+       unsigned int dev;
+
        if (bist == 0) {
                early_mtrr_init();
 #if 0
@@ -76,7 +78,11 @@
                init_timer();
 #endif
        }
-
+
+       // enable the decoding of superio ranges to the LPC interface
+       dev = pci_locate_device(PCI_ID(0x8086, 0x24cc), 0);
+       pci_write_config16(dev, 0xE6, 0x 3cff);
+
         w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE);
         uart_init();
         console_init();




-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From dieter at bloms.de  Wed Jun  6 08:36:31 2007
From: dieter at bloms.de (Dieter Bloms)
Date: Wed, 6 Jun 2007 08:36:31 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070606002724.GB12985@coresystems.de>
References: <20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
	<20070604214846.GA14123@coresystems.de>
	<20070605060119.GA3225@bloms.de>
	<20070606002724.GB12985@coresystems.de>
Message-ID: <20070606063631.GA3554@bloms.de>

Hi Stefan,

On Wed, Jun 06, Stefan Reinauer wrote:

> Ok, I have something for a quick try. Can you add the following code to
> auto.c and try enabling serial once with 2e and once with 4e afterwards?
> 
> You might have to adapt the PCI ID of the south bridge's LPC interface
> device (24cc in the below example)

I used 24c0, because of:

00:1f.0 ISA bridge [0601]: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge [8086:24c0] (rev 02)

> Just so we see whether this makes it work.

no it doesn't work neither with 2e nor with 4e :(

I think I have something total wrong with my config.

I have tared my stuff, maybe someone is willing to have a look at it:

http://www.bloms.de/download/commell_lv671.tar.gz


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/687ed2cc/attachment.sig>

From stepan at coresystems.de  Wed Jun  6 08:57:15 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 6 Jun 2007 08:57:15 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070606063631.GA3554@bloms.de>
References: <20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
	<20070604214846.GA14123@coresystems.de>
	<20070605060119.GA3225@bloms.de>
	<20070606002724.GB12985@coresystems.de>
	<20070606063631.GA3554@bloms.de>
Message-ID: <20070606065715.GA23513@coresystems.de>

* Dieter Bloms <dieter at bloms.de> [070606 08:36]:
> > You might have to adapt the PCI ID of the south bridge's LPC interface
> > device (24cc in the below example)
> 
> I used 24c0, because of:
> 
> 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge [8086:24c0] (rev 02)
 
Ok, that looks correct.

> no it doesn't work neither with 2e nor with 4e :(
 
Pity! Then this is not the only problem at least. I am sure it is
required on ICH4 based boards though as ICH4 does not decode any superio
at poweron. More at a later time.

> I think I have something total wrong with my config.
> 
> I have tared my stuff, maybe someone is willing to have a look at it:
> 
> http://www.bloms.de/download/commell_lv671.tar.gz



-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From svn at openbios.org  Wed Jun  6 12:26:00 2007
From: svn at openbios.org (svn at openbios.org)
Date: Wed,  6 Jun 2007 12:26:00 +0200
Subject: [LinuxBIOS] r2714 - in trunk/LinuxBIOSv2/src/superio/winbond: .
	w83977f
Message-ID: <mailman.383.1355071119.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-06 12:26:00 +0200 (Wed, 06 Jun 2007)
New Revision: 2714

Added:
   trunk/LinuxBIOSv2/src/superio/winbond/w83977f/
   trunk/LinuxBIOSv2/src/superio/winbond/w83977f/Config.lb
   trunk/LinuxBIOSv2/src/superio/winbond/w83977f/chip.h
   trunk/LinuxBIOSv2/src/superio/winbond/w83977f/superio.c
   trunk/LinuxBIOSv2/src/superio/winbond/w83977f/w83977f.h
   trunk/LinuxBIOSv2/src/superio/winbond/w83977f/w83977f_early_serial.c
Log:
Add support for the Winbond W83977F-A Super I/O.

Signed-off-by: Nikolay Petukhov <nikolay.petukhov at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Added: trunk/LinuxBIOSv2/src/superio/winbond/w83977f/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/src/superio/winbond/w83977f/Config.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/superio/winbond/w83977f/Config.lb	2007-06-06 10:26:00 UTC (rev 2714)
@@ -0,0 +1,22 @@
+## 
+## This file is part of the LinuxBIOS project.
+## 
+## Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+## 
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+## 
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+## 
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+## 
+
+config chip.h
+object superio.o

Added: trunk/LinuxBIOSv2/src/superio/winbond/w83977f/chip.h
===================================================================
--- trunk/LinuxBIOSv2/src/superio/winbond/w83977f/chip.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/superio/winbond/w83977f/chip.h	2007-06-06 10:26:00 UTC (rev 2714)
@@ -0,0 +1,29 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <pc80/keyboard.h>
+#include <uart8250.h>
+
+extern struct chip_operations superio_winbond_w83977f_ops;
+
+struct superio_winbond_w83977f_config {
+	struct uart8250 com1, com2;
+	struct pc_keyboard keyboard;
+};

Added: trunk/LinuxBIOSv2/src/superio/winbond/w83977f/superio.c
===================================================================
--- trunk/LinuxBIOSv2/src/superio/winbond/w83977f/superio.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/superio/winbond/w83977f/superio.c	2007-06-06 10:26:00 UTC (rev 2714)
@@ -0,0 +1,118 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <arch/io.h>
+#include <device/device.h>
+#include <device/pnp.h>
+#include <console/console.h>
+#include <string.h>
+#include <bitops.h>
+#include <uart8250.h>
+#include <pc80/keyboard.h>
+#include "chip.h"
+#include "w83977f.h"
+
+static void w83977f_enter_ext_func_mode(device_t dev) 
+{
+	outb(0x87, dev->path.u.pnp.port);
+	outb(0x87, dev->path.u.pnp.port);
+}
+static void w83977f_exit_ext_func_mode(device_t dev) 
+{
+	outb(0xaa, dev->path.u.pnp.port);
+}
+
+static void w83977f_init(device_t dev)
+{
+	struct superio_winbond_w83977f_config *conf;
+	struct resource *res0, *res1;
+
+	if (!dev->enabled) {
+		return;
+	}
+	conf = dev->chip_info;
+	switch(dev->path.u.pnp.device) {
+	case W83977F_SP1:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		init_uart8250(res0->base, &conf->com1);
+		break;
+	case W83977F_SP2:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		init_uart8250(res0->base, &conf->com2);
+		break;
+	case W83977F_KBC:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		res1 = find_resource(dev, PNP_IDX_IO1);
+		init_pc_keyboard(res0->base, res1->base, &conf->keyboard);
+		break;
+	}
+}
+
+static void w83977f_set_resources(device_t dev)
+{
+	w83977f_enter_ext_func_mode(dev);
+	pnp_set_resources(dev);
+	w83977f_exit_ext_func_mode(dev);
+}
+
+static void w83977f_enable_resources(device_t dev)
+{
+	w83977f_enter_ext_func_mode(dev);
+	pnp_enable_resources(dev);
+	w83977f_exit_ext_func_mode(dev);
+}
+
+static void w83977f_enable(device_t dev)
+{
+	w83977f_enter_ext_func_mode(dev);
+	pnp_enable(dev);
+	w83977f_exit_ext_func_mode(dev);
+}
+
+static struct device_operations ops = {
+	.read_resources		= pnp_read_resources,
+	.set_resources		= w83977f_set_resources,
+	.enable_resources	= w83977f_enable_resources,
+	.enable			= w83977f_enable,
+	.init			= w83977f_init,
+};
+
+static struct pnp_info pnp_dev_info[] = {
+	{ &ops, W83977F_FDC,  PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83977F_PP,   PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83977F_SP1,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83977F_SP2,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83977F_RTC,  PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83977F_KBC,  PNP_IO0 | PNP_IO1 | PNP_IRQ0 | PNP_IRQ1, { 0x7f8, 0 }, { 0x7f8, 0x0}, },
+	{ &ops, W83977F_IR, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, },
+	{ &ops, W83977F_GPIO1, PNP_IO0, { 0x7f8, 0 }, },
+	{ &ops, W83977F_GPIO2, PNP_IO0, { 0x7f8, 0 }, },
+};
+
+static void enable_dev(device_t dev)
+{
+	pnp_enable_devices(dev, &ops,
+		sizeof(pnp_dev_info)/sizeof(pnp_dev_info[0]), pnp_dev_info);
+}
+
+struct chip_operations superio_winbond_w83977f_ops = {
+	CHIP_NAME("Winbond W83977F-A Super I/O")
+	.enable_dev = enable_dev,
+};

Added: trunk/LinuxBIOSv2/src/superio/winbond/w83977f/w83977f.h
===================================================================
--- trunk/LinuxBIOSv2/src/superio/winbond/w83977f/w83977f.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/superio/winbond/w83977f/w83977f.h	2007-06-06 10:26:00 UTC (rev 2714)
@@ -0,0 +1,29 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define W83977F_FDC	0	/* Floppy */
+#define W83977F_PP	1	/* Parallel Port */
+#define W83977F_SP1	2	/* Com1 */
+#define W83977F_SP2	3	/* Com2 */
+#define W83977F_RTC	4	/* RTC */
+#define W83977F_KBC	5	/* Keyboard & Mouse */
+#define W83977F_IR	6	/* Infrared Port */
+#define W83977F_GPIO1	7	/* General Purpose I/O 1 */
+#define W83977F_GPIO2	8	/* General Purpose I/O 2 */

Added: trunk/LinuxBIOSv2/src/superio/winbond/w83977f/w83977f_early_serial.c
===================================================================
--- trunk/LinuxBIOSv2/src/superio/winbond/w83977f/w83977f_early_serial.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/superio/winbond/w83977f/w83977f_early_serial.c	2007-06-06 10:26:00 UTC (rev 2714)
@@ -0,0 +1,45 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <arch/romcc_io.h>
+#include "w83977f.h"
+
+static inline void pnp_enter_ext_func_mode(device_t dev)
+{
+	unsigned int port = dev >> 8;
+	outb(0x87, port);
+	outb(0x87, port);
+}
+
+static void pnp_exit_ext_func_mode(device_t dev)
+{
+	unsigned int port = dev >> 8;
+	outb(0xaa, port);
+}
+
+static void w83977f_enable_serial(device_t dev, unsigned int iobase)
+{
+	pnp_enter_ext_func_mode(dev);
+	pnp_set_logical_device(dev);
+	pnp_set_enable(dev, 0);
+	pnp_set_iobase(dev, PNP_IDX_IO0, iobase);
+	pnp_set_enable(dev, 1);
+	pnp_exit_ext_func_mode(dev);
+}




From info at coresystems.de  Wed Jun  6 13:03:37 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 06 Jun 2007 13:03:37 +0200
Subject: [LinuxBIOS] r2703 build service
Message-ID: <E1HvtIf-0007zG-3G@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2703 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Intel 82371EB: Add IDE init support.

In a mainboard's Config.lb file you can configure whether the primary
and/or secondary IDE interfaces shall be enabled.

Also, various fixups in the rest of the southbridge code, most notably
the early SMBus code, plus some documentation improvements.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Corey Osgood <corey_osgood at verizon.net>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2703&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2703&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2703&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2703&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2703&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From info at coresystems.de  Wed Jun  6 13:50:13 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 06 Jun 2007 13:50:13 +0200
Subject: [LinuxBIOS] r2704 build service
Message-ID: <E1Hvu1l-0003je-Pe@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2704 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Use the common LinuxBIOS license header format.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Sven Kapferer <skapfere at rumms.uni-mannheim.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2704&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2704&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2704&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2704&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2704&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From info at coresystems.de  Wed Jun  6 14:45:12 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 06 Jun 2007 14:45:12 +0200
Subject: [LinuxBIOS] r2705 build service
Message-ID: <E1Hvusy-0001cd-R7@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2705 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Drop duplicate 82371AB device IDs (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2705&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2705&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2705&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2705&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2705&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From darmawan.salihun at gmail.com  Wed Jun  6 15:01:47 2007
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Wed, 06 Jun 2007 20:01:47 +0700
Subject: [LinuxBIOS] The purpose of linuxbios_init
Message-ID: <4666B03B.2060500@gmail.com>

Hi all,
    I'm currently reading the source code of flashrom (linux version). I
found this linuxbios_init(void) function. What is the purpose of this
function?
I see that it checks the lb_header and lb_record of the BIOS binary in
the flash ROM chip. I suppose that this function works particularly for
motherboards already
equipped with linuxbios. Am I right? And for motherboard that contains
other vendor BIOS, it plainly "returns". Is that correct?

TIA,
Darmawan



From darmawan.salihun at gmail.com  Wed Jun  6 15:04:54 2007
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Wed, 06 Jun 2007 20:04:54 +0700
Subject: [LinuxBIOS] The purpose of linuxbios_init
In-Reply-To: <4666B03B.2060500@gmail.com>
References: <4666B03B.2060500@gmail.com>
Message-ID: <4666B0F6.1060003@gmail.com>

I see that it's to initializes motherboard-specific flash enable
sequence. However, the details is still too vague for me.
  
Rgds,
Darmawan

Darmawan Salihun wrote:
> Hi all,
>     I'm currently reading the source code of flashrom (linux version). I
> found this linuxbios_init(void) function. What is the purpose of this
> function?
> I see that it checks the lb_header and lb_record of the BIOS binary in
> the flash ROM chip. I suppose that this function works particularly for
> motherboards already
> equipped with linuxbios. Am I right? And for motherboard that contains
> other vendor BIOS, it plainly "returns". Is that correct?
>
> TIA,
> Darmawan
>   



From ward at gnu.org  Wed Jun  6 15:09:45 2007
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 6 Jun 2007 09:09:45 -0400
Subject: [LinuxBIOS] The purpose of linuxbios_init
In-Reply-To: <4666B0F6.1060003@gmail.com>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
Message-ID: <20070606130945.GA8454@countzero.vandewege.net>

On Wed, Jun 06, 2007 at 08:04:54PM +0700, Darmawan Salihun wrote:
> I see that it's to initializes motherboard-specific flash enable
> sequence. However, the details is still too vague for me.

Yeah, I think the idea is that if there is a lb_header, i.e. if this machine
already runs LinuxBIOS, flashrom can figure out exactly which mainboard it is
much more easily. For machines running a proprietary BIOS, this is much more
difficult - you have to look at pci ids etc, and they are not always unique
(vendors like to reuse them....).

This is just my 10,000 feet view, without actually looking at that code ;)

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



From stuge-linuxbios at cdy.org  Wed Jun  6 15:24:29 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 6 Jun 2007 15:24:29 +0200
Subject: [LinuxBIOS] The purpose of linuxbios_init
In-Reply-To: <20070606130945.GA8454@countzero.vandewege.net>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
Message-ID: <20070606132429.10300.qmail@cdy.org>

On Wed, Jun 06, 2007 at 09:09:45AM -0400, Ward Vandewege wrote:
> On Wed, Jun 06, 2007 at 08:04:54PM +0700, Darmawan Salihun wrote:
> > I see that it's to initializes motherboard-specific flash enable
> > sequence. However, the details is still too vague for me.
> 
> Yeah, I think the idea is that if there is a lb_header, i.e. if
> this machine already runs LinuxBIOS, flashrom can figure out
> exactly which mainboard it is much more easily. For machines
> running a proprietary BIOS, this is much more difficult - you have
> to look at pci ids etc, and they are not always unique (vendors
> like to reuse them....).
> 
> This is just my 10,000 feet view, without actually looking at that
> code ;)

Still spot on.

If there is LB in flash already, the mainboard model and flash enable
sequence is determined from that.

Note that this needs an override with -m if the LB chip is being
reflashed in a different board than it's intended to be used with.


//Peter



From stepan at coresystems.de  Wed Jun  6 16:13:26 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 6 Jun 2007 16:13:26 +0200
Subject: [LinuxBIOS] The purpose of linuxbios_init
In-Reply-To: <20070606132429.10300.qmail@cdy.org>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<20070606132429.10300.qmail@cdy.org>
Message-ID: <20070606141326.GB32692@coresystems.de>

* Peter Stuge <stuge-linuxbios at cdy.org> [070606 15:24]:
> Still spot on.
> 
> If there is LB in flash already, the mainboard model and flash enable
> sequence is determined from that.
> 
> Note that this needs an override with -m if the LB chip is being
> reflashed in a different board than it's intended to be used with.

I think you have to say -f, not -m. Since -m is the board specific
enable sequence and the type is determined from ram, not the image.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From info at coresystems.de  Wed Jun  6 17:00:04 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 06 Jun 2007 17:00:04 +0200
Subject: [LinuxBIOS] r2706 build service
Message-ID: <E1HvwzU-0004Q5-Uz@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2706 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
The UART disable code was causing a hang and was worked around with a
return that skipped the disable code. This patch removes the return and
fixes the UART disable code.

The problem was that the disable code was ORing bits into the Legacy_IO
MSR causing issues with the LPC SIOs init code that would manifest as a
hang because the IO would not be decoded correctly. ANDing to clear the
bits fixes the issue.

Signed-off-by: Marc Jones <marc.jones at amd.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2706&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2706&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2706&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2706&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2706&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From darmawan.salihun at gmail.com  Wed Jun  6 17:47:59 2007
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Wed, 06 Jun 2007 22:47:59 +0700
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current device driver
	(testbed)
In-Reply-To: <20070606130945.GA8454@countzero.vandewege.net>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
Message-ID: <4666D72F.1080201@gmail.com>

Hi all,
    I attach the device driver code for my experimental flashrom port to
windows back then. It's buggy, too much direct access, etc.
But, it works at some points during my brief testing phase. It's based
on the old flashrom version 1.23. I know, it's not a good example
of software engineering practice. Nonetheless, I want to discuss, on
which API that I should be removing from user mode application
accesses and which one to retain.

Regards,
Darmawan



From darmawan.salihun at gmail.com  Wed Jun  6 17:50:02 2007
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Wed, 06 Jun 2007 22:50:02 +0700
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current device
	driver (testbed)
In-Reply-To: <4666D72F.1080201@gmail.com>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com>
Message-ID: <4666D7AA.9070204@gmail.com>

Sorry, I forgot the attachment previously.

Darmawan Salihun wrote:
> Hi all,
>     I attach the device driver code for my experimental flashrom port to
> windows back then. It's buggy, too much direct access, etc.
> But, it works at some points during my brief testing phase. It's based
> on the old flashrom version 1.23. I know, it's not a good example
> of software engineering practice. Nonetheless, I want to discuss, on
> which API that I should be removing from user mode application
> accesses and which one to retain.
>
> Regards,
> Darmawan
>
>   

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bios_probe.h
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/98aeeab0/attachment.h>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bios_probe.c
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/98aeeab0/attachment.c>

From info at coresystems.de  Wed Jun  6 17:54:02 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 06 Jun 2007 17:54:02 +0200
Subject: [LinuxBIOS] r2707 build service
Message-ID: <E1Hvxpi-0005ZU-I1@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2707 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Intel 82371EB: Some code simplifications (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2707&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2707&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2707&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2707&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2707&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From stuge-linuxbios at cdy.org  Wed Jun  6 18:00:03 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 6 Jun 2007 18:00:03 +0200
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current device
	driver (testbed)
In-Reply-To: <4666D72F.1080201@gmail.com>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com>
Message-ID: <20070606160003.22896.qmail@cdy.org>

On Wed, Jun 06, 2007 at 10:47:59PM +0700, Darmawan Salihun wrote:
> I know, it's not a good example of software engineering practice.
> Nonetheless, I want to discuss, on which API that I should be
> removing from user mode application accesses and which one to
> retain.

I couldn't make out much of it.

Again, I think the evolution goes like this:

1. Kernel driver allowing unrestricted reads and writes to top 16MB.

2. Kernel driver implementing the lowest level flash chip API.
 Possibly using some macro language so that reboot isn't neccessary
 to upgrade flash support.

API details can't really be that complicated until (2) but I don't
think we can get away from doing (1) first so no need to worry about
(2) yet.


//Peter



From darmawan.salihun at gmail.com  Wed Jun  6 18:16:03 2007
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Wed, 06 Jun 2007 23:16:03 +0700
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
 device	driver (testbed)
In-Reply-To: <20070606160003.22896.qmail@cdy.org>
References: <4666B03B.2060500@gmail.com>
	<4666B0F6.1060003@gmail.com>	<20070606130945.GA8454@countzero.vandewege.net>	<4666D72F.1080201@gmail.com>
	<20070606160003.22896.qmail@cdy.org>
Message-ID: <4666DDC3.1070607@gmail.com>

Peter Stuge wrote:
> On Wed, Jun 06, 2007 at 10:47:59PM +0700, Darmawan Salihun wrote:
>   
>> I know, it's not a good example of software engineering practice.
>> Nonetheless, I want to discuss, on which API that I should be
>> removing from user mode application accesses and which one to
>> retain.
>>     
>
> I couldn't make out much of it.
>
> Again, I think the evolution goes like this:
>
> 1. Kernel driver allowing unrestricted reads and writes to top 16MB.
>   
The current version of the driver code is capable of mapping *anywhere*
within the 4GB physical address space. It shouldn't be a problem
to restrict it to the top 16MB. Anyway, the "mapZone" in the previous
attached driver code represents a single contiguous physical memory range.
The logic of the mapping process is as follows:
 a. The physical memory address range is mapped into the kernel's
virtual memory address range
b. The kernel's virtual memory address range is then mapped to the
"requesting" user mode virtual memory address range.

> 2. Kernel driver implementing the lowest level flash chip API.
>  Possibly using some macro language so that reboot isn't neccessary
>  to upgrade flash support.
>   
Can you please elaborate more on this idea?

--Darmawan MS




From stuge-linuxbios at cdy.org  Wed Jun  6 18:25:13 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 6 Jun 2007 18:25:13 +0200
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <4666DDC3.1070607@gmail.com>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<4666DDC3.1070607@gmail.com>
Message-ID: <20070606162513.28598.qmail@cdy.org>

On Wed, Jun 06, 2007 at 11:16:03PM +0700, Darmawan Salihun wrote:
> > 1. Kernel driver allowing unrestricted reads and writes to top 16MB.
> 
> The current version of the driver code is capable of mapping
> *anywhere* within the 4GB physical address space. It shouldn't be a
> problem to restrict it to the top 16MB.

We should make that 2MB until we actually support larger flash parts
btw.


> The logic of the mapping process is as follows:
>  a. The physical memory address range is mapped into the kernel's
> virtual memory address range
> b. The kernel's virtual memory address range is then mapped to the
> "requesting" user mode virtual memory address range.

Sounds good.


> > 2. Kernel driver implementing the lowest level flash chip API.
> >  Possibly using some macro language so that reboot isn't neccessary
> >  to upgrade flash support.
> 
> Can you please elaborate more on this idea?

Still a hard limit of 2MB space in the kernel driver.

The application would "upload" a protocol description to the kernel
driver so that the kernel driver does not have to change just because
timing parameters or special byte values used in programming
sequences change for a newly added flash chips. In practise this idea
may turn out to allow just as much damage as (1) and in that case we
should just stick with (1).


//Peter



From info at coresystems.de  Wed Jun  6 18:43:20 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 06 Jun 2007 18:43:20 +0200
Subject: [LinuxBIOS] r2708 build service
Message-ID: <E1HvybQ-0001fk-1l@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2708 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Fix the static device tree of the Tyan S1846. Especially the
Super I/O part was incorrect.

Also, add ide0_enable/ide1_enable variables, and enable both the
primary and secondary IDE interface per default.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2708&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2708&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2708&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2708&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2708&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From otavio.junior at gmail.com  Wed Jun  6 18:55:19 2007
From: otavio.junior at gmail.com (=?ISO-8859-1?Q?Ot=E1vio_Alc=E2ntara?=)
Date: Wed, 6 Jun 2007 13:55:19 -0300
Subject: [LinuxBIOS] Problem with FILO
In-Reply-To: <20070604162930.9708.qmail@cdy.org>
References: <751d98080706010744h25bddc0fj854ec1d45c6737c3@mail.gmail.com>
	<20070604162930.9708.qmail@cdy.org>
Message-ID: <751d98080706060955t10af1601i6cc78ce8728863ec@mail.gmail.com>

Hello,

        Sorry, it was my bad. I wrong typed the address of option root (
root=/dev/hda insted of root=/dev/hda1 ) of FILO's 'Config' file.
        Thanks for the help,

Ot?vio

On 6/4/07, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
>
> On Fri, Jun 01, 2007 at 11:44:13AM -0300, Ot?vio Alc?ntara wrote:
> > Is possible to choose more than one file system, I mean, FAT and
> > EXT2?
>
> Yes, that should work just fine.
>
> Please try the patch I sent to the list a while ago and send back the
> debug output you get.
>
> Thanks!
>
>
> //Peter
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>



-- 
Ot?vio Alc?ntara
"I'll never cross to the Dark Side."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/6d775897/attachment.html>

From darmawan.salihun at gmail.com  Wed Jun  6 19:12:45 2007
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Thu, 07 Jun 2007 00:12:45 +0700
Subject: [LinuxBIOS] RFC Winflashrom Architecture --
 Current	device	driver (testbed)
In-Reply-To: <20070606162513.28598.qmail@cdy.org>
References: <4666B03B.2060500@gmail.com>
	<4666B0F6.1060003@gmail.com>	<20070606130945.GA8454@countzero.vandewege.net>	<4666D72F.1080201@gmail.com>
	<20070606160003.22896.qmail@cdy.org>	<4666DDC3.1070607@gmail.com>
	<20070606162513.28598.qmail@cdy.org>
Message-ID: <4666EB0D.8070004@gmail.com>

Peter Stuge wrote:
> On Wed, Jun 06, 2007 at 11:16:03PM +0700, Darmawan Salihun wrote:
>   
>>> 1. Kernel driver allowing unrestricted reads and writes to top 16MB.
>>>       
>> The current version of the driver code is capable of mapping
>> *anywhere* within the 4GB physical address space. It shouldn't be a
>> problem to restrict it to the top 16MB.
>>     
>
> We should make that 2MB until we actually support larger flash parts
> btw.
>
>   
ok, no problem.

>> The logic of the mapping process is as follows:
>>  a. The physical memory address range is mapped into the kernel's
>> virtual memory address range
>> b. The kernel's virtual memory address range is then mapped to the
>> "requesting" user mode virtual memory address range.
>>     
>
> Sounds good.
>
>   
For those interested in the driver code attached previously.
The bulk of the work is carried out in two functions, i.e. 

NTSTATUS MapMmio(PDEVICE_OBJECT pDO, PIRP pIrp)
/*++
Routine Description:
    Process the IRPs with IOCTL_MAP_MMIO code. 
    This routine maps a physical address range 
    to the usermode application address space. 
    
Arguments:
    pDO - pointer to the device object of this driver.
    pIrp - pointer to an I/O Request Packet.

Return Value:
    NT Status code

Notes:
    This function can only map the area 
    below the 4-GB limit.
--*/



and


NTSTATUS CleanupMmioMapping(PDEVICE_EXTENSION pDevExt, ULONG i)
/*++
Routine Description:
    This routine cleanup the mapping of a MMIO range 
    and resources it consumes.
    
Arguments:
    pDevExt - pointer to the device extension of the driver
    i - index of the mapZone to cleanup

Return Value:
    NT Status code
--*/


That's all for now.

--Darmawan Salihun





From info at coresystems.de  Wed Jun  6 19:32:11 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 06 Jun 2007 19:32:11 +0200
Subject: [LinuxBIOS] r2709 build service
Message-ID: <E1HvzMh-0006iT-Jc@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2709 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Tyan S1846: Minor fixes in static device tree (trivial):

 - Linux booted with the proprietary BIOS reports 2e.f as PS/2 mouse
   in the output of 'lspnp -v'.

 - The floppy on 2e.f was a typo, should have been 2e.e from the beginning.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2709&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2709&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2709&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2709&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2709&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From stuge-linuxbios at cdy.org  Wed Jun  6 19:59:50 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 6 Jun 2007 19:59:50 +0200
Subject: [LinuxBIOS] RFC Winflashrom Architecture --
	Current	device	driver (testbed)
In-Reply-To: <4666EB0D.8070004@gmail.com>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<4666DDC3.1070607@gmail.com> <20070606162513.28598.qmail@cdy.org>
	<4666EB0D.8070004@gmail.com>
Message-ID: <20070606175950.18791.qmail@cdy.org>

On Thu, Jun 07, 2007 at 12:12:45AM +0700, Darmawan Salihun wrote:
> NTSTATUS MapMmio(PDEVICE_OBJECT pDO, PIRP pIrp)
[..]
>     pDO - pointer to the device object of this driver.
>     pIrp - pointer to an I/O Request Packet.

Uff. What's wrong with void * ? I guess it's not the Windows way.


//Peter



From stuge-linuxbios at cdy.org  Wed Jun  6 20:02:33 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 6 Jun 2007 20:02:33 +0200
Subject: [LinuxBIOS] Problem with FILO
In-Reply-To: <751d98080706060955t10af1601i6cc78ce8728863ec@mail.gmail.com>
References: <751d98080706010744h25bddc0fj854ec1d45c6737c3@mail.gmail.com>
	<20070604162930.9708.qmail@cdy.org>
	<751d98080706060955t10af1601i6cc78ce8728863ec@mail.gmail.com>
Message-ID: <20070606180233.19494.qmail@cdy.org>

Hello Ot?vio,

On Wed, Jun 06, 2007 at 01:55:19PM -0300, Ot?vio Alc?ntara wrote:
>        Sorry, it was my bad. I wrong typed the address of option
> root (root=/dev/hda insted of root=/dev/hda1 ) of FILO's 'Config'
> file.
>        Thanks for the help,

So you confirm the patch works for you?

What hardware was this on again?

Thanks!


//Peter



From otavio.junior at gmail.com  Wed Jun  6 20:09:15 2007
From: otavio.junior at gmail.com (=?ISO-8859-1?Q?Ot=E1vio_Alc=E2ntara?=)
Date: Wed, 6 Jun 2007 15:09:15 -0300
Subject: [LinuxBIOS] Problem with FILO
In-Reply-To: <20070606180233.19494.qmail@cdy.org>
References: <751d98080706010744h25bddc0fj854ec1d45c6737c3@mail.gmail.com>
	<20070604162930.9708.qmail@cdy.org>
	<751d98080706060955t10af1601i6cc78ce8728863ec@mail.gmail.com>
	<20070606180233.19494.qmail@cdy.org>
Message-ID: <751d98080706061109v47290836o281cbe364cfbe19f@mail.gmail.com>

Hello Peter,

On 6/6/07, Peter Stuge <stuge-linuxbios at cdy.org> wrote:

> So you confirm the patch works for you?
> What hardware was this on again?

          I didn't use your patch and I've used the same board ( Geode 800
LX + CS5536 ) and a HD with Ubuntu 5.0 and Ext2 File System.
Thanks,

Ot?vio

On 6/6/07, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
>
> Hello Ot?vio,
>
> On Wed, Jun 06, 2007 at 01:55:19PM -0300, Ot?vio Alc?ntara wrote:
> >        Sorry, it was my bad. I wrong typed the address of option
> > root (root=/dev/hda insted of root=/dev/hda1 ) of FILO's 'Config'
> > file.
> >        Thanks for the help,
>
> So you confirm the patch works for you?
>
> What hardware was this on again?
>
> Thanks!
>
>
> //Peter
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>



-- 
Ot?vio Alc?ntara
"I'll never cross to the Dark Side."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/c87d8b7a/attachment.html>

From info at coresystems.de  Wed Jun  6 20:23:24 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 06 Jun 2007 20:23:24 +0200
Subject: [LinuxBIOS] r2710 build service
Message-ID: <E1Hw0AG-0003Gc-Ut@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2710 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Switch the Tyan S1846 to a fallback-only boot per default to allow
bigger payloads (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2710&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2710&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2710&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2710&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2710&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From uwe at hermann-uwe.de  Wed Jun  6 22:19:58 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 6 Jun 2007 22:19:58 +0200
Subject: [LinuxBIOS] [PATCH] flashrom: Improve CS5530/CS5530A support a bit
Message-ID: <20070606201958.GA14290@greenwood>

See patch.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_flashrom_cs5530.patch
Type: text/x-diff
Size: 2499 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/d5d971d0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/d5d971d0/attachment.sig>

From info at coresystems.de  Wed Jun  6 22:32:58 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 06 Jun 2007 22:32:58 +0200
Subject: [LinuxBIOS] r2711 build service
Message-ID: <E1Hw2Be-0005Ai-ML@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "stepan" checked in revision 2711 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add support for BCM HT1000 chipset to flashrom. Tested on IBM x3455.
(trivial)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2711&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2711&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2711&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2711&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2711&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From stefan.reinauer at coresystems.de  Wed Jun  6 20:24:13 2007
From: stefan.reinauer at coresystems.de (Stefan Reinauer)
Date: Wed, 06 Jun 2007 20:24:13 +0200
Subject: [LinuxBIOS] [RFC] i82801 generic patch
In-Reply-To: <46615A81.9080509@verizon.net>
References: <46615A81.9080509@verizon.net>
Message-ID: <4666FBCD.6010304@coresystems.de>

Corey Osgood wrote:
> The attached patch is a unified version of the current ports of the
> i82801 series currently in LinuxBIOS. Since most of the ports are nearly
> identical, I've taken for each file and chosen the cleanest or best
> version of the code, then checked over the datasheets to *some* of the
> series, including the aa, ba, ca, and db, to make sure that it would
> work. I've also made some changes here and there, mostly cleanup and
> clarification. The only things left to look at are the huge difference
> between this version's lpc init and the i82801er's, finding a better way
> to select which chip is present on the board, and gpl headers in all
> files. Anyways, comments, suggestions, even flames are welcome ;)
> Testing on other chips can be done at this point as well, this is tested
> and working on one model, the i82801aa.

Some ideas that could simplify the code:
[..]
+#elif 	I82801_MODEL == I82801ER
+#define	I82801_PCI	0x244e
+#define	I82801_LPC	0x24d0
+#define	I82801_IDE	0x24db
+#define	I82801_SATA	0x24df
[..]

You can also add several PCI driver structures in a driver, pointing to
the same PCI ops.

+static struct pci_driver pci_driver __pci_driver = {
+	.ops    = &pci_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = I82801_PCI,
+};

So you could add one of these for each supported component. Since each
pci_driver struct is only 8 bytes, the driver could be made to
completely autodetect which southbridge chip you are using without the
need for any #defines.

The only non-pci_driver use of the _MODEL #define is in
src/southbridge/intel/i82801xx/i82801xx_smbus.h
which is for smbus_write_block() which does not seem to be used, yet.

So my suggestion is to put an unconditional #warning there so that code
can be fixed if it should not work on a given ICH and is ever used.



Forgot to say:
Good work! Really nice!


Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/




From stepan at coresystems.de  Wed Jun  6 22:50:51 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 6 Jun 2007 22:50:51 +0200
Subject: [LinuxBIOS] [PATCH] flashrom: Improve CS5530/CS5530A support a
	bit
In-Reply-To: <20070606201958.GA14290@greenwood>
References: <20070606201958.GA14290@greenwood>
Message-ID: <20070606205050.GA24547@coresystems.de>

* Uwe Hermann <uwe at hermann-uwe.de> [070606 22:19]:
> See patch.
> 
> 
> Uwe.
> -- 
> http://www.hermann-uwe.de  | http://www.holsham-traders.de
> http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

> Fix up and document the AMD CS5530/CS5530A support in flashrom.
> 
> The previous code was pretty unreadable, undocumented and did some totally
> unrelated things (such as mucking with the game port or port 0x92).
> 
> This version is tested with a 256 KB chip and should work for the
> CS5530 and CS5530A.
> 
>Acked-by: Stefan Reinauer <stepan at coresystems.de>
 Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From info at coresystems.de  Wed Jun  6 23:26:28 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 06 Jun 2007 23:26:28 +0200
Subject: [LinuxBIOS] r2712 build service
Message-ID: <E1Hw31Q-0001Ol-Lm@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "stepan" checked in revision 2712 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Move GPIO settings to board specific code for IBM x3455

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2712&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2712&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2712&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2712&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2712&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From uwe at hermann-uwe.de  Wed Jun  6 23:34:36 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 6 Jun 2007 23:34:36 +0200
Subject: [LinuxBIOS] [PATCH] Reimplementation/fixing of CS5530/CS5530A
	southbridge code
Message-ID: <20070606213436.GB14290@greenwood>

See patch.

This is also required to make the JUKI-511P code work AFAICT (won't
build otherwise).


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_cs5530_rewrite.patch
Type: text/x-diff
Size: 15223 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/cc3132fb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/cc3132fb/attachment.sig>

From svn at openbios.org  Wed Jun  6 23:35:46 2007
From: svn at openbios.org (svn at openbios.org)
Date: Wed,  6 Jun 2007 23:35:46 +0200
Subject: [LinuxBIOS] r2715 - trunk/LinuxBIOSv2/util/flashrom
Message-ID: <mailman.384.1355071119.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-06 23:35:45 +0200 (Wed, 06 Jun 2007)
New Revision: 2715

Modified:
   trunk/LinuxBIOSv2/util/flashrom/README
   trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c
Log:
Fix up and document the AMD CS5530/CS5530A support in flashrom.

The previous code was pretty unreadable, undocumented and did some totally
unrelated things (such as mucking with the game port or port 0x92).

This version is tested with a 256 KB chip and should work for the
CS5530 and CS5530A.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/LinuxBIOSv2/util/flashrom/README
===================================================================
--- trunk/LinuxBIOSv2/util/flashrom/README	2007-06-06 10:26:00 UTC (rev 2714)
+++ trunk/LinuxBIOSv2/util/flashrom/README	2007-06-06 21:35:45 UTC (rev 2715)
@@ -150,7 +150,7 @@
 Supported Southbridges
 ----------------------
 
-AMD CS5530
+AMD CS5530/CS5530A
 AMD Geode SC1100
 AMD AMD-8111
 ATI SB400

Modified: trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c
===================================================================
--- trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c	2007-06-06 10:26:00 UTC (rev 2714)
+++ trunk/LinuxBIOSv2/util/flashrom/chipset_enable.c	2007-06-06 21:35:45 UTC (rev 2715)
@@ -183,19 +183,30 @@
 
 static int enable_flash_cs5530(struct pci_dev *dev, char *name)
 {
-	uint8_t new;
+	uint8_t reg8;
 
-	pci_write_byte(dev, 0x52, 0xee);
+	#define DECODE_CONTROL_REG2		0x5b	/* F0 index 0x5b */
+	#define ROM_AT_LOGIC_CONTROL_REG	0x52	/* F0 index 0x52 */
 
-	new = pci_read_byte(dev, 0x52);
+	#define LOWER_ROM_ADDRESS_RANGE		(1 << 0)
+	#define ROM_WRITE_ENABLE		(1 << 1)
+	#define UPPER_ROM_ADDRESS_RANGE		(1 << 2)
+	#define BIOS_ROM_POSITIVE_DECODE	(1 << 5)
 
-	if (new != 0xee) {
-		printf("tried to set register 0x%x to 0x%x on %s failed (WARNING ONLY)\n", 0x52, new, name);
-		return -1;
-	}
+	/* Decode 0x000E0000-0x000FFFFF (128 KB), not just 64 KB, and
+	 * decode 0xFF000000-0xFFFFFFFF (16 MB), not just 256 KB.
+	 * Make the configured ROM areas writable.
+	 */
+	reg8 = pci_read_byte(dev, ROM_AT_LOGIC_CONTROL_REG);
+	reg8 |= LOWER_ROM_ADDRESS_RANGE;
+	reg8 |= UPPER_ROM_ADDRESS_RANGE;
+	reg8 |= ROM_WRITE_ENABLE;
+	pci_write_byte(dev, ROM_AT_LOGIC_CONTROL_REG, reg8);
 
-	new = pci_read_byte(dev, 0x5b) | 0x20;
-	pci_write_byte(dev, 0x5b, new);
+	/* Set positive decode on ROM. */
+	reg8 = pci_read_byte(dev, DECODE_CONTROL_REG2);
+	reg8 |= BIOS_ROM_POSITIVE_DECODE;
+	pci_write_byte(dev, DECODE_CONTROL_REG2, reg8);
 
 	return 0;
 }
@@ -435,7 +446,7 @@
 	{0x1106, 0x3227, "VT8237", enable_flash_vt823x},
 	{0x1106, 0x8324, "CX700", enable_flash_vt823x},
 	{0x1106, 0x0686, "VT82C686", enable_flash_amd8111},
-	{0x1078, 0x0100, "CS5530", enable_flash_cs5530},
+	{0x1078, 0x0100, "CS5530/CS5530A", enable_flash_cs5530},
 	{0x100b, 0x0510, "SC1100", enable_flash_sc1100},
 	{0x1039, 0x0008, "SIS5595", enable_flash_sis5595},
 	{0x1022, 0x7468, "AMD8111", enable_flash_amd8111},




From uwe at hermann-uwe.de  Wed Jun  6 23:36:17 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 6 Jun 2007 23:36:17 +0200
Subject: [LinuxBIOS] [PATCH] flashrom: Improve CS5530/CS5530A support a
	bit
In-Reply-To: <20070606205050.GA24547@coresystems.de>
References: <20070606201958.GA14290@greenwood>
	<20070606205050.GA24547@coresystems.de>
Message-ID: <20070606213617.GC14290@greenwood>

On Wed, Jun 06, 2007 at 10:50:51PM +0200, Stefan Reinauer wrote:
> >Acked-by: Stefan Reinauer <stepan at coresystems.de>

Thanks, r2715.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/6bab028c/attachment.sig>

From stuge-linuxbios at cdy.org  Wed Jun  6 23:47:59 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 6 Jun 2007 23:47:59 +0200
Subject: [LinuxBIOS] r2715 - trunk/LinuxBIOSv2/util/flashrom
Message-ID: <20070606214759.25693.qmail@cdy.org>

On Wed, Jun 06, 2007 at 11:35:46PM +0200, svn at openbios.org wrote:
> The previous code was pretty unreadable, undocumented and did some
> totally unrelated things (such as mucking with the game port or
> port 0x92).

Did you check the data book? I can't find it or I would have checked.

I seem to recall 0x92 is used for this and that, not just the game
port.


//Peter



From uwe at hermann-uwe.de  Wed Jun  6 23:54:13 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 6 Jun 2007 23:54:13 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070606063631.GA3554@bloms.de>
References: <20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
	<20070604214846.GA14123@coresystems.de>
	<20070605060119.GA3225@bloms.de>
	<20070606002724.GB12985@coresystems.de>
	<20070606063631.GA3554@bloms.de>
Message-ID: <20070606215413.GD14290@greenwood>

On Wed, Jun 06, 2007 at 08:36:31AM +0200, Dieter Bloms wrote:
> I have tared my stuff, maybe someone is willing to have a look at it:
> 
> http://www.bloms.de/download/commell_lv671.tar.gz

Please always post (signed-off) patches, tarballs are hard to review and
comment on. 

In Config.lb you have

  option ROM_SIZE=512*1024+128*1024

which looks wrong. ROM_SIZE is the size of your chip, which is
probably 512*1024.

Issue 2:

  option USE_FALLBACK_IMAGE=0

should probably be set to 1. If you only use one image it has to be the
fallback image AFAIK, otherwise it won't work.


Other than that I cannot spot any obvious problems with the code, it
_should_ work, usually...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/99e7407a/attachment.sig>

From uwe at hermann-uwe.de  Wed Jun  6 23:57:40 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 6 Jun 2007 23:57:40 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070604214244.GA3257@bloms.de>
References: <20070531174928.f6d0h87gg4sck480@www.smittys.pointclark.net>
	<20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
Message-ID: <20070606215740.GE14290@greenwood>

On Mon, Jun 04, 2007 at 11:42:44PM +0200, Dieter Bloms wrote:
>         /* Setup the console */
>         w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE);
>         uart_init();
>         console_init();
>         print_err("Hello\n");

Are you sure your hardware setup is working otherwise? Can you leave the
null-modem cable attached as it is right now, but boot a normal Linux
system on both ends of the cable? Then run minicom, 115200 BAUD on both
sides, and test whether the trasmission itself works?

Do you use real serial ports or some USB-to-serial thingy? I had some
problems with these devices in the past, a real serial port might be
more reliable...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070606/22198027/attachment.sig>

From corey.osgood at gmail.com  Thu Jun  7 00:07:06 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Wed, 06 Jun 2007 18:07:06 -0400
Subject: [LinuxBIOS] [RFC] i82801 generic patch
In-Reply-To: <4666FBCD.6010304@coresystems.de>
References: <46615A81.9080509@verizon.net> <4666FBCD.6010304@coresystems.de>
Message-ID: <4667300A.5080908@gmail.com>

Stefan Reinauer wrote:
> Corey Osgood wrote:
>   
>> The attached patch is a unified version of the current ports of the
>> i82801 series currently in LinuxBIOS. Since most of the ports are nearly
>> identical, I've taken for each file and chosen the cleanest or best
>> version of the code, then checked over the datasheets to *some* of the
>> series, including the aa, ba, ca, and db, to make sure that it would
>> work. I've also made some changes here and there, mostly cleanup and
>> clarification. The only things left to look at are the huge difference
>> between this version's lpc init and the i82801er's, finding a better way
>> to select which chip is present on the board, and gpl headers in all
>> files. Anyways, comments, suggestions, even flames are welcome ;)
>> Testing on other chips can be done at this point as well, this is tested
>> and working on one model, the i82801aa.
>>     
>
> Some ideas that could simplify the code:
> [..]
> +#elif 	I82801_MODEL == I82801ER
> +#define	I82801_PCI	0x244e
> +#define	I82801_LPC	0x24d0
> +#define	I82801_IDE	0x24db
> +#define	I82801_SATA	0x24df
> [..]
>
> You can also add several PCI driver structures in a driver, pointing to
> the same PCI ops.
>
> +static struct pci_driver pci_driver __pci_driver = {
> +	.ops    = &pci_ops,
> +	.vendor = PCI_VENDOR_ID_INTEL,
> +	.device = I82801_PCI,
> +};
>
> So you could add one of these for each supported component. Since each
> pci_driver struct is only 8 bytes, the driver could be made to
> completely autodetect which southbridge chip you are using without the
> need for any #defines.
>   
Cool! I didn't even think about that, I'll rework it.
> The only non-pci_driver use of the _MODEL #define is in
> src/southbridge/intel/i82801xx/i82801xx_smbus.h
> which is for smbus_write_block() which does not seem to be used, yet.
>
>   
enable_smbus uses it as well, but both could be handled by using a
static device instead of probing. As long as the code is used with an
ICH-series, the smbus is always at the same location.
> So my suggestion is to put an unconditional #warning there so that code
> can be fixed if it should not work on a given ICH and is ever used.
>
> Forgot to say:
> Good work! Really nice!
Thanks!

-Corey



From uwe at hermann-uwe.de  Thu Jun  7 00:12:22 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 7 Jun 2007 00:12:22 +0200
Subject: [LinuxBIOS] r2715 - trunk/LinuxBIOSv2/util/flashrom
In-Reply-To: <20070606214759.25693.qmail@cdy.org>
References: <20070606214759.25693.qmail@cdy.org>
Message-ID: <20070606221222.GF14290@greenwood>

On Wed, Jun 06, 2007 at 11:47:59PM +0200, Peter Stuge wrote:
> On Wed, Jun 06, 2007 at 11:35:46PM +0200, svn at openbios.org wrote:
> > The previous code was pretty unreadable, undocumented and did some
> > totally unrelated things (such as mucking with the game port or
> > port 0x92).
> 
> Did you check the data book? I can't find it or I would have checked.

Yep, it's here: http://www.national.com/ds.cgi/CS/CS5530A.pdf

This is for flashrom, which only needs to make the ROM readable and
writable. No need for random other stuff (game port, etc).


> I seem to recall 0x92 is used for this and that, not just the game
> port.

Yeah, I think port 0x92 can reboot/reset the system or something alike.
The code was not _using_ port 0x92, though, but rather _enabling_ it
to be used by the OS (or whomever). All of this is not needed in
flashrom, of course.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070607/f56ed529/attachment.sig>

From info at coresystems.de  Thu Jun  7 00:17:50 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Thu, 07 Jun 2007 00:17:50 +0200
Subject: [LinuxBIOS] r2713 build service
Message-ID: <E1Hw3p8-0006dJ-OZ@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2713 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
flashrom: Document the newly supported IBM x3455 board and the
now-supported Broadcom HT-1000 chipset (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2713&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2713&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2713&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2713&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2713&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From darmawan.salihun at gmail.com  Thu Jun  7 00:28:28 2007
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Thu, 07 Jun 2007 05:28:28 +0700
Subject: [LinuxBIOS] RFC Winflashrom Architecture
 --	Current	device	driver (testbed)
In-Reply-To: <20070606175950.18791.qmail@cdy.org>
References: <4666B03B.2060500@gmail.com>
	<4666B0F6.1060003@gmail.com>	<20070606130945.GA8454@countzero.vandewege.net>	<4666D72F.1080201@gmail.com>
	<20070606160003.22896.qmail@cdy.org>	<4666DDC3.1070607@gmail.com>
	<20070606162513.28598.qmail@cdy.org>	<4666EB0D.8070004@gmail.com>
	<20070606175950.18791.qmail@cdy.org>
Message-ID: <4667350C.40105@gmail.com>

Peter Stuge wrote:
> On Thu, Jun 07, 2007 at 12:12:45AM +0700, Darmawan Salihun wrote:
>   
>> NTSTATUS MapMmio(PDEVICE_OBJECT pDO, PIRP pIrp)
>>     
> [..]
>   
>>     pDO - pointer to the device object of this driver.
>>     pIrp - pointer to an I/O Request Packet.
>>     
>
> Uff. What's wrong with void * ? I guess it's not the Windows way.
>
>   
Yeah. That's how it is. So much Microsoft-defined data structures in the
device driver. It's just not save to use void * because of it.
Almost everything has their "accessor" functions, i.e. predefined way of
using. If we don't conform it may not work.

--Darmawan Salihun



From stepan at coresystems.de  Thu Jun  7 00:39:47 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 7 Jun 2007 00:39:47 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070606215740.GE14290@greenwood>
References: <20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de> <20070606215740.GE14290@greenwood>
Message-ID: <20070606223947.GA4413@coresystems.de>

* Uwe Hermann <uwe at hermann-uwe.de> [070606 23:57]:
> Are you sure your hardware setup is working otherwise? Can you leave the
> null-modem cable attached as it is right now, but boot a normal Linux
> system on both ends of the cable? Then run minicom, 115200 BAUD on both
> sides, and test whether the trasmission itself works?
 
The south bridge code needs not only the SuperIO ports enabled but also
the COM1/COM2 ports. I think Corey's unified ICH code does this.


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From info at coresystems.de  Thu Jun  7 01:10:12 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Thu, 07 Jun 2007 01:10:12 +0200
Subject: [LinuxBIOS] r2714 build service
Message-ID: <E1Hw4do-0002kV-Cq@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2714 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add support for the Winbond W83977F-A Super I/O.

Signed-off-by: Nikolay Petukhov <nikolay.petukhov at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2714&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2714&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2714&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2714&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2714&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From svn at openbios.org  Thu Jun  7 01:43:11 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  7 Jun 2007 01:43:11 +0200
Subject: [LinuxBIOS] r347 - LinuxBIOSv3/southbridge/amd/cs5536
Message-ID: <mailman.385.1355071119.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-07 01:43:11 +0200 (Thu, 07 Jun 2007)
New Revision: 347

Modified:
   LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c
Log:
Various cosmetic fixes (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c
===================================================================
--- LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c	2007-06-05 21:01:05 UTC (rev 346)
+++ LinuxBIOSv3/southbridge/amd/cs5536/cs5536_early_setup.c	2007-06-06 23:43:11 UTC (rev 347)
@@ -1,71 +1,75 @@
 /*
-* This file is part of the LinuxBIOS project.
-*
-* Copyright (C) 2007 Advanced Micro Devices
-*
-* This program is free software; you can redistribute it and/or modify
-* it under the terms of the GNU General Public License version 2 as
-* published by the Free Software Foundation.
-*
-* This program is distributed in the hope that it will be useful,
-* but WITHOUT ANY WARRANTY; without even the implied warranty of
-* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-* GNU General Public License for more details.
-*
-* You should have received a copy of the GNU General Public License
-* along with this program; if not, write to the Free Software
-* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
-*/
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 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 version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
 #include <console.h>
 #include <io.h>
 #include <msr.h>
 #include <amd_geodelx.h>
 #include "cs5536.h"
+
 /*
- * cs5536_early_setup.c:Early chipset initialization for CS5536 companion device
- * This code is needed for setting up ram, since we need SMBUS working as
- * well as serial port.
- * This file implements the initialization sequence documented in section 4.2 of
- * AMD Geode GX Processor CS5536 Companion Device GoedeROM Porting Guide.
+ * Early chipset initialization for the AMD CS5536 Companion Device.
+ *
+ * This code is needed for setting up RAM, since we need SMBus working as
+ * well as a serial port.
+ *
+ * This file implements the initialization sequence documented in section 4.2
+ * of AMD Geode GX Processor CS5536 Companion Device GoedeROM Porting Guide.
  */
 
 /**
- * @brief Set up GLINK routing for this part. The routing is controlled by an MSR.
- * This appears to be the
- * same on all boards.
- * If you don't know what GLINK routing is, there is no way to explain it here.
+ * Set up GLINK routing for this part.
+ *
+ * The routing is controlled by an MSR. This appears to be the same on
+ * all boards.
  */
 void cs5536_setup_extmsr(void)
 {
 	msr_t msr;
 
-	/* forward MSR access to CS5536_GLINK_PORT_NUM to CS5536_DEV_NUM */
+	/* Forward MSR access to CS5536_GLINK_PORT_NUM to CS5536_DEV_NUM. */
 	msr.hi = msr.lo = 0x00000000;
-#if  CS5536_GLINK_PORT_NUM <= 4
+
+#if CS5536_GLINK_PORT_NUM <= 4
 	msr.lo = CS5536_DEV_NUM <<
-		(unsigned char)((CS5536_GLINK_PORT_NUM - 1) * 8);
+	    (unsigned char)((CS5536_GLINK_PORT_NUM - 1) * 8);
 #else
 	msr.hi = CS5536_DEV_NUM <<
-		(unsigned char)((CS5536_GLINK_PORT_NUM - 5) * 8);
+	    (unsigned char)((CS5536_GLINK_PORT_NUM - 5) * 8);
 #endif
+
 	wrmsr(GLPCI_ExtMSR, msr);
 }
 
 /**
- * @brief Setup PCI IDSEL for CS5536. There is a Magic Register that must be
+ * Setup PCI IDSEL for CS5536. There is a Magic Register that must be
  * written so that the chip appears at the expected place in the PCI tree.
  */
 void cs5536_setup_idsel(void)
 {
-	/* write IDSEL to the write once register at address 0x0000 */
+	/* Write IDSEL to the write once register at address 0x0000. */
 	outl(0x1 << (CS5536_DEV_NUM + 10), 0);
 }
 
 /**
- * @brief Magic Bits for undocumented register.
- * You don' t need to see those papers.
- * These are not the bits you're looking for.
- * You can go about your business.
+ * Magic Bits for undocumented register. You don't need to see those papers.
+ * These are not the bits you're looking for. You can go about your business.
  * Move along, move along.
  */
 void cs5536_usb_swapsif(void)
@@ -73,57 +77,61 @@
 	msr_t msr;
 
 	msr = rdmsr(USB1_SB_GLD_MSR_CAP + 0x5);
-	//USB Serial short detect bit.
+
+	/* USB Serial short detect bit. */
 	if (msr.hi & 0x10) {
 		/* We need to preserve bits 32,33,35 and not clear any BIST
-		 * error, but clear the SERSHRT error bit */
-
+		 * error, but clear the SERSHRT error bit.
+		 */
 		msr.hi &= 0xFFFFFFFB;
 		wrmsr(USB1_SB_GLD_MSR_CAP + 0x5, msr);
 	}
 }
 
 /**
- * @brief Set up IO bases for SMBUS, GPIO, MFGPT, ACPI, and PM.
- * These can be changed by Linux later. We set some initial value so
- * that the resources are there as needed.
- * The values are hardcoded because, this early in the process, fancy
- * allocation can do more harm than good.
+ * Set up I/O bases for SMBus, GPIO, MFGPT, ACPI, and PM.
+ *
+ * These can be changed by Linux later. We set some initial value so that
+ * the resources are there as needed. The values are hardcoded because,
+ * this early in the process, fancy allocation can do more harm than good.
  */
 void cs5536_setup_iobase(void)
 {
 	msr_t msr;
-	/* setup LBAR for SMBus controller */
+
+	/* Setup LBAR for SMBus controller. */
 	msr.hi = 0x0000f001;
 	msr.lo = SMBUS_IO_BASE;
 	wrmsr(MDD_LBAR_SMB, msr);
 
-	/* setup LBAR for GPIO */
+	/* Setup LBAR for GPIO. */
 	msr.hi = 0x0000f001;
 	msr.lo = GPIO_IO_BASE;
 	wrmsr(MDD_LBAR_GPIO, msr);
 
-	/* setup LBAR for MFGPT */
+	/* Setup LBAR for MFGPT. */
 	msr.hi = 0x0000f001;
 	msr.lo = MFGPT_IO_BASE;
 	wrmsr(MDD_LBAR_MFGPT, msr);
 
-	/* setup LBAR for ACPI */
+	/* Setup LBAR for ACPI. */
 	msr.hi = 0x0000f001;
 	msr.lo = ACPI_IO_BASE;
 	wrmsr(MDD_LBAR_ACPI, msr);
 
-	/* setup LBAR for PM Support */
+	/* Setup LBAR for PM support. */
 	msr.hi = 0x0000f001;
 	msr.lo = PMS_IO_BASE;
 	wrmsr(MDD_LBAR_PMS, msr);
 }
 
 /**
- * @brief Power Button Setup
- * setup GPIO24, it is the external signal for 5536 vsb_work_aux
- * which controls all voltage rails except Vstandby & Vmem.
- * We need to enable, OUT_AUX1 and OUTPUT_ENABLE in this order.
+ * Power Button Setup.
+ *
+ * Setup GPIO24, it is the external signal for CS5536 vsb_work_aux which
+ * controls all voltage rails except Vstandby & Vmem. We need to enable,
+ * OUT_AUX1 and OUTPUT_ENABLE in this order.
+ *
  * If GPIO24 is not enabled then soft-off will not work.
  */
 void cs5536_setup_power_button(void)
@@ -131,39 +139,45 @@
 	outl(0x40020000, PMS_IO_BASE + 0x40);
 	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUT_AUX1_SELECT);
 	outl(GPIOH_24_SET, GPIO_IO_BASE + GPIOH_OUTPUT_ENABLE);
-
 }
 
 /**
- * @brief Set the various GPIOs. An unknown question at this point is
- * how general this is to all mainboards. At the same time, many
- * boards seem to follow this particular reference spec.
+ * Set the various GPIOs.
+ *
+ * An unknown question at this point is how general this is to all mainboards.
+ * At the same time, many boards seem to follow this particular reference spec.
  */
 void cs5536_setup_smbus_gpio(void)
 {
 	u32 val;
 
-	/* setup GPIO pins 14/15 for SDA/SCL */
+	/* Setup GPIO pins 14/15 for SDA/SCL. */
 	val = GPIOL_15_SET | GPIOL_14_SET;
+
 	/* Output Enable */
 	outl(val, GPIO_IO_BASE + GPIOL_OUT_AUX1_SELECT);
+
 	/* Output AUX1 */
 	outl(val, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
+
 	/* Input Enable */
 	outl(val, GPIO_IO_BASE + GPIOL_IN_AUX1_SELECT);
+
 	/* Input AUX1 */
 	outl(val, GPIO_IO_BASE + GPIOL_INPUT_ENABLE);
 }
 
 /**
- * @brief Disable the internal UART.
+ * Disable the internal UART.
+ *
  * Different boards have different UARTs for COM1.
  */
 void cs5536_disable_internal_uart(void)
 {
 	msr_t msr;
+
 	/* The UARTs default to enabled.
-	 * Disable and reset them and configure them later. (SIO init)
+	 * Disable and reset them and configure them later (SIO init).
 	 */
 	msr = rdmsr(MDD_UART1_CONF);
 	msr.lo = 1;		// reset
@@ -179,15 +193,17 @@
 }
 
 /**
- * @brief Set up the cs5536 CIS interface to CPU  interface to match modes.
- * The CIS is related to the interrupt system. It is important to match the
- * south and the cpu chips. At the same time, they always seem to use mode B.
+ * Set up the CS5536 CIS interface to CPU interface to match modes.
+ *
+ * The CIS is related to the interrupt system. It is important to match
+ * the southbridge and the CPU chips. At the same time, they always seem
+ * to use mode B.
  */
 void cs5536_setup_cis_mode(void)
 {
 	msr_t msr;
 
-	/* setup CPU interface serial to mode B to match CPU */
+	/* Setup CPU interface serial to mode B to match CPU. */
 	msr = rdmsr(GLPCI_SB_CTRL);
 	msr.lo &= ~0x18;
 	msr.lo |= 0x10;
@@ -195,92 +211,89 @@
 }
 
 /**
- * @brief Enable the on chip UART.see page 412 of the cs5536 companion book
+ * Enable the on chip UART.
+ *
+ * See page 412 of the AMD Geode CS5536 Companion Device data book.
  */
 void cs5536_setup_onchipuart(void)
 {
 	msr_t msr;
 
 	/* Setup early for polling only mode.
-	 * 1. Eanble GPIO 8 to OUT_AUX1, 9 to IN_AUX1
+	 * 1. Eanble GPIO 8 to OUT_AUX1, 9 to IN_AUX1.
 	 *        GPIO LBAR + 0x04, LBAR + 0x10, LBAR + 0x20, LBAR + 34
-	 * 2. Enable UART IO space in MDD
+	 * 2. Enable UART I/O space in MDD.
 	 *        MSR 0x51400014 bit 18:16
-	 * 3. Enable UART controller
+	 * 3. Enable UART controller.
 	 *        MSR 0x5140003A bit 0, 1
 	 */
 
 	/* GPIO8 - UART1_TX */
-	/* Set: Output Enable  (0x4) */
+	/* Set: Output Enable (0x4) */
 	outl(GPIOL_8_SET, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
 	/* Set: OUTAUX1 Select (0x10) */
 	outl(GPIOL_8_SET, GPIO_IO_BASE + GPIOL_OUT_AUX1_SELECT);
+
 	/* GPIO9 - UART1_RX */
-	/* Set: Input Enable   (0x20) */
+	/* Set: Input Enable (0x20) */
 	outl(GPIOL_9_SET, GPIO_IO_BASE + GPIOL_INPUT_ENABLE);
-	/* Set: INAUX1 Select  (0x34) */
+	/* Set: INAUX1 Select (0x34) */
 	outl(GPIOL_9_SET, GPIO_IO_BASE + GPIOL_IN_AUX1_SELECT);
 
-	/* set address to 3F8 */
+	/* Set address to 0x3F8. */
 	msr = rdmsr(MDD_LEG_IO);
 	msr.lo |= 0x7 << 16;
 	wrmsr(MDD_LEG_IO, msr);
 
-	/*      Bit 1 = DEVEN (device enable)
-	 *      Bit 4 = EN_BANKS (allow access to the upper banks
+	/* Bit 1 = DEVEN (device enable)
+	 * Bit 4 = EN_BANKS (allow access to the upper banks)
 	 */
 	msr.lo = (1 << 4) | (1 << 1);
 	msr.hi = 0;
 
-	/* enable COM1 */
+	/* Enable COM1. */
 	wrmsr(MDD_UART1_CONF, msr);
 }
 
-
 /**
- * @brief Board setup. Known to work on norwich and digitial logic boards.
- * The extmsr and cis_mode are common for sure.
- * The RSTPLL check is mandatory.
- * IDSEl of course is required, so the chip appears in PCI config space,
+ * Board setup.
+ *
+ * Known to work on the AMD Norwich and DIGITIAL-LOGIC boards.
+ *
+ * The extmsr and cis_mode are common for sure. The RSTPLL check is mandatory.
+ * IDSEL of course is required, so the chip appears in PCI config space,
  * and the swapsif covers a necessary chip fix.
- * Finally, the iobase is needed for DRAM, the GPIOs
- * are likely common to all boards, and the power button
- * seems to be the same on all. At the same time,
- * we may need to move gpio and power button
- * out as developments demand.
- * Note we do NOT do any UART
- * setup here -- this is done later by the mainboard setup,
- * since UART usage is not universal.
- * A comment from Marc Jones:
-	"It
-	would be difficult to move this to early mainboard (car_auto) because
-	the IObase needs to be setup first and then SMBus setup would be
-	optional etc. I think that any platform that uses the SMBus GPIOs for
-	something other than SMBus will need a lot of customization anyway and
-	they would have to override the generic file. I understand the desire to
-	make everything generic but that really over complicates 99% of the
-	designs."
+ *
+ * Finally, the iobase is needed for DRAM, the GPIOs are likely common to all
+ * boards, and the power button seems to be the same on all. At the same time,
+ * we may need to move GPIO and power button out as developments demand.
+ *
+ * Note we do NOT do any UART setup here -- this is done later by the
+ * mainboard setup, since UART usage is not universal.
+ *
+ * See also a comment from Marc Jones:
+ * http://www.linuxbios.org/pipermail/linuxbios/2007-June/021958.html
  */
 void cs5536_early_setup(void)
 {
 	msr_t msr;
 
-	/* note: you can't do prints in here in most cases,
-	 * and we don't want to hang on serial, so they are
-	 * commented out
- 	*/
+	/* Note: you can't do prints in here in most cases, and we don't want
+	 * to hang on serial, so they are commented out.
+	 */
 	cs5536_setup_extmsr();
 	cs5536_setup_cis_mode();
 
 	msr = rdmsr(GLCP_SYS_RSTPLL);
 	if (msr.lo & (0x3f << 26)) {
-		/* PLL is already set and we are reboot from PLL reset */
+		/* PLL is already set and we are reboot from PLL reset. */
 		return;
 	}
+
 	cs5536_setup_idsel();
 	cs5536_usb_swapsif();
 	cs5536_setup_iobase();
 	cs5536_setup_smbus_gpio();
-	/* cs5536_enable_smbus(); -- leave this out for now */
+	/* cs5536_enable_smbus(); -- Leave this out for now. */
 	cs5536_setup_power_button();
 }




From info at coresystems.de  Thu Jun  7 02:00:16 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Thu, 07 Jun 2007 02:00:16 +0200
Subject: [LinuxBIOS] r2715 build service
Message-ID: <E1Hw5QG-0007RL-K0@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2715 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Fix up and document the AMD CS5530/CS5530A support in flashrom.

The previous code was pretty unreadable, undocumented and did some totally
unrelated things (such as mucking with the game port or port 0x92).

This version is tested with a 256 KB chip and should work for the
CS5530 and CS5530A.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2715&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2715&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2715&device=e326&vendor=ibm
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2715&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2715&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From svn at openbios.org  Thu Jun  7 02:07:41 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  7 Jun 2007 02:07:41 +0200
Subject: [LinuxBIOS] r348 - in LinuxBIOSv3: device southbridge/amd/cs5536
	util/x86emu/pcbios
Message-ID: <mailman.386.1355071119.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-07 02:07:39 +0200 (Thu, 07 Jun 2007)
New Revision: 348

Modified:
   LinuxBIOSv3/device/device.c
   LinuxBIOSv3/device/pci_device.c
   LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c
   LinuxBIOSv3/util/x86emu/pcbios/pcibios.h
Log:
Fix various Doxygen warnings (trivial).

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: LinuxBIOSv3/device/device.c
===================================================================
--- LinuxBIOSv3/device/device.c	2007-06-06 23:43:11 UTC (rev 347)
+++ LinuxBIOSv3/device/device.c	2007-06-07 00:07:39 UTC (rev 348)
@@ -166,6 +166,7 @@
  *
  * @param parent Parent bus the newly created device is attached to.
  * @param path Path to the device to be created.
+ * @param devid TODO
  * @return Pointer to the newly created device structure.
  * @see device_path
  */
@@ -739,7 +740,7 @@
  * bridges. If the setting up and tuning of the bus causes a reset to be
  * required, reset the bus and scan it again.
  *
- * @param bus Pointer to the bus device.
+ * @param busdevice Pointer to the bus device.
  * @param max Current bus number.
  * @return The maximum bus number found, after scanning all subordinate buses.
  */

Modified: LinuxBIOSv3/device/pci_device.c
===================================================================
--- LinuxBIOSv3/device/pci_device.c	2007-06-06 23:43:11 UTC (rev 347)
+++ LinuxBIOSv3/device/pci_device.c	2007-06-07 00:07:39 UTC (rev 348)
@@ -150,7 +150,6 @@
  * Given a device and register, read the size of the BAR for that register. 
  *
  * @param dev Pointer to the device structure.
- * @param resource Pointer to the resource structure.
  * @param index Address of the PCI configuration register.
  */
 struct resource *pci_get_resource(struct device *dev, unsigned long index)

Modified: LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c
===================================================================
--- LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c	2007-06-06 23:43:11 UTC (rev 347)
+++ LinuxBIOSv3/southbridge/amd/cs5536/smbus_initram.c	2007-06-07 00:07:39 UTC (rev 348)
@@ -249,7 +249,7 @@
  *
  * @param smbus_io_base The SMBus I/O base.
  * @param device The device.
- * @param command The command.
+ * @param address The address.
  * @return The data from the SMBus packet area.
  */
 static u8 do_smbus_read_byte(u16 smbus_io_base, u8 device, u8 address)
@@ -315,7 +315,7 @@
  * one thing -- calling this function to read DRAM parameters.
  *
  * @param device The device.
- * @param command The command.
+ * @param address The address.
  * @return The data from the SMBus packet area or an error of 0xff (i.e. -1).
  */
 int smbus_read_byte(u16 device, u8 address)

Modified: LinuxBIOSv3/util/x86emu/pcbios/pcibios.h
===================================================================
--- LinuxBIOSv3/util/x86emu/pcbios/pcibios.h	2007-06-06 23:43:11 UTC (rev 347)
+++ LinuxBIOSv3/util/x86emu/pcbios/pcibios.h	2007-06-07 00:07:39 UTC (rev 348)
@@ -34,7 +34,9 @@
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
- */#ifndef PCI_BIOS_H
+ */
+
+#ifndef PCI_BIOS_H
 #define PCI_BIOS_H
 
 enum {




From uwe at hermann-uwe.de  Thu Jun  7 02:14:47 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 7 Jun 2007 02:14:47 +0200
Subject: [LinuxBIOS] [PATCH] Fix static device tree of ASI MB-5BLMP target
Message-ID: <20070607001446.GA14920@greenwood>

See patch.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_asi_mb_5blmp_devicetree.patch
Type: text/x-diff
Size: 4066 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070607/d50a71a3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070607/d50a71a3/attachment.sig>

From dieter at bloms.de  Thu Jun  7 08:29:03 2007
From: dieter at bloms.de (Dieter Bloms)
Date: Thu, 7 Jun 2007 08:29:03 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070606215740.GE14290@greenwood>
References: <20070601052108.GB3251@bloms.de>
	<20070601211739.yh1861s000kg4c48@www.smittys.pointclark.net>
	<20070602123541.GD3251@bloms.de>
	<20070602101721.grbroc58ysswwo40@www.smittys.pointclark.net>
	<20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de> <20070606215740.GE14290@greenwood>
Message-ID: <20070607062903.GA4091@bloms.de>

Hi Uwe,

On Wed, Jun 06, Uwe Hermann wrote:

> On Mon, Jun 04, 2007 at 11:42:44PM +0200, Dieter Bloms wrote:
> >         /* Setup the console */
> >         w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE);
> >         uart_init();
> >         console_init();
> >         print_err("Hello\n");
> 
> Are you sure your hardware setup is working otherwise? Can you leave the
> null-modem cable attached as it is right now, but boot a normal Linux
> system on both ends of the cable? Then run minicom, 115200 BAUD on both
> sides, and test whether the trasmission itself works?

it works, because my system is connected via wlan and sometimes the
driver hangs up.
Then I log in via serial cable and reload the driver.

> Do you use real serial ports or some USB-to-serial thingy? I had some
> problems with these devices in the past, a real serial port might be
> more reliable...

yes there are real serial drivers on both sides.


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070607/5ed8324d/attachment.sig>

From dieter at bloms.de  Thu Jun  7 08:34:19 2007
From: dieter at bloms.de (Dieter Bloms)
Date: Thu, 7 Jun 2007 08:34:19 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070606215413.GD14290@greenwood>
References: <20070603193827.GC15426@greenwood> <466440C3.6040809@amd.com>
	<20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
	<20070604214846.GA14123@coresystems.de>
	<20070605060119.GA3225@bloms.de>
	<20070606002724.GB12985@coresystems.de>
	<20070606063631.GA3554@bloms.de> <20070606215413.GD14290@greenwood>
Message-ID: <20070607063419.GB4091@bloms.de>

Hi,

On Wed, Jun 06, Uwe Hermann wrote:

> On Wed, Jun 06, 2007 at 08:36:31AM +0200, Dieter Bloms wrote:
> > I have tared my stuff, maybe someone is willing to have a look at it:
> > 
> > http://www.bloms.de/download/commell_lv671.tar.gz
> 
> Please always post (signed-off) patches, tarballs are hard to review and
> comment on. 

ok, I will do it in future.

> In Config.lb you have
> 
>   option ROM_SIZE=512*1024+128*1024
> 
> which looks wrong. ROM_SIZE is the size of your chip, which is
> probably 512*1024.

without +128*1024 I got a to liddle rom file, but I will correct this
and will see, where to change values to get the right rom sizes.
I saw this by another motherboards like tyan/s2850 board

> Issue 2:
> 
>   option USE_FALLBACK_IMAGE=0
> 
> should probably be set to 1. If you only use one image it has to be the
> fallback image AFAIK, otherwise it won't work.

ok, will change that.

> Other than that I cannot spot any obvious problems with the code, it
> _should_ work, usually...


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070607/db3d5a36/attachment.sig>

From uwe at hermann-uwe.de  Thu Jun  7 13:20:11 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 7 Jun 2007 13:20:11 +0200
Subject: [LinuxBIOS] Added mainboard commell/lv671 and compile works,
	but ...
In-Reply-To: <20070607063419.GB4091@bloms.de>
References: <466440C3.6040809@amd.com> <20070604173602.GE3251@bloms.de>
	<20070604193708.GB9114@coresystems.de>
	<20070604214244.GA3257@bloms.de>
	<20070604214846.GA14123@coresystems.de>
	<20070605060119.GA3225@bloms.de>
	<20070606002724.GB12985@coresystems.de>
	<20070606063631.GA3554@bloms.de> <20070606215413.GD14290@greenwood>
	<20070607063419.GB4091@bloms.de>
Message-ID: <20070607112011.GD14920@greenwood>

On Thu, Jun 07, 2007 at 08:34:19AM +0200, Dieter Bloms wrote:
> > which looks wrong. ROM_SIZE is the size of your chip, which is
> > probably 512*1024.
> 
> without +128*1024 I got a to liddle rom file, but I will correct this
> and will see, where to change values to get the right rom sizes.

I think you need something like this:

option ROM_SIZE=512*1024
option FALLBACK_SIZE=ROM_SIZE

Yeah, this sizing stuff is highly confusing and unintuitive. It will all
be gone in LinuxBIOSv3 which will be a lot easier to use...


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070607/835c64af/attachment.sig>

From svn at openbios.org  Thu Jun  7 19:34:17 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  7 Jun 2007 19:34:17 +0200
Subject: [LinuxBIOS] r349 - LinuxBIOSv3/include
Message-ID: <mailman.387.1355071119.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2007-06-07 19:34:17 +0200 (Thu, 07 Jun 2007)
New Revision: 349

Modified:
   LinuxBIOSv3/include/lib.h
Log:

prototypes for dram and smbus functions.
We are experimenting a bit here; we are going to put all protos for
lib/*.c into this file. Experience has shown this will not be a large
or messy set of protos. Plan 9 has used this technique and it works
well, as it avoids 100 files with one prototype per file.
If you can't trust Ken Thompson, who can you trust?

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Peter Stuge <peter at stuge.se>




Modified: LinuxBIOSv3/include/lib.h
===================================================================
--- LinuxBIOSv3/include/lib.h	2007-06-07 00:07:39 UTC (rev 348)
+++ LinuxBIOSv3/include/lib.h	2007-06-07 17:34:17 UTC (rev 349)
@@ -30,4 +30,11 @@
 void beep_short(void);
 void beep_long(void);
 
+/* smbus functions */
+int smbus_read_byte(unsigned device, unsigned address);
+
+/* dram functions */
+void ram_failure(const char *why);
+void ram_initialize(int controllers, void *ctrl);
+
 #endif /* LIB_H */




From stuge-linuxbios at cdy.org  Thu Jun  7 19:37:27 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu, 7 Jun 2007 19:37:27 +0200
Subject: [LinuxBIOS] r349 - LinuxBIOSv3/include
Message-ID: <20070607173727.19844.qmail@cdy.org>

On Thu, Jun 07, 2007 at 07:34:17PM +0200, svn at openbios.org wrote:
> +void ram_initialize(int controllers, void *ctrl);

I never got any comment on that void * - why was it memory
controllers could not have a unified struct?


//Peter



From rminnich at gmail.com  Thu Jun  7 19:45:30 2007
From: rminnich at gmail.com (ron minnich)
Date: Thu, 7 Jun 2007 10:45:30 -0700
Subject: [LinuxBIOS] r349 - LinuxBIOSv3/include
In-Reply-To: <20070607173727.19844.qmail@cdy.org>
References: <20070607173727.19844.qmail@cdy.org>
Message-ID: <13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>

On 6/7/07, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
> On Thu, Jun 07, 2007 at 07:34:17PM +0200, svn at openbios.org wrote:
> > +void ram_initialize(int controllers, void *ctrl);
>
> I never got any comment on that void * - why was it memory
> controllers could not have a unified struct?

I will try to sum it up but ... there is no way to unify it, short
form. I contains very chip-dependent stuff, ranging from the simple
array of longs up to a very complex multi-channel, mult-i devfn,
multi-address, etc. etc. mess.

There's no good way to do it that I can see.

ron



From stuge-linuxbios at cdy.org  Thu Jun  7 19:55:36 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu, 7 Jun 2007 19:55:36 +0200
Subject: [LinuxBIOS] MC struct
In-Reply-To: <13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
Message-ID: <20070607175536.23359.qmail@cdy.org>

On Thu, Jun 07, 2007 at 10:45:30AM -0700, ron minnich wrote:
> I will try to sum it up but ... there is no way to unify it, short
> form. I contains very chip-dependent stuff, ranging from the simple
> array of longs up to a very complex multi-channel, mult-i devfn,
> multi-address, etc. etc. mess.
> 
> There's no good way to do it that I can see.

How does everyone feel abot unions?

I'm fine with them but a bit annoyed that they need a name. :)

Is there already a generic struct for each MC or is there just the
per-type struct?

Also, can there be more than one MC on a northbridge?

Sorry if this is confusing. I'm not sure I have my head around the
struct layout in v2 or v3 - but I know I want it to be a nice tree
in v3.


//Peter



From stepan at coresystems.de  Thu Jun  7 20:10:07 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 7 Jun 2007 20:10:07 +0200
Subject: [LinuxBIOS] r349 - LinuxBIOSv3/include
In-Reply-To: <13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
Message-ID: <20070607181007.GA11362@coresystems.de>

* ron minnich <rminnich at gmail.com> [070607 19:45]:
> I will try to sum it up but ... there is no way to unify it, short
> form. I contains very chip-dependent stuff, ranging from the simple
> array of longs up to a very complex multi-channel, mult-i devfn,
> multi-address, etc. etc. mess.
 
Saving devfns in the mem ctrl struct is one of the stupid things in v2.

The mem init code could easily know that the 1st ram controller is
0:18.x, the second one 0:19.x etc.

And that was a complex platform.

We dont win any flexibility by letting the board supporter write that in
auto.c. it just looks like something you should know, but in fact you
should not need to.

All it should ever be is:
* number of controller
* channel on controller
* spd position and mux config on i2c bus.

What else?

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Thu Jun  7 20:14:57 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 7 Jun 2007 20:14:57 +0200
Subject: [LinuxBIOS] MC struct
In-Reply-To: <20070607175536.23359.qmail@cdy.org>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
Message-ID: <20070607181457.GB11362@coresystems.de>

* Peter Stuge <stuge-linuxbios at cdy.org> [070607 19:55]:
> On Thu, Jun 07, 2007 at 10:45:30AM -0700, ron minnich wrote:
> > I will try to sum it up but ... there is no way to unify it, short
> > form. I contains very chip-dependent stuff, ranging from the simple
> > array of longs up to a very complex multi-channel, mult-i devfn,
> > multi-address, etc. etc. mess.
> > 
> > There's no good way to do it that I can see.
> 
> How does everyone feel abot unions?
 
Bad. I dont think we need them. (Well if we did, it would be an idea)

People have been copying auto.c from K8 and modifying it. And if their
mem controller was simple, the complicated parts were not always
removed. So we ended up with something complex, and in addition it might
be different on all platforms.

I think what we want is a generic MC structure. BUT we also want a
platform specific sysinfo structure.

And sysinfo is what we want to pass there, not MC. I think the object
model is wrong at the moment.

> Also, can there be more than one MC on a northbridge?
 
In theory. But the meminit code would know that. No need to define it
every time.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From rminnich at gmail.com  Thu Jun  7 20:25:06 2007
From: rminnich at gmail.com (ron minnich)
Date: Thu, 7 Jun 2007 11:25:06 -0700
Subject: [LinuxBIOS] MC struct
In-Reply-To: <20070607181457.GB11362@coresystems.de>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
Message-ID: <13426df10706071125j2a9c32a8xdf824909ca1e772@mail.gmail.com>

I'm fine if somebody wants to work out a MC controller fix.

Weirdly enough, it will look like the device model. But that's ok.

ron



From stuge-linuxbios at cdy.org  Thu Jun  7 20:25:24 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu, 7 Jun 2007 20:25:24 +0200
Subject: [LinuxBIOS] MC struct
In-Reply-To: <20070607181457.GB11362@coresystems.de>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
Message-ID: <20070607182524.29971.qmail@cdy.org>

On Thu, Jun 07, 2007 at 08:14:57PM +0200, Stefan Reinauer wrote:
> > How does everyone feel abot unions?
>  
> Bad. I dont think we need them. (Well if we did, it would be an
> idea)

Agreed, if no need then no reason.


> I think what we want is a generic MC structure.

Yes, this sounds good.


> BUT we also want a platform specific sysinfo structure.

What would it hold? Is it the initial device tree in code?


> And sysinfo is what we want to pass there, not MC. I think the
> object model is wrong at the moment.

Quite possible. I'm not sure how things are right now, just what I
think I'd like:

A device tree (not list) in code that
* is seeded by the mainboard dts, which lists all devices
* has device options set from defaults in device dts
* has device option overrides from mainboard dts
* has device option overrides from Kconfig
* can be translated to (if it isn't already) a device tree for
  consumption by the kernel

Sorry if you've already had to get me to drop this once, but it's the
nice and neat structure that I imagined at the symposium when we
started talking about dts and so on. Is my thinking wrong?


> > Also, can there be more than one MC on a northbridge?
>  
> In theory. But the meminit code would know that. No need to define
> it every time.

How would it know?

I think the tree should have several ctrl nodes - one per MC. Right?


//Peter



From stuge-linuxbios at cdy.org  Thu Jun  7 20:27:03 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu, 7 Jun 2007 20:27:03 +0200
Subject: [LinuxBIOS] MC struct
In-Reply-To: <13426df10706071125j2a9c32a8xdf824909ca1e772@mail.gmail.com>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
	<13426df10706071125j2a9c32a8xdf824909ca1e772@mail.gmail.com>
Message-ID: <20070607182703.30383.qmail@cdy.org>

On Thu, Jun 07, 2007 at 11:25:06AM -0700, ron minnich wrote:
> I'm fine if somebody wants to work out a MC controller fix.

Ah yes - the code. This is where it ended last time too. :p


> Weirdly enough, it will look like the device model. But that's ok.

You mean how it is in v2? Is that so wrong then? (Except that it's a
list and not a tree right?)


//Peter



From uwe at hermann-uwe.de  Thu Jun  7 20:35:52 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 7 Jun 2007 20:35:52 +0200
Subject: [LinuxBIOS] [PATCH] v3: Intel 82371EB reworking, QEMU fixing
Message-ID: <20070607183552.GA19063@greenwood>

See patch.

Comments welcome. Not sure this is already committable, may need some
fixes.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v3_i82371eb_impementation.patch
Type: text/x-diff
Size: 19307 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070607/591a24ba/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070607/591a24ba/attachment.sig>

From stepan at coresystems.de  Thu Jun  7 20:37:02 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 7 Jun 2007 20:37:02 +0200
Subject: [LinuxBIOS] MC struct
In-Reply-To: <20070607182524.29971.qmail@cdy.org>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
	<20070607182524.29971.qmail@cdy.org>
Message-ID: <20070607183702.GA18962@coresystems.de>

* Peter Stuge <stuge-linuxbios at cdy.org> [070607 20:25]:
> > BUT we also want a platform specific sysinfo structure.
> 
> What would it hold? Is it the initial device tree in code?
 
./src/northbridge/amd/amdk8/amdk8_f.h

or is this what should go in the mc structure instead?
 
> Sorry if you've already had to get me to drop this once, but it's the
> nice and neat structure that I imagined at the symposium when we
> started talking about dts and so on. Is my thinking wrong?

No. It will just be hard to get this done right and in time. 
 
> > In theory. But the meminit code would know that. No need to define
> > it every time.
> 
> How would it know?

Well, meminit code knows what memory controller it is written for. AMD
wont start building CPUs using 2:23.0 instead of 0:18.0

On most systems the mem controller is 0:0.0 anyways.

> I think the tree should have several ctrl nodes - one per MC. Right?

yes. It has but they are "ordinary pci devices" in the tree. we dont
have a tree at raminit time (yet?)

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From rminnich at gmail.com  Thu Jun  7 21:16:43 2007
From: rminnich at gmail.com (ron minnich)
Date: Thu, 7 Jun 2007 12:16:43 -0700
Subject: [LinuxBIOS] MC struct
In-Reply-To: <20070607183702.GA18962@coresystems.de>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
	<20070607182524.29971.qmail@cdy.org>
	<20070607183702.GA18962@coresystems.de>
Message-ID: <13426df10706071216m33a2e514g931c12946e84ee67@mail.gmail.com>

On 6/7/07, Stefan Reinauer <stepan at coresystems.de> wrote:

> yes. It has but they are "ordinary pci devices" in the tree. we dont
> have a tree at raminit time (yet?)


yes, but it hit me that dts can build two trees, one very limited one
for raminit.

ron



From stepan at coresystems.de  Thu Jun  7 21:21:13 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 7 Jun 2007 21:21:13 +0200
Subject: [LinuxBIOS] MC struct
In-Reply-To: <13426df10706071216m33a2e514g931c12946e84ee67@mail.gmail.com>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
	<20070607182524.29971.qmail@cdy.org>
	<20070607183702.GA18962@coresystems.de>
	<13426df10706071216m33a2e514g931c12946e84ee67@mail.gmail.com>
Message-ID: <20070607192113.GA30382@coresystems.de>

* ron minnich <rminnich at gmail.com> [070607 21:16]:
> On 6/7/07, Stefan Reinauer <stepan at coresystems.de> wrote:
> 
> >yes. It has but they are "ordinary pci devices" in the tree. we dont
> >have a tree at raminit time (yet?)
> 
> 
> yes, but it hit me that dts can build two trees, one very limited one
> for raminit.

yeah. how would that tree be used?

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rminnich at gmail.com  Thu Jun  7 21:29:11 2007
From: rminnich at gmail.com (ron minnich)
Date: Thu, 7 Jun 2007 12:29:11 -0700
Subject: [LinuxBIOS] MC struct
In-Reply-To: <20070607192113.GA30382@coresystems.de>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
	<20070607182524.29971.qmail@cdy.org>
	<20070607183702.GA18962@coresystems.de>
	<13426df10706071216m33a2e514g931c12946e84ee67@mail.gmail.com>
	<20070607192113.GA30382@coresystems.de>
Message-ID: <13426df10706071229x62a618d6i672c22ecc5721e8e@mail.gmail.com>

On 6/7/07, Stefan Reinauer <stepan at coresystems.de> wrote:

> yeah. how would that tree be used?

to describe the device-independent and device-dependent data. To
provide pointers to functions. Pretty much how it is used now.

ron



From stepan at coresystems.de  Thu Jun  7 22:09:58 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 7 Jun 2007 22:09:58 +0200
Subject: [LinuxBIOS] MC struct
In-Reply-To: <13426df10706071229x62a618d6i672c22ecc5721e8e@mail.gmail.com>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
	<20070607182524.29971.qmail@cdy.org>
	<20070607183702.GA18962@coresystems.de>
	<13426df10706071216m33a2e514g931c12946e84ee67@mail.gmail.com>
	<20070607192113.GA30382@coresystems.de>
	<13426df10706071229x62a618d6i672c22ecc5721e8e@mail.gmail.com>
Message-ID: <20070607200958.GA8057@coresystems.de>

* ron minnich <rminnich at gmail.com> [070607 21:29]:
> >yeah. how would that tree be used?
> 
> to describe the device-independent and device-dependent data. To
> provide pointers to functions. Pretty much how it is used now.
 
Of the memory controller?

So far all that memory init had to do was implement some hooks. Do we
want to change this?

Where do you want to put that device tree? in cache? Or RO in rom?


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From rdabney at daemonicpenguin.net  Thu Jun  7 22:14:22 2007
From: rdabney at daemonicpenguin.net (Richard Neill Dabney)
Date: Fri, 08 Jun 2007 02:14:22 +0600
Subject: [LinuxBIOS] Advantech SOM-4455F
Message-ID: <4668671E.7090905@daemonicpenguin.net>

I have LBv2 booting with EB/Filo on this board but I'm having trouble with the VGA, both onboard and PCI. With a S3 968 card it jumps into the VGA BIOS through the emulator and then goes off into the weeds. I've read the BIOS code put of memory and compared it to a ROM dump. Where have I gone wrong?

Richard Dabney
LASG
Albuquerque,NM

------------------------------------------------------------------------


LinuxBIOS-2.0.0.0Normal Thu Jun  7 13:45:30 MDT 2007 starting...
_MSR GLCP_SYS_RSTPLL (4c000014) value is: 0000039c:07de002a
Done cpuRegInit
SMBUS READ ERROR:03 device:a2
Ram1.00
Ram2.00
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
Ram3
DRAM controller init done.
RAM DLL lock
Ram4
Testing DRAM : 00000000-000a0000
DRAM fill: 00000000-000a0000
00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 000a0000
DRAM filled
DRAM verify: 00000000-000a0000
00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 000a0000
DRAM range verified.
Done.
POST 02
Past wbinvd
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0.0Normal Thu Jun  7 13:45:30 MDT 2007 booting...
end bc8cf26, start 2
32-bit delta 1160
calibrate_tsc 32-bit result is 1160
clocks_per_usec: 1160
Enumerating buses...
scan_static_bus for Root Device

>> >> Entering northbridge.c: enable_dev with path 6
>> >> Entering northbridge.c: pci_domain_enable
>>     
Enter northbridge_init_early
writeglmsr: MSR 0x10000020, val 0x20000000:0x000fff80
writeglmsr: MSR 0x10000021, val 0x20000000:0x080fffe0
writeglmsr: MSR 0x1000002c, val 0x20000000:0x00000003
sizeram: _MSR MC_CF07_DATA: 10076013:00003a40
sizeram: sizem 0x100MB
SysmemInit: enable for 256MBytes
usable RAM: 268304383 bytes
SysmemInit: MSR 0x10000028, val 0x2000000f:0xfdf00100
sizeram: _MSR MC_CF07_DATA: 10076013:00003a40
sizeram: sizem 0x100MB
SMMGL0Init: 268304384 bytes
SMMGL0Init: offset is 0x80400000
SMMGL0Init: MSR 0x10000026, val 0x28fbe080:0x400fffe0
writeglmsr: MSR 0x10000080, val 0x00000000:0x00000003
writeglmsr: MSR 0x40000020, val 0x20000000:0x000fff80
writeglmsr: MSR 0x40000021, val 0x20000000:0x080fffe0
writeglmsr: MSR 0x4000002e, val 0x20000000:0x00000003
sizeram: _MSR MC_CF07_DATA: 10076013:00003a40
sizeram: sizem 0x100MB
SysmemInit: enable for 256MBytes
usable RAM: 268304383 bytes
SysmemInit: MSR 0x4000002a, val 0x2000000f:0xfdf00100
SMMGL1Init:
SMMGL1Init: MSR 0x40000023, val 0x20000080:0x400fffe0
writeglmsr: MSR 0x40000080, val 0x00000000:0x00000001
writeglmsr: MSR 0x400000e3, val 0x60000000:0x033000f0
CPU_RCONF_DEFAULT (1808): 0x25FFF802:0x10FFDF00
CPU_RCONF_BYPASS (180A): 0x00000000 : 0x00000000
L2 cache enabled
Enabling cache
GLPCI R1: system msr.lo 0x00100130 msr.hi 0x0ffdf000
GLPCI R2: system msr.lo 0x80400120 msr.hi 0x8041f000
Exit northbridge_init_early
Done cpubug fixes 
Not Doing ChipsetFlashSetup()
Before VSA:
do_vsmbios
buf ilen 35441 olen60466
buf 00060000 *buf 186 buf[256k] 0
buf[0x20] signature is b0:10:e6:80
Call real_mode_switch_call_vsm
biosint: INT# 0x15
biosint: eax 0xbea7 ebx 0x4e53 ecx 0x10000026 edx 0x10000028
biosint: ebp 0x23f34 esp 0xff0 edi 0x240000 esi 0x10038
biosint:  ip 0x5b3   cs 0x6000  flags 0x46
biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0
handleint21, eax 0xbea7
biosint: INT# 0x15
biosint: eax 0xbea4 ebx 0x4e53 ecx 0x10000026 edx 0x10000028
biosint: ebp 0x23f34 esp 0xfee edi 0x240000 esi 0x10038
biosint:  ip 0x5c1   cs 0x6000  flags 0x46
biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0
handleint21, eax 0xbea4
do_vsmbios: VSA2 VR signature verified
After VSA:
Graphics init...
VRC_VG value: 0x2808
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled

>> >> Entering northbridge.c: enable_dev with path 7
>>     
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 scanning...

>> >> Entering northbridge.c: pci_domain_scan_bus
>>     
PCI: pci_scan_bus for bus 00
PCI: devfn 0x0, bad id 0xffffffff
malloc Enter, size 668, free_mem_ptr 00024000
malloc 0x00024000
PCI: 00:01.0 [1022/2080] ops
PCI: 00:01.0 [1022/2080] enabled
malloc Enter, size 668, free_mem_ptr 0002429c
malloc 0x0002429c
PCI: 00:01.1 [1022/2081] enabled
malloc Enter, size 668, free_mem_ptr 00024538
malloc 0x00024538
PCI: 00:01.2 [1022/2082] enabled
PCI: devfn 0xb, bad id 0xffffffff
PCI: devfn 0xc, bad id 0xffffffff
PCI: devfn 0xd, bad id 0xffffffff
PCI: devfn 0xe, bad id 0xffffffff
PCI: devfn 0xf, bad id 0xffffffff
PCI: devfn 0x10, bad id 0xffffffff
PCI: devfn 0x18, bad id 0xffffffff
PCI: devfn 0x20, bad id 0xffffffff
PCI: devfn 0x28, bad id 0xffffffff

>> >> Entering northbridge.c: enable_dev with path 2
>>     
PCI: 00:06.0 [8086/1209] enabled
malloc Enter, size 668, free_mem_ptr 000247d4
malloc 0x000247d4
PCI: 00:07.0 [1283/8888] enabled
PCI: devfn 0x40, bad id 0xffffffff
PCI: devfn 0x48, bad id 0xffffffff
PCI: devfn 0x50, bad id 0xffffffff
PCI: devfn 0x58, bad id 0xffffffff
malloc Enter, size 668, free_mem_ptr 00024a70
malloc 0x00024a70
PCI: 00:0c.0 [5333/88f0] enabled
PCI: devfn 0x68, bad id 0xffffffff
PCI: devfn 0x70, bad id 0xffffffff
cs5536: southbridge_enable: dev is 0001da40
PCI: 00:0f.0 [1022/2090] bus ops
PCI: 00:0f.0 [1022/2090] enabled
cs5536: southbridge_enable: dev is 0001d7a0
Disabling static device: PCI: 00:0f.1
cs5536: southbridge_enable: dev is 0001d500
PCI: 00:0f.2 [1022/209a] ops
PCI: 00:0f.2 [1022/209a] enabled
cs5536: southbridge_enable: dev is 0001d260
PCI: 00:0f.3 [1022/2093] enabled
cs5536: southbridge_enable: dev is 0001cfc0
PCI: 00:0f.4 [1022/2094] enabled
cs5536: southbridge_enable: dev is 0001cd20
PCI: 00:0f.5 [1022/2095] enabled
malloc Enter, size 668, free_mem_ptr 00024d0c
malloc 0x00024d0c
PCI: 00:0f.6 [1022/2096] enabled
malloc Enter, size 668, free_mem_ptr 00024fa8
malloc 0x00024fa8
PCI: 00:0f.7 [1022/2097] enabled
PCI: devfn 0x80, bad id 0xffffffff
PCI: devfn 0x88, bad id 0xffffffff
PCI: devfn 0x90, bad id 0xffffffff
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
scan_static_bus for PCI: 00:0f.0
PNP: 002e.0 disabled
PNP: 002e.1 disabled
PNP: 002e.2 enabled
PNP: 002e.3 enabled
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
scan_static_bus for PCI: 00:0f.0 done
PCI: pci_scan_bus returning with max=000
scan_static_bus for Root Device done
done
Allocating resources...
Reading resources...
Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0
Root Device read_resources bus 0 link: 0

>> >> Entering northbridge.c: pci_domain_read_resources
>>     
PCI_DOMAIN: 0000 read_resources bus 0 link: 0
PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done
Root Device read_resources bus 0 link: 0 done
PCI: 00:0f.0 14 *  [0x00000400 - 0x000004ff] io
PCI: 00:0f.0 20 *  [0x00000800 - 0x0000087f] io
PCI: 00:0f.3 10 *  [0x00000880 - 0x000008ff] io
PCI: 00:06.0 14 *  [0x00000c00 - 0x00000c3f] io
PCI: 00:0f.0 18 *  [0x00000c40 - 0x00000c7f] io
PCI: 00:0f.0 24 *  [0x00000c80 - 0x00000cbf] io
PCI: 00:0f.0 1c *  [0x00000cc0 - 0x00000cdf] io
PCI: 00:0f.2 20 *  [0x00000ce0 - 0x00000cef] io
PCI: 00:0f.0 10 *  [0x00000cf0 - 0x00000cf7] io
PCI: 00:01.0 10 *  [0x00000d00 - 0x00000d03] io
Root Device compute_allocate_io: base: 00000d04 size: 00000904 align: 8 gran: 0 done
Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:0c.0 10 *  [0x00000000 - 0x01ffffff] mem
PCI: 00:01.1 10 *  [0x02000000 - 0x02ffffff] mem
PCI: 00:06.0 18 *  [0x03000000 - 0x0301ffff] mem
PCI: 00:0c.0 30 *  [0x03020000 - 0x0302ffff] mem
PCI: 00:01.1 14 *  [0x03030000 - 0x03033fff] mem
PCI: 00:01.1 18 *  [0x03034000 - 0x03037fff] mem
PCI: 00:01.1 1c *  [0x03038000 - 0x0303bfff] mem
PCI: 00:01.1 20 *  [0x0303c000 - 0x0303ffff] mem
PCI: 00:01.2 10 *  [0x03040000 - 0x03043fff] mem
PCI: 00:0f.6 10 *  [0x03044000 - 0x03045fff] mem
PCI: 00:06.0 10 *  [0x03046000 - 0x03046fff] mem
PCI: 00:0f.4 10 *  [0x03047000 - 0x03047fff] mem
PCI: 00:0f.5 10 *  [0x03048000 - 0x03048fff] mem
PCI: 00:0f.7 10 *  [0x03049000 - 0x03049fff] mem
Root Device compute_allocate_mem: base: 0304a000 size: 0304a000 align: 25 gran: 0 done
Done reading resources.
Allocating VGA resource PCI: 00:0c.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
Root Device compute_allocate_io: base: 00001000 size: 00000904 align: 8 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:0f.0 14 *  [0x00001000 - 0x000010ff] io
PCI: 00:0f.0 20 *  [0x00001400 - 0x0000147f] io
PCI: 00:0f.3 10 *  [0x00001480 - 0x000014ff] io
PCI: 00:06.0 14 *  [0x00001800 - 0x0000183f] io
PCI: 00:0f.0 18 *  [0x00001840 - 0x0000187f] io
PCI: 00:0f.0 24 *  [0x00001880 - 0x000018bf] io
PCI: 00:0f.0 1c *  [0x000018c0 - 0x000018df] io
PCI: 00:0f.2 20 *  [0x000018e0 - 0x000018ef] io
PCI: 00:0f.0 10 *  [0x000018f0 - 0x000018f7] io
PCI: 00:01.0 10 *  [0x00001900 - 0x00001903] io
Root Device compute_allocate_io: base: 00001904 size: 00000904 align: 8 gran: 0 done
Root Device compute_allocate_mem: base: fa000000 size: 0304a000 align: 25 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:0c.0 10 *  [0xfa000000 - 0xfbffffff] mem
PCI: 00:01.1 10 *  [0xfc000000 - 0xfcffffff] mem
PCI: 00:06.0 18 *  [0xfd000000 - 0xfd01ffff] mem
PCI: 00:0c.0 30 *  [0xfd020000 - 0xfd02ffff] mem
PCI: 00:01.1 14 *  [0xfd030000 - 0xfd033fff] mem
PCI: 00:01.1 18 *  [0xfd034000 - 0xfd037fff] mem
PCI: 00:01.1 1c *  [0xfd038000 - 0xfd03bfff] mem
PCI: 00:01.1 20 *  [0xfd03c000 - 0xfd03ffff] mem
PCI: 00:01.2 10 *  [0xfd040000 - 0xfd043fff] mem
PCI: 00:0f.6 10 *  [0xfd044000 - 0xfd045fff] mem
PCI: 00:06.0 10 *  [0xfd046000 - 0xfd046fff] mem
PCI: 00:0f.4 10 *  [0xfd047000 - 0xfd047fff] mem
PCI: 00:0f.5 10 *  [0xfd048000 - 0xfd048fff] mem
PCI: 00:0f.7 10 *  [0xfd049000 - 0xfd049fff] mem
Root Device compute_allocate_mem: base: fd04a000 size: 0304a000 align: 25 gran: 0 done
Root Device assign_resources, bus 0 link: 0

>> >> Entering northbridge.c: pci_domain_set_resources
>>     
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
PCI: 00:01.1 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 00:01.1 14 <- [0x00fd030000 - 0x00fd033fff] mem
PCI: 00:01.1 18 <- [0x00fd034000 - 0x00fd037fff] mem
PCI: 00:01.1 1c <- [0x00fd038000 - 0x00fd03bfff] mem
PCI: 00:01.1 20 <- [0x00fd03c000 - 0x00fd03ffff] mem
PCI: 00:01.2 10 <- [0x00fd040000 - 0x00fd043fff] mem
PCI: 00:06.0 10 <- [0x00fd046000 - 0x00fd046fff] mem
PCI: 00:06.0 14 <- [0x0000001800 - 0x000000183f] io
PCI: 00:06.0 18 <- [0x00fd000000 - 0x00fd01ffff] mem
PCI: 00:0c.0 10 <- [0x00fa000000 - 0x00fbffffff] mem
PCI: 00:0c.0 30 <- [0x00fd020000 - 0x00fd02ffff] romem
PCI: 00:0f.0 10 <- [0x00000018f0 - 0x00000018f7] io
PCI: 00:0f.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:0f.0 18 <- [0x0000001840 - 0x000000187f] io
PCI: 00:0f.0 1c <- [0x00000018c0 - 0x00000018df] io
PCI: 00:0f.0 20 <- [0x0000001400 - 0x000000147f] io
PCI: 00:0f.0 24 <- [0x0000001880 - 0x00000018bf] io
PCI: 00:0f.0 assign_resources, bus 0 link: 0
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.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: 00:0f.0 assign_resources, bus 0 link: 0
PCI: 00:0f.2 20 <- [0x00000018e0 - 0x00000018ef] io
PCI: 00:0f.3 10 <- [0x0000001480 - 0x00000014ff] io
PCI: 00:0f.4 10 <- [0x00fd047000 - 0x00fd047fff] mem
PCI: 00:0f.5 10 <- [0x00fd048000 - 0x00fd048fff] mem
PCI: 00:0f.6 10 <- [0x00fd044000 - 0x00fd045fff] mem
PCI: 00:0f.7 10 <- [0x00fd049000 - 0x00fd049fff] mem
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
Root Device assign_resources, bus 0 link: 0
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:01.0 cmd <- 145
PCI: 00:01.1 cmd <- 142
PCI: 00:01.2 cmd <- 142
PCI: 00:06.0 subsystem <- 00/00
PCI: 00:06.0 cmd <- 143
PCI: 00:07.0 cmd <- 147
PCI: 00:0c.0 cmd <- 1c3
cs5536: cs5536_pci_dev_enable_resources()
PCI: 00:0f.0 cmd <- 149
w83627hf hwm smbus enabled
PCI: 00:0f.2 cmd <- 141
PCI: 00:0f.3 subsystem <- 00/00
PCI: 00:0f.3 cmd <- 141
PCI: 00:0f.4 subsystem <- 00/00
PCI: 00:0f.4 cmd <- 142
PCI: 00:0f.5 subsystem <- 00/00
PCI: 00:0f.5 cmd <- 142
PCI: 00:0f.6 cmd <- 142
PCI: 00:0f.7 cmd <- 142
done.
Initializing devices...
Root Device init
SOM4455F ENTER init
SOM4455F EXIT init
PCI: 00:06.0 init
PCI: 00:0f.0 init
cs5536: southbridge_init
RTC Init
GPIO_ADDR: 00001000
Not disabling COM1 due to a bug ...
cs5536: southbridge_init: enable_ide_nand_flash is 0
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 00:0f.2 init
cs5536_ide: ide_init
PCI: 00:0f.3 init
PCI: 00:0f.4 init
PCI: 00:0f.5 init
APIC_CLUSTER: 0 init

>> >> Entering northbridge.c: cpu_bus_init
>>     
malloc Enter, size 668, free_mem_ptr 00025244
malloc 0x00025244
Initializing CPU #0
CPU: vendor AMD device 5a2
CPU: family 05, model 0a, stepping 02
model_lx_init
Enabling cache
A20 (0x92): 2
A20 (0x92): 2
CPU model_lx_init DONE
CPU #0 Initialized
PCI: 00:01.0 init

>> >> Entering northbridge.c: northbridge_init
>>     
PCI: 00:01.1 init
PCI: 00:01.2 init
PCI: 00:07.0 init
PCI: 00:0c.0 init
rom address for PCI: 00:0c.0 = fd020000
PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x0138
PCI ROM Image, Vendor 5333, Device 88f0,
PCI ROM Image,  Class Code 000003, Code Type 00
copying VGA ROM Image from 0xfd020000 to 0xc0000, 0x8000 bytes
entering emulator
0000:60b6: 20 ILLEGAL EXTENDED X86 OPCODE!
halt_sys: file /home/rdabney/linuxbios/LinuxBIOSv2.053107/src/devices/emulator/x86emu/ops2.c, line 60
PCI: 00:0f.6 init
PCI: 00:0f.7 init
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
/home/rdabney/linuxbios/LinuxBIOSv2.053107/src/arch/i386/boot/pirq_routing.c:    36:check_pirq_routing_table() - checksum is: 0x0e but should be: 0x62
done.
write_pirq_routing_table(8000785C, BABA)
PIR Entry 0 Dev/Fn: 78 Slot: 0
INT: A bitmap: 400 PIRQ: 10
INT: B bitmap: 800 PIRQ: 11
INT: C bitmap: 400 PIRQ: 10
INT: D bitmap: 800 PIRQ: 11
PIR Entry 1 Dev/Fn: 8 Slot: 0
INT: A bitmap: 400 PIRQ: 10
INT: B bitmap: 0 PIRQ: 0
INT: C bitmap: 0 PIRQ: 0
INT: D bitmap: 0 PIRQ: 0
PIR Entry 2 Dev/Fn: 48 Slot: 1
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
PIR Entry 3 Dev/Fn: 50 Slot: 2
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
PIR Entry 4 Dev/Fn: 58 Slot: 3
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
PIR Entry 5 Dev/Fn: 60 Slot: 4
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
PIR Entry 6 Dev/Fn: 30 Slot: 5
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
PIR Entry 7 Dev/Fn: 28 Slot: 6
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000 
Adjust rom_table_end from 0x000f0400 to 0x00100000 
Wrote linuxbios table at: 00000530 - 000006d4  checksum 751a

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

rom_stream: 0xfff89000 - 0xfffeffff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
n_type: 00000001 n_name(8): ELFBoot  n_desc(10): Etherboot 
n_type: 00000002 n_name(8): ELFBoot  n_desc(6): 5.2.6 
Loading Etherboot version: 5.2.6
Dropping non PT_LOAD segment
malloc Enter, size 32, free_mem_ptr 000254e0
malloc 0x000254e0
New segment addr 0x20000 size 0x3c050 offset 0xb0 filesize 0x10ac8
(cleaned up) New segment addr 0x20000 size 0x3c050 offset 0xb0 filesize 0x10ac8
lb: [0x0000000000004000, 0x0000000000028000)
segment: [0x0000000000020000, 0x0000000000030ac8, 0x000000000005c050)
malloc Enter, size 32, free_mem_ptr 00025500
malloc 0x00025500
   late: [0x0000000000028000, 0x0000000000030ac8, 0x000000000005c050)
 bounce: [0x000000000f7b4000, 0x000000000f7bc000, 0x000000000f7bc000)
Loading Segment: addr: 0x000000000f7b4000 memsz: 0x0000000000008000 filesz: 0x0000000000008000
[ 0x000000000f7b4000, 000000000f7bc000, 0x000000000f7bc000) <- 00000000000000b0
Loading Segment: addr: 0x0000000000028000 memsz: 0x0000000000034050 filesz: 0x0000000000008ac8
[ 0x0000000000028000, 0000000000030ac8, 0x000000000005c050) <- 00000000000080b0
Clearing Segment: addr: 0x0000000000030ac8 memsz: 0x000000000002b588
Loaded segments
verified segments
closed down stream
Jumping to boot code at 0x20000
entry    = 0x00020000
lb_start = 0x00004000
lb_size  = 0x00024000
adjust   = 0x0f7b8000
buffer   = 0x0f798000
     elf_boot_notes = 0x0001eb00
adjusted_boot_notes = 0x0f7d6b00
ROM segment 0xcf79 length 0x01c2 reloc 0x00020000
CPU 515 Mhz
Etherboot 5.2.6 (GPL) http://etherboot.org Tagged ELF for [EEPRO100][FILO]
Relocating _text from: [00020000,0005d590) to [0f6c2a70,0f700000)
Boot from (N)etwork (D)isk or (Q)uit? Probing pci disk...
[FILO]FILO version 0.4.1 (rdabney at rdabney-linux) Thu Jun  7 10:00:32 MDT 2007
boot: hda1:/vmlinuz initrd=/initrd.img ro root=/dev/hda1 acpi=no console=tty0 console=ttyS0,115200
hda: LBA: Maxtor 91366U4                          
Mounted ext2fs
Found Linux version 2.6.20.4 (root at scout-rdabney) #1 Wed May 30 09:15:58 MDT 2007 bzImage.
Loading kernel... ok
Loading initrd... ok
Jumping to entry point...
Linux version 2.6.20.4 (root at scout-rdabney) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #1 Wed May 30 09:15:58 MDT 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 0000000000001000 end: 0000000000001000 type: 16
copy_e820_map() start: 0000000000001000 size: 000000000009f000 end: 00000000000a0000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 16
copy_e820_map() start: 0000000000100000 size: 000000000f6e0000 end: 000000000f7e0000 type: 1
copy_e820_map() type is E820_RAM
 BIOS-e820: 0000000000000000 - 0000000000001000 type 16
 BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 type 16
 BIOS-e820: 0000000000100000 - 000000000f7e0000 (usable)
Malformed early option 'acpi'
247MB LOWMEM available.
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->    63456
early_node_map[1] active PFN ranges
    0:        0 ->    63456
DMI not present or invalid.
ACPI: Unable to locate RSDP
Allocating PCI resources starting at 10000000 (gap: 0f7e0000:f0820000)
Detected 499.931 MHz processor.
Built 1 zonelists.  Total pages: 62961
Kernel command line: ro root=/dev/hda1 acpi=no console=tty0 console=ttyS0,115200
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 247492k/253824k available (2398k kernel code, 5836k reserved, 901k data, 164k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffff8000 - 0xfffff000   (  28 kB)
    vmalloc : 0xd0000000 - 0xffff6000   ( 767 MB)
    lowmem  : 0xc0000000 - 0xcf7e0000   ( 247 MB)
      .init : 0xc043c000 - 0xc0465000   ( 164 kB)
      .data : 0xc035786f - 0xc0438d0c   ( 901 kB)
      .text : 0xc0100000 - 0xc035786f   (2398 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1001.09 BogoMIPS (lpj=2002188)
Mount-cache hash table entries: 512
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 128K (32 bytes/line)
Compat vDSO mapped to ffffe000.
CPU: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02
Checking 'hlt' instruction... OK.
NET: Registered protocol family 16
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter disabled.
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Firmware left 0000:00:06.0 e100 interrupts enabled, disabling
0000:00:0f.2: cannot adjust BAR0 (not I/O)
0000:00:0f.2: cannot adjust BAR1 (not I/O)
0000:00:0f.2: cannot adjust BAR2 (not I/O)
0000:00:0f.2: cannot adjust BAR3 (not I/O)
PCI: Using IRQ router default [1022/2090] at 0000:00:0f.0
PCI: Ignore bogus resource 6 [0:0] of 0000:00:01.1
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
scx200: NatSemi SCx200 Driver
NTFS driver 2.1.28 [Flags: R/W DEBUG].
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
vga16fb: mapped to 0xc00a0000
Console: switching to colour frame buffer device 80x30
fb0: VGA16 VGA frame buffer device
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
AMD Geode RNG detected
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
PCI: Guessed IRQ 11 for device 0000:00:06.0
PCI: Sharing IRQ 11 with 0000:00:0c.0
PCI: Sharing IRQ 11 with 0000:00:0f.4
PCI: Sharing IRQ 11 with 0000:00:0f.5
e100: eth0: e100_probe: addr 0xfd046000, irq 11, MAC addr 00:D0:C9:9F:63:84
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: Maxtor 91366U4, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: Host Protected Area detected.
	current capacity is 26587576 sectors (13612 MB)
	native  capacity is 26588016 sectors (13613 MB)
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: 0xf9
hda: 26587576 sectors (13612 MB) w/2048KiB Cache, CHS=26376/16/63
hda: cache flushes not supported
 hda: hda1 hda2 < hda5 >
SCSI Media Changer driver v0.25 
PCI: Guessed IRQ 11 for device 0000:00:0f.5
PCI: Sharing IRQ 11 with 0000:00:06.0
PCI: Sharing IRQ 11 with 0000:00:0c.0
PCI: Sharing IRQ 11 with 0000:00:0f.4
ehci_hcd 0000:00:0f.5: EHCI Host Controller
ehci_hcd 0000:00:0f.5: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:0f.5: irq 11, io mem 0xfd048000
ehci_hcd 0000:00:0f.5: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
PCI: Guessed IRQ 11 for device 0000:00:0f.4
PCI: Sharing IRQ 11 with 0000:00:06.0
PCI: Sharing IRQ 11 with 0000:00:0c.0
PCI: Sharing IRQ 11 with 0000:00:0f.5
ohci_hcd 0000:00:0f.4: OHCI Host Controller
ohci_hcd 0000:00:0f.4: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:0f.4: irq 11, io mem 0xfd047000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 4 ports detected
USB Universal Host Controller Interface driver v3.0
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input0
input: PC Speaker as /class/input/input1
input: ImPS/2 Generic Wheel Mouse as /class/input/input2
i2c /dev entries driver
**WARNING** I2C adapter driver [CS5536 ACB0] forgot to specify physical device; fix it!
Advanced Linux Sound Architecture Driver Version 1.0.14rc1 (Tue Jan 09 09:56:17 2007 UTC).
PCI: Guessed IRQ 11 for device 0000:00:0f.3
ALSA device list:
  #0: CS5535 Audio cs5535audio at 0x1480, irq 11
IPv4 over IPv4 tunneling driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Using IPI Shortcut mode
BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
Time: tsc clocksource has been installed.
EDD information not available.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 164k freed
 * Setting preliminary keymap...        [ OK ]
 * Preparing restricted drivers...        [ OK ]
 * Starting basic networking...        [ OK ]
 * Starting kernel event manager...        udevd[965]: add_to_rules: invalid SUBSYSTEMS operation
udevd[965]: add_to_rules: invalid rule '/etc/udev/rules.d/99-sdcard.rules:3'
udevd[965]: add_to_rules: invalid SUBSYSTEMS operation
udevd[965]: add_to_rules: invalid rule '/etc/udev/rules.d/99-sdcard.rules:6'
[ OK ]
 * Loading hardware drivers...        e100: eth1: e100_watchdog: link up, 100Mbps, full-duplex
PCI: Guessed IRQ 10 for device 0000:00:01.2
PCI: Sharing IRQ 10 with 0000:00:01.1
geode-aes: GEODE AES engine enabled.
[ OK ]
 * Loading kernel modules...         * Loading manual drivers...        [ OK ]
 * Activating swap...        [ OK ]
 * Checking root file system...        fsck 1.40-WIP (14-Nov-2006)
/dev/hda1: clean, 213733/1586144 files, 1262340/3170821 blocks
[ OK ]
 * Checking file systems...        fsck 1.40-WIP (14-Nov-2006)
[ OK ]
 * Mounting local filesystems...        [ OK ]
 * Activating swapfile swap...        [ OK ]
 * Configuring network interfaces...        [ OK ]
 * Setting sensors limits...        [ OK ]
 * Starting system log daemon...        [ OK ]
 * Starting kernel log...        [ OK ]
 * Starting internet superserver inetd        [ OK ]
 * Starting deferred execution scheduler atd        [ OK ]
 * Starting periodic command scheduler crond        [ OK ]
 * Enabling additional executable binary formats binfmt-support        [ OK ]
 * Running local boot scripts (/etc/rc.local)        [ OK ]
 * Stopping internet superserver inetd        [ OK ]
 * Shutting down ALSA...        [ OK ]
 * Terminating all remaining processes...        [ OK ]
 * Sending all processes the KILL signal...        [ OK ]
 * Deactivating swap...        [ OK ]
 * Unmounting local filesystems...        [ OK ]
 * Will now restart
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0.0Normal Thu Jun  7 13:45:30 MDT 2007 booting...


LinuxBIOS-2.0.0.0Normal Thu Jun  7 13:45:30 MDT 2007 starting...
_MSR GLCP_SYS_RSTPLL (4c000014) value is: 0000039c:0000182a
Configuring PLL


LinuxBIOS-2.0.0.0Normal Thu Jun  7 13:45:30 MDT 2007 starting...
_MSR GLCP_SYS_RSTPLL (4c000014) value is: 0000039c:07de002a
Done cpuRegInit
SMBUS READ ERROR:03 device:a2
Ram1.00
Ram2.00
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
Ram3
DRAM controller init done.
RAM DLL lock
Ram4
Testing DRAM : 00000000-000a0000
DRAM fill: 00000000-000a0000
00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 000a0000
DRAM filled
DRAM verify: 00000000-000a0000
00000000 00010000 00020000 00030000 00040000 00050000 00060000 00070000 00080000 00090000 000a0000
DRAM range verified.
Done.
POST 02
Past wbinvd
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0.0Normal Thu Jun  7 13:45:30 MDT 2007 booting...
end bca1d22, start 2
32-bit delta 1160
calibrate_tsc 32-bit result is 1160
clocks_per_usec: 1160
Enumerating buses...
scan_static_bus for Root Device

>> >> Entering northbridge.c: enable_dev with path 6
>> >> Entering northbridge.c: pci_domain_enable
>>     
Enter northbridge_init_early
writeglmsr: MSR 0x10000020, val 0x20000000:0x000fff80
writeglmsr: MSR 0x10000021, val 0x20000000:0x080fffe0
writeglmsr: MSR 0x1000002c, val 0x20000000:0x00000003
sizeram: _MSR MC_CF07_DATA: 10076013:00003a40
sizeram: sizem 0x100MB
SysmemInit: enable for 256MBytes
usable RAM: 268304383 bytes
SysmemInit: MSR 0x10000028, val 0x2000000f:0xfdf00100
sizeram: _MSR MC_CF07_DATA: 10076013:00003a40
sizeram: sizem 0x100MB
SMMGL0Init: 268304384 bytes
SMMGL0Init: offset is 0x80400000
SMMGL0Init: MSR 0x10000026, val 0x28fbe080:0x400fffe0
writeglmsr: MSR 0x10000080, val 0x00000000:0x00000003
writeglmsr: MSR 0x40000020, val 0x20000000:0x000fff80
writeglmsr: MSR 0x40000021, val 0x20000000:0x080fffe0
writeglmsr: MSR 0x4000002e, val 0x20000000:0x00000003
sizeram: _MSR MC_CF07_DATA: 10076013:00003a40
sizeram: sizem 0x100MB
SysmemInit: enable for 256MBytes
usable RAM: 268304383 bytes
SysmemInit: MSR 0x4000002a, val 0x2000000f:0xfdf00100
SMMGL1Init:
SMMGL1Init: MSR 0x40000023, val 0x20000080:0x400fffe0
writeglmsr: MSR 0x40000080, val 0x00000000:0x00000001
writeglmsr: MSR 0x400000e3, val 0x60000000:0x033000f0
CPU_RCONF_DEFAULT (1808): 0x25FFF802:0x10FFDF00
CPU_RCONF_BYPASS (180A): 0x00000000 : 0x00000000
L2 cache enabled
Enabling cache
GLPCI R1: system msr.lo 0x00100130 msr.hi 0x0ffdf000
GLPCI R2: system msr.lo 0x80400120 msr.hi 0x8041f000
Exit northbridge_init_early
Done cpubug fixes 
Not Doing ChipsetFlashSetup()
Before VSA:
do_vsmbios
buf ilen 35441 olen60466
buf 00060000 *buf 186 buf[256k] 0
buf[0x20] signature is b0:10:e6:80
Call real_mode_switch_call_vsm
biosint: INT# 0x15
biosint: eax 0xbea7 ebx 0x4e53 ecx 0x10000026 edx 0x10000028
biosint: ebp 0x23f34 esp 0xff0 edi 0x240000 esi 0x10038
biosint:  ip 0x5b3   cs 0x6000  flags 0x46
biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0
handleint21, eax 0xbea7
biosint: INT# 0x15
biosint: eax 0xbea4 ebx 0x4e53 ecx 0x10000026 edx 0x10000028
biosint: ebp 0x23f34 esp 0xfee edi 0x240000 esi 0x10038
biosint:  ip 0x5c1   cs 0x6000  flags 0x46
biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0
handleint21, eax 0xbea4
do_vsmbios: VSA2 VR signature verified
After VSA:
Graphics init...
VRC_VG value: 0x2808
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled

>> >> Entering northbridge.c: enable_dev with path 7
>>     
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 scanning...

>> >> Entering northbridge.c: pci_domain_scan_bus
>>     
PCI: pci_scan_bus for bus 00
PCI: devfn 0x0, bad id 0xffffffff
malloc Enter, size 668, free_mem_ptr 00024000
malloc 0x00024000
PCI: 00:01.0 [1022/2080] ops
PCI: 00:01.0 [1022/2080] enabled
malloc Enter, size 668, free_mem_ptr 0002429c
malloc 0x0002429c
PCI: 00:01.1 [1022/2081] enabled
malloc Enter, size 668, free_mem_ptr 00024538
malloc 0x00024538
PCI: 00:01.2 [1022/2082] enabled
PCI: devfn 0xb, bad id 0xffffffff
PCI: devfn 0xc, bad id 0xffffffff
PCI: devfn 0xd, bad id 0xffffffff
PCI: devfn 0xe, bad id 0xffffffff
PCI: devfn 0xf, bad id 0xffffffff
PCI: devfn 0x10, bad id 0xffffffff
PCI: devfn 0x18, bad id 0xffffffff
PCI: devfn 0x20, bad id 0xffffffff
PCI: devfn 0x28, bad id 0xffffffff

>> >> Entering northbridge.c: enable_dev with path 2
>>     
PCI: 00:06.0 [8086/1209] enabled
malloc Enter, size 668, free_mem_ptr 000247d4
malloc 0x000247d4
PCI: 00:07.0 [1283/8888] enabled
PCI: devfn 0x40, bad id 0xffffffff
PCI: devfn 0x48, bad id 0xffffffff
PCI: devfn 0x50, bad id 0xffffffff
PCI: devfn 0x58, bad id 0xffffffff
malloc Enter, size 668, free_mem_ptr 00024a70
malloc 0x00024a70
PCI: 00:0c.0 [5333/88f0] enabled
PCI: devfn 0x68, bad id 0xffffffff
PCI: devfn 0x70, bad id 0xffffffff
cs5536: southbridge_enable: dev is 0001da40
PCI: 00:0f.0 [1022/2090] bus ops
PCI: 00:0f.0 [1022/2090] enabled
cs5536: southbridge_enable: dev is 0001d7a0
Disabling static device: PCI: 00:0f.1
cs5536: southbridge_enable: dev is 0001d500
PCI: 00:0f.2 [1022/209a] ops
PCI: 00:0f.2 [1022/209a] enabled
cs5536: southbridge_enable: dev is 0001d260
PCI: 00:0f.3 [1022/2093] enabled
cs5536: southbridge_enable: dev is 0001cfc0
PCI: 00:0f.4 [1022/2094] enabled
cs5536: southbridge_enable: dev is 0001cd20
PCI: 00:0f.5 [1022/2095] enabled
malloc Enter, size 668, free_mem_ptr 00024d0c
malloc 0x00024d0c
PCI: 00:0f.6 [1022/2096] enabled
malloc Enter, size 668, free_mem_ptr 00024fa8
malloc 0x00024fa8
PCI: 00:0f.7 [1022/2097] enabled
PCI: devfn 0x80, bad id 0xffffffff
PCI: devfn 0x88, bad id 0xffffffff
PCI: devfn 0x90, bad id 0xffffffff
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
scan_static_bus for PCI: 00:0f.0
PNP: 002e.0 disabled
PNP: 002e.1 disabled
PNP: 002e.2 enabled
PNP: 002e.3 enabled
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
scan_static_bus for PCI: 00:0f.0 done
PCI: pci_scan_bus returning with max=000
scan_static_bus for Root Device done
done
Allocating resources...
Reading resources...
Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0
Root Device read_resources bus 0 link: 0

>> >> Entering northbridge.c: pci_domain_read_resources
>>     
PCI_DOMAIN: 0000 read_resources bus 0 link: 0
PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done
Root Device read_resources bus 0 link: 0 done
PCI: 00:0f.0 14 *  [0x00000400 - 0x000004ff] io
PCI: 00:0f.0 20 *  [0x00000800 - 0x0000087f] io
PCI: 00:0f.3 10 *  [0x00000880 - 0x000008ff] io
PCI: 00:06.0 14 *  [0x00000c00 - 0x00000c3f] io
PCI: 00:0f.0 18 *  [0x00000c40 - 0x00000c7f] io
PCI: 00:0f.0 24 *  [0x00000c80 - 0x00000cbf] io
PCI: 00:0f.0 1c *  [0x00000cc0 - 0x00000cdf] io
PCI: 00:0f.2 20 *  [0x00000ce0 - 0x00000cef] io
PCI: 00:0f.0 10 *  [0x00000cf0 - 0x00000cf7] io
PCI: 00:01.0 10 *  [0x00000d00 - 0x00000d03] io
Root Device compute_allocate_io: base: 00000d04 size: 00000904 align: 8 gran: 0 done
Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:0c.0 10 *  [0x00000000 - 0x01ffffff] mem
PCI: 00:01.1 10 *  [0x02000000 - 0x02ffffff] mem
PCI: 00:06.0 18 *  [0x03000000 - 0x0301ffff] mem
PCI: 00:0c.0 30 *  [0x03020000 - 0x0302ffff] mem
PCI: 00:01.1 14 *  [0x03030000 - 0x03033fff] mem
PCI: 00:01.1 18 *  [0x03034000 - 0x03037fff] mem
PCI: 00:01.1 1c *  [0x03038000 - 0x0303bfff] mem
PCI: 00:01.1 20 *  [0x0303c000 - 0x0303ffff] mem
PCI: 00:01.2 10 *  [0x03040000 - 0x03043fff] mem
PCI: 00:0f.6 10 *  [0x03044000 - 0x03045fff] mem
PCI: 00:06.0 10 *  [0x03046000 - 0x03046fff] mem
PCI: 00:0f.4 10 *  [0x03047000 - 0x03047fff] mem
PCI: 00:0f.5 10 *  [0x03048000 - 0x03048fff] mem
PCI: 00:0f.7 10 *  [0x03049000 - 0x03049fff] mem
Root Device compute_allocate_mem: base: 0304a000 size: 0304a000 align: 25 gran: 0 done
Done reading resources.
Allocating VGA resource PCI: 00:0c.0
Setting PCI_BRIDGE_CTL_VGA for bridge PCI_DOMAIN: 0000
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Setting resources...
Root Device compute_allocate_io: base: 00001000 size: 00000904 align: 8 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:0f.0 14 *  [0x00001000 - 0x000010ff] io
PCI: 00:0f.0 20 *  [0x00001400 - 0x0000147f] io
PCI: 00:0f.3 10 *  [0x00001480 - 0x000014ff] io
PCI: 00:06.0 14 *  [0x00001800 - 0x0000183f] io
PCI: 00:0f.0 18 *  [0x00001840 - 0x0000187f] io
PCI: 00:0f.0 24 *  [0x00001880 - 0x000018bf] io
PCI: 00:0f.0 1c *  [0x000018c0 - 0x000018df] io
PCI: 00:0f.2 20 *  [0x000018e0 - 0x000018ef] io
PCI: 00:0f.0 10 *  [0x000018f0 - 0x000018f7] io
PCI: 00:01.0 10 *  [0x00001900 - 0x00001903] io
Root Device compute_allocate_io: base: 00001904 size: 00000904 align: 8 gran: 0 done
Root Device compute_allocate_mem: base: fa000000 size: 0304a000 align: 25 gran: 0
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
PCI: 00:0c.0 10 *  [0xfa000000 - 0xfbffffff] mem
PCI: 00:01.1 10 *  [0xfc000000 - 0xfcffffff] mem
PCI: 00:06.0 18 *  [0xfd000000 - 0xfd01ffff] mem
PCI: 00:0c.0 30 *  [0xfd020000 - 0xfd02ffff] mem
PCI: 00:01.1 14 *  [0xfd030000 - 0xfd033fff] mem
PCI: 00:01.1 18 *  [0xfd034000 - 0xfd037fff] mem
PCI: 00:01.1 1c *  [0xfd038000 - 0xfd03bfff] mem
PCI: 00:01.1 20 *  [0xfd03c000 - 0xfd03ffff] mem
PCI: 00:01.2 10 *  [0xfd040000 - 0xfd043fff] mem
PCI: 00:0f.6 10 *  [0xfd044000 - 0xfd045fff] mem
PCI: 00:06.0 10 *  [0xfd046000 - 0xfd046fff] mem
PCI: 00:0f.4 10 *  [0xfd047000 - 0xfd047fff] mem
PCI: 00:0f.5 10 *  [0xfd048000 - 0xfd048fff] mem
PCI: 00:0f.7 10 *  [0xfd049000 - 0xfd049fff] mem
Root Device compute_allocate_mem: base: fd04a000 size: 0304a000 align: 25 gran: 0 done
Root Device assign_resources, bus 0 link: 0

>> >> Entering northbridge.c: pci_domain_set_resources
>>     
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
PCI: 00:01.1 10 <- [0x00fc000000 - 0x00fcffffff] mem
PCI: 00:01.1 14 <- [0x00fd030000 - 0x00fd033fff] mem
PCI: 00:01.1 18 <- [0x00fd034000 - 0x00fd037fff] mem
PCI: 00:01.1 1c <- [0x00fd038000 - 0x00fd03bfff] mem
PCI: 00:01.1 20 <- [0x00fd03c000 - 0x00fd03ffff] mem
PCI: 00:01.2 10 <- [0x00fd040000 - 0x00fd043fff] mem
PCI: 00:06.0 10 <- [0x00fd046000 - 0x00fd046fff] mem
PCI: 00:06.0 14 <- [0x0000001800 - 0x000000183f] io
PCI: 00:06.0 18 <- [0x00fd000000 - 0x00fd01ffff] mem
PCI: 00:0c.0 10 <- [0x00fa000000 - 0x00fbffffff] mem
PCI: 00:0c.0 30 <- [0x00fd020000 - 0x00fd02ffff] romem
PCI: 00:0f.0 10 <- [0x00000018f0 - 0x00000018f7] io
PCI: 00:0f.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:0f.0 18 <- [0x0000001840 - 0x000000187f] io
PCI: 00:0f.0 1c <- [0x00000018c0 - 0x00000018df] io
PCI: 00:0f.0 20 <- [0x0000001400 - 0x000000147f] io
PCI: 00:0f.0 24 <- [0x0000001880 - 0x00000018bf] io
PCI: 00:0f.0 assign_resources, bus 0 link: 0
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.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: 00:0f.0 assign_resources, bus 0 link: 0
PCI: 00:0f.2 20 <- [0x00000018e0 - 0x00000018ef] io
PCI: 00:0f.3 10 <- [0x0000001480 - 0x00000014ff] io
PCI: 00:0f.4 10 <- [0x00fd047000 - 0x00fd047fff] mem
PCI: 00:0f.5 10 <- [0x00fd048000 - 0x00fd048fff] mem
PCI: 00:0f.6 10 <- [0x00fd044000 - 0x00fd045fff] mem
PCI: 00:0f.7 10 <- [0x00fd049000 - 0x00fd049fff] mem
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
Root Device assign_resources, bus 0 link: 0
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:01.0 cmd <- 145
PCI: 00:01.1 cmd <- 142
PCI: 00:01.2 cmd <- 142
PCI: 00:06.0 subsystem <- 00/00
PCI: 00:06.0 cmd <- 143
PCI: 00:07.0 cmd <- 147
PCI: 00:0c.0 cmd <- 1c3
cs5536: cs5536_pci_dev_enable_resources()
PCI: 00:0f.0 cmd <- 149
w83627hf hwm smbus enabled
PCI: 00:0f.2 cmd <- 141
PCI: 00:0f.3 subsystem <- 00/00
PCI: 00:0f.3 cmd <- 141
PCI: 00:0f.4 subsystem <- 00/00
PCI: 00:0f.4 cmd <- 142
PCI: 00:0f.5 subsystem <- 00/00
PCI: 00:0f.5 cmd <- 142
PCI: 00:0f.6 cmd <- 142
PCI: 00:0f.7 cmd <- 142
done.
Initializing devices...
Root Device init
SOM4455F ENTER init
SOM4455F EXIT init
PCI: 00:06.0 init
PCI: 00:0f.0 init
cs5536: southbridge_init
RTC Init
GPIO_ADDR: 00001000
Not disabling COM1 due to a bug ...
cs5536: southbridge_init: enable_ide_nand_flash is 0
PNP: 002e.2 init
PNP: 002e.3 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 00:0f.2 init
cs5536_ide: ide_init
PCI: 00:0f.3 init
PCI: 00:0f.4 init
PCI: 00:0f.5 init
APIC_CLUSTER: 0 init

>> >> Entering northbridge.c: cpu_bus_init
>>     
malloc Enter, size 668, free_mem_ptr 00025244
malloc 0x00025244
Initializing CPU #0
CPU: vendor AMD device 5a2
CPU: family 05, model 0a, stepping 02
model_lx_init
Enabling cache
A20 (0x92): 2
A20 (0x92): 2
CPU model_lx_init DONE
CPU #0 Initialized
PCI: 00:01.0 init

>> >> Entering northbridge.c: northbridge_init
>>     
PCI: 00:01.1 init
PCI: 00:01.2 init
PCI: 00:07.0 init
PCI: 00:0c.0 init
rom address for PCI: 00:0c.0 = fd020000
PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x0138
PCI ROM Image, Vendor 5333, Device 88f0,
PCI ROM Image,  Class Code 000003, Code Type 00
copying VGA ROM Image from 0xfd020000 to 0xc0000, 0x8000 bytes
entering emulator
0000:60b6: 20 ILLEGAL EXTENDED X86 OPCODE!
halt_sys: file /home/rdabney/linuxbios/LinuxBIOSv2.053107/src/devices/emulator/x86emu/ops2.c, line 60
PCI: 00:0f.6 init
PCI: 00:0f.7 init
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
/home/rdabney/linuxbios/LinuxBIOSv2.053107/src/arch/i386/boot/pirq_routing.c:    36:check_pirq_routing_table() - checksum is: 0x0e but should be: 0x62
done.
write_pirq_routing_table(8000785C, BABA)
PIR Entry 0 Dev/Fn: 78 Slot: 0
INT: A bitmap: 400 PIRQ: 10
INT: B bitmap: 800 PIRQ: 11
INT: C bitmap: 400 PIRQ: 10
INT: D bitmap: 800 PIRQ: 11
PIR Entry 1 Dev/Fn: 8 Slot: 0
INT: A bitmap: 400 PIRQ: 10
INT: B bitmap: 0 PIRQ: 0
INT: C bitmap: 0 PIRQ: 0
INT: D bitmap: 0 PIRQ: 0
PIR Entry 2 Dev/Fn: 48 Slot: 1
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
PIR Entry 3 Dev/Fn: 50 Slot: 2
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
PIR Entry 4 Dev/Fn: 58 Slot: 3
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
PIR Entry 5 Dev/Fn: 60 Slot: 4
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
PIR Entry 6 Dev/Fn: 30 Slot: 5
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
PIR Entry 7 Dev/Fn: 28 Slot: 6
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 800 PIRQ: 11
INT: D bitmap: 400 PIRQ: 10
Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000 
Adjust rom_table_end from 0x000f0400 to 0x00100000 
Wrote linuxbios table at: 00000530 - 000006d4  checksum 751a

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

rom_stream: 0xfff89000 - 0xfffeffff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
n_type: 00000001 n_name(8): ELFBoot  n_desc(10): Etherboot 
n_type: 00000002 n_name(8): ELFBoot  n_desc(6): 5.2.6 
Loading Etherboot version: 5.2.6
Dropping non PT_LOAD segment
malloc Enter, size 32, free_mem_ptr 000254e0
malloc 0x000254e0
New segment addr 0x20000 size 0x3c050 offset 0xb0 filesize 0x10ac8
(cleaned up) New segment addr 0x20000 size 0x3c050 offset 0xb0 filesize 0x10ac8
lb: [0x0000000000004000, 0x0000000000028000)
segment: [0x0000000000020000, 0x0000000000030ac8, 0x000000000005c050)
malloc Enter, size 32, free_mem_ptr 00025500
malloc 0x00025500
   late: [0x0000000000028000, 0x0000000000030ac8, 0x000000000005c050)
 bounce: [0x000000000f7b4000, 0x000000000f7bc000, 0x000000000f7bc000)
Loading Segment: addr: 0x000000000f7b4000 memsz: 0x0000000000008000 filesz: 0x0000000000008000
[ 0x000000000f7b4000, 000000000f7bc000, 0x000000000f7bc000) <- 00000000000000b0
Loading Segment: addr: 0x0000000000028000 memsz: 0x0000000000034050 filesz: 0x0000000000008ac8
[ 0x0000000000028000, 0000000000030ac8, 0x000000000005c050) <- 00000000000080b0
Clearing Segment: addr: 0x0000000000030ac8 memsz: 0x000000000002b588
Loaded segments
verified segments
closed down stream
Jumping to boot code at 0x20000
entry    = 0x00020000
lb_start = 0x00004000
lb_size  = 0x00024000
adjust   = 0x0f7b8000
buffer   = 0x0f798000
     elf_boot_notes = 0x0001eb00
adjusted_boot_notes = 0x0f7d6b00
ROM segment 0x0000 length 0x0000 reloc 0x00020000
CPU 515 Mhz
Etherboot 5.2.6 (GPL) http://etherboot.org Tagged ELF for [EEPRO100][FILO]
Relocating _text from: [00020000,0005d590) to [0f6c2a70,0f700000)
Boot from (N)etwork (D)isk or (Q)uit? 
Probing pci disk...
[FILO]FILO version 0.4.1 (rdabney at rdabney-linux) Thu Jun  7 10:00:32 MDT 2007
boot: hda1:/vmlinuz initrd=/initrd.img ro root=/dev/hda1 acpi=no console=tty0 console=ttyS0,115200
hda: LBA: Maxtor 91366U4                          
Mounted ext2fs
Found Linux version 2.6.20.4 (root at scout-rdabney) #1 Wed May 30 09:15:58 MDT 2007 bzImage.
Loading kernel... ok
Loading initrd... ok
Jumping to entry point...
Linux version 2.6.20.4 (root at scout-rdabney) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #1 Wed May 30 09:15:58 MDT 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 0000000000001000 end: 0000000000001000 type: 16
copy_e820_map() start: 0000000000001000 size: 000000000009f000 end: 00000000000a0000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 16
copy_e820_map() start: 0000000000100000 size: 000000000f6e0000 end: 000000000f7e0000 type: 1
copy_e820_map() type is E820_RAM
 BIOS-e820: 0000000000000000 - 0000000000001000 type 16
 BIOS-e820: 0000000000001000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 type 16
 BIOS-e820: 0000000000100000 - 000000000f7e0000 (usable)
Malformed early option 'acpi'
247MB LOWMEM available.
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->    63456
early_node_map[1] active PFN ranges
    0:        0 ->    63456
DMI not present or invalid.
ACPI: Unable to locate RSDP
Allocating PCI resources starting at 10000000 (gap: 0f7e0000:f0820000)
Detected 499.956 MHz processor.
Built 1 zonelists.  Total pages: 62961
Kernel command line: ro root=/dev/hda1 acpi=no console=tty0 console=ttyS0,115200
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 4096 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 247492k/253824k available (2398k kernel code, 5836k reserved, 901k data, 164k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffff8000 - 0xfffff000   (  28 kB)
    vmalloc : 0xd0000000 - 0xffff6000   ( 767 MB)
    lowmem  : 0xc0000000 - 0xcf7e0000   ( 247 MB)
      .init : 0xc043c000 - 0xc0465000   ( 164 kB)
      .data : 0xc035786f - 0xc0438d0c   ( 901 kB)
      .text : 0xc0100000 - 0xc035786f   (2398 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1001.09 BogoMIPS (lpj=2002195)
Mount-cache hash table entries: 512
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 128K (32 bytes/line)
Compat vDSO mapped to ffffe000.
CPU: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02
Checking 'hlt' instruction... OK.
NET: Registered protocol family 16
PCI: Using configuration type 1
Setting up standard PCI resources
ACPI: Interpreter disabled.
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Firmware left 0000:00:06.0 e100 interrupts enabled, disabling
0000:00:0f.2: cannot adjust BAR0 (not I/O)
0000:00:0f.2: cannot adjust BAR1 (not I/O)
0000:00:0f.2: cannot adjust BAR2 (not I/O)
0000:00:0f.2: cannot adjust BAR3 (not I/O)
PCI: Using IRQ router default [1022/2090] at 0000:00:0f.0
PCI: Ignore bogus resource 6 [0:0] of 0000:00:01.1
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
scx200: NatSemi SCx200 Driver
NTFS driver 2.1.28 [Flags: R/W DEBUG].
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
vga16fb: mapped to 0xc00a0000
Console: switching to colour frame buffer device 80x30
fb0: VGA16 VGA frame buffer device
Real Time Clock Driver v1.12ac
Non-volatile memory driver v1.2
AMD Geode RNG detected
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
PCI: Guessed IRQ 11 for device 0000:00:06.0
PCI: Sharing IRQ 11 with 0000:00:0c.0
PCI: Sharing IRQ 11 with 0000:00:0f.4
PCI: Sharing IRQ 11 with 0000:00:0f.5
e100: eth0: e100_probe: addr 0xfd046000, irq 11, MAC addr 00:D0:C9:9F:63:84
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: Maxtor 91366U4, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 128KiB
hda: Host Protected Area detected.
	current capacity is 26587576 sectors (13612 MB)
	native  capacity is 26588016 sectors (13613 MB)
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: 0xf9
hda: 26587576 sectors (13612 MB) w/2048KiB Cache, CHS=26376/16/63
hda: cache flushes not supported
 hda: hda1 hda2 < hda5 >
SCSI Media Changer driver v0.25 
PCI: Guessed IRQ 11 for device 0000:00:0f.5
PCI: Sharing IRQ 11 with 0000:00:06.0
PCI: Sharing IRQ 11 with 0000:00:0c.0
PCI: Sharing IRQ 11 with 0000:00:0f.4
ehci_hcd 0000:00:0f.5: EHCI Host Controller
ehci_hcd 0000:00:0f.5: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:0f.5: irq 11, io mem 0xfd048000
ehci_hcd 0000:00:0f.5: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
PCI: Guessed IRQ 11 for device 0000:00:0f.4
PCI: Sharing IRQ 11 with 0000:00:06.0
PCI: Sharing IRQ 11 with 0000:00:0c.0
PCI: Sharing IRQ 11 with 0000:00:0f.5
ohci_hcd 0000:00:0f.4: OHCI Host Controller
ohci_hcd 0000:00:0f.4: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:0f.4: irq 11, io mem 0xfd047000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 4 ports detected
USB Universal Host Controller Interface driver v3.0
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input0
input: PC Speaker as /class/input/input1
input: ImPS/2 Generic Wheel Mouse as /class/input/input2
i2c /dev entries driver
**WARNING** I2C adapter driver [CS5536 ACB0] forgot to specify physical device; fix it!
Advanced Linux Sound Architecture Driver Version 1.0.14rc1 (Tue Jan 09 09:56:17 2007 UTC).
PCI: Guessed IRQ 11 for device 0000:00:0f.3
ALSA device list:
  #0: CS5535 Audio cs5535audio at 0x1480, irq 11
IPv4 over IPv4 tunneling driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
Using IPI Shortcut mode
BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
Time: tsc clocksource has been installed.
EDD information not available.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 164k freed
 * Setting preliminary keymap...        [ OK ]
 * Preparing restricted drivers...        [ OK ]
 * Starting basic networking...        [ OK ]
 * Starting kernel event manager...        [ OK ]
 * Loading hardware drivers...        e100: eth1: e100_watchdog: link up, 100Mbps, full-duplex
PCI: Guessed IRQ 10 for device 0000:00:01.2
PCI: Sharing IRQ 10 with 0000:00:01.1
geode-aes: GEODE AES engine enabled.
[ OK ]
 * Loading kernel modules...         * Loading manual drivers...        [ OK ]
 * Activating swap...        [ OK ]
 * Checking root file system...        fsck 1.40-WIP (14-Nov-2006)
/dev/hda1: clean, 213733/1586144 files, 1262354/3170821 blocks
[ OK ]
 * Checking file systems...        fsck 1.40-WIP (14-Nov-2006)
[ OK ]
 * Mounting local filesystems...        [ OK ]
 * Activating swapfile swap...        [ OK ]
 * Configuring network interfaces...        [ OK ]
 * Setting sensors limits...        [ OK ]
 * Starting system log daemon...        [ OK ]
 * Starting kernel log...        [ OK ]
 * Starting internet superserver inetd        [ OK ]
 * Starting deferred execution scheduler atd        [ OK ]
 * Starting periodic command scheduler crond        [ OK ]
 * Enabling additional executable binary formats binfmt-support        [ OK ]
 * Running local boot scripts (/etc/rc.local)        [ OK ]
^L^H






From stepan at coresystems.de  Thu Jun  7 22:19:20 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 7 Jun 2007 22:19:20 +0200
Subject: [LinuxBIOS] Advantech SOM-4455F
In-Reply-To: <4668671E.7090905@daemonicpenguin.net>
References: <4668671E.7090905@daemonicpenguin.net>
Message-ID: <20070607201920.GA11634@coresystems.de>

* Richard Neill Dabney <rdabney at daemonicpenguin.net> [070607 22:14]:
> rom address for PCI: 00:0c.0 = fd020000
> PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x0138
> PCI ROM Image, Vendor 5333, Device 88f0,
> PCI ROM Image,  Class Code 000003, Code Type 00
> copying VGA ROM Image from 0xfd020000 to 0xc0000, 0x8000 bytes
> entering emulator
> 0000:60b6: 20 ILLEGAL EXTENDED X86 OPCODE!
> halt_sys: file /home/rdabney/linuxbios/LinuxBIOSv2.053107/src/devices/emulator/x86emu/ops2.c, line 60

Looks like x86emu does not like the code. 


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From uwe at hermann-uwe.de  Thu Jun  7 22:28:00 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 7 Jun 2007 22:28:00 +0200
Subject: [LinuxBIOS] MC struct
In-Reply-To: <20070607182524.29971.qmail@cdy.org>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
	<20070607182524.29971.qmail@cdy.org>
Message-ID: <20070607202759.GB19063@greenwood>

On Thu, Jun 07, 2007 at 08:25:24PM +0200, Peter Stuge wrote:
> Quite possible. I'm not sure how things are right now, just what I
> think I'd like:
> 
> A device tree (not list) in code that
> * is seeded by the mainboard dts, which lists all devices

  All _static_ devices, correct?

> * has device options set from defaults in device dts
> * has device option overrides from mainboard dts
> * has device option overrides from Kconfig
> * can be translated to (if it isn't already) a device tree for
>   consumption by the kernel

  * Can automatically translated into a kconfig-style menu structure
    and data structure for consumption by lbmenu, the yet to be
    written tool for run-time configuration of LinuxBIOS.

Full ack. This is just about how I'd like it to work in the end.
Now, _how_ we achieve this is yet to be determined, though ;)


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070607/d953ffdc/attachment.sig>

From rdabney at daemonicpenguin.net  Thu Jun  7 22:41:02 2007
From: rdabney at daemonicpenguin.net (Richard Neill Dabney)
Date: Fri, 08 Jun 2007 02:41:02 +0600
Subject: [LinuxBIOS] Advantech SOM-4455F
In-Reply-To: <20070607201920.GA11634@coresystems.de>
References: <4668671E.7090905@daemonicpenguin.net>
	<20070607201920.GA11634@coresystems.de>
Message-ID: <46686D5E.2020404@daemonicpenguin.net>

That's would seem to be the case. Is the emulator so limited that it 
can't run a generic 1995-vintage BIOS? Will it run the AMD Geode VGA BIOS?

Stefan Reinauer wrote:
> * Richard Neill Dabney <rdabney at daemonicpenguin.net> [070607 22:14]:
>   
>> rom address for PCI: 00:0c.0 = fd020000
>> PCI Expansion ROM, signature 0xaa55, INIT size 0x8000, data ptr 0x0138
>> PCI ROM Image, Vendor 5333, Device 88f0,
>> PCI ROM Image,  Class Code 000003, Code Type 00
>> copying VGA ROM Image from 0xfd020000 to 0xc0000, 0x8000 bytes
>> entering emulator
>> 0000:60b6: 20 ILLEGAL EXTENDED X86 OPCODE!
>> halt_sys: file /home/rdabney/linuxbios/LinuxBIOSv2.053107/src/devices/emulator/x86emu/ops2.c, line 60
>>     
>
> Looks like x86emu does not like the code. 
>
>
>   




From svn at openbios.org  Thu Jun  7 22:52:43 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu,  7 Jun 2007 22:52:43 +0200
Subject: [LinuxBIOS] r2716 - in trunk/LinuxBIOSv2: src/mainboard/iei
	src/mainboard/iei/juki-511p targets/iei targets/iei/juki-511p
Message-ID: <mailman.388.1355071119.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-07 22:52:42 +0200 (Thu, 07 Jun 2007)
New Revision: 2716

Added:
   trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/
   trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/Config.lb
   trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/Options.lb
   trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/auto.c
   trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/chip.h
   trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/cmos.layout
   trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/failover.c
   trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/irq_tables.c
   trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/mainboard.c
   trunk/LinuxBIOSv2/targets/iei/juki-511p/
   trunk/LinuxBIOSv2/targets/iei/juki-511p/Config.lb
Log:
Add support for the IEI JUKI-511P and IEI ROCKY-512 half-size boards.

Both are very similar, thus both use the JUKI-511P target.

Linux with patches from Juergen Beisert
(http://www.linuxbios.org/pipermail/linuxbios/2007-May/020932.html)
boots and work fine (ide, usb, ethernet, serial, keyboard and sound
work normally).

Problems:
 - Filo loads a bzImage only from ide0 (ide1 doesn't work yet).
 - Video doesn't work, yet.

Signed-off-by: Nikolay Petukhov <nikolay.petukhov at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Added: trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/Config.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/Config.lb	2007-06-07 20:52:42 UTC (rev 2716)
@@ -0,0 +1,167 @@
+##
+## Compute the location and size of where this firmware image
+## (linuxBIOS plus bootloader) will live in the boot rom chip.
+##
+default ROM_SIZE = 256 * 1024 
+default ROM_SECTION_SIZE   = ROM_SIZE
+default ROM_SECTION_OFFSET = 0
+
+##
+## Compute the start location and size size of
+## The linuxBIOS bootloader.
+##
+default PAYLOAD_SIZE            = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE )
+default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1)
+
+##
+## Compute where this copy of linuxBIOS will start in the boot rom
+##
+default _ROMBASE      = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE )
+
+##
+## Compute a range of ROM that can cached to speed up linuxBIOS,
+## execution speed.
+##
+## XIP_ROM_SIZE must be a power of 2.
+## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE
+##
+default XIP_ROM_SIZE=65536
+default XIP_ROM_BASE = ( _ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE )
+
+##
+## Set all of the defaults for an x86 architecture
+##
+
+arch i386 end
+
+##
+## Build the objects we have code for in this directory.
+##
+
+driver mainboard.o
+
+if HAVE_PIRQ_TABLE object irq_tables.o end
+#object reset.o
+
+##
+## Romcc output
+##
+makerule ./failover.E
+	depends "$(MAINBOARD)/failover.c ./romcc" 
+	action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/failover.c -o $@"
+end
+
+makerule ./failover.inc
+	depends "$(MAINBOARD)/failover.c ./romcc"
+	action "./romcc    -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/failover.c -o $@"
+end
+
+makerule ./auto.E 
+	depends	"$(MAINBOARD)/auto.c option_table.h ./romcc" 
+	action	"./romcc -E -mcpu=i386 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
+end
+makerule ./auto.inc 
+	depends "$(MAINBOARD)/auto.c option_table.h ./romcc"
+	action	"./romcc    -mcpu=i386 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
+end
+
+##
+## Build our 16 bit and 32 bit linuxBIOS entry code
+##
+mainboardinit cpu/x86/16bit/entry16.inc
+mainboardinit cpu/x86/32bit/entry32.inc
+ldscript /cpu/x86/16bit/entry16.lds
+ldscript /cpu/x86/32bit/entry32.lds
+
+##
+## Build our reset vector (This is where linuxBIOS is entered)
+##
+mainboardinit cpu/x86/16bit/reset16.inc 
+ldscript /cpu/x86/16bit/reset16.lds 
+
+### Should this be in the northbridge code?
+mainboardinit arch/i386/lib/cpu_reset.inc
+
+##
+## Include an id string (For safe flashing)
+##
+mainboardinit arch/i386/lib/id.inc
+ldscript /arch/i386/lib/id.lds
+
+###
+### O.k. We aren't just an intermediary anymore!
+###
+
+##
+## Setup RAM
+##
+mainboardinit cpu/x86/fpu/enable_fpu.inc
+mainboardinit cpu/amd/model_gx1/cpu_setup.inc
+mainboardinit cpu/amd/model_gx1/gx_setup.inc
+mainboardinit ./auto.inc
+
+##
+## Include the secondary Configuration files 
+##
+#dir /pc80
+#config chip.h
+
+chip northbridge/amd/gx1
+  device pci_domain 0 on
+    device pci 0.0 on end
+      chip southbridge/amd/cs5530
+
+        device pci 12.0 on
+          chip superio/winbond/w83977f
+            device pnp 3f0.0 on		# FDC
+              irq 0x70 = 6
+            end
+            device pnp 3f0.1 on		# Parallel port
+              io 0x60 = 0x378
+              irq 0x70 = 7
+            end
+            device pnp 3f0.2 on		# COM1
+              io 0x60 = 0x3f8
+              irq 0x70 = 4
+            end
+            register "com1" = "{115200}"
+            device pnp 3f0.3 on		# COM2
+              io 0x60 = 0x2f8
+              irq 0x70 = 3
+            end
+            register "com2" = "{115200}"
+            device pnp 3f0.4 on		# RTC
+              io 0x60 = 0x070
+              irq 0x70 = 8
+            end
+            device pnp 3f0.5 on		# Keyboard
+              io 0x60 = 0x60
+              io 0x62 = 0x64
+              irq 0x70 = 1		# Int  1 for PS/2 keyboard
+              irq 0x72 = 12		# Int 12 for PS/2 mouse
+            end
+            device pnp 3f0.6 off	# IR
+            end
+            device pnp 3f0.7 off	# GPIO1
+            end
+            device pnp 3f0.8 off	# GPIO
+            end
+          end
+        device pci 12.1 on end		# SMI
+        device pci 12.2 on end		# IDE
+        device pci 12.3 on end		# Audio
+        device pci 12.4 on end		# VGA onboard
+
+      end
+
+      device pci 0e.0 on end		# ETH0
+      device pci 13.0 on end		# USB
+
+    end
+  end
+
+  chip cpu/amd/model_gx1
+  end
+
+end
+

Added: trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/Options.lb
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/Options.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/Options.lb	2007-06-07 20:52:42 UTC (rev 2716)
@@ -0,0 +1,147 @@
+uses HAVE_MP_TABLE
+uses HAVE_PIRQ_TABLE
+uses USE_FALLBACK_IMAGE
+uses HAVE_FALLBACK_BOOT
+uses HAVE_HARD_RESET
+uses CONFIG_UDELAY_IO
+uses HAVE_OPTION_TABLE
+uses USE_OPTION_TABLE
+uses CONFIG_COMPRESS
+uses CONFIG_COMPRESSED_PAYLOAD_NRV2B
+uses CONFIG_COMPRESSED_PAYLOAD_LZMA
+uses CONFIG_PRECOMPRESSED_PAYLOAD
+uses CONFIG_ROM_PAYLOAD
+uses IRQ_SLOT_COUNT
+uses MAINBOARD
+uses MAINBOARD_VENDOR
+uses MAINBOARD_PART_NUMBER
+uses LINUXBIOS_EXTRA_VERSION
+uses ARCH
+uses FALLBACK_SIZE
+uses STACK_SIZE
+uses HEAP_SIZE
+uses ROM_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_IMAGE_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_SECTION_OFFSET
+uses CONFIG_ROM_PAYLOAD_START
+uses PAYLOAD_SIZE
+uses _ROMBASE
+uses _RAMBASE
+uses XIP_ROM_SIZE
+uses XIP_ROM_BASE
+uses HAVE_MP_TABLE
+uses CROSS_COMPILE
+uses CC
+uses HOSTCC
+
+uses OBJCOPY
+
+uses CONFIG_CONSOLE_SERIAL8250
+uses DEFAULT_CONSOLE_LOGLEVEL
+uses MAXIMUM_CONSOLE_LOGLEVEL
+
+uses TTYS0_BAUD
+uses TTYS0_BASE
+uses TTYS0_LCS
+
+
+## ROM_SIZE is the size of boot ROM that this board will use.
+default ROM_SIZE  = 256*1024
+
+###
+### Build options
+###
+
+##
+## Build code for the fallback boot
+##
+default HAVE_FALLBACK_BOOT=1
+
+##
+## no MP table
+##
+default HAVE_MP_TABLE=0
+
+##
+## Build code to reset the motherboard from linuxBIOS
+##
+default HAVE_HARD_RESET=0
+
+default CONFIG_UDELAY_IO=1
+##
+## Build code to export a programmable irq routing table
+##
+default HAVE_PIRQ_TABLE=0
+default IRQ_SLOT_COUNT=2
+#object irq_tables.o
+
+##
+## Build code to export a CMOS option table
+##
+default HAVE_OPTION_TABLE=0
+
+###
+### LinuxBIOS layout values
+###
+
+## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy.
+default ROM_IMAGE_SIZE = 65536
+default FALLBACK_SIZE = 131072
+
+##
+## Use a small 8K stack
+##
+default STACK_SIZE=0x2000
+
+##
+## Use a small 16K heap
+##
+default HEAP_SIZE=0x4000
+
+##
+## Only use the option table in a normal image
+##
+#default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE
+default USE_OPTION_TABLE = 0
+
+default _RAMBASE = 0x00004000
+
+default CONFIG_ROM_PAYLOAD     = 1
+
+##
+## The Serial Console
+##
+
+# To Enable the Serial Console
+default CONFIG_CONSOLE_SERIAL8250=1
+default DEFAULT_CONSOLE_LOGLEVEL=8
+default MAXIMUM_CONSOLE_LOGLEVEL=8
+
+## Select the serial console baud rate
+default TTYS0_BAUD=115200
+#default TTYS0_BAUD=57600
+#default TTYS0_BAUD=38400
+#default TTYS0_BAUD=19200
+#default TTYS0_BAUD=9600
+#default TTYS0_BAUD=4800
+#default TTYS0_BAUD=2400
+#default TTYS0_BAUD=1200
+
+# Select the serial console base port
+default TTYS0_BASE=0x3f8
+
+# Select the serial protocol
+# This defaults to 8 data bits, 1 stop bit, and no parity
+default TTYS0_LCS=0x3
+
+##
+## The default compiler
+##
+default CROSS_COMPILE=""
+default CC="$(CROSS_COMPILE)gcc -m32"
+default HOSTCC="gcc"
+
+end
+

Added: trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/auto.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/auto.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/auto.c	2007-06-07 20:52:42 UTC (rev 2716)
@@ -0,0 +1,59 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define ASSEMBLY 1
+
+#include <stdint.h>
+#include <device/pci_def.h>
+#include <arch/io.h>
+#include <device/pnp_def.h>
+#include <arch/romcc_io.h>
+#include <arch/hlt.h>
+#include "pc80/serial.c"
+#include "arch/i386/lib/console.c"
+#include "ram/ramtest.c"
+#include "superio/winbond/w83977f/w83977f_early_serial.c"
+#include "cpu/x86/bist.h"
+#include "pc80/udelay_io.c"
+
+#define SERIAL_DEV PNP_DEV(0x3f0, W83977F_SP1)
+
+#include "northbridge/amd/gx1/raminit.c"
+
+static void main(unsigned long bist)
+{
+	/* Initialize the serial console. */
+	w83977f_enable_serial(SERIAL_DEV, TTYS0_BASE);
+	uart_init();
+	console_init();
+
+	/* Halt if there was a built in self test failure. */
+	report_bist_failure(bist);
+
+	/* Disable Watchdog Timer. */
+	inb(0x043);
+	inb(0x843);
+
+	/* Initialize RAM. */
+	sdram_init();
+
+	/* Check RAM. */
+	/* ram_check(0x00000000, 640 * 1024); */
+}

Added: trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/chip.h
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/chip.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/chip.h	2007-06-07 20:52:42 UTC (rev 2716)
@@ -0,0 +1,25 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+extern struct chip_operations mainboard_iei_juki_511p_ops;
+
+struct mainboard_iei_juki_511p_config {
+	int nothing;
+};

Added: trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/cmos.layout
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/cmos.layout	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/cmos.layout	2007-06-07 20:52:42 UTC (rev 2716)
@@ -0,0 +1,73 @@
+entries
+
+#start-bit length  config config-ID    name
+#0            8       r       0        seconds
+#8            8       r       0        alarm_seconds
+#16           8       r       0        minutes
+#24           8       r       0        alarm_minutes
+#32           8       r       0        hours
+#40           8       r       0        alarm_hours
+#48           8       r       0        day_of_week
+#56           8       r       0        day_of_month
+#64           8       r       0        month
+#72           8       r       0        year
+#80           4       r       0        rate_select
+#84           3       r       0        REF_Clock
+#87           1       r       0        UIP
+#88           1       r       0        auto_switch_DST
+#89           1       r       0        24_hour_mode
+#90           1       r       0        binary_values_enable
+#91           1       r       0        square-wave_out_enable
+#92           1       r       0        update_finished_enable
+#93           1       r       0        alarm_interrupt_enable
+#94           1       r       0        periodic_interrupt_enable
+#95           1       r       0        disable_clock_updates
+#96         288       r       0        temporary_filler
+0          384       r       0        reserved_memory
+384          1       e       4        boot_option
+385          1       e       4        last_boot
+386          1       e       1        ECC_memory
+388          4       r       0        reboot_bits
+392          3       e       5        baud_rate
+400          1       e       1        power_on_after_fail
+412          4       e       6        debug_level
+416          4       e       7        boot_first
+420          4       e       7        boot_second
+424          4       e       7        boot_third
+428          4       h       0        boot_index
+432	     8       h       0        boot_countdown
+1008         16      h       0        check_sum
+
+enumerations
+
+#ID value   text
+1     0     Disable
+1     1     Enable
+2     0     Enable
+2     1     Disable
+4     0     Fallback
+4     1     Normal
+5     0     115200
+5     1     57600
+5     2     38400
+5     3     19200
+5     4     9600
+5     5     4800
+5     6     2400
+5     7     1200
+6     6     Notice
+6     7     Info
+6     8     Debug
+6     9     Spew
+7     0     Network
+7     1     HDD
+7     2     Floppy
+7     8     Fallback_Network
+7     9     Fallback_HDD
+7     10    Fallback_Floppy
+#7     3     ROM
+
+checksums
+
+checksum 392 1007 1008
+

Added: trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/failover.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/failover.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/failover.c	2007-06-07 20:52:42 UTC (rev 2716)
@@ -0,0 +1,53 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define ASSEMBLY 1
+
+#include <stdint.h>
+#include <device/pci_def.h>
+#include <device/pci_ids.h>
+#include <arch/io.h>
+#include "arch/romcc_io.h"
+#include "pc80/mc146818rtc_early.c"
+
+static unsigned long main(unsigned long bist)
+{
+	/* This is the primary cpu how should I boot? */
+	if (do_normal_boot()) {
+		goto normal_image;
+	}
+	else {
+		goto fallback_image;
+	}
+normal_image:
+	asm volatile ("jmp __normal_image"
+		: /* outputs */
+		: "a" (bist) /* inputs */
+		: /* clobbers */
+		);
+cpu_reset:
+	asm volatile ("jmp __cpu_reset"
+		: /* outputs */
+		: "a"(bist) /* inputs */
+		: /* clobbers */
+		);
+fallback_image:
+	return bist;
+}

Added: trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/irq_tables.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/irq_tables.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/irq_tables.c	2007-06-07 20:52:42 UTC (rev 2716)
@@ -0,0 +1,103 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <arch/pirq_routing.h>
+
+#define IRQ_BITMAP_LINK0 0x0800		/* chipset's INTA# input should be routed to IRQ11 */
+#define IRQ_BITMAP_LINK1 0x0400		/* chipset's INTB# input should be routed to IRQ10 */
+#define IRQ_BITMAP_LINK2 0x0000		/* chipset's INTC# input should be routed to nothing (disabled) */
+#define IRQ_BITMAP_LINK3 0x0000		/* chipset's INTD# input should be routed to nothing (disabled) */
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,	 /* u32 signature */
+	PIRQ_VERSION,	 /* u16 version */
+	32+16*2,	 /* There can be a total of 2 devices on the bus */
+	0x00,		 /* Where the interrupt router lies (bus) */
+	(0x12<<3)|0x0,	 /* Where the interrupt router lies (dev) */
+	0xc00,		 /* IRQs devoted exclusively to PCI usage */
+	0x1078,		 /* Vendor */
+	0x2,		 /* Device */
+	0,		 /* Crap (miniport) */
+	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
+	0x57,		 /* u8 checksum. This has to be set to some
+			    value that would give 0 after the sum of all
+			    bytes for this structure (including checksum) */
+
+	.slots = {
+		[0] = {
+			.slot = 0x0,	/* should be 0 when it is no real slot. My device is soldered */
+			.bus = 0x00,
+			.devfn = (0x13<<3)|0x0,	/* 0x13 is my USB OHCI */
+			.irq = {
+				[0] = {	/* <-- 0 means this is INTA# output from the device or slot */
+					.link = 0x01,			/* 0x01 means its connected to INTA# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK0
+				},
+				[1] = {	/* <-- 1 means this is INTB# output from the device or slot */
+					.link = 0x02,			/* 0x02 means its connected to INTB# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK1
+				},
+				[2] = {	/* <-- 2 means this is INTC# output from the device or slot */
+					.link = 0x03,			/* 0x03 means its connected to INTC# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK2
+				},
+				[3] = {	/* <-- 3 means this is INTD# output from the device or slot */
+					.link = 0x04,			/* 0x04 means its connected to INTD# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK3
+				}
+			}
+		},
+
+		[1] = {
+			.slot = 0x0,	/* means also "on board" */
+			.bus = 0x00,
+			.devfn = (0x0e<<3)|0x0,	/* 0x0e is my Realtek Network device */
+			.irq = {
+				[0] = {	/* <-- 0 means this is INTA# output from the device or slot */
+					.link = 0x02,			/* 0x02 means its connected to INTB# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK1
+				},
+				[1] = {	/* <-- 1 means this is INTB# output from the device or slot */
+					.link = 0x03,			/* 0x03 means its connected to INTC# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK2
+				},
+				[2] = {	/* <-- 2 means this is INTC# output from the device or slot */
+					.link = 0x04,			/* 0x04 means its connected to INTD# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK3
+				},
+				[3] = {	/* <-- 3 means this is INTD# output from the device or slot */
+					.link = 0x01,			/* 0x01 means its connected to INTA# input at chipset */
+					.bitmap = IRQ_BITMAP_LINK0
+				}
+			}
+		}
+	}
+};
+
+/**
+ * Copy the IRQ routing table to memory.
+ *
+ * @param addr Destination address (between 0xF0000...0x100000).
+ * @return The end address of the pirq routing table in memory.
+ */
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+	return copy_pirq_routing_table(addr);
+}

Added: trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/mainboard.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/mainboard.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/iei/juki-511p/mainboard.c	2007-06-07 20:52:42 UTC (rev 2716)
@@ -0,0 +1,31 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include <arch/io.h>
+#include "chip.h"
+
+struct chip_operations mainboard_iei_juki_511p_ops = {
+	CHIP_NAME("IEI JUKI-511P Mainboard")
+};

Added: trunk/LinuxBIOSv2/targets/iei/juki-511p/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/targets/iei/juki-511p/Config.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/targets/iei/juki-511p/Config.lb	2007-06-07 20:52:42 UTC (rev 2716)
@@ -0,0 +1,37 @@
+##
+## This file is part of the LinuxBIOS project.
+##
+## Copyright (C) 2007 Nikolay Petukhov <nikolay.petukhov at gmail.com>
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+target juki-511p
+mainboard iei/juki-511p
+
+option ROM_SIZE=256*1024
+
+option HAVE_PIRQ_TABLE=1
+
+option CONFIG_COMPRESS=0
+option CONFIG_PRECOMPRESSED_PAYLOAD=0
+
+romimage "image"
+	option ROM_IMAGE_SIZE=64*1024
+	option LINUXBIOS_EXTRA_VERSION="-filo"
+	payload ../../filo.elf
+end
+
+buildrom ./linuxbios.rom ROM_SIZE "image"




From uwe at hermann-uwe.de  Thu Jun  7 23:01:41 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 7 Jun 2007 23:01:41 +0200
Subject: [LinuxBIOS] new target iei juki-511p/rocky-512
In-Reply-To: <e24af7500706040515j3e2e7ef7k5e86485e81d9555f@mail.gmail.com>
References: <e24af7500706040515j3e2e7ef7k5e86485e81d9555f@mail.gmail.com>
Message-ID: <20070607210141.GC19063@greenwood>

On Mon, Jun 04, 2007 at 06:15:17PM +0600, Nikolay Petukhov wrote:
> 2007/6/3, Stefan Reinauer <stepan at coresystems.de>:
> >Please sign off the patch according to
> >http://www.linuxbios.org/Development_Guidelines#Sign-off_Procedure
> >so we can check this patch in!
> 
> 
> Add sign-off.

Thanks!

The Super I/O patch is committed as r2714, the JUKI-511P code in r2716,
both with minor cosmetic changes.

I also renamed the directory to juki-511p (minus vs. underscore).


> >What does not work? ide1? AFAICS the boards only have one IDE port!?
> 
> The this boards has two IDE ports. IDE0 has 40-pin IDE connector. IDE1
> has CF connector.

Ah, ok. Does booting from IDE1 work with a proprietary BIOS? Try my
CS5530 patch, that _may_ fix the problem (it initializes both IDE0 and
IDE1). Some more IDE work may be needed in LinuxBIOS, though.

Please post a boot log with the CS5530 patch applied.


> +#dir /pc80
> +#config chip.h

Why is this commented? Not needed?


> +        device pci 12.1 on  end		# SMI
> +        device pci 12.2 on  end		# IDE
> +        device pci 12.3 on  end 	# Audio
> +      	device pci 12.4 on  end		# VGA onboard

With my CS5530 patch you might need to enable IDE0/IDE1 explicitly here:

      register "ide0_enable" = "1"
      register "ide1_enable" = "1"


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070607/206e245c/attachment.sig>

From info at coresystems.de  Thu Jun  7 23:38:18 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Thu, 07 Jun 2007 23:38:18 +0200
Subject: [LinuxBIOS] r2716 build service
Message-ID: <E1HwPgQ-0002m3-83@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2716 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add support for the IEI JUKI-511P and IEI ROCKY-512 half-size boards.

Both are very similar, thus both use the JUKI-511P target.

Linux with patches from Juergen Beisert
(http://www.linuxbios.org/pipermail/linuxbios/2007-May/020932.html)
boots and work fine (ide, usb, ethernet, serial, keyboard and sound
work normally).

Problems:
 - Filo loads a bzImage only from ide0 (ide1 doesn't work yet).
 - Video doesn't work, yet.

Signed-off-by: Nikolay Petukhov <nikolay.petukhov at gmail.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2716&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2716&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2716&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2716&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2716&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2716&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From svn at openbios.org  Fri Jun  8 00:16:30 2007
From: svn at openbios.org (svn at openbios.org)
Date: Fri,  8 Jun 2007 00:16:30 +0200
Subject: [LinuxBIOS] r2717 - trunk/LinuxBIOSv2/src/northbridge/intel/i440bx
Message-ID: <mailman.389.1355071119.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-08 00:16:30 +0200 (Fri, 08 Jun 2007)
New Revision: 2717

Modified:
   trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/raminit.c
Log:
Minor tweaks in the 440BX RAM init code (trivial).
Still hardcoded for Tyan S1846.

This slightly increases performance, but it's still pretty horrible.
Some RAM settings are causing a dramatically slow system (confirmed
by comparing memtest performance results of the proprietary BIOS
and our code). Haven't found the problem, yet.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/raminit.c
===================================================================
--- trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/raminit.c	2007-06-07 20:52:42 UTC (rev 2716)
+++ trunk/LinuxBIOSv2/src/northbridge/intel/i440bx/raminit.c	2007-06-07 22:16:30 UTC (rev 2717)
@@ -129,7 +129,11 @@
 	 * [01:00] Reserved
 	 */
 	// TODO
-	NBXCFG, 0x00000000, 0xff00a00c,
+	NBXCFG + 0, 0x00, 0x0c,
+	// NBXCFG + 1, 0x00, 0xa0,
+	NBXCFG + 1, 0x00, 0x80,
+	NBXCFG + 2, 0x00, 0x00,
+	NBXCFG + 3, 0x00, 0xff,
 
 	/* DRAMC - DRAM Control Register
 	 * 0x57
@@ -154,7 +158,7 @@
 	 *       111 = Reserved
 	 */
 	/* Choose SDRAM (not registered), and disable refresh for now. */
-	DRAMC, 0x00, 0x8,
+	DRAMC, 0x00, 0x08,
 
 	/*
 	 * PAM[6:0] - Programmable Attribute Map Registers
@@ -240,7 +244,8 @@
 	 *        TODO
 	 */
 	// TODO
-	RPS, 0x0000, 0x0000,
+	RPS + 0, 0x00, 0x00,
+	RPS + 1, 0x00, 0x00,
 
 	/* SDRAMC - SDRAM Control Register
 	 * 0x76 - 0x77
@@ -276,7 +281,8 @@
 	 *         0 = 3 clocks of RAS# precharge
 	 *         1 = 2 clocks of RAS# precharge
 	 */
-	SDRAMC, 0x0000, 0x0000,
+	SDRAMC + 0, 0x00, 0x00,
+	SDRAMC + 0, 0x00, 0x00,
 
 	/* PGPOL - Paging Policy Register
 	 * 0x78 - 0x79
@@ -299,7 +305,8 @@
 	 *         1xxx = Infinite (pages are not closed for idle condition)
 	 */
 	// TODO
-	PGPOL, 0x0000, 0xff00,
+	PGPOL + 0, 0x00, 0x00,
+	PGPOL + 1, 0x00, 0xff,
 
 	/* PMCR - Power Management Control Register
 	 * 0x7a
@@ -418,7 +425,7 @@
 static void sdram_set_registers(const struct mem_controller *ctrl)
 {
 	int i, max;
-	uint32_t reg;
+	uint8_t reg;
 
 	PRINT_DEBUG("Northbridge prior to SDRAM init:\r\n");
 	DUMPNORTH();
@@ -427,15 +434,15 @@
 
 	/* Set registers as specified in the register_values[] array. */
 	for (i = 0; i < max; i += 3) {
-		reg = pci_read_config32(ctrl->d0, register_values[i]);
+		reg = pci_read_config8(ctrl->d0, register_values[i]);
 		reg &= register_values[i + 1];
 		reg |= register_values[i + 2] & ~(register_values[i + 1]);
-		pci_write_config32(ctrl->d0, register_values[i], reg);
+		pci_write_config8(ctrl->d0, register_values[i], reg);
 
 		PRINT_DEBUG("    Set register 0x");
-		PRINT_DEBUG_HEX32(register_values[i]);
+		PRINT_DEBUG_HEX8(register_values[i]);
 		PRINT_DEBUG(" to 0x");
-		PRINT_DEBUG_HEX32(reg);
+		PRINT_DEBUG_HEX8(reg);
 		PRINT_DEBUG("\r\n");
 	}
 }
@@ -480,23 +487,26 @@
 	pci_write_config16(ctrl->d0, RPS, 0x0001);
 
 	/* TODO: Set SDRAMC. */
-	// pci_write_config16(ctrl->d0, SDRAMC, 0x0000);
+	// pci_write_config16(ctrl->d0, SDRAMC, 0x010f); // FIXME?
+	pci_write_config16(ctrl->d0, SDRAMC, 0x0003); // FIXME?
 
 	/* TODO: Set PGPOL. */
-	pci_write_config16(ctrl->d0, PGPOL, 0x0107);
+	// pci_write_config16(ctrl->d0, PGPOL, 0x0107);
+	pci_write_config16(ctrl->d0, PGPOL, 0x0123);
 
 	/* TODO: Set NBXCFG. */
-	// pci_write_config32(ctrl->d0, NBXCFG, 0x0100220c);
+	// pci_write_config32(ctrl->d0, NBXCFG, 0x0100220c); // FIXME?
+	pci_write_config32(ctrl->d0, NBXCFG, 0xff00800c);
 
 	/* TODO: Set PMCR? */
 	// pci_write_config8(ctrl->d0, PMCR, 0x14);
-	// pci_write_config8(ctrl->d0, PMCR, 0x10);
+	pci_write_config8(ctrl->d0, PMCR, 0x10);
 
 	/* TODO? */
-	// pci_write_config8(ctrl->d0, MLT, 0x40);
-	// pci_write_config8(ctrl->d0, DRAMT, 0x03);
-	// pci_write_config8(ctrl->d0, MBSC, 0x03);
-	// pci_write_config8(ctrl->d0, SCRR, 0x38);
+	pci_write_config8(ctrl->d0, MLT, 0x40);
+	pci_write_config8(ctrl->d0, DRAMT, 0x03);
+	pci_write_config8(ctrl->d0, MBSC, 0x03);
+	pci_write_config8(ctrl->d0, SCRR, 0x38);
 }
 
 /**




From rminnich at gmail.com  Fri Jun  8 00:48:58 2007
From: rminnich at gmail.com (ron minnich)
Date: Thu, 7 Jun 2007 15:48:58 -0700
Subject: [LinuxBIOS] r349 - LinuxBIOSv3/include
In-Reply-To: <20070607173727.19844.qmail@cdy.org>
References: <20070607173727.19844.qmail@cdy.org>
Message-ID: <13426df10706071548s322bbd9asd54d3ea80c800c39@mail.gmail.com>

OK peter you win :-)

I am going to try a simple experiment on my tree, which is to have a
'dts' in each directory, with a spec of the chip and optional defaults
-- I do not like the defaults in the dts, I really feel they belong in
kconfig but -- and I will try to GENERATE the .h file from the
pre-chip dts.


That will be my homework for next week, will report back.

I will pause LX port until I test this.

ron



From info at coresystems.de  Fri Jun  8 01:01:10 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Fri, 08 Jun 2007 01:01:10 +0200
Subject: [LinuxBIOS] r2717 build service
Message-ID: <E1HwQyc-0001Ns-6J@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2717 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Minor tweaks in the 440BX RAM init code (trivial).
Still hardcoded for Tyan S1846.

This slightly increases performance, but it's still pretty horrible.
Some RAM settings are causing a dramatically slow system (confirmed
by comparing memtest performance results of the proprietary BIOS
and our code). Haven't found the problem, yet.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2717&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2717&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2717&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2717&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2717&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2717&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From stuge-linuxbios at cdy.org  Fri Jun  8 01:52:25 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri, 8 Jun 2007 01:52:25 +0200
Subject: [LinuxBIOS] Advantech SOM-4455F
In-Reply-To: <46686D5E.2020404@daemonicpenguin.net>
References: <4668671E.7090905@daemonicpenguin.net>
	<20070607201920.GA11634@coresystems.de>
	<46686D5E.2020404@daemonicpenguin.net>
Message-ID: <20070607235225.1010.qmail@cdy.org>

On Fri, Jun 08, 2007 at 02:41:02AM +0600, Richard Neill Dabney wrote:
> That's would seem to be the case. Is the emulator so limited that
> it can't run a generic 1995-vintage BIOS?

Dunno. Can we get some more info on the particular opcode?


> >> copying VGA ROM Image from 0xfd020000 to 0xc0000, 0x8000 bytes
> >> entering emulator
> >> 0000:60b6: 20 ILLEGAL EXTENDED X86 OPCODE!

Is 0x20 the opcode at 0x60b6? That would be RETN which I think should
work? The ops2.c file seems to indicate these are 2byte-opcodes?

Strange.

Are you sure the image is correct? Can you try unpacking a factory
BIOS with some of the unpacker tools that have been mentioned on the
list?


//Peter



From stuge-linuxbios at cdy.org  Fri Jun  8 01:53:35 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri, 8 Jun 2007 01:53:35 +0200
Subject: [LinuxBIOS] new target iei juki-511p/rocky-512
In-Reply-To: <20070607210141.GC19063@greenwood>
References: <e24af7500706040515j3e2e7ef7k5e86485e81d9555f@mail.gmail.com>
	<20070607210141.GC19063@greenwood>
Message-ID: <20070607235335.1313.qmail@cdy.org>

On Thu, Jun 07, 2007 at 11:01:41PM +0200, Uwe Hermann wrote:
> Ah, ok. Does booting from IDE1 work with a proprietary BIOS?

I think this is a FILO problem.


//Peter



From stuge-linuxbios at cdy.org  Fri Jun  8 02:17:00 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri, 8 Jun 2007 02:17:00 +0200
Subject: [LinuxBIOS] Advantech SOM-4455F
In-Reply-To: <20070607235225.1010.qmail@cdy.org>
References: <4668671E.7090905@daemonicpenguin.net>
	<20070607201920.GA11634@coresystems.de>
	<46686D5E.2020404@daemonicpenguin.net>
	<20070607235225.1010.qmail@cdy.org>
Message-ID: <20070608001700.5605.qmail@cdy.org>

On Fri, Jun 08, 2007 at 01:52:25AM +0200, Peter Stuge wrote:
> > >> copying VGA ROM Image from 0xfd020000 to 0xc0000, 0x8000 bytes
> > >> entering emulator
> > >> 0000:60b6: 20 ILLEGAL EXTENDED X86 OPCODE!
> 
> Is 0x20 the opcode at 0x60b6? That would be RETN which I think
> should work? The ops2.c file seems to indicate these are
> 2byte-opcodes?

I'm confused. 0x20 is the first byte of a two-byte and instruction.

Something must be wrong. What's the byte before 0x20, at 0x60b5?


//Peter



From augusto.pedroza at gmail.com  Fri Jun  8 16:23:23 2007
From: augusto.pedroza at gmail.com (Augusto Pedroza)
Date: Fri, 8 Jun 2007 11:23:23 -0300
Subject: [LinuxBIOS] Current Status - GSoC Booting Windows
Message-ID: <e5e6db420706080723i6ae2a35dy4289c88b78f8af3e@mail.gmail.com>

Hi all,

I found out the output error messages due to missing interrupts are not
responsible for hanging windows boot.

Since QEMU is able to support win2k and winXP using a full bochs bios, I
have been investigating all the initialization done in the file
rombios32.cin order to find out what has to be added/changed en
LinuxBIOS/ADLO.
I just updated the wiki:
http://www.linuxbios.org/Booting_Windows_using_LinuxBIOS

We are also trying to get FREELDR to work with LinuxBIOS with the help of
the ReactOS project.

Please feel free to suggest anything.


Thanks,
-- 
Augusto Pedroza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070608/2dc83689/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Fri Jun  8 16:48:32 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Fri, 08 Jun 2007 16:48:32 +0200
Subject: [LinuxBIOS] new target iei juki-511p/rocky-512
In-Reply-To: <20070607210141.GC19063@greenwood>
References: <e24af7500706040515j3e2e7ef7k5e86485e81d9555f@mail.gmail.com>
	<20070607210141.GC19063@greenwood>
Message-ID: <46696C40.1060408@gmx.net>

On 07.06.2007 23:01, Uwe Hermann wrote:
> The Super I/O patch is committed as r2714, the JUKI-511P code in r2716,
> both with minor cosmetic changes.
> 
> I also renamed the directory to juki-511p (minus vs. underscore).

The abuild of your checkin fails. Any reasons for that?


Regards,
Carl-Daniel



From uwe at hermann-uwe.de  Fri Jun  8 17:11:37 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 8 Jun 2007 17:11:37 +0200
Subject: [LinuxBIOS] [PATCH] Add generic Intel i82801 support
In-Reply-To: <46652C47.4030808@gmail.com>
References: <46652C47.4030808@gmail.com>
Message-ID: <20070608151136.GB21835@greenwood>

Hi,

On Tue, Jun 05, 2007 at 05:26:31AM -0400, Corey Osgood wrote:
> BTW, i810 will be on its way again soon, I'm trying to
> get vga working first.

Please post your current patch. Let's get a somewhat "stable" version
into svn first and fix remaining issues later. The patches will be a
lot smaller and more manageable then...

Ditto for this 82801XX code, please post your current version (maybe
with the PCI IDs stuff Stefan suggested).


Here are some more comments, but not all of this has to be fixed in
this revision, we can make extra patches later for some of these issues...


> Index: src/southbridge/intel/i82801xx/i82801xx_ac97.c
> ===================================================================
> --- src/southbridge/intel/i82801xx/i82801xx_ac97.c	(revision 0)
> +++ src/southbridge/intel/i82801xx/i82801xx_ac97.c	(revision 0)
> @@ -0,0 +1,62 @@
> +#include <console/console.h>
> +#include <device/device.h>
> +#include <device/pci.h>
> +#include <device/pci_ids.h>
> +#include <device/pci_ops.h>

pci_ops.h can be dropped, I think. It's already included by pci.h.


> +#include "i82801xx.h"
> +#include "i82801_model_specific.h"
> +
> +#ifdef I82801_AC97

Can we put these #ifdefs in the Config.lb file around the
  driver i82801xx_foo.o
lines? That's more readable than having them spread over all files, IMO.


> +static void ac97_set_subsystem(device_t dev, unsigned vendor, unsigned device)
> +{
> +	/* Write the subsystem vendor and device id */
> +	pci_write_config32(dev, PCI_SUBSYSTEM_VENDOR_ID, 
> +		((device & 0xffff) << 16) | (vendor & 0xffff));
> +}

I think this is not required. The generic PCI device code already does
exactly this per default, so...


> +static struct pci_operations lops_pci = {
> +	.set_subsystem = ac97_set_subsystem,
> +};

...this can be dropped, ...


> +static struct device_operations ac97_ops  = {
> +	.read_resources   = pci_dev_read_resources,
> +	.set_resources    = pci_dev_set_resources,
> +	.enable_resources = pci_dev_enable_resources,
> +	.init             = 0,
> +	.scan_bus         = 0,
> +	.enable           = i82801xx_enable,


> +	.ops_pci          = &lops_pci,

... and this can be omitted, too.

(should be tested of course, but I'm pretty confident the default
function will be applied/used if it's not overridden here)


> +static struct pci_driver ac97_audio_driver __pci_driver = {
> +	.ops    = &ac97_ops,
> +	.vendor = PCI_VENDOR_ID_INTEL,
> +	.device = I82801_AC97,

PCI_DEVICE_ID_INTEL_I82801XX_AC97, please (defined in pci_ids.h, or
maybe localy in 82801XX code?)

Or rather, as per Stefan's suggestion, one driver entry for each real
device (for ICH0, ICH1, ICH2, etc.) if the PCI IDs are different.


> +static struct device_operations nic_ops  = {
> +	.read_resources   = pci_dev_read_resources,
> +	.set_resources    = pci_dev_set_resources,
> +	.enable_resources = pci_dev_enable_resources,
> +	.init             = 0,
> +	.scan_bus         = 0,
> +};

Maybe add a comment here that this doesn't need special setup, and the
usual PCI ops are enough.


> +static void pci_init(struct device *dev)
> +{
> +	uint32_t dword;
> +	uint16_t word;

Can we use reg16 and reg32 as names here? "Word" is a bit unfortunate,
not all architectures call a 16bit value a "word".


> Index: src/southbridge/intel/i82801xx/i82801xx_lpc.c
> ===================================================================
> --- src/southbridge/intel/i82801xx/i82801xx_lpc.c	(revision 0)
> +++ src/southbridge/intel/i82801xx/i82801xx_lpc.c	(revision 0)
> @@ -0,0 +1,246 @@
> +/*
> + * This file is part of the LinuxBIOS project.
> + *
> + * Copyright (C) 2003 Linux Networx, SuSE Linux AG

Two copyright lines here, please.


> +#define NMI_OFF 0

Should be a config option maybe (later).


> +void i82801xx_enable_ioapic( struct device *dev) 
> +{
> +	uint32_t dword;
> +	volatile uint32_t *ioapic_index = (volatile uint32_t *)0xfec00000;
> +	volatile uint32_t *ioapic_data = (volatile uint32_t *)0xfec00010;

TODO: check if these addresses are the same for all 82801XX devices.


> +	dword = pci_read_config32(dev, GEN_CNTL);
> +	dword |= (3 << 7); /* Enable IOAPIC */
> +	dword |= (1 << 13); /* Coprocessor error enable */
> +	dword |= (1 << 1); /* Delayed transaction enable */
> +	dword |= (1 << 2); /* DMA collection buffer enable */

#defines badly needed here.


> +void i82801xx_enable_serial_irqs( struct device *dev)
> +{
> +	/* set packet length and toggle silent mode bit */
> +	pci_write_config8(dev, SERIRQ_CNTL, (1 << 7)|(1 << 6)|((21 - 17) << 2)|(0 << 0));
> +	pci_write_config8(dev, SERIRQ_CNTL, (1 << 7)|(0 << 6)|((21 - 17) << 2)|(0 << 0));
> +	/* TODO: Get rid of the nasty ugly confusing bit ^^^ */

#defines. Which ugly bit? What's ugly? Why?
(yes, I know you didn't write that code/comment, but we need to find out
and fix this)


> +void i82801xx_lpc_route_dma( struct device *dev, uint8_t mask) 
> +{
> +        uint16_t word;
> +        int i;
> +        word = pci_read_config16(dev, PCI_DMA_CFG);
> +        word &= 0x300;
> +        for(i = 0; i < 8; i++) {
> +                if (i == 4)
> +                        continue;
> +                word |= ((mask & (1 << i))? 3:1) << (i * 2);

Ditto. Needs #defines and good comments/explanations.


> +void i82801xx_1f0_misc(struct device *dev)
> +{
> +	/* Prevent LPC disabling, enable parity errors, and SERR# (System Error) */
> +	pci_write_config16(dev, PCI_COMMAND, 0x014f);
> +	/* Set ACPI base address to 0x1100 (I/O space) */
> +	pci_write_config32(dev, PMBASE, PM_BASE_ADDR | 1);
> +	/* Enable ACPI I/O and power management */
> +	pci_write_config8(dev, ACPI_CNTL, 0x10);

Shouldn't this stuff be in an extra *_acpi_*() function?


> +	/* Set GPIO base address to 0x1180 (I/O space) */
> +	pci_write_config32(dev, GPIO_BASE, GPIO_BASE_ADDR | 1);
> +	/* Enable GPIO */
> +	pci_write_config8(dev, GPIO_CNTL, 0x10);
> +	/* Route PIRQA to IRQ11, PIRQB to IRQ3, PIRQC to IRQ5, PIRQD to IRQ10 */
> +	pci_write_config32(dev, PIRQA_ROUT, 0x0A05030B);
> +	/* Route PIRQE to IRQ7. Leave PIRQF - PIRQH unrouted */
> +	pci_write_config8(dev, PIRQE_ROUT, 0x07);
> +	/* Enable access to the upper 128 byte bank of CMOS RAM */
> +	pci_write_config8(dev, RTC_CONF, 0x04);
> +	/* Decode 0x3F8-0x3FF (COM1) for COMA port, 0x2F8-0x2FF (COM2) for COMB */
> +	pci_write_config8(dev, COM_DEC, 0x10);
> +	/* LPT decode defaults to 0x378-0x37F and 0x778-0x77F
> +	 * Floppy decode defaults to 0x3F0-0x3F5, 0x3F7 */
> +	/* Enable: COMA, COMB, LPT, Floppy
> +	 * Disable: Microcontroller, Super I/O, Sound, Gameport */
> +	pci_write_config16(dev, LPC_EN, 0x000F);
> +}


> +static void enable_hpet(struct device *dev)
> +{
> +#ifdef HPET_PRESENT
> +        uint32_t dword;
> +	uint32_t code = (0 & 0x3);
> +        
> +        dword = pci_read_config32(dev, GEN_CNTL);
> +        dword |= (1 << 17); /* Enable HPET */
> +	/*Bits [16:15]Memory Address Range
> +	00 FED0_0000h - FED0_03FFh
> +	01 FED0_1000h - FED0_13FFh
> +	10 FED0_2000h - FED0_23FFh
> +	11 FED0_3000h - FED0_33FFh*/
> +
> +        dword &= ~(3 << 15); /* Clear it */
> +	dword |= (code << 15);
> +
> +	printk_debug("Enabling HPET @0x%x\n", HPET_ADDR | (code << 12));
> +#endif

Should be (runtime-)configurable later.


> + * Copyright (C) 2007 Corey Osgood <corey.osgood at gmail.com>
> + * Copyright (C) 2005 Digital Design Corporation

Swap order here please, keep the chronological order.


> +void i82801xx_enable(device_t dev)
> +{
> +	unsigned int index = 0;
> +	uint8_t bHasDisableBit = 0;

TODO for later: variable name fixing (should be all-lowercase).


> +	uint16_t cur_disable_mask, new_disable_mask;
> +
> +	// All 82801 devices should be on bus 0
> +	unsigned int devfn = PCI_DEVFN(0x1f, 0); // lpc
> +	device_t lpc_dev = dev_find_slot(0, devfn); // 0
> +	if (!lpc_dev)
> +		return;

A warning would be good, in addition to just returning.


> Index: src/southbridge/intel/i82801xx/i82801xx_reset.c
> ===================================================================
> --- src/southbridge/intel/i82801xx/i82801xx_reset.c	(revision 0)
> +++ src/southbridge/intel/i82801xx/i82801xx_reset.c	(revision 0)
> @@ -0,0 +1,27 @@
> +/*
> + * This file is part of the LinuxBIOS project.
> + *
> + * Copyright (C) 2002 Eric Biederman <ebiederm at xmission.com>

(C) Corey Osgood? Trivial function anyway...


> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
> + */
> +
> +#include <arch/io.h>
> +
> +void hard_reset(void)
> +{
> +        /* Try rebooting through port 0xcf9 */
> +        outb((0 <<3)|(1<<2)|(1<<1), 0xcf9);

Improvement: use #defines.

Also, the (0 << 3) looks a bit strange. This will logically OR bit 3
with a 0, which doesn't have any effect at all.
If the intention is to force bit 3 to be 0, it should be something like
this:

reg8 = inb(0xcf9);
reg8 |= (1 << 2) | (1 << 1);
reg8 &= ~(1 << 3)
outb(0xcf9);

Doing an inb() and modifying the value (as opposed to hardcoding a value
and simply write it) is the "correct" thing anyway. Bits 0 and 7:4 are
marked as reserved, thus should not be changed.
It may be unlikely to cause any harm in this case, but I think we
should -- in general -- always program defensively...


> Index: src/southbridge/intel/i82801xx/i82801xx.h
> ===================================================================
> --- src/southbridge/intel/i82801xx/i82801xx.h	(revision 0)
> +++ src/southbridge/intel/i82801xx/i82801xx.h	(revision 0)
> @@ -0,0 +1,106 @@
> +/*
> + * This file is part of the LinuxBIOS project.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
> + */
> +/* Copyright holder left out intentionally, I don't believe there's anything 
> +really copyrightable in here */

Maybe, but that's the case for other files, too. Just add yourself.
Every file should have a copyright holder and license header.


> +#include <smbus.h>
> +#include <pci.h>
> +#include <arch/io.h>
> +#include "i82801_model_specific.h"
> +#include "i82801xx.h"
> +#include "i82801_smbus.h"
> +
> +static int smbus_read_byte(struct bus *bus, device_t dev, uint8_t address)
> +{
> +	unsigned device;

unsigned -> uint8_t or similar?


> +/* This file's purpose is to define anything that may differ between different 
> + * models within the i82801 series */
> +
> +#if	I82801_MODEL == I82801AA
> +#define	I82801_PCI	0x2418	/* D30:F0, PCI Interface Hub */
> +#define	I82801_LPC	0x2410	/* D31:F0, LPC Interface Bridge */
> +#define	I82801_IDE	0x2411	/* D31:F1, IDE Controller */
> +#define	I82801_USB1	0x2412	/* D31:F2, USB Controller */
> +#define	I82801_SMBUS	0x2413	/* D31:F3, SMBUS Controller */
> +#define	I82801_AC97	0x2415	/* D31:F5, AC'97 Audio Controller */
> +#define	I82801_MC97	0x2416	/* D31:F6, AC'97 Modem Controller */

I'd prefer at least I82801XX_FOO (add the XX), but better would be the
full PCI IDs in pci_ids.h, as usual, and use the approach suggested by
Stefan.


> Index: src/southbridge/intel/i82801xx/cmos_failover.c
> ===================================================================
> --- src/southbridge/intel/i82801xx/cmos_failover.c	(revision 0)
> +++ src/southbridge/intel/i82801xx/cmos_failover.c	(revision 0)
> @@ -0,0 +1,32 @@
> +/*
> + * This file is part of the LinuxBIOS project.
> + *

Missing copyright owner.


> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
> + */
> +
> +#include "i82801xx.h"
> +
> +static void check_cmos_failed(void) 
> +{
> +	uint8_t byte;
> +	byte = pci_read_config8(PCI_DEV(0, 0x1f, 0), GEN_PMCON_3);
> +	if( byte & RTC_FAILED) {
> +		//clear bit 1 and bit 2
> +		byte = cmos_read(RTC_BOOT_BYTE);
> +		byte &= 0x0c;
> +		byte |= MAX_REBOOT_CNT << 4;
> +		cmos_write(byte, RTC_BOOT_BYTE);
> +	}
> +}


> +#ifndef I82801XX_CHIP_H
> +#define I82801XX_CHIP_H

SOUTHBRIDGE_INTEL_I82801XX_CHIP_H


> +static void ide_init(struct device *dev)
> +{
> +	/* TODO: Needs to be tested for compatibility with ICH5(R) */
> +	/* Enable ide devices so the linux ide driver will work */
> +	uint16_t ideTimingConfig;
> +	int enable_primary = 1;
> +	int enable_secondary = 1;

TODO for later: make all of this configurable. See my i82371EB patches
for an example.


You're doing really great work with this patch, we need such cleanups
for many other areas of the code! This will eliminate _lots_ of
duplicated or near-duplicated code, which is a huge win.


Thanks, Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070608/d310bbb7/attachment.sig>

From uwe at hermann-uwe.de  Fri Jun  8 17:18:17 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 8 Jun 2007 17:18:17 +0200
Subject: [LinuxBIOS] new target iei juki-511p/rocky-512
In-Reply-To: <46696C40.1060408@gmx.net>
References: <e24af7500706040515j3e2e7ef7k5e86485e81d9555f@mail.gmail.com>
	<20070607210141.GC19063@greenwood> <46696C40.1060408@gmx.net>
Message-ID: <20070608151817.GC21835@greenwood>

On Fri, Jun 08, 2007 at 04:48:32PM +0200, Carl-Daniel Hailfinger wrote:
> On 07.06.2007 23:01, Uwe Hermann wrote:
> > The Super I/O patch is committed as r2714, the JUKI-511P code in r2716,
> > both with minor cosmetic changes.
> > 
> > I also renamed the directory to juki-511p (minus vs. underscore).
> 
> The abuild of your checkin fails. Any reasons for that?

Yes, I guess the CS5530 code is not compiling. It was probably broken
all the time, I'm really curious why it didn't break stuff earlier...

My CS5530 patch (not yet committed) should fix that.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070608/8246931c/attachment.sig>

From stuge-linuxbios at cdy.org  Fri Jun  8 20:12:31 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri, 8 Jun 2007 20:12:31 +0200
Subject: [LinuxBIOS] Advantech SOM-4455F
In-Reply-To: <46699AEB.5000001@daemonicpenguin.net>
References: <4668671E.7090905@daemonicpenguin.net>
	<20070607201920.GA11634@coresystems.de>
	<46686D5E.2020404@daemonicpenguin.net>
	<20070607235225.1010.qmail@cdy.org>
	<20070608001700.5605.qmail@cdy.org>
	<4668BF04.4090403@daemonicpenguin.net>
	<20070608104938.5631.qmail@stuge.se>
	<46699AEB.5000001@daemonicpenguin.net>
Message-ID: <20070608181231.28141.qmail@cdy.org>

Going back on list..

On Sat, Jun 09, 2007 at 12:07:39AM +0600, Richard Neill Dabney wrote:
> The illegal instruction is in the callbiosint16 function where CR0
> is loaded to turn of protected mode.

Aha.

> I looked at the emulator code and sure enough, that sequence of
> 'movl %cr0,%eax' (0x0f, 0x20,0xc0) is illegal.
> It makes no sense. Did this ever work?

It does work for several other VGA BIOSes. They probably do not try
to switch to PM.

So I guess x86emu doesn't handle protected mode.

Could vm86 work instead of x86emu?


//Peter



From ben at hewson-venieri.com  Fri Jun  8 22:52:09 2007
From: ben at hewson-venieri.com (Ben Hewson)
Date: Fri, 08 Jun 2007 21:52:09 +0100
Subject: [LinuxBIOS] epia acpi patch ( for testing only )
Message-ID: <4669C179.4060403@hewson-venieri.com>


Here is a patch to add limited acpi support to the epia board. This is 
purely for testing purposes. I can't guarantee it will work, however on 
my 500Mhz Epia board it seems to be ok. There are changes to the 
mainboard Config/Options.lb so you will need to rebuild the target, 
before compiling.

This patch allows Linux to poweroff the mainboard correctly.
A shutdown -r also works, however, it should be noted that this will not 
be the same a a physical
reset as I don't think the chipset supports it, at least I can't find 
any references to a reset register.

There are some differences from my original BIOS. It reports only 2 CPU 
throttling states, however mine reports 16 as I believe this is correct. 
I have not been able to test this. Not even sure how to go about it.

Hopefully the ACPI supports S1 and S4 states (not tested) however as 
there are currently no ACPI wakeup devices, if you suspend the board it 
probably won't wakeup.
My main aim was to get power down working. I may have a go at including 
some wakeup functionality when I get time and get my head around the 
ACPI spec a little better.


best of luck
Ben

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: epia_acpi_patch.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070608/cd075197/attachment.ksh>

From stepan at coresystems.de  Fri Jun  8 23:55:47 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 8 Jun 2007 23:55:47 +0200
Subject: [LinuxBIOS] Advantech SOM-4455F
In-Reply-To: <20070608181231.28141.qmail@cdy.org>
References: <4668671E.7090905@daemonicpenguin.net>
	<20070607201920.GA11634@coresystems.de>
	<46686D5E.2020404@daemonicpenguin.net>
	<20070607235225.1010.qmail@cdy.org>
	<20070608001700.5605.qmail@cdy.org>
	<4668BF04.4090403@daemonicpenguin.net>
	<20070608104938.5631.qmail@stuge.se>
	<46699AEB.5000001@daemonicpenguin.net>
	<20070608181231.28141.qmail@cdy.org>
Message-ID: <20070608215547.GC2450@coresystems.de>

* Peter Stuge <stuge-linuxbios at cdy.org> [070608 20:12]:
> It does work for several other VGA BIOSes. They probably do not try
> to switch to PM.
> 
> So I guess x86emu doesn't handle protected mode.
> 
> Could vm86 work instead of x86emu?
 
worth a try. The code could be ported over from via/epia-m.

Maybe we should have a generic driver doing this as an alternative, as
we have in v3?


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From corey.osgood at gmail.com  Sat Jun  9 03:08:43 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Fri, 08 Jun 2007 21:08:43 -0400
Subject: [LinuxBIOS] [PATCH] Add generic Intel i82801 support
In-Reply-To: <20070608151136.GB21835@greenwood>
References: <46652C47.4030808@gmail.com> <20070608151136.GB21835@greenwood>
Message-ID: <4669FD9B.6000607@gmail.com>

Uwe Hermann wrote:
> Hi,
>
> On Tue, Jun 05, 2007 at 05:26:31AM -0400, Corey Osgood wrote:
>   
>> BTW, i810 will be on its way again soon, I'm trying to
>> get vga working first.
>>     
>
> Please post your current patch. Let's get a somewhat "stable" version
> into svn first and fix remaining issues later. The patches will be a
> lot smaller and more manageable then...
>
> Ditto for this 82801XX code, please post your current version (maybe
> with the PCI IDs stuff Stefan suggested).
>
>   

Waiting for fibreglass to dry right at the moment (geeks should never do
body work on cars). I'll finish the 82801 up later tonight and post the
patches. VGA is still not working, and it seems I've now broken the
previously working kernel boot, the latter of which needs to be fixed first.

> Here are some more comments, but not all of this has to be fixed in
> this revision, we can make extra patches later for some of these issues...
>   
And just a few responses, thanks

>> +#include "i82801xx.h"
>> +#include "i82801_model_specific.h"
>> +
>> +#ifdef I82801_AC97
>>     
>
> Can we put these #ifdefs in the Config.lb file around the
>   driver i82801xx_foo.o
> lines? That's more readable than having them spread over all files, IMO.
They're going away, hopefully, so this won't be an issue. Other than that, I'm not really sure, I threw them in the code to make it simple.


>> +static void ac97_set_subsystem(device_t dev, unsigned vendor, unsigned device)
>> +{
>> +	/* Write the subsystem vendor and device id */
>> +	pci_write_config32(dev, PCI_SUBSYSTEM_VENDOR_ID, 
>> +		((device & 0xffff) << 16) | (vendor & 0xffff));
>> +}
>>     
>
> I think this is not required. The generic PCI device code already does
> exactly this per default, so...
>   

Hmm, didn't know that. These were pulled from the i82801er, and it seems
to me that one of the devices requires some special protection method
that I haven't checked out yet.

>> +static struct pci_driver ac97_audio_driver __pci_driver = {
>> +	.ops    = &ac97_ops,
>> +	.vendor = PCI_VENDOR_ID_INTEL,
>> +	.device = I82801_AC97,
>>     
>
> PCI_DEVICE_ID_INTEL_I82801XX_AC97, please (defined in pci_ids.h, or
> maybe localy in 82801XX code?)
>
> Or rather, as per Stefan's suggestion, one driver entry for each real
> device (for ICH0, ICH1, ICH2, etc.) if the PCI IDs are different.
>   

To continue with stefan's idea, they'll be dropped entirely.

>> Index: src/southbridge/intel/i82801xx/i82801xx_lpc.c
>> ===================================================================
>> --- src/southbridge/intel/i82801xx/i82801xx_lpc.c	(revision 0)
>> +++ src/southbridge/intel/i82801xx/i82801xx_lpc.c	(revision 0)
>> @@ -0,0 +1,246 @@
>> +/*
>> + * This file is part of the LinuxBIOS project.
>> + *
>> + * Copyright (C) 2003 Linux Networx, SuSE Linux AG
>>     
>
> Two copyright lines here, please.
>   

This was the only thing copyright-wise I wasn't really sure about, if
this was written by SuSE for Linux Networx, vice versa, or if both
parties had something to do with it. This line was pulled from the
original header, in i82801er I believe.

>> +#define NMI_OFF 0
>>     
>
> Should be a config option maybe (later).
>   

yes, later.

>> +	dword = pci_read_config32(dev, GEN_CNTL);
>> +	dword |= (3 << 7); /* Enable IOAPIC */
>> +	dword |= (1 << 13); /* Coprocessor error enable */
>> +	dword |= (1 << 1); /* Delayed transaction enable */
>> +	dword |= (1 << 2); /* DMA collection buffer enable */
>>     
>
> #defines badly needed here.
>   

Agreed. I think they might already be defined, I just didn't use them,
since the code and defines were from different sources.

>> +void i82801xx_enable_serial_irqs( struct device *dev)
>> +{
>> +	/* set packet length and toggle silent mode bit */
>> +	pci_write_config8(dev, SERIRQ_CNTL, (1 << 7)|(1 << 6)|((21 - 17) << 2)|(0 << 0));
>> +	pci_write_config8(dev, SERIRQ_CNTL, (1 << 7)|(0 << 6)|((21 - 17) << 2)|(0 << 0));
>> +	/* TODO: Get rid of the nasty ugly confusing bit ^^^ */
>>     
>
> #defines. Which ugly bit? What's ugly? Why?
> (yes, I know you didn't write that code/comment, but we need to find out
> and fix this)
>   

I did write the comment, I was talking about that entire string of ORs,
mostly the "((21 - 17) << 2)", which makes no sense whatsoever to me.
Those all need either defines or a decent comment, or both.

>> +void i82801xx_lpc_route_dma( struct device *dev, uint8_t mask) 
>> +{
>> +        uint16_t word;
>> +        int i;
>> +        word = pci_read_config16(dev, PCI_DMA_CFG);
>> +        word &= 0x300;
>> +        for(i = 0; i < 8; i++) {
>> +                if (i == 4)
>> +                        continue;
>> +                word |= ((mask & (1 << i))? 3:1) << (i * 2);
>>     
>
> Ditto. Needs #defines and good comments/explanations.
>   

Comment yes, but I'm not sure a define could be used very well here.

>> +void i82801xx_1f0_misc(struct device *dev)
>> +{
>> +	/* Prevent LPC disabling, enable parity errors, and SERR# (System Error) */
>> +	pci_write_config16(dev, PCI_COMMAND, 0x014f);
>> +	/* Set ACPI base address to 0x1100 (I/O space) */
>> +	pci_write_config32(dev, PMBASE, PM_BASE_ADDR | 1);
>> +	/* Enable ACPI I/O and power management */
>> +	pci_write_config8(dev, ACPI_CNTL, 0x10);
>>     
>
> Shouldn't this stuff be in an extra *_acpi_*() function?
>   

Probably, but this was how the original code did it. I think I'm leaving
this alone for now though, and put in a todo.

>> +void i82801xx_enable(device_t dev)
>> +{
>> +	unsigned int index = 0;
>> +	uint8_t bHasDisableBit = 0;
>>     
>
> TODO for later: variable name fixing (should be all-lowercase).
>   
bHasDisableBit and a lot of that code is disappearing entirely. If the
function actually exists and can't be disabled, it seems that writes
have no effect, or at least not an effect that does anything to the
system, though this has only been tested on i82801aa. This is one of the
few remaining places those defines are used, and I've got some more
research to do on the others (watchdog and hpet).

>> +#include <arch/io.h>
>> +
>> +void hard_reset(void)
>> +{
>> +        /* Try rebooting through port 0xcf9 */
>> +        outb((0 <<3)|(1<<2)|(1<<1), 0xcf9);
>>     
>
> Improvement: use #defines.
>
> Also, the (0 << 3) looks a bit strange. This will logically OR bit 3
> with a 0, which doesn't have any effect at all.
> If the intention is to force bit 3 to be 0, it should be something like
> this:
>
> reg8 = inb(0xcf9);
> reg8 |= (1 << 2) | (1 << 1);
> reg8 &= ~(1 << 3)
> outb(0xcf9);
>
> Doing an inb() and modifying the value (as opposed to hardcoding a value
> and simply write it) is the "correct" thing anyway. Bits 0 and 7:4 are
> marked as reserved, thus should not be changed.
> It may be unlikely to cause any harm in this case, but I think we
> should -- in general -- always program defensively...
>   

I'll look into this, I never actually checked it out at all. This
file/function is a direct descendant from v1, so I figured it probably
worked, ie don't mess with it.

>> +/* This file's purpose is to define anything that may differ between different 
>> + * models within the i82801 series */
>> +
>> +#if	I82801_MODEL == I82801AA
>> +#define	I82801_PCI	0x2418	/* D30:F0, PCI Interface Hub */
>> +#define	I82801_LPC	0x2410	/* D31:F0, LPC Interface Bridge */
>> +#define	I82801_IDE	0x2411	/* D31:F1, IDE Controller */
>> +#define	I82801_USB1	0x2412	/* D31:F2, USB Controller */
>> +#define	I82801_SMBUS	0x2413	/* D31:F3, SMBUS Controller */
>> +#define	I82801_AC97	0x2415	/* D31:F5, AC'97 Audio Controller */
>> +#define	I82801_MC97	0x2416	/* D31:F6, AC'97 Modem Controller */
>>     
>
> I'd prefer at least I82801XX_FOO (add the XX), but better would be the
> full PCI IDs in pci_ids.h, as usual, and use the approach suggested by
> Stefan.
>   

Yep, currently working on this. Most of the IDs are already in pci_ids.h.

>> Index: src/southbridge/intel/i82801xx/cmos_failover.c
>> ===================================================================
>> --- src/southbridge/intel/i82801xx/cmos_failover.c	(revision 0)
>> +++ src/southbridge/intel/i82801xx/cmos_failover.c	(revision 0)
>> @@ -0,0 +1,32 @@
>> +/*
>> + * This file is part of the LinuxBIOS project.
>> + *
>>     
>
> Missing copyright owner.
>   

This was this way when I pulled it from the i82801er, can't be sure who
it belongs to (Yinghai? Eric? or even older than that?)

>> +static void ide_init(struct device *dev)
>> +{
>> +	/* TODO: Needs to be tested for compatibility with ICH5(R) */
>> +	/* Enable ide devices so the linux ide driver will work */
>> +	uint16_t ideTimingConfig;
>> +	int enable_primary = 1;
>> +	int enable_secondary = 1;
>>     
>
> TODO for later: make all of this configurable. See my i82371EB patches
> for an example.
>
>
> You're doing really great work with this patch, we need such cleanups
> for many other areas of the code! This will eliminate _lots_ of
> duplicated or near-duplicated code, which is a huge win.
>   

Yeah, it was already on the todo list, and should be pretty simple.
Later, though, for now enabling both ide controllers really can't hurt
much for a base test system.

BTW, I'm planning a much more complete and hopefully smarter rewrite for
v3, and with v3's build system this should be a lot easier to do. I've
been looking a lot at v3, and playing with qemu, and it's got me
excited, this next release should be great!

-Corey



From stepan at coresystems.de  Sat Jun  9 12:01:13 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 9 Jun 2007 12:01:13 +0200
Subject: [LinuxBIOS] [PATCH] Add generic Intel i82801 support
In-Reply-To: <4669FD9B.6000607@gmail.com>
References: <46652C47.4030808@gmail.com> <20070608151136.GB21835@greenwood>
	<4669FD9B.6000607@gmail.com>
Message-ID: <20070609100113.GA29374@coresystems.de>

* Corey Osgood <corey.osgood at gmail.com> [070609 03:08]:
> >> + * Copyright (C) 2003 Linux Networx, SuSE Linux AG
> >>     
> >
> > Two copyright lines here, please.
> 
> This was the only thing copyright-wise I wasn't really sure about, if
> this was written by SuSE for Linux Networx, vice versa, or if both
> parties had something to do with it. This line was pulled from the
> original header, in i82801er I believe.
 
Eric and me were working on that code at the same time, for AMD64. I
guess at some time it was used as a base to get the intel chip working.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From svn at openbios.org  Sat Jun  9 19:43:27 2007
From: svn at openbios.org (svn at openbios.org)
Date: Sat,  9 Jun 2007 19:43:27 +0200
Subject: [LinuxBIOS] r350 - in LinuxBIOSv3: . arch/x86 lib
Message-ID: <mailman.390.1355071119.16123.coreboot@coreboot.org>

Author: stepan
Date: 2007-06-09 19:43:26 +0200 (Sat, 09 Jun 2007)
New Revision: 350

Modified:
   LinuxBIOSv3/Kconfig
   LinuxBIOSv3/README
   LinuxBIOSv3/arch/x86/Makefile
   LinuxBIOSv3/lib/Makefile
Log:
Rework payload handling to only provide two options:
  - Payload file
  - No payload

Document the current procedure in the README.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: LinuxBIOSv3/Kconfig
===================================================================
--- LinuxBIOSv3/Kconfig	2007-06-07 17:34:17 UTC (rev 349)
+++ LinuxBIOSv3/Kconfig	2007-06-09 17:43:26 UTC (rev 350)
@@ -76,71 +76,32 @@
 
 choice
         prompt "Payload type"
-        default PAYLOAD_ELF
+        default PAYLOAD_NONE
 
-config PAYLOAD_FILO
-	bool "FILO"
+config PAYLOAD_ELF
+	bool "An ELF executable payload file"
 	help
-	  TODO
+	  Select this option if you have a payload image (an ELF file)
+	  which LinuxBIOS should run as soon as the basic hardware
+	  initialization is completed.
 
-config PAYLOAD_ETHERBOOT
-	bool "Etherboot"
-	help
-	  TODO
+	  You will be able to specify the location and file name of the
+	  payload image later.
 
-config PAYLOAD_MEMTEST86
-	bool "Memtest86"
+config PAYLOAD_NONE
+	bool "No payload"
 	help
-	  TODO
+	  Select this option if you want to create an "empty" LinuxBIOS
+	  ROM image for a certain mainboard, i.e. a LinuxBIOS ROM image
+	  which does not yet contain a payload.
 
-config PAYLOAD_LINUX
-	bool "Linux kernel"
-	help
-	  TODO
+	  For such an image to be useful, you have to use the 'lar' tool
+	  to add a payload to the ROM image later.
 
-config PAYLOAD_ELF
-	bool "Any ELF executable"
-	help
-	  TODO
-
-config PAYLOAD_DUMMY
-	bool "Dummy payload"
-	help
-	  For testing purposes only.
-
 endchoice
 
-config PAYLOAD_FILO_DIR
-	string "FILO source code directory"
-	depends PAYLOAD_FILO
-	default "/tmp/filo-0.5"
-	help
-	  The directory where the FILO source code is located.
-
-config PAYLOAD_FILO_CONFIGFILE
-	string "Filename of the FILO 'Config' file"
-	depends PAYLOAD_FILO
-	default "Config"
-	help
-	  The filename of the FILO 'Config' file to use. This file must reside
-	  in the directory specified via PAYLOAD_FILO_DIR.
-
-config PAYLOAD_LINUX_DIR
-	string "Linux kernel source code directory"
-	depends PAYLOAD_LINUX
-	default "/usr/src/linux"
-	help
-	  The directory where the Linux kernel source code is located.
-
-config PAYLOAD_LINUX_CONFIGFILE
-	string "Path and filename of the Linux .config file to use"
-	depends PAYLOAD_LINUX
-	default ".config" # FIXME!
-	help
-	  The path and filename of the Linux .config file to use.
-
-config PAYLOAD_ELF_FILE
-	string "Path and filename of the ELF file to use as payload"
+config PAYLOAD_FILE
+	string "Payload path and filename"
 	depends PAYLOAD_ELF
 	default "payload.elf"
 	help

Modified: LinuxBIOSv3/README
===================================================================
--- LinuxBIOSv3/README	2007-06-07 17:34:17 UTC (rev 349)
+++ LinuxBIOSv3/README	2007-06-09 17:43:26 UTC (rev 350)
@@ -6,7 +6,7 @@
 BIOS you can find in most of today's computers.
 
 It performs just a little bit of hardware initialization and then executes
-one of many possible payloads, e.g. a Linux kernel.
+one of many possible payloads.
 
 
 Payloads
@@ -39,38 +39,91 @@
  * http://www.linuxbios.org/Supported_Chipsets_and_Devices
 
 
-Building and Installing
+Building And Installing
 -----------------------
 
 Note: Currently only the x86 QEMU target is supported in LinuxBIOSv3.
 
 1) Build a payload:
 
-  For example: FILO.
+  THIS IS NOT IMPLEMENTED YET. PLEASE BUILD YOUR PAYLOAD MANUALLY.
 
+  $ make payload
+
+  This step is optional. The 'make payload' command will execute a
+  helper tool which allows you to easily build and configure a wide
+  variety of payloads. The result of this step is usually a file
+  called 'payload.elf' in the top-level directory.
+
 2) Configure LinuxBIOS:
 
   $ make menuconfig
 
-  Select at least the desired mainboard vendor, the mainboard device,
-  the size of your ROM chip, and a payload.
+  Select at least the desired mainboard vendor, the mainboard device, and
+  the size of your ROM chip. Per default LinuxBIOS will look for a file
+  called 'payload.elf' in the current directory and use that as the payload.
 
+  If that's not what you want, you can change the path/filename of the
+  payload to use some other payload file. Or you can choose 'No payload'
+  in the configuration menu, in which case the resulting LinuxBIOS ROM image
+  will not contain any payload. You'll have to manually add a payload
+  later using the 'lar' utility for the LinuxBIOS ROM image to be useful.
+
 3) Build the LinuxBIOS ROM image:
 
   $ make
 
-  The generated ROM image is build/linuxbios.rom.
+  The generated ROM image is the file linuxbios.rom in the build/ directory.
 
-4) You can now test the LinuxBIOS image using:
+4) Flash the LinuxBIOS ROM image on a BIOS chip:
 
+  $ flashrom -wv linuxbios.rom
+
+  NOTE: This step will OVERWRITE the current BIOS located on the ROM chip!
+  Make sure you have adequate backup facilities before performing this
+  step, otherwise you might not be able to recover in case of problems.
+  If you have any questions, please contact us on the mailing list!
+
+  The 'flashrom' tool is located in util/flashrom where you can build it
+  from source code by typing 'make'. Alternatively, your favorite Linux
+  distribution might ship a 'flashrom' package which provides the 'flashrom'
+  program in (e.g.) /usr/bin. On Debian GNU/Linux systems you can get
+  the flashrom package via 'apt-get install flashrom'.
+
+
+Testing LinuxBIOS Without Modifying Your Hardware
+-------------------------------------------------
+
+If you want to test LinuxBIOS without any risks before you really decide
+to use it on your hardware, you can use the QEMU system emulator to run
+LinuxBIOS virtually in QEMU.
+
+The required steps are:
+
+  $ make menuconfig
+
+    Select 'Emulated systems' as mainboard vendor and 'QEMU x86' as
+    mainboard model.
+
+  $ make
+
   $ qemu -L build -hda /dev/zero -serial stdio
 
-  If you have a full QEMU image with a Linux distribution installed,
-  you can boot that Linux kernel by using a proper FILO payload and typing:
+  This will run LinuxBIOS in QEMU and output all debugging messages (which
+  are usually emitted to a serial console) on stdout. It will not do
+  anything useful beyond that, as you provided no virtual harddrive to
+  QEMU (-hda /dev/zero).
 
+  If you have a full QEMU hard drive image (say /tmp/qemu.img) with a Linux
+  distribution installed, you can boot that Linux kernel by using a proper
+  FILO payload with LinuxBIOS and typing:
+
   $ qemu -L build -hda /tmp/qemu.img -serial stdio
 
+  Installing a Linux distribution in QEMU and building the FILO payload is
+  beyond the scope of this document.
 
+
 Website and Mailing List
 ------------------------
 
@@ -92,10 +145,9 @@
 
 LinuxBIOS is licensed under the terms of the GNU General Public License (GPL).
 Some files are licensed under the "GPL (version 2, or any later version)",
-and some files (mostly those derived from the Linux kernel) are licensed under
-the "GPL, version 2". For some parts, which were derived from other projects,
-other (GPL-compatible) licenses may apply. Please check the individual
-source files for details.
+and some files are licensed under the "GPL, version 2". For some parts,
+which were derived from other Free Software projects, other (GPL-compatible)
+licenses may apply. Please check the individual source files for details.
 
 This makes the resulting LinuxBIOS images licensed under the GPL, version 2.
 

Modified: LinuxBIOSv3/arch/x86/Makefile
===================================================================
--- LinuxBIOSv3/arch/x86/Makefile	2007-06-07 17:34:17 UTC (rev 349)
+++ LinuxBIOSv3/arch/x86/Makefile	2007-06-09 17:43:26 UTC (rev 350)
@@ -36,14 +36,25 @@
 
 ROM_SIZE := $(shell expr $(CONFIG_LINUXBIOS_ROMSIZE_KB) \* 1024)
 
-$(obj)/linuxbios.rom: $(obj)/linuxbios.bootblock $(obj)/util/lar/lar lzma $(obj)/linuxbios.initram $(obj)/linuxbios.stage2 $(obj)/option_table payload
+$(obj)/linuxbios.rom: $(obj)/linuxbios.bootblock $(obj)/util/lar/lar lzma $(obj)/linuxbios.initram $(obj)/linuxbios.stage2 $(obj)/option_table payload_compress
 	$(Q)rm -rf $(obj)/lar.tmp
 	$(Q)mkdir $(obj)/lar.tmp
 	$(Q)mkdir $(obj)/lar.tmp/normal
 	$(Q)cp $(obj)/linuxbios.initram $(obj)/lar.tmp/normal/initram
 	$(Q)cp $(obj)/linuxbios.stage2 $(obj)/lar.tmp/normal/stage2
 	$(Q)cp $(obj)/option_table $(obj)/lar.tmp/normal/option_table
-	$(Q)cp $(CONFIG_PAYLOAD) $(obj)/lar.tmp/normal/payload
+ifeq ($(CONFIG_PAYLOAD_NONE),y)
+	$(Q)printf "  PAYLOAD none (as specified by user)\n"
+else
+	$(Q)# TODO: Print sth. other than $(CONFIG_PAYLOAD_FILE) if compressed.
+	$(Q)if [ -r $(CONFIG_PAYLOAD_FILE) ]; then \
+		printf "  PAYLOAD $(CONFIG_PAYLOAD_FILE)\n"; \
+		cp $(CONFIG_PAYLOAD_FILE) $(obj)/lar.tmp/normal/payload; \
+	else \
+		printf "Error: payload file '$(CONFIG_PAYLOAD_FILE)' not found.\n"; \
+		exit 1; \
+	fi
+endif
 	$(Q)printf "  LAR     $(subst $(shell pwd)/,,$(@))\n"
 	$(Q)cd $(obj)/lar.tmp && ../util/lar/lar -c ../linuxbios.rom . \
 		-s $(ROM_SIZE) -b $(obj)/linuxbios.bootblock
@@ -147,15 +158,17 @@
 
 
 #
-# The payload as we love it. Get it from somewhere.
-# Is this a place to incorporate buildrom?
+# TODO: Compress the payload (CONFIG_PAYLOAD_FILE) with the default compressor.
 #
-# TODO: This is not implemented yet.
-# TODO: This needs to be compressed with the default compressor.
-#
 
-payload:
-	$(Q)printf "  BUILD   PAYLOAD (skipped)\n"
+payload_compress:
+ifeq ($(CONFIG_PAYLOAD_NONE),y)
+else
+ifeq ($(CONFIG_DEFAULT_COMPRESSION_NONE),y)
+else
+	$(Q)printf "  ZIP     $(CONFIG_PAYLOAD_FILE) (skipped)\n"
+endif
+endif
 
 
 #

Modified: LinuxBIOSv3/lib/Makefile
===================================================================
--- LinuxBIOSv3/lib/Makefile	2007-06-07 17:34:17 UTC (rev 349)
+++ LinuxBIOSv3/lib/Makefile	2007-06-09 17:43:26 UTC (rev 350)
@@ -33,7 +33,9 @@
 #
 
 lzma:
+ifeq ($(CONFIG_DEFAULT_COMPRESSION_LZMA),y)
 	$(Q)printf "  BUILD   LZMA (skipped)\n"
+endif
 
 $(obj)/lib/%.o: $(src)/lib/%.c
 	$(Q)mkdir -p $(obj)/lib




From citizenr at gmail.com  Sun Jun 10 06:33:00 2007
From: citizenr at gmail.com (RusH)
Date: Sun, 10 Jun 2007 06:33:00 +0200
Subject: [LinuxBIOS] does reinitializing memory controller destroy all the
	data in ram?
Message-ID: <3df49b7b0706092133s7bb642d8hf951bb9067d5a95f@mail.gmail.com>

Im sorry that Im again posting not exactly on the topic of linuxbios,
but I know that people reading this list have the knowledge  about the
subject that im interested in.

 Does reinitializing memory controler destroy all the data in ram?
Lets say I boot the computer, bios sets up the memory controller, then
runs bootloader, then my code. Now my code (using CAR) once again
reinitializes memory controller (sets up everything just like the
bios, only changes timings), will all the data be in ram after this?
or will it get wiped out/destroyed?

At first I was hoping that Bios initializes memory controller only on
cold boot, but it does it on soft ones too :(, my hope now lies in
attaching a bios module to  reinitialize it after the bios is
executed. I want my code to be able to set all the timings. I can do
it for tRCD tRP tRAS, but almost all controllers dont like tCAS
changes and will simply hang up the computer (KT133 and AMD64 to name
a few).

It would be a lot simplier if linuxbios could just boot XP crap :(

-- 
Who logs in to gdm? Not I, said the duck.



From citizenr at gmail.com  Sun Jun 10 06:40:34 2007
From: citizenr at gmail.com (RusH)
Date: Sun, 10 Jun 2007 06:40:34 +0200
Subject: [LinuxBIOS] does reinitializing memory controller destroy all
	the data in ram?
In-Reply-To: <3df49b7b0706092133s7bb642d8hf951bb9067d5a95f@mail.gmail.com>
References: <3df49b7b0706092133s7bb642d8hf951bb9067d5a95f@mail.gmail.com>
Message-ID: <3df49b7b0706092140u6f322770h41e0efa6e77f6fed@mail.gmail.com>

On 6/10/07, RusH <citizenr at gmail.com> wrote:

> It would be a lot simplier if linuxbios could just boot XP crap :(

umm no it wouldnt, I dont know what I was thinking :)

 Im asking about reinitialization because I want to implement it in
Memtest (memtest.org). I want to be able to setup memory controler the
way I like and continue the test. Memtest is big (>100KB) and Im
affraid it wont fit in cache so i need some real ram. Thats where the
'jump to CAR, reinitialize controller, jump back to ram' idea comes
from. Is it doable?


-- 
Who logs in to gdm? Not I, said the duck.



From bari at onelabs.com  Sun Jun 10 07:46:48 2007
From: bari at onelabs.com (Bari Ari)
Date: Sun, 10 Jun 2007 00:46:48 -0500
Subject: [LinuxBIOS] does reinitializing memory controller destroy all
 the	data in ram?
In-Reply-To: <3df49b7b0706092133s7bb642d8hf951bb9067d5a95f@mail.gmail.com>
References: <3df49b7b0706092133s7bb642d8hf951bb9067d5a95f@mail.gmail.com>
Message-ID: <466B9048.5080704@onelabs.com>

RusH wrote:
>  Does reinitializing memory controler destroy all the data in ram?

Yes.

You might be able to get away with some minor changes to memory 
controller settings, but nothing would be guaranteed by the chipset 
maker to be stable. Chipsets  typically aren't designed to be 
reinitialized while saving the data in RAM at the same time. The data in 
RAM is indeterminate until after the memory controller is fully initialized.

-Bari



From darmawan.salihun at gmail.com  Sun Jun 10 11:45:36 2007
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Sun, 10 Jun 2007 16:45:36 +0700
Subject: [LinuxBIOS] mmap() availability in MinGW
In-Reply-To: <20070520111152.GA12899@coresystems.de>
References: <464D8F16.7070604@gmail.com>
	<20070518140625.GA5856@coresystems.de>	<464D8F16.7070604@gmail.com>
	<20070518144822.19059.qmail@cdy.org>	<464E7864.3090600@gmail.com>
	<20070520011227.22745.qmail@cdy.org>
	<20070520111152.GA12899@coresystems.de>
Message-ID: <466BC840.1010003@gmail.com>

Hi,
   I'd like to ask about the availability of some features in MinGW
because I'm not  proficient enough in MinGW
in the Windows platform (I barely use it for about 6 months 4 years
ago). OK, here's my questions:
1. Is the "platform specific (I'm not sure whether this function is
platfomr specific or not)" mmap() function is available in MinGW?
2. Do you think using MinGW in DevCPP IDE is acceptable/good enough
compared to using it in it's command line incarnation?

More questions to come :-).

Anyway, this questions has a direct impact on the Winflashrom that I'm
currently working on. I'm using MS Visual C++ before, and
I can say that I'm proficient enough with it compared to using MinGW.
Hopefully, there's proficient MinGW user here that can help.

TIA,
Darmawan



From stepan at coresystems.de  Sun Jun 10 13:49:24 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 10 Jun 2007 13:49:24 +0200
Subject: [LinuxBIOS] mmap() availability in MinGW
In-Reply-To: <466BC840.1010003@gmail.com>
References: <464D8F16.7070604@gmail.com> <20070518140625.GA5856@coresystems.de>
	<464D8F16.7070604@gmail.com> <20070518144822.19059.qmail@cdy.org>
	<464E7864.3090600@gmail.com> <20070520011227.22745.qmail@cdy.org>
	<20070520111152.GA12899@coresystems.de>
	<466BC840.1010003@gmail.com>
Message-ID: <20070610114924.GA25232@coresystems.de>

* Darmawan Salihun <darmawan.salihun at gmail.com> [070610 11:45]:
> Hi,
> 1. Is the "platform specific (I'm not sure whether this function is
> platfomr specific or not)" mmap() function is available in MinGW?

Good question...
There is some code in cygwin that emulates it:
http://www.koders.com/cpp/fid6DDC4FEBF84310315F4303C64C86EAAEAC1945B0.aspx

> 2. Do you think using MinGW in DevCPP IDE is acceptable/good enough
> compared to using it in it's command line incarnation?
 
What's the DevCPP IDE? ;-)

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Sun Jun 10 14:43:36 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 10 Jun 2007 14:43:36 +0200
Subject: [LinuxBIOS] mmap() availability in MinGW
In-Reply-To: <20070610114924.GA25232@coresystems.de>
References: <464D8F16.7070604@gmail.com> <20070518140625.GA5856@coresystems.de>
	<464D8F16.7070604@gmail.com> <20070518144822.19059.qmail@cdy.org>
	<464E7864.3090600@gmail.com> <20070520011227.22745.qmail@cdy.org>
	<20070520111152.GA12899@coresystems.de>
	<466BC840.1010003@gmail.com>
	<20070610114924.GA25232@coresystems.de>
Message-ID: <20070610124336.GA30509@coresystems.de>

* Stefan Reinauer <stepan at coresystems.de> [070610 13:49]:
> * Darmawan Salihun <darmawan.salihun at gmail.com> [070610 11:45]:
> > Hi,
> > 1. Is the "platform specific (I'm not sure whether this function is
> > platfomr specific or not)" mmap() function is available in MinGW?
 
You could try to use the AWE API (Address Window Extenstion):
http://msdn2.microsoft.com/en-us/library/ms810461.aspx
http://msdn2.microsoft.com/en-us/library/aa366531.aspx
 
Several projects have mmap implementations:

libgw32c has one (here from clamav)
http://www.koders.com/c/fidBEF73F4272C501403E37D4C34B2288CD3D37B102.aspx

Microsoft's "SFU" might have one (Services for Unix)
http://www.microsoft.com/downloads/details.aspx?FamilyID=896C9688-601B-44F1-81A4-02878FF11778&displaylang=en

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From c-d.hailfinger.devel.2006 at gmx.net  Sun Jun 10 23:14:17 2007
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 10 Jun 2007 23:14:17 +0200
Subject: [LinuxBIOS] does reinitializing memory controller destroy all
 the data in ram?
In-Reply-To: <3df49b7b0706092140u6f322770h41e0efa6e77f6fed@mail.gmail.com>
References: <3df49b7b0706092133s7bb642d8hf951bb9067d5a95f@mail.gmail.com>
	<3df49b7b0706092140u6f322770h41e0efa6e77f6fed@mail.gmail.com>
Message-ID: <466C69A9.6040308@gmx.net>

On 10.06.2007 06:40, RusH wrote:
> 
>  Im asking about reinitialization because I want to implement it in
> Memtest (memtest.org). I want to be able to setup memory controler the
> way I like and continue the test. Memtest is big (>100KB) and Im
> affraid it wont fit in cache so i need some real ram. Thats where the
> 'jump to CAR, reinitialize controller, jump back to ram' idea comes
> from. Is it doable?

Why not run Memtest from graphics card RAM? A few years ago, graphics
card RAM was really low quality, so periodic checksumming of any
software running there might be necessary.

> Does reinitializing memory controler destroy all the data in ram?

Depends. Some embedded systems (like the OLPC laptop) put memory
into self-refresh for suspend-to-RAM and reinitialize the memory
controller on resume without losing any contents. However, I
wouldn't count on that for any recent non-embedded x86 system.

Regards,
Carl-Daniel



From stuge-linuxbios at cdy.org  Mon Jun 11 01:16:58 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 11 Jun 2007 01:16:58 +0200
Subject: [LinuxBIOS] mmap() availability in MinGW
In-Reply-To: <466BC840.1010003@gmail.com>
References: <464D8F16.7070604@gmail.com> <20070518140625.GA5856@coresystems.de>
	<464D8F16.7070604@gmail.com> <20070518144822.19059.qmail@cdy.org>
	<464E7864.3090600@gmail.com> <20070520011227.22745.qmail@cdy.org>
	<20070520111152.GA12899@coresystems.de>
	<466BC840.1010003@gmail.com>
Message-ID: <20070610231658.17959.qmail@cdy.org>

On Sun, Jun 10, 2007 at 04:45:36PM +0700, Darmawan Salihun wrote:
> 1. Is the "platform specific (I'm not sure whether this function is
> platfomr specific or not)" mmap() function is available in MinGW?

MinGW is not really a platform. You may be confusing it with Cygwin.

MinGW is just a native gcc for Win32 and open source header files for
a large part of the Win32 API.


> 2. Do you think using MinGW in DevCPP IDE is acceptable/good enough
> compared to using it in it's command line incarnation?

I think you should use whatever you are most comfortable with.

That said, I see many advantages in having as much code as possible
buildable with MinGW since that means easy cross-compiles and also
dealing with only one compiler.

Finally, I can not imagine that a project will _require_ a particular
IDE to build if it is using MinGW and has some good Makefiles.


> Anyway, this questions has a direct impact on the Winflashrom that
> I'm currently working on. I'm using MS Visual C++ before, and
> I can say that I'm proficient enough with it compared to using
> MinGW. Hopefully, there's proficient MinGW user here that can help.

Again, I often just think of MinGW as just a native Win32 gcc.

The application should be buildable with MinGW without problems and
probably without much special care even if you use an IDE for
development.

The kernel driver may not be as easy to build, depending on what
kind of linker tricks that are required to make kernel drivers.
Also, I'm not sure if the w32api (the open source header project)
includes kernel headers as well.


My advice for getting comfortable with MinGW is to just install it.
It's only a few megabytes.

You may or may not want MSYS as well. If MinGW is the compiler, MSYS
is bash and various other tools and programs that are intended really
to make autoconf configure scripts happy about building using MinGW.

If you install MinGW and MSYS then MSYS does some of the work to set
up environment variables and so on, but it is by no means required
just to run MinGW gcc.

If you want a sample app, look at http://stuge.se/dlg.zip which is
just a really basic dialog example that I've prepared for people who
want to get started creating dialog RC files using a text editor.
(I haven't found any really good RC dialog editor tools.)


//Peter



From citizenr at gmail.com  Mon Jun 11 06:58:53 2007
From: citizenr at gmail.com (RusH)
Date: Mon, 11 Jun 2007 06:58:53 +0200
Subject: [LinuxBIOS] does reinitializing memory controller destroy all
	the data in ram?
In-Reply-To: <466C69A9.6040308@gmx.net>
References: <3df49b7b0706092133s7bb642d8hf951bb9067d5a95f@mail.gmail.com>
	<3df49b7b0706092140u6f322770h41e0efa6e77f6fed@mail.gmail.com>
	<466C69A9.6040308@gmx.net>
Message-ID: <3df49b7b0706102158l1c6fe02ve5c0e384d62649c1@mail.gmail.com>

On 6/10/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> On 10.06.2007 06:40, RusH wrote:
> >
> >  Im asking about reinitialization because I want to implement it in
> > Memtest (memtest.org). I want to be able to setup memory controller the
> > way I like and continue the test. Memtest is big (>100KB) and Im
> > afraid it wont fit in cache so i need some real ram. That's where the
> > 'jump to CAR, reinitialize controller, jump back to ram' idea comes
> > from. Is it doable?
>
> Why not run Memtest from graphics card RAM? A few years ago, graphics
> card RAM was really low quality, so periodic checksumming of any
> software running there might be necessary.

Date: Wed, 30 May 2007 18:57:44 +0200
From: RusH <citizenr at gmail.com>
To: linuxbios at linuxbios.org
Subject: using Graphics card ram as actual ram?
Message-ID: <3df49b7b0705300957l3d063c50p404ed2cb07b8bd9 at mail.gmail.com>

so yes, i was thinking about it :)

> > Does reinitializing memory controller er destroy all the data in ram?
>
> Depends. Some embedded systems (like the OLPC laptop) put memory
> into self-refresh for suspend-to-RAM and reinitialize the memory
> controller on resume without losing any contents. However, I
> wouldn't count on that for any recent non-embedded x86 system.

What about AMD64 controller? I know I can change a lot of timings on
it, but changing tCAS is not possible without reinitializing, that's
why I want to be able to reinitialize on the fly.

I read somewhere that reinitializing (memory allready set up earlier)
without touching the mappings would be ok, but I want to be sure
before starting coding (easier to ask than sit on it a good week and
wonder why it doesnt work).

I guess I'll have to check for myself. All I got now is two boards
with KT133 chipset, and that doesnt look to be supported (but
PLE133/CLE266 are similar, so maybe that code will do).

-- 
Who logs in to gdm? Not I, said the duck.



From darmawan.salihun at gmail.com  Mon Jun 11 11:34:38 2007
From: darmawan.salihun at gmail.com (Darmawan Salihun)
Date: Mon, 11 Jun 2007 16:34:38 +0700
Subject: [LinuxBIOS] mmap() availability in MinGW
In-Reply-To: <20070610114924.GA25232@coresystems.de>
References: <20070518140625.GA5856@coresystems.de> <464D8F16.7070604@gmail.com>
	<20070518144822.19059.qmail@cdy.org> <464E7864.3090600@gmail.com>
	<20070520011227.22745.qmail@cdy.org>
	<20070520111152.GA12899@coresystems.de> <466BC840.1010003@gmail.com>
	<20070610114924.GA25232@coresystems.de>
Message-ID: <46893e740706110234hf00ee05y7809376135c667ef@mail.gmail.com>

On 6/10/07, Stefan Reinauer <stepan at coresystems.de> wrote:
...

> > 2. Do you think using MinGW in DevCPP IDE is acceptable/good enough
> > compared to using it in it's command line incarnation?
>
> What's the DevCPP IDE? ;-)
>
>
DevCPP is an Integrated Development Environment for MinGW in Windows. Yeah,
more like the GUI for Visual C++
(Visual C++ can be invoked from command line as well; with its
cl.execompiler commands ;).

-- Darmawan Salihun a.k.a Pinczakko
--------------------------------------------------------------------
-= Human knowledge belongs to the world =-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070611/56a40942/attachment.html>

From jerj at coplanar.net  Mon Jun 11 16:58:55 2007
From: jerj at coplanar.net (Jeremy Jackson)
Date: Mon, 11 Jun 2007 10:58:55 -0400
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <20070606160003.22896.qmail@cdy.org>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com>  <20070606160003.22896.qmail@cdy.org>
Message-ID: <1181573935.6811.18.camel@ragnarok>

I've thought about this a fair bit, going way back a year or more ago,
to when I started porting the DevBIOS project to Linux MTD framework.

Overall I disagree with flashrom being in userspace.  

There is the issue of mapping PCI roms to free areas, locking (can you
use the EEPROM socket on a NIC while it's receiving a frame?).

I have an idea of how the #2 layer would go, with the hardware access
done in the kernel.  My first guess is that the library of flash parts
would be in the kernel (yuck), or at least the current chip's parameters
could be loaded into the kernel driver with an IOCTL which stops kernel
bloat and eases updates for new flash parts.  This would let whole
chip/sector erase, sector program of varying sector sizes, and any other
chip specific functions be supported safely.

A simple whole-chip programming could be done with 

  # cat bios.rom > /dev/bios 

style command, while the flashrom2 userspace tool could read the current
chip's sector sizes, and selectively program with simple read()/write()
calls.

With the hardware access moved into the kernel, the userspace tool(s)
could focus on partial updates of code (boot block vs fallback vs normal
images), userspace initramfs, kernels (on 2MB flash parts).

One thing that should really drive this home, is that using this
architecture on Linux *and* Windows, the same userspace tool could be
used on both, so the fancy code for incremental updates, writing
parameter blocks, etc.,  wouldn't have to be duplicated.

Isn't MTD framework capable of handling most of this already?

Regards,

Jeremy

On Wed, 2007-06-06 at 18:00 +0200, Peter Stuge wrote:
> On Wed, Jun 06, 2007 at 10:47:59PM +0700, Darmawan Salihun wrote:
> > I know, it's not a good example of software engineering practice.
> > Nonetheless, I want to discuss, on which API that I should be
> > removing from user mode application accesses and which one to
> > retain.
> 
> I couldn't make out much of it.
> 
> Again, I think the evolution goes like this:
> 
> 1. Kernel driver allowing unrestricted reads and writes to top 16MB.
> 
> 2. Kernel driver implementing the lowest level flash chip API.
>  Possibly using some macro language so that reboot isn't neccessary
>  to upgrade flash support.
> 
> API details can't really be that complicated until (2) but I don't
> think we can get away from doing (1) first so no need to worry about
> (2) yet.






From jerj at coplanar.net  Mon Jun 11 17:17:40 2007
From: jerj at coplanar.net (Jeremy Jackson)
Date: Mon, 11 Jun 2007 11:17:40 -0400
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <20070606160003.22896.qmail@cdy.org>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com>  <20070606160003.22896.qmail@cdy.org>
Message-ID: <1181575060.6811.26.camel@ragnarok>

A 16MB top window seems to be a generic window, most APIC/IOAPIC are
mapped at 4GB - 20MB IIRC

My dream is to have a chip specific driver (map driver in MTD terms)
which knows the window size the BIOS hardware decoder supports,
including the optional enable bits.

The chip driver also interacts with Linux /dev/iomem to reflect the
current setting of the optional enables.

It should also update the below 1MB (and maybe below 16MB) aliases
in /proc/iomem, according to their actual status in the hardware.  For
example, the K8 northbridge fixed MTRRs could be disabled, rendering any
aliasing of the southbridge or LPC/FWH parts moot (from the processor's
perspective at least)

There is a similar (lack of) infrastructure issue with lmsensors ATM,
might be interesting to watch progress there

Regards,

Jeremy

On Wed, 2007-06-06 at 18:00 +0200, Peter Stuge wrote:
> On Wed, Jun 06, 2007 at 10:47:59PM +0700, Darmawan Salihun wrote:
> > I know, it's not a good example of software engineering practice.
> > Nonetheless, I want to discuss, on which API that I should be
> > removing from user mode application accesses and which one to
> > retain.
> 
> I couldn't make out much of it.
> 
> Again, I think the evolution goes like this:
> 
> 1. Kernel driver allowing unrestricted reads and writes to top 16MB.





From stepan at coresystems.de  Mon Jun 11 18:17:38 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 11 Jun 2007 18:17:38 +0200
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <1181573935.6811.18.camel@ragnarok>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<1181573935.6811.18.camel@ragnarok>
Message-ID: <20070611161737.GA28077@coresystems.de>

Oh I love playing advocatus diaboli ;-)

* Jeremy Jackson <jerj at coplanar.net> [070611 16:58]:
> Overall I disagree with flashrom being in userspace.  
 
I have mixed feelings about the approach.  As a hardware driver, it
strictly belongs to the kernel. Oh, wait, in modern systems hardware
drivers strictly belong into userspace, but Linux is not one of them.

At some point more than 50% of my effort went into keeping up with minor
and major interface changes in the driver and while I thought I was
maintaining it well, it suffered from bitrot and features like pci card
flashing broke away since things in the kernel changed.

> There is the issue of mapping PCI roms to free areas, locking (can you
> use the EEPROM socket on a NIC while it's receiving a frame?).

This depends very well on the card. The PCI standard forbids this
anyways. Either the ROM or MEM/IO must be enabled, not both at the same
time.
Nonetheless, you can make sure it does not happen by unloading the
network card module.

> bloat and eases updates for new flash parts.  This would let whole
> chip/sector erase, sector program of varying sector sizes, and any other
> chip specific functions be supported safely.
 
One rule of thumb you have to follow is: Do not run flashrom on an
otherwise loaded machine. Then the timing is uncritical.

> A simple whole-chip programming could be done with 
> 
>   # cat bios.rom > /dev/bios

cat for example always uses 4k blocks, which might lead to early
destruction of the chip. dd bs=512k ... is much better.
 
> With the hardware access moved into the kernel, the userspace tool(s)
> could focus on partial updates of code (boot block vs fallback vs normal
> images), userspace initramfs, kernels (on 2MB flash parts).
 
At what gain? And at what loss?

If you want to block other hw completely like /dev/bios did, you can
just do cli/sti in a userspace program as well. That keeps timing issues
away.

I agree flashrom should set itself to running with realtime policy
enabled. 

> One thing that should really drive this home, is that using this
> architecture on Linux *and* Windows, the same userspace tool could be
> used on both, so the fancy code for incremental updates, writing
> parameter blocks, etc.,  wouldn't have to be duplicated.

It should not be duplicated anyways. The Windows driver currently only
takes care of mapping memory into user space if I remember correctly.

> Isn't MTD framework capable of handling most of this already?

Yes, it is. And it is incredibly complicated and complex for such a
simple task. ie. it can be done, but MTD is designed for larger flash
parts with filesystems on them. For BIOS chips it is a bit of a PITA.

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Mon Jun 11 18:23:02 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 11 Jun 2007 18:23:02 +0200
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <1181575060.6811.26.camel@ragnarok>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<1181575060.6811.26.camel@ragnarok>
Message-ID: <20070611162302.GA15682@coresystems.de>

* Jeremy Jackson <jerj at coplanar.net> [070611 17:17]:
> My dream is to have a chip specific driver (map driver in MTD terms)
> which knows the window size the BIOS hardware decoder supports,
> including the optional enable bits.

One kernel driver per supported chipset? Ouch. That does not make things
easy at all.

> The chip driver also interacts with Linux /dev/iomem to reflect the
> current setting of the optional enables.
 
In the kernel you don't have to use /dev/iomem, you can just inb/outb
directly (which is what /dev/iomem does)

> It should also update the below 1MB (and maybe below 16MB) aliases
> in /proc/iomem, according to their actual status in the hardware.  For
> example, the K8 northbridge fixed MTRRs could be disabled, rendering any
> aliasing of the southbridge or LPC/FWH parts moot (from the processor's
> perspective at least)

How is this thing done today? Is it part of the e820 table? Or does
Linux hardcode that area?

Stefan


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866



From jerj at coplanar.net  Mon Jun 11 19:18:46 2007
From: jerj at coplanar.net (Jeremy Jackson)
Date: Mon, 11 Jun 2007 13:18:46 -0400
Subject: [LinuxBIOS] Another inexpensive DIY flash programmer
Message-ID: <1181582326.6811.29.camel@ragnarok>

Hi,

Found this while googling:

http://www.loet.de/flasher_en.html

It uses an IDE port, very inexpensive and simple.

Cheers,

Jeremy




From jerj at coplanar.net  Mon Jun 11 19:27:17 2007
From: jerj at coplanar.net (Jeremy Jackson)
Date: Mon, 11 Jun 2007 13:27:17 -0400
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <20070611162302.GA15682@coresystems.de>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<1181575060.6811.26.camel@ragnarok>
	<20070611162302.GA15682@coresystems.de>
Message-ID: <1181582837.6811.37.camel@ragnarok>

Presently at least for amd64 (the early init stuff is copied from i386
so it's probably the same), Linux kernel hard codes the below 1M bios
area.  I'm looking for a way to pass that info to the kernel (from
linuxbios table?) similar to e820, so that can be used as RAM. (keyword:
legacy removal)

I'm curious to know what depends on the below 1MB alias, and could they
be adjusted to use the high BIOS area.  Is the low 1MB alias where the
standards put $PIR and other tables read from the BIOS by the OS?

Jeremy

> > It should also update the below 1MB (and maybe below 16MB) aliases
> > in /proc/iomem, according to their actual status in the hardware.  For
> > example, the K8 northbridge fixed MTRRs could be disabled, rendering any
> > aliasing of the southbridge or LPC/FWH parts moot (from the processor's
> > perspective at least)
> 
> How is this thing done today? Is it part of the e820 table? Or does
> Linux hardcode that area?
> 
> Stefan
> 
> 




From jerj at coplanar.net  Mon Jun 11 19:31:12 2007
From: jerj at coplanar.net (Jeremy Jackson)
Date: Mon, 11 Jun 2007 13:31:12 -0400
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <20070611162302.GA15682@coresystems.de>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<1181575060.6811.26.camel@ragnarok>
	<20070611162302.GA15682@coresystems.de>
Message-ID: <1181583072.6811.41.camel@ragnarok>

On Mon, 2007-06-11 at 18:23 +0200, Stefan Reinauer wrote:
> * Jeremy Jackson <jerj at coplanar.net> [070611 17:17]:
> > My dream is to have a chip specific driver (map driver in MTD terms)
> > which knows the window size the BIOS hardware decoder supports,
> > including the optional enable bits.
> 
> One kernel driver per supported chipset? Ouch. That does not make things
> easy at all.

Well flashrom has numerous per-chipset and per-motherboard drivers for
the write-enable, the quantity of those would remain the same for an
in-kernel driver.  The benefit would be that the drivers would tell the
kernel (/proc/iomem /proc/ioports) what is going on.  Consider also that
there are per-chipset drivers in Linux for EDAC that flash rom functions
could be merged into.

There is always the option of the generic 4G - 16MB window for
not-yet-written drivers.
> 
>
> Stefan
> 
> 




From jerj at coplanar.net  Mon Jun 11 19:36:09 2007
From: jerj at coplanar.net (Jeremy Jackson)
Date: Mon, 11 Jun 2007 13:36:09 -0400
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <20070611161737.GA28077@coresystems.de>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<1181573935.6811.18.camel@ragnarok>
	<20070611161737.GA28077@coresystems.de>
Message-ID: <1181583369.6811.46.camel@ragnarok>

On Mon, 2007-06-11 at 18:17 +0200, Stefan Reinauer wrote:

> > There is the issue of mapping PCI roms to free areas, locking (can you
> > use the EEPROM socket on a NIC while it's receiving a frame?).
> 
> This depends very well on the card. The PCI standard forbids this
> anyways. Either the ROM or MEM/IO must be enabled, not both at the same
> time.
> Nonetheless, you can make sure it does not happen by unloading the
> network card module.

Well unloading the driver seems a bit clumsy, and a contradiction
really.  (unloading a driver to use hardware).  I would add the flash
ROM functionality to the NIC driver, and have it export an MTD map.  The
space.c stub implementation would just return EBUSY if the interface is
up, but specific drivers could enable interleaved access as they are
able.

Regards,

Jeremy




From stuge-linuxbios at cdy.org  Mon Jun 11 19:36:42 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Mon, 11 Jun 2007 19:36:42 +0200
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <1181582837.6811.37.camel@ragnarok>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<1181575060.6811.26.camel@ragnarok>
	<20070611162302.GA15682@coresystems.de>
	<1181582837.6811.37.camel@ragnarok>
Message-ID: <20070611173642.11952.qmail@cdy.org>

On Mon, Jun 11, 2007 at 01:27:17PM -0400, Jeremy Jackson wrote:
> I'm curious to know what depends on the below 1MB alias,

DMA IIRC.


//Peter



From jerj at coplanar.net  Mon Jun 11 19:38:07 2007
From: jerj at coplanar.net (Jeremy Jackson)
Date: Mon, 11 Jun 2007 13:38:07 -0400
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <20070611162302.GA15682@coresystems.de>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<1181575060.6811.26.camel@ragnarok>
	<20070611162302.GA15682@coresystems.de>
Message-ID: <1181583487.6811.48.camel@ragnarok>

On Mon, 2007-06-11 at 18:23 +0200, Stefan Reinauer wrote:

> 
> > The chip driver also interacts with Linux /dev/iomem to reflect the
> > current setting of the optional enables.

I meant to say /proc/iomem here, how about a do-over?
>  
> In the kernel you don't have to use /dev/iomem, you can just inb/outb
> directly (which is what /dev/iomem does)
> 
> > It should also update the below 1MB (and maybe below 16MB) aliases
> > in /proc/iomem, according to their actual status in the hardware.  For
> > example, the K8 northbridge fixed MTRRs could be disabled, rendering any
> > aliasing of the southbridge or LPC/FWH parts moot (from the processor's
> > perspective at least)
> 
> How is this thing done today? Is it part of the e820 table? Or does
> Linux hardcode that area?
> 
> Stefan
> 
> 




From stepan at coresystems.de  Mon Jun 11 20:24:35 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 11 Jun 2007 20:24:35 +0200
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <1181583369.6811.46.camel@ragnarok>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<1181573935.6811.18.camel@ragnarok>
	<20070611161737.GA28077@coresystems.de>
	<1181583369.6811.46.camel@ragnarok>
Message-ID: <20070611182435.GA15647@coresystems.de>

* Jeremy Jackson <jerj at coplanar.net> [070611 19:36]:
> > Nonetheless, you can make sure it does not happen by unloading the
> > network card module.
> 
> Well unloading the driver seems a bit clumsy, and a contradiction
> really.  (unloading a driver to use hardware).  I would add the flash
> ROM functionality to the NIC driver, and have it export an MTD map.  The
> space.c stub implementation would just return EBUSY if the interface is
> up, but specific drivers could enable interleaved access as they are
> able.

Still, it has to disable all it's memory and io resources before the rom
resource can be used reliably. This is equal to unloading the module, no
matter whether you really unload or not.

Adding this to the NIC driver sounds like an interesting approach.

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Mon Jun 11 20:26:35 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 11 Jun 2007 20:26:35 +0200
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <1181582837.6811.37.camel@ragnarok>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<1181575060.6811.26.camel@ragnarok>
	<20070611162302.GA15682@coresystems.de>
	<1181582837.6811.37.camel@ragnarok>
Message-ID: <20070611182635.GB15647@coresystems.de>

* Jeremy Jackson <jerj at coplanar.net> [070611 19:27]:
> area.  I'm looking for a way to pass that info to the kernel (from
> linuxbios table?) similar to e820, so that can be used as RAM. (keyword:
> legacy removal)

GOOOD idea!

> I'm curious to know what depends on the below 1MB alias, and could they
> be adjusted to use the high BIOS area.  Is the low 1MB alias where the
> standards put $PIR and other tables read from the BIOS by the OS?

PIR and co can be anywhere in the low ram too I think. 

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From stepan at coresystems.de  Mon Jun 11 20:27:30 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 11 Jun 2007 20:27:30 +0200
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current
	device	driver (testbed)
In-Reply-To: <20070611173642.11952.qmail@cdy.org>
References: <4666B03B.2060500@gmail.com> <4666B0F6.1060003@gmail.com>
	<20070606130945.GA8454@countzero.vandewege.net>
	<4666D72F.1080201@gmail.com> <20070606160003.22896.qmail@cdy.org>
	<1181575060.6811.26.camel@ragnarok>
	<20070611162302.GA15682@coresystems.de>
	<1181582837.6811.37.camel@ragnarok>
	<20070611173642.11952.qmail@cdy.org>
Message-ID: <20070611182730.GC15647@coresystems.de>

* Peter Stuge <stuge-linuxbios at cdy.org> [070611 19:36]:
> On Mon, Jun 11, 2007 at 01:27:17PM -0400, Jeremy Jackson wrote:
> > I'm curious to know what depends on the below 1MB alias,
> 
> DMA IIRC.

Is ISA DMA still being used?

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From patrick at georgi-clan.de  Mon Jun 11 20:01:36 2007
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 11 Jun 2007 20:01:36 +0200
Subject: [LinuxBIOS] RFC Winflashrom Architecture -- Current device
	driver (testbed)
In-Reply-To: <1181583369.6811.46.camel@ragnarok>
References: <4666B03B.2060500@gmail.com>
	<4666B0F6.1060003@gmail.com>	<20070606130945.GA8454@countzero.vandewege.net>	<4666D72F.1080201@gmail.com>
	<20070606160003.22896.qmail@cdy.org>	<1181573935.6811.18.camel@ragnarok>	<20070611161737.GA28077@coresystems.de>
	<1181583369.6811.46.camel@ragnarok>
Message-ID: <f4k2m1$hjq$1@sea.gmane.org>

Jeremy Jackson schrieb:
> Well unloading the driver seems a bit clumsy, and a contradiction
> really.  (unloading a driver to use hardware).  I would add the flash
> ROM functionality to the NIC driver, and have it export an MTD map.  The
> space.c stub implementation would just return EBUSY if the interface is
> up, but specific drivers could enable interleaved access as they are
> able.
so who puts exactly the same chunk of code in all the 50-or-so network 
drivers (not to speak of all the other devices that might be flashable) 
and maintains it?

 From a maintenance perspective, this proposal is a nightmare - in this 
case, just unloading the driver is preferred imho.
Hmm.. I'm not sure how the suspend stuff works on linux, but maybe you 
could fake a suspend signal to the driver from your driver, so it 
detaches properly (and can attach again once you're done)?


Regards,
Patrick Georgi




From thomas.ekstrand at gmail.com  Mon Jun 11 23:05:18 2007
From: thomas.ekstrand at gmail.com (Thomas Ekstrand)
Date: Mon, 11 Jun 2007 23:05:18 +0200
Subject: [LinuxBIOS] EPIA hang after patch
Message-ID: <f7085c470706111405k65b925ddi872fabc3648e230a@mail.gmail.com>

Hi!

I checked out r2717 and at first it behaved like Markus Boas Epia V
but then I applied Ben's patch to the vt8231_early_serial.c and it
booted into filo, once, then hanged at the dram setup. then I applied
the vt8231_lpc.c patch and it hangs on this:

LinuxBIOS-2.0.0.0Normal Mon Jun 11 22:28:57 CEST 2007 starting...
87 is the comm register
SMBus controller enabled
vt8601 init starting
00000000 is the north
                     1106 0601
0120d4 is the computed timing
                             NOP
PRECHARGE
DUMMY READS
CBR
MRS
NORMAL
set ref. rate
enable multi-page open
Slot 00 is SDRAM 10000000 bytes
000e is the MA type
Slot 01 is SDRAM 08000000 bytes x2
000c is the MA type
Slot 02 is empty
Slot 03 is empty
vt8601 done
Copying LinuxBIOS to RAM.
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0.0Normal Mon Jun 11 22:28:57 CEST 2007 booting...
Enumerating buses...
scan_static_bus for Root Device
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI_DOMAIN: 0000 scanning...
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [1106/0601] ops
PCI: 00:00.0 [1106/0601] enabled
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
malloc Enter, size 668, free_mem_ptr 0001829c
malloc 0x0001829c
PCI: 00:14.0 [1106/3065] ops
PCI: 00:14.0 [1106/3065] enabled
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
do_pci_scan_bridge for PCI: 00:01.0
PCI: pci_scan_bus for bus 01
PCI: devfn 0x0, bad id 0xffffffff
PCI: devfn 0x8, bad id 0xffffffff
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: devfn 0x88, bad id 0xffffffff
PCI: devfn 0x90, bad id 0xffffffff
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: pci_scan_bus returning with max=001
do_pci_scan_bridge returns max 1
scan_static_bus for PCI: 00:11.0
malloc Enter, size 668, free_mem_ptr 00018538
malloc 0x00018538
malloc Enter, size 668, free_mem_ptr 000187d4
malloc 0x000187d4
malloc Enter, size 668, free_mem_ptr 00018a70
malloc 0x00018a70
malloc Enter, size 668, free_mem_ptr 00018d0c
malloc 0x00018d0c
malloc Enter, size 668, free_mem_ptr 00018fa8
malloc 0x00018fa8
malloc Enter, size 668, free_mem_ptr 00019244
malloc 0x00019244
malloc Enter, size 668, free_mem_ptr 000194e0
malloc 0x000194e0
malloc Enter, size 668, free_mem_ptr 0001977c
malloc 0x0001977c
malloc Enter, size 668, free_mem_ptr 00019a18
malloc 0x00019a18
malloc Enter, size 668, free_mem_ptr 00019cb4
malloc 0x00019cb4
malloc Enter, size 668, free_mem_ptr 00019f50
malloc 0x00019f50
PNP: 002e.0 disabled
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
PNP: 607a.0 enabled
PNP: 607a.1 enabled
PNP: 607a.2 enabled
PNP: 607a.3 enabled
PNP: 607a.5 enabled
PNP: 607a.6 enabled
PNP: 607a.7 enabled
PNP: 607a.8 enabled
PNP: 607a.9 enabled
PNP: 607a.a enabled
PNP: 607a.b enabled
scan_static_bus for PCI: 00:11.0 done
PCI: pci_scan_bus returning with max=001
Unexpected Exception: 6 @ 10:e2c3f00a - Halting
Code: 0 eflags: 00010093
eax: ffffff00 ebx: 00000000 ecx: 000003f8 edx: 00017eec
edi: 00000000 esi: 00000000 ebp: 00000000 esp: 00010004


Any ideas would be great!

Thanks!
/Thomas



From btrotter at gmail.com  Tue Jun 12 06:23:40 2007
From: btrotter at gmail.com (Brendan Trotter)
Date: Tue, 12 Jun 2007 04:23:40 +0000
Subject: [LinuxBIOS] Specifications?
Message-ID: <b1ebdcad0706112123w5372b7ecv6f76a913dc0b64e4@mail.gmail.com>

Hi,

I'm wondering if there's a specification describing the state of the
computer at the hand-off between LinuxBIOS and a payload.

So far I've got LinxBIOS booting a dummy "for(;;)" payload in Bochs,
and I've found out there's a "LinuxBIOS Table" and that it can be
found by searching for "LBIO" in the first 4 KB of RAM and in the area
between 0xF000 and 0xFFFFF. I don't know if there's a checksum or any
other validation, and have been unable to find anything describing
what this table contains.

I assume there may also be ACPI, MP specification, PIRQ routing and/or
(possibly) SMI/DMI tables, and I'm guessing that (if present) these
tables can be searched for using the same methods as described in
their corresponding specifications.

There's also other issues, for e.g:
- will an 80x86 system always be in 32-bit protected mode for 32-bit
ELF payloads, and is long mode possible for ELF64 payloads (and if so,
how is paging setup)?
- are any parameters passed on the stack to the payload's entry function?
- are AP CPUs started (or waiting for a SIPI sequence)?
- can the payload assume anything about the state of the PIC, I/O
APIC/s and local APIC/s, PIT, RTC, ISA DMA controllers, serial ports,
etc?
- what state are PCI buses and devices left in (would a payload need
to do full PCI bus enumeration, or..)?
- is there anything in the LinuxBIOS table that could be used to
determine if the computer is "headless" and which serial port or other
device to use if it is?
- can anything be assumed about AGP and the first video card (if the
computer isn't headless)?
- is there any form of "LinuxBIOS API" that can be used by the payload
for generic low level disk access (floppy/ATA/ATAPI/SCSI)?


Thanks,

Brendan



From xiongyi04 at gmail.com  Tue Jun 12 21:45:10 2007
From: xiongyi04 at gmail.com (xiongyi)
Date: Tue, 12 Jun 2007 12:45:10 -0700
Subject: [LinuxBIOS] Specifications?
In-Reply-To: <b1ebdcad0706112123w5372b7ecv6f76a913dc0b64e4@mail.gmail.com>
Message-ID: <466e2495.3371d49a.3c60.fffff869@mx.google.com>


I am also figuring out about the hand-off between LB and the payload these
days. Till now, I haven't found any specification about this issue. But I
think the source code files explain it clearly. 

For example, the "struct lb_memory *write_tables(void)" in the file of
/src/arch/i386/boot/tables.c can answer some issues you mentioned.


There's some doxygen documentation of LinuxBIOS here:

http://qa.linuxbios.org/docs/doxygen/. It is sometimes useful to follow the
code flow more easily.

I also care much about this subject you submitted.

-----????-----
???: linuxbios-bounces at linuxbios.org [mailto:linuxbios-bounces at linuxbios.
org] ?? Brendan Trotter
????: 2007?6?11? 21:24
???: linuxbios at linuxbios.org
??: [LinuxBIOS] Specifications?

Hi,

I'm wondering if there's a specification describing the state of the
computer at the hand-off between LinuxBIOS and a payload.

So far I've got LinxBIOS booting a dummy "for(;;)" payload in Bochs,
and I've found out there's a "LinuxBIOS Table" and that it can be
found by searching for "LBIO" in the first 4 KB of RAM and in the area
between 0xF000 and 0xFFFFF. I don't know if there's a checksum or any
other validation, and have been unable to find anything describing
what this table contains.

I assume there may also be ACPI, MP specification, PIRQ routing and/or
(possibly) SMI/DMI tables, and I'm guessing that (if present) these
tables can be searched for using the same methods as described in
their corresponding specifications.

There's also other issues, for e.g:
- will an 80x86 system always be in 32-bit protected mode for 32-bit
ELF payloads, and is long mode possible for ELF64 payloads (and if so,
how is paging setup)?
- are any parameters passed on the stack to the payload's entry function?
- are AP CPUs started (or waiting for a SIPI sequence)?
- can the payload assume anything about the state of the PIC, I/O
APIC/s and local APIC/s, PIT, RTC, ISA DMA controllers, serial ports,
etc?
- what state are PCI buses and devices left in (would a payload need
to do full PCI bus enumeration, or..)?
- is there anything in the LinuxBIOS table that could be used to
determine if the computer is "headless" and which serial port or other
device to use if it is?
- can anything be assumed about AGP and the first video card (if the
computer isn't headless)?
- is there any form of "LinuxBIOS API" that can be used by the payload
for generic low level disk access (floppy/ATA/ATAPI/SCSI)?


Thanks,

Brendan

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




From stepan at coresystems.de  Tue Jun 12 09:49:10 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 12 Jun 2007 09:49:10 +0200
Subject: [LinuxBIOS] Specifications?
In-Reply-To: <b1ebdcad0706112123w5372b7ecv6f76a913dc0b64e4@mail.gmail.com>
References: <b1ebdcad0706112123w5372b7ecv6f76a913dc0b64e4@mail.gmail.com>
Message-ID: <20070612074909.GA25127@coresystems.de>

* Brendan Trotter <btrotter at gmail.com> [070612 06:23]:
> Hi,
> 
> I'm wondering if there's a specification describing the state of the
> computer at the hand-off between LinuxBIOS and a payload.
> 
> So far I've got LinxBIOS booting a dummy "for(;;)" payload in Bochs,
> and I've found out there's a "LinuxBIOS Table" and that it can be
> found by searching for "LBIO" in the first 4 KB of RAM and in the area
> between 0xF000 and 0xFFFFF. I don't know if there's a checksum or any
> other validation, and have been unable to find anything describing
> what this table contains.

check LinuxBIOSv2/util/lbtdump

> I assume there may also be ACPI, MP specification, PIRQ routing and/or
> (possibly) SMI/DMI tables, and I'm guessing that (if present) these
> tables can be searched for using the same methods as described in
> their corresponding specifications.

They're not used by payloads (except the Linux kernel)

> - will an 80x86 system always be in 32-bit protected mode for 32-bit
> ELF payloads, and is long mode possible for ELF64 payloads (and if so,
> how is paging setup)?

long mode is not yet possible. If you know how to do it and have time,
we'd appreciate any patches though!

> - are any parameters passed on the stack to the payload's entry function?

no

> - are AP CPUs started (or waiting for a SIPI sequence)?

yes, hardware is completely up when linuxbios is done.

> - can the payload assume anything about the state of the PIC, I/O
> APIC/s and local APIC/s, PIT, RTC, ISA DMA controllers, serial ports,
> etc?

yes. they're initialized.

> - what state are PCI buses and devices left in (would a payload need
> to do full PCI bus enumeration, or..)?

They have their resources.

What do you mean by full pci bus enumeration? What would be the
opposite? 

> - is there anything in the LinuxBIOS table that could be used to
> determine if the computer is "headless" and which serial port or other
> device to use if it is?

Not at the moment. But in General this is easy. If no VGA class PCI
device is there, the machine is 99.99% headless.

> - can anything be assumed about AGP and the first video card (if the
> computer isn't headless)?

What would you like to assume?

> - is there any form of "LinuxBIOS API" that can be used by the payload
> for generic low level disk access (floppy/ATA/ATAPI/SCSI)?

No. No Callbacks. That's our intended design.

We don't have functions to access floppy or SCSI in LinuxBIOS anyways
(and in v3 we also dropped ATA)

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From ben at hewson-venieri.co.uk  Tue Jun 12 09:48:47 2007
From: ben at hewson-venieri.co.uk (ben at hewson-venieri.co.uk)
Date: Tue, 12 Jun 2007 09:48:47 +0200
Subject: [LinuxBIOS] EPIA hang after patch
Message-ID: <19634852.109631181634527829.JavaMail.servlet@kundenserver>

Can you try using just 1 memory module to start with and see if that helps.



>Hi!
>
>I checked out r2717 and at first it behaved like Markus Boas Epia V
>but then I applied Ben's patch to the vt8231_early_serial.c and it
>booted into filo, once, then hanged at the dram setup. then I applied
>the vt8231_lpc.c patch and it hangs on this:
>
>LinuxBIOS-2.0.0.0Normal Mon Jun 11 22:28:57 CEST 2007 starting...
>87 is the comm register
>SMBus controller enabled
>vt8601 init starting
>00000000 is the north
>                     1106 0601
>0120d4 is the computed timing
>                             NOP
>PRECHARGE
>DUMMY READS
>CBR
>MRS
>NORMAL
>set ref. rate
>enable multi-page open
>Slot 00 is SDRAM 10000000 bytes
>000e is the MA type
>Slot 01 is SDRAM 08000000 bytes x2
>000c is the MA type
>Slot 02 is empty
>Slot 03 is empty
>vt8601 done
>Copying LinuxBIOS to RAM.
>Jumping to LinuxBIOS.
>LinuxBIOS-2.0.0.0Normal Mon Jun 11 22:28:57 CEST 2007 booting...
>Enumerating buses...
>scan_static_bus for Root Device
>Finding PCI configuration type.
>PCI: Using configuration type 1
>PCI_DOMAIN: 0000 enabled
>APIC_CLUSTER: 0 enabled
>PCI_DOMAIN: 0000 scanning...
>PCI: pci_scan_bus for bus 00
>PCI: 00:00.0 [1106/0601] ops
>PCI: 00:00.0 [1106/0601] enabled
>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
>malloc Enter, size 668, free_mem_ptr 0001829c
>malloc 0x0001829c
>PCI: 00:14.0 [1106/3065] ops
>PCI: 00:14.0 [1106/3065] enabled
>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
>do_pci_scan_bridge for PCI: 00:01.0
>PCI: pci_scan_bus for bus 01
>PCI: devfn 0x0, bad id 0xffffffff
>PCI: devfn 0x8, bad id 0xffffffff
>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: devfn 0x88, bad id 0xffffffff
>PCI: devfn 0x90, bad id 0xffffffff
>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: pci_scan_bus returning with max=001
>do_pci_scan_bridge returns max 1
>scan_static_bus for PCI: 00:11.0
>malloc Enter, size 668, free_mem_ptr 00018538
>malloc 0x00018538
>malloc Enter, size 668, free_mem_ptr 000187d4
>malloc 0x000187d4
>malloc Enter, size 668, free_mem_ptr 00018a70
>malloc 0x00018a70
>malloc Enter, size 668, free_mem_ptr 00018d0c
>malloc 0x00018d0c
>malloc Enter, size 668, free_mem_ptr 00018fa8
>malloc 0x00018fa8
>malloc Enter, size 668, free_mem_ptr 00019244
>malloc 0x00019244
>malloc Enter, size 668, free_mem_ptr 000194e0
>malloc 0x000194e0
>malloc Enter, size 668, free_mem_ptr 0001977c
>malloc 0x0001977c
>malloc Enter, size 668, free_mem_ptr 00019a18
>malloc 0x00019a18
>malloc Enter, size 668, free_mem_ptr 00019cb4
>malloc 0x00019cb4
>malloc Enter, size 668, free_mem_ptr 00019f50
>malloc 0x00019f50
>PNP: 002e.0 disabled
>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
>PNP: 607a.0 enabled
>PNP: 607a.1 enabled
>PNP: 607a.2 enabled
>PNP: 607a.3 enabled
>PNP: 607a.5 enabled
>PNP: 607a.6 enabled
>PNP: 607a.7 enabled
>PNP: 607a.8 enabled
>PNP: 607a.9 enabled
>PNP: 607a.a enabled
>PNP: 607a.b enabled
>scan_static_bus for PCI: 00:11.0 done
>PCI: pci_scan_bus returning with max=001
>Unexpected Exception: 6 @ 10:e2c3f00a - Halting
>Code: 0 eflags: 00010093
>eax: ffffff00 ebx: 00000000 ecx: 000003f8 edx: 00017eec
>edi: 00000000 esi: 00000000 ebp: 00000000 esp: 00010004
>
>
>Any ideas would be great!
>
>Thanks!
>/Thomas
>
>-- 
>linuxbios mailing list
>linuxbios at linuxbios.org
>http://www.linuxbios.org/mailman/listinfo/linuxbios



From thomas.ekstrand at gmail.com  Tue Jun 12 09:55:43 2007
From: thomas.ekstrand at gmail.com (Thomas Ekstrand)
Date: Tue, 12 Jun 2007 09:55:43 +0200
Subject: [LinuxBIOS] compilation error
Message-ID: <f7085c470706120055w43650284m3e1f49147567c105@mail.gmail.com>

Hi!

I've tried to compile linuxbios for the broadcom/blast with only
fallback but i get this error message:

-snip-
1: Error: can't resolve `.L0' {*ABS* section} - `c0000' {*UND* section}
make[1]: *** [crt0.o] Error 1
-snip-

Any ideas?

Thanks!
/Thomas



From stepan at coresystems.de  Tue Jun 12 10:15:37 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 12 Jun 2007 10:15:37 +0200
Subject: [LinuxBIOS] compilation error
In-Reply-To: <f7085c470706120055w43650284m3e1f49147567c105@mail.gmail.com>
References: <f7085c470706120055w43650284m3e1f49147567c105@mail.gmail.com>
Message-ID: <20070612081537.GA1658@coresystems.de>

* Thomas Ekstrand <thomas.ekstrand at gmail.com> [070612 09:55]:
> Hi!
> 
> I've tried to compile linuxbios for the broadcom/blast with only
> fallback but i get this error message:
> 
> -snip-
> 1: Error: can't resolve `.L0' {*ABS* section} - `c0000' {*UND* section}
> make[1]: *** [crt0.o] Error 1
> -snip-

Can you send a little bit more of the log? (last 10 lines or so)

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From thomas.ekstrand at gmail.com  Tue Jun 12 12:06:16 2007
From: thomas.ekstrand at gmail.com (Thomas Ekstrand)
Date: Tue, 12 Jun 2007 12:06:16 +0200
Subject: [LinuxBIOS] compilation error
In-Reply-To: <20070612081537.GA1658@coresystems.de>
References: <f7085c470706120055w43650284m3e1f49147567c105@mail.gmail.com>
	<20070612081537.GA1658@coresystems.de>
Message-ID: <f7085c470706120306o6802b70fo9e2e093bb48b51b3@mail.gmail.com>

2007/6/12, Stefan Reinauer <stepan at coresystems.de>:
> * Thomas Ekstrand <thomas.ekstrand at gmail.com> [070612 09:55]:
> > Hi!
> >
> > I've tried to compile linuxbios for the broadcom/blast with only
> > fallback but i get this error message:
> >
> > -snip-
> > 1: Error: can't resolve `.L0' {*ABS* section} - `c0000' {*UND* section}
> > make[1]: *** [crt0.o] Error 1
> > -snip-
>
> Can you send a little bit more of the log? (last 10 lines or so)
>

-snip-
-I. -I/home/uabgembt/linuxbios/source_code/LinuxBIOSv2-2609/src
crt0.S > crt0.s.new && mv crt0.s.new crt0.sgcc -m32 ... -o crt0.o
crt0.s
/home/uabgembt/linuxbios/source_code/LinuxBIOSv2-2609/src/arch/i386/lib/id.inc:
Assembler messages:
/home/uabgembt/linuxbios/source_code/LinuxBIOSv2-2609/src/arch/i386/lib/id.inc:11:
Error: can't resolve `.L0' {*ABS* section} - `c0000' {*UND* section}
make[1]: *** [crt0.o] Error 1
make[1]: Leaving directory
`/home/uabgembt/linuxbios/source_code/LinuxBIOSv2-2609/targets/broadcom/blast/blast/fallback'
make: *** [fallback/linuxbios.rom] Error 1
uabgembt at fwoscp03:~/linuxbios/source_code/LinuxBIOSv2-2609/targets/broadcom/blast/blast>


/Thomas



From btrotter at gmail.com  Tue Jun 12 12:43:47 2007
From: btrotter at gmail.com (Brendan Trotter)
Date: Tue, 12 Jun 2007 10:43:47 +0000
Subject: [LinuxBIOS] Specifications?
In-Reply-To: <20070612074909.GA25127@coresystems.de>
References: <b1ebdcad0706112123w5372b7ecv6f76a913dc0b64e4@mail.gmail.com>
	<20070612074909.GA25127@coresystems.de>
Message-ID: <b1ebdcad0706120343l7087881h5bd9981efab8e341@mail.gmail.com>

Hi,

On 6/12/07, Stefan Reinauer <stepan at coresystems.de> wrote:
> * Brendan Trotter <btrotter at gmail.com> [070612 06:23]:
> > I'm wondering if there's a specification describing the state of the
> > computer at the hand-off between LinuxBIOS and a payload.
> >
> > So far I've got LinxBIOS booting a dummy "for(;;)" payload in Bochs,
> > and I've found out there's a "LinuxBIOS Table" and that it can be
> > found by searching for "LBIO" in the first 4 KB of RAM and in the area
> > between 0xF000 and 0xFFFFF. I don't know if there's a checksum or any
> > other validation, and have been unable to find anything describing
> > what this table contains.
>
> check LinuxBIOSv2/util/lbtdump

I've found "src/include/boot/linuxbios_tables.h" and have also looked
at the source for LinuxBIOSv2/util/lbtdump.

However, I fail to see how any source code can be considered a viable
alternative to documentation for something that is (hopefully) a
non-proprietory common standard. Reverse engineering (including
relying on assumptions derived from the source code of any specific
implementation) is what people do when they have no documentation and
are willing to stumble around in the dark hoping to implement
something that works until the wind changes.

For a simple example, which piece of source code would tell me if
"lb_mainboard.vendor_idx" is guaranteed to be unique both now and in
the future?

> > I assume there may also be ACPI, MP specification, PIRQ routing and/or
> > (possibly) SMI/DMI tables, and I'm guessing that (if present) these
> > tables can be searched for using the same methods as described in
> > their corresponding specifications.
>
> They're not used by payloads (except the Linux kernel)

Surely LinuxBIOS isn't intended as a "Linux only" BIOS though....

> > - are AP CPUs started (or waiting for a SIPI sequence)?
>
> yes, hardware is completely up when linuxbios is done.

I tried it on a dual CPU Bochs emulation (second CPU was left in "wait
for SIPI" state) - I'm guessing I need to enable multi-CPU support
via. some compile time option for the "emulation/qemu-i386" target?

> > - can the payload assume anything about the state of the PIC, I/O
> > APIC/s and local APIC/s, PIT, RTC, ISA DMA controllers, serial ports,
> > etc?
>
> yes. they're initialized.

:-)

Initialised to which states? For e.g. would the PIT be guaranteed to
be initialised to generate IRQ0 at a certain frequency, and would the
PIC (and/or I/O APIC?) be guaranteed to be initialised to generate
specific interrupt when IRQ0 occurs; or (from the payload's
perspective) are these things left in an undefined state (i.e. the
state they happened to be left in when/if LinuxBIOS used them)?

> > - what state are PCI buses and devices left in (would a payload need
> > to do full PCI bus enumeration, or..)?
>
> They have their resources.
>
> What do you mean by full pci bus enumeration? What would be the
> opposite?

Either:
a) PCI buses and bridges aren't guaranteed to be enumerated, or
b) PCI buses and bridges are guaranteed to be enumerated but PCI
devices aren't guaranteed to be assigned resources, or
c) PCI buses and bridges are guaranteed to be enumerated and PCI
devices are guaranteed to have resources assigned (including ROMs)
d) PCI buses and bridges are guaranteed to be enumerated and PCI
devices are guaranteed to have resources assigned (except ROMs)

"They have their resources." would mean either c) or d), where each
device may or may not be in a power saving state (if supported by the
device), and may or may not be still configured to use MSI (if
supported by the device)....

> > - is there anything in the LinuxBIOS table that could be used to
> > determine if the computer is "headless" and which serial port or other
> > device to use if it is?
>
> Not at the moment. But in General this is easy. If no VGA class PCI
> device is there, the machine is 99.99% headless.

And if a VGA class PCI device is present, you've got no idea if no
monitor is attached...

> > - can anything be assumed about AGP and the first video card (if the
> > computer isn't headless)?
>
> What would you like to assume?

Video card set to default "80 * 25" text mode accessible at 0xB8000;
or some video mode set with display memory directly accessible at some
physical address (where video mode details and physical address
included in LinuxBIOS Table); or AGP aperture configured, AGP transfer
speed set, MTRRs set to "write combining" and some video mode set with
display memory directly accessible at some physical address; or
anything else, as long as a payload writer knows how much or how
little they can assume about it (and hopefully doesn't need to
implement a wide range of video drivers just to do a "Hello World"
that works on all video cards)... ;)


Cheers,

Brendan



From stepan at coresystems.de  Tue Jun 12 13:35:08 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 12 Jun 2007 13:35:08 +0200
Subject: [LinuxBIOS] Specifications
In-Reply-To: <b1ebdcad0706120343l7087881h5bd9981efab8e341@mail.gmail.com>
References: <b1ebdcad0706112123w5372b7ecv6f76a913dc0b64e4@mail.gmail.com>
	<20070612074909.GA25127@coresystems.de>
	<b1ebdcad0706120343l7087881h5bd9981efab8e341@mail.gmail.com>
Message-ID: <20070612113508.GA13122@coresystems.de>

* Brendan Trotter <btrotter at gmail.com> [070612 12:43]:
> > check LinuxBIOSv2/util/lbtdump
> 
>  I've found "src/include/boot/linuxbios_tables.h" and have also looked
>  at the source for LinuxBIOSv2/util/lbtdump.
> 
>  However, I fail to see how any source code can be considered a viable
>  alternative to documentation for something that is (hopefully) a
>  non-proprietory common standard. Reverse engineering (including
>  relying on assumptions derived from the source code of any specific
>  implementation) is what people do when they have no documentation and
>  are willing to stumble around in the dark hoping to implement
>  something that works until the wind changes.
 
Yes, no doubt. You are perfectly right, and we are looking forward to
your patches to fix this problem. Of course you do not have to reverse
engineer, but just read the code, as we are non-proprietary. And of
course we are always here to be asked.

So please, submit any documentation to this list for inclusion as soon
as you wrote it.

>  For a simple example, which piece of source code would tell me if
>  "lb_mainboard.vendor_idx" is guaranteed to be unique both now and in
>  the future?

It is of course not unique. It is the index of the vendor name within
the strings array of struct lb_mainboard. Since we're not trying to
close things down, we don't have to work with magic numbers. So nothing
needs to stay unique.

But I suggest you have a look at the code and document it as you
start understanding it.

> > > I assume there may also be ACPI, MP specification, PIRQ routing and/or
> > > (possibly) SMI/DMI tables, and I'm guessing that (if present) these
> > > tables can be searched for using the same methods as described in
> > > their corresponding specifications.
> >
> > They're not used by payloads (except the Linux kernel)
> 
>  Surely LinuxBIOS isn't intended as a "Linux only" BIOS though....
 
Of course not. ACPI is not really useful for payloads though, unless the
payload wants to carry a full blown ACPI interpreter. Which rules out
basically anything but an OS.

> > > - are AP CPUs started (or waiting for a SIPI sequence)?
> >
> > yes, hardware is completely up when linuxbios is done.
> 
>  I tried it on a dual CPU Bochs emulation (second CPU was left in "wait
>  for SIPI" state) - I'm guessing I need to enable multi-CPU support
>  via. some compile time option for the "emulation/qemu-i386" target?
 
Yes, the emulation/qemu-i386 is per default not supporting SMP.

>  Either:
>  a) PCI buses and bridges aren't guaranteed to be enumerated, or
>  b) PCI buses and bridges are guaranteed to be enumerated but PCI
>  devices aren't guaranteed to be assigned resources, or
>  c) PCI buses and bridges are guaranteed to be enumerated and PCI
>  devices are guaranteed to have resources assigned (including ROMs)
>  d) PCI buses and bridges are guaranteed to be enumerated and PCI
>  devices are guaranteed to have resources assigned (except ROMs)
 
>  "They have their resources." would mean either c) or d), where each
>  device may or may not be in a power saving state (if supported by the
>  device), and may or may not be still configured to use MSI (if
>  supported by the device)....
 
yes, either c or d. You choose.

> > Not at the moment. But in General this is easy. If no VGA class PCI
> > device is there, the machine is 99.99% headless.
> 
>  And if a VGA class PCI device is present, you've got no idea if no
>  monitor is attached...

Obviously not. and if the device does not do EDD you have no reliable
way of finding out either.

> > > - can anything be assumed about AGP and the first video card (if the
> > > computer isn't headless)?
> >
> > What would you like to assume?
> 
>  Video card set to default "80 * 25" text mode accessible at 0xB8000;
>  or some video mode set with display memory directly accessible at some
>  physical address (where video mode details and physical address
>  included in LinuxBIOS Table); or AGP aperture configured, AGP transfer
>  speed set, MTRRs set to "write combining" and some video mode set with
>  display memory directly accessible at some physical address; or
>  anything else, as long as a payload writer knows how much or how
>  little they can assume about it (and hopefully doesn't need to
>  implement a wide range of video drivers just to do a "Hello World"
>  that works on all video cards)... ;)

Ok, the video hardware is in the state that the VGA Option ROM sets it
to. Since that is closed source, we can not guarantee anything,
obviously. A rule of thumb tells you that 80x25 at B8000 is a reasonable
assumption. The AGP setup is chipset specific, so it might vary from
chipset to chipset.



-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From Jon.Butterfield at Aeroflex.com  Tue Jun 12 15:34:14 2007
From: Jon.Butterfield at Aeroflex.com (Jon Butterfield)
Date: Tue, 12 Jun 2007 08:34:14 -0500
Subject: [LinuxBIOS] need help porting linuxbios to new motherboard
Message-ID: <1181655254.3333.5.camel@WIC-100573.mis.ifrsys.com>

Hi,

I'm trying to port linuxbios onto a Kontron P3T motherboard. It runs
Intel 82815 NB and Intel 82801DB SB, with the mobile Celeron CPU. I have
downloaded linuxBIOSv2 source code, and FILO. I haven't the first clue
how to go about porting linuxBIOS to my motherboard. Where do I start?

Thanks,

Jon
--




From corey.osgood at gmail.com  Tue Jun 12 16:44:06 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 12 Jun 2007 10:44:06 -0400
Subject: [LinuxBIOS] need help porting linuxbios to new motherboard
In-Reply-To: <1181655254.3333.5.camel@WIC-100573.mis.ifrsys.com>
References: <1181655254.3333.5.camel@WIC-100573.mis.ifrsys.com>
Message-ID: <466EB136.9090703@gmail.com>

Jon Butterfield wrote:
> Hi,
>
> I'm trying to port linuxbios onto a Kontron P3T motherboard. It runs
> Intel 82815 NB and Intel 82801DB SB, with the mobile Celeron CPU. I have
> downloaded linuxBIOSv2 source code, and FILO. I haven't the first clue
> how to go about porting linuxBIOS to my motherboard. Where do I start?
>   

Later tonight (would've been a few days ago, but I've been sick), I
should have a set of patches to get the i810 up and running on the asus
mew-vm, those should make a very good starting point for the i815.  The
biggest differences between the two are the 2 additional dram slots and
a second agp controller for off-chip video. I was going to do the 815
myself, but the IDE controller on my board has gone kaput. You'll also
need both the datasheet and the specification update from Intel's
website, just use the search function, "82815 datasheet" should get you
what you need.

-Corey



From btrotter at gmail.com  Tue Jun 12 16:51:51 2007
From: btrotter at gmail.com (Brendan Trotter)
Date: Tue, 12 Jun 2007 14:51:51 +0000
Subject: [LinuxBIOS] Specifications
In-Reply-To: <20070612113508.GA13122@coresystems.de>
References: <b1ebdcad0706112123w5372b7ecv6f76a913dc0b64e4@mail.gmail.com>
	<20070612074909.GA25127@coresystems.de>
	<b1ebdcad0706120343l7087881h5bd9981efab8e341@mail.gmail.com>
	<20070612113508.GA13122@coresystems.de>
Message-ID: <b1ebdcad0706120751i517e8afdnb40cfb9d3570992d@mail.gmail.com>

Hi,

On 6/12/07, Stefan Reinauer <stepan at coresystems.de> wrote:
> * Brendan Trotter <btrotter at gmail.com> [070612 12:43]:
> > > check LinuxBIOSv2/util/lbtdump
> >
> >  I've found "src/include/boot/linuxbios_tables.h" and have also looked
> >  at the source for LinuxBIOSv2/util/lbtdump.
> >
> >  However, I fail to see how any source code can be considered a viable
> >  alternative to documentation for something that is (hopefully) a
> >  non-proprietory common standard. Reverse engineering (including
> >  relying on assumptions derived from the source code of any specific
> >  implementation) is what people do when they have no documentation and
> >  are willing to stumble around in the dark hoping to implement
> >  something that works until the wind changes.
>
> Yes, no doubt. You are perfectly right, and we are looking forward to
> your patches to fix this problem. Of course you do not have to reverse
> engineer, but just read the code, as we are non-proprietary. And of
> course we are always here to be asked.

Hehe - by the time you've finished answering all my questions you'd
wish you'd written the documentation beforehand... ;-)

Is "uint32_t" always little-endian or is it architecture specific
(reverse engineering ruled out "always big-endian"), and would the
"lb_header.signature" field always have an ASCII 'L' at the lowest
address (or is that architecture specific too)?

The source file "util/lbtdump/lbtdump.c" does this:

		if (head->header_bytes != sizeof(*head)) {
			fprintf(stderr, "Header bytes of %d are incorrect\n",
				head->header_bytes);
			continue;
		}


From thomas.ekstrand at gmail.com  Tue Jun 12 18:56:46 2007
From: thomas.ekstrand at gmail.com (Thomas Ekstrand)
Date: Tue, 12 Jun 2007 18:56:46 +0200
Subject: [LinuxBIOS] Strange reset loading linux on epia! was "EPIA hang
	after patch"
Message-ID: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>

I got passed it! seemed to be a buggy flash and/or burn. The vt8231 is
working with flashrom, except for the verify :/
Anyway I rebuilt and reflashed it and now it almost works.
I get an immediate reset during linux startup I have no Idea what
might cause it. I've attached the serial output

Thanks for any help!
Thomas

2007/6/12, ben at hewson-venieri.co.uk <ben at hewson-venieri.co.uk>:
> Can you try using just 1 memory module to start with and see if that helps.
>
>
>
> >Hi!
> >
> >I checked out r2717 and at first it behaved like Markus Boas Epia V
> >but then I applied Ben's patch to the vt8231_early_serial.c and it
> >booted into filo, once, then hanged at the dram setup. then I applied
> >the vt8231_lpc.c patch and it hangs on this:
> >
> >LinuxBIOS-2.0.0.0Normal Mon Jun 11 22:28:57 CEST 2007 starting...
> >87 is the comm register
> >SMBus controller enabled
> >vt8601 init starting
> >00000000 is the north
> >                     1106 0601
> >0120d4 is the computed timing
> >                             NOP
> >PRECHARGE
> >DUMMY READS
> >CBR
> >MRS
> >NORMAL
> >set ref. rate
> >enable multi-page open
> >Slot 00 is SDRAM 10000000 bytes
> >000e is the MA type
> >Slot 01 is SDRAM 08000000 bytes x2
> >000c is the MA type
> >Slot 02 is empty
> >Slot 03 is empty
> >vt8601 done
> >Copying LinuxBIOS to RAM.
> >Jumping to LinuxBIOS.
> >LinuxBIOS-2.0.0.0Normal Mon Jun 11 22:28:57 CEST 2007 booting...
> >Enumerating buses...
> >scan_static_bus for Root Device
> >Finding PCI configuration type.
> >PCI: Using configuration type 1
> >PCI_DOMAIN: 0000 enabled
> >APIC_CLUSTER: 0 enabled
> >PCI_DOMAIN: 0000 scanning...
> >PCI: pci_scan_bus for bus 00
> >PCI: 00:00.0 [1106/0601] ops
> >PCI: 00:00.0 [1106/0601] enabled
> >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
> >malloc Enter, size 668, free_mem_ptr 0001829c
> >malloc 0x0001829c
> >PCI: 00:14.0 [1106/3065] ops
> >PCI: 00:14.0 [1106/3065] enabled
> >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
> >do_pci_scan_bridge for PCI: 00:01.0
> >PCI: pci_scan_bus for bus 01
> >PCI: devfn 0x0, bad id 0xffffffff
> >PCI: devfn 0x8, bad id 0xffffffff
> >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: devfn 0x88, bad id 0xffffffff
> >PCI: devfn 0x90, bad id 0xffffffff
> >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: pci_scan_bus returning with max=001
> >do_pci_scan_bridge returns max 1
> >scan_static_bus for PCI: 00:11.0
> >malloc Enter, size 668, free_mem_ptr 00018538
> >malloc 0x00018538
> >malloc Enter, size 668, free_mem_ptr 000187d4
> >malloc 0x000187d4
> >malloc Enter, size 668, free_mem_ptr 00018a70
> >malloc 0x00018a70
> >malloc Enter, size 668, free_mem_ptr 00018d0c
> >malloc 0x00018d0c
> >malloc Enter, size 668, free_mem_ptr 00018fa8
> >malloc 0x00018fa8
> >malloc Enter, size 668, free_mem_ptr 00019244
> >malloc 0x00019244
> >malloc Enter, size 668, free_mem_ptr 000194e0
> >malloc 0x000194e0
> >malloc Enter, size 668, free_mem_ptr 0001977c
> >malloc 0x0001977c
> >malloc Enter, size 668, free_mem_ptr 00019a18
> >malloc 0x00019a18
> >malloc Enter, size 668, free_mem_ptr 00019cb4
> >malloc 0x00019cb4
> >malloc Enter, size 668, free_mem_ptr 00019f50
> >malloc 0x00019f50
> >PNP: 002e.0 disabled
> >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
> >PNP: 607a.0 enabled
> >PNP: 607a.1 enabled
> >PNP: 607a.2 enabled
> >PNP: 607a.3 enabled
> >PNP: 607a.5 enabled
> >PNP: 607a.6 enabled
> >PNP: 607a.7 enabled
> >PNP: 607a.8 enabled
> >PNP: 607a.9 enabled
> >PNP: 607a.a enabled
> >PNP: 607a.b enabled
> >scan_static_bus for PCI: 00:11.0 done
> >PCI: pci_scan_bus returning with max=001
> >Unexpected Exception: 6 @ 10:e2c3f00a - Halting
> >Code: 0 eflags: 00010093
> >eax: ffffff00 ebx: 00000000 ecx: 000003f8 edx: 00017eec
> >edi: 00000000 esi: 00000000 ebp: 00000000 esp: 00010004
> >
> >
> >Any ideas would be great!
> >
> >Thanks!
> >/Thomas
> >
> >--
> >linuxbios mailing list
> >linuxbios at linuxbios.org
> >http://www.linuxbios.org/mailman/listinfo/linuxbios
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom.cap
Type: application/cap
Size: 23320 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070612/3d226ada/attachment.bin>

From bios at ryven.de  Tue Jun 12 21:24:53 2007
From: bios at ryven.de (Markus)
Date: Tue, 12 Jun 2007 19:24:53 +0000
Subject: [LinuxBIOS] EPIA hang after patch
In-Reply-To: <19634852.109631181634527829.JavaMail.servlet@kundenserver>
References: <19634852.109631181634527829.JavaMail.servlet@kundenserver>
Message-ID: <20070612192453.3519cb4f@PXE-Image>

Am Tue, 12 Jun 2007 09:48:47 +0200
schrieb ben at hewson-venieri.co.uk:
The Epia V has only one SD-Ram Slot.
And badly is like "only" Infineon Chips. :-(

Markus
> Can you try using just 1 memory module to start with and see if that
> helps.
> 
> 
> 
> >Hi!
> >
> >I checked out r2717 and at first it behaved like Markus Boas Epia V
> >but then I applied Ben's patch to the vt8231_early_serial.c and it
> >booted into filo, once, then hanged at the dram setup. then I applied
> >the vt8231_lpc.c patch and it hangs on this:
> >
> >LinuxBIOS-2.0.0.0Normal Mon Jun 11 22:28:57 CEST 2007 starting...
> >87 is the comm register
> >SMBus controller enabled
> >vt8601 init starting
> >00000000 is the north
> >                     1106 0601
> >0120d4 is the computed timing
> >                             NOP
> >PRECHARGE
> >DUMMY READS
> >CBR
> >MRS
> >NORMAL
> >set ref. rate
> >enable multi-page open
> >Slot 00 is SDRAM 10000000 bytes
> >000e is the MA type
> >Slot 01 is SDRAM 08000000 bytes x2
> >000c is the MA type
> >Slot 02 is empty
> >Slot 03 is empty
> >vt8601 done
> >Copying LinuxBIOS to RAM.
> >Jumping to LinuxBIOS.
> >LinuxBIOS-2.0.0.0Normal Mon Jun 11 22:28:57 CEST 2007 booting...
> >Enumerating buses...
> >scan_static_bus for Root Device
> >Finding PCI configuration type.
> >PCI: Using configuration type 1
> >PCI_DOMAIN: 0000 enabled
> >APIC_CLUSTER: 0 enabled
> >PCI_DOMAIN: 0000 scanning...
> >PCI: pci_scan_bus for bus 00
> >PCI: 00:00.0 [1106/0601] ops
> >PCI: 00:00.0 [1106/0601] enabled
> >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
> >malloc Enter, size 668, free_mem_ptr 0001829c
> >malloc 0x0001829c
> >PCI: 00:14.0 [1106/3065] ops
> >PCI: 00:14.0 [1106/3065] enabled
> >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
> >do_pci_scan_bridge for PCI: 00:01.0
> >PCI: pci_scan_bus for bus 01
> >PCI: devfn 0x0, bad id 0xffffffff
> >PCI: devfn 0x8, bad id 0xffffffff
> >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: devfn 0x88, bad id 0xffffffff
> >PCI: devfn 0x90, bad id 0xffffffff
> >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: pci_scan_bus returning with max=001
> >do_pci_scan_bridge returns max 1
> >scan_static_bus for PCI: 00:11.0
> >malloc Enter, size 668, free_mem_ptr 00018538
> >malloc 0x00018538
> >malloc Enter, size 668, free_mem_ptr 000187d4
> >malloc 0x000187d4
> >malloc Enter, size 668, free_mem_ptr 00018a70
> >malloc 0x00018a70
> >malloc Enter, size 668, free_mem_ptr 00018d0c
> >malloc 0x00018d0c
> >malloc Enter, size 668, free_mem_ptr 00018fa8
> >malloc 0x00018fa8
> >malloc Enter, size 668, free_mem_ptr 00019244
> >malloc 0x00019244
> >malloc Enter, size 668, free_mem_ptr 000194e0
> >malloc 0x000194e0
> >malloc Enter, size 668, free_mem_ptr 0001977c
> >malloc 0x0001977c
> >malloc Enter, size 668, free_mem_ptr 00019a18
> >malloc 0x00019a18
> >malloc Enter, size 668, free_mem_ptr 00019cb4
> >malloc 0x00019cb4
> >malloc Enter, size 668, free_mem_ptr 00019f50
> >malloc 0x00019f50
> >PNP: 002e.0 disabled
> >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
> >PNP: 607a.0 enabled
> >PNP: 607a.1 enabled
> >PNP: 607a.2 enabled
> >PNP: 607a.3 enabled
> >PNP: 607a.5 enabled
> >PNP: 607a.6 enabled
> >PNP: 607a.7 enabled
> >PNP: 607a.8 enabled
> >PNP: 607a.9 enabled
> >PNP: 607a.a enabled
> >PNP: 607a.b enabled
> >scan_static_bus for PCI: 00:11.0 done
> >PCI: pci_scan_bus returning with max=001
> >Unexpected Exception: 6 @ 10:e2c3f00a - Halting
> >Code: 0 eflags: 00010093
> >eax: ffffff00 ebx: 00000000 ecx: 000003f8 edx: 00017eec
> >edi: 00000000 esi: 00000000 ebp: 00000000 esp: 00010004
> >
> >
> >Any ideas would be great!
> >
> >Thanks!
> >/Thomas
> >
> >-- 
> >linuxbios mailing list
> >linuxbios at linuxbios.org
> >http://www.linuxbios.org/mailman/listinfo/linuxbios
> 



From dieter at bloms.de  Tue Jun 12 19:55:11 2007
From: dieter at bloms.de (Dieter Bloms)
Date: Tue, 12 Jun 2007 19:55:11 +0200
Subject: [LinuxBIOS] buggy burn with uniflash ? (was "EPIA hang after patch")
In-Reply-To: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
Message-ID: <20070612175511.GA3652@bloms.de>

Hi,

On Tue, Jun 12, Thomas Ekstrand wrote:

> I got passed it! seemed to be a buggy flash and/or burn. The vt8231 is
> working with flashrom, except for the verify :/

may this be my problem, too ?
I use uniflash (http://www.uniflash.org/), because flashrom doesn't burn
my flash ...


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070612/348808f5/attachment.sig>

From ben at hewson-venieri.com  Tue Jun 12 20:47:04 2007
From: ben at hewson-venieri.com (Ben Hewson)
Date: Tue, 12 Jun 2007 19:47:04 +0100
Subject: [LinuxBIOS] EPIA hang after patch
In-Reply-To: <20070612192453.3519cb4f@PXE-Image>
References: <19634852.109631181634527829.JavaMail.servlet@kundenserver>
	<20070612192453.3519cb4f@PXE-Image>
Message-ID: <466EEA28.2000101@hewson-venieri.com>

Markus wrote:
> Am Tue, 12 Jun 2007 09:48:47 +0200
> schrieb ben at hewson-venieri.co.uk:
> The Epia V has only one SD-Ram Slot.
> And badly is like "only" Infineon Chips. :-(
>
>   

if that is the case then there is a problem with the ram init I think.

Slot 00 is SDRAM 10000000 bytes
000e is the MA type
Slot 01 is SDRAM 08000000 bytes x2
000c is the MA type


Ben




From corey.osgood at gmail.com  Tue Jun 12 21:00:18 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Tue, 12 Jun 2007 15:00:18 -0400
Subject: [LinuxBIOS] Specifications
In-Reply-To: <b1ebdcad0706120751i517e8afdnb40cfb9d3570992d@mail.gmail.com>
References: <b1ebdcad0706112123w5372b7ecv6f76a913dc0b64e4@mail.gmail.com>	<20070612074909.GA25127@coresystems.de>	<b1ebdcad0706120343l7087881h5bd9981efab8e341@mail.gmail.com>	<20070612113508.GA13122@coresystems.de>
	<b1ebdcad0706120751i517e8afdnb40cfb9d3570992d@mail.gmail.com>
Message-ID: <466EED42.9060600@gmail.com>

Brendan Trotter wrote:
> Hi,
>
> On 6/12/07, Stefan Reinauer <stepan at coresystems.de> wrote:
>   
>> * Brendan Trotter <btrotter at gmail.com> [070612 12:43]:
>>     
>>>> check LinuxBIOSv2/util/lbtdump
>>>>         
>>>  I've found "src/include/boot/linuxbios_tables.h" and have also looked
>>>  at the source for LinuxBIOSv2/util/lbtdump.
>>>
>>>  However, I fail to see how any source code can be considered a viable
>>>  alternative to documentation for something that is (hopefully) a
>>>  non-proprietory common standard. Reverse engineering (including
>>>  relying on assumptions derived from the source code of any specific
>>>  implementation) is what people do when they have no documentation and
>>>  are willing to stumble around in the dark hoping to implement
>>>  something that works until the wind changes.
>>>       
>> Yes, no doubt. You are perfectly right, and we are looking forward to
>> your patches to fix this problem. Of course you do not have to reverse
>> engineer, but just read the code, as we are non-proprietary. And of
>> course we are always here to be asked.
>>     
>
> Hehe - by the time you've finished answering all my questions you'd
> wish you'd written the documentation beforehand... ;-)
>   

Probably, but personally I'd rather see Stefan devote his time to the
great work they're doing on v3 ;) I'll try to help a little, although my
knowledge of the inner workings of LB is somewhat limited.

> Is "uint32_t" always little-endian or is it architecture specific
> (reverse engineering ruled out "always big-endian"), 

Yes, it should be dependent on the architecture

> and would the
> "lb_header.signature" field always have an ASCII 'L' at the lowest
> address (or is that architecture specific too)?
>   

no idea...
> The source file "util/lbtdump/lbtdump.c" does this:
>
> 		if (head->header_bytes != sizeof(*head)) {
> 			fprintf(stderr, "Header bytes of %d are incorrect\n",
> 				head->header_bytes);
> 			continue;
> 		}
>
> >From this can I assume that the size of the LinuxBIOS Table header
> will always be 24 bytes, and the LinuxBIOS Table header will never be
> extended in the future (or is this just a bug that makes "lbtdump"
> unable to handle forward/backward compatability)?
>
> The file "src/include/boot/linuxbios_tables.h" defines 3 types of memory ranges:
>
> #define LB_MEM_RAM       1	/* Memory anyone can use */
> #define LB_MEM_RESERVED  2	/* Don't use this memory region */
> #define LB_MEM_TABLE     16	/* Ram configuration tables are kept in */
>
> The file "util/lbtdump/lbtdump.c" doesn't agree:
>
> 		switch(rec->map[i].type) {
> 		case 1: mem_type = "ram"; break;
> 		case 3: mem_type = "acpi"; break;
> 		case 4: mem_type = "nvs"; break;
> 		default:
> 		case 2: mem_type = "reserved"; break;
> 		}
>
> Can I assume that the defines in "linuxbios_tables.h" are out-of-date,
> and that the memory type field is the same as specified by version 2
> of the ACPI specification (but perhaps not version 3, as that defines
> a new "5 = faulty RAM" type)? If "linuxbios_tables.h" is out-of-date,
> is "16 = RAM configuration tables are stored in" still possible on
> older versions of LinuxBIOS (and how would I detect which version of
> LinuxBIOS is present, considering there's no version number in the
> LinuxBIOS Table header)?
>
> What is the LB_TAG_HWRPB structure. Is it something to do with a
> "Hardware Restart Parameter Block", and what does it contain? For e.g.
> would a value of zero indicate that the computer was shutdown
> correctly before boot, and a non-zero value indicate that the computer
> crashed or had hardware problems?
>
>   

Again, no clue really..

> Would I also be correct to assume that a payload doesn't need to care
> about any of the "cmos_entries" and "cmos_enums", unless a BIOS
> setup/configuration utility is being built into the payload?
> Alternatively, could/would a payload search for strings to find CMOS
> values (e.g. search for the cmos_entry with the name string
> "power_on_after_fail" to see if additional hardware testing can be
> skipped, search for "baud_rate" to determine the serial port
> configuration, etc)?
>   

My *understanding* is that different vendors do different things with
the cmos, so payloads couldn't count on them for the vendor bios, so
they don't for linuxbios either. I suppose a payload *could* do this
with linuxbios, if the project wanted to, but I can't think of any that
does, although openbios may. Anything cmos-related, such as power on
after fail, should currently be handled between linuxbios and a
userspace utility, like lxbios.

>   
>> It is of course not unique. It is the index of the vendor name within
>> the strings array of struct lb_mainboard. Since we're not trying to
>> close things down, we don't have to work with magic numbers. So nothing
>> needs to stay unique.
>>     
>
> Of course - it's similar to the way SMI/DMI does strings, yet are the
> strings themselves guaranteed to be unique, or is it possible for one
> manufacturer to use an identifying string in the future that another
> (possibly out of business) manufacturer had used in the past?
>   

This is something google would be good for, I can't come up with a good
answer. Yes, they SHOULD always be unique, given that there are 65536
possible combinations, but whether there's some sort of registration or
assignment system or it's at the manufacturers disposal, I don't know.

> Motherboard manufacturer identification is one of the things that
> (IMHO) should be unique. The motherboard part number string should
> also be unique for that manufacturer ID. Otherwise it'd be difficult
> for payloads/utilities/OSs to use these IDs to avoid any hardware
> problems in specific motherboards.
>   

Manufacturers are often very lax about this, in some cases motherboards
have 5 or more different (subsystem) device IDs on the same board, or in
others they don't bother setting most of them. This is one area where
mainboard manufacturers need to clean up.

>>>>> I assume there may also be ACPI, MP specification, PIRQ routing and/or
>>>>> (possibly) SMI/DMI tables, and I'm guessing that (if present) these
>>>>> tables can be searched for using the same methods as described in
>>>>> their corresponding specifications.
>>>>>           
>>>> They're not used by payloads (except the Linux kernel)
>>>>         
>>>  Surely LinuxBIOS isn't intended as a "Linux only" BIOS though....
>>>       
>> Of course not. ACPI is not really useful for payloads though, unless the
>> payload wants to carry a full blown ACPI interpreter. Which rules out
>> basically anything but an OS.
>>     
>
> I can think of a variety of uses, ranging from utilities that do
> nothing more than display hardware information, to diagnostics, to
> benchmarking, to hyper-visors, to full OSs...
>
>   
>>>>> - are AP CPUs started (or waiting for a SIPI sequence)?
>>>>>           
>>>> yes, hardware is completely up when linuxbios is done.
>>>>         
>>>  I tried it on a dual CPU Bochs emulation (second CPU was left in "wait
>>>  for SIPI" state) - I'm guessing I need to enable multi-CPU support
>>>  via. some compile time option for the "emulation/qemu-i386" target?
>>>       
>> Yes, the emulation/qemu-i386 is per default not supporting SMP.
>>     
>
> I'm becoming skeptical here. I can't find anything in LinuxBIOS source
> code that starts AP CPUs, but in "src/arch/i386/smp/mpspec.c" I did
> find:
>
> /* If we assume a symmetric processor configuration we can
>  * get all of the information we need to write the processor
>  * entry from the bootstrap processor.
>  * Plus I don't think linux really even cares.
>  * Having the proper apicid's in the table so the non-bootstrap
>  *  processors can be woken up should be enough.
>  */
>
> It might be possible that no AP CPUs are ever started, and are instead
> left in a "wait for SIPI" default state, assumed to be identical to
> the BSP, and even assumed to be working (no BIST checks).
>
> AFAIK the normal approach is to send a broadcast INIT-SIPI sequence
> and wait to see which AP CPUs start (if any), and then either record
> details somewhere or have each AP CPU add itself to the MP
> specification and ACPI tables, then setup their MTTRs, thermal
> monitoring, HT links, SMBASE, etc before sending the APs back to the
> "wait for SIPI" state - i.e. in theory it should be mostly
> "configuration-less".
>
> In any case, I'm guessing I need to get LinuxBIOS to generate MP
> specification and ACPI tables to suit the number of CPUs being
> emulated by Bochs/Qemu. Is this as simple as adding something like
> "option CPUs = ?" to the "targets/emulation/qemu-i386/Config.lb" file?
> I'm guessing it's more involved than this, as I couldn't find an
> example in the "Config.lb" of other targets.
>   

Please check out the k8 code, especially init_cpus.c, I think you'll
find what you're looking for there. Afaik, the k8 is the only
smp-supported cpu for the moment.

>   
>>>  Either:
>>>  a) PCI buses and bridges aren't guaranteed to be enumerated, or
>>>  b) PCI buses and bridges are guaranteed to be enumerated but PCI
>>>  devices aren't guaranteed to be assigned resources, or
>>>  c) PCI buses and bridges are guaranteed to be enumerated and PCI
>>>  devices are guaranteed to have resources assigned (including ROMs)
>>>  d) PCI buses and bridges are guaranteed to be enumerated and PCI
>>>  devices are guaranteed to have resources assigned (except ROMs)
>>>       
>>>  "They have their resources." would mean either c) or d), where each
>>>  device may or may not be in a power saving state (if supported by the
>>>  device), and may or may not be still configured to use MSI (if
>>>  supported by the device)....
>>>       
>> yes, either c or d. You choose.
>>     
>
> You mean all LinuxBIOS developers are willing to make sure all PCI
> device ROMs either have physical addresses assigned or don't have
> physical addresses assigned based on my advice? Perhaps I've
> misunderstood... :-)
>   

I think I have too...

>>>> Not at the moment. But in General this is easy. If no VGA class PCI
>>>> device is there, the machine is 99.99% headless.
>>>>         
>>>  And if a VGA class PCI device is present, you've got no idea if no
>>>  monitor is attached...
>>>       
>> Obviously not. and if the device does not do EDD you have no reliable
>> way of finding out either.
>>     
>
> There's a simple and easy way to find out if a monitor is attached or
> not, and it doesn't involve messing about with EDD - simply give the
> end-user the option of setting (or not setting) a value in the CMOS.
>   

This is already an option, to have vga you run the vga rom and send
output to the monitor. Otherwise, you keep serial output and don't
bother with the rom.

> My (limited) reverse engineering has already shown that there's CMOS
> entries for a serial port (possibly intended for setting up a serial
> cable to communicate with a terminal emulator?).
>   

Why reverse engineer? The source code is openly available ;) BTW, we use
the serial port as our main debugging source, LinuxBIOS initially sets
it up in the pre-ram init code, usually to 115200 8N1. Then the post-ram
code reads from the cmos to determine if that speed should be changed or
if serial output should be turned off entirely in favor of vga.

Hope I've been a little help

-Corey



From marc.jones at amd.com  Tue Jun 12 21:51:07 2007
From: marc.jones at amd.com (Marc Jones)
Date: Tue, 12 Jun 2007 13:51:07 -0600
Subject: [LinuxBIOS] [PATCH] AMD DB800 mainboard
Message-ID: <466EF92B.50906@amd.com>

Add the AMD DB800 (AKA Salsa) mainboard.
The DB800 is the AMD LX Reference Design Kit platform.
For details see: http://www.amd.com/geodelxdb800

Signed-off-by: Marc Jones <marc.jones at amd.com>

-- 
Marc Jones
Senior Software Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mainboard_amd_db800.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070612/d96626fc/attachment.ksh>

From svn at openbios.org  Wed Jun 13 00:54:41 2007
From: svn at openbios.org (svn at openbios.org)
Date: Wed, 13 Jun 2007 00:54:41 +0200
Subject: [LinuxBIOS] r2718 - in trunk/LinuxBIOSv2: src/mainboard/amd
	src/mainboard/amd/db800 targets/amd targets/amd/db800
Message-ID: <mailman.392.1355071120.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-13 00:54:41 +0200 (Wed, 13 Jun 2007)
New Revision: 2718

Added:
   trunk/LinuxBIOSv2/src/mainboard/amd/db800/
   trunk/LinuxBIOSv2/src/mainboard/amd/db800/Config.lb
   trunk/LinuxBIOSv2/src/mainboard/amd/db800/Options.lb
   trunk/LinuxBIOSv2/src/mainboard/amd/db800/cache_as_ram_auto.c
   trunk/LinuxBIOSv2/src/mainboard/amd/db800/chip.h
   trunk/LinuxBIOSv2/src/mainboard/amd/db800/cmos.layout
   trunk/LinuxBIOSv2/src/mainboard/amd/db800/failover.c
   trunk/LinuxBIOSv2/src/mainboard/amd/db800/irq_tables.c
   trunk/LinuxBIOSv2/src/mainboard/amd/db800/mainboard.c
   trunk/LinuxBIOSv2/targets/amd/db800/
   trunk/LinuxBIOSv2/targets/amd/db800/Config.lb
Log:
Add the AMD DB800 (AKA Salsa) mainboard.
The DB800 is the AMD LX Reference Design Kit platform.
For details see: http://www.amd.com/geodelxdb800

Signed-off-by: Marc Jones <marc.jones at amd.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Added: trunk/LinuxBIOSv2/src/mainboard/amd/db800/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/amd/db800/Config.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/amd/db800/Config.lb	2007-06-12 22:54:41 UTC (rev 2718)
@@ -0,0 +1,189 @@
+##
+## Compute the location and size of where this firmware image
+## (linuxBIOS plus bootloader) will live in the boot rom chip.
+##
+if USE_FALLBACK_IMAGE
+	default ROM_SECTION_SIZE   = FALLBACK_SIZE
+	default ROM_SECTION_OFFSET = ( ROM_SIZE - FALLBACK_SIZE )
+else
+	default ROM_SECTION_SIZE   = ( ROM_SIZE - FALLBACK_SIZE )
+	default ROM_SECTION_OFFSET = 0
+end
+
+##
+## Compute the start location and size size of
+## The linuxBIOS bootloader.
+##
+
+default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1)
+default PAYLOAD_SIZE			= ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE )
+
+##
+## Compute where this copy of linuxBIOS will start in the boot rom
+##
+default _ROMBASE	  = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE )
+
+##
+## Compute a range of ROM that can cached to speed up linuxBIOS,
+## execution speed.
+##
+## XIP_ROM_SIZE must be a power of 2.
+## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE
+##
+default XIP_ROM_SIZE=65536
+default XIP_ROM_BASE = ( _ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE )
+
+
+##
+## Set all of the defaults for an x86 architecture
+##
+
+arch i386 end
+
+##
+## Build the objects we have code for in this directory.
+##
+
+driver mainboard.o
+
+if HAVE_PIRQ_TABLE
+	object irq_tables.o
+end
+
+if USE_DCACHE_RAM
+	#compile cache_as_ram.c to auto.inc
+	makerule ./cache_as_ram_auto.inc
+			depends "$(MAINBOARD)/cache_as_ram_auto.c option_table.h"
+			action "$(CC) -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/cache_as_ram_auto.c -Os -nostdinc -nostdlib -fno-builtin -Wall -c -S -o $@"
+			action "perl -e 's/.rodata/.rom.data/g' -pi $@"
+			action "perl -e 's/.text/.section .rom.text/g' -pi $@"
+	end
+end
+
+
+##
+## Build our 16 bit and 32 bit linuxBIOS entry code
+##
+mainboardinit cpu/x86/16bit/entry16.inc
+mainboardinit cpu/x86/32bit/entry32.inc
+ldscript /cpu/x86/16bit/entry16.lds
+ldscript /cpu/x86/32bit/entry32.lds
+
+##
+## Build our reset vector (This is where linuxBIOS is entered)
+##
+if USE_FALLBACK_IMAGE
+	mainboardinit cpu/x86/16bit/reset16.inc
+	ldscript /cpu/x86/16bit/reset16.lds
+else
+	mainboardinit cpu/x86/32bit/reset32.inc
+	ldscript /cpu/x86/32bit/reset32.lds
+end
+
+### Should this be in the northbridge code?
+#not in serengeti_cheetah mainboardinit arch/i386/lib/cpu_reset.inc
+
+##
+## Include an id string (For safe flashing)
+##
+mainboardinit arch/i386/lib/id.inc
+ldscript /arch/i386/lib/id.lds
+
+###
+### This is the early phase of linuxBIOS startup
+### Things are delicate and we test to see if we should
+### failover to another image.
+###
+if USE_FALLBACK_IMAGE
+	ldscript /arch/i386/lib/failover.lds
+#	mainboardinit ./failover.inc
+end
+
+###
+### O.k. We aren't just an intermediary anymore!
+###
+
+##
+## Setup RAM
+##
+mainboardinit cpu/x86/fpu/enable_fpu.inc
+
+if USE_DCACHE_RAM
+	mainboardinit cpu/amd/model_lx/cache_as_ram.inc
+	mainboardinit ./cache_as_ram_auto.inc
+end
+
+##
+## Include the secondary Configuration files
+##
+dir /pc80
+config chip.h
+
+chip northbridge/amd/lx
+	device pci_domain 0 on
+		device pci 1.0 on end				# Northbridge
+		device pci 1.1 on end				# Graphics
+		chip southbridge/amd/cs5536
+			# IRQ 12 and 1 unmasked,  Keyboard and Mouse IRQs. OK
+			# SIRQ Mode = Active(Quiet) mode. Save power....
+			# Invert mask = IRQ 12 and 1 are active high. Keyboard and Mouse, UARTs, etc IRQs. OK
+			register "lpc_serirq_enable" = "0x000010da"
+			register "lpc_serirq_polarity" = "0x0000EF25"
+			register "lpc_serirq_mode" = "1"
+			register "enable_gpio_int_route" = "0x0D0C0700"
+			register "enable_ide_nand_flash" = "0"	# 0:ide mode, 1:flash
+			register "enable_USBP4_device" = "1"	# 0: host, 1:device
+			register "enable_USBP4_overcurrent" = "0" #0:off, xxxx:overcurrent setting CS5536 Data Book (pages 380-381)
+			register "com1_enable" = "0"
+			register "com1_address" = "0x3F8"
+			register "com1_irq" = "4"
+			register "com2_enable" = "0"
+			register "com2_address" = "0x2F8"
+			register "com2_irq" = "3"
+			register "unwanted_vpci[0]" = "0"	# End of list has a zero
+			device pci d.0 on end			# Ethernet
+			device pci e.0 on end			# Slot1
+			device pci f.0 on			# ISA Bridge
+				chip superio/winbond/w83627hf
+					device pnp 2e.0 off	# Floppy
+						io 0x60 = 0x3f0
+						irq 0x70 = 6
+						drq 0x74 = 2
+					end
+					device pnp 2e.1 off	# Parallel port
+						io 0x60 = 0x378
+						irq 0x70 = 7
+					end
+					device pnp 2e.2 on	# Com1
+						io 0x60 = 0x3f8
+						irq 0x70 = 4
+					end
+					device pnp 2e.3 off end	# Com2
+					device pnp 2e.5 on	# Keyboard
+						io 0x60 = 0x60
+						io 0x62 = 0x64
+						irq 0x70 = 1
+						irq 0x72 = 12
+					end
+					device pnp 2e.6 off end	# CIR
+					device pnp 2e.7 off end	# GAME_MIDI_GIPO1
+					device pnp 2e.8 off end	# GPIO2
+					device pnp 2e.9 off end	# GPIO3
+					device pnp 2e.a off end	# ACPI
+					device pnp 2e.b off end	# HW Monitor
+				end
+			end
+			device pci f.2 on end			# IDE Controller
+			device pci f.3 on end			# Audio
+			device pci f.4 on end			# OHCI
+			device pci f.5 on end			# EHCI
+		end
+	end
+	# APIC cluster is late CPU init.
+	device apic_cluster 0 on
+		chip cpu/amd/model_lx
+			device apic 0 on end
+		end
+	end
+end
+

Added: trunk/LinuxBIOSv2/src/mainboard/amd/db800/Options.lb
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/amd/db800/Options.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/amd/db800/Options.lb	2007-06-12 22:54:41 UTC (rev 2718)
@@ -0,0 +1,179 @@
+uses HAVE_MP_TABLE
+uses HAVE_PIRQ_TABLE
+uses USE_FALLBACK_IMAGE
+uses HAVE_FALLBACK_BOOT
+uses HAVE_HARD_RESET
+uses HAVE_OPTION_TABLE
+uses USE_OPTION_TABLE
+uses CONFIG_ROM_PAYLOAD
+uses IRQ_SLOT_COUNT
+uses MAINBOARD
+uses MAINBOARD_VENDOR
+uses MAINBOARD_PART_NUMBER
+uses LINUXBIOS_EXTRA_VERSION
+uses ARCH
+uses FALLBACK_SIZE
+uses STACK_SIZE
+uses HEAP_SIZE
+uses ROM_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_IMAGE_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_SECTION_OFFSET
+uses CONFIG_ROM_PAYLOAD_START
+uses CONFIG_COMPRESSED_PAYLOAD_NRV2B
+uses CONFIG_COMPRESSED_PAYLOAD_LZMA
+uses CONFIG_PRECOMPRESSED_PAYLOAD
+uses PAYLOAD_SIZE
+uses _ROMBASE
+uses _RAMBASE
+uses XIP_ROM_SIZE
+uses XIP_ROM_BASE
+uses HAVE_MP_TABLE
+uses CROSS_COMPILE
+uses CC
+uses HOSTCC
+uses OBJCOPY
+uses DEFAULT_CONSOLE_LOGLEVEL
+uses MAXIMUM_CONSOLE_LOGLEVEL
+uses CONFIG_CONSOLE_SERIAL8250
+uses TTYS0_BAUD
+uses TTYS0_BASE
+uses TTYS0_LCS
+uses CONFIG_UDELAY_TSC
+uses CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2
+uses CONFIG_CONSOLE_VGA
+uses CONFIG_PCI_ROM_RUN
+uses CONFIG_VIDEO_MB
+uses USE_DCACHE_RAM
+uses DCACHE_RAM_BASE
+uses DCACHE_RAM_SIZE
+
+## ROM_SIZE is the size of boot ROM that this board will use.
+default ROM_SIZE  = 256*1024
+
+###
+### Build options
+###
+default CONFIG_CONSOLE_VGA=0
+default CONFIG_VIDEO_MB=8
+default CONFIG_PCI_ROM_RUN=0
+
+##
+## Build code for the fallback boot
+##
+default HAVE_FALLBACK_BOOT=1
+
+##
+## no MP table
+##
+default HAVE_MP_TABLE=0
+
+##
+## Build code to reset the motherboard from linuxBIOS
+##
+default HAVE_HARD_RESET=0
+
+## Delay timer options
+##
+default CONFIG_UDELAY_TSC=1
+default CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2=1
+
+##
+## Build code to export a programmable irq routing table
+##
+default HAVE_PIRQ_TABLE=1
+default IRQ_SLOT_COUNT=4
+#object irq_tables.o
+
+##
+## Build code to export a CMOS option table
+##
+default HAVE_OPTION_TABLE=0
+
+###
+### LinuxBIOS layout values
+###
+
+## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy.
+default ROM_IMAGE_SIZE = 65536
+default FALLBACK_SIZE = 131072
+
+##
+## enable CACHE_AS_RAM specifics
+##
+default USE_DCACHE_RAM=1
+default DCACHE_RAM_BASE=0xc8000
+default DCACHE_RAM_SIZE=0x08000
+
+##
+## Use a small 8K stack
+##
+default STACK_SIZE=0x2000
+
+##
+## Use a small 16K heap
+##
+default HEAP_SIZE=0x4000
+
+##
+## Only use the option table in a normal image
+##
+#default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE
+default USE_OPTION_TABLE = 0
+
+default _RAMBASE = 0x00004000
+
+default CONFIG_ROM_PAYLOAD = 1
+
+##
+## The default compiler
+##
+default CROSS_COMPILE=""
+default CC="$(CROSS_COMPILE)gcc -m32"
+default HOSTCC="gcc"
+
+##
+## The Serial Console
+##
+
+# To Enable the Serial Console
+default CONFIG_CONSOLE_SERIAL8250=1
+
+## Select the serial console baud rate
+default TTYS0_BAUD=115200
+#default TTYS0_BAUD=57600
+#default TTYS0_BAUD=38400
+#default TTYS0_BAUD=19200
+#default TTYS0_BAUD=9600
+#default TTYS0_BAUD=4800
+#default TTYS0_BAUD=2400
+#default TTYS0_BAUD=1200
+
+# Select the serial console base port
+default TTYS0_BASE=0x3f8
+
+# Select the serial protocol
+# This defaults to 8 data bits, 1 stop bit, and no parity
+default TTYS0_LCS=0x3
+
+##
+### Select the linuxBIOS loglevel
+##
+## EMERG      1   system is unusable
+## ALERT      2   action must be taken immediately
+## CRIT       3   critical conditions
+## ERR        4   error conditions
+## WARNING    5   warning conditions
+## NOTICE     6   normal but significant condition
+## INFO       7   informational
+## DEBUG      8   debug-level messages
+## SPEW       9   Way too many details
+
+## Request this level of debugging output
+default  DEFAULT_CONSOLE_LOGLEVEL=8
+## At a maximum only compile in this level of debugging
+default  MAXIMUM_CONSOLE_LOGLEVEL=8
+
+end
+

Added: trunk/LinuxBIOSv2/src/mainboard/amd/db800/cache_as_ram_auto.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/amd/db800/cache_as_ram_auto.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/amd/db800/cache_as_ram_auto.c	2007-06-12 22:54:41 UTC (rev 2718)
@@ -0,0 +1,132 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define ASSEMBLY 1
+
+#include <stdint.h>
+#include <device/pci_def.h>
+#include <arch/io.h>
+#include <device/pnp_def.h>
+#include <arch/hlt.h>
+#include "pc80/serial.c"
+#include "arch/i386/lib/console.c"
+#include "ram/ramtest.c"
+#include "cpu/x86/bist.h"
+#include "cpu/x86/msr.h"
+#include <cpu/amd/lxdef.h>
+#include <cpu/amd/geode_post_code.h>
+#include "southbridge/amd/cs5536/cs5536.h"
+
+#define POST_CODE(x) outb(x, 0x80)
+#define SERIAL_DEV PNP_DEV(0x2e, W83627HF_SP1)
+
+#include "southbridge/amd/cs5536/cs5536_early_smbus.c"
+#include "southbridge/amd/cs5536/cs5536_early_setup.c"
+#include "superio/winbond/w83627hf/w83627hf_early_serial.c"
+
+static inline int spd_read_byte(unsigned int device, unsigned int address)
+{
+	return smbus_read_byte(device, address);
+}
+
+#define ManualConf 0		/* Do automatic strapped PLL config */
+#define PLLMSRhi 0x00001490	/* Manual settings for the PLL */
+#define PLLMSRlo 0x02000030
+#define DIMM0 0xA0
+#define DIMM1 0xA2
+
+#include "northbridge/amd/lx/raminit.h"
+#include "northbridge/amd/lx/pll_reset.c"
+#include "northbridge/amd/lx/raminit.c"
+#include "sdram/generic_sdram.c"
+#include "cpu/amd/model_lx/cpureginit.c"
+#include "cpu/amd/model_lx/syspreinit.c"
+
+static void msr_init(void)
+{
+	msr_t msr;
+
+	/* Setup access to the cache for under 1MB. */
+	msr.hi = 0x24fffc02;
+	msr.lo = 0x1000A000;	/* 0-A0000 write back */
+	wrmsr(CPU_RCONF_DEFAULT, msr);
+
+	msr.hi = 0x0;		/* Write back */
+	msr.lo = 0x0;
+	wrmsr(CPU_RCONF_A0_BF, msr);
+	wrmsr(CPU_RCONF_C0_DF, msr);
+	wrmsr(CPU_RCONF_E0_FF, msr);
+
+	/* Setup access to the cache for under 640K. Note MC not setup yet. */
+	msr.hi = 0x20000000;
+	msr.lo = 0xfff80;
+	wrmsr(MSR_GLIU0 + 0x20, msr);
+
+	msr.hi = 0x20000000;
+	msr.lo = 0x80fffe0;
+	wrmsr(MSR_GLIU0 + 0x21, msr);
+
+	msr.hi = 0x20000000;
+	msr.lo = 0xfff80;
+	wrmsr(MSR_GLIU1 + 0x20, msr);
+
+	msr.hi = 0x20000000;
+	msr.lo = 0x80fffe0;
+	wrmsr(MSR_GLIU1 + 0x21, msr);
+}
+
+static void mb_gpio_init(void)
+{
+	/* Early mainboard specific GPIO setup. */
+}
+
+void cache_as_ram_main(void)
+{
+	POST_CODE(0x01);
+
+	static const struct mem_controller memctrl[] = {
+		{.channel0 = {(0xa << 3) | 0, (0xa << 3) | 1}}
+	};
+
+	SystemPreInit();
+	msr_init();
+
+	cs5536_early_setup();
+
+	/* Note: must do this AFTER the early_setup! It is counting on some
+	 * early MSR setup for CS5536.
+	 */
+	w83627hf_enable_serial(SERIAL_DEV, TTYS0_BASE);
+	mb_gpio_init();
+	uart_init();
+	console_init();
+
+	pll_reset(ManualConf);
+
+	cpuRegInit();
+
+	sdram_initialize(1, memctrl);
+
+	/* Check memory. */
+	/* ram_check(0x00000000, 640 * 1024); */
+
+	/* Memory is setup. Return to cache_as_ram.inc and continue to boot. */
+	return;
+}

Added: trunk/LinuxBIOSv2/src/mainboard/amd/db800/chip.h
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/amd/db800/chip.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/amd/db800/chip.h	2007-06-12 22:54:41 UTC (rev 2718)
@@ -0,0 +1,25 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+extern struct chip_operations mainboard_amd_db800_ops;
+
+struct mainboard_amd_db800_config {
+	int nothing;
+};

Added: trunk/LinuxBIOSv2/src/mainboard/amd/db800/cmos.layout
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/amd/db800/cmos.layout	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/amd/db800/cmos.layout	2007-06-12 22:54:41 UTC (rev 2718)
@@ -0,0 +1,74 @@
+entries
+
+#start-bit length  config config-ID    name
+#0            8       r       0        seconds
+#8            8       r       0        alarm_seconds
+#16           8       r       0        minutes
+#24           8       r       0        alarm_minutes
+#32           8       r       0        hours
+#40           8       r       0        alarm_hours
+#48           8       r       0        day_of_week
+#56           8       r       0        day_of_month
+#64           8       r       0        month
+#72           8       r       0        year
+#80           4       r       0        rate_select
+#84           3       r       0        REF_Clock
+#87           1       r       0        UIP
+#88           1       r       0        auto_switch_DST
+#89           1       r       0        24_hour_mode
+#90           1       r       0        binary_values_enable
+#91           1       r       0        square-wave_out_enable
+#92           1       r       0        update_finished_enable
+#93           1       r       0        alarm_interrupt_enable
+#94           1       r       0        periodic_interrupt_enable
+#95           1       r       0        disable_clock_updates
+#96         288       r       0        temporary_filler
+0          384       r       0        reserved_memory
+384          1       e       4        boot_option
+385          1       e       4        last_boot
+386          1       e       1        ECC_memory
+388          4       r       0        reboot_bits
+392          3       e       5        baud_rate
+400          1       e       1        power_on_after_fail
+412          4       e       6        debug_level
+416          4       e       7        boot_first
+420          4       e       7        boot_second
+424          4       e       7        boot_third
+428          4       h       0        boot_index
+432	     8       h       0        boot_countdown
+1008         16      h       0        check_sum
+
+enumerations
+
+#ID value   text
+1     0     Disable
+1     1     Enable
+2     0     Enable
+2     1     Disable
+4     0     Fallback
+4     1     Normal
+5     0     115200
+5     1     57600
+5     2     38400
+5     3     19200
+5     4     9600
+5     5     4800
+5     6     2400
+5     7     1200
+6     6     Notice
+6     7     Info
+6     8     Debug
+6     9     Spew
+7     0     Network
+7     1     HDD
+7     2     Floppy
+7     8     Fallback_Network
+7     9     Fallback_HDD
+7     10    Fallback_Floppy
+#7     3     ROM
+
+checksums
+
+checksum 392 1007 1008
+
+

Added: trunk/LinuxBIOSv2/src/mainboard/amd/db800/failover.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/amd/db800/failover.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/amd/db800/failover.c	2007-06-12 22:54:41 UTC (rev 2718)
@@ -0,0 +1,32 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define ASSEMBLY 1
+
+#include <stdint.h>
+#include <device/pci_def.h>
+#include <device/pci_ids.h>
+#include <arch/io.h>
+#include "pc80/mc146818rtc_early.c"
+
+static unsigned long main(unsigned long bist)
+{
+	return bist;
+}

Added: trunk/LinuxBIOSv2/src/mainboard/amd/db800/irq_tables.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/amd/db800/irq_tables.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/amd/db800/irq_tables.c	2007-06-12 22:54:41 UTC (rev 2718)
@@ -0,0 +1,106 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 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 version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.	See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <arch/pirq_routing.h>
+#include <console/console.h>
+#include <arch/io.h>
+#include <arch/pirq_routing.h>
+#include "../../../southbridge/amd/cs5536/cs5536.h"
+
+/* Platform IRQs */
+#define PIRQA 10
+#define PIRQB 11
+#define PIRQC 10
+#define PIRQD 11
+
+/* Map */
+#define M_PIRQA (1 << PIRQA)	/* Bitmap of supported IRQs */
+#define M_PIRQB (1 << PIRQB)	/* Bitmap of supported IRQs */
+#define M_PIRQC (1 << PIRQC)	/* Bitmap of supported IRQs */
+#define M_PIRQD (1 << PIRQD)	/* Bitmap of supported IRQs */
+
+/* Link */
+#define L_PIRQA	 1		/* Means Slot INTx# Connects To Chipset INTA# */
+#define L_PIRQB	 2		/* Means Slot INTx# Connects To Chipset INTB# */
+#define L_PIRQC	 3		/* Means Slot INTx# Connects To Chipset INTC# */
+#define L_PIRQD	 4		/* Means Slot INTx# Connects To Chipset INTD# */
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,		/* u32 signature */
+	PIRQ_VERSION,		/* u16 version   */
+	32 + 16 * IRQ_SLOT_COUNT,	/* there can be total 6 devices on the bus */
+	0x00,			/* Where the interrupt router lies (bus) */
+	(0x0F << 3) | 0x0,	/* Where the interrupt router lies (dev) */
+	0x00,			/* IRQs devoted exclusively to PCI usage */
+	0x100B,			/* Vendor */
+	0x002B,			/* Device */
+	0,			/* Crap (miniport) */
+	{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},	/* u8 rfu[11] */
+	0x00,			/*      u8 checksum , this has to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */
+	{
+	 /* If you change the number of entries, change the IRQ_SLOT_COUNT above! */
+	 /* bus, dev|fn,           {link, bitmap},      {link, bitmap},     {link, bitmap},     {link, bitmap},     slot, rfu */
+	 {0x00, (0x01 << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* cpu */
+	 {0x00, (0x0F << 3) | 0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0},	/* chipset */
+	 {0x00, (0x0D << 3) | 0x0, {{L_PIRQB, M_PIRQB}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0},	/* ethernet */
+	 {0x00, (0x0E << 3) | 0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x1, 0x0},	/* slot1 */
+	 }
+};
+
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+	int i, j, k, num_entries;
+	unsigned char pirq[4];
+	uint16_t chipset_irq_map;
+	uint32_t pciAddr, pirtable_end;
+	struct irq_routing_table *pirq_tbl;
+
+	pirtable_end = copy_pirq_routing_table(addr);
+
+	/* Set up chipset IRQ steering. */
+	pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C;
+	chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA);
+	printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr,
+		     chipset_irq_map);
+	outl(pciAddr & ~3, 0xCF8);
+	outl(chipset_irq_map, 0xCFC);
+
+	pirq_tbl = (struct irq_routing_table *)(addr);
+	num_entries = (pirq_tbl->size - 32) / 16;
+
+	/* Set PCI IRQs. */
+	for (i = 0; i < num_entries; i++) {
+		printk_debug("PIR Entry %d Dev/Fn: %X Slot: %d\n", i,
+			     pirq_tbl->slots[i].devfn, pirq_tbl->slots[i].slot);
+		for (j = 0; j < 4; j++) {
+			printk_debug("INT: %c bitmap: %x ", 'A' + j,
+				     pirq_tbl->slots[i].irq[j].bitmap);
+			for (k = 0; (!((pirq_tbl->slots[i].irq[j].bitmap >> k) & 1)) && (pirq_tbl->slots[i].irq[j].bitmap != 0); k++) ;	/* Finds lsb in bitmap to IRQ#. */
+			pirq[j] = k;
+			printk_debug("PIRQ: %d\n", k);
+		}
+
+		/* Bus, device, slots IRQs for {A,B,C,D}. */
+		pci_assign_irqs(pirq_tbl->slots[i].bus,
+				pirq_tbl->slots[i].devfn >> 3, pirq);
+	}
+
+	/* Put the PIR table in memory and checksum. */
+	return pirtable_end;
+}

Added: trunk/LinuxBIOSv2/src/mainboard/amd/db800/mainboard.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/amd/db800/mainboard.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/amd/db800/mainboard.c	2007-06-12 22:54:41 UTC (rev 2718)
@@ -0,0 +1,193 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 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 version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <arch/io.h>
+#include <cpu/x86/msr.h>
+#include <cpu/amd/lxdef.h>
+#include <device/pci_def.h>
+#include "../../../southbridge/amd/cs5536/cs5536.h"
+#include "chip.h"
+
+/* Print the platform configuration - do before PCI init or it will not
+ * work right.
+ */
+void print_conf(void)
+{
+#if DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR
+	int i;
+	unsigned long iol;
+	msr_t msr;
+
+	int cpu_msr_defs[] = { CPU_BC_L2_CONF, CPU_IM_CONFIG, CPU_DM_CONFIG0,
+		CPU_RCONF_DEFAULT, CPU_RCONF_BYPASS, CPU_RCONF_A0_BF,
+		CPU_RCONF_C0_DF, CPU_RCONF_E0_FF, CPU_RCONF_SMM, CPU_RCONF_DMM,
+		GLCP_DELAY_CONTROLS, GL_END
+	};
+
+	int gliu0_msr_defs[] = { MSR_GLIU0_BASE1, MSR_GLIU0_BASE2,
+		MSR_GLIU0_BASE4, MSR_GLIU0_BASE5, MSR_GLIU0_BASE6,
+		GLIU0_P2D_BMO_0, GLIU0_P2D_BMO_1, MSR_GLIU0_SYSMEM,
+		GLIU0_P2D_RO_0, GLIU0_P2D_RO_1, GLIU0_P2D_RO_2,
+		MSR_GLIU0_SHADOW, GLIU0_IOD_BM_0, GLIU0_IOD_BM_1,
+		GLIU0_IOD_BM_2, GLIU0_IOD_SC_0, GLIU0_IOD_SC_1, GLIU0_IOD_SC_2,
+		GLIU0_IOD_SC_3, GLIU0_IOD_SC_4, GLIU0_IOD_SC_5,
+		GLIU0_GLD_MSR_COH, GL_END
+	};
+
+	int gliu1_msr_defs[] = { MSR_GLIU1_BASE1, MSR_GLIU1_BASE2,
+		MSR_GLIU1_BASE3, MSR_GLIU1_BASE4, MSR_GLIU1_BASE5,
+		MSR_GLIU1_BASE6, MSR_GLIU1_BASE7, MSR_GLIU1_BASE8,
+		MSR_GLIU1_BASE9, MSR_GLIU1_BASE10, GLIU1_P2D_R_0,
+		GLIU1_P2D_R_1, GLIU1_P2D_R_2, GLIU1_P2D_R_3, MSR_GLIU1_SHADOW,
+		GLIU1_IOD_BM_0, GLIU1_IOD_BM_1, GLIU1_IOD_BM_2, GLIU1_IOD_SC_0,
+		GLIU1_IOD_SC_1, GLIU1_IOD_SC_2, GLIU1_IOD_SC_3,
+		GLIU1_GLD_MSR_COH, GL_END
+	};
+
+	int rconf_msr[] = { CPU_RCONF0, CPU_RCONF1, CPU_RCONF2, CPU_RCONF3,
+		CPU_RCONF4, CPU_RCONF5, CPU_RCONF6, CPU_RCONF7, GL_END
+	};
+
+	int cs5536_msr[] = { MDD_LBAR_GPIO, MDD_LBAR_FLSH0, MDD_LBAR_FLSH1,
+		MDD_LEG_IO, MDD_PIN_OPT, MDD_IRQM_ZLOW, MDD_IRQM_ZHIGH,
+		MDD_IRQM_PRIM, GL_END
+	};
+
+	int pci_msr[] = { GLPCI_CTRL, GLPCI_ARB, GLPCI_REN, GLPCI_A0_BF,
+		GLPCI_C0_DF, GLPCI_E0_FF, GLPCI_RC0, GLPCI_RC1, GLPCI_RC2,
+		GLPCI_RC3, GLPCI_ExtMSR, GLPCI_SPARE, GL_END
+	};
+
+	int dma_msr[] = { MDD_DMA_MAP, MDD_DMA_SHAD1, MDD_DMA_SHAD2,
+		MDD_DMA_SHAD3, MDD_DMA_SHAD4, MDD_DMA_SHAD5, MDD_DMA_SHAD6,
+		MDD_DMA_SHAD7, MDD_DMA_SHAD8, MDD_DMA_SHAD9, GL_END
+	};
+
+	printk_debug("---------- CPU ------------\n");
+
+	for (i = 0; cpu_msr_defs[i] != GL_END; i++) {
+		msr = rdmsr(cpu_msr_defs[i]);
+		printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n",
+			     cpu_msr_defs[i], msr.hi, msr.lo);
+	}
+
+	printk_debug("---------- GLIU 0 ------------\n");
+
+	for (i = 0; gliu0_msr_defs[i] != GL_END; i++) {
+		msr = rdmsr(gliu0_msr_defs[i]);
+		printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n",
+			     gliu0_msr_defs[i], msr.hi, msr.lo);
+	}
+
+	printk_debug("---------- GLIU 1 ------------\n");
+
+	for (i = 0; gliu1_msr_defs[i] != GL_END; i++) {
+		msr = rdmsr(gliu1_msr_defs[i]);
+		printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n",
+			     gliu1_msr_defs[i], msr.hi, msr.lo);
+	}
+
+	printk_debug("---------- RCONF ------------\n");
+
+	for (i = 0; rconf_msr[i] != GL_END; i++) {
+		msr = rdmsr(rconf_msr[i]);
+		printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", rconf_msr[i],
+			     msr.hi, msr.lo);
+	}
+
+	printk_debug("---------- VARIA ------------\n");
+	msr = rdmsr(0x51300010);
+	printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51300010, msr.hi,
+		     msr.lo);
+
+	msr = rdmsr(0x51400015);
+	printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", 0x51400015, msr.hi,
+		     msr.lo);
+
+	printk_debug("---------- DIVIL IRQ ------------\n");
+	msr = rdmsr(MDD_IRQM_YLOW);
+	printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YLOW, msr.hi,
+		     msr.lo);
+	msr = rdmsr(MDD_IRQM_YHIGH);
+	printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_YHIGH,
+		     msr.hi, msr.lo);
+	msr = rdmsr(MDD_IRQM_ZLOW);
+	printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZLOW, msr.hi,
+		     msr.lo);
+	msr = rdmsr(MDD_IRQM_ZHIGH);
+	printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", MDD_IRQM_ZHIGH,
+		     msr.hi, msr.lo);
+
+	printk_debug("---------- PCI ------------\n");
+
+	for (i = 0; pci_msr[i] != GL_END; i++) {
+		msr = rdmsr(pci_msr[i]);
+		printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", pci_msr[i],
+			     msr.hi, msr.lo);
+	}
+
+	printk_debug("---------- LPC/UART DMA ------------\n");
+
+	for (i = 0; dma_msr[i] != GL_END; i++) {
+		msr = rdmsr(dma_msr[i]);
+		printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", dma_msr[i],
+			     msr.hi, msr.lo);
+	}
+
+	printk_debug("---------- CS5536 ------------\n");
+
+	for (i = 0; cs5536_msr[i] != GL_END; i++) {
+		msr = rdmsr(cs5536_msr[i]);
+		printk_debug("MSR 0x%08X is now 0x%08X:0x%08X\n", cs5536_msr[i],
+			     msr.hi, msr.lo);
+	}
+
+	iol = inl(GPIO_IO_BASE + GPIOL_INPUT_ENABLE);
+	printk_debug("IOR 0x%08X is now 0x%08X\n",
+		     GPIO_IO_BASE + GPIOL_INPUT_ENABLE, iol);
+	iol = inl(GPIOL_EVENTS_ENABLE);
+	printk_debug("IOR 0x%08X is now 0x%08X\n",
+		     GPIO_IO_BASE + GPIOL_EVENTS_ENABLE, iol);
+	iol = inl(GPIOL_INPUT_INVERT_ENABLE);
+	printk_debug("IOR 0x%08X is now 0x%08X\n",
+		     GPIO_IO_BASE + GPIOL_INPUT_INVERT_ENABLE, iol);
+	iol = inl(GPIO_MAPPER_X);
+	printk_debug("IOR 0x%08X is now 0x%08X\n", GPIO_IO_BASE + GPIO_MAPPER_X,
+		     iol);
+#endif				//DEFAULT_CONSOLE_LOGLEVEL >= BIOS_ERR
+}
+
+static void init(struct device *dev)
+{
+	printk_debug("AMD DB800 ENTER %s\n", __FUNCTION__);
+	printk_debug("AMD DB800 EXIT %s\n", __FUNCTION__);
+}
+
+static void enable_dev(struct device *dev)
+{
+	dev->ops->init = init;
+}
+
+struct chip_operations mainboard_amd_db800_ops = {
+	CHIP_NAME("AMD DB800 Mainboard")
+	.enable_dev = enable_dev,
+
+};

Added: trunk/LinuxBIOSv2/targets/amd/db800/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/targets/amd/db800/Config.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/targets/amd/db800/Config.lb	2007-06-12 22:54:41 UTC (rev 2718)
@@ -0,0 +1,49 @@
+##
+## This file is part of the LinuxBIOS project.
+##
+## Copyright (C) 2007 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.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+# Config file for the AMD Geode LX/5536 DB800 platform.
+
+target db800
+mainboard amd/db800
+
+# HACK to get the right TSC support.
+option CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2=1
+
+option CONFIG_COMPRESSED_PAYLOAD_NRV2B=0
+option CONFIG_COMPRESSED_PAYLOAD_LZMA=0
+
+# Leave 36k for VSA.
+option ROM_SIZE=512*1024-36*1024
+# option ROM_SIZE=256*1024-36*1024
+option FALLBACK_SIZE=ROM_SIZE
+
+option DEFAULT_CONSOLE_LOGLEVEL = 11
+option MAXIMUM_CONSOLE_LOGLEVEL = 11
+# option DEFAULT_CONSOLE_LOGLEVEL = 4
+# option MAXIMUM_CONSOLE_LOGLEVEL = 4
+
+romimage "fallback"
+	option USE_FALLBACK_IMAGE=1
+	option ROM_IMAGE_SIZE=64*1024
+	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
+	payload ../payload.elf
+end
+
+buildrom ./db800.rom ROM_SIZE "fallback"




From uwe at hermann-uwe.de  Wed Jun 13 01:03:47 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 13 Jun 2007 01:03:47 +0200
Subject: [LinuxBIOS] [PATCH] AMD DB800 mainboard
In-Reply-To: <466EF92B.50906@amd.com>
References: <466EF92B.50906@amd.com>
Message-ID: <20070612230347.GA12600@greenwood>

On Tue, Jun 12, 2007 at 01:51:07PM -0600, Marc Jones wrote:
> Add the AMD DB800 (AKA Salsa) mainboard.
> The DB800 is the AMD LX Reference Design Kit platform.
> For details see: http://www.amd.com/geodelxdb800
> 
> Signed-off-by: Marc Jones <marc.jones at amd.com>

Great stuff! Committed in r2718 with minor fixes. Thanks a lot!


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070613/0dfa6468/attachment.sig>

From uwe at hermann-uwe.de  Wed Jun 13 01:26:31 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 13 Jun 2007 01:26:31 +0200
Subject: [LinuxBIOS] Strange reset loading linux on epia! was "EPIA hang
	after patch"
In-Reply-To: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
Message-ID: <20070612232631.GB12600@greenwood>

On Tue, Jun 12, 2007 at 06:56:46PM +0200, Thomas Ekstrand wrote:
> I got passed it! seemed to be a buggy flash and/or burn. The vt8231 is
> working with flashrom, except for the verify :/
> Anyway I rebuilt and reflashed it and now it almost works.
> I get an immediate reset during linux startup I have no Idea what
> might cause it. I've attached the serial output

This looks like the culprit:

0000:00:11.4: base address not set -                             upgrade BIOS or use force_addr=0xaddr

What is 00:11.4?

Or maybe it's just a random, unrelated effect and bad RAM init is the
real culprit(?) hard to say.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070613/e55c59e8/attachment.sig>

From info at coresystems.de  Wed Jun 13 01:37:59 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Wed, 13 Jun 2007 01:37:59 +0200
Subject: [LinuxBIOS] r2718 build service
Message-ID: <E1HyFvz-00012e-8L@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "uwe" checked in revision 2718 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
Add the AMD DB800 (AKA Salsa) mainboard.
The DB800 is the AMD LX Reference Design Kit platform.
For details see: http://www.amd.com/geodelxdb800

Signed-off-by: Marc Jones <marc.jones at amd.com>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2718&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2718&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2718&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2718&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2718&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2718&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From uwe at hermann-uwe.de  Wed Jun 13 01:56:17 2007
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 13 Jun 2007 01:56:17 +0200
Subject: [LinuxBIOS] [PATCH] Intel 82371EB improvements
Message-ID: <20070612235617.GC12600@greenwood>

See patch.

Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_i82371eb.patch
Type: text/x-diff
Size: 18145 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070613/996a8841/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070613/996a8841/attachment.sig>

From rminnich at gmail.com  Wed Jun 13 06:18:51 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 12 Jun 2007 21:18:51 -0700
Subject: [LinuxBIOS] MC struct
In-Reply-To: <20070607182524.29971.qmail@cdy.org>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
	<20070607182524.29971.qmail@cdy.org>
Message-ID: <13426df10706122118n66227050s94c78fa1942beb71@mail.gmail.com>

On 6/7/07, Peter Stuge <stuge-linuxbios at cdy.org> wrote:


>
> A device tree (not list) in code that
> * is seeded by the mainboard dts, which lists all devices
> * has device options set from defaults in device dts
> * has device option overrides from mainboard dts

I have this almost done, just FYI.

ron



From rminnich at gmail.com  Wed Jun 13 06:37:27 2007
From: rminnich at gmail.com (ron minnich)
Date: Tue, 12 Jun 2007 21:37:27 -0700
Subject: [LinuxBIOS] MC struct
In-Reply-To: <13426df10706122118n66227050s94c78fa1942beb71@mail.gmail.com>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
	<20070607182524.29971.qmail@cdy.org>
	<13426df10706122118n66227050s94c78fa1942beb71@mail.gmail.com>
Message-ID: <13426df10706122137p36dbd21bx351ca6368f48081b@mail.gmail.com>

On 6/12/07, ron minnich <rminnich at gmail.com> wrote:
> On 6/7/07, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
>
>
> >
> > A device tree (not list) in code that
> > * is seeded by the mainboard dts, which lists all devices
> > * has device options set from defaults in device dts
> > * has device option overrides from mainboard dts
>
> I have this almost done, just FYI.


it seems to work, but the error checking is incomplete.

But you can have something like this:

/{
                        north{
                                /config/("northbridge/intel/i440bxemulation");
                        };
};

The /config/ keyword (there has to be a better way to do keywords?) means:
suck in northbridge/intel/i440bxemulation/dts.
That file has a list of properties, well, currently only one:
 { dram = "no"; };

The "no" value for the dram property will provide a reasonable default
if the dram property is not spec'ed. A mainboard value can override
it. You probably want a number there.

The dtc generates the struct as described by the
northbridge/intel/i440bxemulation/dts file:
struct  north {
        u32 dram;
}; /*north*/
(i.e. this struct generation came ENTIRELY from the chip dts, and was
emitted by the device tree compiler (dtc))

and, as it generates the initializations, you see this:
struct  north {
        .dram = {0|(0x6e<<24)|(0x6f<<16)|(0x00<<8)},
}; /*north*/

i.e. you only get u32's at present and, until we're sure we need
something else, that's all you get. I hope people aren't going to
start asking for types ...

So you can spec that a chip dts is to be used; that chip dts will
cause a struct to be generated; the struct members in there can have a
default value, set for that chip; and, the defaults can be over-ridden
by mainboard settings.

Pretty much what we said we wanted, I think. But your Kconfig request
is not in there, as supporting it will require:
1) dtc pass
2) kconfig pass
3) dtc pass again

I think.

The changes are backwards-compatible; current qemu target builds just fine.

Peter, is this it?

I can generate a patch if people want to look at the code. I admit it
is rough, but gives us a starting point.

ron



From btrotter at gmail.com  Wed Jun 13 07:28:02 2007
From: btrotter at gmail.com (Brendan Trotter)
Date: Wed, 13 Jun 2007 05:28:02 +0000
Subject: [LinuxBIOS] Specifications
In-Reply-To: <466EED42.9060600@gmail.com>
References: <b1ebdcad0706112123w5372b7ecv6f76a913dc0b64e4@mail.gmail.com>
	<20070612074909.GA25127@coresystems.de>
	<b1ebdcad0706120343l7087881h5bd9981efab8e341@mail.gmail.com>
	<20070612113508.GA13122@coresystems.de>
	<b1ebdcad0706120751i517e8afdnb40cfb9d3570992d@mail.gmail.com>
	<466EED42.9060600@gmail.com>
Message-ID: <b1ebdcad0706122228r42d2ebf6m69bf6ad74c47920c@mail.gmail.com>

Hi,

On 6/12/07, Corey Osgood <corey.osgood at gmail.com> wrote:
> Brendan Trotter wrote:
> > On 6/12/07, Stefan Reinauer <stepan at coresystems.de> wrote:
> >
> >> * Brendan Trotter <btrotter at gmail.com> [070612 12:43]:
> >>
> >>>> check LinuxBIOSv2/util/lbtdump
> >>>>
> >>>  I've found "src/include/boot/linuxbios_tables.h" and have also looked
> >>>  at the source for LinuxBIOSv2/util/lbtdump.
> >>>
> >>>  However, I fail to see how any source code can be considered a viable
> >>>  alternative to documentation for something that is (hopefully) a
> >>>  non-proprietory common standard. Reverse engineering (including
> >>>  relying on assumptions derived from the source code of any specific
> >>>  implementation) is what people do when they have no documentation and
> >>>  are willing to stumble around in the dark hoping to implement
> >>>  something that works until the wind changes.
> >>>
> >> Yes, no doubt. You are perfectly right, and we are looking forward to
> >> your patches to fix this problem. Of course you do not have to reverse
> >> engineer, but just read the code, as we are non-proprietary. And of
> >> course we are always here to be asked.
> >>
> >
> > Hehe - by the time you've finished answering all my questions you'd
> > wish you'd written the documentation beforehand... ;-)
>
> Probably, but personally I'd rather see Stefan devote his time to the
> great work they're doing on v3 ;) I'll try to help a little, although my
> knowledge of the inner workings of LB is somewhat limited.

Thanks :-)

> > Is "uint32_t" always little-endian or is it architecture specific
> > (reverse engineering ruled out "always big-endian"),
>
> Yes, it should be dependent on the architecture
>
> > and would the
> > "lb_header.signature" field always have an ASCII 'L' at the lowest
> > address (or is that architecture specific too)?

I'll assume that also architecture dependant.

> no idea...
> > The source file "util/lbtdump/lbtdump.c" does this:
> >
> >               if (head->header_bytes != sizeof(*head)) {
> >                       fprintf(stderr, "Header bytes of %d are incorrect\n",
> >                               head->header_bytes);
> >                       continue;
> >               }
> >
> > >From this can I assume that the size of the LinuxBIOS Table header
> > will always be 24 bytes, and the LinuxBIOS Table header will never be
> > extended in the future (or is this just a bug that makes "lbtdump"
> > unable to handle forward/backward compatability)?
> >
> > The file "src/include/boot/linuxbios_tables.h" defines 3 types of memory ranges:
> >
> > #define LB_MEM_RAM       1    /* Memory anyone can use */
> > #define LB_MEM_RESERVED  2    /* Don't use this memory region */
> > #define LB_MEM_TABLE     16   /* Ram configuration tables are kept in */
> >
> > The file "util/lbtdump/lbtdump.c" doesn't agree:
> >
> >               switch(rec->map[i].type) {
> >               case 1: mem_type = "ram"; break;
> >               case 3: mem_type = "acpi"; break;
> >               case 4: mem_type = "nvs"; break;
> >               default:
> >               case 2: mem_type = "reserved"; break;
> >               }
> >
> > Can I assume that the defines in "linuxbios_tables.h" are out-of-date,
> > and that the memory type field is the same as specified by version 2
> > of the ACPI specification (but perhaps not version 3, as that defines
> > a new "5 = faulty RAM" type)? If "linuxbios_tables.h" is out-of-date,
> > is "16 = RAM configuration tables are stored in" still possible on
> > older versions of LinuxBIOS (and how would I detect which version of
> > LinuxBIOS is present, considering there's no version number in the
> > LinuxBIOS Table header)?
> >
> > What is the LB_TAG_HWRPB structure. Is it something to do with a
> > "Hardware Restart Parameter Block", and what does it contain? For e.g.
> > would a value of zero indicate that the computer was shutdown
> > correctly before boot, and a non-zero value indicate that the computer
> > crashed or had hardware problems?
>
> Again, no clue really..
>
> > Would I also be correct to assume that a payload doesn't need to care
> > about any of the "cmos_entries" and "cmos_enums", unless a BIOS
> > setup/configuration utility is being built into the payload?
> > Alternatively, could/would a payload search for strings to find CMOS
> > values (e.g. search for the cmos_entry with the name string
> > "power_on_after_fail" to see if additional hardware testing can be
> > skipped, search for "baud_rate" to determine the serial port
> > configuration, etc)?
>
> My *understanding* is that different vendors do different things with
> the cmos, so payloads couldn't count on them for the vendor bios, so
> they don't for linuxbios either. I suppose a payload *could* do this
> with linuxbios, if the project wanted to, but I can't think of any that
> does, although openbios may. Anything cmos-related, such as power on
> after fail, should currently be handled between linuxbios and a
> userspace utility, like lxbios.

I just think it'd be annoying for end-users if (for e.g.) the payload
decided to use the 28800 8N1 for serial communication when LinuxBIOS
is using 57600 8N1 because there was no way for the payload to
determine how LinuxBIOS is currently configured.

If LinuxBIOS told the payload "use the frambuffer, which is in ? * ?
mode at ?" or "use the serial port at ? at ? baud and ? protocol",
then the payload could seemlessly autodetect at run-time and continue
using the same method for text output that LinuxBIOS used. Without
this end-users would need to mess about with compile-time settings for
the payload, and possibly recompile the payload if CMOS settings are
changed after LinuxBIOS is installed.

> >> It is of course not unique. It is the index of the vendor name within
> >> the strings array of struct lb_mainboard. Since we're not trying to
> >> close things down, we don't have to work with magic numbers. So nothing
> >> needs to stay unique.
> >>
> >
> > Of course - it's similar to the way SMI/DMI does strings, yet are the
> > strings themselves guaranteed to be unique, or is it possible for one
> > manufacturer to use an identifying string in the future that another
> > (possibly out of business) manufacturer had used in the past?
>
> This is something google would be good for, I can't come up with a good
> answer. Yes, they SHOULD always be unique, given that there are 65536
> possible combinations, but whether there's some sort of registration or
> assignment system or it's at the manufacturers disposal, I don't know.

I'm not sure googling for the information about the strings the
LinuxBIOS project may or may not use in future for it's identifiers
would help, unless (for e.g.) the "payload hand-off specification"
explicitly states that the identifiers (if present) must be identical
to those used by SMI/DMI, in which case I could google for SMI/DMI
identifiers....

> > Motherboard manufacturer identification is one of the things that
> > (IMHO) should be unique. The motherboard part number string should
> > also be unique for that manufacturer ID. Otherwise it'd be difficult
> > for payloads/utilities/OSs to use these IDs to avoid any hardware
> > problems in specific motherboards.
> >
>
> Manufacturers are often very lax about this, in some cases motherboards
> have 5 or more different (subsystem) device IDs on the same board, or in
> others they don't bother setting most of them. This is one area where
> mainboard manufacturers need to clean up.
>
> >>>>> I assume there may also be ACPI, MP specification, PIRQ routing and/or
> >>>>> (possibly) SMI/DMI tables, and I'm guessing that (if present) these
> >>>>> tables can be searched for using the same methods as described in
> >>>>> their corresponding specifications.
> >>>>>
> >>>> They're not used by payloads (except the Linux kernel)
> >>>>
> >>>  Surely LinuxBIOS isn't intended as a "Linux only" BIOS though....
> >>>
> >> Of course not. ACPI is not really useful for payloads though, unless the
> >> payload wants to carry a full blown ACPI interpreter. Which rules out
> >> basically anything but an OS.
> >>
> >
> > I can think of a variety of uses, ranging from utilities that do
> > nothing more than display hardware information, to diagnostics, to
> > benchmarking, to hyper-visors, to full OSs...
> >
> >
> >>>>> - are AP CPUs started (or waiting for a SIPI sequence)?
> >>>>>
> >>>> yes, hardware is completely up when linuxbios is done.
> >>>>
> >>>  I tried it on a dual CPU Bochs emulation (second CPU was left in "wait
> >>>  for SIPI" state) - I'm guessing I need to enable multi-CPU support
> >>>  via. some compile time option for the "emulation/qemu-i386" target?
> >>>
> >> Yes, the emulation/qemu-i386 is per default not supporting SMP.
> >>
> >
> > I'm becoming skeptical here. I can't find anything in LinuxBIOS source
> > code that starts AP CPUs, but in "src/arch/i386/smp/mpspec.c" I did
> > find:
> >
> > /* If we assume a symmetric processor configuration we can
> >  * get all of the information we need to write the processor
> >  * entry from the bootstrap processor.
> >  * Plus I don't think linux really even cares.
> >  * Having the proper apicid's in the table so the non-bootstrap
> >  *  processors can be woken up should be enough.
> >  */
> >
> > It might be possible that no AP CPUs are ever started, and are instead
> > left in a "wait for SIPI" default state, assumed to be identical to
> > the BSP, and even assumed to be working (no BIST checks).
> >
> > AFAIK the normal approach is to send a broadcast INIT-SIPI sequence
> > and wait to see which AP CPUs start (if any), and then either record
> > details somewhere or have each AP CPU add itself to the MP
> > specification and ACPI tables, then setup their MTTRs, thermal
> > monitoring, HT links, SMBASE, etc before sending the APs back to the
> > "wait for SIPI" state - i.e. in theory it should be mostly
> > "configuration-less".
> >
> > In any case, I'm guessing I need to get LinuxBIOS to generate MP
> > specification and ACPI tables to suit the number of CPUs being
> > emulated by Bochs/Qemu. Is this as simple as adding something like
> > "option CPUs = ?" to the "targets/emulation/qemu-i386/Config.lb" file?
> > I'm guessing it's more involved than this, as I couldn't find an
> > example in the "Config.lb" of other targets.
> >
>
> Please check out the k8 code, especially init_cpus.c, I think you'll
> find what you're looking for there. Afaik, the k8 is the only
> smp-supported cpu for the moment.
>
> >
> >>>  Either:
> >>>  a) PCI buses and bridges aren't guaranteed to be enumerated, or
> >>>  b) PCI buses and bridges are guaranteed to be enumerated but PCI
> >>>  devices aren't guaranteed to be assigned resources, or
> >>>  c) PCI buses and bridges are guaranteed to be enumerated and PCI
> >>>  devices are guaranteed to have resources assigned (including ROMs)
> >>>  d) PCI buses and bridges are guaranteed to be enumerated and PCI
> >>>  devices are guaranteed to have resources assigned (except ROMs)
> >>>
> >>>  "They have their resources." would mean either c) or d), where each
> >>>  device may or may not be in a power saving state (if supported by the
> >>>  device), and may or may not be still configured to use MSI (if
> >>>  supported by the device)....
> >>>
> >> yes, either c or d. You choose.
> >
> > You mean all LinuxBIOS developers are willing to make sure all PCI
> > device ROMs either have physical addresses assigned or don't have
> > physical addresses assigned based on my advice? Perhaps I've
> > misunderstood... :-)
>
> I think I have too...

As far as I can tell, Stefan's "You choose." either implies that it's
my choice what LinuxBIOS developers do or that it's my choice how
end-users configure LinuxBIOS. I doubt I've got that much influence
with either group.

I'll assume that whether or not ROMs are assigned physical addresses,
whether or not device may be left in a power saving state, and whether
or not MSI may still be setup is all "undefined" - not guaranteed
either way.

> >>>> Not at the moment. But in General this is easy. If no VGA class PCI
> >>>> device is there, the machine is 99.99% headless.
> >>>>
> >>>  And if a VGA class PCI device is present, you've got no idea if no
> >>>  monitor is attached...
> >>>
> >> Obviously not. and if the device does not do EDD you have no reliable
> >> way of finding out either.
> >
> > There's a simple and easy way to find out if a monitor is attached or
> > not, and it doesn't involve messing about with EDD - simply give the
> > end-user the option of setting (or not setting) a value in the CMOS.
>
> This is already an option, to have vga you run the vga rom and send
> output to the monitor. Otherwise, you keep serial output and don't
> bother with the rom.

This is an option for end-users, but not something a payload can assume.

> > My (limited) reverse engineering has already shown that there's CMOS
> > entries for a serial port (possibly intended for setting up a serial
> > cable to communicate with a terminal emulator?).
>
> Why reverse engineer? The source code is openly available ;)

There is little practical difference between reverse engineering in
the traditional sense, and "reverse engineering" source code. In both
cases it tells you nothing about what is guaranteed and what is
coincedence (or what is incorrect behaviour), which values are valid
for different fields, or what may or may not be implemented in future
or past versions.


Thanks,

Brendan



From linuxoflondon at googlemail.com  Tue Jun 12 19:49:07 2007
From: linuxoflondon at googlemail.com (Bob CFC)
Date: Tue, 12 Jun 2007 18:49:07 +0100
Subject: [LinuxBIOS] dmidecode & lspci for new MSI P35 Platinum
	(Rollercoaster)
Message-ID: <90e180400706121049h736e6089qabcaba53a916c3b4@mail.gmail.com>

I read a post on a forum asking people to run these commands and post
the results here to support the LinuxBios project.

dmidecode
lspci -n
lspci -v
lspci -t


I have the new MSI P35 Platinum,
E6600 Core2Duo at stock speed,
8gb (4x2) DDR2 pc2-6400 cas5 at stock speed (OCZ2G8004GK),
Overclocked BFG Geforce 8800GTS 320mb
Single PATA drive on the Marvell chip and no SATA devices yet.
Running Ubuntu 7.04 (Feisty Fawn) x86_64.


Hope this helps.  Just ask if there is anything else that you need.

Bob,
London
-------------- next part --------------
# dmidecode 2.8
SMBIOS 2.5 present.
27 structures occupying 1379 bytes.
Table at 0x000FBC70.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: American Megatrends Inc.
	Version: V1.0BD
	Release Date: 04/23/2007
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 1024 kB
	Characteristics:
		ISA is supported
		PCI is supported
		PNP is supported
		APM is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		ESCD support is available
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 KB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		LS-120 boot is supported
		ATAPI Zip drive boot is supported
		BIOS boot specification is supported
		Targeted content distribution is supported
	BIOS Revision: 8.14

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: MICRO-STAR INTERNATIONAL CO.,LTD
	Product Name: MS-7345
	Version: 1.1
	Serial Number: To Be Filled By O.E.M.
	UUID: Not Present
	Wake-up Type: Power Switch
	SKU Number: To Be Filled By O.E.M.
	Family: To Be Filled By O.E.M.

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: MICRO-STAR INTERNATIONAL CO.,LTD
	Product Name: MS-7345
	Version: 1.1
	Serial Number: To be filled by O.E.M.
	Asset Tag: To Be Filled By O.E.M.
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: To Be Filled By O.E.M.
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
	Manufacturer: MICRO-STAR INTERNATIONAL CO.,LTD
	Type: Desktop
	Lock: Not Present
	Version: 1.1
	Serial Number: To Be Filled By O.E.M.
	Asset Tag: To Be Filled By O.E.M.
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Heigth: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 0

Handle 0x0004, DMI type 4, 40 bytes
Processor Information
	Socket Designation: CPU 1
	Type: Central Processor
	Family: <OUT OF SPEC>
	Manufacturer: Intel            
	ID: F6 06 00 00 FF FB EB BF
	Version: Intel(R) Core(TM)2 CPU          6600  @ 2.40GHz     
	Voltage: 1.3 V
	External Clock: 267 MHz
	Max Speed: 2400 MHz
	Current Speed: 2403 MHz
	Status: Populated, Enabled
	Upgrade: Other
	L1 Cache Handle: 0x0005
	L2 Cache Handle: 0x0006
	L3 Cache Handle: 0x0007
	Serial Number: To Be Filled By O.E.M.
	Asset Tag: To Be Filled By O.E.M.
	Part Number: To Be Filled By O.E.M.

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1-Cache
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 64 KB
	Maximum Size: 64 KB
	Supported SRAM Types:
		Other
	Installed SRAM Type: Other
	Speed: Unknown
	Error Correction Type: Parity
	System Type: Data
	Associativity: 8-way Set-associative

Handle 0x0006, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L2-Cache
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 4096 KB
	Maximum Size: 4096 KB
	Supported SRAM Types:
		Other
	Installed SRAM Type: Other
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Instruction
	Associativity: 8-way Set-associative

Handle 0x0007, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L3-Cache
	Configuration: Disabled, Not Socketed, Level 3
	Operational Mode: Unknown
	Location: Internal
	Installed Size: 0 KB
	Maximum Size: 0 KB
	Supported SRAM Types:
		Unknown
	Installed SRAM Type: Unknown
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Unknown
	Associativity: Unknown

Handle 0x0008, DMI type 5, 24 bytes
Memory Controller Information
	Error Detecting Method: 64-bit ECC
	Error Correcting Capabilities:
		None
	Supported Interleave: One-way Interleave
	Current Interleave: One-way Interleave
	Maximum Memory Module Size: 4096 MB
	Maximum Total Memory Size: 16384 MB
	Supported Speeds:
		Other
	Supported Memory Types:
		DIMM
		SDRAM
	Memory Module Voltage: 3.3 V
	Associated Memory Slots: 4
		0x0009
		0x000A
		0x000B
		0x000C
	Enabled Error Correcting Capabilities:
		None

Handle 0x0009, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: DIMM0
	Bank Connections: 0 1
	Current Speed: Unknown
	Type: DIMM SDRAM
	Installed Size: 2048 MB (Double-bank Connection)
	Enabled Size: 2048 MB (Double-bank Connection)
	Error Status: OK

Handle 0x000A, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: DIMM1
	Bank Connections: 2 3
	Current Speed: Unknown
	Type: DIMM SDRAM
	Installed Size: 2048 MB (Double-bank Connection)
	Enabled Size: 2048 MB (Double-bank Connection)
	Error Status: OK

Handle 0x000B, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: DIMM2
	Bank Connections: 4 5
	Current Speed: Unknown
	Type: DIMM SDRAM
	Installed Size: 2048 MB (Double-bank Connection)
	Enabled Size: 2048 MB (Double-bank Connection)
	Error Status: OK

Handle 0x000C, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: DIMM3
	Bank Connections: 6 7
	Current Speed: Unknown
	Type: DIMM SDRAM
	Installed Size: 2048 MB (Double-bank Connection)
	Enabled Size: 2048 MB (Double-bank Connection)
	Error Status: OK

Handle 0x000D, DMI type 13, 22 bytes
BIOS Language Information
	Installable Languages: 1
		en|US|iso8859-1
	Currently Installed Language: en|US|iso8859-1

Handle 0x000E, DMI type 15, 35 bytes
System Event Log
	Area Length: 4 bytes
	Header Start Offset: 0x0000
	Header Length: 2 bytes
	Data Start Offset: 0x0002
	Access Method: Indexed I/O, one 16-bit index port, one 8-bit data port
	Access Address: Index 0x046A, Data 0x046C
	Status: Invalid, Not Full
	Change Token: 0x00000000
	Header Format: No Header
	Supported Log Type Descriptors: 6
	Descriptor 1: End of log
	Data Format 1: OEM-specific
	Descriptor 2: End of log
	Data Format 2: OEM-specific
	Descriptor 3: End of log
	Data Format 3: OEM-specific
	Descriptor 4: End of log
	Data Format 4: OEM-specific
	Descriptor 5: End of log
	Data Format 5: OEM-specific
	Descriptor 6: End of log
	Data Format 6: OEM-specific

Handle 0x000F, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 4 GB
	Error Information Handle: Not Provided
	Number Of Devices: 4

Handle 0x0010, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 8 GB
	Physical Array Handle: 0x000F
	Partition Width: 0

Handle 0x0011, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x000F
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM0
	Bank Locator: BANK0
	Type: SDRAM
	Type Detail: Synchronous
	Speed: Unknown
	Manufacturer: Manufacturer0
	Serial Number: SerNum0
	Asset Tag: AssetTagNum0
	Part Number: PartNum0

Handle 0x0012, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0007FFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0011
	Memory Array Mapped Address Handle: 0x0010
	Partition Row Position: 1
	Interleaved Data Depth: 1

Handle 0x0013, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x000F
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM1
	Bank Locator: BANK1
	Type: SDRAM
	Type Detail: Synchronous
	Speed: Unknown
	Manufacturer: Manufacturer1
	Serial Number: SerNum1
	Asset Tag: AssetTagNum1
	Part Number: PartNum1

Handle 0x0014, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00080000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0013
	Memory Array Mapped Address Handle: 0x0010
	Partition Row Position: 1
	Interleaved Data Depth: 1

Handle 0x0015, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x000F
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM2
	Bank Locator: BANK2
	Type: SDRAM
	Type Detail: Synchronous
	Speed: Unknown
	Manufacturer: Manufacturer2
	Serial Number: SerNum2
	Asset Tag: AssetTagNum2
	Part Number: PartNum2

Handle 0x0016, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00100000000
	Ending Address: 0x0017FFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0015
	Memory Array Mapped Address Handle: 0x0010
	Partition Row Position: 1
	Interleaved Data Depth: 1

Handle 0x0017, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x000F
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM3
	Bank Locator: BANK3
	Type: SDRAM
	Type Detail: Synchronous
	Speed: Unknown
	Manufacturer: Manufacturer3
	Serial Number: SerNum3
	Asset Tag: AssetTagNum3
	Part Number: PartNum3

Handle 0x0018, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00180000000
	Ending Address: 0x001FFFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0017
	Memory Array Mapped Address Handle: 0x0010
	Partition Row Position: 1
	Interleaved Data Depth: 1

Handle 0x0019, DMI type 32, 20 bytes
System Boot Information
	Status: No errors detected

Handle 0x001A, DMI type 127, 4 bytes
End Of Table

-------------- next part --------------
00:00.0 0600: 8086:29c0 (rev 02)
00:01.0 0604: 8086:29c1 (rev 02)
00:1a.0 0c03: 8086:2937 (rev 02)
00:1a.1 0c03: 8086:2938 (rev 02)
00:1a.7 0c03: 8086:293c (rev 02)
00:1b.0 0403: 8086:293e (rev 02)
00:1c.0 0604: 8086:2940 (rev 02)
00:1c.4 0604: 8086:2948 (rev 02)
00:1c.5 0604: 8086:294a (rev 02)
00:1d.0 0c03: 8086:2934 (rev 02)
00:1d.1 0c03: 8086:2935 (rev 02)
00:1d.2 0c03: 8086:2936 (rev 02)
00:1d.3 0c03: 8086:2939 (rev 02)
00:1d.7 0c03: 8086:293a (rev 02)
00:1e.0 0604: 8086:244e (rev 92)
00:1f.0 0601: 8086:2916 (rev 02)
00:1f.2 0106: 8086:2922 (rev 02)
00:1f.3 0c05: 8086:2930 (rev 02)
01:00.0 0300: 10de:0193 (rev a2)
03:00.0 0101: 11ab:6121 (rev b1)
04:00.0 0200: 10ec:8168 (rev 01)
05:02.0 0c00: 1106:3044 (rev c0)
-------------- next part --------------
-[0000:00]-+-00.0
           +-01.0-[0000:01]----00.0
           +-1a.0
           +-1a.1
           +-1a.7
           +-1b.0
           +-1c.0-[0000:02]--
           +-1c.4-[0000:03]----00.0
           +-1c.5-[0000:04]----00.0
           +-1d.0
           +-1d.1
           +-1d.2
           +-1d.3
           +-1d.7
           +-1e.0-[0000:05]----02.0
           +-1f.0
           +-1f.2
           \-1f.3
-------------- next part --------------
00:00.0 Host bridge: Intel Corporation Unknown device 29c0 (rev 02)
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, fast devsel, latency 0
	Capabilities: [e0] Vendor Specific Information

00:01.0 PCI bridge: Intel Corporation Unknown device 29c1 (rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: fa000000-fe8fffff
	Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff
	Capabilities: [88] Subsystem: Intel Corporation Unknown device 0000
	Capabilities: [80] Power Management version 3
	Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
	Capabilities: [a0] Express Root Port (Slot+) IRQ 0

00:1a.0 USB Controller: Intel Corporation Unknown device 2937 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, medium devsel, latency 0, IRQ 16
	I/O ports at ac00 [size=32]
	Capabilities: [50] Vendor Specific Information

00:1a.1 USB Controller: Intel Corporation Unknown device 2938 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, medium devsel, latency 0, IRQ 21
	I/O ports at a880 [size=32]
	Capabilities: [50] Vendor Specific Information

00:1a.7 USB Controller: Intel Corporation Unknown device 293c (rev 02) (prog-if 20 [EHCI])
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, medium devsel, latency 0, IRQ 18
	Memory at f9fffc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
	Capabilities: [58] Debug port
	Capabilities: [98] Vendor Specific Information

00:1b.0 Audio device: Intel Corporation Unknown device 293e (rev 02)
	Subsystem: Micro-Star International Co., Ltd. Unknown device 735a
	Flags: bus master, fast devsel, latency 0, IRQ 22
	Memory at f9ff8000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
	Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
	Capabilities: [70] Express Unknown type IRQ 0

00:1c.0 PCI bridge: Intel Corporation Unknown device 2940 (rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	Capabilities: [40] Express Root Port (Slot+) IRQ 0
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
	Capabilities: [90] Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Capabilities: [a0] Power Management version 2

00:1c.4 PCI bridge: Intel Corporation Unknown device 2948 (rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: fe900000-fe9fffff
	Capabilities: [40] Express Root Port (Slot+) IRQ 0
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
	Capabilities: [90] Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Capabilities: [a0] Power Management version 2

00:1c.5 PCI bridge: Intel Corporation Unknown device 294a (rev 02) (prog-if 00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: fea00000-feafffff
	Capabilities: [40] Express Root Port (Slot+) IRQ 0
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
	Capabilities: [90] Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Capabilities: [a0] Power Management version 2

00:1d.0 USB Controller: Intel Corporation Unknown device 2934 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, medium devsel, latency 0, IRQ 23
	I/O ports at a800 [size=32]
	Capabilities: [50] Vendor Specific Information

00:1d.1 USB Controller: Intel Corporation Unknown device 2935 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, medium devsel, latency 0, IRQ 19
	I/O ports at a480 [size=32]
	Capabilities: [50] Vendor Specific Information

00:1d.2 USB Controller: Intel Corporation Unknown device 2936 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, medium devsel, latency 0, IRQ 18
	I/O ports at a400 [size=32]
	Capabilities: [50] Vendor Specific Information

00:1d.3 USB Controller: Intel Corporation Unknown device 2939 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, medium devsel, latency 0, IRQ 16
	I/O ports at a080 [size=32]
	Capabilities: [50] Vendor Specific Information

00:1d.7 USB Controller: Intel Corporation Unknown device 293a (rev 02) (prog-if 20 [EHCI])
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, medium devsel, latency 0, IRQ 23
	Memory at f9fff800 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
	Capabilities: [58] Debug port
	Capabilities: [98] Vendor Specific Information

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) (prog-if 01 [Subtractive decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=32
	I/O behind bridge: 0000e000-0000efff
	Memory behind bridge: feb00000-febfffff
	Capabilities: [50] Subsystem: Micro-Star International Co., Ltd. Unknown device 7345

00:1f.0 ISA bridge: Intel Corporation Unknown device 2916 (rev 02)
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, medium devsel, latency 0
	Capabilities: [e0] Vendor Specific Information

00:1f.2 SATA controller: Intel Corporation Unknown device 2922 (rev 02) (prog-if 01 [AHCI 1.0])
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 19
	I/O ports at a000 [size=8]
	I/O ports at 9c00 [size=4]
	I/O ports at 9880 [size=8]
	I/O ports at 9800 [size=4]
	I/O ports at 9480 [size=32]
	Memory at f9fff000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4 Enable-
	Capabilities: [70] Power Management version 3
	Capabilities: [a8] #12 [0010]
	Capabilities: [b0] Vendor Specific Information

00:1f.3 SMBus: Intel Corporation Unknown device 2930 (rev 02)
	Subsystem: Micro-Star International Co., Ltd. Unknown device 7345
	Flags: medium devsel, IRQ 11
	Memory at f9ffec00 (64-bit, non-prefetchable) [size=256]
	I/O ports at 0400 [size=32]

01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0193 (rev a2) (prog-if 00 [VGA])
	Subsystem: Unknown device 19f1:040f
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
	Memory at d0000000 (64-bit, prefetchable) [size=256M]
	Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
	I/O ports at bc00 [size=128]
	[virtual] Expansion ROM at fe8e0000 [disabled] [size=128K]
	Capabilities: [60] Power Management version 2
	Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
	Capabilities: [78] Express Endpoint IRQ 0

03:00.0 IDE interface: Marvell Technology Group Ltd. Unknown device 6121 (rev b1) (prog-if 8f [Master SecP SecO PriP PriO])
	Subsystem: Marvell Technology Group Ltd. Unknown device 6121
	Flags: bus master, fast devsel, latency 0, IRQ 16
	I/O ports at cc00 [size=8]
	I/O ports at c880 [size=4]
	I/O ports at c800 [size=8]
	I/O ports at c480 [size=4]
	I/O ports at c400 [size=16]
	Memory at fe9ffc00 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [48] Power Management version 2
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
	Capabilities: [e0] Express Legacy Endpoint IRQ 0

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
	Subsystem: Micro-Star International Co., Ltd. Unknown device 345c
	Flags: bus master, fast devsel, latency 0, IRQ 17
	I/O ports at d800 [size=256]
	Memory at feaff000 (64-bit, non-prefetchable) [size=4K]
	Expansion ROM at feac0000 [disabled] [size=128K]
	Capabilities: [40] Power Management version 2
	Capabilities: [48] Vital Product Data
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable-
	Capabilities: [60] Express Endpoint IRQ 0
	Capabilities: [84] Vendor Specific Information

05:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev c0) (prog-if 10 [OHCI])
	Subsystem: Micro-Star International Co., Ltd. Unknown device 345d
	Flags: bus master, medium devsel, latency 64, IRQ 18
	Memory at febff800 (32-bit, non-prefetchable) [size=2K]
	I/O ports at ec00 [size=128]
	Capabilities: [50] Power Management version 2


From ryven at ryven.de  Wed Jun 13 08:07:53 2007
From: ryven at ryven.de (Markus)
Date: Wed, 13 Jun 2007 06:07:53 +0000
Subject: [LinuxBIOS] EPIA hang after patch
In-Reply-To: <466EEA28.2000101@hewson-venieri.com>
References: <19634852.109631181634527829.JavaMail.servlet@kundenserver>
	<20070612192453.3519cb4f@PXE-Image>
	<466EEA28.2000101@hewson-venieri.com>
Message-ID: <20070613060753.4d3c7e9e@PXE-Image>

Am Tue, 12 Jun 2007 19:47:04 +0100
schrieb Ben Hewson <ben at hewson-venieri.com>:

> Markus wrote:
> > Am Tue, 12 Jun 2007 09:48:47 +0200
> > schrieb ben at hewson-venieri.co.uk:
> > The Epia V has only one SD-Ram Slot.
> > And badly is like "only" Infineon Chips. :-(
> >
> >   
> 
> if that is the case then there is a problem with the ram init I think.
> 
> Slot 00 is SDRAM 10000000 bytes
> 000e is the MA type
> Slot 01 is SDRAM 08000000 bytes x2
> 000c is the MA type
> 
> 
> Ben
> 
An Boot with the Via Bios runs? Did memtest dedecet any errors?
In case was the trouble, that the epia doesn't boot or dedect the ram
not correct.

Markus



From stuge-linuxbios at cdy.org  Wed Jun 13 11:08:58 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 13 Jun 2007 11:08:58 +0200
Subject: [LinuxBIOS] MC struct
In-Reply-To: <13426df10706122137p36dbd21bx351ca6368f48081b@mail.gmail.com>
References: <20070607173727.19844.qmail@cdy.org>
	<13426df10706071045n56ba631asb20fe58555395ab8@mail.gmail.com>
	<20070607175536.23359.qmail@cdy.org>
	<20070607181457.GB11362@coresystems.de>
	<20070607182524.29971.qmail@cdy.org>
	<13426df10706122118n66227050s94c78fa1942beb71@mail.gmail.com>
	<13426df10706122137p36dbd21bx351ca6368f48081b@mail.gmail.com>
Message-ID: <20070613090858.6609.qmail@cdy.org>

On Tue, Jun 12, 2007 at 09:37:27PM -0700, ron minnich wrote:
> On 6/12/07, ron minnich <rminnich at gmail.com> wrote:
> > On 6/7/07, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
> > > A device tree (not list) in code that
> > > * is seeded by the mainboard dts, which lists all devices
> > > * has device options set from defaults in device dts
> > > * has device option overrides from mainboard dts
> >
> > I have this almost done, just FYI.
> 
> it seems to work, but the error checking is incomplete.

Awesome! Really great work!


[..]

> Pretty much what we said we wanted, I think.

Yes indeed.


> But your Kconfig request is not in there, as supporting it will
> require:
> 
> 1) dtc pass
> 2) kconfig pass
> 3) dtc pass again
> 
> I think.

2 is user doing make *config, right?

Hmm - why the second dtc pass?
Maybe it could be run from the Makefile automatically?


> The changes are backwards-compatible; current qemu target builds
> just fine.
> 
> Peter, is this it?

I think so!


> I can generate a patch if people want to look at the code. I admit
> it is rough, but gives us a starting point.

I'd love to take a look at it!


//Peter



From stuge-linuxbios at cdy.org  Wed Jun 13 11:27:50 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed, 13 Jun 2007 11:27:50 +0200
Subject: [LinuxBIOS] Specifications
In-Reply-To: <b1ebdcad0706122228r42d2ebf6m69bf6ad74c47920c@mail.gmail.com>
References: <b1ebdcad0706112123w5372b7ecv6f76a913dc0b64e4@mail.gmail.com>
	<20070612074909.GA25127@coresystems.de>
	<b1ebdcad0706120343l7087881h5bd9981efab8e341@mail.gmail.com>
	<20070612113508.GA13122@coresystems.de>
	<b1ebdcad0706120751i517e8afdnb40cfb9d3570992d@mail.gmail.com>
	<466EED42.9060600@gmail.com>
	<b1ebdcad0706122228r42d2ebf6m69bf6ad74c47920c@mail.gmail.com>
Message-ID: <20070613092750.10250.qmail@cdy.org>

On Wed, Jun 13, 2007 at 05:28:02AM +0000, Brendan Trotter wrote:
> I just think it'd be annoying for end-users if (for e.g.) the
> payload decided to use the 28800 8N1 for serial communication when
> LinuxBIOS is using 57600 8N1 because there was no way for the
> payload to determine how LinuxBIOS is currently configured.

It can just not set up the serial port but use it immediately and it
will keep the settings that LinuxBIOS used.

Granted, which one to choose must still be specified in the payload.


> As far as I can tell, Stefan's "You choose." either implies that
> it's my choice what LinuxBIOS developers do or that it's my choice
> how end-users configure LinuxBIOS. I doubt I've got that much
> influence with either group.

You would be surprised how receptive and tolerant this group of
people is. Ron even writes code the way I want if I nag him enough.
(Hi, Ron! :)

I think what Stefan wanted to say was that LinuxBIOS behavior is
rather configurable and the person building it gets to decide many of
the things you're asking about.


> I'll assume that whether or not ROMs are assigned physical
> addresses, whether or not device may be left in a power saving
> state, and whether or not MSI may still be setup is all "undefined"
> - not guaranteed either way.

I think this is belittling the effort in this project to initialize
hardware.


> > > There's a simple and easy way to find out if a monitor is
> > > attached or not, and it doesn't involve messing about with EDD
> > > - simply give the end-user the option of setting (or not
> > > setting) a value in the CMOS.

It depends. This is not workable unless there actually is an
end-user. It's also not workable unless said end-user is actually the
system administrator. LB was initially designed to explicitly not
have much user interaction and certainly not at boot time. A few
settings are available, but the idea is to always boot the OS
regardless.


> > This is already an option, to have vga you run the vga rom and
> > send output to the monitor. Otherwise, you keep serial output and
> > don't bother with the rom.
> 
> This is an option for end-users, but not something a payload can
> assume.

Watch out there. CMOS VGA/SERIAL is also an option for end-users, but
not something a (robust) payload will want to assume.


> > > My (limited) reverse engineering has already shown that there's
> > > CMOS entries for a serial port (possibly intended for setting
> > > up a serial cable to communicate with a terminal emulator?).
> >
> > Why reverse engineer? The source code is openly available ;)
> 
> There is little practical difference between reverse engineering in
> the traditional sense, and "reverse engineering" source code.

This depends a lot on the source code IMHO.


> In both cases it tells you nothing about what is guaranteed and
> what is coincedence (or what is incorrect behaviour), which values
> are valid for different fields, or what may or may not be
> implemented in future or past versions.

The code may not, but comments may, and discussion will.

I find that getting "into" open source projects is by far the best
way to learn how they think. Documenting the train of thought is IMHO
not worthwhile (although for new developers it would be nice) until
the code itself actually becomes rather high quality. It's better to
write code.

You are right that LB could have more and better documentation but
there is already a good amount available. There has not yet been much
demand for the kind of documentation you are asking for but perhaps
you can help us improve.

Meanwhile just talking to us will get you far.

(Please don't forget to read COPYING if you haven't already, though.)


//Peter



From ben at hewson-venieri.com  Wed Jun 13 14:15:03 2007
From: ben at hewson-venieri.com (Ben Hewson)
Date: Wed, 13 Jun 2007 13:15:03 +0100
Subject: [LinuxBIOS] Strange reset loading linux on epia! was "EPIA hang
 after patch"
In-Reply-To: <20070612232631.GB12600@greenwood>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
	<20070612232631.GB12600@greenwood>
Message-ID: <466FDFC7.1030108@hewson-venieri.com>

Uwe Hermann wrote:
> On Tue, Jun 12, 2007 at 06:56:46PM +0200, Thomas Ekstrand wrote:
>   
>> I got passed it! seemed to be a buggy flash and/or burn. The vt8231 is
>> working with flashrom, except for the verify :/
>> Anyway I rebuilt and reflashed it and now it almost works.
>> I get an immediate reset during linux startup I have no Idea what
>> might cause it. I've attached the serial output
>>     
>
> This looks like the culprit:
>
> 0000:00:11.4: base address not set -                             upgrade BIOS or use force_addr=0xaddr
>
> What is 00:11.4?
>
>   
11.4 is acpi so unless my testing patch posted here last week was 
applied, there should be no acpi tables for the kernel.  At the start it 
says acpi interpreter is disabled.


 From the linux log it looks like the reset happen while doing agp 
stuff, which wont be initialised

shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA Apollo ProMedia/PLE133Ta chipset


LinuxBIOS-2.0.0.0Fallback Tue Jun 12 18:21:53 CEST 2007 starting...

Ben





From myles at pel.cs.byu.edu  Wed Jun 13 16:39:42 2007
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Wed, 13 Jun 2007 08:39:42 -0600
Subject: [LinuxBIOS] Opteron caching of device memory
Message-ID: <000001c7adc8$add80b70$4d22040a@chimp>

I'm using LinuxBIOS on my Tyan s2892.  I have a device that maps a lot of
the memory space, but I'm struggling trying to get the Opteron to read and
write to my device in larger blocks.  I have set the variable MTRRs in the
device driver to writeback (witnessed by /proc/mtrr), but I still get 64-bit
accesses instead of 64-byte (cache line).

 

Any suggestions?

 

Thanks,

Myles

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

From yinghailu at gmail.com  Wed Jun 13 18:21:01 2007
From: yinghailu at gmail.com (yhlu)
Date: Wed, 13 Jun 2007 09:21:01 -0700
Subject: [LinuxBIOS] Opteron caching of device memory
In-Reply-To: <000001c7adc8$add80b70$4d22040a@chimp>
References: <000001c7adc8$add80b70$4d22040a@chimp>
Message-ID: <2ea3fae10706130921w3317cddw4a11c485511f314c@mail.gmail.com>

On 6/13/07, Myles Watson <myles at pel.cs.byu.edu> wrote:
>
>
>
>
> I'm using LinuxBIOS on my Tyan s2892.  I have a device that maps a lot of
> the memory space, but I'm struggling trying to get the Opteron to read and
> write to my device in larger blocks.  I have set the variable MTRRs in the
> device driver to writeback (witnessed by /proc/mtrr), but I still get 64-bit
> accesses instead of 64-byte (cache line).

wirte-back or write-combining?

YH



From myles at pel.cs.byu.edu  Wed Jun 13 18:48:51 2007
From: myles at pel.cs.byu.edu (Myles Watson)
Date: Wed, 13 Jun 2007 10:48:51 -0600
Subject: [LinuxBIOS] Opteron caching of device memory
In-Reply-To: <2ea3fae10706130921w3317cddw4a11c485511f314c@mail.gmail.com>
References: <000001c7adc8$add80b70$4d22040a@chimp>
	<2ea3fae10706130921w3317cddw4a11c485511f314c@mail.gmail.com>
Message-ID: <002101c7adda$b8d2ffa0$4d22040a@chimp>

> On 6/13/07, Myles Watson <myles at pel.cs.byu.edu> wrote:
> > I'm using LinuxBIOS on my Tyan s2892.  I have a device that maps a lot
> > of the memory space, but I'm struggling trying to get the Opteron to
> > read and write to my device in larger blocks.  I have set the variable 
> > MTRRs in the device driver to writeback (witnessed by /proc/mtrr), but I

> > still get 64-bit accesses instead of 64-byte (cache line).
> 
> wirte-back or write-combining?
> 
> YH

I did write-back, because I would like it to be treated as much like DRAM as
possible.

Myles





From hawke at hawkesnest.net  Wed Jun 13 19:32:47 2007
From: hawke at hawkesnest.net (Alex Mauer)
Date: Wed, 13 Jun 2007 12:32:47 -0500
Subject: [LinuxBIOS] Strange reset loading linux on epia! was "EPIA hang
	after patch"
In-Reply-To: <466FDFC7.1030108@hewson-venieri.com>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>	<20070612232631.GB12600@greenwood>
	<466FDFC7.1030108@hewson-venieri.com>
Message-ID: <f4p9og$tt1$1@sea.gmane.org>

Ben Hewson wrote:
>  From the linux log it looks like the reset happen while doing agp 
> stuff, which wont be initialised

This happens to me as well, I worked around it by blacklisting the
via_agp kernel module (and I think the agpgart module, don't remember)

I'll add a note to the wiki about that.

-Alex Mauer "hawke"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070613/08484699/attachment.sig>

From thomas.ekstrand at gmail.com  Wed Jun 13 20:32:39 2007
From: thomas.ekstrand at gmail.com (Thomas Ekstrand)
Date: Wed, 13 Jun 2007 20:32:39 +0200
Subject: [LinuxBIOS] Strange reset loading linux on epia! was "EPIA hang
	after patch"
In-Reply-To: <f4p9og$tt1$1@sea.gmane.org>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
	<20070612232631.GB12600@greenwood>
	<466FDFC7.1030108@hewson-venieri.com> <f4p9og$tt1$1@sea.gmane.org>
Message-ID: <f7085c470706131132u742b8f7axebf675808f488dc1@mail.gmail.com>

That was the problem! Once I've blacklisted the module it comes up
like it should.

Thanks for all your help!
/Thomas

2007/6/13, Alex Mauer <hawke at hawkesnest.net>:
> Ben Hewson wrote:
> >  From the linux log it looks like the reset happen while doing agp
> > stuff, which wont be initialised
>
> This happens to me as well, I worked around it by blacklisting the
> via_agp kernel module (and I think the agpgart module, don't remember)
>
> I'll add a note to the wiki about that.
>
> -Alex Mauer "hawke"
>
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>
>



From thomas.ekstrand at gmail.com  Wed Jun 13 20:37:00 2007
From: thomas.ekstrand at gmail.com (Thomas Ekstrand)
Date: Wed, 13 Jun 2007 20:37:00 +0200
Subject: [LinuxBIOS] buggy burn with uniflash ? (was "EPIA hang after
	patch")
In-Reply-To: <20070612175511.GA3652@bloms.de>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
	<20070612175511.GA3652@bloms.de>
Message-ID: <f7085c470706131137p30e8d8c2n933156c1fe9f48d2@mail.gmail.com>

That would depend on what kind of problem you have... ?
Funny! I am prone to flashrom because uniflash won't do my board :P

/Thomas

2007/6/12, Dieter Bloms <dieter at bloms.de>:
> Hi,
>
> On Tue, Jun 12, Thomas Ekstrand wrote:
>
> > I got passed it! seemed to be a buggy flash and/or burn. The vt8231 is
> > working with flashrom, except for the verify :/
>
> may this be my problem, too ?
> I use uniflash (http://www.uniflash.org/), because flashrom doesn't burn
> my flash ...
>
>
> --
> Gru?
>
>   Dieter
>
> --
> I do not get viruses because I do not use MS software.
> If you use Outlook then please do not put my email address in your
> address-book so that WHEN you get a virus it won't use my address in the
> From field.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGbt3++xZgAwaK6mMRAm6TAKCPqNFMpTc9vfSdNkJXWPFnFPl0OwCfbRUI
> w1vv5eDGY6zgQU+DDMvy34o=
> =Zvgj
> -----END PGP SIGNATURE-----
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>



From linuxbios at bloms.de  Wed Jun 13 22:00:26 2007
From: linuxbios at bloms.de (Dieter Bloms)
Date: Wed, 13 Jun 2007 22:00:26 +0200
Subject: [LinuxBIOS] buggy burn with uniflash ? (was "EPIA hang after
	patch")
In-Reply-To: <f7085c470706131137p30e8d8c2n933156c1fe9f48d2@mail.gmail.com>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
	<20070612175511.GA3652@bloms.de>
	<f7085c470706131137p30e8d8c2n933156c1fe9f48d2@mail.gmail.com>
Message-ID: <20070613200026.GA4302@bloms.de>

Hi,

On Wed, Jun 13, Thomas Ekstrand wrote:

> That would depend on what kind of problem you have... ?
> Funny! I am prone to flashrom because uniflash won't do my board :P

my problem is, that I can't see anything on serial console.
When I boot linux I can login via serial console with 115200,8N1


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070613/a259a763/attachment.sig>

From corey.osgood at gmail.com  Wed Jun 13 23:15:27 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Wed, 13 Jun 2007 17:15:27 -0400
Subject: [LinuxBIOS] buggy burn with uniflash ? (was "EPIA hang after
 patch")
In-Reply-To: <20070613200026.GA4302@bloms.de>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>	<20070612175511.GA3652@bloms.de>	<f7085c470706131137p30e8d8c2n933156c1fe9f48d2@mail.gmail.com>
	<20070613200026.GA4302@bloms.de>
Message-ID: <46705E6F.6090103@gmail.com>

Dieter Bloms wrote:
> Hi,
>
> On Wed, Jun 13, Thomas Ekstrand wrote:
>
>   
>> That would depend on what kind of problem you have... ?
>> Funny! I am prone to flashrom because uniflash won't do my board :P
>>     
>
> my problem is, that I can't see anything on serial console.
>   

Are you sure that the serial console is set up correctly, both in
Options.lb and the early serial code? And you don't have vga console
enabled, right?

> When I boot linux I can login via serial console with 115200,8N1

When booting the factory bios or linuxbios?

-Corey



From corey.osgood at gmail.com  Wed Jun 13 23:23:46 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Wed, 13 Jun 2007 17:23:46 -0400
Subject: [LinuxBIOS] [PATCH] Add Asus MEW-VM, Intel i82810,
	and generic i82801
Message-ID: <46706062.1070605@gmail.com>

See attached patch. Thanks for all the great comments and suggestions!

-Corey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asus_mew.patch
Type: text/x-patch
Size: 77627 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070613/0a4fab51/attachment.patch>

From marc.jones at amd.com  Thu Jun 14 02:09:53 2007
From: marc.jones at amd.com (Marc Jones)
Date: Wed, 13 Jun 2007 18:09:53 -0600
Subject: [LinuxBIOS] [PATCH] Geode LX CAS setting fix
Message-ID: <46708751.9000800@amd.com>

See attached patch.
Thanks!
Marc

-- 
Marc Jones
Senior Software Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: geodelx_mem_cas_fix.patch
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070613/4bf4cfeb/attachment.ksh>

From rminnich at gmail.com  Thu Jun 14 02:51:27 2007
From: rminnich at gmail.com (ron minnich)
Date: Wed, 13 Jun 2007 17:51:27 -0700
Subject: [LinuxBIOS] [PATCH] Geode LX CAS setting fix
In-Reply-To: <46708751.9000800@amd.com>
References: <46708751.9000800@amd.com>
Message-ID: <13426df10706131751i7e370canc4a561daf22e8114@mail.gmail.com>

Acked-by: Ronald G. Minnich <rminnich at gmail.com>

Note: I have not tested this on hardware. But I can bet Marc has :-)
This just convinces me that DRAM really is black magic :-)

On 6/13/07, Marc Jones <marc.jones at amd.com> wrote:
> See attached patch.
> Thanks!
> Marc
>
> --
> Marc Jones
> Senior Software Engineer
> (970) 226-9684 Office
> mailto:Marc.Jones at amd.com
> http://www.amd.com/embeddedprocessors
>
> This patch fixes the CAS map for -.5 and -1 CAS settings. The -.5 setting should only shift the mask one bit, not two.
>
> Signed-off-by: Marc Jones <marc.jones at amd.com>
>
>
> Index: LinuxBIOSv2/src/northbridge/amd/lx/raminit.c
> ===================================================================
> --- LinuxBIOSv2.orig/src/northbridge/amd/lx/raminit.c   2007-06-13 17:01:03.000000000 -0600
> +++ LinuxBIOSv2/src/northbridge/amd/lx/raminit.c        2007-06-13 17:01:03.000000000 -0600
> @@ -151,7 +151,7 @@
>         }
>
>         /* I don't think you need this check.
> -          if (spd_byte0 < 0xA0 || spd_byte0 < 0xA0){
> +          if (spd_byte0 >= 0xA0 || spd_byte1 >= 0xA0){
>            print_debug("DIMM overclocked. Check GeodeLink Speed\n");
>            POST_CODE(POST_PLL_MEM_FAIL);
>            __asm__       __volatile__("hlt\n");
> @@ -231,7 +231,7 @@
>  ;*     Destroys: We really use everything !
>  ;*****************************************************************************/
>         uint16_t glspeed, dimm_speed;
> -       uint8_t spd_byte, casmap0, casmap1;
> +       uint8_t spd_byte, casmap0, casmap1, casmap_shift;
>         msr_t msr;
>
>         glspeed = GeodeLinkSpeed();
> @@ -246,25 +246,24 @@
>                         dimm_speed = 2 * (10000 / (((spd_byte >> 4) * 10) +
>                                                 (spd_byte & 0x0F)));
>                         if (dimm_speed >= glspeed) {
> +                               casmap_shift = 1; /* -.5 is a shift of 1 */
>                                 /* IF -1 timing is supported, check -1 timing > GeodeLink */
>                                 spd_byte = spd_read_byte(DIMM0, SPD_SDRAM_CYCLE_TIME_3RD);
>                                 if (spd_byte != 0) {
>                                         /* Turn SPD ns time into MHZ. Check what the asm does to this math. */
>                                         dimm_speed = 2 * (10000 / (((spd_byte >> 4) * 10) + (spd_byte & 0x0F)));
> -                                       if (dimm_speed <= glspeed) {
> -                                               /* set we can use -.5 timing but not -1 */
> -                                               spd_byte = 31 - __builtin_clz((uint32_t) casmap0);
> -                                               /* just want bits in the lower byte since we have to cast to a 32 */
> -                                               casmap0 &= 0xFF << (--spd_byte);
> +                                       if (dimm_speed >= glspeed) {
> +                                               casmap_shift = 2; /* -1 is a shift of 2 */
>                                         }
> -                               }       /*MIN_CYCLE_10 !=0 */
> +                               }       /* SPD_SDRAM_CYCLE_TIME_3RD (-1) !=0 */
>                         } else {
> -                               /* Timing_05 < GLspeed, can't use -.5 or -1 timing */
> -                               spd_byte = 31 - __builtin_clz((uint32_t) casmap0);
> -                               /* just want bits in the lower byte since we have to cast to a 32 */
> -                               casmap0 &= 0xFF << (spd_byte);
> +                               casmap_shift = 0;
>                         }
> -               }               /*MIN_CYCLE_05 !=0 */
> +               }       /* SPD_SDRAM_CYCLE_TIME_2ND (-.5) !=0 */
> +               /* set the casmap based on the shift to limit possible CAS settings */
> +               spd_byte = 31 - __builtin_clz((uint32_t) casmap0);
> +               /* just want bits in the lower byte since we have to cast to a 32 */
> +               casmap0 &= 0xFF << (spd_byte - casmap_shift);
>         } else {                /* No DIMM */
>                 casmap0 = 0;
>         }
> @@ -278,25 +277,25 @@
>                         /* Turn SPD ns time into MHZ. Check what the asm does to this math. */
>                         dimm_speed = 2 * (10000 / (((spd_byte >> 4) * 10) + (spd_byte & 0x0F)));
>                         if (dimm_speed >= glspeed) {
> +                               casmap_shift = 1; /* -.5 is a shift of 1 */
>                                 /* IF -1 timing is supported, check -1 timing > GeodeLink */
>                                 spd_byte = spd_read_byte(DIMM1, SPD_SDRAM_CYCLE_TIME_3RD);
>                                 if (spd_byte != 0) {
>                                         /* Turn SPD ns time into MHZ. Check what the asm does to this math. */
>                                         dimm_speed = 2 * (10000 / (((spd_byte >> 4) * 10) + (spd_byte & 0x0F)));
> -                                       if (dimm_speed <= glspeed) {
> -                                               /* set we can use -.5 timing but not -1 */
> -                                               spd_byte = 31 - __builtin_clz((uint32_t) casmap1);
> -                                               /* just want bits in the lower byte since we have to cast to a 32 */
> -                                               casmap1 &= 0xFF << (--spd_byte);
> +                                       if (dimm_speed >= glspeed) {
> +                                               casmap_shift = 2; /* -1 is a shift of 2 */
>                                         }
> -                               }       /*MIN_CYCLE_10 !=0 */
> +                                       /* note that the -1 result doesn't need to change the available CAS map */
> +                               }       /* SPD_SDRAM_CYCLE_TIME_3RD (-1) !=0 */
>                         } else {
> -                               /* Timing_05 < GLspeed, can't use -.5 or -1 timing */
> -                               spd_byte = 31 - __builtin_clz((uint32_t) casmap1);
> -                               /* just want bits in the lower byte since we have to cast to a 32 */
> -                               casmap1 &= 0xFF << (spd_byte);
> +                               casmap_shift = 0;
>                         }
> -               }               /*MIN_CYCLE_05 !=0 */
> +               }       /* SPD_SDRAM_CYCLE_TIME_2ND (-.5) !=0 */
> +               /* set the casmap based on the shift to limit possible CAS settings */
> +               spd_byte = 31 - __builtin_clz((uint32_t) casmap1);
> +               /* just want bits in the lower byte since we have to cast to a 32 */
> +               casmap1 &= 0xFF << (spd_byte - casmap_shift);
>         } else {                /* No DIMM */
>                 casmap1 = 0;
>         }
>
> --
> linuxbios mailing list
> linuxbios at linuxbios.org
> http://www.linuxbios.org/mailman/listinfo/linuxbios
>



From joe at smittys.pointclark.net  Thu Jun 14 04:29:12 2007
From: joe at smittys.pointclark.net (Joseph Smith)
Date: Wed, 13 Jun 2007 22:29:12 -0400
Subject: [LinuxBIOS] [PATCH] Add Asus MEW-VM, Intel i82810,
	and	generic i82801
In-Reply-To: <46706062.1070605@gmail.com>
References: <46706062.1070605@gmail.com>
Message-ID: <20070613222912.gsudwijb0gsw080c@www.smittys.pointclark.net>

Quoting Corey Osgood <corey.osgood at gmail.com>:

> See attached patch. Thanks for all the great comments and suggestions!
>
> -Corey
>
Am I alowed to Ack this? If so I ACK it :-)

Thanks - Joe



From stuge-linuxbios at cdy.org  Thu Jun 14 04:35:35 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu, 14 Jun 2007 04:35:35 +0200
Subject: [LinuxBIOS] [PATCH] Add Asus MEW-VM, Intel i82810,
	and	generic i82801
In-Reply-To: <20070613222912.gsudwijb0gsw080c@www.smittys.pointclark.net>
References: <46706062.1070605@gmail.com>
	<20070613222912.gsudwijb0gsw080c@www.smittys.pointclark.net>
Message-ID: <20070614023535.6925.qmail@cdy.org>

On Wed, Jun 13, 2007 at 10:29:12PM -0400, Joseph Smith wrote:
> > See attached patch. Thanks for all the great comments and suggestions!
> 
> Am I alowed to Ack this? If so I ACK it :-)

Sure you are, but please see the Development Guidelines on the wiki
for the formalia. http://linuxbios.org/Development_Guidelines

Sign-off Procedure and Review are particularly relevant.


//Peter



From joe at smittys.pointclark.net  Thu Jun 14 05:41:48 2007
From: joe at smittys.pointclark.net (Joseph Smith)
Date: Wed, 13 Jun 2007 23:41:48 -0400
Subject: [LinuxBIOS] [PATCH] Add Asus MEW-VM, Intel i82810,
	and	generic i82801
In-Reply-To: <20070614023535.6925.qmail@cdy.org>
References: <46706062.1070605@gmail.com>
	<20070613222912.gsudwijb0gsw080c@www.smittys.pointclark.net>
	<20070614023535.6925.qmail@cdy.org>
Message-ID: <20070613234148.c97tnkb6n4kcc4ko@www.smittys.pointclark.net>

Quoting Peter Stuge <stuge-linuxbios at cdy.org>:

> On Wed, Jun 13, 2007 at 10:29:12PM -0400, Joseph Smith wrote:
>> > See attached patch. Thanks for all the great comments and suggestions!
>>
>> Am I alowed to Ack this? If so I ACK it :-)
>
> Sure you are, but please see the Development Guidelines on the wiki
> for the formalia. http://linuxbios.org/Development_Guidelines
>
> Sign-off Procedure and Review are particularly relevant.
>
>
> //Peter
>

Ok,
Acked-by: Joseph Smith <joe at smittys.pointclark.net>

Thanks - Joe



From linuxbios at bloms.de  Thu Jun 14 06:53:20 2007
From: linuxbios at bloms.de (Dieter Bloms)
Date: Thu, 14 Jun 2007 06:53:20 +0200
Subject: [LinuxBIOS] buggy burn with uniflash ? (was "EPIA hang after
	patch")
In-Reply-To: <46705E6F.6090103@gmail.com>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
	<20070612175511.GA3652@bloms.de>
	<f7085c470706131137p30e8d8c2n933156c1fe9f48d2@mail.gmail.com>
	<20070613200026.GA4302@bloms.de> <46705E6F.6090103@gmail.com>
Message-ID: <20070614045320.GB4302@bloms.de>

Hi,

On Wed, Jun 13, Corey Osgood wrote:

> Are you sure that the serial console is set up correctly, both in
> Options.lb and the early serial code? And you don't have vga console
> enabled, right?

no I'am not sure.
I'am sure I have something wrong, but I don't know what is wrong.

> > When I boot linux I can login via serial console with 115200,8N1
> 
> When booting the factory bios or linuxbios?

when booting factory bios, because the linuxbios doesn't boot...


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070614/949dd5b4/attachment.sig>

From corey.osgood at gmail.com  Thu Jun 14 07:11:20 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Thu, 14 Jun 2007 01:11:20 -0400
Subject: [LinuxBIOS] buggy burn with uniflash ? (was "EPIA hang after
 patch")
In-Reply-To: <20070614045320.GB4302@bloms.de>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>	<20070612175511.GA3652@bloms.de>	<f7085c470706131137p30e8d8c2n933156c1fe9f48d2@mail.gmail.com>	<20070613200026.GA4302@bloms.de>
	<46705E6F.6090103@gmail.com> <20070614045320.GB4302@bloms.de>
Message-ID: <4670CDF8.80108@gmail.com>

Dieter Bloms wrote:
> Hi,
>
> On Wed, Jun 13, Corey Osgood wrote:
>
>   
>> Are you sure that the serial console is set up correctly, both in
>> Options.lb and the early serial code? And you don't have vga console
>> enabled, right?
>>     
>
> no I'am not sure.
> I'am sure I have something wrong, but I don't know what is wrong.
>   

Alright, looking just at the possible flashing issue for the moment, if
you flash the original bios (to your spare chip) does it work correctly?
And please remind me, what board and flash part are you using? Epia?
Also, what does flashrom do?

-Corey



From linuxbios at bloms.de  Thu Jun 14 07:55:52 2007
From: linuxbios at bloms.de (Dieter Bloms)
Date: Thu, 14 Jun 2007 07:55:52 +0200
Subject: [LinuxBIOS] buggy burn with uniflash ? (was "EPIA hang after
	patch")
In-Reply-To: <4670CDF8.80108@gmail.com>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
	<20070612175511.GA3652@bloms.de>
	<f7085c470706131137p30e8d8c2n933156c1fe9f48d2@mail.gmail.com>
	<20070613200026.GA4302@bloms.de> <46705E6F.6090103@gmail.com>
	<20070614045320.GB4302@bloms.de> <4670CDF8.80108@gmail.com>
Message-ID: <20070614055552.GD4302@bloms.de>

Hi,

On Thu, Jun 14, Corey Osgood wrote:

> Alright, looking just at the possible flashing issue for the moment, if
> you flash the original bios (to your spare chip) does it work correctly?
> And please remind me, what board and flash part are you using? Epia?
> Also, what does flashrom do?

I've a commell lv671 board with W39V040FA bios chip and Winbound
w83627hf-aw super-io chip.

If I burn the factory bios the page count increase from 0001 to 0007 and
takes about 20 seconds/page:

video:/usr/src/neues_bios/LinuxBIOSv2/util/flashrom# flashrom -w originalbios.img
Calibrating delay loop... ok
No LinuxBIOS table found.
Found chipset "ICH4/ICH4-L": Enabling flash write... OK.
W39V040FA found at physical address: 0xfff80000
Flash part is W39V040FA (512 KB)
Flash image seems to be a legacy BIOS. Disabling checks.
Programming Page: 0007 at address: 0x00070000
video:/usr/src/neues_bios/LinuxBIOSv2/util/flashrom# flashrom -v originalbios.img
Calibrating delay loop... ok
No LinuxBIOS table found.
Found chipset "ICH4/ICH4-L": Enabling flash write... OK.
W39V040FA found at physical address: 0xfff80000
Flash part is W39V040FA (512 KB)
Flash image seems to be a legacy BIOS. Disabling checks.
Verifying flash - FAILED

the same with linuxbios, but the burning takes about 10 seconds for the
whole burn:

video:/usr/src/neues_bios/LinuxBIOSv2/util/flashrom# flashrom -w ../../targets/commell/lv671/lv671/linuxbios.rom
Calibrating delay loop... ok
No LinuxBIOS table found.
Found chipset "ICH4/ICH4-L": Enabling flash write... OK.
W39V040FA found at physical address: 0xfff80000
Flash part is W39V040FA (512 KB)
Note: If the following flash access fails, you might need to specify -m
<vendor>:<mainboard>
Programming Page: 0007 at address: 0x00070000
video:/usr/src/neues_bios/LinuxBIOSv2/util/flashrom# flashrom -v ../../targets/commell/lv671/lv671/linuxbios.rom
Calibrating delay loop... ok
No LinuxBIOS table found.
Found chipset "ICH4/ICH4-L": Enabling flash write... OK.
W39V040FA found at physical address: 0xfff80000
Flash part is W39V040FA (512 KB)
Note: If the following flash access fails, you might need to specify -m
<vendor>:<mainboard>
Verifying flash - FAILED


-- 
Gru?

  Dieter

--
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070614/b22f0092/attachment.sig>

From svn at openbios.org  Thu Jun 14 08:10:57 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu, 14 Jun 2007 08:10:57 +0200
Subject: [LinuxBIOS] r2719 - in trunk/LinuxBIOSv2: src/cpu/intel/model_6xx
	src/mainboard/asus src/mainboard/asus/mew-vm
	src/southbridge/intel src/southbridge/intel/i82801xx
	targets/asus targets/asus/mew-vm
Message-ID: <mailman.393.1355071121.16123.coreboot@coreboot.org>

Author: stepan
Date: 2007-06-14 08:10:57 +0200 (Thu, 14 Jun 2007)
New Revision: 2719

Added:
   trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/
   trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/Config.lb
   trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/Options.lb
   trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/auto.c
   trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/chip.h
   trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/cmos.layout
   trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/debug.c
   trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/failover.c
   trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/irq_tables.c
   trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/mainboard.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/Config.lb
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/chip.h
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/cmos_failover.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx.h
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_ac97.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_early_smbus.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_ide.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_lpc.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_nic.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_pci.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_reset.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_sata.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_smbus.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_smbus.h
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_usb.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_usb_ehci.c
   trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_watchdog.c
   trunk/LinuxBIOSv2/targets/asus/mew-vm/
   trunk/LinuxBIOSv2/targets/asus/mew-vm/Config.lb
Modified:
   trunk/LinuxBIOSv2/src/cpu/intel/model_6xx/model_6xx_init.c
Log:
This patch adds support for the Intel i82810 northbridge and various i82801xx
southbridges, along with the Asus MEW-VM. With this, my machine attempts to
boot linux, but does so very slowly and fails during the boot process, probably
because of the irq tables.

Signed-off-by: Corey Osgood <corey.osgood at gmail.com>
Acked-by: Joseph Smith <joe at smittys.pointclark.net>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/LinuxBIOSv2/src/cpu/intel/model_6xx/model_6xx_init.c
===================================================================
--- trunk/LinuxBIOSv2/src/cpu/intel/model_6xx/model_6xx_init.c	2007-06-12 22:54:41 UTC (rev 2718)
+++ trunk/LinuxBIOSv2/src/cpu/intel/model_6xx/model_6xx_init.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -44,6 +44,7 @@
 	.init     = model_6xx_init,
 };
 static struct cpu_device_id cpu_table[] = {
+	{ X86_VENDOR_INTEL, 0x0665 }, /* Celeron (Mendocino) */
 	{ X86_VENDOR_INTEL, 0x0672 },
 	{ X86_VENDOR_INTEL, 0x0673 },
 	{ X86_VENDOR_INTEL, 0x0681 },

Added: trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/Config.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/Config.lb	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,182 @@
+##
+## Compute the location and size of where this firmware image
+## (linuxBIOS plus bootloader) will live in the boot rom chip.
+##
+if USE_FALLBACK_IMAGE
+	default ROM_SECTION_SIZE   = FALLBACK_SIZE
+	default ROM_SECTION_OFFSET = ( ROM_SIZE - FALLBACK_SIZE )
+else
+	default ROM_SECTION_SIZE   = ( ROM_SIZE - FALLBACK_SIZE )
+	default ROM_SECTION_OFFSET = 0
+end
+
+##
+## Compute the start location and size size of
+## The linuxBIOS bootloader.
+##
+default CONFIG_ROM_PAYLOAD_START = (0xffffffff - ROM_SIZE + ROM_SECTION_OFFSET + 1)
+default PAYLOAD_SIZE            = ( ROM_SECTION_SIZE - ROM_IMAGE_SIZE )
+
+##
+## Compute where this copy of linuxBIOS will start in the boot rom
+##
+default _ROMBASE      = ( CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE )
+
+##
+## Compute a range of ROM that can cached to speed up linuxBIOS,
+## execution speed.
+##
+## XIP_ROM_SIZE must be a power of 2.
+## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE
+##
+default XIP_ROM_SIZE=65536
+default XIP_ROM_BASE = ( _ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE )
+
+##
+## Set all of the defaults for an x86 architecture
+##
+
+arch i386 end
+
+##
+## Build the objects we have code for in this directory.
+##
+
+driver mainboard.o
+
+if HAVE_PIRQ_TABLE object irq_tables.o end
+#object reset.o
+
+##
+## Romcc output
+##
+makerule ./failover.E
+	depends "$(MAINBOARD)/failover.c ./romcc" 
+	action "./romcc -E -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/failover.c -o $@"
+end
+
+makerule ./failover.inc
+	depends "$(MAINBOARD)/failover.c ./romcc"
+	action "./romcc    -O --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/failover.c -o $@"
+end
+
+makerule ./auto.E 
+	depends	"$(MAINBOARD)/auto.c option_table.h ./romcc" 
+	action	"./romcc -E -mcpu=p2 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
+end
+makerule ./auto.inc 
+	depends "$(MAINBOARD)/auto.c option_table.h ./romcc"
+	action	"./romcc    -mcpu=p2 -O -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/auto.c -o $@"
+end
+
+##
+## Build our 16 bit and 32 bit linuxBIOS entry code
+##
+mainboardinit cpu/x86/16bit/entry16.inc
+mainboardinit cpu/x86/32bit/entry32.inc
+ldscript /cpu/x86/16bit/entry16.lds
+ldscript /cpu/x86/32bit/entry32.lds
+
+##
+## Build our reset vector (This is where linuxBIOS is entered)
+##
+if USE_FALLBACK_IMAGE 
+	mainboardinit cpu/x86/16bit/reset16.inc 
+	ldscript /cpu/x86/16bit/reset16.lds 
+else
+	mainboardinit cpu/x86/32bit/reset32.inc 
+	ldscript /cpu/x86/32bit/reset32.lds 
+end
+
+### Should this be in the northbridge code?
+mainboardinit arch/i386/lib/cpu_reset.inc
+
+##
+## Include an id string (For safe flashing)
+##
+mainboardinit arch/i386/lib/id.inc
+ldscript /arch/i386/lib/id.lds
+
+###
+### This is the early phase of linuxBIOS startup 
+### Things are delicate and we test to see if we should
+### failover to another image.
+###
+if USE_FALLBACK_IMAGE
+	ldscript /arch/i386/lib/failover.lds 
+	mainboardinit ./failover.inc
+end
+
+###
+### O.k. We aren't just an intermediary anymore!
+###
+
+##
+## Setup RAM
+##
+mainboardinit cpu/x86/fpu/enable_fpu.inc
+mainboardinit cpu/x86/mmx/enable_mmx.inc
+mainboardinit ./auto.inc
+mainboardinit cpu/x86/mmx/disable_mmx.inc
+
+##
+## Include the secondary Configuration files 
+##
+dir /pc80
+config chip.h
+
+chip northbridge/intel/i82810
+	device pci_domain 0 on 
+		device pci 0.0 on end # Host bridge
+		device pci 1.0 on # Onboard Video
+			#chip drivers/pci/onboard
+			#	device pci 1.0 on end
+			#	register "rom_address" = "0xfff80000"
+		        #end
+		end
+		chip southbridge/intel/i82801xx # Southbridge
+			device pci 1e.0 on # PCI Bridge
+				#chip drivers/pci/onboard
+				#	device pci 1.0 on end
+				#	register "rom_address" = "0xfff80000"
+			        #end
+			end
+			device pci 1f.0 on  # ISA/LPC? Bridge
+				chip superio/smsc/lpc47b272
+					device pnp 2e.0 off # Floppy
+						io 0x60 = 0x3f0
+						irq 0x70 = 6
+						drq 0x74 = 2
+					end
+					device pnp 2e.3 off # Parallel Port
+						io 0x60 = 0x378
+						irq 0x70 = 7
+					end
+					device pnp 2e.4 on # Com1
+						io 0x60 = 0x3f8
+						irq 0x70 = 4
+					end
+					device pnp 2e.5 off # Com2
+						io 0x60 = 0x2f8
+						irq 0x70 = 3
+					end
+					device pnp 2e.7 on # Keyboard
+						io 0x60 = 0x60
+						io 0x62 = 0x64
+						irq 0x70 = 1 # Keyboard interrupt
+						irq 0x72 = 12 # Mouse interrupt
+					end
+					device pnp 2e.a off end # ACPI
+				end
+			end
+			device pci 1f.1 on end # IDE
+			device pci 1f.2 on end # USB
+			device pci 1f.3 on end # SMBus
+			device pci 1f.5 off end # AC'97, no header on MEW-VM
+			device pci 1f.6 off end # AC'97 Modem (MC'97)
+		end
+	end
+	chip cpu/intel/socket_PGA370
+	end
+end
+

Added: trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/Options.lb
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/Options.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/Options.lb	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,159 @@
+uses HAVE_MP_TABLE
+uses HAVE_PIRQ_TABLE
+uses USE_FALLBACK_IMAGE
+uses HAVE_FALLBACK_BOOT
+uses HAVE_HARD_RESET
+uses HAVE_OPTION_TABLE
+uses USE_OPTION_TABLE
+uses CONFIG_ROM_PAYLOAD
+uses IRQ_SLOT_COUNT
+uses MAINBOARD
+uses MAINBOARD_VENDOR
+uses MAINBOARD_PART_NUMBER
+uses LINUXBIOS_EXTRA_VERSION
+uses ARCH
+uses FALLBACK_SIZE
+uses STACK_SIZE
+uses HEAP_SIZE
+uses ROM_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_IMAGE_SIZE
+uses ROM_SECTION_SIZE
+uses ROM_SECTION_OFFSET
+uses CONFIG_ROM_PAYLOAD_START
+uses CONFIG_COMPRESSED_PAYLOAD_LZMA
+uses PAYLOAD_SIZE
+uses _ROMBASE
+uses _RAMBASE
+uses XIP_ROM_SIZE
+uses XIP_ROM_BASE
+uses HAVE_MP_TABLE
+uses CROSS_COMPILE
+uses CC
+uses HOSTCC
+uses OBJCOPY
+uses DEFAULT_CONSOLE_LOGLEVEL
+uses MAXIMUM_CONSOLE_LOGLEVEL
+uses CONFIG_CONSOLE_SERIAL8250
+uses TTYS0_BAUD
+uses TTYS0_BASE
+uses TTYS0_LCS
+uses CONFIG_UDELAY_TSC
+uses CONFIG_IDE
+
+## ROM_SIZE is the size of boot ROM that this board will use.
+default ROM_SIZE  = 512*1024
+
+###
+### Build options
+###
+
+##
+## Build code for the fallback boot
+##
+default HAVE_FALLBACK_BOOT = 1
+
+##
+## no MP table
+##
+default HAVE_MP_TABLE = 0
+
+##
+## Build code to reset the motherboard from linuxBIOS
+##
+default HAVE_HARD_RESET = 0
+
+##
+## Build code to export a programmable irq routing table
+##
+default HAVE_PIRQ_TABLE = 1
+default IRQ_SLOT_COUNT = 4
+
+##
+## Build code to export a CMOS option table
+##
+default HAVE_OPTION_TABLE = 0
+
+## IDE Support
+default CONFIG_IDE = 1
+
+###
+### LinuxBIOS layout values
+###
+
+## ROM_IMAGE_SIZE is the amount of space to allow linuxBIOS to occupy.
+default ROM_IMAGE_SIZE = 65536
+default FALLBACK_SIZE = 131072
+
+##
+## Use a small 8K stack
+##
+default STACK_SIZE=0x2000
+
+##
+## Use a small 16K heap
+##
+default HEAP_SIZE=0x4000
+
+##
+## Only use the option table in a normal image
+##
+#default USE_OPTION_TABLE = !USE_FALLBACK_IMAGE
+default USE_OPTION_TABLE = 0
+
+default _RAMBASE = 0x00004000
+
+default CONFIG_ROM_PAYLOAD     = 1
+
+##
+## The default compiler
+##
+default CROSS_COMPILE=""
+default CC="$(CROSS_COMPILE)gcc -m32"
+default HOSTCC="gcc"
+
+##
+## The Serial Console
+##
+
+# To Enable the Serial Console
+default CONFIG_CONSOLE_SERIAL8250=1
+
+## Select the serial console baud rate
+default TTYS0_BAUD=115200
+#default TTYS0_BAUD=57600
+#default TTYS0_BAUD=38400
+#default TTYS0_BAUD=19200
+#default TTYS0_BAUD=9600
+#default TTYS0_BAUD=4800
+#default TTYS0_BAUD=2400
+#default TTYS0_BAUD=1200
+
+# Select the serial console base port
+default TTYS0_BASE=0x3f8
+
+# Select the serial protocol
+# This defaults to 8 data bits, 1 stop bit, and no parity
+default TTYS0_LCS=0x3
+
+##
+### Select the linuxBIOS loglevel
+##
+## EMERG      1   system is unusable               
+## ALERT      2   action must be taken immediately 
+## CRIT       3   critical conditions              
+## ERR        4   error conditions                 
+## WARNING    5   warning conditions               
+## NOTICE     6   normal but significant condition 
+## INFO       7   informational                    
+## DEBUG      8   debug-level messages             
+## SPEW       9   Way too many details             
+
+## Request this level of debugging output
+default  DEFAULT_CONSOLE_LOGLEVEL=9
+## At a maximum only compile in this level of debugging
+default  MAXIMUM_CONSOLE_LOGLEVEL=9
+
+default CONFIG_UDELAY_TSC=1
+end
+

Added: trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/auto.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/auto.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/auto.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,106 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Corey Osgood <corey at slightlyhackish.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#define ASSEMBLY 1
+
+#include <stdint.h>
+#include <device/pci_def.h>
+#include <arch/io.h>
+#include <device/pnp_def.h>
+#include <arch/romcc_io.h>
+#include <arch/hlt.h>
+#include "pc80/serial.c"
+#include "arch/i386/lib/console.c"
+#include "ram/ramtest.c"
+#include "superio/smsc/lpc47b272/lpc47b272_early_serial.c"
+#include "northbridge/intel/i82810/raminit.h"
+#include "cpu/x86/mtrr/earlymtrr.c"
+#include "cpu/x86/bist.h"
+
+#define SERIAL_DEV PNP_DEV(0x2e, LPC47B272_SP1)
+
+#include "southbridge/intel/i82801xx/i82801xx_early_smbus.c"
+
+void udelay(int usecs) 
+{
+	int i;
+	for(i = 0; i < usecs; i++)
+		outb(i&0xff, 0x80);
+}
+
+#include "debug.c"
+#include "lib/delay.c"
+
+#include "northbridge/intel/i82810/raminit.c"
+#include "northbridge/intel/i82810/debug.c"
+#include "sdram/generic_sdram.c"
+
+static void main(unsigned long bist)
+{
+	static const struct mem_controller memctrl[] = {
+		{
+		 .d0 = PCI_DEV(0, 0, 0),
+		 .channel0 = {
+			      (0xa << 3) | 0,
+			      (0xa << 3) | 1,
+			      },
+		 }
+	};
+	
+	if (bist == 0) {
+		early_mtrr_init();
+	}
+	
+	enable_smbus();
+	
+	lpc47b272_enable_serial(SERIAL_DEV, TTYS0_BASE);
+	uart_init();
+	console_init();
+
+	/* Halt if there was a built in self test failure */
+	report_bist_failure(bist);
+
+	//enable_shadow_ram();
+
+	//dump_spd_registers(&memctrl[0]);
+
+	/* sdram_initialize runs out of registers */
+	//sdram_initialize(sizeof(memctrl) / sizeof(memctrl[0]), memctrl);
+	
+	sdram_set_registers(memctrl);
+	sdram_set_spd_registers(memctrl);
+	sdram_enable(0, memctrl);
+
+	/* Check whether RAM is working.
+	 *
+	 * Do _not_ check the area from 640 KB - 1 MB, as that's not really
+	 * RAM, but rather reserved for various other things:
+	 *
+	 *  - 640 KB - 768 KB: Video Buffer Area
+	 *  - 768 KB - 896 KB: Expansion Area
+	 *  - 896 KB - 960 KB: Extended System BIOS Area
+	 *  - 960 KB - 1 MB:   Memory (BIOS Area) - System BIOS Area
+	 *
+	 * Trying to check these areas will fail.
+	 */
+	/* TODO: This is currently hardcoded to check 64 MB. */
+	//ram_check(0x00000000, 0x0009ffff);	/* 0 - 640 KB */
+	//ram_check(0x00100000, 0x007c0000);	/* 1 MB - 64 MB */
+}

Added: trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/chip.h
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/chip.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/chip.h	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,5 @@
+extern struct chip_operations mainboard_asus_mew_vm_ops;
+
+struct mainboard_asus_mew_vm_config {
+	int nothing;
+};

Added: trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/cmos.layout
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/cmos.layout	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/cmos.layout	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,74 @@
+entries
+
+#start-bit length  config config-ID    name
+#0            8       r       0        seconds
+#8            8       r       0        alarm_seconds
+#16           8       r       0        minutes
+#24           8       r       0        alarm_minutes
+#32           8       r       0        hours
+#40           8       r       0        alarm_hours
+#48           8       r       0        day_of_week
+#56           8       r       0        day_of_month
+#64           8       r       0        month
+#72           8       r       0        year
+#80           4       r       0        rate_select
+#84           3       r       0        REF_Clock
+#87           1       r       0        UIP
+#88           1       r       0        auto_switch_DST
+#89           1       r       0        24_hour_mode
+#90           1       r       0        binary_values_enable
+#91           1       r       0        square-wave_out_enable
+#92           1       r       0        update_finished_enable
+#93           1       r       0        alarm_interrupt_enable
+#94           1       r       0        periodic_interrupt_enable
+#95           1       r       0        disable_clock_updates
+#96         288       r       0        temporary_filler
+0          384       r       0        reserved_memory
+384          1       e       4        boot_option
+385          1       e       4        last_boot
+386          1       e       1        ECC_memory
+388          4       r       0        reboot_bits
+392          3       e       5        baud_rate
+400          1       e       1        power_on_after_fail
+412          4       e       6        debug_level
+416          4       e       7        boot_first
+420          4       e       7        boot_second
+424          4       e       7        boot_third
+428          4       h       0        boot_index
+432	     8       h       0        boot_countdown
+1008         16      h       0        check_sum
+
+enumerations
+
+#ID value   text
+1     0     Disable
+1     1     Enable
+2     0     Enable
+2     1     Disable
+4     0     Fallback
+4     1     Normal
+5     0     115200
+5     1     57600
+5     2     38400
+5     3     19200
+5     4     9600
+5     5     4800
+5     6     2400
+5     7     1200
+6     6     Notice
+6     7     Info
+6     8     Debug
+6     9     Spew
+7     0     Network
+7     1     HDD
+7     2     Floppy
+7     8     Fallback_Network
+7     9     Fallback_HDD
+7     10    Fallback_Floppy
+#7     3     ROM
+
+checksums
+
+checksum 392 1007 1008
+
+

Added: trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/debug.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/debug.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/debug.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,66 @@
+
+static void print_debug_pci_dev(unsigned dev)
+{
+	print_debug("PCI: ");
+	print_debug_hex8((dev >> 16) & 0xff);
+	print_debug_char(':');
+	print_debug_hex8((dev >> 11) & 0x1f);
+	print_debug_char('.');
+	print_debug_hex8((dev >> 8) & 7);
+}
+
+static void print_pci_devices(void)
+{
+	device_t dev;
+	for(dev = PCI_DEV(0, 0, 0); 
+		dev <= PCI_DEV(0, 0x1f, 0x7); 
+		dev += PCI_DEV(0,0,1)) {
+		uint32_t id;
+		id = pci_read_config32(dev, PCI_VENDOR_ID);
+		if (((id & 0xffff) == 0x0000) || ((id & 0xffff) == 0xffff) ||
+			(((id >> 16) & 0xffff) == 0xffff) ||
+			(((id >> 16) & 0xffff) == 0x0000)) {
+			continue;
+		}
+		print_debug_pci_dev(dev);
+		print_debug("\r\n");
+	}
+}
+
+static void dump_pci_device(unsigned dev)
+{
+	int i;
+	print_debug_pci_dev(dev);
+	print_debug("\r\n");
+	
+	for(i = 0; i <= 255; i++) {
+		unsigned char val;
+		if ((i & 0x0f) == 0) {
+			print_debug_hex8(i);
+			print_debug_char(':');
+		}
+		val = pci_read_config8(dev, i);
+		print_debug_char(' ');
+		print_debug_hex8(val);
+		if ((i & 0x0f) == 0x0f) {
+			print_debug("\r\n");
+		}
+	}
+}
+
+static void dump_pci_devices(void)
+{
+	device_t dev;
+	for(dev = PCI_DEV(0, 0, 0); 
+		dev <= PCI_DEV(0, 0x1f, 0x7); 
+		dev += PCI_DEV(0,0,1)) {
+		uint32_t id;
+		id = pci_read_config32(dev, PCI_VENDOR_ID);
+		if (((id & 0xffff) == 0x0000) || ((id & 0xffff) == 0xffff) ||
+			(((id >> 16) & 0xffff) == 0xffff) ||
+			(((id >> 16) & 0xffff) == 0x0000)) {
+			continue;
+		}
+		dump_pci_device(dev);
+	}
+}

Added: trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/failover.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/failover.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/failover.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,32 @@
+#define ASSEMBLY 1
+#include <stdint.h>
+#include <device/pci_def.h>
+#include <device/pci_ids.h>
+#include <arch/io.h>
+#include "arch/romcc_io.h"
+#include "pc80/mc146818rtc_early.c"
+
+static unsigned long main(unsigned long bist)
+{
+	/* This is the primary cpu how should I boot? */
+	if (do_normal_boot()) {
+		goto normal_image;
+	}
+	else {
+		goto fallback_image;
+	}
+ normal_image:
+	asm volatile ("jmp __normal_image" 
+		: /* outputs */ 
+		: "a" (bist) /* inputs */
+		: /* clobbers */
+		);
+ cpu_reset:
+	asm volatile ("jmp __cpu_reset"
+		: /* outputs */ 
+		: "a"(bist) /* inputs */
+		: /* clobbers */
+		);
+ fallback_image:
+	return bist;
+}

Added: trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/irq_tables.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/irq_tables.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/irq_tables.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,42 @@
+/* This file was generated by getpir.c, do not modify! 
+ * (but if you do, please run checkpir on it to verify)
+ * Contains the IRQ Routing Table dumped directly from your memory, which BIOS sets up
+ *
+ * Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM
+*/
+
+#include <arch/pirq_routing.h>
+
+const struct irq_routing_table intel_irq_routing_table = {
+	PIRQ_SIGNATURE,  /* u32 signature */
+	PIRQ_VERSION,    /* u16 version   */
+	32+16*11,	 /* there can be total 11 devices on the bus */
+	0x00,		 /* Where the interrupt router lies (bus) */
+	(0x11<<3)|0x0,   /* Where the interrupt router lies (dev) */
+	0xe20,		 /* IRQs devoted exclusively to PCI usage */
+	0x8086,		 /* Vendor */
+	0x7120,		 /* Device */
+	0,		 /* Crap (miniport) */
+	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
+	0x89,		 /*  u8 checksum , this has to set to some value 
+that would give 0 after the sum of all bytes for this structure (including checksum) */
+	{
+		/* bus,     dev|fn,   {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap},  slot, rfu */
+		{0x00,(0x08<<3)|0x0, {{0x02, 0xdea0}, {0x03, 0xdea0}, {0x04, 0xdea0}, {0x01, 0x0dea0}}, 0x1, 0x0},
+		{0x00,(0x09<<3)|0x0, {{0x03, 0xdea0}, {0x04, 0xdea0}, {0x01, 0xdea0}, {0x02, 0x0dea0}}, 0x2, 0x0},
+		{0x00,(0x0a<<3)|0x0, {{0x04, 0xdea0}, {0x01, 0xdea0}, {0x02, 0xdea0}, {0x03, 0x0dea0}}, 0x3, 0x0},
+		{0x00,(0x0b<<3)|0x0, {{0x04, 0xdea0}, {0x01, 0xdea0}, {0x02, 0xdea0}, {0x03, 0x0dea0}}, 0x4, 0x0},
+		{0x00,(0x0c<<3)|0x0, {{0x01, 0xdea0}, {0x02, 0xdea0}, {0x03, 0xdea0}, {0x04, 0x0dea0}}, 0x5, 0x0},
+		{0x00,(0x0d<<3)|0x0, {{0x01, 0xdea0}, {0x02, 0xdea0}, {0x03, 0xdea0}, {0x04, 0x0dea0}}, 0x6, 0x0},
+		{0x00,(0x11<<3)|0x0, {{0x00, 0xdea0}, {0x00, 0xdea0}, {0x03, 0xdea0}, {0x04, 0x0dea0}}, 0x0, 0x0},
+		{0x00,(0x0f<<3)|0x0, {{0x01, 0xdea0}, {0x02, 0xdea0}, {0x03, 0xdea0}, {0x04, 0x0dea0}}, 0x0, 0x0},
+		{0x00,(0x01<<3)|0x0, {{0x01, 0xdea0}, {0x02, 0xdea0}, {0x03, 0xdea0}, {0x04, 0x0dea0}}, 0x0, 0x0},
+		{0x00,(0x10<<3)|0x0, {{0x01, 0xdea0}, {0x02, 0xdea0}, {0x03, 0xdea0}, {0x04, 0x0dea0}}, 0x0, 0x0},
+		{0x00,(0x12<<3)|0x0, {{0x01, 0xdea0}, {0x00, 0xdea0}, {0x00, 0xdea0}, {0x00, 0x0dea0}}, 0x0, 0x0},
+	}
+};
+
+unsigned long write_pirq_routing_table(unsigned long addr)
+{
+        return copy_pirq_routing_table(addr);
+}

Added: trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/mainboard.c
===================================================================
--- trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/mainboard.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/mainboard/asus/mew-vm/mainboard.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,7 @@
+#include <device/device.h>
+#include "chip.h"
+
+struct chip_operations mainboard_asus_mew_vm_ops = {
+	CHIP_NAME("ASUS MEW-VM Mainboard")
+};
+

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/Config.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/Config.lb	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,30 @@
+##
+## This file is part of the LinuxBIOS project.
+##
+## Copyright (C) 2007 Corey Osgood <corey.osgood at gmail.com>
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+driver i82801xx.o
+driver i82801xx_usb.o
+driver i82801xx_lpc.o
+driver i82801xx_ide.o
+driver i82801xx_usb_ehci.o
+driver i82801xx_ac97.o
+driver i82801xx_nic.o
+driver i82801xx_pci.o
+driver i82801xx_sata.o
+object i82801xx_reset.o
+object i82801xx_watchdog.o

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/chip.h
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/chip.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/chip.h	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,39 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Corey Osgood <corey_osgood at verizon.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef IGNORE_I82801XX_DEVICE_LIST
+#warning "The i82801xx code currently supports, on a testing/experimental basis," 
+#warning "these devices:"
+#warning "i82801aa, i82801ab, i82801ba, i82801ca, i82801db, i82801dbm, i82801eb,"
+#warning "and i82801er."
+#warning "Using this without modification on any other i82801 version will probably"
+#warning "work until ram init, but will fail after that"
+#endif
+
+#ifndef SOUTHBRIDGE_INTEL_I82801XX_CHIP_H
+#define SOUTHBRIDGE_INTEL_I82801XX_CHIP_H
+
+struct southbridge_intel_i82801xx_config 
+{
+};
+
+extern struct chip_operations southbridge_intel_i82801xx_ops;
+
+#endif /* SOUTHBRIDGE_INTEL_I82801XX_CHIP_H */

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/cmos_failover.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/cmos_failover.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/cmos_failover.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,32 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include "i82801xx.h"
+
+static void check_cmos_failed(void) 
+{
+	uint8_t byte;
+	byte = pci_read_config8(PCI_DEV(0, 0x1f, 0), GEN_PMCON_3);
+	if( byte & RTC_FAILED) {
+		//clear bit 1 and bit 2
+		byte = cmos_read(RTC_BOOT_BYTE);
+		byte &= 0x0c;
+		byte |= MAX_REBOOT_CNT << 4;
+		cmos_write(byte, RTC_BOOT_BYTE);
+	}
+}

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,67 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2005 Digital Design Corporation
+ * (Written by Steven J. Magnani <steve at digidescorp.com> for Digital Design Corp)
+ * Copyright (C) 2007 Corey Osgood <corey.osgood at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include "i82801xx.h"
+
+void i82801xx_enable(device_t dev)
+{
+	unsigned int index = 0;
+	uint16_t cur_disable_mask, new_disable_mask;
+
+	// All 82801 devices should be on bus 0
+	unsigned int devfn = PCI_DEVFN(0x1f, 0); // lpc
+	device_t lpc_dev = dev_find_slot(0, devfn); // 0
+	if (!lpc_dev)
+		return;
+
+	/* We're going to assume, perhaps incorrectly, that if a function exists
+	it can be disabled. Workarounds for ICH variants that don't follow this 
+	should be done by checking the device ID */
+
+	if (PCI_SLOT(dev->path.u.pci.devfn) == 31) {
+		index = PCI_FUNC(dev->path.u.pci.devfn);
+	} else if (PCI_SLOT(dev->path.u.pci.devfn) == 29) {
+		index = 8 + PCI_FUNC(dev->path.u.pci.devfn);
+	}
+	
+	/* Function 0 is a bit of an exception */
+	if(index == 0)
+	{
+		index = 14;
+	}
+	cur_disable_mask = pci_read_config16(lpc_dev, FUNC_DIS);
+	new_disable_mask = cur_disable_mask & ~(1 << index); // enable it
+	if (!dev->enabled) {
+		new_disable_mask |= (1 << index);  // disable it, if desired
+	}
+	if (new_disable_mask != cur_disable_mask) {
+		pci_write_config16(lpc_dev, FUNC_DIS, new_disable_mask);
+	}
+}
+
+struct chip_operations southbridge_intel_i82801xx_ops = {
+	CHIP_NAME("Intel i82801 Series Southbridge")
+	.enable_dev = i82801xx_enable,
+};

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx.h
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx.h	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,106 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Corey Osgood <corey.osgood at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef I82801XX_H
+#define I82801XX_H
+
+#ifndef __ROMCC__
+#include "chip.h"
+extern void i82801xx_enable(device_t dev);
+#endif
+
+#define PCI_DMA_CFG     0x90
+#define SERIRQ_CNTL     0x64
+#define GEN_CNTL        0xd0
+#define GEN_STS         0xd4
+#define RTC_CONF        0xd8
+#define GEN_PMCON_3     0xa4
+
+#define PCICMD          0x04
+#define PMBASE          0x40
+#define PM_BASE_ADDR	0x1100
+#define ACPI_CNTL       0x44
+#define BIOS_CNTL       0x4E
+#define GPIO_BASE	0x58
+#define GPIO_BASE_ADDR	0x1180
+#define GPIO_CNTL       0x5C
+#define PIRQA_ROUT      0x60
+#define PIRQE_ROUT      0x68
+#define COM_DEC         0xE0
+#define LPC_EN          0xE6
+#define FUNC_DIS        0xF2
+
+#define CMD		0x04
+#define SBUS_NUM	0x19
+#define SUB_BUS_NUM	0x1A
+#define SMLT		0x1B
+#define IOBASE		0x1C
+#define IOLIM		0x1D
+#define MEMBASE		0x20
+#define MEMLIM		0x22
+#define CNF		0x50
+#define MTT		0x70
+#define PCI_MAST_STS	0x82
+
+// GEN_PMCON_3 bits
+#define RTC_BATTERY_DEAD	(1 << 2)
+#define RTC_POWER_FAILED	(1 << 1)
+#define SLEEP_AFTER_POWER_FAIL	(1 << 0)
+
+// PCI Configuration Space (D31:F1)
+#define IDE_TIM_PRI		0x40	// IDE timings, primary
+#define IDE_TIM_SEC		0x42	// IDE timings, secondary
+
+// IDE_TIM bits
+#define IDE_DECODE_ENABLE	(1 << 15)
+
+// PCI Configuration Space (D31:F3)
+#define SMB_BASE	0x20
+#define HOSTC		0x40
+
+// HOSTC bits
+#define I2C_EN		(1 << 2)
+#define SMB_SMI_EN	(1 << 1)
+#define HST_EN		(1 << 0)
+
+// SMBus IO bits
+/* TODO: Does it matter where we put the SMBus IO base, as long as we keep 
+   consistent and don't interfere with anything else? */
+//#define SMBUS_IO_BASE 0x1000
+#define SMBUS_IO_BASE	0x0f00
+
+#define SMBHSTSTAT	0x0
+#define SMBHSTCTL	0x2
+#define SMBHSTCMD	0x3
+#define SMBXMITADD	0x4
+#define SMBHSTDAT0	0x5
+#define SMBHSTDAT1	0x6
+#define SMBBLKDAT	0x7
+#define SMBTRNSADD	0x9
+#define SMBSLVDATA	0xa
+#define SMLINK_PIN_CTL	0xe
+#define SMBUS_PIN_CTL	0xf 
+
+#define SMBUS_TIMEOUT	(10 * 1000 * 100)
+
+//HPET, if present
+#define HPET_ADDR		0xfed0000
+
+#endif /* I82801XX_H */

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_ac97.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_ac97.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_ac97.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,113 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2005 Tyan Computer
+ * (Written by Yinghai Lu <yinghailu at gmail.com> for Tyan Computer)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include "i82801xx.h"
+
+static struct device_operations ac97_ops  = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = 0,
+	.scan_bus         = 0,
+	.enable           = i82801xx_enable,
+};
+
+/* i82801aa */
+static struct pci_driver i82801aa_ac97_audio __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2415,
+};
+
+static struct pci_driver i82801aa_ac97_modem __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2416,
+};
+
+/* i82801ab */
+static struct pci_driver i82801ab_ac97_audio __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2425,
+};
+
+static struct pci_driver i82801ab_ac97_modem __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2426,
+};
+
+/* i82801ba */
+static struct pci_driver i82801ba_ac97_audio __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2445,
+};
+
+static struct pci_driver i82801ba_ac97_modem __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2446,
+};
+
+/* i82801ca */
+static struct pci_driver i82801ca_ac97_audio __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2485,
+};
+
+static struct pci_driver i82801ca_ac97_modem __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2486,
+};
+
+/* i82801db & i82801dbm */
+static struct pci_driver i82801db_ac97_audio __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24c5,
+};
+
+static struct pci_driver i82801db_ac97_modem __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24c6,
+};
+
+/* i82801eb & i82801er */
+static struct pci_driver i82801ex_ac97_audio __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24d5,
+};
+
+static struct pci_driver i82801ex_ac97_modem __pci_driver = {
+	.ops    = &ac97_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24d6,
+};

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_early_smbus.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_early_smbus.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_early_smbus.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,74 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2005 Tyan Computer
+ * (Written by Yinghai Lu <yinghailu at gmail.com> for Tyan Computer)
+ * Copyright (C) 2007 Corey Osgood <corey.osgood at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <device/pci_ids.h>
+#include "i82801xx.h"
+#include "i82801xx_smbus.h"
+
+static void enable_smbus(void)
+{
+	device_t dev;
+	uint16_t device_id;
+	
+	/* Set the SMBus device staticly */
+	dev = PCI_DEV(0x0, 0x1f, 0x3);
+	
+	/* Check to make sure we've got the right device */
+	device_id = pci_read_config16(dev, 0x2);
+	
+	/* Clear bits 7-4, since those are the only bits that vary between models */
+	device_id &= 0xff0f;
+	
+	if(device_id != 0x2403)
+	{
+		die("Device not found, Corey probably screwed up!");
+	}
+	
+	/* Set SMBus I/O base */
+	pci_write_config32(dev, SMB_BASE, SMBUS_IO_BASE | PCI_BASE_ADDRESS_SPACE_IO);
+	/* Set SMBus enable */
+	pci_write_config8(dev, HOSTC, HST_EN);
+	/* Set SMBus I/O space enable */ 
+	pci_write_config16(dev, PCI_COMMAND, PCI_COMMAND_IO);
+	/* Disable interrupt generation */ 
+	outb(0, SMBUS_IO_BASE + SMBHSTCTL);
+	/* Clear any lingering errors, so transactions can run */
+	outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT);
+	print_debug("SMBus controller enabled\r\n");
+}
+
+static inline int smbus_read_byte(unsigned device, unsigned address)
+{
+	return do_smbus_read_byte(device, address);
+}
+
+static void smbus_write_byte(unsigned device, unsigned address, unsigned char val)
+{
+	print_err("Unimplemented smbus_write_byte() called\r\n");
+	return;
+}
+
+static inline int smbus_write_block(unsigned device, unsigned length, unsigned cmd, 
+		 unsigned data1, unsigned data2)
+{
+	return do_smbus_write_block(device, length, cmd, data1, data2);
+}

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_ide.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_ide.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_ide.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,113 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2005 Tyan Computer
+ * (Written by Yinghai Lu <yinghailu at gmail.com> for Tyan Computer)
+ * Copyright (C) 2005 Digital Design Corporation
+ * (Written by Steven J. Magnani <steve at digidescorp.com> for Digital Design Corp)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include "i82801xx.h"
+
+static void ide_init(struct device *dev)
+{
+	/* TODO: Needs to be tested for compatibility with ICH5(R) */
+	/* Enable ide devices so the linux ide driver will work */
+	uint16_t ideTimingConfig;
+	int enable_primary = 1;
+	int enable_secondary = 1;
+
+	ideTimingConfig = pci_read_config16(dev, IDE_TIM_PRI);
+	ideTimingConfig &= ~IDE_DECODE_ENABLE;
+	if (enable_primary) {
+		/* Enable primary ide interface */
+		ideTimingConfig |= IDE_DECODE_ENABLE;
+		printk_debug("IDE0 ");
+	}
+	pci_write_config16(dev, IDE_TIM_PRI, ideTimingConfig);
+
+	ideTimingConfig = pci_read_config16(dev, IDE_TIM_SEC);
+	ideTimingConfig &= ~IDE_DECODE_ENABLE;
+	if (enable_secondary) {
+		/* Enable secondary ide interface */
+		ideTimingConfig |= IDE_DECODE_ENABLE;
+		printk_debug("IDE1 ");
+	}
+	pci_write_config16(dev, IDE_TIM_SEC, ideTimingConfig);
+}
+
+static struct device_operations ide_ops  = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = ide_init,
+	.scan_bus         = 0,
+	.enable           = i82801xx_enable,
+};
+
+/* i82801aa */
+static struct pci_driver i82801aa_ide __pci_driver = {
+	.ops    = &ide_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2411,
+};
+
+/* i82801ab */
+static struct pci_driver i82801ab_ide __pci_driver = {
+	.ops    = &ide_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2421,
+};
+
+/* i82801ba */
+static struct pci_driver i82801ba_ide __pci_driver = {
+	.ops    = &ide_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x244b,
+};
+
+/* i82801ca */
+static struct pci_driver i82801ca_ide __pci_driver = {
+	.ops    = &ide_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x248b,
+};
+
+/* i82801db */
+static struct pci_driver i82801db_ide __pci_driver = {
+	.ops    = &ide_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24cb,
+};
+
+/* i82801dbm */
+static struct pci_driver i82801dbm_ide __pci_driver = {
+	.ops    = &ide_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24ca,
+};
+
+/* i82801eb & i82801er */
+static struct pci_driver i82801ex_ide __pci_driver = {
+	.ops    = &ide_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24db,
+};

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_lpc.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_lpc.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_lpc.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,289 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2003 Linux Networx
+ * Copyright (C) 2003 SuSE Linux AG
+ * Copyright (C) 2005 Tyan Computer
+ * (Written by Yinghai Lu <yinghailu at gmail.com> for Tyan Computer)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+ 
+/* from i82801dbm, needs to be fixed to support everything the i82801er does */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <pc80/mc146818rtc.h>
+#include <pc80/isa-dma.h>
+#include <arch/io.h>
+#include "i82801xx.h"
+
+#define NMI_OFF 0
+
+void i82801xx_enable_ioapic( struct device *dev) 
+{
+	uint32_t reg32;
+	volatile uint32_t *ioapic_index = (volatile uint32_t *)0xfec00000;
+	volatile uint32_t *ioapic_data = (volatile uint32_t *)0xfec00010;
+
+	reg32 = pci_read_config32(dev, GEN_CNTL);
+	reg32 |= (3 << 7); /* Enable IOAPIC */
+	reg32 |= (1 << 13); /* Coprocessor error enable */
+	reg32 |= (1 << 1); /* Delayed transaction enable */
+	reg32 |= (1 << 2); /* DMA collection buffer enable */
+	pci_write_config32(dev, GEN_CNTL, reg32);
+	printk_debug("IOAPIC Southbridge enabled %x\n", reg32);
+
+	*ioapic_index = 0;
+	*ioapic_data = (1 << 25);
+
+	*ioapic_index = 0;
+	reg32 = *ioapic_data;
+	printk_debug("Southbridge APIC ID = %x\n", reg32);
+	if(reg32 != (1 << 25))
+		die("APIC Error\n");
+
+	/* TODO: From i82801ca, needed/useful on other ICH? */
+	*ioapic_index = 3;	// Select Boot Configuration register
+	*ioapic_data = 1;	// Use Processor System Bus to deliver interrupts
+}
+
+void i82801xx_enable_serial_irqs( struct device *dev)
+{
+	/* set packet length and toggle silent mode bit */
+	pci_write_config8(dev, SERIRQ_CNTL, (1 << 7)|(1 << 6)|((21 - 17) << 2)|(0 << 0));
+	pci_write_config8(dev, SERIRQ_CNTL, (1 << 7)|(0 << 6)|((21 - 17) << 2)|(0 << 0));
+	/* TODO: Explain/#define the real meaning of these magic numbers ^^^ */
+}
+
+void i82801xx_lpc_route_dma( struct device *dev, uint8_t mask) 
+{
+        uint16_t reg16;
+        int i;
+        reg16 = pci_read_config16(dev, PCI_DMA_CFG);
+        reg16 &= 0x300;
+        for(i = 0; i < 8; i++) {
+                if (i == 4)
+                        continue;
+                reg16 |= ((mask & (1 << i))? 3:1) << (i * 2);
+        }
+        pci_write_config16(dev, PCI_DMA_CFG, reg16);
+}
+
+void i82801xx_rtc_init(struct device *dev)
+{//todo:needs serious cleanup/comments
+        uint8_t reg8;
+        uint32_t reg32;
+        int rtc_failed;
+        byte = pci_read_config8(dev, GEN_PMCON_3);
+        rtc_failed = byte & RTC_BATTERY_DEAD;
+        if (rtc_failed) {
+                reg8 &= ~(1 << 1); /* preserve the power fail state */
+                pci_write_config8(dev, GEN_PMCON_3, reg8);
+        }
+        reg32 = pci_read_config32(dev, GEN_STS);
+        rtc_failed |= reg32 & (1 << 2);
+        rtc_init(rtc_failed);
+}
+
+
+void i82801xx_1f0_misc(struct device *dev)
+{
+	/* TODO: break this down into smaller functions */
+
+	//move to acpi_enable or something
+	/* Set ACPI base address to 0x1100 (I/O space) */
+	pci_write_config32(dev, PMBASE, PM_BASE_ADDR | 1);
+	/* Enable ACPI I/O and power management */
+	pci_write_config8(dev, ACPI_CNTL, 0x10);
+	/* Set GPIO base address to 0x1180 (I/O space) */
+	pci_write_config32(dev, GPIO_BASE, GPIO_BASE_ADDR | 1);
+	/* Enable GPIO */
+	pci_write_config8(dev, GPIO_CNTL, 0x10);
+	
+	//get rid of?
+	/* Route PIRQA to IRQ11, PIRQB to IRQ3, PIRQC to IRQ5, PIRQD to IRQ10 */
+	pci_write_config32(dev, PIRQA_ROUT, 0x0A05030B);
+	/* Route PIRQE to IRQ7. Leave PIRQF - PIRQH unrouted */
+	pci_write_config8(dev, PIRQE_ROUT, 0x07);
+	
+	//move to i82801xx_init
+	/* Prevent LPC disabling, enable parity errors, and SERR# (System Error) */
+	pci_write_config16(dev, PCI_COMMAND, 0x014f);
+	/* Enable access to the upper 128 byte bank of CMOS RAM */
+	pci_write_config8(dev, RTC_CONF, 0x04);
+	/* Decode 0x3F8-0x3FF (COM1) for COMA port, 0x2F8-0x2FF (COM2) for COMB */
+	pci_write_config8(dev, COM_DEC, 0x10);
+	/* LPT decode defaults to 0x378-0x37F and 0x778-0x77F
+	 * Floppy decode defaults to 0x3F0-0x3F5, 0x3F7 */
+	/* Enable: COMA, COMB, LPT, Floppy
+	 * Disable: Microcontroller, Sound, Gameport */
+	pci_write_config16(dev, LPC_EN, 0x000F);
+}
+
+static void enable_hpet(struct device *dev)
+{
+#ifdef HPET_PRESENT
+	uint32_t reg32;
+	uint32_t code = (0 & 0x3);
+
+	reg32 = pci_read_config32(dev, GEN_CNTL);
+	reg32 |= (1 << 17); /* Enable HPET */
+	/*Bits [16:15]Memory Address Range
+	00 FED0_0000h - FED0_03FFh
+	01 FED0_1000h - FED0_13FFh
+	10 FED0_2000h - FED0_23FFh
+	11 FED0_3000h - FED0_33FFh*/
+
+	reg32 &= ~(3 << 15); /* Clear it */
+	reg32 |= (code << 15);
+	/* reg32 is never written to anywhere?? */
+	printk_debug("Enabling HPET @0x%x\n", HPET_ADDR | (code << 12));
+#endif
+}
+
+
+static void lpc_init(struct device *dev)
+{
+	uint8_t byte;
+	int pwr_on = -1;
+	int nmi_option;
+
+	/* IO APIC initialization */
+	i82801xx_enable_ioapic(dev);
+
+	i82801xx_enable_serial_irqs(dev);
+
+	/* TODO: Find out if this is being used/works */
+#ifdef SUSPICIOUS_LOOKING_CODE	
+	/* The ICH-4 datasheet does not mention this configuration register. */ 
+	/* This code may have been inherited (incorrectly) from code for 
+	the AMD 766 southbridge, which *does* support this functionality. */
+
+	/* Posted memory write enable */
+	byte = pci_read_config8(dev, 0x46);
+	pci_write_config8(dev, 0x46, byte | (1<<0)); 
+#endif
+
+	/* power after power fail */
+	/* FIXME this doesn't work! */
+	/* Which state do we want to goto after g3 (power restored)?
+	 * 0 == S0 Full On
+	 * 1 == S5 Soft Off
+	 */
+        pci_write_config8(dev, GEN_PMCON_3, pwr_on?0:1);
+        printk_info("Set power %s if power fails\n", pwr_on?"on":"off");
+
+	/* Set up NMI on errors */
+	byte = inb(0x61);
+	byte &= ~(1 << 3); /* IOCHK# NMI Enable */
+	byte &= ~(1 << 2); /* PCI SERR# Enable */
+	outb(byte, 0x61);
+	byte = inb(0x70);
+
+	nmi_option = NMI_OFF;
+	get_option(&nmi_option, "nmi");
+	if (nmi_option) {			
+		byte &= ~(1 << 7); /* set NMI */
+		outb(byte, 0x70);
+	}
+	
+	/* Initialize the real time clock */
+	i82801xx_rtc_init(dev);
+
+	i82801xx_lpc_route_dma(dev, 0xff);
+
+	/* Initialize isa dma */
+	isa_dma_init();
+
+	i82801xx_1f0_misc(dev);
+	/* Initialize the High Precision Event Timers, if present */
+	enable_hpet(dev);
+}
+
+static void i82801xx_lpc_read_resources(device_t dev)
+{
+	struct resource *res;
+
+	/* Get the normal pci resources of this device */
+	pci_dev_read_resources(dev);
+
+	/* Add an extra subtractive resource for both memory and I/O */
+	res = new_resource(dev, IOINDEX_SUBTRACTIVE(0, 0));
+	res->flags = IORESOURCE_IO | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+
+	res = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
+	res->flags = IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+}
+
+static void i82801xx_lpc_enable_resources(device_t dev)
+{
+	pci_dev_enable_resources(dev);
+	enable_childrens_resources(dev);
+}
+
+static struct device_operations lpc_ops  = {
+	.read_resources   = i82801xx_lpc_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = i82801xx_lpc_enable_resources,
+	.init             = lpc_init,
+	.scan_bus         = scan_static_bus,
+	.enable           = i82801xx_enable,
+};
+
+static struct pci_driver i82801aa_lpc __pci_driver = {
+	.ops    = &lpc_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2410,
+};
+
+static struct pci_driver i82801ab_lpc __pci_driver = {
+	.ops    = &lpc_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2420,
+};
+
+static struct pci_driver i82801ba_lpc __pci_driver = {
+	.ops    = &lpc_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2440,
+};
+
+static struct pci_driver i82801ca_lpc __pci_driver = {
+	.ops    = &lpc_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2480,
+};
+
+static struct pci_driver i82801db_lpc __pci_driver = {
+	.ops    = &lpc_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24c0,
+};
+
+static struct pci_driver i82801dbm_lpc __pci_driver = {
+	.ops    = &lpc_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24cc,
+};
+
+/* i82801eb and er */
+static struct pci_driver i82801ex_lpc __pci_driver = {
+	.ops    = &lpc_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24d0,
+};

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_nic.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_nic.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_nic.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,44 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Corey Osgood <corey.osgood at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+
+static struct device_operations nic_ops  = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = 0,
+	.scan_bus         = 0,
+};
+
+static struct pci_driver i82801dbm_nic __pci_driver = {
+	.ops    = &nic_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x103a,
+};
+
+static struct pci_driver i82801ex_nic __pci_driver = {
+	.ops    = &nic_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x1051,
+};

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_pci.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_pci.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_pci.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,80 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2005 Tyan Computer
+ * (Written by Yinghai Lu <yinghailu at gmail.com> for Tyan Computer)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+
+static void pci_init(struct device *dev)
+{
+	uint32_t reg32;
+	uint16_t reg16;
+
+	/* Clear system errors */
+	reg16 = pci_read_config16(dev, 0x06);
+	reg16 |= 0xf900; /* Clear possible errors */
+	pci_write_config16(dev, 0x06, reg16);
+
+	/* i82801er has this commented out, wonder why? */
+	/* System error enable */
+	reg32 = pci_read_config32(dev, 0x04);
+	reg32 |= (1 << 8); /* SERR# Enable */
+	reg32 |= (1 << 6); /* Parity Error Response */
+	pci_write_config32(dev, 0x04, reg32);
+	
+	reg16 = pci_read_config16(dev, 0x1e);
+	reg16 |= 0xf800; /* Clear possible errors */
+	pci_write_config16(dev, 0x1e, reg16);
+}
+
+static struct device_operations pci_ops  = {
+	.read_resources   = pci_bus_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_bus_enable_resources,
+	.init             = pci_init,
+	.scan_bus         = pci_scan_bridge,
+};
+
+static struct pci_driver i82801aa_pci __pci_driver = {
+	.ops    = &pci_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2418,
+};
+
+static struct pci_driver i82801ab_pci __pci_driver = {
+	.ops    = &pci_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2428,
+};
+
+/* i82801ba, ca, db, eb, and er */
+static struct pci_driver i82801misc_pci __pci_driver = {
+	.ops    = &pci_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x244e,
+};
+
+static struct pci_driver i82801dbm_pci __pci_driver = {
+	.ops    = &pci_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2448,
+};

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_reset.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_reset.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_reset.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,27 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2002 Eric Biederman <ebiederm at xmission.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <arch/io.h>
+
+void hard_reset(void)
+{
+        /* Try rebooting through port 0xcf9 */
+        outb((1 << 2)|(1 << 1), 0xcf9);
+}

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_sata.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_sata.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_sata.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,82 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2005 Tyan Computer
+ * (Written by Yinghai Lu <yinghailu at gmail.com> for Tyan Computer)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include "i82801xx.h"
+
+/* TODO: set dynamically, if the user only wants one sata channel or none at all */
+
+static void sata_init(struct device *dev)
+{
+	/* SATA configuration */
+	pci_write_config8(dev, 0x04, 0x07);
+	pci_write_config8(dev, 0x09, 0x8f);
+	
+	/* Set timmings */
+	pci_write_config16(dev, 0x40, 0x0a307);
+	pci_write_config16(dev, 0x42, 0x0a307);
+
+	/* Sync DMA */
+	pci_write_config16(dev, 0x48, 0x000f);
+	pci_write_config16(dev, 0x4a, 0x1111);
+
+	/* 66 mhz */
+	pci_write_config16(dev, 0x54, 0xf00f);
+
+	/* Combine ide - sata configuration */
+	pci_write_config8(dev, 0x90, 0x0);
+	
+	/* port 0 & 1 enable */
+	pci_write_config8(dev, 0x92, 0x33);
+	
+	/* initialize SATA  */
+	pci_write_config16(dev, 0xa0, 0x0018);
+	pci_write_config32(dev, 0xa4, 0x00000264);
+	pci_write_config16(dev, 0xa0, 0x0040);
+	pci_write_config32(dev, 0xa4, 0x00220043);
+}
+
+static struct device_operations sata_ops  = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = sata_init,
+	.scan_bus         = 0,
+	.enable           = i82801xx_enable,
+};
+
+/* i82801eb */
+static struct pci_driver i82801eb_sata_driver __pci_driver = {
+	.ops    = &sata_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24d1,
+};
+
+/* i82801er */
+static struct pci_driver i82801er_sata_driver __pci_driver = {
+	.ops    = &sata_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24df,
+};

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_smbus.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_smbus.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_smbus.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,94 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2005 Yinghai Lu <yinghailu at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <smbus.h>
+#include <pci.h>
+#include <arch/io.h>
+#include "i82801_model_specific.h"
+#include "i82801xx.h"
+#include "i82801_smbus.h"
+
+static int smbus_read_byte(struct bus *bus, device_t dev, uint8_t address)
+{
+	unsigned device;
+	struct resource *res;
+
+	device = dev->path.u.i2c.device;
+	res = find_resource(bus->dev, 0x20);
+	
+	return do_smbus_read_byte(res->base, device, address);
+}
+
+static struct smbus_bus_operations lops_smbus_bus = {
+	.read_byte  = smbus_read_byte,
+};
+
+static struct device_operations smbus_ops = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = 0,
+	.scan_bus         = scan_static_bus,
+	.enable           = i82801er_enable,
+	.ops_smbus_bus    = &lops_smbus_bus,
+};
+
+/* i82801aa */
+static struct pci_driver smbus_driver __pci_driver = {
+	.ops    = &smbus_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2413,
+};
+
+/* i82801ab */
+static struct pci_driver smbus_driver __pci_driver = {
+	.ops    = &smbus_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2423,
+};
+
+/* i82801ba */
+static struct pci_driver smbus_driver __pci_driver = {
+	.ops    = &smbus_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2443,
+};
+
+/* i82801ca */
+static struct pci_driver smbus_driver __pci_driver = {
+	.ops    = &smbus_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2483,
+};
+
+/* i82801db and i82801dbm */
+static struct pci_driver smbus_driver __pci_driver = {
+	.ops    = &smbus_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24c3,
+};
+
+/* i82801eb and i82801er */
+static struct pci_driver smbus_driver __pci_driver = {
+	.ops    = &smbus_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24d3,
+};
+

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_smbus.h
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_smbus.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_smbus.h	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,181 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2005 Yinghai Lu <yinghailu at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <device/smbus_def.h>
+
+static void smbus_delay(void)
+{
+	inb(0x80);
+}
+
+static int smbus_wait_until_ready(void)
+{
+	unsigned loops = SMBUS_TIMEOUT;
+	unsigned char byte;
+	do {
+		smbus_delay();
+		if (--loops == 0)
+			break;
+		byte = inb(SMBUS_IO_BASE + SMBHSTSTAT);
+	} while(byte & 1);
+	return loops?0:-1;
+}
+
+static int smbus_wait_until_done(void)
+{
+	unsigned loops = SMBUS_TIMEOUT;
+	unsigned char byte;
+	do {
+	        smbus_delay();
+	        if (--loops == 0)
+	               break;
+	        byte = inb(SMBUS_IO_BASE + SMBHSTSTAT);
+	} while((byte & 1) || (byte & ~((1<<6)|(1<<0))) == 0);
+	return loops?0:-1;
+}
+
+static int smbus_wait_until_blk_done(void)
+{
+	unsigned loops = SMBUS_TIMEOUT;
+	unsigned char byte;
+	do {
+	        smbus_delay();
+	        if (--loops == 0)
+	               break;
+	        byte = inb(SMBUS_IO_BASE + SMBHSTSTAT);
+	} while((byte & (1 << 7)) == 0);
+	return loops?0:-1;
+}
+
+static int do_smbus_read_byte(unsigned device, unsigned address)
+{
+	unsigned char global_status_register;
+	unsigned char byte;
+
+	if (smbus_wait_until_ready() < 0) {
+		return SMBUS_WAIT_UNTIL_READY_TIMEOUT;
+	}
+	/* Setup transaction */
+	/* Disable interrupts */
+	outb(inb(SMBUS_IO_BASE + SMBHSTCTL) & (~1), SMBUS_IO_BASE + SMBHSTCTL);
+	/* Set the device I'm talking too */
+	outb(((device & 0x7f) << 1) | 1, SMBUS_IO_BASE + SMBXMITADD);
+	/* Set the command/address... */
+	outb(address & 0xff, SMBUS_IO_BASE + SMBHSTCMD);
+	/* Set up for a byte data read */
+	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xe3) | (0x2 << 2), (SMBUS_IO_BASE + SMBHSTCTL));
+	/* Clear any lingering errors, so the transaction will run */
+	outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT);
+
+	/* Clear the data byte...*/
+	outb(0, SMBUS_IO_BASE + SMBHSTDAT0);
+
+	/* Start the command */
+	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) | 0x40), SMBUS_IO_BASE + SMBHSTCTL);
+
+	/* Poll for transaction completion */
+	if (smbus_wait_until_done() < 0) {
+		return SMBUS_WAIT_UNTIL_DONE_TIMEOUT;
+	}
+
+	global_status_register = inb(SMBUS_IO_BASE + SMBHSTSTAT);
+
+	/* Ignore the "In Use" status... */
+	global_status_register &= ~(3 << 5);
+
+	/* Read results of transaction */
+	byte = inb(SMBUS_IO_BASE + SMBHSTDAT0);
+	if (global_status_register != (1 << 1)) {
+		return SMBUS_ERROR;
+	}
+	return byte;
+}
+
+/* This function is neither used nor tested by me (Corey Osgood), the author 
+(Yinghai) probably tested/used it on i82801er */
+static int do_smbus_write_block(unsigned device, unsigned length, unsigned cmd, 
+		 unsigned data1, unsigned data2)
+{
+#warning "do_smbus_write_block is commented out"
+	print_err("Untested smbus_write_block called\r\n");
+#if 0
+	unsigned char global_control_register;
+	unsigned char global_status_register;
+	unsigned char byte;
+	unsigned char stat;
+	int i;
+
+	/* Clear the PM timeout flags, SECOND_TO_STS */
+	outw(inw(0x0400 + 0x66), 0x0400 + 0x66);
+	
+	if (smbus_wait_until_ready(SMBUS_IO_BASE) < 0) {
+		return -2;
+	}
+	
+	/* Setup transaction */
+	/* Obtain ownership */
+	outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), SMBUS_IO_BASE + SMBHSTSTAT);
+	for(stat = 0; (stat & 0x40) == 0; ) {
+	stat = inb(SMBUS_IO_BASE + SMBHSTSTAT);
+	}
+	/* Clear the done bit */
+	outb(0x80, SMBUS_IO_BASE + SMBHSTSTAT);
+	/* Disable interrupts */
+	outb(inb(SMBUS_IO_BASE + SMBHSTCTL) & (~1), SMBUS_IO_BASE + SMBHSTCTL);
+	
+	/* Set the device I'm talking too */
+	outb(((device & 0x7f) << 1), SMBUS_IO_BASE + SMBXMITADD);
+	
+	/* Set the command address */
+	outb(cmd & 0xff, SMBUS_IO_BASE + SMBHSTCMD);
+	
+	/* Set the block length */
+	outb(length & 0xff, SMBUS_IO_BASE + SMBHSTDAT0);
+	
+	/* Try sending out the first byte of data here */
+	byte = (data1 >> (0)) & 0x0ff;
+	outb(byte, SMBUS_IO_BASE + SMBBLKDAT);
+	/* Issue a block write command */
+	outb((inb(SMBUS_IO_BASE + SMBHSTCTL) & 0xe3) | (0x5 << 2) | 0x40, 
+			SMBUS_IO_BASE + SMBHSTCTL);
+
+	for(i = 0;i < length; i++) {
+		
+		/* Poll for transaction completion */
+		if (smbus_wait_until_blk_done(SMBUS_IO_BASE) < 0) {
+			return -3;
+		}
+		
+		/* Load the next byte */
+		if(i > 3)
+			byte = (data2 >> (i % 4)) & 0x0ff;
+		else
+			byte = (data1 >> (i)) & 0x0ff;
+		outb(byte, SMBUS_IO_BASE + SMBBLKDAT);
+		
+		/* Clear the done bit */
+		outb(inb(SMBUS_IO_BASE + SMBHSTSTAT), 
+				SMBUS_IO_BASE + SMBHSTSTAT);
+	}
+
+	print_debug("SMBUS Block complete\r\n");
+	return 0;
+#endif
+}

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_usb.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_usb.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_usb.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,130 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Corey Osgood <corey.osgood at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include "i82801xx.h"
+
+static void usb_init(struct device *dev)
+{
+/* TODO: Any init needed? Some ports have it, others don't */
+}
+
+static struct device_operations usb_ops  = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = usb_init,
+	.scan_bus         = 0,
+	.enable           = i82801xx_enable,
+};
+
+/* i82801aa */
+static struct pci_driver i82801aa_usb_1 __pci_driver = {
+	.ops    = &usb_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x2412,
+};
+
+/* i82801ab */
+static struct pci_driver i82801ab_usb_1 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x2422,
+};
+
+/* i82801ba */
+static struct pci_driver i82801ba_usb_1 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x2442,
+};
+
+static struct pci_driver i82801ba_usb_2 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x2444,
+};
+
+/* i82801ca */
+static struct pci_driver i82801ca_usb_1 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x2482,
+};
+
+static struct pci_driver i82801ca_usb_2 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x2484,
+};
+
+static struct pci_driver i82801ca_usb_3 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x2487,
+};
+
+/* i82801db and i82801dbm */
+static struct pci_driver i82801db_usb_1 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x24c2,
+};
+
+static struct pci_driver i82801db_usb_2 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x24c4,
+};
+
+static struct pci_driver i82801db_usb_3 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x24c7,
+};
+
+/* i82801eb and i82801er */
+static struct pci_driver i82801ex_usb_1 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x24d2,
+};
+
+static struct pci_driver i82801ex_usb_2 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x24d4,
+};
+
+static struct pci_driver i82801ex_usb_3 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x24d7,
+};
+
+static struct pci_driver i82801ex_usb_4 __pci_driver = {
+        .ops    = &usb_ops,
+        .vendor = PCI_VENDOR_ID_INTEL,
+        .device = 0x24de,
+};

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_usb_ehci.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_usb_ehci.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_usb_ehci.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,81 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2005 Tyan Computer
+ * (Written by Yinghai Lu <yinghailu at gmail.com> for Tyan Computer>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <device/pci_ops.h>
+#include "i82801xx.h"
+
+static void usb_ehci_init(struct device *dev)
+{
+	/* TODO: Is any special init really needed? */
+	uint32_t cmd;
+
+	printk_debug("EHCI: Setting up controller.. ");
+	cmd = pci_read_config32(dev, PCI_COMMAND);
+	pci_write_config32(dev, PCI_COMMAND, 
+		cmd | PCI_COMMAND_MASTER);
+
+	printk_debug("done.\n");
+}
+
+static void usb_ehci_set_subsystem(device_t dev, unsigned vendor, unsigned device)
+{
+	uint8_t access_cntl;
+	access_cntl = pci_read_config8(dev, 0x80);
+	/* Enable writes to protected registers */
+	pci_write_config8(dev, 0x80, access_cntl | 1);
+	/* Write the subsystem vendor and device id */
+	pci_write_config32(dev, PCI_SUBSYSTEM_VENDOR_ID, 
+		((device & 0xffff) << 16) | (vendor & 0xffff));
+	/* Restore protection */
+	pci_write_config8(dev, 0x80, access_cntl);
+}
+
+static struct pci_operations lops_pci = {
+	.set_subsystem = &usb_ehci_set_subsystem,
+};
+
+static struct device_operations usb_ehci_ops  = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = usb_ehci_init,
+	.scan_bus         = 0,
+	.enable           = i82801xx_enable,
+	.ops_pci          = &lops_pci,
+};
+
+/* i82801db and i82801dbm */
+static struct pci_driver i82801db_usb_ehci __pci_driver = {
+	.ops    = &usb_ehci_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24cd,
+};
+
+/* i82801eb and i82801er */
+static struct pci_driver i82801ex_usb_ehci __pci_driver = {
+	.ops    = &usb_ehci_ops,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x24dd,
+};

Added: trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_watchdog.c
===================================================================
--- trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_watchdog.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/southbridge/intel/i82801xx/i82801xx_watchdog.c	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,51 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2006 John Dufresne <jon.dufresne at gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+#include <console/console.h>
+#include <arch/io.h>
+#include <device/device.h>
+#include <device/pci.h>
+
+/* TODO: I'm fairly sure the same functionality is provided elsewhere */
+
+void watchdog_off(void)
+{
+        device_t dev;
+        unsigned long value,base;
+
+	/* turn off the ICH5 watchdog */
+        dev = dev_find_slot(0, PCI_DEVFN(0x1f,0));
+        
+        /* Enable I/O space */
+        value = pci_read_config16(dev, 0x04);
+        value |= (1 << 10);
+        pci_write_config16(dev, 0x04, value);
+        /* Get TCO base */
+        base = (pci_read_config32(dev, 0x40) & 0x0fffe) + 0x60;
+        /* Disable the watchdog timer */
+        value = inw(base + 0x08);
+        value |= 1 << 11;
+        outw(value, base + 0x08);
+        /* Clear TCO timeout status */
+        outw(0x0008, base + 0x04);
+        outw(0x0002, base + 0x06);
+        printk_debug("ICH Watchdog disabled\r\n");
+}
+
+

Added: trunk/LinuxBIOSv2/targets/asus/mew-vm/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/targets/asus/mew-vm/Config.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/targets/asus/mew-vm/Config.lb	2007-06-14 06:10:57 UTC (rev 2719)
@@ -0,0 +1,28 @@
+# Config file for asus mew-vm board
+# This will make a target directory of ./mew-vm
+
+target mew-vm
+mainboard asus/mew-vm
+
+## Without VGA BIOS
+option ROM_SIZE = 512 * 1024
+## With VGA BIOS (32k)
+#option ROM_SIZE = (512 * 1024) - (32 * 1024)
+
+romimage "normal"
+	option USE_FALLBACK_IMAGE=0
+	option ROM_IMAGE_SIZE=0x10000
+	option LINUXBIOS_EXTRA_VERSION=".0Normal"
+#	payload /etc/hosts
+	payload /home/amp/filo-0.5/filo.elf
+end
+
+romimage "fallback" 
+	option USE_FALLBACK_IMAGE=1
+	option ROM_IMAGE_SIZE=0x10000
+	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
+#	payload /etc/hosts
+	payload /home/amp/filo-0.5/filo.elf
+end
+
+buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"




From stepan at coresystems.de  Thu Jun 14 08:11:38 2007
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 14 Jun 2007 08:11:38 +0200
Subject: [LinuxBIOS] [PATCH] Add Asus MEW-VM, Intel i82810,
	and generic	i82801
In-Reply-To: <20070613234148.c97tnkb6n4kcc4ko@www.smittys.pointclark.net>
References: <46706062.1070605@gmail.com>
	<20070613222912.gsudwijb0gsw080c@www.smittys.pointclark.net>
	<20070614023535.6925.qmail@cdy.org>
	<20070613234148.c97tnkb6n4kcc4ko@www.smittys.pointclark.net>
Message-ID: <20070614061138.GA2715@coresystems.de>

* Joseph Smith <joe at smittys.pointclark.net> [070614 05:41]:
> Ok,
> Acked-by: Joseph Smith <joe at smittys.pointclark.net>

 r2719

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/



From info at coresystems.de  Thu Jun 14 08:56:37 2007
From: info at coresystems.de (LinuxBIOS information)
Date: Thu, 14 Jun 2007 08:56:37 +0200
Subject: [LinuxBIOS] r2719 build service
Message-ID: <E1HyjG1-0006JX-Fp@khepri.openbios.org>

Dear LinuxBIOS readers!

This is the automated build check service of LinuxBIOS.

The developer "stepan" checked in revision 2719 to
the LinuxBIOS source repository and caused the following 
changes:

Change Log:
This patch adds support for the Intel i82810 northbridge and various i82801xx
southbridges, along with the Asus MEW-VM. With this, my machine attempts to
boot linux, but does so very slowly and fails during the boot process, probably
because of the irq tables.

Signed-off-by: Corey Osgood <corey.osgood at gmail.com>
Acked-by: Joseph Smith <joe at smittys.pointclark.net>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of arima:hdama is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2719&device=hdama&vendor=arima
Configuration of artecgroup:dbe61 is still broken
Configuration of asus:mew-vm is still broken
Compilation of ibm:e325 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2719&device=e325&vendor=ibm
Compilation of ibm:e326 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2719&device=e326&vendor=ibm
Compilation of iei:juki-511p is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2719&device=juki-511p&vendor=iei
Compilation of iwill:dk8s2 is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2719&device=dk8s2&vendor=iwill
Compilation of iwill:dk8x is still broken
See the error log at http://qa.linuxbios.org/log_buildbrd.php?revision=2719&device=dk8x&vendor=iwill


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     LinuxBIOS automatic build system





From corey.osgood at gmail.com  Thu Jun 14 09:37:31 2007
From: corey.osgood at gmail.com (Corey Osgood)
Date: Thu, 14 Jun 2007 03:37:31 -0400
Subject: [LinuxBIOS] [PATCH] Fix previous patch for Asus MEW-VM
In-Reply-To: <20070614061138.GA2715@coresystems.de>
References: <46706062.1070605@gmail.com>	<20070613222912.gsudwijb0gsw080c@www.smittys.pointclark.net>	<20070614023535.6925.qmail@cdy.org>	<20070613234148.c97tnkb6n4kcc4ko@www.smittys.pointclark.net>
	<20070614061138.GA2715@coresystems.de>
Message-ID: <4670F03B.10306@gmail.com>

Stefan Reinauer wrote:
> * Joseph Smith <joe at smittys.pointclark.net> [070614 05:41]:
>   
>> Ok,
>> Acked-by: Joseph Smith <joe at smittys.pointclark.net>
>>     
>
>  r2719
>
>   

Thanks guys. Somehow I let the i82810 slip by completely, and missed a
couple lines when I was manually editing the i82801. Attached patch
fixes those.

Signed-off-by: Corey Osgood <corey.osgood at gmail.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asus_mew_fix.patch
Type: text/x-patch
Size: 28481 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070614/2f3061cf/attachment.patch>

From joe at smittys.pointclark.net  Thu Jun 14 10:36:05 2007
From: joe at smittys.pointclark.net (Joseph Smith)
Date: Thu, 14 Jun 2007 04:36:05 -0400
Subject: [LinuxBIOS] [PATCH] Fix previous patch for Asus MEW-VM
In-Reply-To: <4670F03B.10306@gmail.com>
References: <46706062.1070605@gmail.com>
	<20070613222912.gsudwijb0gsw080c@www.smittys.pointclark.net>
	<20070614023535.6925.qmail@cdy.org>
	<20070613234148.c97tnkb6n4kcc4ko@www.smittys.pointclark.net>
	<20070614061138.GA2715@coresystems.de> <4670F03B.10306@gmail.com>
Message-ID: <20070614043605.lfu9ilr81wkcos4s@www.smittys.pointclark.net>

Quoting Corey Osgood <corey.osgood at gmail.com>:

> Stefan Reinauer wrote:
>> * Joseph Smith <joe at smittys.pointclark.net> [070614 05:41]:
>>
>>> Ok,
>>> Acked-by: Joseph Smith <joe at smittys.pointclark.net>
>>>
>>
>>  r2719
>>
>>
>
> Thanks guys. Somehow I let the i82810 slip by completely, and missed a
> couple lines when I was manually editing the i82801. Attached patch
> fixes those.
>
> Signed-off-by: Corey Osgood <corey.osgood at gmail.com>
>

Oh your right Corey, Oops. We should probibly get your patch commited  
asap right?

Acked-by: Joseph Smith <joe at smittys.pointclark.net>

Thanks - Joe



From thomas.ekstrand at gmail.com  Thu Jun 14 11:55:45 2007
From: thomas.ekstrand at gmail.com (Thomas Ekstrand)
Date: Thu, 14 Jun 2007 11:55:45 +0200
Subject: [LinuxBIOS] buggy burn with uniflash ? (was "EPIA hang after
	patch")
In-Reply-To: <20070614055552.GD4302@bloms.de>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
	<20070612175511.GA3652@bloms.de>
	<f7085c470706131137p30e8d8c2n933156c1fe9f48d2@mail.gmail.com>
	<20070613200026.GA4302@bloms.de> <46705E6F.6090103@gmail.com>
	<20070614045320.GB4302@bloms.de> <4670CDF8.80108@gmail.com>
	<20070614055552.GD4302@bloms.de>
Message-ID: <f7085c470706140255v6d57d3e8k8df928255b2cca54@mail.gmail.com>

2007/6/14, Dieter Bloms <linuxbios at bloms.de>:
> Hi,
>
> On Thu, Jun 14, Corey Osgood wrote:
>
> > Alright, looking just at the possible flashing issue for the moment, if
> > you flash the original bios (to your spare chip) does it work correctly?
> > And please remind me, what board and flash part are you using? Epia?
> > Also, what does flashrom do?
>
> I've a commell lv671 board with W39V040FA bios chip and Winbound
> w83627hf-aw super-io chip.
>
> If I burn the factory bios the page count increase from 0001 to 0007 and
> takes about 20 seconds/page:
>
> video:/usr/src/neues_bios/LinuxBIOSv2/util/flashrom# flashrom -w originalbios.img
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "ICH4/ICH4-L": Enabling flash write... OK.
> W39V040FA found at physical address: 0xfff80000
> Flash part is W39V040FA (512 KB)
> Flash image seems to be a legacy BIOS. Disabling checks.
> Programming Page: 0007 at address: 0x00070000
> video:/usr/src/neues_bios/LinuxBIOSv2/util/flashrom# flashrom -v originalbios.img
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "ICH4/ICH4-L": Enabling flash write... OK.
> W39V040FA found at physical address: 0xfff80000
> Flash part is W39V040FA (512 KB)
> Flash image seems to be a legacy BIOS. Disabling checks.
> Verifying flash - FAILED
>
> the same with linuxbios, but the burning takes about 10 seconds for the
> whole burn:
>
> video:/usr/src/neues_bios/LinuxBIOSv2/util/flashrom# flashrom -w ../../targets/commell/lv671/lv671/linuxbios.rom
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "ICH4/ICH4-L": Enabling flash write... OK.
> W39V040FA found at physical address: 0xfff80000
> Flash part is W39V040FA (512 KB)
> Note: If the following flash access fails, you might need to specify -m
> <vendor>:<mainboard>
> Programming Page: 0007 at address: 0x00070000
> video:/usr/src/neues_bios/LinuxBIOSv2/util/flashrom# flashrom -v ../../targets/commell/lv671/lv671/linuxbios.rom
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "ICH4/ICH4-L": Enabling flash write... OK.
> W39V040FA found at physical address: 0xfff80000
> Flash part is W39V040FA (512 KB)
> Note: If the following flash access fails, you might need to specify -m
> <vendor>:<mainboard>
> Verifying flash - FAILED

Have you tried reading the flash after burning and compare that image
to the one you used when burning? I always get verify fail but it
works anyway.

/Thomas



From thomas.ekstrand at gmail.com  Thu Jun 14 12:10:13 2007
From: thomas.ekstrand at gmail.com (Thomas Ekstrand)
Date: Thu, 14 Jun 2007 12:10:13 +0200
Subject: [LinuxBIOS] bigger flash part for via/epia
Message-ID: <f7085c470706140310p141aa06em61228802d76795ce@mail.gmail.com>

Hi!

I want a bigger bios flash so I'm wondering, what is the maximum size
possible for a flash memory chip to a via epia board?
The original is only 256KByte.

Any recommended part numbers are welcome!

Thanks in advance!
/Thomas



From stuge-linuxbios at cdy.org  Thu Jun 14 12:12:29 2007
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu, 14 Jun 2007 12:12:29 +0200
Subject: [LinuxBIOS] bigger flash part for via/epia
In-Reply-To: <f7085c470706140310p141aa06em61228802d76795ce@mail.gmail.com>
References: <f7085c470706140310p141aa06em61228802d76795ce@mail.gmail.com>
Message-ID: <20070614101230.15034.qmail@cdy.org>

On Thu, Jun 14, 2007 at 12:10:13PM +0200, Thomas Ekstrand wrote:
> I want a bigger bios flash so I'm wondering, what is the maximum
> size possible for a flash memory chip to a via epia board?

4Mbit or 512kbyte


> Any recommended part numbers are welcome!

SST39SF040-70-4C-NHE

I have stock in Sweden and will gladly sell single quantities but
can't ship until on Monday.


//Peter



From thomas.ekstrand at gmail.com  Thu Jun 14 13:07:17 2007
From: thomas.ekstrand at gmail.com (Thomas Ekstrand)
Date: Thu, 14 Jun 2007 13:07:17 +0200
Subject: [LinuxBIOS] bigger flash part for via/epia
In-Reply-To: <20070614101230.15034.qmail@cdy.org>
References: <f7085c470706140310p141aa06em61228802d76795ce@mail.gmail.com>
	<20070614101230.15034.qmail@cdy.org>
Message-ID: <f7085c470706140407t5e60ed9ev4ca9254619adeb58@mail.gmail.com>

2007/6/14, Peter Stuge <stuge-linuxbios at cdy.org>:
> On Thu, Jun 14, 2007 at 12:10:13PM +0200, Thomas Ekstrand wrote:
> > I want a bigger bios flash so I'm wondering, what is the maximum
> > size possible for a flash memory chip to a via epia board?
>
> 4Mbit or 512kbyte
>
>
> > Any recommended part numbers are welcome!
>
> SST39SF040-70-4C-NHE
>
> I have stock in Sweden and will gladly sell single quantities but
> can't ship until on Monday.
>
>

Thanks!
I'll let you know when I need one!
Just out of curiousity, how much?

/Thomas



From hawke at hawkesnest.net  Thu Jun 14 13:29:56 2007
From: hawke at hawkesnest.net (Alex Mauer)
Date: Thu, 14 Jun 2007 06:29:56 -0500
Subject: [LinuxBIOS] Strange reset loading linux on epia! was "EPIA hang
	after patch"
In-Reply-To: <f7085c470706131132u742b8f7axebf675808f488dc1@mail.gmail.com>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>	<20070612232631.GB12600@greenwood>	<466FDFC7.1030108@hewson-venieri.com>
	<f4p9og$tt1$1@sea.gmane.org>
	<f7085c470706131132u742b8f7axebf675808f488dc1@mail.gmail.com>
Message-ID: <f4r8s2$t7d$1@sea.gmane.org>

Thomas Ekstrand wrote:
> That was the problem! Once I've blacklisted the module it comes up
> like it should.
> 

Did you need to blacklist both, or just via_agp?

-Alex Mauer "hawke"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20070614/d0769217/attachment.sig>

From thomas.ekstrand at gmail.com  Thu Jun 14 14:01:02 2007
From: thomas.ekstrand at gmail.com (Thomas Ekstrand)
Date: Thu, 14 Jun 2007 14:01:02 +0200
Subject: [LinuxBIOS] Strange reset loading linux on epia! was "EPIA hang
	after patch"
In-Reply-To: <f4r8s2$t7d$1@sea.gmane.org>
References: <f7085c470706120956j37863d3cy1c27a85270c891c4@mail.gmail.com>
	<20070612232631.GB12600@greenwood>
	<466FDFC7.1030108@hewson-venieri.com> <f4p9og$tt1$1@sea.gmane.org>
	<f7085c470706131132u742b8f7axebf675808f488dc1@mail.gmail.com>
	<f4r8s2$t7d$1@sea.gmane.org>
Message-ID: <f7085c470706140501l6b5ecfbcned240c1c32dcf725@mail.gmail.com>

2007/6/14, Alex Mauer <hawke at hawkesnest.net>:
> Thomas Ekstrand wrote:
> > That was the problem! Once I've blacklisted the module it comes up
> > like it should.
> >
>
> Did you need to blacklist both, or just via_agp?
>
I don't know whether I had to or not but I blacklisted both.
I can test and see what happens if I blacklist either one and post the
results back here if you like?

/Thomas



From svn at openbios.org  Thu Jun 14 14:02:38 2007
From: svn at openbios.org (svn at openbios.org)
Date: Thu, 14 Jun 2007 14:02:38 +0200
Subject: [LinuxBIOS] r2720 - in trunk/LinuxBIOSv2/src/northbridge/intel: .
	i82810
Message-ID: <mailman.394.1355071121.16123.coreboot@coreboot.org>

Author: uwe
Date: 2007-06-14 14:02:38 +0200 (Thu, 14 Jun 2007)
New Revision: 2720

Added:
   trunk/LinuxBIOSv2/src/northbridge/intel/i82810/
   trunk/LinuxBIOSv2/src/northbridge/intel/i82810/Config.lb
   trunk/LinuxBIOSv2/src/northbridge/intel/i82810/chip.h
   trunk/LinuxBIOSv2/src/northbridge/intel/i82810/debug.c
   trunk/LinuxBIOSv2/src/northbridge/intel/i82810/i82810.h
   trunk/LinuxBIOSv2/src/northbridge/intel/i82810/northbridge.c
   trunk/LinuxBIOSv2/src/northbridge/intel/i82810/northbridge.h
   trunk/LinuxBIOSv2/src/northbridge/intel/i82810/raminit.c
   trunk/LinuxBIOSv2/src/northbridge/intel/i82810/raminit.h
Log:
Add initial support for the Intel 82810 northbridge.

Signed-off-by: Corey Osgood <corey.osgood at gmail.com>
Acked-by: Joseph Smith <joe at smittys.pointclark.net>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Added: trunk/LinuxBIOSv2/src/northbridge/intel/i82810/Config.lb
===================================================================
--- trunk/LinuxBIOSv2/src/northbridge/intel/i82810/Config.lb	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/northbridge/intel/i82810/Config.lb	2007-06-14 12:02:38 UTC (rev 2720)
@@ -0,0 +1,22 @@
+##
+## This file is part of the LinuxBIOS project.
+##
+## Copyright (C) 2007 Corey Osgood <corey at slightlyhackish.com>
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+config chip.h
+object northbridge.o

Added: trunk/LinuxBIOSv2/src/northbridge/intel/i82810/chip.h
===================================================================
--- trunk/LinuxBIOSv2/src/northbridge/intel/i82810/chip.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/northbridge/intel/i82810/chip.h	2007-06-14 12:02:38 UTC (rev 2720)
@@ -0,0 +1,25 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Corey Osgood <corey at slightlyhackish.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+struct northbridge_intel_i82810_config
+{
+};
+
+extern struct chip_operations northbridge_intel_i82810_ops;

Added: trunk/LinuxBIOSv2/src/northbridge/intel/i82810/debug.c
===================================================================
--- trunk/LinuxBIOSv2/src/northbridge/intel/i82810/debug.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/northbridge/intel/i82810/debug.c	2007-06-14 12:02:38 UTC (rev 2720)
@@ -0,0 +1,35 @@
+
+static void dump_spd_registers(const struct mem_controller *ctrl)
+{
+	int i;
+	print_debug("\r\n");
+	for(i = 0; i < 4; i++) {
+		unsigned device;
+		device = ctrl->channel0[i];
+		if (device) {
+			int j;
+			print_debug("dimm: "); 
+			print_debug_hex8(i); 
+			print_debug(".0: ");
+			print_debug_hex8(device);
+			for(j = 0; j < 256; j++) {
+				int status;
+				unsigned char byte;
+				if ((j & 0xf) == 0) {
+					print_debug("\r\n");
+					print_debug_hex8(j);
+					print_debug(": ");
+				}
+				status = smbus_read_byte(device, j);
+				if (status < 0) {
+					print_debug("bad device\r\n");
+					break;
+				}
+				byte = status & 0xff;
+				print_debug_hex8(byte);
+				print_debug_char(' ');
+			}
+			print_debug("\r\n");
+		}
+	}
+}

Added: trunk/LinuxBIOSv2/src/northbridge/intel/i82810/i82810.h
===================================================================
--- trunk/LinuxBIOSv2/src/northbridge/intel/i82810/i82810.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/northbridge/intel/i82810/i82810.h	2007-06-14 12:02:38 UTC (rev 2720)
@@ -0,0 +1,59 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Corey Osgood <corey at slightlyhackish.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+/*
+ * Datasheet:
+ *   - Name: Intel 810 Chipset:
+ *           82810/82810-DC100 Graphics and Memory Controller Hub (GMCH)
+ *   - URL: http://www.intel.com/design/chipsets/datashts/290656.htm
+ *   - PDF: ftp://download.intel.com/design/chipsets/datashts/29065602.pdf
+ *   - Order Number: 290656-002
+ */
+
+/*
+ * PCI Configuration Registers.
+ *
+ * Any addresses between 0x00 and 0xff not listed below are reserved and
+ * should not be touched.
+ */
+
+#define VID	0x00 /* Vendor Identification   */
+#define DID	0x02 /* Device Identification   */
+#define PCICMD	0x04 /* PCI Command Register    */
+#define PCISTS	0x06 /* PCI Status Register     */
+#define RID	0x08 /* Revision Identification */
+#define SUBC	0x0a /* Sub-Class Code          */
+#define BCC	0x0b /* Base Class Code         */
+#define MLT	0x0d /* Master Latency Timer    */
+#define HDR	0x0e /* Header Type             */
+#define SVID	0x2c /* Subsystem Vendor Identification  */
+#define SID	0x2e /* Subsystem Identification         */
+#define CAPPTR	0x34 /* Capabilities Pointer             */
+
+/* TODO: Descriptions  */
+#define GMCHCFG	0x50
+#define PAM	0x51
+#define DRP	0x52
+#define DRAMT	0x53
+#define FDHC	0x58
+#define SMRAM	0x70 /* System Management RAM Control */
+#define MISSC	0x72
+#define MISSC2	0x80
+#define BUFF_SC	0x92

Added: trunk/LinuxBIOSv2/src/northbridge/intel/i82810/northbridge.c
===================================================================
--- trunk/LinuxBIOSv2/src/northbridge/intel/i82810/northbridge.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/northbridge/intel/i82810/northbridge.c	2007-06-14 12:02:38 UTC (rev 2720)
@@ -0,0 +1,217 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Corey Osgood <corey at slightlyhackish.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <console/console.h>
+#include <arch/io.h>
+#include <stdint.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ids.h>
+#include <stdlib.h>
+#include <string.h>
+#include <bitops.h>
+#include "chip.h"
+#include "northbridge.h"
+#include "i82810.h"
+
+static void northbridge_init(device_t dev) 
+{
+	printk_spew("Northbridge init\n");
+}
+
+static struct device_operations northbridge_operations = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = northbridge_init,
+	.enable           = 0,
+	.ops_pci          = 0,
+};
+
+static struct pci_driver northbridge_driver __pci_driver = {
+	.ops = &northbridge_operations,
+	.vendor = PCI_VENDOR_ID_INTEL,
+	.device = 0x7120,
+};
+
+#define BRIDGE_IO_MASK (IORESOURCE_IO | IORESOURCE_MEM)
+
+static void pci_domain_read_resources(device_t dev)
+{
+	struct resource *resource;
+	unsigned reg;
+
+	/* Initialize the system wide io space constraints */
+	resource = new_resource(dev, IOINDEX_SUBTRACTIVE(0, 0));
+	resource->base = 0x400;
+	resource->limit = 0xffffUL;
+	resource->flags = IORESOURCE_IO | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+
+	/* Initialize the system wide memory resources constraints */
+	resource = new_resource(dev, IOINDEX_SUBTRACTIVE(1, 0));
+	resource->limit = 0xffffffffULL;
+	resource->flags = IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+}
+
+static void ram_resource(device_t dev, unsigned long index,
+        unsigned long basek, unsigned long sizek)
+{
+	struct resource *resource;
+
+	if (!sizek) {
+		return;
+	}
+	resource = new_resource(dev, index);
+	resource->base  = ((resource_t)basek) << 10;
+	resource->size  = ((resource_t)sizek) << 10;
+	resource->flags =  IORESOURCE_MEM | IORESOURCE_CACHEABLE | \
+		IORESOURCE_FIXED | IORESOURCE_STORED | IORESOURCE_ASSIGNED;
+}
+
+static void tolm_test(void *gp, struct device *dev, struct resource *new)
+{
+	struct resource **best_p = gp;
+	struct resource *best;
+	best = *best_p;
+	if (!best || (best->base > new->base)) {
+		best = new;
+	}
+	*best_p = best;
+}
+
+static uint32_t find_pci_tolm(struct bus *bus)
+{
+	struct resource *min;
+	uint32_t tolm;
+	min = 0;
+	search_bus_resources(bus, IORESOURCE_MEM, IORESOURCE_MEM, tolm_test, &min);
+	tolm = 0xffffffffUL;
+	if (min && tolm > min->base) {
+		tolm = min->base;
+	}
+	return tolm;
+}
+
+/* Table which returns the RAM size in MB when fed the DRP[7:4] or [3:0] value.
+ * Note that 2 is a value which the DRP should never be programmed to.
+ * Some size values appear twice, due to single-sided vs dual-sided banks.
+ */
+static int translate_i82810_to_mb[] = {
+/* DRP	0  1 (2) 3   4   5   6   7   8   9   A   B   C    D    E    F */
+/* MB */0, 8, 0, 16, 16, 24, 32, 32, 48, 64, 64, 96, 128, 128, 192, 256,
+};
+
+static void pci_domain_set_resources(device_t dev)
+{
+	device_t mc_dev;
+	uint32_t pci_tolm;
+
+	pci_tolm = find_pci_tolm(&dev->link[0]);
+	mc_dev = dev->link[0].children;
+
+	if (mc_dev) {
+		/* Figure out which areas are/should be occupied by RAM.
+		 * This is all computed in kilobytes and converted to/from
+		 * the memory controller right at the edges.
+		 * Having different variables in different units is
+		 * too confusing to get right.  Kilobytes are good up to
+		 * 4 Terabytes of RAM...
+		 */
+		unsigned long tomk, tolmk;
+		int idx;
+		int drp_value;
+
+		/* First get the value for DIMM 0. */
+		drp_value = pci_read_config8(mc_dev, DRP);
+		/* Translate it to MB and add to tomk. */
+		tomk = (unsigned long)(translate_i82810_to_mb[drp_value & 0xf]);
+		/* Now do the same for DIMM 1. */
+		drp_value = drp_value >> 4; // >>= 4; //? mess with later
+		tomk += (unsigned long)(translate_i82810_to_mb[drp_value]);
+
+		printk_debug("Setting RAM size to %d MB\n", tomk);
+
+		/* Convert tomk from MB to KB. */
+		tomk = tomk << 10;
+
+		/* Compute the top of Low memory. */
+		tolmk = pci_tolm >> 10;
+		if (tolmk >= tomk) {
+			/* The PCI hole does does not overlap the memory. */
+			tolmk = tomk;
+		}
+
+		/* Report the memory regions. */
+		idx = 10;
+		ram_resource(dev, idx++, 0, 640);
+		ram_resource(dev, idx++, 1024, tolmk - 1024);
+	}
+	assign_resources(&dev->link[0]);
+}
+
+static unsigned int pci_domain_scan_bus(device_t dev, unsigned int max)
+{
+	max = pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, max);
+	return max;
+}
+
+static struct device_operations pci_domain_ops = {
+	.read_resources   = pci_domain_read_resources,
+	.set_resources    = pci_domain_set_resources,
+	.enable_resources = enable_childrens_resources,
+	.init             = 0,
+	.scan_bus         = pci_domain_scan_bus,
+};
+
+static void cpu_bus_init(device_t dev)
+{
+	initialize_cpus(&dev->link[0]);
+}
+
+static void cpu_bus_noop(device_t dev)
+{
+}
+
+static struct device_operations cpu_bus_ops = {
+	.read_resources   = cpu_bus_noop,
+	.set_resources    = cpu_bus_noop,
+	.enable_resources = cpu_bus_noop,
+	.init             = cpu_bus_init,
+	.scan_bus         = 0,
+};
+
+static void enable_dev(struct device *dev)
+{
+	struct device_path path;
+
+	/* Set the operations if it is a special bus type */
+	if (dev->path.type == DEVICE_PATH_PCI_DOMAIN) {
+		dev->ops = &pci_domain_ops;
+		pci_set_method(dev);
+	}
+	else if (dev->path.type == DEVICE_PATH_APIC_CLUSTER) {
+		dev->ops = &cpu_bus_ops;
+	}
+}
+
+struct chip_operations northbridge_intel_i82810_ops = {
+	CHIP_NAME("Intel 82810 Northbridge")
+	.enable_dev = enable_dev,
+};

Added: trunk/LinuxBIOSv2/src/northbridge/intel/i82810/northbridge.h
===================================================================
--- trunk/LinuxBIOSv2/src/northbridge/intel/i82810/northbridge.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/northbridge/intel/i82810/northbridge.h	2007-06-14 12:02:38 UTC (rev 2720)
@@ -0,0 +1,26 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Corey Osgood <corey at slightlyhackish.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef NORTHBRIDGE_INTEL_I82810_NORTHBRIDGE_H
+#define NORTHBRIDGE_INTEL_I82810_NORTHBRIDGE_H
+
+extern unsigned int i82810_scan_root_bus(device_t root, unsigned int max);
+
+#endif				/* NORTHBRIDGE_INTEL_I82810_NORTHBRIDGE_H */

Added: trunk/LinuxBIOSv2/src/northbridge/intel/i82810/raminit.c
===================================================================
--- trunk/LinuxBIOSv2/src/northbridge/intel/i82810/raminit.c	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/northbridge/intel/i82810/raminit.c	2007-06-14 12:02:38 UTC (rev 2720)
@@ -0,0 +1,327 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Uwe Hermann <uwe at hermann-uwe.de>
+ * Copyright (C) 2007 Corey Osgood <corey at slightlyhackish.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <spd.h>
+#include <sdram_mode.h>
+#include <delay.h>
+#include "i82810.h"
+
+/*-----------------------------------------------------------------------------
+Macros and definitions.
+-----------------------------------------------------------------------------*/
+
+/* Uncomment this to enable debugging output. */
+// #define DEBUG_RAM_SETUP 1
+
+/* Debugging macros. */
+#if defined(DEBUG_RAM_SETUP)
+#define PRINT_DEBUG(x)		print_debug(x)
+#define PRINT_DEBUG_HEX8(x)	print_debug_hex8(x)
+#define PRINT_DEBUG_HEX16(x)	print_debug_hex16(x)
+#define PRINT_DEBUG_HEX32(x)	print_debug_hex32(x)
+#define DUMPNORTH()		dump_pci_device(PCI_DEV(0, 0, 0))
+#else
+#define PRINT_DEBUG(x)
+#define PRINT_DEBUG_HEX8(x)
+#define PRINT_DEBUG_HEX16(x)
+#define PRINT_DEBUG_HEX32(x)
+#define DUMPNORTH()
+#endif
+
+/* DRAMT[7:5] - SDRAM Mode Select (SMS). */
+#define RAM_COMMAND_SELF_REFRESH 0x0 /* IE disable refresh */
+#define RAM_COMMAND_NORMAL	 0x1 /* Normal refresh, 15.6us/11.7us for 100/133MHz */
+#define RAM_COMMAND_NORMAL_FR	 0x2 /* Fast refresh, 7.8us/5.85us for 100/133MHz */
+#define RAM_COMMAND_NOP		 0x4
+#define RAM_COMMAND_PRECHARGE	 0x5
+#define RAM_COMMAND_MRS		 0x6
+#define RAM_COMMAND_CBR		 0x7
+
+/*-----------------------------------------------------------------------------
+SDRAM configuration functions.
+-----------------------------------------------------------------------------*/
+
+/**
+ * Send the specified RAM command to all DIMMs.
+ *
+ * @param Memory controller
+ * @param TODO
+ * @param TODO
+ */
+static void do_ram_command(const struct mem_controller *ctrl, uint32_t command,
+			   uint32_t addr_offset, uint32_t row_offset)
+{
+	int i;
+	uint8_t reg;
+
+	/* TODO: Support for multiple DIMMs. */
+
+	/* Configure the RAM command. */
+	reg = pci_read_config8(ctrl->d0, DRAMT);
+	reg &= 0x1f;		/* Clear bits 7-5. */
+	reg |= command << 5;
+	pci_write_config8(ctrl->d0, DRAMT, reg);
+
+	/* RAM_COMMAND_NORMAL affects only the memory controller and
+	   doesn't need to be "sent" to the DIMMs. */
+	/* if (command == RAM_COMMAND_NORMAL) return; */
+
+	PRINT_DEBUG("    Sending RAM command 0x");
+	PRINT_DEBUG_HEX8(reg);
+	PRINT_DEBUG(" to 0x");
+	PRINT_DEBUG_HEX32(0 + addr_offset); // FIXME
+	PRINT_DEBUG("\r\n");
+
+	/* Read from (DIMM start address + addr_offset). */
+	read32(0 + addr_offset);	//first offset is always 0
+	read32(row_offset + addr_offset);
+}
+
+/*-----------------------------------------------------------------------------
+DIMM-independant configuration functions.
+-----------------------------------------------------------------------------*/
+
+static void spd_set_dram_size(const struct mem_controller *ctrl, uint32_t row_offset)
+{
+	/* The variables drp and dimm_size have to be ints since all the
+	 * SMBus-related functions return ints, and its just easier this way.
+	 */
+	int i, drp, dimm_size;
+
+	drp = 0x00;
+	
+	for (i = 0; i < DIMM_SOCKETS; i++)
+	{
+		/* First check if a DIMM is actually present. */
+		if (smbus_read_byte(ctrl->channel0[i], 2) == 4) {
+			print_debug("Found DIMM in slot ");
+			print_debug_hex8(i);
+			print_debug("\r\n");
+
+			dimm_size = smbus_read_byte(ctrl->channel0[i], 31);
+
+			/* WISHLIST: would be nice to display it as decimal? */
+			print_debug("DIMM is 0x");
+			print_debug_hex8(dimm_size * 4);
+			print_debug("MB\r\n");
+
+			/* The i810 can't handle DIMMs larger than 128MB per
+			 * side. This will fail if the DIMM uses a
+			 * non-supported DRAM tech, and can't be used until
+			 * buffers are done dynamically.
+			 * Note: the factory BIOS just dies if it spots
+			 * this :D
+			 */
+			if(dimm_size > 32) {
+				print_err("DIMM row sizes larger than 128MB not" 
+							"supported on i810\r\n");
+				print_err("Attempting to treat as 128MB DIMM\r\n");
+				dimm_size = 32;
+			}
+
+			/* Set the row offset, in KBytes (should this be Kbits?) */
+			/* Note that this offset is the start of the next row. */
+			row_offset = (dimm_size * 4 * 1024);
+
+			/* This is the way I was doing this, it's provided mainly
+			 * as an alternative to the "new" way.
+			 */
+
+			#if 0
+			/* 8MB */
+			if(dimm_size == 0x2) dimm_size = 0x1;
+			/* 16MB */
+			else if(dimm_size == 0x4) dimm_size = 0x4;
+			/* 32MB */
+			else if(dimm_size == 0x8) dimm_size = 0x7;
+			/* 64 MB */
+			else if(dimm_size == 0x10) dimm_size = 0xa;
+			/* 128 MB */
+			else if(dimm_size == 0x20) dimm_size = 0xd;
+			else print_debug("Ram Size not supported\r\n");
+			#endif
+
+			/* This array is provided in raminit.h, because it got
+			 * extremely messy. The above way is cleaner, but
+			 * doesn't support any asymetrical/odd configurations.
+			 */
+			dimm_size = translate_spd_to_i82810[dimm_size];
+
+			print_debug("After translation, dimm_size is 0x");
+			print_debug_hex8(dimm_size);
+			print_debug("\r\n");
+
+			/* If the DIMM is dual-sided, the DRP value is +2 */
+			/* TODO: Figure out asymetrical configurations */
+			if ((smbus_read_byte(ctrl->channel0[i], 127) | 0xf) == 0xff) {
+				print_debug("DIMM is dual-sided\r\n");
+				dimm_size += 2;
+			}
+		} else {
+			print_debug("No DIMM found in slot ");
+			print_debug_hex8(i);
+			print_debug("\r\n");
+
+			/* If there's no DIMM in the slot, set the value to 0. */
+			dimm_size = 0x00;
+		}
+
+		/* Put in dimm_size to reflect the current DIMM. */
+		drp |= dimm_size << (i * 4);
+	}
+
+	print_debug("DRP calculated to 0x");
+	print_debug_hex8(drp);
+	print_debug("\r\n");
+
+	pci_write_config8(ctrl->d0, DRP, drp);
+}
+
+static void set_dram_timing(const struct mem_controller *ctrl)
+{
+	/* TODO, for now using default, hopefully safe values. */
+	// pci_write_config8(ctrl->d0, DRAMT, 0x00);
+}
+
+static void set_dram_buffer_strength(const struct mem_controller *ctrl)
+{
+	/* TODO: This needs to be set according to the DRAM tech
+	 * (x8, x16, or x32). Argh, Intel provides no docs on this!
+	 * Currently, it needs to be pulled from the output of
+	 * lspci -xxx Rx92
+	 */
+	pci_write_config16(ctrl->d0, BUFF_SC, 0x77da);
+}
+
+/*-----------------------------------------------------------------------------
+Public interface.
+-----------------------------------------------------------------------------*/
+
+/**
+ * TODO.
+ *
+ * @param Memory controller
+ */
+static void sdram_set_registers(const struct mem_controller *ctrl)
+{
+	unsigned long val;
+
+	/* TODO */
+	pci_write_config8(ctrl->d0, GMCHCFG, 0x60);
+
+	/* PAMR: Programmable Attributes Register
+	 * Every pair of bits controls an address range:
+	 * 00 = Disabled, all accesses are forwarded to the ICH
+	 * 01 = Read Only
+	 * 10 = Write Only
+	 * 11 = Read/Write
+
+	 * Bit	Range
+	 * 7:6	000F0000 - 000FFFFF
+	 * 5:4	000E0000 - 000EFFFF
+	 * 3:2	000D0000 - 000DFFFF
+	 * 1:0	000C0000 - 000CFFFF
+	 */
+
+	/* Ideally, this should be R/W for as many ranges as possible. */
+	pci_write_config8(ctrl->d0, PAM, 0x00);
+
+	/* Enable 1MB framebuffer. */
+	pci_write_config8(ctrl->d0, SMRAM, 0xC0);
+
+	val = pci_read_config16(ctrl->d0, MISSC);
+	/* Preserve reserved bits. */
+	val &= 0xff06;
+	/* Set graphics cache window to 32MB, no power throttling. */
+	val |= 0x0001;
+	pci_write_config16(ctrl->d0, MISSC, val);
+
+	val = pci_read_config8(ctrl->d0, MISSC2);
+	/* Enable graphics palettes and clock gating (not optional!) */
+	val |= 0x06;
+	pci_write_config8(ctrl->d0, MISSC2, val);
+}
+
+/**
+ * TODO.
+ *
+ * @param Memory controller
+ */
+static void sdram_set_spd_registers(const struct mem_controller *ctrl)
+{
+	/* spd_set_dram_size() moved into sdram_enable() to prevent having
+	 * to pass a variable between here and there.
+	 */
+	set_dram_buffer_strength(ctrl);
+
+	set_dram_timing(ctrl);
+}
+
+/**
+ * Enable SDRAM.
+ *
+ * @param Number of controllers
+ * @param Memory controller
+ */
+static void sdram_enable(int controllers, const struct mem_controller *ctrl)
+{
+	int i;
+
+	/* Todo: this will currently work with either one dual sided or two
+	 * single sided DIMMs. Needs to work with 2 dual sided DIMMs in the
+	 * long run.
+	 */
+	uint32_t row_offset;
+
+	spd_set_dram_size(ctrl, row_offset); 
+
+	/* 1. Apply NOP. */
+	PRINT_DEBUG("RAM Enable 1: Apply NOP\r\n");
+	do_ram_command(ctrl, RAM_COMMAND_NOP, 0, row_offset);
+	udelay(200);
+
+	/* 2. Precharge all. Wait tRP. */
+	PRINT_DEBUG("RAM Enable 2: Precharge all\r\n");
+	do_ram_command(ctrl, RAM_COMMAND_PRECHARGE, 0, row_offset);
+	udelay(1);
+
+	/* 3. Perform 8 refresh cycles. Wait tRC each time. */
+	PRINT_DEBUG("RAM Enable 3: CBR\r\n");
+	do_ram_command(ctrl, RAM_COMMAND_CBR, 0, row_offset);
+	for (i = 0; i < 8; i++) {
+		read32(0);
+		read32(row_offset);
+		udelay(1);
+	}
+
+	/* 4. Mode register set. Wait two memory cycles. */
+	PRINT_DEBUG("RAM Enable 4: Mode register set\r\n");
+	do_ram_command(ctrl, RAM_COMMAND_MRS, 0x1d0, row_offset);
+	udelay(2);
+
+	/* 5. Normal operation (enables refresh) */
+	PRINT_DEBUG("RAM Enable 5: Normal operation\r\n");
+	do_ram_command(ctrl, RAM_COMMAND_NORMAL, 0, row_offset);
+	udelay(1);
+
+	PRINT_DEBUG("Northbridge following SDRAM init:\r\n");
+	DUMPNORTH();
+}

Added: trunk/LinuxBIOSv2/src/northbridge/intel/i82810/raminit.h
===================================================================
--- trunk/LinuxBIOSv2/src/northbridge/intel/i82810/raminit.h	                        (rev 0)
+++ trunk/LinuxBIOSv2/src/northbridge/intel/i82810/raminit.h	2007-06-14 12:02:38 UTC (rev 2720)
@@ -0,0 +1,90 @@
+/*
+ * This file is part of the LinuxBIOS project.
+ *
+ * Copyright (C) 2007 Corey Osgood <corey at slightlyhackish.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#ifndef NORTHBRIDGE_INTEL_I82810_RAMINIT_H
+#define NORTHBRIDGE_INTEL_I82810_RAMINIT_H
+
+/* The i810 supports max 2 dual-sided DIMMs. */
+#define DIMM_SOCKETS	2
+
+struct mem_controller {
+	device_t d0;
+	uint16_t channel0[DIMM_SOCKETS];
+};
+
+
+#endif				/* NORTHBRIDGE_INTEL_I82810_RAMINIT_H */
+
+/* The following table has been bumped over to this header to avoid clutter in 
+ * raminit.c. It's used to translate the value read from SPD Byte 31 to a value
+ * the northbridge can understand in DRP, aka Rx52[7:4], [3:0]. Where most
+ * northbridges have some sort of simple calculation that can be done for this,
+ * I haven't yet figured out one for this northbridge. Until someone does,
+ * this table is necessary.
+ */
+
+/* TODO: Find a better way of doing this */
+
+static const uint8_t translate_spd_to_i82810[] = {
+	/* Note: 4MB sizes are not supported, so dual-sided DIMMs with a 4MB 
+	 * side can't be either, at least for now.
+	 */
+	/* TODO: For above case, only use the other side if > 4MB, and get some
+	 * of these DIMMs to test it with. Same for unsupported 128/x sizes.
+	 */
+
+		/*   SPD Byte 31	Memory Size [Side 1/2]	*/
+	0xff,	/*	0x01		No memory	*/
+	0xff,	/*	0x01		 4/0		*/
+	0x01,	/*	0x02		 8/0		*/
+	0xff,	/*	0x03		 8/4		*/
+	0x04,	/*	0x04		16/0 or 16	*/
+	0xff,	/*	0x05		16/4		*/
+	0x05,	/*	0x06		16/8		*/
+	0xff,	/*	0x07		Invalid		*/
+	0x07,	/*	0x08		32/0 or 32	*/
+	0xff,	/*	0x09		32/4		*/
+	0xff,	/*	0x0A		32/8		*/
+	0xff,	/*	0x0B		Invalid		*/
+	0x08,	/*	0x0C		32/16		*/
+	0xff, 0xff, 0xff, /* 0x0D-0F	Invalid		*/
+	0x0a,	/*	0x10		64/0 or 64	*/
+	0xff,	/*	0x11		64/4		*/
+	0xff,	/*	0x12		64/8		*/
+	0xff,	/*	0x13		Invalid		*/
+	0xff,	/*	0x14		64/16		*/
+	0xff, 0xff, 0xff, /* 0x15-17	Invalid		*/
+	0x0b,	/*	0x18		64/32		*/
+	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 0x19-1f Invalid */
+	0x0d,	/*	0x20		128/0 or 128	*/
+	/* These configurations are not supported by the i810 */
+	0xff,	/*	0x21		128/4		*/
+	0xff,	/*	0x22		128/8		*/
+	0xff,	/*	0x23		Invalid		*/
+	0xff,	/*	0x24		128/16		*/
+	0xff, 0xff, 0xff, /* 0x25-27	Invalid		*/
+	0xff,	/*	0x28		128/32		*/
+	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, /* 0x29-2f Invalid */
+	0x0e,	/*	0x30		128/64		*/
+	0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+	0xff, 0xff, 0xff, /* 0x31-3f	Invalid		*/
+	0x0f,	/*	0x40		256/0 or 256	*/
+	/* Anything lar