From ijpraveen1 at yahoo.com  Fri Aug  1 04:07:00 2003
From: ijpraveen1 at yahoo.com (John Praveen)
Date: Fri Aug  1 04:07:00 2003
Subject: address
Message-ID: <20030801082212.9086.qmail@web41705.mail.yahoo.com>

Hello,
 
           At what address should the linuxbios.rom and the kernel image  file should be kept in Flash memory? My linuxbios.rom is 256KB and kernel image is 1.1MB.


---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20030801/260a1938/attachment.html>

From ts1 at tsn.or.jp  Fri Aug  1 04:26:01 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Fri Aug  1 04:26:01 2003
Subject: [PATCH] fix to pcibios.c
Message-ID: <20030801084030.GA5756@tsn.or.jp>

Hi,
A realmode BIOS function in the LinuxBIOS didn't work properly
(at least for me while trying to call int10h ax=4f01 of VGA BIOS),
and below is the fix.
With this fix, more boards and video cards might
be able to use built-in VGA BIOS support of LinuxBIOS.

Also I'm writing some code to switch video mode to VESA SuperVGA
and get mode information (address of framebuffer etc) from VGA BIOS,
then load 256-color logo image into the SuperVGA screen.
It would be nice if it can pass mode information to the kernel
(via LinuxBIOS table?) so we can use vesafb...


Index: pcibios.c
===================================================================
RCS file: /cvsroot/freebios/freebios/src/bioscall/pcibios.c,v
retrieving revision 1.3
diff -u -r1.3 pcibios.c
--- pcibios.c	22 May 2003 12:59:58 -0000	1.3
+++ pcibios.c	1 Aug 2003 08:17:10 -0000
@@ -50,7 +50,7 @@
 	unsigned short func = (unsigned short) eax;
 	int retval = -1;
 	unsigned short devid, vendorid, devfn;
-	int devindex;
+	short devindex; /* Use short to get rid of gabage in upper half of 32-bit register */
 	unsigned char bus;
 	struct pci_dev *dev;
 
@@ -76,7 +76,8 @@
 			*peax = 0;
 				// busnum is an unsigned char;
 				// devfn is an int, so we mask it off. 
-			busdevfn = dev->bus->secondary | (dev->devfn & 0xff);
+			busdevfn = (dev->bus->secondary << 8)
+					| (dev->devfn & 0xff);
 			printk_debug("0x%x: return 0x%x\n", func, busdevfn);
 			*pebx = busdevfn;
 			retval = 0;


From ebiederman at lnxi.com  Fri Aug  1 06:33:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Aug  1 06:33:00 2003
Subject: Fixes for Tyan s2880
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA03E@TYANWEB>
References: <3174569B9743D511922F00A0C943142302FCA03E@TYANWEB>
Message-ID: <m3he51abxo.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> Several Macro in console/console.h should be changed.
> 
> For example: 
> #define print_debug_hex8(HEX) printk_debug("0x08x", ((HEX))
> #define print_debug_hex16(HEX) printk_debug("0x016x", ((HEX))
> #define print_debug_hex32(HEX) printk_debug("0x032x", ((HEX))
> 
> to:
> #define print_debug_hex8(HEX) printk_debug("0x02x", ((HEX))
> #define print_debug_hex16(HEX) printk_debug("0x04x", ((HEX))
> #define print_debug_hex32(HEX) printk_debug("0x08x", ((HEX))
> 
> regards

Thanks.  That was a thinko.

Eric.



From stepan at suse.de  Fri Aug  1 06:39:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Fri Aug  1 06:39:00 2003
Subject: Fixes for Tyan s2880
In-Reply-To: <m3smomqbzs.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142302FCA037@TYANWEB> <m3smomqbzs.fsf@maxwell.lnxi.com>
Message-ID: <20030801104925.GA5055@suse.de>

* Eric W. Biederman <ebiederman at lnxi.com> [030801 05:43]:
> Here is my most recent snapshot, which is slightly newer
> than what I have in the public CVS tree.
> 
> I think I need to scrub all of memory on the B3 stepping before
> I start using it.  I have not tested anything that is C0 specific yet.

Even with this one I still dont get the kernel up on hdama

I get lots of these:
                                                               
80065d08:ffffffff                                                               
80065d0c:ffffffff                                                               
80065d10:ffffffff                                                               
80065d14:ffffffff                                                               
80065d18:ffffffff                                                               
80065d1c:ffffffff     

My machine has 2*256MB on each CPU.


driving only the first controller works fine.

(both with old config method.)

Stefan






From ebiederman at lnxi.com  Fri Aug  1 07:06:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Aug  1 07:06:00 2003
Subject: Fixes for Tyan s2880
In-Reply-To: <20030801104925.GA5055@suse.de>
References: <3174569B9743D511922F00A0C943142302FCA037@TYANWEB>
	<m3smomqbzs.fsf@maxwell.lnxi.com> <20030801104925.GA5055@suse.de>
Message-ID: <m33cgl7h97.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [030801 05:43]:
> > Here is my most recent snapshot, which is slightly newer
> > than what I have in the public CVS tree.
> > 
> > I think I need to scrub all of memory on the B3 stepping before
> > I start using it.  I have not tested anything that is C0 specific yet.
> 
> Even with this one I still dont get the kernel up on hdama
> 
> I get lots of these:
>                                                                
> 80065d08:ffffffff
> 
> 80065d0c:ffffffff
> 
> 80065d10:ffffffff
> 
> 80065d14:ffffffff
> 
> 80065d18:ffffffff
> 
> 80065d1c:ffffffff     
> 
> My machine has 2*256MB on each CPU.

This is a relic of my debugging code in auto.c  Move
the test down to 512MB instead of 2GB and you should be
fine.  I have 2GB in my first cpu...

> driving only the first controller works fine.
> 
> (both with old config method.)
> 
> Stefan



From linuxbios at smashed.demon.co.uk  Fri Aug  1 09:07:00 2003
From: linuxbios at smashed.demon.co.uk (James Weir)
Date: Fri Aug  1 09:07:00 2003
Subject: Question before buying hardware
Message-ID: <000601c3582f$f5ab3050$0b00000a@quadra001>

Hi,

 

I am hoping not to sound too stupid by asking these questions but before
I spend money on hardware I wanted to ask a few questions... 

 

1.       Can linux bios be configured to boot from a local disk as well
as using etherboot?

2.       Is the EPIA M10000 supported by linux bios?

 

Thanks,

 

James.

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

From sc at flagen.com  Fri Aug  1 14:14:01 2003
From: sc at flagen.com (David Hendricks)
Date: Fri Aug  1 14:14:01 2003
Subject: Intel E7000 / 82801CA and SPD
Message-ID: <34426.128.165.250.195.1059765739.squirrel@mail.flagen.com>

I'm having problems detecting memory on a SuperMicro P4DP6 mainboard using
the scanspd utility. Using the spd_82801.c file in the util/scanspd
directory, it returns "smbus_devfn not found!"

After a few small modifications (
http://www.flagen.com/~sc/linux/lb/p4dp6/spd_82801ca.c ), it finds the
SMBus but still can't seem to find any of the memory modules.

Any ideas?


From rsmith at bitworks.com  Fri Aug  1 16:49:00 2003
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Aug  1 16:49:00 2003
Subject: Question before buying hardware
In-Reply-To: <000601c3582f$f5ab3050$0b00000a@quadra001>
References: <000601c3582f$f5ab3050$0b00000a@quadra001>
Message-ID: <3F2AD5A9.7000008@bitworks.com>

James Weir wrote:


> 1.       Can linux bios be configured to boot from a local disk as well
> as using etherboot?

Yes.  Although the method varies.  I've attached my FAQ I wrote a while
ago when I started working with LB.  It should answer some of your
questions (and probally create more).  The FAQ is really rough so pardon
all the spelling and grammer mistakes.

> 2.       Is the EPIA M10000 supported by linux bios?

That I don't know.  The web site is the reference for what boards are 
supported but its out of date.  There has been a lot of EPIA work over
the last few months.  Search the archives for EPIA and see.

-- 
Richard A. Smith
rsmith at bitworks.com


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lb_faq.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20030801/3785deca/attachment.txt>

From rminnich at lanl.gov  Fri Aug  1 16:53:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  1 16:53:01 2003
Subject: address
In-Reply-To: <20030801082212.9086.qmail@web41705.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0308011025040.23291-100000@maxroach.lanl.gov>

On Fri, 1 Aug 2003, John Praveen wrote:

>            At what address should the linuxbios.rom and the kernel image
> file should be kept in Flash memory? My linuxbios.rom is 256KB and
> kernel image is 1.1MB.

what part are you using such that you can hold this much image (> 1 MB)

ron



From han2004 at hotmail.com  Sat Aug  2 09:46:01 2003
From: han2004 at hotmail.com (gimyung han)
Date: Sat Aug  2 09:46:01 2003
Subject: How can I transfer file to LinuxBIOS machine
Message-ID: <BAY2-F47xapzhad2VqK00000d0f@hotmail.com>

I'm trying to enable vgabios on my LinuxBIOS machine.

Currently, my EPIA computer is not supporting vga bios and I didn't backup 
my original BIOS.

Fortunately, I have another machine(EPIA-M), so I extract vgabios from BIOS 
on EPIA-M.

I transfered vga bios to my host computer hooked up with EPIA machine. 

According to the HOWTO, EPIA machine is given a static IP address from host 
computer. (by its MAC address).

so, I tried to connect to host computer via telnet, but I failed. I think 
network card on EPIA board  is not detected. (I compiled kernel image on 
other computer) 

is there any way to connect to EPIA computer and transfer vga bios to it. 

Thanks for any help.


From bari at onelabs.com  Sat Aug  2 10:48:00 2003
From: bari at onelabs.com (Bari Ari)
Date: Sat Aug  2 10:48:00 2003
Subject: LinuxBIOS for SIS661FX Based Laptop
Message-ID: <3F2BD2D8.7030800@onelabs.com>

SiS just publicly announced a new chipset for laptops that supports 800 
MHz FSB, DDR400, Ultra-AGPII and HyperStreaming.

http://www.sis.com/news/press/661mfx.htm
http://www.theregister.co.uk/content/3/32095.html
http://www.theregister.co.uk/content/3/31504.html

Any idea of the support from SiS (Ollie) on the docs and especially the 
graphic engine/VideoBIOS support we can expect for LinuxBIOS?

-Bari




From bari at onelabs.com  Sat Aug  2 11:48:01 2003
From: bari at onelabs.com (Bari Ari)
Date: Sat Aug  2 11:48:01 2003
Subject: Open Firware for Laptop Keyboard Scan/Super I/O's
Message-ID: <3F2BE0F5.4080405@onelabs.com>

One of the final hurdles in open firmware for laptops is having support 
for the "super I/O keyboard scan controllers". Closed source offerings 
include:

http://www.insydesw.com/solutions/pc/keyboard.htm

http://www.phoenix.com/en/products/phoenix+cme+firstbios/system+firmware/technologies/phoenix+multikey.htm

Has anyone come across any open source projects that have started work 
on this?

Bari




From thomas at wehrspann.de  Sat Aug  2 12:39:00 2003
From: thomas at wehrspann.de (Thomas Wehrspann)
Date: Sat Aug  2 12:39:00 2003
Subject: K7SEM support broken in freebios?
In-Reply-To: <Pine.LNX.4.44.0307280857180.12872-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0307280857180.12872-100000@maxroach.lanl.gov>
Message-ID: <200308021728.33550.thomas@wehrspann.de>

Am Montag, 28. Juli 2003 16:57 schrieb ron minnich:
> On Mon, 28 Jul 2003, Andrew Ip wrote:
> > > yes, this is the reason we have not frozen the tree. I am hoping
> > > somebody can fix the K7sem :-(
> >
> > Could it be the ecc problem?
>
> I think so. Is there a reasonable fix?
>
> ron

With the following patch the k7sem can boot with the current CVS.
But I don't know if it breaks anything else, or if it's important.

Thomas



diff -ur freebios.orig/src/cpu/k7/cpufixup.c freebios/src/cpu/k7/cpufixup.c
--- freebios.orig/src/cpu/k7/cpufixup.c Sat Aug  2 15:53:01 2003
+++ freebios/src/cpu/k7/cpufixup.c      Sat Aug  2 15:45:25 2003
@@ -51,7 +51,7 @@
        rdmsr(SYSCFG_MSR, lo, hi);
        printk_spew("SYSCFG was 0x%x:0x%x\n", hi, lo);
        lo |= SYSCFG_MSR_MtrrVarDramEn;
-       lo |= SYSCFG_MSR_SysEccEn;
+       //lo |= SYSCFG_MSR_SysEccEn;
        wrmsr(SYSCFG_MSR, lo, hi);
        rdmsr(SYSCFG_MSR, lo, hi);
        printk_spew("SYSCFG IS NOW 0x%x:0x%x\n", hi, lo);



From ts1 at cma.co.jp  Mon Aug  4 01:57:00 2003
From: ts1 at cma.co.jp (SONE Takeshi)
Date: Mon Aug  4 01:57:00 2003
Subject: How can I transfer file to LinuxBIOS machine
In-Reply-To: <BAY2-F47xapzhad2VqK00000d0f@hotmail.com>
References: <BAY2-F47xapzhad2VqK00000d0f@hotmail.com>
Message-ID: <20030804061215.GA7851@cma.co.jp>

On Sat, Aug 02, 2003 at 02:01:38PM +0000, gimyung han wrote:
> I'm trying to enable vgabios on my LinuxBIOS machine.
> 
> Currently, my EPIA computer is not supporting vga bios and I didn't backup 
> my original BIOS.
> 
> Fortunately, I have another machine(EPIA-M), so I extract vgabios from BIOS 
> on EPIA-M.
> 
> I transfered vga bios to my host computer hooked up with EPIA machine. 

EPIA-M has different VGA device, so the VGA BIOS of EPIA-M
might not work on EPIA.
You can use DOS program CBROM (google for it) to extract VGA BIOS
from the EPIA BIOS image on the VIA's download page.

--
Takeshi


From ebiederman at lnxi.com  Mon Aug  4 14:30:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 14:30:01 2003
Subject: Weird behaviour with new config method
In-Reply-To: <Pine.LNX.4.44.0308011027180.23291-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308011027180.23291-100000@maxroach.lanl.gov>
Message-ID: <m3ispdntqx.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> interesting. I am loading linux direct from flash and it works fine with 
> the new config method. Now I'll have to try etherboot and see what's up.
> 
> this is complicated as my tree is in an intermediate state, but I hope to 
> work it out monday.

Something very peculiar is going on at the moment as I can't even get
a configuration to build.

Eric


bash-2.05a$ ./buildtarget arima/hdama/
make: `config.py' is up to date.
Configuring TARGET hdama
Creating directory arima/hdama/hdama
Will place Makefile, crt0.S, etc. in arima/hdama/hdama
Configuring ROMIMAGE fallback
Configuring DIR /config/Config.lb
Configuring DIR /lib/Config.lb
Configuring DIR /console/Config.lb
Configuring DIR /stream/Config.lb
Configuring DIR /devices/Config.lb
Configuring DIR /pc80/Config.lb
Configuring DIR /boot/Config.lb
Configuring PART mainboard, path arima/hdama
Configuring PART arch, path i386
Adding init file: config/crt0.base
Configuring DIR lib/Config.lb
Configuring DIR boot/Config.lb
Configuring DIR smp/Config.lb
End PART arch
WARNING: Option CONFIG_SMP using default value 0
Configuring PART northbridge, path amd/amdk8
End PART northbridge
Configuring PART southbridge, path amd/amd8111
End PART southbridge
Configuring PART southbridge, path amd/amd8131
End PART southbridge
Configuring PART superio, path NSC/pc87360
End PART superio
Configuring DIR /pc80/Config.lb
Warning, object/driver mc146818rtc previously defined
Configuring PART cpu, path p5
End PART cpu
Configuring PART cpu, path p6
End PART cpu
Configuring PART cpu, path k7
End PART cpu
Configuring PART cpu, path k8
End PART cpu
End PART mainboard
WARNING: Option AMD8111_DEV using default value 0x3800
WARNING: Option CONFIG_IDE_STREAM using default value 0
Traceback (most recent call last):
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 2137, in ?
    if (not parse('board', fp.read())):
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1782, in parse
    return wrap_error_reporter(P, rule)
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/yappsrt.py", line 162, in wrap_error_reporter
    try: return getattr(parser, rule)()
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1716, in board
    romstmts = self.romstmts()
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1701, in romstmts
    romimage = self.romimage()
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1680, in romimage
    romstmt = self.romstmt(1)
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1671, in romstmt
    mainboard = self.mainboard(C)
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1650, in mainboard
    if (C): mainboard(PATH)
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1034, in mainboard
    partpop()
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 1087, in partpop
    print "WARNING: Option %s using default value %s" % (i, getformated(i, curpart.image))
  File "/home/eric/projects/linuxbios/checkin/freebios2/util/newconfig/config.py", line 884, in getformated
    return (f % v.contents())
TypeError: an integer is required



From rminnich at lanl.gov  Mon Aug  4 14:41:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 14:41:00 2003
Subject: heads up with new config method. 
In-Reply-To: <m3ispdntqx.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308041255510.30253-100000@maxroach.lanl.gov>

I am going to make a very minor tweak in a few minutes that should not 
affect any of you. 

But we'll see. This tweak is aimed at letting us shrink the top-level 
Config.lb files to almost nothing.

ron



From YhLu at tyan.com  Mon Aug  4 14:49:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug  4 14:49:01 2003
Subject: VGA 
Message-ID: <3174569B9743D511922F00A0C943142302FCA1AE@TYANWEB>

Ron,

How about VGA support status on LinuxBIOS?

I also wonder if AGP addon card need init too.

Regards

Yinghai Lu


From ebiederman at lnxi.com  Mon Aug  4 15:06:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 15:06:01 2003
Subject: Weird behaviour with new config method
In-Reply-To: <p06001a04bb545bb84cd0@[10.0.1.2]>
References: <Pine.LNX.4.44.0308011027180.23291-100000@maxroach.lanl.gov>
	<m3ispdntqx.fsf@maxwell.lnxi.com> <p06001a04bb545bb84cd0@[10.0.1.2]>
Message-ID: <m38yq9kz1q.fsf@maxwell.lnxi.com>

Greg Watson <g.watson at computer.org> writes:

> You need to provide a 'format' string for the option. This bit Ron too. I think
> it needs to be made mandatory.


If I was not using the stock hdama configuration I would not have a problem
with that.  It looks like Ron did not check in the fix or whatever.

I don't know yet which option it is having a problem with.

Eric



From rminnich at lanl.gov  Mon Aug  4 15:08:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 15:08:01 2003
Subject: VGA 
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA1AE@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308041323340.30253-100000@maxroach.lanl.gov>

On Mon, 4 Aug 2003, YhLu wrote:

> How about VGA support status on LinuxBIOS?

we're hung up on the 7505 chipset right now, we can't get it to work 
correctly with SPD. 

> I also wonder if AGP addon card need init too.

that is an ongoing project here, with expected completion in august.

ron



From rminnich at lanl.gov  Mon Aug  4 15:10:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 15:10:00 2003
Subject: Weird behaviour with new config method
In-Reply-To: <m38yq9kz1q.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308041325020.30253-100000@maxroach.lanl.gov>

On 4 Aug 2003, Eric W. Biederman wrote:

> If I was not using the stock hdama configuration I would not have a problem
> with that.  It looks like Ron did not check in the fix or whatever.

yup, things still break sometimes :-)

> I don't know yet which option it is having a problem with.

yup, better diagnostics are needed.

ron



From rminnich at lanl.gov  Mon Aug  4 15:13:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 15:13:00 2003
Subject: Weird behaviour with new config method
In-Reply-To: <m3ispdntqx.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308041327370.30253-100000@maxroach.lanl.gov>

On 4 Aug 2003, Eric W. Biederman wrote:

> WARNING: Option AMD8111_DEV using default value 0x3800
> WARNING: Option CONFIG_IDE_STREAM using default value 0

you've got something different. We're building from cvs here with no 
trouble. 

The order of some of your messages differs from ours. 

Are you sure it's a 'stock hdama' or ...

ron



From YhLu at tyan.com  Mon Aug  4 15:18:00 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug  4 15:18:00 2003
Subject: IO ports assign
Message-ID: <3174569B9743D511922F00A0C943142302FCA1B0@TYANWEB>

Eric,

I have tested s2880 with all addon cards, and found interesting problem.

When I plug Adaptec 29320 PCI X scsi card into slot 3 and 4. That share
BUS_A of 8131 with LSI SCSI. Linux bios got IO port allocation problem on
bus 1.

BUS 1: 1000-2fff
LSI will use 3000 later...

Regards

Yinghai Lu

Allocating resources...
ASSIGN RESOURCES, bus 0
PCI: 00:01.0 1c <- [0x00001000 - 0x00002fff] bus 1 io
PCI: 00:01.0 24 <- [0xfe300000 - 0xfe2fffff] bus 1 prefmem
PCI: 00:01.0 20 <- [0xfe100000 - 0xfe1fffff] bus 1 mem
ASSIGN RESOURCES, bus 1
PCI: 01:07.0 10 <- [0x00001000 - 0x000010ff] io
PCI: 01:07.0 14 <- [0xfe180000 - 0xfe181fff] mem
PCI: 01:07.0 1c <- [0x00001400 - 0x000014ff] io
PCI: 01:07.1 10 <- [0x00001800 - 0x000018ff] io
PCI: 01:07.1 14 <- [0xfe182000 - 0xfe183fff] mem
PCI: 01:07.1 1c <- [0x00001c00 - 0x00001cff] io
PCI: 01:08.0 10 <- [0x00002000 - 0x000020ff] io
PCI: 01:08.0 14 <- [0xfe184000 - 0xfe185fff] mem
PCI: 01:08.0 1c <- [0x00002400 - 0x000024ff] io
PCI: 01:08.1 10 <- [0x00002800 - 0x000028ff] io
PCI: 01:08.1 14 <- [0xfe186000 - 0xfe187fff] mem
PCI: 01:08.1 1c <- [0x00002c00 - 0x00002cff] io
PCI: 01:09.0 10 <- [0xfe100000 - 0xfe10ffff] mem
PCI: 01:09.0 18 <- [0xfe110000 - 0xfe11ffff] mem
PCI: 01:09.1 10 <- [0xfe120000 - 0xfe12ffff] mem
PCI: 01:09.1 18 <- [0xfe130000 - 0xfe13ffff] mem
PCI: 01:0a.0 10 <- [0x00003000 - 0x000030ff] io
PCI: 01:0a.0 14 <- [0xfe140000 - 0xfe14ffff] mem
PCI: 01:0a.0 1c <- [0xfe150000 - 0xfe15ffff] mem
PCI: 01:0a.1 10 <- [0x00003400 - 0x000034ff] io
PCI: 01:0a.1 14 <- [0xfe160000 - 0xfe16ffff] mem
PCI: 01:0a.1 1c <- [0xfe170000 - 0xfe17ffff] mem
ASSIGNED RESOURCES, bus 1


From ebiederman at lnxi.com  Mon Aug  4 15:22:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 15:22:00 2003
Subject: Weird behaviour with new config method
In-Reply-To: <Pine.LNX.4.44.0308041327370.30253-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308041327370.30253-100000@maxroach.lanl.gov>
Message-ID: <m3smohdxfb.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 4 Aug 2003, Eric W. Biederman wrote:
> 
> > WARNING: Option AMD8111_DEV using default value 0x3800
> > WARNING: Option CONFIG_IDE_STREAM using default value 0
> 
> you've got something different. We're building from cvs here with no 
> trouble. 
> 
> The order of some of your messages differs from ours. 
> 
> Are you sure it's a 'stock hdama' or ...

100%.  I just ran a cvs update -d -P in my freebios2 directory and I have run
a cvs diff and I while I have one or two modified files, none of them are the
new configuration files.

I did do a rebuild on config.py before I got started which may affect something.

Eric



From rminnich at lanl.gov  Mon Aug  4 15:28:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 15:28:00 2003
Subject: Weird behaviour with new config method
In-Reply-To: <m3smohdxfb.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308041341480.30253-100000@maxroach.lanl.gov>

fresh checkout:

bash-2.05b$ python /tmp//freebios2/util/newconfig/config.py  Config.lb 
/tmp///freebios2

Configuring TARGET hdama
Creating directory hdama
Will place Makefile, crt0.S, etc. in hdama
Configuring ROMIMAGE fallback
Configuring DIR /config/Config.lb
Configuring DIR /lib/Config.lb
Configuring DIR /console/Config.lb
Configuring DIR /stream/Config.lb
Configuring DIR /devices/Config.lb
Configuring DIR /pc80/Config.lb
Configuring DIR /boot/Config.lb
Configuring PART mainboard, path arima/hdama
Configuring PART arch, path i386
Adding init file: config/crt0.base
Configuring DIR lib/Config.lb
Configuring DIR boot/Config.lb
Configuring DIR smp/Config.lb
End PART arch
WARNING: Option CONFIG_SMP using default value 0
Configuring PART northbridge, path amd/amdk8
End PART northbridge
Configuring PART southbridge, path amd/amd8111
End PART southbridge
Configuring PART southbridge, path amd/amd8131
End PART southbridge
Configuring PART superio, path NSC/pc87360
End PART superio
Configuring DIR /pc80/Config.lb
Warning, object/driver mc146818rtc previously defined
Configuring PART cpu, path p5
End PART cpu
Configuring PART cpu, path p6
End PART cpu
Configuring PART cpu, path k7
End PART cpu
Configuring PART cpu, path k8
End PART cpu
End PART mainboard
WARNING: Option USE_NORMAL_IMAGE using default value 0
WARNING: Option CONFIG_IDE_STREAM using default value 0
WARNING: Option AMD8111_DEV using default value 0x3800
End ROMIMAGE
Build ROM size 1048576
Creating directory hdama/fallback
Creating hdama/fallback/static.c
Creating hdama/fallback/Makefile.settings
Creating hdama/fallback/crt0_includes.h
Creating hdama/fallback/Makefile
Creating hdama/fallback/ldoptions
Creating hdama/Makefile.settings
Creating hdama/Makefile

=========================
BUT: greg points out you are using buildtarget maybe.

but that works too. Dammit!
=========================

bash-2.05b$ sh buildtarget arima/hdama/
make: `config.py' is up to date.
Configuring TARGET hdama
Will place Makefile, crt0.S, etc. in arima/hdama/hdama
Configuring ROMIMAGE fallback
Configuring DIR /config/Config.lb
Configuring DIR /lib/Config.lb
Configuring DIR /console/Config.lb
Configuring DIR /stream/Config.lb
Configuring DIR /devices/Config.lb
Configuring DIR /pc80/Config.lb
Configuring DIR /boot/Config.lb
Configuring PART mainboard, path arima/hdama
Configuring PART arch, path i386
Adding init file: config/crt0.base
Configuring DIR lib/Config.lb
Configuring DIR boot/Config.lb
Configuring DIR smp/Config.lb
End PART arch
WARNING: Option CONFIG_SMP using default value 0
Configuring PART northbridge, path amd/amdk8
End PART northbridge
Configuring PART southbridge, path amd/amd8111
End PART southbridge
Configuring PART southbridge, path amd/amd8131
End PART southbridge
Configuring PART superio, path NSC/pc87360
End PART superio
Configuring DIR /pc80/Config.lb
Warning, object/driver mc146818rtc previously defined
Configuring PART cpu, path p5
End PART cpu
Configuring PART cpu, path p6
End PART cpu
Configuring PART cpu, path k7
End PART cpu
Configuring PART cpu, path k8
End PART cpu
End PART mainboard
WARNING: Option USE_NORMAL_IMAGE using default value 0
WARNING: Option CONFIG_IDE_STREAM using default value 0
WARNING: Option AMD8111_DEV using default value 0x3800
End ROMIMAGE
Build ROM size 1048576
Creating arima/hdama/hdama/fallback/static.c
Creating arima/hdama/hdama/fallback/Makefile.settings
Creating arima/hdama/hdama/fallback/crt0_includes.h
Creating arima/hdama/hdama/fallback/Makefile
Creating arima/hdama/hdama/fallback/ldoptions
Creating arima/hdama/hdama/Makefile.settings
Creating arima/hdama/hdama/Makefile
bash-2.05b$ 
=========================


Python variability?

Python 2.2.1 (#1, Aug 30 2002, 12:15:30) 
[GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2

This on RH 8.0

ron



From ebiederman at lnxi.com  Mon Aug  4 15:48:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 15:48:00 2003
Subject: IO ports assign
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA1B0@TYANWEB>
References: <3174569B9743D511922F00A0C943142302FCA1B0@TYANWEB>
Message-ID: <m3ispdb3cz.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I have tested s2880 with all addon cards, and found interesting problem.
> 
> When I plug Adaptec 29320 PCI X scsi card into slot 3 and 4. That share
> BUS_A of 8131 with LSI SCSI. Linux bios got IO port allocation problem on
> bus 1.
> 
> BUS 1: 1000-2fff
> LSI will use 3000 later...

I believe this is a bug that failed to get pushed forward
from freebios tree.  I have just committed this fix and
a patch is attached.


The problem is because it was performing it's size calculations
at address 0.  It figured the I/O space registers could be safely
packed more tightly then they actually can be.

Eric


bash-2.05a$ cvs diff -u src/devices/device.c
ebiederm at cvs.freebios.sourceforge.net's password: 
Index: src/devices/device.c
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/devices/device.c,v
retrieving revision 1.4
diff -u -r1.4 device.c
--- src/devices/device.c	21 Jul 2003 20:13:42 -0000	1.4
+++ src/devices/device.c	4 Aug 2003 19:52:30 -0000
@@ -217,8 +217,12 @@
 		if (resource->flags & IORESOURCE_IO) {
 			/* Don't allow potential aliases over the
 			 * legacy pci expansion card addresses.
+			 * The legacy pci decodes only 10 bits,
+			 * uses 100h - 3ffh. Therefor, only 0 - ff
+			 * can be used out of each 400h block of io
+			 * space.
 			 */
-			if ((base > 0x3ff) && ((base & 0x300) != 0)) {
+			if ((base & 0x300) != 0) {
 				base = (base & ~0x3ff) + 0x400;
 			}
 			/* Don't allow allocations in the VGA IO range.



From ebiederman at lnxi.com  Mon Aug  4 16:08:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 16:08:00 2003
Subject: Weird behaviour with new config method
In-Reply-To: <Pine.LNX.4.44.0308041341480.30253-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308041341480.30253-100000@maxroach.lanl.gov>
Message-ID: <m38yq9896i.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> fresh checkout:
> 
> Python variability?

Quite possible as I just confirmed the issue on a fresh checkout.

> Python 2.2.1 (#1, Aug 30 2002, 12:15:30) 
> [GCC 3.2 20020822 (Red Hat Linux Rawhide 3.2-4)] on linux2
> 
> This on RH 8.0

Python -V
Python 2.1.3

This is on a debian system.  

Hmm. Other versions of python are easy to upgrade so:

Python 2.3b2 works
Python 2.2.3 works
Python 2.1.3 fails
Python 1.5   fails

Previously when we had this conversation we tried for a minimum python
of 1.5 and the old config tool manages that.  We may need to bump the
python requirement but we this needs investigation to see why the earlier
versions of python have problems.

Eric



From YhLu at tyan.com  Mon Aug  4 16:10:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug  4 16:10:01 2003
Subject: IO ports assign
Message-ID: <3174569B9743D511922F00A0C943142302FCA1B9@TYANWEB>

Eric,

Thanks, it works.

Regards

Yinghai Lu

ASSIGN RESOURCES, bus 0
PCI: 00:01.0 1c <- [0x00001000 - 0x00003fff] bus 1 io
PCI: 00:01.0 24 <- [0xfe300000 - 0xfe2fffff] bus 1 prefmem
PCI: 00:01.0 20 <- [0xfe100000 - 0xfe1fffff] bus 1 mem
ASSIGN RESOURCES, bus 1
PCI: 01:07.0 10 <- [0x00001000 - 0x000010ff] io
PCI: 01:07.0 14 <- [0xfe180000 - 0xfe181fff] mem
PCI: 01:07.0 1c <- [0x00001400 - 0x000014ff] io
PCI: 01:07.1 10 <- [0x00001800 - 0x000018ff] io
PCI: 01:07.1 14 <- [0xfe182000 - 0xfe183fff] mem
PCI: 01:07.1 1c <- [0x00001c00 - 0x00001cff] io
PCI: 01:08.0 10 <- [0x00002000 - 0x000020ff] io
PCI: 01:08.0 14 <- [0xfe184000 - 0xfe185fff] mem
PCI: 01:08.0 1c <- [0x00002400 - 0x000024ff] io
PCI: 01:08.1 10 <- [0x00002800 - 0x000028ff] io
PCI: 01:08.1 14 <- [0xfe186000 - 0xfe187fff] mem
PCI: 01:08.1 1c <- [0x00002c00 - 0x00002cff] io
PCI: 01:09.0 10 <- [0xfe100000 - 0xfe10ffff] mem
PCI: 01:09.0 18 <- [0xfe110000 - 0xfe11ffff] mem
PCI: 01:09.1 10 <- [0xfe120000 - 0xfe12ffff] mem
PCI: 01:09.1 18 <- [0xfe130000 - 0xfe13ffff] mem
PCI: 01:0a.0 10 <- [0x00003000 - 0x000030ff] io
PCI: 01:0a.0 14 <- [0xfe140000 - 0xfe14ffff] mem
PCI: 01:0a.0 1c <- [0xfe150000 - 0xfe15ffff] mem
PCI: 01:0a.1 10 <- [0x00003400 - 0x000034ff] io
PCI: 01:0a.1 14 <- [0xfe160000 - 0xfe16ffff] mem
PCI: 01:0a.1 1c <- [0xfe170000 - 0xfe17ffff] mem
ASSIGNED RESOURCES, bus 1


From YhLu at tyan.com  Mon Aug  4 16:33:00 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug  4 16:33:00 2003
Subject: Fixes for Tyan s2880
Message-ID: <3174569B9743D511922F00A0C943142302FCA1C0@TYANWEB>

Eric,

It works on 12G too.

Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
Setting variable MTRR 4, base: 4096MB, range: 4096MB, type WB
Setting variable MTRR 5, base: 8192MB, range: 4096MB, type WB

But I think you need to optimize mtrr.c now, otherwise it may not work with
arima Hadama. 8*2=16G, will use out MTRR.

It may be
Setting variable MTRR 0, base: 3840MB, range:  256MB, type WC
Setting variable MTRR 1, base: 4096MB, range: 4096MB, type WB
Setting variable MTRR 2, base: 8192MB, range: 4096MB, type WB
Setting variable MTRR 3, base: 4096MB, range: 4096MB, type WB

Regards

Yinghai Lu

-----????-----
???: YhLu 
????: 2003?7?31? 21:08
???: ebiederman at lnxi.com
??: ron minnich; Stefan Reinauer; linuxbios at clustermatic.org
??: re: Fixes for Tyan s2880

Eric,

It works. For 6G.  Tommorrow I will try 12G.

Thanks.

Yinghai Lu




From rminnich at lanl.gov  Mon Aug  4 16:41:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 16:41:01 2003
Subject: Weird behaviour with new config method
In-Reply-To: <m38yq9896i.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308041456170.30253-100000@maxroach.lanl.gov>

On 4 Aug 2003, Eric W. Biederman wrote:

> Previously when we had this conversation we tried for a minimum python
> of 1.5 and the old config tool manages that.  We may need to bump the
> python requirement but we this needs investigation to see why the earlier
> versions of python have problems.
> 

we're going to have to bump minimums anyway. romcc fails for me on RH 7.3. 

ron



From YhLu at tyan.com  Mon Aug  4 16:44:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug  4 16:44:01 2003
Subject: Weird behaviour with new config method
Message-ID: <3174569B9743D511922F00A0C943142302FCA1C5@TYANWEB>

Etherboot images (5.1.8) built with RH 9 doesn't work. I think RH 8 the
same.

Only Etherboot images(5.1.8) built with Suse 8.2 can work.

Different gcc??

Regards

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?4? 13:57
???: Eric W. Biederman
??: Stefan Reinauer; YhLu; gwatson at lanl.gov; LinuxBIOS
??: Re: Weird behaviour with new config method

On 4 Aug 2003, Eric W. Biederman wrote:

> Previously when we had this conversation we tried for a minimum python
> of 1.5 and the old config tool manages that.  We may need to bump the
> python requirement but we this needs investigation to see why the earlier
> versions of python have problems.
> 

we're going to have to bump minimums anyway. romcc fails for me on RH 7.3. 

ron


From gwatson at lanl.gov  Mon Aug  4 16:50:01 2003
From: gwatson at lanl.gov (Greg Watson)
Date: Mon Aug  4 16:50:01 2003
Subject: Weird behaviour with new config method
In-Reply-To: <Pine.LNX.4.44.0308041456170.30253-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308041456170.30253-100000@maxroach.lanl.gov>
Message-ID: <p06001a0fbb547ab08eeb@[10.0.1.2]>

At 2:56 PM -0600 4/8/03, ron minnich wrote:
>On 4 Aug 2003, Eric W. Biederman wrote:
>
>>  Previously when we had this conversation we tried for a minimum python
>>  of 1.5 and the old config tool manages that.  We may need to bump the
>>  python requirement but we this needs investigation to see why the earlier
>>  versions of python have problems.
>>
>
>we're going to have to bump minimums anyway. romcc fails for me on RH 7.3.
>
>ron

It'll have to be version 2.0 at a minimum since yapps (and config.g) 
depends on some 2.0 features. It maybe a later version depending on 
what Eric's problem turns out to be.

Greg


From rminnich at lanl.gov  Mon Aug  4 16:54:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 16:54:01 2003
Subject: Commit on freebios2
Message-ID: <Pine.LNX.4.44.0308041505210.30253-100000@maxroach.lanl.gov>

I have made the initial commits for the items Stefan requested; comments 
welcome. 

Here is the log.

Commits for the new config static device design, to allow more than one 
static 
cpu of a certain type and to eliminate the 
cpu p5
cpu p6
cpu k7

nonsense in the old config files.

Next step is to hook into Eric's pci device stuff.

CVS: 
----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/cpu/k7/Config.lb src/cpu/k8/Config.lb
CVS:    src/cpu/k8/cpufixup.c src/cpu/p6/Config.lb
CVS:    src/mainboard/arima/hdama/Config.lb
CVS:    src/mainboard/arima/hdama/mainboard.c util/newconfig/config.g
CVS: 
----------------------------------------------------------------------

Here is the fragment of the arima mainboard file that uses the new code; 
note that it is incomplete, I hope to fill it in.

cpu k8 "cpu0"
  register "up" = "{.chip = &amd8111, .ht_width=8, .ht_speed=200}"
end

cpu k8 "cpu1"
end


Here is the code produced.

struct chip static_root = {
/* mainboard /home/rminnich/src/bios/freebios2/src/mainboard/arima/hdama 
*/
  .next = 0,
  .children = &cpu1,
  .control= &mainboard_arima_hdama_control,
  .chip_info = (void *) &mainboard_arima_hdama_config_0,
};
struct cpu_k8_config cpu1_config;
struct chip cpu1 = {
/* cpu /home/rminnich/src/bios/freebios2/src/cpu/k8 */
  .next = &cpu0,
  .children = 0,
  .control= &cpu_k8_control,
  .chip_info = (void *) &cpu1_config,
};
struct cpu_k8_config cpu0_config        = {
  .up = {.chip = &amd8111, .ht_width=8, .ht_speed=200},
};

struct chip cpu0 = {
/* cpu /home/rminnich/src/bios/freebios2/src/cpu/k8 */
  .next = &superio_NSC_pc87360_dev5,
  .children = 0,
  .control= &cpu_k8_control,
  .chip_info = (void *) &cpu0_config,
};


thanks

ron



From rminnich at lanl.gov  Mon Aug  4 16:55:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 16:55:01 2003
Subject: Yh Lu's patches
Message-ID: <Pine.LNX.4.44.0308041509520.30253-100000@maxroach.lanl.gov>

Can Eric and Stefan and others interested please take a quick look at
this, it is the non-tyan mods from Yh Lu.

I am going to commit the tyan mods in a few minutes.

thanks

ron
diff -uNr ./freebios2/src/cpu/k8/cpufixup.c ../freebios2/src/cpu/k8/cpufixup.c
--- ./freebios2/src/cpu/k8/cpufixup.c	2003-08-04 17:57:43.000000000 -0400
+++ ../freebios2/src/cpu/k8/cpufixup.c	2003-08-04 19:41:18.000000000 -0400
@@ -29,15 +29,28 @@
 		mmio_basek = tomk;
 	}
 
-	/* Setup TOP_MEM */
-	msr.hi = mmio_basek >> 22;
-	msr.lo = mmio_basek << 10;
-	wrmsr(TOP_MEM, msr);
+#if 1
+        /* Report the amount of memory. */
+        print_debug("cpufixup RAM: 0x");
+        print_debug_hex32(tomk);
+        print_debug(" KB\r\n");
+#endif
+
+        /* Now set top of memory */
+        msr.lo = (tomk & 0x003fffff) << 10;
+        msr.hi = (tomk & 0xffc00000) >> 22;
+        wrmsr(TOP_MEM2, msr);
+
+        /* Leave a 64M hole between TOP_MEM and TOP_MEM2
+         * so I can see my rom chip and other I/O devices.
+         */
+        if (tomk >= 0x003f0000) {
+                tomk = 0x3f0000;
+        } //    tom_k = 0x3c0000;
+        msr.lo = (tomk & 0x003fffff) << 10;
+        msr.hi = (tomk & 0xffc00000) >> 22;
+        wrmsr(TOP_MEM, msr);
 
-	/* Setup TOP_MEM2 */
-	msr.hi = tomk >> 22;
-	msr.lo = tomk << 10;
-	wrmsr(TOP_MEM2, msr);
 
 	/* zero the IORR's before we enable to prevent
 	 * undefined side effects.
diff -uNr ./freebios2/src/include/console/console.h ../freebios2/src/include/console/console.h
--- ./freebios2/src/include/console/console.h	2003-07-19 00:28:21.000000000 -0400
+++ ../freebios2/src/include/console/console.h	2003-08-02 01:40:57.000000000 -0400
@@ -92,34 +92,34 @@
 #define print_debug_char(CH)   printk_debug  ("%c", (CH))
 #define print_spew_char(CH)    printk_spew   ("%c", (CH))
 
-#define print_emerg_hex8(HEX)   printk_emerg  ("%08x",  (HEX))
-#define print_alert_hex8(HEX)   printk_alert  ("%08x",  (HEX))
-#define print_crit_hex8(HEX)    printk_crit   ("%08x",  (HEX))
-#define print_err_hex8(HEX)     printk_err    ("%08x",  (HEX))
-#define print_warning_hex8(HEX) printk_warning("%08x",  (HEX))
-#define print_notice_hex8(HEX)  printk_notice ("%08x",  (HEX))
-#define print_info_hex8(HEX)    printk_info   ("%08x",  (HEX))
-#define print_debug_hex8(HEX)   printk_debug  ("%08x",  (HEX))
-#define print_spew_hex8(HEX)    printk_spew   ("%08x",  (HEX))
+#define print_emerg_hex8(HEX)   printk_emerg  ("%02x",  (HEX))
+#define print_alert_hex8(HEX)   printk_alert  ("%02x",  (HEX))
+#define print_crit_hex8(HEX)    printk_crit   ("%02x",  (HEX))
+#define print_err_hex8(HEX)     printk_err    ("%02x",  (HEX))
+#define print_warning_hex8(HEX) printk_warning("%02x",  (HEX))
+#define print_notice_hex8(HEX)  printk_notice ("%02x",  (HEX))
+#define print_info_hex8(HEX)    printk_info   ("%02x",  (HEX))
+#define print_debug_hex8(HEX)   printk_debug  ("%02x",  (HEX))
+#define print_spew_hex8(HEX)    printk_spew   ("%02x",  (HEX))
 
-#define print_emerg_hex16(HEX)   printk_emerg  ("%016x", (HEX))
-#define print_alert_hex16(HEX)   printk_alert  ("%016x", (HEX))
-#define print_crit_hex16(HEX)    printk_crit   ("%016x", (HEX))
-#define print_err_hex16(HEX)     printk_err    ("%016x", (HEX))
-#define print_warning_hex16(HEX) printk_warning("%016x", (HEX))
-#define print_notice_hex16(HEX)  printk_notice ("%016x", (HEX))
-#define print_info_hex16(HEX)    printk_info   ("%016x", (HEX))
-#define print_debug_hex16(HEX)   printk_debug  ("%016x", (HEX))
-#define print_spew_hex16(HEX)    printk_spew   ("%016x", (HEX))
+#define print_emerg_hex16(HEX)   printk_emerg  ("%04x", (HEX))
+#define print_alert_hex16(HEX)   printk_alert  ("%04x", (HEX))
+#define print_crit_hex16(HEX)    printk_crit   ("%04x", (HEX))
+#define print_err_hex16(HEX)     printk_err    ("%04x", (HEX))
+#define print_warning_hex16(HEX) printk_warning("%04x", (HEX))
+#define print_notice_hex16(HEX)  printk_notice ("%04x", (HEX))
+#define print_info_hex16(HEX)    printk_info   ("%04x", (HEX))
+#define print_debug_hex16(HEX)   printk_debug  ("%04x", (HEX))
+#define print_spew_hex16(HEX)    printk_spew   ("%04x", (HEX))
 
-#define print_emerg_hex32(HEX)   printk_emerg  ("%032x", (HEX))
-#define print_alert_hex32(HEX)   printk_alert  ("%032x", (HEX))
-#define print_crit_hex32(HEX)    printk_crit   ("%032x", (HEX))
-#define print_err_hex32(HEX)     printk_err    ("%032x", (HEX))
-#define print_warning_hex32(HEX) printk_warning("%032x", (HEX))
-#define print_notice_hex32(HEX)  printk_notice ("%032x", (HEX))
-#define print_info_hex32(HEX)    printk_info   ("%032x", (HEX))
-#define print_debug_hex32(HEX)   printk_debug  ("%032x", (HEX))
-#define print_spew_hex32(HEX)    printk_spew   ("%032x", (HEX))
+#define print_emerg_hex32(HEX)   printk_emerg  ("%08x", (HEX))
+#define print_alert_hex32(HEX)   printk_alert  ("%08x", (HEX))
+#define print_crit_hex32(HEX)    printk_crit   ("%08x", (HEX))
+#define print_err_hex32(HEX)     printk_err    ("%08x", (HEX))
+#define print_warning_hex32(HEX) printk_warning("%08x", (HEX))
+#define print_notice_hex32(HEX)  printk_notice ("%08x", (HEX))
+#define print_info_hex32(HEX)    printk_info   ("%08x", (HEX))
+#define print_debug_hex32(HEX)   printk_debug  ("%08x", (HEX))
+#define print_spew_hex32(HEX)    printk_spew   ("%08x", (HEX))
 
diff -uNr ./freebios2/src/northbridge/amd/amdk8/raminit.c ../freebios2/src/northbridge/amd/amdk8/raminit.c
--- ./freebios2/src/northbridge/amd/amdk8/raminit.c	2003-08-04 17:59:30.000000000 -0400
+++ ../freebios2/src/northbridge/amd/amdk8/raminit.c	2003-08-04 18:47:31.000000000 -0400
@@ -1124,6 +1124,23 @@
 	}
 }
 
+//BY LYH //Fill next base reg with right value
+static void fill_last(unsigned long node_id,unsigned long base)
+{
+        unsigned i;
+        unsigned base_reg;
+        base &=0xffff0000;
+        device_t device;
+        for(device = PCI_DEV(0, 0x18, 1); device <= PCI_DEV(0, 0x1f, 1); device
++= PCI_DEV(0, 1, 0)) {
+                for(i=node_id+1;i<=7;i++) {
+                        base_reg=0x40+(i<<3);
+                        pci_write_config32(device,base_reg,base);
+                }
+        }
+}
+//BY LYH END
+ 
 static void route_dram_accesses(const struct mem_controller *ctrl,
 	unsigned long base_k, unsigned long limit_k)
 {
@@ -1276,6 +1293,9 @@
 	print_debug("\r\n");
 #endif
 	route_dram_accesses(ctrl, base_k, tom_k);
+//BY LYH
+        fill_last(ctrl->node_id, tom_k<<2);
+//BY LYH END
 	set_top_mem(tom_k);
 }
 
diff -uNr ./freebios2/src/southbridge/amd/amd8111/config.lb ../freebios2/src/southbridge/amd/amd8111/config.lb
--- ./freebios2/src/southbridge/amd/amd8111/config.lb	2003-06-17 12:51:05.000000000 -0400
+++ ../freebios2/src/southbridge/amd/amd8111/config.lb	1969-12-31 19:00:00.000000000 -0500
@@ -1,4 +0,0 @@
-driver amd8111_usb.o
-driver amd8111_lpc.o
-driver amd8111_ide.o
-driver amd8111_acpi.o



From rminnich at lanl.gov  Mon Aug  4 17:53:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 17:53:00 2003
Subject: Yh Lu patch
Message-ID: <Pine.LNX.4.44.0308041608120.30253-100000@maxroach.lanl.gov>

I took a long look and it looked ok. I have patched and tested my 
linuxbios for HDAMA and it works fine. 

I am going to commit these patches.

ron




From ebiederman at lnxi.com  Mon Aug  4 19:01:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 19:01:01 2003
Subject: Weird behaviour with new config method
In-Reply-To: <p06001a0fbb547ab08eeb@[10.0.1.2]>
References: <Pine.LNX.4.44.0308041456170.30253-100000@maxroach.lanl.gov>
	<p06001a0fbb547ab08eeb@[10.0.1.2]>
Message-ID: <m3u18x3t9f.fsf@maxwell.lnxi.com>

Greg Watson <gwatson at lanl.gov> writes:

> At 2:56 PM -0600 4/8/03, ron minnich wrote:
> >On 4 Aug 2003, Eric W. Biederman wrote:
> >
> >>  Previously when we had this conversation we tried for a minimum python
> >>  of 1.5 and the old config tool manages that.  We may need to bump the
> >>  python requirement but we this needs investigation to see why the earlier
> >>  versions of python have problems.
> >>
> >
> >we're going to have to bump minimums anyway. romcc fails for me on RH 7.3.

Hmm.  I will take a look later.  But my default compiler is 2.95.4 and I believe
romcc still compiles with that.  Dropping egcs-2.91.66 is unfortunate but
livable.  With compilers and even more so with binutils pushing the
requirements is not a big deal as it is necessary to support the
newest hardware.

We have no innate requirement for python which makes me worry much
more about pushing the version.

> It'll have to be version 2.0 at a minimum since yapps (and config.g) depends on
> some 2.0 features. It maybe a later version depending on what Eric's problem
> turns out to be.

Hopefully we can track that down.  A few weeks ago it worked with
my version 2.1 of python.

Eric



From ebiederman at lnxi.com  Mon Aug  4 19:21:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 19:21:00 2003
Subject: Yh Lu's patches
In-Reply-To: <Pine.LNX.4.44.0308041509520.30253-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308041509520.30253-100000@maxroach.lanl.gov>
Message-ID: <m3el01yp2a.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> Can Eric and Stefan and others interested please take a quick look at
> this, it is the non-tyan mods from Yh Lu.
> 
> I am going to commit the tyan mods in a few minutes.
> 
> thanks
> 
> ron
> diff -uNr ./freebios2/src/cpu/k8/cpufixup.c ../freebios2/src/cpu/k8/cpufixup.c
> --- ./freebios2/src/cpu/k8/cpufixup.c	2003-08-04 17:57:43.000000000 -0400
> +++ ../freebios2/src/cpu/k8/cpufixup.c	2003-08-04 19:41:18.000000000 -0400
> @@ -29,15 +29,28 @@
>  		mmio_basek = tomk;
>  	}
>  
> -	/* Setup TOP_MEM */
> -	msr.hi = mmio_basek >> 22;
> -	msr.lo = mmio_basek << 10;
> -	wrmsr(TOP_MEM, msr);
> +#if 1
> +        /* Report the amount of memory. */
> +        print_debug("cpufixup RAM: 0x");
> +        print_debug_hex32(tomk);
> +        print_debug(" KB\r\n");
> +#endif
> +
> +        /* Now set top of memory */
> +        msr.lo = (tomk & 0x003fffff) << 10;
> +        msr.hi = (tomk & 0xffc00000) >> 22;
> +        wrmsr(TOP_MEM2, msr);
> +
> +        /* Leave a 64M hole between TOP_MEM and TOP_MEM2
> +         * so I can see my rom chip and other I/O devices.
> +         */
> +        if (tomk >= 0x003f0000) {
> +                tomk = 0x3f0000;
> +        } //    tom_k = 0x3c0000;
> +        msr.lo = (tomk & 0x003fffff) << 10;
> +        msr.hi = (tomk & 0xffc00000) >> 22;
> +        wrmsr(TOP_MEM, msr);
>  
> -	/* Setup TOP_MEM2 */
> -	msr.hi = tomk >> 22;
> -	msr.lo = tomk << 10;
> -	wrmsr(TOP_MEM2, msr);
>  
>  	/* zero the IORR's before we enable to prevent
>  	 * undefined side effects.

This bit is redundant. 
I described the change to Yinghai Lu and he made is own version of it.

And in fact it is actively wrong. mmio_basek does a much better job
of leaving an I/O hole there, then simply subtracting 64MB from 4GB.


> diff -uNr ./freebios2/src/include/console/console.h
> ../freebios2/src/include/console/console.h
> 
> --- ./freebios2/src/include/console/console.h 2003-07-19 00:28:21.000000000
> -0400
> 
> +++ ../freebios2/src/include/console/console.h 2003-08-02 01:40:57.000000000
> -0400
> 
> @@ -92,34 +92,34 @@
>  #define print_debug_char(CH)   printk_debug  ("%c", (CH))
>  #define print_spew_char(CH)    printk_spew   ("%c", (CH))
>  
> -#define print_emerg_hex8(HEX)   printk_emerg  ("%08x",  (HEX))
> -#define print_alert_hex8(HEX)   printk_alert  ("%08x",  (HEX))
> -#define print_crit_hex8(HEX)    printk_crit   ("%08x",  (HEX))
> -#define print_err_hex8(HEX)     printk_err    ("%08x",  (HEX))
> -#define print_warning_hex8(HEX) printk_warning("%08x",  (HEX))
> -#define print_notice_hex8(HEX)  printk_notice ("%08x",  (HEX))
> -#define print_info_hex8(HEX)    printk_info   ("%08x",  (HEX))
> -#define print_debug_hex8(HEX)   printk_debug  ("%08x",  (HEX))
> -#define print_spew_hex8(HEX)    printk_spew   ("%08x",  (HEX))
> +#define print_emerg_hex8(HEX)   printk_emerg  ("%02x",  (HEX))
> +#define print_alert_hex8(HEX)   printk_alert  ("%02x",  (HEX))
> +#define print_crit_hex8(HEX)    printk_crit   ("%02x",  (HEX))
> +#define print_err_hex8(HEX)     printk_err    ("%02x",  (HEX))
> +#define print_warning_hex8(HEX) printk_warning("%02x",  (HEX))
> +#define print_notice_hex8(HEX)  printk_notice ("%02x",  (HEX))
> +#define print_info_hex8(HEX)    printk_info   ("%02x",  (HEX))
> +#define print_debug_hex8(HEX)   printk_debug  ("%02x",  (HEX))
> +#define print_spew_hex8(HEX)    printk_spew   ("%02x",  (HEX))
>  
> -#define print_emerg_hex16(HEX)   printk_emerg  ("%016x", (HEX))
> -#define print_alert_hex16(HEX)   printk_alert  ("%016x", (HEX))
> -#define print_crit_hex16(HEX)    printk_crit   ("%016x", (HEX))
> -#define print_err_hex16(HEX)     printk_err    ("%016x", (HEX))
> -#define print_warning_hex16(HEX) printk_warning("%016x", (HEX))
> -#define print_notice_hex16(HEX)  printk_notice ("%016x", (HEX))
> -#define print_info_hex16(HEX)    printk_info   ("%016x", (HEX))
> -#define print_debug_hex16(HEX)   printk_debug  ("%016x", (HEX))
> -#define print_spew_hex16(HEX)    printk_spew   ("%016x", (HEX))
> +#define print_emerg_hex16(HEX)   printk_emerg  ("%04x", (HEX))
> +#define print_alert_hex16(HEX)   printk_alert  ("%04x", (HEX))
> +#define print_crit_hex16(HEX)    printk_crit   ("%04x", (HEX))
> +#define print_err_hex16(HEX)     printk_err    ("%04x", (HEX))
> +#define print_warning_hex16(HEX) printk_warning("%04x", (HEX))
> +#define print_notice_hex16(HEX)  printk_notice ("%04x", (HEX))
> +#define print_info_hex16(HEX)    printk_info   ("%04x", (HEX))
> +#define print_debug_hex16(HEX)   printk_debug  ("%04x", (HEX))
> +#define print_spew_hex16(HEX)    printk_spew   ("%04x", (HEX))
>  
> -#define print_emerg_hex32(HEX)   printk_emerg  ("%032x", (HEX))
> -#define print_alert_hex32(HEX)   printk_alert  ("%032x", (HEX))
> -#define print_crit_hex32(HEX)    printk_crit   ("%032x", (HEX))
> -#define print_err_hex32(HEX)     printk_err    ("%032x", (HEX))
> -#define print_warning_hex32(HEX) printk_warning("%032x", (HEX))
> -#define print_notice_hex32(HEX)  printk_notice ("%032x", (HEX))
> -#define print_info_hex32(HEX)    printk_info   ("%032x", (HEX))
> -#define print_debug_hex32(HEX)   printk_debug  ("%032x", (HEX))
> -#define print_spew_hex32(HEX)    printk_spew   ("%032x", (HEX))
> +#define print_emerg_hex32(HEX)   printk_emerg  ("%08x", (HEX))
> +#define print_alert_hex32(HEX)   printk_alert  ("%08x", (HEX))
> +#define print_crit_hex32(HEX)    printk_crit   ("%08x", (HEX))
> +#define print_err_hex32(HEX)     printk_err    ("%08x", (HEX))
> +#define print_warning_hex32(HEX) printk_warning("%08x", (HEX))
> +#define print_notice_hex32(HEX)  printk_notice ("%08x", (HEX))
> +#define print_info_hex32(HEX)    printk_info   ("%08x", (HEX))
> +#define print_debug_hex32(HEX)   printk_debug  ("%08x", (HEX))
> +#define print_spew_hex32(HEX)    printk_spew   ("%08x", (HEX))

This bit is reasonable.  I thought I had already committed it but...
I typoed and did bit widths instead of nibble widths.
  
> diff -uNr ./freebios2/src/northbridge/amd/amdk8/raminit.c
> ../freebios2/src/northbridge/amd/amdk8/raminit.c
> 
> --- ./freebios2/src/northbridge/amd/amdk8/raminit.c 2003-08-04
> 17:59:30.000000000 -0400
> 
> +++ ../freebios2/src/northbridge/amd/amdk8/raminit.c 2003-08-04
> 18:47:31.000000000 -0400
> 
> @@ -1124,6 +1124,23 @@
>  	}
>  }
>  
> +//BY LYH //Fill next base reg with right value
> +static void fill_last(unsigned long node_id,unsigned long base)
> +{
> +        unsigned i;
> +        unsigned base_reg;
> +        base &=0xffff0000;
> +        device_t device;
> + for(device = PCI_DEV(0, 0x18, 1); device <= PCI_DEV(0, 0x1f, 1); device
> 
> ++= PCI_DEV(0, 1, 0)) {
> +                for(i=node_id+1;i<=7;i++) {
> +                        base_reg=0x40+(i<<3);
> +                        pci_write_config32(device,base_reg,base);
> +                }
> +        }
> +}
> +//BY LYH END
> + 
>  static void route_dram_accesses(const struct mem_controller *ctrl,
>  	unsigned long base_k, unsigned long limit_k)
>  {
> @@ -1276,6 +1293,9 @@
>  	print_debug("\r\n");
>  #endif
>  	route_dram_accesses(ctrl, base_k, tom_k);
> +//BY LYH
> +        fill_last(ctrl->node_id, tom_k<<2);
> +//BY LYH END
>  	set_top_mem(tom_k);
>  }

This is a bug fix for a buggy kernel.   It is extra code but it should
not be a real problem.
  
> diff -uNr ./freebios2/src/southbridge/amd/amd8111/config.lb
> ../freebios2/src/southbridge/amd/amd8111/config.lb
> 
> --- ./freebios2/src/southbridge/amd/amd8111/config.lb 2003-06-17
> 12:51:05.000000000 -0400
> 
> +++ ../freebios2/src/southbridge/amd/amd8111/config.lb 1969-12-31
> 19:00:00.000000000 -0500
> 
> @@ -1,4 +0,0 @@
> -driver amd8111_usb.o
> -driver amd8111_lpc.o
> -driver amd8111_ide.o
> -driver amd8111_acpi.o

Hmm.  Removing all of those driver statements looks wrong...

Eric



From ebiederman at lnxi.com  Mon Aug  4 19:25:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 19:25:01 2003
Subject: Commit on freebios2
In-Reply-To: <Pine.LNX.4.44.0308041505210.30253-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308041505210.30253-100000@maxroach.lanl.gov>
Message-ID: <m3adapyoxb.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> I have made the initial commits for the items Stefan requested; comments 
> welcome. 
> 
> Here is the log.
> 
> Commits for the new config static device design, to allow more than one 
> static 
> cpu of a certain type and to eliminate the 
> cpu p5
> cpu p6
> cpu k7
> 
> nonsense in the old config files.

Cool.
 
> Next step is to hook into Eric's pci device stuff.

This hasn't happened yet?
I thought that had happened a while ago..

> CVS: 
> ----------------------------------------------------------------------
> CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
> CVS:
> CVS: Committing in .
> CVS:
> CVS: Modified Files:
> CVS:    src/cpu/k7/Config.lb src/cpu/k8/Config.lb
> CVS:    src/cpu/k8/cpufixup.c src/cpu/p6/Config.lb
> CVS:    src/mainboard/arima/hdama/Config.lb
> CVS:    src/mainboard/arima/hdama/mainboard.c util/newconfig/config.g
> CVS: 
> ----------------------------------------------------------------------
> 
> Here is the fragment of the arima mainboard file that uses the new code; 
> note that it is incomplete, I hope to fill it in.
> 
> cpu k8 "cpu0"
>   register "up" = "{.chip = &amd8111, .ht_width=8, .ht_speed=200}"
> end
> 
> cpu k8 "cpu1"
> end

Interesting.  I will take a look in a moment.  

A good question is how much of this stuff can we get working in romcc.
Currently romcc doesn't cope with constant pointers. But that is because
of lazyness and not something more practical.

Eric



From YhLu at tyan.com  Mon Aug  4 19:37:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug  4 19:37:01 2003
Subject: Yh Lu's patches
Message-ID: <3174569B9743D511922F00A0C943142302FCA215@TYANWEB>

Eric,

As for cpufixup.c, actually I grab the fragment from raminit.c's
set_top_ram.
I don't want to make my own, because I can not access the most update code
because of 24 hours delay.

Fill_last:
Can someone raise the bug to LinuxKernel developer team?


There are Config.lb and config.lb in the southbridge/amd/amd8111.
We should get rid of config.lb.

Regards

Yinghai Lu

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2003?8?4? 16:35
???: ron minnich
??: linuxbios at clustermatic.org
??: Re: Yh Lu's patches

ron minnich <rminnich at lanl.gov> writes:

> Can Eric and Stefan and others interested please take a quick look at
> this, it is the non-tyan mods from Yh Lu.
> 
> I am going to commit the tyan mods in a few minutes.
> 
> thanks
> 
> ron
> diff -uNr ./freebios2/src/cpu/k8/cpufixup.c
../freebios2/src/cpu/k8/cpufixup.c
> --- ./freebios2/src/cpu/k8/cpufixup.c	2003-08-04 17:57:43.000000000 -0400
> +++ ../freebios2/src/cpu/k8/cpufixup.c	2003-08-04
19:41:18.000000000 -0400
> @@ -29,15 +29,28 @@
>  		mmio_basek = tomk;
>  	}
>  
> -	/* Setup TOP_MEM */
> -	msr.hi = mmio_basek >> 22;
> -	msr.lo = mmio_basek << 10;
> -	wrmsr(TOP_MEM, msr);
> +#if 1
> +        /* Report the amount of memory. */
> +        print_debug("cpufixup RAM: 0x");
> +        print_debug_hex32(tomk);
> +        print_debug(" KB\r\n");
> +#endif
> +
> +        /* Now set top of memory */
> +        msr.lo = (tomk & 0x003fffff) << 10;
> +        msr.hi = (tomk & 0xffc00000) >> 22;
> +        wrmsr(TOP_MEM2, msr);
> +
> +        /* Leave a 64M hole between TOP_MEM and TOP_MEM2
> +         * so I can see my rom chip and other I/O devices.
> +         */
> +        if (tomk >= 0x003f0000) {
> +                tomk = 0x3f0000;
> +        } //    tom_k = 0x3c0000;
> +        msr.lo = (tomk & 0x003fffff) << 10;
> +        msr.hi = (tomk & 0xffc00000) >> 22;
> +        wrmsr(TOP_MEM, msr);
>  
> -	/* Setup TOP_MEM2 */
> -	msr.hi = tomk >> 22;
> -	msr.lo = tomk << 10;
> -	wrmsr(TOP_MEM2, msr);
>  
>  	/* zero the IORR's before we enable to prevent
>  	 * undefined side effects.

This bit is redundant. 
I described the change to Yinghai Lu and he made is own version of it.

And in fact it is actively wrong. mmio_basek does a much better job
of leaving an I/O hole there, then simply subtracting 64MB from 4GB.


> diff -uNr ./freebios2/src/include/console/console.h
> ../freebios2/src/include/console/console.h
> 
> --- ./freebios2/src/include/console/console.h 2003-07-19
00:28:21.000000000
> -0400
> 
> +++ ../freebios2/src/include/console/console.h 2003-08-02
01:40:57.000000000
> -0400
> 
> @@ -92,34 +92,34 @@
>  #define print_debug_char(CH)   printk_debug  ("%c", (CH))
>  #define print_spew_char(CH)    printk_spew   ("%c", (CH))
>  
> -#define print_emerg_hex8(HEX)   printk_emerg  ("%08x",  (HEX))
> -#define print_alert_hex8(HEX)   printk_alert  ("%08x",  (HEX))
> -#define print_crit_hex8(HEX)    printk_crit   ("%08x",  (HEX))
> -#define print_err_hex8(HEX)     printk_err    ("%08x",  (HEX))
> -#define print_warning_hex8(HEX) printk_warning("%08x",  (HEX))
> -#define print_notice_hex8(HEX)  printk_notice ("%08x",  (HEX))
> -#define print_info_hex8(HEX)    printk_info   ("%08x",  (HEX))
> -#define print_debug_hex8(HEX)   printk_debug  ("%08x",  (HEX))
> -#define print_spew_hex8(HEX)    printk_spew   ("%08x",  (HEX))
> +#define print_emerg_hex8(HEX)   printk_emerg  ("%02x",  (HEX))
> +#define print_alert_hex8(HEX)   printk_alert  ("%02x",  (HEX))
> +#define print_crit_hex8(HEX)    printk_crit   ("%02x",  (HEX))
> +#define print_err_hex8(HEX)     printk_err    ("%02x",  (HEX))
> +#define print_warning_hex8(HEX) printk_warning("%02x",  (HEX))
> +#define print_notice_hex8(HEX)  printk_notice ("%02x",  (HEX))
> +#define print_info_hex8(HEX)    printk_info   ("%02x",  (HEX))
> +#define print_debug_hex8(HEX)   printk_debug  ("%02x",  (HEX))
> +#define print_spew_hex8(HEX)    printk_spew   ("%02x",  (HEX))
>  
> -#define print_emerg_hex16(HEX)   printk_emerg  ("%016x", (HEX))
> -#define print_alert_hex16(HEX)   printk_alert  ("%016x", (HEX))
> -#define print_crit_hex16(HEX)    printk_crit   ("%016x", (HEX))
> -#define print_err_hex16(HEX)     printk_err    ("%016x", (HEX))
> -#define print_warning_hex16(HEX) printk_warning("%016x", (HEX))
> -#define print_notice_hex16(HEX)  printk_notice ("%016x", (HEX))
> -#define print_info_hex16(HEX)    printk_info   ("%016x", (HEX))
> -#define print_debug_hex16(HEX)   printk_debug  ("%016x", (HEX))
> -#define print_spew_hex16(HEX)    printk_spew   ("%016x", (HEX))
> +#define print_emerg_hex16(HEX)   printk_emerg  ("%04x", (HEX))
> +#define print_alert_hex16(HEX)   printk_alert  ("%04x", (HEX))
> +#define print_crit_hex16(HEX)    printk_crit   ("%04x", (HEX))
> +#define print_err_hex16(HEX)     printk_err    ("%04x", (HEX))
> +#define print_warning_hex16(HEX) printk_warning("%04x", (HEX))
> +#define print_notice_hex16(HEX)  printk_notice ("%04x", (HEX))
> +#define print_info_hex16(HEX)    printk_info   ("%04x", (HEX))
> +#define print_debug_hex16(HEX)   printk_debug  ("%04x", (HEX))
> +#define print_spew_hex16(HEX)    printk_spew   ("%04x", (HEX))
>  
> -#define print_emerg_hex32(HEX)   printk_emerg  ("%032x", (HEX))
> -#define print_alert_hex32(HEX)   printk_alert  ("%032x", (HEX))
> -#define print_crit_hex32(HEX)    printk_crit   ("%032x", (HEX))
> -#define print_err_hex32(HEX)     printk_err    ("%032x", (HEX))
> -#define print_warning_hex32(HEX) printk_warning("%032x", (HEX))
> -#define print_notice_hex32(HEX)  printk_notice ("%032x", (HEX))
> -#define print_info_hex32(HEX)    printk_info   ("%032x", (HEX))
> -#define print_debug_hex32(HEX)   printk_debug  ("%032x", (HEX))
> -#define print_spew_hex32(HEX)    printk_spew   ("%032x", (HEX))
> +#define print_emerg_hex32(HEX)   printk_emerg  ("%08x", (HEX))
> +#define print_alert_hex32(HEX)   printk_alert  ("%08x", (HEX))
> +#define print_crit_hex32(HEX)    printk_crit   ("%08x", (HEX))
> +#define print_err_hex32(HEX)     printk_err    ("%08x", (HEX))
> +#define print_warning_hex32(HEX) printk_warning("%08x", (HEX))
> +#define print_notice_hex32(HEX)  printk_notice ("%08x", (HEX))
> +#define print_info_hex32(HEX)    printk_info   ("%08x", (HEX))
> +#define print_debug_hex32(HEX)   printk_debug  ("%08x", (HEX))
> +#define print_spew_hex32(HEX)    printk_spew   ("%08x", (HEX))

This bit is reasonable.  I thought I had already committed it but...
I typoed and did bit widths instead of nibble widths.
  
> diff -uNr ./freebios2/src/northbridge/amd/amdk8/raminit.c
> ../freebios2/src/northbridge/amd/amdk8/raminit.c
> 
> --- ./freebios2/src/northbridge/amd/amdk8/raminit.c 2003-08-04
> 17:59:30.000000000 -0400
> 
> +++ ../freebios2/src/northbridge/amd/amdk8/raminit.c 2003-08-04
> 18:47:31.000000000 -0400
> 
> @@ -1124,6 +1124,23 @@
>  	}
>  }
>  
> +//BY LYH //Fill next base reg with right value
> +static void fill_last(unsigned long node_id,unsigned long base)
> +{
> +        unsigned i;
> +        unsigned base_reg;
> +        base &=0xffff0000;
> +        device_t device;
> + for(device = PCI_DEV(0, 0x18, 1); device <= PCI_DEV(0, 0x1f, 1); device
> 
> ++= PCI_DEV(0, 1, 0)) {
> +                for(i=node_id+1;i<=7;i++) {
> +                        base_reg=0x40+(i<<3);
> +                        pci_write_config32(device,base_reg,base);
> +                }
> +        }
> +}
> +//BY LYH END
> + 
>  static void route_dram_accesses(const struct mem_controller *ctrl,
>  	unsigned long base_k, unsigned long limit_k)
>  {
> @@ -1276,6 +1293,9 @@
>  	print_debug("\r\n");
>  #endif
>  	route_dram_accesses(ctrl, base_k, tom_k);
> +//BY LYH
> +        fill_last(ctrl->node_id, tom_k<<2);
> +//BY LYH END
>  	set_top_mem(tom_k);
>  }

This is a bug fix for a buggy kernel.   It is extra code but it should
not be a real problem.
  
> diff -uNr ./freebios2/src/southbridge/amd/amd8111/config.lb
> ../freebios2/src/southbridge/amd/amd8111/config.lb
> 
> --- ./freebios2/src/southbridge/amd/amd8111/config.lb 2003-06-17
> 12:51:05.000000000 -0400
> 
> +++ ../freebios2/src/southbridge/amd/amd8111/config.lb 1969-12-31
> 19:00:00.000000000 -0500
> 
> @@ -1,4 +0,0 @@
> -driver amd8111_usb.o
> -driver amd8111_lpc.o
> -driver amd8111_ide.o
> -driver amd8111_acpi.o

Hmm.  Removing all of those driver statements looks wrong...

Eric

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Mon Aug  4 19:39:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 19:39:01 2003
Subject: Fixes for Tyan s2880
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA1C0@TYANWEB>
References: <3174569B9743D511922F00A0C943142302FCA1C0@TYANWEB>
Message-ID: <m365ldyoao.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> It works on 12G too.
> 
> Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
> Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
> Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
> Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
> Setting variable MTRR 4, base: 4096MB, range: 4096MB, type WB
> Setting variable MTRR 5, base: 8192MB, range: 4096MB, type WB
> 
> But I think you need to optimize mtrr.c now, otherwise it may not work with
> arima Hadama. 8*2=16G, will use out MTRR.

I agree we are very close, to that point.  And it does look like
 
However I suspect the 16G case to look like:

> Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
> Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
> Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
> Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
> Setting variable MTRR 4, base: 4096MB, range: 4096MB, type WB
> Setting variable MTRR 5, base: 8192MB, range: 8192MB, type WB

I hadn't realized we would start using > 1 mtrr after 4GB.

The challenge is that the kernel really need to be shown how to handle
overlapping mtrrs.  That would let me handle the first 4 mtrrs (0-3) with
just two mtrrs, fairly reliably.

Eric



From ebiederman at lnxi.com  Mon Aug  4 20:40:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 20:40:00 2003
Subject: Yh Lu's patches
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA215@TYANWEB>
References: <3174569B9743D511922F00A0C943142302FCA215@TYANWEB>
Message-ID: <m3ispcvs3e.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> As for cpufixup.c, actually I grab the fragment from raminit.c's
> set_top_ram.
> I don't want to make my own, because I can not access the most update code
> because of 24 hours delay.

Not a problem with what you did.  Just a problem with inclusion of the code.
The only real problem was the one line where I shifted by 12 instead of 10.
Otherwise the original is fine.

> Fill_last:
> Can someone raise the bug to LinuxKernel developer team?

Done.  Hmm.  The Linux kernel developer team is an interesting concept...

> There are Config.lb and config.lb in the southbridge/amd/amd8111.
> We should get rid of config.lb.

Agreed.  ... That is why you deleted all of the driver statements.
That makes sense now.

Eric





From ebiederman at lnxi.com  Mon Aug  4 20:49:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 20:49:00 2003
Subject: heads up with new config method.
In-Reply-To: <Pine.LNX.4.44.0308041255510.30253-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308041255510.30253-100000@maxroach.lanl.gov>
Message-ID: <m33cggsyhn.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> I am going to make a very minor tweak in a few minutes that should not 
> affect any of you. 
> 
> But we'll see. This tweak is aimed at letting us shrink the top-level 
> Config.lb files to almost nothing.

I now have a mysterious requirement to have a chip.h in
the arima/hdama mainboard directory.

This looks like a new a requirement, and the file was not added.

Eric



From rminnich at lanl.gov  Mon Aug  4 21:50:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 21:50:00 2003
Subject: Yh Lu's patches
In-Reply-To: <m3el01yp2a.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308042005060.3602-100000@maxroach.lanl.gov>

On 4 Aug 2003, Eric W. Biederman wrote:

> > diff -uNr ./freebios2/src/southbridge/amd/amd8111/config.lb
> > ../freebios2/src/southbridge/amd/amd8111/config.lb
> > 
> > --- ./freebios2/src/southbridge/amd/amd8111/config.lb 2003-06-17
> > 12:51:05.000000000 -0400
> > 
> > +++ ../freebios2/src/southbridge/amd/amd8111/config.lb 1969-12-31
> > 19:00:00.000000000 -0500
> > 
> > @@ -1,4 +0,0 @@
> > -driver amd8111_usb.o
> > -driver amd8111_lpc.o
> > -driver amd8111_ide.o
> > -driver amd8111_acpi.o
> 
> Hmm.  Removing all of those driver statements looks wrong...

what's really happening is deletion of the mis-named config.lb file, as we 
replaced it with Config.lb.

Thanks very much for looking at this, and also for trying out the new 
config tool.

ron



From rminnich at lanl.gov  Mon Aug  4 21:51:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 21:51:01 2003
Subject: Commit on freebios2
In-Reply-To: <m3adapyoxb.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308042006150.3602-100000@maxroach.lanl.gov>

On 4 Aug 2003, Eric W. Biederman wrote:

> This hasn't happened yet?
> I thought that had happened a while ago..
no, sorry, we just kind of worked it out last week, as the PPC really does 
things quite differently.

ron



From rminnich at lanl.gov  Mon Aug  4 22:05:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 22:05:01 2003
Subject: Yh Lu's patches
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA215@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308042020200.3723-100000@maxroach.lanl.gov>

On Mon, 4 Aug 2003, YhLu wrote:

> There are Config.lb and config.lb in the southbridge/amd/amd8111.
> We should get rid of config.lb.

done and comitted.

ron



From rminnich at lanl.gov  Mon Aug  4 22:09:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 22:09:01 2003
Subject: heads up with new config method.
In-Reply-To: <m33cggsyhn.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308042024100.3723-100000@maxroach.lanl.gov>

On 4 Aug 2003, Eric W. Biederman wrote:

> I now have a mysterious requirement to have a chip.h in
> the arima/hdama mainboard directory.

my fault! I forgot to cvs add.

Fixed and committed.

FWIW this build is working well for me as of today for both etherboot and 
kernel.

ron



From rminnich at lanl.gov  Mon Aug  4 22:17:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug  4 22:17:01 2003
Subject: HDAMA status at LANL
Message-ID: <Pine.LNX.4.44.0308042029530.3798-100000@maxroach.lanl.gov>

well, to sum up, on a 1 CPU system with arima/hdama
- etherboot is working fine
- linux loading from flash is working fine
- once linux is loaded, it can't find an IRQ for the on-board 
  ethernet. There is a PIRQ problem I will try to fix tomorrow.

What's really neat, is that the fear level of cvs update is greatly 
reduced. A week or two ago I tar'ed up the tree every time I did a cvs 
update, for fear that I'd be left with a busted tree. The tree is solid 
enough that this worry is over.

The K8 is moving fast! We hope to have a 4-node bproc cluster working this 
week. There will be some more interesting K8 news next week :-)

In a day or two we start the NEWISYS port.

ron



From sc at flagen.com  Mon Aug  4 22:21:00 2003
From: sc at flagen.com (David Hendricks)
Date: Mon Aug  4 22:21:00 2003
Subject: VGA
In-Reply-To: <Pine.LNX.4.44.0308041323340.30253-100000@maxroach.lanl.gov>
References: <3174569B9743D511922F00A0C943142302FCA1AE@TYANWEB> 
     <Pine.LNX.4.44.0308041323340.30253-100000@maxroach.lanl.gov>
Message-ID: <39166.68.35.24.31.1060054183.squirrel@mail.flagen.com>

I've been carefully stepping through the spd_82801.c code and testing it
out on a E7500. Ron fixed a bug with pcibios.c, but it was only an
incremental step toward solving this problem.

> On Mon, 4 Aug 2003, YhLu wrote:
>
>> How about VGA support status on LinuxBIOS?
>
> we're hung up on the 7505 chipset right now, we can't get it to work
> correctly with SPD.
>
>> I also wonder if AGP addon card need init too.
>
> that is an ongoing project here, with expected completion in august.
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From ebiederman at lnxi.com  Mon Aug  4 23:51:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug  4 23:51:01 2003
Subject: heads up with new config method.
In-Reply-To: <Pine.LNX.4.44.0308042024100.3723-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308042024100.3723-100000@maxroach.lanl.gov>
Message-ID: <m3y8y8kaoi.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 4 Aug 2003, Eric W. Biederman wrote:
> 
> > I now have a mysterious requirement to have a chip.h in
> > the arima/hdama mainboard directory.
> 
> my fault! I forgot to cvs add.
> 
> Fixed and committed.
> 
> FWIW this build is working well for me as of today for both etherboot and 
> kernel.

If you could please verify that is the only one because I think
I ran into at least one more chips.h that was not committed.

If I can get the thing to build I can comment a lot more fairly.

Eric



From rminnich at lanl.gov  Tue Aug  5 09:12:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 09:12:00 2003
Subject: heads up with new config method.
In-Reply-To: <m3y8y8kaoi.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308050727540.7947-100000@maxroach.lanl.gov>

On 4 Aug 2003, Eric W. Biederman wrote:

> If you could please verify that is the only one because I think
> I ran into at least one more chips.h that was not committed.

I'll look again but ... the clean checkout yesterday built fine, which is 
odd.

ron



From rminnich at lanl.gov  Tue Aug  5 09:22:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 09:22:00 2003
Subject: heads up with new config method.
In-Reply-To: <Pine.LNX.4.44.0308050727540.7947-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.44.0308050737060.7947-100000@maxroach.lanl.gov>

On Tue, 5 Aug 2003, ron minnich wrote:

> I'll look again but ... the clean checkout yesterday built fine, which is 
> odd.

I mean odd as in the sense of 'works for me, but not for you'. I actually 
still can't do a real build on RH 7.3 as romcc still fails on that 
platform.

ron



From rminnich at lanl.gov  Tue Aug  5 09:28:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 09:28:01 2003
Subject: heads up with new config method.
In-Reply-To: <Pine.LNX.4.44.0308050737060.7947-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.44.0308050744010.8486-100000@maxroach.lanl.gov>

On Tue, 5 Aug 2003, ron minnich wrote:

> I mean odd as in the sense of 'works for me, but not for you'. I actually 
> still can't do a real build on RH 7.3 as romcc still fails on that 
> platform.
> 

yep it was missing a chip.h. 

Try it now.

ron



From rminnich at lanl.gov  Tue Aug  5 09:34:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 09:34:00 2003
Subject: config tool problem on early python
Message-ID: <Pine.LNX.4.44.0308050749460.8517-100000@maxroach.lanl.gov>

OK, I see the problem, and I'll talk to greg about it. He is on the way to 
Oz so it will take another day or so.

ron



From rminnich at lanl.gov  Tue Aug  5 09:38:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 09:38:00 2003
Subject: linking static to dynamic devices
Message-ID: <Pine.LNX.4.44.0308050751160.8535-100000@maxroach.lanl.gov>

The next obvious step is to link static to dynamic devices. 

One issue is that we define CPUs statically, up to the maximum the
mainboard can take. But they may not be there. How do we express this? 
Greg had some ideas, so he may jump in once he gets off the plane.

I do think the new static architecture will allow for things like 
cpufixup() calls per-cpu, etc. but we'll see.

ron



From gwatson at lanl.gov  Tue Aug  5 11:30:00 2003
From: gwatson at lanl.gov (Greg Watson)
Date: Tue Aug  5 11:30:00 2003
Subject: linking static to dynamic devices
In-Reply-To: <Pine.LNX.4.44.0308050751160.8535-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308050751160.8535-100000@maxroach.lanl.gov>
Message-ID: <p06001a09bb557d08ff0d@[10.0.1.2]>

I'm not on the plane yet... :-)

My suggestion was to add an 'optional' keyword to the cpu device. So 
you would declare something like:

cpu k8 "cpu0"
	...
end
cpu k8 "cpu1"
	optional
	...
end
cpu k8 "cpu2"
	optional
	...
end
cpu k8 "cpu3"
	optional
	...
end

The effect of the optional keyword is to call a special function 
"probe" which is added to the chip_control structure. probe() is 
called before any calls to enable() and the result (0=success, <0 
fail) is used to set a "present" flag in the chip structure. probe() 
should not do anything else except check for existence (any other 
configuration is done in enable()). Non-optional devices always have 
their present flag set to 1.

struct chip_control {
   void (*enable)(struct chip *, enum chip_pass);
   int (*probe)(struct chip *);
   char *path;     /* the default path. Can be overridden
                    * by commands in config
                    */
   // This is the print name for debugging
   char *name;
};

struct chip {
   struct chip_control *control; /* for this device */
   int present; /* device is present */
   char *path; /* can be 0, in which case the default is taken */
   char *configuration; /* can be 0. */
   int irq;
   struct chip *next, *children;
   /* there is one of these for each INSTANCE of a chip */
   void *chip_info; /* the dreaded "void *" */
};


Greg


At 7:54 AM -0600 5/8/03, ron minnich wrote:
>The next obvious step is to link static to dynamic devices.
>
>One issue is that we define CPUs statically, up to the maximum the
>mainboard can take. But they may not be there. How do we express this?
>Greg had some ideas, so he may jump in once he gets off the plane.
>
>I do think the new static architecture will allow for things like
>cpufixup() calls per-cpu, etc. but we'll see.
>
>ron
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios



From gwatson at lanl.gov  Tue Aug  5 12:21:01 2003
From: gwatson at lanl.gov (Greg Watson)
Date: Tue Aug  5 12:21:01 2003
Subject: new config version skew problem
Message-ID: <p06001a0ebb558d78d956@[10.0.1.2]>

I found the problem that was causing the error with python 2.1. 
Please test new version.

Greg


From YhLu at tyan.com  Tue Aug  5 13:12:01 2003
From: YhLu at tyan.com (YhLu)
Date: Tue Aug  5 13:12:01 2003
Subject: linking static to dynamic devices
Message-ID: <3174569B9743D511922F00A0C943142302FCA27A@TYANWEB>

If you want cpufixup called by per cpu, you may need to modify
cpu_initialize function and maybe add one pass for it.

Regards

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?5? 6:54
???: linuxbios at clustermatic.org
??: linking static to dynamic devices

The next obvious step is to link static to dynamic devices. 

One issue is that we define CPUs statically, up to the maximum the
mainboard can take. But they may not be there. How do we express this? 
Greg had some ideas, so he may jump in once he gets off the plane.

I do think the new static architecture will allow for things like 
cpufixup() calls per-cpu, etc. but we'll see.

ron

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Tue Aug  5 13:18:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 13:18:01 2003
Subject: linking static to dynamic devices
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA27A@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308051133540.8917-100000@maxroach.lanl.gov>

On Tue, 5 Aug 2003, YhLu wrote:

> If you want cpufixup called by per cpu, you may need to modify
> cpu_initialize function and maybe add one pass for it.

I plan to look at this  tomorrow.

ron
> 
> Regards



From rminnich at lanl.gov  Tue Aug  5 13:30:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 13:30:00 2003
Subject: HDAMA status
Message-ID: <Pine.LNX.4.44.0308051141490.8917-100000@maxroach.lanl.gov>

currently, I'm having PIRQ routing problems. 

Etherboot loads the kernel just fine, and here's something very odd: 
etherboot says the two MACs are at 1:3.0 and 1:4.0; the kernel says the 
macs are at 2:3.0 and 2:4.0. 

This is odd. Any one out there have a simple explanation for me? 

Also the PIRQ in the CVS looked quite wrong, but dumping the PIRQ from a 
running BIOS and using that fails as well. 

I've gone so far as to have LinuxBIOS just jam the same interrupts the 
standard bios uses by doing this in mainboard/arima/hdama/mainboard.c

static void
enable(struct chip *chip, enum chip_pass pass)
{

        struct mainboard_arima_hdama_config *conf =
                (struct mainboard_arima_hdama_config *)chip->chip_info;

        switch (pass) {
        default: break;
        case CONF_PASS_PRE_BOOT:
        {
                struct device *p;
                /* PIRQ is still wrong. Just set ethernet for now */
                p = dev_find_slot(1, 0x18);
                pci_write_config8(p, 0x3c, 0xb);
                p = dev_find_slot(1, 0x20);
                pci_write_config8(p, 0x3c, 0xb);
                printk_err("JAM ethernet to IRQ 11!\n");
                break;
        }
        }

}

But it didn't help at all. I also tried doing the same crude thing to
device 2:3.0 but that did not help.

This business of the gige appearing on different busses is very odd; any 
explanation here?

Hints welcome :-)

ron



From gwatson at lanl.gov  Tue Aug  5 13:35:01 2003
From: gwatson at lanl.gov (Greg Watson)
Date: Tue Aug  5 13:35:01 2003
Subject: linking static to dynamic devices
In-Reply-To: <Pine.LNX.4.44.0308051133540.8917-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308051133540.8917-100000@maxroach.lanl.gov>
Message-ID: <p06001a12bb559ecae88b@[10.0.1.2]>

I forgot to add to my suggestion that enable() is only called if the 
'present' flag is set. In this model you should be able to do the cpu 
fixups at the appropriate pass in enable().

Greg

At 11:34 AM -0600 5/8/03, ron minnich wrote:
>On Tue, 5 Aug 2003, YhLu wrote:
>
>>  If you want cpufixup called by per cpu, you may need to modify
>>  cpu_initialize function and maybe add one pass for it.
>
>I plan to look at this  tomorrow.
>
>ron
>>
>>  Regards
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios



From YhLu at tyan.com  Tue Aug  5 13:59:01 2003
From: YhLu at tyan.com (YhLu)
Date: Tue Aug  5 13:59:01 2003
Subject: HDAMA status
Message-ID: <3174569B9743D511922F00A0C943142302FCA2A0@TYANWEB>

Ron,

I have checked the mptable.c and irq_table.c for hdama. They seem got some
problem.

And you maybe need to re-produce the two files.

Regards

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?5? 10:46
???: linuxbios at clustermatic.org
??: HDAMA status

currently, I'm having PIRQ routing problems. 

Etherboot loads the kernel just fine, and here's something very odd: 
etherboot says the two MACs are at 1:3.0 and 1:4.0; the kernel says the 
macs are at 2:3.0 and 2:4.0. 

This is odd. Any one out there have a simple explanation for me? 

Also the PIRQ in the CVS looked quite wrong, but dumping the PIRQ from a 
running BIOS and using that fails as well. 

I've gone so far as to have LinuxBIOS just jam the same interrupts the 
standard bios uses by doing this in mainboard/arima/hdama/mainboard.c

static void
enable(struct chip *chip, enum chip_pass pass)
{

        struct mainboard_arima_hdama_config *conf =
                (struct mainboard_arima_hdama_config *)chip->chip_info;

        switch (pass) {
        default: break;
        case CONF_PASS_PRE_BOOT:
        {
                struct device *p;
                /* PIRQ is still wrong. Just set ethernet for now */
                p = dev_find_slot(1, 0x18);
                pci_write_config8(p, 0x3c, 0xb);
                p = dev_find_slot(1, 0x20);
                pci_write_config8(p, 0x3c, 0xb);
                printk_err("JAM ethernet to IRQ 11!\n");
                break;
        }
        }

}

But it didn't help at all. I also tried doing the same crude thing to
device 2:3.0 but that did not help.

This business of the gige appearing on different busses is very odd; any 
explanation here?

Hints welcome :-)

ron

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Tue Aug  5 15:08:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 15:08:00 2003
Subject: more on HDAMA PIRQ table
Message-ID: <Pine.LNX.4.44.0308051318560.11457-100000@maxroach.lanl.gov>

It looks pretty wrong in the BIOS. Here are the entries for 2:3.0 and
2:4.0. This translates to (bus,devfn) of (2,0x18) and (2,0x20)

		{0x2,0x18, {{0x4, 0xdef8}, {0, 0xdef8}, \
			{0, 0xdef8}, {0, 0xdef8}}, 0x7, 0},

First, the slot is 7, not 0 as it should be for on-board. 

		{0x2,0x20, {{0x4, 0xdef8}, {0, 0xdef8}, \
			{0, 0xdef8}, {0,  0xdef8}}, 0x8, 0},

The slot is 8, not 0. 

Also, the IRQ line id is 4, and the hardware shows it as 1. 

So everything about this table is busted ....

I'll try to fix it, but this is a worrisome sign for the future, in that 
we seem to find more and more broken IRQ tables.

ron



From YhLu at tyan.com  Tue Aug  5 15:14:00 2003
From: YhLu at tyan.com (YhLu)
Date: Tue Aug  5 15:14:00 2003
Subject: Option ROM for Device.
Message-ID: <3174569B9743D511922F00A0C943142302FCA2F0@TYANWEB>

Ron,

How about the support of Option rom execution for on board device?
Some device vendors only provide option rom instead of datasheet.

Regards

Yinghai Lu


From rminnich at lanl.gov  Tue Aug  5 15:16:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 15:16:00 2003
Subject: Option ROM for Device.
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA2F0@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308051331560.11457-100000@maxroach.lanl.gov>

On Tue, 5 Aug 2003, YhLu wrote:

> How about the support of Option rom execution for on board device?
> Some device vendors only provide option rom instead of datasheet.

That's on the list. We're going to need to support it. VGA comes first.

ron



From rminnich at lanl.gov  Tue Aug  5 15:18:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 15:18:00 2003
Subject: [PATCH] fix to pcibios.c
In-Reply-To: <20030801084030.GA5756@tsn.or.jp>
Message-ID: <Pine.LNX.4.44.0308051333500.11457-100000@maxroach.lanl.gov>

On Fri, 1 Aug 2003, SONE Takeshi wrote:

> A realmode BIOS function in the LinuxBIOS didn't work properly
> (at least for me while trying to call int10h ax=4f01 of VGA BIOS),
> and below is the fix.
> With this fix, more boards and video cards might
> be able to use built-in VGA BIOS support of LinuxBIOS.

I have committed this patch, please test.

Thanks

ron



From rminnich at lanl.gov  Tue Aug  5 15:45:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 15:45:00 2003
Subject: OK, HDAMA is up as a cluster node
Message-ID: <Pine.LNX.4.44.0308051359560.11457-100000@maxroach.lanl.gov>

The PIRQ is indeed wrong. So I booted a bproc phase 2 configured with 
IO-APIC support and all is well, since the _MP_ is correct. 

Gee, this is nice. 

I guess what we should do is dynamically generate PIRQ from the _MP_ 
table?

That's for later.

ron



From rminnich at lanl.gov  Tue Aug  5 17:38:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 17:38:01 2003
Subject: new mainboard for freebios 1
Message-ID: <Pine.LNX.4.44.0308051553470.11457-100000@maxroach.lanl.gov>

the supermicro x5dae, with e7505 and 82801db

we'd like to have all new ports on freebios2 but we're short for time and 
decided to do this quick one.

ron



From rminnich at lanl.gov  Tue Aug  5 17:41:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 17:41:01 2003
Subject: XIP for K8
Message-ID: <Pine.LNX.4.44.0308051555080.11457-100000@maxroach.lanl.gov>

Stefan can you send me your info on what you did for XIP? Just want to 
make sure what I do makes sense.

ron



From rminnich at lanl.gov  Tue Aug  5 18:23:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 18:23:00 2003
Subject: smp, newconfig, hdama
Message-ID: <Pine.LNX.4.44.0308051637470.11457-100000@maxroach.lanl.gov>

fails. 

ah well it was too good to last. 

LinuxBIOS is saying that CPU #1 did not initialize. 

just FYI, this is doubtless a "setup" problem.

ron



From YhLu at tyan.com  Tue Aug  5 18:40:00 2003
From: YhLu at tyan.com (YhLu)
Date: Tue Aug  5 18:40:00 2003
Subject: smp, newconfig, hdama
Message-ID: <3174569B9743D511922F00A0C943142302FCA329@TYANWEB>

You need to change _RAMBASE to 0x4000.

Regards

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?5? 15:39
???: linuxbios at clustermatic.org
??: smp, newconfig, hdama


fails. 

ah well it was too good to last. 

LinuxBIOS is saying that CPU #1 did not initialize. 

just FYI, this is doubtless a "setup" problem.

ron

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Tue Aug  5 19:04:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 19:04:00 2003
Subject: smp, newconfig, hdama
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA329@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308051719200.11457-100000@maxroach.lanl.gov>

On Tue, 5 Aug 2003, YhLu wrote:

> You need to change _RAMBASE to 0x4000.

thank you, that did it. I now have an HDAMA running as a 2-cpu bproc slave 
node, in 32-bit mode, with an IBM T23 laptop as the master.

ron



From YhLu at tyan.com  Tue Aug  5 19:05:00 2003
From: YhLu at tyan.com (YhLu)
Date: Tue Aug  5 19:05:00 2003
Subject: smp, newconfig, hdama
Message-ID: <3174569B9743D511922F00A0C943142302FCA336@TYANWEB>

Why not try 64 bit?

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?5? 16:20
???: YhLu
??: linuxbios at clustermatic.org
??: Re: smp, newconfig, hdama

On Tue, 5 Aug 2003, YhLu wrote:

> You need to change _RAMBASE to 0x4000.

thank you, that did it. I now have an HDAMA running as a 2-cpu bproc slave 
node, in 32-bit mode, with an IBM T23 laptop as the master.

ron


From rminnich at lanl.gov  Tue Aug  5 19:09:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 19:09:00 2003
Subject: smp, newconfig, hdama
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA336@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308051724260.11457-100000@maxroach.lanl.gov>

On Tue, 5 Aug 2003, YhLu wrote:

> Why not try 64 bit?

that's next. I am waiting for something. You'll see :-)

ron



From rminnich at lanl.gov  Tue Aug  5 19:16:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug  5 19:16:01 2003
Subject: a few changes for HDAMA
Message-ID: <Pine.LNX.4.44.0308051731290.11457-100000@maxroach.lanl.gov>

1. PIRQ table derived from standard bios, but it is still wrong. 
2. have a hook in arima/hdama/mainboard.c for CONF_PASS_PRE_BOOT, 
   but it is a no-op
3. targets/arima/hdama/Config.lb now enables SMP and sets max_cpus to 2

ron



From ebiederman at lnxi.com  Tue Aug  5 23:24:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Aug  5 23:24:00 2003
Subject: new config version skew problem
In-Reply-To: <p06001a0ebb558d78d956@[10.0.1.2]>
References: <p06001a0ebb558d78d956@[10.0.1.2]>
Message-ID: <m365lbjvsf.fsf@maxwell.lnxi.com>

Greg Watson <gwatson at lanl.gov> writes:

> I found the problem that was causing the error with python 2.1. Please test new
> version.

There is progress.  What I get now with python2.1 is:

Configuring TARGET hdama
Will place Makefile, crt0.S, etc. in hdama
Configuring ROMIMAGE normal
Configuring DIR /config/Config.lb
Configuring DIR /lib/Config.lb
Configuring DIR /console/Config.lb
Configuring DIR /stream/Config.lb
Configuring DIR /devices/Config.lb
Configuring DIR /pc80/Config.lb
Configuring DIR /boot/Config.lb
Configuring PART mainboard, path arima/hdama
Configuring PART arch, path i386
Adding init file: config/crt0.base
Configuring DIR lib/Config.lb
Configuring DIR boot/Config.lb
Configuring DIR smp/Config.lb
End PART arch
===> WARNING: Option CONFIG_SMP using default value 0
Traceback (most recent call last):
  File "./freebios2/util/newconfig/config.py", line 2155, in ?
    if (not parse('board', fp.read())):
  File "./freebios2/util/newconfig/config.py", line 1800, in parse
    return wrap_error_reporter(P, rule)
  File "./freebios2/util/newconfig/yappsrt.py", line 162, in wrap_error_reporter
    try: return getattr(parser, rule)()
  File "./freebios2/util/newconfig/config.py", line 1734, in board
    romstmts = self.romstmts()
  File "./freebios2/util/newconfig/config.py", line 1719, in romstmts
    romimage = self.romimage()
  File "./freebios2/util/newconfig/config.py", line 1698, in romimage
    romstmt = self.romstmt(1)
  File "./freebios2/util/newconfig/config.py", line 1689, in romstmt
    mainboard = self.mainboard(C)
  File "./freebios2/util/newconfig/config.py", line 1668, in mainboard
    if (C): mainboard(PATH)
  File "./freebios2/util/newconfig/config.py", line 1036, in mainboard
    part('mainboard', path, 'Config.lb', 0)
  File "./freebios2/util/newconfig/config.py", line 1094, in part
    doconfigfile(srcdir, partdir, file)
  File "./freebios2/util/newconfig/config.py", line 1159, in doconfigfile
    if (not parse('cfgfile', fp.read())):
  File "./freebios2/util/newconfig/config.py", line 1800, in parse
    return wrap_error_reporter(P, rule)
  File "./freebios2/util/newconfig/yappsrt.py", line 162, in wrap_error_reporter
    try: return getattr(parser, rule)()
  File "./freebios2/util/newconfig/config.py", line 1606, in cfgfile
    stmt = self.stmt(1)
  File "./freebios2/util/newconfig/config.py", line 1548, in stmt
    arch = self.arch(C)
  File "./freebios2/util/newconfig/config.py", line 1416, in arch
    partend = self.partend(C)
  File "./freebios2/util/newconfig/config.py", line 1373, in partend
    if (C): partpop()
  File "./freebios2/util/newconfig/config.py", line 1105, in partpop
    warning("Option %s using default value %s" % (i, getformated(i, curpart.image)))
  File "./freebios2/util/newconfig/config.py", line 179, in warning
    print "%s" % loc
  File "./freebios2/util/newconfig/config.py", line 137, in __str__
    s = s + '\n' + p.at()
AttributeError: 'int' object has no attribute 'at'

With python 2.2 I get:
bash-2.05a$ python2.2 ./freebios2/util/newconfig/config.py ./Config.lb ./freebios2
Configuring TARGET hdama
Will place Makefile, crt0.S, etc. in hdama
Configuring ROMIMAGE normal
Configuring DIR /config/Config.lb
Configuring DIR /lib/Config.lb
Configuring DIR /console/Config.lb
Configuring DIR /stream/Config.lb
Configuring DIR /devices/Config.lb
Configuring DIR /pc80/Config.lb
Configuring DIR /boot/Config.lb
Configuring PART mainboard, path arima/hdama
Configuring PART arch, path i386
Adding init file: config/crt0.base
Configuring DIR lib/Config.lb
Configuring DIR boot/Config.lb
Configuring DIR smp/Config.lb
End PART arch
===> WARNING: Option CONFIG_SMP using default value 0
Config.lb:0
mainboard/arima/hdama/Config.lb:0
NO FALLBACK USED!
Configuring PART northbridge, path amd/amdk8
End PART northbridge
Configuring PART southbridge, path amd/amd8111
End PART southbridge
Configuring PART southbridge, path amd/amd8131
End PART southbridge
Configuring PART superio, path NSC/pc87360
End PART superio
Configuring DIR /pc80/Config.lb
===> WARNING: object/driver mc146818rtc previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
pc80/Config.lb:0
Configuring DIR /cpu/k8/Config.lb
Configuring DIR /cpu/k7/Config.lb
Configuring DIR /cpu/p6/Config.lb
Configuring DIR /cpu/p5/Config.lb
Configuring PART cpu, path k8
Configuring DIR /cpu/k7/Config.lb
Configuring DIR /cpu/p6/Config.lb
Configuring DIR /cpu/p5/Config.lb
===> WARNING: object/driver cpuid previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
cpu/p5/Config.lb:0
===> WARNING: object/driver mtrr previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
===> WARNING: object/driver cpufixup previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
===> WARNING: object/driver apic_timer previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
End PART cpu
Configuring DIR /cpu/k8/Config.lb
Configuring DIR /cpu/k7/Config.lb
Configuring DIR /cpu/p6/Config.lb
Configuring DIR /cpu/p5/Config.lb
===> WARNING: object/driver cpuid previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
cpu/p5/Config.lb:0
===> WARNING: object/driver mtrr previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
===> WARNING: object/driver cpufixup previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
===> WARNING: object/driver apic_timer previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
Configuring PART cpu, path k8
Configuring DIR /cpu/k7/Config.lb
Configuring DIR /cpu/p6/Config.lb
Configuring DIR /cpu/p5/Config.lb
===> WARNING: object/driver cpuid previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
cpu/p5/Config.lb:0
===> WARNING: object/driver mtrr previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
===> WARNING: object/driver cpufixup previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
===> WARNING: object/driver apic_timer previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
End PART cpu
End PART mainboard
===> WARNING: Option CONFIG_IDE_STREAM using default value 0
Config.lb:0
===> WARNING: Option AMD8111_DEV using default value 0x3800
Config.lb:0
===> WARNING: Option USE_NORMAL_IMAGE using default value 1
Config.lb:0
End ROMIMAGE
Configuring ROMIMAGE fallback
Configuring DIR /config/Config.lb
Configuring DIR /lib/Config.lb
Configuring DIR /console/Config.lb
Configuring DIR /stream/Config.lb
Configuring DIR /devices/Config.lb
Configuring DIR /pc80/Config.lb
Configuring DIR /boot/Config.lb
Configuring PART mainboard, path arima/hdama
Configuring PART arch, path i386
Adding init file: config/crt0.base
Configuring DIR lib/Config.lb
Configuring DIR boot/Config.lb
Configuring DIR smp/Config.lb
End PART arch
===> WARNING: Option CONFIG_SMP using default value 0
Config.lb:0
mainboard/arima/hdama/Config.lb:0
Configuring PART northbridge, path amd/amdk8
End PART northbridge
Configuring PART southbridge, path amd/amd8111
End PART southbridge
Configuring PART southbridge, path amd/amd8131
End PART southbridge
Configuring PART superio, path NSC/pc87360
End PART superio
Configuring DIR /pc80/Config.lb
===> WARNING: object/driver mc146818rtc previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
pc80/Config.lb:0
Configuring DIR /cpu/k8/Config.lb
Configuring DIR /cpu/k7/Config.lb
Configuring DIR /cpu/p6/Config.lb
Configuring DIR /cpu/p5/Config.lb
Configuring PART cpu, path k8
Configuring DIR /cpu/k7/Config.lb
Configuring DIR /cpu/p6/Config.lb
Configuring DIR /cpu/p5/Config.lb
===> WARNING: object/driver cpuid previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
cpu/p5/Config.lb:0
===> WARNING: object/driver mtrr previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
===> WARNING: object/driver cpufixup previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
===> WARNING: object/driver apic_timer previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
End PART cpu
Configuring DIR /cpu/k8/Config.lb
Configuring DIR /cpu/k7/Config.lb
Configuring DIR /cpu/p6/Config.lb
Configuring DIR /cpu/p5/Config.lb
===> WARNING: object/driver cpuid previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
cpu/p5/Config.lb:0
===> WARNING: object/driver mtrr previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
===> WARNING: object/driver cpufixup previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
===> WARNING: object/driver apic_timer previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
Configuring PART cpu, path k8
Configuring DIR /cpu/k7/Config.lb
Configuring DIR /cpu/p6/Config.lb
Configuring DIR /cpu/p5/Config.lb
===> WARNING: object/driver cpuid previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
cpu/p5/Config.lb:0
===> WARNING: object/driver mtrr previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
cpu/k7/Config.lb:0
cpu/p6/Config.lb:0
===> WARNING: object/driver cpufixup previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
===> WARNING: object/driver apic_timer previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
cpu/k8/Config.lb:0
End PART cpu
End PART mainboard
===> WARNING: Option CONFIG_IDE_STREAM using default value 0
Config.lb:0
===> WARNING: Option AMD8111_DEV using default value 0x3800
Config.lb:0
===> WARNING: Option USE_NORMAL_IMAGE using default value 0
Config.lb:0
End ROMIMAGE
Build ROM size 1048576
Creating hdama/fallback/static.c
Creating hdama/fallback/Makefile.settings
Creating hdama/fallback/crt0_includes.h
Creating hdama/fallback/Makefile
Creating hdama/fallback/ldoptions
Creating hdama/normal/static.c
Creating hdama/normal/Makefile.settings
Creating hdama/normal/crt0_includes.h
Creating hdama/normal/Makefile
Creating hdama/normal/ldoptions
Creating hdama/Makefile.settings
Creating hdama/Makefile

Eric



From ebiederman at lnxi.com  Tue Aug  5 23:28:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Aug  5 23:28:01 2003
Subject: Option ROM for Device.
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA2F0@TYANWEB>
References: <3174569B9743D511922F00A0C943142302FCA2F0@TYANWEB>
Message-ID: <m31xvzjvkv.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Ron,
> 
> How about the support of Option rom execution for on board device?
> Some device vendors only provide option rom instead of datasheet.

There are a couple of sides of this.
1) Anyone who supports Linux on non-x86 generally has a reasonable
   Linux driver that does not need an option rom to set anything up.
   This includes most hardware raid vendors.

2) We have the ADLO code which emulates a classic BIOS interface
   and as it matures it should be usable for most of those kinds
   of issues.  

3) If we are running Linux if we can't get programming information
   from the vendor so there is an open source driver we generally
   don't want to use the hardware.   Which is why ADLO is not
   an especially high priority.

Eric



From ebiederman at lnxi.com  Tue Aug  5 23:31:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Aug  5 23:31:01 2003
Subject: OK, HDAMA is up as a cluster node
In-Reply-To: <Pine.LNX.4.44.0308051359560.11457-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308051359560.11457-100000@maxroach.lanl.gov>
Message-ID: <m3vftbigw9.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> The PIRQ is indeed wrong. So I booted a bproc phase 2 configured with 
> IO-APIC support and all is well, since the _MP_ is correct. 
> 
> Gee, this is nice. 
> 
> I guess what we should do is dynamically generate PIRQ from the _MP_ 
> table?
> 
> That's for later.

If you look at the MP table you will notice how dynamic it already is.

One of the TODO list items for the freebios2 tree is still to dynamically
generate the irq tables from information in the device tree.  

We have just been using the old table as a stop gap measure, until
a native version is ready.

Eric



From ebiederman at lnxi.com  Tue Aug  5 23:34:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Aug  5 23:34:00 2003
Subject: a few changes for HDAMA
In-Reply-To: <Pine.LNX.4.44.0308051731290.11457-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308051731290.11457-100000@maxroach.lanl.gov>
Message-ID: <m3r83zigqd.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> 1. PIRQ table derived from standard bios, but it is still wrong. 

Of course we change all of the device id, on bus 0.
You simply can not cut and paste a binary table any more.

> 2. have a hook in arima/hdama/mainboard.c for CONF_PASS_PRE_BOOT, 
>    but it is a no-op

Once these things merge I have a few more comments.
But the more I see of it, the enumeration value instead of separate
functions looks increasingly like the wrong thing.

> 3. targets/arima/hdama/Config.lb now enables SMP and sets max_cpus to 2

Good. Hopefully I can do some interesting development now and get
the static configuration where it needs to be.

Eric



From rminnich at lanl.gov  Wed Aug  6 00:30:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 00:30:01 2003
Subject: new config version skew problem
In-Reply-To: <m365lbjvsf.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308052245520.16348-100000@maxroach.lanl.gov>

it still looks weird to me, but my python is 2.2.1

I'll try to do some compares tomorrow.

ron



From rminnich at lanl.gov  Wed Aug  6 00:36:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 00:36:01 2003
Subject: a few changes for HDAMA
In-Reply-To: <m3r83zigqd.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308052248260.16348-100000@maxroach.lanl.gov>

On 5 Aug 2003, Eric W. Biederman wrote:

> Once these things merge I have a few more comments.
> But the more I see of it, the enumeration value instead of separate
> functions looks increasingly like the wrong thing.

hmm, not sure we agree from here but we're open to discussion. Greg had an 
interesting point that given the enumeration value, hardwaremain could 
actually be a fairly straightforward state machine, and lots of current 
special cases could go away.

Also, inserting a new enumeration value is still lots easier than 
inserting a new special function all over the place, but as always on this 
project we can evolve by working this out on the list.

ron



From rminnich at lanl.gov  Wed Aug  6 00:50:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 00:50:00 2003
Subject: new config version skew problem
In-Reply-To: <m365lbjvsf.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308052305130.16348-100000@maxroach.lanl.gov>

oh yes, note the top level makefile should concatenate the images in 
fallback and normal to produce the final image, but I am not that far 
along yet.

ron



From stepan at suse.de  Wed Aug  6 03:47:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Aug  6 03:47:01 2003
Subject: Option ROM for Device.
In-Reply-To: <m31xvzjvkv.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142302FCA2F0@TYANWEB> <m31xvzjvkv.fsf@maxwell.lnxi.com>
Message-ID: <20030806080327.GB1340@suse.de>

* Eric W. Biederman <ebiederman at lnxi.com> [030806 05:47]:
> There are a couple of sides of this.
> 1) Anyone who supports Linux on non-x86 generally has a reasonable
>    Linux driver that does not need an option rom to set anything up.
>    This includes most hardware raid vendors.
 
Still, this is not always enough. I cursed many times when the x86
emulation on Alpha machines was not capable of executing the hacks
some vendors put in their option roms, which prevents video or
booting from scsi from working.

> 3) If we are running Linux if we can't get programming information
>    from the vendor so there is an open source driver we generally
>    don't want to use the hardware.   Which is why ADLO is not
>    an especially high priority.
 
This is also a matter of effort. I'd definitely prefer having the
graphics hardware vendors write initialization firmware for their
device than to do that myself for every vendor whose graphics card
I happen to use. In clusters this would not matter. It's all the same
hardware anyways, and no video is needed. But for many other
applications it's really useful.

  Stefan

-- 
Architecture Team
    SuSE Linux AG


From rogerxxmaillist at speakeasy.net  Wed Aug  6 03:57:00 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Wed Aug  6 03:57:00 2003
Subject: new mainboard for freebios 1
In-Reply-To: <Pine.LNX.4.44.0308051553470.11457-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308051553470.11457-100000@maxroach.lanl.gov>
Message-ID: <1060156963.17263.14.camel@localhost3.localdomain>

sweet. looks like my new computer.

On Tue, 2003-08-05 at 14:54, ron minnich wrote:
> the supermicro x5dae, with e7505 and 82801db
> 
> we'd like to have all new ports on freebios2 but we're short for time and 
> decided to do this quick one.
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
-- 

Roger
http://www.eskimo.com/~roger/index.html



From linuxbios at smashed.demon.co.uk  Wed Aug  6 07:34:00 2003
From: linuxbios at smashed.demon.co.uk (linuxbios at smashed.demon.co.uk)
Date: Wed Aug  6 07:34:00 2003
Subject: Bios Saviour
Message-ID: <E19kMnv-000Fo6-0W@anchor-post-32.mail.demon.net>

Hi,

I am hoping someone on the list has an EPIA M-10000 VIA C3 E-Series, could tell me which Bios Saviour kit they are using, if any....

Are there any other alternatives to Bios Saviour, preferably no more expensive than ?25 ish.

Thanks All,

James.



From niki.waibel at newlogic.com  Wed Aug  6 07:43:00 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Wed Aug  6 07:43:00 2003
Subject: tools for programing?
Message-ID: <200308061159.h76BxKH3008583@enterprise2.newlogic.at>

quite new to all this...

just got 2 epia-m's and 2 bios saviors.

what tools do i need to flash the bios?
where do i get them?
(i'd like to flash the chips on the board...)

what do i need to activate in the kernel to
program a chip / use the flash tools?
what do i need to activate in the kernel to
boot?

niki
-- 
niki w. waibel - system administrator @ newlogic technologies ag


From niki.waibel at newlogic.com  Wed Aug  6 07:47:00 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Wed Aug  6 07:47:00 2003
Subject: Bios Saviour
In-Reply-To: <E19kMnv-000Fo6-0W@anchor-post-32.mail.demon.net>
Message-ID: <200308061202.h76C2tH3009095@enterprise2.newlogic.at>

On 06-Aug-2003 linuxbios at smashed.demon.co.uk wrote:
> I am hoping someone on the list has an EPIA M-10000 VIA C3 E-Series,
> could tell me which Bios Saviour kit they are using, if any....

i just got the IOSS RD1-PL.
i put them into the epia-m (600mhz, because no fan)
and the orig bios works fine.

i try to find out now how to flash the bios, etc.

> Are there any other alternatives to Bios Saviour, preferably no more expensive than ?25 ish.

dont know.


From aip at cwlinux.com  Wed Aug  6 07:59:01 2003
From: aip at cwlinux.com (Andrew Ip)
Date: Wed Aug  6 07:59:01 2003
Subject: tools for programing?
In-Reply-To: <200308061159.h76BxKH3008583@enterprise2.newlogic.at>; from Niki Waibel on Wed, Aug 06, 2003 at 01:59:20PM +0200
References: <200308061159.h76BxKH3008583@enterprise2.newlogic.at>
Message-ID: <20030806201452.A24722@mail.cwlinux.com>

Hi Niki,

> quite new to all this...
> just got 2 epia-m's and 2 bios saviors.
> what tools do i need to flash the bios?
> where do i get them?
> (i'd like to flash the chips on the board...)
> what do i need to activate in the kernel to
> program a chip / use the flash tools?
> what do i need to activate in the kernel to
> boot?
I checked in the code couple weeks ago, the current flash_rom 
should work.

-Andrew

-- 
Andrew Ip
Email:  aip at cwlinux.com
Tel:    (852) 2542 2046
Fax:    (852) 2542 2036
Mobile: (852) 9201 9866

Cwlinux Limited
Unit 202B 2/F Lai Cheong Factory Building,
479-479A Castle Peak Road,
Lai Chi Kok, Kowloon,
Hong Kong.

For public pgp key, please obtain it from http://www.keyserver.net/en.


From niki.waibel at newlogic.com  Wed Aug  6 08:07:01 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Wed Aug  6 08:07:01 2003
Subject: tools for programing?
In-Reply-To: <20030806201452.A24722@mail.cwlinux.com>
Message-ID: <200308061223.h76CNaH3011611@enterprise2.newlogic.at>

>> quite new to all this...
>> just got 2 epia-m's and 2 bios saviors.
>> what tools do i need to flash the bios?
>> where do i get them?
>> (i'd like to flash the chips on the board...)
>> what do i need to activate in the kernel to
>> program a chip / use the flash tools?
>> what do i need to activate in the kernel to
>> boot?
> I checked in the code couple weeks ago, the current flash_rom 
> should work.
means that all tools necessary for flashing/programing the
bios are in the cvs of freebios?
:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios

cvs.sourceforge.net seems to be VERY slow from here...

niki


From aip at cwlinux.com  Wed Aug  6 08:41:01 2003
From: aip at cwlinux.com (Andrew Ip)
Date: Wed Aug  6 08:41:01 2003
Subject: tools for programing?
In-Reply-To: <200308061223.h76CNaH3011611@enterprise2.newlogic.at>; from Niki Waibel on Wed, Aug 06, 2003 at 02:23:36PM +0200
References: <20030806201452.A24722@mail.cwlinux.com> <200308061223.h76CNaH3011611@enterprise2.newlogic.at>
Message-ID: <20030806205734.B25215@mail.cwlinux.com>

Hi Niki,

> >> quite new to all this...
> >> just got 2 epia-m's and 2 bios saviors.
> >> what tools do i need to flash the bios?
> >> where do i get them?
> >> (i'd like to flash the chips on the board...)
> >> what do i need to activate in the kernel to
> >> program a chip / use the flash tools?
> >> what do i need to activate in the kernel to
> >> boot?
> > I checked in the code couple weeks ago, the current flash_rom 
> > should work.
> means that all tools necessary for flashing/programing the
> bios are in the cvs of freebios?
> :pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios
> cvs.sourceforge.net seems to be VERY slow from here...
That's right.  SF has a little bit of improvement lately.
At least it is not rejecting connection.  :)

-Andrew

-- 
Andrew Ip
Email:  aip at cwlinux.com
Tel:    (852) 2542 2046
Fax:    (852) 2542 2036
Mobile: (852) 9201 9866

Cwlinux Limited
Unit 202B 2/F Lai Cheong Factory Building,
479-479A Castle Peak Road,
Lai Chi Kok, Kowloon,
Hong Kong.

For public pgp key, please obtain it from http://www.keyserver.net/en.


From linuxbios at smashed.demon.co.uk  Wed Aug  6 09:32:00 2003
From: linuxbios at smashed.demon.co.uk (linuxbios at smashed.demon.co.uk)
Date: Wed Aug  6 09:32:00 2003
Subject: Datasheets for EPIA-M10000
Message-ID: <E19kOdz-000Di3-0V@anchor-post-31.mail.demon.net>

Hi,

Can anyone help with info on VIA CLE266, VT8235, VT6103, VT1616, VT1662, VT6307S, anything would be appreciated .... or have people just used the linux kernel source for their information???

It appears for anyones interest that the EPIA-M10000 with C3 processor has the SST39SF020A flash chip ( revision 70-4C-NH ), which is the PLCC type, which requires Bios Saviour RD1-PL.

James.



From rminnich at lanl.gov  Wed Aug  6 10:22:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 10:22:00 2003
Subject: Option ROM for Device.
In-Reply-To: <20030806080327.GB1340@suse.de>
Message-ID: <Pine.LNX.4.44.0308060836540.20543-100000@maxroach.lanl.gov>

On Wed, 6 Aug 2003, Stefan Reinauer wrote:

> * Eric W. Biederman <ebiederman at lnxi.com> [030806 05:47]:
> > There are a couple of sides of this.
> > 1) Anyone who supports Linux on non-x86 generally has a reasonable
> >    Linux driver that does not need an option rom to set anything up.
> >    This includes most hardware raid vendors.
>  
> Still, this is not always enough. I cursed many times when the x86
> emulation on Alpha machines was not capable of executing the hacks
> some vendors put in their option roms, which prevents video or
> booting from scsi from working.

yes, although I have always hoped it would be enough to count on
open-source linux drivers, we still need expansion rom support today.
There's a cluster at Argonne that needs an old-fashioned BIOS on the nodes
that have a certain model RAID-SCSI controller. They want linuxbios, and
we need to do expansion roms first.

ron




From rminnich at lanl.gov  Wed Aug  6 10:25:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 10:25:00 2003
Subject: tools for programing?
In-Reply-To: <200308061223.h76CNaH3011611@enterprise2.newlogic.at>
Message-ID: <Pine.LNX.4.44.0308060840430.20543-100000@maxroach.lanl.gov>

On Wed, 6 Aug 2003, Niki Waibel wrote:

> means that all tools necessary for flashing/programing the
> bios are in the cvs of freebios?

utils/flash_and_burn/flash_rom

ron



From rminnich at lanl.gov  Wed Aug  6 10:28:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 10:28:01 2003
Subject: Datasheets for EPIA-M10000
In-Reply-To: <E19kOdz-000Di3-0V@anchor-post-31.mail.demon.net>
Message-ID: <Pine.LNX.4.44.0308060844040.20543-100000@maxroach.lanl.gov>

On Wed, 6 Aug 2003 linuxbios at smashed.demon.co.uk wrote:

> It appears for anyones interest that the EPIA-M10000 with C3 processor
> has the SST39SF020A flash chip ( revision 70-4C-NH ), which is the PLCC
> type, which requires Bios Saviour RD1-PL.

you don't "have" to have the saviour. 

You can boot the normal flash, pop it out, put in your new part, and flash 
it.

ron



From rminnich at lanl.gov  Wed Aug  6 11:00:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 11:00:01 2003
Subject: new config tool fix
Message-ID: <Pine.LNX.4.44.0308060915020.20543-100000@maxroach.lanl.gov>

Eric, I have eliminated the unnecessary reading of Config.lb files that 
you saw in your note. 

It now looks like this:

bash-2.05b$ python ~/src/bios/freebios2/util/newconfig/config.py  
Config.lb ~/src/bios/freebios2
Configuring TARGET hdama
Will place Makefile, crt0.S, etc. in hdama
Configuring ROMIMAGE fallback
Configuring DIR /config/Config.lb
Configuring DIR /lib/Config.lb
Configuring DIR /console/Config.lb
Configuring DIR /stream/Config.lb
Configuring DIR /devices/Config.lb
Configuring DIR /pc80/Config.lb
Configuring DIR /boot/Config.lb
Configuring PART mainboard, path arima/hdama
Configuring PART arch, path i386
Adding init file: config/crt0.base
Configuring DIR lib/Config.lb
Configuring DIR boot/Config.lb
Configuring DIR smp/Config.lb
End PART arch
Configuring PART northbridge, path amd/amdk8
End PART northbridge
Configuring PART southbridge, path amd/amd8111
End PART southbridge
Configuring PART southbridge, path amd/amd8131
End PART southbridge
Configuring PART superio, path NSC/pc87360
End PART superio
Configuring DIR /pc80/Config.lb
===> WARNING: object/driver mc146818rtc previously defined
Config.lb:0
mainboard/arima/hdama/Config.lb:0
pc80/Config.lb:0
Configuring PART cpu, path k8
Configuring DIR /cpu/k8/Config.lb
Configuring DIR /cpu/k7/Config.lb
Configuring DIR /cpu/p6/Config.lb
Configuring DIR /cpu/p5/Config.lb
End PART cpu
Configuring PART cpu, path k8
End PART cpu
End PART mainboard
===> WARNING: Option USE_NORMAL_IMAGE using default value 0
Config.lb:0
===> WARNING: Option CONFIG_IDE_STREAM using default value 0
Config.lb:0
===> WARNING: Option AMD8111_DEV using default value 0x3800
Config.lb:0
End ROMIMAGE
Build ROM size 1048576
Creating hdama/fallback/static.c
Creating hdama/fallback/Makefile.settings
Creating hdama/fallback/crt0_includes.h
Creating hdama/fallback/Makefile
Creating hdama/fallback/ldoptions
Creating hdama/Makefile.settings
Creating hdama/Makefile




From rminnich at lanl.gov  Wed Aug  6 11:03:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 11:03:01 2003
Subject: reducing debugging messages from arima/hdama/auto.c
Message-ID: <Pine.LNX.4.44.0308060918190.20543-100000@maxroach.lanl.gov>

I hope nobody minds, but since I'm the one who wired these as high, I 
don't think they will. I want to reduce the debug spew from auto.c to get 
some timings. I plan to remove my overrides in auto.c so that it goes back 
to using the level set in Config.lb for debug messages.

thanks

ron 




From linuxbios at smashed.demon.co.uk  Wed Aug  6 13:44:01 2003
From: linuxbios at smashed.demon.co.uk (James Weir)
Date: Wed Aug  6 13:44:01 2003
Subject: UK supplier of Bios Saviour or SST39SF020A 70-4C-NH Flash Part
Message-ID: <000201c35c44$7afdf0e0$0b00000a@quadra001>

Does anyone now of suppliers for either of the above ( see subject ) ?

 

Thanks, James

 

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

From ebiederman at lnxi.com  Wed Aug  6 13:52:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Aug  6 13:52:00 2003
Subject: Option ROM for Device.
In-Reply-To: <Pine.LNX.4.44.0308060836540.20543-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308060836540.20543-100000@maxroach.lanl.gov>
Message-ID: <m3r83ymzbb.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Wed, 6 Aug 2003, Stefan Reinauer wrote:
> 
> > * Eric W. Biederman <ebiederman at lnxi.com> [030806 05:47]:
> > > There are a couple of sides of this.
> > > 1) Anyone who supports Linux on non-x86 generally has a reasonable
> > >    Linux driver that does not need an option rom to set anything up.
> > >    This includes most hardware raid vendors.
> >  
> > Still, this is not always enough. I cursed many times when the x86
> > emulation on Alpha machines was not capable of executing the hacks
> > some vendors put in their option roms, which prevents video or
> > booting from scsi from working.
> 
> yes, although I have always hoped it would be enough to count on
> open-source linux drivers, we still need expansion rom support today.
> There's a cluster at Argonne that needs an old-fashioned BIOS on the nodes
> that have a certain model RAID-SCSI controller. They want linuxbios, and
> we need to do expansion roms first.

Which model RAID-SCSI controller?  I have seen an amazing number that
have worked.  I am wondering if it is simply a misreport.

Eric



From YhLu at tyan.com  Wed Aug  6 13:59:00 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Aug  6 13:59:00 2003
Subject: Option ROM for Device.
Message-ID: <3174569B9743D511922F00A0C943142302FCA3EF@TYANWEB>

If it is only addon card, it should work already. 

Some cases need option rom support are on-board one.  For example need to
option rom to download FW to the controller and start up the controller.

So LinuxBIOS should have some code do the job or have some code to excute
option rom that will residue in EEPROM.

The first way is more better than second way, and is more fast. But if there
is no info or datasheet, it is hard to do that.

Regards

Yinghai Lu

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2003?8?6? 11:11
???: ron minnich
??: Stefan Reinauer; YhLu; linuxbios at clustermatic.org
??: Re: Option ROM for Device.

ron minnich <rminnich at lanl.gov> writes:

> On Wed, 6 Aug 2003, Stefan Reinauer wrote:
> 
> > * Eric W. Biederman <ebiederman at lnxi.com> [030806 05:47]:
> > > There are a couple of sides of this.
> > > 1) Anyone who supports Linux on non-x86 generally has a reasonable
> > >    Linux driver that does not need an option rom to set anything up.
> > >    This includes most hardware raid vendors.
> >  
> > Still, this is not always enough. I cursed many times when the x86
> > emulation on Alpha machines was not capable of executing the hacks
> > some vendors put in their option roms, which prevents video or
> > booting from scsi from working.
> 
> yes, although I have always hoped it would be enough to count on
> open-source linux drivers, we still need expansion rom support today.
> There's a cluster at Argonne that needs an old-fashioned BIOS on the nodes
> that have a certain model RAID-SCSI controller. They want linuxbios, and
> we need to do expansion roms first.

Which model RAID-SCSI controller?  I have seen an amazing number that
have worked.  I am wondering if it is simply a misreport.

Eric


From YhLu at tyan.com  Wed Aug  6 14:05:01 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Aug  6 14:05:01 2003
Subject: S2880
Message-ID: <3174569B9743D511922F00A0C943142302FCA3F4@TYANWEB>

Eric,

It seems the image that built with can not switch to Normal booting.

1. In Fallback mode, after power on I can use cmos_util.
2. after rebooting it is still in Fallback mode,and can not cmos_util, it
said can not find option table in the ram. And can not access cmos.layout.

When I using old tool, I can switch to normal mode, but need to change
boot_option and last_boot from fallback to normal.

regards

Yinghai Lu



From YhLu at tyan.com  Wed Aug  6 14:12:00 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Aug  6 14:12:00 2003
Subject: new config version skew problem
Message-ID: <3174569B9743D511922F00A0C943142302FCA3FD@TYANWEB>

Only need one cat command to do that.

I use ns2880 to produce one
cat ../../fwx.rom ./normal/linuxbios.rom ./fallback/linuxbios.rom >
s2880_linuxbios.rom

regards

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?5? 22:06
???: Eric W. Biederman
??: Greg Watson; linuxbios at clustermatic.org
??: Re: new config version skew problem

oh yes, note the top level makefile should concatenate the images in 
fallback and normal to produce the final image, but I am not that far 
along yet.

ron

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Wed Aug  6 14:34:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 14:34:01 2003
Subject: Option ROM for Device.
In-Reply-To: <m3r83ymzbb.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308061249340.20543-100000@maxroach.lanl.gov>

On 6 Aug 2003, Eric W. Biederman wrote:

> Which model RAID-SCSI controller?  I have seen an amazing number that
> have worked.  I am wondering if it is simply a misreport.

not sure, talk to the folks at Argonne, it's a LNXI cluster.

ron



From YhLu at tyan.com  Wed Aug  6 17:56:00 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Aug  6 17:56:00 2003
Subject: S2880
Message-ID: <3174569B9743D511922F00A0C943142302FCA433@TYANWEB>

Ron,

After swap _ROMBASE etc to after ROM_SECTION_SIZE and ROM_SECTION_OFFSET.  I
can switch to the normal mode.

But in fallback mode and normal mode ( after reboot) still got problem.

~ # cmos_util -d
# The CMOS Definition table was not found in ram
# CMOS definition table was not found in RAM memory
# Looking for definitions in cmos.layout file
Can not open config file cmos.layout


Regards

Yinghai Lu

-----????-----
???: YhLu 
????: 2003?8?6? 11:18
???: 'ebiederman at lnxi.com'; ron minnich
??: Stefan Reinauer; linuxbios at clustermatic.org
??: S2880


Eric,

It seems the image that built with can not switch to Normal booting.

1. In Fallback mode, after power on I can use cmos_util.
2. after rebooting it is still in Fallback mode,and can not cmos_util, it
said can not find option table in the ram. And can not access cmos.layout.

When I using old tool, I can switch to normal mode, but need to change
boot_option and last_boot from fallback to normal.

regards

Yinghai Lu



From YhLu at tyan.com  Wed Aug  6 18:07:00 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Aug  6 18:07:00 2003
Subject: S2880
Message-ID: <3174569B9743D511922F00A0C943142302FCA434@TYANWEB>

Ron,

It seems I can not enable XIP_ROM_SIZE and XIP_ROM_BASE. Even I have set
them in Options.lb

Regards

Yinghai Lu

-----????-----
???: YhLu 
????: 2003?8?6? 15:17
???: YhLu; ebiederman at lnxi.com; ron minnich
??: Stefan Reinauer; linuxbios at clustermatic.org
??: Re: S2880

Ron,

After swap _ROMBASE etc to after ROM_SECTION_SIZE and ROM_SECTION_OFFSET.  I
can switch to the normal mode.

But in fallback mode and normal mode ( after reboot) still got problem.

~ # cmos_util -d
# The CMOS Definition table was not found in ram
# CMOS definition table was not found in RAM memory
# Looking for definitions in cmos.layout file
Can not open config file cmos.layout


Regards

Yinghai Lu

-----????-----
???: YhLu 
????: 2003?8?6? 11:18
???: 'ebiederman at lnxi.com'; ron minnich
??: Stefan Reinauer; linuxbios at clustermatic.org
??: S2880


Eric,

It seems the image that built with can not switch to Normal booting.

1. In Fallback mode, after power on I can use cmos_util.
2. after rebooting it is still in Fallback mode,and can not cmos_util, it
said can not find option table in the ram. And can not access cmos.layout.

When I using old tool, I can switch to normal mode, but need to change
boot_option and last_boot from fallback to normal.

regards

Yinghai Lu



From rminnich at lanl.gov  Wed Aug  6 18:35:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 18:35:00 2003
Subject: S2880
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA434@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308061650560.20543-100000@maxroach.lanl.gov>

I will try to email you my latest tree, Stefan put them in last night.

ron



From YhLu at tyan.com  Wed Aug  6 19:49:00 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Aug  6 19:49:00 2003
Subject: =?GB2312?B?tPC4tDogUzI4ODA=?=
Message-ID: <3174569B9743D511922F00A0C943142302FCA452@TYANWEB>

Ron,

I have verfied that if I disable the XIP... in old config tool, the image
produced will make the option table not accessiable after reboot too.

Regards

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?6? 15:51
???: YhLu
??: 'ebiederman at lnxi.com'; 'Stefan Reinauer'; 'linuxbios at clustermatic.org'
??: Re: S2880

I will try to email you my latest tree, Stefan put them in last night.

ron


From YhLu at tyan.com  Wed Aug  6 21:08:01 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Aug  6 21:08:01 2003
Subject: S2880
Message-ID: <3174569B9743D511922F00A0C943142302FCA468@TYANWEB>

Eric,
Under 4G RAM  linusbios_tables occupy 0x500-0xae0, cmos_util can find
option_table even after rebooting.
Under 6G RAM linuxbios_tables occupy 0x500-0xaf4, cmos_util can find
option_table after power on but can not find it after rebooting.

The only difference should be that rebooting don't execute auto.c again.

Any advise.

Regards

Yingahi Lu


-----????-----
???: YhLu 
????: 2003?8?6? 17:11
???: ron minnich
??: 'ebiederman at lnxi.com'; 'Stefan Reinauer'; 'linuxbios at clustermatic.org'
??: ??: S2880

Ron,

I have verfied that if I disable the XIP... in old config tool, the image
produced will make the option table not accessiable after reboot too.

Regards

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?6? 15:51
???: YhLu
??: 'ebiederman at lnxi.com'; 'Stefan Reinauer'; 'linuxbios at clustermatic.org'
??: Re: S2880

I will try to email you my latest tree, Stefan put them in last night.

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From agnew at cs.umd.edu  Wed Aug  6 22:29:00 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Wed Aug  6 22:29:00 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA468@TYANWEB>
Message-ID: <20030806223432.R5878-100000@www.missl.cs.umd.edu>

I was looking at the 2.6.0-test2 kernel tree today and saw new menu
choices under

"General Setup -> Remove Kernel Features (for embedded systems)" which
looks like the beginings of an effort to strip out large though somewhat
optional features. For instance, the current choices include:

Load all symbols for kernel debugging/ksysmoops
Enable futex support
Enable eventpoll support
Anticipatory I/O Schedualer
Deadline I/O Schedualer

It seems like pretty good news for the linux kernel as a bootloader route
that effots are being made to get the kernel smaller when necessary.

- Adam Agnew



From rminnich at lanl.gov  Wed Aug  6 23:14:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 23:14:01 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <20030806223432.R5878-100000@www.missl.cs.umd.edu>
Message-ID: <Pine.LNX.4.44.0308062130030.3905-100000@maxroach.lanl.gov>

On Wed, 6 Aug 2003, Adam Agnew wrote:

> It seems like pretty good news for the linux kernel as a bootloader route
> that effots are being made to get the kernel smaller when necessary.

good, because long term, that is still a preferred choice for me.

ron



From YhLu at tyan.com  Wed Aug  6 23:29:00 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Aug  6 23:29:00 2003
Subject: S2880
Message-ID: <3174569B9743D511922F00A0C943142302FCA482@TYANWEB>

It seems the Kernel clear 0x0--4k.
Of course after itself take the MP TABLE.

Maybe need to update the kernel.

YH
-----????-----
???: YhLu 
????: 2003?8?6? 18:30
???: ron minnich
??: 'ebiederman at lnxi.com'; 'Stefan Reinauer'; 'linuxbios at clustermatic.org'
??: re: S2880

Eric,
Under 4G RAM  linusbios_tables occupy 0x500-0xae0, cmos_util can find
option_table even after rebooting.
Under 6G RAM linuxbios_tables occupy 0x500-0xaf4, cmos_util can find
option_table after power on but can not find it after rebooting.

The only difference should be that rebooting don't execute auto.c again.

Any advise.

Regards

Yingahi Lu


-----????-----
???: YhLu 
????: 2003?8?6? 17:11
???: ron minnich
??: 'ebiederman at lnxi.com'; 'Stefan Reinauer'; 'linuxbios at clustermatic.org'
??: ??: S2880

Ron,

I have verfied that if I disable the XIP... in old config tool, the image
produced will make the option table not accessiable after reboot too.

Regards

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?6? 15:51
???: YhLu
??: 'ebiederman at lnxi.com'; 'Stefan Reinauer'; 'linuxbios at clustermatic.org'
??: Re: S2880

I will try to email you my latest tree, Stefan put them in last night.

ron
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Wed Aug  6 23:33:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 23:33:00 2003
Subject: S2880
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA482@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308062148300.4075-100000@maxroach.lanl.gov>

On Wed, 6 Aug 2003, YhLu wrote:

> It seems the Kernel clear 0x0--4k.
> Of course after itself take the MP TABLE.

yuck. I always thought it left that page alone, since it's page zero 
anyway. 

Well, that explains a thing or two.

ron



From rminnich at lanl.gov  Wed Aug  6 23:34:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug  6 23:34:01 2003
Subject: S2880
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA482@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308062149170.4075-100000@maxroach.lanl.gov>

I really need a working PIRQ (don't ask) so I'm going to take a stab at 
generating one from the linuxbios tables, unless somebody else has 
done/wants to do it.

ron



From YhLu at tyan.com  Wed Aug  6 23:38:00 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Aug  6 23:38:00 2003
Subject: S2880
Message-ID: <3174569B9743D511922F00A0C943142302FCA483@TYANWEB>

So you will add one module that will produce PIRQ automatically?

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?6? 20:50
???: YhLu
??: 'ebiederman at lnxi.com'; 'Stefan Reinauer'; 'linuxbios at clustermatic.org'
??: Re: S2880

I really need a working PIRQ (don't ask) so I'm going to take a stab at 
generating one from the linuxbios tables, unless somebody else has 
done/wants to do it.

ron


From joshua at joshuawise.com  Wed Aug  6 23:40:00 2003
From: joshua at joshuawise.com (Joshua Wise)
Date: Wed Aug  6 23:40:00 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <20030806223432.R5878-100000@www.missl.cs.umd.edu>
References: <20030806223432.R5878-100000@www.missl.cs.umd.edu>
Message-ID: <200308062356.43057.joshua@joshuawise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I was looking at the 2.6.0-test2 kernel tree today and saw new menu
> choices under
>
> "General Setup -> Remove Kernel Features (for embedded systems)" which
> looks like the beginings of an effort to strip out large though somewhat
> optional features. For instance, the current choices include:

Ooh, I wish that existed in the 2.4.x tree... I am working on a 'linux as 
bootldr' project for ARM (iPAQ specifically). Presently, our zImages are at 
480k, and we need to get them down to sub-256k (while still adding more 
features!) Out of curiousity, how small have you guys managed to build 
zImages for LinuxBIOS?

~joshua


- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
Quote       | <lilo> I akilled *@* by mistake
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Mc35Pn9tWOqA4LMRAi+CAJ0TVjmLD3wn8nkshyJajUZmwL04RACdE+2d
Hf84kNche1h0zJDM8WopiaU=
=YxUn
-----END PGP SIGNATURE-----



From YhLu at tyan.com  Wed Aug  6 23:43:01 2003
From: YhLu at tyan.com (YhLu)
Date: Wed Aug  6 23:43:01 2003
Subject: S2880
Message-ID: <3174569B9743D511922F00A0C943142302FCA484@TYANWEB>

In the cmos_util if it can not find linuxbios table from (0--4k) , it will
find that from (960k to 1M).

Please suggest where we should preserve second copy of linuxbios table.

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?6? 20:49
???: YhLu
??: 'ebiederman at lnxi.com'; 'Stefan Reinauer'; 'linuxbios at clustermatic.org'
??: Re: S2880

On Wed, 6 Aug 2003, YhLu wrote:

> It seems the Kernel clear 0x0--4k.
> Of course after itself take the MP TABLE.

yuck. I always thought it left that page alone, since it's page zero 
anyway. 

Well, that explains a thing or two.

ron


From steve at nexpath.com  Thu Aug  7 00:08:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Thu Aug  7 00:08:01 2003
Subject: S2880
In-Reply-To: <Pine.LNX.4.44.0308062149170.4075-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308062149170.4075-100000@maxroach.lanl.gov>
Message-ID: <3F31D49F.5040701@nexpath.com>

ron minnich wrote:

> I really need a working PIRQ (don't ask) so I'm going to take a stab at 
> generating one from the linuxbios tables, unless somebody else has 
> done/wants to do it.
> 

I don't know if it is helpful to what you need or not, but there is code 
in the stpc section that builds a PIRQ table: 
(freebios/src/mainboard/stpc/consumer2/mainboard.c).  This uses the 0x0f 
router code which is a way around linux if it does not know about the 
router in your north/south bridge.  There are comments in the code.

-Steve



From ijpraveen1 at yahoo.com  Thu Aug  7 00:15:00 2003
From: ijpraveen1 at yahoo.com (John Praveen)
Date: Thu Aug  7 00:15:00 2003
Subject: Preliminary doubts!
Message-ID: <20030807043143.5713.qmail@web41707.mail.yahoo.com>

Hi,
                 I have the custom board (geode sc1200) with peripherals like ethernet, PCI audio video decoder, Tuner, hard disk, SDRAM, Flash memory. I will have to have my BIOS program, linux kernel and specific application program in my Flash memory. I have hard disk only for storing files.
 
                  My Flash memory is of 32 Mbits and SDRAM 32MBytes. 
 
                  I want to use LinuxBios. I build it for nano mainboard. But still I have many doubts. In normal BIOS, we will say the bios program to load the bootloader from hard disk into location 0000:7C00. 
 
                 What part of the program in Linuxbios will bring my linux kernel image from Flash into SDRAM?
 
                 Is any options or something to be included in the configuration file to say to boot from Flash memory.
 
                 In my embedded device the Flash memory is mapped to physical address 00000h to 3FFFFFh. So at what location should i place the linuxbios romimage and linux kernel image in my Flash memory? 
        
                Where shall my application program be placed in Flash? I hope I should have a filesystem. Is the MTD meant for the filesystem?
 
               What part of the program in Linuxbios will bring my linux kernel image from Flash into SDRAM?
 
Thanks in advance.
 
Regards,
John.
      


---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20030807/a6b2c8b7/attachment.html>

From rminnich at lanl.gov  Thu Aug  7 00:24:00 2003
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Aug  7 00:24:00 2003
Subject: S2880
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA483@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308062239540.23531-100000@pink.lanl.gov>

On Wed, 6 Aug 2003, YhLu wrote:

> So you will add one module that will produce PIRQ automatically?

I don't see any choice. Bus mapping is dynamic and hence a static table 
is not going to work. We have needed this for some time now anyway.

ron



From rminnich at lanl.gov  Thu Aug  7 00:25:01 2003
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Aug  7 00:25:01 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <200308062356.43057.joshua@joshuawise.com>
Message-ID: <Pine.LNX.4.44.0308062240460.23531-100000@pink.lanl.gov>

On Wed, 6 Aug 2003, Joshua Wise wrote:

> Ooh, I wish that existed in the 2.4.x tree... I am working on a 'linux as 
> bootldr' project for ARM (iPAQ specifically). Presently, our zImages are at 
> 480k, and we need to get them down to sub-256k (while still adding more 
> features!) Out of curiousity, how small have you guys managed to build 
> zImages for LinuxBIOS?
> 

up until about 2.4.13, putting a kernel, small initrd, and linuxbios in 
512KB was not that hard. Then it just balloned.

ron



From rminnich at lanl.gov  Thu Aug  7 00:29:01 2003
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Thu Aug  7 00:29:01 2003
Subject: S2880
In-Reply-To: <3F31D49F.5040701@nexpath.com>
Message-ID: <Pine.LNX.4.44.0308062244300.23531-100000@pink.lanl.gov>

On Wed, 6 Aug 2003, Steve Gehlbach wrote:

> I don't know if it is helpful to what you need or not, but there is code
> in the stpc section that builds a PIRQ table:  
> (freebios/src/mainboard/stpc/consumer2/mainboard.c).  This uses the 0x0f
> router code which is a way around linux if it does not know about the
> router in your north/south bridge.  There are comments in the code.

That's what I love about this list. Everytime I ask a question it gets
answered in a work-saving way. Steve, I'll take a look at your stuff, and
thanks.

I am much relieved ...

ron



From joshua at joshuawise.com  Thu Aug  7 00:31:01 2003
From: joshua at joshuawise.com (Joshua Wise)
Date: Thu Aug  7 00:31:01 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <Pine.LNX.4.44.0308062240460.23531-100000@pink.lanl.gov>
References: <Pine.LNX.4.44.0308062240460.23531-100000@pink.lanl.gov>
Message-ID: <200308070047.04863.joshua@joshuawise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> up until about 2.4.13, putting a kernel, small initrd, and linuxbios in
> 512KB was not that hard. Then it just balloned.

Ouch. Was there specific bloat that happened after 2.4.13? After doing a 
preliminary look over the kernel code, much of the bloat seems to be in the 
filesystem code...

BTW, if you guys don't have serial console stuff yet (IIRC last I checked, 
there was no CLI for linuxbios - things may have changed since then, I've 
been rather out of the loop recently), we're working on extensible CLI stuff 
for ARM Linux As Bootloader that would probably be portable to LinuxBIOS.

/me wishes that the flash block that we put the bootloader in was bigger :(

~jw, who is very sleepy after having spent the previous night hacking till 
0330, and hence probably won't respond to any more email tonight.


- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
Quote       | <lilo> I akilled *@* by mistake
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/MdnHPn9tWOqA4LMRAhqRAJ9GTRKVP4/5GmQUs6+tXvlN7DSYYQCfXKdL
LKSyDAnuWdDWPpMu3EWypoU=
=zA1m
-----END PGP SIGNATURE-----



From ijpraveen1 at yahoo.com  Thu Aug  7 00:37:01 2003
From: ijpraveen1 at yahoo.com (John Praveen)
Date: Thu Aug  7 00:37:01 2003
Subject: Preliminary doubts
Message-ID: <20030807045330.33524.qmail@web41712.mail.yahoo.com>

 
              Sorry. I donot know whats the problem. I can get mails properly sent through this id.
Hi,
                 I have the custom board (geode sc1200) with peripherals like ethernet, PCI audio video decoder, Tuner, hard disk, SDRAM, Flash memory. I will have to have my BIOS program, linux kernel and specific application program in my Flash memory. I have hard disk only for storing files.
 
                  My Flash memory is of 32 Mbits and SDRAM 32MBytes. 
 
                  I want to use LinuxBios. I build it for nano mainboard. But still I have many doubts. In normal BIOS, we will say the bios program to load the bootloader from hard disk into location 0000:7C00. 
 
                 What part of the program in Linuxbios will bring my linux kernel image from Flash into SDRAM?
 
                 Is any options or something to be included in the configuration file to say to boot from Flash memory.
 
                 In my embedded device the Flash memory is mapped to physical address 00000h to 3FFFFFh. So at what location should i place the linuxbios romimage and linux kernel image in my Flash memory? 
        
                Where shall my application program be placed in Flash? I hope I should have a filesystem. Is the MTD meant for the filesystem?
 
               What part of the program in Linuxbios will bring my linux kernel image from Flash into SDRAM?
 
Thanks in advance.
 
Regards,
John.
      



---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20030807/179138f9/attachment.html>

From rminnich at lanl.gov  Thu Aug  7 00:39:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug  7 00:39:01 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <200308070047.04863.joshua@joshuawise.com>
Message-ID: <Pine.LNX.4.44.0308062253140.4485-100000@maxroach.lanl.gov>

On Thu, 7 Aug 2003, Joshua Wise wrote:

> Ouch. Was there specific bloat that happened after 2.4.13? After doing a 
> preliminary look over the kernel code, much of the bloat seems to be in the 
> filesystem code...

the dentry cache was not a cheap date. But the bloat seems to happen 
everywhere, which is why it's so hard to slice out. 

> BTW, if you guys don't have serial console stuff yet (IIRC last I checked, 
> there was no CLI for linuxbios - things may have changed since then, I've 
> been rather out of the loop recently), we're working on extensible CLI stuff 
> for ARM Linux As Bootloader that would probably be portable to LinuxBIOS.

I'm interested. I assume this CLI is running as part of linux? Or is it 
the pre-linux stuff?

This looks like a good area for cooperation. 

thanks

ron



From joshua at joshuawise.com  Thu Aug  7 00:42:00 2003
From: joshua at joshuawise.com (Joshua Wise)
Date: Thu Aug  7 00:42:00 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <Pine.LNX.4.44.0308062253140.4485-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308062253140.4485-100000@maxroach.lanl.gov>
Message-ID: <200308070057.56761.joshua@joshuawise.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I'm interested. I assume this CLI is running as part of linux? Or is it
> the pre-linux stuff?

Presently, the CLI is running as part of the kernel - not as a seperate 
userland application (the reasoning being that we can use the kernel's driver 
architecture - I have created a drivers/bootldr subdirectory for things like 
that. for more, check out handhelds.org CVS - kernel 2.4, not 25 or 26.) more 
info tomorrow - until then, sleep! :)

> This looks like a good area for cooperation.
yep, look forward to hearing from you!

> thanks
>
> ron
~j

- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
Quote       | <lilo> I akilled *@* by mistake
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/MdxTPn9tWOqA4LMRAlDbAKCk73voq6zyaSLG/ykohE6vy9lGvgCeOuoh
jVuhfjDOyf44AAoAfOONolY=
=Dev9
-----END PGP SIGNATURE-----



From rminnich at lanl.gov  Thu Aug  7 00:55:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug  7 00:55:01 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <200308070057.56761.joshua@joshuawise.com>
Message-ID: <Pine.LNX.4.44.0308062310380.4485-100000@maxroach.lanl.gov>

On Thu, 7 Aug 2003, Joshua Wise wrote:

> Presently, the CLI is running as part of the kernel - not as a seperate 
> userland application (the reasoning being that we can use the kernel's driver 
> architecture - I have created a drivers/bootldr subdirectory for things like 
> that. for more, check out handhelds.org CVS - kernel 2.4, not 25 or 26.) more 
> info tomorrow - until then, sleep! :)

OK, I am very interested in this. I'll take a look.

ron




From jeff at planetfall.com  Thu Aug  7 01:00:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Thu Aug  7 01:00:00 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <200308070047.04863.joshua@joshuawise.com>
References: <Pine.LNX.4.44.0308062240460.23531-100000@pink.lanl.gov> <200308070047.04863.joshua@joshuawise.com>
Message-ID: <20030807051619.GA19983@planetfall.com>

I just built 2.6.0-test2 in 441kB with one IDE DMA driver and ext3.
I have yet to try LinuxBIOS (waiting for some BIOS Saviors!), but it
looks like I will be able to do quite a lot with my Tyan Tiger MPX
(S2466N-4M) if I upgrade the BIOS chip to an 8mbit part.

Doing anything useful with the 4mbit chip may still be a lost cause,
but it does look like 2.6.0 has lost some bloat.  Perhaps if some
of us contribute more "embedded fat-trimming" patches we can make
linuxbios+linux+initrd fit easily in a half megabyte.

Jeff


From mwilkinson at ndirect.co.uk  Thu Aug  7 02:27:01 2003
From: mwilkinson at ndirect.co.uk (Mark Wilkinson)
Date: Thu Aug  7 02:27:01 2003
Subject: UK supplier of Bios Saviour or SST39SF020A 70-4C-NH Flash Part
In-Reply-To: <000201c35c44$7afdf0e0$0b00000a@quadra001>
References: <000201c35c44$7afdf0e0$0b00000a@quadra001>
Message-ID: <200308070743.00717.mwilkinson@ndirect.co.uk>

Hi James,
	You can get a BIOS Saviour from a company called SCAN in the UK 
(www.scan.co.uk)

It's hidden away on the overclocking products page. 

Regards
Mark.

On Wednesday 06 Aug 2003 18:59, James Weir wrote:
> Does anyone now of suppliers for either of the above ( see subject ) ?
>
>
>
> Thanks, James



From niki.waibel at newlogic.com  Thu Aug  7 06:09:00 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Thu Aug  7 06:09:00 2003
Subject: DoC 2000 in Europe/Austria
Message-ID: <200308071025.h77AP4H3013930@enterprise2.newlogic.at>

does anyone know where i can order online a DoC 2000
in Austria or Europe?
-- 
niki w. waibel - system administrator @ newlogic technologies ag


From bgr at gw.linespeed.net  Thu Aug  7 06:10:01 2003
From: bgr at gw.linespeed.net (Brian G. Rhodes)
Date: Thu Aug  7 06:10:01 2003
Subject: gx1
Message-ID: <Pine.LNX.4.53.0308070520490.24493@gw.linespeed.net>

There was some talk about the geode GX1 line here, so I thought people
might be interested in the fact that AMD has purchased national's GX1
line, so hopefully in the near future there will be some hardware fixes
for the current problems programmers have to deal with.

Brian G Rhodes
bgr at linespeed.net
brhodes at visualcircuits.com
+1 612-741-1191



From niki.waibel at newlogic.com  Thu Aug  7 08:25:00 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Thu Aug  7 08:25:00 2003
Subject: DoC 2000 vs DoC Millennium
Message-ID: <200308071241.h77CfAH3000653@enterprise2.newlogic.at>

what are actually the differences between DoC 2000 and DoC Millennium?
are both versions working in linux?
which one is the newer product?
are they electrically (pins, voltage, etc) different?
are there any limitation in the size of these chips?
i mean -- could a 2GB chip be used on linux?
niki


From stepan at suse.de  Thu Aug  7 10:03:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Aug  7 10:03:01 2003
Subject: quartet boot
Message-ID: <20030807141946.GA13690@suse.de>

Hi,

I'm having bad luck with the AMD Quartet machines currently.
Due to the 4 memory controllers I had to take out quite some
debug messages from auto.c to get it compile, but I don't really
get to that point anyways..

all I get is the following:

  LinuxBIOS-1.1.0Fallback Do Aug 7 16:05:24 CEST 2003 starting...
  setting up resource map....
  done.
  Enabling routing table for node 00000000 done.
  Enabling SMP settings
  setup_remote_node
  setup_remote_done
  Renaming current temp node to 00000001 done.
  Enabling routing table for node 00000001 done.
[long delay here]
  Renaming current temp node to 00000002 [long delay here] done.
  Enabling routing table for node 00000002
[long delay here, then reset:]

  LinuxBIOS-1.1.0Fallback Do Aug 7 16:05:24 CEST 2003 starting...
  setting up resource map....
  done.
  Enabling routing table for node 00000000 done.
  Enabling SMP settings
[complete hang]

this worked some time ago in CVS, but I don't know when it stopped.

Can the resource map cause these problems? I dumped the resource map
I am using from a different quartet machine, and now I get the same
problems than I had before with the default resource map.

It looks to me like it's a bad idea[tm] to set the resource map at all 
before knowing anything about the machine's resources.


debugging...
  Stefan



From stepan at suse.de  Thu Aug  7 10:42:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Aug  7 10:42:00 2003
Subject: quartet boot
In-Reply-To: <20030807141946.GA13690@suse.de>
References: <20030807141946.GA13690@suse.de>
Message-ID: <20030807145802.GA14546@suse.de>

* Stefan Reinauer <stepan at suse.de> [030807 16:19]:
> Can the resource map cause these problems? I dumped the resource map
> I am using from a different quartet machine, and now I get the same
> problems than I had before with the default resource map.

This time it's different trouble. Seems some changes in coherent_ht.c
did not like the quartet too well...

Stefan



From pyro at linuxlabs.com  Thu Aug  7 10:51:30 2003
From: pyro at linuxlabs.com (steven james)
Date: Thu Aug  7 10:51:30 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <20030807051619.GA19983@planetfall.com>
Message-ID: <Pine.LNX.4.21.0308071055170.23114-100000@ucontrol.mobiledns.com>

Greetings,

It might be useful to switch to ext2 so the journaling code can be
dropped. In general, a bootloader mostly needs read only access anyway.

Might also be interesting to see how much network/socket code can be
chopped out of a kernel/bootloader.

G'day,
sjames



On Thu, 7 Aug 2003, Jeff Noxon wrote:

> I just built 2.6.0-test2 in 441kB with one IDE DMA driver and ext3.
> I have yet to try LinuxBIOS (waiting for some BIOS Saviors!), but it
> looks like I will be able to do quite a lot with my Tyan Tiger MPX
> (S2466N-4M) if I upgrade the BIOS chip to an 8mbit part.
> 
> Doing anything useful with the 4mbit chip may still be a lost cause,
> but it does look like 2.6.0 has lost some bloat.  Perhaps if some
> of us contribute more "embedded fat-trimming" patches we can make
> linuxbios+linux+initrd fit easily in a half megabyte.
> 
> Jeff
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------




From rminnich at lanl.gov  Thu Aug  7 11:14:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug  7 11:14:00 2003
Subject: quartet boot
In-Reply-To: <20030807141946.GA13690@suse.de>
Message-ID: <Pine.LNX.4.44.0308070908320.8383-100000@maxroach.lanl.gov>

On Thu, 7 Aug 2003, Stefan Reinauer wrote:

> It looks to me like it's a bad idea[tm] to set the resource map at all 
> before knowing anything about the machine's resources.

Is this the right time to fill out the "probe" and "present" stuff that 
Greg mentioned for the static cpu map?

ron



From ebiederman at lnxi.com  Thu Aug  7 13:48:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Aug  7 13:48:00 2003
Subject: Option ROM for Device.
In-Reply-To: <Pine.LNX.4.44.0308061249340.20543-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308061249340.20543-100000@maxroach.lanl.gov>
Message-ID: <m3wudp8hnv.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 6 Aug 2003, Eric W. Biederman wrote:
> 
> > Which model RAID-SCSI controller?  I have seen an amazing number that
> > have worked.  I am wondering if it is simply a misreport.
> 
> not sure, talk to the folks at Argonne, it's a LNXI cluster

If it is the one I think it is LinuxBIOS was not ready for the board
at the time the cluster shipped, so we did not put it on.  It was not
the RAID-SCSI, that we managed to test without the option ROM and that
worked.

Eric



From jeff at planetfall.com  Thu Aug  7 14:15:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Thu Aug  7 14:15:00 2003
Subject: Using USB Flash drives instead of CF
Message-ID: <20030807183102.GA5486@planetfall.com>

Has anyone tried using a USB Flash drive instead of CF?  I can build a
usable 2.6.0-test2 kernel in well under 400kB with USB and SCSI support,
and most of the rest as modules.  In theory it could just use /dev/sda
as the root device, right?

Unfortunately, networking adds another 156kB to the size of the compressed
kernel, and cannot be built as a module...  But I can live without that
on a workstation, and etherboot could always be included too.

Regards,

Jeff


From jeff at planetfall.com  Thu Aug  7 15:30:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Thu Aug  7 15:30:01 2003
Subject: Tiger MPX & LinuxBIOS
In-Reply-To: <Pine.LNX.4.21.0308061627420.23114-100000@ucontrol.mobiledns.com>
References: <20030806201500.GA31025@planetfall.com> <Pine.LNX.4.21.0308061627420.23114-100000@ucontrol.mobiledns.com>
Message-ID: <20030807194631.GA20777@planetfall.com>

Howdy, I'm the newbie du jour.

I'm attempting to get Linuxbios working on an EPIA 533 and a Tyan Tiger
MPX (S2466N-4M).  I was able to build an EPIA BIOS w/o trouble using
the Howto.  Applying the same principles to the Tiger, I am running
into trouble.

Can someone please help?

TIA,

Jeff

---- cut here ----

hedgehog:/usr/src/linuxbios/TigerMPX-primary# make
Makefile:602: warning: overriding commands for target `keyboard.o'
Makefile:479: warning: ignoring old commands for target `keyboard.o'
Makefile:605: warning: overriding commands for target `mc146818rtc.o'
Makefile:482: warning: ignoring old commands for target `mc146818rtc.o'
Makefile:608: warning: overriding commands for target `isa-dma.o'
Makefile:485: warning: ignoring old commands for target `isa-dma.o'
Makefile:611: warning: overriding commands for target `i8259.o'
Makefile:488: warning: ignoring old commands for target `i8259.o'
Makefile:614: warning: overriding commands for target `udelay_timer2.o'
Makefile:491: warning: ignoring old commands for target `udelay_timer2.o'
Makefile:617: warning: overriding commands for target `beep.o'
Makefile:494: warning: ignoring old commands for target `beep.o'
Makefile:620: warning: overriding commands for target `vga_load_regs.o'
Makefile:497: warning: ignoring old commands for target `vga_load_regs.o'
Makefile:623: warning: overriding commands for target `font_8x16.o'
Makefile:500: warning: ignoring old commands for target `font_8x16.o'
Makefile:626: warning: overriding commands for target `vga_set_mode.o'
Makefile:503: warning: ignoring old commands for target `vga_set_mode.o'
Makefile:629: warning: overriding commands for target `vga_load_pcx.o'
Makefile:506: warning: ignoring old commands for target `vga_load_pcx.o'
Makefile:632: warning: overriding commands for target `ide.o'
Makefile:509: warning: ignoring old commands for target `ide.o'
cp /usr/src/linuxbios/linuxbios/src/arch/i386/config/crt0.base crt0.S
gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s
gcc ... -o crt0.o crt0.s
crt0.S: Assembler messages:
crt0.S:156: Warning: indirect jmp without `*'
/usr/src/linuxbios/linuxbios/src/southbridge/amd/amd768/disable_watchdog.inc:3: Error: undefined symbol `L0
' in operation
/usr/src/linuxbios/linuxbios/src/southbridge/amd/amd768/disable_watchdog.inc:10: Error: undefined symbol `L0
' in operation
/usr/src/linuxbios/linuxbios/src/southbridge/amd/amd768/disable_watchdog.inc:18: Error: undefined symbol `L0
' in operation
/usr/src/linuxbios/linuxbios/src/southbridge/amd/amd768/smbus.inc:48: Error: undefined symbol `L0
' in operation
/usr/src/linuxbios/linuxbios/src/southbridge/amd/amd768/smbus.inc:57: Error: undefined symbol `L0
' in operation
make: *** [crt0.o] Error 1

---- cut here ----

All the lines that are giving me trouble are a varation of this:

       movl    $(0x80000000 | PM_DEV_FN | 0x49), %eax

Which is defined as:

#define PM_DEV_FN (AMD768_DEV + 0x300)

Although I don't immediately see where AMD768_DEV is defined.  Hey,
I'm a newbie ;)

Versions:

LinuxBIOS CVS from yesterday (wow, sf.net is slow!)
gcc version 3.3.1 20030728 (Debian prerelease)
[binutils] GNU assembler version 2.14.90.0.5 (i386-linux) using BFD version 2.14.90.0.5 20030722 Debian GNU/Linux

Here is my config file, basically borrowed from the example:


## This is relative to where the configuration file resides in the filesystem
target /usr/src/linuxbios/TigerMPX-primary

mainboard tyan/TigerMPX

## Build a normal not a fallback image.
option USE_NORMAL_IMAGE=1

## Build an image for a 512KB rom
## ./normal/romimage is the entire rom image except for the last 64KB
## which are reserved for the fallback image.
option ROM_SIZE=524288

## Select the maximum size the linuxBIOS code can compile to.
## Allow linuxBIOS to be up to 48KB in size
#option ROM_IMAGE_SIZE=49152
option ROM_IMAGE_SIZE=65536

## 
### The Serial Console
##
## Hardware flow control is currently ignored.

## Enable the Serial Console
option SERIAL_CONSOLE=1

## Select the serial console baud rate.
option TTYS0_BAUD=115200
#option TTYS0_BAUD=57600
#option TTYS0_BAUD=38400
#option TTYS0_BAUD=19200
#option TTYS0_BAUD=9600
#option TTYS0_BAUD=4800
#option TTYS0_BAUD=2400
#option TTYS0_BAUD=1200

# Select the serial console base port
option TTYS0_BASE=0x3f8

# Select the serial protocol
# This defaults to 8 data bits, 1 stop bit, and no parity
option TTYS0_LCS=0x3

#this configures serial to accept input (needed for some payloads)
option PYRO_SERIAL=1

##
### 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
option DEFAULT_CONSOLE_LOGLEVEL=8
## At a maximum only compile in this level of debugging
option MAXIMUM_CONSOLE_LOGLEVEL=9

## Use the elf bootloader
option USE_ELF_BOOT=1

## Select the boot device
option USE_GENERIC_ROM=1
#option BOOT_FLOPPY=1
#option USE_SERIAL_FILL_INBUF=1
#option BOOT_IDE=1

# Load etherboot with the elf bootloader
# The payload command is relative the build directory
# So .. is the directory this config file resides in
payload /usr/src/linuxbios/etherboot-5.0.8/src/bin32/3c90x.elf



From ts1 at tsn.or.jp  Thu Aug  7 15:55:01 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Thu Aug  7 15:55:01 2003
Subject: Supporting extension ROMs and beyond...
Message-ID: <20030807201111.GA26899@tsn.or.jp>

I guess, in this direction of development, you will most certainly
have to implement more legacy BIOS services (realmode INTxx).

And, once SCSI BIOS worked, you automatically get INT13
(disk services) because SCSI BIOS hooks it.
You already have INT10 (video services) by external VGA BIOS.
Also you already have IDE and floppy drivers to implement your own
INT13.

OTOH, loading first sector of first drive into 0x7c00
and jumping into it is an easy task, because you already have pieces of code
to support it (realmode switching, bounce buffer, etc.)

So, will you add a few more legacy services to run LILO and bzImage
directly from LinuxBIOS? Even more services to boot Windows?
What do you think?

--
Takeshi


From linuxbios at smashed.demon.co.uk  Thu Aug  7 16:01:01 2003
From: linuxbios at smashed.demon.co.uk (James Weir)
Date: Thu Aug  7 16:01:01 2003
Subject: List Problem
Message-ID: <000001c35d20$5b8d0110$0b00000a@quadra001>

Can someone help, I keep getting two of every message?  Is anyone else
having this problem,

 

Thanks,

 

James.

 

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

From agnew at cs.umd.edu  Thu Aug  7 16:13:01 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Thu Aug  7 16:13:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030807201111.GA26899@tsn.or.jp>
Message-ID: <20030807162419.T10245-100000@www.missl.cs.umd.edu>


On Fri, 8 Aug 2003, SONE Takeshi wrote:

> I guess, in this direction of development, you will most certainly
> have to implement more legacy BIOS services (realmode INTxx).
>
> And, once SCSI BIOS worked, you automatically get INT13
> (disk services) because SCSI BIOS hooks it.
> You already have INT10 (video services) by external VGA BIOS.
> Also you already have IDE and floppy drivers to implement your own
> INT13.
>
> OTOH, loading first sector of first drive into 0x7c00
> and jumping into it is an easy task, because you already have pieces of code
> to support it (realmode switching, bounce buffer, etc.)
>
> So, will you add a few more legacy services to run LILO and bzImage
> directly from LinuxBIOS? Even more services to boot Windows?
> What do you think?
>

No one really wants LinuxBIOS to support legacy BIOS services. However,
the need for them keeps creeping in (I believe Ron plans to add int15 to
have better support for some vga roms). In the meantime, with a little
hacking you can probably get LinuxBIOS working with Bochs BIOS to do the
same job. Please see freebios/util/ADLO, it currently works for booting
Windows 2000 on SiS630 boards with LinuxBIOS and you probably only need
to make a few changes in loader.S to get it to work on your board too.

- Adam Agnew




From ebiederman at lnxi.com  Thu Aug  7 16:57:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Aug  7 16:57:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030807162419.T10245-100000@www.missl.cs.umd.edu>
References: <20030807162419.T10245-100000@www.missl.cs.umd.edu>
Message-ID: <m3oez1182h.fsf@maxwell.lnxi.com>

Adam Agnew <agnew at cs.umd.edu> writes:

> On Fri, 8 Aug 2003, SONE Takeshi wrote:
> 
> > I guess, in this direction of development, you will most certainly
> > have to implement more legacy BIOS services (realmode INTxx).
> >
> > And, once SCSI BIOS worked, you automatically get INT13
> > (disk services) because SCSI BIOS hooks it.
> > You already have INT10 (video services) by external VGA BIOS.
> > Also you already have IDE and floppy drivers to implement your own
> > INT13.
> >
> > OTOH, loading first sector of first drive into 0x7c00
> > and jumping into it is an easy task, because you already have pieces of code
> > to support it (realmode switching, bounce buffer, etc.)
> >
> > So, will you add a few more legacy services to run LILO and bzImage
> > directly from LinuxBIOS? Even more services to boot Windows?
> > What do you think?
> >
> 
> No one really wants LinuxBIOS to support legacy BIOS services. However,
> the need for them keeps creeping in (I believe Ron plans to add int15 to
> have better support for some vga roms). In the meantime, with a little
> hacking you can probably get LinuxBIOS working with Bochs BIOS to do the
> same job. Please see freebios/util/ADLO, it currently works for booting
> Windows 2000 on SiS630 boards with LinuxBIOS and you probably only need
> to make a few changes in loader.S to get it to work on your board too.

Given that Bochs BIOS aka ADLO works.  That is solution for supporting
binary only x86 options roms.

Nothing I have seen requires these things to be up terribly early, and without
source we can't bring them up early anyway.

Other directions similar directions are OpenBIOS for Open firmware support.
And at some point we might even do EFI support.

However none of this will get into the core of LinuxBIOS, they will all be
separate ELF loadable components like etherboot.

The project will still work on them, but they are not components of the core.

To grow beyond a certain point support it is required to support legacy hardware,
and hardware without open source drivers.  But by no means do we want to encourage
that kind of hardware.

The really fun prospect is to put general option ROM support into ADLO and
have Etherboot as an Option ROM implementing the network boot support.

Legacy services are expedient.

Eric



From steve at nexpath.com  Thu Aug  7 17:04:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Thu Aug  7 17:04:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030807162419.T10245-100000@www.missl.cs.umd.edu>
References: <20030807162419.T10245-100000@www.missl.cs.umd.edu>
Message-ID: <3F32C330.3040807@nexpath.com>

Adam Agnew wrote:

> No one really wants LinuxBIOS to support legacy BIOS services. However,
> the need for them keeps creeping in (I believe Ron plans to add int15 to
> have better support for some vga roms). 

True, and too bad if any int's are added, I agree with Linus' original 
comment that "we don't need no stinking BIOS...", but I agree that 
reverse engineering these complex VGA chips is no easy task.  However, I 
am going to continue to do it as I have time.  I don't know if there is 
a good argument for this other than religious convictions.  I seem to 
get a certain amount of self satisfaction out of booting linux without 
ever going into 16-bit mode, save the first instruction or two.  And it 
is disconcerting to see that linux is starting to use BIOS calls in some 
places, like power management stuff (AFAIR).

-Steve




From ebiederman at lnxi.com  Thu Aug  7 17:10:15 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Aug  7 17:10:15 2003
Subject: List Problem
In-Reply-To: <000001c35d20$5b8d0110$0b00000a@quadra001>
References: <000001c35d20$5b8d0110$0b00000a@quadra001>
Message-ID: <m3isp9yxga.fsf@maxwell.lnxi.com>

"James Weir" <linuxbios at smashed.demon.co.uk> writes:

> Can someone help, I keep getting two of every message?  Is anyone else
> having this problem,

I only see that when I have been copied on a message as well
as seeing it on the list.  Like I have just copied you now.

If you see three copies of this message I suspect you have
somehow been subscribed twice. Ron?

Eric



From rminnich at lanl.gov  Thu Aug  7 17:17:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug  7 17:17:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <3F32C330.3040807@nexpath.com>
Message-ID: <Pine.LNX.4.44.0308071530480.9213-100000@maxroach.lanl.gov>

On Thu, 7 Aug 2003, Steve Gehlbach wrote:

> is disconcerting to see that linux is starting to use BIOS calls in some 
> places, like power management stuff (AFAIR).

that's a big mistake ...

ron



From jeff at planetfall.com  Thu Aug  7 17:23:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Thu Aug  7 17:23:00 2003
Subject: BIOS Savior works on Tyan Tiger MPX (S2466N-4M)
In-Reply-To: <Pine.LNX.4.21.0308061627420.23114-100000@ucontrol.mobiledns.com>
References: <20030806201500.GA31025@planetfall.com> <Pine.LNX.4.21.0308061627420.23114-100000@ucontrol.mobiledns.com>
Message-ID: <20030807213605.GA1590@planetfall.com>

Folks,

I successfully installed a BIOS Savior RD1-PMC4 on my Tyan Tiger MPX
(S2466N-4M) today.  It works just fine, but I cannot identify the Flash
chip on it (0x9d/0x6e) -- if anyone knows how to track this down, I'd
love to know.  In the meantime I forced it to work with Steven James's
flash_tool program.  The flash chip that Tyan shipped with the board is
a SST49LF040.

I presume the RD1-PMC2 would work on the older Tiger MP board.

I can't say whether Tyan's DOS-based flash utility works with this beast
or not.  I can't get it to run at all on my machine -- it complains that
himem.sys is loaded, even on a boot disk that doesn't contain himem.sys!
I tried a handful of other flash utilities but none of them would ID the
BIOS Savior chip for me.

Regards,

Jeff


From rminnich at lanl.gov  Thu Aug  7 17:47:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug  7 17:47:01 2003
Subject: List Problem
In-Reply-To: <m3isp9yxga.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308071603040.9213-100000@maxroach.lanl.gov>

On 7 Aug 2003, Eric W. Biederman wrote:

> If you see three copies of this message I suspect you have
> somehow been subscribed twice. Ron?

I will be looking at this, but I saw no doubles last time I looked. I 
suspect another mailling list gone awry.

ron



From ijpraveen1 at yahoo.com  Thu Aug  7 21:46:01 2003
From: ijpraveen1 at yahoo.com (John Praveen)
Date: Thu Aug  7 21:46:01 2003
Subject: basic help.
Message-ID: <20030808020209.10113.qmail@web41704.mail.yahoo.com>

Hi,
                 I have the custom board (geode sc1200) with peripherals like ethernet, PCI audio video decoder, Tuner, hard disk, SDRAM, Flash memory. I will have to have my BIOS program, linux kernel and specific application program in my Flash memory. I have hard disk only for storing files.
 
                  My Flash memory is of 32 Mbits and SDRAM 32MBytes. 
 
                  I want to use LinuxBios. I build it for nano mainboard. But still I have many doubts. In normal BIOS, we will say the bios program to load the bootloader from hard disk into location 0000:7C00. 
 
                 What part of the program in Linuxbios will bring my linux kernel image from Flash into SDRAM?
 
                 Is any options or something to be included in the configuration file to say to boot from Flash memory.
 
                 In my embedded device the Flash memory is mapped to physical address 00000h to 3FFFFFh. So at what location should i place the linuxbios romimage and linux kernel image in my Flash memory? 
        
                Where shall my application program be placed in Flash? I hope I should have a filesystem. Is the MTD meant for the filesystem?
 
               What part of the program in Linuxbios will bring my linux kernel image from Flash into SDRAM?
 
Thanks in advance.
 
Regards,
John.
      



---------------------------------
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20030807/9925c38e/attachment.html>

From wing549 at earthlink.com  Thu Aug  7 23:38:00 2003
From: wing549 at earthlink.com (wing549)
Date: Thu Aug  7 23:38:00 2003
Subject: will it work?
Message-ID: <1060314853.15184.641.camel@localhost>

though my motherboard my not be on the list is it not their because it
just dosent work? or lack of reasearch, i have a asus a7v333, and a
abitkx7333r, both via chipsets, what are the possibilities of getting
the linuxbios on them? and could i totaly destroy my computers if im not
sucessful? thanks



From niki.waibel at newlogic.com  Fri Aug  8 03:37:00 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Fri Aug  8 03:37:00 2003
Subject: DoC on EPIA-M with DIP2PLCC adapter -- instead of 256kbyte bios chip
Message-ID: <200308080753.h787rPH3010365@enterprise2.newlogic.at>

hi,

my plan is still to use a DoC 2000 on an EPIA-M mobo
with a DIP2PLCC adapter -- instead of the original
256kbyte (PLCC) bios chip.

can anyone tell me if this is theoretically possible?

niki


From ts1 at cma.co.jp  Fri Aug  8 03:48:01 2003
From: ts1 at cma.co.jp (SONE Takeshi)
Date: Fri Aug  8 03:48:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <m3oez1182h.fsf@maxwell.lnxi.com>
References: <20030807162419.T10245-100000@www.missl.cs.umd.edu> <m3oez1182h.fsf@maxwell.lnxi.com>
Message-ID: <20030808080425.GA6138@cma.co.jp>

On Thu, Aug 07, 2003 at 03:17:26PM -0600, Eric W. Biederman wrote:
> Adam Agnew <agnew at cs.umd.edu> writes:
> > No one really wants LinuxBIOS to support legacy BIOS services. However,
> > the need for them keeps creeping in (I believe Ron plans to add int15 to
> > have better support for some vga roms). In the meantime, with a little
> > hacking you can probably get LinuxBIOS working with Bochs BIOS to do the
> > same job. Please see freebios/util/ADLO, it currently works for booting
> > Windows 2000 on SiS630 boards with LinuxBIOS and you probably only need
> > to make a few changes in loader.S to get it to work on your board too.
> 
> Given that Bochs BIOS aka ADLO works.  That is solution for supporting
> binary only x86 options roms.
> 
> Nothing I have seen requires these things to be up terribly early, and without
> source we can't bring them up early anyway.
> 
> Other directions similar directions are OpenBIOS for Open firmware support.
> And at some point we might even do EFI support.
> 
> However none of this will get into the core of LinuxBIOS, they will all be
> separate ELF loadable components like etherboot.
> 
> The project will still work on them, but they are not components of the core.

I thought I would get comments like this.

So, we need an external program that provides legacy BIOS compatibility,
like ADLO.

However, using Bochs BIOS as a base does not look very good idea to me.
Adding more code to such a fragile piece of code is almost impossible to
me.
It's already broken in many ways when dealing with real hardware, for 
instance, IDE detection is wrong, it tries to probe device
presence by writing and reading registers without checking
BSY bit cleared. It's violation of ATA spec and that's why one of
my drive is not detcted while spinning up. Bochs BIOS is all written
this way since Bochs' emulated hard drives never spin up.
Also, Bochs BIOS is providing deep level of compatibility, such as
hardcoded entry points, and I guess they are unneeded to support
option ROMs (and loading modern OS), they only contribute to make it
hard to maintain.

OTOH, current VGABIOS support in LinuxBIOS can be extended
in a lot cleaner way, since it's 32-bit GCC code.

So, my suggestion is to move the legacy BIOS support of LinuxBIOS to
a new standalone ELF executable, and extend it to support general PCI
option ROMs, and optionally IPL from first drive.

> The really fun prospect is to put general option ROM support into ADLO and
> have Etherboot as an Option ROM implementing the network boot support.

Last time I tried ADLO->Etherboot worked. ADLO reserves 64KB
for VGABIOS but my VGABIOS is 48KB and ide_disk.zrom is just 16KB
so it was easy to have it there. Bochs BIOS already has code to find
and call option ROMs when they are on memory already.

--
Takeshi


From agnew at cs.umd.edu  Fri Aug  8 03:55:00 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Fri Aug  8 03:55:00 2003
Subject: ClearWater533 / Winbond Datasheet?
In-Reply-To: <m3isp9yxga.fsf@maxwell.lnxi.com>
Message-ID: <20030808040225.U12593-100000@www.missl.cs.umd.edu>

I'm trying to get a Clearwater 533 board up (the SuperMicro X5DPL-IGM)
without success. Or well, there's probably success, but I wouldn't know
about it because the serial port throws out only question marks and
periods :)

The only time I see anything is when i reboot into LinuxBIOS from the
original BIOS, though its just the
Restarting system.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.0.0 Fri Aug 8 02:27:40 EDT 2003 rebooting...
..?.?.?????.?.????..??????.?.?.???.??.?.??????.??.?????.?.?.????????
and so on..

Therefore, I believe the problem is the Winbond SuperI/O. The product
number is W83627HF-AW and perhaps that's somewhat different than the
W83627HF. So my question is, does anyone know where a datasheet for
W83627HF-AW can be found (it's not among those offered at winbond.com),
know someone at winbond i could talk to, or have any further insights on
the matter?

- Adam Agnew



From jhearns at micromuse.com  Fri Aug  8 05:24:01 2003
From: jhearns at micromuse.com (John Hearns)
Date: Fri Aug  8 05:24:01 2003
Subject: Using USB Flash drives instead of CF
In-Reply-To: <20030807183102.GA5486@planetfall.com>
References: <20030807183102.GA5486@planetfall.com>
Message-ID: <3F33700D.6030507@micromuse.com>

Jeff Noxon wrote:

>Has anyone tried using a USB Flash drive instead of CF?  I can build a
>usable 2.6.0-test2 kernel in well under 400kB with USB and SCSI support,
>and most of the rest as modules.  In theory it could just use /dev/sda
>as the root device, right?
>  
>
The Oreilly book on Embedded Linux I mentioned yesterday has a good 
section on using USB flash drives.




From bob at drzyzgula.org  Fri Aug  8 05:31:00 2003
From: bob at drzyzgula.org (Bob Drzyzgula)
Date: Fri Aug  8 05:31:00 2003
Subject: ClearWater533 / Winbond Datasheet?
In-Reply-To: <20030808040225.U12593-100000@www.missl.cs.umd.edu>
References: <m3isp9yxga.fsf@maxwell.lnxi.com> <20030808040225.U12593-100000@www.missl.cs.umd.edu>
Message-ID: <20030808054609.A32381@www2>

Adam,

I found (using google) a datasheet here:

http://isc.portwell.com.tw/support/Technical%20Spec%20&%20Users%20Manual/datasheet/Winbond/83627hf.pdf

that mentions -AW and -PW versions of the chip. The HF appears
to have a 2KB programmable ROM for the 8042 controller; the
-AW supposedly comes pre-programmed with has AMIKEY firmware
and -PW with Pheonix Multikey firmware.

Hope this helps,
--Bob

On Fri, Aug 08, 2003 at 04:11:43AM -0400, Adam Agnew wrote:
> 
> I'm trying to get a Clearwater 533 board up (the SuperMicro X5DPL-IGM)
> without success. Or well, there's probably success, but I wouldn't know
> about it because the serial port throws out only question marks and
> periods :)
> 
> The only time I see anything is when i reboot into LinuxBIOS from the
> original BIOS, though its just the
> Restarting system.
> Copying LinuxBIOS to ram.
> Jumping to LinuxBIOS.
> LinuxBIOS-1.0.0 Fri Aug 8 02:27:40 EDT 2003 rebooting...
> ..?.?.?????.?.????..??????.?.?.???.??.?.??????.??.?????.?.?.????????
> and so on..
> 
> Therefore, I believe the problem is the Winbond SuperI/O. The product
> number is W83627HF-AW and perhaps that's somewhat different than the
> W83627HF. So my question is, does anyone know where a datasheet for
> W83627HF-AW can be found (it's not among those offered at winbond.com),
> know someone at winbond i could talk to, or have any further insights on
> the matter?
> 
> - Adam Agnew
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


From Antony at Soft-Solutions.co.uk  Fri Aug  8 05:54:01 2003
From: Antony at Soft-Solutions.co.uk (Antony Stone)
Date: Fri Aug  8 05:54:01 2003
Subject: Using USB Flash drives instead of CF
In-Reply-To: <3F33700D.6030507@micromuse.com>
References: <20030807183102.GA5486@planetfall.com> <3F33700D.6030507@micromuse.com>
Message-ID: <200308081010.h78AASD15147@onyx.rockstone.co.uk>

On Friday 08 August 2003 10:40 am, John Hearns wrote:

> The Oreilly book on Embedded Linux I mentioned yesterday has a good
> section on using USB flash drives.

Hi John :)

I didn't see a posting from you on this list yesterday, but the book sounds 
interesting; please could you repeat it?

Thanks,

Antony.

-- 

The difference between theory and practice is that
in theory there is no difference, whereas in practice there is.


From jhearns at micromuse.com  Fri Aug  8 06:19:00 2003
From: jhearns at micromuse.com (John Hearns)
Date: Fri Aug  8 06:19:00 2003
Subject: Embedded Linux Systems book
Message-ID: <3F337CEA.2040203@micromuse.com>

Over the weekend I went to the UKUUG Linux Developers Conference in 
Edinburgh.
http://www.ukuug.org/events/linux2003/
Lots of great stuff, including a tutorial by Stephen Tweedie and a BOF 
we had on clusters and
filesystems. Plus whisky and visits to the Festival Fringe :-)
I gave a presentation on mini-ITX systems, sadly though I didn't run 
Linuxbios.

Josette Garcia from OReilly UK had her usual stand, with lots of 
tempting books.
As usual, I could not resist adding to my collection.
I bought the new 'Building Embedded Linux Systems'  
http://www.oreilly.com/catalog/belinuxsys/
Reading it on the train journey back home, I tought it is an excellent 
book.
Lots of information on DoC, CompactFlash, filesystems -CRAMFS, JFFS2 
etc. and their characteristics,
methods of booting and creating bootable CFS, programming BIOSes.
Could give people good information on DoC etc.

All in all, I would reccomend this book, as there are good general 
sections on the various architectures
Linux runs on, and also an appendix discussing binary-only drivers, and 
Linus' attitude to them.


BTW, was it in this book that I read that from 2.5 kernels Linux will 
run on MMU-less 68000 CPUs?
Time to dust down my old copy of "68000 Assembly Language Programming" 
from yea long ago...



From rminnich at lanl.gov  Fri Aug  8 10:05:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 10:05:01 2003
Subject: DoC on EPIA-M with DIP2PLCC adapter -- instead of 256kbyte bios
 chip
In-Reply-To: <200308080753.h787rPH3010365@enterprise2.newlogic.at>
Message-ID: <Pine.LNX.4.44.0308080821320.17741-100000@maxroach.lanl.gov>

On Fri, 8 Aug 2003, Niki Waibel wrote:

> my plan is still to use a DoC 2000 on an EPIA-M mobo
> with a DIP2PLCC adapter -- instead of the original
> 256kbyte (PLCC) bios chip.

that won't work, as the 2000 does not have an addressable boot block like 
the 2001.

ron



From rminnich at lanl.gov  Fri Aug  8 10:12:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 10:12:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030808080425.GA6138@cma.co.jp>
Message-ID: <Pine.LNX.4.44.0308080823030.17741-100000@maxroach.lanl.gov>

On Fri, 8 Aug 2003, SONE Takeshi wrote:

> On Thu, Aug 07, 2003 at 03:17:26PM -0600, Eric W. Biederman wrote:
> > However none of this will get into the core of LinuxBIOS, they will all be
> > separate ELF loadable components like etherboot.
> So, we need an external program that provides legacy BIOS compatibility,
> like ADLO.

I don't have quite the same opinion on this one. I would like to have 
Linux in flash -- we do that now. 

If I plug in the linux vga support, by boot path is simple. 

Linuxbios->Linux

The VGA support code is very simple. 

If I stick with this requirement that the VGA roms get supported by an 
external ELF piece, I have to do this:

linuxbios -> external ELF bit that does VGA ROMs -> some other bit that 
loads linux from flash -> linux

More and more pieces. ADLO is far more capability than I need. Therefore I 
intend to bring the VGA support forward to FreeBIOS2, based on my needs 
and comments from other linuxbios users.

I agree that in some sense it is "cleaner" to have VGA support in some 
external binary blob, but it is far more convenient to have it right in 
linuxbios itself. It works today, so I can't see strong reasons not to 
continue using it.

ron



From rminnich at lanl.gov  Fri Aug  8 10:18:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 10:18:00 2003
Subject: ClearWater533 / Winbond Datasheet?
In-Reply-To: <20030808040225.U12593-100000@www.missl.cs.umd.edu>
Message-ID: <Pine.LNX.4.44.0308080829180.17741-100000@maxroach.lanl.gov>

we're having trouble with that supermicro chipset too. We're doing teh 
X5DAE. 

Our problem looks like SPD issues.

I'll try to tell you more as we see it.

ron



From niki.waibel at newlogic.com  Fri Aug  8 11:17:00 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Fri Aug  8 11:17:00 2003
Subject: DoC on EPIA-M with DIP2PLCC adapter -- instead of 256kbyte bios chip
In-Reply-To: <Pine.LNX.4.44.0308080821320.17741-100000@maxroach.lanl.gov>
Message-ID: <200308081533.h78FX9H3005783@enterprise2.newlogic.at>

>> my plan is still to use a DoC 2000 on an EPIA-M mobo
>> with a DIP2PLCC adapter -- instead of the original
>> 256kbyte (PLCC) bios chip.
> 
> that won't work, as the 2000 does not have an addressable boot block like 
> the 2001.

what is the exact type i need for that?
does that 2001 fit into a DIP socket?

niki


From rminnich at lanl.gov  Fri Aug  8 11:17:42 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 11:17:42 2003
Subject: DoC on EPIA-M with DIP2PLCC adapter -- instead of 256kbyte bios
 chip
In-Reply-To: <200308081533.h78FX9H3005783@enterprise2.newlogic.at>
Message-ID: <Pine.LNX.4.44.0308080933280.18166-100000@maxroach.lanl.gov>

On Fri, 8 Aug 2003, Niki Waibel wrote:

> does that 2001 fit into a DIP socket?

DIP32

ron



From agnew at cs.umd.edu  Fri Aug  8 11:53:01 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Fri Aug  8 11:53:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308080823030.17741-100000@maxroach.lanl.gov>
Message-ID: <20030808114245.Y12668-100000@www.missl.cs.umd.edu>


> If I stick with this requirement that the VGA roms get supported by an
> external ELF piece, I have to do this:
>
> linuxbios -> external ELF bit that does VGA ROMs -> some other bit that
> loads linux from flash -> linux
>

I tend to agree with Sone that much of these functions should be seperated
into ELFs, but I did so on the assumption that we had a framework to
return to LinuxBIOS already. Is that still in the works? It seemed to me
like a utility such as Steven James' Bare Metal Toolkit, which seeks out
ELF images in ROM could then execute them in order:

linuxBIOS ->
	VGA Search and Init ROM ELF
	<- Back to linuxBIOS
linuxBIOS ->
	Polled IDE & File Systems Support ELF
	Success:
	-> Linux
	Failure
	<- Back to LinuxBIOS
LinuxBIOS ->
	Etherboot tftp boot ELF
	Success:
	-> Linux
	Failure
	<- Back to LinuxBIOS
LinuxBIOS ->
	Last Ditch Effort Floppy Boot ELF
	Success:
	-> Linux
	Failure
	<- Back to LinuxBIOS
LinuxBIOS out of options and says so.

All of that could fit in a 256KB part while providing several fallbacks
and choices. And it still serves a purpose when EEPROMs are big and roomy, as
tasks like a VGA Seek and Init ELF can perform their task without getting
LB2 dirty before going to Linux. The complexity of returning to LB to then
execute the next ELF image seems trivial next to maintaining polled ide,
floppy, INT15, and all these other features right in LB.

Thanks for concideration before flames :)

- Adam Agnew



From agnew at cs.umd.edu  Fri Aug  8 12:03:00 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Fri Aug  8 12:03:00 2003
Subject: ClearWater533 / Winbond Datasheet?
In-Reply-To: <Pine.LNX.4.44.0308080829180.17741-100000@maxroach.lanl.gov>
Message-ID: <20030808121616.H12668-100000@www.missl.cs.umd.edu>

Did you have the same winbond with award firmware? I'd be interested to
learn if you found a way to work through that.

On Fri, 8 Aug 2003, ron minnich wrote:

> we're having trouble with that supermicro chipset too. We're doing teh
> X5DAE.
>
> Our problem looks like SPD issues.
>
> I'll try to tell you more as we see it.
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From rminnich at lanl.gov  Fri Aug  8 12:05:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 12:05:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030808114245.Y12668-100000@www.missl.cs.umd.edu>
Message-ID: <Pine.LNX.4.44.0308081019370.18166-100000@maxroach.lanl.gov>

I guess I have a hard time seeing the difference between linking functions 
into LB via the static device tree, and calling ELFs, except that you get 
no space savings with the ELF approach. You're going to create printk etc. 
functions in every single ELF image, and in fact you'll have a whole "BIOS 
library" in each and every ELF iamge. 

All things considered I'd rather link them in. I am very tight for space 
no the K8 with 1 MB flash, so growing things larger is not an option. 

Now if we want to have a way to choose seperate ELF payloads or direct 
linking them in at build time, that makes lots of sense to me. We can try 
to look at that. 

ron



From rminnich at lanl.gov  Fri Aug  8 12:07:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 12:07:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030808114245.Y12668-100000@www.missl.cs.umd.edu>
Message-ID: <Pine.LNX.4.44.0308081022170.18166-100000@maxroach.lanl.gov>

On Fri, 8 Aug 2003, Adam Agnew wrote:

for example;
> linuxBIOS ->
> 	VGA Search and Init ROM ELF

	with its own printk, etc?

> 	<- Back to linuxBIOS
> linuxBIOS ->

	with its own printk, etc?

> 	Polled IDE & File Systems Support ELF

> 	Success:
> 	-> Linux
> 	Failure
> 	<- Back to LinuxBIOS
> LinuxBIOS ->

	with its own printk, etc?

> 	Etherboot tftp boot ELF
> 	Success:
> 	-> Linux
> 	Failure
> 	<- Back to LinuxBIOS
> LinuxBIOS ->

	with its own printk, etc?

> 	Last Ditch Effort Floppy Boot ELF

	with its own printk, etc?

> 	Success:
> 	-> Linux
> 	Failure
> 	<- Back to LinuxBIOS

I just don't see this as the best approach. If we're going to have some 
flexibilty in boot modules, why not just compile them in in a flexible 
way, as opposed to building them all separately? What's the advantage?

ron



From rminnich at lanl.gov  Fri Aug  8 12:09:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 12:09:00 2003
Subject: ClearWater533 / Winbond Datasheet?
In-Reply-To: <20030808121616.H12668-100000@www.missl.cs.umd.edu>
Message-ID: <Pine.LNX.4.44.0308081025550.18166-100000@maxroach.lanl.gov>

On Fri, 8 Aug 2003, Adam Agnew wrote:

> 
> Did you have the same winbond with award firmware? I'd be interested to
> learn if you found a way to work through that.

what is that all about? I am confused by the concept.

ron



From ebiederman at lnxi.com  Fri Aug  8 12:31:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Aug  8 12:31:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308081019370.18166-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308081019370.18166-100000@maxroach.lanl.gov>
Message-ID: <m3he4srt2s.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> I guess I have a hard time seeing the difference between linking functions 
> into LB via the static device tree, and calling ELFs, except that you get 
> no space savings with the ELF approach. You're going to create printk etc. 
> functions in every single ELF image, and in fact you'll have a whole "BIOS 
> library" in each and every ELF iamge. 

Possibly.  But that library can be made very small.  printk is a fairly
trivial function.  At least when you are talking the serial console.
 
> All things considered I'd rather link them in. I am very tight for space 
> no the K8 with 1 MB flash, so growing things larger is not an option. 

And this is a real issue that will drive a lot of this.
The standard flash on the K8's I have seen is 512K.
 
> Now if we want to have a way to choose seperate ELF payloads or direct 
> linking them in at build time, that makes lots of sense to me. We can try 
> to look at that. 

I am not certain about multiple payloads.  

But beyond that having etherboot separate has proved very valuable.

1) It totally separates the chipset initialization from booting.
2) It allows usage of a known good etherboot on a development platform.

And only by reusing binaries does this work so well.

As for space constraints once I get romcc fixed to not inline everything
Opteron LinuxBIOS should get as small as the rest of them.

Taking boot loaders to the next step is a very interesting question.  For
the normal case where traditional BIOS's work ADLO looks to be a very
satisfying solution.  For the HPC side this are much trickier.  

For things to think about.  The reason traditional BIOS's are 16bit
real mode beasts is because Windows runs parts of them in vm86 mode.
Which is why 32bit extensions are not common.

Eric



From rminnich at lanl.gov  Fri Aug  8 12:39:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 12:39:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <m3he4srt2s.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308081054030.18166-100000@maxroach.lanl.gov>

On 8 Aug 2003, Eric W. Biederman wrote:

> But beyond that having etherboot separate has proved very valuable.

agree. In general, having "THE PAYLOAD" separate is a good deal. I would 
not want to link, e.g., 9load into linuxbios, and I can't even build those 
two on the same system. 

My doubts concern the multiple payload scenario.

ron




From lpacheco at netvisao.pt  Fri Aug  8 12:44:01 2003
From: lpacheco at netvisao.pt (Luis Pacheco)
Date: Fri Aug  8 12:44:01 2003
Subject: Using USB Flash drives instead of CF
Message-ID: <1060365621.1799.6.camel@toshiba.loopback>

Hello,

I think this link can help you:

http://www.8ung.at/spblinux/concept.htm#usb

There is an part about usb storage media and linux kernel...

-- 
Luis Andr?? Pacheco
http://www.neuralbit.com



From jeff at planetfall.com  Fri Aug  8 13:31:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Fri Aug  8 13:31:00 2003
Subject: TigerMPX no dice - please help
Message-ID: <20030808174727.GA22159@planetfall.com>

Howdy,

I've been playing around with the CVS tree trying to get the TigerMPX
stuff to compile.

At first I got assembler warnings because AMD768_DEV was not defined.
I found that AMD766_DEV was defined, so I changed it.  That got a
little further.  It was set to 0x3800 yet my lspci -vvv shows my PCI
bridge at 0x2000.  Is that because the Tyan BIOS moved it?

Then I got a compile failure on the ide code.  It tries to include <ide.h>
which doesn't exist.  I #if 0'd around this because I use a different
controller anyway.  That got further along.

Then, after all the 768 stuff compiled, I got link failures as it was
trying to link amd766 functions instead of the 768 functions.

This all leads me to believe that the code in CVS is not really functional
to begin with.  Either that, or I am doing something really stupid, which
is entirely possible.  ;) Is there newer code that someone can send me,
and/or commit to CVS?

Last but not least, Sourceforge seems to be having a lot of CVS problems.
It is slow when it works, but it doesn't work much of the time I try
to use it.  I haven't been able to update in a few days, it just drops
my connections.

Thanks & Regards,

Jeff


From jeff at planetfall.com  Fri Aug  8 14:33:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Fri Aug  8 14:33:01 2003
Subject: Flash chip identified in BIOS Savior PMC4
Message-ID: <20030808185007.GA15445@planetfall.com>

To answer one of my own questions - The flash chip in the Bios Savior
RD1-PMC4 is the PMC Pm49FL004. (Manufacturer ID: 0=0x9D, 2=0x7F; Device
ID 1=0x6E)

http://www.pmcflash.com/resource_center/docs/Pm49FL002%2D004%2D008%20V1%2E1%2Epdf

Regards,

Jeff


From ts1 at tsn.or.jp  Fri Aug  8 15:09:01 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Fri Aug  8 15:09:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <m3he4srt2s.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0308081019370.18166-100000@maxroach.lanl.gov> <m3he4srt2s.fsf@maxwell.lnxi.com>
Message-ID: <20030808192552.GA13131@tsn.or.jp>

On Fri, Aug 08, 2003 at 10:51:23AM -0600, Eric W. Biederman wrote:
> > Now if we want to have a way to choose seperate ELF payloads or direct 
> > linking them in at build time, that makes lots of sense to me. We can try 
> > to look at that. 
> 
> I am not certain about multiple payloads.  

I've seen there is no way to ensure images to not overwrite each
other.
When LinuxBIOS loads ELF image at the same location as itself,
it moves itself to top of memory (below 4GB).
Etherboot (>=5.1) relocates itself to the same top memory,
since it is usually safe place when loading kernel.
Other future bootloaders would do the same.

Probably this could be resolved by indicating LinuxBIOS's location
in the memory map of LinuxBIOS table?

> Taking boot loaders to the next step is a very interesting question.  For
> the normal case where traditional BIOS's work ADLO looks to be a very
> satisfying solution. 

If ADLO works at all.

> For things to think about.  The reason traditional BIOS's are 16bit
> real mode beasts is because Windows runs parts of them in vm86 mode.
> Which is why 32bit extensions are not common.

I've been thinking about the same thing.
I guess you refer to the DOS-based Windows (-95/98/Me).
Of couse the DOS applications like EMM386 and things like DPMI 
won't run with a BIOS which does it's job in 32-bit.
And nowadays nobody uses those application.

Open source applications I've seen so far (setup of Linux, GRUB, Etherboot,
LILO...) are calling BIOS from pure real mode, so they won't notice
if the BIOS services they are calling are in fact 32-bit code.
I'm not sure but I guess NT-based Windows and its bootloader are
like Linux and its bootloaders.

If we cut off some of lagacy applications, we can implement a
clean 32-bit minimum legacy layer.



From ts1 at tsn.or.jp  Fri Aug  8 15:20:01 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Fri Aug  8 15:20:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308080823030.17741-100000@maxroach.lanl.gov>
References: <20030808080425.GA6138@cma.co.jp> <Pine.LNX.4.44.0308080823030.17741-100000@maxroach.lanl.gov>
Message-ID: <20030808193650.GB13131@tsn.or.jp>

On Fri, Aug 08, 2003 at 08:28:34AM -0600, ron minnich wrote:
> I agree that in some sense it is "cleaner" to have VGA support in some 
> external binary blob, but it is far more convenient to have it right in 
> linuxbios itself. It works today, so I can't see strong reasons not to 
> continue using it.

Then it's convenient to have a few more INTs and generic PCI ROM
enabling routine to enable the SCSI adapter. That code would be
simple and small anyway.
Then, at this point, why not adding a simple code to load IPL and
jumping it in real mode? It's smaller than a printk.


From rminnich at lanl.gov  Fri Aug  8 15:25:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 15:25:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030808193650.GB13131@tsn.or.jp>
Message-ID: <Pine.LNX.4.44.0308081338170.18166-100000@maxroach.lanl.gov>

On Sat, 9 Aug 2003, SONE Takeshi wrote:

> Then it's convenient to have a few more INTs and generic PCI ROM
> enabling routine to enable the SCSI adapter. That code would be
> simple and small anyway.

It doesn't bother me. I am fine with it. I believe that the VGA BIOS 
support can be used for this as well, with very little extra work.

> Then, at this point, why not adding a simple code to load IPL and
> jumping it in real mode? It's smaller than a printk.

Sure. 

Eric is concerned that it not be in the "core". I am willing to call it a 
compiled-in extension if everyone is ok with that. We could have a 
src/extensions directory, and put items such as the VGA BIOS support etc. 
in there. Such extensions have to be explicitly enabled. The static device 
mechanism gives us an easy way to hook into them.

But for reasons of space at least, I would really like to keep the ability
to compile VGA BIOS support directly into linuxbios. The ELF chaining that
Adam mentioned, while interesting, is complex enough to worry me.

Takeshi did I apply your last patch to VGA BIOS support? Can you check? 

thanks

ron



From ebiederman at lnxi.com  Fri Aug  8 15:31:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Aug  8 15:31:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030808192552.GA13131@tsn.or.jp>
References: <Pine.LNX.4.44.0308081019370.18166-100000@maxroach.lanl.gov>
	<m3he4srt2s.fsf@maxwell.lnxi.com> <20030808192552.GA13131@tsn.or.jp>
Message-ID: <m3he4sgc7f.fsf@maxwell.lnxi.com>

SONE Takeshi <ts1 at tsn.or.jp> writes:

> On Fri, Aug 08, 2003 at 10:51:23AM -0600, Eric W. Biederman wrote:
> > > Now if we want to have a way to choose seperate ELF payloads or direct 
> > > linking them in at build time, that makes lots of sense to me. We can try 
> > > to look at that. 
> > 
> > I am not certain about multiple payloads.  
> 
> I've seen there is no way to ensure images to not overwrite each
> other.
> When LinuxBIOS loads ELF image at the same location as itself,
> it moves itself to top of memory (below 4GB).
> Etherboot (>=5.1) relocates itself to the same top memory,
> since it is usually safe place when loading kernel.
> Other future bootloaders would do the same.
> 
> Probably this could be resolved by indicating LinuxBIOS's location
> in the memory map of LinuxBIOS table?

Yes that would resolve the problem.
 
> > Taking boot loaders to the next step is a very interesting question.  For
> > the normal case where traditional BIOS's work ADLO looks to be a very
> > satisfying solution. 
> 
> If ADLO works at all.

True.  ADLO is not quite ready to handle that yet.
 
> > For things to think about.  The reason traditional BIOS's are 16bit
> > real mode beasts is because Windows runs parts of them in vm86 mode.
> > Which is why 32bit extensions are not common.
> 
> I've been thinking about the same thing.
> I guess you refer to the DOS-based Windows (-95/98/Me).

Correct. 

> Of couse the DOS applications like EMM386 and things like DPMI 
> won't run with a BIOS which does it's job in 32-bit.
> And nowadays nobody uses those application.

Dosemu which uses DPMI still has a surprising number of users.

So while I don't think it is absolutely mandatory to support that kind
of think I think it is worth considering very carefully.

I believe FreeBSD also does BIOS calls from vm86 mode.

> Open source applications I've seen so far (setup of Linux, GRUB, Etherboot,
> LILO...) are calling BIOS from pure real mode, so they won't notice
> if the BIOS services they are calling are in fact 32-bit code.
> I'm not sure but I guess NT-based Windows and its bootloader are
> like Linux and its bootloaders.

Possibly.
 
> If we cut off some of lagacy applications, we can implement a
> clean 32-bit minimum legacy layer.

That is a hard question.   Remember thought that we have 256KB to
work with.  So it may not be too bad.  Traditional BIOS services
are pretty stupid.

I guess my preference would be to make a 16bit clean core that supports
option ROMS and those options roms could be like etherboot and do the extension.

Also of course we can put all of the 32bit entry points in high memory.

By and large I want to support as many legacy uses as we can.  That
allows use to be a complete replacement for AMI, and Phoenix.

Eric



From YhLu at tyan.com  Fri Aug  8 15:42:01 2003
From: YhLu at tyan.com (YhLu)
Date: Fri Aug  8 15:42:01 2003
Subject: Supporting extension ROMs and beyond...
Message-ID: <3174569B9743D511922F00A0C943142302FCA5C0@TYANWEB>

Ron,

Where is the VGA BIOS support? Still in freebios?

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?8? 12:42
???: SONE Takeshi
??: linuxbios at clustermatic.org
??: Re: Supporting extension ROMs and beyond...

On Sat, 9 Aug 2003, SONE Takeshi wrote:

> Then it's convenient to have a few more INTs and generic PCI ROM
> enabling routine to enable the SCSI adapter. That code would be
> simple and small anyway.

It doesn't bother me. I am fine with it. I believe that the VGA BIOS 
support can be used for this as well, with very little extra work.

> Then, at this point, why not adding a simple code to load IPL and
> jumping it in real mode? It's smaller than a printk.

Sure. 

Eric is concerned that it not be in the "core". I am willing to call it a 
compiled-in extension if everyone is ok with that. We could have a 
src/extensions directory, and put items such as the VGA BIOS support etc. 
in there. Such extensions have to be explicitly enabled. The static device 
mechanism gives us an easy way to hook into them.

But for reasons of space at least, I would really like to keep the ability
to compile VGA BIOS support directly into linuxbios. The ELF chaining that
Adam mentioned, while interesting, is complex enough to worry me.

Takeshi did I apply your last patch to VGA BIOS support? Can you check? 

thanks

ron

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Fri Aug  8 15:45:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Aug  8 15:45:01 2003
Subject: Slowly merging the static and dynamic device trees.
Message-ID: <m3d6ffhq4y.fsf@maxwell.lnxi.com>

So at first glance the static device tree seems to be pretty
usable so now I am investigating what needs to happen to merge
the device trees.

There is one large area of mismatch though that I don't know 
if I want to do something about or not.  Currently the static
device tree is by chip.  And the dynamic tree is by logical device.

Where this becomes challenging is on chips like the 8131 or the 8111
which have multiple busses hanging off of them.  Or even for the
simple amdk8 processor which has 3 HT links hanging off of it.  And I
don't want to mix the children of various busses.

For the arima/hdama my static device tree currently like:

cpu k8 "cpu0" 
	register "up" = "{.chip = &amd8131, .ht_width=16, .ht_speed=600}"
	southbridge amd/amd8131 "amd8131"
	end
	southbridge amd/amd8111 "amd8111"
		superio NSC/pc87360
			register "com1" = "{1}"
			register "lpt" = "{1}"
		end
	end
end

cpu k8 "cpu1" 
end


Now that I have something to start with I am busily brainstorming how
to glue all this together and make it work.

The new configuration tool seems to be doing a good job so far.

Eric



From pyro at linuxlabs.com  Fri Aug  8 15:46:01 2003
From: pyro at linuxlabs.com (steven james)
Date: Fri Aug  8 15:46:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030808192552.GA13131@tsn.or.jp>
Message-ID: <Pine.LNX.4.21.0308081558550.23114-100000@ucontrol.mobiledns.com>

Greetings,

I solved that for payloads built from the baremetal toolkit. They create a
simple data structure at the top of RAM with a signature in it so that the
first payload to run will know to set it up.

Each payload is expected to take what it needs from the top of available
memory and alter the structure to reflect the new top of available
memory. Upon exit, the old value is written back to release the memory.

A 'terminal' target such as linux ignores the structure since it will
never return anyway.

G'day,
sjames


On Sat, 9 Aug 2003, SONE Takeshi wrote:

> On Fri, Aug 08, 2003 at 10:51:23AM -0600, Eric W. Biederman wrote:
> > > Now if we want to have a way to choose seperate ELF payloads or direct 
> > > linking them in at build time, that makes lots of sense to me. We can try 
> > > to look at that. 
> > 
> > I am not certain about multiple payloads.  
> 
> I've seen there is no way to ensure images to not overwrite each
> other.
> When LinuxBIOS loads ELF image at the same location as itself,
> it moves itself to top of memory (below 4GB).
> Etherboot (>=5.1) relocates itself to the same top memory,
> since it is usually safe place when loading kernel.
> Other future bootloaders would do the same.
> 
> Probably this could be resolved by indicating LinuxBIOS's location
> in the memory map of LinuxBIOS table?
> 
> > Taking boot loaders to the next step is a very interesting question.  For
> > the normal case where traditional BIOS's work ADLO looks to be a very
> > satisfying solution. 
> 
> If ADLO works at all.
> 
> > For things to think about.  The reason traditional BIOS's are 16bit
> > real mode beasts is because Windows runs parts of them in vm86 mode.
> > Which is why 32bit extensions are not common.
> 
> I've been thinking about the same thing.
> I guess you refer to the DOS-based Windows (-95/98/Me).
> Of couse the DOS applications like EMM386 and things like DPMI 
> won't run with a BIOS which does it's job in 32-bit.
> And nowadays nobody uses those application.
> 
> Open source applications I've seen so far (setup of Linux, GRUB, Etherboot,
> LILO...) are calling BIOS from pure real mode, so they won't notice
> if the BIOS services they are calling are in fact 32-bit code.
> I'm not sure but I guess NT-based Windows and its bootloader are
> like Linux and its bootloaders.
> 
> If we cut off some of lagacy applications, we can implement a
> clean 32-bit minimum legacy layer.
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------




From ebiederman at lnxi.com  Fri Aug  8 15:54:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Aug  8 15:54:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308081338170.18166-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308081338170.18166-100000@maxroach.lanl.gov>
Message-ID: <m3oeyzewkh.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Sat, 9 Aug 2003, SONE Takeshi wrote:
> 
> > Then it's convenient to have a few more INTs and generic PCI ROM
> > enabling routine to enable the SCSI adapter. That code would be
> > simple and small anyway.
> 
> It doesn't bother me. I am fine with it. I believe that the VGA BIOS 
> support can be used for this as well, with very little extra work.

Several bugs fixes later and we have put the Bochs BIOS into LinuxBIOS.
Which doesn't work on anything but x86....

> > Then, at this point, why not adding a simple code to load IPL and
> > jumping it in real mode? It's smaller than a printk.
> 
> Sure. 
> 
> Eric is concerned that it not be in the "core". 

I am concerned in large part with feature creep and future maintainability.
I drew a line in the sand so we can see when we are going over it and
are close to being in trouble.

In the core we don't drive the hardware we initialize the hardware.  We only
drive the hardware that is needed to initialize other parts.

> I am willing to call it a 
> compiled-in extension if everyone is ok with that. We could have a 
> src/extensions directory, and put items such as the VGA BIOS support etc. 
> in there. Such extensions have to be explicitly enabled. The static device 
> mechanism gives us an easy way to hook into them.

It might be possible to convince me.  But doing it because it is most
convenient this way is not one I like.

> But for reasons of space at least, I would really like to keep the ability
> to compile VGA BIOS support directly into linuxbios. The ELF chaining that
> Adam mentioned, while interesting, is complex enough to worry me.

And why can't you do this a kernel patch for your magic kernel bootloader?

> Takeshi did I apply your last patch to VGA BIOS support? Can you check? 

Eric



From rminnich at lanl.gov  Fri Aug  8 16:12:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 16:12:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA5C0@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308081428370.18166-100000@maxroach.lanl.gov>

On Fri, 8 Aug 2003, YhLu wrote:

> Where is the VGA BIOS support? Still in freebios?

it's the one that SONE used in linuxbios, he can describe again how it is 
enabled. We are using it here for NVidia cards.

ron
p.s. but it doesn't work on nvidia yet!



From rminnich at lanl.gov  Fri Aug  8 16:13:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 16:13:00 2003
Subject: Slowly merging the static and dynamic device trees.
In-Reply-To: <m3d6ffhq4y.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308081429460.18166-100000@maxroach.lanl.gov>

On 8 Aug 2003, Eric W. Biederman wrote:

> cpu k8 "cpu0" 
> 	register "up" = "{.chip = &amd8131, .ht_width=16, .ht_speed=600}"
> 	southbridge amd/amd8131 "amd8131"
> 	end
> 	southbridge amd/amd8111 "amd8111"
> 		superio NSC/pc87360
> 			register "com1" = "{1}"
> 			register "lpt" = "{1}"
> 		end
> 	end
> end

nice, that's how we hoped it would look. 


> The new configuration tool seems to be doing a good job so far.

you just made my day.

ron



From agnew at cs.umd.edu  Fri Aug  8 16:30:01 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Fri Aug  8 16:30:01 2003
Subject: Clearwater533
In-Reply-To: <Pine.LNX.4.21.0308081558550.23114-100000@ucontrol.mobiledns.com>
Message-ID: <20030808164313.I12668-100000@www.missl.cs.umd.edu>

Could I trouble the list, and you three gentleman in particular, for a
list of E7501 motherboards which have worked for you? It would really help
me out so that I don't have to figure out what exactly is wrong with this
SuperMicro X5DPL-iGM in a short amount of time, as any E7501 working would
do. Thanks!

- Adam Agnew




From pyro at linuxlabs.com  Fri Aug  8 16:33:00 2003
From: pyro at linuxlabs.com (steven james)
Date: Fri Aug  8 16:33:00 2003
Subject: Clearwater533
In-Reply-To: <20030808164313.I12668-100000@www.missl.cs.umd.edu>
Message-ID: <Pine.LNX.4.21.0308081647480.23114-100000@ucontrol.mobiledns.com>

Greetings,

The clearwater itself (se7501cw2), Tyan (s2723 I believe)
Several of the Supermicro X5dpr and x5dpe
It looks like the new Superio on the DPL is the real problem there.

G'day,
sjames


On Fri, 8 Aug 2003, Adam Agnew wrote:

> 
> Could I trouble the list, and you three gentleman in particular, for a
> list of E7501 motherboards which have worked for you? It would really help
> me out so that I don't have to figure out what exactly is wrong with this
> SuperMicro X5DPL-iGM in a short amount of time, as any E7501 working would
> do. Thanks!
> 
> - Adam Agnew
> 
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------




From pyro at linuxlabs.com  Fri Aug  8 16:35:01 2003
From: pyro at linuxlabs.com (steven james)
Date: Fri Aug  8 16:35:01 2003
Subject: TigerMPX no dice - please help
In-Reply-To: <20030808174727.GA22159@planetfall.com>
Message-ID: <Pine.LNX.4.21.0308081650320.23114-100000@ucontrol.mobiledns.com>

Greetings,

I'm not honestly sure where the problems are coming from unless you got a
corrupted checkout. I will be in the office next week, and will do a fresh
checkout and see if I can duplicate the problem.

G'day,
sjames



On Fri, 8 Aug 2003, Jeff Noxon wrote:

> Howdy,
> 
> I've been playing around with the CVS tree trying to get the TigerMPX
> stuff to compile.
> 
> At first I got assembler warnings because AMD768_DEV was not defined.
> I found that AMD766_DEV was defined, so I changed it.  That got a
> little further.  It was set to 0x3800 yet my lspci -vvv shows my PCI
> bridge at 0x2000.  Is that because the Tyan BIOS moved it?
> 
> Then I got a compile failure on the ide code.  It tries to include <ide.h>
> which doesn't exist.  I #if 0'd around this because I use a different
> controller anyway.  That got further along.
> 
> Then, after all the 768 stuff compiled, I got link failures as it was
> trying to link amd766 functions instead of the 768 functions.
> 
> This all leads me to believe that the code in CVS is not really functional
> to begin with.  Either that, or I am doing something really stupid, which
> is entirely possible.  ;) Is there newer code that someone can send me,
> and/or commit to CVS?
> 
> Last but not least, Sourceforge seems to be having a lot of CVS problems.
> It is slow when it works, but it doesn't work much of the time I try
> to use it.  I haven't been able to update in a few days, it just drops
> my connections.
> 
> Thanks & Regards,
> 
> Jeff
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------




From rminnich at lanl.gov  Fri Aug  8 17:07:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 17:07:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <m3oeyzewkh.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308081512130.18166-100000@maxroach.lanl.gov>

On 8 Aug 2003, Eric W. Biederman wrote:

> Several bugs fixes later and we have put the Bochs BIOS into LinuxBIOS.
> Which doesn't work on anything but x86....

I take your point, but is there any harm done if this is packaged as an 
extension, not a part of the core? I just can't see the harm in it. It 
lies somewhere between ELF modules and integration into the core.

> I am concerned in large part with feature creep and future maintainability.
> I drew a line in the sand so we can see when we are going over it and
> are close to being in trouble.

No problem. 

> In the core we don't drive the hardware we initialize the hardware.  We only
> drive the hardware that is needed to initialize other parts.

Yep, but that means we still actually do drive the hardware in some cases. 
We do that because Linux can't do it, or because we should do it in one 
place, not in every payload. 

The problem is the complete lack of vga support is a common complaint I
hear all the time. I'd like to resolve that complaint in a simple way.  
Bochs is neat, but not simple. Maybe, however, we can make it simpler. I
really don't want to write x86 asm at this point, however. If I do this I
want to do it by building on the VGA BIOS stuff I wrote for 1.0.

The VGA BIOS code in 1.0 has proven to be pretty easy to use for people,
it's 32-bit code, and it's pretty easy to fix. Also, like the rest of 
LinuxBIOS, it has a very small assembly bit and the rest is C. 

I think chain-loading ELF modules or calling multiple ELF modules is a
harder, more complex, harder to build, and less efficient way to go.

> And why can't you do this a kernel patch for your magic kernel bootloader?

yes, that's an interesting idea. I can do it for Linux. If we use Linux as 
the bootloader we're ok. But if people want 9load or plan 9 in there, then 
I have to do it over again for them. It's not just a linux world.

As it happens, I just found out that Plan 9 can boot Plan 9, so Plan 9 in 
the FLASH is not at all unrealistic. And I already have 9load in flash, 
and VGA support would be very nice.

ron




From rminnich at lanl.gov  Fri Aug  8 17:09:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 17:09:01 2003
Subject: Clearwater533
In-Reply-To: <20030808164313.I12668-100000@www.missl.cs.umd.edu>
Message-ID: <Pine.LNX.4.44.0308081524150.18166-100000@maxroach.lanl.gov>

On Fri, 8 Aug 2003, Adam Agnew wrote:

> 
> Could I trouble the list, and you three gentleman in particular, for a
> list of E7501 motherboards which have worked for you? It would really help
> me out so that I don't have to figure out what exactly is wrong with this
> SuperMicro X5DPL-iGM in a short amount of time, as any E7501 working would
> do. Thanks!

The trouble we've just found with the X5DAE is that something else is 
needed to enable SPD. It appears that it's not just the GPIO2 on the 
superio. I am hoping supermicro will tell me what. It's even possible that 
they're not using the Intel ICH4 for SMBUS at this point, but are using 
the superio; we just can't tell. 

ron



From rminnich at lanl.gov  Fri Aug  8 18:41:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug  8 18:41:01 2003
Subject: A lesson from Plan 9
Message-ID: <Pine.LNX.4.44.0308081649590.18166-100000@maxroach.lanl.gov>

Eric's comments on the keeping the core clean bring Plan 9 to mind, 
especially as Plan 9 was the inspiration for both the original and new 
config tools. 

Plan 9 is broken into two trees, as follows. 

/sys/src/9/port
/sys/src/9/<architecture>

The 'port' code is that code which is non-platform-specific. The 
<architecture> code is of course platform-specific. You can actually think 
of 'port' as the "core", and the other tree as the specialization to a 
given platform. 

To a large degree, platform-specific code gets linked in statically as 
devices, defined in arrays of structures. These are accessed via 
indirection through structures. The platform code can of course make calls 
to the OS for services. 

I think this is what many people I talk to would like for linuxbios: the
ability to specialize the bios for specific platforms, e.g. x86 mainboards
with VGA or other ROMs, to allow card initialization (e.g. rom bios). 
Obviously this brings a degree of x86-specificity to that build of the 
bios, but I think we can keep it isolated from the core. 

I feel this specialization could be done in a clean way: 

/src/freebios/src/extensions/....


and with a new keyword in the config tool that makes the nature of the 
extension clear.

We need somehow to address the demand for very early VGA support in 
linuxbios. It's probably the highest-demand item right now.

ron



From agnew at cs.umd.edu  Fri Aug  8 19:38:01 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Fri Aug  8 19:38:01 2003
Subject: VGA BIOS init debate
Message-ID: <20030808195410.B15439-100000@www.missl.cs.umd.edu>

I want to throw these arguments into the debate:


I vote for the ELF payload. I would say that linking it in would be just
as good, except that if EFI ever does really become common, a lot of
these payloads would become useful to a larger user base. I do agree that
there would be some redundancy in code, but I also believe the build
process would be simplified (rom-o-matic certainly seems more feasible
without so many options) and those new to LinuxBIOS would be able
to grasp how it all links together easier.

Right now, the split in idealogy has put us in quite the pickle. Linuxbios
has two ways to tftp boot, three ways to polled ide boot, two ways to get
a vga rom up and running.. If things are still even linked in to
freebios2, there's a lot of confusion. Do different boot methods use elf
payloads or are they compiled in? Well that would depend on which one.
I too would like the Linux kernel to solve all of these problems, I hope
I've never created the impression that I wish otherwise. But the chunk of
mailing list traffic from embedded enthusiasts is getting still larger,
nothing's really changed in ROM size since the Great Payload Debates of
2001, and Linux has only gotten bigger (though there's hope..).

- Adam Agnew

On Fri, 8 Aug 2003, ron minnich wrote:

> folks, any opinions expressed on this VGA BIOS discussion would be
> welcome.
>
> VGA BIOS in linuxbios, or in an ELF payload? What's your bet?
>
> ron
>
>






From linuxbios at xdr.com  Fri Aug  8 22:11:01 2003
From: linuxbios at xdr.com (Dave Ashley)
Date: Fri Aug  8 22:11:01 2003
Subject: Datasheets for EPIA-M10000
Message-ID: <200308090227.h792RPcP004907@xdr.com>

>Can anyone help with info on VIA CLE266, VT8235, VT6103, VT1616, VT1662, VT6307S, anything would be appreciated .... or have people just used the linux kernel source for their information???
>James.

VIA doesn't give out datasheets easily, for the most part they are available
only under NDA, probably so they don't have to be fighting the US patent
insanity all the time. Look at viarena.com, more information is there,
and try to convince VIA reps you're a serious developer.

Contrast that with this page:
http://www.national.com/pf/SC/SC1200.html

Anyone can anonymously download the geode SC1200 datasheet without any
hassle at all, and the doc is accurate and complete. Sometimes VIA's
datasheets raise more questions than they answer...

-Dave 



From niki.waibel at newlogic.com  Sat Aug  9 04:15:00 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Sat Aug  9 04:15:00 2003
Subject: DoC on EPIA-M with DIP2PLCC adapter -- instead of 256kbyte bios chip
In-Reply-To: <Pine.LNX.4.44.0308080933280.18166-100000@maxroach.lanl.gov>
Message-ID: <200308090832.h798W4H3025408@enterprise2.newlogic.at>

>> does that 2001 fit into a DIP socket?
> 
> DIP32

on the m-systems website:
http://www.m-sys.com/Content/Products/DiskOnChip.asp
there is only the DiskOnChip 2000 which is in a
DIP socket.
are you really sure that that type would not work
in the bios?

is it the 8mbyte DoC millennium (not millennium plus)
which would work (MD2800-D08) and which you call 2001?

could you explain why a DiskOnChip2000 (ie MD-2202-D128-V3)
cannot be used as bios chip?

niki


From rogerxxmaillist at speakeasy.net  Sat Aug  9 08:33:01 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Sat Aug  9 08:33:01 2003
Subject: DoC on EPIA-M with DIP2PLCC adapter -- instead of 256kbyte
	bios chip
In-Reply-To: <200308090832.h798W4H3025408@enterprise2.newlogic.at>
References: <200308090832.h798W4H3025408@enterprise2.newlogic.at>
Message-ID: <1060433106.14310.6.camel@localhost3.localdomain>

On Sat, 2003-08-09 at 01:32, Niki Waibel wrote:
> >> does that 2001 fit into a DIP socket?
> > 
> > DIP32
> 
> on the m-systems website:
> http://www.m-sys.com/Content/Products/DiskOnChip.asp
> there is only the DiskOnChip 2000 which is in a
> DIP socket.
> are you really sure that that type would not work
> in the bios?
> 
> is it the 8mbyte DoC millennium (not millennium plus)
> which would work (MD2800-D08) and which you call 2001?
> 
> could you explain why a DiskOnChip2000 (ie MD-2202-D128-V3)
> cannot be used as bios chip?
> 
> niki

DOC Millennium 8MB Module MD2802-D08 
EMJ America Inc
http://www.emj.com/
Part No. 1MML8MB

32 Pin w/ handle ARIES Zif socket (~$14 ea)
www.mouser.com
Stock No. 535-32-6554-11
Bin No. 94-68G1

DIP-32 256K X8 120NS Atmel Flash Memory (~$4 ea)
Stock No. 556-AT29C02012PC
Bin No. F0-59J8

Mouser, EMJ, Digikey all have online catalogs (in pdf format) and can be
easily searched via www.google.com (i prefer to use mouser.com)

-- 

Roger
http://www.eskimo.com/~roger/index.html



From ts1 at tsn.or.jp  Sat Aug  9 13:01:01 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Sat Aug  9 13:01:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <m3he4sgc7f.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0308081019370.18166-100000@maxroach.lanl.gov> <m3he4srt2s.fsf@maxwell.lnxi.com> <20030808192552.GA13131@tsn.or.jp> <m3he4sgc7f.fsf@maxwell.lnxi.com>
Message-ID: <20030809171729.GA25206@tsn.or.jp>

On Fri, Aug 08, 2003 at 01:51:16PM -0600, Eric W. Biederman wrote:
> > Of couse the DOS applications like EMM386 and things like DPMI 
> > won't run with a BIOS which does it's job in 32-bit.
> > And nowadays nobody uses those application.
> 
> Dosemu which uses DPMI still has a surprising number of users.

I thought dosemu emulates all the BIOS calls itself, and never
calls the underlying real BIOS.

> I guess my preference would be to make a 16bit clean core that supports
> option ROMS and those options roms could be like etherboot and do the extension.

In my opinion, 16-bit code is never clean. :)
(except the case everything is in 64KB)

Even if using GCC with .code16gcc to make a realmode code,
the compiler knows nothing about segmentation, 64KB barrier...
so we have to take care of segments in all over the code.
"Flat real mode" (setting segment limits to 4G) is out of question
because it will not run in vm86 either.

--
Takeshi


From linuxbios at techfreakz.net  Sat Aug  9 13:09:59 2003
From: linuxbios at techfreakz.net (Alex Scarbro)
Date: Sat Aug  9 13:09:59 2003
Subject: K7SEM support broken in freebios?
In-Reply-To: <200308021728.33550.thomas@wehrspann.de>
Message-ID: <200389182014.239953@techfreakz>

An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20030809/22d46b0c/attachment.html>

From ts1 at tsn.or.jp  Sat Aug  9 13:24:01 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Sat Aug  9 13:24:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308081512130.18166-100000@maxroach.lanl.gov>
References: <m3oeyzewkh.fsf@maxwell.lnxi.com> <Pine.LNX.4.44.0308081512130.18166-100000@maxroach.lanl.gov>
Message-ID: <20030809174051.GB25206@tsn.or.jp>

On Fri, Aug 08, 2003 at 03:23:42PM -0600, ron minnich wrote:
> Bochs is neat, but not simple. Maybe, however, we can make it simpler. I
> really don't want to write x86 asm at this point, however. If I do this I
> want to do it by building on the VGA BIOS stuff I wrote for 1.0.

That's what I'm intersted in doing.
Also I felt that doing this in LinuxBIOS core could be wrong direction
for the project, so I posted the first question.
I think Ron's src/extension idea makes a lot of sense.

> The VGA BIOS code in 1.0 has proven to be pretty easy to use for people,
> it's 32-bit code, and it's pretty easy to fix. Also, like the rest of 
> LinuxBIOS, it has a very small assembly bit and the rest is C. 

Yes, that is why I like this code. This can be easily and cleanly
extended, unlike Bochs BIOS.
As Eric pointed out, this approach has drawbacks, with regard to
full compatibility, it still has many advantages over the way
Bochs doing.
--
Takeshi


From ts1 at tsn.or.jp  Sat Aug  9 13:38:00 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Sat Aug  9 13:38:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308081428370.18166-100000@maxroach.lanl.gov>
References: <3174569B9743D511922F00A0C943142302FCA5C0@TYANWEB> <Pine.LNX.4.44.0308081428370.18166-100000@maxroach.lanl.gov>
Message-ID: <20030809175434.GC25206@tsn.or.jp>

On Fri, Aug 08, 2003 at 02:29:08PM -0600, ron minnich wrote:
> On Fri, 8 Aug 2003, YhLu wrote:
> 
> > Where is the VGA BIOS support? Still in freebios?
> 
> it's the one that SONE used in linuxbios, he can describe again how it is 
> enabled. We are using it here for NVidia cards.

I don't know about freebios2 tree, but in freebios tree there is 
some code to call POST routine of external VGA BIOS,
and support for some realmode BIOS call (like PCI BIOS) to
help the VGA BIOS run happily.

It is activated by config like below:

    option CONFIG_VGABIOS=1
    option CONFIG_REALMODE_IDT=1
    dir src/bioscall
    option CONFIG_PCIBIOS=1
    option VGABIOS_START=0xfffe0000

The last line is needed when you use the VGA BIOS image from 
the Flash (typically for onboard VGA).

If this option is not defined, VGA card's ROM is used
(this is what Ron's original code does).

Ron: my last fix to pcibios.c is in the tree and working ok. Thanks.

--
Takeshi


From stepan at suse.de  Sat Aug  9 14:10:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Sat Aug  9 14:10:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030809174051.GB25206@tsn.or.jp>; from ts1@tsn.or.jp on Sun, Aug 10, 2003 at 02:40:51AM +0900
References: <m3oeyzewkh.fsf@maxwell.lnxi.com> <Pine.LNX.4.44.0308081512130.18166-100000@maxroach.lanl.gov> <20030809174051.GB25206@tsn.or.jp>
Message-ID: <20030809202655.A14721@suse.de>

* SONE Takeshi <ts1 at tsn.or.jp> [030809 19:40]:
> On Fri, Aug 08, 2003 at 03:23:42PM -0600, ron minnich wrote:
> > Bochs is neat, but not simple. Maybe, however, we can make it simpler. I
> > really don't want to write x86 asm at this point, however. If I do this I
> > want to do it by building on the VGA BIOS stuff I wrote for 1.0.
> 
> That's what I'm intersted in doing.
> Also I felt that doing this in LinuxBIOS core could be wrong direction
> for the project, so I posted the first question.
> I think Ron's src/extension idea makes a lot of sense.

going all the way to the end this could mean that the elf loader goes
to the extensions directory as well, reducing the LinuxBIOS kernel to 
three parts: 
* Assembler starter: switching to protected mode
* romcc code: initializing ram controller and starting 
  LinuxBIOS C payload
* gcc code: initializing static and dynamic devices so that
  they can be used by the extensions

Extensions could be "stackable" and configurable for certain
application goals:
* legacy emulation for VGA and SCSI init
* elf loader
* openbios kernel

My OpenBIOS multiboot kernel is currently 6.6k big, implementing all
forth primitives needed to build an Open Firmware implementation on top
of it. It includes a small console implementation for serial and vga.

The extensions idea could integrate this kernel sanely and even reduce 
the code as the interface to LinuxBIOS and the console code could be
dropped.

> > The VGA BIOS code in 1.0 has proven to be pretty easy to use for people,
> > it's 32-bit code, and it's pretty easy to fix. Also, like the rest of 
> > LinuxBIOS, it has a very small assembly bit and the rest is C. 
> 
> Yes, that is why I like this code. This can be easily and cleanly
> extended, unlike Bochs BIOS.
> As Eric pointed out, this approach has drawbacks, with regard to
> full compatibility, it still has many advantages over the way
> Bochs doing.

On the other hand, it has certain advantages as well, the code can
probably easier integrate an x86 emulation, like milo/srm do on alpha
and some free ARM firmware implementation does as well..

  Stefan



From stepan at suse.de  Sat Aug  9 14:22:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Sat Aug  9 14:22:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030809175434.GC25206@tsn.or.jp>; from ts1@tsn.or.jp on Sun, Aug 10, 2003 at 02:54:34AM +0900
References: <3174569B9743D511922F00A0C943142302FCA5C0@TYANWEB> <Pine.LNX.4.44.0308081428370.18166-100000@maxroach.lanl.gov> <20030809175434.GC25206@tsn.or.jp>
Message-ID: <20030809203843.B14721@suse.de>

* SONE Takeshi <ts1 at tsn.or.jp> [030809 19:54]:
> I don't know about freebios2 tree, but in freebios tree there is 
> some code to call POST routine of external VGA BIOS,
> and support for some realmode BIOS call (like PCI BIOS) to
> help the VGA BIOS run happily.
 
the code is currently only in the freebios 1.0 tree, since the freebios2
tree only includes the features that were used and tested during the PPC
and Opteron port to get rid of unneeded code. It might be a good idea to
get this code over into the freebios2 tree as an extension.

> It is activated by config like below:
> 
>     option CONFIG_VGABIOS=1
>     option CONFIG_REALMODE_IDT=1
>     dir src/bioscall
>     option CONFIG_PCIBIOS=1
>     option VGABIOS_START=0xfffe0000
 
> The last line is needed when you use the VGA BIOS image from 
> the Flash (typically for onboard VGA).
 
What's the meaning of the other config variables? Does it make sense
to automatically use REALMODE_IDT=1, when compiling this extension
(in spe) on an x86 box, maybe in favour of CONFIG_X86EMU=1 on non-x86
platforms? The new config method might allow to make this really
readable and understandable.

  Stefan



From thomas at wehrspann.de  Sat Aug  9 17:48:00 2003
From: thomas at wehrspann.de (Thomas Wehrspann)
Date: Sat Aug  9 17:48:00 2003
Subject: K7SEM support broken in freebios?
In-Reply-To: <200389182014.239953@techfreakz>
References: <200389182014.239953@techfreakz>
Message-ID: <200308092339.01327.thomas@wehrspann.de>

On Saturday 09 August 2003 19:20, Alex Scarbro wrote:
>   Thankyou for the patch, just about to apply it, but realised i don't know 
>what to apply it to.  I'm not familiar with how you guys name the freebios 
>tree.  Ie on the first line it refers to freebios.orig/src/cpu/k7/ then 
>freebios/src/cpu/k7 - do i need two copies of the freebios source tree? (one 
>CVS-downloaded tree left "untouched" and one copy of that tree with the 
>patch applied.  Perhaps it would be worth a little documentation on this 
>subject?  
>
just change to your freebios directory and
"patch -p1 < /path/to/patch.diff".

>Also, i'm planning to compile on the 2.4.7 Kernel (as per the K7SEM howto),  
>Is there now a more preferred kernel version?  
>
There are patches for 2.4.17 and/or 2.4.19. Look in your source tree (see 
howto)

>And finally, what distro of linux do you guys use for your compilation?  I 
>tried Suse 8.1, but that failed.  Now i'm unsing an aged Redhat 7.2.  Can i 
>use the new Suse 8.2 instead.  Thought id ask first rather than try it only 
>to fail.....again :-)
>
SuSE 8.0 works fine for me. 

Thomas


From min at hello.org  Sun Aug 10 02:08:01 2003
From: min at hello.org (Chung Ming)
Date: Sun Aug 10 02:08:01 2003
Subject: EPIA-ME6000
References: <00ba01c355b9$758ecf30$17f09b83@campus.tue.nl> <Pine.LNX.4.53.0307290900280.15334@gw.linespeed.net>
Message-ID: <008d01c355df$c3955e80$6601a8c0@MINXP>

I Believe VIA ME6000 uses VT8235 SouthBridge.

Ming.

----- Original Message ----- 
From: "Brian G. Rhodes" <bgr at gw.linespeed.net>
To: "Leon Woestenberg" <leon.woestenberg at gmx.net>
Cc: <linuxbios at clustermatic.org>
Sent: Tuesday, July 29, 2003 10:05 PM
Subject: Re: EPIA-ME6000


> That board has a VIA vt82c686b south on it?  I built linuxbios for a
> similar VIA board (endat) with an 8601 north and vt82c686b south.  That
> won't work with the epia or epia-m configs.  but you can go from the
> via/vt5426 config.  You are perhaps getting garbage serial output because
> you're setting up serial for the wrong superio.
>
> Have you figured out how to enable flash memory write?  I have two 686
> datasheets which seem to contradict one another on how it's done.  one
> appears like the 8231 south, and another alike the sis630.
>
> Brian G Rhodes
> bgr at linespeed.net
> brhodes at visualcircuits.com
> +1 612-741-1191
>
>
> On Tue, 29 Jul 2003, Leon Woestenberg wrote:
>
> > Hello,
> >
> > I have been fiddling with etherboot 5.0.10 and freebios(v1) from CVS
today
> > on a EPIA-ME6000 platform.
> >
> > This is the unit with a low speed clock (500MHz?) Eden C3 processor
> > which copes with passive cooling. I think it is EPIA-M9000 alike
otherwise.
> >
> > Using a hardware flash programmer, I first copied the VIA BIOS from the
> > STT39SF040A (256Kbytes) into a STMicro 29F040B (512Kbytes) device.
> >
> > That only worked after I copied the BIOS into the upper half of the
larger
> > device (from 0x40000 to 0x7FFFF). So I recon the highest address line
> > is not connected on the board and so the FlashROM sees high-impedance
> > on its most significant address line (and addresses the upper half
always)>
> >
> > I followed the HOWTO/EPIA document to the letter (without the VGA
> > BIOS at first) booting linuxbios w/ via-rhine.elf payload.
> >
> > When booting, I merely got garbled output on the serial port.
> >
> > I have double checked that the config file reads 115200 and that my
> > terminal reads 115200 8N1. (The 115200 is assembly hardcoded in
> > the vt82c686 superio code -- does it cope with my different processor
> > speed? I do not have the datasheet (yet?).
> >
> > After that, I have tried all speeds on the terminal without result.
> >
> > Is the EPIA-ME6000 (aka M6000) already reported to work here,
> > or are you guys'n'gals refering to the M9000 and M10000 alone?
> >
> > How can I help?
> >
> > Regards,
> >
> > Leon.
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From lisamstout at yahoo.com  Sun Aug 10 02:08:57 2003
From: lisamstout at yahoo.com (lisa stout)
Date: Sun Aug 10 02:08:57 2003
Subject: Questions to the experts
Message-ID: <20030730190256.68672.qmail@web10910.mail.yahoo.com>

Hi all- I am trying to get myself up to speed on server management in a Linux environment and in my research I keep running across your e-mail list serve. I have been doing a lot of reading and many times the information I am reading is contradictory. I am looking for some definitive answers on the following:
 
1) Does Linux support IPMI? If so how?
2) Why is their a preference for using Console Port Servers in Linux and Unix, while Windows tends to be KVM?  Is their a technical reason or is it simply 1) cost 2) text based management preference through CLI?
3) I read an article on Linux where in the serial section they indicate: "Linux supports ordinary telephone modems only if they work through a serial port (although the port may be built into the modem). Is this true? if it is true and someone wants to modem in then it must be done serially? 
 
Thanks in advance. 
 
Lisa


---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20030810/1a3e57f5/attachment.html>

From mschuele at zscom.de  Sun Aug 10 02:09:00 2003
From: mschuele at zscom.de (Michael Schuele)
Date: Sun Aug 10 02:09:00 2003
Subject: Gigabyte BX2000
Message-ID: <20030801192208.18BA617D36@michelangelo.mschuele.de>

Hi,

I've got a Gigabyte BX2000 mainboard with an Intel BX chipset.
It has a so called "dual bios" which means that there is a backup bios
from which you can recover your "main" bios if flashing failed or something
other happend to it. 
Do you know if I can use LinuxBios on this board or should I try to get
an other board?

Which kernel patch do I have to use? I can't find one in src/kernel-patches..
I downloaded the kernel from cwlinux.com, is this already patched or what 
is it for?

thx,

Michael


From David.Barr at student.oc.edu  Sun Aug 10 02:09:04 2003
From: David.Barr at student.oc.edu (David Barr)
Date: Sun Aug 10 02:09:04 2003
Subject: smp, newconfig, hdama
Message-ID: <FC97984414D48E42B6B70CA3CAE07C78B15BD9@mail.oc.edu>

Ron, is the T23 running linuxbios?  When I joined the list (though I 

later left) and was reading back-issues, I vaguely remember you as 

having said you  couldn't get it on your lappy due to IBM's chipset 

detail stinginess; has any/all of that changed, or am I perhaps 

hallucinating?

 

I have access to a fairly largish supply of A22-M series, and as 

president of my local student ACM chapter (named Beta Iota Tau, 

nerdily enough) am desparately searching for more projects for the 

upcoming  semester/year.

 

Short Summary:  Does linuxBios work on your T23?  If so, can I have 

all the juicy (or at least some moderately damp) details?

 

TIA,

-David H. Barr.

 

>thank you, that did it. I now have an HDAMA running as a 2-cpu bproc

> slave

>node, in 32-bit mode, with an IBM T23 laptop as the master.

 

>ron



From ijpraveen1 at yahoo.com  Sun Aug 10 02:17:01 2003
From: ijpraveen1 at yahoo.com (John Praveen)
Date: Sun Aug 10 02:17:01 2003
Subject: Preliminary doubts
Message-ID: <20030810063349.28838.qmail@web41706.mail.yahoo.com>

Hi,
                 I have the custom board (geode
sc1200) with some external peripherals.  I will have
to have my BIOS program, linux kernel and specific
application program in my Flash memory. I have hard
disk only for storing files.
 
                  My Flash memory is of 32 Mbits and
SDRAM 32MBytes. 
 
                  I want to use LinuxBios. I build it
for nano mainboard. But still I have many doubts. In
normal BIOS, we will say the bios program to load the
bootloader from hard disk into location 0000:7C00. 
 
                 What part of the program in Linuxbios
will bring my linux kernel image from Flash into
SDRAM?
 
                 Is any options or something to be
included in the configuration file to say to boot from
Flash memory?
 
                 In my embedded device the Flash
memory is mapped to physical address 00000h to
3FFFFFh. So at what location should i place the
linuxbios romimage and linux kernel image in my Flash
memory? 
        
                Where shall my application program be
placed in Flash? I hope I should have a filesystem. Is
the MTD meant for the filesystem?
  
Please help me.

Thanks in advance.
 
Regards,
John.
      

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com


From linuxbios at smashed.demon.co.uk  Sun Aug 10 11:58:01 2003
From: linuxbios at smashed.demon.co.uk (James Weir)
Date: Sun Aug 10 11:58:01 2003
Subject: help can't get it working on epia-m10000
Message-ID: <1060532050.4851.1.camel@Quadra.localdomain>

I have included below the output from the console when attempting to
boot linuxbios, it always seems to just hang at this point... any
pointers... I am on an EPIA-M10000 board.

Thanks,

James.

LinuxBIOS-1.0.0 Sun Aug 10 17:10:40 BST 2003 starting...
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.0.0 Sun Aug 10 17:10:40 BST 2003 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Scanning PCI bus...PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/3123]
PCI: 00:01.0 [1106/b091]
PCI: 00:0d.0 [1106/3044]
PCI: 00:10.0 [1106/3038]
PCI: 00:10.1 [1106/3038]
PCI: 00:10.2 [1106/3038]
PCI: 00:10.3 [1106/3104]
PCI: 00:11.0 [1106/3177]
PCI: 00:11.1 [1106/0571]
PCI: 00:11.5 [1106/3059]
PCI: 00:12.0 [1106/3065]
PCI: pci_scan_bus for bus 1
PCI: pci_scan_bus returning with max=01
PCI: pci_scan_bus returning with max=01
done
Allocating PCI resources...
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
ASSIGN RESOURCES, bus 0
PCI: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io
PCI: 00:01.0 24 <- [0xfeb00000 - 0xfeafffff] bus 1 prefmem
PCI: 00:01.0 20 <- [0xfeb00000 - 0xfeafffff] bus 1 mem
PCI: 00:0d.0 10 <- [0xfeb00000 - 0xfeb007ff] mem
PCI: 00:0d.0 14 <- [0x00001800 - 0x0000187f] io
PCI: 00:10.0 20 <- [0x00001880 - 0x0000189f] io
PCI: 00:10.1 20 <- [0x000018a0 - 0x000018bf] io
PCI: 00:10.2 20 <- [0x000018c0 - 0x000018df] io
PCI: 00:10.3 10 <- [0xfeb01000 - 0xfeb010ff] mem
PCI: 00:11.1 20 <- [0x000018e0 - 0x000018ef] io
PCI: 00:11.5 10 <- [0x00001000 - 0x000010ff] io
PCI: 00:12.0 10 <- [0x00001400 - 0x000014ff] io
PCI: 00:12.0 14 <- [0xfeb02000 - 0xfeb020ff] mem
ASSIGNED RESOURCES, bus 0
done.
Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06
PCI: 00:01.0 cmd <- 07
PCI: 00:0d.0 cmd <- 83
PCI: 00:10.0 cmd <- 01
PCI: 00:10.1 cmd <- 01
PCI: 00:10.2 cmd <- 01
PCI: 00:10.3 cmd <- 02
PCI: 00:11.0 cmd <- 87
PCI: 00:11.1 cmd <- 07
PCI: 00:11.5 cmd <- 01
PCI: 00:12.0 cmd <- 83
done.
Initializing PCI devices...
PCI devices initialized
totalram: 127M
Initializing CPU #0
Enabling cache...
Setting fixed MTRRs(0-88) type: UC



From aip at cwlinux.com  Sun Aug 10 12:50:00 2003
From: aip at cwlinux.com (Andrew Ip)
Date: Sun Aug 10 12:50:00 2003
Subject: help can't get it working on epia-m10000
In-Reply-To: <1060532050.4851.1.camel@Quadra.localdomain>; from James Weir on Sun, Aug 10, 2003 at 05:14:10PM +0100
References: <1060532050.4851.1.camel@Quadra.localdomain>
Message-ID: <20030811010708.A28182@mail.cwlinux.com>

Hi James,

	What kind of memory are you using?

-Andrew

On Sun, Aug 10, 2003 at 05:14:10PM +0100, James Weir wrote:
> I have included below the output from the console when attempting to
> boot linuxbios, it always seems to just hang at this point... any
> pointers... I am on an EPIA-M10000 board.
> 
> Thanks,
> 
> James.
> 
> LinuxBIOS-1.0.0 Sun Aug 10 17:10:40 BST 2003 starting...
> Copying LinuxBIOS to ram.
> Jumping to LinuxBIOS.
> LinuxBIOS-1.0.0 Sun Aug 10 17:10:40 BST 2003 booting...
> Finding PCI configuration type.
> PCI: Using configuration type 1
> Scanning PCI bus...PCI: pci_scan_bus for bus 0
> PCI: 00:00.0 [1106/3123]
> PCI: 00:01.0 [1106/b091]
> PCI: 00:0d.0 [1106/3044]
> PCI: 00:10.0 [1106/3038]
> PCI: 00:10.1 [1106/3038]
> PCI: 00:10.2 [1106/3038]
> PCI: 00:10.3 [1106/3104]
> PCI: 00:11.0 [1106/3177]
> PCI: 00:11.1 [1106/0571]
> PCI: 00:11.5 [1106/3059]
> PCI: 00:12.0 [1106/3065]
> PCI: pci_scan_bus for bus 1
> PCI: pci_scan_bus returning with max=01
> PCI: pci_scan_bus returning with max=01
> done
> Allocating PCI resources...
> PCI: 00:00.0 register 10(00000008), read-only ignoring it
> PCI: 00:00.0 register 10(00000008), read-only ignoring it
> PCI: 00:00.0 register 10(00000008), read-only ignoring it
> PCI: 00:00.0 register 10(00000008), read-only ignoring it
> ASSIGN RESOURCES, bus 0
> PCI: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io
> PCI: 00:01.0 24 <- [0xfeb00000 - 0xfeafffff] bus 1 prefmem
> PCI: 00:01.0 20 <- [0xfeb00000 - 0xfeafffff] bus 1 mem
> PCI: 00:0d.0 10 <- [0xfeb00000 - 0xfeb007ff] mem
> PCI: 00:0d.0 14 <- [0x00001800 - 0x0000187f] io
> PCI: 00:10.0 20 <- [0x00001880 - 0x0000189f] io
> PCI: 00:10.1 20 <- [0x000018a0 - 0x000018bf] io
> PCI: 00:10.2 20 <- [0x000018c0 - 0x000018df] io
> PCI: 00:10.3 10 <- [0xfeb01000 - 0xfeb010ff] mem
> PCI: 00:11.1 20 <- [0x000018e0 - 0x000018ef] io
> PCI: 00:11.5 10 <- [0x00001000 - 0x000010ff] io
> PCI: 00:12.0 10 <- [0x00001400 - 0x000014ff] io
> PCI: 00:12.0 14 <- [0xfeb02000 - 0xfeb020ff] mem
> ASSIGNED RESOURCES, bus 0
> done.
> Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06
> PCI: 00:01.0 cmd <- 07
> PCI: 00:0d.0 cmd <- 83
> PCI: 00:10.0 cmd <- 01
> PCI: 00:10.1 cmd <- 01
> PCI: 00:10.2 cmd <- 01
> PCI: 00:10.3 cmd <- 02
> PCI: 00:11.0 cmd <- 87
> PCI: 00:11.1 cmd <- 07
> PCI: 00:11.5 cmd <- 01
> PCI: 00:12.0 cmd <- 83
> done.
> Initializing PCI devices...
> PCI devices initialized
> totalram: 127M
> Initializing CPU #0
> Enabling cache...
> Setting fixed MTRRs(0-88) type: UC
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios

-- 
Andrew Ip
Email:  aip at cwlinux.com
Tel:    (852) 2542 2046
Fax:    (852) 2542 2036
Mobile: (852) 9201 9866

Cwlinux Limited
Unit 202B 2/F Lai Cheong Factory Building,
479-479A Castle Peak Road,
Lai Chi Kok, Kowloon,
Hong Kong.

For public pgp key, please obtain it from http://www.keyserver.net/en.


From linuxbios at smashed.demon.co.uk  Sun Aug 10 12:52:00 2003
From: linuxbios at smashed.demon.co.uk (James Weir)
Date: Sun Aug 10 12:52:00 2003
Subject: Problem with EPIA-M10000
Message-ID: <000001c35f61$fdd4e440$0b00000a@quadra001>

I have narrowed the problem to a hang at the disable_cache() call in
mtrr.c file in cpu/p6 directory of the src tree.  It is also worth
noting that the board has 256Mb installed not 127Mb as it suggests in
debug output ( see previous post ).

 

James :-)

 

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

From linuxbios at smashed.demon.co.uk  Sun Aug 10 12:52:30 2003
From: linuxbios at smashed.demon.co.uk (James Weir)
Date: Sun Aug 10 12:52:30 2003
Subject: help can't get it working on epia-m10000
In-Reply-To: <20030811010708.A28182@mail.cwlinux.com>
Message-ID: <000501c35f62$19530210$0b00000a@quadra001>

Andrew,

	It is DDR 266 as I remember.... I will double check..

		James.

-----Original Message-----
From: Andrew Ip [mailto:aip at cwlinux.com] 
Sent: 10 August 2003 18:07
To: James Weir
Cc: linuxbios at clustermatic.org
Subject: Re: help can't get it working on epia-m10000

Hi James,

	What kind of memory are you using?

-Andrew

On Sun, Aug 10, 2003 at 05:14:10PM +0100, James Weir wrote:
> I have included below the output from the console when attempting to
> boot linuxbios, it always seems to just hang at this point... any
> pointers... I am on an EPIA-M10000 board.
> 
> Thanks,
> 
> James.
> 
> LinuxBIOS-1.0.0 Sun Aug 10 17:10:40 BST 2003 starting...
> Copying LinuxBIOS to ram.
> Jumping to LinuxBIOS.
> LinuxBIOS-1.0.0 Sun Aug 10 17:10:40 BST 2003 booting...
> Finding PCI configuration type.
> PCI: Using configuration type 1
> Scanning PCI bus...PCI: pci_scan_bus for bus 0
> PCI: 00:00.0 [1106/3123]
> PCI: 00:01.0 [1106/b091]
> PCI: 00:0d.0 [1106/3044]
> PCI: 00:10.0 [1106/3038]
> PCI: 00:10.1 [1106/3038]
> PCI: 00:10.2 [1106/3038]
> PCI: 00:10.3 [1106/3104]
> PCI: 00:11.0 [1106/3177]
> PCI: 00:11.1 [1106/0571]
> PCI: 00:11.5 [1106/3059]
> PCI: 00:12.0 [1106/3065]
> PCI: pci_scan_bus for bus 1
> PCI: pci_scan_bus returning with max=01
> PCI: pci_scan_bus returning with max=01
> done
> Allocating PCI resources...
> PCI: 00:00.0 register 10(00000008), read-only ignoring it
> PCI: 00:00.0 register 10(00000008), read-only ignoring it
> PCI: 00:00.0 register 10(00000008), read-only ignoring it
> PCI: 00:00.0 register 10(00000008), read-only ignoring it
> ASSIGN RESOURCES, bus 0
> PCI: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io
> PCI: 00:01.0 24 <- [0xfeb00000 - 0xfeafffff] bus 1 prefmem
> PCI: 00:01.0 20 <- [0xfeb00000 - 0xfeafffff] bus 1 mem
> PCI: 00:0d.0 10 <- [0xfeb00000 - 0xfeb007ff] mem
> PCI: 00:0d.0 14 <- [0x00001800 - 0x0000187f] io
> PCI: 00:10.0 20 <- [0x00001880 - 0x0000189f] io
> PCI: 00:10.1 20 <- [0x000018a0 - 0x000018bf] io
> PCI: 00:10.2 20 <- [0x000018c0 - 0x000018df] io
> PCI: 00:10.3 10 <- [0xfeb01000 - 0xfeb010ff] mem
> PCI: 00:11.1 20 <- [0x000018e0 - 0x000018ef] io
> PCI: 00:11.5 10 <- [0x00001000 - 0x000010ff] io
> PCI: 00:12.0 10 <- [0x00001400 - 0x000014ff] io
> PCI: 00:12.0 14 <- [0xfeb02000 - 0xfeb020ff] mem
> ASSIGNED RESOURCES, bus 0
> done.
> Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06
> PCI: 00:01.0 cmd <- 07
> PCI: 00:0d.0 cmd <- 83
> PCI: 00:10.0 cmd <- 01
> PCI: 00:10.1 cmd <- 01
> PCI: 00:10.2 cmd <- 01
> PCI: 00:10.3 cmd <- 02
> PCI: 00:11.0 cmd <- 87
> PCI: 00:11.1 cmd <- 07
> PCI: 00:11.5 cmd <- 01
> PCI: 00:12.0 cmd <- 83
> done.
> Initializing PCI devices...
> PCI devices initialized
> totalram: 127M
> Initializing CPU #0
> Enabling cache...
> Setting fixed MTRRs(0-88) type: UC
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios

-- 
Andrew Ip
Email:  aip at cwlinux.com
Tel:    (852) 2542 2046
Fax:    (852) 2542 2036
Mobile: (852) 9201 9866

Cwlinux Limited
Unit 202B 2/F Lai Cheong Factory Building,
479-479A Castle Peak Road,
Lai Chi Kok, Kowloon,
Hong Kong.

For public pgp key, please obtain it from http://www.keyserver.net/en.



From stepan at suse.de  Sun Aug 10 14:44:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Sun Aug 10 14:44:00 2003
Subject: help can't get it working on epia-m10000
In-Reply-To: <1060532050.4851.1.camel@Quadra.localdomain>; from linuxbios@smashed.demon.co.uk on Sun, Aug 10, 2003 at 05:14:10PM +0100
References: <1060532050.4851.1.camel@Quadra.localdomain>
Message-ID: <20030810210041.A22214@suse.de>

* James Weir <linuxbios at smashed.demon.co.uk> [030810 18:14]:
> I have included below the output from the console when attempting to
> boot linuxbios, it always seems to just hang at this point... any
> pointers... I am on an EPIA-M10000 board.


> Initializing PCI devices...
> PCI devices initialized
> totalram: 127M
> Initializing CPU #0
> Enabling cache...
> Setting fixed MTRRs(0-88) type: UC
 
I'm having the very same problem. You could try a different DDR Ram
module. The Epia-M Port does not do a complete SPD-based setup of the
ram controller yet

Stefan
  
-- 
Architecture Team
    SuSE Linux AG


From ts1 at tsn.or.jp  Sun Aug 10 15:15:00 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Sun Aug 10 15:15:00 2003
Subject: Preliminary doubts
In-Reply-To: <20030810063349.28838.qmail@web41706.mail.yahoo.com>
References: <20030810063349.28838.qmail@web41706.mail.yahoo.com>
Message-ID: <20030810193141.GA17548@tsn.or.jp>

Although luck of documentation is the problem the project faces,
the source and the list archive are always open to people.
If you investigate them yourself first, then ask,
you will get more helpful response.

On Sat, Aug 09, 2003 at 11:33:48PM -0700, John Praveen wrote:
>                  What part of the program in Linuxbios
> will bring my linux kernel image from Flash into
> SDRAM?

freebios/src/lib/elfboot.c

There is also a old linux-only loader, linuxbiosmain.
"grep -r" is your friend.

>                  Is any options or something to be
> included in the configuration file to say to boot from
> Flash memory?

USE_GENERIC_ROM 

>                  In my embedded device the Flash
> memory is mapped to physical address 00000h to
> 3FFFFFh. So at what location should i place the
> linuxbios romimage and linux kernel image in my Flash
> memory? 

I have my doubt here.
AFAIK, every x86 system has its ROM at the top of
address space (eg. if ROM is 256K, it's at 0xfffc0000 = 4G-256K),
since x86 starts execution at last 16 byte of address space (0xfffffff0).

Does your board have another ROM at here?
Or the flash is shadowed/aliased to here?

Also, if the bottom 4MB is ROM and it can't be remapped,
you will have to modify the kernel as well as LinuxBIOS.
Convenional x86 systems has 640KB of RAM
at bottom (from address 0), then 384KB of hole for legacy BIOS and I/O,
then rest of RAM from address 1M.
x86 port of Linux and LinuxBIOS is written for such system.

>                 Where shall my application program be
> placed in Flash? I hope I should have a filesystem. Is
> the MTD meant for the filesystem?

I'm not sure but if your flash will be used for BIOS, you most certainly 
have to use it as a raw storage.
You can put the LinuxBIOS, Linux kernel, and initrd there.
Your application code will be in the initrd.

--
Takeshi


From hansolofalcon at worldnet.att.net  Sun Aug 10 15:21:01 2003
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Sun Aug 10 15:21:01 2003
Subject: Preliminary doubts
In-Reply-To: <20030810193141.GA17548@tsn.or.jp>
Message-ID: <000201c35f77$10002de0$0100a8c0@who5>

Hello from Gregg C Levine
Are we discussing the strangeness behind the Geode here? If I remember
correctly, everything about that device is documented. Even the boards
that NSC developed for us to try out, before committing to a bigger
board were documented. About the only thing that wasn't, were the
binary only drivers, and loaders, that they supplied. They did give
use instructions, but that was all. As our correspondent in Japan
says, investigate the source, the lists, everything. When in doubt
ask. So far you're heading in the right direction with this. 
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of SONE Takeshi
> Sent: Sunday, August 10, 2003 3:32 PM
> To: John Praveen
> Cc: linuxbios at clustermatic.org
> Subject: Re: Preliminary doubts
> 
> Although luck of documentation is the problem the project faces,
> the source and the list archive are always open to people.
> If you investigate them yourself first, then ask,
> you will get more helpful response.
> 
> On Sat, Aug 09, 2003 at 11:33:48PM -0700, John Praveen wrote:
> >                  What part of the program in Linuxbios
> > will bring my linux kernel image from Flash into
> > SDRAM?
> 
> freebios/src/lib/elfboot.c
> 
> There is also a old linux-only loader, linuxbiosmain.
> "grep -r" is your friend.
> 
> >                  Is any options or something to be
> > included in the configuration file to say to boot from
> > Flash memory?
> 
> USE_GENERIC_ROM
> 
> >                  In my embedded device the Flash
> > memory is mapped to physical address 00000h to
> > 3FFFFFh. So at what location should i place the
> > linuxbios romimage and linux kernel image in my Flash
> > memory?
> 
> I have my doubt here.
> AFAIK, every x86 system has its ROM at the top of
> address space (eg. if ROM is 256K, it's at 0xfffc0000 = 4G-256K),
> since x86 starts execution at last 16 byte of address space
(0xfffffff0).
> 
> Does your board have another ROM at here?
> Or the flash is shadowed/aliased to here?
> 
> Also, if the bottom 4MB is ROM and it can't be remapped,
> you will have to modify the kernel as well as LinuxBIOS.
> Convenional x86 systems has 640KB of RAM
> at bottom (from address 0), then 384KB of hole for legacy BIOS and
I/O,
> then rest of RAM from address 1M.
> x86 port of Linux and LinuxBIOS is written for such system.
> 
> >                 Where shall my application program be
> > placed in Flash? I hope I should have a filesystem. Is
> > the MTD meant for the filesystem?
> 
> I'm not sure but if your flash will be used for BIOS, you most
certainly
> have to use it as a raw storage.
> You can put the LinuxBIOS, Linux kernel, and initrd there.
> Your application code will be in the initrd.
> 
> --
> Takeshi
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From ts1 at tsn.or.jp  Sun Aug 10 15:41:00 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Sun Aug 10 15:41:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030809202655.A14721@suse.de>
References: <m3oeyzewkh.fsf@maxwell.lnxi.com> <Pine.LNX.4.44.0308081512130.18166-100000@maxroach.lanl.gov> <20030809174051.GB25206@tsn.or.jp> <20030809202655.A14721@suse.de>
Message-ID: <20030810195802.GB17548@tsn.or.jp>

On Sat, Aug 09, 2003 at 08:26:55PM +0200, Stefan Reinauer wrote:
> Extensions could be "stackable" and configurable for certain
> application goals:
> * legacy emulation for VGA and SCSI init
> * elf loader
> * openbios kernel

Something like splash image support could be in the extension.
I have one for VESA SVGA but it's a too strange thing to be in
the core. I know supercomputer guys will hate it, but I believe 
some kinds of embedded systems will need it. It will be displayed
ealier than disk spin up.

I also developed a standalone bootloader, by putting together the
IDE driver from Etherboot 5.1 and filesystem code from GRUB,
with keyboard (as well as serial) support and a simple line input
routine to boot arbitrary ELF files in the filesystem of disk.
It's an ELF image for now, but could be ported to LinuxBIOS,
then I can save space for printk etc.

> On the other hand, it has certain advantages as well, the code can
> probably easier integrate an x86 emulation, like milo/srm do on alpha
> and some free ARM firmware implementation does as well..

I'm totally ignorant about non-x86 architecture, but it sounds cool.

--
Takeshi


From rminnich at lanl.gov  Sun Aug 10 19:43:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sun Aug 10 19:43:01 2003
Subject: Questions to the experts
In-Reply-To: <20030730190256.68672.qmail@web10910.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0308101757450.20943-100000@maxroach.lanl.gov>

On Wed, 30 Jul 2003, lisa stout wrote:

> 1) Does Linux support IPMI? If so how?

sure. 

I don't know where the tools are. 

> 2) Why is their a preference for using Console Port Servers in Linux and
> Unix, while Windows tends to be KVM?  

Because windows systems can't be managed well any other way. We don't 
actually use Console Port servers for day-to-day, we have found they are 
unusable in clusters with many nodes. Real OSes are manageable over a 
network.



>  3) I read an article on Linux where in the serial section they
> indicate: "Linux supports ordinary telephone modems only if they work
> through a serial port (although the port may be built into the modem).
> Is this true? if it is true and someone wants to modem in then it must
> be done serially?

no, stop reading the rag that wrote that, they are wrong.

ron



From rminnich at lanl.gov  Sun Aug 10 19:45:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sun Aug 10 19:45:01 2003
Subject: smp, newconfig, hdama
In-Reply-To: <FC97984414D48E42B6B70CA3CAE07C78B15BD9@mail.oc.edu>
Message-ID: <Pine.LNX.4.44.0308101800220.20943-100000@maxroach.lanl.gov>

On Tue, 5 Aug 2003, David Barr wrote:

> Ron, is the T23 running linuxbios?  When I joined the list (though I 
> 
> later left) and was reading back-issues, I vaguely remember you as 
> 
> having said you  couldn't get it on your lappy due to IBM's chipset 
> 
> detail stinginess; has any/all of that changed, or am I perhaps 
> 
> hallucinating?

it's on the list, but IBM has never helped much. 

We'd rather work with something like the lindows system, as we think they 
might actually help.

ron



From rminnich at lanl.gov  Sun Aug 10 19:47:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sun Aug 10 19:47:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030810195802.GB17548@tsn.or.jp>
Message-ID: <Pine.LNX.4.44.0308101803400.20943-100000@maxroach.lanl.gov>

so, in the config file, we have something like:

extension pcbios
extension vgabios
extension elfboot

and the system linkes these in via src/extionsions/whatever.

They are each run in turn.

reasonable?

ron



From gwatson at lanl.gov  Sun Aug 10 20:00:01 2003
From: gwatson at lanl.gov (Greg Watson)
Date: Sun Aug 10 20:00:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308101803400.20943-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308101803400.20943-100000@maxroach.lanl.gov>
Message-ID: <p06001a02bb5c90a7d789@[210.49.48.229]>

At 6:04 PM -0600 10/8/03, ron minnich wrote:
>so, in the config file, we have something like:
>
>extension pcbios
>extension vgabios
>extension elfboot
>
>and the system linkes these in via src/extionsions/whatever.
>
>They are each run in turn.
>
>reasonable?
>

Sounds good, but what does the 'extension' keyword actually do? Is 
there stuff that needs to be called early on, then after elfboot? Or 
can it all be done after elfboot?

Greg


From bari at onelabs.com  Sun Aug 10 20:44:00 2003
From: bari at onelabs.com (Bari Ari)
Date: Sun Aug 10 20:44:00 2003
Subject: smp, newconfig, hdama
In-Reply-To: <FC97984414D48E42B6B70CA3CAE07C78B15BD9@mail.oc.edu>
References: <FC97984414D48E42B6B70CA3CAE07C78B15BD9@mail.oc.edu>
Message-ID: <3F36EB19.2080408@onelabs.com>


David Barr wrote:

> I have access to a fairly largish supply of A22-M series, and as 
>
>president of my local student ACM chapter (named Beta Iota Tau, 
>
>nerdily enough) am desparately searching for more projects for the 
>
>upcoming  semester/year.
>
>  
>
The IBM A22-M uses the Intel 440BX chipset with the ATI Mobility Rage M3 
for graphics. The 440BX is supported by LinuxBIOS and the VideoBIOS can 
be extracted from the flash in the unit. Find out what they use for a 
keyboard controller/superI/O and it may be workable. It may be one of 
the Renasas (Hitachi) IKAP family.

Bari




From agnew at cs.umd.edu  Sun Aug 10 20:53:00 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Sun Aug 10 20:53:00 2003
Subject: smp, newconfig, hdama
In-Reply-To: <3F36EB19.2080408@onelabs.com>
Message-ID: <20030810210549.F15439-100000@www.missl.cs.umd.edu>

>
>
> David Barr wrote:
>
> > I have access to a fairly largish supply of A22-M series, and as
> >
> >president of my local student ACM chapter (named Beta Iota Tau,
> >
> >nerdily enough) am desparately searching for more projects for the
> >
> >upcoming  semester/year.
> >
> >

Also take a look at the flash. If it's soldered on, you'll need to have a
socket put on before you should dare trying to flash it. Use one laptop to
get a working image, then you can flash the rest with their flash still
soldered on. Also, put a layer of foam under the keyboard for when you lay
it down in its socket in order to be able to turn the laptop on. The
underside of those keyboards is metal and can short out the motherboard. I
never thought to look and learned that lesson the hard way, one dead
T23. Let me know if you need to find a place to have a socket put on for
the flash.

- Adam Agnew



From hansolofalcon at worldnet.att.net  Sun Aug 10 21:08:01 2003
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Sun Aug 10 21:08:01 2003
Subject: Backoirted oatch to 2.4.19 for kexec does not work
Message-ID: <000f01c35fa7$8bf25ec0$0100a8c0@who5>

Hello from Gregg C Levine
I don't know why, Andrew, but the patch your company supplied via the
FTP site, for the 2.4.19 kernel, applied correctly, and I was able to
build the kernel. But the expected event didn't work. When I issued a
"kexec kernel.elf", which was built using the latest version of
mkelfImage from the FTP site, that Eric has for his company, I got the
same expected output as before. Here it is:
Script started on Sun Aug 10 21:11:01 2003
root at drwho4:/usr/src/lobos/work# kexec kernel.elf
kexec_load failed: Function not implemented
entry       = (nil)
nr_segments = 4
segment[0].buf   = 0x80a8ea0
segment[0].bufsz = 158
segment[0].mem   = (nil)
segment[0].memsz = 158
segment[1].buf   = 0x80a3888
segment[1].bufsz = 559c
segment[1].mem   = 0x10000
segment[1].memsz = 1aa24
segment[2].buf   = 0x80a8e28
segment[2].bufsz = 0
segment[2].mem   = 0x91000
segment[2].memsz = 70
segment[3].buf   = 0x40001008
segment[3].bufsz = b48dc
segment[3].mem   = 0x100000
segment[3].memsz = 700000
root at drwho4:/usr/src/lobos/work# exit
Script done on Sun Aug 10 21:11:12 2003

Incidentally that's the same thing that I got before. Did this
function work for you? 
What distribution did you use for building your kernel, and, ah, test
system?
As it happens, this is built using Slackware 8.0, with the compiler
version as 2.95.3, and the binary utilities at 2.10.90. Do I need to
upgrade them for attempting to build the later kernels?
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )






From hansolofalcon at worldnet.att.net  Sun Aug 10 21:13:00 2003
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Sun Aug 10 21:13:00 2003
Subject: Backported patch  to 2.4.19 for kexec does not work was RE: Backoirted oatch to 2.4.19 for kexec does not work
In-Reply-To: <000f01c35fa7$8bf25ec0$0100a8c0@who5>
Message-ID: <001001c35fa8$3a1e13e0$0100a8c0@who5>

Hello from Gregg C Levine
Sorry! Predictable typo in subject name, content same.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Gregg C Levine
> Sent: Sunday, August 10, 2003 9:26 PM
> To: Linuxbios
> Subject: Backoirted oatch to 2.4.19 for kexec does not work
> 
> Hello from Gregg C Levine
> I don't know why, Andrew, but the patch your company supplied via
the
> FTP site, for the 2.4.19 kernel, applied correctly, and I was able
to
> build the kernel. But the expected event didn't work. When I issued
a
> "kexec kernel.elf", which was built using the latest version of
> mkelfImage from the FTP site, that Eric has for his company, I got
the
> same expected output as before. Here it is:
> Script started on Sun Aug 10 21:11:01 2003
> root at drwho4:/usr/src/lobos/work# kexec kernel.elf
> kexec_load failed: Function not implemented
> entry       = (nil)
> nr_segments = 4
> segment[0].buf   = 0x80a8ea0
> segment[0].bufsz = 158
> segment[0].mem   = (nil)
> segment[0].memsz = 158
> segment[1].buf   = 0x80a3888
> segment[1].bufsz = 559c
> segment[1].mem   = 0x10000
> segment[1].memsz = 1aa24
> segment[2].buf   = 0x80a8e28
> segment[2].bufsz = 0
> segment[2].mem   = 0x91000
> segment[2].memsz = 70
> segment[3].buf   = 0x40001008
> segment[3].bufsz = b48dc
> segment[3].mem   = 0x100000
> segment[3].memsz = 700000
> root at drwho4:/usr/src/lobos/work# exit
> Script done on Sun Aug 10 21:11:12 2003
> 
> Incidentally that's the same thing that I got before. Did this
> function work for you?
> What distribution did you use for building your kernel, and, ah,
test
> system?
> As it happens, this is built using Slackware 8.0, with the compiler
> version as 2.95.3, and the binary utilities at 2.10.90. Do I need to
> upgrade them for attempting to build the later kernels?
> -------------------
> Gregg C Levine hansolofalcon at worldnet.att.net
> ------------------------------------------------------------
> "The Force will be with you...Always." Obi-Wan Kenobi
> "Use the Force, Luke."? Obi-Wan Kenobi
> (This company dedicates this E-Mail to General Obi-Wan Kenobi )
> (This company dedicates this E-Mail to Master Yoda )
> 
> 
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From rminnich at lanl.gov  Sun Aug 10 21:50:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sun Aug 10 21:50:00 2003
Subject: smp, newconfig, hdama
In-Reply-To: <3F36EB19.2080408@onelabs.com>
Message-ID: <Pine.LNX.4.44.0308102006450.21757-100000@maxroach.lanl.gov>

On Sun, 10 Aug 2003, Bari Ari wrote:

> The IBM A22-M uses the Intel 440BX chipset with the ATI Mobility Rage M3 
> for graphics. The 440BX is supported by LinuxBIOS and the VideoBIOS can 
> be extracted from the flash in the unit. Find out what they use for a 
> keyboard controller/superI/O and it may be workable. It may be one of 
> the Renasas (Hitachi) IKAP family.

The two unknowable issues with IBM:
- enable SPD
- enable FLASH write

they refuse to tell us.

ron



From michel.belleau at malaiwah.com  Sun Aug 10 21:51:01 2003
From: michel.belleau at malaiwah.com (Michel Belleau)
Date: Sun Aug 10 21:51:01 2003
Subject: DIP2PLCC
Message-ID: <1060567685.3f36fa85be43e@www.malaiwah.com>

Hi.

Where could I find a DIP2PLCC adapter ? I'm trying to learn LinuxBIOS but I 
found out that the motherboard I'm trying to get running (VIA Epia 800 
fanless) has a socketed PLCC chip. I checked out on the M-Systems web site and 
they just have DIP32 packages of DoChips (Millenium). These should be 
compatible 1:1 with the PLCC version, right? All I need is an adapter right?

-- 
Michel Belleau <michel.belleau at malaiwah.com>


From bari at onelabs.com  Sun Aug 10 23:04:00 2003
From: bari at onelabs.com (Bari Ari)
Date: Sun Aug 10 23:04:00 2003
Subject: smp, newconfig, hdama
In-Reply-To: <Pine.LNX.4.44.0308102006450.21757-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308102006450.21757-100000@maxroach.lanl.gov>
Message-ID: <3F370BE1.4@onelabs.com>

ron minnich wrote:

>The two unknowable issues with IBM:
>- enable SPD
>- enable FLASH write
>
>they refuse to tell us.
>
>  
>
Was that with the T23? The T23 has a 830MP chipset and S3 graphics. What 
did they use for the keyboard controller/super I/O?

Bari




From steve at nexpath.com  Sun Aug 10 23:35:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Sun Aug 10 23:35:01 2003
Subject: Questions to the experts
In-Reply-To: <Pine.LNX.4.44.0308101757450.20943-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308101757450.20943-100000@maxroach.lanl.gov>
Message-ID: <3F371335.7000207@nexpath.com>

ron minnich wrote:

>> 3) I read an article on Linux where in the serial section they
>>indicate: "Linux supports ordinary telephone modems only if they work
>>through a serial port (although the port may be built into the modem).
>>Is this true? if it is true and someone wants to modem in then it must
>>be done serially?
> 
> no, stop reading the rag that wrote that, they are wrong.
> 

Maybe they were talking about Winmodem cards, I think these are a 
problem on Linux.

-Steve



From ebiederman at lnxi.com  Mon Aug 11 00:07:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug 11 00:07:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308101803400.20943-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308101803400.20943-100000@maxroach.lanl.gov>
Message-ID: <m3d6fcom1r.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> so, in the config file, we have something like:
> 
> extension pcbios
> extension vgabios
> extension elfboot
> 
> and the system linkes these in via src/extionsions/whatever.
> 
> They are each run in turn.
> 
> reasonable?

Not really.

I haven't seen the numbers on the dreaded size overhead.  So
that argument does not yet convince me.  If I can fit a whole IP/UDP
stack a network driver, and printk in 16K I have trouble seeing
the problem.

Most of the things proposed so far are things I am primarily opposed
to, at least except way out on the periphery.  Callbacks are bad.
Binary only code is bad.  Maintenance would be a pain, and we have
not even succeeded in doing a single stable release off of either of
our public trees yet.

I would much rather see these things prototyped with something
like Steve James bare metal tool kit.  We can easily open another
tree just for that up on sourceforge, like we did with the freebios2
tree.

And the biggest reason I don't want to go there is because simple
things tend to be reliable.  And complex things tend to broken.  And
the extension extension looks to allow a lot of needless complexity
into LinuxBIOS.

Also the problems being solved with the extension mechanism are vary
different from what is solved with the core of LinuxBIOS so there are
very different evolutionary pressures.  And there are a different
group of people working on those problems, and the evolution happens
at different rates.

I am not opposed to solving those problems, not even expediently.  But
I don't want a solution in the public tree that causes maintenance
problems.

My mind can be changed, but I need to see a good reason to do this.
The biggest piece of code everyone has been arguing for including, the
code to run a vgabios option rom, simply doesn't work in a lot of
cases, and unless I have overlooked something the reason it doesn't
work in a lot of cases is a design flaw, it doesn't aim for complete
pcbios compliance.

Eric



From ebiederman at lnxi.com  Mon Aug 11 00:18:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug 11 00:18:00 2003
Subject: S2880
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA468@TYANWEB>
References: <3174569B9743D511922F00A0C943142302FCA468@TYANWEB>
Message-ID: <m38yq0oliq.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> Under 4G RAM  linusbios_tables occupy 0x500-0xae0, cmos_util can find
> option_table even after rebooting.
> Under 6G RAM linuxbios_tables occupy 0x500-0xaf4, cmos_util can find
> option_table after power on but can not find it after rebooting.
> 
> The only difference should be that rebooting don't execute auto.c again.

I am not really certain what is going on, but it doesn't sound good.  Normally
I just reset the board and that is probably the right solution.  I am still
struggling to get the new config tool usable, so I am a bit distracted.

We should be rewriting the table even during a reboot.  So the fact
that this doesn't work indicates there is some kind of problem.  What I
don't know.

I can positively report that I have seen this.  If I don't start
pushing my reset code into the tree in the next couple of days please
bug me.

Eric



From ebiederman at lnxi.com  Mon Aug 11 00:25:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug 11 00:25:00 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <20030806223432.R5878-100000@www.missl.cs.umd.edu>
References: <20030806223432.R5878-100000@www.missl.cs.umd.edu>
Message-ID: <m34r0oolh6.fsf@maxwell.lnxi.com>

Adam Agnew <agnew at cs.umd.edu> writes:

> I was looking at the 2.6.0-test2 kernel tree today and saw new menu
> choices under
> 
> "General Setup -> Remove Kernel Features (for embedded systems)" which
> looks like the beginings of an effort to strip out large though somewhat
> optional features. For instance, the current choices include:
> 
> Load all symbols for kernel debugging/ksysmoops
> Enable futex support
> Enable eventpoll support
> Anticipatory I/O Schedualer
> Deadline I/O Schedualer
> 
> It seems like pretty good news for the linux kernel as a bootloader route
> that effots are being made to get the kernel smaller when necessary.

Currently this is running about 60K-100K larger than 2.4.x even with
everything disabled.  But patches to shrink this are welcome.

Eric



From ebiederman at lnxi.com  Mon Aug 11 00:31:08 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug 11 00:31:08 2003
Subject: Kernel in smaller ROMs, salvation in sight?
In-Reply-To: <Pine.LNX.4.44.0308062130030.3905-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308062130030.3905-100000@maxroach.lanl.gov>
Message-ID: <m3znign6q0.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Wed, 6 Aug 2003, Adam Agnew wrote:
> 
> > It seems like pretty good news for the linux kernel as a bootloader route
> > that effots are being made to get the kernel smaller when necessary.
> 
> good, because long term, that is still a preferred choice for me.

Me as well.  I think I want to see if I can get a 2.6.0 kernel to run
on x86 without an mmu.  Potentially that could be very nice size
reduction wise.

And to really get it useful I need to put in the extra work to get
kexec into the kernel.  I'm almost there, but I am currently distracted
with freebios2 and the Opteron port.

Now that there is a good general purpose solution to small 256KB ROMS.
I don't feel bad about pursue a solution that is only useful for 512KB
ROMS and above.  A very compelling reason is that hardware is getting
increasingly interesting, and needs more drivers etc.

Though given how things are going I am half tempted to do things like
write a mini TCP stack that is closer to 10K than 100K.

Eric



From agnew at cs.umd.edu  Mon Aug 11 01:18:00 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Mon Aug 11 01:18:00 2003
Subject: DIP2PLCC
In-Reply-To: <1060567685.3f36fa85be43e@www.malaiwah.com>
Message-ID: <20030811013346.V15439-100000@www.missl.cs.umd.edu>

You don't *have* to use a Disc On Chip. If you have an extra PLCC flash to
play with, you could get LinuxBIOS up and running on the Epia and boot
linux off of a hard drive or ide flash disk (compact flash with an ide
adaptor perhaps). See the mailing list archives for Richard Smith's FAQ to
learn more.
- Adam Agnew


On Sun, 10 Aug 2003, Michel Belleau wrote:

> Hi.
>
> Where could I find a DIP2PLCC adapter ? I'm trying to learn LinuxBIOS but I
> found out that the motherboard I'm trying to get running (VIA Epia 800
> fanless) has a socketed PLCC chip. I checked out on the M-Systems web site and
> they just have DIP32 packages of DoChips (Millenium). These should be
> compatible 1:1 with the PLCC version, right? All I need is an adapter right?
>
> --
> Michel Belleau <michel.belleau at malaiwah.com>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From hansolofalcon at worldnet.att.net  Mon Aug 11 01:27:01 2003
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Mon Aug 11 01:27:01 2003
Subject: Floppy drives and Linux BIOS
Message-ID: <000001c35fcb$ba38f2c0$0100a8c0@who5>

Hello from Gregg C Levine
Here's a question that's definitely going to keep me up nights. Can a
properly configured and working Linux BIOS image, boot something else
via the floppy drive, in this case a normal 3.5 drive setup as the A
drive? 

Well at least from the point of view of the motherboard with its
original BIOS, it would be setup as the A drive. Basically our friends
at FSMLabs market the RTLinux kits. They also make available the same
thing under the GPL license, I still haven't figured if there is a
loss of functionality between the two. At some point they were working
on a floppy drive sized version of the product. 

Before committing to having a working Linux BIOS image based on it,
what I am leaning towards is having the chosen image boot the floppy
drive sized version, and then facilitate whatever tests I, (or my
staff), have in mind. Probably between two or more machines, with one
of them being the lucky one with the working Linux BIOS image on it,
in place of the commodity BIOS. I suspect they all would need to be
the same machine for this to work. And of course the company
unofficially tells me that they have actually discontinued work on
this floppy drive sized version of their product. So far, I can't seem
to get them to tell me why.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )






From aip at cwlinux.com  Mon Aug 11 01:46:01 2003
From: aip at cwlinux.com (Andrew Ip)
Date: Mon Aug 11 01:46:01 2003
Subject: Backoirted oatch to 2.4.19 for kexec does not work
In-Reply-To: <000f01c35fa7$8bf25ec0$0100a8c0@who5>; from Gregg C Levine on Sun, Aug 10, 2003 at 09:26:08PM -0400
References: <000f01c35fa7$8bf25ec0$0100a8c0@who5>
Message-ID: <20030811140316.A4472@mail.cwlinux.com>

Hi Gregg,

> Hello from Gregg C Levine
> I don't know why, Andrew, but the patch your company supplied via the
> FTP site, for the 2.4.19 kernel, applied correctly, and I was able to
> build the kernel. But the expected event didn't work. When I issued a
> "kexec kernel.elf", which was built using the latest version of
> mkelfImage from the FTP site, that Eric has for his company, I got the
> same expected output as before. Here it is:
> Script started on Sun Aug 10 21:11:01 2003
> root at drwho4:/usr/src/lobos/work# kexec kernel.elf
> kexec_load failed: Function not implemented
> entry       = (nil)
> nr_segments = 4
> segment[0].buf   = 0x80a8ea0
> segment[0].bufsz = 158
> segment[0].mem   = (nil)
> segment[0].memsz = 158
> segment[1].buf   = 0x80a3888
> segment[1].bufsz = 559c
> segment[1].mem   = 0x10000
> segment[1].memsz = 1aa24
> segment[2].buf   = 0x80a8e28
> segment[2].bufsz = 0
> segment[2].mem   = 0x91000
> segment[2].memsz = 70
> segment[3].buf   = 0x40001008
> segment[3].bufsz = b48dc
> segment[3].mem   = 0x100000
> segment[3].memsz = 700000
> root at drwho4:/usr/src/lobos/work# exit
> Script done on Sun Aug 10 21:11:12 2003
> Incidentally that's the same thing that I got before. Did this
> function work for you? 
> What distribution did you use for building your kernel, and, ah, test
> system?
> As it happens, this is built using Slackware 8.0, with the compiler
> version as 2.95.3, and the binary utilities at 2.10.90. Do I need to
> upgrade them for attempting to build the later kernels?
It did work here.  I was able to boot from DOC, then mount ide hd and
kexec the kernel without any problem.  Since the patch is pretty old,
it might be a problem if you are using the latest kexec program.  Have
you tried older version?

-Andrew

-- 
Andrew Ip
Email:  aip at cwlinux.com
Tel:    (852) 2542 2046
Fax:    (852) 2542 2036
Mobile: (852) 9201 9866

Cwlinux Limited
Unit 202B 2/F Lai Cheong Factory Building,
479-479A Castle Peak Road,
Lai Chi Kok, Kowloon,
Hong Kong.

For public pgp key, please obtain it from http://www.keyserver.net/en.


From hansolofalcon at worldnet.att.net  Mon Aug 11 01:52:00 2003
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Mon Aug 11 01:52:00 2003
Subject: Backported oatch to 2.4.19 for kexec does not work (Respelled0
In-Reply-To: <20030811140316.A4472@mail.cwlinux.com>
Message-ID: <000301c35fcf$1734a160$0100a8c0@who5>

Hello again from Gregg C Levine
I tried the original program that Eric had written, it gave me the
classic Linux error message, "Segmentation fault". Version 1.0 of the
newer version gave me that same message, even though that is captured
from version 1.8. Also it was repeated all down the line from 1.2 all
the way to 1.8. Since I wasn't sure how long it would be before you
got back to me, I decided to see if I could build a 2.5 series kernel
here. I chose the 2.5.7 applied the necessary patches and that
compiled to the end, telling me that it was ready for the next series
of steps. Why? Do you have a more recent patch on your site?
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: Andrew Ip [mailto:aip at cwlinux.com]
> Sent: Monday, August 11, 2003 2:03 AM
> To: Gregg C Levine
> Cc: Linuxbios
> Subject: Re: Backoirted oatch to 2.4.19 for kexec does not work
> 
> Hi Gregg,
> 
> > Hello from Gregg C Levine
> > I don't know why, Andrew, but the patch your company supplied via
the
> > FTP site, for the 2.4.19 kernel, applied correctly, and I was able
to
> > build the kernel. But the expected event didn't work. When I
issued a
> > "kexec kernel.elf", which was built using the latest version of
> > mkelfImage from the FTP site, that Eric has for his company, I got
the
> > same expected output as before. Here it is:
> > Script started on Sun Aug 10 21:11:01 2003
> > root at drwho4:/usr/src/lobos/work# kexec kernel.elf
> > kexec_load failed: Function not implemented
> > entry       = (nil)
> > nr_segments = 4
> > segment[0].buf   = 0x80a8ea0
> > segment[0].bufsz = 158
> > segment[0].mem   = (nil)
> > segment[0].memsz = 158
> > segment[1].buf   = 0x80a3888
> > segment[1].bufsz = 559c
> > segment[1].mem   = 0x10000
> > segment[1].memsz = 1aa24
> > segment[2].buf   = 0x80a8e28
> > segment[2].bufsz = 0
> > segment[2].mem   = 0x91000
> > segment[2].memsz = 70
> > segment[3].buf   = 0x40001008
> > segment[3].bufsz = b48dc
> > segment[3].mem   = 0x100000
> > segment[3].memsz = 700000
> > root at drwho4:/usr/src/lobos/work# exit
> > Script done on Sun Aug 10 21:11:12 2003
> > Incidentally that's the same thing that I got before. Did this
> > function work for you?
> > What distribution did you use for building your kernel, and, ah,
test
> > system?
> > As it happens, this is built using Slackware 8.0, with the
compiler
> > version as 2.95.3, and the binary utilities at 2.10.90. Do I need
to
> > upgrade them for attempting to build the later kernels?
> It did work here.  I was able to boot from DOC, then mount ide hd
and
> kexec the kernel without any problem.  Since the patch is pretty
old,
> it might be a problem if you are using the latest kexec program.
Have
> you tried older version?
> 
> -Andrew
> 
> --
> Andrew Ip
> Email:  aip at cwlinux.com
> Tel:    (852) 2542 2046
> Fax:    (852) 2542 2036
> Mobile: (852) 9201 9866
> 
> Cwlinux Limited
> Unit 202B 2/F Lai Cheong Factory Building,
> 479-479A Castle Peak Road,
> Lai Chi Kok, Kowloon,
> Hong Kong.
> 
> For public pgp key, please obtain it from
http://www.keyserver.net/en.



From agnew at cs.umd.edu  Mon Aug 11 03:01:01 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Mon Aug 11 03:01:01 2003
Subject: Floppy drives and Linux BIOS
In-Reply-To: <000001c35fcb$ba38f2c0$0100a8c0@who5>
Message-ID: <20030811031549.S15439-100000@www.missl.cs.umd.edu>

I'm confused. What's your question? If you could use the same floppy image
on a series of machines, with some running their normal bios and at least
one running linuxbios?

If that is your question, then I would say yes. If you make the kernel
image on the floppy with linuxbios support. And if you can't change the
kernel image, then you could use ADLO/Bochs to implement the same BIOS
services that you would have on a commercial BIOS.

- Adam Agnew

On Mon, 11 Aug 2003, Gregg C Levine wrote:

> Hello from Gregg C Levine
> Here's a question that's definitely going to keep me up nights. Can a
> properly configured and working Linux BIOS image, boot something else
> via the floppy drive, in this case a normal 3.5 drive setup as the A
> drive?
>
> Well at least from the point of view of the motherboard with its
> original BIOS, it would be setup as the A drive. Basically our friends
> at FSMLabs market the RTLinux kits. They also make available the same
> thing under the GPL license, I still haven't figured if there is a
> loss of functionality between the two. At some point they were working
> on a floppy drive sized version of the product.
>
> Before committing to having a working Linux BIOS image based on it,
> what I am leaning towards is having the chosen image boot the floppy
> drive sized version, and then facilitate whatever tests I, (or my
> staff), have in mind. Probably between two or more machines, with one
> of them being the lucky one with the working Linux BIOS image on it,
> in place of the commodity BIOS. I suspect they all would need to be
> the same machine for this to work. And of course the company
> unofficially tells me that they have actually discontinued work on
> this floppy drive sized version of their product. So far, I can't seem
> to get them to tell me why.
> -------------------
> Gregg C Levine hansolofalcon at worldnet.att.net
> ------------------------------------------------------------
> "The Force will be with you...Always." Obi-Wan Kenobi
> "Use the Force, Luke."? Obi-Wan Kenobi
> (This company dedicates this E-Mail to General Obi-Wan Kenobi )
> (This company dedicates this E-Mail to Master Yoda )
>
>
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From stepan at suse.de  Mon Aug 11 06:10:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Aug 11 06:10:00 2003
Subject: Questions to the experts
In-Reply-To: <3F371335.7000207@nexpath.com>
References: <Pine.LNX.4.44.0308101757450.20943-100000@maxroach.lanl.gov> <3F371335.7000207@nexpath.com>
Message-ID: <20030811102653.GA2583@suse.de>

* Steve Gehlbach <steve at nexpath.com> [030811 05:53]:
> >>3) I read an article on Linux where in the serial section they
> >>indicate: "Linux supports ordinary telephone modems only if they work
> >>through a serial port (although the port may be built into the modem).
> >>Is this true? if it is true and someone wants to modem in then it must
> >>be done serially?
> >
> >no, stop reading the rag that wrote that, they are wrong.
> 
> Maybe they were talking about Winmodem cards, I think these are a 
> problem on Linux.

Many Laptops have these and most of them work fine nowadays. Since most
available drivers are not included in the kernel source itself, it needs
some extra fiddling around, but it's certainly doable.

Stefan




From pyro at linuxlabs.com  Mon Aug 11 06:51:01 2003
From: pyro at linuxlabs.com (steven james)
Date: Mon Aug 11 06:51:01 2003
Subject: VGA BIOS init debate
In-Reply-To: <20030808195410.B15439-100000@www.missl.cs.umd.edu>
Message-ID: <Pine.LNX.4.21.0308110651480.23114-100000@ucontrol.mobiledns.com>

Greetings,

At the risk of getting too complex, we are already generating a map for
LinuxBIOS, what about placing it into an in RAM  table so payloads can
call the functions themselves rather than duplicate them?

That would certainly help out things like ADLO that need to do something
chipset specific in an otherwise generic function (such as control shadow
RAM).

The problem with BIOS and DOS wasn't that there were int calls, it was
just that they were such an ad-hoc mismash and poorly defined.

Ultimately, I do want Linux as the bootloader, but form the looks of
things, 2.6 is still too big unless the network stack is compiled out.

Perhaps 2.7 will see a continuation of the embedded configuration so we
can have a very simple stack and polled I/O driver set, but it's clearly
not ready yet.

Meanwhile even as bigger flash chips become available, mainboard designers
almost seem determined to do the wrong thing.

G'day,
sjames


On Fri, 8 Aug 2003, Adam Agnew wrote:

> 
> I want to throw these arguments into the debate:
> 
> 
> I vote for the ELF payload. I would say that linking it in would be just
> as good, except that if EFI ever does really become common, a lot of
> these payloads would become useful to a larger user base. I do agree that
> there would be some redundancy in code, but I also believe the build
> process would be simplified (rom-o-matic certainly seems more feasible
> without so many options) and those new to LinuxBIOS would be able
> to grasp how it all links together easier.
> 
> Right now, the split in idealogy has put us in quite the pickle. Linuxbios
> has two ways to tftp boot, three ways to polled ide boot, two ways to get
> a vga rom up and running.. If things are still even linked in to
> freebios2, there's a lot of confusion. Do different boot methods use elf
> payloads or are they compiled in? Well that would depend on which one.
> I too would like the Linux kernel to solve all of these problems, I hope
> I've never created the impression that I wish otherwise. But the chunk of
> mailing list traffic from embedded enthusiasts is getting still larger,
> nothing's really changed in ROM size since the Great Payload Debates of
> 2001, and Linux has only gotten bigger (though there's hope..).
> 
> - Adam Agnew
> 
> On Fri, 8 Aug 2003, ron minnich wrote:
> 
> > folks, any opinions expressed on this VGA BIOS discussion would be
> > welcome.
> >
> > VGA BIOS in linuxbios, or in an ELF payload? What's your bet?
> >
> > ron
> >
> >
> 
> 
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------




From rminnich at lanl.gov  Mon Aug 11 09:33:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 09:33:00 2003
Subject: smp, newconfig, hdama
In-Reply-To: <3F370BE1.4@onelabs.com>
Message-ID: <Pine.LNX.4.44.0308110750350.26375-100000@maxroach.lanl.gov>

On Sun, 10 Aug 2003, Bari Ari wrote:

> ron minnich wrote:
> 
> >The two unknowable issues with IBM:
> >- enable SPD
> >- enable FLASH write
> >
> >they refuse to tell us.
> Was that with the T23? The T23 has a 830MP chipset and S3 graphics. What 
> did they use for the keyboard controller/super I/O?

that is with all IBMs.

ron



From rminnich at lanl.gov  Mon Aug 11 09:35:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 09:35:00 2003
Subject: Questions to the experts
In-Reply-To: <3F371335.7000207@nexpath.com>
Message-ID: <Pine.LNX.4.44.0308110750570.26375-100000@maxroach.lanl.gov>

On Sun, 10 Aug 2003, Steve Gehlbach wrote:

> Maybe they were talking about Winmodem cards, I think these are a 
> problem on Linux.

yes, but the author of that article is still pretty clueless.

ron



From hansolofalcon at worldnet.att.net  Mon Aug 11 09:42:01 2003
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Mon Aug 11 09:42:01 2003
Subject: Questions to the experts
In-Reply-To: <Pine.LNX.4.44.0308110750570.26375-100000@maxroach.lanl.gov>
Message-ID: <001201c36010$cca7d440$0100a8c0@who5>

Hello from Gregg C Levine
Originally when I saw the first message, I wasn't going to say
anything. I figured that all of you would have the right things to
say. However, one of the things I have seen in the past five years, is
that when it comes to Linux, and the magazine isn't one that was
formed to publish articles and things on the subject of Linux, the
magazine, and its authors usually are clueless about it. Take for
example the theme of Linux on the mainframe. The bunch attempting to
write about that one, are more clueless then the group I just
mentioned.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of ron minnich
> Sent: Monday, August 11, 2003 9:51 AM
> To: Steve Gehlbach
> Cc: lisa stout; linuxbios at clustermatic.org
> Subject: Re: Questions to the experts
> 
> On Sun, 10 Aug 2003, Steve Gehlbach wrote:
> 
> > Maybe they were talking about Winmodem cards, I think these are a
> > problem on Linux.
> 
> yes, but the author of that article is still pretty clueless.
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From jhearns at micromuse.com  Mon Aug 11 10:16:00 2003
From: jhearns at micromuse.com (John Hearns)
Date: Mon Aug 11 10:16:00 2003
Subject: Questions to the experts
In-Reply-To: <001201c36010$cca7d440$0100a8c0@who5>
References: <001201c36010$cca7d440$0100a8c0@who5>
Message-ID: <3F37A90F.5040205@micromuse.com>

Gregg C Levine wrote:

>Hello from Gregg C Levine
>Originally when I saw the first message, I wasn't going to say
>anything. 
>
I think Lisa might get some good answers over on the Beowulf list,
http://www.beowulf.org/mailman/listinfo/beowulf



From rminnich at lanl.gov  Mon Aug 11 10:20:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 10:20:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <m3d6fcom1r.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308110824040.26375-100000@maxroach.lanl.gov>

On 10 Aug 2003, Eric W. Biederman wrote:

> I haven't seen the numbers on the dreaded size overhead.  So
> that argument does not yet convince me.  If I can fit a whole IP/UDP
> stack a network driver, and printk in 16K I have trouble seeing
> the problem.

multiply that by, let's just say 4, for 4 elf payloads for 4 functions. 
At that point, I can no longer fit a kernel + linuxbios in 1 MB flash. At 
present I can barely fit one linuxbios + 1 stripped kernel.

I am right on the edge of being able to fit right now. Either I statically 
link in the VGABIOS code or I can't fit it. That's the issue for me.

Yes, I am well aware that we hope to have more compact ROMCC code, but 
that is not there right now.

> Most of the things proposed so far are things I am primarily opposed
> to, at least except way out on the periphery.  Callbacks are bad.

Callbacks are required if we hope to support VGA. There is no way around 
this.

> Binary only code is bad.  

Binary code support is required for future chipsets that, e.g., build
wireless into the chipset. There will be many future software radios that
are in chipsets, and you will not be able to get that in open source --
the FCC has a few things to say about that. Binary code support is
inevitable. We won't be able to compile this code in, or build it as an
ELF module.  That's not going to be an option. 

For linuxbios to succeed in future, we'll need support for these two 
things. I think this is a lamentable state of affairs. But that's how it 
is.

I think long-term the best way to fix it for all architectures is via
emulation, but for the immediate-term we can make callback/binary support 
for the common(-est) case: the x86. 

> And the biggest reason I don't want to go there is because simple
> things tend to be reliable.  And complex things tend to broken.  And
> the extension extension looks to allow a lot of needless complexity
> into LinuxBIOS.

But the limits of poor PC design limit our ability to be simple. The 
original LinuxBIOS idea -- "Let Linux do it" -- was simple. We have found 
we need a bit more than that to be workable. 

The single most common request I hear for LinuxBIOS is early VGA support 
-- early enough to see linuxbios messages. You have no idea how often 
this comes up -- or maybe you do :-)

I think we're going to need to do this in a reasonable way, or somebody
will do it for us in an unreasonable way.

> The biggest piece of code everyone has been arguing for including, the
> code to run a vgabios option rom, simply doesn't work in a lot of
> cases, and unless I have overlooked something the reason it doesn't
> work in a lot of cases is a design flaw, it doesn't aim for complete
> pcbios compliance.

That's a factor of time people have had to work on it. The code itself, I 
am told, has proven to be pretty solid for those operations it supports. 

It's possible, the more I think of it, that what we really need is a
payload for solid x86 emulation. That would buy us
architecture-independence which we need. No callbacks either -- just 
emulate the trap and do the code for the callback. Much more reliable than 
callbacks. Very portable.

Still thinking .... more discussion welcome.

ron



From jeff at planetfall.com  Mon Aug 11 10:25:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Mon Aug 11 10:25:00 2003
Subject: EPIA Linuxbios strangeness
Message-ID: <20030811144204.GA24442@planetfall.com>

I got LB working on my EPIA 533 machine.  It works fine -- BUT,

1) The reset button does nothing.  No kidding.  

2) I can't do a software reboot either.  The machine just goes dead if
I try "init 6" or any variation of the reboot command.

3) If I unplug it & plug it back in, the power stays off.

Any ideas?

Thanks!

Jeff


From aip at cwlinux.com  Mon Aug 11 11:07:00 2003
From: aip at cwlinux.com (Andrew Ip)
Date: Mon Aug 11 11:07:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308110824040.26375-100000@maxroach.lanl.gov>; from ron minnich on Mon, Aug 11, 2003 at 08:37:17AM -0600
References: <m3d6fcom1r.fsf@maxwell.lnxi.com> <Pine.LNX.4.44.0308110824040.26375-100000@maxroach.lanl.gov>
Message-ID: <20030811232423.A12486@mail.cwlinux.com>

Hi,

> > I haven't seen the numbers on the dreaded size overhead.  So
> > that argument does not yet convince me.  If I can fit a whole IP/UDP
> > stack a network driver, and printk in 16K I have trouble seeing
> > the problem.
> multiply that by, let's just say 4, for 4 elf payloads for 4 functions. 
> At that point, I can no longer fit a kernel + linuxbios in 1 MB flash. At 
> present I can barely fit one linuxbios + 1 stripped kernel.
> I am right on the edge of being able to fit right now. Either I statically 
> link in the VGABIOS code or I can't fit it. That's the issue for me.
> Yes, I am well aware that we hope to have more compact ROMCC code, but 
> that is not there right now.
Maybe we can separate LinuxBIOS into 2 parts.  The first part contains
the core of LinuxBIOS, and the second part contains different extensions
for different archs and elf loader at the end.  We could have something
like the following in the config which is pretty much like Ron suggested
before

extension1
extension2
extension3
elfloader ide usb net

-Andrew

-- 
Andrew Ip
Email:  aip at cwlinux.com
Tel:    (852) 2542 2046
Fax:    (852) 2542 2036
Mobile: (852) 9201 9866

Cwlinux Limited
Unit 202B 2/F Lai Cheong Factory Building,
479-479A Castle Peak Road,
Lai Chi Kok, Kowloon,
Hong Kong.

For public pgp key, please obtain it from http://www.keyserver.net/en.


From rminnich at lanl.gov  Mon Aug 11 11:41:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 11:41:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308110824040.26375-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.44.0308110956360.27047-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, ron minnich wrote:

> For linuxbios to succeed in future, we'll need support for these two 
> things. I think this is a lamentable state of affairs. But that's how it 
> is.
> 
> I think long-term the best way to fix it for all architectures is via
> emulation, but for the immediate-term we can make callback/binary support 
> for the common(-est) case: the x86. 

I contradict myself. Either we need callbacks or we don't. If we get 
emulation, we don't need them. Sorry for my confusing note. 

Eric, I am sympathy with what you are saying. There is a reality here -- 
people want VGA and they want it on early. I want to accomodate this. 

Is emulation a suitable, architecture-independent way to achieve this? 
I'm thinking it might be. Can we then build it in as an option when we 
build a linuxbios?

thanks

ron



From bari at onelabs.com  Mon Aug 11 11:49:01 2003
From: bari at onelabs.com (Bari Ari)
Date: Mon Aug 11 11:49:01 2003
Subject: smp, newconfig, hdama
In-Reply-To: <Pine.LNX.4.44.0308110750350.26375-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308110750350.26375-100000@maxroach.lanl.gov>
Message-ID: <3F37BF1E.1030708@onelabs.com>

ron minnich wrote:

>On Sun, 10 Aug 2003, Bari Ari wrote:
>
>  
>
>>ron minnich wrote:
>>
>>    
>>
>>>The two unknowable issues with IBM:
>>>- enable SPD
>>>- enable FLASH write
>>>
>>>they refuse to tell us.
>>>      
>>>
>>Was that with the T23? The T23 has a 830MP chipset and S3 graphics. What 
>>did they use for the keyboard controller/super I/O?
>>    
>>
>
>that is with all IBMs.
>
>  
>
The few IBM's I've looked at mux all the SMBus and I2C lines that are 
used for SPD, smart battery, keyboard controller and DDC for CRT, etc, 
etc. The Flash ROM's and FWH write enables tend to be controlled through 
GPIO's on the Super I/O or keyboard/system management controller.

Bari




From rminnich at lanl.gov  Mon Aug 11 11:53:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 11:53:01 2003
Subject: smp, newconfig, hdama
In-Reply-To: <3F37BF1E.1030708@onelabs.com>
Message-ID: <Pine.LNX.4.44.0308111010040.27047-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, Bari Ari wrote:

> The few IBM's I've looked at mux all the SMBus and I2C lines that are 
> used for SPD, smart battery, keyboard controller and DDC for CRT, etc, 
> etc. The Flash ROM's and FWH write enables tend to be controlled through 
> GPIO's on the Super I/O or keyboard/system management controller.

yes, and we can't find those enables.

ron



From bgr at gw.linespeed.net  Mon Aug 11 12:24:00 2003
From: bgr at gw.linespeed.net (Brian G. Rhodes)
Date: Mon Aug 11 12:24:00 2003
Subject: sc1200 (GX1)
Message-ID: <Pine.LNX.4.53.0308111138570.28765@gw.linespeed.net>

This is not directly linuxbios related at all, but since there have been
some other people asking questions about the geode gx1 hardware, I am
curious.

Is anyone successfully using National's fastPCI (66MHz)?  The hardware I
am working on seems to lock up when doing a large number or reads, or big
reads.  It is most evident when using DMA with IDE.  Any ideas?

Brian G Rhodes
bgr at linespeed.net
brhodes at visualcircuits.com
+1 612-741-1191



From YhLu at tyan.com  Mon Aug 11 12:35:00 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug 11 12:35:00 2003
Subject: Supporting extension ROMs and beyond...
Message-ID: <3174569B9743D511922F00A0C943142302FCA66E@TYANWEB>

Ron,

If the user want to LinuxBIOS with embedded solution with screen (SET TOP
BOX???)  the VGA support must be ready and some Workstation also need that.
Otherwise it will limit the application scope of linubios.

Other option rom will be another story, for example: about Serial ATA,
Promise doesn't want provide support, but it's OK , We can get detail info
from Silicon Images chip, so We can use their solution and forget Promise.
As for the scsi chip, LSI likes to share the info. So We can produce their
chip support at first. ( I have add the support for LSI scsi chip). As for
Adaptec is hesitating to give the detail info, and may need more request to
them. It is said Only DELL have got the corresponding from them. 

Who will move VGABIOS support to freebios2 ? I would have a try on Tyan
S2885 . (Two Opterons and workstation MB) this week.

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?11? 8:59
???: Eric W. Biederman
??: SONE Takeshi; Stefan Reinauer; linuxbios at clustermatic.org
??: Re: Supporting extension ROMs and beyond...

On Mon, 11 Aug 2003, ron minnich wrote:

> For linuxbios to succeed in future, we'll need support for these two 
> things. I think this is a lamentable state of affairs. But that's how it 
> is.
> 
> I think long-term the best way to fix it for all architectures is via
> emulation, but for the immediate-term we can make callback/binary support 
> for the common(-est) case: the x86. 

I contradict myself. Either we need callbacks or we don't. If we get 
emulation, we don't need them. Sorry for my confusing note. 

Eric, I am sympathy with what you are saying. There is a reality here -- 
people want VGA and they want it on early. I want to accomodate this. 

Is emulation a suitable, architecture-independent way to achieve this? 
I'm thinking it might be. Can we then build it in as an option when we 
build a linuxbios?

thanks

ron

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Mon Aug 11 12:42:00 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug 11 12:42:00 2003
Subject: Supporting extension ROMs and beyond...
Message-ID: <3174569B9743D511922F00A0C943142302FCA674@TYANWEB>

Ron,

If I only want to use addon AGP Display adapter ROM, I don't need to use
VGABIOS? How about PCIBIOS?

Regards

YH.

-----????-----
???: SONE Takeshi [mailto:ts1 at tsn.or.jp] 
????: 2003?8?9? 10:55
???: ron minnich
??: YhLu; linuxbios at clustermatic.org
??: Re: Supporting extension ROMs and beyond...

On Fri, Aug 08, 2003 at 02:29:08PM -0600, ron minnich wrote:
> On Fri, 8 Aug 2003, YhLu wrote:
> 
> > Where is the VGA BIOS support? Still in freebios?
> 
> it's the one that SONE used in linuxbios, he can describe again how it is 
> enabled. We are using it here for NVidia cards.

I don't know about freebios2 tree, but in freebios tree there is 
some code to call POST routine of external VGA BIOS,
and support for some realmode BIOS call (like PCI BIOS) to
help the VGA BIOS run happily.

It is activated by config like below:

    option CONFIG_VGABIOS=1
    option CONFIG_REALMODE_IDT=1
    dir src/bioscall
    option CONFIG_PCIBIOS=1
    option VGABIOS_START=0xfffe0000

The last line is needed when you use the VGA BIOS image from 
the Flash (typically for onboard VGA).

If this option is not defined, VGA card's ROM is used
(this is what Ron's original code does).

Ron: my last fix to pcibios.c is in the tree and working ok. Thanks.

--
Takeshi


From rminnich at lanl.gov  Mon Aug 11 12:50:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 12:50:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA674@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308111106590.27047-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, YhLu wrote:

> If I only want to use addon AGP Display adapter ROM, I don't need to use
> VGABIOS? How about PCIBIOS?

does the rom need pcibios support? if so, you need both of these modules.

ron



From steve at nexpath.com  Mon Aug 11 13:29:00 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Mon Aug 11 13:29:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308110956360.27047-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308110956360.27047-100000@maxroach.lanl.gov>
Message-ID: <3F37D82F.7050306@nexpath.com>

> Eric, I am sympathy with what you are saying. There is a reality here -- 
> people want VGA and they want it on early. I want to accomodate this. 
> 
> ron

There is always the direct register programming approach that we have 
for the sis630 and stpc, but in the case of the sis630, vga is not 
available immediately due to the PCI init not done yet.  Right after PCI 
init, it comes on.  I suspect this just a few bits in some bridge 
registers, but I have not cared enough to go look.  The stpc is immediate.

Most if not all of the chips and cards support the legacy registers for 
text mode.  But there are always a few magic registers that need to be 
setup to enable legacy mode, and when you don't have the docs, it means 
reverse engineering the BIOS.

I do this quite a bit with the IDA disassembler (comm'l product on 
Windows from datarescue), and it is not so difficult, but very time 
consuming.  And right now I am very busy.

So in the end the most expedient way to get VGA is with the BIOS calls 
and a binary.

I will someday get to more work on VGA disassembly, it is a hobby, some 
people play chess, I disassemble BIOSes.

So how many requests do you get for direct booting vmlinuz.gz from IDE 
(linux fs compatible ala grub or lilo)?

-Steve



From rminnich at lanl.gov  Mon Aug 11 13:35:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 13:35:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <3F37D82F.7050306@nexpath.com>
Message-ID: <Pine.LNX.4.44.0308111152060.27047-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, Steve Gehlbach wrote:

> I will someday get to more work on VGA disassembly, it is a hobby, some 
> people play chess, I disassemble BIOSes.

we can't use that code, however, or some idiot will decide to sue. 

we don't ever use code based on disassembly.

> So how many requests do you get for direct booting vmlinuz.gz from IDE 
> (linux fs compatible ala grub or lilo)?

A fair number ...

ron



From linuxbios at smashed.demon.co.uk  Mon Aug 11 14:37:00 2003
From: linuxbios at smashed.demon.co.uk (James Weir)
Date: Mon Aug 11 14:37:00 2003
Subject: EPIA-M DDR HELP
Message-ID: <000001c36039$ff8c1a00$0b00000a@quadra001>

I hacked the rominit.inc for the epia to configure for my memory
configuration i.e 128 Mb on first bank, 128 Mb on second bank ( total
256Mb ), but now rather than hanging when it Disables cache for first
time whilst setting up mtrr it restarts continuously..

 

,,should I get different ram, or can someone explain the register maps
and configuration options in raminit.inc so that I can customize it to
my own ddr.

 

Thanks,

 

A frustrated James :-)

 

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

From ebiederman at lnxi.com  Mon Aug 11 15:40:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug 11 15:40:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030811232423.A12486@mail.cwlinux.com>
References: <m3d6fcom1r.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.44.0308110824040.26375-100000@maxroach.lanl.gov>
	<20030811232423.A12486@mail.cwlinux.com>
Message-ID: <m3k79kufpg.fsf@maxwell.lnxi.com>

Andrew Ip <aip at cwlinux.com> writes:

> Hi,
> 
> > > I haven't seen the numbers on the dreaded size overhead.  So
> > > that argument does not yet convince me.  If I can fit a whole IP/UDP
> > > stack a network driver, and printk in 16K I have trouble seeing
> > > the problem.
> > multiply that by, let's just say 4, for 4 elf payloads for 4 functions. 
> > At that point, I can no longer fit a kernel + linuxbios in 1 MB flash. At 
> > present I can barely fit one linuxbios + 1 stripped kernel.
> > I am right on the edge of being able to fit right now. Either I statically 
> > link in the VGABIOS code or I can't fit it. That's the issue for me.
> > Yes, I am well aware that we hope to have more compact ROMCC code, but 
> > that is not there right now.
> Maybe we can separate LinuxBIOS into 2 parts.  The first part contains
> the core of LinuxBIOS, and the second part contains different extensions
> for different archs and elf loader at the end.  We could have something
> like the following in the config which is pretty much like Ron suggested

We already have LinuxBIOS separated into 2 parts, and the ELF loader is
the glue between them.   What we don't have is a good second part to hold
the Video code, and other random hacks.  Except for possibly Steve James
bare metal toolkit.

Eric



From steve at nexpath.com  Mon Aug 11 15:49:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Mon Aug 11 15:49:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308111152060.27047-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308111152060.27047-100000@maxroach.lanl.gov>
Message-ID: <3F37F748.8070300@nexpath.com>

ron minnich wrote:

> we can't use that code, however, or some idiot will decide to sue. 
> 
> we don't ever use code based on disassembly.
> 

I understand, although they would lose the suit (Sony v. Connectix and 
related cases), it is not the kind of trouble we need.  Would that idiot 
be named SCO?

I amend my statement.  I use my oscilloscope and logic analyzer to 
determine the register numbers and settings.

Anyhow, I never use the code in any fashion or form, only register 
numbers and bit settings. The actual code is useless, it is 16-bit, you 
might catch a bad disease (urge to write spaghetti code or something) if 
you copy 16-bit code.  I write a spec, then use the spec to write the code.

Where did the VGABIOS code come from (the binary thing we are talking 
about)?

-Steve

PS: I am a pretty big student of title 17 (US copyright law) and the 
DMCA portion (chapter 12).  But so is IBM and they got sued.  So 
lawsuits happens no matter what you do, it happens with probability one 
when the $$ get big.




From ebiederman at lnxi.com  Mon Aug 11 15:55:31 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug 11 15:55:31 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308110956360.27047-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308110956360.27047-100000@maxroach.lanl.gov>
Message-ID: <m3fzk8ufdh.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Mon, 11 Aug 2003, ron minnich wrote:
> 
> > For linuxbios to succeed in future, we'll need support for these two 
> > things. I think this is a lamentable state of affairs. But that's how it 
> > is.
> > 
> > I think long-term the best way to fix it for all architectures is via
> > emulation, but for the immediate-term we can make callback/binary support 
> > for the common(-est) case: the x86. 
> 
> I contradict myself. Either we need callbacks or we don't. If we get 
> emulation, we don't need them. Sorry for my confusing note. 
> 
> Eric, I am sympathy with what you are saying. There is a reality here -- 
> people want VGA and they want it on early. I want to accomodate this. 

Early is a problem unless we intimately know the video chipset.  We can
never accomodate early (as in all LinuxBIOS messages) with an option ROM.

For the option ROM solution the best we can do reliably is to run it
right after we run the LinuxBIOS core.

> Is emulation a suitable, architecture-independent way to achieve this? 
> I'm thinking it might be. Can we then build it in as an option when we 
> build a linuxbios?

Where to put this functionality, because we want it no matter which
bootloader we use is a good question.  My hunch is we make it some
sort of header.  

Because by early all we can really promise are the bootloader and the
kernel messages, at least via this route.

Eric



From bari at onelabs.com  Mon Aug 11 16:02:01 2003
From: bari at onelabs.com (Bari Ari)
Date: Mon Aug 11 16:02:01 2003
Subject: smp, newconfig, hdama
In-Reply-To: <Pine.LNX.4.44.0308111010040.27047-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308111010040.27047-100000@maxroach.lanl.gov>
Message-ID: <3F37F84D.5040100@onelabs.com>

ron minnich wrote:

>yes, and we can't find those enables.
>
>  
>
If you've not given up yet/disgusted with the T23, the 830 reference 
design schematic is pretty close to the actual laptop design.

ftp://download.intel.com/design/chipsets/designex/29833904.pdf

the last 50 pages may be of help.

Bari




From YhLu at tyan.com  Mon Aug 11 18:31:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug 11 18:31:01 2003
Subject: Supporting extension ROMs and beyond...
Message-ID: <3174569B9743D511922F00A0C943142302FCA6E1@TYANWEB>

Ron,

I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom
to 0xfff8c000, ( the second 48k).

The result is When execute the option rom produce following output, and it
seems 
In the option rom doesn't process bus/dev/func properly.

Regards

YH.

INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1002, did=4752
0x55 0xaa 0x48 0xeb 0x7b 0x2e 0x65 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
biosint: # 0x1a, eax 0xb109 ebx 0x0 ecx 0x3f8 edx 0xc2cc
biosint: ebp 0x16788 esp 0xfd6 edi 0x2e esi 0xe578
biosint: ip 0x29c cs 0x0 flags 0x46
0xb109: BAD DEVICE bus 0 devfn 0x0
0xb109: bus 0 devfn 0x0 reg 0x2e val 0xffff
biosint: # 0x1a, eax 0xb109 ebx 0x0 ecx 0xffff edx 0xc2cc
biosint: ebp 0x16788 esp 0xfd6 edi 0x14 esi 0xe578
biosint: ip 0x308 cs 0x0 flags 0x46
0xb109: BAD DEVICE bus 0 devfn 0x0
0xb109: bus 0 devfn 0x0 reg 0x14 val 0xffff
biosint: # 0x1a, eax 0xb10a ebx 0x0 ecx 0x3 edx 0xc2cc
biosint: ebp 0x16788 esp 0xfd6 edi 0x18 esi 0xe578
biosint: ip 0x32d cs 0x0 flags 0x86
0xb10a: BAD DEVICE bus 0 devfn 0x0
0xb10a: bus 0 devfn 0x0 reg 0x18 val 0xffffffff
biosint: # 0x1a, eax 0xb108 ebx 0x0 ecx 0x84 edx 0xb108
biosint: ebp 0x10fa4 esp 0xf96 edi 0x4 esi 0x1b1
biosint: ip 0x84e9 cs 0x0 flags 0x46
0xb108: BAD DEVICE bus 0 devfn 0x0
0xb108: bus 0 devfn 0x0 reg 0x4 val 0xff
biosint: # 0x1a, eax 0xb10b ebx 0x0 ecx 0xff edx 0xb10b
biosint: ebp 0x10fa4 esp 0xf9a edi 0x4 esi 0x1b2
biosint: ip 0x841b cs 0x0 flags 0x46
0xb10b: BAD DEVICE bus 0 devfn 0x0
0xb10b: bus 0 devfn 0x0 reg 0x4 val 0xff
biosint: # 0x1a, eax 0xb10c ebx 0x0 ecx 0x0 edx 0xb10c
biosint: ebp 0x10fa4 esp 0xf9a edi 0x0 esi 0x1b4
biosint: ip 0x841b cs 0x0 flags 0x46
0xb10c: BAD DEVICE bus 0 devfn 0x0
0xb10c: bus 0 devfn 0x0 reg 0x0 val 0x0
"
-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?11? 10:07
???: YhLu
??: SONE Takeshi; linuxbios at clustermatic.org
??: re: Supporting extension ROMs and beyond...

On Mon, 11 Aug 2003, YhLu wrote:

> If I only want to use addon AGP Display adapter ROM, I don't need to use
> VGABIOS? How about PCIBIOS?

does the rom need pcibios support? if so, you need both of these modules.

ron


From rminnich at lanl.gov  Mon Aug 11 18:38:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 18:38:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <3F37F748.8070300@nexpath.com>
Message-ID: <Pine.LNX.4.44.0308111649330.30099-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, Steve Gehlbach wrote:

> Where did the VGABIOS code come from (the binary thing we are talking 
> about)?

??

which one.

ron



From steve at nexpath.com  Mon Aug 11 18:46:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Mon Aug 11 18:46:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308111649330.30099-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308111649330.30099-100000@maxroach.lanl.gov>
Message-ID: <3F38228D.8050604@nexpath.com>

ron minnich wrote:
> 
>>Where did the VGABIOS code come from (the binary thing we are talking 
>>about)?

> which one.

The point was, is it a proprietary BIOS from a mfr of the 
video/motherboard?  I got the impression we were talking of copying a 
binary into the project, and wanted to know if it was a copyrighted and 
proprietary work.  Or did I miss the point?  The issue is that just 
because you bought the board doesn't mean you have the right to copy the 
BIOS code, unless the mfr is specifically giving us the license to do that.

-Steve



From rminnich at lanl.gov  Mon Aug 11 19:04:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 19:04:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA6E1@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308111715390.30099-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, YhLu wrote:

> I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom
> to 0xfff8c000, ( the second 48k).

ah, well, we shouldn't really do that until we resolve the VGA bios 
question. 

Looks, however, looke tehre is a bug ... Takeshi can perhaps address it 
better than I. 

I did look at our three options today: emulation, ADLO, and VGABIOS. 

VGABIOS is almost 100% C save for the 32-16 trampoline code. 

ADLO rombios.c is mostly assembly code with C wrappers around it.

Emulation is C. 

Emulation is 256K

ADLO is 64K. 

VGABIOS is much less, something like 16K last time I built it.

The functions that VGABIOS needs to finish up to have as complete support 
as bringing up graphics as ADLO are not that many in number. Which makes 
sense: what a VGA BIOS needs to do is diddle its own registers, so most 
BISO functionality is not that useful for them. 

ADLO will not find the option rom on a card and use it; VGABIOS will. 

The most portable long-term way to go is emulation. I don't have room. 

These are the issues I have seen so far. 

ron



From rminnich at lanl.gov  Mon Aug 11 19:06:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 19:06:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <3F38228D.8050604@nexpath.com>
Message-ID: <Pine.LNX.4.44.0308111721350.30099-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, Steve Gehlbach wrote:

> The point was, is it a proprietary BIOS from a mfr of the 
> video/motherboard?  I got the impression we were talking of copying a 
> binary into the project, and wanted to know if it was a copyrighted and 
> proprietary work.  Or did I miss the point?  

you missed the point. We will never copy a vga bios into the tree in any 
place unless given permission. 

> The issue is that just 
> because you bought the board doesn't mean you have the right to copy the 
> BIOS code, unless the mfr is specifically giving us the license to do that.

Fair use says, I think, that you can copy a bios from your machine to your
machine for personal use. Certainly that's what you do when you load a new
bios image from a web site. You can't distribute it. So ADLO supports
getting the VGA bios out of your on-card bios and building it into
linuxbios. That's how it is done: copy it from your machine to your 
machine. 

VGABIOS, on the other hand, just finds the on-card bios and runs it.

ron



From YhLu at tyan.com  Mon Aug 11 19:16:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug 11 19:16:01 2003
Subject: Supporting extension ROMs and beyond...
Message-ID: <3174569B9743D511922F00A0C943142302FCA6F5@TYANWEB>

Ron,

Thanks the clarification.

I only move idt.c and vgabios.c and pcbios.c to the freebios2 and make it
can be compiled into linuxbios. And it should call the Option rom in MB
EEPROM or addon on card's expansion rom.

I also find the freebios/util/vgabios. Is that you mean 16 VGABIOS or
emulation?

Regards

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?11? 16:21
???: YhLu
??: SONE Takeshi; linuxbios at clustermatic.org
??: Re: Supporting extension ROMs and beyond...

On Mon, 11 Aug 2003, YhLu wrote:

> I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom
> to 0xfff8c000, ( the second 48k).

ah, well, we shouldn't really do that until we resolve the VGA bios 
question. 

Looks, however, looke tehre is a bug ... Takeshi can perhaps address it 
better than I. 

I did look at our three options today: emulation, ADLO, and VGABIOS. 

VGABIOS is almost 100% C save for the 32-16 trampoline code. 

ADLO rombios.c is mostly assembly code with C wrappers around it.

Emulation is C. 

Emulation is 256K

ADLO is 64K. 

VGABIOS is much less, something like 16K last time I built it.

The functions that VGABIOS needs to finish up to have as complete support 
as bringing up graphics as ADLO are not that many in number. Which makes 
sense: what a VGA BIOS needs to do is diddle its own registers, so most 
BISO functionality is not that useful for them. 

ADLO will not find the option rom on a card and use it; VGABIOS will. 

The most portable long-term way to go is emulation. I don't have room. 

These are the issues I have seen so far. 

ron


From bari at onelabs.com  Mon Aug 11 19:23:00 2003
From: bari at onelabs.com (Bari Ari)
Date: Mon Aug 11 19:23:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308111721350.30099-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308111721350.30099-100000@maxroach.lanl.gov>
Message-ID: <3F38299B.5060701@onelabs.com>

ron minnich wrote:

>Fair use says, I think, that you can copy a bios from your machine to your
>machine for personal use. Certainly that's what you do when you load a new
>bios image from a web site. You can't distribute it. So ADLO supports
>getting the VGA bios out of your on-card bios and building it into
>linuxbios. That's how it is done: copy it from your machine to your 
>machine. 
>
>VGABIOS, on the other hand, just finds the on-card bios and runs it.
>
>  
>
Does this mean that VGABIOS would not work for boards that have 
integrated video and have the video BIOS combined into the system BIOS?

Bari




From steve at nexpath.com  Mon Aug 11 19:33:00 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Mon Aug 11 19:33:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308111721350.30099-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308111721350.30099-100000@maxroach.lanl.gov>
Message-ID: <3F382D8A.8040003@nexpath.com>

ron minnich wrote:


> you missed the point. We will never copy a vga bios into the tree in any 
> place unless given permission. 
> 

Okay, I saw something about putting binaries into linuxbios, and made 
the assumption...

-Steve



From YhLu at tyan.com  Mon Aug 11 19:33:17 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug 11 19:33:17 2003
Subject: Supporting extension ROMs and beyond...
Message-ID: <3174569B9743D511922F00A0C943142302FCA700@TYANWEB>

It should work with onboard one. You may put the option rom in the EEPROM
and set the VGABIOS_START correctly.

YH.

-----????-----
???: Bari Ari [mailto:bari at onelabs.com] 
????: 2003?8?11? 16:41
???: ron minnich
??: Steve Gehlbach; Eric W. Biederman; SONE Takeshi; Stefan Reinauer;
linuxbios at clustermatic.org
??: Re: Supporting extension ROMs and beyond...

ron minnich wrote:

>Fair use says, I think, that you can copy a bios from your machine to your
>machine for personal use. Certainly that's what you do when you load a new
>bios image from a web site. You can't distribute it. So ADLO supports
>getting the VGA bios out of your on-card bios and building it into
>linuxbios. That's how it is done: copy it from your machine to your 
>machine. 
>
>VGABIOS, on the other hand, just finds the on-card bios and runs it.
>
>  
>
Does this mean that VGABIOS would not work for boards that have 
integrated video and have the video BIOS combined into the system BIOS?

Bari


_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Mon Aug 11 21:08:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 21:08:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA6F5@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308111924440.31101-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, YhLu wrote:

> I also find the freebios/util/vgabios. Is that you mean 16 VGABIOS or
> emulation?

that is the (fixed) x86 emulation code from the XFree86 tree. 

ron



From rminnich at lanl.gov  Mon Aug 11 21:08:43 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 21:08:43 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <3F38299B.5060701@onelabs.com>
Message-ID: <Pine.LNX.4.44.0308111925170.31101-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, Bari Ari wrote:

> Does this mean that VGABIOS would not work for boards that have 
> integrated video and have the video BIOS combined into the system BIOS?

Currently, it means it won't work, but that is pretty straightforward to 
fix.

ron




From rminnich at lanl.gov  Mon Aug 11 21:09:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 21:09:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA700@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308111926060.31101-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, YhLu wrote:

> It should work with onboard one. You may put the option rom in the EEPROM
> and set the VGABIOS_START correctly.

oops, forgot, we do support that. I never tried it though.

ron



From adam at cfar.umd.edu  Mon Aug 11 22:23:01 2003
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Mon Aug 11 22:23:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308111926060.31101-100000@maxroach.lanl.gov>
Message-ID: <20030811223806.O31174-100000@www.missl.cs.umd.edu>

[apologies if it was mentioned before]

Not sure if folks now about it,
but there's this project.

	http://www.nongnu.org/vgabios/

perhaps it would be usefull.

-- 
Adam Sulmicki
http://www.eax.com 	The Supreme Headquarters of the 32 bit registers



From rminnich at lanl.gov  Mon Aug 11 23:08:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 11 23:08:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030811223806.O31174-100000@www.missl.cs.umd.edu>
Message-ID: <Pine.LNX.4.44.0308112122410.31824-100000@maxroach.lanl.gov>

On Mon, 11 Aug 2003, Adam Sulmicki wrote:

> Not sure if folks now about it,
> but there's this project.

it's ok but it's overkill. All we want is to get vga into a state that
linux etc. can use it. That means only supporting PCIBIOS functions used
by VGA expansion roms for initialization. That in turn means I don't want 
to support stuff such as:

static void biosfn_get_single_palette_reg();
static void biosfn_read_overscan_border_color();
static void biosfn_get_all_palette_reg();
static void biosfn_set_single_dac_reg();
static void biosfn_set_all_dac_reg();
static void biosfn_select_video_dac_color_page();
static void biosfn_read_single_dac_reg();
static void biosfn_read_all_dac_reg();
static void biosfn_set_pel_mask();
static void biosfn_read_pel_mask();
static void biosfn_read_video_dac_state();
static void biosfn_perform_gray_scale_summing();
static void biosfn_load_text_user_pat();
static void biosfn_load_text_8_14_pat();
static void biosfn_load_text_8_8_pat();
static void biosfn_set_text_block_specifier();
static void biosfn_load_text_8_16_pat();
static void biosfn_load_gfx_8_8_chars();
static void biosfn_load_gfx_user_chars();
static void biosfn_load_gfx_8_14_chars();
static void biosfn_load_gfx_8_8_dd_chars();
static void biosfn_load_gfx_8_16_chars();

etc.

But it's still a neat hack.

ron



From steve at nexpath.com  Mon Aug 11 23:27:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Mon Aug 11 23:27:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030811223806.O31174-100000@www.missl.cs.umd.edu>
References: <20030811223806.O31174-100000@www.missl.cs.umd.edu>
Message-ID: <3F3862B0.9000705@nexpath.com>

Adam Sulmicki wrote:

> 	http://www.nongnu.org/vgabios/
> 

Thanks, I hadn't seen this before, looks like a very nice implementation.

I believe on a quick read that it is implementing basic legacy mode VGA, 
which we have in linuxbios.  The problem always is, how to set the 
bridge or card to the point to enable the legacy mode.  I think that is 
where the card VGABIOS comes in, and since it calls regular BIOS, you 
need both.

But I am frustrated by not having enough time to spend on this, because 
you are only a handfull of registers (or much less) away from having 
legacy enabled on most cards.  Sometimes it is just a bit or two in one 
or two registers.  The rest we already have.  Frambuffer, of course, is 
more complicated (at higher res anyway).

-Steve




From hansolofalcon at worldnet.att.net  Tue Aug 12 00:02:01 2003
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Tue Aug 12 00:02:01 2003
Subject: Floppy drives and Linux BIOS
In-Reply-To: <20030811031549.S15439-100000@www.missl.cs.umd.edu>
Message-ID: <000401c36089$13a25e60$0100a8c0@who5>

Hello again from Gregg C Levine
To be honest Adam, the thought that I brought up earlier today, wasn't
well presented, but you did answer it accurately. My big problem as
near as I can tell, is that the currently available versions of their
floppy based RTL are older kernels, and they have no plans to update
it. I think your suggestion of using the ADLO arrangement is what I am
looking for. But I am looking for suggestions from the group.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Adam Agnew
> Sent: Monday, August 11, 2003 3:19 AM
> To: Gregg C Levine
> Cc: Linuxbios
> Subject: Re: Floppy drives and Linux BIOS
> 
> 
> I'm confused. What's your question? If you could use the same floppy
image
> on a series of machines, with some running their normal bios and at
least
> one running linuxbios?
> 
> If that is your question, then I would say yes. If you make the
kernel
> image on the floppy with linuxbios support. And if you can't change
the
> kernel image, then you could use ADLO/Bochs to implement the same
BIOS
> services that you would have on a commercial BIOS.
> 
> - Adam Agnew
> 
> On Mon, 11 Aug 2003, Gregg C Levine wrote:
> 
> > Hello from Gregg C Levine
> > Here's a question that's definitely going to keep me up nights.
Can a
> > properly configured and working Linux BIOS image, boot something
else
> > via the floppy drive, in this case a normal 3.5 drive setup as the
A
> > drive?
> >
> > Well at least from the point of view of the motherboard with its
> > original BIOS, it would be setup as the A drive. Basically our
friends
> > at FSMLabs market the RTLinux kits. They also make available the
same
> > thing under the GPL license, I still haven't figured if there is a
> > loss of functionality between the two. At some point they were
working
> > on a floppy drive sized version of the product.
> >
> > Before committing to having a working Linux BIOS image based on
it,
> > what I am leaning towards is having the chosen image boot the
floppy
> > drive sized version, and then facilitate whatever tests I, (or my
> > staff), have in mind. Probably between two or more machines, with
one
> > of them being the lucky one with the working Linux BIOS image on
it,
> > in place of the commodity BIOS. I suspect they all would need to
be
> > the same machine for this to work. And of course the company
> > unofficially tells me that they have actually discontinued work on
> > this floppy drive sized version of their product. So far, I can't
seem
> > to get them to tell me why.
> > -------------------
> > Gregg C Levine hansolofalcon at worldnet.att.net
> > ------------------------------------------------------------
> > "The Force will be with you...Always." Obi-Wan Kenobi
> > "Use the Force, Luke."? Obi-Wan Kenobi
> > (This company dedicates this E-Mail to General Obi-Wan Kenobi )
> > (This company dedicates this E-Mail to Master Yoda )
> >
> >
> >
> >
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From stepan at suse.de  Tue Aug 12 06:19:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Aug 12 06:19:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308111715390.30099-100000@maxroach.lanl.gov>
References: <3174569B9743D511922F00A0C943142302FCA6E1@TYANWEB> <Pine.LNX.4.44.0308111715390.30099-100000@maxroach.lanl.gov>
Message-ID: <20030812103627.GA1759@suse.de>

* ron minnich <rminnich at lanl.gov> [030812 01:21]:
> > I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom
> > to 0xfff8c000, ( the second 48k).
> 
> ah, well, we shouldn't really do that until we resolve the VGA bios 
> question. 
 
It sounds cleaner to work on a seperated version of the legacy emulation
code since no matter what it does, it won't mess up the LinuxBIOS core.

> I did look at our three options today: emulation, ADLO, and VGABIOS. 
> 
> VGABIOS is almost 100% C save for the 32-16 trampoline code. 
> 
> ADLO rombios.c is mostly assembly code with C wrappers around it.
> 
> Emulation is C. 
> 
> Emulation is 256K
> 
> ADLO is 64K. 
> 
> VGABIOS is much less, something like 16K last time I built it.
 
Emulation and ADLO go hand in hand I think. There are 2 different
problems to be addressed:

 1) x86 realmode code execution.
 2) legacy api emulation/implementation (pcibios, etc)

* LinuxBIOS1 on x86 supports 1) directly and does 2 with an emulation
  (pcibios.c)

* ADLO on x86 supports 1) and does 2) using the bochs bios image.
 
* "testbios" from the freebios1 tree (util/vgabios) supports 1) with
  an x86 emulation and 2) with an emulation as well. (int*.c)

Now x86emu comes with some example code doing legacy emulation, either 
in vm86 mode on x86 or with the cpu emulation on non-x86 cpus. This is
how XFree86 does it.

In my opinion writing the legacy emulation code (2) in C certainly makes
sense, since it will run on all platforms by recompiling and it can be
driven by either the realmode idt code (like in linuxbios1) or by an
x86emu, depending on your platform.

OTOH, making an x86emu capable version of ADLO can make the day as well,
running the whole blob of bochs bios in the emulation. This looks
closest to a normal PC, but definitely needs tweaking as well.
Looking at the several thousand lines of bochs bios intermixed assembler
and C code I am not sure whether I would want to touch this at all.
bochs bios has problems in quite some places and a clean 32bit rewrite
of the legacy interface that is enough to interface with vga and scsi
devices is not an overwhelming effort.

Looking at the size I got the x86emu emulation including an incomplete
legacy bios emulation plus userland pci code (testbios) to 
below 150k with -Os, so it would fit in a 256k rom with linuxbios and
etherboot pretty easily. On x86 most of the code can be dropped leaving
probably less than 32k for the legacy emulation.

> The functions that VGABIOS needs to finish up to have as complete support 
> as bringing up graphics as ADLO are not that many in number. Which makes 
> sense: what a VGA BIOS needs to do is diddle its own registers, so most 
> BISO functionality is not that useful for them. 

Still it can be easily enhanced to cope with more hardware if someone
needs this. Even some disk interfacing code to be able to load a kernel
from a scsi device just by using the scsi controller's firmware seems
only little extra work 

> ADLO will not find the option rom on a card and use it; VGABIOS will. 
 
This is probably only a matter of setting the right shadow/ram/rom
mapping configuration?

    Stefan





From stepan at suse.de  Tue Aug 12 06:36:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Aug 12 06:36:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030811223806.O31174-100000@www.missl.cs.umd.edu>
References: <Pine.LNX.4.44.0308111926060.31101-100000@maxroach.lanl.gov> <20030811223806.O31174-100000@www.missl.cs.umd.edu>
Message-ID: <20030812105207.GB1759@suse.de>

* Adam Sulmicki <adam at cfar.umd.edu> [030812 04:39]:
> 
> [apologies if it was mentioned before]
> 
> Not sure if folks now about it,
> but there's this project.
> 
> 	http://www.nongnu.org/vgabios/
> 
> perhaps it would be usefull.

This is nice and useful for bochs and plex86, since they don't run on
real hardware but implement a generic, really dumb vga device.

To get VGA initialized generally we _do_ need the vga bios that sits
on the graphics card itself (or in the system rom, if vga is onboard)

A reimplementation like the above contains all the nice API that would 
allow any OS or bootloader to interface with the bios nicely. But that
is not what we need, since the graphics card bios provided by the card
manufacturer does that already.
It would be useful if we solved the problem of calling pci option roms
for initialization and want to be able to test LinuxBIOS in bochs
though.

Stefan




From lpacheco at netvisao.pt  Tue Aug 12 06:47:01 2003
From: lpacheco at netvisao.pt (Luis Pacheco)
Date: Tue Aug 12 06:47:01 2003
Subject: VGABIOS
Message-ID: <1060689886.1413.8.camel@toshiba.loopback>

Hi there,

I'm reading your discussion about building an vgabios... and i discover
this link with an vgabios for SiS systems... It could be a good example
to start something .... At this moment i'm trying to convert the source
from masm to as86 and C... 

http://openbios.infra.de/archiv/2000-06/0071.html

Best Regards,

-- 
Luis Andr?? Pacheco
http://www.neuralbit.com



From niki.waibel at newlogic.com  Tue Aug 12 07:15:01 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Tue Aug 12 07:15:01 2003
Subject: DIP2PLCC
In-Reply-To: <1060567685.3f36fa85be43e@www.malaiwah.com>
Message-ID: <200308121132.h7CBWiH3008080@enterprise2.newlogic.at>

> Where could I find a DIP2PLCC adapter ?

http://www.epboard.com/

i just ordered E32-0035 (still waiting).
E32-0030 seems to be too big (for my epia-m).
in addition i got the RD1 BIOS Savior from
http://www.ioss.com.tw/web/English/RD1BIOSSavior.html
the PL version works for my 600mhz epia-m.

i also ordered a MD-2802-D08-V3 and a MD-2202-D128-V3.
both come originally from www.m-sys.com (m-systems).
on their website you can find a local reseller:
http://www.m-sys.com/Content/Contact/MsysWorldwide.asp
i am waiting for that as well.

currently (afaik) noone has tried to get linuxbios
working like this. (if i am wrong then pls tell me!)
the plan is to have linuxbios, the kernel and a small
rootfs in this m-systems chip (MD-2802-D08-V3 = 8MByte -- can boot
linuxbios on DIP motherboards, MD-2202-D128-V3 = 128MB --
but i've heard on this list that it is not possible to
boot linuxbios with this chip... we'll see ;-) ).
the chip will sit on the DIP2PLCC converter.
the converter sits on the BIOS Savior in its first stage
(to program the msystems chip easyly). and the BIOS Savior
is plugged into the mainboard instead of the bios chip.

> I'm trying to learn LinuxBIOS but I 

that is what i do currently as well :)

> found out that the motherboard I'm trying to get running (VIA Epia 800 

what type of chassis do you use?
mine is very small, but has the following disadvantages:
        * only slimline floppy/cdrom (will be very hard to
find a smartcard reader which fits)
        * external power supply
        * no chassis intrusion detection
        * no lock possible on chassis
        * 2 chassis fans -- not so silent -- it is
ok, but it could be better imho.

> fanless) has a socketed PLCC chip. I checked out on the M-Systems web site and 
> they just have DIP32 packages of DoChips (Millenium). These should be 
> compatible 1:1 with the PLCC version, right?

i dont know yet 100% (but i really hope so!).
but you'll find a report on this list as soon as i
get the missing pieces :)

> All I need is an adapter right?

and a bios savior to make programming easy.
and a flash chip (there is one integrated in
the bios savior, but that chip is only 256kbyte).

hope this answers some questions, niki



From stepan at suse.de  Tue Aug 12 07:35:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Aug 12 07:35:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030812103627.GA1759@suse.de>
References: <3174569B9743D511922F00A0C943142302FCA6E1@TYANWEB> <Pine.LNX.4.44.0308111715390.30099-100000@maxroach.lanl.gov> <20030812103627.GA1759@suse.de>
Message-ID: <20030812115132.GA3414@suse.de>

* Stefan Reinauer <stepan at suse.de> [030812 12:36]:
>  1) x86 realmode code execution.
>  2) legacy api emulation/implementation (pcibios, etc)
> 
> In my opinion writing the legacy emulation code (2) in C certainly makes
> sense, since it will run on all platforms by recompiling and it can be
> driven by either the realmode idt code (like in linuxbios1) or by an
> x86emu, depending on your platform.

I looked at the official x86emu code at 
ftp://ftp.scitechsoft.com/devel/x86emu/x86emu-0.8.tar.gz

This contains something pretty similar than what we need in the v86bios
directory. It's a bios emulation that either plugs into vm86 or x86emu.

> Looking at the size I got the x86emu emulation including an incomplete
> legacy bios emulation plus userland pci code (testbios) to 
> below 150k with -Os, so it would fit in a 256k rom with linuxbios and
> etherboot pretty easily. On x86 most of the code can be dropped leaving
> probably less than 32k for the legacy emulation.
 
compiling v86bios.vm86 from above I get everything into 20k.

   Stefan




From michel.belleau at malaiwah.com  Tue Aug 12 09:13:00 2003
From: michel.belleau at malaiwah.com (Michel Belleau)
Date: Tue Aug 12 09:13:00 2003
Subject: DIP2PLCC
In-Reply-To: <200308121132.h7CBWiH3008080@enterprise2.newlogic.at>
References: <200308121132.h7CBWiH3008080@enterprise2.newlogic.at>
Message-ID: <1060695002.3f38ebda73e0b@www.malaiwah.com>

Selon Niki Waibel <niki.waibel at newlogic.com>:

> > Where could I find a DIP2PLCC adapter ?
> http://www.epboard.com/

That's what I did yesterday ;-)

> i also ordered a MD-2802-D08-V3 and a MD-2202-D128-V3.
> both come originally from www.m-sys.com (m-systems).
> on their website you can find a local reseller:
> http://www.m-sys.com/Content/Contact/MsysWorldwide.asp
> i am waiting for that as well.

I ordered the 5V versions because my EPIA 800mhz board uses the "SST 39SF020A" 
flash chip which is rated at 4.5/5V. What board do you have?

> currently (afaik) noone has tried to get linuxbios
> working like this. (if i am wrong then pls tell me!)
> the plan is to have linuxbios, the kernel and a small
> rootfs in this m-systems chip (MD-2802-D08-V3 = 8MByte -- can boot
> linuxbios on DIP motherboards, MD-2202-D128-V3 = 128MB --
> but i've heard on this list that it is not possible to
> boot linuxbios with this chip... we'll see ;-) ).
> the chip will sit on the DIP2PLCC converter.

I ordered the 8Mbyte chip from tri-m and the DIP2PLCC adapter from epboard. I'm 
looking to integrate everything to the 8mb chip. I think it's really possible 
because I already made a linux boot disk (uclibc+busybox+mpg321) which 
connected itself to my home server and played mp3's as soon as it could.

> what type of chassis do you use?

I made a custom chassis for prototyping use only ;-) The final stage of 
developpement will be to make something nice for the casing.

> and a bios savior to make programming easy.
> and a flash chip (there is one integrated in
> the bios savior, but that chip is only 256kbyte).

I'm very curious and I want to learn everything ;-) My current project consists 
of:

VIA EPIA 800mhz all-on-board fanless mb
DC-to-DC power supply (input: car voltage.. 14.4v)
VWCDPIC adapter (to connect to the cd-changer input of my car (VW))
DIP2PLCC adapter (for the millenium chip)
DoC Millenium (8mb, all right for the linuxbios + kernel + small fs)

My first goal is to make it boot in 3 seconds (i think linuxbios can help me 
achieve it) and start to play mp3's from whatever will be connected to it (for 
instance, an old hard drive and/or a dvd-rom drive). The mb will feed the audio 
to the VWCDPIC and the VWCDPIC will feed the commands from my oem head-unit to 
the computer (rs-232).

Right now, it's kinda slow to boot and only starts playing several seconds 
after i power-up the board.

I know there's already products that have the same functionnality on the 
market, but I want to learn for fun how everything is made and create my own 
product.

My next goal will be to make it play DVDs (once I get a cheap LCD), or rip 
audio CDs right on the hard drive connected to it, or diagnose what's wrong 
with my car (vag-com) or whatever I can think of.

-- 
Michel Belleau <michel.belleau at malaiwah.com>


From rminnich at lanl.gov  Tue Aug 12 09:16:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 12 09:16:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030812103627.GA1759@suse.de>
Message-ID: <Pine.LNX.4.44.0308120729470.3381-100000@maxroach.lanl.gov>

On Tue, 12 Aug 2003, Stefan Reinauer wrote:

> Emulation and ADLO go hand in hand I think. There are 2 different
> problems to be addressed:

I'm not so sure. The emulation code supports the INT functions needed for 
vga setup. I would actually be inclined to dump ADLO rombios.c completely 
and replace it with real C code. 

ADLO is a great proof-of-concept but after walking the code I find too 
much assembly in there, most of it not needed.

It's the bochs heritage. 

If you look at the x86 emulator in the freebios tree, you can see it 
supports emulation and in addition provides (in normal C, not bcc) 32-bit 
functions for vga calls to the bios.

>  1) x86 realmode code execution.
>  2) legacy api emulation/implementation (pcibios, etc)
> 
> * LinuxBIOS1 on x86 supports 1) directly and does 2 with an emulation
>   (pcibios.c)

I'm not sure I agree with your definitions. 

Emulation means (to me) emulating an x86 via software instruction decoding 
and execution. 

the pcibios code is not doing emulation --  it is supporting pcibios 
functions, albeit in 32-bit mode. 

While the x86emu will fit in with etherboot, it won't fit in with a linux 
kernel. 

ron



From rminnich at lanl.gov  Tue Aug 12 09:19:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 12 09:19:00 2003
Subject: DIP2PLCC
In-Reply-To: <200308121132.h7CBWiH3008080@enterprise2.newlogic.at>
Message-ID: <Pine.LNX.4.44.0308120735470.3381-100000@maxroach.lanl.gov>

On Tue, 12 Aug 2003, Niki Waibel wrote:

> currently (afaik) noone has tried to get linuxbios
> working like this. (if i am wrong then pls tell me!)
> the plan is to have linuxbios, the kernel and a small
> rootfs in this m-systems chip (MD-2802-D08-V3 = 8MByte -- can boot
> linuxbios on DIP motherboards, MD-2202-D128-V3 = 128MB --
> but i've heard on this list that it is not possible to
> boot linuxbios with this chip... we'll see ;-) ).
> the chip will sit on the DIP2PLCC converter.
> the converter sits on the BIOS Savior in its first stage
> (to program the msystems chip easyly). and the BIOS Savior
> is plugged into the mainboard instead of the bios chip.

I am glad you are doing this. We did in fact do this 3 years ago for SC 
2000. It's a very nice way to go. Also, Andrew Ip ships DOCs formatted 
this way from cwlinux.com

ron



From rminnich at lanl.gov  Tue Aug 12 09:22:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 12 09:22:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030812115132.GA3414@suse.de>
Message-ID: <Pine.LNX.4.44.0308120737510.3381-100000@maxroach.lanl.gov>

On Tue, 12 Aug 2003, Stefan Reinauer wrote:

> I looked at the official x86emu code at 
> ftp://ftp.scitechsoft.com/devel/x86emu/x86emu-0.8.tar.gz

I wonder if my bug fixes ever made it in. They had some "issues"  (well,
bugs) with prefix 0x66 instruction parsing.

hmm.

> This contains something pretty similar than what we need in the v86bios
> directory. It's a bios emulation that either plugs into vm86 or x86emu.

OK you lost me. This is an emulator for the x86, that can parse x86 binary 
instruction streams, or this is a BIOS emulator? 

> compiling v86bios.vm86 from above I get everything into 20k.

I'll yank it down and take a look.

thanks

ron



From rminnich at lanl.gov  Tue Aug 12 09:25:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 12 09:25:01 2003
Subject: DIP2PLCC
In-Reply-To: <1060695002.3f38ebda73e0b@www.malaiwah.com>
Message-ID: <Pine.LNX.4.44.0308120742000.3381-100000@maxroach.lanl.gov>

On Tue, 12 Aug 2003, Michel Belleau wrote:

> My first goal is to make it boot in 3 seconds (i think linuxbios can help me 
> achieve it) and start to play mp3's from whatever will be connected to it (for 
> instance, an old hard drive and/or a dvd-rom drive). The mb will feed the audio 
> to the VWCDPIC and the VWCDPIC will feed the commands from my oem head-unit to 
> the computer (rs-232).

If you do this we'll put you and pictures of your stuff on linuxbios.org 
web page :-)

ron



From deyasis at yahoo.co.in  Tue Aug 12 09:34:00 2003
From: deyasis at yahoo.co.in (=?iso-8859-1?q?deya=20privi?=)
Date: Tue Aug 12 09:34:00 2003
Subject: PXA255?
Message-ID: <20030812135125.29118.qmail@web8202.mail.in.yahoo.com>

Hi,
     Does linuxbios support Intels Xsxale PxA255?

________________________________________________________________________
Yahoo! India Promos: Win TVs, Bikes, DVD players & more!
Go to http://in.promos.yahoo.com


From rminnich at lanl.gov  Tue Aug 12 09:49:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 12 09:49:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308120737510.3381-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.44.0308120804310.3381-100000@maxroach.lanl.gov>

On Tue, 12 Aug 2003, ron minnich wrote:

> > compiling v86bios.vm86 from above I get everything into 20k.

not the emulator, surely. Just the bios support code, right? 

Let's get our terms right.

BIOS support code -> the code in ADLO, or the linuxbios support code, that 
	provides BIOS support functions to expansion roms
emulator -> A software program that can interpret x86 instruction streams 
	and execute them

Let's stop using the term 'BIOS emulation' -- it's way too confusing!

The x86 emulator need to support the needs of an expansion rom bios is ca. 
150K at best. 

The BIOS support code is tiny -- I'm not surprised at 20k.

ron



From michel.belleau at malaiwah.com  Tue Aug 12 10:00:01 2003
From: michel.belleau at malaiwah.com (Michel Belleau)
Date: Tue Aug 12 10:00:01 2003
Subject: DIP2PLCC
In-Reply-To: <Pine.LNX.4.44.0308120735470.3381-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308120735470.3381-100000@maxroach.lanl.gov>
Message-ID: <1060697870.3f38f70e4c4c7@www.malaiwah.com>

Selon ron minnich <rminnich at lanl.gov>:

> I am glad you are doing this. We did in fact do this 3 years ago for SC 
> 2000. It's a very nice way to go. Also, Andrew Ip ships DOCs formatted 
> this way from cwlinux.com

Does Andrew have any HOWTO on how it must be formatted?

-- 
Michel Belleau <michel.belleau at malaiwah.com>


From stepan at suse.de  Tue Aug 12 10:03:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Aug 12 10:03:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308120737510.3381-100000@maxroach.lanl.gov>
References: <20030812115132.GA3414@suse.de> <Pine.LNX.4.44.0308120737510.3381-100000@maxroach.lanl.gov>
Message-ID: <20030812142014.GA3767@suse.de>

* ron minnich <rminnich at lanl.gov> [030812 15:39]:
> On Tue, 12 Aug 2003, Stefan Reinauer wrote:
> I wonder if my bug fixes ever made it in. They had some "issues"  (well,
> bugs) with prefix 0x66 instruction parsing.

Don't know, but this version is from 2001. It also does not contain the
latest fixes from xfree (which is using it, too) either.

> > This contains something pretty similar than what we need in the v86bios
> > directory. It's a bios emulation that either plugs into vm86 or x86emu.
> 
> OK you lost me. This is an emulator for the x86, that can parse x86 binary 
> instruction streams, or this is a BIOS emulator? 
 
x86emu in general is the x86 emulator. But the source tar ball comes
with this little program written by the XFree86-Developer Egbert Eich.

* It uses _either_ vm86 mode (on x86 cpus) _or_ x86emu (on non x86 cpus)
  to execute the graphics cards option rom. The cpu code is in either
  x86emu.c or v86.c depending on whether you are on x86 or not.

* it implements an int handler, similar to util/vgabios/ that currently
  only implements int 0x10 and 0x1a. The interrupt handler code is in
  int.c

This application is running in user space, using /dev/mem to access the
rom. When pushing this down to the bios level it could get stripped down
to access the roms and do io directly.

The code is a bit nasty, the Makefile wants to have an s/^\ \ \ \ /\t/
before it works with the gnu make i use and the bison parser does not
compile either, but that is not needed for vbios but only vor the
debugging utilities that Egbert wrote..


Stefan



From stepan at suse.de  Tue Aug 12 10:10:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Aug 12 10:10:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308120804310.3381-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308120737510.3381-100000@maxroach.lanl.gov> <Pine.LNX.4.44.0308120804310.3381-100000@maxroach.lanl.gov>
Message-ID: <20030812142746.GB3767@suse.de>

* ron minnich <rminnich at lanl.gov> [030812 16:06]:
> On Tue, 12 Aug 2003, ron minnich wrote:
> 
> > > compiling v86bios.vm86 from above I get everything into 20k.
> 
> not the emulator, surely. Just the bios support code, right? 
 
yes.

> The x86 emulator need to support the needs of an expansion rom bios is ca. 
> 150K at best. 
 
> The BIOS support code is tiny -- I'm not surprised at 20k.

But that 20k is all you ever need on x86 machines. the 150k are still
useful for non-x86 platforms out there where 150k of flash are probably
cheaper than buying hardware that is reported to work without option
rom. Most non-x86 platforms come with bigger eeproms than average x86
machines anyways.
Gzip on testbios (full blown x86emu + bios support code) shrinks the size 
from 150k down to 53k here.

Stefan




From stepan at suse.de  Tue Aug 12 10:19:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Aug 12 10:19:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308120729470.3381-100000@maxroach.lanl.gov>
References: <20030812103627.GA1759@suse.de> <Pine.LNX.4.44.0308120729470.3381-100000@maxroach.lanl.gov>
Message-ID: <20030812143609.GC3767@suse.de>

* ron minnich <rminnich at lanl.gov> [030812 15:33]:
> On Tue, 12 Aug 2003, Stefan Reinauer wrote:
> 
> I'm not so sure. The emulation code supports the INT functions needed for 
> vga setup. I would actually be inclined to dump ADLO rombios.c completely 
> and replace it with real C code. 
 
which is what the freebios1 bioscall code and util/vgabios/testbios do
already, just in a non-complete way.

> ADLO is a great proof-of-concept but after walking the code I find too 
> much assembly in there, most of it not needed.

> It's the bochs heritage. 

definitely. they put a lot of focus on having all the fixed address bios
entries at the right place, but we hopefully dont need that to
initialize vga (at least the milo x86 emulation code never did that)
 
> If you look at the x86 emulator in the freebios tree, you can see it 
> supports emulation and in addition provides (in normal C, not bcc) 32-bit 
> functions for vga calls to the bios.
> 
> >  1) x86 realmode code execution.
> >  2) legacy api emulation/implementation (pcibios, etc)
> > 
> > * LinuxBIOS1 on x86 supports 1) directly and does 2 with an emulation
> >   (pcibios.c)
> 
> I'm not sure I agree with your definitions. 
> 
> Emulation means (to me) emulating an x86 via software instruction decoding 
> and execution. 
 
I used emulation in addition when calling 32bit C code instead of a
16bit bios interrupt. Just replace this with "legacy support code" then.

> the pcibios code is not doing emulation --  it is supporting pcibios 
> functions, albeit in 32-bit mode. 
 
> While the x86emu will fit in with etherboot, it won't fit in with a linux 
> kernel. 

I agree, but it is still a really big step forward. When you want video
support, you either have network or a disk or a completely custom
application without linux anyways. 

Stefan




From Antony at Soft-Solutions.co.uk  Tue Aug 12 10:34:00 2003
From: Antony at Soft-Solutions.co.uk (Antony Stone)
Date: Tue Aug 12 10:34:00 2003
Subject: DIP2PLCC
In-Reply-To: <1060697870.3f38f70e4c4c7@www.malaiwah.com>
References: <Pine.LNX.4.44.0308120735470.3381-100000@maxroach.lanl.gov> <1060697870.3f38f70e4c4c7@www.malaiwah.com>
Message-ID: <200308121451.h7CEpi024842@agate.rockstone.co.uk>

On Tuesday 12 August 2003 3:17 pm, Michel Belleau wrote:

> Selon ron minnich <rminnich at lanl.gov>:
> > I am glad you are doing this. We did in fact do this 3 years ago for SC
> > 2000. It's a very nice way to go. Also, Andrew Ip ships DOCs formatted
> > this way from cwlinux.com
>
> Does Andrew have any HOWTO on how it must be formatted?

I wrote an article for Linux User magazine a few months ago which explained 
how to put LinuxBios into a DoC, and I just about managed to get some 
instructions on formatting the root fs into the DoC at the end of the article.

http://www.linux-magazine.com/issue/28/LinuxBIOS.pdf

Hope it's useful for you...

Regards,

Antony.

-- 

Ramdisk is not an installation procedure.


From michel.belleau at malaiwah.com  Tue Aug 12 10:54:01 2003
From: michel.belleau at malaiwah.com (Michel Belleau)
Date: Tue Aug 12 10:54:01 2003
Subject: VGA BIOS on EPIA 800
Message-ID: <1060701099.3f3903ab3a36b@www.malaiwah.com>

Hi everyone,

I checked everywhere but I can't seem to find any real information about this..

The current status of LinuxBIOS on the EPIA 800 seems to lack vga output (only 
serial)? On some other site, I found out that it could work but I should 
extract the VGABIOS out of the current BIOS and inject it somewhere on the 
flash (?!). How can I extract the current vga bios on my epia800?

I don't have my millenium chip and its adapter yet, but I'm gathering 
informations right now, just to know what to do once I receive them.

Thanks a lot to everyone.

-- 
Michel Belleau <michel.belleau at malaiwah.com>


From jeff at planetfall.com  Tue Aug 12 11:10:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Tue Aug 12 11:10:01 2003
Subject: VGA BIOS on EPIA 800
In-Reply-To: <1060701099.3f3903ab3a36b@www.malaiwah.com>
References: <1060701099.3f3903ab3a36b@www.malaiwah.com>
Message-ID: <20030812152738.GA5881@planetfall.com>

The EPIA HOWTO has instructions on how to extract the BIOS, enable VGA
support, etc.

On Tue, Aug 12, 2003 at 11:11:39AM -0400, Michel Belleau wrote:
> Hi everyone,
> 
> I checked everywhere but I can't seem to find any real information about this..
> 
> The current status of LinuxBIOS on the EPIA 800 seems to lack vga output (only 
> serial)? On some other site, I found out that it could work but I should 
> extract the VGABIOS out of the current BIOS and inject it somewhere on the 
> flash (?!). How can I extract the current vga bios on my epia800?
> 
> I don't have my millenium chip and its adapter yet, but I'm gathering 
> informations right now, just to know what to do once I receive them.
> 
> Thanks a lot to everyone.


From steve at nexpath.com  Tue Aug 12 11:14:00 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Tue Aug 12 11:14:00 2003
Subject: VGA BIOS on EPIA 800
In-Reply-To: <1060701099.3f3903ab3a36b@www.malaiwah.com>
References: <1060701099.3f3903ab3a36b@www.malaiwah.com>
Message-ID: <3F390A61.4050104@nexpath.com>

Michel Belleau wrote:

> The current status of LinuxBIOS on the EPIA 800 seems to lack vga output (only 
> serial)?

This is true AFAIK; I tried a few times to find the handles to enable 
legacy VGA on this board and came up without success.

As I said, if I could just get a little more time to work on it...

The hard thing about VGA is that you can be 100 register settings off, 
or 1 bit in one register off, and the result is the same, a black screen.

I don't know about the VGABIOS, maybe others can help on that.

-Steve



From rminnich at lanl.gov  Tue Aug 12 11:18:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 12 11:18:01 2003
Subject: DIP2PLCC
In-Reply-To: <1060697870.3f38f70e4c4c7@www.malaiwah.com>
Message-ID: <Pine.LNX.4.44.0308120935260.4234-100000@maxroach.lanl.gov>

the sis630- howto has some discussion of MTD.

you can format MTD as anything -- ext3 for example, or a compressed file 
system.

ron



From rminnich at lanl.gov  Tue Aug 12 11:21:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 12 11:21:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030812142746.GB3767@suse.de>
Message-ID: <Pine.LNX.4.44.0308120937261.4234-100000@maxroach.lanl.gov>

well, 20K of full bios support answers one of Eric's objections ;-)

but we still need callbacks, right?

Still this is promising if emulator + bios gets to 53K, still rather 
large, but interesting.

Stefan, do you plan to test this? anyone else?

ron



From rminnich at lanl.gov  Tue Aug 12 11:23:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 12 11:23:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030812143609.GC3767@suse.de>
Message-ID: <Pine.LNX.4.44.0308120940210.4234-100000@maxroach.lanl.gov>

On Tue, 12 Aug 2003, Stefan Reinauer wrote:

> I agree, but it is still a really big step forward. When you want video
> support, you either have network or a disk or a completely custom
> application without linux anyways. 

yes. Do you think we should test this as an ELF payload?

ron



From michel.belleau at malaiwah.com  Tue Aug 12 13:08:01 2003
From: michel.belleau at malaiwah.com (Michel Belleau)
Date: Tue Aug 12 13:08:01 2003
Subject: VGA BIOS on EPIA 800
In-Reply-To: <20030812152738.GA5881@planetfall.com>
References: <1060701099.3f3903ab3a36b@www.malaiwah.com> <20030812152738.GA5881@planetfall.com>
Message-ID: <1060709159.3f392327be059@www.malaiwah.com>

Selon Jeff Noxon <jeff at planetfall.com>:

> The EPIA HOWTO has instructions on how to extract the BIOS, enable VGA
> support, etc.

That's the answer I read everywhere.. But where is the EPIA HOWTO located on 
the web?
-- 
Michel Belleau <michel.belleau at malaiwah.com>


From jeff at planetfall.com  Tue Aug 12 13:17:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Tue Aug 12 13:17:00 2003
Subject: VGA BIOS on EPIA 800
In-Reply-To: <1060709159.3f392327be059@www.malaiwah.com>
References: <1060701099.3f3903ab3a36b@www.malaiwah.com> <20030812152738.GA5881@planetfall.com> <1060709159.3f392327be059@www.malaiwah.com>
Message-ID: <20030812173426.GA9683@planetfall.com>

It's not on the web.  It's in CVS under HOWTO/EPIA.

On Tue, Aug 12, 2003 at 01:25:59PM -0400, Michel Belleau wrote:
> > The EPIA HOWTO has instructions on how to extract the BIOS, enable VGA
> > support, etc.
> 
> That's the answer I read everywhere.. But where is the EPIA HOWTO located on 
> the web?


From stepan at suse.de  Tue Aug 12 15:29:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Aug 12 15:29:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308120940210.4234-100000@maxroach.lanl.gov>; from rminnich@lanl.gov on Tue, Aug 12, 2003 at 09:40:35AM -0600
References: <20030812143609.GC3767@suse.de> <Pine.LNX.4.44.0308120940210.4234-100000@maxroach.lanl.gov>
Message-ID: <20030812214645.A4768@suse.de>

* ron minnich <rminnich at lanl.gov> [030812 17:40]:
> > I agree, but it is still a really big step forward. When you want video
> > support, you either have network or a disk or a completely custom
> > application without linux anyways. 
> 
> yes. Do you think we should test this as an ELF payload?

I'll look into this. vm86.c uses the vm86old linux systemcall to run
realmode code. I'll try to use the realmode idt code that is already in
linuxbios1 instead.

  Stefan

-- 
Architecture Team
    SuSE Linux AG


From michel.belleau at malaiwah.com  Tue Aug 12 16:09:00 2003
From: michel.belleau at malaiwah.com (Michel Belleau)
Date: Tue Aug 12 16:09:00 2003
Subject: VGA BIOS on EPIA 800
In-Reply-To: <20030812173426.GA9683@planetfall.com>
References: <1060701099.3f3903ab3a36b@www.malaiwah.com> <20030812152738.GA5881@planetfall.com> <1060709159.3f392327be059@www.malaiwah.com> <20030812173426.GA9683@planetfall.com>
Message-ID: <1060719977.3f394d69bd4f3@www.malaiwah.com>

Selon Jeff Noxon <jeff at planetfall.com>:

> It's not on the web.  It's in CVS under HOWTO/EPIA.

Hehehe.. That's why I haven't found it yet! Thanks a lot!

-- 
Michel Belleau <michel.belleau at malaiwah.com>


From rogerxxmaillist at speakeasy.net  Tue Aug 12 17:45:00 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Tue Aug 12 17:45:00 2003
Subject: smp, newconfig, hdama
In-Reply-To: <Pine.LNX.4.44.0308102006450.21757-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308102006450.21757-100000@maxroach.lanl.gov>
Message-ID: <1060588939.15850.8.camel@localhost3.localdomain>

On Sun, 2003-08-10 at 19:07, ron minnich wrote:
> On Sun, 10 Aug 2003, Bari Ari wrote:
> 
> > The IBM A22-M uses the Intel 440BX chipset with the ATI Mobility Rage M3 
> > for graphics. The 440BX is supported by LinuxBIOS and the VideoBIOS can 
> > be extracted from the flash in the unit. Find out what they use for a 
> > keyboard controller/superI/O and it may be workable. It may be one of 
> > the Renasas (Hitachi) IKAP family.
> 
> The two unknowable issues with IBM:
> - enable SPD
> - enable FLASH write

I thought the openbios/devbios code that i posted and made reference to
had the corresponding addresses for enabling flash write for the i440bx
chipset? (or is this another issue?  ...i thought it was really an mtd
issue.)

> 
> they refuse to tell us.
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
-- 

Roger
http://www.eskimo.com/~roger/index.html



From ollie at sis.com.tw  Tue Aug 12 21:16:01 2003
From: ollie at sis.com.tw (=?big5?B?wGSl37lG?=)
Date: Tue Aug 12 21:16:01 2003
Subject: VGABIOS
References: <1060689886.1413.8.camel@toshiba.loopback>
Message-ID: <040b01c3613a$ef190e60$0201a8c0@ollie>

That code is obselete long time ago. All the knowledge in the ugly ASM code
has been
translated to C in the SiSFB_Lite. Beware that the ASM  only deal with mode
setting
which is far awary from a complete VGABIOS implementation.

----- Original Message ----- 
From: "Luis Pacheco" <lpacheco at netvisao.pt>
To: <linuxbios at clustermatic.org>
Sent: Tuesday, August 12, 2003 8:04 PM
Subject: VGABIOS


Hi there,

I'm reading your discussion about building an vgabios... and i discover
this link with an vgabios for SiS systems... It could be a good example
to start something .... At this moment i'm trying to convert the source
from masm to as86 and C...

http://openbios.infra.de/archiv/2000-06/0071.html

Best Regards,

-- 
Luis Andr? Pacheco
http://www.neuralbit.com

_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios




From ollie at sis.com.tw  Tue Aug 12 21:37:00 2003
From: ollie at sis.com.tw (???)
Date: Tue Aug 12 21:37:00 2003
Subject: Supporting extension ROMs and beyond...
References: <Pine.LNX.4.44.0308111721350.30099-100000@maxroach.lanl.gov> <3F38299B.5060701@onelabs.com>
Message-ID: <045901c3613d$f6e15e10$0201a8c0@ollie>

For integrated chipsets, I think you have to go the ADLO way. The space for
integrated BIOS
is very tight (256KB for System + VGA instead of System along) such that it
is a common
practice to make VGA BIOS as a compressed "payload" of System BIOS. The only
thing
knows where and how to uncompress the VGA BIOS part is the System BIOS.

----- Original Message ----- 
From: "Bari Ari" <bari at onelabs.com>
To: "ron minnich" <rminnich at lanl.gov>
Cc: "Steve Gehlbach" <steve at nexpath.com>; "Eric W. Biederman"
<ebiederman at lnxi.com>; "SONE Takeshi" <ts1 at tsn.or.jp>; "Stefan Reinauer"
<stepan at suse.de>; <linuxbios at clustermatic.org>
Sent: Tuesday, August 12, 2003 7:41 AM
Subject: Re: Supporting extension ROMs and beyond...


> ron minnich wrote:
>
> >Fair use says, I think, that you can copy a bios from your machine to
your
> >machine for personal use. Certainly that's what you do when you load a
new
> >bios image from a web site. You can't distribute it. So ADLO supports
> >getting the VGA bios out of your on-card bios and building it into
> >linuxbios. That's how it is done: copy it from your machine to your
> >machine.
> >
> >VGABIOS, on the other hand, just finds the on-card bios and runs it.
> >
> >
> >
> Does this mean that VGABIOS would not work for boards that have
> integrated video and have the video BIOS combined into the system BIOS?
>
> Bari
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>




From rminnich at lanl.gov  Tue Aug 12 22:12:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 12 22:12:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <045901c3613d$f6e15e10$0201a8c0@ollie>
Message-ID: <Pine.LNX.4.44.0308122027590.8276-100000@maxroach.lanl.gov>

Ollie can't we use the x86 emulator + bios support? 

I am sympathetic to Eric's concerns about callbacks, in spite of my having 
written callback support into the vgabios for linuxbios. It's so easy to 
lose control of that vgabios off running on its own. It seems like the 
emulator would let us keep things under control.

ron



From stepan at suse.de  Tue Aug 12 22:56:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Aug 12 22:56:01 2003
Subject: smp, newconfig, hdama
In-Reply-To: <1060588939.15850.8.camel@localhost3.localdomain>; from rogerxxmaillist@speakeasy.net on Mon, Aug 11, 2003 at 01:02:20AM -0700
References: <Pine.LNX.4.44.0308102006450.21757-100000@maxroach.lanl.gov> <1060588939.15850.8.camel@localhost3.localdomain>
Message-ID: <20030813051213.A7180@suse.de>

* Roger <rogerxxmaillist at speakeasy.net> [030811 10:02]:
> > The two unknowable issues with IBM:
> > - enable SPD
> > - enable FLASH write
> 
> I thought the openbios/devbios code that i posted and made reference to
> had the corresponding addresses for enabling flash write for the i440bx
> chipset? (or is this another issue?  ...i thought it was really an mtd
> issue.)
  
devbios generally knows how to do this for certain chipsets, including
the 440. Unfortunately some mainboard vendors additionaly protect flash
write with some undocumented GPIO circuit, so supporting the chipset
alone is not enough. There is not much you can do except gnireenigne 
esrever existing firmware or trying out all possible GPIO lines (and
combine them etc) The first is probably illegal in some countries, the
second might destroy your hardware, esp. on laptops.

  Stefan

-- 
Architecture Team
    SuSE Linux AG


From rminnich at lanl.gov  Tue Aug 12 23:10:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 12 23:10:00 2003
Subject: smp, newconfig, hdama
In-Reply-To: <20030813051213.A7180@suse.de>
Message-ID: <Pine.LNX.4.44.0308122122240.8276-100000@maxroach.lanl.gov>

On Wed, 13 Aug 2003, Stefan Reinauer wrote:

> devbios generally knows how to do this for certain chipsets, including
> the 440. Unfortunately some mainboard vendors additionaly protect flash
> write with some undocumented GPIO circuit, so supporting the chipset
> alone is not enough. There is not much you can do except gnireenigne 
> esrever existing firmware or trying out all possible GPIO lines (and
> combine them etc) The first is probably illegal in some countries, the
> second might destroy your hardware, esp. on laptops.

I did in fact try all GPIO combinations on the T23 GPIO lines, as well as
on the T22.  Interestingly enough, some of them will reset the laptop. But
I never found the combination, after much work, that would open up SPD or 
enable FLASH write. Some of these designers put an extra flipflop in such 
that the control bits are "sticky" -- you can turn the SPD off, for 
example, but not back on.

We found out how to do this type of thing on the L440GX, and the hardware 
was not simple.

ron





From steve at nexpath.com  Tue Aug 12 23:48:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Tue Aug 12 23:48:01 2003
Subject: smp, newconfig, hdama
In-Reply-To: <20030813051213.A7180@suse.de>
References: <Pine.LNX.4.44.0308102006450.21757-100000@maxroach.lanl.gov> <1060588939.15850.8.camel@localhost3.localdomain> <20030813051213.A7180@suse.de>
Message-ID: <3F39B925.8070709@nexpath.com>

Stefan Reinauer wrote:
> There is not much you can do except gnireenigne
> esrever existing firmware 
>   Stefan
> 

That's it, gnireenigne esrever, perfectly legal in the US (Sony v 
Connectix) as long as the code is not encrypted for copy protection or 
content access protection (DMCA).  Even then it is okay for developing 
interoperable software, but Judge Kaplan in the DeCSS case wrote that 
the law did not permit you to disseminate the information you gained 
from gnireenigne esrever (in the case of encryption).

-Steve





From sc at flagen.com  Wed Aug 13 17:21:00 2003
From: sc at flagen.com (David Hendricks)
Date: Wed Aug 13 17:21:00 2003
Subject: Memory on EPIA
Message-ID: <51619.128.165.250.195.1060809796.squirrel@mail.flagen.com>

I was wondering what kind of memory you all were using for your EPIAs and
if anyone has been tweaking things like memory timings in their freebios
tree.

I've been using Corsair PC-133 cas latency 2 memory modules (Specs here:
http://www.corsairmicro.com/main/products/specs/cm654s256.html ) without
modification to any epia code in my tree. However, I keep getting stuck at
the "jumping to boot code" message in elfboot with via-rhine and memtest
payloads.

I have lots of RAM at my disposal, but would like to know if there's a
specific type that seems to work best.


From jeff at planetfall.com  Wed Aug 13 17:46:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Wed Aug 13 17:46:01 2003
Subject: Memory on EPIA
In-Reply-To: <51619.128.165.250.195.1060809796.squirrel@mail.flagen.com>
References: <51619.128.165.250.195.1060809796.squirrel@mail.flagen.com>
Message-ID: <20030813220403.GA11425@planetfall.com>

I'm using a single Crucial 512MB CL3 DIMM.   CT64M64S4D75.16LT

Works fine.  I'm using an Eden processor @ 533 MHz.  I have thought about
adding another identical DIMM, but haven't done it yet.  On a side note,
if you order from Crucial you may want to do it via phone.  I ordered
online using their memory configurator and they sent me a DIMM that was
too tall to fit in my Morex case.  They replaced it, but it was a hassle.

Regards,

Jeff

On Wed, Aug 13, 2003 at 02:23:16PM -0700, David Hendricks wrote:
> I was wondering what kind of memory you all were using for your EPIAs and
> if anyone has been tweaking things like memory timings in their freebios
> tree.
> 
> I've been using Corsair PC-133 cas latency 2 memory modules (Specs here:
> http://www.corsairmicro.com/main/products/specs/cm654s256.html ) without
> modification to any epia code in my tree. However, I keep getting stuck at
> the "jumping to boot code" message in elfboot with via-rhine and memtest
> payloads.
> 
> I have lots of RAM at my disposal, but would like to know if there's a
> specific type that seems to work best.


From sc at flagen.com  Wed Aug 13 18:59:01 2003
From: sc at flagen.com (David Hendricks)
Date: Wed Aug 13 18:59:01 2003
Subject: Questions to the experts
In-Reply-To: <Pine.LNX.4.44.0308101757450.20943-100000@maxroach.lanl.gov>
References: <20030730190256.68672.qmail@web10910.mail.yahoo.com> 
     <Pine.LNX.4.44.0308101757450.20943-100000@maxroach.lanl.gov>
Message-ID: <52141.128.165.250.195.1060815686.squirrel@mail.flagen.com>

> On Wed, 30 Jul 2003, lisa stout wrote:
>
>> 1) Does Linux support IPMI? If so how?
>
> sure.
>
> I don't know where the tools are.

There's an IPMI section in the 2.6 kernel under "character devices." I
haven't searched for tools, though...


From jeff at planetfall.com  Wed Aug 13 19:04:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Wed Aug 13 19:04:00 2003
Subject: EPIA Linuxbios strangeness
In-Reply-To: <20030811144204.GA24442@planetfall.com>
References: <20030811144204.GA24442@planetfall.com>
Message-ID: <20030813232138.GA15729@planetfall.com>

The reset button turned out to be a bad connection.

I still can't reboot the system under software control.  Anyone?

Thanks,

Jeff

On Mon, Aug 11, 2003 at 09:42:04AM -0500, Jeff Noxon wrote:
> 2) I can't do a software reboot either.  The machine just goes dead if
> I try "init 6" or any variation of the reboot command.
> 
> 3) If I unplug it & plug it back in, the power stays off.


From rminnich at lanl.gov  Thu Aug 14 00:20:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 00:20:01 2003
Subject: EPIA Linuxbios strangeness
In-Reply-To: <20030813232138.GA15729@planetfall.com>
Message-ID: <Pine.LNX.4.44.0308132237180.18293-100000@maxroach.lanl.gov>

On Wed, 13 Aug 2003, Jeff Noxon wrote:

> I still can't reboot the system under software control.  Anyone?

you're going to have to figure out how to make those chips assert pci 
reset. Once you get it, tell me :-)

ron



From aip at cwlinux.com  Thu Aug 14 02:08:00 2003
From: aip at cwlinux.com (Andrew Ip)
Date: Thu Aug 14 02:08:00 2003
Subject: EPIA Linuxbios strangeness
In-Reply-To: <Pine.LNX.4.44.0308132237180.18293-100000@maxroach.lanl.gov>; from ron minnich on Wed, Aug 13, 2003 at 10:37:39PM -0600
References: <20030813232138.GA15729@planetfall.com> <Pine.LNX.4.44.0308132237180.18293-100000@maxroach.lanl.gov>
Message-ID: <20030814142601.A25807@mail.cwlinux.com>

Hi,

> you're going to have to figure out how to make those chips assert pci 
> reset. Once you get it, tell me :-)
I don't have this reset problem.

-Andrew

-- 
Andrew Ip
Email:  aip at cwlinux.com
Tel:    (852) 2542 2046
Fax:    (852) 2542 2036
Mobile: (852) 9201 9866

Cwlinux Limited
Unit 202B 2/F Lai Cheong Factory Building,
479-479A Castle Peak Road,
Lai Chi Kok, Kowloon,
Hong Kong.

For public pgp key, please obtain it from http://www.keyserver.net/en.


From rogerxxmaillist at speakeasy.net  Thu Aug 14 07:13:01 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Thu Aug 14 07:13:01 2003
Subject: l440bx compiling errors
Message-ID: <1060860513.27596.30.camel@localhost3.localdomain>

 l440bx $ make
gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s 
gcc ... -o crt0.o crt0.s
/home/roger/src/linuxbios/freebios/src/northbridge/intel/440bx/raminit.inc: Assembler messages:
/home/roger/src/linuxbios/freebios/src/northbridge/intel/440bx/raminit.inc:478: Warning: using `%al' instead of `%eax' due to `b' suffix
crt0.S:156: Warning: indirect jmp without `*'
gcc ... -o version.o
/home/roger/src/linuxbios/freebios/src/lib/version.c
gcc ... -o ide.o /home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:27: parse error
before '<<' token
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:31: parse error
before '>>' token
In file included from
/home/roger/src/linuxbios/freebios/src/include/pci.h:280,
                 from
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:32:
/home/roger/src/linuxbios/freebios/src/include/types.h:7: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/types.h:7: warning: type
defaults to `int' in declaration of `u8'
/home/roger/src/linuxbios/freebios/src/include/types.h:7: warning: data
definition has no type or storage class
In file included from
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:32:
/home/roger/src/linuxbios/freebios/src/include/pci.h:325: parse error
before "uint8_t"
/home/roger/src/linuxbios/freebios/src/include/pci.h:325: warning: no
semicolon at end of struct or union
/home/roger/src/linuxbios/freebios/src/include/pci.h:346: parse error
before '}' token
/home/roger/src/linuxbios/freebios/src/include/pci.h:349: parse error
before "bus"
/home/roger/src/linuxbios/freebios/src/include/pci.h:350: parse error
before "bus"
/home/roger/src/linuxbios/freebios/src/include/pci.h:351: parse error
before "bus"
/home/roger/src/linuxbios/freebios/src/include/pci.h:352: parse error
before "bus"
/home/roger/src/linuxbios/freebios/src/include/pci.h:353: parse error
before "bus"
/home/roger/src/linuxbios/freebios/src/include/pci.h:354: parse error
before "bus"
/home/roger/src/linuxbios/freebios/src/include/pci.h:377: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:383: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:389: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:411: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:412: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:413: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:414: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:415: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:416: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:417: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:418: parse error
before "u8"
/home/roger/src/linuxbios/freebios/src/include/pci.h:419: parse error
before "u8"
In file included from
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:33:
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:35: parse
error before "uint8_t"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:35: warning:
no semicolon at end of struct or union
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:36: warning:
type defaults to `int' in declaration of `slave'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:36: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:45: parse
error before '}' token
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:77: parse
error before "uint8_t"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:77: warning:
no semicolon at end of struct or union
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:78: warning:
type defaults to `int' in declaration of `sector_count'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:78: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:79: parse
error before "lba_low"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:79: warning:
type defaults to `int' in declaration of `lba_low'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:79: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:80: parse
error before "lba_mid"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:80: warning:
type defaults to `int' in declaration of `lba_mid'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:80: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:81: parse
error before "lba_high"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:81: warning:
type defaults to `int' in declaration of `lba_high'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:81: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:82: parse
error before "device"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:82: warning:
type defaults to `int' in declaration of `device'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:82: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:89: parse
error before "command"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:89: warning:
type defaults to `int' in declaration of `command'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:89: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:90: parse
error before "sector_count2"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:90: warning:
type defaults to `int' in declaration of `sector_count2'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:90: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:91: parse
error before "lba_low2"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:91: warning:
type defaults to `int' in declaration of `lba_low2'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:91: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:92: parse
error before "lba_mid2"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:92: warning:
type defaults to `int' in declaration of `lba_mid2'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:92: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:93: parse
error before "lba_high2"
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:93: warning:
type defaults to `int' in declaration of `lba_high2'
/home/roger/src/linuxbios/freebios/src/include/pc80/ide.h:93: warning:
data definition has no type or storage class
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c: In function
`await_ide':
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:51: warning:
implicit declaration of function `udelay'
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c: In function
`pio_set_registers':
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:101: `uint8_t'
undeclared (first use in this function)
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:101: (Each
undeclared identifier is reported only once
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:101: for each
function it appears in.)
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:101: parse error
before "device"
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:107: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:108: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:115: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:116: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:117: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:118: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:119: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:120: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:121: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:122: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:123: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:124: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c: In function
`ide_read_sector_chs':
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:174: storage size
of `cmd' isn't known
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:182: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:184: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:185: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:190: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:191: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:194: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:174: warning:
unused variable `cmd'
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c: In function
`ide_read_sector_lba':
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:200: storage size
of `cmd' isn't known
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:209: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:212: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:200: warning:
unused variable `cmd'
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c: In function
`ide_read_sector_lba48':
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:218: storage size
of `cmd' isn't known
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:228: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:230: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:218: warning:
unused variable `cmd'
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c: In function
`ide_read_sector':
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:236: invalid use
of undefined type `struct harddisk_info'
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:240: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:243: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:246: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:249: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c: In function
`init_drive':
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:261: storage size
of `cmd' isn't known
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:265: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:266: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:267: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:268: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:269: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:270: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:271: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:272: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:273: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:274: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:276: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:279: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:303: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:306: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:322: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:334: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:350: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:351: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:353: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:354: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:358: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:359: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:364: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:365: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:372: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:373: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:374: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:375: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:376: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:377: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:378: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:379: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:384: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:384: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:384: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:387: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:388: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:394: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:407: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:407: dereferencing
pointer to incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:261: warning:
unused variable `cmd'
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c: In function
`init_controller':
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:461: invalid use
of undefined type `struct harddisk_info'
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c: In function
`ide_init':
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:482: sizeof
applied to an incomplete type
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c: At top level:
/home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:37: storage size
of `harddisk_info' isn't known
make: *** [ide.o] Error 1


-- 

Roger
http://www.eskimo.com/~roger/index.html



From rogerxxmaillist at speakeasy.net  Thu Aug 14 07:24:01 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Thu Aug 14 07:24:01 2003
Subject: smartcore-p3 compiling errors
Message-ID: <1060860515.27596.32.camel@localhost3.localdomain>

smartcore-p3 $ make
Makefile:508: warning: overriding commands for target `nsuperio.o'
Makefile:502: warning: ignoring old commands for target `nsuperio.o'
cp /home/roger/src/linuxbios/freebios/src/arch/i386/config/crt0.base
crt0.S
gcc -x assembler-with-cpp -DASSEMBLY -E ... crt0.S > crt0.s
gcc ... -o crt0.o crt0.s
/home/roger/src/linuxbios/freebios/src/northbridge/intel/440bx/raminit.inc: Assembler messages:
/home/roger/src/linuxbios/freebios/src/northbridge/intel/440bx/raminit.inc:478: Warning: using `%al' instead of `%eax' due to `b' suffix
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:13:
Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:15:
Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:22:
Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:23:
Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:31:
Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:37:
Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:42:
Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:50:
Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:53:
Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:60:
Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram_enable.inc:24: Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram_enable.inc:38: Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram_enable.inc:52: Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram_enable.inc:65: Error: invalid character '_' in mnemonic
/home/roger/src/linuxbios/freebios/src/sdram/generic_sdram_enable.inc:70: Error: invalid character '_' in mnemonic
crt0.S:47: Error: invalid character '_' in mnemonic
crt0.S:154: Error: invalid character '_' in mnemonic
crt0.S:156: Warning: indirect jmp without `*'
make: *** [crt0.o] Error 1



-- 

Roger
http://www.eskimo.com/~roger/index.html



From rogerxxmaillist at speakeasy.net  Thu Aug 14 07:26:01 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Thu Aug 14 07:26:01 2003
Subject: sourceforge cvs hang & incorrect url for cvs-root snapshot tarball
Message-ID: <1060861178.23111.43.camel@localhost3.localdomain>

I'm noticing when checking out the sourceforge freebios cvs, it will
hang on the last file. (fails to close the connect?)

I've also noticed that cvs check-out has been really slow, so I decided
to check-out the cvs snapshot tarball from the download page:
http://www.linuxbios.org/developer/download/index.html

The posted url:
http://cvs.sourceforge.net/cvstarballs/freebios-cvsroot.tar.gz


The working url:
http://cvs.sourceforge.net/cvstarballs/freebios-cvsroot.tar.bz2

(notice that suffix differences ".gz" & ".bz")

-- 

Roger
http://www.eskimo.com/~roger/index.html



From rminnich at lanl.gov  Thu Aug 14 09:31:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 09:31:01 2003
Subject: EPIA Linuxbios strangeness
In-Reply-To: <20030814142601.A25807@mail.cwlinux.com>
Message-ID: <Pine.LNX.4.44.0308140747340.22535-100000@maxroach.lanl.gov>

On Thu, 14 Aug 2003, Andrew Ip wrote:

> > you're going to have to figure out how to make those chips assert pci 
> > reset. Once you get it, tell me :-)
> I don't have this reset problem.

I think overall the EPIA port is shaky. David can't build a working
romimage here. I was able to last decemnber and will try again today.

I think EPIA is a first good candidate for freebios2, dumping assembly and 
going to C.

ron



From rminnich at lanl.gov  Thu Aug 14 09:31:32 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 09:31:32 2003
Subject: l440bx compiling errors
In-Reply-To: <1060860513.27596.30.camel@localhost3.localdomain>
Message-ID: <Pine.LNX.4.44.0308140748440.22535-100000@maxroach.lanl.gov>

On 14 Aug 2003, Roger wrote:

> /home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:27: parse error
> before '<<' token
> /home/roger/src/linuxbios/freebios/src/pc80/ide/ide.c:31: parse error
> before '>>' token

blash. somebody committed ide.c with conflicts in it.

I think we can ask Greg to take a look. baremetal toolkit doesn't build 
either.

ron



From rminnich at lanl.gov  Thu Aug 14 09:33:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 09:33:01 2003
Subject: smartcore-p3 compiling errors
In-Reply-To: <1060860515.27596.32.camel@localhost3.localdomain>
Message-ID: <Pine.LNX.4.44.0308140749420.22535-100000@maxroach.lanl.gov>

On 14 Aug 2003, Roger wrote:

> /home/roger/src/linuxbios/freebios/src/sdram/generic_sdram.inc:13:
> Error: invalid character '_' in mnemonic

yeah, this is due to changes people have made without all testing. 

I'll try to look at this, but it boils down to a debug print macro being 
defined before use.

ron



From rminnich at lanl.gov  Thu Aug 14 09:33:06 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 09:33:06 2003
Subject: sourceforge cvs hang & incorrect url for cvs-root snapshot
 tarball
In-Reply-To: <1060861178.23111.43.camel@localhost3.localdomain>
Message-ID: <Pine.LNX.4.44.0308140750380.22535-100000@maxroach.lanl.gov>

On 14 Aug 2003, Roger wrote:

> I'm noticing when checking out the sourceforge freebios cvs, it will
> hang on the last file. (fails to close the connect?)

sourceforge problem.

ron



From meinrad.sauter at gmx.de  Thu Aug 14 09:36:01 2003
From: meinrad.sauter at gmx.de (Meinrad Sauter)
Date: Thu Aug 14 09:36:01 2003
Subject: Questions on BX Chipset
In-Reply-To: <3F219378.9090104@bitworks.com>
References: <Pine.LNX.4.44.0307251120420.893-100000@maxroach.lanl.gov> <3F219378.9090104@bitworks.com>
Message-ID: <200308141554.11808.meinrad.sauter@gmx.de>

Hi all,

thanks for your answers and sory for the late response (vacancies)

> ron minnich wrote:
> > On Wed, 23 Jul 2003, Meinrad Sauter wrote:
> >>- VGA: The Multitainer has an onboard MPACT2 Graphics adapter. It would
> >> be nice to have, but not really required. From the docs, I think I could
> >> make it work using ADLO or with the builtin VGA support. What do you
> >> think?
> >
> > it would be cool if you would test the builtin VGA support and let us
> > know how it goes.
>
> 2nd that.  Last time I tried the builtin VGA stuff I was unable to get
> it to compile but the problem didn't seem to happen for Ron.  So please
> try the builtin support.  Lots of stuff has changed since then and I
> haven't re-tested.
>
Unfortunately my video BIOS is 128K in size and I couldn't fit it into my 2M 
flash eprom together with ADLO and LinuxBIOS. So I tried the builtin support 
first.
I was able to compile everything OK after either leaving out FRAMEBUFFER=1 in 
the config file or copying the function framebuffer_on from 
northbridge/intel/440GX/northbridge.c to the same file in 
northbridge/intel/440BX

During boot I get the following log on the serial console:

****START LOG*****
LinuxBIOS-1.0.0 Don Aug 14 15:33:05 CEST 2003 starting...
Ram1
Ram2
Ram3
Ram Enable 1
Ram Enable 2
Ram Enable 3
Ram Enable 4
Ram Enable 5
Ram4
Ram5
Ram6
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.0.0 Don Aug 14 15:33:05 CEST 2003 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Scanning PCI bus...PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [8086/7190]
PCI: 00:01.0 [8086/7191]
PCI: 00:07.0 [8086/7110]
PCI: 00:07.1 [8086/7111]
PCI: 00:07.2 [8086/7112]
PCI: 00:07.3 [8086/7113]
PCI: 00:0a.0 [10ec/8139]
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [110b/0004]
PCI: pci_scan_bus returning with max=01
PCI: pci_scan_bus returning with max=01
done
Allocating PCI resources...
ASSIGN RESOURCES, bus 0
PCI: 00:00.0 10 <- [0xe0000000 - 0xefffffff] prefmem
PCI: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io
PCI: 00:01.0 24 <- [0xf8000000 - 0xf7ffffff] bus 1 prefmem
PCI: 00:01.0 20 <- [0xf0000000 - 0xf7ffffff] bus 1 mem
ASSIGN RESOURCES, bus 1
PCI: 01:00.0 10 <- [0xf0000000 - 0xf7ffffff] mem
ASSIGNED RESOURCES, bus 1
PCI: 00:07.1 20 <- [0x00001420 - 0x0000142f] io
PCI: 00:07.2 20 <- [0x00001400 - 0x0000141f] io
PCI: 00:0a.0 10 <- [0x00001000 - 0x000010ff] io
PCI: 00:0a.0 14 <- [0xf8000000 - 0xf80000ff] mem
ASSIGNED RESOURCES, bus 0
Allocating VGA resource
done.
Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06
PCI: 00:01.0 cmd <- 07
PCI: 00:07.0 cmd <- 07
PCI: 00:07.1 cmd <- 01
PCI: 00:07.2 cmd <- 01
PCI: 00:07.3 cmd <- 01
PCI: 00:0a.0 cmd <- 03
PCI: 01:00.0 cmd <- 03
done.
Initializing PCI devices...
PCI devices initialized
totalram: 128M
Initializing CPU #0
Updating microcode
microcode_info: sig = 0x00000686 pf=0x00000010 rev = 0x00000000
Enabling cache...
Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range:  128MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's
call intel_enable_fixed_mtrr()
call intel_enable_var_mtrr()
Leave setup_mtrrs
done.

Max cpuid index    : 2
Vendor ID          : GenuineIntel
Processor Type     : 0x00
Processor Family   : 0x06
Processor Model    : 0x08
Processor Mask     : 0x00
Processor Stepping : 0x06
Feature flags      : 0x0383fbff

Cache/TLB descriptor values: 1 reads required
Desc 0x01 : Instr TLB: 4KB pages, 4-way set assoc, 32 entries
Desc 0x02 : Instr TLB: 4MB pages, fully assoc, 2 entries
Desc 0x03 : Data TLB: 4KB pages, 4-way set assoc, 64 entries
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x41 : L2 Unified cache: 128K bytes, 4-way set assoc, 32 byte line size
Desc 0x08 : Inst cache: 16K bytes, 4-way set assoc, 32 byte line size
Desc 0x04 : Data TLB: 4MB pages, 4-way set assoc, 8 entries
Desc 0x0c : Data cache: 16K bytes, 2-way or 4-way set assoc, 32 byte line size



MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Configuring L2 cache...CPU signature of 680 so no L2 cache configuration
Enable Cache
done.
Disabling local apic...done.
CPU #0 Initialized
intel_mainboard_fixup()
Testing SMI
SMI disabled
Enabling IDE...0x40 = 0x8000
0x42 = 0x8000
Enabled IDE for channels 1 and 2
enabling smbus
enable pm functions
Setting up RTC
RTC Init
Invalid CMOS LB checksum
done.
Enabling extended BIOS access
Enabling Full ISA Mode
Enabling IRQ8
Enabling Mouse IRQ12 on piix4e
done.
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=110b, did=4
0x55 0xaa 0x40 0xea 0xbe 0x31 0x0 0xc0 0x0 0x0 0xc3 0x0 0x14 0x0 0x0 0x0 
biosint: # 0x6, eax 0x0 ebx 0xd5b4 ecx 0x720 edx 0xa2f1
biosint: ebp 0x136ac esp 0xff6 edi 0xf6d4 esi 0xfb9fc
biosint: ip 0x3 cs 0x0 flags 0x46
biosint: Unsupport int #0x6
biosint: # 0x6, eax 0x0 ebx 0xd5b4 ecx 0x720 edx 0xa2f1
biosint: ebp 0x136ac esp 0xff6 edi 0xf6d4 esi 0xfb9fc
biosint: ip 0x3 cs 0x0 flags 0x46
biosint: Unsupport int #0x6
biosint: # 0x6, eax 0x0 ebx 0xd5b4 ecx 0x720 edx 0xa2f1
biosint: ebp 0x136ac esp 0xff6 edi 0xf6d4 esi 0xfb9fc
biosint: ip 0x3 cs 0x0 flags 0x46
biosint: Unsupport int #0x6

*****END LOG *******

Any Ideas what's missing?

Meinrad
-- 
Meinrad Sauter
email: meinrad.sauter at gmx.de



From rminnich at lanl.gov  Thu Aug 14 09:39:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 09:39:01 2003
Subject: Questions on BX Chipset
In-Reply-To: <200308141554.11808.meinrad.sauter@gmx.de>
Message-ID: <Pine.LNX.4.44.0308140755510.22535-100000@maxroach.lanl.gov>

On Thu, 14 Aug 2003, Meinrad Sauter wrote:

> Enabling extended BIOS access
> Enabling Full ISA Mode
> Enabling IRQ8
> Enabling Mouse IRQ12 on piix4e
> done.
> INSTALL REAL-MODE IDT
> DO THE VGA BIOS
> found VGA: vid=110b, did=4
> 0x55 0xaa 0x40 0xea 0xbe 0x31 0x0 0xc0 0x0 0x0 0xc3 0x0 0x14 0x0 0x0 0x0 
> biosint: # 0x6, eax 0x0 ebx 0xd5b4 ecx 0x720 edx 0xa2f1
> biosint: ebp 0x136ac esp 0xff6 edi 0xf6d4 esi 0xfb9fc
> biosint: ip 0x3 cs 0x0 flags 0x46
> biosint: Unsupport int #0x6
> biosint: # 0x6, eax 0x0 ebx 0xd5b4 ecx 0x720 edx 0xa2f1
> biosint: ebp 0x136ac esp 0xff6 edi 0xf6d4 esi 0xfb9fc
> biosint: ip 0x3 cs 0x0 flags 0x46
> biosint: Unsupport int #0x6
> biosint: # 0x6, eax 0x0 ebx 0xd5b4 ecx 0x720 edx 0xa2f1
> biosint: ebp 0x136ac esp 0xff6 edi 0xf6d4 esi 0xfb9fc
> biosint: ip 0x3 cs 0x0 flags 0x46
> biosint: Unsupport int #0x6
> 

yes, sorry, you just hit an int we don't support yet. It's all working 
right, but you'll need to implement int #6. 

These things are pretty easy to write, since the support code is 100% C, 
so you might want to take a hack at it. You can use ADLO code as the 
reference for what to do.

I really think that the ADLO code could be turned into C in a day or so by 
a motivated hacker.

ron



From rminnich at lanl.gov  Thu Aug 14 09:44:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 09:44:01 2003
Subject: smartcore-p3 compiling errors
In-Reply-To: <Pine.LNX.4.44.0308140749420.22535-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.44.0308140801330.22535-100000@maxroach.lanl.gov>

send me your config file, I just built it and it worked fine.

ron



From jeff at planetfall.com  Thu Aug 14 11:25:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Thu Aug 14 11:25:00 2003
Subject: EPIA Linuxbios strangeness
In-Reply-To: <20030814142601.A25807@mail.cwlinux.com>
References: <20030813232138.GA15729@planetfall.com> <Pine.LNX.4.44.0308132237180.18293-100000@maxroach.lanl.gov> <20030814142601.A25807@mail.cwlinux.com>
Message-ID: <20030814154242.GA4152@planetfall.com>

On Thu, Aug 14, 2003 at 02:26:01PM +0800, Andrew Ip wrote:
> Ron Minnich wrote:
> > you're going to have to figure out how to make those chips assert pci 
> > reset. Once you get it, tell me :-)
>
> I don't have this reset problem.

Interesting.  Any suggestions on where I should poke around to help
debug this?

As an aside, I found a Winbond w49f002u chip and decided to back up the
original EPIA BIOS to it.  I had to remove the print statements from the
flash_and_burn w49f002u driver, turn off the chip erase, and program it
repeatedly before it verified correctly!  Apparently that chip is very
timing sensitive!  Aside from that issue, the Winbond chip works fine
on the EPIA.

Thanks,

Jeff


From rminnich at lanl.gov  Thu Aug 14 11:26:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 11:26:01 2003
Subject: EPIA Linuxbios strangeness
In-Reply-To: <20030814154242.GA4152@planetfall.com>
Message-ID: <Pine.LNX.4.44.0308140943091.22535-100000@maxroach.lanl.gov>

On Thu, 14 Aug 2003, Jeff Noxon wrote:
> As an aside, I found a Winbond w49f002u chip and decided to back up the
> original EPIA BIOS to it.  I had to remove the print statements from the
> flash_and_burn w49f002u driver, turn off the chip erase, and program it
> repeatedly before it verified correctly!  Apparently that chip is very
> timing sensitive!  Aside from that issue, the Winbond chip works fine
> on the EPIA.

this seems to be a generic flash programming issue, timing is tricky even 
on parts with clocks.

ron



From meinrad.sauter at gmx.de  Thu Aug 14 11:28:01 2003
From: meinrad.sauter at gmx.de (Meinrad Sauter)
Date: Thu Aug 14 11:28:01 2003
Subject: Questions on BX Chipset
In-Reply-To: <Pine.LNX.4.44.0308140755510.22535-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308140755510.22535-100000@maxroach.lanl.gov>
Message-ID: <200308141745.59136.meinrad.sauter@gmx.de>

> > biosint: Unsupport int #0x6
> > biosint: # 0x6, eax 0x0 ebx 0xd5b4 ecx 0x720 edx 0xa2f1
> > biosint: ebp 0x136ac esp 0xff6 edi 0xf6d4 esi 0xfb9fc
> > biosint: ip 0x3 cs 0x0 flags 0x46
> > biosint: Unsupport int #0x6
>
> yes, sorry, you just hit an int we don't support yet. It's all working
> right, but you'll need to implement int #6.

Fine, I had a look at the code and found out where to implement int #6. 
Unfortunately I have no idea what to implement. Can you point me to some more 
information?
>
> These things are pretty easy to write, since the support code is 100% C,
> so you might want to take a hack at it. You can use ADLO code as the
> reference for what to do.

I looked at that also, but I couldn't find an int #6 implementation there, 
neither in C nor in anything else.



-- 
Meinrad Sauter
email: meinrad.sauter at gmx.de


From nathanael at gnat.ca  Thu Aug 14 11:46:01 2003
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Thu Aug 14 11:46:01 2003
Subject: Questions on BX Chipset
In-Reply-To: <200308141745.59136.meinrad.sauter@gmx.de>
Message-ID: <D7F3095B-CE70-11D7-AEFD-0003931B4D6A@gnat.ca>

On Thursday, August 14, 2003, at 09:45  AM, Meinrad Sauter wrote:
>
> I looked at that also, but I couldn't find an int #6 implementation 
> there,
> neither in C nor in anything else.

from Adam Agnew's email a few weeks ago:

See Ralf Brown's interrupt list:
http://oopweb.com/Assembly/Documents/InterList/Volume2.html


-- 
Nathanael Noblet
Gnat Solutions
4604 Monterey Ave NW
Calgary, AB
T3B 5K4

T/F 403.288.5360
C 403.809.5368

http://www.gnat.ca/



From jeff at planetfall.com  Thu Aug 14 12:32:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Thu Aug 14 12:32:01 2003
Subject: Port to 845 chipset
Message-ID: <20030814164931.GA6548@planetfall.com>

Care to guess how much effort would be required to port LB to the 845
chipset?  I have several of these boxed Intel boards in use in embedded
situations.  I assume (perhaps wrongly) that the Xeon chipsets aren't
all that different.

Thanks

Jeff


From pyro at linuxlabs.com  Thu Aug 14 12:53:00 2003
From: pyro at linuxlabs.com (steven james)
Date: Thu Aug 14 12:53:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308110824040.26375-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.21.0308141258590.23114-100000@ucontrol.mobiledns.com>

Greetings,

One other call for modular binary support is end users. It's one thing to
get them to use a provided tool to flash in one of several mix and match
modules, it's quite a different matter to get them to actually compile
something correctly and then flash it.

An idea I have for baremetal is to have it set up a callback table at the
top of RAM for all of the useful (and possibly hardware
dependant) functions. It's not too much of a leap to make a compile time
decision to either:

1. End up by calling elfload and running baremetal which has it's own
function library
2. link the baremetal setup in static and just call it.

With a bit of designing any payload should potentially be linkable
againmst either LinuxBIOS to be called directly, or an ELF stub to be
called externally.

The stub would likely have something like:

int printk(char *format, ...)
{
	return call_table("printk", format ...);
}

Otherwise, the payload will just link against LinuxBIOS.

The rest would be similar to the way mon can be standalone or linked in to
init for beoboot.

I think some of the different opinions here really come not so much from
philosophical differences as just different goals.

G'day,
sjames

On Mon, 11 Aug 2003, ron minnich wrote:

> On 10 Aug 2003, Eric W. Biederman wrote:
> 
> > I haven't seen the numbers on the dreaded size overhead.  So
> > that argument does not yet convince me.  If I can fit a whole IP/UDP
> > stack a network driver, and printk in 16K I have trouble seeing
> > the problem.
> 
> multiply that by, let's just say 4, for 4 elf payloads for 4 functions. 
> At that point, I can no longer fit a kernel + linuxbios in 1 MB flash. At 
> present I can barely fit one linuxbios + 1 stripped kernel.
> 
> I am right on the edge of being able to fit right now. Either I statically 
> link in the VGABIOS code or I can't fit it. That's the issue for me.
> 
> Yes, I am well aware that we hope to have more compact ROMCC code, but 
> that is not there right now.
> 
> > Most of the things proposed so far are things I am primarily opposed
> > to, at least except way out on the periphery.  Callbacks are bad.
> 
> Callbacks are required if we hope to support VGA. There is no way around 
> this.
> 
> > Binary only code is bad.  
> 
> Binary code support is required for future chipsets that, e.g., build
> wireless into the chipset. There will be many future software radios that
> are in chipsets, and you will not be able to get that in open source --
> the FCC has a few things to say about that. Binary code support is
> inevitable. We won't be able to compile this code in, or build it as an
> ELF module.  That's not going to be an option. 
> 
> For linuxbios to succeed in future, we'll need support for these two 
> things. I think this is a lamentable state of affairs. But that's how it 
> is.
> 
> I think long-term the best way to fix it for all architectures is via
> emulation, but for the immediate-term we can make callback/binary support 
> for the common(-est) case: the x86. 
> 
> > And the biggest reason I don't want to go there is because simple
> > things tend to be reliable.  And complex things tend to broken.  And
> > the extension extension looks to allow a lot of needless complexity
> > into LinuxBIOS.
> 
> But the limits of poor PC design limit our ability to be simple. The 
> original LinuxBIOS idea -- "Let Linux do it" -- was simple. We have found 
> we need a bit more than that to be workable. 
> 
> The single most common request I hear for LinuxBIOS is early VGA support 
> -- early enough to see linuxbios messages. You have no idea how often 
> this comes up -- or maybe you do :-)
> 
> I think we're going to need to do this in a reasonable way, or somebody
> will do it for us in an unreasonable way.
> 
> > The biggest piece of code everyone has been arguing for including, the
> > code to run a vgabios option rom, simply doesn't work in a lot of
> > cases, and unless I have overlooked something the reason it doesn't
> > work in a lot of cases is a design flaw, it doesn't aim for complete
> > pcbios compliance.
> 
> That's a factor of time people have had to work on it. The code itself, I 
> am told, has proven to be pretty solid for those operations it supports. 
> 
> It's possible, the more I think of it, that what we really need is a
> payload for solid x86 emulation. That would buy us
> architecture-independence which we need. No callbacks either -- just 
> emulate the trap and do the code for the callback. Much more reliable than 
> callbacks. Very portable.
> 
> Still thinking .... more discussion welcome.
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------




From jeff at planetfall.com  Thu Aug 14 13:37:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Thu Aug 14 13:37:00 2003
Subject: LinuxBIOS & binutils evilness
Message-ID: <20030814175502.GA8315@planetfall.com>

2.14.90.0.5 (Debian unstable) works for mkelfImage 2.5 but won't link
LinuxBIOS.

2.12.90.0.1 (Debian stable) works for LinuxBIOS but mkelfimage 2.5
complains about no a5 magic.

Am I stuck with two versions of binutils?  Or maybe you know how to make
LB link with the latest binutils?  It looks like a binutils bug.

Here is my link error:

[snip]
cp linuxbios_payload.nrv2b linuxbios_payload
echo "INCLUDE ldoptions" > ldscript.ld ; for file in  /usr/src/linuxbios/linuxbios/src/arch/i386/config/ldscript.base /usr/src/linuxbios/linuxbios/src/cpu/i386/entry16.lds /usr/src/linuxbios/linuxbios/src/cpu/i386/entry32.lds /usr/src/linuxbios/linuxbios/src/cpu/i386/reset16.lds /usr/src/linuxbios/linuxbios/src/arch/i386/lib/id.lds /usr/src/linuxbios/linuxbios/src/arch/i386/lib/failover-noz.lds ; do echo "INCLUDE $file" >> ldscript.ld ; done
gcc -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
crt0.o(.reset+0x1): In function `reset_vector':
: relocation truncated to fit: R_386_PC16 _start_offset
collect2: ld returned 1 exit status
make[1]: *** [linuxbios] Error 1
make[1]: Leaving directory `/usr/src/linuxbios/tyan'
make: *** [xtyan] Error 2



From ebiederman at lnxi.com  Thu Aug 14 13:49:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Aug 14 13:49:01 2003
Subject: LinuxBIOS & binutils evilness
In-Reply-To: <20030814175502.GA8315@planetfall.com>
References: <20030814175502.GA8315@planetfall.com>
Message-ID: <m3ptj8t8h2.fsf@maxwell.lnxi.com>

Jeff Noxon <jeff at planetfall.com> writes:

> 2.14.90.0.5 (Debian unstable) works for mkelfImage 2.5 but won't link
> LinuxBIOS.

This one is change in behavior of binutils.
 
> 2.12.90.0.1 (Debian stable) works for LinuxBIOS but mkelfimage 2.5
> complains about no a5 magic.

That is a binutils bug.
 
> Am I stuck with two versions of binutils?  Or maybe you know how to make
> LB link with the latest binutils?  It looks like a binutils bug.

The code in the freebios2:src/cpu/i386/reset16.inc should avoid this
problem, but oit does not generate a far jump only a near jump.

The problem binutils does not do a good job of supporting 16bit
offsets.  If you would like to pull the code back and generate a patch
for the freebios1 tree it would be appreciated.

Eric



From stepan at suse.de  Thu Aug 14 13:50:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Aug 14 13:50:00 2003
Subject: LinuxBIOS & binutils evilness
In-Reply-To: <20030814175502.GA8315@planetfall.com>; from jeff@planetfall.com on Thu, Aug 14, 2003 at 12:55:02PM -0500
References: <20030814175502.GA8315@planetfall.com>
Message-ID: <20030814200742.A18429@suse.de>

* Jeff Noxon <jeff at planetfall.com> [030814 19:55]:
> 2.14.90.0.5 (Debian unstable) works for mkelfImage 2.5 but won't link
> LinuxBIOS.
 
do you have x86-64 support enabled in these binutils? This breaks
relocations 32->16bit.

> Here is my link error:
> 
> crt0.o(.reset+0x1): In function `reset_vector':
> : relocation truncated to fit: R_386_PC16 _start_offset
> collect2: ld returned 1 exit status

src/cpu/i386/reset16.inc is the culprit. See the freebios2 tree
for a wild but working implementation of reset16.inc. The 
"jmp _start" is there implemented as:
reset_vector:
        /* jmp _start */
        .byte  0xe9
        .int   _start - ( . + 2 )

This should also be changed in the old LinuxBIOS tree. It works fine.

Stefan
-- 
Architecture Team
    SuSE Linux AG


From jeff at planetfall.com  Thu Aug 14 13:59:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Thu Aug 14 13:59:00 2003
Subject: LinuxBIOS & binutils evilness
In-Reply-To: <m3ptj8t8h2.fsf@maxwell.lnxi.com>
References: <20030814175502.GA8315@planetfall.com> <m3ptj8t8h2.fsf@maxwell.lnxi.com>
Message-ID: <20030814181642.GA9918@planetfall.com>

Is there something wrong with the near jump approach?

I will attempt to pull freebios2 from cvs.  Sourceforge CVS seems not
to work most of the time I try to use it.  It would be nice to have CVS
hosted somewhere reliable, maybe BerliOS.

Is freebios2 booting yet on any platforms?

On Thu, Aug 14, 2003 at 12:11:37PM -0600, Eric W. Biederman wrote:
> The code in the freebios2:src/cpu/i386/reset16.inc should avoid this
> problem, but oit does not generate a far jump only a near jump.
> 
> The problem binutils does not do a good job of supporting 16bit
> offsets.  If you would like to pull the code back and generate a patch
> for the freebios1 tree it would be appreciated.


From rminnich at lanl.gov  Thu Aug 14 15:29:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 15:29:00 2003
Subject: LinuxBIOS & binutils evilness
In-Reply-To: <20030814181642.GA9918@planetfall.com>
Message-ID: <Pine.LNX.4.44.0308141346350.22535-100000@maxroach.lanl.gov>

On Thu, 14 Aug 2003, Jeff Noxon wrote:

> Is freebios2 booting yet on any platforms?

Both PPC and K8 platforms. We need to try to cut a 386 machine over, I am 
going to try with the AMD Elan boards.

ron



From rminnich at lanl.gov  Thu Aug 14 15:47:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 15:47:01 2003
Subject: K8 cluster@LANL
Message-ID: <Pine.LNX.4.44.0308141359010.22535-100000@maxroach.lanl.gov>

If you check out www.lanl.gov, there is an early announcement of an new 
K8+infiniband cluster. It is 256 nodes, and will run LinuxBIOS. 

There is also mention of a larger K8 cluster, which we believe will also
run LinuxBIOS. This larger cluster is not InfiniBand, as I read the 
announcement.

Linux NetworX are building the systems, and of course Eric Biederman is 
managing the LinuxBIOS part. 

Thanks to Linux NetworX, AMD, Arima, Tyan, Eric, Stefan, and Yh Lu for all
the work they have working on and supporting LinuxBIOS on the K8. I hope I
didn't leave too many people/companies out.

The really positive news here is that our hope, when we started this 
project 4 years ago, was that we could someday buy machines and they would 
be delivered with LinuxBIOS installed; this has now happened on over 4 
machines here at LANL, one machine at LLNL, and one machine at ANL, to 
name a few. There are already at least 3 machines on the TOP  500 list 
running LinuxBIOS. 

ron



From YhLu at tyan.com  Thu Aug 14 16:19:00 2003
From: YhLu at tyan.com (YhLu)
Date: Thu Aug 14 16:19:00 2003
Subject: S2885 support.
Message-ID: <3174569B9743D511922F00A0C943142302FCA906@TYANWEB>

Ron,

I'm trying to port LinuxBIOS to Tyan s2885.

CPU0's Link0 is linked to 8151 ,Link1 is linked to CPU1, and Link2 is linked
to 8131. other parts is the same as s2880.

I change some hard code in raminit.c and coherent_ht.c to relecting the 8131
is linked to Link2 instead  of link0. and let link 0 to not init. ( Just
ignore it)

Everything is OK till elf boot. It seems can not access the ROM in elfboot.

Any suggestion.

PS: after add the CPU HT link definition in Config.lb, I can not see any
changes in static.c, Is it mean that you update newconfig tool? To eliminate
the Hardcode in coherent_ht and raminit.c, we need add chip.h in
northbridge/amdk8 and include it in them. Am I right?

Regards

YH


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

    23:stream_init() - rom_stream: 0xfffe8000 - 0xfffeffff
dest=0x0000d9a0, count=0x00002000
src=0xfffe8000, bytes=0x00002000

 fffe8000:----> Hang here, I try to print the ROM contect here.




From rminnich at lanl.gov  Thu Aug 14 18:12:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 18:12:00 2003
Subject: S2885 support.
In-Reply-To: <3174569B9743D511922F00A0C943142302FCA906@TYANWEB>
Message-ID: <Pine.LNX.4.44.0308141627560.22535-100000@maxroach.lanl.gov>

can you send me your config? or better yet, your diff, which I will commit 
and then start testing. 

I just this morning got the ARIMA HDAMA working with a bproc phase 1 boot, 
it was a bit of hackery needed with the kernel to tell it what kind of irq 
router it had. 

I wonder how the normal bios handles the PIRQ? getpir returns one that is 
clearly bogus. I guess linux never tries to use it? But a lilo boot of 
phase 1 reveals that it does find some sort of pirq table, and does 
something I can't figure out ... oh well that's for later.

ron



From YhLu at tyan.com  Thu Aug 14 18:33:00 2003
From: YhLu at tyan.com (YhLu)
Date: Thu Aug 14 18:33:00 2003
Subject: S2885 support.
Message-ID: <3174569B9743D511922F00A0C943142303187FE6@TYANWEB>

Ron,

I will send the diff tonight, for I add a lot of printk_debug.

Regards

Yinghai Lu
-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2003?8?14? 15:30
???: YhLu
??: linuxbios at clustermatic.org
??: Re: S2885 support.

can you send me your config? or better yet, your diff, which I will commit 
and then start testing. 

I just this morning got the ARIMA HDAMA working with a bproc phase 1 boot, 
it was a bit of hackery needed with the kernel to tell it what kind of irq 
router it had. 

I wonder how the normal bios handles the PIRQ? getpir returns one that is 
clearly bogus. I guess linux never tries to use it? But a lilo boot of 
phase 1 reveals that it does find some sort of pirq table, and does 
something I can't figure out ... oh well that's for later.

ron


From rogerxxmaillist at speakeasy.net  Thu Aug 14 19:51:00 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Thu Aug 14 19:51:00 2003
Subject: burn_mtd script fixes
Message-ID: <1060905968.27596.62.camel@localhost3.localdomain>

Fails to load module mtdchar.o (or atleast on my boxens with Gentoo)
 - Should probably load mtdchar at the time doc2001 & docprobe are
loaded.


/dev/mtd0 should probably be named /dev/mtd/0
(or a if /dev/mtd0 not found, then /dev/mtd/0 ...depends if the person
has deployed devfs or not.)

-- 

Roger
http://www.eskimo.com/~roger/index.html



From rminnich at lanl.gov  Thu Aug 14 22:45:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 14 22:45:00 2003
Subject: burn_mtd script fixes
In-Reply-To: <1060905968.27596.62.camel@localhost3.localdomain>
Message-ID: <Pine.LNX.4.44.0308142101590.28821-100000@maxroach.lanl.gov>

On 14 Aug 2003, Roger wrote:

> Fails to load module mtdchar.o (or atleast on my boxens with Gentoo)
>  - Should probably load mtdchar at the time doc2001 & docprobe are
> loaded.

yikes, that has not failed in years. I'll try to look.

> /dev/mtd0 should probably be named /dev/mtd/0

only with devfs. OK, how do we cleanly work around the naming problem, 
given that devfs is living on borrowed time?

ron



From steve at nexpath.com  Thu Aug 14 23:52:00 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Thu Aug 14 23:52:00 2003
Subject: burn_mtd script fixes
In-Reply-To: <Pine.LNX.4.44.0308142101590.28821-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308142101590.28821-100000@maxroach.lanl.gov>
Message-ID: <3F3C5D65.8080108@nexpath.com>

ron minnich wrote:
OK, how do we cleanly work around the naming problem,
> given that devfs is living on borrowed time?

Oh great, just as I converted to devfs and got used to it.

-Steve



From rminnich at lanl.gov  Fri Aug 15 03:18:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 15 03:18:01 2003
Subject: Questions on BX Chipset
In-Reply-To: <200308141745.59136.meinrad.sauter@gmx.de>
Message-ID: <Pine.LNX.4.44.0308141003510.22535-100000@maxroach.lanl.gov>

On Thu, 14 Aug 2003, Meinrad Sauter wrote:

> Fine, I had a look at the code and found out where to implement int #6. 
> Unfortunately I have no idea what to implement. Can you point me to some more 
> information?

you'll have to hunt down the bios interrupts.

> I looked at that also, but I couldn't find an int #6 implementation there, 
> neither in C nor in anything else.
> 

well, that's not good. Without doing some digging I am not sure I can say 
what's going on.

ron



From rogerxxmaillist at speakeasy.net  Fri Aug 15 04:47:01 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Fri Aug 15 04:47:01 2003
Subject: burn_mtd script fixes
In-Reply-To: <Pine.LNX.4.44.0308142101590.28821-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308142101590.28821-100000@maxroach.lanl.gov>
Message-ID: <1060938148.23111.90.camel@localhost3.localdomain>

Something like the following should work fine. However, I find the
simplicity of burn_mtd easy to understand and learn what needs to be
done in order to successfully complete the linuxbios build.  Adding more
scripting will increase the time decoding the additional scripting to
understand what actually needs to be done in order to complete the
build.  Maybe when builds become stable such as sis/amd, it would help
to make enhance the scripting to account for these situations (ie
something like autoconf/automake)


#! /bin/bash

if [ -e "/dev/mtd/0" ]; then
	echo 'hello'
else
	echo 'bye'
fi


On Thu, 2003-08-14 at 20:02, ron minnich wrote:
> On 14 Aug 2003, Roger wrote:
> 
> > Fails to load module mtdchar.o (or atleast on my boxens with Gentoo)
> >  - Should probably load mtdchar at the time doc2001 & docprobe are
> > loaded.
> 
> yikes, that has not failed in years. I'll try to look.
> 
> > /dev/mtd0 should probably be named /dev/mtd/0
> 
> only with devfs. OK, how do we cleanly work around the naming problem, 
> given that devfs is living on borrowed time?
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
-- 

Roger
http://www.eskimo.com/~roger/index.html



From rogerxxmaillist at speakeasy.net  Fri Aug 15 04:56:00 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Fri Aug 15 04:56:00 2003
Subject: Linuxbios Howto
Message-ID: <1060938223.23111.93.camel@localhost3.localdomain>

I really really found the article 
http://www.linux-magazine.com/issue/28/LinuxBIOS.pdf a great howto.  It
pretty much surpassed all the other linuxbios quick howto's i've seen
yet, however, every little bit helps when i'm working with a 440bx &
DOC.

-- 

Roger
http://www.eskimo.com/~roger/index.html



From Antony at Soft-Solutions.co.uk  Fri Aug 15 05:32:00 2003
From: Antony at Soft-Solutions.co.uk (Antony Stone)
Date: Fri Aug 15 05:32:00 2003
Subject: Linuxbios Howto
In-Reply-To: <1060938223.23111.93.camel@localhost3.localdomain>
References: <1060938223.23111.93.camel@localhost3.localdomain>
Message-ID: <200308150950.h7F9o7025803@agate.rockstone.co.uk>

On Friday 15 August 2003 10:06 am, Roger wrote:

> I really really found the article
> http://www.linux-magazine.com/issue/28/LinuxBIOS.pdf a great howto.  It
> pretty much surpassed all the other linuxbios quick howto's i've seen
> yet, however, every little bit helps when i'm working with a 440bx &
> DOC.

Thanks Roger :)

Antony.

-- 

If you want to be happy for an hour, get drunk.
If you want to be happy for a year, get married.
If you want to be happy for a lifetime, get a garden.


From rminnich at lanl.gov  Fri Aug 15 10:24:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 15 10:24:00 2003
Subject: burn_mtd script fixes
In-Reply-To: <1060938148.23111.90.camel@localhost3.localdomain>
Message-ID: <Pine.LNX.4.44.0308150841310.1179-100000@maxroach.lanl.gov>

well, if you rewrite it I will committ it.

ron



From sterling at cis.ksu.edu  Fri Aug 15 10:24:42 2003
From: sterling at cis.ksu.edu (Andrew Sterling Hanenkamp)
Date: Fri Aug 15 10:24:42 2003
Subject: Etherboot in the BIOS?
Message-ID: <3F3CF126.8060608@cis.ksu.edu>

According to the FAQ, it's possible to boot Linux using Etherboot with 
LinuxBIOS.  This appears to be a pretty simple and straightforward 
process, but I was wandering if it were possible to render the system 
unbootable?  That is, is it posible that overwriting the BIOS will cause 
boot to fail (because of misconfiguration, etc.)?  If this happens, is 
there anyway to recover?  What are the pitfalls and how can I avoid them?

The idea of overwriting the BIOS makes me a bit nervous, but the 
potential benefits of this boot-up process could save us quite a bit 
when it comes to configuring our clustered systems.

Thanks,
Sterling

-- 
<>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><> <>< ><>
  Andrew Sterling Hanenkamp
  http://Andrew.Sterling.Hanenkamp.com/
  sterling at hanenkamp.com / sterling at cis.ksu.edu

  Keep me informed on the behaviour of this kernel..  As the
  "BugFree(tm)" series didn't turn out too well, I'm starting a new
  series called the "ItWorksForMe(tm)" series, of which this new 
  kernel is yet another shining example.
                       -- Linus, in the announcement for 1.3.29
	




From rminnich at lanl.gov  Fri Aug 15 10:28:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 15 10:28:01 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <3F3CF126.8060608@cis.ksu.edu>
Message-ID: <Pine.LNX.4.44.0308150844430.1179-100000@maxroach.lanl.gov>

On Fri, 15 Aug 2003, Andrew Sterling Hanenkamp wrote:
> According to the FAQ, it's possible to boot Linux using Etherboot with 
> LinuxBIOS.  This appears to be a pretty simple and straightforward 
> process, but I was wandering if it were possible to render the system 
> unbootable?  That is, is it posible that overwriting the BIOS will cause 
> boot to fail (because of misconfiguration, etc.)?  If this happens, is 
> there anyway to recover?  What are the pitfalls and how can I avoid them?

There is a fallback bios mechanism for linuxbios, and in V2 it is easy to 
build fallback/normal images. It's quite an interesting design, Eric 
developed it, and it's worth a read of the code to see how it works.

We use this fallback system on the 1024 node pink system, and it has 
served us well through many flash cycles. 

ron



From jeff at planetfall.com  Fri Aug 15 10:36:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Fri Aug 15 10:36:01 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <3F3CF126.8060608@cis.ksu.edu>
References: <3F3CF126.8060608@cis.ksu.edu>
Message-ID: <20030815145412.GA3301@planetfall.com>

Purchase yourself a BIOS Savior.  They're about $20-$25 depending
on the motherboard and provide absolute protection against screwups.
http://www.pcmods.com/

Basically you end up with two BIOS chips on the motherboard, and a little
toggle switch to select one or the other.  That way you don't need to
"hotswap" BIOS chips, either.

On Fri, Aug 15, 2003 at 09:41:42AM -0500, Andrew Sterling Hanenkamp wrote:
> According to the FAQ, it's possible to boot Linux using Etherboot with 
> LinuxBIOS.  This appears to be a pretty simple and straightforward 
> process, but I was wandering if it were possible to render the system 
> unbootable?  That is, is it posible that overwriting the BIOS will cause 
> boot to fail (because of misconfiguration, etc.)?  If this happens, is 
> there anyway to recover?  What are the pitfalls and how can I avoid them?
> 
> The idea of overwriting the BIOS makes me a bit nervous, but the 
> potential benefits of this boot-up process could save us quite a bit 
> when it comes to configuring our clustered systems.
> 
> Thanks,
> Sterling


From rminnich at lanl.gov  Fri Aug 15 10:42:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 15 10:42:00 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <20030815145412.GA3301@planetfall.com>
Message-ID: <Pine.LNX.4.44.0308150859200.4377-100000@maxroach.lanl.gov>

On Fri, 15 Aug 2003, Jeff Noxon wrote:

> Purchase yourself a BIOS Savior.  They're about $20-$25 depending
> on the motherboard and provide absolute protection against screwups.
> http://www.pcmods.com/

This is ok on a onesy-twosy scale, but it won't help people who are 
looking at larger numbers of nodes. It's a wondeful too however.

ron



From jeff at planetfall.com  Fri Aug 15 10:47:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Fri Aug 15 10:47:01 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <Pine.LNX.4.44.0308150859200.4377-100000@maxroach.lanl.gov>
References: <20030815145412.GA3301@planetfall.com> <Pine.LNX.4.44.0308150859200.4377-100000@maxroach.lanl.gov>
Message-ID: <20030815150451.GA3641@planetfall.com>

On Fri, Aug 15, 2003 at 08:59:53AM -0600, ron minnich wrote:
> > Purchase yourself a BIOS Savior.  They're about $20-$25 depending
> 
> This is ok on a onesy-twosy scale, but it won't help people who are 
> looking at larger numbers of nodes. It's a wondeful too however.

Agreed, but I think the poster's concern was rendering a machine
unbootable.  Once LinuxBIOS is working on one node, it can be copied
to the others easily and without much concern.  I still don't have LB
working properly on my Tyan TigerMPX board.  It's nice to have a way to
continue booting it ;)

Regards,

Jeff


From steve at nexpath.com  Fri Aug 15 10:52:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Fri Aug 15 10:52:01 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <Pine.LNX.4.44.0308150844430.1179-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308150844430.1179-100000@maxroach.lanl.gov>
Message-ID: <3F3CF9C6.2030407@nexpath.com>

ron minnich wrote:
> It's quite an interesting design, Eric 
> developed it, and it's worth a read of the code to see how it works.
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
One of the things we very much need to work on, and of course I'm just 
as guilty, but so many things in linuxbios require a "read of the code".

-Steve



From rminnich at lanl.gov  Fri Aug 15 10:52:07 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 15 10:52:07 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <20030815150451.GA3641@planetfall.com>
Message-ID: <Pine.LNX.4.44.0308150909010.4542-100000@maxroach.lanl.gov>

On Fri, 15 Aug 2003, Jeff Noxon wrote:

> Agreed, but I think the poster's concern was rendering a machine
> unbootable.  Once LinuxBIOS is working on one node, it can be copied
> to the others easily and without much concern.  I still don't have LB
> working properly on my Tyan TigerMPX board.  It's nice to have a way to
> continue booting it ;)

not always true. On one 1024 node update, a linuxbios update uncovered a 
problem in the hardware, such that 5 of the 1024 nodes had trouble 
booting. Times like those you really need a fallback. It's easy to see, 
given the general bugginess of so much PC hardware, why the BIOSes run it 
so slow. 

ron



From rminnich at lanl.gov  Fri Aug 15 10:53:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 15 10:53:01 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <3F3CF9C6.2030407@nexpath.com>
Message-ID: <Pine.LNX.4.44.0308150910440.4542-100000@maxroach.lanl.gov>

On Fri, 15 Aug 2003, Steve Gehlbach wrote:

> One of the things we very much need to work on, and of course I'm just 
> as guilty, but so many things in linuxbios require a "read of the code".

on the list.

ron



From steve at nexpath.com  Fri Aug 15 12:23:00 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Fri Aug 15 12:23:00 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <Pine.LNX.4.44.0308150909010.4542-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308150909010.4542-100000@maxroach.lanl.gov>
Message-ID: <3F3D0F10.3050406@nexpath.com>

ron minnich wrote:

> On one 1024 node update, a linuxbios update uncovered a
> problem in the hardware, such that 5 of the 1024 nodes had trouble 
> booting. Times like those you really need a fallback. It's easy to see, 
> given the general bugginess of so much PC hardware, why the BIOSes run it 
> so slow. 

I'm actually amazed you can get 1024 PC mobos all going at once.  Many 
if not most mobo mfrs turn their designs 4 times a year, that is not 
much time to do exhaustive design checks.  And the power conversion 
circuits are frequently running components beyond spec, so that this 
area has a life expectancy of 1-2 years, on many boards.  I guess PC 
mfrs figure you'll buy a new one by then so what the heck.  But it 
varies with the mfr and the specific board.  I've had some with <5% 
failure in 10 years, others 25% failure in 5 years.  And dont get me 
started on the power supply and the fans...

-Steve



From rogerxxmaillist at speakeasy.net  Fri Aug 15 13:39:00 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Fri Aug 15 13:39:00 2003
Subject: burn_mtd script fixes
In-Reply-To: <Pine.LNX.4.44.0308150841310.1179-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308150841310.1179-100000@maxroach.lanl.gov>
Message-ID: <1060969670.17316.4.camel@localhost3.localdomain>

On Fri, 2003-08-15 at 07:41, ron minnich wrote:
> well, if you rewrite it I will committ it.
> 
> ron

Have yet to be able to get a successful linuxbios install on my 440bx
chipsets. So this would be "putting the horse before the carriage" for
me. :-/

-- 

Roger
http://www.eskimo.com/~roger/index.html



From rogerxxmaillist at speakeasy.net  Fri Aug 15 14:20:00 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Fri Aug 15 14:20:00 2003
Subject: intel 440bx failures
In-Reply-To: <1060970942.20437.26.camel@localhost3.localdomain>
References: <1060970942.20437.26.camel@localhost3.localdomain>
Message-ID: <1060972162.17316.28.camel@localhost3.localdomain>

ignore this thread as i sent it from a de-activated email account!

On Fri, 2003-08-15 at 11:09, roger wrote:
> I've tried smartcore-p5/ & l440bx/ and on each boot, the 440bx box still
> acts like it can't find any bios (ie black screen, some minimal drive
> activity, nothing on ttyS1, etc)
> 
> >From what has been briefed to me, the DOC MIL chip will mimic a standard
> flash DIP and doesn't need docipl(?) -- docipl is needed in order to use
> nftl to install something like a root partition on the chip?
> 
> I've also tried flashing the builds to a standard DIP 2Mb/256kb flash
> (even though I know it doesn't fit :-).
> 
> One thing I will note tho, I do have to use openbios/devbios to burn the
> standard AMTEL 32pin DIP Flash as for some reason linux mtd will fail to
> recognize these chips (even after I unshadow flash to the chipset by
> hacking devbios module to *not* unshadow after being unloaded.
> 
> I do know that openbios/devbios is flashing properly as I mistakenly
> flashed my original manuf bios flash chip and then had to re-flash it
> and then flash another chip for backup incase it failed.  Amazingly both
> chips worked and both had good copies of the manuf. bios on them. ;-)
-- 

Roger
http://www.eskimo.com/~roger/index.html



From rogerxxmaillist at speakeasy.net  Fri Aug 15 14:23:00 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Fri Aug 15 14:23:00 2003
Subject: intel 440bx failures <-- good thread
Message-ID: <1060972336.17316.32.camel@localhost3.localdomain>

(sorry about that. my san.rr.com isp has been deactivated in favor of
the Linux based speakeasy.net isp ;-) 

(BTW. I can send a beginning hexdump/edit of the bios chip for
verification that it is being burned properly. )

I've tried smartcore-p5/ & l440bx/ and on each boot, the 440bx box still
acts like it can't find any bios (ie black screen, some minimal drive
activity, nothing on ttyS1, etc)

>From what has been briefed to me, the DOC MIL chip will mimic a standard
flash DIP and doesn't need docipl(?) -- docipl is needed in order to use
nftl to install something like a root partition on the chip?

I've also tried flashing the builds to a standard DIP 2Mb/256kb flash
(even though I know it doesn't fit :-).

One thing I will note tho, I do have to use openbios/devbios to burn the
standard AMTEL 32pin DIP Flash as for some reason linux mtd will fail to
recognize these chips (even after I unshadow flash to the chipset by
hacking devbios module to *not* unshadow after being unloaded.

I do know that openbios/devbios is flashing properly as I mistakenly
flashed my original manuf bios flash chip and then had to re-flash it
and then flash another chip for backup incase it failed.  Amazingly both
chips worked and both had good copies of the manuf. bios on them. ;-)

-- 

Roger
http://www.eskimo.com/~roger/index.html



From rminnich at lanl.gov  Fri Aug 15 15:06:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 15 15:06:01 2003
Subject: burn_mtd script fixes
In-Reply-To: <1060969670.17316.4.camel@localhost3.localdomain>
Message-ID: <Pine.LNX.4.44.0308151323580.6506-100000@maxroach.lanl.gov>

On 15 Aug 2003, Roger wrote:
> Have yet to be able to get a successful linuxbios install on my 440bx
> chipsets. So this would be "putting the horse before the carriage" for
> me. :-/

I'm off to vacation but will be happy to try to help when I get back in 10 
days.

If anybody wants to take a shot at something new and fun, a port of a 
known-working-board to 2.0 would be very useful.

ron



From rminnich at lanl.gov  Fri Aug 15 15:09:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 15 15:09:00 2003
Subject: intel 440bx failures <-- good thread
In-Reply-To: <1060972336.17316.32.camel@localhost3.localdomain>
Message-ID: <Pine.LNX.4.44.0308151325460.6506-100000@maxroach.lanl.gov>

On 15 Aug 2003, Roger wrote:

> (BTW. I can send a beginning hexdump/edit of the bios chip for
> verification that it is being burned properly. )

sure, send it along.
ron

> >From what has been briefed to me, the DOC MIL chip will mimic a standard
> flash DIP and doesn't need docipl(?) -- docipl is needed in order to use
> nftl to install something like a root partition on the chip?

There is no way you can get 440bx memory up in 512 bytes. No DOC MIL on 
440bx.

> I've also tried flashing the builds to a standard DIP 2Mb/256kb flash
> (even though I know it doesn't fit :-).

So it won't work anyway.

ron



From rogerxxmaillist at speakeasy.net  Fri Aug 15 17:42:00 2003
From: rogerxxmaillist at speakeasy.net (Roger)
Date: Fri Aug 15 17:42:00 2003
Subject: intel 440bx failures <-- good thread
In-Reply-To: <Pine.LNX.4.44.0308151325460.6506-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308151325460.6506-100000@maxroach.lanl.gov>
Message-ID: <1060984283.20437.48.camel@localhost3.localdomain>

On Fri, 2003-08-15 at 12:26, ron minnich wrote:
> On 15 Aug 2003, Roger wrote:
> 
> > (BTW. I can send a beginning hexdump/edit of the bios chip for
> > verification that it is being burned properly. )
> 
> sure, send it along.
> ron
> 
> > >From what has been briefed to me, the DOC MIL chip will mimic a standard
> > flash DIP and doesn't need docipl(?) -- docipl is needed in order to use
> > nftl to install something like a root partition on the chip?
> 
> There is no way you can get 440bx memory up in 512 bytes. No DOC MIL on 
> 440bx.
> 
> > I've also tried flashing the builds to a standard DIP 2Mb/256kb flash
> > (even though I know it doesn't fit :-).
> 
> So it won't work anyway.
> 
> ron

ok. point well made. now i'll go into a slumber with a couple of bottles
for the next few days :-/

when i become conscience again, i'll try to see how many friendly emails
my intel archs can turn out and send to intel ;-)

within this year. i'll be looking at investing $$$ into h/w that *does*
make use of linuxbios since i'm tired of the old amibios/award bioses.

-- 

Roger
http://www.eskimo.com/~roger/index.html



From rminnich at lanl.gov  Fri Aug 15 18:56:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 15 18:56:01 2003
Subject: I'm off for a week
Message-ID: <Pine.LNX.4.44.0308151711310.8206-100000@maxroach.lanl.gov>

I'm outta town for 10 days, off the grid, no email, yeeee ha!

So if you were waiting on me for something, sorry, but I'm gone.

have a good one.

see you the 26th.

ron



From YhLu at tyan.com  Sat Aug 16 01:08:00 2003
From: YhLu at tyan.com (YhLu)
Date: Sat Aug 16 01:08:00 2003
Subject: s2885
Message-ID: <3174569B9743D511922F00A0C9431423031880B8@TYANWEB>

Eric,

Is ethboot 5.2.0 support Broadcom 5703X?  (deviceid = 0x16a7).

For the S2885's onboard 5703X, it says: EBUSY err.

Regards

Yinghai Lu

01:09.00 [14E4/16A7]
[tg3-5703X]The PCI BIOS has not enabled this device!
Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
Capability: 7
Capability: 1
err=-1
Problem fetching invariants of chip, aborting.




From jeff at planetfall.com  Sat Aug 16 10:14:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Sat Aug 16 10:14:00 2003
Subject: s2885
In-Reply-To: <3174569B9743D511922F00A0C9431423031880B8@TYANWEB>
References: <3174569B9743D511922F00A0C9431423031880B8@TYANWEB>
Message-ID: <20030816143244.GA9139@planetfall.com>

I can't get it to work with a 3com 3C996T (14e4:1644) ... it recognizes
the card but thinks there's no cable plugged in.

On Fri, Aug 15, 2003 at 10:31:44PM -0700, YhLu wrote:
> Eric,
> 
> Is ethboot 5.2.0 support Broadcom 5703X?  (deviceid = 0x16a7).
> 
> For the S2885's onboard 5703X, it says: EBUSY err.
> 
> Regards
> 
> Yinghai Lu
> 
> 01:09.00 [14E4/16A7]
> [tg3-5703X]The PCI BIOS has not enabled this device!
> Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
> Capability: 7
> Capability: 1
> err=-1
> Problem fetching invariants of chip, aborting.


From ebiederman at lnxi.com  Sat Aug 16 12:55:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Aug 16 12:55:01 2003
Subject: s2885
In-Reply-To: <20030816143244.GA9139@planetfall.com>
References: <3174569B9743D511922F00A0C9431423031880B8@TYANWEB>
	<20030816143244.GA9139@planetfall.com>
Message-ID: <m33cg1v7wc.fsf@maxwell.lnxi.com>

Guys the etherboot users list is really the right forum for
this kind of question. 

Jeff Noxon <jeff at planetfall.com> writes:

> I can't get it to work with a 3com 3C996T (14e4:1644) ... it recognizes
> the card but thinks there's no cable plugged in.

I don't know.  When the link detection code was written it was tested
and it worked here.  Except when the link really is not connected I
have not seen code like that fail forever.
 
> On Fri, Aug 15, 2003 at 10:31:44PM -0700, YhLu wrote:
> > Eric,
> > 
> > Is ethboot 5.2.0 support Broadcom 5703X?  (deviceid = 0x16a7).
> > 
> > For the S2885's onboard 5703X, it says: EBUSY err.

Looking at the code it is should work.  I just stripped down the
appropriate driver.  I do admit I have not tested 5.2 yet.  But
I don't see why anything would have broken.

> > Regards
> > 
> > Yinghai Lu
> > 
> > 01:09.00 [14E4/16A7]
> > [tg3-5703X]The PCI BIOS has not enabled this device!
> > Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
> > Capability: 7
> > Capability: 1
> > err=-1
> > Problem fetching invariants of chip, aborting.

Hmm.  I have once or twice seen the problem of fetching invariants of
the chip.  But something is noticeably different from the tree I have
because I do not have an line that will print err=-1 in the tree I am
looking at.

Eric



From ts1 at tsn.or.jp  Sat Aug 16 13:57:01 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Sat Aug 16 13:57:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <Pine.LNX.4.44.0308111715390.30099-100000@maxroach.lanl.gov>
References: <3174569B9743D511922F00A0C943142302FCA6E1@TYANWEB> <Pine.LNX.4.44.0308111715390.30099-100000@maxroach.lanl.gov>
Message-ID: <20030816181518.GA1076@tsn.or.jp>

On Mon, Aug 11, 2003 at 05:21:06PM -0600, ron minnich wrote:
> On Mon, 11 Aug 2003, YhLu wrote:
> > I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom
> > to 0xfff8c000, ( the second 48k).
> 
> ah, well, we shouldn't really do that until we resolve the VGA bios 
> question. 
> 
> Looks, however, looke tehre is a bug ... Takeshi can perhaps address it 
> better than I. 

PCI spec requires System BIOS to provide Bus/Dev/Fn of the device
in AX register when calling option ROM during POST.
This way multiple instances of same PCI device can be initialized
one by one, I guess.

And, vgabios.c doesn't do that.

YhLu, you can at first hardcode the bus/devfn of your VGA card
in the assembly part of the vgabios.c, and see what happens.

--
Takeshi


From pyro at linuxlabs.com  Sat Aug 16 14:09:01 2003
From: pyro at linuxlabs.com (steven james)
Date: Sat Aug 16 14:09:01 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <3F3CF126.8060608@cis.ksu.edu>
Message-ID: <Pine.LNX.4.21.0308161414310.23114-100000@ucontrol.mobiledns.com>

Greetings,

It IS possible to render a board unbootable with a bad flash, but there
are a few protections in place.

The trickiest part is the initial loading where a fallback image is
flashed into the top of the BIOS. The fallback block can (should) be set
up as a completely independant boot image with a copy of Etherboot built
in.

Most of the boards have a socketed flash so that the worst case scenerio
for a mis-flashed fallback is that you'll have to boot from a spare
chip, hot swap in the mis-flashed chip, and try again.

Unfortunatly, a few boards do have a soldered down flash. In those cases,
the only way to recover is to de-solder the chip (which may not be worth
the cost vs. a new board)

Once in place and functioning, the fallback should never be changed. Many
mainboards (all of the i7501 based boards for example) have a jumper that
can be set to prevent accidental flashing of the top block.

The rest of the flash contains the primary LinuxBIOS image and the
preferred boot payload (often another copy of Etherboot), and can then be
flashed at will. The worst case will be that you'll have to hit reset a
few times to cause the fallback image to boot the system.

G'day,
sjames

On Fri, 15 Aug 2003, Andrew Sterling Hanenkamp wrote:

> According to the FAQ, it's possible to boot Linux using Etherboot with 
> LinuxBIOS.  This appears to be a pretty simple and straightforward 
> process, but I was wandering if it were possible to render the system 
> unbootable?  That is, is it posible that overwriting the BIOS will cause 
> boot to fail (because of misconfiguration, etc.)?  If this happens, is 
> there anyway to recover?  What are the pitfalls and how can I avoid them?
> 
> The idea of overwriting the BIOS makes me a bit nervous, but the 
> potential benefits of this boot-up process could save us quite a bit 
> when it comes to configuring our clustered systems.
> 
> Thanks,
> Sterling
> 
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------




From jeff at planetfall.com  Sat Aug 16 17:05:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Sat Aug 16 17:05:01 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <Pine.LNX.4.21.0308161414310.23114-100000@ucontrol.mobiledns.com>
References: <3F3CF126.8060608@cis.ksu.edu> <Pine.LNX.4.21.0308161414310.23114-100000@ucontrol.mobiledns.com>
Message-ID: <20030816212324.GA13193@planetfall.com>

Would you please elaborate on this a little?

I still don't have my Tyan board working properly, but I can tell you
this -- my fallback image doesn't have any payload at all.  I thought
it just ran the payload from the other image.  (Which puzzled me.)

I was just burning the linuxbios.rom into top 64KB of flash.

Now that I'm clued in, I'm not sure how it's supposed to work.  

The fallback file "linuxbios" is 48884 bytes in size.  For some reason
when it is run through objdump to create linuxbios.strip, it ends up
being 65536 bytes.  That doesn't leave room for any payload.  Is this
another binutils problem?

Here you can see how make dies:

objcopy -O binary linuxbios linuxbios.strip
export size=`ls -l linuxbios.strip | (read p c u g size r ; echo $size)` ; \
echo $size ; \
dd if=linuxbios.strip of=linuxbios.rom bs=1 seek=`expr 65536 - $size`
65536
65536+0 records in
65536+0 records out
dd conv=sync bs=0 if=/usr/src/linuxbios/3c90x.elf of=payload.block
dd: invalid number `0'
make: *** [payload.block] Error 1

Of course, dd fails because PAYLOAD_SIZE is not set.

I can't use my working EPIA board as an example, because that board
doesn't have "normal" and "fallback" images -- it just has one image.

It would be very helpful for me to have your diffs against CVS, or the
config files you're actually using to build these ROM images.

Thanks,

Jeff
(Trying not to look like a total idiot)

On Sat, Aug 16, 2003 at 02:27:07PM -0400, steven james wrote:
> Greetings,
> 
> It IS possible to render a board unbootable with a bad flash, but there
> are a few protections in place.
> 
> The trickiest part is the initial loading where a fallback image is
> flashed into the top of the BIOS. The fallback block can (should) be set
> up as a completely independant boot image with a copy of Etherboot built
> in.
> 
> Most of the boards have a socketed flash so that the worst case scenerio
> for a mis-flashed fallback is that you'll have to boot from a spare
> chip, hot swap in the mis-flashed chip, and try again.
> 
> Unfortunatly, a few boards do have a soldered down flash. In those cases,
> the only way to recover is to de-solder the chip (which may not be worth
> the cost vs. a new board)
> 
> Once in place and functioning, the fallback should never be changed. Many
> mainboards (all of the i7501 based boards for example) have a jumper that
> can be set to prevent accidental flashing of the top block.
> 
> The rest of the flash contains the primary LinuxBIOS image and the
> preferred boot payload (often another copy of Etherboot), and can then be
> flashed at will. The worst case will be that you'll have to hit reset a
> few times to cause the fallback image to boot the system.
> 
> G'day,
> sjames


From pyro at linuxlabs.com  Sat Aug 16 18:50:00 2003
From: pyro at linuxlabs.com (steven james)
Date: Sat Aug 16 18:50:00 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <20030816212324.GA13193@planetfall.com>
Message-ID: <Pine.LNX.4.21.0308161905360.23114-100000@ucontrol.mobiledns.com>

Greetings,

The fallback image has to be pieced together. Just create a pad file sized
0x10000 - (lb image + etherboot image) and
dd if=/dev/zero bs=1 count=<size> of=pad
then cat etherboot pad linuxbios>fallback_block

and flash the result.

G'day,
sjames



On Sat, 16 Aug 2003, Jeff Noxon wrote:

> Would you please elaborate on this a little?
> 
> I still don't have my Tyan board working properly, but I can tell you
> this -- my fallback image doesn't have any payload at all.  I thought
> it just ran the payload from the other image.  (Which puzzled me.)
> 
> I was just burning the linuxbios.rom into top 64KB of flash.
> 
> Now that I'm clued in, I'm not sure how it's supposed to work.  
> 
> The fallback file "linuxbios" is 48884 bytes in size.  For some reason
> when it is run through objdump to create linuxbios.strip, it ends up
> being 65536 bytes.  That doesn't leave room for any payload.  Is this
> another binutils problem?
> 
> Here you can see how make dies:
> 
> objcopy -O binary linuxbios linuxbios.strip
> export size=`ls -l linuxbios.strip | (read p c u g size r ; echo $size)` ; \
> echo $size ; \
> dd if=linuxbios.strip of=linuxbios.rom bs=1 seek=`expr 65536 - $size`
> 65536
> 65536+0 records in
> 65536+0 records out
> dd conv=sync bs=0 if=/usr/src/linuxbios/3c90x.elf of=payload.block
> dd: invalid number `0'
> make: *** [payload.block] Error 1
> 
> Of course, dd fails because PAYLOAD_SIZE is not set.
> 
> I can't use my working EPIA board as an example, because that board
> doesn't have "normal" and "fallback" images -- it just has one image.
> 
> It would be very helpful for me to have your diffs against CVS, or the
> config files you're actually using to build these ROM images.
> 
> Thanks,
> 
> Jeff
> (Trying not to look like a total idiot)
> 
> On Sat, Aug 16, 2003 at 02:27:07PM -0400, steven james wrote:
> > Greetings,
> > 
> > It IS possible to render a board unbootable with a bad flash, but there
> > are a few protections in place.
> > 
> > The trickiest part is the initial loading where a fallback image is
> > flashed into the top of the BIOS. The fallback block can (should) be set
> > up as a completely independant boot image with a copy of Etherboot built
> > in.
> > 
> > Most of the boards have a socketed flash so that the worst case scenerio
> > for a mis-flashed fallback is that you'll have to boot from a spare
> > chip, hot swap in the mis-flashed chip, and try again.
> > 
> > Unfortunatly, a few boards do have a soldered down flash. In those cases,
> > the only way to recover is to de-solder the chip (which may not be worth
> > the cost vs. a new board)
> > 
> > Once in place and functioning, the fallback should never be changed. Many
> > mainboards (all of the i7501 based boards for example) have a jumper that
> > can be set to prevent accidental flashing of the top block.
> > 
> > The rest of the flash contains the primary LinuxBIOS image and the
> > preferred boot payload (often another copy of Etherboot), and can then be
> > flashed at will. The worst case will be that you'll have to hit reset a
> > few times to cause the fallback image to boot the system.
> > 
> > G'day,
> > sjames
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------




From jeff at planetfall.com  Sat Aug 16 19:11:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Sat Aug 16 19:11:01 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <Pine.LNX.4.21.0308161905360.23114-100000@ucontrol.mobiledns.com>
References: <20030816212324.GA13193@planetfall.com> <Pine.LNX.4.21.0308161905360.23114-100000@ucontrol.mobiledns.com>
Message-ID: <20030816232921.GA14787@planetfall.com>

That gets back to my original question:

I have a "linuxbios.strip" file that's exactly 64KB.  How can I add
Etherboot to it and still have a 64KB image?

Is this a problem with my objdump utility?  Or do I have to manually
_overlay_ the linuxbios.strip file and Etherboot?  And if the latter,
how do I know how much space I have for Etherboot?

Where have I gone wrong?

Thanks,

Jeff

On Sat, Aug 16, 2003 at 07:08:51PM -0400, steven james wrote:
> Greetings,
> 
> The fallback image has to be pieced together. Just create a pad file sized
> 0x10000 - (lb image + etherboot image) and
> dd if=/dev/zero bs=1 count=<size> of=pad
> then cat etherboot pad linuxbios>fallback_block
> 
> and flash the result.
> 
> On Sat, 16 Aug 2003, Jeff Noxon wrote:
> 
> > Would you please elaborate on this a little?
> > 
> > I still don't have my Tyan board working properly, but I can tell you
> > this -- my fallback image doesn't have any payload at all.  I thought
> > it just ran the payload from the other image.  (Which puzzled me.)
> > 
> > I was just burning the linuxbios.rom into top 64KB of flash.
> > 
> > Now that I'm clued in, I'm not sure how it's supposed to work.  
> > 
> > The fallback file "linuxbios" is 48884 bytes in size.  For some reason
> > when it is run through objdump to create linuxbios.strip, it ends up
> > being 65536 bytes.  That doesn't leave room for any payload.  Is this
> > another binutils problem?


From rminnich at lanl.gov  Sat Aug 16 22:37:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sat Aug 16 22:37:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030816181518.GA1076@tsn.or.jp>
Message-ID: <Pine.LNX.4.44.0308162055180.16044-100000@maxroach.lanl.gov>

On Sun, 17 Aug 2003, SONE Takeshi wrote:

> And, vgabios.c doesn't do that.

gee, I thought I had it doing that. I will try to fix this when I get 
back.

ron



From rminnich at lanl.gov  Sat Aug 16 23:07:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sat Aug 16 23:07:00 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <20030816212324.GA13193@planetfall.com>
Message-ID: <Pine.LNX.4.44.0308162123130.19868-100000@maxroach.lanl.gov>

On Sat, 16 Aug 2003, Jeff Noxon wrote:

> I still don't have my Tyan board working properly, but I can tell you
> this -- my fallback image doesn't have any payload at all.  I thought
> it just ran the payload from the other image.  (Which puzzled me.)

the fallback must have a payload. Fallback and normal are two totally 
independent things.

> I was just burning the linuxbios.rom into top 64KB of flash.

oh, gosh, are you using v1 or v2?

> 
> objcopy -O binary linuxbios linuxbios.strip
> export size=`ls -l linuxbios.strip | (read p c u g size r ; echo $size)` ; \
> echo $size ; \
> dd if=linuxbios.strip of=linuxbios.rom bs=1 seek=`expr 65536 - $size`
> 65536
> 65536+0 records in
> 65536+0 records out
> dd conv=sync bs=0 if=/usr/src/linuxbios/3c90x.elf of=payload.block
> dd: invalid number `0'
> make: *** [payload.block] Error 1

sorry for this, I am going off the air soon but I think Andrew Ip or the 
other EIPA guys on this list might be able to help.

I will send you my config under seperate cover.

ron



From rminnich at lanl.gov  Sat Aug 16 23:10:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sat Aug 16 23:10:00 2003
Subject: Etherboot in the BIOS?
In-Reply-To: <Pine.LNX.4.21.0308161905360.23114-100000@ucontrol.mobiledns.com>
Message-ID: <Pine.LNX.4.44.0308162127470.19868-100000@maxroach.lanl.gov>

On Sat, 16 Aug 2003, steven james wrote:

> The fallback image has to be pieced together. Just create a pad file sized
> 0x10000 - (lb image + etherboot image) and
> dd if=/dev/zero bs=1 count=<size> of=pad
> then cat etherboot pad linuxbios>fallback_block

yes, this is fixed on v2. I got rid of all the 'dd' magic and have a 
trivial C program. 

ron



From ebiederman at lnxi.com  Sun Aug 17 06:12:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Aug 17 06:12:00 2003
Subject: [PATCH] memtest86...
Message-ID: <m3y8xstw0f.fsf@maxwell.lnxi.com>

I have finally had a chance to make a good patch with
my changes that have been accumulating to memtest86.   I believe
this patch resolves most of the outstanding issues.  

There are quite a few people on the LinuxBIOS list who are
interested so I am posting it here before I run out of time again.

- Fixes problems when compiling with newer versions of gcc
  o Rely on test.h for the declaration of v
  o Update memtest86.lds so we include all of the relocation sections
- Add support for the memory controller in the E7500 
- Add private versions elf.h and stdint.h to ensure a good copy is present.
- Rewrite cacheable so it works properly with sparse memory maps.
- Add the ability to automatically detect the baud rate
- Generalized the code that sanitizes the memory map so it is universal.
- Detect Opteron CPUS 

Eric

diff --exclude=CVS -uNr memtest86-3.0/Makefile memtest86/Makefile
--- memtest86-3.0/Makefile	Tue Apr 23 05:21:05 2002
+++ memtest86/Makefile	Sun Aug 17 04:00:36 2003
@@ -12,7 +12,7 @@
 #
 # gcc compiler options, these settings should suffice
 #
-CCFLAGS=-Wall -march=i486 -O -fomit-frame-pointer -fno-builtin
+CCFLAGS=-Wall -march=i486 -Os -fomit-frame-pointer -fno-builtin -ffreestanding
 
 AS=as
 
@@ -56,6 +56,9 @@
 controller.o: controller.c defs.h config.h test.h pci.h controller.h
 	$(CC) -c $(CCFLAGS) -fPIC controller.c
 
+controller.s: controller.c defs.h config.h test.h pci.h controller.h
+	$(CC) -S $(CCFLAGS) -fPIC controller.c
+
 head.s: head.S
 	$(CC) -E -traditional $< -o $@
 
@@ -70,7 +73,7 @@
 # relocation information
 memtest_shared: $(OBJS) memtest_shared.lds Makefile
 	$(LD) --warn-constructors --warn-common -static -T memtest_shared.lds -o $@ $(OBJS) && \
-	$(LD) -shared -T memtest_shared.lds -o $@ $(OBJS)
+	$(LD) -shared -Bsymbolic -T memtest_shared.lds -o $@ $(OBJS)
 
 memtest_shared.bin: memtest_shared
 	objcopy -O binary $< memtest_shared.bin
diff --exclude=CVS -uNr memtest86-3.0/config.c memtest86/config.c
--- memtest86-3.0/config.c	Tue May 21 12:27:11 2002
+++ memtest86/config.c	Sat Aug 16 22:40:06 2003
@@ -10,7 +10,6 @@
 
 extern int bail;
 extern struct tseq tseq[];
-extern struct vars *v;
 extern short e820_nr;
 extern char memsz_mode;
 
diff --exclude=CVS -uNr memtest86-3.0/config.h memtest86/config.h
--- memtest86-3.0/config.h	Tue May 21 15:14:30 2002
+++ memtest86/config.h	Sun Aug 17 04:09:51 2003
@@ -15,7 +15,10 @@
 /*	to enable. */
 #define SERIAL_CONSOLE_DEFAULT 0
 
-/* SERIAL_BAUD_RATE - Baud rate for the serial console */
+/* SERIAL_BAUD_RATE - Baud rate for the serial console
+ * If this is not defined it is assumed a previous program has set the
+ * baud rate, and the baud is preserved.
+ */
 #define SERIAL_BAUD_RATE 9600
 
 /* SCRN_DEBUG - extra check for SCREEN_BUFFER
diff --exclude=CVS -uNr memtest86-3.0/controller.c memtest86/controller.c
--- memtest86-3.0/controller.c	Wed Apr 24 10:55:22 2002
+++ memtest86/controller.c	Sun Aug 17 02:26:50 2003
@@ -417,6 +417,75 @@
 	}
 }
 
+static void setup_iE7500(void)
+{
+	unsigned long mchcfgns;
+	unsigned long drc;
+
+	/* Read the hardare capabilities */
+	pci_conf_read(ctrl.bus, ctrl.dev, ctrl.fn, 0x52, 2, &mchcfgns);
+	pci_conf_read(ctrl.bus, ctrl.dev, ctrl.fn, 0x7C, 4, &drc);
+
+	/* Fill in the correct memory capabilities */
+	ctrl.cap = ECC_SCRUB;
+	ctrl.mode = 0;
+	/* checking and correcting enabled */
+	if (((drc >> 20) & 3) == 2) {
+		ctrl.mode |= ECC_CORRECT;
+	}
+	/* scrub enabled */
+	if (mchcfgns & (1 << 2)) {
+		ctrl.mode |= __ECC_SCRUB;
+	}
+
+	/* Clear any prexisting error reports */
+	pci_conf_write(ctrl.bus, ctrl.dev, ctrl.fn +1, 0x80, 1, 3);
+	pci_conf_write(ctrl.bus, ctrl.dev, ctrl.fn +1, 0x82, 1, 3);
+}
+
+static void poll_iE7500(void)
+{
+	unsigned long ferr;
+	unsigned long nerr;
+	unsigned char err;
+	pci_conf_read(ctrl.bus, ctrl.dev, ctrl.fn +1, 0x80, 1, &ferr);
+	pci_conf_read(ctrl.bus, ctrl.dev, ctrl.fn +1, 0x82, 1, &nerr);
+	err = ferr | nerr;
+	if (err & 1) {
+		/* Find out about the first correctable error */
+		unsigned long celog_add;
+		unsigned long celog_syndrome;
+		unsigned long page;
+		/* Read the error location */
+		pci_conf_read(ctrl.bus, ctrl.dev, ctrl.fn +1, 0xA0, 4, &celog_add);
+		/* Read the syndrome */
+		pci_conf_read(ctrl.bus, ctrl.dev, ctrl.fn +1, 0xD0, 2, &celog_syndrome);
+
+		/* Parse the error location */
+		page = (celog_add & 0x0FFFFFC0) >> 6;
+		
+		/* Report the error */
+		print_ecc_err(page, 0, 1, celog_syndrome, 0);
+	}
+	if (err & 2) {
+		/* Found out about the first uncorrectable error */
+		unsigned long uccelog_add;
+		unsigned long page;
+		/* Read the error location */
+		pci_conf_read(ctrl.bus, ctrl.dev, ctrl.fn +1, 0xB0, 4, &uccelog_add);
+
+		/* Parse the error location */
+		page = (uccelog_add & 0x0FFFFFC0) >> 6;
+		
+		/* Report the error */
+		print_ecc_err(page, 0, 2, 0, 0);
+		
+	}
+	/* Clear the error registers */
+	pci_conf_write(ctrl.bus, ctrl.dev, ctrl.fn +1, 0x80, 1, ferr & 3);
+	pci_conf_write(ctrl.bus, ctrl.dev, ctrl.fn +1, 0x82, 1, nerr & 3);
+}
+
 struct pci_memory_controller {
 	unsigned vendor;
 	unsigned device;
@@ -465,10 +534,10 @@
 	{ 0x8086, 0x122d, "i430fx",    0, setup_nothing, poll_nothing },
 	{ 0x8086, 0x1237, "i440fx",    0, setup_nothing, poll_nothing },
 	{ 0x8086, 0x1250, "i430hx",    0, setup_nothing, poll_nothing },
-	{ 0x8086, 0x1A21, "i840",      0,setup_i840, poll_i840 },
-	{ 0x8086, 0x1A30, "i845",      0,setup_i845, poll_i845 },
-	{ 0x8086, 0x2500, "i820",      0,setup_i820, poll_i820 },
-	{ 0x8086, 0x2530, "i850",      0,setup_i850, poll_i850 },
+	{ 0x8086, 0x1A21, "i840",      0, setup_i840, poll_i840 },
+	{ 0x8086, 0x1A30, "i845",      0, setup_i845, poll_i845 },
+	{ 0x8086, 0x2500, "i820",      0, setup_i820, poll_i820 },
+	{ 0x8086, 0x2530, "i850",      0, setup_i850, poll_i850 },
 	{ 0x8086, 0x2531, "i860",      1, setup_i860, poll_i860 },
 	{ 0x8086, 0x7030, "i430vx",    0, setup_nothing, poll_nothing },
 	{ 0x8086, 0x7120, "i810",      0, setup_nothing, poll_nothing },
@@ -480,6 +549,7 @@
 	{ 0x8086, 0x71A0, "i440gx",    0, setup_i440gx, poll_i440gx },
 	{ 0x8086, 0x71A2, "i440gx",    0, setup_i440gx, poll_i440gx },
 	{ 0x8086, 0x84C5, "i450gx",    0, setup_nothing, poll_nothing },
+	{ 0x8086, 0x2540, "iE7500",    1, setup_iE7500, poll_iE7500 },
 };
 
 static void print_memory_controller(void)
@@ -541,6 +611,7 @@
 	unsigned long device;
 	int i;
 	int result;
+
 	result = pci_conf_read(ctrl.bus, ctrl.dev, ctrl.fn, PCI_VENDOR_ID, 2, &vendor);
 	result = pci_conf_read(ctrl.bus, ctrl.dev, ctrl.fn, PCI_DEVICE_ID, 2, &device);
 	ctrl.index = 0;
@@ -553,7 +624,8 @@
 			}
 		}
 	}
-	controllers[ctrl.index].setup_ecc();
+	controllers[ctrl.index].setup_ecc(); 
+
 	/* Don't enable ECC polling by default unless it has
 	 * been well tested.
 	 */
diff --exclude=CVS -uNr memtest86-3.0/elf.h memtest86/elf.h
--- memtest86-3.0/elf.h	Wed Dec 31 17:00:00 1969
+++ memtest86/elf.h	Sat Aug 16 23:17:22 2003
@@ -0,0 +1,590 @@
+#ifndef ELF_H
+#define ELF_H
+
+#define EI_NIDENT	16	/* Size of e_ident array. */
+
+/* Values for e_type. */
+#define ET_NONE		0	/* No file type */
+#define ET_REL		1	/* Relocatable file */
+#define ET_EXEC		2	/* Executable file */
+#define ET_DYN		3	/* Shared object file */
+#define ET_CORE		4	/* Core file */
+
+/* Values for e_machine (architecute). */
+#define EM_NONE		 0		/* No machine */
+#define EM_M32		 1		/* AT&T WE 32100 */
+#define EM_SPARC	 2		/* SUN SPARC */
+#define EM_386		 3		/* Intel 80386+ */
+#define EM_68K		 4		/* Motorola m68k family */
+#define EM_88K		 5		/* Motorola m88k family */
+#define EM_486		 6		/* Perhaps disused */
+#define EM_860		 7		/* Intel 80860 */
+#define EM_MIPS		 8		/* MIPS R3000 big-endian */
+#define EM_S370		 9		/* IBM System/370 */
+#define EM_MIPS_RS3_LE	10		/* MIPS R3000 little-endian */
+
+#define EM_PARISC	15		/* HPPA */
+#define EM_VPP500	17		/* Fujitsu VPP500 */
+#define EM_SPARC32PLUS	18		/* Sun's "v8plus" */
+#define EM_960		19		/* Intel 80960 */
+#define EM_PPC		20		/* PowerPC */
+#define EM_PPC64	21		/* PowerPC 64-bit */
+#define EM_S390		22		/* IBM S390 */
+
+#define EM_V800		36		/* NEC V800 series */
+#define EM_FR20		37		/* Fujitsu FR20 */
+#define EM_RH32		38		/* TRW RH-32 */
+#define EM_RCE		39		/* Motorola RCE */
+#define EM_ARM		40		/* ARM */
+#define EM_FAKE_ALPHA	41		/* Digital Alpha */
+#define EM_SH		42		/* Hitachi SH */
+#define EM_SPARCV9	43		/* SPARC v9 64-bit */
+#define EM_TRICORE	44		/* Siemens Tricore */
+#define EM_ARC		45		/* Argonaut RISC Core */
+#define EM_H8_300	46		/* Hitachi H8/300 */
+#define EM_H8_300H	47		/* Hitachi H8/300H */
+#define EM_H8S		48		/* Hitachi H8S */
+#define EM_H8_500	49		/* Hitachi H8/500 */
+#define EM_IA_64	50		/* Intel Merced */
+#define EM_MIPS_X	51		/* Stanford MIPS-X */
+#define EM_COLDFIRE	52		/* Motorola Coldfire */
+#define EM_68HC12	53		/* Motorola M68HC12 */
+#define EM_MMA		54		/* Fujitsu MMA Multimedia Accelerator*/
+#define EM_PCP		55		/* Siemens PCP */
+#define EM_NCPU		56		/* Sony nCPU embeeded RISC */
+#define EM_NDR1		57		/* Denso NDR1 microprocessor */
+#define EM_STARCORE	58		/* Motorola Start*Core processor */
+#define EM_ME16		59		/* Toyota ME16 processor */
+#define EM_ST100	60		/* STMicroelectronic ST100 processor */
+#define EM_TINYJ	61		/* Advanced Logic Corp. Tinyj emb.fam*/
+#define EM_X86_64	62		/* AMD x86-64 architecture */
+#define EM_PDSP		63		/* Sony DSP Processor */
+
+#define EM_FX66		66		/* Siemens FX66 microcontroller */
+#define EM_ST9PLUS	67		/* STMicroelectronics ST9+ 8/16 mc */
+#define EM_ST7		68		/* STmicroelectronics ST7 8 bit mc */
+#define EM_68HC16	69		/* Motorola MC68HC16 microcontroller */
+#define EM_68HC11	70		/* Motorola MC68HC11 microcontroller */
+#define EM_68HC08	71		/* Motorola MC68HC08 microcontroller */
+#define EM_68HC05	72		/* Motorola MC68HC05 microcontroller */
+#define EM_SVX		73		/* Silicon Graphics SVx */
+#define EM_AT19		74		/* STMicroelectronics ST19 8 bit mc */
+#define EM_VAX		75		/* Digital VAX */
+#define EM_CRIS		76		/* Axis Communications 32-bit embedded processor */
+#define EM_JAVELIN	77		/* Infineon Technologies 32-bit embedded processor */
+#define EM_FIREPATH	78		/* Element 14 64-bit DSP Processor */
+#define EM_ZSP		79		/* LSI Logic 16-bit DSP Processor */
+#define EM_MMIX		80		/* Donald Knuth's educational 64-bit processor */
+#define EM_HUANY	81		/* Harvard University machine-independent object files */
+#define EM_PRISM	82		/* SiTera Prism */
+#define EM_AVR		83		/* Atmel AVR 8-bit microcontroller */
+#define EM_FR30		84		/* Fujitsu FR30 */
+#define EM_D10V		85		/* Mitsubishi D10V */
+#define EM_D30V		86		/* Mitsubishi D30V */
+#define EM_V850		87		/* NEC v850 */
+#define EM_M32R		88		/* Mitsubishi M32R */
+#define EM_MN10300	89		/* Matsushita MN10300 */
+#define EM_MN10200	90		/* Matsushita MN10200 */
+#define EM_PJ		91		/* picoJava */
+#define EM_OPENRISC	92		/* OpenRISC 32-bit embedded processor */
+#define EM_ARC_A5	93		/* ARC Cores Tangent-A5 */
+#define EM_XTENSA	94		/* Tensilica Xtensa Architecture */
+#define EM_NUM		95
+
+/* Values for p_type. */
+#define PT_NULL		0	/* Unused entry. */
+#define PT_LOAD		1	/* Loadable segment. */
+#define PT_DYNAMIC	2	/* Dynamic linking information segment. */
+#define PT_INTERP	3	/* Pathname of interpreter. */
+#define PT_NOTE		4	/* Auxiliary information. */
+#define PT_SHLIB	5	/* Reserved (not used). */
+#define PT_PHDR		6	/* Location of program header itself. */
+
+/* Values for p_flags. */
+#define PF_X		0x1	/* Executable. */
+#define PF_W		0x2	/* Writable. */
+#define PF_R		0x4	/* Readable. */
+
+
+#define	ELF_PROGRAM_RETURNS_BIT	0x8000000	/* e_flags bit 31 */
+
+#define EI_MAG0		0
+#define ELFMAG0		0x7f
+
+#define EI_MAG1		1
+#define ELFMAG1		'E'
+
+#define EI_MAG2		2
+#define ELFMAG2		'L'
+
+#define EI_MAG3		3
+#define ELFMAG3		'F'
+
+#define ELFMAG		"\177ELF"
+
+#define EI_CLASS	4	/* File class byte index */
+#define ELFCLASSNONE	0	/* Invalid class */
+#define ELFCLASS32	1	/* 32-bit objects */
+#define ELFCLASS64	2	/* 64-bit objects */
+
+#define EI_DATA		5	/* Data encodeing byte index */
+#define ELFDATANONE	0	/* Invalid data encoding */
+#define ELFDATA2LSB	1	/* 2's complement little endian */
+#define ELFDATA2MSB	2	/* 2's complement big endian */
+
+#define EI_VERSION	6	/* File version byte index */
+				/* Value must be EV_CURRENT */
+
+#define EV_NONE		0	/* Invalid ELF Version */
+#define EV_CURRENT	1	/* Current version */
+
+#define ELF32_PHDR_SIZE (8*4)	/* Size of an elf program header */
+
+#ifndef ASSEMBLY
+
+#include "stdint.h"
+
+/*
+ * ELF definitions common to all 32-bit architectures.
+ */
+
+typedef uint32_t	Elf32_Addr;
+typedef uint16_t	Elf32_Half;
+typedef uint32_t	Elf32_Off;
+typedef uint16_t	Elf32_Section;
+typedef int32_t		Elf32_Sword;
+typedef uint32_t	Elf32_Word;
+typedef uint32_t	Elf32_Size;
+
+typedef uint64_t	Elf64_Addr;
+typedef uint16_t	Elf64_Half;
+typedef uint64_t	Elf64_Off;
+typedef uint16_t	Elf64_Section;
+typedef int32_t		Elf64_Sword;
+typedef uint32_t	Elf64_Word;
+typedef uint64_t	Elf64_Size;
+typedef uint64_t	Elf64_Xword;
+typedef	int64_t		Elf64_Sxword;
+
+/*
+ * ELF header.
+ */
+typedef struct {
+	unsigned char	e_ident[EI_NIDENT];	/* File identification. */
+	Elf32_Half	e_type;		/* File type. */
+	Elf32_Half	e_machine;	/* Machine architecture. */
+	Elf32_Word	e_version;	/* ELF format version. */
+	Elf32_Addr	e_entry;	/* Entry point. */
+	Elf32_Off	e_phoff;	/* Program header file offset. */
+	Elf32_Off	e_shoff;	/* Section header file offset. */
+	Elf32_Word	e_flags;	/* Architecture-specific flags. */
+	Elf32_Half	e_ehsize;	/* Size of ELF header in bytes. */
+	Elf32_Half	e_phentsize;	/* Size of program header entry. */
+	Elf32_Half	e_phnum;	/* Number of program header entries. */
+	Elf32_Half	e_shentsize;	/* Size of section header entry. */
+	Elf32_Half	e_shnum;	/* Number of section header entries. */
+	Elf32_Half	e_shstrndx;	/* Section name strings section. */
+} Elf32_Ehdr;
+
+typedef struct {
+	unsigned char	e_ident[EI_NIDENT];	/* File identification. */
+	Elf64_Half	e_type;		/* File type. */
+	Elf64_Half	e_machine;	/* Machine architecture. */
+	Elf64_Word	e_version;	/* ELF format version. */
+	Elf64_Addr	e_entry;	/* Entry point. */
+	Elf64_Off	e_phoff;	/* Program header file offset. */
+	Elf64_Off	e_shoff;	/* Section header file offset. */
+	Elf64_Word	e_flags;	/* Architecture-specific flags. */
+	Elf64_Half	e_ehsize;	/* Size of ELF header in bytes. */
+	Elf64_Half	e_phentsize;	/* Size of program header entry. */
+	Elf64_Half	e_phnum;	/* Number of program header entries. */
+	Elf64_Half	e_shentsize;	/* Size of section header entry. */
+	Elf64_Half	e_shnum;	/* Number of section header entries. */
+	Elf64_Half	e_shstrndx;	/* Section name strings section. */
+} Elf64_Ehdr;
+
+/*
+ * Program header.
+ */
+typedef struct {
+	Elf32_Word	p_type;		/* Entry type. */
+	Elf32_Off	p_offset;	/* File offset of contents. */
+	Elf32_Addr	p_vaddr;	/* Virtual address (not used). */
+	Elf32_Addr	p_paddr;	/* Physical address. */
+	Elf32_Size	p_filesz;	/* Size of contents in file. */
+	Elf32_Size	p_memsz;	/* Size of contents in memory. */
+	Elf32_Word	p_flags;	/* Access permission flags. */
+	Elf32_Size	p_align;	/* Alignment in memory and file. */
+} Elf32_Phdr;
+
+typedef struct {
+	Elf64_Word	p_type;		/* Entry type. */
+	Elf64_Word	p_flags;	/* Access permission flags. */
+	Elf64_Off	p_offset;	/* File offset of contents. */
+	Elf64_Addr	p_vaddr;	/* Virtual address (not used). */
+	Elf64_Addr	p_paddr;	/* Physical address. */
+	Elf64_Size	p_filesz;	/* Size of contents in file. */
+	Elf64_Size	p_memsz;	/* Size of contents in memory. */
+	Elf64_Size	p_align;	/* Alignment in memory and file. */
+} Elf64_Phdr;
+
+
+/* Dynamic section entry.  */
+
+typedef struct
+{
+	Elf32_Sword	d_tag;			/* Dynamic entry type */
+	union
+	{
+		Elf32_Word d_val;			/* Integer value */
+		Elf32_Addr d_ptr;			/* Address value */
+	} d_un;
+} Elf32_Dyn;
+
+typedef struct
+{
+	Elf64_Sxword	d_tag;			/* Dynamic entry type */
+	union
+	{
+		Elf64_Xword d_val;		/* Integer value */
+		Elf64_Addr d_ptr;		/* Address value */
+	} d_un;
+} Elf64_Dyn;
+
+/* Legal values for d_tag (dynamic entry type).  */
+
+#define DT_NULL		0		/* Marks end of dynamic section */
+#define DT_NEEDED	1		/* Name of needed library */
+#define DT_PLTRELSZ	2		/* Size in bytes of PLT relocs */
+#define DT_PLTGOT	3		/* Processor defined value */
+#define DT_HASH		4		/* Address of symbol hash table */
+#define DT_STRTAB	5		/* Address of string table */
+#define DT_SYMTAB	6		/* Address of symbol table */
+#define DT_RELA		7		/* Address of Rela relocs */
+#define DT_RELASZ	8		/* Total size of Rela relocs */
+#define DT_RELAENT	9		/* Size of one Rela reloc */
+#define DT_STRSZ	10		/* Size of string table */
+#define DT_SYMENT	11		/* Size of one symbol table entry */
+#define DT_INIT		12		/* Address of init function */
+#define DT_FINI		13		/* Address of termination function */
+#define DT_SONAME	14		/* Name of shared object */
+#define DT_RPATH	15		/* Library search path (deprecated) */
+#define DT_SYMBOLIC	16		/* Start symbol search here */
+#define DT_REL		17		/* Address of Rel relocs */
+#define DT_RELSZ	18		/* Total size of Rel relocs */
+#define DT_RELENT	19		/* Size of one Rel reloc */
+#define DT_PLTREL	20		/* Type of reloc in PLT */
+#define DT_DEBUG	21		/* For debugging; unspecified */
+#define DT_TEXTREL	22		/* Reloc might modify .text */
+#define DT_JMPREL	23		/* Address of PLT relocs */
+#define	DT_BIND_NOW	24		/* Process relocations of object */
+#define	DT_INIT_ARRAY	25		/* Array with addresses of init fct */
+#define	DT_FINI_ARRAY	26		/* Array with addresses of fini fct */
+#define	DT_INIT_ARRAYSZ	27		/* Size in bytes of DT_INIT_ARRAY */
+#define	DT_FINI_ARRAYSZ	28		/* Size in bytes of DT_FINI_ARRAY */
+#define DT_RUNPATH	29		/* Library search path */
+#define DT_FLAGS	30		/* Flags for the object being loaded */
+#define DT_ENCODING	32		/* Start of encoded range */
+#define DT_PREINIT_ARRAY 32		/* Array with addresses of preinit fct*/
+#define DT_PREINIT_ARRAYSZ 33		/* size in bytes of DT_PREINIT_ARRAY */
+#define	DT_NUM		34		/* Number used */
+#define DT_LOOS		0x6000000d	/* Start of OS-specific */
+#define DT_HIOS		0x6ffff000	/* End of OS-specific */
+#define DT_LOPROC	0x70000000	/* Start of processor-specific */
+#define DT_HIPROC	0x7fffffff	/* End of processor-specific */
+#define	DT_PROCNUM	0x32		/* Most used by any processor */
+
+/* DT_* entries which fall between DT_VALRNGHI & DT_VALRNGLO use the
+   Dyn.d_un.d_val field of the Elf*_Dyn structure.  This follows Sun's
+   approach.  */
+#define DT_VALRNGLO	0x6ffffd00
+#define DT_GNU_PRELINKED 0x6ffffdf5	/* Prelinking timestamp */
+#define DT_GNU_CONFLICTSZ 0x6ffffdf6	/* Size of conflict section */
+#define DT_GNU_LIBLISTSZ 0x6ffffdf7	/* Size of library list */
+#define DT_CHECKSUM	0x6ffffdf8
+#define DT_PLTPADSZ	0x6ffffdf9
+#define DT_MOVEENT	0x6ffffdfa
+#define DT_MOVESZ	0x6ffffdfb
+#define DT_FEATURE_1	0x6ffffdfc	/* Feature selection (DTF_*).  */
+#define DT_POSFLAG_1	0x6ffffdfd	/* Flags for DT_* entries, effecting
+					   the following DT_* entry.  */
+#define DT_SYMINSZ	0x6ffffdfe	/* Size of syminfo table (in bytes) */
+#define DT_SYMINENT	0x6ffffdff	/* Entry size of syminfo */
+#define DT_VALRNGHI	0x6ffffdff
+#define DT_VALTAGIDX(tag)	(DT_VALRNGHI - (tag))	/* Reverse order! */
+#define DT_VALNUM 12
+
+/* DT_* entries which fall between DT_ADDRRNGHI & DT_ADDRRNGLO use the
+   Dyn.d_un.d_ptr field of the Elf*_Dyn structure.
+
+   If any adjustment is made to the ELF object after it has been
+   built these entries will need to be adjusted.  */
+#define DT_ADDRRNGLO	0x6ffffe00
+#define DT_GNU_CONFLICT	0x6ffffef8	/* Start of conflict section */
+#define DT_GNU_LIBLIST	0x6ffffef9	/* Library list */
+#define DT_CONFIG	0x6ffffefa	/* Configuration information.  */
+#define DT_DEPAUDIT	0x6ffffefb	/* Dependency auditing.  */
+#define DT_AUDIT	0x6ffffefc	/* Object auditing.  */
+#define	DT_PLTPAD	0x6ffffefd	/* PLT padding.  */
+#define	DT_MOVETAB	0x6ffffefe	/* Move table.  */
+#define DT_SYMINFO	0x6ffffeff	/* Syminfo table.  */
+#define DT_ADDRRNGHI	0x6ffffeff
+#define DT_ADDRTAGIDX(tag)	(DT_ADDRRNGHI - (tag))	/* Reverse order! */
+#define DT_ADDRNUM 10
+
+/* The versioning entry types.  The next are defined as part of the
+   GNU extension.  */
+#define DT_VERSYM	0x6ffffff0
+
+#define DT_RELACOUNT	0x6ffffff9
+#define DT_RELCOUNT	0x6ffffffa
+
+/* These were chosen by Sun.  */
+#define DT_FLAGS_1	0x6ffffffb	/* State flags, see DF_1_* below.  */
+#define	DT_VERDEF	0x6ffffffc	/* Address of version definition
+					   table */
+#define	DT_VERDEFNUM	0x6ffffffd	/* Number of version definitions */
+#define	DT_VERNEED	0x6ffffffe	/* Address of table with needed
+					   versions */
+#define	DT_VERNEEDNUM	0x6fffffff	/* Number of needed versions */
+#define DT_VERSIONTAGIDX(tag)	(DT_VERNEEDNUM - (tag))	/* Reverse order! */
+#define DT_VERSIONTAGNUM 16
+
+/* Sun added these machine-independent extensions in the "processor-specific"
+   range.  Be compatible.  */
+#define DT_AUXILIARY    0x7ffffffd      /* Shared object to load before self */
+#define DT_FILTER       0x7fffffff      /* Shared object to get values from */
+#define DT_EXTRATAGIDX(tag)	((Elf32_Word)-((Elf32_Sword) (tag) <<1>>1)-1)
+#define DT_EXTRANUM	3
+
+/* Values of `d_un.d_val' in the DT_FLAGS entry.  */
+#define DF_ORIGIN	0x00000001	/* Object may use DF_ORIGIN */
+#define DF_SYMBOLIC	0x00000002	/* Symbol resolutions starts here */
+#define DF_TEXTREL	0x00000004	/* Object contains text relocations */
+#define DF_BIND_NOW	0x00000008	/* No lazy binding for this object */
+#define DF_STATIC_TLS	0x00000010	/* Module uses the static TLS model */
+
+/* State flags selectable in the `d_un.d_val' element of the DT_FLAGS_1
+   entry in the dynamic section.  */
+#define DF_1_NOW	0x00000001	/* Set RTLD_NOW for this object.  */
+#define DF_1_GLOBAL	0x00000002	/* Set RTLD_GLOBAL for this object.  */
+#define DF_1_GROUP	0x00000004	/* Set RTLD_GROUP for this object.  */
+#define DF_1_NODELETE	0x00000008	/* Set RTLD_NODELETE for this object.*/
+#define DF_1_LOADFLTR	0x00000010	/* Trigger filtee loading at runtime.*/
+#define DF_1_INITFIRST	0x00000020	/* Set RTLD_INITFIRST for this object*/
+#define DF_1_NOOPEN	0x00000040	/* Set RTLD_NOOPEN for this object.  */
+#define DF_1_ORIGIN	0x00000080	/* $ORIGIN must be handled.  */
+#define DF_1_DIRECT	0x00000100	/* Direct binding enabled.  */
+#define DF_1_TRANS	0x00000200
+#define DF_1_INTERPOSE	0x00000400	/* Object is used to interpose.  */
+#define DF_1_NODEFLIB	0x00000800	/* Ignore default lib search path.  */
+#define DF_1_NODUMP	0x00001000	/* Object can't be dldump'ed.  */
+#define DF_1_CONFALT	0x00002000	/* Configuration alternative created.*/
+#define DF_1_ENDFILTEE	0x00004000	/* Filtee terminates filters search. */
+#define	DF_1_DISPRELDNE	0x00008000	/* Disp reloc applied at build time. */
+#define	DF_1_DISPRELPND	0x00010000	/* Disp reloc applied at run-time.  */
+
+/* Flags for the feature selection in DT_FEATURE_1.  */
+#define DTF_1_PARINIT	0x00000001
+#define DTF_1_CONFEXP	0x00000002
+
+/* Flags in the DT_POSFLAG_1 entry effecting only the next DT_* entry.  */
+#define DF_P1_LAZYLOAD	0x00000001	/* Lazyload following object.  */
+#define DF_P1_GROUPPERM	0x00000002	/* Symbols from next object are not
+					   generally available.  */
+
+/* Special section indices.  */
+
+#define SHN_UNDEF	0		/* Undefined section */
+#define SHN_LORESERVE	0xff00		/* Start of reserved indices */
+#define SHN_LOPROC	0xff00		/* Start of processor-specific */
+#define SHN_HIPROC	0xff1f		/* End of processor-specific */
+#define SHN_LOOS	0xff20		/* Start of OS-specific */
+#define SHN_HIOS	0xff3f		/* End of OS-specific */
+#define SHN_ABS		0xfff1		/* Associated symbol is absolute */
+#define SHN_COMMON	0xfff2		/* Associated symbol is common */
+#define SHN_XINDEX	0xffff		/* Index is in extra table.  */
+#define SHN_HIRESERVE	0xffff		/* End of reserved indices */
+
+/* Legal values for sh_type (section type).  */
+
+#define SHT_NULL	  0		/* Section header table entry unused */
+#define SHT_PROGBITS	  1		/* Program data */
+#define SHT_SYMTAB	  2		/* Symbol table */
+#define SHT_STRTAB	  3		/* String table */
+#define SHT_RELA	  4		/* Relocation entries with addends */
+#define SHT_HASH	  5		/* Symbol hash table */
+#define SHT_DYNAMIC	  6		/* Dynamic linking information */
+#define SHT_NOTE	  7		/* Notes */
+#define SHT_NOBITS	  8		/* Program space with no data (bss) */
+#define SHT_REL		  9		/* Relocation entries, no addends */
+#define SHT_SHLIB	  10		/* Reserved */
+#define SHT_DYNSYM	  11		/* Dynamic linker symbol table */
+#define SHT_INIT_ARRAY	  14		/* Array of constructors */
+#define SHT_FINI_ARRAY	  15		/* Array of destructors */
+#define SHT_PREINIT_ARRAY 16		/* Array of pre-constructors */
+#define SHT_GROUP	  17		/* Section group */
+#define SHT_SYMTAB_SHNDX  18		/* Extended section indeces */
+#define	SHT_NUM		  19		/* Number of defined types.  */
+#define SHT_LOOS	  0x60000000	/* Start OS-specific */
+#define SHT_GNU_LIBLIST	  0x6ffffff7	/* Prelink library list */
+#define SHT_CHECKSUM	  0x6ffffff8	/* Checksum for DSO content.  */
+#define SHT_LOSUNW	  0x6ffffffa	/* Sun-specific low bound.  */
+#define SHT_SUNW_move	  0x6ffffffa
+#define SHT_SUNW_COMDAT   0x6ffffffb
+#define SHT_SUNW_syminfo  0x6ffffffc
+#define SHT_GNU_verdef	  0x6ffffffd	/* Version definition section.  */
+#define SHT_GNU_verneed	  0x6ffffffe	/* Version needs section.  */
+#define SHT_GNU_versym	  0x6fffffff	/* Version symbol table.  */
+#define SHT_HISUNW	  0x6fffffff	/* Sun-specific high bound.  */
+#define SHT_HIOS	  0x6fffffff	/* End OS-specific type */
+#define SHT_LOPROC	  0x70000000	/* Start of processor-specific */
+#define SHT_HIPROC	  0x7fffffff	/* End of processor-specific */
+#define SHT_LOUSER	  0x80000000	/* Start of application-specific */
+#define SHT_HIUSER	  0x8fffffff	/* End of application-specific */
+
+/* Legal values for sh_flags (section flags).  */
+
+#define SHF_WRITE	     (1 << 0)	/* Writable */
+#define SHF_ALLOC	     (1 << 1)	/* Occupies memory during execution */
+#define SHF_EXECINSTR	     (1 << 2)	/* Executable */
+#define SHF_MERGE	     (1 << 4)	/* Might be merged */
+#define SHF_STRINGS	     (1 << 5)	/* Contains nul-terminated strings */
+#define SHF_INFO_LINK	     (1 << 6)	/* `sh_info' contains SHT index */
+#define SHF_LINK_ORDER	     (1 << 7)	/* Preserve order after combining */
+#define SHF_OS_NONCONFORMING (1 << 8)	/* Non-standard OS specific handling
+					   required */
+#define SHF_GROUP	     (1 << 9)	/* Section is member of a group.  */
+#define SHF_TLS		     (1 << 10)	/* Section hold thread-local data.  */
+#define SHF_MASKOS	     0x0ff00000	/* OS-specific.  */
+#define SHF_MASKPROC	     0xf0000000	/* Processor-specific */
+
+/* Section group handling.  */
+#define GRP_COMDAT	0x1		/* Mark group as COMDAT.  */
+
+/* Symbol table entry.  */
+
+typedef struct
+{
+	Elf32_Word	st_name;	/* Symbol name (string tbl index) */
+	Elf32_Addr	st_value;	/* Symbol value */
+	Elf32_Word	st_size;	/* Symbol size */
+	unsigned char	st_info;	/* Symbol type and binding */
+	unsigned char	st_other;	/* Symbol visibility */
+	Elf32_Section	st_shndx;	/* Section index */
+} Elf32_Sym;
+
+typedef struct
+{
+	Elf64_Word	st_name;	/* Symbol name (string tbl index) */
+	unsigned char	st_info;	/* Symbol type and binding */
+	unsigned char st_other;		/* Symbol visibility */
+	Elf64_Section	st_shndx;	/* Section index */
+	Elf64_Addr	st_value;	/* Symbol value */
+	Elf64_Xword	st_size;	/* Symbol size */
+} Elf64_Sym;
+
+/* Relocation table entry without addend (in section of type SHT_REL).  */
+
+typedef struct
+{
+	Elf32_Addr	r_offset;	/* Address */
+	Elf32_Word	r_info;		/* Relocation type and symbol index */
+} Elf32_Rel;
+
+/* I have seen two different definitions of the Elf64_Rel and
+   Elf64_Rela structures, so we'll leave them out until Novell (or
+   whoever) gets their act together.  */
+/* The following, at least, is used on Sparc v9, MIPS, and Alpha.  */
+
+typedef struct
+{
+	Elf64_Addr	r_offset;	/* Address */
+	Elf64_Xword	r_info;		/* Relocation type and symbol index */
+} Elf64_Rel;
+
+/* Relocation table entry with addend (in section of type SHT_RELA).  */
+
+typedef struct
+{
+	Elf32_Addr	r_offset;	/* Address */
+	Elf32_Word	r_info;		/* Relocation type and symbol index */
+	Elf32_Sword	r_addend;	/* Addend */
+} Elf32_Rela;
+
+typedef struct
+{
+	Elf64_Addr	r_offset;	/* Address */
+	Elf64_Xword	r_info;		/* Relocation type and symbol index */
+	Elf64_Sxword	r_addend;	/* Addend */
+} Elf64_Rela;
+
+/* How to extract and insert information held in the r_info field.  */
+
+#define ELF32_R_SYM(val)		((val) >> 8)
+#define ELF32_R_TYPE(val)		((val) & 0xff)
+#define ELF32_R_INFO(sym, type)		(((sym) << 8) + ((type) & 0xff))
+
+#define ELF64_R_SYM(i)			((i) >> 32)
+#define ELF64_R_TYPE(i)			((i) & 0xffffffff)
+#define ELF64_R_INFO(sym,type)		((((Elf64_Xword) (sym)) << 32) + (type))
+
+
+/* Intel 80386 specific definitions.  */
+
+/* i386 relocs.  */
+
+#define R_386_NONE	   0		/* No reloc */
+#define R_386_32	   1		/* Direct 32 bit  */
+#define R_386_PC32	   2		/* PC relative 32 bit */
+#define R_386_GOT32	   3		/* 32 bit GOT entry */
+#define R_386_PLT32	   4		/* 32 bit PLT address */
+#define R_386_COPY	   5		/* Copy symbol at runtime */
+#define R_386_GLOB_DAT	   6		/* Create GOT entry */
+#define R_386_JMP_SLOT	   7		/* Create PLT entry */
+#define R_386_RELATIVE	   8		/* Adjust by program base */
+#define R_386_GOTOFF	   9		/* 32 bit offset to GOT */
+#define R_386_GOTPC	   10		/* 32 bit PC relative offset to GOT */
+#define R_386_32PLT	   11
+#define R_386_TLS_TPOFF	   14		/* Offset in static TLS block */
+#define R_386_TLS_IE	   15		/* Address of GOT entry for static TLS
+					   block offset */
+#define R_386_TLS_GOTIE	   16		/* GOT entry for static TLS block
+					   offset */
+#define R_386_TLS_LE	   17		/* Offset relative to static TLS
+					   block */
+#define R_386_TLS_GD	   18		/* Direct 32 bit for GNU version of
+					   general dynamic thread local data */
+#define R_386_TLS_LDM	   19		/* Direct 32 bit for GNU version of
+					   local dynamic thread local data
+					   in LE code */
+#define R_386_16	   20
+#define R_386_PC16	   21
+#define R_386_8		   22
+#define R_386_PC8	   23
+#define R_386_TLS_GD_32	   24		/* Direct 32 bit for general dynamic
+					   thread local data */
+#define R_386_TLS_GD_PUSH  25		/* Tag for pushl in GD TLS code */
+#define R_386_TLS_GD_CALL  26		/* Relocation for call to
+					   __tls_get_addr() */
+#define R_386_TLS_GD_POP   27		/* Tag for popl in GD TLS code */
+#define R_386_TLS_LDM_32   28		/* Direct 32 bit for local dynamic
+					   thread local data in LE code */
+#define R_386_TLS_LDM_PUSH 29		/* Tag for pushl in LDM TLS code */
+#define R_386_TLS_LDM_CALL 30		/* Relocation for call to
+					   __tls_get_addr() in LDM code */
+#define R_386_TLS_LDM_POP  31		/* Tag for popl in LDM TLS code */
+#define R_386_TLS_LDO_32   32		/* Offset relative to TLS block */
+#define R_386_TLS_IE_32	   33		/* GOT entry for negated static TLS
+					   block offset */
+#define R_386_TLS_LE_32	   34		/* Negated offset relative to static
+					   TLS block */
+#define R_386_TLS_DTPMOD32 35		/* ID of module containing symbol */
+#define R_386_TLS_DTPOFF32 36		/* Offset in TLS block */
+#define R_386_TLS_TPOFF32  37		/* Negated offset in static TLS block */
+/* Keep this the last entry.  */
+#define R_386_NUM	   38
+
+#endif /* ASSEMBLY */
+
+#endif /* ELF_H */
diff --exclude=CVS -uNr memtest86-3.0/init.c memtest86/init.c
--- memtest86-3.0/init.c	Tue May 21 16:52:37 2002
+++ memtest86/init.c	Sun Aug 17 04:02:42 2003
@@ -11,7 +11,6 @@
 #include "pci.h"
 #include "io.h"
 
-extern struct vars *v;
 extern short memsz_mode;
 extern short firmware;
 
@@ -47,7 +46,7 @@
 	for(i=0, pp=(char *)(SCREEN_ADR+1); i<TITLE_WIDTH; i++, pp+=2) {
 		*pp = 0x47;
 	}
-	cprint(0, 0, "      Memtest-86 v3.0       ");
+	cprint(0, 0, "      Memtest-86 v3.0.eb2   ");
 
 	/* Do reverse video for the bottom display line */
 	for(i=0, pp=(char *)(SCREEN_ADR+1+(24 * 160)); i<80; i++, pp+=2) {
@@ -82,7 +81,6 @@
 			firmware = FIRMWARE_PCBIOS;
 		}
 	}
-
 	mem_size();
 
 	/* setup pci */
@@ -402,6 +400,16 @@
 			}
 			l1_cache = cpu_id.cache_info[3];
 			l1_cache += cpu_id.cache_info[7];
+			break;
+		case 15:
+			/* FIXME distinguish between the Opteron and Athlon64 */ 
+			cprint(LINE_CPU, 0, "AMD Opteron");
+			off = 11;
+			l1_cache = cpu_id.cache_info[3];
+			l1_cache += cpu_id.cache_info[7];
+			l2_cache = (cpu_id.cache_info[11] << 8);
+			l2_cache += cpu_id.cache_info[10];
+			break;
 		}
 		break;
 
@@ -665,21 +673,40 @@
 static void cacheable(void)
 {
 	ulong speed, pspeed;
-	ulong paddr, mem_top, cache_top;
+	ulong paddr, mem_top, cached;
 
 	mem_top = v->pmap[v->msegs - 1].end;
-	cache_top = mem_top;
+	cached = v->test_pages;
 	pspeed = 0;
 	for (paddr=0x200; paddr <= mem_top - 64; paddr+=0x400) {
+		int i;
+		int found;
+		/* See if the paddr is at a testable location */
+		found = 0;
+		for(i = 0; i < v->msegs; i++) {
+			if ((v->pmap[i].start >= paddr)  &&
+				(v->pmap[i].end <= (paddr + 32))) {
+				found = 1;
+				break;
+			}
+		}
+		if (!found) {
+			continue;
+		}
+		/* Map the range and perform the test */
+		map_page(paddr);
 		speed = memspeed((ulong)mapping(paddr), 32*4096, 1);
 		if (pspeed) {
 			if (speed < pspeed) {
-				cache_top = paddr;
+				cached -= 32;
 			}
 			pspeed = (ulong)((float)speed * 0.7);
 		}
 	}
-	aprint(LINE_INFO, COL_CACHE_TOP, cache_top);
+	aprint(LINE_INFO, COL_CACHE_TOP, cached);
+	/* Ensure the default set of pages are mapped */
+	map_page(0);
+	map_page(0x80000);
 }
 
 
diff --exclude=CVS -uNr memtest86-3.0/lib.c memtest86/lib.c
--- memtest86-3.0/lib.c	Tue May 21 17:12:07 2002
+++ memtest86/lib.c	Sat Aug 16 22:39:41 2003
@@ -9,8 +9,6 @@
 #include "config.h"
 #include "screen_buffer.h"
 
-extern struct vars *v;
-
 int slock = 0, lsr = 0;
 short serial_cons = SERIAL_CONSOLE_DEFAULT;
 char buf[18];
@@ -641,12 +639,16 @@
 	serial_echo_print(p);
 }
 
+#if defined(SERIAL_BAUD_RATE)
+
 #if ((115200%SERIAL_BAUD_RATE) != 0)
 #error Bad ttys0 baud rate
 #endif
 
 #define SERIAL_DIV     (115200/SERIAL_BAUD_RATE)
 
+#endif /* SERIAL_BAUD_RATE */
+
 void serial_echo_init(void)
 {
 	int comstat, hi, lo;
@@ -660,10 +662,12 @@
 
 	/* now do hardwired init */
 	serial_echo_outb(0x03, UART_LCR); /* No parity, 8 data bits, 1 stop */
+#if defined(SERIAL_BAUD_RATE)
 	serial_echo_outb(0x83, UART_LCR); /* Access divisor latch */
 	serial_echo_outb(SERIAL_DIV & 0xff, UART_DLL);  /* baud rate divisor */
 	serial_echo_outb((SERIAL_DIV>> 8) & 0xff, UART_DLM);
 	serial_echo_outb(0x03, UART_LCR); /* Done with divisor */
+#endif
 
 	/* Prior to disabling interrupts, read the LSR and RBR
 	 * registers */
diff --exclude=CVS -uNr memtest86-3.0/linuxbios_tables.h memtest86/linuxbios_tables.h
--- memtest86-3.0/linuxbios_tables.h	Fri Apr 19 11:47:50 2002
+++ memtest86/linuxbios_tables.h	Sat Aug 16 23:03:00 2003
@@ -1,7 +1,7 @@
 #ifndef LINUXBIOS_TABLES_H
 #define LINUXBIOS_TABLES_H
 
-#include <stdint.h>
+#include "stdint.h"
 
 /* The linuxbios table information is for conveying information
  * from the firmware to the loaded OS image.  Primarily this
diff --exclude=CVS -uNr memtest86-3.0/memsize.c memtest86/memsize.c
--- memtest86-3.0/memsize.c	Tue May 21 15:07:01 2002
+++ memtest86/memsize.c	Sun Aug 17 03:53:09 2003
@@ -20,6 +20,7 @@
 extern volatile ulong *p;
 
 static void sort_pmap(void);
+static void sanitize_pmap(void);
 static int check_ram(void);
 static void memsize_bios(int res);
 static void memsize_820(int res);
@@ -70,6 +71,7 @@
 	}
 	/* Guarantee that pmap entries are in ascending order */
 	sort_pmap();
+	sanitize_pmap();
 	v->plim_lower = 0;
 	v->plim_upper = v->pmap[v->msegs-1].end;
 
@@ -111,6 +113,60 @@
 		}
 	}
 }
+
+static void remove_pmap_region(unsigned long res_start, unsigned long res_end)
+{
+	/* Ensure a range of addresses is absent from the pmap */
+	int i;
+	for(i = 0; i < v->msegs; i++) {
+		unsigned long start, end;
+		start = v->pmap[i].start;
+		end = v->pmap[i].end;
+		if ((start < res_start) && (end > res_start)) {
+			/* If the tail of the range overlaps the region, truncate it */
+			v->pmap[i].end = res_start;
+			if ((end > res_end) && (v->msegs < MAX_MEM_SEGMENTS)) {
+				/* If the tail extends past the end of the region
+				 * insert a new pmap entry for the tail.
+				 */
+				memmove(&v->pmap[i+2], &v->pmap[i + 1],
+					((v->msegs - 1) - i) *sizeof(v->pmap[0]));
+				v->msegs += 1;
+				i += 1;
+				start = res_start;
+				v->pmap[i].start = start;
+				v->pmap[i].end = end;
+			}
+			else {
+				end = res_start;
+			}
+		}
+		if ((start >= res_start) && (end <= res_end)) {
+			/* If the range is completely contained in the region remove it */
+			memmove(&v->pmap[i], &v->pmap[i+1],
+				((v->msegs - 1) - i) * sizeof(v->pmap[0]));
+			v->msegs -= 1;
+			i -= 1;
+		}
+		else if ((start < res_end) && (end > res_end)) {
+			/* If the start is in the middle of the region increment it */
+			start = res_end;
+			v->pmap[i].start = start;
+		}
+	}
+}
+
+static void sanitize_pmap(void)
+{
+	/* Remove any questionable addresses from the memory map */
+	/* Unless we really trust the BIOS don't test 640-1M */
+	if (firmware != FIRMWARE_LINUXBIOS) {
+		remove_pmap_region(RES_START >> 12 , (RES_END + 4095) >> 12);
+	}
+	/* Never test where our video buffer lives */
+	remove_pmap_region(SCREEN_ADR >> 12, (SCREEN_END_ADR  + 4095) >> 12);
+}
+
 static void memsize_linuxbios(void)
 {
 	int i, n;
@@ -155,16 +211,6 @@
 			start = nm[i].addr;
 			end = start + nm[i].size;
 
-			/* Don't ever use memory between 640 and 1024k */
-			if (start > RES_START && start < RES_END) {
-				if (end < RES_END) {
-					continue;
-				}
-				start = RES_END;
-			}
-			if (end > RES_START && end < RES_END) {
-				end = RES_START;
-			}
 			v->pmap[n].start = (start + 4095) >> 12;
 			v->pmap[n].end = end >> 12;
 			v->test_pages += v->pmap[n].end - v->pmap[n].start;
diff --exclude=CVS -uNr memtest86-3.0/memtest_shared.lds memtest86/memtest_shared.lds
--- memtest86-3.0/memtest_shared.lds	Mon Apr 22 00:11:15 2002
+++ memtest86/memtest_shared.lds	Sun Aug 17 02:26:29 2003
@@ -20,11 +20,11 @@
 	.hash       : { *(.hash) }
 	.dynamic    : { *(.dynamic) }
 
-	.rel.text   : { *(.rel.text) }
-	.rel.rodata : { *(.rel.rodata) }
-	.rel.data   : { *(.rel.data) }
-	.rel.got    : { *(.rel.got) }
-	.rel.plt    : { *(.rel.plt) }
+	.rel.text    : { *(.rel.text   .rel.text.*) }
+	.rel.rodata  : { *(.rel.rodata .rel.rodata.*) }
+	.rel.data    : { *(.rel.data   .rel.data.*) }
+	.rel.got     : { *(.rel.got    .rel.got.*) }
+	.rel.plt     : { *(.rel.plt    .rel.plt.*) }
 
 	. = ALIGN(4);
 	.data : {
diff --exclude=CVS -uNr memtest86-3.0/patn.c memtest86/patn.c
--- memtest86-3.0/patn.c	Wed Oct 17 17:30:32 2001
+++ memtest86/patn.c	Sat Aug 16 22:39:55 2003
@@ -18,9 +18,6 @@
 #define DEFAULT_MASK ((~0L) << 2)
 
 
-extern struct vars *v;
-
-
 /* What it does:
  *  - Keep track of a number of BadRAM patterns in an array;
  *  - Combine new faulty addresses with it whenever possible;
Binary files memtest86-3.0/precomp.bin and memtest86/precomp.bin differ
diff --exclude=CVS -uNr memtest86-3.0/reloc.c memtest86/reloc.c
--- memtest86-3.0/reloc.c	Mon Apr 15 12:54:01 2002
+++ memtest86/reloc.c	Sat Aug 16 23:23:10 2003
@@ -1,7 +1,7 @@
 #include <stddef.h>
-#include <stdint.h>
-#include <elf.h>
 #include <string.h>
+#include "stdint.h"
+#include "elf.h"
 
 #define __ELF_NATIVE_CLASS 32
 #define ELF_MACHINE_NO_RELA 1
@@ -68,7 +68,7 @@
 {
 	Elf32_Addr ls_addr, s_addr;
 	Elf32_Addr value;
-	if (ELF32_R_TYPE (reloc->r_info) == R_386_RELATIVE)
+	if (ELF32_R_TYPE (reloc->r_info) == R_386_RELATIVE) 
 	{
 		*reloc_addr += map->l_addr - map->ll_addr;
 		return;
diff --exclude=CVS -uNr memtest86-3.0/stdint.h memtest86/stdint.h
--- memtest86-3.0/stdint.h	Wed Dec 31 17:00:00 1969
+++ memtest86/stdint.h	Sat Aug 16 23:02:10 2003
@@ -0,0 +1,52 @@
+#ifndef I386_STDINT_H
+#define I386_STDINT_H
+
+/* Exact integral types */
+typedef unsigned char      uint8_t;
+typedef signed char        int8_t; 
+
+typedef unsigned short     uint16_t;
+typedef signed short       int16_t;
+
+typedef unsigned int       uint32_t;
+typedef signed int         int32_t;
+
+typedef unsigned long long uint64_t;
+typedef signed long long   int64_t;
+
+/* Small types */
+typedef unsigned char      uint_least8_t;
+typedef signed char        int_least8_t; 
+
+typedef unsigned short     uint_least16_t;
+typedef signed short       int_least16_t;
+
+typedef unsigned int       uint_least32_t;
+typedef signed int         int_least32_t;
+
+typedef unsigned long long uint_least64_t;
+typedef signed long long   int_least64_t;
+
+/* Fast Types */
+typedef unsigned char      uint_fast8_t;
+typedef signed char        int_fast8_t; 
+
+typedef unsigned int       uint_fast16_t;
+typedef signed int         int_fast16_t;
+
+typedef unsigned int       uint_fast32_t;
+typedef signed int         int_fast32_t;
+
+typedef unsigned long long uint_fast64_t;
+typedef signed long long   int_fast64_t;
+
+/* Types for `void *' pointers.  */
+typedef int                intptr_t;
+typedef unsigned int       uintptr_t;
+
+/* Largest integral types */
+typedef long long int      intmax_t;
+typedef unsigned long long uintmax_t;
+
+
+#endif /* I386_STDINT_H */
diff --exclude=CVS -uNr memtest86-3.0/test.c memtest86/test.c
--- memtest86-3.0/test.c	Tue May 21 17:13:32 2002
+++ memtest86/test.c	Thu Jan 30 17:20:16 2003
@@ -9,7 +9,6 @@
 extern int segs, bail;
 extern volatile ulong *p;
 extern ulong p1, p2;
-extern struct vars *v;
 extern int test_ticks, nticks;
 extern struct tseq tseq[];
 void poll_errors();
@@ -1282,7 +1281,7 @@
  * Print an ecc error
  */
 void print_ecc_err(unsigned long page, unsigned long offset, 
-	int corrected, unsigned char syndrom, int channel)
+	int corrected, unsigned short syndrome, int channel)
 {
 	update_err_counts();
 	++(v->ecc_ecount);
@@ -1293,7 +1292,7 @@
 
 	cprint(v->msg_line, 36, 
 		corrected?"corrected           ": "uncorrected         ");
-	hprint2(v->msg_line, 56, syndrom, 2);
+	hprint2(v->msg_line, 56, syndrome, 4);
 	cprint(v->msg_line, 66, "ECC"); 
 	dprint(v->msg_line, 71, channel, 2, 0);
 }
diff --exclude=CVS -uNr memtest86-3.0/test.h memtest86/test.h
--- memtest86-3.0/test.h	Tue May 21 15:06:16 2002
+++ memtest86/test.h	Sun Aug 17 04:04:33 2003
@@ -44,6 +44,7 @@
 #define RES_START	0xa0000
 #define RES_END		0x100000
 #define SCREEN_ADR	0xb8000
+#define SCREEN_END_ADR  (SCREEN_ADR + 80*25*2)
 
 #define TITLE_WIDTH	28
 #define LINE_TIME	9
@@ -129,7 +130,7 @@
 void find_ticks(void);
 void print_err(ulong *adr, ulong good, ulong bad, ulong xor);
 void print_ecc_err(ulong page, ulong offset, int corrected, 
-	unsigned char syndrom, int channel);
+	unsigned short syndrome, int channel);
 void mem_size(void);
 void adj_mem(void);
 ulong getval(int x, int y, int result_shift);



From ebiederman at lnxi.com  Sun Aug 17 14:11:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Aug 17 14:11:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030812143609.GC3767@suse.de>
References: <20030812103627.GA1759@suse.de>
	<Pine.LNX.4.44.0308120729470.3381-100000@maxroach.lanl.gov>
	<20030812143609.GC3767@suse.de>
Message-ID: <m3fzk0uofa.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * ron minnich <rminnich at lanl.gov> [030812 15:33]:
> > On Tue, 12 Aug 2003, Stefan Reinauer wrote:
> > 
> > I'm not so sure. The emulation code supports the INT functions needed for 
> > vga setup. I would actually be inclined to dump ADLO rombios.c completely 
> > and replace it with real C code. 
>  
> which is what the freebios1 bioscall code and util/vgabios/testbios do
> already, just in a non-complete way.
> 
> > ADLO is a great proof-of-concept but after walking the code I find too 
> > much assembly in there, most of it not needed.
> 
> > It's the bochs heritage. 
> 
> definitely. they put a lot of focus on having all the fixed address bios
> entries at the right place, but we hopefully dont need that to
> initialize vga (at least the milo x86 emulation code never did that)

Looking at the various specifications there is an additional route
we can take.  We can have the 16bit trampoline detect if it is running
in v86 mode, and if so use the appropriate DPMI/VCPI/XMS functions to
switch to protected mode instead of our hand crafted code.

That should allow us to run under Win9x, freedos, and djgpp.  For
Freebsd we will probably need a couple of the very most common calls
implemented in the 16bit trampoline as well.  And of course we can
still implement the legacy entry points.

- It is not clear what an Option ROM will care about so being as
  backward compatible as possible is a real plus.

- Going with a solution that can (at least in theory) handle
  all of the legacy backwards compatibility cases will allow us
  to concentrate on a single implementation.

- Going with a solution that is primarily 32bit C code will allow us
  to reuse the code in appropriate ways.

- Not using v86 mode by default will allow a high degree of
  compatibility anyway.

Does a version of ADLO that runs as 32bit C code sound reasonable?

Eric



From ts1 at tsn.or.jp  Sun Aug 17 14:40:00 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Sun Aug 17 14:40:00 2003
Subject: Questions on BX Chipset
In-Reply-To: <Pine.LNX.4.44.0308140755510.22535-100000@maxroach.lanl.gov>
References: <200308141554.11808.meinrad.sauter@gmx.de> <Pine.LNX.4.44.0308140755510.22535-100000@maxroach.lanl.gov>
Message-ID: <20030817185425.GA14755@tsn.or.jp>

On Thu, Aug 14, 2003 at 07:57:21AM -0600, ron minnich wrote:
> On Thu, 14 Aug 2003, Meinrad Sauter wrote:
> 
> > Enabling extended BIOS access
> > Enabling Full ISA Mode
> > Enabling IRQ8
> > Enabling Mouse IRQ12 on piix4e
> > done.
> > INSTALL REAL-MODE IDT
> > DO THE VGA BIOS
> > found VGA: vid=110b, did=4
> > 0x55 0xaa 0x40 0xea 0xbe 0x31 0x0 0xc0 0x0 0x0 0xc3 0x0 0x14 0x0 0x0 0x0 
> > biosint: # 0x6, eax 0x0 ebx 0xd5b4 ecx 0x720 edx 0xa2f1
> > biosint: ebp 0x136ac esp 0xff6 edi 0xf6d4 esi 0xfb9fc
> > biosint: ip 0x3 cs 0x0 flags 0x46
> > biosint: Unsupport int #0x6
> > biosint: # 0x6, eax 0x0 ebx 0xd5b4 ecx 0x720 edx 0xa2f1
> > biosint: ebp 0x136ac esp 0xff6 edi 0xf6d4 esi 0xfb9fc
> > biosint: ip 0x3 cs 0x0 flags 0x46
> > biosint: Unsupport int #0x6
> > biosint: # 0x6, eax 0x0 ebx 0xd5b4 ecx 0x720 edx 0xa2f1
> > biosint: ebp 0x136ac esp 0xff6 edi 0xf6d4 esi 0xfb9fc
> > biosint: ip 0x3 cs 0x0 flags 0x46
> > biosint: Unsupport int #0x6
> > 
> 
> yes, sorry, you just hit an int we don't support yet. It's all working 
> right, but you'll need to implement int #6. 

INT6 is not a BIOS service. It's a CPU exception -- invalid opcode.

At this point we don't have an easy way other than gnireenigne esrever
to track this down.
And the CS:IP prints here are probably incorrect, so if you go this
way you must fix this first (I have a patch for it, but I'm not sure
if it's good for other versions of GCC than the one I used).

The other way is to gain legacy compatibility, like BIOS data area,
farcall entry points, etc, one by one, until your VGA BIOS happens to
work...

--
Takeshi


From ts1 at tsn.or.jp  Sun Aug 17 14:58:00 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Sun Aug 17 14:58:00 2003
Subject: Memory on EPIA
In-Reply-To: <51619.128.165.250.195.1060809796.squirrel@mail.flagen.com>
References: <51619.128.165.250.195.1060809796.squirrel@mail.flagen.com>
Message-ID: <20030817191313.GB14755@tsn.or.jp>

On Wed, Aug 13, 2003 at 02:23:16PM -0700, David Hendricks wrote:
> I was wondering what kind of memory you all were using for your EPIAs and
> if anyone has been tweaking things like memory timings in their freebios
> tree.
> 
> I've been using Corsair PC-133 cas latency 2 memory modules (Specs here:
> http://www.corsairmicro.com/main/products/specs/cm654s256.html ) without
> modification to any epia code in my tree. However, I keep getting stuck at
> the "jumping to boot code" message in elfboot with via-rhine and memtest
> payloads.
> 
> I have lots of RAM at my disposal, but would like to know if there's a
> specific type that seems to work best.

I've tried 3 different DIMMs, all of them are no-name (some have marking
in Japanese).
And all of them worked with EPIA 5000, the one with 533MHz CPU.
I've also tried PC133 and CL2 timings when the DIMM should supports
them, and they just worked.

--
Takeshi


From ts1 at tsn.or.jp  Sun Aug 17 15:10:01 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Sun Aug 17 15:10:01 2003
Subject: EPIA Linuxbios strangeness
In-Reply-To: <20030811144204.GA24442@planetfall.com>
References: <20030811144204.GA24442@planetfall.com>
Message-ID: <20030817192458.GC14755@tsn.or.jp>

On Mon, Aug 11, 2003 at 09:42:04AM -0500, Jeff Noxon wrote:
> 2) I can't do a software reboot either.  The machine just goes dead if
> I try "init 6" or any variation of the reboot command.

Setting bit 1 of ISA bridge register 4F does a system reset.
I have these lines instead of /sbin/reboot in /etc/init.d/reboot
(Debian system).

    sleep 1
    setpci -s 0:11.0 4f.b=9

For power-off, I'm using a small program in /etc/init.d/halt.
It is something like the one I posted to this list before
(now with the daemon mode to watch the power-button hit).

However, these things should eventually go in the kernel.
Userspace solutions ignore shutdown callbacks in the kernel,
so it might be dangerous. For me these things work well,
probably helped by "sleep 1" to allow the drive to flush its
writeback cache..

> 3) If I unplug it & plug it back in, the power stays off.

It needs some programming to the supersouth.

--
Takeshi


From steve at nexpath.com  Sun Aug 17 15:57:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Sun Aug 17 15:57:01 2003
Subject: EPIA Linuxbios strangeness
In-Reply-To: <20030817192458.GC14755@tsn.or.jp>
References: <20030811144204.GA24442@planetfall.com> <20030817192458.GC14755@tsn.or.jp>
Message-ID: <3F3FE1AD.60208@nexpath.com>

SONE Takeshi wrote:

> Setting bit 1 of ISA bridge register 4F does a system reset.
> I have these lines instead of /sbin/reboot in /etc/init.d/reboot
> (Debian system).
> 
>     sleep 1
>     setpci -s 0:11.0 4f.b=9
> 

 From the datasheet:

Via VT8231 fn 0
Offset 4F ?PCI Bus and CPU Interface Control ..........RW
----------------------------------------------------------

7-4 Reserved ................always reads 0
3 CPU Reset Source
   0 Use CPURST as CPU Reset..default
   1 Use INIT# as CPU Reset
2 Config Command Reg Rx04 Access (Test Only)
   0 Normal:Bits 0-1=RO,Bit 3=RW...default
   1 Test Mode:Bits 0-1=RW,Bit-3=RO
1 IRDY #Wait States
   0 0 Wait States.............default
   1 1 WaitState
0 Software PCI Reset ...write 1 to generate PCI reset

What about the ACPI I/O space (set same as Award BIOS, I think, 0x4000), 
in particular 0x4002, 0x4003? Anyway this can be used?

-Steve



From yhlu at tyan.com  Sun Aug 17 19:24:01 2003
From: yhlu at tyan.com (Yinghai Lu)
Date: Sun Aug 17 19:24:01 2003
Subject: s2885
In-Reply-To: <m33cg1v7wc.fsf@maxwell.lnxi.com>
Message-ID: <000201c36518$68aeea20$dbcba140@yhlunb>

I add one printf if tg3.c to produce "err=?".

YH

-----????-----
???: Eric W. Biederman [mailto:eric at lnxi.com] ?? Eric W. Biederman
????: 2003?8?16? 10:18
???: Etherboot-users
??: YhLu; 'linuxbios at clustermatic.org'; Jeff Noxon
??: Re: s2885


Guys the etherboot users list is really the right forum for
this kind of question. 

Jeff Noxon <jeff at planetfall.com> writes:

> I can't get it to work with a 3com 3C996T (14e4:1644) ... it
recognizes
> the card but thinks there's no cable plugged in.

I don't know.  When the link detection code was written it was tested
and it worked here.  Except when the link really is not connected I
have not seen code like that fail forever.
 
> On Fri, Aug 15, 2003 at 10:31:44PM -0700, YhLu wrote:
> > Eric,
> > 
> > Is ethboot 5.2.0 support Broadcom 5703X?  (deviceid = 0x16a7).
> > 
> > For the S2885's onboard 5703X, it says: EBUSY err.

Looking at the code it is should work.  I just stripped down the
appropriate driver.  I do admit I have not tested 5.2 yet.  But
I don't see why anything would have broken.

> > Regards
> > 
> > Yinghai Lu
> > 
> > 01:09.00 [14E4/16A7]
> > [tg3-5703X]The PCI BIOS has not enabled this device!
> > Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
> > Capability: 7
> > Capability: 1
> > err=-1
> > Problem fetching invariants of chip, aborting.

Hmm.  I have once or twice seen the problem of fetching invariants of
the chip.  But something is noticeably different from the tree I have
because I do not have an line that will print err=-1 in the tree I am
looking at.

Eric



From ts1 at tsn.or.jp  Mon Aug 18 03:15:00 2003
From: ts1 at tsn.or.jp (SONE Takeshi)
Date: Mon Aug 18 03:15:00 2003
Subject: EPIA Linuxbios strangeness
In-Reply-To: <3F3FE1AD.60208@nexpath.com>
References: <20030811144204.GA24442@planetfall.com> <20030817192458.GC14755@tsn.or.jp> <3F3FE1AD.60208@nexpath.com>
Message-ID: <20030818072928.GA8040@tsn.or.jp>

On Sun, Aug 17, 2003 at 01:12:29PM -0700, Steve Gehlbach wrote:
> SONE Takeshi wrote:
> 
> >Setting bit 1 of ISA bridge register 4F does a system reset.
           ~~~~~
Typo, bit 0.

> >I have these lines instead of /sbin/reboot in /etc/init.d/reboot
> >(Debian system).
> >
> >    sleep 1
> >    setpci -s 0:11.0 4f.b=9
> >
> 
> From the datasheet:
> 
> Via VT8231 fn 0
> Offset 4F ?PCI Bus and CPU Interface Control ..........RW
> ----------------------------------------------------------
> 
> 7-4 Reserved ................always reads 0
> 3 CPU Reset Source
>   0 Use CPURST as CPU Reset..default
>   1 Use INIT# as CPU Reset
> 2 Config Command Reg Rx04 Access (Test Only)
>   0 Normal:Bits 0-1=RO,Bit 3=RW...default
>   1 Test Mode:Bits 0-1=RW,Bit-3=RO
> 1 IRDY #Wait States
>   0 0 Wait States.............default
>   1 1 WaitState
> 0 Software PCI Reset ...write 1 to generate PCI reset
> 
> What about the ACPI I/O space (set same as Award BIOS, I think, 0x4000), 
> in particular 0x4002, 0x4003? Anyway this can be used?

I use it only for power-off.
It does have a reset function, but it didn't always work for me.

--
Takeshi


From nathanael at gnat.ca  Mon Aug 18 11:24:00 2003
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Mon Aug 18 11:24:00 2003
Subject: Epia M status
Message-ID: <09EE7B54-D192-11D7-9E80-0003931B4D6A@gnat.ca>

Hello,
	I'm in the process of buying an epia board. I want to use LinuxBIOS. 
So I checked the status page and Epia-M is marked unstable. Just 
wondering what is unstable, where there are problems, whether it is 
being actively worked on ( I don't mind helping it along if the 
datasheets are available etc). What parts aren't working so good etc.. 
Just basically wondering if it would be better to go with the EPIA 
first as I only need a demo board and the EPIA-M later on? Or whether 
the EPIA-M would be sufficient for now and sort of works but only some 
parts of it don't etc...

Any help would be appreciated.

-- 
Nathanael Noblet
Gnat Solutions
4604 Monterey Ave NW
Calgary, AB
T3B 5K4

T/F 403.288.5360
C 403.809.5368

http://www.gnat.ca/



From ebiederman at lnxi.com  Mon Aug 18 14:14:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug 18 14:14:01 2003
Subject: [Etherboot-users] re: s2885
In-Reply-To: <000201c36518$68aeea20$dbcba140@yhlunb>
References: <000201c36518$68aeea20$dbcba140@yhlunb>
Message-ID: <m3y8xqerxs.fsf@maxwell.lnxi.com>

"Yinghai Lu" <yhlu at tyan.com> writes:

> I add one printf if tg3.c to produce "err=?".

Ok.  

So far the consensus is that we should not have seen any new problems
with version 5.2.x, as nothing has changed (except your printf :).

So either there is a LinuxBIOS bug where memory mapped I/O is not
being properly routed, or you have come across a bug in the driver.

It has had a moderate amount of testing, and I did my best to preserve
the initialization that the Linux driver was doing when I stripped it
down.  You do have a version of the tg3 I don't have on hand.  So I
don't currently have a clue where to start looking except to add more
printfs to track down which part of the initialization failed.

Eric



From YhLu at tyan.com  Mon Aug 18 14:23:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug 18 14:23:01 2003
Subject: [Etherboot-users] re: s2885
Message-ID: <3174569B9743D511922F00A0C94314230318811D@TYANWEB>

Eric,

Mmio should be the problem. S2885 has link 2 to 8131. I have set the lock to
mmio base reg to disable the change to base/limit reg.  Before that I found
that even I set the correct value in auto.c, after the hardwaremain.c is
executed the base reg would change back to link0.  The result is that it
will hang at the ROM access for Etherboot.

I will add more printf in tg3.c today.

Regards

Yinghai Lu

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2003?8?18? 11:34
???: YhLu
??: 'Etherboot-users'; linuxbios at clustermatic.org; 'Jeff Noxon'
??: Re: [Etherboot-users] re: s2885

"Yinghai Lu" <yhlu at tyan.com> writes:

> I add one printf if tg3.c to produce "err=?".

Ok.  

So far the consensus is that we should not have seen any new problems
with version 5.2.x, as nothing has changed (except your printf :).

So either there is a LinuxBIOS bug where memory mapped I/O is not
being properly routed, or you have come across a bug in the driver.

It has had a moderate amount of testing, and I did my best to preserve
the initialization that the Linux driver was doing when I stripped it
down.  You do have a version of the tg3 I don't have on hand.  So I
don't currently have a clue where to start looking except to add more
printfs to track down which part of the initialization failed.

Eric


From YhLu at tyan.com  Mon Aug 18 21:20:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug 18 21:20:01 2003
Subject: [Etherboot-users] re: s2885
Message-ID: <3174569B9743D511922F00A0C9431423031881AC@TYANWEB>

Eric,

There is one hardcode in src/northbridge/amd/amdk8/northbridge.c to change
the value of 0xBC to 0x00ffff00, so the link2 to cpu0 is changed back to
link0 again.

I changed the hard code to "|" instead of direct assignment.

But it hung after get the Ethernet mac address.

Any idea?

Regards

YH.


Etherboot 5.2.0 (GPL) http://etherboot.org Tagged ELF for [TG3]
Relocating _text from: [00025a60,00065df0) to [efebfc70,eff00000)
Probing pci nic...
00:01.00 [1022/7450]
00:01.01 [1022/7451]
00:02.00 [1022/7450]
00:02.01 [1022/7451]
00:03.00 [1022/7460]
00:04.00 [1022/7468]
00:04.01 [1022/7469]
00:04.02 [1022/746A]
00:04.03 [1022/746B]
00:04.05 [1022/746D]
00:18.00 [1022/1100]
00:18.01 [1022/1101]
00:18.02 [1022/1102]
00:18.03 [1022/1103]
00:19.00 [1022/1100]
00:19.01 [1022/1101]
00:19.02 [1022/1102]
00:19.03 [1022/1103]
01:09.00 [14E4/16A7]
[tg3-5703X]The PCI BIOS has not enabled this device!
Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
Capability: 7
Capability: 1
err=0
Ethernet addr: 00:E0:81:F0:19:63
Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit)




From YhLu at tyan.com  Mon Aug 18 22:41:01 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug 18 22:41:01 2003
Subject: [Etherboot-users] re: s2885
Message-ID: <3174569B9743D511922F00A0C9431423031881B5@TYANWEB>

Eric,

It hangs at 
Tg3_init_hw/tg3_disable_ints/tw32_mailbox2(MAILBOX_INTERUPT_0 +
TG3_64BIT_REG_LOW,0x00000001).

Regards

YH



Etherboot 5.2.0 (GPL) http://etherboot.org Tagged ELF for [TG3]
Relocating _text from: [00025ae0,00065e70) to [efebfc70,eff00000)
Probing pci nic...
00:01.00 [1022/7450]
00:01.01 [1022/7451]
00:02.00 [1022/7450]
00:02.01 [1022/7451]
00:03.00 [1022/7460]
00:04.00 [1022/7468]
00:04.01 [1022/7469]
00:04.02 [1022/746A]
00:04.03 [1022/746B]
00:04.05 [1022/746D]
00:18.00 [1022/1100]
00:18.01 [1022/1101]
00:18.02 [1022/1102]
00:18.03 [1022/1103]
00:19.00 [1022/1100]
00:19.01 [1022/1101]
00:19.02 [1022/1102]
00:19.03 [1022/1103]
01:09.00 [14E4/16A7]
[tg3-5703X]The PCI BIOS has not enabled this device!
Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
Capability: 7
Capability: 1
Ethernet addr: 00:E0:81:F0:19:63
Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit)
tg3_init_hw 1
tg3_disable_ints 1

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tg3.c
Type: application/octet-stream
Size: 77547 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20030818/be68dea3/attachment.obj>

From YhLu at tyan.com  Mon Aug 18 22:45:00 2003
From: YhLu at tyan.com (YhLu)
Date: Mon Aug 18 22:45:00 2003
Subject: [Etherboot-users] re: s2885
Message-ID: <3174569B9743D511922F00A0C9431423031881B6@TYANWEB>

Eric,

It hangs at 
Tg3_init_hw/tg3_disable_ints/tw32_mailbox2(MAILBOX_INTERUPT_0 +
TG3_64BIT_REG_LOW,0x00000001).

Regards

YH



Etherboot 5.2.0 (GPL) http://etherboot.org Tagged ELF for [TG3]
Relocating _text from: [00025ae0,00065e70) to [efebfc70,eff00000)
Probing pci nic...
00:01.00 [1022/7450]
00:01.01 [1022/7451]
00:02.00 [1022/7450]
00:02.01 [1022/7451]
00:03.00 [1022/7460]
00:04.00 [1022/7468]
00:04.01 [1022/7469]
00:04.02 [1022/746A]
00:04.03 [1022/746B]
00:04.05 [1022/746D]
00:18.00 [1022/1100]
00:18.01 [1022/1101]
00:18.02 [1022/1102]
00:18.03 [1022/1103]
00:19.00 [1022/1100]
00:19.01 [1022/1101]
00:19.02 [1022/1102]
00:19.03 [1022/1103]
01:09.00 [14E4/16A7]
[tg3-5703X]The PCI BIOS has not enabled this device!
Updating PCI command 0002->0007. pci_bus 01 pci_device_fn 48
Capability: 7
Capability: 1
Ethernet addr: 00:E0:81:F0:19:63
Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit)
tg3_init_hw 1
tg3_disable_ints 1


From ts1 at cma.co.jp  Tue Aug 19 03:36:01 2003
From: ts1 at cma.co.jp (SONE Takeshi)
Date: Tue Aug 19 03:36:01 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030812142746.GB3767@suse.de>
References: <Pine.LNX.4.44.0308120737510.3381-100000@maxroach.lanl.gov> <Pine.LNX.4.44.0308120804310.3381-100000@maxroach.lanl.gov> <20030812142746.GB3767@suse.de>
Message-ID: <20030819075030.GA6384@cma.co.jp>

On Tue, Aug 12, 2003 at 04:27:46PM +0200, Stefan Reinauer wrote:
> > The BIOS support code is tiny -- I'm not surprised at 20k.
> But that 20k is all you ever need on x86 machines.

I looked at the x86emu but int.c only contains PCI services
and some other little functions. This is pretty much like what
we have now in LinuxBIOS for VGA BIOS support.

What I found really interesting in that source tree is
the 'happy_cards' file, which tells what various VGA BIOS's 
do, and what the author had to do to make them happy.

--
Takeshi


From ts1 at cma.co.jp  Tue Aug 19 03:44:00 2003
From: ts1 at cma.co.jp (SONE Takeshi)
Date: Tue Aug 19 03:44:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <m3fzk0uofa.fsf@maxwell.lnxi.com>
References: <20030812103627.GA1759@suse.de> <Pine.LNX.4.44.0308120729470.3381-100000@maxroach.lanl.gov> <20030812143609.GC3767@suse.de> <m3fzk0uofa.fsf@maxwell.lnxi.com>
Message-ID: <20030819075433.GB6384@cma.co.jp>

On Sun, Aug 17, 2003 at 12:30:49PM -0600, Eric W. Biederman wrote:
> Looking at the various specifications there is an additional route
> we can take.  We can have the 16bit trampoline detect if it is running
> in v86 mode, and if so use the appropriate DPMI/VCPI/XMS functions to
> switch to protected mode instead of our hand crafted code.
> 
> That should allow us to run under Win9x, freedos, and djgpp.  For
> Freebsd we will probably need a couple of the very most common calls
> implemented in the 16bit trampoline as well.  And of course we can
> still implement the legacy entry points.

Very interesting.

> - It is not clear what an Option ROM will care about so being as
>   backward compatible as possible is a real plus.
> 
> - Going with a solution that can (at least in theory) handle
>   all of the legacy backwards compatibility cases will allow us
>   to concentrate on a single implementation.
> 
> - Going with a solution that is primarily 32bit C code will allow us
>   to reuse the code in appropriate ways.
> 
> - Not using v86 mode by default will allow a high degree of
>   compatibility anyway.
> 
> Does a version of ADLO that runs as 32bit C code sound reasonable?

What do you think about non-x86?

--
Takeshi


From steve at nexpath.com  Wed Aug 20 00:54:00 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Wed Aug 20 00:54:00 2003
Subject: epia-800 kernel panic
In-Reply-To: <20030819075433.GB6384@cma.co.jp>
References: <20030812103627.GA1759@suse.de> <Pine.LNX.4.44.0308120729470.3381-100000@maxroach.lanl.gov> <20030812143609.GC3767@suse.de> <m3fzk0uofa.fsf@maxwell.lnxi.com> <20030819075433.GB6384@cma.co.jp>
Message-ID: <3F43029E.3000609@nexpath.com>

I have gotten back to doing some work on the vga of the epia-800, and 
can't seem to get linux to fully boot. It panics as below.  If anyone 
has any ideas on what this might be, I would appreciate the help. The 
kernel is 2.4.21.  I am using the std epia config with a few mods to 
boot from IDE.

-Steve

...
CPU: Centaur VIA Ezra stepping 08
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
general protection fault: 0000
CPU:    0
EIP:    0010:[<c0144ebe>]    Not tainted
EFLAGS: 00010286
eax: c3eb0000   ebx: 00000f00   ecx: c3eb0000   edx: ffffffff
esi: c3eb0000   edi: ffffffff   ebp: c10e9f64   esp: c10e9ef8
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c10e9000)
Stack: 00000f00 c3eb0000 c3eb05a0 c10e9f64 ffffffff 00000000 00000000 
00000000
        c01130dc 00000f00 c3eb0000 c10e8000 c10e9fa0 00000000 c10e9f64 
c3eb0000
        00000000 fffffff4 c0116654 00000000 c02c1ba0 00000001 c010740e 
00000f00
Call Trace:    [<c01130dc>] [<c0116654>] [<c010740e>] [<c01087b3>] 
[<c017adef>]
   [<c010706b>] [<c0112c08>] [<c017adef>] [<c017adef>] [<c0105073>] 
[<c0107074>]

Code: ff 07 8b 44 24 24 a9 00 00 02 00 0f 84 9b 02 00 00 bb 00 e0
  <0>Kernel panic: Attempted to kill init!



From jeff at planetfall.com  Wed Aug 20 11:13:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Wed Aug 20 11:13:00 2003
Subject: epia-800 kernel panic
In-Reply-To: <3F43029E.3000609@nexpath.com>
References: <20030812103627.GA1759@suse.de> <Pine.LNX.4.44.0308120729470.3381-100000@maxroach.lanl.gov> <20030812143609.GC3767@suse.de> <m3fzk0uofa.fsf@maxwell.lnxi.com> <20030819075433.GB6384@cma.co.jp> <3F43029E.3000609@nexpath.com>
Message-ID: <20030820152834.GA1124@planetfall.com>

Run that log through ksymoops.  As it is it's meaningless.

Regards,

Jeff

On Tue, Aug 19, 2003 at 10:09:50PM -0700, Steve Gehlbach wrote:
> I have gotten back to doing some work on the vga of the epia-800, and 
> can't seem to get linux to fully boot. It panics as below.  If anyone 
> has any ideas on what this might be, I would appreciate the help. The 
> kernel is 2.4.21.  I am using the std epia config with a few mods to 
> boot from IDE.
> 
> -Steve
> 
> ...
> CPU: Centaur VIA Ezra stepping 08
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Starting kswapd
> general protection fault: 0000
> CPU:    0
> EIP:    0010:[<c0144ebe>]    Not tainted
> EFLAGS: 00010286
> eax: c3eb0000   ebx: 00000f00   ecx: c3eb0000   edx: ffffffff
> esi: c3eb0000   edi: ffffffff   ebp: c10e9f64   esp: c10e9ef8
> ds: 0018   es: 0018   ss: 0018
> Process swapper (pid: 1, stackpage=c10e9000)
> Stack: 00000f00 c3eb0000 c3eb05a0 c10e9f64 ffffffff 00000000 00000000 
> 00000000
>        c01130dc 00000f00 c3eb0000 c10e8000 c10e9fa0 00000000 c10e9f64 
> c3eb0000
>        00000000 fffffff4 c0116654 00000000 c02c1ba0 00000001 c010740e 
> 00000f00
> Call Trace:    [<c01130dc>] [<c0116654>] [<c010740e>] [<c01087b3>] 
> [<c017adef>]
>   [<c010706b>] [<c0112c08>] [<c017adef>] [<c017adef>] [<c0105073>] 
> [<c0107074>]
> 
> Code: ff 07 8b 44 24 24 a9 00 00 02 00 0f 84 9b 02 00 00 bb 00 e0
>  <0>Kernel panic: Attempted to kill init!


From steve at nexpath.com  Wed Aug 20 13:06:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Wed Aug 20 13:06:01 2003
Subject: epia-800 kernel panic
In-Reply-To: <20030820152834.GA1124@planetfall.com>
References: <20030812103627.GA1759@suse.de> <Pine.LNX.4.44.0308120729470.3381-100000@maxroach.lanl.gov> <20030812143609.GC3767@suse.de> <m3fzk0uofa.fsf@maxwell.lnxi.com> <20030819075433.GB6384@cma.co.jp> <3F43029E.3000609@nexpath.com> <20030820152834.GA1124@planetfall.com>
Message-ID: <3F43B004.1060904@nexpath.com>

Jeff Noxon wrote:
> Run that log through ksymoops.  As it is it's meaningless.
> 

Good point:

CPU:    0
EIP:    0010:[<c0146f37>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: c3eb2000   ebx: c3eb2000   ecx: 00000f00   edx: ffffffff
esi: 00000f00   edi: ffffffff   ebp: c10ebf64   esp: c10ebefc
ds: 0018   es: 0018   ss: 0018
Process swapper (pid: 1, stackpage=c10eb000)
Stack: c3eb2000 00000f00 c3eb25a0 c10ebf64 ffffffff 00000000 00000000 
00000000
        c0113401 00000f00 c3eb2000 c10ea000 c10ebfa0 00000000 c10ebf64 
00000000
        fffffff4 c01169a6 00000000 c02f8ba0 00000001 c01075a5 00000f00 
00000078
Call Trace:    [<c0113401>] [<c01169a6>] [<c01075a5>] [<c01089d3>] 
[<c017e748>]
   [<c01071eb>] [<c0112f54>] [<c017e748>] [<c017e748>] [<c010507e>] 
[<c01071f4>]
Code: ff 07 8b 44 24 24 a9 00 00 02 00 0f 84 a6 02 00 00 bb 00 e0


 >>EIP; c0146f37 <copy_namespace+3b/360>   <=====

 >>eax; c3eb2000 <END_OF_CODE+3b8e090/????>
 >>ebx; c3eb2000 <END_OF_CODE+3b8e090/????>
 >>ecx; 00000f00 Before first symbol
 >>edx; ffffffff <END_OF_CODE+3fcdc08f/????>
 >>esi; 00000f00 Before first symbol
 >>edi; ffffffff <END_OF_CODE+3fcdc08f/????>
 >>ebp; c10ebf64 <END_OF_CODE+dc7ff4/????>
 >>esp; c10ebefc <END_OF_CODE+dc7f8c/????>

Trace; c0113401 <do_fork+491/7c8>
Trace; c01169a6 <tasklet_hi_action+4a/70>
Trace; c01075a5 <sys_clone+1d/24>
Trace; c01089d3 <system_call+33/40>
Trace; c017e748 <jfsIOWait+0/194>
Trace; c01071eb <arch_kernel_thread+1f/38>
Trace; c0112f54 <kernel_thread+6c/88>
Trace; c017e748 <jfsIOWait+0/194>
Trace; c017e748 <jfsIOWait+0/194>
Trace; c010507e <init+1a/14c>
Trace; c01071f4 <arch_kernel_thread+28/38>

Code;  c0146f37 <copy_namespace+3b/360>
00000000 <_EIP>:
Code;  c0146f37 <copy_namespace+3b/360>   <=====
    0:   ff 07                     incl   (%edi)   <=====
Code;  c0146f39 <copy_namespace+3d/360>
    2:   8b 44 24 24               mov    0x24(%esp,1),%eax
Code;  c0146f3d <copy_namespace+41/360>
    6:   a9 00 00 02 00            test   $0x20000,%eax
Code;  c0146f42 <copy_namespace+46/360>
    b:   0f 84 a6 02 00 00         je     2b7 <_EIP+0x2b7> c01471ee 
<copy_namespace+2f2/360>
Code;  c0146f48 <copy_namespace+4c/360>
   11:   bb 00 e0 00 00            mov    $0xe000,%ebx

  <0>Kernel panic: Attempted to kill init!

----------

Memory seems to be correct:

Jumping to boot code
Linux version 2.4.21 (root at nexpath70.kesa.com) (gcc version 2.95.4 
20011002 (Debian prerelease)) #24 Wed Aug 20 09:57:32 PDT 2003
BIOS-provided physical RAM map:
  BIOS-e801: 0000000000000000 - 000000000009f000 (usable)
  BIOS-e801: 0000000000100000 - 0000000003f00000 (usable)
63MB LOWMEM available.
On node 0 totalpages: 16128
zone(0): 4096 pages.
zone(1): 12032 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda1 ro console=ttyS0,115200n8
Initializing CPU#0
Detected 800.048 MHz processor.
Calibrating delay loop... 1595.80 BogoMIPS
Memory: 61152k/64512k available (1360k kernel code, 2972k reserved, 383k 
data, 264k init, 0k highmem)
.....

Steve



From steve at nexpath.com  Wed Aug 20 14:13:00 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Wed Aug 20 14:13:00 2003
Subject: epia-800 kernel panic
In-Reply-To: <3F43B004.1060904@nexpath.com>
References: <20030812103627.GA1759@suse.de> <Pine.LNX.4.44.0308120729470.3381-100000@maxroach.lanl.gov> <20030812143609.GC3767@suse.de> <m3fzk0uofa.fsf@maxwell.lnxi.com> <20030819075433.GB6384@cma.co.jp> <3F43029E.3000609@nexpath.com> <20030820152834.GA1124@planetfall.com> <3F43B004.1060904@nexpath.com>
Message-ID: <3F43BFF1.6030304@nexpath.com>

Steve Gehlbach wrote:

> Jeff Noxon wrote:
> 
>> Run that log through ksymoops.  As it is it's meaningless.
>>
> 

Never mind, I found the problem.  RAM was not getting init'ed correctly 
for the SDRAM I was using.  I was not completely sync'ed to the 
repository, and did not have the latest northbridge files.  Main reason 
was that ide.c, ide.h were broken for secondary ide, but I backed up one 
rev on each got that to work.

-Steve



From linladn at yahoo.co.in  Thu Aug 21 11:32:01 2003
From: linladn at yahoo.co.in (=?iso-8859-1?q?mount=20me?=)
Date: Thu Aug 21 11:32:01 2003
Subject: LINUXBIOS can boot any variety OS 
Message-ID: <20030821154715.48240.qmail@web8202.mail.in.yahoo.com>

Hi linuxbiosians,
Heard and Read that Windows 2000 can be booted using 
Linuxbios. Keeeeeeen and Interested in entering 
linuxbios. Could i get the list of OS's 
booted using LINUXBIOS and a brief explanation
document along with it ? or links plz....

I am stilll looking for a motherboard in Chennai,INDIA
Has anyone tried linuxbios in CHENNAI,INDIA ?
need your support to start linuxbios with.

Regards,
karthik bala guru



________________________________________________________________________
Yahoo! India Promos: Win TVs, Bikes, DVD players & more!
Go to http://in.promos.yahoo.com


From agnew at cs.umd.edu  Thu Aug 21 12:24:01 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Thu Aug 21 12:24:01 2003
Subject: LINUXBIOS can boot any variety OS 
In-Reply-To: <20030821154715.48240.qmail@web8202.mail.in.yahoo.com>
Message-ID: <20030821123454.S72144-100000@www.missl.cs.umd.edu>

You should start at Richard Smith's FAQ. It can be found in the LinuxBIOS
mailing list archive for now.

LinuxBIOS proper, I believe, has been used to boot Linux kernels, Plan9,
and WinCE.

Using LinuxBIOS to boot Windows 2000, OpenBSD, FreeBSD, unmodified Linux,
and lots of others which went untested has been described in a couple
places

You can read about it in this paper here
http://www.usenix.org/events/usenix03/tech/freenix03/agnew.html

You can try the guilty part by pulling down the freebios cvs, and looking
at freebios/util/ADLO

- Adam Agnew


On Thu, 21 Aug 2003, [iso-8859-1] mount me wrote:

> Hi linuxbiosians,
> Heard and Read that Windows 2000 can be booted using
> Linuxbios. Keeeeeeen and Interested in entering
> linuxbios. Could i get the list of OS's
> booted using LINUXBIOS and a brief explanation
> document along with it ? or links plz....
>
> I am stilll looking for a motherboard in Chennai,INDIA
> Has anyone tried linuxbios in CHENNAI,INDIA ?
> need your support to start linuxbios with.
>
> Regards,
> karthik bala guru
>
>
>
> ________________________________________________________________________
> Yahoo! India Promos: Win TVs, Bikes, DVD players & more!
> Go to http://in.promos.yahoo.com
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From linuxbios at denkmair.de  Fri Aug 22 07:04:00 2003
From: linuxbios at denkmair.de (Hubert Denkmair)
Date: Fri Aug 22 07:04:00 2003
Subject: linuxbios on arbor emcore i612?
Message-ID: <3F45FC4C.4080405@denkmair.de>

Hello list,

i am planning to build my own car mp3 player in the near future.
Therefore I'm going to buy a 3.5" Single Board Computer, and
OF COURSE linux will be my operating system of choice :-)

Since a fast boot process will be important for me, it seems very
useful to buy a board supporting linuxbios.

Currently I have a rather cheap SBC on my mind, the
"EmCORE-i612VL", manufactured by arbor.

Datasheet:
ftp://ftp.arbor.com.tw/pub/datasheets/miniboards/emcore-i612.pdf

Is this board supported by linuxbios?
I looked at the status page and did not find information about this
board or even the used i815 chipset. Are the boards mentioned on
the status page really the only ones with linuxbios support?

If so, can you recommand me a cheap SBC with similar features
(+5V power supply only, Celeron400 or equivalent CPU, CF Socket)?

Thank you in advance, seems to me you're doing great work!

Hubert





From linuxbios at denkmair.de  Fri Aug 22 07:08:01 2003
From: linuxbios at denkmair.de (Hubert Denkmair)
Date: Fri Aug 22 07:08:01 2003
Subject: linuxbios on arbor emcore i612?
Message-ID: <3F45FD36.7070208@denkmair.de>

Hello list,

i am planning to build my own car mp3 player in the near future.
Therefore I'm going to buy a 3.5" Single Board Computer, and
OF COURSE linux will be my operating system of choice :-)

Since a fast boot process will be important for me, it seems very
useful to buy a board supporting linuxbios.

Currently I have a rather cheap SBC on my mind, the
"EmCORE-i612VL", manufactured by arbor.

Datasheet:
ftp://ftp.arbor.com.tw/pub/datasheets/miniboards/emcore-i612.pdf

Is this board supported by linuxbios?
I looked at the status page and did not find information about this
board or even the used i815 chipset. Are the boards mentioned on
the status page really the only ones with linuxbios support?

If so, can you recommand me a cheap SBC with similar features
(+5V power supply only, Celeron400 or equivalent CPU, CF Socket)?

Thank you in advance, seems to me you're doing great work!

Hubert





From nathanael at gnat.ca  Fri Aug 22 15:34:01 2003
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Fri Aug 22 15:34:01 2003
Subject: compatible flash chips
Message-ID: <C9B9D51D-D4D9-11D7-AC88-0003931B4D6A@gnat.ca>

Hello,
	I just received my EPIA 800 and am itching to get it up and running 
with freebios. I have flash parts for a board I was previously working 
on. I'd like to know if they are compatible, they are the same form 
factor (as in PLCC chips). The one in the board is a SST 39sf020a, and 
I have Winbond w29c020cp90b. How do I know if they are compatible? I'd 
rather not flash this and it not work, and then not be able to do 
anything with it...

-- 
Nathanael Noblet
Gnat Solutions
4604 Monterey Ave NW
Calgary, AB
T3B 5K4

T/F 403.288.5360
C 403.809.5368

http://www.gnat.ca/



From jeff at planetfall.com  Fri Aug 22 17:07:00 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Fri Aug 22 17:07:00 2003
Subject: compatible flash chips
In-Reply-To: <C9B9D51D-D4D9-11D7-AC88-0003931B4D6A@gnat.ca>
References: <C9B9D51D-D4D9-11D7-AC88-0003931B4D6A@gnat.ca>
Message-ID: <20030822212302.GA26108@planetfall.com>

The best thing to do is compare data sheets.  Also, look at the
linuxbios flash-and-burn program and see what chips it supports.  If
your chip isn't supported, you may need to add the support yourself.

Flash chips tend to vary in operating voltage, programming voltage,
block size, block organization, and bus interface.  There are also
variations to the commands they support.

You *must* make sure they have the same bus interface, i.e., you can't
swap LPC or FWH chips with traditional chips.  The EPIA board uses a
traditional flash chip.  Make sure then pinouts are the same, and the
voltage requirements for the two chips are the same.  Then you can be
sure you're not going to fry anything.

If the block organizations are different, that doesn't matter so much.
As long as you can erase the whole chip and program it, it should work
to boot the system.

Flash chips also come in all kinds of different speed grades.  I may be
wrong, but I doubt the speeds matter much.  The BIOS gets copied into
RAM almost immediately and then runs from there.

Also, note that programming flash chips from usermode can be tricky.
Some chips are very sensitive to timing and may not program correctly.
I recently had problems programming a winbond chip until I removed all
the print statements from flash-and-burn!  The moral of the story is
to always verify that the flash was done error-free.

It might be worth the $20 to buy a Bios Savior, and you'll get the
same SST chip with that...

Regards,

Jeff

On Fri, Aug 22, 2003 at 01:49:48PM -0600, Nathanael Noblet wrote:
> Hello,
> 	I just received my EPIA 800 and am itching to get it up and running 
> with freebios. I have flash parts for a board I was previously working 
> on. I'd like to know if they are compatible, they are the same form 
> factor (as in PLCC chips). The one in the board is a SST 39sf020a, and 
> I have Winbond w29c020cp90b. How do I know if they are compatible? I'd 
> rather not flash this and it not work, and then not be able to do 
> anything with it...


From agnew at cs.umd.edu  Fri Aug 22 20:59:00 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Fri Aug 22 20:59:00 2003
Subject: bootselect problems
In-Reply-To: <20030822212302.GA26108@planetfall.com>
Message-ID: <20030822210949.I82702-100000@www.missl.cs.umd.edu>

Hi, has anyone tried out Steven James' baremetal toolkit / bootselect and
run into this problem?

I put a 16 byte 'tag' before each payload. My tags have the standard
'$TAG$' beginning, then 0x00 to show that there will be no more additional
16 byte tag blocks on that payload, then four 0x00s because the payload
size is optional, and then 6 characters for the name. Maybe the payload
size isn't option after all?

I got bootselect out of a three month old cvs because it doesn't currently
compile.

Welcome to the LinuxLabs boot chooser!
Found LinuxBIOS table at: 500
   210:init_bytes() - zkernel_start:0xfff00000  zkernel_mask:0x0000ffff
    71:rom_read_bytes() - overflowed source buffer. max_block = 15
Loading tag 0 @ 00000000
Tag contents: 24 54 41 47 24 00 00 00 00 00 6d 65 6d 38 36 20
TAG block count = 0
init_bytes found 2 tags
    71:rom_read_bytes() - overflowed source buffer. max_block = 15
Loading tag 0 @ 00000000
Tag contents: 24 54 41 47 24 00 00 00 00 00 6d 65 6d 38 36 20
TAG block count = 0
Stream count = 2 blocks
STREAM: 0. mem86
STREAM: 1. e1000
Choose a stream: Loading tag 1 @ 00010ee0
Tag contents: 24 54 41 47 24 00 00 00 00 00 65 31 30 30 30 20
TAG block count = 0

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

Cannot Load ELF Image




From agnew at cs.umd.edu  Sat Aug 23 03:16:02 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Sat Aug 23 03:16:02 2003
Subject: bootselect problems
In-Reply-To: <20030822210949.I82702-100000@www.missl.cs.umd.edu>
Message-ID: <20030823033331.O82702-100000@www.missl.cs.umd.edu>

Stupid user error! I managed to sneak an extra byte into my tags :) Sorry
for the false bug report.

- Adam Agnew

On Fri, 22 Aug 2003, Adam Agnew wrote:

>
> Hi, has anyone tried out Steven James' baremetal toolkit / bootselect and
> run into this problem?
>
> I put a 16 byte 'tag' before each payload. My tags have the standard
> '$TAG$' beginning, then 0x00 to show that there will be no more additional
> 16 byte tag blocks on that payload, then four 0x00s because the payload
> size is optional, and then 6 characters for the name. Maybe the payload
> size isn't option after all?
>
> I got bootselect out of a three month old cvs because it doesn't currently
> compile.
>
> Welcome to the LinuxLabs boot chooser!
> Found LinuxBIOS table at: 500
>    210:init_bytes() - zkernel_start:0xfff00000  zkernel_mask:0x0000ffff
>     71:rom_read_bytes() - overflowed source buffer. max_block = 15
> Loading tag 0 @ 00000000
> Tag contents: 24 54 41 47 24 00 00 00 00 00 6d 65 6d 38 36 20
> TAG block count = 0
> init_bytes found 2 tags
>     71:rom_read_bytes() - overflowed source buffer. max_block = 15
> Loading tag 0 @ 00000000
> Tag contents: 24 54 41 47 24 00 00 00 00 00 6d 65 6d 38 36 20
> TAG block count = 0
> Stream count = 2 blocks
> STREAM: 0. mem86
> STREAM: 1. e1000
> Choose a stream: Loading tag 1 @ 00010ee0
> Tag contents: 24 54 41 47 24 00 00 00 00 00 65 31 30 30 30 20
> TAG block count = 0
>
> Welcome to elfboot, the open sourced starter.
> January 2002, Eric Biederman.
> Version 1.2
>
> Cannot Load ELF Image
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From pyro at linuxlabs.com  Sat Aug 23 11:16:01 2003
From: pyro at linuxlabs.com (steven james)
Date: Sat Aug 23 11:16:01 2003
Subject: bootselect problems
In-Reply-To: <20030823033331.O82702-100000@www.missl.cs.umd.edu>
Message-ID: <Pine.LNX.4.21.0308231129180.8983-100000@ucontrol.mobiledns.com>

Greetings,

I need to add a tag generator in there!
The newer baremetal is breaking with ide.c from the freebios/src tree. I'm
looking at that, but in the meantime, you can change
util/baremetal/lib/Makefile to skip ide.c and it will compile (minus ide
support of course).

When I get a moment, I'll either fix it or remove IDE in CVS for now.

G'day,
sjames


On Sat, 23 Aug 2003, Adam Agnew wrote:

> 
> Stupid user error! I managed to sneak an extra byte into my tags :) Sorry
> for the false bug report.
> 
> - Adam Agnew
> 
> On Fri, 22 Aug 2003, Adam Agnew wrote:
> 
> >
> > Hi, has anyone tried out Steven James' baremetal toolkit / bootselect and
> > run into this problem?
> >
> > I put a 16 byte 'tag' before each payload. My tags have the standard
> > '$TAG$' beginning, then 0x00 to show that there will be no more additional
> > 16 byte tag blocks on that payload, then four 0x00s because the payload
> > size is optional, and then 6 characters for the name. Maybe the payload
> > size isn't option after all?
> >
> > I got bootselect out of a three month old cvs because it doesn't currently
> > compile.
> >
> > Welcome to the LinuxLabs boot chooser!
> > Found LinuxBIOS table at: 500
> >    210:init_bytes() - zkernel_start:0xfff00000  zkernel_mask:0x0000ffff
> >     71:rom_read_bytes() - overflowed source buffer. max_block = 15
> > Loading tag 0 @ 00000000
> > Tag contents: 24 54 41 47 24 00 00 00 00 00 6d 65 6d 38 36 20
> > TAG block count = 0
> > init_bytes found 2 tags
> >     71:rom_read_bytes() - overflowed source buffer. max_block = 15
> > Loading tag 0 @ 00000000
> > Tag contents: 24 54 41 47 24 00 00 00 00 00 6d 65 6d 38 36 20
> > TAG block count = 0
> > Stream count = 2 blocks
> > STREAM: 0. mem86
> > STREAM: 1. e1000
> > Choose a stream: Loading tag 1 @ 00010ee0
> > Tag contents: 24 54 41 47 24 00 00 00 00 00 65 31 30 30 30 20
> > TAG block count = 0
> >
> > Welcome to elfboot, the open sourced starter.
> > January 2002, Eric Biederman.
> > Version 1.2
> >
> > Cannot Load ELF Image
> >
> >
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
-------------------------steven james, director of research, linux labs
... ........ ..... ....                    230 peachtree st nw ste 2701
the original linux labs                             atlanta.ga.us 30303
      -since 1995                              http://www.linuxlabs.com
                                   office 404.577.7747 fax 404.577.7743
-----------------------------------------------------------------------




From linuxbios at denkmair.de  Sat Aug 23 13:40:01 2003
From: linuxbios at denkmair.de (Hubert Denkmair)
Date: Sat Aug 23 13:40:01 2003
Subject: Linuxbios: Booting linux from flash IDE drive on epia boards?
Message-ID: <3F47AAAE.1070507@denkmair.de>

Hello, (second try)

I'm planning to build my own car mp3 player on a PC basis and now found 
out that the VIA epia boards seem to be supported by linuxbios.
I'd love to boot my mp3 player via linuxbios to get the music playing
asap... unfortunatly the linuxbios-docs are not very userfriendly - I
understand that it's possible to boot the epia boards via etherboot, but
can i also load a kernel from IDE devices, e.g. a compact flash card
mounted into a IDE compact flash drive?
If not - is there any other way to load a linux-kernel really FAST in a
EPIA standalone (car-) system?

Would you recommand a special board, such as the EPIA-V8000, or are they
all working well?

Thanks a lot for your help,


Hubert
---
hubert at denkmair.de





From jeff at planetfall.com  Sat Aug 23 14:53:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Sat Aug 23 14:53:01 2003
Subject: Linuxbios: Booting linux from flash IDE drive on epia boards?
In-Reply-To: <3F47AAAE.1070507@denkmair.de>
References: <3F47AAAE.1070507@denkmair.de>
Message-ID: <20030823190933.GA15346@planetfall.com>

The only EPIA boards working close to 100% right now are the original
series, which is fine for your car MP3 project.  I'd suggest the fanless
533 MHz model.

Please read the mailing list archives.  It should be possible to use
some adapters to support a DiskOnChip with the EPIA board.  Etherboot can
also boot from IDE devices, including CF adapters.  Etherboot 5.2.0 can
do that without any patches (or so it would seem.)

I've found it helpful to download the entire mailing list archive (a
huge file) and use grepmail to search for answers.

Regards,

Jeff

On Sat, Aug 23, 2003 at 07:55:58PM +0200, Hubert Denkmair wrote:
> Hello, (second try)
> 
> I'm planning to build my own car mp3 player on a PC basis and now found 
> out that the VIA epia boards seem to be supported by linuxbios.
> I'd love to boot my mp3 player via linuxbios to get the music playing
> asap... unfortunatly the linuxbios-docs are not very userfriendly - I
> understand that it's possible to boot the epia boards via etherboot, but
> can i also load a kernel from IDE devices, e.g. a compact flash card
> mounted into a IDE compact flash drive?
> If not - is there any other way to load a linux-kernel really FAST in a
> EPIA standalone (car-) system?
> 
> Would you recommand a special board, such as the EPIA-V8000, or are they
> all working well?
> 
> Thanks a lot for your help,


From rminnich at lanl.gov  Sun Aug 24 01:21:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sun Aug 24 01:21:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <m3fzk0uofa.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308232336000.1485-100000@maxroach.lanl.gov>

On 17 Aug 2003, Eric W. Biederman wrote:

> Does a version of ADLO that runs as 32bit C code sound reasonable?

it sounds interesting, I'll look at this too. 

I'm back sporadically now until tuesday, back then for real.

2000 messages to dig through.

ron



From agnew at cs.umd.edu  Sun Aug 24 02:42:01 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Sun Aug 24 02:42:01 2003
Subject: rage xl framebuffer
In-Reply-To: <Pine.LNX.4.44.0308232336000.1485-100000@maxroach.lanl.gov>
Message-ID: <20030824024931.V87300-100000@www.missl.cs.umd.edu>

In newer 2.5/2.6 kernelS, there's a framebuffer option for initializing a
Rage XL without BIOS support. These ATI Rage XLs show up integrated into a
great variety of server boards, so I thought this tidbit would be of
interest to many of you. Has anyone had luck with this code though?
I, so far, have not. Blank screen, very diagnosable..

- Adam Agnew




From spyro at f2s.com  Sun Aug 24 19:24:00 2003
From: spyro at f2s.com (Ian Molton)
Date: Sun Aug 24 19:24:00 2003
Subject: Linuxbios: Booting linux from flash IDE drive on epia boards?
In-Reply-To: <3F47AAAE.1070507@denkmair.de>
References: <3F47AAAE.1070507@denkmair.de>
Message-ID: <20030825003956.55021eac.spyro@f2s.com>

On Sat, 23 Aug 2003 19:55:58 +0200
Hubert Denkmair <linuxbios at denkmair.de> wrote:

> 
> I'm planning to build my own car mp3 player on a PC basis and now
> found out that the VIA epia boards seem to be supported by linuxbios.

Why PC? theres some lovely *tiny* ARM based boards out there that are
far better suited to the task...

-- 
Spyros lair: http://www.mnementh.co.uk/   ||||   Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with
ketchup.


From jeff at planetfall.com  Sun Aug 24 20:12:01 2003
From: jeff at planetfall.com (Jeff Noxon)
Date: Sun Aug 24 20:12:01 2003
Subject: Linuxbios: Booting linux from flash IDE drive on epia boards?
In-Reply-To: <20030825003956.55021eac.spyro@f2s.com>
References: <3F47AAAE.1070507@denkmair.de> <20030825003956.55021eac.spyro@f2s.com>
Message-ID: <20030825002806.GA7177@planetfall.com>

Sure, and they're damn expensive.  EPIA is dirt cheap.  (And crap too,
but sometimes price wins anyway. ;)

Unless you know of a sub-$125 ARM-based board?  /dreaming

Regards,

Jeff

On Mon, Aug 25, 2003 at 12:39:56AM +0100, Ian Molton wrote:
> On Sat, 23 Aug 2003 19:55:58 +0200
> Hubert Denkmair <linuxbios at denkmair.de> wrote:
> 
> > 
> > I'm planning to build my own car mp3 player on a PC basis and now
> > found out that the VIA epia boards seem to be supported by linuxbios.
> 
> Why PC? theres some lovely *tiny* ARM based boards out there that are
> far better suited to the task...


From kimyj at etri.re.kr  Mon Aug 25 01:15:01 2003
From: kimyj at etri.re.kr (kimyj at etri.re.kr)
Date: Mon Aug 25 01:15:01 2003
Subject: =?euc-kr?B?W8i4vcVdIFdlbGNvbWUgdG8gdGhlICJMaW51eGJpb3MiIG1haWxp?=
	=?euc-kr?B?bmcgbGlzdCAoRGlnZXN0IG1vZGUp?=
Message-ID: <63CCC1EB21D5D511A2DF00D0B7A8DCBD02CD2210@cms4>

Hi, I'm Youngjae, Kim. 

I hope my email address would be posted to the Linuxbios at clustermatic.org
mailing list! 

Thanks in advance. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20030825/db6706bd/attachment.html>

From gael.mace at thomson.net  Mon Aug 25 06:12:01 2003
From: gael.mace at thomson.net (Mace Gael)
Date: Mon Aug 25 06:12:01 2003
Subject: Any freebios2 CVS snapshot ?
Message-ID: <05B4910E0216D411B14F00508B6A67A9033535FD@renexch5.rennes.thmulti.com>

Hello,

working on an AMD platform (dual Opteron), I concentrate one's efforts on
the HyperTransport link and related chipset (8111, 8131 and 8151).

And first of all, because I want to have under control all blocks, I'm
starting by-passing any propriatery BIOS.

Also, I'm very interested in getting and testing your FreeBios module and
why not offering my contribution. However, all things related to my target
are located in your freebios2 branch.

And because my (...) proxy doesn't give me permission to access to CVS
server, is any snapshot gathering the latest version ? Or any other way than
to download manually each file ?

Thanks in advance

Gael MACE                              e-mail:gael.mace at thomson.net
Research & Innovation                  Corporate Research Rennes
            Labo Multimedia Streaming & Storage (MSS)
Thomson Multimedia R&D                 
1 Avenue de Belle Fontaine             Tel: (33)(0)299.273.386
CS17616                                Fax: (33)(0)299.273.558
35510 CESSON-SEVIGNE
FRANCE

------>>    The speed can kill ==> use Windows   <<------



From agnew at cs.umd.edu  Mon Aug 25 06:26:01 2003
From: agnew at cs.umd.edu (Adam Agnew)
Date: Mon Aug 25 06:26:01 2003
Subject: Any freebios2 CVS snapshot ?
In-Reply-To: <05B4910E0216D411B14F00508B6A67A9033535FD@renexch5.rennes.thmulti.com>
Message-ID: <20030825064211.O93410-100000@www.missl.cs.umd.edu>

Here you go. Just pulled down and tarbz2-ed up.
http://www.missl.cs.umd.edu/~agnew/freebios2-08252003.tar.bz2


On Mon, 25 Aug 2003, Mace Gael wrote:

> Hello,
>
> working on an AMD platform (dual Opteron), I concentrate one's efforts on
> the HyperTransport link and related chipset (8111, 8131 and 8151).
>
> And first of all, because I want to have under control all blocks, I'm
> starting by-passing any propriatery BIOS.
>
> Also, I'm very interested in getting and testing your FreeBios module and
> why not offering my contribution. However, all things related to my target
> are located in your freebios2 branch.
>
> And because my (...) proxy doesn't give me permission to access to CVS
> server, is any snapshot gathering the latest version ? Or any other way than
> to download manually each file ?
>
> Thanks in advance
>
> Gael MACE                              e-mail:gael.mace at thomson.net
> Research & Innovation                  Corporate Research Rennes
>             Labo Multimedia Streaming & Storage (MSS)
> Thomson Multimedia R&D
> 1 Avenue de Belle Fontaine             Tel: (33)(0)299.273.386
> CS17616                                Fax: (33)(0)299.273.558
> 35510 CESSON-SEVIGNE
> FRANCE
>
> ------>>    The speed can kill ==> use Windows   <<------
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>




From sc at flagen.com  Mon Aug 25 13:54:00 2003
From: sc at flagen.com (David Hendricks)
Date: Mon Aug 25 13:54:00 2003
Subject: Linuxbios: Booting linux from flash IDE drive on epia boards?
In-Reply-To: <3F47AAAE.1070507@denkmair.de>
References: <3F47AAAE.1070507@denkmair.de>
Message-ID: <60023.128.165.250.195.1061838630.squirrel@mail.flagen.com>

Etherboot can boot a kernel from an IDE device as well as a floppy or over
a network.

Have you checked the freebios/HOWTO/EPIA file? That should help get you
started. To get it working from an IDE device, The basic procedure should
go something like this:
0) Consider investing in a BIOS Savior device in case something goes wrong.
1) Modify the epia.config.example file to use IDE--Add the line "option
BOOT_IDE=1" somewhere in there, maybe some other stuff Sone Takeshi or
Andrew Ip or some others around here can help you with. Here's an old one
from Sone that I haven't defiled:
http://www.flagen.com/~sc/linux/lb/epia/epia.config.sone
2a) Download Etherboot ( etherboot.sf.net ) Build a working etherboot
payload (Should be ide_disk in the etherboot/src/bin directory after you
'make' etherboot).
2b) Build LinuxBIOS with that python command described in
freebios/HOWTO/EPIA and run 'make' in the target directory to build your
romimage.
2c) Burn the romimage to the EPIA flash chip using the flash_write utility
(Under /freebios/util/flash_and_burn).
3) Build kernel for EPIA.
4) Use mkelfImage ( ftp://lnxi.com/pub/mkelfImage/ ) on your kernel image.
5) Format your IDE device with FAT
6) Write your elfImage to the IDE device like so: dd if=elfImage
of=/dev/your_compactflash_device bs=1024 seek=4
7) Test it out, fail, and have someone with more expertise explain this to
you in further (And more correct) detail :)

If all else fails, you can try this ROM:
http://www.flagen.com/~sc/linux/lb/epia/epia-ide.andrew.rom . It's an old
one from Andrew Ip, the l33t master. If it doesn't work, at least you can
use it as a proof of concept to figure if this whole ordeal is worthwhile
for your needs.

> Hello, (second try)
>
> I'm planning to build my own car mp3 player on a PC basis and now found
> out that the VIA epia boards seem to be supported by linuxbios.
> I'd love to boot my mp3 player via linuxbios to get the music playing
> asap... unfortunatly the linuxbios-docs are not very userfriendly - I
> understand that it's possible to boot the epia boards via etherboot, but
> can i also load a kernel from IDE devices, e.g. a compact flash card
> mounted into a IDE compact flash drive?
> If not - is there any other way to load a linux-kernel really FAST in a
> EPIA standalone (car-) system?
>
> Would you recommand a special board, such as the EPIA-V8000, or are they
> all working well?
>
> Thanks a lot for your help,
>
>
> Hubert
> ---
> hubert at denkmair.de
>
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From sc at flagen.com  Mon Aug 25 16:47:01 2003
From: sc at flagen.com (David Hendricks)
Date: Mon Aug 25 16:47:01 2003
Subject: Question about Opteron UnitID register
Message-ID: <60248.128.165.250.195.1061848983.squirrel@mail.flagen.com>

I know you guys aren't AMD tech support, I was hoping someone could help
me figure this problem out. In section 3.3.8 (page 35) of their BIOS and
Kernel developers guide (
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF
), they have a 32-bit UnitID register. The example given lists the lowest
four bits as follows:
3-2: CPU1 Unit ID
1-2: CPU0 Unit ID

Ok, so you could give CPU1, CPU2, and CPU3 a unique ID with two binary
digits, but I thought we were supposed to be able to have eight (or more?)
CPUs?

Is there something obvious I'm missing? Is the CPU Unit ID the same as the
NodeID, or different? Do these CPU Unit IDs even have to be unique for
each CPU?

I was thinking perhaps the CPU1 Unit ID is used only by a noncoherant
device attached via Hypertransport link to what it thinks is CPU1 to
differentiate the CPU it's attached to from CPU0. If this is true, is it
necessary since the bootstrap processor, CPU0, is the only one with access
to its northbridge and memory controller at this point?

Sorry if all this is complete and utter nonsense, I'm just a very curious
newbie.


From rminnich at lanl.gov  Mon Aug 25 20:42:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 25 20:42:00 2003
Subject: epia-800 kernel panic
In-Reply-To: <3F43BFF1.6030304@nexpath.com>
Message-ID: <Pine.LNX.4.44.0308251858240.30625-100000@maxroach.lanl.gov>

On Wed, 20 Aug 2003, Steve Gehlbach wrote:

> Never mind, I found the problem.  RAM was not getting init'ed correctly 
> for the SDRAM I was using.  I was not completely sync'ed to the 
> repository, and did not have the latest northbridge files.  Main reason 
> was that ide.c, ide.h were broken for secondary ide, but I backed up one 
> rev on each got that to work.

ok. That kind of thing is usually ram. 

We need to get this ide mess fixed.

ron



From ebiederman at lnxi.com  Mon Aug 25 21:14:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Aug 25 21:14:00 2003
Subject: Question about Opteron UnitID register
In-Reply-To: <60248.128.165.250.195.1061848983.squirrel@mail.flagen.com>
References: <60248.128.165.250.195.1061848983.squirrel@mail.flagen.com>
Message-ID: <m3vfsl6vzl.fsf@maxwell.lnxi.com>

"David Hendricks" <sc at flagen.com> writes:

> I know you guys aren't AMD tech support, I was hoping someone could help
> me figure this problem out. In section 3.3.8 (page 35) of their BIOS and
> Kernel developers guide (
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26094.PDF
> 
> ), they have a 32-bit UnitID register. The example given lists the lowest
> four bits as follows:
> 3-2: CPU1 Unit ID
> 1-2: CPU0 Unit ID
> 
> Ok, so you could give CPU1, CPU2, and CPU3 a unique ID with two binary
> digits, but I thought we were supposed to be able to have eight (or more?)
> CPUs?
> 
> Is there something obvious I'm missing? 
The context.  The unitid referred to are all internal to the cpu.

On current cpu implementations only CP0 is present so it is a little
confusing.

> Is the CPU Unit ID the same as the NodeID, or different? 
Different.

> Do these CPU Unit IDs even have to be unique for each CPU?

Yes.

> I was thinking perhaps the CPU1 Unit ID is used only by a noncoherant
> device attached via Hypertransport link to what it thinks is CPU1 to
> differentiate the CPU it's attached to from CPU0. If this is true, is it
> necessary since the bootstrap processor, CPU0, is the only one with access
> to its northbridge and memory controller at this point?
> 
> Sorry if all this is complete and utter nonsense, I'm just a very curious
> newbie.


There is a lot integrated into an opteron and it takes some serious looking
to really see what is going on.

Eric



From rminnich at lanl.gov  Mon Aug 25 21:25:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 25 21:25:01 2003
Subject: linuxbios on arbor emcore i612?
In-Reply-To: <3F45FC4C.4080405@denkmair.de>
Message-ID: <Pine.LNX.4.44.0308251940480.31051-100000@maxroach.lanl.gov>

hi, we are really time-pressed, so an lspci is much better than a data 
sheet. 

Thanks

ron



From rminnich at lanl.gov  Mon Aug 25 21:30:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 25 21:30:00 2003
Subject: bootselect problems
In-Reply-To: <Pine.LNX.4.21.0308231129180.8983-100000@ucontrol.mobiledns.com>
Message-ID: <Pine.LNX.4.44.0308251946290.31051-100000@maxroach.lanl.gov>

On Sat, 23 Aug 2003, steven james wrote:

> I need to add a tag generator in there!
> The newer baremetal is breaking with ide.c from the freebios/src tree. I'm
> looking at that, but in the meantime, you can change
> util/baremetal/lib/Makefile to skip ide.c and it will compile (minus ide
> support of course).

let me know when fixed. I want to try this out.

ron



From rminnich at lanl.gov  Mon Aug 25 21:33:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 25 21:33:01 2003
Subject: Linuxbios: Booting linux from flash IDE drive on epia boards?
In-Reply-To: <20030825002806.GA7177@planetfall.com>
Message-ID: <Pine.LNX.4.44.0308251948550.31051-100000@maxroach.lanl.gov>

On Sun, 24 Aug 2003, Jeff Noxon wrote:

> Sure, and they're damn expensive.  EPIA is dirt cheap.  (And crap too,
> but sometimes price wins anyway. ;)

it's not that crappy. 

> Unless you know of a sub-$125 ARM-based board?  /dreaming
> 


All the things that should be cheap, it seems, are not cheap. I just saw 
an add for an 8-bit, 16-bit address space Zilog Z80, running at 50 Mhz, 
for $199 -- 2x the whole EPIA!

ron



From rminnich at lanl.gov  Mon Aug 25 21:42:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Mon Aug 25 21:42:00 2003
Subject: Any freebios2 CVS snapshot ?
In-Reply-To: <05B4910E0216D411B14F00508B6A67A9033535FD@renexch5.rennes.thmulti.com>
Message-ID: <Pine.LNX.4.44.0308251958510.31051-100000@maxroach.lanl.gov>

I will try to set up snapshots via the web page this week. 

ron



From niki.waibel at newlogic.com  Tue Aug 26 05:28:01 2003
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Tue Aug 26 05:28:01 2003
Subject: DIP2PLCC
In-Reply-To: <1060695002.3f38ebda73e0b@www.malaiwah.com>
Message-ID: <200308260944.h7Q9iTH3001905@enterprise2.newlogic.at>

On 12-Aug-2003 Michel Belleau wrote:
> Selon Niki Waibel <niki.waibel at newlogic.com>:
>> > Where could I find a DIP2PLCC adapter ?
>> http://www.epboard.com/
> 
> That's what I did yesterday ;-)
> 
>> i also ordered a MD-2802-D08-V3 and a MD-2202-D128-V3.
>> both come originally from www.m-sys.com (m-systems).
>> on their website you can find a local reseller:
>> http://www.m-sys.com/Content/Contact/MsysWorldwide.asp
>> i am waiting for that as well.
> 
> I ordered the 5V versions because my EPIA 800mhz board uses the "SST 39SF020A" 
> flash chip which is rated at 4.5/5V. What board do you have?

bios savior rd1-pl is working.
shitt!
this is the 5V version ...
it seems that i ordered the wrong devices...

>> currently (afaik) noone has tried to get linuxbios
>> working like this. (if i am wrong then pls tell me!)
>> the plan is to have linuxbios, the kernel and a small
>> rootfs in this m-systems chip (MD-2802-D08-V3 = 8MByte -- can boot
>> linuxbios on DIP motherboards, MD-2202-D128-V3 = 128MB --
>> but i've heard on this list that it is not possible to
>> boot linuxbios with this chip... we'll see ;-) ).
>> the chip will sit on the DIP2PLCC converter.
> 
> I ordered the 8Mbyte chip from tri-m and the DIP2PLCC adapter from epboard. I'm 
> looking to integrate everything to the 8mb chip. I think it's really possible 
> because I already made a linux boot disk (uclibc+busybox+mpg321) which 
> connected itself to my home server and played mp3's as soon as it could.

sounds cool.

>> what type of chassis do you use?
> 
> I made a custom chassis for prototyping use only ;-) The final stage of 
> developpement will be to make something nice for the casing.

ok. a car mp3 player needs a custom chassis :)

>> and a bios savior to make programming easy.
>> and a flash chip (there is one integrated in
>> the bios savior, but that chip is only 256kbyte).
> 
> I'm very curious and I want to learn everything ;-) My current project consists 
> of:
> 
> VIA EPIA 800mhz all-on-board fanless mb
> DC-to-DC power supply (input: car voltage.. 14.4v)
> VWCDPIC adapter (to connect to the cd-changer input of my car (VW))
> DIP2PLCC adapter (for the millenium chip)
> DoC Millenium (8mb, all right for the linuxbios + kernel + small fs)
> 
> My first goal is to make it boot in 3 seconds (i think linuxbios can help me 
> achieve it) and start to play mp3's from whatever will be connected to it (for 
> instance, an old hard drive and/or a dvd-rom drive). The mb will feed the audio 
> to the VWCDPIC and the VWCDPIC will feed the commands from my oem head-unit to 
> the computer (rs-232).
> 
> Right now, it's kinda slow to boot and only starts playing several seconds 
> after i power-up the board.
> 
> I know there's already products that have the same functionnality on the 
> market, but I want to learn for fun how everything is made and create my own 
> product.
> 
> My next goal will be to make it play DVDs (once I get a cheap LCD), or rip 
> audio CDs right on the hard drive connected to it, or diagnose what's wrong 
> with my car (vag-com) or whatever I can think of.

good luck!

niki


From rminnich at lanl.gov  Tue Aug 26 09:54:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 26 09:54:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030816181518.GA1076@tsn.or.jp>
Message-ID: <Pine.LNX.4.44.0308260809490.3587-100000@maxroach.lanl.gov>

On Sun, 17 Aug 2003, SONE Takeshi wrote:

> On Mon, Aug 11, 2003 at 05:21:06PM -0600, ron minnich wrote:
> > On Mon, 11 Aug 2003, YhLu wrote:
> > > I try to move the vgabios to freebios2 for 2880. I put the BIOS option rom
> > > to 0xfff8c000, ( the second 48k).
> > Looks, however, looke tehre is a bug ... Takeshi can perhaps address it 
> > better than I. 
> 
> PCI spec requires System BIOS to provide Bus/Dev/Fn of the device
> in AX register when calling option ROM during POST.
> This way multiple instances of same PCI device can be initialized
> one by one, I guess.
> 
> And, vgabios.c doesn't do that.

I have a fixed vgabios.c if anyone wants to test it that should now put 
bus/dev/fn in the ax register.

ron



From rminnich at lanl.gov  Tue Aug 26 09:56:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Tue Aug 26 09:56:00 2003
Subject: Supporting extension ROMs and beyond...
In-Reply-To: <20030816181518.GA1076@tsn.or.jp>
Message-ID: <Pine.LNX.4.44.0308260812480.3614-100000@maxroach.lanl.gov>

On Sun, 17 Aug 2003, SONE Takeshi wrote:

> PCI spec requires System BIOS to provide Bus/Dev/Fn of the device

BTW I am assuming the format is 
(bus << 8) | devfn, correct?

ron



From rimy2000 at hotmail.com  Tue Aug 26 23:25:01 2003
From: rimy2000 at hotmail.com (elife elife)
Date: Tue Aug 26 23:25:01 2003
Subject: about VGA support in voyager2 board
Message-ID: <BAY2-F114ztxc1o8yfo00013bf4@hotmail.com>

Hi,
  I am trying to add VGA support in cocom voyager2 board. The VGA is found 
but lb complain "biosint: Unsupport int #0x6" endlessly. I dumped the 
original bios and found besides VGA BIOS I extracted, there is VSA driver. 
Is VSA driver also needed to work with linuxbios and VGA BIOS? If so, Where 
should I put it? And need I do more things to make it work?

   Best Regards!


              ********  phoneix.bin BIOS component ********

 No. Item-Name         Original-Size   Compressed-Size Original-File-Name
==============================================================================

  0. System BIOS       20000h(128.00K) 12EECh(75.73K)  original.tmp
  1. XGROUP CODE       07340h(28.81K)  04D70h(19.36K)  awardext.rom
  2. EPA LOGO          0168Ch(5.64K)   002AAh(0.67K)   AwardBmp.bmp
  3. VGA ROM[1]        08000h(32.00K)  04229h(16.54K)  gxivideo.208
  4. PCI ROM[A]        0C800h(50.00K)  07536h(29.30K)  RTSROM_M.LOM
  5. VSA driver        20000h(128.00K) 09B2Fh(38.80K)  GXM55306.BIN
  6. LOGO BitMap       2583Ch(150.06K) 0474Bh(17.82K)  n5535.bmp


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

INSTALL REAL-MODE IDT

DO THE VGA BIOS

found VGA: vid=1078, did=104

0x55 0xaa 0x40 0xeb 0x4b 0x37 0x34 0x30 0x30 0xe9 0x4c 0x19 0x77 0xcc 0x56 
0x49 biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c

biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000

biosint: ip 0x3 cs 0x0 flags 0x46

biosint: Unsupport int #0x6

biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c

biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000

biosint: ip 0x3 cs 0x0 flags 0x46

biosint: Unsupport int #0x6

biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c

biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000

biosint: ip 0x3 cs 0x0 flags 0x46

biosint: Unsupport int #0x6

_________________________________________________________________
??????????????? MSN Hotmail?  http://www.hotmail.com  



From rminnich at lanl.gov  Wed Aug 27 00:44:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug 27 00:44:01 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <BAY2-F114ztxc1o8yfo00013bf4@hotmail.com>
Message-ID: <Pine.LNX.4.44.0308262259250.9023-100000@maxroach.lanl.gov>

On Wed, 27 Aug 2003, elife elife wrote:

>   I am trying to add VGA support in cocom voyager2 board. The VGA is found 
> but lb complain "biosint: Unsupport int #0x6" endlessly. I dumped the 
> original bios and found besides VGA BIOS I extracted, there is VSA driver. 
> Is VSA driver also needed to work with linuxbios and VGA BIOS? If so, Where 
> should I put it? And need I do more things to make it work?

you need to confirm that int #5 is a VSA interrupt of some sort. 

What I would recommend to make debugging easier is to use the "testbios" 
program to do the VGA support first. Once that is working, you can see how 
to make vgabios work. What makes this easier is that you can run testbios 
under linux.

ron



From ts1 at cma.co.jp  Wed Aug 27 02:58:01 2003
From: ts1 at cma.co.jp (SONE Takeshi)
Date: Wed Aug 27 02:58:01 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <Pine.LNX.4.44.0308262259250.9023-100000@maxroach.lanl.gov>
References: <BAY2-F114ztxc1o8yfo00013bf4@hotmail.com> <Pine.LNX.4.44.0308262259250.9023-100000@maxroach.lanl.gov>
Message-ID: <20030827071442.GA2082@cma.co.jp>

On Tue, Aug 26, 2003 at 11:00:27PM -0600, ron minnich wrote:
> On Wed, 27 Aug 2003, elife elife wrote:
> 
> >   I am trying to add VGA support in cocom voyager2 board. The VGA is found 
> > but lb complain "biosint: Unsupport int #0x6" endlessly. I dumped the 
> > original bios and found besides VGA BIOS I extracted, there is VSA driver. 
> > Is VSA driver also needed to work with linuxbios and VGA BIOS? If so, Where 
> > should I put it? And need I do more things to make it work?
> 
> you need to confirm that int #5 is a VSA interrupt of some sort. 

I don't know what VSA is, but int 6 is the Invalid Opcode Exception,
not a BIOS service.
This means the execution crashed.

Btw, I've noticed that the idt.c (realmode int handler) puts
"stub"s starting at 0x400 (1024). It installs 256 stubs, 9 bytes each,
so they occupy 256*9=2304 bytes from 0x400.
The 256 bytes (or more?) starting at 0x400 is the BIOS Data Area,
and VGABIOS tends to rewrite some bytes in it.
So, it might damage the int handler before calling it.

I don't know if this is the case, but the stubs can easily be moved
anywhere below 64k, I think.

--
Takeshi


From veikko.werner at logware.de  Wed Aug 27 07:39:02 2003
From: veikko.werner at logware.de (Veikko Werner)
Date: Wed Aug 27 07:39:02 2003
Subject: download cvs tarball
Message-ID: <8BEFECF23C9C264094D4B53DFC3ACE98A29A5D@bmail.logware.de>

hey guys,

I can't download the cvs tarball onthe website (file not found) and I can't download directly from CVS (company firewall)

How can I get the latest sources?

Regards,

Veikko


From rminnich at lanl.gov  Wed Aug 27 09:21:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug 27 09:21:00 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <20030827071442.GA2082@cma.co.jp>
Message-ID: <Pine.LNX.4.44.0308270737050.12604-100000@maxroach.lanl.gov>

On Wed, 27 Aug 2003, SONE Takeshi wrote:

> On Tue, Aug 26, 2003 at 11:00:27PM -0600, ron minnich wrote:
> > you need to confirm that int #5 is a VSA interrupt of some sort. 
> 
> I don't know what VSA is, but int 6 is the Invalid Opcode Exception, not
> a BIOS service. This means the execution crashed.

yes, I think something is going wrong. 


> Btw, I've noticed that the idt.c (realmode int handler) puts
> "stub"s starting at 0x400 (1024). It installs 256 stubs, 9 bytes each,
> so they occupy 256*9=2304 bytes from 0x400.
> The 256 bytes (or more?) starting at 0x400 is the BIOS Data Area,
> and VGABIOS tends to rewrite some bytes in it.
> So, it might damage the int handler before calling it.

that's a very good thing to know! 

Where would you like to see the stubs moved?

ron



From ts1 at cma.co.jp  Wed Aug 27 09:40:01 2003
From: ts1 at cma.co.jp (SONE Takeshi)
Date: Wed Aug 27 09:40:01 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <Pine.LNX.4.44.0308270737050.12604-100000@maxroach.lanl.gov>
References: <20030827071442.GA2082@cma.co.jp> <Pine.LNX.4.44.0308270737050.12604-100000@maxroach.lanl.gov>
Message-ID: <20030827135654.GA25677@cma.co.jp>

On Wed, Aug 27, 2003 at 07:37:58AM -0600, ron minnich wrote:
> > Btw, I've noticed that the idt.c (realmode int handler) puts
> > "stub"s starting at 0x400 (1024). It installs 256 stubs, 9 bytes each,
> > so they occupy 256*9=2304 bytes from 0x400.
> > The 256 bytes (or more?) starting at 0x400 is the BIOS Data Area,
> > and VGABIOS tends to rewrite some bytes in it.
> > So, it might damage the int handler before calling it.
> 
> that's a very good thing to know! 
> 
> Where would you like to see the stubs moved?

I think any address below 64K is ok without more modifications to the
code.
You put realmode stack at 4K (and below).
LinuxBIOS starts at 32K for most configurations(?).
So, putting stubs at 4K (0x1000) makes sense, I think.

--
Takeshi


From rminnich at lanl.gov  Wed Aug 27 09:58:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug 27 09:58:00 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <20030827135654.GA25677@cma.co.jp>
Message-ID: <Pine.LNX.4.44.0308270814050.12778-100000@maxroach.lanl.gov>

OK, would anyone like to test out my fixed vgabios with the devfn patch?

I will look at moving the table to 0x1000. I actually think there was a 
reason I kept all this on page 0, but that reason probably no longer 
matters.

ron




From michel.belleau at malaiwah.com  Wed Aug 27 12:48:01 2003
From: michel.belleau at malaiwah.com (Michel Belleau)
Date: Wed Aug 27 12:48:01 2003
Subject: LinuxBIOS problems with DoC
Message-ID: <1062003873.3f4ce4a1660c8@www.malaiwah.com>

Hi.

VIA EPIA 800Mhz
DIP2PLCC adapter
DoC Millenium 8MB
Slackware 9.0 on the HD

I downloaded via CVS the latest version of Linuxbios and made my epia.config 
file. I can hotswap my BIOS chip with the DoC and Linux sees it when I load the 
modules. I can erase the chip and write whatever to it.

I can build a romimage (256k) with Linuxbios but I don't have to guts yet to 
flash it on my original chip. *** Can I write it on the DoC? How?

I don't seem to be able to build with the USE_DOC_MIL=1 option set in the 
config file. The make command always result in a failure, because "dd" doesn't 
have a valid argument for the size (it's a negative value). *** What are the 
values needed in the config file to prepare Linuxbios to be flashed on a DoC? I 
tried ROM_SIZE=838xxxx but the resulting "romimage" file is too big for the DoC.

*** What are the steps to write the BIOS onto the DoC? Can I go step by step 
and check out what's wrong easily?

Here's what I tried yesterday (by heart).

modprobe doc2001 && modprobe docecc && modprobe docprobe (my DoC is found)
erase /dev/mtd0 0 1024 (which erases the entire DoC, right?)
dd if=docpil of=/dev/mtd0 (docipl is supposed to be at the first block, right?)
dd if=docipl of=/dev/mtd0 seek=1 (docipl is at the second block too, right?)
dd if=romimage.via-rhine of=/dev/mtd0 seek=2 (i TRIED by guess to put the 
romimage I built earlier right after the two docipl)
reboot
(shut off the computer beacuse it hangs at "Rebooting the system...")
When I power it up, nothing comes up on my serial console, just like when I 
tried starting the board without a BIOS chip.

What can I do to test gradually my setup? What did I did wrong? Help me out 
please ;-)

-- 
Michel Belleau <michel.belleau at malaiwah.com>


From stuge-linuxbios at cdy.org  Wed Aug 27 13:08:00 2003
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed Aug 27 13:08:00 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <20030827071442.GA2082@cma.co.jp>
References: <BAY2-F114ztxc1o8yfo00013bf4@hotmail.com> <Pine.LNX.4.44.0308262259250.9023-100000@maxroach.lanl.gov> <20030827071442.GA2082@cma.co.jp>
Message-ID: <20030827170013.GC16732@foo.birdnet.se>

On Wed, Aug 27, 2003 at 04:14:42PM +0900, SONE Takeshi wrote:
> > you need to confirm that int #5 is a VSA interrupt of some sort. 
> 
> I don't know what VSA is, but int 6 is the Invalid Opcode Exception,

VSA is the name of a NSC system to allow for software implementations of
legacy hardware. VSMs (Virtual System Modules) load themselves e.g. from
option ROM or part of the BIOS and tell VSA that IO reads and writes to
this-and-that address should be trapped, and sent to the VSM for proper
handling instead.

E.g. audio and USB require a VSM on SCx2xx/GX1+CS5530 systems, which I
believe the voyager2 is.

Unfortunately I don't remember if VSA can be used to trap interrupts as
well, but I agree with Ron and Mr. Takeshi that this is likely the VGA BIOS
scribbling over the interrupt table, if that's located at 400h.


//Peter


From rminnich at lanl.gov  Wed Aug 27 17:47:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Wed Aug 27 17:47:01 2003
Subject: LinuxBIOS problems with DoC
In-Reply-To: <1062003873.3f4ce4a1660c8@www.malaiwah.com>
Message-ID: <Pine.LNX.4.44.0308271603430.15762-100000@maxroach.lanl.gov>

you can not use doc with the EPIA, you have to use a normal flash.

ron



From michel.belleau at malaiwah.com  Wed Aug 27 20:01:01 2003
From: michel.belleau at malaiwah.com (Michel Belleau)
Date: Wed Aug 27 20:01:01 2003
Subject: LinuxBIOS problems with DoC
In-Reply-To: <Pine.LNX.4.44.0308271603430.15762-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0308271603430.15762-100000@maxroach.lanl.gov>
Message-ID: <1062029852.3f4d4a1cb4b9f@www.malaiwah.com>

Selon ron minnich <rminnich at lanl.gov>:

> you can not use doc with the EPIA, you have to use a normal flash.

Hi Ron. Is this a software or an hardware problem? Thanks a lot.

-- 
Michel Belleau <michel.belleau at malaiwah.com>


From rminnich at lanl.gov  Thu Aug 28 00:17:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 28 00:17:00 2003
Subject: LinuxBIOS problems with DoC
In-Reply-To: <1062029852.3f4d4a1cb4b9f@www.malaiwah.com>
Message-ID: <Pine.LNX.4.44.0308272233050.18188-100000@maxroach.lanl.gov>

On Wed, 27 Aug 2003, Michel Belleau wrote:

> Selon ron minnich <rminnich at lanl.gov>:
> 
> > you can not use doc with the EPIA, you have to use a normal flash.
> 
> Hi Ron. Is this a software or an hardware problem? Thanks a lot.

it is a chipset problem. You can not really get that chipset on in a 
general way in the 256 bytes or so you get with the DoC. 

I did have that northbridge working once up on a time with DoC but it was 
very flaky. It has a very finicky ram bus and so you can not just set 
general parameters and have dram come up reliably.

ron



From ts1 at cma.co.jp  Thu Aug 28 02:26:00 2003
From: ts1 at cma.co.jp (SONE Takeshi)
Date: Thu Aug 28 02:26:00 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <Pine.LNX.4.44.0308270814050.12778-100000@maxroach.lanl.gov>
References: <20030827135654.GA25677@cma.co.jp> <Pine.LNX.4.44.0308270814050.12778-100000@maxroach.lanl.gov>
Message-ID: <20030828064246.GA4973@cma.co.jp>

On Wed, Aug 27, 2003 at 08:14:47AM -0600, ron minnich wrote:
> OK, would anyone like to test out my fixed vgabios with the devfn patch?
> 
> I will look at moving the table to 0x1000. I actually think there was a 
> reason I kept all this on page 0, but that reason probably no longer 
> matters.

I think the page size hardly matters, since nothing does paging.
What matters is the 64K limit of 16-bit segments.
I found it very clever that current code puts everything below 64K
and sets zero to all 16-bit segment registers. It simplfies the
code a lot.

It's also worth mentioning that the current code works only
if the "trampoline" code is also located below 64K.
On my build it is ok, but nothing forces or checks it.

--
Takeshi


From rimy2000 at hotmail.com  Thu Aug 28 08:20:01 2003
From: rimy2000 at hotmail.com (elife elife)
Date: Thu Aug 28 08:20:01 2003
Subject: about VGA support in voyager2 board
Message-ID: <BAY2-F135yR1xKJRAB900000469@hotmail.com>

Sorry for delayed reply. I will test it tomorrow.

Thanks all!


>From: ron minnich <rminnich at lanl.gov>
>To: SONE Takeshi <ts1 at cma.co.jp>
>CC: elife elife <rimy2000 at hotmail.com>, <linuxbios at clustermatic.org>
>Subject: Re: about VGA support in voyager2 board
>Date: Wed, 27 Aug 2003 08:14:47 -0600 (MDT)
>
>OK, would anyone like to test out my fixed vgabios with the devfn patch?
>
>I will look at moving the table to 0x1000. I actually think there was a
>reason I kept all this on page 0, but that reason probably no longer
>matters.
>
>ron
>
>

_________________________________________________________________
?????????????? MSN Messenger:  http://messenger.msn.com/cn  



From stepan at suse.de  Thu Aug 28 09:09:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Aug 28 09:09:00 2003
Subject: Unified setup...
Message-ID: <20030828133427.GA12241@suse.de>

Hi LYH, Ron and others,

I've been looking at the recent changes that went into the tree, and I
don't like the fact that a lot of code is duplicated. Is there some way
to unify this?

--- raminit.c   2003-08-28 14:43:39.000000000 +0200
+++ raminit.1.c 2003-08-28 06:42:50.000000000 +0200
[..]
-       PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff00,
+       PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff20,

This changes the link id where the southbridge is connected.
We can get this information out of the configuration file since we
are able to describe a map of all CHT components.
On most machines the southbridge is probably connected to LDT0, but
having two files for this one setting seems inappropriate.
Ron, what is the easiest way of getting this information from the
config file?

LYH: To get this unified again, I added a resourcemap.c file to the
s2885 directory that contains the resource map of the 2885. In auto.c
this is used instead of the default.

-       PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff000,
+       PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff020,

same as above.

-       PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0xff000003,
-       PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000000,
+       PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x03000203,
+       PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x05040003,

These change the bus numbers and read/write enables. How can we write
these more general?

+/*
 //BY LYH  add IOMMU 64M APERTURE
        PCI_ADDR(0, 0x18, 3, 0x94), 0xffff8000, 0x00000f70,
        PCI_ADDR(0, 0x18, 3, 0x90), 0xffffff80, 0x00000002,
        PCI_ADDR(0, 0x18, 3, 0x98), 0x0000000f, 0x00068300,
 
 //BY LYH END
+*/

I added a configuration variable ENABLE_IOMMU and set it to 1 for all
existing boards except the s2885. It would be nice to have the size of
the aperture also selectable via the configuration file, or even better 
during firmware run time. 

I am scared that changes for special motherboards will contaminate the
source tree and make it hard for anyone to see what is actually going
on. If this happens in a source tree for a special motherboard, it does
not really matter, but I think it is a good goal to keep the generic
code clean and generic and make it even more generic in the places where
it's not sufficient.

I'll look into coherent_ht.1.c and see if this can be done more general
as well.

I commited the attached patch. Please comment.

Stefan

-- 
Architecture Team
    SuSE Linux AG
-------------- next part --------------
diff --exclude='*CVS*' -urN mylinuxbios/LinuxBIOS/freebios2/src/config/Options.lb freebios2/src/config/Options.lb
--- mylinuxbios/LinuxBIOS/freebios2/src/config/Options.lb	2003-08-14 11:09:07.000000000 +0200
+++ freebios2/src/config/Options.lb	2003-08-28 15:14:23.000000000 +0200
@@ -590,6 +590,11 @@
 	export used
 	comment "Disable watchdog if we're doing lots of output"
 end
+define ENABLE_IOMMU
+	default 1
+	export used
+	comment "Enable IOMMU aperture"
+end
 
 ###############################################
 # Misc device options
diff --exclude='*CVS*' -urN mylinuxbios/LinuxBIOS/freebios2/src/mainboard/amd/quartet/Config.lb freebios2/src/mainboard/amd/quartet/Config.lb
--- mylinuxbios/LinuxBIOS/freebios2/src/mainboard/amd/quartet/Config.lb	2003-08-14 11:09:11.000000000 +0200
+++ freebios2/src/mainboard/amd/quartet/Config.lb	2003-08-28 15:19:27.000000000 +0200
@@ -2,7 +2,7 @@
 uses HAVE_PIRQ_TABLE
 uses USE_FALLBACK_IMAGE
 uses USE_NORMAL_IMAGE
-uses AMD8111_DEV
+uses ENABLE_IOMMU
 #
 #
 ###
@@ -141,3 +141,5 @@
 cpu p6 end
 cpu k7 end
 cpu k8 end
+
+option ENABLE_IOMMU=1
diff --exclude='*CVS*' -urN mylinuxbios/LinuxBIOS/freebios2/src/mainboard/arima/hdama/Config.lb freebios2/src/mainboard/arima/hdama/Config.lb
--- mylinuxbios/LinuxBIOS/freebios2/src/mainboard/arima/hdama/Config.lb	2003-08-14 11:09:12.000000000 +0200
+++ freebios2/src/mainboard/arima/hdama/Config.lb	2003-08-28 15:19:55.000000000 +0200
@@ -5,6 +5,7 @@
 uses AMD8111_DEV
 uses MAINBOARD
 uses ARCH
+uses ENABLE_IOMMU
 #
 #
 ###
@@ -163,3 +164,5 @@
 
 cpu k8 "cpu1" 
 end
+
+option ENABLE_IOMMU=1
diff --exclude='*CVS*' -urN mylinuxbios/LinuxBIOS/freebios2/src/mainboard/tyan/s2880/Config.lb freebios2/src/mainboard/tyan/s2880/Config.lb
--- mylinuxbios/LinuxBIOS/freebios2/src/mainboard/tyan/s2880/Config.lb	2003-08-28 15:25:23.000000000 +0200
+++ freebios2/src/mainboard/tyan/s2880/Config.lb	2003-08-28 15:18:28.000000000 +0200
@@ -5,6 +5,7 @@
 uses AMD8111_DEV
 uses MAINBOARD
 uses ARCH
+uses ENABLE_IOMMU
 #
 #
 ###
@@ -174,3 +175,5 @@
 
 cpu k8 "cpu1"
 end
+
+option ENABLE_IOMMU=1
diff --exclude='*CVS*' -urN mylinuxbios/LinuxBIOS/freebios2/src/mainboard/tyan/s2882/Config.lb freebios2/src/mainboard/tyan/s2882/Config.lb
--- mylinuxbios/LinuxBIOS/freebios2/src/mainboard/tyan/s2882/Config.lb	2003-08-27 16:33:13.000000000 +0200
+++ freebios2/src/mainboard/tyan/s2882/Config.lb	2003-08-28 15:18:00.000000000 +0200
@@ -5,6 +5,7 @@
 uses AMD8111_DEV
 uses MAINBOARD
 uses ARCH
+uses ENABLE_IOMMU
 #
 #
 ###
@@ -173,3 +174,5 @@
 
 cpu k8 "cpu1"
 end
+
+option ENABLE_IOMMU=1
diff --exclude='*CVS*' -urN mylinuxbios/LinuxBIOS/freebios2/src/mainboard/tyan/s2885/auto.c freebios2/src/mainboard/tyan/s2885/auto.c
--- mylinuxbios/LinuxBIOS/freebios2/src/mainboard/tyan/s2885/auto.c	2003-08-27 16:33:13.000000000 +0200
+++ freebios2/src/mainboard/tyan/s2885/auto.c	2003-08-28 15:21:38.000000000 +0200
@@ -84,10 +84,12 @@
 #include "northbridge/amd/amdk8/cpu_ldtstop.c"
 #include "southbridge/amd/amd8111/amd8111_ldtstop.c"
 
-#include "northbridge/amd/amdk8/raminit.1.c"
+#include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.1.c"
 #include "sdram/generic_sdram.c"
 
+#include "resourcemap.c" /* tyan does not want the default */
+
 static void enable_lapic(void)
 {
 	msr_t msr;
@@ -164,7 +166,7 @@
 	}
 	uart_init();
 	console_init();
-	setup_default_resource_map();
+	setup_s2885_resource_map();
 	setup_coherent_ht_domain();
         enumerate_ht_chain(0);
 	//setup_resource_map_x();
diff --exclude='*CVS*' -urN mylinuxbios/LinuxBIOS/freebios2/src/mainboard/tyan/s2885/Config.lb freebios2/src/mainboard/tyan/s2885/Config.lb
--- mylinuxbios/LinuxBIOS/freebios2/src/mainboard/tyan/s2885/Config.lb	2003-08-27 16:33:13.000000000 +0200
+++ freebios2/src/mainboard/tyan/s2885/Config.lb	2003-08-28 15:15:35.000000000 +0200
@@ -5,6 +5,7 @@
 uses AMD8111_DEV
 uses MAINBOARD
 uses ARCH
+uses ENABLE_IOMMU
 #
 #
 ###
@@ -176,3 +177,6 @@
 
 cpu k8 "cpu1"
 end
+
+option ENABLE_IOMMU=0
+
diff --exclude='*CVS*' -urN mylinuxbios/LinuxBIOS/freebios2/src/mainboard/tyan/s2885/resourcemap.c freebios2/src/mainboard/tyan/s2885/resourcemap.c
--- mylinuxbios/LinuxBIOS/freebios2/src/mainboard/tyan/s2885/resourcemap.c	1970-01-01 01:00:00.000000000 +0100
+++ freebios2/src/mainboard/tyan/s2885/resourcemap.c	2003-08-28 15:11:53.000000000 +0200
@@ -0,0 +1,264 @@
+/*
+ * Tyan S2885 needs a different resource map
+ *
+ */
+
+static void setup_s2885_resource_map(void)
+{
+	static const unsigned int register_values[] = {
+	/* Careful set limit registers before base registers which contain the enables */
+	/* DRAM Limit i Registers
+	 * F1:0x44 i = 0
+	 * F1:0x4C i = 1
+	 * F1:0x54 i = 2
+	 * F1:0x5C i = 3
+	 * F1:0x64 i = 4
+	 * F1:0x6C i = 5
+	 * F1:0x74 i = 6
+	 * F1:0x7C i = 7
+	 * [ 2: 0] Destination Node ID
+	 *	   000 = Node 0
+	 *	   001 = Node 1
+	 *	   010 = Node 2
+	 *	   011 = Node 3
+	 *	   100 = Node 4
+	 *	   101 = Node 5
+	 *	   110 = Node 6
+	 *	   111 = Node 7
+	 * [ 7: 3] Reserved
+	 * [10: 8] Interleave select
+	 *	   specifies the values of A[14:12] to use with interleave enable.
+	 * [15:11] Reserved
+	 * [31:16] DRAM Limit Address i Bits 39-24
+	 *	   This field defines the upper address bits of a 40 bit  address
+	 *	   that define the end of the DRAM region.
+	 */
+	PCI_ADDR(0, 0x18, 1, 0x44), 0x0000f8f8, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x4C), 0x0000f8f8, 0x00000001,
+	PCI_ADDR(0, 0x18, 1, 0x54), 0x0000f8f8, 0x00000002,
+	PCI_ADDR(0, 0x18, 1, 0x5C), 0x0000f8f8, 0x00000003,
+	PCI_ADDR(0, 0x18, 1, 0x64), 0x0000f8f8, 0x00000004,
+	PCI_ADDR(0, 0x18, 1, 0x6C), 0x0000f8f8, 0x00000005,
+	PCI_ADDR(0, 0x18, 1, 0x74), 0x0000f8f8, 0x00000006,
+	PCI_ADDR(0, 0x18, 1, 0x7C), 0x0000f8f8, 0x00000007,
+	/* DRAM Base i Registers
+	 * F1:0x40 i = 0
+	 * F1:0x48 i = 1
+	 * F1:0x50 i = 2
+	 * F1:0x58 i = 3
+	 * F1:0x60 i = 4
+	 * F1:0x68 i = 5
+	 * F1:0x70 i = 6
+	 * F1:0x78 i = 7
+	 * [ 0: 0] Read Enable
+	 *	   0 = Reads Disabled
+	 *	   1 = Reads Enabled
+	 * [ 1: 1] Write Enable
+	 *	   0 = Writes Disabled
+	 *	   1 = Writes Enabled
+	 * [ 7: 2] Reserved
+	 * [10: 8] Interleave Enable
+	 *	   000 = No interleave
+	 *	   001 = Interleave on A[12] (2 nodes)
+	 *	   010 = reserved
+	 *	   011 = Interleave on A[12] and A[14] (4 nodes)
+	 *	   100 = reserved
+	 *	   101 = reserved
+	 *	   110 = reserved
+	 *	   111 = Interleve on A[12] and A[13] and A[14] (8 nodes)
+	 * [15:11] Reserved
+	 * [13:16] DRAM Base Address i Bits 39-24
+	 *	   This field defines the upper address bits of a 40-bit address
+	 *	   that define the start of the DRAM region.
+	 */
+	PCI_ADDR(0, 0x18, 1, 0x40), 0x0000f8fc, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x48), 0x0000f8fc, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x50), 0x0000f8fc, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x58), 0x0000f8fc, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x60), 0x0000f8fc, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x68), 0x0000f8fc, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x70), 0x0000f8fc, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x78), 0x0000f8fc, 0x00000000,
+
+	/* Memory-Mapped I/O Limit i Registers
+	 * F1:0x84 i = 0
+	 * F1:0x8C i = 1
+	 * F1:0x94 i = 2
+	 * F1:0x9C i = 3
+	 * F1:0xA4 i = 4
+	 * F1:0xAC i = 5
+	 * F1:0xB4 i = 6
+	 * F1:0xBC i = 7
+	 * [ 2: 0] Destination Node ID
+	 *	   000 = Node 0
+	 *	   001 = Node 1
+	 *	   010 = Node 2
+	 *	   011 = Node 3
+	 *	   100 = Node 4
+	 *	   101 = Node 5
+	 *	   110 = Node 6
+	 *	   111 = Node 7
+	 * [ 3: 3] Reserved
+	 * [ 5: 4] Destination Link ID
+	 *	   00 = Link 0
+	 *	   01 = Link 1
+	 *	   10 = Link 2
+	 *	   11 = Reserved
+	 * [ 6: 6] Reserved
+	 * [ 7: 7] Non-Posted
+	 *	   0 = CPU writes may be posted
+	 *	   1 = CPU writes must be non-posted
+	 * [31: 8] Memory-Mapped I/O Limit Address i (39-16)
+	 *	   This field defines the upp adddress bits of a 40-bit address that
+	 *	   defines the end of a memory-mapped I/O region n
+	 */
+	PCI_ADDR(0, 0x18, 1, 0x84), 0x00000048, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x8C), 0x00000048, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x94), 0x00000048, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x9C), 0x00000048, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xA4), 0x00000048, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xAC), 0x00000048, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xB4), 0x00000048, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff20,
+
+	/* Memory-Mapped I/O Base i Registers
+	 * F1:0x80 i = 0
+	 * F1:0x88 i = 1
+	 * F1:0x90 i = 2
+	 * F1:0x98 i = 3
+	 * F1:0xA0 i = 4
+	 * F1:0xA8 i = 5
+	 * F1:0xB0 i = 6
+	 * F1:0xB8 i = 7
+	 * [ 0: 0] Read Enable
+	 *	   0 = Reads disabled
+	 *	   1 = Reads Enabled
+	 * [ 1: 1] Write Enable
+	 *	   0 = Writes disabled
+	 *	   1 = Writes Enabled
+	 * [ 2: 2] Cpu Disable
+	 *	   0 = Cpu can use this I/O range
+	 *	   1 = Cpu requests do not use this I/O range
+	 * [ 3: 3] Lock
+	 *	   0 = base/limit registers i are read/write
+	 *	   1 = base/limit registers i are read-only
+	 * [ 7: 4] Reserved
+	 * [31: 8] Memory-Mapped I/O Base Address i (39-16)
+	 *	   This field defines the upper address bits of a 40bit address 
+	 *	   that defines the start of memory-mapped I/O region i
+	 */
+	PCI_ADDR(0, 0x18, 1, 0x80), 0x000000f0, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x88), 0x000000f0, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x90), 0x000000f0, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0x98), 0x000000f0, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xA0), 0x000000f0, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xA8), 0x000000f0, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xB0), 0x000000f0, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xB8), 0x000000f0, 0x00fc0003,
+
+	/* PCI I/O Limit i Registers
+	 * F1:0xC4 i = 0
+	 * F1:0xCC i = 1
+	 * F1:0xD4 i = 2
+	 * F1:0xDC i = 3
+	 * [ 2: 0] Destination Node ID
+	 *	   000 = Node 0
+	 *	   001 = Node 1
+	 *	   010 = Node 2
+	 *	   011 = Node 3
+	 *	   100 = Node 4
+	 *	   101 = Node 5
+	 *	   110 = Node 6
+	 *	   111 = Node 7
+	 * [ 3: 3] Reserved
+	 * [ 5: 4] Destination Link ID
+	 *	   00 = Link 0
+	 *	   01 = Link 1
+	 *	   10 = Link 2
+	 *	   11 = reserved
+	 * [11: 6] Reserved
+	 * [24:12] PCI I/O Limit Address i
+	 *	   This field defines the end of PCI I/O region n
+	 * [31:25] Reserved
+	 */
+	PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff020,
+	PCI_ADDR(0, 0x18, 1, 0xCC), 0xFE000FC8, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xD4), 0xFE000FC8, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xDC), 0xFE000FC8, 0x00000000,
+
+	/* PCI I/O Base i Registers
+	 * F1:0xC0 i = 0
+	 * F1:0xC8 i = 1
+	 * F1:0xD0 i = 2
+	 * F1:0xD8 i = 3
+	 * [ 0: 0] Read Enable
+	 *	   0 = Reads Disabled
+	 *	   1 = Reads Enabled
+	 * [ 1: 1] Write Enable
+	 *	   0 = Writes Disabled
+	 *	   1 = Writes Enabled
+	 * [ 3: 2] Reserved
+	 * [ 4: 4] VGA Enable
+	 *	   0 = VGA matches Disabled
+	 *	   1 = matches all address < 64K and where A[9:0] is in the 
+	 *	       range 3B0-3BB or 3C0-3DF independen of the base & limit registers
+	 * [ 5: 5] ISA Enable
+	 *	   0 = ISA matches Disabled
+	 *	   1 = Blocks address < 64K and in the last 768 bytes of eack 1K block
+	 *	       from matching agains this base/limit pair
+	 * [11: 6] Reserved
+	 * [24:12] PCI I/O Base i
+	 *	   This field defines the start of PCI I/O region n 
+	 * [31:25] Reserved
+	 */
+	PCI_ADDR(0, 0x18, 1, 0xC0), 0xFE000FCC, 0x00000003,
+	PCI_ADDR(0, 0x18, 1, 0xC8), 0xFE000FCC, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xD0), 0xFE000FCC, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xD8), 0xFE000FCC, 0x00000000,
+
+	/* Config Base and Limit i Registers
+	 * F1:0xE0 i = 0
+	 * F1:0xE4 i = 1
+	 * F1:0xE8 i = 2
+	 * F1:0xEC i = 3
+	 * [ 0: 0] Read Enable
+	 *	   0 = Reads Disabled
+	 *	   1 = Reads Enabled
+	 * [ 1: 1] Write Enable
+	 *	   0 = Writes Disabled
+	 *	   1 = Writes Enabled
+	 * [ 2: 2] Device Number Compare Enable
+	 *	   0 = The ranges are based on bus number
+	 *	   1 = The ranges are ranges of devices on bus 0
+	 * [ 3: 3] Reserved
+	 * [ 6: 4] Destination Node
+	 *	   000 = Node 0
+	 *	   001 = Node 1
+	 *	   010 = Node 2
+	 *	   011 = Node 3
+	 *	   100 = Node 4
+	 *	   101 = Node 5
+	 *	   110 = Node 6
+	 *	   111 = Node 7
+	 * [ 7: 7] Reserved
+	 * [ 9: 8] Destination Link
+	 *	   00 = Link 0
+	 *	   01 = Link 1
+	 *	   10 = Link 2
+	 *	   11 - Reserved
+	 * [15:10] Reserved
+	 * [23:16] Bus Number Base i
+	 *	   This field defines the lowest bus number in configuration region i
+	 * [31:24] Bus Number Limit i
+	 *	   This field defines the highest bus number in configuration regin i
+	 */
+	PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x03000203,
+	PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x05040003,
+	PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x00000000,
+	PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000,
+	};
+	int max;
+	max = sizeof(register_values)/sizeof(register_values[0]);
+	setup_resource_map(register_values, max);
+}
+
diff --exclude='*CVS*' -urN mylinuxbios/LinuxBIOS/freebios2/src/northbridge/amd/amdk8/raminit.1.c freebios2/src/northbridge/amd/amdk8/raminit.1.c
--- mylinuxbios/LinuxBIOS/freebios2/src/northbridge/amd/amdk8/raminit.1.c	2003-08-28 06:42:50.000000000 +0200
+++ freebios2/src/northbridge/amd/amdk8/raminit.1.c	1970-01-01 01:00:00.000000000 +0100
@@ -1,2308 +0,0 @@
-//Changed by LYH to be used with Tyan s2885
-#include <cpu/k8/mtrr.h>
-#include "raminit.h"
-
-/* Function 2 */
-#define DRAM_CSBASE	   0x40
-#define DRAM_CSMASK	   0x60
-#define DRAM_BANK_ADDR_MAP 0x80
-#define DRAM_TIMING_LOW	   0x88
-#define	 DTL_TCL_SHIFT	   0
-#define	 DTL_TCL_MASK	   0x7
-#define	  DTL_CL_2	   1
-#define	  DTL_CL_3	   2
-#define	  DTL_CL_2_5	   5
-#define	 DTL_TRC_SHIFT	   4
-#define	 DTL_TRC_MASK	   0xf
-#define	  DTL_TRC_BASE	   7
-#define	  DTL_TRC_MIN	   7
-#define	  DTL_TRC_MAX	   22
-#define	 DTL_TRFC_SHIFT	   8
-#define	 DTL_TRFC_MASK	   0xf
-#define	  DTL_TRFC_BASE	   9
-#define	  DTL_TRFC_MIN	   9
-#define	  DTL_TRFC_MAX	   24
-#define	 DTL_TRCD_SHIFT	   12
-#define	 DTL_TRCD_MASK	   0x7
-#define	  DTL_TRCD_BASE	   0
-#define	  DTL_TRCD_MIN	   2
-#define	  DTL_TRCD_MAX	   6
-#define	 DTL_TRRD_SHIFT	   16
-#define	 DTL_TRRD_MASK	   0x7
-#define	  DTL_TRRD_BASE	   0
-#define	  DTL_TRRD_MIN	   2
-#define	  DTL_TRRD_MAX	   4
-#define	 DTL_TRAS_SHIFT	   20
-#define	 DTL_TRAS_MASK	   0xf
-#define	  DTL_TRAS_BASE	   0
-#define	  DTL_TRAS_MIN	   5
-#define	  DTL_TRAS_MAX	   15
-#define	 DTL_TRP_SHIFT	   24
-#define	 DTL_TRP_MASK	   0x7
-#define	  DTL_TRP_BASE	   0
-#define	  DTL_TRP_MIN	   2
-#define	  DTL_TRP_MAX	   6
-#define	 DTL_TWR_SHIFT	   28
-#define	 DTL_TWR_MASK	   0x1
-#define	  DTL_TWR_BASE	   2
-#define	  DTL_TWR_MIN	   2
-#define	  DTL_TWR_MAX	   3
-#define DRAM_TIMING_HIGH   0x8c
-#define	 DTH_TWTR_SHIFT	   0
-#define	 DTH_TWTR_MASK	   0x1
-#define	  DTH_TWTR_BASE	   1
-#define	  DTH_TWTR_MIN	   1
-#define	  DTH_TWTR_MAX	   2
-#define	 DTH_TRWT_SHIFT	   4
-#define	 DTH_TRWT_MASK	   0x7
-#define	  DTH_TRWT_BASE	   1
-#define	  DTH_TRWT_MIN	   1
-#define	  DTH_TRWT_MAX	   6
-#define	 DTH_TREF_SHIFT	   8
-#define	 DTH_TREF_MASK	   0x1f
-#define	  DTH_TREF_100MHZ_4K 0x00
-#define	  DTH_TREF_133MHZ_4K 0x01
-#define	  DTH_TREF_166MHZ_4K 0x02
-#define	  DTH_TREF_200MHZ_4K 0x03
-#define	  DTH_TREF_100MHZ_8K 0x08
-#define	  DTH_TREF_133MHZ_8K 0x09
-#define	  DTH_TREF_166MHZ_8K 0x0A
-#define	  DTH_TREF_200MHZ_8K 0x0B
-#define	 DTH_TWCL_SHIFT	    20
-#define	 DTH_TWCL_MASK	    0x7
-#define	  DTH_TWCL_BASE	    1
-#define	  DTH_TWCL_MIN	    1
-#define	  DTH_TWCL_MAX	    2
-#define DRAM_CONFIG_LOW	   0x90
-#define	 DCL_DLL_Disable   (1<<0)
-#define	 DCL_D_DRV	   (1<<1)
-#define	 DCL_QFC_EN	   (1<<2)
-#define	 DCL_DisDqsHys	   (1<<3)
-#define	 DCL_DramInit	   (1<<8)
-#define	 DCL_DramEnable	   (1<<10)
-#define	 DCL_MemClrStatus  (1<<11)
-#define	 DCL_ESR	   (1<<12)
-#define	 DCL_SRS	   (1<<13)
-#define	 DCL_128BitEn	   (1<<16)
-#define	 DCL_DimmEccEn	   (1<<17)
-#define	 DCL_UnBufDimm	   (1<<18)
-#define	 DCL_32ByteEn	   (1<<19)
-#define	 DCL_x4DIMM_SHIFT  20
-#define DRAM_CONFIG_HIGH   0x94
-#define	 DCH_ASYNC_LAT_SHIFT  0
-#define	 DCH_ASYNC_LAT_MASK   0xf
-#define	  DCH_ASYNC_LAT_BASE  0
-#define	  DCH_ASYNC_LAT_MIN   0
-#define	  DCH_ASYNC_LAT_MAX   15
-#define	 DCH_RDPREAMBLE_SHIFT 8
-#define	 DCH_RDPREAMBLE_MASK  0xf
-#define	  DCH_RDPREAMBLE_BASE ((2<<1)+0) /* 2.0 ns */
-#define	  DCH_RDPREAMBLE_MIN  ((2<<1)+0) /* 2.0 ns */
-#define	  DCH_RDPREAMBLE_MAX  ((9<<1)+1) /* 9.5 ns */
-#define	 DCH_IDLE_LIMIT_SHIFT 16
-#define	 DCH_IDLE_LIMIT_MASK  0x7
-#define	  DCH_IDLE_LIMIT_0    0
-#define	  DCH_IDLE_LIMIT_4    1
-#define	  DCH_IDLE_LIMIT_8    2
-#define	  DCH_IDLE_LIMIT_16   3
-#define	  DCH_IDLE_LIMIT_32   4
-#define	  DCH_IDLE_LIMIT_64   5
-#define	  DCH_IDLE_LIMIT_128  6
-#define	  DCH_IDLE_LIMIT_256  7
-#define	 DCH_DYN_IDLE_CTR_EN (1 << 19)
-#define	 DCH_MEMCLK_SHIFT     20
-#define	 DCH_MEMCLK_MASK      0x7
-#define	  DCH_MEMCLK_100MHZ   0
-#define	  DCH_MEMCLK_133MHZ   2
-#define	  DCH_MEMCLK_166MHZ   5
-#define	  DCH_MEMCLK_200MHZ   7
-#define	 DCH_MEMCLK_VALID     (1 << 25)
-#define	 DCH_MEMCLK_EN0	      (1 << 26) 
-#define	 DCH_MEMCLK_EN1	      (1 << 27) 
-#define	 DCH_MEMCLK_EN2	      (1 << 28) 
-#define	 DCH_MEMCLK_EN3	      (1 << 29) 
-
-/* Function 3 */
-#define SCRUB_CONTROL	   0x58
-#define	  SCRUB_NONE	    0
-#define	  SCRUB_40ns	    1
-#define	  SCRUB_80ns	    2
-#define	  SCRUB_160ns	    3
-#define	  SCRUB_320ns	    4
-#define	  SCRUB_640ns	    5
-#define	  SCRUB_1_28us	    6
-#define	  SCRUB_2_56us	    7
-#define	  SCRUB_5_12us	    8
-#define	  SCRUB_10_2us	    9
-#define	  SCRUB_20_5us	   10
-#define	  SCRUB_41_0us	   11
-#define	  SCRUB_81_9us	   12
-#define	  SCRUB_163_8us	   13
-#define	  SCRUB_327_7us	   14
-#define	  SCRUB_655_4us	   15
-#define	  SCRUB_1_31ms	   16
-#define	  SCRUB_2_62ms	   17
-#define	  SCRUB_5_24ms	   18 
-#define	  SCRUB_10_49ms	   19
-#define	  SCRUB_20_97ms	   20
-#define	  SCRUB_42ms	   21
-#define	  SCRUB_84ms	   22
-#define	 SC_DRAM_SCRUB_RATE_SHFIT  0
-#define	 SC_DRAM_SCRUB_RATE_MASK   0x1f
-#define	 SC_L2_SCRUB_RATE_SHIFT	   8
-#define	 SC_L2_SCRUB_RATE_MASK	   0x1f
-#define	 SC_L1D_SCRUB_RATE_SHIFT   16
-#define	 SC_L1D_SCRUB_RATE_MASK	   0x1f
-#define SCRUB_ADDR_LOW	   0x5C
-#define SCRUB_ADDR_HIGH	   0x60
-#define NORTHBRIDGE_CAP	   0xE8
-#define	 NBCAP_128Bit	      0x0001
-#define	 NBCAP_MP	      0x0002
-#define	 NBCAP_BIG_MP	      0x0004
-#define	 NBCAP_ECC	      0x0004
-#define	 NBCAP_CHIPKILL_ECC   0x0010
-#define	 NBCAP_MEMCLK_SHIFT   5
-#define	 NBCAP_MEMCLK_MASK    3
-#define	 NBCAP_MEMCLK_100MHZ  3
-#define	 NBCAP_MEMCLK_133MHZ  2
-#define	 NBCAP_MEMCLK_166MHZ  1
-#define	 NBCAP_MEMCLK_200MHZ  0
-#define	 NBCAP_MEMCTRL	      0x0100
-
-
-static void setup_resource_map(const unsigned int *register_values, int max)
-{
-	int i;
-	print_debug("setting up resource map....\r\n");
-	for(i = 0; i < max; i += 3) {
-		device_t dev;
-		unsigned where;
-		unsigned long reg;
-#if 0
-		print_debug_hex32(register_values[i]);
-		print_debug(" <-");
-		print_debug_hex32(register_values[i+2]);
-		print_debug("\r\n");
-#endif
-		dev = register_values[i] & ~0xff;
-		where = register_values[i] & 0xff;
-		reg = pci_read_config32(dev, where);
-		reg &= register_values[i+1];
-		reg |= register_values[i+2];
-		pci_write_config32(dev, where, reg);
-#if 0
-		reg = pci_read_config32(register_values[i]);
-		reg &= register_values[i+1];
-		reg |= register_values[i+2] & ~register_values[i+1];
-		pci_write_config32(register_values[i], reg);
-#endif
-	}
-	print_debug("done.\r\n");
-}
-
-static void setup_default_resource_map(void)
-{
-	static const unsigned int register_values[] = {
-	/* Careful set limit registers before base registers which contain the enables */
-	/* DRAM Limit i Registers
-	 * F1:0x44 i = 0
-	 * F1:0x4C i = 1
-	 * F1:0x54 i = 2
-	 * F1:0x5C i = 3
-	 * F1:0x64 i = 4
-	 * F1:0x6C i = 5
-	 * F1:0x74 i = 6
-	 * F1:0x7C i = 7
-	 * [ 2: 0] Destination Node ID
-	 *	   000 = Node 0
-	 *	   001 = Node 1
-	 *	   010 = Node 2
-	 *	   011 = Node 3
-	 *	   100 = Node 4
-	 *	   101 = Node 5
-	 *	   110 = Node 6
-	 *	   111 = Node 7
-	 * [ 7: 3] Reserved
-	 * [10: 8] Interleave select
-	 *	   specifies the values of A[14:12] to use with interleave enable.
-	 * [15:11] Reserved
-	 * [31:16] DRAM Limit Address i Bits 39-24
-	 *	   This field defines the upper address bits of a 40 bit  address
-	 *	   that define the end of the DRAM region.
-	 */
-	PCI_ADDR(0, 0x18, 1, 0x44), 0x0000f8f8, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x4C), 0x0000f8f8, 0x00000001,
-	PCI_ADDR(0, 0x18, 1, 0x54), 0x0000f8f8, 0x00000002,
-	PCI_ADDR(0, 0x18, 1, 0x5C), 0x0000f8f8, 0x00000003,
-	PCI_ADDR(0, 0x18, 1, 0x64), 0x0000f8f8, 0x00000004,
-	PCI_ADDR(0, 0x18, 1, 0x6C), 0x0000f8f8, 0x00000005,
-	PCI_ADDR(0, 0x18, 1, 0x74), 0x0000f8f8, 0x00000006,
-	PCI_ADDR(0, 0x18, 1, 0x7C), 0x0000f8f8, 0x00000007,
-	/* DRAM Base i Registers
-	 * F1:0x40 i = 0
-	 * F1:0x48 i = 1
-	 * F1:0x50 i = 2
-	 * F1:0x58 i = 3
-	 * F1:0x60 i = 4
-	 * F1:0x68 i = 5
-	 * F1:0x70 i = 6
-	 * F1:0x78 i = 7
-	 * [ 0: 0] Read Enable
-	 *	   0 = Reads Disabled
-	 *	   1 = Reads Enabled
-	 * [ 1: 1] Write Enable
-	 *	   0 = Writes Disabled
-	 *	   1 = Writes Enabled
-	 * [ 7: 2] Reserved
-	 * [10: 8] Interleave Enable
-	 *	   000 = No interleave
-	 *	   001 = Interleave on A[12] (2 nodes)
-	 *	   010 = reserved
-	 *	   011 = Interleave on A[12] and A[14] (4 nodes)
-	 *	   100 = reserved
-	 *	   101 = reserved
-	 *	   110 = reserved
-	 *	   111 = Interleve on A[12] and A[13] and A[14] (8 nodes)
-	 * [15:11] Reserved
-	 * [13:16] DRAM Base Address i Bits 39-24
-	 *	   This field defines the upper address bits of a 40-bit address
-	 *	   that define the start of the DRAM region.
-	 */
-	PCI_ADDR(0, 0x18, 1, 0x40), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x48), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x50), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x58), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x60), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x68), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x70), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x78), 0x0000f8fc, 0x00000000,
-
-	/* Memory-Mapped I/O Limit i Registers
-	 * F1:0x84 i = 0
-	 * F1:0x8C i = 1
-	 * F1:0x94 i = 2
-	 * F1:0x9C i = 3
-	 * F1:0xA4 i = 4
-	 * F1:0xAC i = 5
-	 * F1:0xB4 i = 6
-	 * F1:0xBC i = 7
-	 * [ 2: 0] Destination Node ID
-	 *	   000 = Node 0
-	 *	   001 = Node 1
-	 *	   010 = Node 2
-	 *	   011 = Node 3
-	 *	   100 = Node 4
-	 *	   101 = Node 5
-	 *	   110 = Node 6
-	 *	   111 = Node 7
-	 * [ 3: 3] Reserved
-	 * [ 5: 4] Destination Link ID
-	 *	   00 = Link 0
-	 *	   01 = Link 1
-	 *	   10 = Link 2
-	 *	   11 = Reserved
-	 * [ 6: 6] Reserved
-	 * [ 7: 7] Non-Posted
-	 *	   0 = CPU writes may be posted
-	 *	   1 = CPU writes must be non-posted
-	 * [31: 8] Memory-Mapped I/O Limit Address i (39-16)
-	 *	   This field defines the upp adddress bits of a 40-bit address that
-	 *	   defines the end of a memory-mapped I/O region n
-	 */
-	PCI_ADDR(0, 0x18, 1, 0x84), 0x00000048, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x8C), 0x00000048, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x94), 0x00000048, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x9C), 0x00000048, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xA4), 0x00000048, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xAC), 0x00000048, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xB4), 0x00000048, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff20,
-
-	/* Memory-Mapped I/O Base i Registers
-	 * F1:0x80 i = 0
-	 * F1:0x88 i = 1
-	 * F1:0x90 i = 2
-	 * F1:0x98 i = 3
-	 * F1:0xA0 i = 4
-	 * F1:0xA8 i = 5
-	 * F1:0xB0 i = 6
-	 * F1:0xB8 i = 7
-	 * [ 0: 0] Read Enable
-	 *	   0 = Reads disabled
-	 *	   1 = Reads Enabled
-	 * [ 1: 1] Write Enable
-	 *	   0 = Writes disabled
-	 *	   1 = Writes Enabled
-	 * [ 2: 2] Cpu Disable
-	 *	   0 = Cpu can use this I/O range
-	 *	   1 = Cpu requests do not use this I/O range
-	 * [ 3: 3] Lock
-	 *	   0 = base/limit registers i are read/write
-	 *	   1 = base/limit registers i are read-only
-	 * [ 7: 4] Reserved
-	 * [31: 8] Memory-Mapped I/O Base Address i (39-16)
-	 *	   This field defines the upper address bits of a 40bit address 
-	 *	   that defines the start of memory-mapped I/O region i
-	 */
-	PCI_ADDR(0, 0x18, 1, 0x80), 0x000000f0, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x88), 0x000000f0, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x90), 0x000000f0, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x98), 0x000000f0, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xA0), 0x000000f0, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xA8), 0x000000f0, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xB0), 0x000000f0, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xB8), 0x000000f0, 0x00fc0003,
-
-	/* PCI I/O Limit i Registers
-	 * F1:0xC4 i = 0
-	 * F1:0xCC i = 1
-	 * F1:0xD4 i = 2
-	 * F1:0xDC i = 3
-	 * [ 2: 0] Destination Node ID
-	 *	   000 = Node 0
-	 *	   001 = Node 1
-	 *	   010 = Node 2
-	 *	   011 = Node 3
-	 *	   100 = Node 4
-	 *	   101 = Node 5
-	 *	   110 = Node 6
-	 *	   111 = Node 7
-	 * [ 3: 3] Reserved
-	 * [ 5: 4] Destination Link ID
-	 *	   00 = Link 0
-	 *	   01 = Link 1
-	 *	   10 = Link 2
-	 *	   11 = reserved
-	 * [11: 6] Reserved
-	 * [24:12] PCI I/O Limit Address i
-	 *	   This field defines the end of PCI I/O region n
-	 * [31:25] Reserved
-	 */
-	PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff020,
-	PCI_ADDR(0, 0x18, 1, 0xCC), 0xFE000FC8, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xD4), 0xFE000FC8, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xDC), 0xFE000FC8, 0x00000000,
-
-	/* PCI I/O Base i Registers
-	 * F1:0xC0 i = 0
-	 * F1:0xC8 i = 1
-	 * F1:0xD0 i = 2
-	 * F1:0xD8 i = 3
-	 * [ 0: 0] Read Enable
-	 *	   0 = Reads Disabled
-	 *	   1 = Reads Enabled
-	 * [ 1: 1] Write Enable
-	 *	   0 = Writes Disabled
-	 *	   1 = Writes Enabled
-	 * [ 3: 2] Reserved
-	 * [ 4: 4] VGA Enable
-	 *	   0 = VGA matches Disabled
-	 *	   1 = matches all address < 64K and where A[9:0] is in the 
-	 *	       range 3B0-3BB or 3C0-3DF independen of the base & limit registers
-	 * [ 5: 5] ISA Enable
-	 *	   0 = ISA matches Disabled
-	 *	   1 = Blocks address < 64K and in the last 768 bytes of eack 1K block
-	 *	       from matching agains this base/limit pair
-	 * [11: 6] Reserved
-	 * [24:12] PCI I/O Base i
-	 *	   This field defines the start of PCI I/O region n 
-	 * [31:25] Reserved
-	 */
-	PCI_ADDR(0, 0x18, 1, 0xC0), 0xFE000FCC, 0x00000003,
-	PCI_ADDR(0, 0x18, 1, 0xC8), 0xFE000FCC, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xD0), 0xFE000FCC, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xD8), 0xFE000FCC, 0x00000000,
-
-	/* Config Base and Limit i Registers
-	 * F1:0xE0 i = 0
-	 * F1:0xE4 i = 1
-	 * F1:0xE8 i = 2
-	 * F1:0xEC i = 3
-	 * [ 0: 0] Read Enable
-	 *	   0 = Reads Disabled
-	 *	   1 = Reads Enabled
-	 * [ 1: 1] Write Enable
-	 *	   0 = Writes Disabled
-	 *	   1 = Writes Enabled
-	 * [ 2: 2] Device Number Compare Enable
-	 *	   0 = The ranges are based on bus number
-	 *	   1 = The ranges are ranges of devices on bus 0
-	 * [ 3: 3] Reserved
-	 * [ 6: 4] Destination Node
-	 *	   000 = Node 0
-	 *	   001 = Node 1
-	 *	   010 = Node 2
-	 *	   011 = Node 3
-	 *	   100 = Node 4
-	 *	   101 = Node 5
-	 *	   110 = Node 6
-	 *	   111 = Node 7
-	 * [ 7: 7] Reserved
-	 * [ 9: 8] Destination Link
-	 *	   00 = Link 0
-	 *	   01 = Link 1
-	 *	   10 = Link 2
-	 *	   11 - Reserved
-	 * [15:10] Reserved
-	 * [23:16] Bus Number Base i
-	 *	   This field defines the lowest bus number in configuration region i
-	 * [31:24] Bus Number Limit i
-	 *	   This field defines the highest bus number in configuration regin i
-	 */
-	PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x03000203,
-	PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x05040003,
-	PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000,
-	};
-	int max;
-	max = sizeof(register_values)/sizeof(register_values[0]);
-	setup_resource_map(register_values, max);
-}
-
-static void sdram_set_registers(const struct mem_controller *ctrl)
-{
-	static const unsigned int register_values[] = {
-
-	/* Careful set limit registers before base registers which contain the enables */
-	/* DRAM Limit i Registers
-	 * F1:0x44 i = 0
-	 * F1:0x4C i = 1
-	 * F1:0x54 i = 2
-	 * F1:0x5C i = 3
-	 * F1:0x64 i = 4
-	 * F1:0x6C i = 5
-	 * F1:0x74 i = 6
-	 * F1:0x7C i = 7
-	 * [ 2: 0] Destination Node ID
-	 *	   000 = Node 0
-	 *	   001 = Node 1
-	 *	   010 = Node 2
-	 *	   011 = Node 3
-	 *	   100 = Node 4
-	 *	   101 = Node 5
-	 *	   110 = Node 6
-	 *	   111 = Node 7
-	 * [ 7: 3] Reserved
-	 * [10: 8] Interleave select
-	 *	   specifies the values of A[14:12] to use with interleave enable.
-	 * [15:11] Reserved
-	 * [31:16] DRAM Limit Address i Bits 39-24
-	 *	   This field defines the upper address bits of a 40 bit  address
-	 *	   that define the end of the DRAM region.
-	 */
-	PCI_ADDR(0, 0x18, 1, 0x44), 0x0000f8f8, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x4C), 0x0000f8f8, 0x00000001,
-	PCI_ADDR(0, 0x18, 1, 0x54), 0x0000f8f8, 0x00000002,
-	PCI_ADDR(0, 0x18, 1, 0x5C), 0x0000f8f8, 0x00000003,
-	PCI_ADDR(0, 0x18, 1, 0x64), 0x0000f8f8, 0x00000004,
-	PCI_ADDR(0, 0x18, 1, 0x6C), 0x0000f8f8, 0x00000005,
-	PCI_ADDR(0, 0x18, 1, 0x74), 0x0000f8f8, 0x00000006,
-	PCI_ADDR(0, 0x18, 1, 0x7C), 0x0000f8f8, 0x00000007,
-	/* DRAM Base i Registers
-	 * F1:0x40 i = 0
-	 * F1:0x48 i = 1
-	 * F1:0x50 i = 2
-	 * F1:0x58 i = 3
-	 * F1:0x60 i = 4
-	 * F1:0x68 i = 5
-	 * F1:0x70 i = 6
-	 * F1:0x78 i = 7
-	 * [ 0: 0] Read Enable
-	 *	   0 = Reads Disabled
-	 *	   1 = Reads Enabled
-	 * [ 1: 1] Write Enable
-	 *	   0 = Writes Disabled
-	 *	   1 = Writes Enabled
-	 * [ 7: 2] Reserved
-	 * [10: 8] Interleave Enable
-	 *	   000 = No interleave
-	 *	   001 = Interleave on A[12] (2 nodes)
-	 *	   010 = reserved
-	 *	   011 = Interleave on A[12] and A[14] (4 nodes)
-	 *	   100 = reserved
-	 *	   101 = reserved
-	 *	   110 = reserved
-	 *	   111 = Interleve on A[12] and A[13] and A[14] (8 nodes)
-	 * [15:11] Reserved
-	 * [13:16] DRAM Base Address i Bits 39-24
-	 *	   This field defines the upper address bits of a 40-bit address
-	 *	   that define the start of the DRAM region.
-	 */
-	PCI_ADDR(0, 0x18, 1, 0x40), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x48), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x50), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x58), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x60), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x68), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x70), 0x0000f8fc, 0x00000000,
-	PCI_ADDR(0, 0x18, 1, 0x78), 0x0000f8fc, 0x00000000,
-
-	/* DRAM CS Base Address i Registers
-	 * F2:0x40 i = 0
-	 * F2:0x44 i = 1
-	 * F2:0x48 i = 2
-	 * F2:0x4C i = 3
-	 * F2:0x50 i = 4
-	 * F2:0x54 i = 5
-	 * F2:0x58 i = 6
-	 * F2:0x5C i = 7
-	 * [ 0: 0] Chip-Select Bank Enable
-	 *	   0 = Bank Disabled
-	 *	   1 = Bank Enabled
-	 * [ 8: 1] Reserved
-	 * [15: 9] Base Address (19-13)
-	 *	   An optimization used when all DIMM are the same size...
-	 * [20:16] Reserved
-	 * [31:21] Base Address (35-25)
-	 *	   This field defines the top 11 addresses bit of a 40-bit
-	 *	   address that define the memory address space.  These
-	 *	   bits decode 32-MByte blocks of memory.
-	 */
-	PCI_ADDR(0, 0x18, 2, 0x40), 0x001f01fe, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x44), 0x001f01fe, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x48), 0x001f01fe, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x4C), 0x001f01fe, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x50), 0x001f01fe, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x54), 0x001f01fe, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x58), 0x001f01fe, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x5C), 0x001f01fe, 0x00000000,
-	/* DRAM CS Mask Address i Registers
-	 * F2:0x60 i = 0
-	 * F2:0x64 i = 1
-	 * F2:0x68 i = 2
-	 * F2:0x6C i = 3
-	 * F2:0x70 i = 4
-	 * F2:0x74 i = 5
-	 * F2:0x78 i = 6
-	 * F2:0x7C i = 7
-	 * Select bits to exclude from comparison with the DRAM Base address register.
-	 * [ 8: 0] Reserved
-	 * [15: 9] Address Mask (19-13)
-	 *	   Address to be excluded from the optimized case
-	 * [20:16] Reserved
-	 * [29:21] Address Mask (33-25)
-	 *	   The bits with an address mask of 1 are excluded from address comparison
-	 * [31:30] Reserved
-	 * 
-	 */
-	PCI_ADDR(0, 0x18, 2, 0x60), 0xC01f01ff, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x64), 0xC01f01ff, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x68), 0xC01f01ff, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x6C), 0xC01f01ff, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x70), 0xC01f01ff, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x74), 0xC01f01ff, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x78), 0xC01f01ff, 0x00000000,
-	PCI_ADDR(0, 0x18, 2, 0x7C), 0xC01f01ff, 0x00000000,
-	/* DRAM Bank Address Mapping Register
-	 * F2:0x80
-	 * Specify the memory module size
-	 * [ 2: 0] CS1/0 
-	 * [ 6: 4] CS3/2
-	 * [10: 8] CS5/4
-	 * [14:12] CS7/6
-	 *	   000 = 32Mbyte  (Rows = 12 & Col =  8)
-	 *	   001 = 64Mbyte  (Rows = 12 & Col =  9)
-	 *	   010 = 128Mbyte (Rows = 13 & Col =  9)|(Rows = 12 & Col = 10)
-	 *	   011 = 256Mbyte (Rows = 13 & Col = 10)|(Rows = 12 & Col = 11)
-	 *	   100 = 512Mbyte (Rows = 13 & Col = 11)|(Rows = 14 & Col = 10)
-	 *	   101 = 1Gbyte	  (Rows = 14 & Col = 11)|(Rows = 13 & Col = 12)
-	 *	   110 = 2Gbyte	  (Rows = 14 & Col = 12)
-	 *	   111 = reserved 
-	 * [ 3: 3] Reserved
-	 * [ 7: 7] Reserved
-	 * [11:11] Reserved
-	 * [31:15]
-	 */
-	PCI_ADDR(0, 0x18, 2, 0x80), 0xffff8888, 0x00000000,
-	/* DRAM Timing Low Register
-	 * F2:0x88
-	 * [ 2: 0] Tcl (Cas# Latency, Cas# to read-data-valid)
-	 *	   000 = reserved
-	 *	   001 = CL 2
-	 *	   010 = CL 3
-	 *	   011 = reserved
-	 *	   100 = reserved
-	 *	   101 = CL 2.5
-	 *	   110 = reserved
-	 *	   111 = reserved
-	 * [ 3: 3] Reserved
-	 * [ 7: 4] Trc (Row Cycle Time, Ras#-active to Ras#-active/bank auto refresh)
-	 *	   0000 =  7 bus clocks
-	 *	   0001 =  8 bus clocks
-	 *	   ...
-	 *	   1110 = 21 bus clocks
-	 *	   1111 = 22 bus clocks
-	 * [11: 8] Trfc (Row refresh Cycle time, Auto-refresh-active to RAS#-active or RAS#auto-refresh)
-	 *	   0000 = 9 bus clocks
-	 *	   0010 = 10 bus clocks
-	 *	   ....
-	 *	   1110 = 23 bus clocks
-	 *	   1111 = 24 bus clocks
-	 * [14:12] Trcd (Ras#-active to Case#-read/write Delay)
-	 *	   000 = reserved
-	 *	   001 = reserved
-	 *	   010 = 2 bus clocks
-	 *	   011 = 3 bus clocks
-	 *	   100 = 4 bus clocks
-	 *	   101 = 5 bus clocks
-	 *	   110 = 6 bus clocks
-	 *	   111 = reserved
-	 * [15:15] Reserved
-	 * [18:16] Trrd (Ras# to Ras# Delay)
-	 *	   000 = reserved
-	 *	   001 = reserved
-	 *	   010 = 2 bus clocks
-	 *	   011 = 3 bus clocks
-	 *	   100 = 4 bus clocks
-	 *	   101 = reserved
-	 *	   110 = reserved
-	 *	   111 = reserved
-	 * [19:19] Reserved
-	 * [23:20] Tras (Minmum Ras# Active Time)
-	 *	   0000 to 0100 = reserved
-	 *	   0101 = 5 bus clocks
-	 *	   ...
-	 *	   1111 = 15 bus clocks
-	 * [26:24] Trp (Row Precharge Time)
-	 *	   000 = reserved
-	 *	   001 = reserved
-	 *	   010 = 2 bus clocks
-	 *	   011 = 3 bus clocks
-	 *	   100 = 4 bus clocks
-	 *	   101 = 5 bus clocks
-	 *	   110 = 6 bus clocks
-	 *	   111 = reserved
-	 * [27:27] Reserved
-	 * [28:28] Twr (Write Recovery Time)
-	 *	   0 = 2 bus clocks
-	 *	   1 = 3 bus clocks
-	 * [31:29] Reserved
-	 */
-	PCI_ADDR(0, 0x18, 2, 0x88), 0xe8088008, 0x02522001 /* 0x03623125 */ ,
-	/* DRAM Timing High Register
-	 * F2:0x8C
-	 * [ 0: 0] Twtr (Write to Read Delay)
-	 *	   0 = 1 bus Clocks
-	 *	   1 = 2 bus Clocks
-	 * [ 3: 1] Reserved
-	 * [ 6: 4] Trwt (Read to Write Delay)
-	 *	   000 = 1 bus clocks
-	 *	   001 = 2 bus clocks
-	 *	   010 = 3 bus clocks
-	 *	   011 = 4 bus clocks
-	 *	   100 = 5 bus clocks
-	 *	   101 = 6 bus clocks
-	 *	   110 = reserved
-	 *	   111 = reserved
-	 * [ 7: 7] Reserved
-	 * [12: 8] Tref (Refresh Rate)
-	 *	   00000 = 100Mhz 4K rows
-	 *	   00001 = 133Mhz 4K rows
-	 *	   00010 = 166Mhz 4K rows
-	 *	   00011 = 200Mhz 4K rows
-	 *	   01000 = 100Mhz 8K/16K rows
-	 *	   01001 = 133Mhz 8K/16K rows
-	 *	   01010 = 166Mhz 8K/16K rows
-	 *	   01011 = 200Mhz 8K/16K rows
-	 * [19:13] Reserved
-	 * [22:20] Twcl (Write CAS Latency)
-	 *	   000 = 1 Mem clock after CAS# (Unbuffered Dimms)
-	 *	   001 = 2 Mem clocks after CAS# (Registered Dimms)
-	 * [31:23] Reserved
-	 */
-	PCI_ADDR(0, 0x18, 2, 0x8c), 0xff8fe08e, (0 << 20)|(0 << 8)|(0 << 4)|(0 << 0),
-	/* DRAM Config Low Register
-	 * F2:0x90
-	 * [ 0: 0] DLL Disable
-	 *	   0 = Enabled
-	 *	   1 = Disabled
-	 * [ 1: 1] D_DRV
-	 *	   0 = Normal Drive
-	 *	   1 = Weak Drive
-	 * [ 2: 2] QFC_EN
-	 *	   0 = Disabled
-	 *	   1 = Enabled
-	 * [ 3: 3] Disable DQS Hystersis  (FIXME handle this one carefully)
-	 *	   0 = Enable DQS input filter 
-	 *	   1 = Disable DQS input filtering 
-	 * [ 7: 4] Reserved
-	 * [ 8: 8] DRAM_Init
-	 *	   0 = Initialization done or not yet started.
-	 *	   1 = Initiate DRAM intialization sequence
-	 * [ 9: 9] SO-Dimm Enable
-	 *	   0 = Do nothing
-	 *	   1 = SO-Dimms present
-	 * [10:10] DramEnable
-	 *	   0 = DRAM not enabled
-	 *	   1 = DRAM initialized and enabled
-	 * [11:11] Memory Clear Status
-	 *	   0 = Memory Clear function has not completed
-	 *	   1 = Memory Clear function has completed
-	 * [12:12] Exit Self-Refresh
-	 *	   0 = Exit from self-refresh done or not yet started
-	 *	   1 = DRAM exiting from self refresh
-	 * [13:13] Self-Refresh Status
-	 *	   0 = Normal Operation
-	 *	   1 = Self-refresh mode active
-	 * [15:14] Read/Write Queue Bypass Count
-	 *	   00 = 2
-	 *	   01 = 4
-	 *	   10 = 8
-	 *	   11 = 16
-	 * [16:16] 128-bit/64-Bit
-	 *	   0 = 64bit Interface to DRAM
-	 *	   1 = 128bit Interface to DRAM
-	 * [17:17] DIMM ECC Enable
-	 *	   0 = Some DIMMs do not have ECC
-	 *	   1 = ALL DIMMS have ECC bits
-	 * [18:18] UnBuffered DIMMs
-	 *	   0 = Buffered DIMMS
-	 *	   1 = Unbuffered DIMMS
-	 * [19:19] Enable 32-Byte Granularity
-	 *	   0 = Optimize for 64byte bursts
-	 *	   1 = Optimize for 32byte bursts
-	 * [20:20] DIMM 0 is x4
-	 * [21:21] DIMM 1 is x4
-	 * [22:22] DIMM 2 is x4
-	 * [23:23] DIMM 3 is x4
-	 *	   0 = DIMM is not x4
-	 *	   1 = x4 DIMM present
-	 * [24:24] Disable DRAM Receivers
-	 *	   0 = Receivers enabled
-	 *	   1 = Receivers disabled
-	 * [27:25] Bypass Max
-	 *	   000 = Arbiters chois is always respected
-	 *	   001 = Oldest entry in DCQ can be bypassed 1 time
-	 *	   010 = Oldest entry in DCQ can be bypassed 2 times
-	 *	   011 = Oldest entry in DCQ can be bypassed 3 times
-	 *	   100 = Oldest entry in DCQ can be bypassed 4 times
-	 *	   101 = Oldest entry in DCQ can be bypassed 5 times
-	 *	   110 = Oldest entry in DCQ can be bypassed 6 times
-	 *	   111 = Oldest entry in DCQ can be bypassed 7 times
-	 * [31:28] Reserved
-	 */
-	PCI_ADDR(0, 0x18, 2, 0x90), 0xf0000000, 
-	(4 << 25)|(0 << 24)| 
-	(0 << 23)|(0 << 22)|(0 << 21)|(0 << 20)| 
-	(1 << 19)|(0 << 18)|(1 << 17)|(0 << 16)| 
-	(2 << 14)|(0 << 13)|(0 << 12)| 
-	(0 << 11)|(0 << 10)|(0 << 9)|(0 << 8)| 
-	(0 << 3) |(0 << 1) |(0 << 0),
-	/* DRAM Config High Register
-	 * F2:0x94
-	 * [ 0: 3] Maximum Asynchronous Latency
-	 *	   0000 = 0 ns
-	 *	   ...
-	 *	   1111 = 15 ns
-	 * [ 7: 4] Reserved
-	 * [11: 8] Read Preamble
-	 *	   0000 = 2.0 ns
-	 *	   0001 = 2.5 ns
-	 *	   0010 = 3.0 ns
-	 *	   0011 = 3.5 ns
-	 *	   0100 = 4.0 ns
-	 *	   0101 = 4.5 ns
-	 *	   0110 = 5.0 ns
-	 *	   0111 = 5.5 ns
-	 *	   1000 = 6.0 ns
-	 *	   1001 = 6.5 ns
-	 *	   1010 = 7.0 ns
-	 *	   1011 = 7.5 ns
-	 *	   1100 = 8.0 ns
-	 *	   1101 = 8.5 ns
-	 *	   1110 = 9.0 ns
-	 *	   1111 = 9.5 ns
-	 * [15:12] Reserved
-	 * [18:16] Idle Cycle Limit
-	 *	   000 = 0 cycles
-	 *	   001 = 4 cycles
-	 *	   010 = 8 cycles
-	 *	   011 = 16 cycles
-	 *	   100 = 32 cycles
-	 *	   101 = 64 cycles
-	 *	   110 = 128 cycles
-	 *	   111 = 256 cycles
-	 * [19:19] Dynamic Idle Cycle Center Enable
-	 *	   0 = Use Idle Cycle Limit
-	 *	   1 = Generate a dynamic Idle cycle limit
-	 * [22:20] DRAM MEMCLK Frequency
-	 *	   000 = 100Mhz
-	 *	   001 = reserved
-	 *	   010 = 133Mhz
-	 *	   011 = reserved
-	 *	   100 = reserved
-	 *	   101 = 166Mhz
-	 *	   110 = reserved
-	 *	   111 = reserved
-	 * [24:23] Reserved
-	 * [25:25] Memory Clock Ratio Valid (FIXME carefully enable memclk)
-	 *	   0 = Disable MemClks
-	 *	   1 = Enable MemClks
-	 * [26:26] Memory Clock 0 Enable
-	 *	   0 = Disabled
-	 *	   1 = Enabled
-	 * [27:27] Memory Clock 1 Enable
-	 *	   0 = Disabled
-	 *	   1 = Enabled
-	 * [28:28] Memory Clock 2 Enable
-	 *	   0 = Disabled
-	 *	   1 = Enabled
-	 * [29:29] Memory Clock 3 Enable
-	 *	   0 = Disabled
-	 *	   1 = Enabled
-	 * [31:30] Reserved
-	 */
-	PCI_ADDR(0, 0x18, 2, 0x94), 0xc180f0f0,
-	(0 << 29)|(0 << 28)|(0 << 27)|(0 << 26)|(0 << 25)|
-	(0 << 20)|(0 << 19)|(DCH_IDLE_LIMIT_16 << 16)|(0 << 8)|(0 << 0),
-	/* DRAM Delay Line Register
-	 * F2:0x98
-	 * Adjust the skew of the input DQS strobe relative to DATA
-	 * [15: 0] Reserved
-	 * [23:16] Delay Line Adjust
-	 *	   Adjusts the DLL derived PDL delay by one or more delay stages
-	 *	   in either the faster or slower direction.
-	 * [24:24} Adjust Slower
-	 *	   0 = Do Nothing
-	 *	   1 = Adj is used to increase the PDL delay
-	 * [25:25] Adjust Faster
-	 *	   0 = Do Nothing
-	 *	   1 = Adj is used to decrease the PDL delay
-	 * [31:26] Reserved
-	 */
-	PCI_ADDR(0, 0x18, 2, 0x98), 0xfc00ffff, 0x00000000,
-	/* DRAM Scrub Control Register
-	 * F3:0x58
-	 * [ 4: 0] DRAM Scrube Rate
-	 * [ 7: 5] reserved
-	 * [12: 8] L2 Scrub Rate
-	 * [15:13] reserved
-	 * [20:16] Dcache Scrub
-	 * [31:21] reserved
-	 *	   Scrub Rates
-	 *	   00000 = Do not scrub
-	 *	   00001 =  40.00 ns
-	 *	   00010 =  80.00 ns
-	 *	   00011 = 160.00 ns
-	 *	   00100 = 320.00 ns
-	 *	   00101 = 640.00 ns
-	 *	   00110 =   1.28 us
-	 *	   00111 =   2.56 us
-	 *	   01000 =   5.12 us
-	 *	   01001 =  10.20 us
-	 *	   01011 =  41.00 us
-	 *	   01100 =  81.90 us
-	 *	   01101 = 163.80 us
-	 *	   01110 = 327.70 us
-	 *	   01111 = 655.40 us
-	 *	   10000 =   1.31 ms
-	 *	   10001 =   2.62 ms
-	 *	   10010 =   5.24 ms
-	 *	   10011 =  10.49 ms
-	 *	   10100 =  20.97 ms
-	 *	   10101 =  42.00 ms
-	 *	   10110 =  84.00 ms
-	 *	   All Others = Reserved
-	 */
-	PCI_ADDR(0, 0x18, 3, 0x58), 0xffe0e0e0, 0x00000000,
-	/* DRAM Scrub Address Low Register
-	 * F3:0x5C
-	 * [ 0: 0] DRAM Scrubber Redirect Enable
-	 *	   0 = Do nothing
-	 *	   1 = Scrubber Corrects errors found in normal operation
-	 * [ 5: 1] Reserved
-	 * [31: 6] DRAM Scrub Address 31-6
-	 */
-	PCI_ADDR(0, 0x18, 3, 0x5C), 0x0000003e, 0x00000000,
-	/* DRAM Scrub Address High Register
-	 * F3:0x60
-	 * [ 7: 0] DRAM Scrubb Address 39-32
-	 * [31: 8] Reserved
-	 */
-	PCI_ADDR(0, 0x18, 3, 0x60), 0xffffff00, 0x00000000,
-/*
-//BY LYH  add IOMMU 64M APERTURE
-	PCI_ADDR(0, 0x18, 3, 0x94), 0xffff8000, 0x00000f70,
-	PCI_ADDR(0, 0x18, 3, 0x90), 0xffffff80, 0x00000002,
-	PCI_ADDR(0, 0x18, 3, 0x98), 0x0000000f, 0x00068300,
-
-//BY LYH END
-*/
-	};
-	int i;
-	int max;
-	print_debug("setting up CPU");
-	print_debug_hex8(ctrl->node_id);
-	print_debug(" northbridge registers\r\n");
-	max = sizeof(register_values)/sizeof(register_values[0]);
-	for(i = 0; i < max; i += 3) {
-		device_t dev;
-		unsigned where;
-		unsigned long reg;
-#if 0
-		print_debug_hex32(register_values[i]);
-		print_debug(" <-");
-		print_debug_hex32(register_values[i+2]);
-		print_debug("\r\n");
-#endif
-		dev = (register_values[i] & ~0xff) - PCI_DEV(0, 0x18, 0) + ctrl->f0;
-		where = register_values[i] & 0xff;
-		reg = pci_read_config32(dev, where);
-		reg &= register_values[i+1];
-		reg |= register_values[i+2];
-		pci_write_config32(dev, where, reg);
-#if 0
-
-		reg = pci_read_config32(register_values[i]);
-		reg &= register_values[i+1];
-		reg |= register_values[i+2];
-		pci_write_config32(register_values[i], reg);
-#endif
-	}
-	print_debug("done.\r\n");
-}
-
-
-static int is_dual_channel(const struct mem_controller *ctrl)
-{
-	uint32_t dcl;
-	dcl = pci_read_config32(ctrl->f2, DRAM_CONFIG_LOW);
-	return dcl & DCL_128BitEn;
-}
-
-static int is_opteron(const struct mem_controller *ctrl)
-{
-	/* Test to see if I am an Opteron.  
-	 * FIXME Testing dual channel capability is correct for now
-	 * but a beter test is probably required.
-	 */
-#warning "FIXME implement a better test for opterons"
-	uint32_t nbcap;
-	nbcap = pci_read_config32(ctrl->f3, NORTHBRIDGE_CAP);
-	return !!(nbcap & NBCAP_128Bit);
-}
-
-static int is_registered(const struct mem_controller *ctrl)
-{
-	/* Test to see if we are dealing with registered SDRAM.
-	 * If we are not registered we are unbuffered.
-	 * This function must be called after spd_handle_unbuffered_dimms.
-	 */
-	uint32_t dcl;
-	dcl = pci_read_config32(ctrl->f2, DRAM_CONFIG_LOW);
-	return !(dcl & DCL_UnBufDimm);
-}
-
-struct dimm_size {
-	unsigned long side1;
-	unsigned long side2;
-};
-
-static struct dimm_size spd_get_dimm_size(unsigned device)
-{
-	/* Calculate the log base 2 size of a DIMM in bits */
-	struct dimm_size sz;
-	int value, low;
-	sz.side1 = 0;
-	sz.side2 = 0;
-
-	/* Note it might be easier to use byte 31 here, it has the DIMM size as
-	 * a multiple of 4MB.  The way we do it now we can size both
-	 * sides of an assymetric dimm.
-	 */
-	value = spd_read_byte(device, 3);	/* rows */
-	if (value < 0) goto out;
-	sz.side1 += value & 0xf;
-
-	value = spd_read_byte(device, 4);	/* columns */
-	if (value < 0) goto out;
-	sz.side1 += value & 0xf;
-
-	value = spd_read_byte(device, 17);	/* banks */
-	if (value < 0) goto out;
-	sz.side1 += log2(value & 0xff);
-
-	/* Get the module data width and convert it to a power of two */
-	value = spd_read_byte(device, 7);	/* (high byte) */
-	if (value < 0) goto out;
-	value &= 0xff;
-	value <<= 8;
-	
-	low = spd_read_byte(device, 6);	/* (low byte) */
-	if (low < 0) goto out;
-	value = value | (low & 0xff);
-	sz.side1 += log2(value);
-
-	/* side 2 */
-	value = spd_read_byte(device, 5);	/* number of physical banks */
-	if (value <= 1) goto out;
-
-	/* Start with the symmetrical case */
-	sz.side2 = sz.side1;
-
-	value = spd_read_byte(device, 3);	/* rows */
-	if (value < 0) goto out;
-	if ((value & 0xf0) == 0) goto out;	/* If symmetrical we are done */
-	sz.side2 -= (value & 0x0f);		/* Subtract out rows on side 1 */
-	sz.side2 += ((value >> 4) & 0x0f);	/* Add in rows on side 2 */
-
-	value = spd_read_byte(device, 4);	/* columns */
-	if (value < 0) goto out;
-	sz.side2 -= (value & 0x0f);		/* Subtract out columns on side 1 */
-	sz.side2 += ((value >> 4) & 0x0f);	/* Add in columsn on side 2 */
-
- out:
-	return sz;
-}
-
-static void set_dimm_size(const struct mem_controller *ctrl, struct dimm_size sz, unsigned index)
-{
-	uint32_t base0, base1, map;
-	uint32_t dch;
-
-#if 0
-	print_debug("set_dimm_size: (");
-	print_debug_hex32(sz.side1);
-	print_debug_char(',');
-	print_debug_hex32(sz.side2);
-	print_debug_char(',');
-	print_debug_hex32(index);
-	print_debug(")\r\n");
-#endif
-	if (sz.side1 != sz.side2) {
-		sz.side2 = 0;
-	}
-	map = pci_read_config32(ctrl->f2, DRAM_BANK_ADDR_MAP);
-	map &= ~(0xf << (index + 4));
-
-	/* For each base register.
-	 * Place the dimm size in 32 MB quantities in the bits 31 - 21.
-	 * The initialize dimm size is in bits.
-	 * Set the base enable bit0.
-	 */
-	
-	base0 = base1 = 0;
-
-	/* Make certain side1 of the dimm is at least 32MB */
-	if (sz.side1 >= (25 +3)) {
-		map |= (sz.side1 - (25 + 3)) << (index *4);
-		base0 = (1 << ((sz.side1 - (25 + 3)) + 21)) | 1;
-	}
-	/* Make certain side2 of the dimm is at least 32MB */
-	if (sz.side2 >= (25 + 3)) {
-		base1 = (1 << ((sz.side2 - (25 + 3)) + 21)) | 1;
-	}
-
-	/* Double the size if we are using dual channel memory */
-	if (is_dual_channel(ctrl)) {
-		base0 = (base0 << 1) | (base0 & 1);
-		base1 = (base1 << 1) | (base1 & 1);
-	}
-
-	/* Clear the reserved bits */
-	base0 &= ~0x001ffffe;
-	base1 &= ~0x001ffffe;
-
-	/* Set the appropriate DIMM base address register */
-	pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1)+0)<<2), base0);
-	pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1)+1)<<2), base1);
-	pci_write_config32(ctrl->f2, DRAM_BANK_ADDR_MAP, map);
-	
-	/* Enable the memory clocks for this DIMM */
-	if (base0) {
-		dch = pci_read_config32(ctrl->f2, DRAM_CONFIG_HIGH);
-		dch |= DCH_MEMCLK_EN0 << index;
-		pci_write_config32(ctrl->f2, DRAM_CONFIG_HIGH, dch);
-	}
-}
-
-static void spd_set_ram_size(const struct mem_controller *ctrl)
-{
-	int i;
-	
-	for(i = 0; (i < 4) && (ctrl->channel0[i]); i++) {
-		struct dimm_size sz;
-		sz = spd_get_dimm_size(ctrl->channel0[i]);
-		set_dimm_size(ctrl, sz, i);
-	}
-}
-
-//BY LYH //Fill next base reg with right value
-static void fill_last(unsigned long node_id,unsigned long base)
-{
-        unsigned i;
-        unsigned base_reg;
-        base &=0xffff0000;
-        device_t device;
-        for(device = PCI_DEV(0, 0x18, 1); device <= PCI_DEV(0, 0x1f, 1); device
-+= PCI_DEV(0, 1, 0)) {
-                for(i=node_id+1;i<=7;i++) {
-                        base_reg=0x40+(i<<3);
-                        pci_write_config32(device,base_reg,base);
-                }
-        }
-}
-//BY LYH END
- 
-static void route_dram_accesses(const struct mem_controller *ctrl,
-	unsigned long base_k, unsigned long limit_k)
-{
-	/* Route the addresses to the controller node */
-	unsigned node_id;
-	unsigned limit;
-	unsigned base;
-	unsigned index;
-	unsigned limit_reg, base_reg;
-	device_t device;
-
-	node_id = ctrl->node_id;
-	index = (node_id << 3);
-	limit = (limit_k << 2);
-	limit &= 0xffff0000;
-	limit -= 0x00010000;
-	limit |= ( 0 << 8) | (node_id << 0);
-	base = (base_k << 2);
-	base &= 0xffff0000;
-	base |= (0 << 8) | (1<<1) | (1<<0);
-
-	limit_reg = 0x44 + index;
-	base_reg = 0x40 + index;
-	for(device = PCI_DEV(0, 0x18, 1); device <= PCI_DEV(0, 0x1f, 1); device += PCI_DEV(0, 1, 0)) {
-		pci_write_config32(device, limit_reg, limit);
-		pci_write_config32(device, base_reg, base);
-	}
-}
-
-static void set_top_mem(unsigned tom_k)
-{
-	/* Error if I don't have memory */
-	if (!tom_k) {
-		die("No memory");
-	}
-
-#if 1
-	/* Report the amount of memory. */
-	print_debug("RAM: 0x");
-	print_debug_hex32(tom_k);
-	print_debug(" KB\r\n");
-#endif
-
-	/* Now set top of memory */
-	msr_t msr;
-	msr.lo = (tom_k & 0x003fffff) << 10;
-	msr.hi = (tom_k & 0xffc00000) >> 22;
-	wrmsr(TOP_MEM2, msr);
-
-	/* Leave a 64M hole between TOP_MEM and TOP_MEM2
-	 * so I can see my rom chip and other I/O devices.
-	 */
-	if (tom_k >= 0x003f0000) {
-		tom_k = 0x3f0000;
-	}
-	msr.lo = (tom_k & 0x003fffff) << 10;
-	msr.hi = (tom_k & 0xffc00000) >> 22;
-	wrmsr(TOP_MEM, msr);
-}
-
-static void order_dimms(const struct mem_controller *ctrl)
-{
-	unsigned long tom, tom_k, base_k;
-	unsigned node_id;
-
-	/* Compute the memory base address address */
-	base_k = 0;
-	/* Remember which registers we have used in the high 8 bits of tom */
-	tom = base_k >> 15;
-	for(;;) {
-		/* Find the largest remaining canidate */
-		unsigned index, canidate;
-		uint32_t csbase, csmask;
-		unsigned size;
-		csbase = 0;
-		canidate = 0;
-		for(index = 0; index < 8; index++) {
-			uint32_t value;
-			value = pci_read_config32(ctrl->f2, DRAM_CSBASE + (index << 2));
-
-			/* Is it enabled? */
-			if (!(value & 1)) {
-				continue;
-			}
-			
-			/* Is it greater? */
-			if (value <= csbase) {
-				continue;
-			}
-			
-			/* Has it already been selected */
-			if (tom & (1 << (index + 24))) {
-				continue;
-			}
-			/* I have a new canidate */
-			csbase = value;
-			canidate = index;
-		}
-		/* See if I have found a new canidate */
-		if (csbase == 0) {
-			break;
-		}
-
-		/* Remember the dimm size */
-		size = csbase >> 21;
-
-		/* Remember I have used this register */
-		tom |= (1 << (canidate + 24));
-
-		/* Recompute the cs base register value */
-		csbase = (tom << 21) | 1;
-
-		/* Increment the top of memory */
-		tom += size;
-
-		/* Compute the memory mask */
-		csmask = ((size -1) << 21);
-		csmask |= 0xfe00;		/* For now don't optimize */
-#warning "Don't forget to optimize the DIMM size"
-
-		/* Write the new base register */
-		pci_write_config32(ctrl->f2, DRAM_CSBASE + (canidate << 2), csbase);
-		/* Write the new mask register */
-		pci_write_config32(ctrl->f2, DRAM_CSMASK + (canidate << 2), csmask);
-		
-	}
-	tom_k = (tom & ~0xff000000) << 15;
-
-	/* Compute the memory base address */
-	base_k = 0;
-	for(node_id = 0; node_id < ctrl->node_id; node_id++) {
-		uint32_t limit, base;
-		unsigned index;
-		index = node_id << 3;
-		base = pci_read_config32(ctrl->f1, 0x40 + index);
-		/* Only look at the limit if the base is enabled */
-		if ((base & 3) == 3) {
-			limit = pci_read_config32(ctrl->f1, 0x44 + index);
-			base_k = ((limit + 0x00010000) & 0xffff0000) >> 2;
-		}
-	}
-	tom_k += base_k;
-#if 0
-	print_debug("tom: ");
-	print_debug_hex32(tom);
-	print_debug(" base_k: ");
-	print_debug_hex32(base_k);
-	print_debug(" tom_k: ");
-	print_debug_hex32(tom_k);
-	print_debug("\r\n");
-#endif
-	route_dram_accesses(ctrl, base_k, tom_k);
-//BY LYH
-        fill_last(ctrl->node_id, tom_k<<2);
-//BY LYH END
-	set_top_mem(tom_k);
-}
-
-static void disable_dimm(const struct mem_controller *ctrl, unsigned index)
-{
-	print_debug("disabling dimm"); 
-	print_debug_hex8(index); 
-	print_debug("\r\n");
-	pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1)+0)<<2), 0);
-	pci_write_config32(ctrl->f2, DRAM_CSBASE + (((index << 1)+1)<<2), 0);
-}
-
-
-static void spd_handle_unbuffered_dimms(const struct mem_controller *ctrl)
-{
-	int i;
-	int registered;
-	int unbuffered;
-	uint32_t dcl;
-	unbuffered = 0;
-	registered = 0;
-	for(i = 0; (i < 4) && (ctrl->channel0[i]); i++) {
-		int value;
-		value = spd_read_byte(ctrl->channel0[i], 21);
-		if (value < 0) {
-			disable_dimm(ctrl, i);
-			continue;
-		}
-		/* Registered dimm ? */
-		if (value & (1 << 1)) {
-			registered = 1;
-		} 
-		/* Otherwise it must be an unbuffered dimm */
-		else {
-			unbuffered = 1;
-		}
-	}
-	if (unbuffered && registered) {
-		die("Mixed buffered and registered dimms not supported");
-	}
-	if (unbuffered && is_opteron(ctrl)) {
-		die("Unbuffered Dimms not supported on Opteron");
-	}
-
-	dcl = pci_read_config32(ctrl->f2, DRAM_CONFIG_LOW);
-	dcl &= ~DCL_UnBufDimm;
-	if (unbuffered) {
-		dcl |= DCL_UnBufDimm;
-	}
-	pci_write_config32(ctrl->f2, DRAM_CONFIG_LOW, dcl);
-#if 0
-	if (is_registered(ctrl)) {
-		print_debug("Registered\r\n");
-	} else {
-		print_debug("Unbuffered\r\n");
-	}
-#endif
-}
-
-static void spd_enable_2channels(const struct mem_controller *ctrl)
-{
-	int i;
-	uint32_t nbcap;
-	/* SPD addresses to verify are identical */
-#warning "FINISHME review and see if these are the bytes I need"
-	/* FINISHME review and see if these are the bytes I need */
-	static const unsigned addresses[] = {
-		2,	/* Type should be DDR SDRAM */
-		3,	/* *Row addresses */
-		4,	/* *Column addresses */
-		5,	/* *Physical Banks */
-		6,	/* *Module Data Width low */
-		7,	/* *Module Data Width high */
-		9,	/* *Cycle time at highest CAS Latency CL=X */
-		11,	/* *SDRAM Type */
-		13,	/* *SDRAM Width */
-		17,	/* *Logical Banks */
-		18,	/* *Supported CAS Latencies */
-		21,	/* *SDRAM Module Attributes */
-		23,	/* *Cycle time at CAS Latnecy (CLX - 0.5) */
-		26,	/* *Cycle time at CAS Latnecy (CLX - 1.0) */
-		27,	/* *tRP Row precharge time */
-		28,	/* *Minimum Row Active to Row Active Delay (tRRD) */
-		29,	/* *tRCD RAS to CAS */
-		30,	/* *tRAS Activate to Precharge */
-		41,	/* *Minimum Active to Active/Auto Refresh Time(Trc) */
-		42,	/* *Minimum Auto Refresh Command Time(Trfc) */
-	};
-	nbcap = pci_read_config32(ctrl->f3, NORTHBRIDGE_CAP);
-	if (!(nbcap & NBCAP_128Bit)) {
-		return;
-	}
-	for(i = 0; (i < 4) && (ctrl->channel0[i]); i++) {
-		unsigned device0, device1;
-		int value0, value1;
-		int j;
-		device0 = ctrl->channel0[i];
-		device1 = ctrl->channel1[i];
-		if (!device1)
-			return;
-		for(j = 0; j < sizeof(addresses)/sizeof(addresses[0]); j++) {
-			unsigned addr;
-			addr = addresses[j];
-			value0 = spd_read_byte(device0, addr);
-			if (value0 < 0) {
-				break;
-			}
-			value1 = spd_read_byte(device1, addr);
-			if (value1 < 0) {
-				return;
-			}
-			if (value0 != value1) {
-				return;
-			}
-		}
-	}
-	print_debug("Enabling dual channel memory\r\n");
-	uint32_t dcl;
-	dcl = pci_read_config32(ctrl->f2, DRAM_CONFIG_LOW);
-	dcl &= ~DCL_32ByteEn;
-	dcl |= DCL_128BitEn;
-	pci_write_config32(ctrl->f2, DRAM_CONFIG_LOW, dcl);
-}
-
-struct mem_param {
-	uint8_t cycle_time;
-	uint8_t divisor; /* In 1/2 ns increments */
-	uint8_t tRC;
-	uint8_t tRFC;
-	uint32_t dch_memclk;
-	uint16_t dch_tref4k, dch_tref8k;
-	uint8_t	 dtl_twr;
-	char name[9];
-};
-
-static const struct mem_param *get_mem_param(unsigned min_cycle_time)
-{
-	static const struct mem_param speed[] = {
-		{
-			.name	    = "100Mhz\r\n",
-			.cycle_time = 0xa0,
-			.divisor    = (10 <<1),
-			.tRC	    = 0x46,
-			.tRFC	    = 0x50,
-			.dch_memclk = DCH_MEMCLK_100MHZ << DCH_MEMCLK_SHIFT,
-			.dch_tref4k = DTH_TREF_100MHZ_4K,
-			.dch_tref8k = DTH_TREF_100MHZ_8K,
-			.dtl_twr    = 2,
-		},
-		{
-			.name	    = "133Mhz\r\n",
-			.cycle_time = 0x75,
-			.divisor    = (7<<1)+1,
-			.tRC	    = 0x41,
-			.tRFC	    = 0x4B,
-			.dch_memclk = DCH_MEMCLK_133MHZ << DCH_MEMCLK_SHIFT,
-			.dch_tref4k = DTH_TREF_133MHZ_4K,
-			.dch_tref8k = DTH_TREF_133MHZ_8K,
-			.dtl_twr    = 2,
-		},
-		{
-			.name	    = "166Mhz\r\n",
-			.cycle_time = 0x60,
-			.divisor    = (6<<1),
-			.tRC	    = 0x3C,
-			.tRFC	    = 0x48,
-			.dch_memclk = DCH_MEMCLK_166MHZ << DCH_MEMCLK_SHIFT,
-			.dch_tref4k = DTH_TREF_166MHZ_4K,
-			.dch_tref8k = DTH_TREF_166MHZ_8K,
-			.dtl_twr    = 3,
-		},
-		{
-			.name	    = "200Mhz\r\n",
-			.cycle_time = 0x50,
-			.divisor    = (5<<1),
-			.tRC	    = 0x37,
-			.tRFC	    = 0x46,
-			.dch_memclk = DCH_MEMCLK_200MHZ << DCH_MEMCLK_SHIFT,
-			.dch_tref4k = DTH_TREF_200MHZ_4K,
-			.dch_tref8k = DTH_TREF_200MHZ_8K,
-			.dtl_twr    = 3,
-		},
-		{
-			.cycle_time = 0x00,
-		},
-	};
-	const struct mem_param *param;
-	for(param = &speed[0]; param->cycle_time ; param++) {
-		if (min_cycle_time > (param+1)->cycle_time) {
-			break;
-		}
-	}
-	if (!param->cycle_time) {
-		die("min_cycle_time to low");
-	}
-#if 1
-	print_debug(param->name);
-#endif
-	return param;
-}
-
-static const struct mem_param *spd_set_memclk(const struct mem_controller *ctrl)
-{
-	/* Compute the minimum cycle time for these dimms */
-	const struct mem_param *param;
-	unsigned min_cycle_time, min_latency;
-	int i;
-	uint32_t value;
-
-	static const int latency_indicies[] = { 26, 23, 9 };
-	static const unsigned char min_cycle_times[] = {
-		[NBCAP_MEMCLK_200MHZ] = 0x50, /* 5ns */
-		[NBCAP_MEMCLK_166MHZ] = 0x60, /* 6ns */
-		[NBCAP_MEMCLK_133MHZ] = 0x75, /* 7.5ns */
-		[NBCAP_MEMCLK_100MHZ] = 0xa0, /* 10ns */
-	};
-
-
-	value = pci_read_config32(ctrl->f3, NORTHBRIDGE_CAP);
-	min_cycle_time = min_cycle_times[(value >> NBCAP_MEMCLK_SHIFT) & NBCAP_MEMCLK_MASK];
-	min_latency = 2;
-
-#if 0
-	print_debug("min_cycle_time: "); 
-	print_debug_hex8(min_cycle_time); 
-	print_debug(" min_latency: ");
-	print_debug_hex8(min_latency);
-	print_debug("\r\n");
-#endif
-
-	/* Compute the least latency with the fastest clock supported
-	 * by both the memory controller and the dimms.
-	 */
-	for(i = 0; (i < 4) && (ctrl->channel0[i]); i++) {
-		int new_cycle_time, new_latency;
-		int index;
-		int latencies;
-		int latency;
-
-		/* First find the supported CAS latencies
-		 * Byte 18 for DDR SDRAM is interpreted:
-		 * bit 0 == CAS Latency = 1.0
-		 * bit 1 == CAS Latency = 1.5
-		 * bit 2 == CAS Latency = 2.0
-		 * bit 3 == CAS Latency = 2.5
-		 * bit 4 == CAS Latency = 3.0
-		 * bit 5 == CAS Latency = 3.5
-		 * bit 6 == TBD
-		 * bit 7 == TBD
-		 */
-		new_cycle_time = 0xa0;
-		new_latency = 5;
-
-		latencies = spd_read_byte(ctrl->channel0[i], 18);
-		if (latencies <= 0) continue;
-
-		/* Compute the lowest cas latency supported */
-		latency = log2(latencies) -2;
-
-		/* Loop through and find a fast clock with a low latency */
-		for(index = 0; index < 3; index++, latency++) {
-			int value;
-			if ((latency < 2) || (latency > 4) ||
-				(!(latencies & (1 << latency)))) {
-				continue;
-			}
-			value = spd_read_byte(ctrl->channel0[i], latency_indicies[index]);
-			if (value < 0) {
-				continue;
-			}
-
-			/* Only increase the latency if we decreas the clock */
-			if ((value >= min_cycle_time) && (value < new_cycle_time)) {
-				new_cycle_time = value;
-				new_latency = latency;
-			}
-		}
-		if (new_latency > 4){
-			continue;
-		}
-		/* Does min_latency need to be increased? */
-		if (new_cycle_time > min_cycle_time) {
-			min_cycle_time = new_cycle_time;
-		}
-		/* Does min_cycle_time need to be increased? */
-		if (new_latency > min_latency) {
-			min_latency = new_latency;
-		}
-#if 0
-		print_debug("i: ");
-		print_debug_hex8(i);
-		print_debug(" min_cycle_time: "); 
-		print_debug_hex8(min_cycle_time); 
-		print_debug(" min_latency: ");
-		print_debug_hex8(min_latency);
-		print_debug("\r\n");
-#endif
-	}
-	/* Make a second pass through the dimms and disable
-	 * any that cannot support the selected memclk and cas latency.
-	 */
-	
-	for(i = 0; (i < 4) && (ctrl->channel0[i]); i++) {
-		int latencies;
-		int latency;
-		int index;
-		int value;
-		int dimm;
-		latencies = spd_read_byte(ctrl->channel0[i], 18);
-		if (latencies <= 0) {
-			goto dimm_err;
-		}
-
-		/* Compute the lowest cas latency supported */
-		latency = log2(latencies) -2;
-
-		/* Walk through searching for the selected latency */
-		for(index = 0; index < 3; index++, latency++) {
-			if (!(latencies & (1 << latency))) {
-				continue;
-			}
-			if (latency == min_latency)
-				break;
-		}
-		/* If I can't find the latency or my index is bad error */
-		if ((latency != min_latency) || (index >= 3)) {
-			goto dimm_err;
-		}
-		
-		/* Read the min_cycle_time for this latency */
-		value = spd_read_byte(ctrl->channel0[i], latency_indicies[index]);
-		
-		/* All is good if the selected clock speed 
-		 * is what I need or slower.
-		 */
-		if (value <= min_cycle_time) {
-			continue;
-		}
-		/* Otherwise I have an error, disable the dimm */
-	dimm_err:
-		disable_dimm(ctrl, i);
-	}
-#if 0
-	print_debug("min_cycle_time: "); 
-	print_debug_hex8(min_cycle_time); 
-	print_debug(" min_latency: ");
-	print_debug_hex8(min_latency);
-	print_debug("\r\n");
-#endif
-	/* Now that I know the minimum cycle time lookup the memory parameters */
-	param = get_mem_param(min_cycle_time);
-
-	/* Update DRAM Config High with our selected memory speed */
-	value = pci_read_config32(ctrl->f2, DRAM_CONFIG_HIGH);
-	value &= ~(DCH_MEMCLK_MASK << DCH_MEMCLK_SHIFT);
-	value |= param->dch_memclk;
-	pci_write_config32(ctrl->f2, DRAM_CONFIG_HIGH, value);
-
-	static const unsigned latencies[] = { DTL_CL_2, DTL_CL_2_5, DTL_CL_3 };
-	/* Update DRAM Timing Low with our selected cas latency */
-	value = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
-	value &= ~(DTL_TCL_MASK << DTL_TCL_SHIFT);
-	value |= latencies[min_latency - 2] << DTL_TCL_SHIFT;
-	pci_write_config32(ctrl->f2, DRAM_TIMING_LOW, value);
-	
-	return param;
-}
-
-
-static int update_dimm_Trc(const struct mem_controller *ctrl, const struct mem_param *param, int i)
-{
-	unsigned clocks, old_clocks;
-	uint32_t dtl;
-	int value;
-	value = spd_read_byte(ctrl->channel0[i], 41);
-	if (value < 0) return -1;
-	if ((value == 0) || (value == 0xff)) {
-		value = param->tRC;
-	}
-	clocks = ((value << 1) + param->divisor - 1)/param->divisor;
-	if (clocks < DTL_TRC_MIN) {
-		clocks = DTL_TRC_MIN;
-	}
-	if (clocks > DTL_TRC_MAX) {
-		return -1;
-	}
-
-	dtl = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
-	old_clocks = ((dtl >> DTL_TRC_SHIFT) & DTL_TRC_MASK) + DTL_TRC_BASE;
-	if (old_clocks > clocks) {
-		clocks = old_clocks;
-	}
-	dtl &= ~(DTL_TRC_MASK << DTL_TRC_SHIFT);
-	dtl |=	((clocks - DTL_TRC_BASE) << DTL_TRC_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_LOW, dtl);
-	return 0;
-}
-
-static int update_dimm_Trfc(const struct mem_controller *ctrl, const struct mem_param *param, int i)
-{
-	unsigned clocks, old_clocks;
-	uint32_t dtl;
-	int value;
-	value = spd_read_byte(ctrl->channel0[i], 42);
-	if (value < 0) return -1;
-	if ((value == 0) || (value == 0xff)) {
-		value = param->tRFC;
-	}
-	clocks = ((value << 1) + param->divisor - 1)/param->divisor;
-	if (clocks < DTL_TRFC_MIN) {
-		clocks = DTL_TRFC_MIN;
-	}
-	if (clocks > DTL_TRFC_MAX) {
-		return -1;
-	}
-	dtl = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
-	old_clocks = ((dtl >> DTL_TRFC_SHIFT) & DTL_TRFC_MASK) + DTL_TRFC_BASE;
-	if (old_clocks > clocks) {
-		clocks = old_clocks;
-	}
-	dtl &= ~(DTL_TRFC_MASK << DTL_TRFC_SHIFT);
-	dtl |= ((clocks - DTL_TRFC_BASE) << DTL_TRFC_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_LOW, dtl);
-	return 0;
-}
-
-
-static int update_dimm_Trcd(const struct mem_controller *ctrl, const struct mem_param *param, int i)
-{
-	unsigned clocks, old_clocks;
-	uint32_t dtl;
-	int value;
-	value = spd_read_byte(ctrl->channel0[i], 29);
-	if (value < 0) return -1;
-#if 0
-	clocks = (value + (param->divisor << 1) -1)/(param->divisor << 1);
-#else
-	clocks = (value + ((param->divisor & 0xff) << 1) -1)/((param->divisor & 0xff) << 1);
-#endif
-	if (clocks < DTL_TRCD_MIN) {
-		clocks = DTL_TRCD_MIN;
-	}
-	if (clocks > DTL_TRCD_MAX) {
-		return -1;
-	}
-	dtl = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
-	old_clocks = ((dtl >> DTL_TRCD_SHIFT) & DTL_TRCD_MASK) + DTL_TRCD_BASE;
-	if (old_clocks > clocks) {
-		clocks = old_clocks;
-	}
-	dtl &= ~(DTL_TRCD_MASK << DTL_TRCD_SHIFT);
-	dtl |= ((clocks - DTL_TRCD_BASE) << DTL_TRCD_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_LOW, dtl);
-	return 0;
-}
-
-static int update_dimm_Trrd(const struct mem_controller *ctrl, const struct mem_param *param, int i)
-{
-	unsigned clocks, old_clocks;
-	uint32_t dtl;
-	int value;
-	value = spd_read_byte(ctrl->channel0[i], 28);
-	if (value < 0) return -1;
-	clocks = (value + ((param->divisor & 0xff) << 1) -1)/((param->divisor & 0xff) << 1);
-	if (clocks < DTL_TRRD_MIN) {
-		clocks = DTL_TRRD_MIN;
-	}
-	if (clocks > DTL_TRRD_MAX) {
-		return -1;
-	}
-	dtl = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
-	old_clocks = ((dtl >> DTL_TRRD_SHIFT) & DTL_TRRD_MASK) + DTL_TRRD_BASE;
-	if (old_clocks > clocks) {
-		clocks = old_clocks;
-	}
-	dtl &= ~(DTL_TRRD_MASK << DTL_TRRD_SHIFT);
-	dtl |= ((clocks - DTL_TRRD_BASE) << DTL_TRRD_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_LOW, dtl);
-	return 0;
-}
-
-static int update_dimm_Tras(const struct mem_controller *ctrl, const struct mem_param *param, int i)
-{
-	unsigned clocks, old_clocks;
-	uint32_t dtl;
-	int value;
-	value = spd_read_byte(ctrl->channel0[i], 30);
-	if (value < 0) return -1;
-	clocks = ((value << 1) + param->divisor - 1)/param->divisor;
-	if (clocks < DTL_TRAS_MIN) {
-		clocks = DTL_TRAS_MIN;
-	}
-	if (clocks > DTL_TRAS_MAX) {
-		return -1;
-	}
-	dtl = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
-	old_clocks = ((dtl >> DTL_TRAS_SHIFT) & DTL_TRAS_MASK) + DTL_TRAS_BASE;
-	if (old_clocks > clocks) {
-		clocks = old_clocks;
-	}
-	dtl &= ~(DTL_TRAS_MASK << DTL_TRAS_SHIFT);
-	dtl |= ((clocks - DTL_TRAS_BASE) << DTL_TRAS_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_LOW, dtl);
-	return 0;
-}
-
-static int update_dimm_Trp(const struct mem_controller *ctrl, const struct mem_param *param, int i)
-{
-	unsigned clocks, old_clocks;
-	uint32_t dtl;
-	int value;
-	value = spd_read_byte(ctrl->channel0[i], 27);
-	if (value < 0) return -1;
-#if 0
-	clocks = (value + (param->divisor << 1) - 1)/(param->divisor << 1);
-#else
-	clocks = (value + ((param->divisor & 0xff) << 1) - 1)/((param->divisor & 0xff) << 1);
-#endif
-#if 0
-	print_debug("Trp: ");
-	print_debug_hex8(clocks);
-	print_debug(" spd value: ");
-	print_debug_hex8(value);
-	print_debug(" divisor: ");
-	print_debug_hex8(param->divisor);
-	print_debug("\r\n");
-#endif
-	if (clocks < DTL_TRP_MIN) {
-		clocks = DTL_TRP_MIN;
-	}
-	if (clocks > DTL_TRP_MAX) {
-		return -1;
-	}
-	dtl = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
-	old_clocks = ((dtl >> DTL_TRP_SHIFT) & DTL_TRP_MASK) + DTL_TRP_BASE;
-	if (old_clocks > clocks) {
-		clocks = old_clocks;
-	}
-	dtl &= ~(DTL_TRP_MASK << DTL_TRP_SHIFT);
-	dtl |= ((clocks - DTL_TRP_BASE) << DTL_TRP_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_LOW, dtl);
-	return 0;
-}
-
-static void set_Twr(const struct mem_controller *ctrl, const struct mem_param *param)
-{
-	uint32_t dtl;
-	dtl = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
-	dtl &= ~(DTL_TWR_MASK << DTL_TWR_SHIFT);
-	dtl |= (param->dtl_twr - DTL_TWR_BASE) << DTL_TWR_SHIFT;
-	pci_write_config32(ctrl->f2, DRAM_TIMING_LOW, dtl);
-}
-
-
-static void init_Tref(const struct mem_controller *ctrl, const struct mem_param *param)
-{
-	uint32_t dth;
-	dth = pci_read_config32(ctrl->f2, DRAM_TIMING_HIGH);
-	dth &= ~(DTH_TREF_MASK << DTH_TREF_SHIFT);
-	dth |= (param->dch_tref4k << DTH_TREF_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_HIGH, dth);
-}
-
-static int update_dimm_Tref(const struct mem_controller *ctrl, const struct mem_param *param, int i)
-{
-	uint32_t dth;
-	int value;
-	unsigned tref, old_tref;
-	value = spd_read_byte(ctrl->channel0[i], 3);
-	if (value < 0) return -1;
-	value &= 0xf;
-
-	tref = param->dch_tref8k;
-	if (value == 12) {
-		tref = param->dch_tref4k;
-	}
-
-	dth = pci_read_config32(ctrl->f2, DRAM_TIMING_HIGH);
-	old_tref = (dth >> DTH_TREF_SHIFT) & DTH_TREF_MASK;
-	if ((value == 12) && (old_tref == param->dch_tref4k)) {
-		tref = param->dch_tref4k;
-	} else {
-		tref = param->dch_tref8k;
-	}
-	dth &= ~(DTH_TREF_MASK << DTH_TREF_SHIFT);
-	dth |= (tref << DTH_TREF_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_HIGH, dth);
-	return 0;
-}
-
-
-static int update_dimm_x4(const struct mem_controller *ctrl, const struct mem_param *param, int i)
-{
-	uint32_t dcl;
-	int value;
-	int dimm;
-	value = spd_read_byte(ctrl->channel0[i], 13);
-	if (value < 0) {
-		return -1;
-	}
-	dimm = i;
-	dimm += DCL_x4DIMM_SHIFT;
-	dcl = pci_read_config32(ctrl->f2, DRAM_CONFIG_LOW);
-	dcl &= ~(1 << dimm);
-	if (value == 4) {
-		dcl |= (1 << dimm);
-	}
-	pci_write_config32(ctrl->f2, DRAM_CONFIG_LOW, dcl);
-	return 0;
-}
-
-static int update_dimm_ecc(const struct mem_controller *ctrl, const struct mem_param *param, int i)
-{
-	uint32_t dcl;
-	int value;
-	value = spd_read_byte(ctrl->channel0[i], 11);
-	if (value < 0) {
-		return -1;
-	}
-	if (value != 2) {
-		dcl = pci_read_config32(ctrl->f2, DRAM_CONFIG_LOW);
-		dcl &= ~DCL_DimmEccEn;
-		pci_write_config32(ctrl->f2, DRAM_CONFIG_LOW, dcl);
-	}
-	return 0;
-}
-
-static int count_dimms(const struct mem_controller *ctrl)
-{
-	int dimms;
-	unsigned index;
-	dimms = 0;
-	for(index = 0; index < 8; index += 2) {
-		uint32_t csbase;
-		csbase = pci_read_config32(ctrl->f2, (DRAM_CSBASE + index << 2));
-		if (csbase & 1) {
-			dimms += 1;
-		}
-	}
-	return dimms;
-}
-
-static void set_Twtr(const struct mem_controller *ctrl, const struct mem_param *param)
-{
-	uint32_t dth;
-	unsigned clocks;
-	clocks = 1; /* AMD says hard code this */
-	dth = pci_read_config32(ctrl->f2, DRAM_TIMING_HIGH);
-	dth &= ~(DTH_TWTR_MASK << DTH_TWTR_SHIFT);
-	dth |= ((clocks - DTH_TWTR_BASE) << DTH_TWTR_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_HIGH, dth);
-}
-
-static void set_Trwt(const struct mem_controller *ctrl, const struct mem_param *param)
-{
-	uint32_t dth, dtl;
-	unsigned divisor;
-	unsigned latency;
-	unsigned clocks;
-
-	clocks = 0;
-	dtl = pci_read_config32(ctrl->f2, DRAM_TIMING_LOW);
-	latency = (dtl >> DTL_TCL_SHIFT) & DTL_TCL_MASK;
-	divisor = param->divisor;
-
-	if (is_opteron(ctrl)) {
-		if (latency == DTL_CL_2) {
-			if (divisor == ((6 << 0) + 0)) {
-				/* 166Mhz */
-				clocks = 3;
-			}
-			else if (divisor > ((6 << 0)+0)) {
-				/* 100Mhz && 133Mhz */
-				clocks = 2;
-			}
-		}
-		else if (latency == DTL_CL_2_5) {
-			clocks = 3;
-		}
-		else if (latency == DTL_CL_3) {
-			if (divisor == ((6 << 0)+0)) {
-				/* 166Mhz */
-				clocks = 4;
-			}
-			else if (divisor > ((6 << 0)+0)) {
-				/* 100Mhz && 133Mhz */
-				clocks = 3;
-			}
-		}
-	}
-	else /* Athlon64 */ {
-		if (is_registered(ctrl)) {
-			if (latency == DTL_CL_2) {
-				clocks = 2;
-			}
-			else if (latency == DTL_CL_2_5) {
-				clocks = 3;
-			}
-			else if (latency == DTL_CL_3) {
-				clocks = 3;
-			}
-		}
-		else /* Unbuffered */{
-			if (latency == DTL_CL_2) {
-				clocks = 3;
-			}
-			else if (latency == DTL_CL_2_5) {
-				clocks = 4;
-			}
-			else if (latency == DTL_CL_3) {
-				clocks = 4;
-			}
-		}
-	}
-	if ((clocks < DTH_TRWT_MIN) || (clocks > DTH_TRWT_MAX)) {
-		die("Unknown Trwt");
-	}
-	
-	dth = pci_read_config32(ctrl->f2, DRAM_TIMING_HIGH);
-	dth &= ~(DTH_TRWT_MASK << DTH_TRWT_SHIFT);
-	dth |= ((clocks - DTH_TRWT_BASE) << DTH_TRWT_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_HIGH, dth);
-	return;
-}
-
-static void set_Twcl(const struct mem_controller *ctrl, const struct mem_param *param)
-{
-	/* Memory Clocks after CAS# */
-	uint32_t dth;
-	unsigned clocks;
-	if (is_registered(ctrl)) {
-		clocks = 2;
-	} else {
-		clocks = 1;
-	}
-	dth = pci_read_config32(ctrl->f2, DRAM_TIMING_HIGH);
-	dth &= ~(DTH_TWCL_MASK << DTH_TWCL_SHIFT);
-	dth |= ((clocks - DTH_TWCL_BASE) << DTH_TWCL_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_TIMING_HIGH, dth);
-}
-
-
-static void set_read_preamble(const struct mem_controller *ctrl, const struct mem_param *param)
-{
-	uint32_t dch;
-	unsigned divisor;
-	unsigned rdpreamble;
-	divisor = param->divisor;
-	dch = pci_read_config32(ctrl->f2, DRAM_CONFIG_HIGH);
-	dch &= ~(DCH_RDPREAMBLE_MASK << DCH_RDPREAMBLE_SHIFT);
-	rdpreamble = 0;
-	if (is_registered(ctrl)) {
-		if (divisor == ((10 << 1)+0)) {
-			/* 100Mhz, 9ns */
-			rdpreamble = ((9 << 1)+ 0);
-		}
-		else if (divisor == ((7 << 1)+1)) {
-			/* 133Mhz, 8ns */
-			rdpreamble = ((8 << 1)+0);
-		}
-		else if (divisor == ((6 << 1)+0)) {
-			/* 166Mhz, 7.5ns */
-			rdpreamble = ((7 << 1)+1);
-		}
-	}
-	else {
-		int slots;
-		int i;
-		slots = 0;
-		for(i = 0; i < 4; i++) {
-			if (ctrl->channel0[i]) {
-				slots += 1;
-			}
-		}
-		if (divisor == ((10 << 1)+0)) {
-			/* 100Mhz */
-			if (slots <= 2) {
-				/* 9ns */
-				rdpreamble = ((9 << 1)+0);
-			} else {
-				/* 14ns */
-				rdpreamble = ((14 << 1)+0);
-			}
-		}
-		else if (divisor == ((7 << 1)+1)) {
-			/* 133Mhz */
-			if (slots <= 2) {
-				/* 7ns */
-				rdpreamble = ((7 << 1)+0);
-			} else {
-				/* 11 ns */
-				rdpreamble = ((11 << 1)+0);
-			}
-		}
-		else if (divisor == ((6 << 1)+0)) {
-			/* 166Mhz */
-			if (slots <= 2) {
-				/* 6ns */
-				rdpreamble = ((7 << 1)+0);
-			} else {
-				/* 9ns */
-				rdpreamble = ((9 << 1)+0);
-			}
-		}
-		else if (divisor == ((5 << 1)+0)) {
-			/* 200Mhz */
-			if (slots <= 2) {
-				/* 5ns */
-				rdpreamble = ((5 << 1)+0);
-			} else {
-				/* 7ns */
-				rdpreamble = ((7 << 1)+0);
-			}
-		}
-	}
-	if ((rdpreamble < DCH_RDPREAMBLE_MIN) || (rdpreamble > DCH_RDPREAMBLE_MAX)) {
-		die("Unknown rdpreamble");
-	}
-	dch |= (rdpreamble - DCH_RDPREAMBLE_BASE) << DCH_RDPREAMBLE_SHIFT;
-	pci_write_config32(ctrl->f2, DRAM_CONFIG_HIGH, dch);
-}
-
-static void set_max_async_latency(const struct mem_controller *ctrl, const struct mem_param *param)
-{
-	uint32_t dch;
-	int i;
-	unsigned async_lat;
-	int dimms;
-
-	dimms = count_dimms(ctrl);
-
-	dch = pci_read_config32(ctrl->f2, DRAM_CONFIG_HIGH);
-	dch &= ~(DCH_ASYNC_LAT_MASK << DCH_ASYNC_LAT_SHIFT);
-	async_lat = 0;
-	if (is_registered(ctrl)) {
-		if (dimms == 4) {
-			/* 9ns */
-			async_lat = 9;
-		} 
-		else {
-			/* 8ns */
-			async_lat = 8;
-		}
-	}
-	else {
-		if (dimms > 3) {
-			die("Too many unbuffered dimms");
-		}
-		else if (dimms == 3) {
-			/* 7ns */
-			async_lat = 7;
-		}
-		else {
-			/* 6ns */
-			async_lat = 6;
-		}
-	}
-	dch |= ((async_lat - DCH_ASYNC_LAT_BASE) << DCH_ASYNC_LAT_SHIFT);
-	pci_write_config32(ctrl->f2, DRAM_CONFIG_HIGH, dch);
-}
-
-static void set_idle_cycle_limit(const struct mem_controller *ctrl, const struct mem_param *param)
-{
-	uint32_t dch;
-	/* AMD says to Hardcode this */
-	dch = pci_read_config32(ctrl->f2, DRAM_CONFIG_HIGH);
-	dch &= ~(DCH_IDLE_LIMIT_MASK << DCH_IDLE_LIMIT_SHIFT);
-	dch |= DCH_IDLE_LIMIT_16 << DCH_IDLE_LIMIT_SHIFT;
-	dch |= DCH_DYN_IDLE_CTR_EN;
-	pci_write_config32(ctrl->f2, DRAM_CONFIG_HIGH, dch);
-}
-
-static void spd_set_dram_timing(const struct mem_controller *ctrl, const struct mem_param *param)
-{
-	int dimms;
-	int i;
-	init_Tref(ctrl, param);
-	for(i = 0; (i < 4) && ctrl->channel0[i]; i++) {
-		int rc;
-		/* DRAM Timing Low Register */
-		if (update_dimm_Trc (ctrl, param, i) < 0) goto dimm_err;
-		if (update_dimm_Trfc(ctrl, param, i) < 0) goto dimm_err;
-		if (update_dimm_Trcd(ctrl, param, i) < 0) goto dimm_err;
-		if (update_dimm_Trrd(ctrl, param, i) < 0) goto dimm_err;
-		if (update_dimm_Tras(ctrl, param, i) < 0) goto dimm_err;
-		if (update_dimm_Trp (ctrl, param, i) < 0) goto dimm_err;
-
-		/* DRAM Timing High Register */
-		if (update_dimm_Tref(ctrl, param, i) < 0) goto dimm_err;
-
-		/* DRAM Config Low */
-		if (update_dimm_x4 (ctrl, param, i) < 0) goto dimm_err;
-		if (update_dimm_ecc(ctrl, param, i) < 0) goto dimm_err;
-		continue;
-	dimm_err:
-		disable_dimm(ctrl, i);
-		
-	}
-	/* DRAM Timing Low Register */
-	set_Twr(ctrl, param);
-
-	/* DRAM Timing High Register */
-	set_Twtr(ctrl, param);
-	set_Trwt(ctrl, param);
-	set_Twcl(ctrl, param);
-
-	/* DRAM Config High */
-	set_read_preamble(ctrl, param);
-	set_max_async_latency(ctrl, param);
-	set_idle_cycle_limit(ctrl, param);
-}
-
-static void sdram_set_spd_registers(const struct mem_controller *ctrl) 
-{
-	const struct mem_param *param;
-	spd_enable_2channels(ctrl);
-	spd_set_ram_size(ctrl);
-	spd_handle_unbuffered_dimms(ctrl);
-	param = spd_set_memclk(ctrl);
-	spd_set_dram_timing(ctrl, param);
-	order_dimms(ctrl);
-}
-
-#define TIMEOUT_LOOPS 300000
-static void sdram_enable(int controllers, const struct mem_controller *ctrl)
-{
-	int i;
-
-	/* Before enabling memory start the memory clocks */
-	for(i = 0; i < controllers; i++) {
-		uint32_t dch;
-		dch = pci_read_config32(ctrl[i].f2, DRAM_CONFIG_HIGH);
-		dch |= DCH_MEMCLK_VALID;
-		pci_write_config32(ctrl[i].f2, DRAM_CONFIG_HIGH, dch);
-	}
-
-	/* And if necessary toggle the the reset on the dimms by hand */
-	memreset(controllers, ctrl);
-
-	for(i = 0; i < controllers; i++) {
-		uint32_t dcl;
-		/* Toggle DisDqsHys to get it working */
-		dcl = pci_read_config32(ctrl[i].f2, DRAM_CONFIG_LOW);
-#if 0
-		print_debug("dcl: ");
-		print_debug_hex32(dcl);
-		print_debug("\r\n");
-#endif
-#warning "FIXME set the ECC type to perform"
-#warning "FIXME initialize the scrub registers"
-#if 1
-		if (dcl & DCL_DimmEccEn) {
-			print_debug("ECC enabled\r\n");
-		}
-#endif
-		dcl |= DCL_DisDqsHys;
-		pci_write_config32(ctrl[i].f2, DRAM_CONFIG_LOW, dcl);
-		dcl &= ~DCL_DisDqsHys;
-		dcl &= ~DCL_DLL_Disable;
-		dcl &= ~DCL_D_DRV;
-		dcl &= ~DCL_QFC_EN;
-		dcl |= DCL_DramInit;
-		pci_write_config32(ctrl[i].f2, DRAM_CONFIG_LOW, dcl);
-
-	}
-	for(i = 0; i < controllers; i++) {
-		uint32_t dcl;
-		print_debug("Initializing memory: ");
-		int loops = 0;
-		do {
-			dcl = pci_read_config32(ctrl[i].f2, DRAM_CONFIG_LOW);
-			loops += 1;
-			if ((loops & 1023) == 0) {
-				print_debug(".");
-			}
-		} while(((dcl & DCL_DramInit) != 0) && (loops < TIMEOUT_LOOPS));
-		if (loops >= TIMEOUT_LOOPS) {
-			print_debug(" failed\r\n");
-		} else {
-			print_debug(" done\r\n");
-		}
-#if 0
-		if (dcl & DCL_DimmEccEn) {
-			print_debug("Clearing memory: ");
-			loops = 0;
-			dcl &= ~DCL_MemClrStatus;
-			pci_write_config32(ctrl[i].f2, DRAM_CONFIG_LOW, dcl);
-			
-			do {
-				dcl = pci_read_config32(ctrl[i].f2, DRAM_CONFIG_LOW);
-				loops += 1;
-				if ((loops & 1023) == 0) {
-					print_debug(" ");
-					print_debug_hex32(loops);
-				}
-			} while(((dcl & DCL_MemClrStatus) == 0) && (loops < TIMEOUT_LOOPS));
-			if (loops >= TIMEOUT_LOOPS) {
-				print_debug("failed\r\n");
-			} else {
-				print_debug("done\r\n");
-			}
-			pci_write_config32(ctrl[i].f3, SCRUB_ADDR_LOW, 0);
-			pci_write_config32(ctrl[i].f3, SCRUB_ADDR_HIGH, 0);
-		}
-#endif
-	}
-}
diff --exclude='*CVS*' -urN mylinuxbios/LinuxBIOS/freebios2/src/northbridge/amd/amdk8/raminit.c freebios2/src/northbridge/amd/amdk8/raminit.c
--- mylinuxbios/LinuxBIOS/freebios2/src/northbridge/amd/amdk8/raminit.c	2003-08-14 11:09:06.000000000 +0200
+++ freebios2/src/northbridge/amd/amdk8/raminit.c	2003-08-28 15:24:37.000000000 +0200
@@ -919,12 +919,13 @@
 	 * [31: 8] Reserved
 	 */
 	PCI_ADDR(0, 0x18, 3, 0x60), 0xffffff00, 0x00000000,
-//BY LYH  add IOMMU 64M APERTURE
+
+#if ENABLE_IOMMU != 0
+	/* BY LYH  add IOMMU 64M APERTURE */
 	PCI_ADDR(0, 0x18, 3, 0x94), 0xffff8000, 0x00000f70,
 	PCI_ADDR(0, 0x18, 3, 0x90), 0xffffff80, 0x00000002,
 	PCI_ADDR(0, 0x18, 3, 0x98), 0x0000000f, 0x00068300,
-
-//BY LYH END
+#endif
 	};
 	int i;
 	int max;

From rminnich at lanl.gov  Thu Aug 28 09:09:17 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 28 09:09:17 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <20030828064246.GA4973@cma.co.jp>
Message-ID: <Pine.LNX.4.44.0308280725450.21778-100000@maxroach.lanl.gov>

On Thu, 28 Aug 2003, SONE Takeshi wrote:

> I found it very clever that current code puts everything below 64K
> and sets zero to all 16-bit segment registers. It simplfies the
> code a lot.

thanks :-)

> It's also worth mentioning that the current code works only
> if the "trampoline" code is also located below 64K.

oops. What do you mean by "trampoline" here? 

Do you think you could test a new vgabios.c for me?


ron



From rminnich at lanl.gov  Thu Aug 28 09:18:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 28 09:18:00 2003
Subject: Unified setup...
In-Reply-To: <20030828133427.GA12241@suse.de>
Message-ID: <Pine.LNX.4.44.0308280733130.21778-100000@maxroach.lanl.gov>

we are clearly going down the wrong path with the motherboard-specific 
changes. I mainly committed that so we could get a handle on what we 
really need. 

Yes, this type of thing should be driven from config files. I am pausing 
on changes because I want to get a better idea what Eric is up to in this 
area. 

I'll look some more at this however.

ron



From ts1 at cma.co.jp  Thu Aug 28 09:32:01 2003
From: ts1 at cma.co.jp (SONE Takeshi)
Date: Thu Aug 28 09:32:01 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <Pine.LNX.4.44.0308280725450.21778-100000@maxroach.lanl.gov>
References: <20030828064246.GA4973@cma.co.jp> <Pine.LNX.4.44.0308280725450.21778-100000@maxroach.lanl.gov>
Message-ID: <20030828134853.GA23493@cma.co.jp>

On Thu, Aug 28, 2003 at 07:26:30AM -0600, ron minnich wrote:
> > It's also worth mentioning that the current code works only
> > if the "trampoline" code is also located below 64K.
> 
> oops. What do you mean by "trampoline" here? 

32-16-32 transition in vgabios.c and 16-32-16 transition in idt.c.
The problem is that 16-bit code segment descriptor (0x28) has base address
zero and 64K limit.

(I studied these code to implement my own 32-bit legacy services
but abandoned it because vm86 starts looking inevitable...)

Perhaps we can put these functions in a special section and
modify the ld script to put this section near the beginning of image
so that these functions will be located below 64K for most cases.

> Do you think you could test a new vgabios.c for me?

Sure.
My EPIA doesn't need the fix but I can confirm the fix doesn't break it.

--
Takeshi


From rminnich at lanl.gov  Thu Aug 28 09:35:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 28 09:35:01 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <20030828134853.GA23493@cma.co.jp>
Message-ID: <Pine.LNX.4.44.0308280751240.21778-100000@maxroach.lanl.gov>

On Thu, 28 Aug 2003, SONE Takeshi wrote:

> (I studied these code to implement my own 32-bit legacy services
> but abandoned it because vm86 starts looking inevitable...)

Why not use the emulation instead, so we can support PPC etc.?

ron



From stepan at suse.de  Thu Aug 28 10:14:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Aug 28 10:14:01 2003
Subject: Unified setup...
In-Reply-To: <20030828133427.GA12241@suse.de>
References: <20030828133427.GA12241@suse.de>
Message-ID: <20030828143957.GE12241@suse.de>

Hi again,

the coherent_ht.c changes are all to LYH's hardcodes to 
coherent_ht_finalize(). These are there to setup link speed and width
on the cht nodes. 

I remember tomz from LNXI was working on that on a higher level at pci 
setup. Is that code complete by now? Are all bridges set up full speed?

Then we could just drop this code, which i would favour. Otherwise it
should walk into the motherboard specific code.

As far as I can see this code is noop anyways since speed changes need a
reset or LDTSTOP_L which is not asserted here. LYH, any comments?

--- coherent_ht.c       2003-08-14 11:11:10.000000000 +0200
+++ coherent_ht.1.c     2003-08-28 06:42:50.000000000 +0200
[..]
-        PCI_ADDR(0, 0x18, 0, 0xc4), 0x88ff9c05, 0x770000d0,
+        PCI_ADDR(0, 0x18, 0, 0xc4), 0x88ff9c05, 0x11000020,
[..]
-        PCI_ADDR(0, 0x18, 0, 0xc8), 0xfffff0ff, 0x00000000,
+        PCI_ADDR(0, 0x18, 0, 0xc8), 0xfffff0ff, 0x00000400,
[..]
-        PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00ff0000,
+        PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00050000,
[..]
-        PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00000000,
+        PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00030000,


Stefan
-- 
Architecture Team
    SuSE Linux AG


From rminnich at lanl.gov  Thu Aug 28 10:19:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 28 10:19:00 2003
Subject: Unified setup...
In-Reply-To: <20030828143957.GE12241@suse.de>
Message-ID: <Pine.LNX.4.44.0308280835200.22221-100000@maxroach.lanl.gov>

thanks stefan for cleaning this up, this is a step in the right direction. 

I think we need to drive this kind of thing out of the config tool, I'm 
still trying to get my brain wrapped around the whole thing.

ron



From stepan at suse.de  Thu Aug 28 10:25:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Aug 28 10:25:01 2003
Subject: Unified setup...
In-Reply-To: <20030828143957.GE12241@suse.de>
References: <20030828133427.GA12241@suse.de> <20030828143957.GE12241@suse.de>
Message-ID: <20030828145105.GC13287@suse.de>

* Stefan Reinauer <stepan at suse.de> [030828 16:39]:
> Then we could just drop this code, which i would favour. Otherwise it
> should walk into the motherboard specific code.
> 
> As far as I can see this code is noop anyways since speed changes need a
> reset or LDTSTOP_L which is not asserted here. LYH, any comments?
 
Plus, the code is only touching node 0. This should be done for all
nodes, if it is done...

Stefan

-- 
Architecture Team
    SuSE Linux AG


From stepan at suse.de  Thu Aug 28 10:46:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Aug 28 10:46:01 2003
Subject: Unified setup...
In-Reply-To: <20030828145105.GC13287@suse.de>
References: <20030828133427.GA12241@suse.de> <20030828143957.GE12241@suse.de> <20030828145105.GC13287@suse.de>
Message-ID: <20030828151139.GA13705@suse.de>

* Stefan Reinauer <stepan at suse.de> [030828 16:51]:
> * Stefan Reinauer <stepan at suse.de> [030828 16:39]:
> > Then we could just drop this code, which i would favour. Otherwise it
> > should walk into the motherboard specific code.
> > 
> > As far as I can see this code is noop anyways since speed changes need a
> > reset or LDTSTOP_L which is not asserted here. LYH, any comments?
>  
> Plus, the code is only touching node 0. This should be done for all
> nodes, if it is done...

I should read before writing. It does touch both CPUs. Still, it does
not check whether both CPUs are actually there. 

Stefan

-- 
Architecture Team
    SuSE Linux AG


From stepan at suse.de  Thu Aug 28 10:51:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Aug 28 10:51:01 2003
Subject: Unified setup...
In-Reply-To: <20030828143957.GE12241@suse.de>
References: <20030828133427.GA12241@suse.de> <20030828143957.GE12241@suse.de>
Message-ID: <20030828151702.GB13705@suse.de>

* Stefan Reinauer <stepan at suse.de> [030828 16:39]:
> the coherent_ht.c changes are all to LYH's hardcodes to 
> coherent_ht_finalize(). These are there to setup link speed and width
> on the cht nodes. 

Ok, I changed this bit also, getting rid of
northbridge/amd/amdk8/coherent_ht.1.c

M mainboard/amd/quartet/auto.c
M mainboard/amd/solo/auto.c
M mainboard/arima/hdama/auto.c
M mainboard/tyan/s2880/auto.c
A mainboard/tyan/s2880/hypertransport.c
M mainboard/tyan/s2882/auto.c
A mainboard/tyan/s2882/hypertransport.c
M mainboard/tyan/s2885/auto.c
A mainboard/tyan/s2885/hypertransport.c
R northbridge/amd/amdk8/coherent_ht.1.c
M northbridge/amd/amdk8/coherent_ht.c

All tyan motherboards load the hardcodes from their special
hypertransport.c now, so tyan should be happy. All other mainboards
only have a dummy function there to satisfy romcc since I don't think
that this code is actually needed.

   Stefan

-- 
Architecture Team
    SuSE Linux AG


From stepan at suse.de  Thu Aug 28 11:00:00 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Aug 28 11:00:00 2003
Subject: AMD8111_DEV
Message-ID: <20030828152540.GA13800@suse.de>

Hi,

Looking at the config variable AMD8111_DEV I find quite some strange
things:

./mainboard/amd/solo/Config:option AMD8111_DEV=0x5
./mainboard/amd/solo/Config.lb:option AMD8111_DEV=0x3800
./mainboard/amd/quartet/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2880/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2880/Config.lb:uses AMD8111_DEV
./mainboard/tyan/s2882/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2882/Config.lb:uses AMD8111_DEV
./mainboard/tyan/s2885/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2885/Config.lb:uses AMD8111_DEV
./mainboard/arima/hdama/Config:option AMD8111_DEV=0x5
./mainboard/arima/hdama/Config.lb~:option AMD8111_DEV=0x3800
./mainboard/arima/hdama/Config.lb:uses AMD8111_DEV

It seems to be 5 in some places, and 0x3800 in some obsolete places,
which makes me think that in some config files it is assumed to be
shifted whereas in others it is assumed to contain an already shifted
value.


Same thing here:

./southbridge/amd/amd8111/cmos_boot_failover.inc:       movl $(0x80000000 | AMD8111_DEV | 0x40), %eax
./southbridge/amd/amd8111/amd8111_smbus.c:#define PM_DEVFN (AMD8111_DEVFN+3)
./southbridge/amd/amd8111/smbus.inc:#define PM_DEV_FN (AMD8111_DEV + 0x300)

This should be cleaned up. Any preferences for any variant?

   Stefan

-- 
Architecture Team
    SuSE Linux AG


From YhLu at tyan.com  Thu Aug 28 12:21:01 2003
From: YhLu at tyan.com (YhLu)
Date: Thu Aug 28 12:21:01 2003
Subject: Unified setup...
Message-ID: <3174569B9743D511922F00A0C94314230318882B@TYANWEB>

Stephan,

All about the duplicate code are for the multilink etc. I think after Eric
and the code to enumerate the HT belongs to the CPU0. and make the static
links to work in chip.h and ... it will be eliminated. (auto.c and
pci_device.c and cpufixup.c may all need the static config processing code)

Regards

Yinghai Lu

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2003?8?28? 6:34
???: linuxbios at clustermatic.org
??: Unified setup...

Hi LYH, Ron and others,

I've been looking at the recent changes that went into the tree, and I
don't like the fact that a lot of code is duplicated. Is there some way
to unify this?

--- raminit.c   2003-08-28 14:43:39.000000000 +0200
+++ raminit.1.c 2003-08-28 06:42:50.000000000 +0200
[..]
-       PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff00,
+       PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff20,

This changes the link id where the southbridge is connected.
We can get this information out of the configuration file since we
are able to describe a map of all CHT components.
On most machines the southbridge is probably connected to LDT0, but
having two files for this one setting seems inappropriate.
Ron, what is the easiest way of getting this information from the
config file?

LYH: To get this unified again, I added a resourcemap.c file to the
s2885 directory that contains the resource map of the 2885. In auto.c
this is used instead of the default.

-       PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff000,
+       PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff020,

same as above.

-       PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0xff000003,
-       PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000000,
+       PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x03000203,
+       PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x05040003,

These change the bus numbers and read/write enables. How can we write
these more general?

+/*
 //BY LYH  add IOMMU 64M APERTURE
        PCI_ADDR(0, 0x18, 3, 0x94), 0xffff8000, 0x00000f70,
        PCI_ADDR(0, 0x18, 3, 0x90), 0xffffff80, 0x00000002,
        PCI_ADDR(0, 0x18, 3, 0x98), 0x0000000f, 0x00068300,
 
 //BY LYH END
+*/

I added a configuration variable ENABLE_IOMMU and set it to 1 for all
existing boards except the s2885. It would be nice to have the size of
the aperture also selectable via the configuration file, or even better 
during firmware run time. 

I am scared that changes for special motherboards will contaminate the
source tree and make it hard for anyone to see what is actually going
on. If this happens in a source tree for a special motherboard, it does
not really matter, but I think it is a good goal to keep the generic
code clean and generic and make it even more generic in the places where
it's not sufficient.

I'll look into coherent_ht.1.c and see if this can be done more general
as well.

I commited the attached patch. Please comment.

Stefan

-- 
Architecture Team
    SuSE Linux AG


From YhLu at tyan.com  Thu Aug 28 13:42:00 2003
From: YhLu at tyan.com (YhLu)
Date: Thu Aug 28 13:42:00 2003
Subject: =?gb2312?B?tPC4tDogQU1EODExMV9ERVY=?=
Message-ID: <3174569B9743D511922F00A0C94314230318884B@TYANWEB>

These three files seems should be removed and the AMD8111_DEV should be
removed too.

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2003?8?28? 8:26
???: linuxbios at clustermatic.org
??: AMD8111_DEV

Hi,

Looking at the config variable AMD8111_DEV I find quite some strange
things:

./mainboard/amd/solo/Config:option AMD8111_DEV=0x5
./mainboard/amd/solo/Config.lb:option AMD8111_DEV=0x3800
./mainboard/amd/quartet/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2880/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2880/Config.lb:uses AMD8111_DEV
./mainboard/tyan/s2882/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2882/Config.lb:uses AMD8111_DEV
./mainboard/tyan/s2885/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2885/Config.lb:uses AMD8111_DEV
./mainboard/arima/hdama/Config:option AMD8111_DEV=0x5
./mainboard/arima/hdama/Config.lb~:option AMD8111_DEV=0x3800
./mainboard/arima/hdama/Config.lb:uses AMD8111_DEV

It seems to be 5 in some places, and 0x3800 in some obsolete places,
which makes me think that in some config files it is assumed to be
shifted whereas in others it is assumed to contain an already shifted
value.


Same thing here:

./southbridge/amd/amd8111/cmos_boot_failover.inc:       movl $(0x80000000 |
AMD8111_DEV | 0x40), %eax
./southbridge/amd/amd8111/amd8111_smbus.c:#define PM_DEVFN (AMD8111_DEVFN+3)
./southbridge/amd/amd8111/smbus.inc:#define PM_DEV_FN (AMD8111_DEV + 0x300)

This should be cleaned up. Any preferences for any variant?

   Stefan

-- 
Architecture Team
    SuSE Linux AG
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Thu Aug 28 15:30:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Thu Aug 28 15:30:01 2003
Subject: AMD8111_DEV
In-Reply-To: <20030828152540.GA13800@suse.de>
Message-ID: <Pine.LNX.4.44.0308281345270.24071-100000@maxroach.lanl.gov>

On Thu, 28 Aug 2003, Stefan Reinauer wrote:

> ./mainboard/amd/solo/Config:option AMD8111_DEV=0x5

if the name is DEV, it should be a device number, not a devfn. If it is a 
device number, it shouldn't be shifted -- that's very confusing for 
people. It should be the device number that lspci shows.

So I prefer 5, and it gets shifted in the macros.

ron



From YhLu at tyan.com  Thu Aug 28 17:21:01 2003
From: YhLu at tyan.com (YhLu)
Date: Thu Aug 28 17:21:01 2003
Subject: Unified setup...
Message-ID: <3174569B9743D511922F00A0C94314230318888C@TYANWEB>

Stephan,

I have checked the AMD sheet, and you are right it will not change to
setting width and speed without reset or LDTSTOP_L.
In the pci_device.c, there is some code about HT.
I have removed the hardcode about width and speed and do some test, after I
checked the REG, and it seems width is set right but the speed is not right.
Maybe Eric need to check that part.

PS: 
-        PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00ff0000,
+        PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00050000,
[..]
-        PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00000000,
+        PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00030000,

should be there. It defines the bus number behind the links. It will be used
when enumerating the non-coherent devices.

Regards

YH


-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2003?8?28? 7:40
???: linuxbios at clustermatic.org
??: Re: Unified setup...

Hi again,

the coherent_ht.c changes are all to LYH's hardcodes to 
coherent_ht_finalize(). These are there to setup link speed and width
on the cht nodes. 

I remember tomz from LNXI was working on that on a higher level at pci 
setup. Is that code complete by now? Are all bridges set up full speed?

Then we could just drop this code, which i would favour. Otherwise it
should walk into the motherboard specific code.

As far as I can see this code is noop anyways since speed changes need a
reset or LDTSTOP_L which is not asserted here. LYH, any comments?

--- coherent_ht.c       2003-08-14 11:11:10.000000000 +0200
+++ coherent_ht.1.c     2003-08-28 06:42:50.000000000 +0200
[..]
-        PCI_ADDR(0, 0x18, 0, 0xc4), 0x88ff9c05, 0x770000d0,
+        PCI_ADDR(0, 0x18, 0, 0xc4), 0x88ff9c05, 0x11000020,
[..]
-        PCI_ADDR(0, 0x18, 0, 0xc8), 0xfffff0ff, 0x00000000,
+        PCI_ADDR(0, 0x18, 0, 0xc8), 0xfffff0ff, 0x00000400,
[..]
-        PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00ff0000,
+        PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00050000,
[..]
-        PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00000000,
+        PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00030000,


Stefan
-- 
Architecture Team
    SuSE Linux AG
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From steve at nexpath.com  Thu Aug 28 22:29:01 2003
From: steve at nexpath.com (Steve Gehlbach)
Date: Thu Aug 28 22:29:01 2003
Subject: Via CLE266
In-Reply-To: <3174569B9743D511922F00A0C94314230318888C@TYANWEB>
References: <3174569B9743D511922F00A0C94314230318888C@TYANWEB>
Message-ID: <3F4EBEB1.5030507@nexpath.com>

This guy has RE'd the cle266 mpeg library.  I wonder if there is any
useful info for linuxbios.  Pretty impressive work.

http://www.ivor.it/cle266/

-Steve



From ts1 at cma.co.jp  Fri Aug 29 05:55:00 2003
From: ts1 at cma.co.jp (SONE Takeshi)
Date: Fri Aug 29 05:55:00 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <Pine.LNX.4.44.0308280751240.21778-100000@maxroach.lanl.gov>
References: <20030828134853.GA23493@cma.co.jp> <Pine.LNX.4.44.0308280751240.21778-100000@maxroach.lanl.gov>
Message-ID: <20030829101223.GA11725@cma.co.jp>

On Thu, Aug 28, 2003 at 07:51:41AM -0600, ron minnich wrote:
> On Thu, 28 Aug 2003, SONE Takeshi wrote:
> 
> > (I studied these code to implement my own 32-bit legacy services
> > but abandoned it because vm86 starts looking inevitable...)
> 
> Why not use the emulation instead, so we can support PPC etc.?

I'm interested in more complete PCBIOS functionality, like ADLO,
rather than something just for running option ROMs. 
(Running LILO in an emulator wouldn't be really useful!)

I'm thinking on possibility of implementing BIOS *services* in
real mode, and initialization (POST), including option ROM 
handling, in 32-bit.

Services can be written in normal C. They will be built into a realmode
SystemBIOS image when built for x86, and for non-x86, they will be
compiled natively and linked together with x86 emulator.
Only entry/exit routines (to/from 16-bit code, eg. VGABIOS) will
make the difference.

--
Takeshi


From stepan at suse.de  Fri Aug 29 07:30:01 2003
From: stepan at suse.de (Stefan Reinauer)
Date: Fri Aug 29 07:30:01 2003
Subject: Unified setup...
In-Reply-To: <3174569B9743D511922F00A0C94314230318888C@TYANWEB>; from YhLu@tyan.com on Thu, Aug 28, 2003 at 02:36:32PM -0700
References: <3174569B9743D511922F00A0C94314230318888C@TYANWEB>
Message-ID: <20030829134740.B4110@suse.de>

* YhLu <YhLu at tyan.com> [030828 23:36]:
> PS: 
> -        PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00ff0000,
> +        PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00050000,
> [..]
> -        PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00000000,
> +        PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00030000,
> 
> should be there. It defines the bus number behind the links. It will be used
> when enumerating the non-coherent devices.

I agree. But maybe we find a nicer way of describing this.

Are these "hard coded" in hardware? 
The motherboard configuration should then probably contain a busnumber
value for each ht bridge that implements a pci bus

southbridge amd/amd8131 "amd8131"
        register "bus0" = "5"
end

southbridge amd/amd8151 "amd8151"
        register "bus0" = "3"
end

Or should this be handled distinct from the bridges with 
options like
option BUS1=99
option BUS2=5
?


Stefan

-- 
Architecture Team
    SuSE Linux AG


From rminnich at lanl.gov  Fri Aug 29 09:56:01 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 29 09:56:01 2003
Subject: about VGA support in voyager2 board
In-Reply-To: <20030829101223.GA11725@cma.co.jp>
Message-ID: <Pine.LNX.4.44.0308290812240.31174-100000@maxroach.lanl.gov>

On Fri, 29 Aug 2003, SONE Takeshi wrote:

> Services can be written in normal C. They will be built into a realmode
> SystemBIOS image when built for x86, and for non-x86, they will be
> compiled natively and linked together with x86 emulator.
> Only entry/exit routines (to/from 16-bit code, eg. VGABIOS) will
> make the difference.

OK, for the emulation you might want to look at util/vgabios. 

ron



From rminnich at lanl.gov  Fri Aug 29 09:58:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Fri Aug 29 09:58:00 2003
Subject: Unified setup...
In-Reply-To: <20030829134740.B4110@suse.de>
Message-ID: <Pine.LNX.4.44.0308290815290.31174-100000@maxroach.lanl.gov>

On Fri, 29 Aug 2003, Stefan Reinauer wrote:

> southbridge amd/amd8131 "amd8131"
>         register "bus0" = "5"
> end

yes.

ron



From ebiederman at lnxi.com  Sat Aug 30 00:46:01 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Aug 30 00:46:01 2003
Subject: =?gb2312?b?tPC4tA==?=: AMD8111_DEV
In-Reply-To: <3174569B9743D511922F00A0C94314230318884B@TYANWEB>
References: <3174569B9743D511922F00A0C94314230318884B@TYANWEB>
Message-ID: <m3y8xb7mtr.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> These three files seems should be removed and the AMD8111_DEV should be
> removed too.

The definition should be removed as should the files using it.  It
is a left over from code converted from the freebios1 tree, and it
currently dead code.

Eric



From root at hamburg.de  Sat Aug 30 11:23:01 2003
From: root at hamburg.de (Felix Kloeckner)
Date: Sat Aug 30 11:23:01 2003
Subject: hdd register and dma
Message-ID: <20030830173722.A13733@synapse.pentanet>

hello,
i am booting linuxbios from compatchflash and skip initialization of my additional hdd for faster booting
(using kernel-commandline-argument "hdc=none"). after the system is up I register the hdd using

#hdparm -R 0x170 0x376 15 /dev/hda

everything works fine, except after enabling the drive this way I can't put it into dma mode,
hdparm produces error like this:

# hdparm -d1 /dev/hdc

/dev/hdc:
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Operation not permitted
 using_dma    =  0 (off)


I am using elitegroup/p6stp-fl, sis630, sis5513 as IDE-controller

any idea


ps.:
Bari Ari,
did you find any solution to your "ide-hotswap" problem, please let me know!

thanks
	Felix Kloeckner


From ebiederman at lnxi.com  Sat Aug 30 13:10:00 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Aug 30 13:10:00 2003
Subject: Infrastructure status....
Message-ID: <m34qzzqcbu.fsf@maxwell.lnxi.com>

I have been working on merging the static and dynamic device
trees, and I finally have a working version.  The hard
part was that I was enumerating hypertransport first thing
and that was new code so any bug there and nothing looked like
it was working.

I have just a little bit more to finish up my initial superio
example and then I plan on committing the code.

I have had to extend the dynamic device tree in a couple of
ways to get this far.

Unless someone has some objects my plan is to tag the tree so it is
possible to look back and then commit everything.

There are lots of places where I am certain things can be done
better but the code is far enough along to be useful.  Which
means it is now safe to put more eyes on the code and see how
things are going.

Eric



From rminnich at lanl.gov  Sat Aug 30 15:54:00 2003
From: rminnich at lanl.gov (ron minnich)
Date: Sat Aug 30 15:54:00 2003
Subject: Infrastructure status....
In-Reply-To: <m34qzzqcbu.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0308301411160.11491-100000@maxroach.lanl.gov>

thanks, Eric, good to hear. 

now the real fun begins :-)

ron



From bari at onelabs.com  Sat Aug 30 22:02:01 2003
From: bari at onelabs.com (Bari Ari)
Date: Sat Aug 30 22:02:01 2003
Subject: hdd register and dma
In-Reply-To: <20030830173722.A13733@synapse.pentanet>
References: <20030830173722.A13733@synapse.pentanet>
Message-ID: <3F515B50.5050500@onelabs.com>

Felix Kloeckner wrote:

>ps.:
>Bari Ari,
>did you find any solution to your "ide-hotswap" problem, please let me know!
>  
>

I think you should be asking Jeremy. It was his problem.

"Jeremy Jackson wrote:

The second issue is the ability to tri-state off the bus, but I can find 
that info elsewhere (ie kernel source)  The hdparm utility/kernel driver 
has the beginnings of this support. "

-Bari