From rminnich at lanl.gov  Mon Aug  1 03:27:42 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Sun, 31 Jul 2005 19:27:42 -0600 (MDT)
Subject: [LinuxBIOS] Potential copyright issues with decompiling ACPI
	tables?
In-Reply-To: <20050731094623.61e7600d@absurd>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
	<20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>
	<20050731094623.61e7600d@absurd>
Message-ID: <Pine.LNX.4.58.0507311927210.21749@enigma.lanl.gov>



On Sun, 31 Jul 2005, Janek Kozicki wrote:

> > Facts can't be copyrighted. But it's not easy to use that to convince
> > someone to stop labeling a fact as being copyrighted.
> 
> but current linux kernel has to decompile ACPI tables too, right? and BSD also?

sure it does. Now what happens if it decompiles tables and mails them to 
world, I just don't know. 

ron



From GBu at lem.com  Mon Aug  1 16:01:50 2005
From: GBu at lem.com (Gernot Butschek)
Date: Mon, 1 Aug 2005 16:01:50 +0200
Subject: [LinuxBIOS] Gernot Butschek/LNO/LEM is out of the office.
Message-ID: <OFAE550BFC.9A4D6BBF-ONC1257050.004D128E-C1257050.004D128E@lem.com>

I will be out of the office starting  01.08.2005 and will not return until
09.08.2005.

I will respond to your message when I return.




From rminnich at lanl.gov  Tue Aug  2 22:31:16 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue, 2 Aug 2005 14:31:16 -0600 (MDT)
Subject: [LinuxBIOS] Mark your calendars for the first linuxbios summit
Message-ID: <Pine.LNX.4.58.0508021426300.26913@enigma.lanl.gov>

Just hold these dates: october 11-13, 2005

We've arranged for the lacsi symposium, in santa fe:  
http://lacsi.rice.edu/symposium/ to set up 2.5 days for a linuxbios
summit. The info on the linuxbios track, hotels, etc. should be on that
web page later today or tomorrow. We hope to have vendor talks, and
discussions on where we as a community are going with linuxbios.

The time of year is nice in santa fe, new mexico is beautiful, the food is
great, the hotel is very pleasant: do consider coming! We'd like to see 
all of you folks out here. 

Vendors on this list, if you have something you'd like to talk about, 
please get back to me.

thanks

ron



From noodles at earth.li  Tue Aug  2 23:40:12 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Tue, 2 Aug 2005 22:40:12 +0100
Subject: [LinuxBIOS] Submitting patches / getting svn commit access?
Message-ID: <20050802214012.GA12895@earth.li>

I've started looking at moving my EPIA-M patches over to the new svn
trunk from my arch repo. However, rather than end up with one huge patch
at the end that needs committed I figure it'd be better to submit
patches as I go along; makes it easier for me to track mainline and also
for anyone else to pickup from where I've got to.

So, what's the best way for me to submit patches, or is there any way I
can get commit access to check in things myself?

J.

-- 
Do you know any phreaks who carry around their own trunks.



From yinghailu at gmail.com  Tue Aug  2 23:46:42 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 2 Aug 2005 14:46:42 -0700
Subject: [LinuxBIOS] Mark your calendars for the first linuxbios summit
In-Reply-To: <Pine.LNX.4.58.0508021426300.26913@enigma.lanl.gov>
References: <Pine.LNX.4.58.0508021426300.26913@enigma.lanl.gov>
Message-ID: <2ea3fae105080214461d967fb1@mail.gmail.com>

I'm little comfused about linuxbios summit with lacsi symposium.

So linuxbios summit will be a session of lacsi symposium?

or I must register to lacsi symposium?

YH

On 8/2/05, Ronald G. Minnich <rminnich at lanl.gov> wrote:
> Just hold these dates: october 11-13, 2005
> 
> We've arranged for the lacsi symposium, in santa fe:
> http://lacsi.rice.edu/symposium/ to set up 2.5 days for a linuxbios
> summit. The info on the linuxbios track, hotels, etc. should be on that
> web page later today or tomorrow. We hope to have vendor talks, and
> discussions on where we as a community are going with linuxbios.
> 
> The time of year is nice in santa fe, new mexico is beautiful, the food is
> great, the hotel is very pleasant: do consider coming! We'd like to see
> all of you folks out here.
> 
> Vendors on this list, if you have something you'd like to talk about,
> please get back to me.
> 
> thanks
> 
> ron
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From rminnich at lanl.gov  Tue Aug  2 23:55:47 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue, 2 Aug 2005 15:55:47 -0600 (MDT)
Subject: [LinuxBIOS] Mark your calendars for the first linuxbios summit
In-Reply-To: <2ea3fae105080214461d967fb1@mail.gmail.com>
References: <Pine.LNX.4.58.0508021426300.26913@enigma.lanl.gov>
	<2ea3fae105080214461d967fb1@mail.gmail.com>
Message-ID: <Pine.LNX.4.58.0508021554590.26913@enigma.lanl.gov>



On Tue, 2 Aug 2005, yhlu wrote:

> I'm little comfused about linuxbios summit with lacsi symposium.
> 
> So linuxbios summit will be a session of lacsi symposium?

co-located, same place, same time, same bureaucracy, just register, but 
hold on until it mentions linuxbios on there so you can check the box.

It's saving us lots of work to do it this way ...

And you will just register for lacsi symposium.

ron



From rminnich at lanl.gov  Wed Aug  3 00:02:55 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue, 2 Aug 2005 16:02:55 -0600 (MDT)
Subject: [LinuxBIOS] Mark your calendars for the first linuxbios summit
In-Reply-To: <Pine.LNX.4.58.0508021554590.26913@enigma.lanl.gov>
References: <Pine.LNX.4.58.0508021426300.26913@enigma.lanl.gov>
	<2ea3fae105080214461d967fb1@mail.gmail.com>
	<Pine.LNX.4.58.0508021554590.26913@enigma.lanl.gov>
Message-ID: <Pine.LNX.4.58.0508021602410.26913@enigma.lanl.gov>

oh, and, by appearing at LACSI, if you want, you can meet some real 
supercomputing dudes.

ron




From okajima at digitalinfra.co.jp  Wed Aug  3 04:59:20 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Wed, 03 Aug 2005 11:59:20 +0900
Subject: [LinuxBIOS] BIOS Saver RD1
Message-ID: <200508030259.AA00208@bbb-jz5c7z9hn9y.digitalinfra.co.jp>



Hello.

Probably, most guys here use BIOS Saver.
And it works well?
In mine, RD1 for PLCC gets not being writable suddenly.
I mean, it seems writable but # flash_rom -v fails.
I solved this problem by a quick hack.


How about yours? You can write RD1 or W49F002U well?
Any problem happen?

BTW, a cable of your RD1 is not broken?
I needed soldering to fix it.

     --- Okajima.




From rminnich at lanl.gov  Wed Aug  3 05:27:15 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Tue, 2 Aug 2005 21:27:15 -0600 (MDT)
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <200508030259.AA00208@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200508030259.AA00208@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <Pine.LNX.4.58.0508022127030.27503@enigma.lanl.gov>

I don't use bios saver, but I have heard it is very nice.

ron




From stepan at openbios.org  Wed Aug  3 10:29:20 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 3 Aug 2005 10:29:20 +0200
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <200508030259.AA00208@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200508030259.AA00208@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <20050803082920.GA27303@openbios.org>

* Jun OKAJIMA <okajima at digitalinfra.co.jp> [050803 04:59]:
> In mine, RD1 for PLCC gets not being writable suddenly.
> I mean, it seems writable but # flash_rom -v fails.
> I solved this problem by a quick hack.
 
Can you describe this quick hack?
 
> BTW, a cable of your RD1 is not broken?
> I needed soldering to fix it.

Is it "flawed by design", or did you get a defective one?

Stefan 





From noodles at earth.li  Wed Aug  3 10:36:40 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Wed, 3 Aug 2005 09:36:40 +0100
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <200508030259.AA00208@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200508030259.AA00208@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <20050803083640.GB12895@earth.li>

On Wed, Aug 03, 2005 at 11:59:20AM +0900, Jun OKAJIMA wrote:
> Probably, most guys here use BIOS Saver.
> And it works well?
> In mine, RD1 for PLCC gets not being writable suddenly.
> I mean, it seems writable but # flash_rom -v fails.
> I solved this problem by a quick hack.
> 
> How about yours? You can write RD1 or W49F002U well?
> Any problem happen?

I had to patch util/flash_and_burn/w49f002u.c:

@@ -42,7 +42,7 @@
        erase_chip_jedec(flash);
 
        printf("Programming Page: ");
-       for (i = 0; i < total_size; i++) {
+       for (i = 0; i < total_size / page_size; i++) {

Even after that it's sometimes a bit flakey and I have to erase, then
write it. I've put the board's original BIOS in the RD1 and am writing
to the SST 39SF020A instead, which works without problems.

I also tried to add Atmel AT49F002 support to flash_rom, which according
to the data sheet should be very like the W49F002U. However I couldn't
get it reliably working.

> BTW, a cable of your RD1 is not broken?
> I needed soldering to fix it.

Mine was fine out of the box.

J.

-- 
  "Hex Dump" - Where Witches put   |  .''`.  Debian GNU/Linux Developer
           used Curses?            | : :' :  Happy to accept PGP signed
                                   | `. `'   or encrypted mail - RSA +
                                   |   `-    DSA keys on the keyservers.



From noodles at earth.li  Wed Aug  3 17:08:29 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Wed, 3 Aug 2005 16:08:29 +0100
Subject: [LinuxBIOS] romcc / GCC4 fix.
Message-ID: <20050803150829.GO12895@earth.li>

I've found that since Debian upgraded the default GCC to 4 romcc doesn't
compile any more. The attached trivial patch fixes this. I don't see how
it could break anything, but let me know if you can see any issues with
it.

J.

-- 
If I want to hear the pitter patter of little feet, I'll put shoes on
my cats.
-------------- next part --------------
diff -ruN LinuxBIOSv2.01/util/romcc/romcc.c LinuxBIOSv2.02/util/romcc/romcc.c
--- LinuxBIOSv2.01/util/romcc/romcc.c	2005-08-03 15:13:50.376453000 +0100
+++ LinuxBIOSv2.02/util/romcc/romcc.c	2005-08-03 15:59:44.360566500 +0100
@@ -1301,7 +1301,10 @@
 	struct compile_state *state, struct triple *ins);
 static struct triple *flatten(
 	struct compile_state *state, struct triple *first, struct triple *ptr);
-
+static void print_dominators(struct compile_state *state,
+	FILE *fp, struct basic_blocks *bb);
+static void print_dominance_frontiers(struct compile_state *state,
+	FILE *fp, struct basic_blocks *bb);
 
 
 
@@ -15293,8 +15296,6 @@
 }
 static void print_blocks(struct compile_state *state, const char *func, FILE *fp)
 {
-	static void print_dominators(struct compile_state *state, FILE *fp, struct basic_blocks *bb);
-	static void print_dominance_frontiers(struct compile_state *state, FILE *fp, struct basic_blocks *bb);
 	if (state->compiler->debug & DEBUG_BASIC_BLOCKS) {
 		fprintf(fp, "After %s\n", func);
 		romcc_print_blocks(state, fp);

From kfuchs at winternet.com  Wed Aug  3 17:27:09 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Wed, 3 Aug 2005 10:27:09 -0500 (CDT)
Subject: [LinuxBIOS] BIOS Saver RD1
Message-ID: <200508031527.j73FR9fW016999@tundra.winternet.com>

> On Wed, Aug 03, 2005 at 11:59:20AM +0900, Jun OKAJIMA wrote:

> > Probably, most guys here use BIOS Saver.
> > And it works well?
> > In mine, RD1 for PLCC gets not being writable suddenly.
> > I mean, it seems writable but # flash_rom -v fails.
> > I solved this problem by a quick hack.
> > 
> > How about yours? You can write RD1 or W49F002U well?
> > Any problem happen?

Johnathan McDowell wrote:

> Even after that it's sometimes a bit flakey and I have to erase, then
> write it. I've put the board's original BIOS in the RD1 and am writing
> to the SST 39SF020A instead, which works without problems.

I've read posts about the RD1 that suggest its integrated flash device
is low quality and it may take 10 or more flash attempts to get a good
flash update to the RD1 flash device.

As a result, many RD1 BIOS Savior users will flash the commercial
BIOS image (or other known good BIOS image) into the RD1 integrated
flash device as many times as needed to get an image that boots.
Then use the original BIOS device to flash test BIOS image (usually
LinuxBIOS images among this group), since the original BIOS device
usually flashes OK on the first attempt.

I've used the RD1 in the above fashion with great success on the
Tyan S2885 mainboard.

The same RD1 would not work on the nVidia CK8-04 CRB mainboard.
I think the CK8-04 CRB requires a flash device that the RD1 does
not support.  However, the RD1 worked well as an "do nothing" adapter
which allowed swapping the BIOS flash device between my flash burner
and the mainboard without any wear to the mainboard's BIOS socket.

BTW, my flash burner is an older Enhanced Willem Universal Programmer.
I got mine for only $60 US over a year ago.  I've seen it for less
than $40 on eBay a few weeks ago.  The newest model is going for about
$50 US.  It does a LinuxBIOS flash in about 5 minutes; not bad for a
$60 burner.  However, it does require changing DIP switches to match
an image for each device it can program.  Great for the amateur or
professional with a small budget.

> > BTW, a cable of your RD1 is not broken?
> > I needed soldering to fix it.

> Mine was fine out of the box.

Mine cable and switch worked fine out of the box as well.

Sincerely,

Ken Fuchs <kfuchs at winternet.com> ami-mac-sun



From rminnich at lanl.gov  Wed Aug  3 18:50:10 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed, 3 Aug 2005 10:50:10 -0600 (MDT)
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <200508031527.j73FR9fW016999@tundra.winternet.com>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
Message-ID: <Pine.LNX.4.58.0508031049560.29161@enigma.lanl.gov>

can somebody write Ken's excellent note up as a FAQ entry and get it on 
the web page? 

ron




From yinghailu at gmail.com  Wed Aug  3 18:50:49 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 3 Aug 2005 09:50:49 -0700
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <200508031527.j73FR9fW016999@tundra.winternet.com>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
Message-ID: <2ea3fae105080309503b144e24@mail.gmail.com>

You need split mess into two seperate thing
1. does flash_rom support your MB, some mb has gpio to disable the
flash write or last 64KiB
2. are you give dead bios savior.

ps. other thing about flash_rom
1. with 2.6 kernel 64 bit for amd8111 based MB, you can not install 4G
or more in CPU0.
2. with 2.6 kernel 64 bit for Nvidia ck804 based MB, you must install
4G or more in CPU0

solution is use 32 bit 2.6 or 2.4 32bit or 2.4 64 bit.
for case 1 you can command line: maxmem to limit mem to 4G less.

It seems last 4KiB near 4G can not be accessed. when read in Linux it
alreays show 0.

Andi may have some idea about it. maybe something related iommu...

YH


On 8/3/05, Ken Fuchs <kfuchs at winternet.com> wrote:
> > On Wed, Aug 03, 2005 at 11:59:20AM +0900, Jun OKAJIMA wrote:
> 
> > > Probably, most guys here use BIOS Saver.
> > > And it works well?
> > > In mine, RD1 for PLCC gets not being writable suddenly.
> > > I mean, it seems writable but # flash_rom -v fails.
> > > I solved this problem by a quick hack.
> > >
> > > How about yours? You can write RD1 or W49F002U well?
> > > Any problem happen?
> 
> Johnathan McDowell wrote:
> 
> > Even after that it's sometimes a bit flakey and I have to erase, then
> > write it. I've put the board's original BIOS in the RD1 and am writing
> > to the SST 39SF020A instead, which works without problems.
> 
> I've read posts about the RD1 that suggest its integrated flash device
> is low quality and it may take 10 or more flash attempts to get a good
> flash update to the RD1 flash device.
> 
> As a result, many RD1 BIOS Savior users will flash the commercial
> BIOS image (or other known good BIOS image) into the RD1 integrated
> flash device as many times as needed to get an image that boots.
> Then use the original BIOS device to flash test BIOS image (usually
> LinuxBIOS images among this group), since the original BIOS device
> usually flashes OK on the first attempt.
> 
> I've used the RD1 in the above fashion with great success on the
> Tyan S2885 mainboard.
> 
> The same RD1 would not work on the nVidia CK8-04 CRB mainboard.
> I think the CK8-04 CRB requires a flash device that the RD1 does
> not support.  However, the RD1 worked well as an "do nothing" adapter
> which allowed swapping the BIOS flash device between my flash burner
> and the mainboard without any wear to the mainboard's BIOS socket.
> 
> BTW, my flash burner is an older Enhanced Willem Universal Programmer.
> I got mine for only $60 US over a year ago.  I've seen it for less
> than $40 on eBay a few weeks ago.  The newest model is going for about
> $50 US.  It does a LinuxBIOS flash in about 5 minutes; not bad for a
> $60 burner.  However, it does require changing DIP switches to match
> an image for each device it can program.  Great for the amateur or
> professional with a small budget.
> 
> > > BTW, a cable of your RD1 is not broken?
> > > I needed soldering to fix it.
> 
> > Mine was fine out of the box.
> 
> Mine cable and switch worked fine out of the box as well.
> 
> Sincerely,
> 
> Ken Fuchs <kfuchs at winternet.com> ami-mac-sun
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From ak at suse.de  Wed Aug  3 21:53:16 2005
From: ak at suse.de (Andi Kleen)
Date: Wed, 3 Aug 2005 21:53:16 +0200
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <2ea3fae105080309503b144e24@mail.gmail.com>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
	<2ea3fae105080309503b144e24@mail.gmail.com>
Message-ID: <20050803195316.GD8266@wotan.suse.de>

On Wed, Aug 03, 2005 at 09:50:49AM -0700, yhlu wrote:
> You need split mess into two seperate thing
> 1. does flash_rom support your MB, some mb has gpio to disable the
> flash write or last 64KiB
> 2. are you give dead bios savior.
> 
> ps. other thing about flash_rom
> 1. with 2.6 kernel 64 bit for amd8111 based MB, you can not install 4G
> or more in CPU0.
> 2. with 2.6 kernel 64 bit for Nvidia ck804 based MB, you must install
> 4G or more in CPU0
> 
> solution is use 32 bit 2.6 or 2.4 32bit or 2.4 64 bit.
> for case 1 you can command line: maxmem to limit mem to 4G less.
> 
> It seems last 4KiB near 4G can not be accessed. when read in Linux it
> alreays show 0.
> 
> Andi may have some idea about it. maybe something related iommu...

IOMMU is not involved here. Me and Torsten looked at it some time ago
and we suspected a chipset issue because there was nothing obviously
special with the way that memory was mapped via /dev/mem.

-Andi




From bari at onelabs.com  Wed Aug  3 21:59:12 2005
From: bari at onelabs.com (Bari Ari)
Date: Wed, 03 Aug 2005 14:59:12 -0500
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <Pine.LNX.4.58.0508031049560.29161@enigma.lanl.gov>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
	<Pine.LNX.4.58.0508031049560.29161@enigma.lanl.gov>
Message-ID: <42F12210.2040809@onelabs.com>

Ronald G. Minnich wrote:
> can somebody write Ken's excellent note up as a FAQ entry and get it on 
> the web page? 

Done.

-Bari



From yinghailu at gmail.com  Wed Aug  3 23:02:35 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 3 Aug 2005 14:02:35 -0700
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <20050803195316.GD8266@wotan.suse.de>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
	<2ea3fae105080309503b144e24@mail.gmail.com>
	<20050803195316.GD8266@wotan.suse.de>
Message-ID: <2ea3fae105080314022c9756ab@mail.gmail.com>

I believe, sometime the SB eat some byte...write to LPC.

YH

On 8/3/05, Andi Kleen <ak at suse.de> wrote:
> On Wed, Aug 03, 2005 at 09:50:49AM -0700, yhlu wrote:
> > You need split mess into two seperate thing
> > 1. does flash_rom support your MB, some mb has gpio to disable the
> > flash write or last 64KiB
> > 2. are you give dead bios savior.
> >
> > ps. other thing about flash_rom
> > 1. with 2.6 kernel 64 bit for amd8111 based MB, you can not install 4G
> > or more in CPU0.
> > 2. with 2.6 kernel 64 bit for Nvidia ck804 based MB, you must install
> > 4G or more in CPU0
> >
> > solution is use 32 bit 2.6 or 2.4 32bit or 2.4 64 bit.
> > for case 1 you can command line: maxmem to limit mem to 4G less.
> >
> > It seems last 4KiB near 4G can not be accessed. when read in Linux it
> > alreays show 0.
> >
> > Andi may have some idea about it. maybe something related iommu...
> 
> IOMMU is not involved here. Me and Torsten looked at it some time ago
> and we suspected a chipset issue because there was nothing obviously
> special with the way that memory was mapped via /dev/mem.
> 
> -Andi
> 
>



From steve at digidescorp.com  Wed Aug  3 23:38:59 2005
From: steve at digidescorp.com (Steve Magnani)
Date: Wed, 03 Aug 2005 16:38:59 -0500
Subject: [LinuxBIOS] elfboot() can trash GDT
Message-ID: <WorldClient-F200508031638.AA38590015@digidescorp.com>

I've run into an interesting problem doing some "bait and switch" with my
emulator.

I have machine code for an x86 program that expects to run in protected
mode. It's not an ELF file, so I can't load it directly with elfboot().
What I'm doing for the time being is having elfboot load Etherboot, with
the emulator set to break at the Etherboot entry address. When the
breakpoint is hit I load the machine code into memory and change EIP to
its entry point. (Ultimately I'll probably create an ELF wrapper for this
code, but I don't have one yet).

My machine code gets a protection exception when it tries to set one of
the segment registers (to the value it already has, BTW). I traced this to
the fact that Etherboot was loaded on top of the GDT used by LinuxBIOS.

We can argue about what kind of assumptions payloads should make about
their runtime environment, but it seems to me that being in protected mode
without a GDT is a bomb waiting to go off. Some payloads are bound to do
things in a sequence that causes an explosion. 

Can we move the GDT within the memory LB reports as unusable, say, before
the tables? 

Steve
www.digidescorp.com





From rminnich at lanl.gov  Thu Aug  4 06:22:55 2005
From: rminnich at lanl.gov (Ronald G. Minnich)
Date: Wed, 3 Aug 2005 22:22:55 -0600 (MDT)
Subject: [LinuxBIOS] elfboot() can trash GDT
In-Reply-To: <WorldClient-F200508031638.AA38590015@digidescorp.com>
References: <WorldClient-F200508031638.AA38590015@digidescorp.com>
Message-ID: <Pine.LNX.4.58.0508032221430.30453@enigma.lanl.gov>



On Wed, 3 Aug 2005, Steve Magnani wrote:

> My machine code gets a protection exception when it tries to set one of
> the segment registers (to the value it already has, BTW). I traced this to
> the fact that Etherboot was loaded on top of the GDT used by LinuxBIOS.

cute. Now, the great part is, this is the first time we've ever been
bitten by this one, yet it is clearly quite a fine, healthy, nasty bug.

OK, we'll have to fix this one :-)

ron



From ebiederman at lnxi.com  Thu Aug  4 09:47:41 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu, 04 Aug 2005 01:47:41 -0600
Subject: [BULK] [LinuxBIOS] elfboot() can trash GDT
In-Reply-To: <WorldClient-F200508031638.AA38590015@digidescorp.com> (Steve
	Magnani's message of "Wed, 03 Aug 2005 16:38:59 -0500")
References: <WorldClient-F200508031638.AA38590015@digidescorp.com>
Message-ID: <m33bpq5ejm.fsf@maxwell.lnxi.com>

"Steve Magnani" <steve at digidescorp.com> writes:

> I've run into an interesting problem doing some "bait and switch" with my
> emulator.
>
> I have machine code for an x86 program that expects to run in protected
> mode. It's not an ELF file, so I can't load it directly with elfboot().
> What I'm doing for the time being is having elfboot load Etherboot, with
> the emulator set to break at the Etherboot entry address. When the
> breakpoint is hit I load the machine code into memory and change EIP to
> its entry point. (Ultimately I'll probably create an ELF wrapper for this
> code, but I don't have one yet).
>
> My machine code gets a protection exception when it tries to set one of
> the segment registers (to the value it already has, BTW). I traced this to
> the fact that Etherboot was loaded on top of the GDT used by LinuxBIOS.

Etherboot a few instructions later will load it's own GDT.

> We can argue about what kind of assumptions payloads should make about
> their runtime environment, but it seems to me that being in protected mode
> without a GDT is a bomb waiting to go off. Some payloads are bound to do
> things in a sequence that causes an explosion. 

Not really.  I don't think there are any processor operations that
automatically reload segment registers.  In fact segment registers are
so useless that in 64bit mode they are not even implemented.  If you want
to mess with the segment registers you should really be loading your own.

The values in the segments persist in the segment shadow registers.  And
that is where the values matter.  It is unfortunate that the registers
that matter are write only registers though.

> Can we move the GDT within the memory LB reports as unusable, say, before
> the tables? 

I looked at the code and we aren't nuking the gdt deliberately.  But
I am not really comfortable with applications caring about it.  At one
point I was thinking it might be sane to return to LinuxBIOS but there
don't appear to be any uses for that.

The sane thing for an application to expect in 32bit protected mode
is flat 32bit segments with a base of 0.  That is enough to get
things done.  If you need something more I would like to hear why.

We really can't sanely fix this when you are doing something that
seems to have no real justification.

Eric



From ebiederman at lnxi.com  Thu Aug  4 09:50:51 2005
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu, 04 Aug 2005 01:50:51 -0600
Subject: [BULK] Re: [LinuxBIOS] Potential copyright issues with
	decompiling ACPI tables?
In-Reply-To: <Pine.LNX.4.58.0507311927210.21749@enigma.lanl.gov> (Ronald G.
	Minnich's message of "Sun, 31 Jul 2005 19:27:42 -0600 (MDT)")
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
	<20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>
	<20050731094623.61e7600d@absurd>
	<Pine.LNX.4.58.0507311927210.21749@enigma.lanl.gov>
Message-ID: <m3y87i3ztw.fsf@maxwell.lnxi.com>

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

> On Sun, 31 Jul 2005, Janek Kozicki wrote:
>
>> > Facts can't be copyrighted. But it's not easy to use that to convince
>> > someone to stop labeling a fact as being copyrighted.
>> 
>> but current linux kernel has to decompile ACPI tables too, right? and BSD
> also?
>
> sure it does. Now what happens if it decompiles tables and mails them to 
> world, I just don't know. 

I don't know where we should get the information.  But
we should generate all of our tables from our native
LinuxBIOS device tree.  The MP table is about half way
there now.

That will both keep our information consistent.  And placing
the information in our own format means we are simply using
the information and not copying something.

Eric



From duwe at suse.de  Thu Aug  4 12:29:50 2005
From: duwe at suse.de (Torsten Duwe)
Date: Thu, 4 Aug 2005 12:29:50 +0200
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <2ea3fae105080314022c9756ab@mail.gmail.com>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
	<2ea3fae105080309503b144e24@mail.gmail.com>
	<20050803195316.GD8266@wotan.suse.de>
	<2ea3fae105080314022c9756ab@mail.gmail.com>
Message-ID: <17137.60958.910871.640402@schifrin.suse.de>

>>>>> "yhlu" == yhlu  <yinghailu at gmail.com> writes:

    yhlu> I believe, sometime the SB eat some byte...write to LPC.  YH

    >> > ps. other thing about flash_rom > 1. with 2.6 kernel 64 bit for
    >> amd8111 based MB, you can not install 4G > or more in CPU0.  > 2. with
    >> 2.6 kernel 64 bit for Nvidia ck804 based MB, you must install > 4G or
    >> more in CPU0

But how is the (physical?) mapping of the LPC bus dependent on the amount of
memory installed? If it's neither MMU, nor IOMMU, nor MTRR, it must be the
chipset, as you suggest above!

	Torsten




From okajima at digitalinfra.co.jp  Thu Aug  4 14:43:08 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Thu, 04 Aug 2005 21:43:08 +0900
Subject: [LinuxBIOS] W49F002U patch
Message-ID: <200508041243.AA00214@bbb-jz5c7z9hn9y.digitalinfra.co.jp>



Hello.

An attached file is a quick hack to burn my RD1.

Use like this.
Assuming you put SST39SF020A or at least, not W49F002U on a socket.

Usage:
   The first burn:
       flash_rom -t W49F002U -wv BIOS.IMG
   If not verified:
       flash_rom -t W49F002U -Fwv BIOS.IMG
       (repeat this until verified.)
Before rebooting,
do # flash_rom -v BIOS.IMG again to make doubly sure. 

-t option does not affect chip probing. Avoiding just in case that
you miss to set a select switch rightly.
If your swich is set to "ORG", and you put SST chip on a socket,
it fails when you add "-t W49F002U".

Hope an attached file can be sent on this ML.

             --- Okajima, Jun. Tokyo, Japan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rd1.patch
Type: application/octet-stream
Size: 4764 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050804/f9a58df5/attachment.obj>

From steve at digidescorp.com  Thu Aug  4 15:49:51 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Thu, 4 Aug 2005 08:49:51 -0500
Subject: [BULK] [LinuxBIOS] elfboot() can trash GDT
In-Reply-To: <m33bpq5ejm.fsf@maxwell.lnxi.com>
Message-ID: <000001c598fb$66271de0$6ffea8c0@banana>

Eric,

I admit that my current situation is out of the mainstream. But it's
uncovered an issue that could affect others doing more mainstream
things.

You write:
> The sane thing for an application to expect in 32bit protected 
> mode is flat 32bit segments with a base of 0.  That is enough 
> to get things done.  If you need something more I would like to 
> hear why.

The code I'm having trouble with is defensive in nature. It is
attempting to put the processor into a known state, in case some of the
segment registers or flags were not initialized in the switch to
protected mode. The code fails because LinuxBIOS is leaving the
processor in an inconsistent state (ring 0 protected mode with an
invalid GDT backing it). I think this demonstrates both the need for
defensive programming by payload writers, and the potential pitfalls of
LinuxBIOS doing things that are unexpected.

It is always good to ask whether the cost of NOT making a change
outweighs the cost of making it. As Ron points out, I'm the first to
trip over this (lucky me). If LB continues as it is, will I be the last?
No. That's the "any problem you've ever run into is somewhere on the
Internet" syndrome. 

I can certainly resolve my problem by writing a wrapper that sets up a
GDT before branching to the "problem" code. But that only helps me. I'd
prefer to have a solution that helps everyone. 

The cost of changing LB to maintain a consistent GDT is that one
developer has to make the changes to accomplish this. Others probably
review the change. That's less work now than it will be in future,
because the issues are fresh.

The cost of NOT changing LB is that N future payload developers discover
the problem and have to implement workarounds. The larger part of that
cost is probably tracking down what's causing the problem in the first
place. 

I would argue that while N might be increasing very slowly, eventually
the cost to the LB community of NOT fixing the GDT will outweigh the
cost of fixing it. 

An alternative (but to me, a less desirable one) would be to find some
way to make it obvious to payload developers what kind of environment
they can count on (i.e. document the GDT issue, making it a 'feature'
rather than a 'bug'). You could argue that this e-mail thread does that,
but I don't think it will help anyone who hasn't already run into the
issue and spent time finding its cause.

Steve






From ollie at lanl.gov  Thu Aug  4 16:52:39 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu, 04 Aug 2005 08:52:39 -0600
Subject: [LinuxBIOS] W49F002U patch
In-Reply-To: <200508041243.AA00214@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
References: <200508041243.AA00214@bbb-jz5c7z9hn9y.digitalinfra.co.jp>
Message-ID: <1123167159.5232.0.camel@logarithm.lanl.gov>

On Thu, 2005-08-04 at 21:43 +0900, Jun OKAJIMA wrote:
> 
> Hello.
> 
> An attached file is a quick hack to burn my RD1.
> 
> Use like this.
> Assuming you put SST39SF020A or at least, not W49F002U on a socket.
> 
> Usage:
>    The first burn:
>        flash_rom -t W49F002U -wv BIOS.IMG
>    If not verified:
>        flash_rom -t W49F002U -Fwv BIOS.IMG
>        (repeat this until verified.)
> Before rebooting,
> do # flash_rom -v BIOS.IMG again to make doubly sure. 
> 
> -t option does not affect chip probing. Avoiding just in case that
> you miss to set a select switch rightly.
> If your swich is set to "ORG", and you put SST chip on a socket,
> it fails when you add "-t W49F002U".
> 
> Hope an attached file can be sent on this ML.
> 
>              --- Okajima, Jun. Tokyo, Japan.


What is the "fix_it" doing?

Could you send a unified diff instead?

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From okajima at digitalinfra.co.jp  Thu Aug  4 17:35:07 2005
From: okajima at digitalinfra.co.jp (Jun OKAJIMA)
Date: Fri, 05 Aug 2005 00:35:07 +0900
Subject: [LinuxBIOS] Unified Patch
Message-ID: <200508041535.AA00215@bbb-jz5c7z9hn9y.digitalinfra.co.jp>


If you need an unified format, use this.

And, what this does is, basically, minimize erasing and writing.
I found that byte of W49 changes after verifing of the byte passed.
Probably, it is due to be affected by wrinting of another byte.

So, basic idea is like this.

1. write normally in the first run.
2. write only error bytes after second run without erasing.

As you know, bits of flash are 1 when erased and writing changes only 1 -> 0.
So, my way can be applied only if you need to change 1 -> 0.
But, all cases I have found are this case.

And, this is just a quick hack, not such a good solution.
I think this way can be applied to even the first run.
Why you do erasing -> writing sequence if all data in a sector is
just same as what you want to write?

                 --- Okajima, Jun.

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rd1.patch.unified
Type: application/octet-stream
Size: 3584 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050805/fd4728b8/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rd1.patch.unified
Type: application/octet-stream
Size: 3584 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050805/fd4728b8/attachment-0001.obj>

From noodles at earth.li  Thu Aug  4 17:59:52 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Thu, 4 Aug 2005 16:59:52 +0100
Subject: [LinuxBIOS] Trying to build all available targets.
Message-ID: <20050804155951.GN12895@earth.li>

I've been playing about with trying to autobuild all the available
targets, to catch regressions, or more relevantly to convince myself
that when things are broken it's not just EPIA-M that's affected.

http://the.earth.li/~noodles/lb/

is what I've got so far.

1987/ is pre gcc4 fix, so 1989/ is more interesting.

All 12 Tyan boards built, leaving 18 that didn't.

amd-quartet, amd-solo, arima-hdama & ibm-e325 all look like they'd build
with elf payloads (the directories they look for the payload in aren't
convenient for an enclosed build - does anyone object if I clean this
up?).

embeddedplanet-ep405pc & motorola-sandpoint are both PPC so won't build
anyway.

via-epia-m, Iwill-dk8s2, totalimpact-briq, technologic-ts5300 and
newisys-khepri all failed to have a config file that buildtarget was
happy with.

via-epia, digitallogic-adl855pc, digitallogic-msm586seg, eaglelion-5bcm
& emulation-qemu-i386 all have problems with udelay.

amd-serenade has an error I don't quite understand.

island-aruma has a non-standard build dir so it doesn't get picked up.
Again this is something I'll fix up in the config file unless I hear
complaints.

I've got my EPIA-M code to the point where it's hitting the udelay
problem various other ports have. I haven't quite tracked down what
other change has made this happen though. EPIA was certainly building a
month or so ago from the tree when I tried it.

J.

-- 
Hell hath no fury like the lawyer of a woman scorned.



From ollie at lanl.gov  Thu Aug  4 18:17:03 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu, 04 Aug 2005 10:17:03 -0600
Subject: [LinuxBIOS] Trying to build all available targets.
In-Reply-To: <20050804155951.GN12895@earth.li>
References: <20050804155951.GN12895@earth.li>
Message-ID: <1123172223.5232.6.camel@logarithm.lanl.gov>

On Thu, 2005-08-04 at 16:59 +0100, Jonathan McDowell wrote:
> I've been playing about with trying to autobuild all the available
> targets, to catch regressions, or more relevantly to convince myself
> that when things are broken it's not just EPIA-M that's affected.
> 
> http://the.earth.li/~noodles/lb/
> 
> is what I've got so far.
> 
> 1987/ is pre gcc4 fix, so 1989/ is more interesting.
> 
> All 12 Tyan boards built, leaving 18 that didn't.
> 
> amd-quartet, amd-solo, arima-hdama & ibm-e325 all look like they'd build
> with elf payloads (the directories they look for the payload in aren't
> convenient for an enclosed build - does anyone object if I clean this
> up?).
> 

Do you mean I left "payload /home/ollie/xxxx" there ?

> embeddedplanet-ep405pc & motorola-sandpoint are both PPC so won't build
> anyway.
> 
> via-epia-m, Iwill-dk8s2, totalimpact-briq, technologic-ts5300 and
> newisys-khepri all failed to have a config file that buildtarget was
> happy with.
> 

totalimpac-briq should be PPC. technologic-ts5300 is never finished.

> via-epia, digitallogic-adl855pc, digitallogic-msm586seg, eaglelion-5bcm
> & emulation-qemu-i386 all have problems with udelay.
> 

I have a quick fix to the udelay but I am not sure it is the correct
way to do it.

> amd-serenade has an error I don't quite understand.
> 
> island-aruma has a non-standard build dir so it doesn't get picked up.
> Again this is something I'll fix up in the config file unless I hear
> complaints.
> 
> I've got my EPIA-M code to the point where it's hitting the udelay
> problem various other ports have. I haven't quite tracked down what
> other change has made this happen though. EPIA was certainly building a
> month or so ago from the tree when I tried it.
> 
> J.
> 
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From yinghailu at gmail.com  Thu Aug  4 18:24:37 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 4 Aug 2005 09:24:37 -0700
Subject: [LinuxBIOS] Trying to build all available targets.
In-Reply-To: <1123172223.5232.6.camel@logarithm.lanl.gov>
References: <20050804155951.GN12895@earth.li>
	<1123172223.5232.6.camel@logarithm.lanl.gov>
Message-ID: <2ea3fae105080409245d920b10@mail.gmail.com>

All tyan MB are using CAR, So I wonder if something related that.

But seems that Ollie already verified with gcc 3.3 or 3.4 romcc
version could work too.

YH

On 8/4/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> On Thu, 2005-08-04 at 16:59 +0100, Jonathan McDowell wrote:
> > I've been playing about with trying to autobuild all the available
> > targets, to catch regressions, or more relevantly to convince myself
> > that when things are broken it's not just EPIA-M that's affected.
> >
> > http://the.earth.li/~noodles/lb/
> >
> > is what I've got so far.
> >
> > 1987/ is pre gcc4 fix, so 1989/ is more interesting.
> >
> > All 12 Tyan boards built, leaving 18 that didn't.
> >
> > amd-quartet, amd-solo, arima-hdama & ibm-e325 all look like they'd build
> > with elf payloads (the directories they look for the payload in aren't
> > convenient for an enclosed build - does anyone object if I clean this
> > up?).
> >
> 
> Do you mean I left "payload /home/ollie/xxxx" there ?
> 
> > embeddedplanet-ep405pc & motorola-sandpoint are both PPC so won't build
> > anyway.
> >
> > via-epia-m, Iwill-dk8s2, totalimpact-briq, technologic-ts5300 and
> > newisys-khepri all failed to have a config file that buildtarget was
> > happy with.
> >
> 
> totalimpac-briq should be PPC. technologic-ts5300 is never finished.
> 
> > via-epia, digitallogic-adl855pc, digitallogic-msm586seg, eaglelion-5bcm
> > & emulation-qemu-i386 all have problems with udelay.
> >
> 
> I have a quick fix to the udelay but I am not sure it is the correct
> way to do it.
> 
> > amd-serenade has an error I don't quite understand.
> >
> > island-aruma has a non-standard build dir so it doesn't get picked up.
> > Again this is something I'll fix up in the config file unless I hear
> > complaints.
> >
> > I've got my EPIA-M code to the point where it's hitting the udelay
> > problem various other ports have. I haven't quite tracked down what
> > other change has made this happen though. EPIA was certainly building a
> > month or so ago from the tree when I tried it.
> >
> > J.
> >
> --
> Li-Ta Lo <ollie at lanl.gov>
> Los Alamos National Lab
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From yinghailu at gmail.com  Thu Aug  4 18:28:22 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 4 Aug 2005 09:28:22 -0700
Subject: [BULK] Re: [LinuxBIOS] Potential copyright issues with
	decompiling ACPI tables?
In-Reply-To: <m3y87i3ztw.fsf@maxwell.lnxi.com>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
	<20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>
	<20050731094623.61e7600d@absurd>
	<Pine.LNX.4.58.0507311927210.21749@enigma.lanl.gov>
	<m3y87i3ztw.fsf@maxwell.lnxi.com>
Message-ID: <2ea3fae1050804092844cf91c4@mail.gmail.com>

So everyone agree to put acpi support to LinuxBIOS?

An the way that we need to create our own acpi tables dynamically. (
in case user add pci bridge .....)

YH

On 8/4/05, Eric W. Biederman <ebiederman at lnxi.com> wrote:
> "Ronald G. Minnich" <rminnich at lanl.gov> writes:
> 
> > On Sun, 31 Jul 2005, Janek Kozicki wrote:
> >
> >> > Facts can't be copyrighted. But it's not easy to use that to convince
> >> > someone to stop labeling a fact as being copyrighted.
> >>
> >> but current linux kernel has to decompile ACPI tables too, right? and BSD
> > also?
> >
> > sure it does. Now what happens if it decompiles tables and mails them to
> > world, I just don't know.
> 
> I don't know where we should get the information.  But
> we should generate all of our tables from our native
> LinuxBIOS device tree.  The MP table is about half way
> there now.
> 
> That will both keep our information consistent.  And placing
> the information in our own format means we are simply using
> the information and not copying something.
> 
> Eric
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From noodles at earth.li  Thu Aug  4 18:51:55 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Thu, 4 Aug 2005 17:51:55 +0100
Subject: [LinuxBIOS] Trying to build all available targets.
In-Reply-To: <1123172223.5232.6.camel@logarithm.lanl.gov>
References: <20050804155951.GN12895@earth.li>
	<1123172223.5232.6.camel@logarithm.lanl.gov>
Message-ID: <20050804165155.GR12895@earth.li>

On Thu, Aug 04, 2005 at 10:17:03AM -0600, Li-Ta Lo wrote:
> On Thu, 2005-08-04 at 16:59 +0100, Jonathan McDowell wrote:
> > I've been playing about with trying to autobuild all the available
> > targets, to catch regressions, or more relevantly to convince myself
> > that when things are broken it's not just EPIA-M that's affected.
> > 
> > http://the.earth.li/~noodles/lb/
> > 
> > is what I've got so far.
> > 
> > 1987/ is pre gcc4 fix, so 1989/ is more interesting.
> > 
> > All 12 Tyan boards built, leaving 18 that didn't.
> > 
> > amd-quartet, amd-solo, arima-hdama & ibm-e325 all look like they'd build
> > with elf payloads (the directories they look for the payload in aren't
> > convenient for an enclosed build - does anyone object if I clean this
> > up?).
> > 
> 
> Do you mean I left "payload /home/ollie/xxxx" there ?

Yes. The attached patch cleans up the payload bits (put them in
targets/<vendor>/payloads like the Tyan boards do) and also fixes
island-aruma to put itself in the same format of directory as everything
else. With it I get PASSes for amd-quartet, amd-solo, arima-hdama,
ibm-e325 & island-aruma, in addition to the Tyan boards. That brings us
up to 17 images building fine and 13 failing.

> > embeddedplanet-ep405pc & motorola-sandpoint are both PPC so won't build
> > anyway.
> > 
> > via-epia-m, Iwill-dk8s2, totalimpact-briq, technologic-ts5300 and
> > newisys-khepri all failed to have a config file that buildtarget was
> > happy with.
> > 
> totalimpac-briq should be PPC. technologic-ts5300 is never finished.

buildtarget can't even parse their config files, so my test rig never
even tries to compile them.

> > via-epia, digitallogic-adl855pc, digitallogic-msm586seg, eaglelion-5bcm
> > & emulation-qemu-i386 all have problems with udelay.
> I have a quick fix to the udelay but I am not sure it is the correct
> way to do it.

Can you show me your quick fix even to give me an idea of where the
issue is?

J.

-- 
/-\                             |    noodles is not a sign of poor
|@/  Debian GNU/Linux Developer |            table manners
\-                              |
-------------- next part --------------
Index: targets/arima/hdama/Config.lb
===================================================================
--- targets/arima/hdama/Config.lb	(revision 1989)
+++ targets/arima/hdama/Config.lb	(working copy)
@@ -13,7 +13,7 @@
 	option USE_FALLBACK_IMAGE=0
 	option ROM_IMAGE_SIZE=0x16000
 	option LINUXBIOS_EXTRA_VERSION=".0Normal"
-	payload /home/ollie/work/filo-0.4.1/filo.elf
+	payload ../../../payloads/filo.elf
 #	payload /etc/hosts
 end
 
@@ -21,7 +21,7 @@
 	option USE_FALLBACK_IMAGE=1
 	option ROM_IMAGE_SIZE=0x16000
 	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
-	payload /home/ollie/work/filo-0.4.1/filo.elf
+	payload ../../../payloads/filo.elf
 #	payload /etc/hosts
 end
 
Index: targets/amd/quartet/Config.lb
===================================================================
--- targets/amd/quartet/Config.lb	(revision 1989)
+++ targets/amd/quartet/Config.lb	(working copy)
@@ -7,14 +7,14 @@
 	option USE_FALLBACK_IMAGE=0
 	option ROM_IMAGE_SIZE=0x14000
 	option LINUXBIOS_EXTRA_VERSION=".0-Normal"
-	payload /usr/share/LinuxBIOS/tg3--ide_disk.zelf
+	payload ../../../payloads/tg3--ide_disk.zelf
 end
 
 romimage "fallback" 
 	option USE_FALLBACK_IMAGE=1
 	option ROM_IMAGE_SIZE=0x14000
 	option LINUXBIOS_EXTRA_VERSION=".0-Fallback"
-	payload /usr/share/LinuxBIOS/tg3--ide_disk.zelf
+	payload ../../../payloads/tg3--ide_disk.zelf
 end
 
 buildrom ./quartet.rom ROM_SIZE "normal" "fallback"
Index: targets/amd/solo/Config.lb
===================================================================
--- targets/amd/solo/Config.lb	(revision 1989)
+++ targets/amd/solo/Config.lb	(working copy)
@@ -9,14 +9,14 @@
 	option USE_FALLBACK_IMAGE=0
 	option ROM_IMAGE_SIZE=0x14000
 	option LINUXBIOS_EXTRA_VERSION=".0-Normal"
-	payload /usr/share/LinuxBIOS/tg3--ide_disk.zelf
+	payload ../../../payloads/tg3--ide_disk.zelf
 end
 
 romimage "fallback" 
 	option USE_FALLBACK_IMAGE=1
 	option ROM_IMAGE_SIZE=0x14000
 	option LINUXBIOS_EXTRA_VERSION=".0-Fallback"
-	payload /usr/share/LinuxBIOS/tg3--ide_disk.zelf
+	payload ../../../payloads/tg3--ide_disk.zelf
 end
 
 buildrom ./solo.rom ROM_SIZE "normal" "fallback"
Index: targets/ibm/e325/Config.lb
===================================================================
--- targets/ibm/e325/Config.lb	(revision 1989)
+++ targets/ibm/e325/Config.lb	(working copy)
@@ -18,7 +18,7 @@
 	option ROM_IMAGE_SIZE=0x12000
 	option LINUXBIOS_EXTRA_VERSION=".0Normal"
 #	payload ../../filo.elf
-        payload /home/ollie/work/filo-0.4.1/filo.elf
+	payload ../../../payloads/filo.elf
 end
 
 romimage "fallback" 
@@ -26,7 +26,7 @@
 	option ROM_IMAGE_SIZE=0x12000
 	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
 #	payload ../../filo.elf
-        payload /home/ollie/work/filo-0.4.1/filo.elf
+	payload ../../../payloads/filo.elf
 # use this to test a build if you don't have the etherboot
 #	payload /etc/hosts
 end
Index: targets/island/aruma/Config.lb
===================================================================
--- targets/island/aruma/Config.lb	(revision 1989)
+++ targets/island/aruma/Config.lb	(working copy)
@@ -1,6 +1,6 @@
-# This will make a target directory of ./island_aruma
+# This will make a target directory of ./aruma
 
-target island_aruma
+target aruma
 mainboard island/aruma
 
 option DEFAULT_CONSOLE_LOGLEVEL=8
@@ -21,7 +21,7 @@
 	option ROM_IMAGE_SIZE=0x1c000
 	option XIP_ROM_SIZE=0x20000
 	option LINUXBIOS_EXTRA_VERSION=".0-normal"
-	payload /home/stepan/agami/build/filo-0.4.2/filo.elf
+	payload ../../../payloads/filo.elf
 end
 
 romimage "fallback" 
@@ -29,7 +29,7 @@
 	option ROM_IMAGE_SIZE=0x1c000
 	option XIP_ROM_SIZE=0x20000
 	option LINUXBIOS_EXTRA_VERSION=".0-fallback"
-	payload /home/stepan/agami/build/filo-0.4.2/filo.elf
+	payload ../../../payloads/filo.elf
 end
 
 buildrom ./island_aruma.rom ROM_SIZE "normal" "fallback"

From ollie at lanl.gov  Thu Aug  4 19:05:05 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu, 04 Aug 2005 11:05:05 -0600
Subject: [LinuxBIOS] Trying to build all available targets.
In-Reply-To: <20050804165155.GR12895@earth.li>
References: <20050804155951.GN12895@earth.li>
	<1123172223.5232.6.camel@logarithm.lanl.gov>
	<20050804165155.GR12895@earth.li>
Message-ID: <1123175106.5232.9.camel@logarithm.lanl.gov>

On Thu, 2005-08-04 at 17:51 +0100, Jonathan McDowell wrote:
> On Thu, Aug 04, 2005 at 10:17:03AM -0600, Li-Ta Lo wrote:
> > On Thu, 2005-08-04 at 16:59 +0100, Jonathan McDowell wrote:
> > > I've been playing about with trying to autobuild all the available
> > > targets, to catch regressions, or more relevantly to convince myself
> > > that when things are broken it's not just EPIA-M that's affected.
> > > 
> > > http://the.earth.li/~noodles/lb/
> > > 
> > > is what I've got so far.
> > > 
> > > 1987/ is pre gcc4 fix, so 1989/ is more interesting.
> > > 
> > > All 12 Tyan boards built, leaving 18 that didn't.
> > > 
> > > amd-quartet, amd-solo, arima-hdama & ibm-e325 all look like they'd build
> > > with elf payloads (the directories they look for the payload in aren't
> > > convenient for an enclosed build - does anyone object if I clean this
> > > up?).
> > > 
> > 
> > Do you mean I left "payload /home/ollie/xxxx" there ?
> 
> Yes. The attached patch cleans up the payload bits (put them in
> targets/<vendor>/payloads like the Tyan boards do) and also fixes
> island-aruma to put itself in the same format of directory as everything
> else. With it I get PASSes for amd-quartet, amd-solo, arima-hdama,
> ibm-e325 & island-aruma, in addition to the Tyan boards. That brings us
> up to 17 images building fine and 13 failing.
> 

Did you get your commit privilege yet? Can you commit your patch?

-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From noodles at earth.li  Thu Aug  4 19:07:34 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Thu, 4 Aug 2005 18:07:34 +0100
Subject: [LinuxBIOS] Trying to build all available targets.
In-Reply-To: <1123175106.5232.9.camel@logarithm.lanl.gov>
References: <20050804155951.GN12895@earth.li>
	<1123172223.5232.6.camel@logarithm.lanl.gov>
	<20050804165155.GR12895@earth.li>
	<1123175106.5232.9.camel@logarithm.lanl.gov>
Message-ID: <20050804170734.GU12895@earth.li>

On Thu, Aug 04, 2005 at 11:05:05AM -0600, Li-Ta Lo wrote:
> On Thu, 2005-08-04 at 17:51 +0100, Jonathan McDowell wrote:
> > On Thu, Aug 04, 2005 at 10:17:03AM -0600, Li-Ta Lo wrote:
> > > Do you mean I left "payload /home/ollie/xxxx" there ?
> > Yes. The attached patch cleans up the payload bits (put them in
> > targets/<vendor>/payloads like the Tyan boards do) and also fixes
> > island-aruma to put itself in the same format of directory as everything
> > else. With it I get PASSes for amd-quartet, amd-solo, arima-hdama,
> > ibm-e325 & island-aruma, in addition to the Tyan boards. That brings us
> > up to 17 images building fine and 13 failing.
> Did you get your commit privilege yet? Can you commit your patch?

I did, yes. I've been posting patches to the list before committing
them, but you've been committing them for me so far. :) I'll commit this
one now.

J.

-- 
101 things you can't have too much  |       Black Cat Networks Ltd
   of : 36 - Spare video tapes.     | http://www.blackcatnetworks.co.uk/
                                    |  UK Web, domain and email hosting



From rminnich at lanl.gov  Tue Aug  2 17:57:04 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 02 Aug 2005 09:57:04 -0600
Subject: [LinuxBIOS] [Fwd: Info for LinuxBIOS Summit announcement]
Message-ID: <42EF97D0.6060507@lanl.gov>

Here's the information. This is a very nice hotel, in a nice town (Santa 
Fe), so I think we'll have a great time. If you plan to bring hardware 
or need anything special, let me know.


MEETING DETAILS

The LinuxBIOS Summit will be at the 2005 LACSI Symposium, October 11-13, 
2005 in Santa Fe, New Mexico USA. See lacsi.rice.edu/symposium.  We will 
begin as a full-day workshop (among nine others) on the Symposium's 
first day (October 11).  Then we'll have another 1.5 days to meet in 
parallel with the Symposium.

REGISTRATION

Register for the LACSI Symposium at
https://ssl.linklings.net/registrations/lacsi/
and select the LinuxBIOS Summit as your preferred workshop.  You'll have
all the perquisites of a Symposium attendee (access to all workshops,
reception, research presentations, panels, proceedings) as well as to 
the LinuxBIOS Summit meetings.  Registration is $350 until September 5, 
then $400 until October 5 or on-site.  There are also student rates.

LODGING

Rooms are reserved in the "LACSI" block at the Eldorado Hotel in
Santa Fe, NM USA.  You may reserve a room at the Conference
Registration page (see "Hotel Reservation Form), or by calling
800.955.4455.  Single rooms are $94, doubles are $114 (plus tax).



From noodles at earth.li  Thu Aug  4 19:36:35 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Thu, 4 Aug 2005 18:36:35 +0100
Subject: [LinuxBIOS] EPIA-M first round of patches.
Message-ID: <20050804173635.GV12895@earth.li>

Attached are my first round of EPIA-M patches. They get it compiling to
the point of hitting the udelay patches and are basically what had been
committed to my arch tree.

01-epiam-config-fixup.diff
	Fix up the config files so buildtarget runs
03-vt8235-fixup.diff
	Fix up compilation of the VT8235 southbridge
04-epim-mainboard-config-fixup.diff
	Fix up the mainboard config file for the southbridge devices
	etc.
05-vt8623-fixup.diff
	Fix up the VT8623 northbridge.
06-vt1211-fixup.diff
	Fix up the VT1211 SuperIO device.

Comments appreciated; if I don't hear anything by the end of the weekend
I'll assume it's ok to commit.

J.

-- 
Web [                     noodles is now open                      ]
site: http:// [                                          ]       Made by
www.earth.li/~noodles/  [                      ]         HuggieTag 0.0.23
-------------- next part --------------
diff -ruN LinuxBIOSv2.02/src/southbridge/via/vt8235/chip.h LinuxBIOSv2.03/src/southbridge/via/vt8235/chip.h
--- LinuxBIOSv2.02/src/southbridge/via/vt8235/chip.h	2005-08-03 15:12:36.955864000 +0100
+++ LinuxBIOSv2.03/src/southbridge/via/vt8235/chip.h	2005-08-03 16:23:51.843028500 +0100
@@ -1,7 +1,7 @@
 #ifndef _SOUTHBRIDGE_VIA_VT8235
 #define _SOUTHBRIDGE_VIA_VT8235
 
-extern struct chip_operations southbridge_via_vt8235_control;
+extern struct chip_operations southbridge_via_vt8235_ops;
 
 struct southbridge_via_vt8235_config {
 	/* PCI function enables */
diff -ruN LinuxBIOSv2.02/src/southbridge/via/vt8235/Config.lb LinuxBIOSv2.03/src/southbridge/via/vt8235/Config.lb
--- LinuxBIOSv2.02/src/southbridge/via/vt8235/Config.lb	2005-08-03 15:12:36.951864000 +0100
+++ LinuxBIOSv2.03/src/southbridge/via/vt8235/Config.lb	2005-08-03 16:28:57.270116500 +0100
@@ -1,2 +1,6 @@
 config chip.h
-object vt8235.o
+driver vt8235.o
+driver vt8235_ide.o
+driver vt8235_lpc.o
+driver vt8235_nic.o
+driver vt8235_usb.o
diff -ruN LinuxBIOSv2.02/src/southbridge/via/vt8235/vt8235.c LinuxBIOSv2.03/src/southbridge/via/vt8235/vt8235.c
--- LinuxBIOSv2.02/src/southbridge/via/vt8235/vt8235.c	2005-08-03 15:12:36.979866000 +0100
+++ LinuxBIOSv2.03/src/southbridge/via/vt8235/vt8235.c	2005-08-03 16:29:02.786461250 +0100
@@ -1,267 +1,36 @@
-
-#include <arch/io.h>
+#include <console/console.h>
 #include <device/device.h>
 #include <device/pci.h>
 #include <device/pci_ops.h>
 #include <device/pci_ids.h>
-#include <console/console.h>
+#include <pc80/keyboard.h>
 #include "vt8235.h"
 #include "chip.h"
 
-void rtc_init(int i);
-
-void pc_keyboard_init(void);
+/*
+ * Base VT8235.
+ */
+static device_t lpc_dev;
 
 void hard_reset(void) 
 {
 	printk_err("NO HARD RESET ON VT8235! FIX ME!\n");
 }
 
-static void usb_on(int enable)
-{
-	unsigned char regval;
-
-	/* Base 8235 controller */
-	device_t dev0 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235, 0);
-	/* USB controller 1 */
-	device_t dev1 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, 0);
-	/* USB controller 2 */
-	device_t dev2 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2, dev1);
-	/* USB controller 2 */
-	device_t dev3 = dev_find_device(PCI_VENDOR_ID_VIA, 
-	PCI_DEVICE_ID_VIA_82C586_2, dev2);
-	
-	if(enable){
-        	if(dev0) {
-	    		regval = pci_read_config8(dev0, 0x50);
-	    		regval &= ~(0x36);
-	    		pci_write_config8(dev0, 0x50, regval);
-		}
-
-		/* enable USB1 */
-		if(dev1) {
-	    		pci_write_config8(dev1, 0x04, 0x07);
-		}
-
-		/* enable USB2 */
-		if(dev2) {
-	    		pci_write_config8(dev2, 0x04, 0x07);
-		}
-
-		/* enable USB3 */
-		if(dev3) {
-	    		pci_write_config8(dev3, 0x04, 0x07);
-		}
-
-	}else{
-        	if(dev0) {
-	    		regval = pci_read_config8(dev0, 0x50);
-	    		regval |= 0x36;    
-	    		pci_write_config8(dev0, 0x50, regval);
-		}
-
-		/* disable USB1 */
-		if(dev1) {
-	    		pci_write_config8(dev1, 0x3c, 0x00);
-	    		pci_write_config8(dev1, 0x04, 0x00);
-		}
-
-		/* disable USB2 */
-		if(dev2) {
-	    		pci_write_config8(dev2, 0x3c, 0x00);
-	    		pci_write_config8(dev2, 0x04, 0x00);
-		}
-
-		/* disable USB3 */
-		if(dev3) {
-	    		pci_write_config8(dev3, 0x3c, 0x00);
-	    		pci_write_config8(dev3, 0x04, 0x00);
-		}
-	}
-}
-
-static void keyboard_on(void)
+static void keyboard_on(struct device *dev)
 {
 	unsigned char regval;
 
-	/* Base 8235 controller */
-	device_t dev0 = dev_find_device(PCI_VENDOR_ID_VIA, \
-						PCI_DEVICE_ID_VIA_8235, 0);
+	regval = pci_read_config8(dev, 0x51);
+//	regval |= 0x0f; 
+	/* !!!FIX let's try this */
+	regval |= 0x1d; 
+	pci_write_config8(dev, 0x51, regval);
 
-	if (dev0) {
-		regval = pci_read_config8(dev0, 0x51);
-//		regval |= 0x0f; 
-		/* !!!FIX let's try this */
-		regval |= 0x1d; 
-		pci_write_config8(dev0, 0x51, regval);
-	}
-	pc_keyboard_init();
+	init_pc_keyboard(0x60, 0x64, 0);
 }
 
-static void nvram_on(void)
-{
-	/*
-	 * the VIA 8235 South has a very different nvram setup than the 
-	 * piix4e ...
-	 * turn on ProMedia nvram.
-	 * TO DO: use the PciWriteByte function here.
-	 */
-	
-	/*
-	 * kevinh/Ispiri - I don't think this is the correct address/value
-	 * intel_conf_writeb(0x80008841, 0xFF);
-	 */
-}
-
-
-/*
- * Enable the ethernet device and turn off stepping (because it is integrated 
- * inside the southbridge)
- */
-static void ethernet_fixup()
-{
-	device_t	edev;
-	uint8_t		byte;
-
-	printk_info("Ethernet fixup\n");
-
-	edev = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8233_7, 0);
-	if (edev) {
-		printk_debug("Configuring VIA LAN\n");
-		
-		/* We don't need stepping - though the device supports it */
-		byte = pci_read_config8(edev, PCI_COMMAND);
-		byte &= ~PCI_COMMAND_WAIT;
-		pci_write_config8(edev, PCI_COMMAND, byte);
-	} else {
-		printk_debug("VIA LAN not found\n");
-	}
-}
-
-
-/* we need to do things in this function so that PCI scan will find 
- * them.  One problem here is that we can't use ANY of the new device 
- * stuff. This work here precedes all that.      
- * Fundamental problem with linuxbios V2 architecture.
- * You can't do pci control in the C code without having done a PCI scan.
- * But in some cases you need to to pci control in the c code before doing
- * a PCI scan. But you can't use arch/romcc_io.h (the code you need) because
- * that has functions with the same name but different type signatures
- * (e.g. device_t). This needs to get fixed. We need low-level pci scans
- * in the C code. 
- */
-static void vt8235_pci_enable(struct southbridge_via_vt8235_config *conf) 
-{
-	/*
-	  unsigned long busdevfn = 0x8000;
-	  if (conf->enable_ide) {
-	  printk_debug("%s: enabling IDE function\n", __FUNCTION__);
-	  }
-	*/
-}
-
-/* PIRQ init
- */
-void pci_assign_irqs(unsigned bus, unsigned slot, const unsigned char pIntAtoD[4]);
-
-/* taken some liberties - changed irq structures to pins numbers so that it is easier to
- * change PCI irq assignments without having to change each PCI function individually
- */
-
-/* pciIrqs contains the irqs assigned for PCI pins A-D */
-/* setting will depend on motherboard as irqs can be quite scarce */
-/* e.g on EPIA-MII, 16 bit CF card wants a dedicated IRQ. A 16 bit card in pcmcia socket */
-/* may want another - for now only claim 3 interupts for PCI, leaving at least one spare */
-/* for CF.  */
-/* On EPIA-M one could allocated all four irqs to different numbers since there are no cardbus */
-/* devices */
-
-
-static const unsigned char pciIrqs[4] = { 5 , 9 , 9, 10 };
-
-static const unsigned char usbPins[4] =      { 'A','B','C','D'};
-static const unsigned char enetPins[4] =     { 'A','B','C','D'};
-static const unsigned char slotPins[4] =     { 'B','C','D','A'};
-static const unsigned char firewirePins[4] = { 'B','C','D','A'};
-static const unsigned char vt8235Pins[4] =   { 'A','B','C','D'};
-static const unsigned char vgaPins[4] =      { 'A','B','C','D'};
-static const unsigned char cbPins[4] =       { 'A','B','C','D'};
-static const unsigned char riserPins[4] =    { 'A','B','C','D'};
-/*
-	Our IDSEL mappings are as follows
-	PCI slot is AD31          (device 15) (00:14.0)
-	Southbridge is AD28       (device 12) (00:11.0)
-*/
-static unsigned char *pin_to_irq(const unsigned char *pin)
-{
-	static unsigned char Irqs[4];
-	int i;
-	for (i = 0 ; i < 4 ; i++)
-		Irqs[i] = pciIrqs[ pin[i] - 'A' ];
-
-	return Irqs;
-}
-static void pci_routing_fixup(void)
-{
-	device_t dev;
-
-        dev = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235, 0);
-	printk_info("%s: dev is %p\n", __FUNCTION__, dev);
-	if (dev) {
-		/* initialize PCI interupts - these assignments depend
-		   on the PCB routing of PINTA-D 
-
-		   PINTA = IRQ11
-		   PINTB = IRQ5
-		   PINTC = IRQ10
-		   PINTD = IRQ12
-		*/
-		pci_write_config8(dev, 0x55, pciIrqs[0] << 4);
-		pci_write_config8(dev, 0x56, pciIrqs[1] | (pciIrqs[2] << 4) );
-		pci_write_config8(dev, 0x57, pciIrqs[3] << 4);
-
-	}
-
-
-
-	// firewire built into southbridge
-	printk_info("setting firewire\n");
-	pci_assign_irqs(0, 0x0d, pin_to_irq(firewirePins) );
-
-	// Standard usb components
-	printk_info("setting usb\n");
-	pci_assign_irqs(0, 0x10, pin_to_irq(usbPins) );
-
-	// VT8235 + sound hardware
-	printk_info("setting vt8235\n");
-	pci_assign_irqs(0, 0x11, pin_to_irq(vt8235Pins) );
-
-	// Ethernet built into southbridge
-	printk_info("setting ethernet\n");
-	pci_assign_irqs(0, 0x12, pin_to_irq(enetPins) );
-
-	// VGA
-	printk_info("setting vga\n");
-	pci_assign_irqs(1, 0x00, pin_to_irq(vgaPins) );
-
-	// PCI slot
-	printk_info("setting pci slot\n");
-	pci_assign_irqs(0, 0x14, pin_to_irq(slotPins) );
-
-	// Cardbus slot 
-	printk_info("setting cardbus slot\n");
-	pci_assign_irqs(0, 0x0a, pin_to_irq(cbPins) );
-
-	// Via 2 slot riser card 2nd slot
-	printk_info("setting riser slot\n");
-	pci_assign_irqs(0, 0x13, pin_to_irq(riserPins) );
-
-
-}
-
-
-void
-dump_south(void)
+void dump_south(void)
 {
 	device_t dev0;
 	dev0 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235, 0);
@@ -276,288 +45,26 @@
 	}
 }
 
-void set_led(void)
+void set_led(struct device *dev)
 {
-
 	// set power led to steady now that lxbios has virtually done its job
-	device_t dev0;
-	dev0 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235,0);
-
-	pci_write_config8(dev0,0x94,0xb0);
-
-}
-
-/* set up the power management capabilities directly into ACPI mode */
-/* this avoids having to handle any System Management Interrupts (SMI's) which I can't */
-/* figure out how to do !!!! */ 
-
-void setup_pm(device_t dev0)
-{
-
-	// Set gen config 0
-	pci_write_config8(dev0,0x80,0x20);
-
-	// Set ACPI base address to IO 0x4000
-	pci_write_config16(dev0, 0x88, 0x0401);
-	
-	// set ACPI irq to 5
-	pci_write_config8(dev0,0x82,0x55);
-
-	// primary interupt channel
-	pci_write_config16(dev0,0x84,0x30f2);
-
-	// throttle / stop clock control
-	pci_write_config8(dev0,0x8d,0x18);
-
-	pci_write_config8(dev0,0x93,0x88);
-	//pci_write_config8(dev0,0x94,0xb0);
-	pci_write_config8(dev0,0x95,0xc0);
-	pci_write_config8(dev0,0x98,0);
-	pci_write_config8(dev0,0x99,0xea);
-	pci_write_config8(dev0,0xe4,0x14);
-	pci_write_config8(dev0,0xe5,0x08);
-
-
-	// Enable ACPI access (and setup like award)
-	pci_write_config8(dev0, 0x81, 0x84);
-
-	outw(0xffff,0x400);
-	outw(0xffff,0x420);
-	outw(0xffff,0x428);
-	outl(0xffffffff,0x430);
-	
-	outw(0x0,0x424);
-	outw(0x0,0x42a);
-	outw(0x1,0x42c);
-	outl(0x0,0x434);
-	outl(0x01,0x438);
-	outb(0x0,0x442);
-	outl(0xffff7fff,0x448);
-	outw(0x001,0x404);
-
-
-}
-
-static void vt8235_init(struct southbridge_via_vt8235_config *conf)
-{
-	unsigned char enables;
-	device_t dev0;
-	device_t dev1;
-	//device_t devpwr;
-	//int i;
-
-	// to do: use the pcibios_find function here, instead of 
-	// hard coding the devfn. 
-	// done - kevinh/Ispiri
-	printk_debug("vt8235 init\n");
-	/* Base 8235 controller */
-	dev0 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235, 0);
-	/* IDE controller */
-	dev1 = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_1, 0);
-	/* Power management controller */
-	//devpwr = dev_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235_4, 0);
-
-	// enable the internal I/O decode
-	enables = pci_read_config8(dev0, 0x6C);
-	enables |= 0x80;
-	pci_write_config8(dev0, 0x6C, enables);
-	
-	// Map 4MB of FLASH into the address space
-	pci_write_config8(dev0, 0x41, 0x7f);
-	
-	// Set bit 6 of 0x40, because Award does it (IO recovery time)
-	// IMPORTANT FIX - EISA 0x4d0 decoding must be on so that PCI 
-	// interrupts can be properly marked as level triggered.
-	enables = pci_read_config8(dev0, 0x40);
-	enables |= 0x45;
-	pci_write_config8(dev0, 0x40, enables);
-	
-	// Set 0x42 to 0xf0 to match Award bios
-	enables = pci_read_config8(dev0, 0x42);
-	enables |= 0xf0;
-	pci_write_config8(dev0, 0x42, enables);
-	
-
-	/* Set 0x58 to 0x03 to match Award */
-	pci_write_config8(dev0, 0x58, 0x03);
-
-	/* Set bit 3 of 0x4f to match award (use INIT# as cpu reset) */
-	enables = pci_read_config8(dev0, 0x4f);
-	enables |= 0x08;
-	pci_write_config8(dev0, 0x4f, enables);
-
-
-
-	// Set bit 3 of 0x4a, to match award (dummy pci request)
-	enables = pci_read_config8(dev0, 0x4a);
-	enables |= 0x08;
-	pci_write_config8(dev0, 0x4a, enables);
-	
-	// Set bit 3 of 0x4f to match award (use INIT# as cpu reset)
-	enables = pci_read_config8(dev0, 0x4f);
-	enables |= 0x08;
-	pci_write_config8(dev0, 0x4f, enables);
-	
-	// Set 0x58 to 0x03 to match Award
-	pci_write_config8(dev0, 0x58, 0x03);
-	
-	// enable the ethernet/RTC
-	if(dev0) {
-		enables = pci_read_config8(dev0, 0x51);
-		enables |= 0x18; 
-		pci_write_config8(dev0, 0x51, enables);
-	}
-	
-	
-	/* enable serial irq */
-	pci_write_config8(dev0,0x52,0x9);
-
-	/* dma */
-	pci_write_config8(dev0, 0x53, 0x00);
-
-	/* Use compatability mode - per award bios */
-	pci_write_config32(dev1, 0x10, 0x0);
-	pci_write_config32(dev1, 0x14, 0x0);
-	pci_write_config32(dev1, 0x18, 0x0);
-	pci_write_config32(dev1, 0x1c, 0x0);
-
-
-	// Power management setup
-	setup_pm(dev0);
-	
-	//
-	//
-	// IDE setup
-	//
-	if (! conf->enable_native_ide) {
-		// Run the IDE controller in 'compatiblity mode - i.e. don't use PCI
-		// interrupts.  Using PCI ints confuses linux for some reason.
-		
-		printk_info("%s: enabling compatibility IDE addresses\n", __FUNCTION__);
-		enables = pci_read_config8(dev1, 0x42);
-		printk_debug("enables in reg 0x42 0x%x\n", enables);
-		enables &= ~0xc0;		// compatability mode
-		pci_write_config8(dev1, 0x42, enables);
-		enables = pci_read_config8(dev1, 0x42);
-		printk_debug("enables in reg 0x42 read back as 0x%x\n", enables);
-	}
-	
-	enables = pci_read_config8(dev1, 0x40);
-	printk_debug("enables in reg 0x40 0x%x\n", enables);
-	enables |= 3;
-	pci_write_config8(dev1, 0x40, enables);
-	enables = pci_read_config8(dev1, 0x40);
-	printk_debug("enables in reg 0x40 read back as 0x%x\n", enables);
-	
-	// Enable prefetch buffers
-	enables = pci_read_config8(dev1, 0x41);
-	enables |= 0xf0;
-	pci_write_config8(dev1, 0x41, enables);
-	
-	// Lower thresholds (cause award does it)
-	enables = pci_read_config8(dev1, 0x43);
-	enables &= ~0x0f;
-	enables |=  0x05;
-	pci_write_config8(dev1, 0x43, enables);
-	
-	// PIO read prefetch counter (cause award does it)
-	pci_write_config8(dev1, 0x44, 0x18);
-	
-	// Use memory read multiple
-	pci_write_config8(dev1, 0x45, 0x1c);
-	
-	// address decoding. 
-	// we want "flexible", i.e. 1f0-1f7 etc. or native PCI
-	// kevinh at ispiri.com - the standard linux drivers seem ass slow when 
-	// used in native mode - I've changed back to classic
-	enables = pci_read_config8(dev1, 0x9);
-	printk_debug("enables in reg 0x9 0x%x\n", enables);
-	// by the book, set the low-order nibble to 0xa. 
-	if (conf->enable_native_ide) {
-		enables &= ~0xf;
-		// cf/cg silicon needs an 'f' here. 
-		enables |= 0xf;
-	} else {
-		enables &= ~0x5;
-	}
-	
-	pci_write_config8(dev1, 0x9, enables);
-	enables = pci_read_config8(dev1, 0x9);
-	printk_debug("enables in reg 0x9 read back as 0x%x\n", enables);
-	
-	// standard bios sets master bit. 
-	enables = pci_read_config8(dev1, 0x4);
-	printk_debug("command in reg 0x4 0x%x\n", enables);
-	enables |= 7;
-	
-	// No need for stepping - kevinh at ispiri.com
-	enables &= ~0x80;
-	
-	pci_write_config8(dev1, 0x4, enables);
-	enables = pci_read_config8(dev1, 0x4);
-	printk_debug("command in reg 0x4 reads back as 0x%x\n", enables);
-	
-	if (! conf->enable_native_ide) {
-		// Use compatability mode - per award bios
-		pci_write_config32(dev1, 0x10, 0x0);
-		pci_write_config32(dev1, 0x14, 0x0);
-		pci_write_config32(dev1, 0x18, 0x0);
-		pci_write_config32(dev1, 0x1c, 0x0);
-		
-		// Force interrupts to use compat mode - just like Award bios
-		pci_write_config8(dev1, 0x3d, 00);
-		pci_write_config8(dev1, 0x3c, 0xff);
-	}
-	
-	
-	/* set up isa bus -- i/o recovery time, rom write enable, extend-ale */
-	pci_write_config8(dev0, 0x40, 0x54);
-	ethernet_fixup();
-	
-	// Start the rtc
-	rtc_init(0);
-
-
+	pci_write_config8(dev, 0x94, 0xb0);
 }
 
-static void southbridge_init(struct chip *chip, enum chip_pass pass)
+static void vt8235_enable(struct device *dev)
 {
+	struct southbridge_via_vt8235_config *conf = dev->chip_info;
 
-	struct southbridge_via_vt8235_config *conf = 
-		(struct southbridge_via_vt8235_config *)chip->chip_info;
-
-	switch (pass) {
-	case CONF_PASS_PRE_PCI:
-		vt8235_pci_enable(conf);
-		break;
-		
-	case CONF_PASS_POST_PCI:
-		/* initialise the PIC - particularly so that VGA bios init code 
-                   doesn't get nasty unknown interupt vectors when it tries to establish 
-                   its interrupts. */
-		setup_i8259();
-		vt8235_init(conf);
-		pci_routing_fixup();
-		usb_on(1);
-		keyboard_on();
-		vga_fixup();
-
-
-
-		break;
-
-	case CONF_PASS_PRE_BOOT:
-		dump_south();
-		set_led();
-		break;
-		
-	default:
-		/* nothing yet */
-		break;
+	printk_debug("In vt8235_enable.\n");
+	if (!lpc_dev) {
+		lpc_dev = dev_find_device(PCI_VENDOR_ID_VIA,
+				PCI_DEVICE_ID_VIA_8235, 0);
+		if (conf->enable_keyboard)
+			keyboard_on(lpc_dev);
 	}
 }
 
-struct chip_operations southbridge_via_vt8235_control = {
+struct chip_operations southbridge_via_vt8235_ops = {
 	CHIP_NAME("VIA vt8235")
-	.enable    = southbridge_init,
+	.enable_dev = vt8235_enable,
 };
diff -ruN LinuxBIOSv2.02/src/southbridge/via/vt8235/vt8235_ide.c LinuxBIOSv2.03/src/southbridge/via/vt8235/vt8235_ide.c
--- LinuxBIOSv2.02/src/southbridge/via/vt8235/vt8235_ide.c	1970-01-01 01:00:00.000000000 +0100
+++ LinuxBIOSv2.03/src/southbridge/via/vt8235/vt8235_ide.c	2005-08-03 16:29:17.171360250 +0100
@@ -0,0 +1,114 @@
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ops.h>
+#include <device/pci_ids.h>
+#include <console/console.h>
+#include "vt8235.h"
+#include "chip.h"
+
+static void ide_init(struct device *dev)
+{
+	struct southbridge_via_vt8235_config *conf = dev->chip_info;
+	unsigned char enables;
+
+	printk_info("Enabling VIA IDE.\n");
+
+	if (!conf->enable_native_ide) {
+		/*
+		 * Run the IDE controller in 'compatiblity mode - i.e. don't
+		 * use PCI interrupts.  Using PCI ints confuses linux for some
+		 * reason.
+		 */
+		printk_info("%s: enabling compatibility IDE addresses\n",
+				__FUNCTION__);
+		enables = pci_read_config8(dev, 0x42);
+		printk_debug("enables in reg 0x42 0x%x\n", enables);
+		enables &= ~0xc0;		// compatability mode
+		pci_write_config8(dev, 0x42, enables);
+		enables = pci_read_config8(dev, 0x42);
+		printk_debug("enables in reg 0x42 read back as 0x%x\n",
+				enables);
+	}
+	
+	enables = pci_read_config8(dev, 0x40);
+	printk_debug("enables in reg 0x40 0x%x\n", enables);
+	enables |= 3;
+	pci_write_config8(dev, 0x40, enables);
+	enables = pci_read_config8(dev, 0x40);
+	printk_debug("enables in reg 0x40 read back as 0x%x\n", enables);
+	
+	// Enable prefetch buffers
+	enables = pci_read_config8(dev, 0x41);
+	enables |= 0xf0;
+	pci_write_config8(dev, 0x41, enables);
+	
+	// Lower thresholds (cause award does it)
+	enables = pci_read_config8(dev, 0x43);
+	enables &= ~0x0f;
+	enables |=  0x05;
+	pci_write_config8(dev, 0x43, enables);
+	
+	// PIO read prefetch counter (cause award does it)
+	pci_write_config8(dev, 0x44, 0x18);
+	
+	// Use memory read multiple
+	pci_write_config8(dev, 0x45, 0x1c);
+	
+	// address decoding. 
+	// we want "flexible", i.e. 1f0-1f7 etc. or native PCI
+	// kevinh at ispiri.com - the standard linux drivers seem ass slow when 
+	// used in native mode - I've changed back to classic
+	enables = pci_read_config8(dev, 0x9);
+	printk_debug("enables in reg 0x9 0x%x\n", enables);
+	// by the book, set the low-order nibble to 0xa. 
+	if (conf->enable_native_ide) {
+		enables &= ~0xf;
+		// cf/cg silicon needs an 'f' here. 
+		enables |= 0xf;
+	} else {
+		enables &= ~0x5;
+	}
+	
+	pci_write_config8(dev, 0x9, enables);
+	enables = pci_read_config8(dev, 0x9);
+	printk_debug("enables in reg 0x9 read back as 0x%x\n", enables);
+	
+	// standard bios sets master bit. 
+	enables = pci_read_config8(dev, 0x4);
+	printk_debug("command in reg 0x4 0x%x\n", enables);
+	enables |= 7;
+	
+	// No need for stepping - kevinh at ispiri.com
+	enables &= ~0x80;
+	
+	pci_write_config8(dev, 0x4, enables);
+	enables = pci_read_config8(dev, 0x4);
+	printk_debug("command in reg 0x4 reads back as 0x%x\n", enables);
+	
+	if (!conf->enable_native_ide) {
+		// Use compatability mode - per award bios
+		pci_write_config32(dev, 0x10, 0x0);
+		pci_write_config32(dev, 0x14, 0x0);
+		pci_write_config32(dev, 0x18, 0x0);
+		pci_write_config32(dev, 0x1c, 0x0);
+		
+		// Force interrupts to use compat mode - just like Award bios
+		pci_write_config8(dev, 0x3d, 0x0);
+		pci_write_config8(dev, 0x3c, 0xff);
+	}
+}
+
+static struct device_operations ide_ops = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = ide_init,
+	.enable           = 0,
+	.ops_pci          = 0, 
+};
+
+static struct pci_driver northbridge_driver __pci_driver = { 
+	.ops    = &ide_ops,
+	.vendor = PCI_VENDOR_ID_VIA,
+	.device = PCI_DEVICE_ID_VIA_82C586_1,
+};
diff -ruN LinuxBIOSv2.02/src/southbridge/via/vt8235/vt8235_lpc.c LinuxBIOSv2.03/src/southbridge/via/vt8235/vt8235_lpc.c
--- LinuxBIOSv2.02/src/southbridge/via/vt8235/vt8235_lpc.c	1970-01-01 01:00:00.000000000 +0100
+++ LinuxBIOSv2.03/src/southbridge/via/vt8235/vt8235_lpc.c	2005-08-03 16:29:26.003912250 +0100
@@ -0,0 +1,245 @@
+#include <arch/io.h>
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ops.h>
+#include <device/pci_ids.h>
+
+#include <pc80/mc146818rtc.h>
+
+#include "vt8235.h"
+#include "chip.h"
+
+/*
+ * Taken some liberties - changed irq structures to pins numbers so that it is
+ * easier to change PCI irq assignments without having to change each PCI
+ * function individually
+ * 
+ * pciIrqs contains the irqs assigned for PCI pins A-D
+ * 
+ * Setting will depend on motherboard as irqs can be quite scarce e.g on
+ * EPIA-MII, 16 bit CF card wants a dedicated IRQ. A 16 bit card in pcmcia
+ * socket may want another - for now only claim 3 interupts for PCI, leaving at
+ * least one spare for CF.  On EPIA-M one could allocated all four irqs to
+ * different numbers since there are no cardbus devices
+ */
+
+static const unsigned char pciIrqs[4] = { 11 , 5, 10 , 12 };
+
+static const unsigned char usbPins[4] =      { 'A','B','C','D'};
+static const unsigned char enetPins[4] =     { 'A','B','C','D'};
+static const unsigned char slotPins[4] =     { 'B','C','D','A'};
+static const unsigned char firewirePins[4] = { 'B','C','D','A'};
+static const unsigned char vt8235Pins[4] =   { 'A','B','C','D'};
+static const unsigned char vgaPins[4] =      { 'A','B','C','D'};
+static const unsigned char cbPins[4] =       { 'A','B','C','D'};
+static const unsigned char riserPins[4] =    { 'A','B','C','D'};
+
+/*
+	Our IDSEL mappings are as follows
+	PCI slot is AD31          (device 15) (00:14.0)
+	Southbridge is AD28       (device 12) (00:11.0)
+*/
+
+static unsigned char *pin_to_irq(const unsigned char *pin)
+{
+	static unsigned char Irqs[4];
+	int i;
+	for (i = 0 ; i < 4 ; i++)
+		Irqs[i] = pciIrqs[ pin[i] - 'A' ];
+
+	return Irqs;
+}
+
+static void pci_routing_fixup(struct device *dev)
+{
+	printk_info("%s: dev is %p\n", __FUNCTION__, dev);
+	if (dev) {
+		/* initialize PCI interupts - these assignments depend
+		   on the PCB routing of PINTA-D 
+
+		   PINTA = IRQ11
+		   PINTB = IRQ5
+		   PINTC = IRQ10
+		   PINTD = IRQ12
+		*/
+		pci_write_config8(dev, 0x55, pciIrqs[0] << 4);
+		pci_write_config8(dev, 0x56, pciIrqs[1] | (pciIrqs[2] << 4) );
+		pci_write_config8(dev, 0x57, pciIrqs[3] << 4);
+	}
+
+	// firewire built into southbridge
+	printk_info("setting firewire\n");
+	pci_assign_irqs(0, 0x0d, pin_to_irq(firewirePins));
+
+	// Standard usb components
+	printk_info("setting usb\n");
+	pci_assign_irqs(0, 0x10, pin_to_irq(usbPins));
+
+	// VT8235 + sound hardware
+	printk_info("setting vt8235\n");
+	pci_assign_irqs(0, 0x11, pin_to_irq(vt8235Pins));
+
+	// Ethernet built into southbridge
+	printk_info("setting ethernet\n");
+	pci_assign_irqs(0, 0x12, pin_to_irq(enetPins));
+
+	// VGA
+	printk_info("setting vga\n");
+	pci_assign_irqs(1, 0x00, pin_to_irq(vgaPins));
+
+	// PCI slot
+	printk_info("setting pci slot\n");
+	pci_assign_irqs(0, 0x14, pin_to_irq(slotPins));
+
+	// Cardbus slot 
+	printk_info("setting cardbus slot\n");
+	pci_assign_irqs(0, 0x0a, pin_to_irq(cbPins));
+
+	// Via 2 slot riser card 2nd slot
+	printk_info("setting riser slot\n");
+	pci_assign_irqs(0, 0x13, pin_to_irq(riserPins));
+
+	printk_spew("%s: DONE\n", __FUNCTION__);
+}
+
+/* 
+ * Set up the power management capabilities directly into ACPI mode.  This
+ * avoids having to handle any System Management Interrupts (SMI's) which I
+ * can't figure out how to do !!!!
+ */ 
+
+void setup_pm(device_t dev)
+{
+
+	// Set gen config 0
+	pci_write_config8(dev, 0x80, 0x20);
+
+	// Set ACPI base address to IO 0x4000
+	pci_write_config16(dev, 0x88, 0x0401);
+	
+	// set ACPI irq to 5
+	pci_write_config8(dev, 0x82, 0x45);
+
+	// primary interupt channel
+	pci_write_config16(dev, 0x84, 0x30f2);
+
+	// throttle / stop clock control
+	pci_write_config8(dev, 0x8d, 0x18);
+
+	pci_write_config8(dev, 0x93, 0x88);
+	pci_write_config8(dev, 0x94, 0xb0);
+	pci_write_config8(dev, 0x95, 0xc0);
+	pci_write_config8(dev, 0x98, 0);
+	pci_write_config8(dev, 0x99, 0xea);
+	pci_write_config8(dev, 0xe4, 0x14);
+	pci_write_config8(dev, 0xe5, 0x08);
+
+
+	// Enable ACPI access (and setup like award)
+	pci_write_config8(dev, 0x81, 0x84);
+
+	outw(0xffff, 0x400);
+	outw(0xffff, 0x420);
+	outw(0xffff, 0x428);
+	outl(0xffffffff, 0x430);
+	
+	outw(0x0, 0x424);
+	outw(0x0, 0x42a);
+	outw(0x1, 0x42c);
+	outl(0x0, 0x434);
+	outl(0x01, 0x438);
+	outb(0x0, 0x442);
+	outl(0xffff7fff, 0x448);
+	outw(0x001, 0x404);
+}
+
+static void vt8235_init(struct device *dev)
+{
+	unsigned char enables;
+	
+	printk_debug("vt8235 init\n");
+
+	// enable the internal I/O decode
+	enables = pci_read_config8(dev, 0x6C);
+	enables |= 0x80;
+	pci_write_config8(dev, 0x6C, enables);
+	
+	// Map 4MB of FLASH into the address space
+	pci_write_config8(dev, 0x41, 0x7f);
+	
+	// Set bit 6 of 0x40, because Award does it (IO recovery time)
+	// IMPORTANT FIX - EISA 0x4d0 decoding must be on so that PCI 
+	// interrupts can be properly marked as level triggered.
+	enables = pci_read_config8(dev, 0x40);
+	enables |= 0x45;
+	pci_write_config8(dev, 0x40, enables);
+	
+	// Set 0x42 to 0xf0 to match Award bios
+	enables = pci_read_config8(dev, 0x42);
+	enables |= 0xf0;
+	pci_write_config8(dev, 0x42, enables);
+	
+	/* Set 0x58 to 0x03 to match Award */
+	pci_write_config8(dev, 0x58, 0x03);
+
+	/* Set bit 3 of 0x4f to match award (use INIT# as cpu reset) */
+	enables = pci_read_config8(dev, 0x4f);
+	enables |= 0x08;
+	pci_write_config8(dev, 0x4f, enables);
+
+	// Set bit 3 of 0x4a, to match award (dummy pci request)
+	enables = pci_read_config8(dev, 0x4a);
+	enables |= 0x08;
+	pci_write_config8(dev, 0x4a, enables);
+	
+	// Set bit 3 of 0x4f to match award (use INIT# as cpu reset)
+	enables = pci_read_config8(dev, 0x4f);
+	enables |= 0x08;
+	pci_write_config8(dev, 0x4f, enables);
+	
+	// Set 0x58 to 0x03 to match Award
+	pci_write_config8(dev, 0x58, 0x03);
+	
+	// enable the ethernet/RTC
+	if (dev) {
+		enables = pci_read_config8(dev, 0x51);
+		enables |= 0x18; 
+		pci_write_config8(dev, 0x51, enables);
+	}
+	
+	/* enable serial irq */
+	pci_write_config8(dev, 0x52, 0x9);
+
+	/* dma */
+	pci_write_config8(dev, 0x53, 0x00);
+
+	// Power management setup
+	setup_pm(dev);
+	
+	/* set up isa bus -- i/o recovery time, rom write enable, extend-ale */
+	pci_write_config8(dev, 0x40, 0x54);
+	
+	// Start the rtc
+	rtc_init(0);
+}
+
+static void southbridge_init(struct device *dev)
+{
+	vt8235_init(dev);
+	pci_routing_fixup(dev);
+}
+
+static struct device_operations vt8235_lpc_ops = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = &southbridge_init,
+	.scan_bus         = scan_static_bus,
+};
+
+static struct pci_driver lpc_driver __pci_driver = {
+	.ops    = &vt8235_lpc_ops,
+	.vendor = PCI_VENDOR_ID_VIA,
+	.device = PCI_DEVICE_ID_VIA_8235,
+};
diff -ruN LinuxBIOSv2.02/src/southbridge/via/vt8235/vt8235_nic.c LinuxBIOSv2.03/src/southbridge/via/vt8235/vt8235_nic.c
--- LinuxBIOSv2.02/src/southbridge/via/vt8235/vt8235_nic.c	1970-01-01 01:00:00.000000000 +0100
+++ LinuxBIOSv2.03/src/southbridge/via/vt8235/vt8235_nic.c	2005-08-03 16:29:34.272429000 +0100
@@ -0,0 +1,37 @@
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ops.h>
+#include <device/pci_ids.h>
+#include "vt8235.h"
+
+/*
+ * Enable the ethernet device and turn off stepping (because it is integrated 
+ * inside the southbridge)
+ */
+static void nic_init(struct device *dev)
+{
+	uint8_t	byte;
+
+	printk_debug("Configuring VIA Rhine LAN\n");
+
+	/* We don't need stepping - though the device supports it */
+	byte = pci_read_config8(dev, PCI_COMMAND);
+	byte &= ~PCI_COMMAND_WAIT;
+	pci_write_config8(dev, PCI_COMMAND, byte);
+}
+
+static struct device_operations nic_ops = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = nic_init,
+	.enable           = 0,
+	.ops_pci          = 0,
+};
+
+static struct pci_driver northbridge_driver __pci_driver = {
+	.ops    = &nic_ops,
+	.vendor = PCI_VENDOR_ID_VIA,
+	.device = PCI_DEVICE_ID_VIA_8233_7,
+};
diff -ruN LinuxBIOSv2.02/src/southbridge/via/vt8235/vt8235_usb.c LinuxBIOSv2.03/src/southbridge/via/vt8235/vt8235_usb.c
--- LinuxBIOSv2.02/src/southbridge/via/vt8235/vt8235_usb.c	1970-01-01 01:00:00.000000000 +0100
+++ LinuxBIOSv2.03/src/southbridge/via/vt8235/vt8235_usb.c	2005-08-03 16:29:40.604824750 +0100
@@ -0,0 +1,41 @@
+#include <console/console.h>
+#include <device/device.h>
+#include <device/pci.h>
+#include <device/pci_ops.h>
+#include <device/pci_ids.h>
+#include "vt8235.h"
+
+static void usb_init(struct device *dev)
+{
+	printk_debug("Configuring VIA USB 1.1\n");
+
+	pci_write_config8(dev, 0x04, 0x07);
+
+	/*
+	 * To disable; though do we need to do this?
+    		pci_write_config8(dev1, 0x3c, 0x00);
+    		pci_write_config8(dev1, 0x04, 0x00);
+
+	   Also, on the root dev, for enable:
+	   	regval = pci_read_config8(dev0, 0x50);
+		regval &= ~(0x36);
+		pci_write_config8(dev0, 0x50, regval);
+
+		(regval |= 0x36; for disable)
+	 */
+}
+
+static struct device_operations usb_ops = {
+	.read_resources   = pci_dev_read_resources,
+	.set_resources    = pci_dev_set_resources,
+	.enable_resources = pci_dev_enable_resources,
+	.init             = usb_init,
+	.enable           = 0,
+	.ops_pci          = 0,
+};
+
+static struct pci_driver northbridge_driver __pci_driver = {
+	.ops    = &usb_ops,
+	.vendor = PCI_VENDOR_ID_VIA,
+	.device = PCI_DEVICE_ID_VIA_82C586_2,
+};
-------------- next part --------------
diff -ruN LinuxBIOSv2.03/src/mainboard/via/epia-m/Config.lb LinuxBIOSv2.04/src/mainboard/via/epia-m/Config.lb
--- LinuxBIOSv2.03/src/mainboard/via/epia-m/Config.lb	2005-08-03 15:12:56.161065000 +0100
+++ LinuxBIOSv2.04/src/mainboard/via/epia-m/Config.lb	2005-08-03 16:35:39.375246500 +0100
@@ -138,8 +138,20 @@
 			register "enable_com_ports" = "1"
 			register "enable_keyboard" = "0"
 			register "enable_nvram" = "1"
-		end
-		chip southbridge/ricoh/rl5c476
+
+			device pci 10.0 on end # USB 1.1
+			device pci 10.1 on end # USB 1.1
+			device pci 10.2 on end # USB 1.1
+			device pci 10.3 on end # USB 2
+
+			device pci 11.0 on      # Southbridge
+			end
+			
+			device pci 11.1 on  end # IDE
+			# 2-4 non existant?
+			device pci 11.5 on  end # AC97 Audio
+			device pci 11.6 off end # AC97 Modem
+			device pci 12.0 on end  # Ethernet
 		end
 		chip superio/via/vt1211 
 			register "enable_com_ports" = "1"
@@ -147,7 +159,11 @@
 			register "enable_lpt" = "1"
 			register "enable_fdc" = "1"
 		end
-		chip cpu/via/model_centaur 
-		end
+#		This is on the EPIA MII, not the M.
+#		chip southbridge/ricoh/rl5c476
+#		end
+	end
+
+	chip cpu/via/model_centaur 
 	end
 end
-------------- next part --------------
diff -ruN LinuxBIOSv2.04/src/include/device/pci_ids.h LinuxBIOSv2.05/src/include/device/pci_ids.h
--- LinuxBIOSv2.04/src/include/device/pci_ids.h	2005-08-03 15:12:48.148564000 +0100
+++ LinuxBIOSv2.05/src/include/device/pci_ids.h	2005-08-03 18:01:46.534173750 +0100
@@ -1060,6 +1060,8 @@
 #define PCI_DEVICE_ID_VIA_8233C_0	0x3109
 #define PCI_DEVICE_ID_VIA_8361		0x3112
 #define PCI_DEVICE_ID_VIA_8233A		0x3147
+#define PCI_DEVICE_ID_VIA_CLE266_VGA	0x3122
+#define PCI_DEVICE_ID_VIA_8623		0x3123
 #define PCI_DEVICE_ID_VIA_86C100A	0x6100
 #define PCI_DEVICE_ID_VIA_8231		0x8231
 #define PCI_DEVICE_ID_VIA_8231_4	0x8235
diff -ruN LinuxBIOSv2.04/src/northbridge/via/vt8623/chip.h LinuxBIOSv2.05/src/northbridge/via/vt8623/chip.h
--- LinuxBIOSv2.04/src/northbridge/via/vt8623/chip.h	2005-08-03 15:13:16.862358000 +0100
+++ LinuxBIOSv2.05/src/northbridge/via/vt8623/chip.h	2005-08-03 16:38:42.298678500 +0100
@@ -2,4 +2,4 @@
 {
 };
 
-extern struct chip_operations northbridge_via_vt8623_control;
+extern struct chip_operations northbridge_via_vt8623_ops;
diff -ruN LinuxBIOSv2.04/src/northbridge/via/vt8623/northbridge.c LinuxBIOSv2.05/src/northbridge/via/vt8623/northbridge.c
--- LinuxBIOSv2.04/src/northbridge/via/vt8623/northbridge.c	2005-08-03 15:13:16.862358000 +0100
+++ LinuxBIOSv2.05/src/northbridge/via/vt8623/northbridge.c	2005-08-03 18:05:49.913384000 +0100
@@ -8,7 +8,8 @@
 #include <stdlib.h>
 #include <string.h>
 #include <bitops.h>
-#include <cpu/p6/mtrr.h>
+#include <cpu/cpu.h>
+#include <cpu/x86/mtrr.h>
 #include "chip.h"
 #include "northbridge.h"
 
@@ -18,7 +19,7 @@
  * slower than normal, ethernet drops packets).
  * Apparently these registers govern some sort of bus master behavior.
  */
-static void norhbrige_init(device_t dev) 
+static void northbridge_init(device_t dev) 
 {
 	device_t fb_dev;
 	unsigned long fb;
@@ -60,15 +61,13 @@
 	.read_resources   = pci_dev_read_resources,
 	.set_resources    = pci_dev_set_resources,
 	.enable_resources = pci_dev_enable_resources,
-	.init             = northbridge_init,
-	.scan_bus         = pci_scan_bridge,
-	.ops_pci          = 0,
+	.init             = northbridge_init
 };
 
 static struct pci_driver northbridge_driver __pci_driver = {
-	.ops = &northbridge_ops,
+	.ops = &northbridge_operations,
 	.vendor = PCI_VENDOR_ID_VIA,
-	.device = 0x3123,
+	.device = PCI_DEVICE_ID_VIA_8623,
 };
 
 static void agp_init(device_t dev)
@@ -93,23 +92,25 @@
 };
 
 static struct pci_driver agp_driver __pci_driver = {
-	.ops = &agp_ops,
+	.ops = &agp_operations,
 	.vendor = PCI_VENDOR_ID_VIA,
-	.device = 0xb091,
+	.device = PCI_DEVICE_ID_VIA_8633_1,
 };
 
 static void vga_init(device_t dev)
 {
-	unsigned long fb;
+//	unsigned long fb;
 
 	printk_debug("VGA random fixup ...\n");
 	pci_write_config8(dev, 0x04, 0x07);
 	pci_write_config8(dev, 0x0d, 0x20);
 	
-	/* Set the vga mtrrs */
+	/* Set the vga mtrrs - disable for the moment */
+#if 0
 	add_var_mtrr( 0xd0000000 >> 10, 0x08000000>>10, MTRR_TYPE_WRCOMB);
 	fb = pci_read_config32(dev,0x10); // get the fb address
 	add_var_mtrr( fb>>10, 8192, MTRR_TYPE_WRCOMB);
+#endif
 }
 
 static struct device_operations vga_operations = {
@@ -121,7 +122,7 @@
 };
 
 static struct pci_driver vga_driver __pci_driver = {
-	.ops = &vga_ops,
+	.ops = &vga_operations,
 	.vendor = PCI_VENDOR_ID_VIA,
 	.device = 0x3122,
 };
@@ -132,17 +133,22 @@
 static void pci_domain_read_resources(device_t dev)
 {
         struct resource *resource;
-        unsigned reg;
+
+	printk_spew("Entering vt8623 pci_domain_read_resources.\n");
 
         /* Initialize the system wide io space constraints */
         resource = new_resource(dev, IOINDEX_SUBTRACTIVE(0,0));
         resource->limit = 0xffffUL;
-        resource->flags = IORESOURCE_IO | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+        resource->flags = IORESOURCE_IO | IORESOURCE_SUBTRACTIVE |
+		IORESOURCE_ASSIGNED;
 
         /* Initialize the system wide memory resources constraints */
         resource = new_resource(dev, IOINDEX_SUBTRACTIVE(1,0));
         resource->limit = 0xffffffffULL;
-        resource->flags = IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE | IORESOURCE_ASSIGNED;
+        resource->flags = IORESOURCE_MEM | IORESOURCE_SUBTRACTIVE |
+		IORESOURCE_ASSIGNED;
+
+	printk_spew("Leaving vt8623 pci_domain_read_resources.\n");
 }
 
 static void ram_resource(device_t dev, unsigned long index,
@@ -187,10 +193,11 @@
 static void pci_domain_set_resources(device_t dev)
 {
 	static const uint8_t ramregs[] = {0x5a, 0x5b, 0x5c, 0x5d };
-        struct resource *resource, *last;
 	device_t mc_dev;
         uint32_t pci_tolm;
 
+	printk_spew("Entering vt8623 pci_domain_set_resources.\n");
+
         pci_tolm = find_pci_tolm(&dev->link[0]);
 	mc_dev = dev->link[0].children;
 	if (mc_dev) {
@@ -214,7 +221,7 @@
 					ramregs[i]);
 		}
 		printk_debug("I would set ram size to 0x%x Kbytes\n", (rambits)*16*1024);
-		tomk = ramreg*16*1024 - 32768;
+		tomk = rambits*16*1024 - 32768;
 		/* Compute the top of Low memory */
 		tolmk = pci_tolm >> 10;
 		if (tolmk >= tomk) {
@@ -232,6 +239,8 @@
 
 static unsigned int pci_domain_scan_bus(device_t dev, unsigned int max)
 {
+	printk_spew("Entering vt8623 pci_domain_scan_bus.\n");
+
         max = pci_scan_bus(&dev->link[0], PCI_DEVFN(0, 0), 0xff, max);
         return max;
 }
@@ -263,7 +272,7 @@
 
 static void enable_dev(struct device *dev)
 {
-        struct device_path path;
+	printk_spew("In vt8623 enable_dev for device %s.\n", dev_path(dev));
 
         /* Set the operations if it is a special bus type */
         if (dev->path.type == DEVICE_PATH_PCI_DOMAIN) {
@@ -275,7 +284,7 @@
         }
 }
 
-struct chip_operations northbridge_via_vt8623_control = {
+struct chip_operations northbridge_via_vt8623_ops = {
 	CHIP_NAME("VIA vt8623 Northbridge")
 	.enable_dev = enable_dev,
 };
diff -ruN LinuxBIOSv2.04/src/northbridge/via/vt8623/raminit.c LinuxBIOSv2.05/src/northbridge/via/vt8623/raminit.c
--- LinuxBIOSv2.04/src/northbridge/via/vt8623/raminit.c	2005-08-03 15:13:16.862358000 +0100
+++ LinuxBIOSv2.05/src/northbridge/via/vt8623/raminit.c	2005-08-03 18:01:40.397790250 +0100
@@ -110,7 +110,7 @@
 	north = pci_locate_device(PCI_ID(0x1106, 0x3123), 0);
 	north = 0;
 	print_debug_hex32(north);
-	print_debug(" is the north\n");
+	print_debug(" is the north\r\n");
 	print_debug_hex16(pci_read_config16(north, 0));
 	print_debug(" ");
 	print_debug_hex16(pci_read_config16(north, 2));
@@ -250,7 +250,7 @@
 	
 	val = (Trp << 7) | (Tras << 6) | (casl << 4) | 4;
 	
-	print_debug_hex8(val); print_debug(" is the computed timing\n");
+	print_debug_hex8(val); print_debug(" is the computed timing\r\n");
 	/* don't set it. Experience shows that this screwy chipset should just
 	 * be run with the most conservative timing.
 	 * pci_write_config8(0, 0x64, val);
-------------- next part --------------
diff -ruN LinuxBIOSv2.05/src/mainboard/via/epia-m/Config.lb LinuxBIOSv2.06/src/mainboard/via/epia-m/Config.lb
--- LinuxBIOSv2.05/src/mainboard/via/epia-m/Config.lb	2005-08-03 16:35:39.375246000 +0100
+++ LinuxBIOSv2.06/src/mainboard/via/epia-m/Config.lb	2005-08-03 18:15:51.238964500 +0100
@@ -145,6 +145,30 @@
 			device pci 10.3 on end # USB 2
 
 			device pci 11.0 on      # Southbridge
+				chip superio/via/vt1211
+					device pnp 2e.0 on	# Floppy
+						io 0x60 = 0x3f0
+						irq 0x70 = 6
+						drq 0x74 = 2
+					end
+					device pnp 2e.1 off	# Parallel Port
+						io 0x60 = 0x378
+						irq 0x70 = 7
+						drq 0x74 = 3
+					end
+					device pnp 2e.2 on	# COM1
+						io 0x60 = 0x3f8
+						irq 0x70 = 4
+					end
+					device pnp 2e.3 on	# COM2
+						io 0x60 = 0x2f8
+						irq 0x70 = 3
+					end
+					device pnp 2e.b on	# HWM
+						io 0x60 = 0xec00
+					end
+
+				end
 			end
 			
 			device pci 11.1 on  end # IDE
@@ -153,12 +177,6 @@
 			device pci 11.6 off end # AC97 Modem
 			device pci 12.0 on end  # Ethernet
 		end
-		chip superio/via/vt1211 
-			register "enable_com_ports" = "1"
-			register "enable_hwmon" = "1"
-			register "enable_lpt" = "1"
-			register "enable_fdc" = "1"
-		end
 #		This is on the EPIA MII, not the M.
 #		chip southbridge/ricoh/rl5c476
 #		end
diff -ruN LinuxBIOSv2.05/src/superio/via/vt1211/chip.h LinuxBIOSv2.06/src/superio/via/vt1211/chip.h
--- LinuxBIOSv2.05/src/superio/via/vt1211/chip.h	2005-08-03 15:12:49.108624000 +0100
+++ LinuxBIOSv2.06/src/superio/via/vt1211/chip.h	2005-08-03 18:16:33.913631500 +0100
@@ -1,19 +1,12 @@
 #ifndef _SUPERIO_VIA_VT1211
 #define _SUPERIO_VIA_VT1211
 
-extern struct chip_operations superio_via_vt1211_control;
+#include <uart8250.h>
+
+extern struct chip_operations superio_via_vt1211_ops;
 
 struct superio_via_vt1211_config {
-	/* PCI function enables */
-	/* i.e. so that pci scan bus will find them. */
-	/* I am putting in IDE as an example but obviously this needs
-	 * to be more complete!
-	 */
-	/* enables of functions of devices */
-	int enable_com_ports;
-	int enable_fdc;
-	int enable_lpt;
-	int enable_hwmon;
+	struct uart8250 com1, com2;
 };
 
 #endif /* _SUPERIO_VIA_VT1211 */
diff -ruN LinuxBIOSv2.05/src/superio/via/vt1211/vt1211.c LinuxBIOSv2.06/src/superio/via/vt1211/vt1211.c
--- LinuxBIOSv2.05/src/superio/via/vt1211/vt1211.c	2005-08-03 15:12:49.108624000 +0100
+++ LinuxBIOSv2.06/src/superio/via/vt1211/vt1211.c	2005-08-03 18:16:43.054202750 +0100
@@ -22,11 +22,11 @@
 
 
 #include <arch/io.h>
-#include <device/device.h>
-#include <device/pci.h>
-#include <device/pci_ops.h>
-#include <device/pci_ids.h>
 #include <console/console.h>
+#include <device/device.h>
+#include <device/pnp.h>
+#include <uart8250.h>
+
 #include "vt1211.h"
 #include "chip.h"
 
@@ -47,102 +47,120 @@
  0x4c,0x0, 0x4d,0x0, 0x4e,0xf, 0x5d,0x77,
  0x5c,0x0, 0x5f,0x33, 0x40,0x1};
 
-static void start_conf_pnp(int dev)
-{
-	outb(0x87,0x2e);
-	outb(0x87,0x2e);
-	outb(7,0x2e);
-	outb(dev,0x2f);
-}
-static void write_pnp(int reg, int val)
+static void pnp_enter_ext_func_mode(device_t dev) 
 {
-	outb(reg,0x2e);
-	outb(val,0x2f);
+	outb(0x87, dev->path.u.pnp.port);
+	outb(0x87, dev->path.u.pnp.port);
 }
-static void end_conf_pnp()
+
+static void pnp_exit_ext_func_mode(device_t dev) 
 {
-	outb(0xaa,0x2e);
+	outb(0xaa, dev->path.u.pnp.port);
 }
 
-static void vt1211_init(struct superio_via_vt1211_config *conf)
+static void init_hwm(unsigned long base)
 {
-
 	int i;
- 	// Activate the vt1211 hardware monitor
-	if(conf->enable_hwmon){
-		start_conf_pnp(0x0b);
-		write_pnp(0x60,0xec); 
-		write_pnp(0x30,1);
-		end_conf_pnp();
-
-	 	// initialize vt1211 hardware monitor registers, which are at 0xECXX
- 		for(i=0;i<sizeof(vt1211hwmonitorinits);i+=2)
- 			outb(vt1211hwmonitorinits[i+1],0xec00+vt1211hwmonitorinits[i]);
-	}
-	if( conf->enable_fdc){
-		// activate FDC
-		start_conf_pnp(0); // fdc is device 0
-		write_pnp(0x60,0xfc); // io address
-		write_pnp(0x70,0x06); // interupt
-		write_pnp(0x74,0x02); // dma
-		write_pnp(0x30,0x01); // activate it
-		end_conf_pnp();
-	}	
-
-	if( conf->enable_com_ports ){
-		// activate com2
-		start_conf_pnp(3);
-		write_pnp(0x60,0xbe);
-		write_pnp(0x70,0x3);
-		write_pnp(0xf0,0x02);
-		write_pnp(0x30,0x01);
-		end_conf_pnp();
-	}
 
-	if( conf->enable_lpt ){
-		// activate lpt
-		start_conf_pnp(1);
-		write_pnp(0x60,0xde);
-		write_pnp(0x70,0x07);
-		write_pnp(0x74,0x3);
-		write_pnp(0x30,0x01);
-		end_conf_pnp();
+ 	// initialize vt1211 hardware monitor registers, which are at 0xECXX
+	for(i = 0; i < sizeof(vt1211hwmonitorinits); i += 2) {
+ 			outb(vt1211hwmonitorinits[i + 1],
+					base + vt1211hwmonitorinits[i]);
 	}
-
 }
 
-static void superio_init(struct chip *chip, enum chip_pass pass)
+static void vt1211_init(struct device *dev)
 {
+	struct superio_via_vt1211_config *conf = dev->chip_info;
+	struct resource *res0;
 
-	struct superio_via_vt1211_config *conf = 
-		(struct superio_via_vt1211_config *)chip->chip_info;
+	if (!dev->enabled) {
+		return;
+	}
 
-	switch (pass) {
-	case CONF_PASS_PRE_PCI:
+	switch (dev->path.u.pnp.device) {
+	case VT1211_SP1:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		init_uart8250(res0->base, &conf->com1);
 		break;
-		
-	case CONF_PASS_POST_PCI:
-		vt1211_init(conf);
+	case VT1211_SP2:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		init_uart8250(res0->base, &conf->com2);
 		break;
-
-	case CONF_PASS_PRE_BOOT:
+	case VT1211_HWM:
+		res0 = find_resource(dev, PNP_IDX_IO0);
+		init_hwm(res0->base);
 		break;
-		
 	default:
-		/* nothing yet */
-		break;
+		printk_info("vt1211 asked to initialise unknown device!\n");
 	}
+	
+	/* activate com2
+	start_conf_pnp(3);
+	write_pnp(0x60,0xbe);
+	write_pnp(0x70,0x3);
+	write_pnp(0xf0,0x02);
+	write_pnp(0x30,0x01);
+	end_conf_pnp();
+
+ 	// Activate the vt1211 hardware monitor
+	start_conf_pnp(0x0b);
+	write_pnp(0x60,0xec); 
+	write_pnp(0x30,1);
+	end_conf_pnp(); */
+
+}
+
+void vt1211_pnp_enable_resources(device_t dev)
+{
+	pnp_enter_ext_func_mode(dev);
+	pnp_enable_resources(dev);
+	pnp_exit_ext_func_mode(dev);
 }
 
-static void enumerate(struct chip *chip)
+void vt1211_pnp_set_resources(struct device *dev)
+{
+	pnp_enter_ext_func_mode(dev);
+	pnp_set_resources(dev);
+	pnp_exit_ext_func_mode(dev);
+}
+
+void vt1211_pnp_enable(device_t dev)
+{
+	if (!dev->enabled) {
+		pnp_enter_ext_func_mode(dev);
+		pnp_set_logical_device(dev);
+		pnp_set_enable(dev, 0);
+		pnp_exit_ext_func_mode(dev);
+	}
+}
+
+struct device_operations ops = {
+	.read_resources   = pnp_read_resources,
+	.set_resources    = vt1211_pnp_set_resources,
+	.enable_resources = vt1211_pnp_enable_resources,
+	.enable           = vt1211_pnp_enable,
+	.init             = vt1211_init,
+};
+
+static struct pnp_info pnp_dev_info[] = {
+	{ &ops, VT1211_FDC, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, },
+	{ &ops, VT1211_PP,  PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, },
+	{ &ops, VT1211_SP1, PNP_IO0 | PNP_IRQ0,            { 0x07f8, 0}, },
+	{ &ops, VT1211_SP2, PNP_IO0 | PNP_IRQ0,            { 0x07f8, 0}, },
+	{ &ops, VT1211_HWM, PNP_IO0 , { 0xfff8, 0 }, },
+};
+
+static void enable_dev(struct device *dev)
 {
-	extern struct device_operations default_pci_ops_bus;
-	chip_enumerate(chip);
-	chip->dev->ops = &default_pci_ops_bus;
+	printk_debug("vt1211 enabling PNP devices.\n");
+	pnp_enable_devices(dev,
+			&ops,
+			sizeof(pnp_dev_info) / sizeof(pnp_dev_info[0]),
+			pnp_dev_info);
 }
 
-struct chip_operations superio_via_vt1211_control = {
+struct chip_operations superio_via_vt1211_ops = {
 	CHIP_NAME("VIA vt1211")
-	.enumerate = enumerate,
-	.enable    = superio_init,
+	.enable_dev = enable_dev,
 };
diff -ruN LinuxBIOSv2.05/src/superio/via/vt1211/vt1211.h LinuxBIOSv2.06/src/superio/via/vt1211/vt1211.h
--- LinuxBIOSv2.05/src/superio/via/vt1211/vt1211.h	2005-08-03 15:12:49.108624000 +0100
+++ LinuxBIOSv2.06/src/superio/via/vt1211/vt1211.h	2005-08-03 18:16:50.502668250 +0100
@@ -18,5 +18,17 @@
  * MA 02111-1307 USA
  */
 
- /* vt1211 routines and defines*/
+/* vt1211 PNP devices */
 
+#define VT1211_FDC		0	/* Floppy */
+#define VT1211_PP		1	/* Parallel Port */
+#define VT1211_SP1		2	/* COM1 */
+#define VT1211_SP2		3	/* COM2 */
+#define VT1211_MIDI		6	/* MIDI */
+#define VT1211_GAME		7	/* Game port */
+#define VT1211_GPIO		8	/* GPIO pins */
+#define VT1211_WATCHDOG		9	/* Watchdog timer */
+#define VT1211_WAKEUP		10	/* Wakeup control */
+#define VT1211_HWM		11	/* Hardware monitor */
+#define VT1211_FIR		12	/* Irda */
+#define VT1211_ROM		13	/* ROM control */
-------------- next part --------------
diff -ruN LinuxBIOSv2.orig/src/mainboard/via/epia-m/Options.lb LinuxBIOSv2.01/src/mainboard/via/epia-m/Options.lb
--- LinuxBIOSv2.orig/src/mainboard/via/epia-m/Options.lb	2005-08-03 15:12:56.161065000 +0100
+++ LinuxBIOSv2.01/src/mainboard/via/epia-m/Options.lb	2005-08-03 15:43:21.287128250 +0100
@@ -32,6 +32,9 @@
 uses CC
 uses HOSTCC
 uses OBJCOPY
+uses DEFAULT_CONSOLE_LOGLEVEL
+uses MAXIMUM_CONSOLE_LOGLEVEL
+uses CONFIG_CONSOLE_SERIAL8250
 
 ## ROM_SIZE is the size of boot ROM that this board will use.
 default ROM_SIZE  = 256*1024
diff -ruN LinuxBIOSv2.orig/targets/via/epia-m/Config.512kflash.lb LinuxBIOSv2.01/targets/via/epia-m/Config.512kflash.lb
--- LinuxBIOSv2.orig/targets/via/epia-m/Config.512kflash.lb	2005-08-03 15:13:31.827294000 +0100
+++ LinuxBIOSv2.01/targets/via/epia-m/Config.512kflash.lb	2005-08-03 15:42:26.515705250 +0100
@@ -1,64 +1,14 @@
 # Sample config file for EPIA-M
 # This will make a target directory of ./epia-m.512kflash
 
-loadoptions
-
 target epia-m.512kflash
 
-uses ARCH
-uses CONFIG_COMPRESS
-uses CONFIG_IOAPIC
-uses CONFIG_ROM_STREAM
-uses CONFIG_ROM_STREAM_START
-uses CONFIG_UDELAY_TSC
-uses CPU_FIXUP
-uses FALLBACK_SIZE
-uses HAVE_FALLBACK_BOOT
-uses HAVE_MP_TABLE
-uses HAVE_PIRQ_TABLE
-uses HAVE_HARD_RESET
-uses i586
-uses i686
-uses INTEL_PPRO_MTRR
-uses HEAP_SIZE
-uses IRQ_SLOT_COUNT
-uses MAINBOARD_PART_NUMBER
-uses MAINBOARD_VENDOR
-uses CONFIG_SMP
-uses CONFIG_MAX_CPUS
-uses MEMORY_HOLE
-uses PAYLOAD_SIZE
-uses _RAMBASE
-uses _ROMBASE
-uses ROM_IMAGE_SIZE
-uses ROM_SECTION_OFFSET
-uses ROM_SECTION_SIZE
-uses ROM_SIZE
-uses STACK_SIZE
-uses USE_FALLBACK_IMAGE
-uses USE_OPTION_TABLE
-uses HAVE_OPTION_TABLE
-uses MAXIMUM_CONSOLE_LOGLEVEL
-uses  DEFAULT_CONSOLE_LOGLEVEL
-uses  CONFIG_CONSOLE_SERIAL8250
-uses MAINBOARD
-uses CONFIG_CHIP_CONFIGURE
-uses XIP_ROM_SIZE
-uses XIP_ROM_BASE
-uses LINUXBIOS_EXTRA_VERSION
-
-option CONFIG_CHIP_CONFIGURE=1
+mainboard via/epia-m
 
 option  MAXIMUM_CONSOLE_LOGLEVEL=8
 option  DEFAULT_CONSOLE_LOGLEVEL=8
 option  CONFIG_CONSOLE_SERIAL8250=1
 
-option CPU_FIXUP=1
-option CONFIG_UDELAY_TSC=0
-option i686=1
-option i586=1
-option INTEL_PPRO_MTRR=1
-
 option ROM_SIZE=524288
 
 
@@ -82,12 +32,12 @@
 ###
 
 #
-# Arima hdama
+# Via EPIA M
+#
 romimage "normal"
 	option USE_FALLBACK_IMAGE=0
 	option ROM_IMAGE_SIZE=0x10000
 	option LINUXBIOS_EXTRA_VERSION=".0Normal"
-	mainboard via/epia-m
 #	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
 #	payload ../../../../tg3--ide_disk.zelf	
 	payload ../../../../../lnxieepro100.ebi
@@ -97,7 +47,6 @@
 	option USE_FALLBACK_IMAGE=1
 	option ROM_IMAGE_SIZE=0x10000
 	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
-	mainboard via/epia-m
 #	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
 #	payload ../../../../tg3--ide_disk.zelf	
 	payload ../../../../../lnxieepro100.ebi
diff -ruN LinuxBIOSv2.orig/targets/via/epia-m/Config.etherboot.lb LinuxBIOSv2.01/targets/via/epia-m/Config.etherboot.lb
--- LinuxBIOSv2.orig/targets/via/epia-m/Config.etherboot.lb	2005-08-03 15:13:31.831294000 +0100
+++ LinuxBIOSv2.01/targets/via/epia-m/Config.etherboot.lb	2005-08-03 15:42:14.638963000 +0100
@@ -1,66 +1,14 @@
 # Sample config file for EPIA-M
 # This will make a target directory of ./epia-m
 
-loadoptions
-
 target epia-m
 
-uses ARCH
-uses CONFIG_COMPRESS
-uses CONFIG_IOAPIC
-uses CONFIG_ROM_STREAM
-uses CONFIG_ROM_STREAM_START
-uses CONFIG_UDELAY_TSC
-uses CPU_FIXUP
-uses FALLBACK_SIZE
-uses HAVE_FALLBACK_BOOT
-uses HAVE_MP_TABLE
-uses HAVE_PIRQ_TABLE
-uses HAVE_HARD_RESET
-uses i586
-uses i686
-uses INTEL_PPRO_MTRR
-uses HEAP_SIZE
-uses IRQ_SLOT_COUNT
-uses MAINBOARD_PART_NUMBER
-uses MAINBOARD_VENDOR
-uses CONFIG_SMP
-uses CONFIG_MAX_CPUS
-uses MEMORY_HOLE
-uses PAYLOAD_SIZE
-uses _RAMBASE
-uses _ROMBASE
-uses ROM_IMAGE_SIZE
-uses ROM_SECTION_OFFSET
-uses ROM_SECTION_SIZE
-uses ROM_SIZE
-uses STACK_SIZE
-uses USE_FALLBACK_IMAGE
-uses USE_OPTION_TABLE
-uses HAVE_OPTION_TABLE
-uses MAXIMUM_CONSOLE_LOGLEVEL
-uses  DEFAULT_CONSOLE_LOGLEVEL
-uses  CONFIG_CONSOLE_SERIAL8250
-uses MAINBOARD
-uses CONFIG_CHIP_CONFIGURE
-uses XIP_ROM_SIZE
-uses XIP_ROM_BASE
-uses LINUXBIOS_EXTRA_VERSION
-uses TTYS0_BAUD
-
-option TTYS0_BAUD=19200
+mainboard via/epia-m
 
-option CONFIG_CHIP_CONFIGURE=1
-
-option  MAXIMUM_CONSOLE_LOGLEVEL=7
-option  DEFAULT_CONSOLE_LOGLEVEL=7
+option  MAXIMUM_CONSOLE_LOGLEVEL=8
+option  DEFAULT_CONSOLE_LOGLEVEL=8
 option  CONFIG_CONSOLE_SERIAL8250=1
 
-option CPU_FIXUP=1
-option CONFIG_UDELAY_TSC=0
-option i686=1
-option i586=1
-option INTEL_PPRO_MTRR=1
 option ROM_SIZE=256*1024
 
 option HAVE_OPTION_TABLE=1
@@ -83,12 +31,12 @@
 ###
 
 #
-# Arima hdama
+# Via EPIA-M
+#
 romimage "normal"
 	option USE_FALLBACK_IMAGE=0
 	option ROM_IMAGE_SIZE=0x10000
 	option LINUXBIOS_EXTRA_VERSION=".0Normal"
-	mainboard via/epia-m
 #	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
 #	payload ../../../../tg3--ide_disk.zelf	
 	payload ../../../../../lnxieepro100.ebi
@@ -98,7 +46,6 @@
 	option USE_FALLBACK_IMAGE=1
 	option ROM_IMAGE_SIZE=0x10000
 	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
-	mainboard via/epia-m
 #	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
 #	payload ../../../../tg3--ide_disk.zelf	
 	payload ../../../../../lnxieepro100.ebi
diff -ruN LinuxBIOSv2.orig/targets/via/epia-m/Config.filo.lb LinuxBIOSv2.01/targets/via/epia-m/Config.filo.lb
--- LinuxBIOSv2.orig/targets/via/epia-m/Config.filo.lb	2005-08-03 15:13:31.827294000 +0100
+++ LinuxBIOSv2.01/targets/via/epia-m/Config.filo.lb	2005-08-03 15:41:56.421824500 +0100
@@ -1,63 +1,14 @@
 # Sample config file for EPIA-M
 # This will make a target directory of ./epia-m
 
-loadoptions
-
 target epia-m
 
-uses ARCH
-uses CONFIG_COMPRESS
-uses CONFIG_IOAPIC
-uses CONFIG_ROM_STREAM
-uses CONFIG_ROM_STREAM_START
-uses CONFIG_UDELAY_TSC
-uses CPU_FIXUP
-uses FALLBACK_SIZE
-uses HAVE_FALLBACK_BOOT
-uses HAVE_MP_TABLE
-uses HAVE_PIRQ_TABLE
-uses HAVE_HARD_RESET
-uses i586
-uses i686
-uses INTEL_PPRO_MTRR
-uses HEAP_SIZE
-uses IRQ_SLOT_COUNT
-uses MAINBOARD_PART_NUMBER
-uses MAINBOARD_VENDOR
-uses CONFIG_SMP
-uses CONFIG_MAX_CPUS
-uses MEMORY_HOLE
-uses PAYLOAD_SIZE
-uses _RAMBASE
-uses _ROMBASE
-uses ROM_IMAGE_SIZE
-uses ROM_SECTION_OFFSET
-uses ROM_SECTION_SIZE
-uses ROM_SIZE
-uses STACK_SIZE
-uses USE_FALLBACK_IMAGE
-uses USE_OPTION_TABLE
-uses HAVE_OPTION_TABLE
-uses MAXIMUM_CONSOLE_LOGLEVEL
-uses  DEFAULT_CONSOLE_LOGLEVEL
-uses  CONFIG_CONSOLE_SERIAL8250
-uses MAINBOARD
-uses CONFIG_CHIP_CONFIGURE
-uses XIP_ROM_SIZE
-uses XIP_ROM_BASE
-uses LINUXBIOS_EXTRA_VERSION
-
-option CONFIG_CHIP_CONFIGURE=1
+mainboard via/epia-m
 
 option  MAXIMUM_CONSOLE_LOGLEVEL=8
 option  DEFAULT_CONSOLE_LOGLEVEL=8
 option  CONFIG_CONSOLE_SERIAL8250=1
 
-option CPU_FIXUP=1
-option CONFIG_UDELAY_TSC=0
-option i686=1
-option i586=1
-option INTEL_PPRO_MTRR=1
 option ROM_SIZE=256*1024
 
 option HAVE_OPTION_TABLE=1
@@ -80,12 +31,12 @@
 ###
 
 #
-# Arima hdama
+# EPIA-M
+#
 romimage "normal"
 	option USE_FALLBACK_IMAGE=0
 	option ROM_IMAGE_SIZE=0x10000
 	option LINUXBIOS_EXTRA_VERSION=".0Normal"
-	mainboard via/epia-m
 #	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
 #	payload ../../../../tg3--ide_disk.zelf	
 #	payload ../../../../../lnxieepro100.ebi
@@ -96,7 +47,6 @@
 	option USE_FALLBACK_IMAGE=1
 	option ROM_IMAGE_SIZE=0x10000
 	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
-	mainboard via/epia-m
 #	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
 #	payload ../../../../tg3--ide_disk.zelf	
 #	payload ../../../../../lnxieepro100.ebi
diff -ruN LinuxBIOSv2.orig/targets/via/epia-m/Config.lb LinuxBIOSv2.01/targets/via/epia-m/Config.lb
--- LinuxBIOSv2.orig/targets/via/epia-m/Config.lb	2005-08-03 15:13:31.827294000 +0100
+++ LinuxBIOSv2.01/targets/via/epia-m/Config.lb	2005-08-04 18:37:09.614520500 +0100
@@ -1,78 +1,24 @@
 # Sample config file for EPIA-M
 # This will make a target directory of ./epia-m
 
-loadoptions
-
 target epia-m
 
-uses ARCH
-uses CONFIG_COMPRESS
-uses CONFIG_IOAPIC
-uses CONFIG_ROM_STREAM
-uses CONFIG_ROM_STREAM_START
-uses CONFIG_UDELAY_TSC
-uses CPU_FIXUP
-uses FALLBACK_SIZE
-uses HAVE_FALLBACK_BOOT
-uses HAVE_MP_TABLE
-uses HAVE_PIRQ_TABLE
-uses HAVE_HARD_RESET
-uses i586
-uses i686
-uses INTEL_PPRO_MTRR
-uses HEAP_SIZE
-uses IRQ_SLOT_COUNT
-uses MAINBOARD_PART_NUMBER
-uses MAINBOARD_VENDOR
-uses CONFIG_SMP
-uses CONFIG_MAX_CPUS
-uses MEMORY_HOLE
-uses PAYLOAD_SIZE
-uses _RAMBASE
-uses _ROMBASE
-uses ROM_IMAGE_SIZE
-uses ROM_SECTION_OFFSET
-uses ROM_SECTION_SIZE
-uses ROM_SIZE
-uses STACK_SIZE
-uses USE_FALLBACK_IMAGE
-uses USE_OPTION_TABLE
-uses HAVE_OPTION_TABLE
-uses MAXIMUM_CONSOLE_LOGLEVEL
-uses  DEFAULT_CONSOLE_LOGLEVEL
-uses  CONFIG_CONSOLE_SERIAL8250
-uses MAINBOARD
-uses CONFIG_CHIP_CONFIGURE
-uses XIP_ROM_SIZE
-uses XIP_ROM_BASE
-uses LINUXBIOS_EXTRA_VERSION
-uses HAVE_ACPI_TABLES
-uses CONFIG_LEGACY_VGABIOS
-uses VGABIOS_START
-uses VGABIOS_START
-option CONFIG_CHIP_CONFIGURE=1
+mainboard via/epia-m
 
 option  MAXIMUM_CONSOLE_LOGLEVEL=8
 option  DEFAULT_CONSOLE_LOGLEVEL=8
 option  CONFIG_CONSOLE_SERIAL8250=1
-option HAVE_ACPI_TABLES=1
-option CPU_FIXUP=1
-option CONFIG_UDELAY_TSC=0
-option i686=1
-option i586=1
-option INTEL_PPRO_MTRR=1
+
 option ROM_SIZE=256*1024
-option CONFIG_LEGACY_VGABIOS=1
 option HAVE_OPTION_TABLE=1
 option CONFIG_ROM_STREAM=1
 option HAVE_FALLBACK_BOOT=1
 
-option VGABIOS_START=0xfffc0000
 ###
 ### Compute the location and size of where this firmware image
 ### (linuxBIOS plus bootloader) will live in the boot rom chip.
 ###
-option FALLBACK_SIZE=0x18000
+option FALLBACK_SIZE=131072
 
 ## LinuxBIOS C code runs at this location in RAM
 option _RAMBASE=0x00004000
@@ -84,29 +30,26 @@
 ###
 
 #
-# Arima hdama
+# Via EPIA-M
+#
 romimage "normal"
 	option USE_FALLBACK_IMAGE=0
-	option ROM_IMAGE_SIZE=0xc000
-	option ROM_SECTION_OFFSET=0x10000
-	option ROM_SECTION_SIZE=0x18000
+	option ROM_IMAGE_SIZE=0x10000
 	option LINUXBIOS_EXTRA_VERSION=".0Normal"
-	mainboard via/epia-m
 #	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
 #	payload ../../../../tg3--ide_disk.zelf	
 #	payload ../../../../../lnxieepro100.ebi
-	payload /filo.elf
+	payload ../../../payloads/filo.elf
 end
 
 romimage "fallback" 
 	option USE_FALLBACK_IMAGE=1
-	option ROM_IMAGE_SIZE=0xc000
+	option ROM_IMAGE_SIZE=0x10000
 	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
-	mainboard via/epia-m
 #	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
 #	payload ../../../../tg3--ide_disk.zelf	
 #	payload ../../../../../lnxieepro100.ebi
-	payload /filo.elf
+	payload ../../../payloads/filo.elf
 end
 
 buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"
diff -ruN LinuxBIOSv2.orig/targets/via/epia-m/Config.vga.filo LinuxBIOSv2.01/targets/via/epia-m/Config.vga.filo
--- LinuxBIOSv2.orig/targets/via/epia-m/Config.vga.filo	2005-08-03 15:13:31.831294000 +0100
+++ LinuxBIOSv2.01/targets/via/epia-m/Config.vga.filo	2005-08-03 15:40:43.593273000 +0100
@@ -1,66 +1,14 @@
 # Sample config file for EPIA-M
 # This will make a target directory of ./epia-m
 
-loadoptions
-
 target epia-m
 
-uses ARCH
-uses CONFIG_COMPRESS
-uses CONFIG_IOAPIC
-uses CONFIG_ROM_STREAM
-uses CONFIG_ROM_STREAM_START
-uses CONFIG_UDELAY_TSC
-uses CPU_FIXUP
-uses FALLBACK_SIZE
-uses HAVE_FALLBACK_BOOT
-uses HAVE_MP_TABLE
-uses HAVE_PIRQ_TABLE
-uses HAVE_HARD_RESET
-uses i586
-uses i686
-uses INTEL_PPRO_MTRR
-uses HEAP_SIZE
-uses IRQ_SLOT_COUNT
-uses MAINBOARD_PART_NUMBER
-uses MAINBOARD_VENDOR
-uses CONFIG_SMP
-uses CONFIG_MAX_CPUS
-uses MEMORY_HOLE
-uses PAYLOAD_SIZE
-uses _RAMBASE
-uses _ROMBASE
-uses ROM_IMAGE_SIZE
-uses ROM_SECTION_OFFSET
-uses ROM_SECTION_SIZE
-uses ROM_SIZE
-uses STACK_SIZE
-uses USE_FALLBACK_IMAGE
-uses USE_OPTION_TABLE
-uses HAVE_OPTION_TABLE
-uses MAXIMUM_CONSOLE_LOGLEVEL
-uses  DEFAULT_CONSOLE_LOGLEVEL
-uses  CONFIG_CONSOLE_SERIAL8250
-uses MAINBOARD
-uses CONFIG_CHIP_CONFIGURE
-uses XIP_ROM_SIZE
-uses XIP_ROM_BASE
-uses LINUXBIOS_EXTRA_VERSION
-uses HAVE_ACPI_TABLES
-uses CONFIG_LEGACY_VGABIOS
-uses VGABIOS_START
-uses VGABIOS_START
-option CONFIG_CHIP_CONFIGURE=1
+mainboard via/epia-m
 
 option  MAXIMUM_CONSOLE_LOGLEVEL=8
 option  DEFAULT_CONSOLE_LOGLEVEL=8
 option  CONFIG_CONSOLE_SERIAL8250=1
-option HAVE_ACPI_TABLES=1
-option CPU_FIXUP=1
-option CONFIG_UDELAY_TSC=0
-option i686=1
-option i586=1
-option INTEL_PPRO_MTRR=1
+
 option ROM_SIZE=256*1024
 option CONFIG_LEGACY_VGABIOS=1
 option HAVE_OPTION_TABLE=1
@@ -84,14 +32,14 @@
 ###
 
 #
-# Arima hdama
+# EPIA-M
+#
 romimage "normal"
 	option USE_FALLBACK_IMAGE=0
 	option ROM_IMAGE_SIZE=0xc000
 	option ROM_SECTION_OFFSET=0x10000
 	option ROM_SECTION_SIZE=0x18000
 	option LINUXBIOS_EXTRA_VERSION=".0Normal"
-	mainboard via/epia-m
 #	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
 #	payload ../../../../tg3--ide_disk.zelf	
 #	payload ../../../../../lnxieepro100.ebi
@@ -102,7 +50,6 @@
 	option USE_FALLBACK_IMAGE=1
 	option ROM_IMAGE_SIZE=0xc000
 	option LINUXBIOS_EXTRA_VERSION=".0Fallback"
-	mainboard via/epia-m
 #	payload /usr/share/etherboot/5.1.9pre2-lnxi-lb/tg3--ide_disk.zelf
 #	payload ../../../../tg3--ide_disk.zelf	
 #	payload ../../../../../lnxieepro100.ebi
Binary files LinuxBIOSv2.orig/util/newconfig/yappsrt.pyc and LinuxBIOSv2.01/util/newconfig/yappsrt.pyc differ

From stepan at openbios.org  Thu Aug  4 20:01:20 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu, 4 Aug 2005 20:01:20 +0200
Subject: [BULK] Re: [LinuxBIOS] Potential copyright issues with
	decompiling ACPI tables?
In-Reply-To: <2ea3fae1050804092844cf91c4@mail.gmail.com>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
	<20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>
	<20050731094623.61e7600d@absurd>
	<Pine.LNX.4.58.0507311927210.21749@enigma.lanl.gov>
	<m3y87i3ztw.fsf@maxwell.lnxi.com>
	<2ea3fae1050804092844cf91c4@mail.gmail.com>
Message-ID: <20050804180120.GA31416@openbios.org>

* yhlu <yinghailu at gmail.com> [050804 18:28]:
> So everyone agree to put acpi support to LinuxBIOS?

It's there already ;-) 

But the question is how do we want to create the information ..

> An the way that we need to create our own acpi tables dynamically. (
> in case user add pci bridge .....)

I'm not sure how far we get with this approach, since we'd quickly need
a DSDT for basically everything. 

Look at the island/aruma - it won't find any devices on bus!=0 unless 
the dsdt is there and it needs to be patched online with the bus numbers
(that may vary, dependent on the cards that are connected)

As soon as you start with ACPI in the Linux kernel you need to provide
a pretty complete set of it, since the ACPI code is not very modular.

And it does not interact well with the other tables. So basically, if
you have ACPI enabled, Linux will ignore the mptable and the pirq table.

This is probably due to inconsistent tables of different kinds in
awkward and ashes bios, so you can't really blame the linux code. It's
not really a clean modular parallel implementation of the standards but
an empirical answer to the real world.

To make sure we don't run into problems, LinuxBIOS should create all
tables from a single internal representation, to make sure they are
consistant. This will bloat the configs noticably so I am not sure
whether it is a good idea to head here before another set of config
mechanism changes. The next step then would be to provide all
information in the config that can not be autoprobed. ie. the board's
IRQ wiring.

Then pack all this information into the internal device representation.
Possibly in the LinuxBIOS table. 

Most ACPI tables will then be pretty easy to produce:
 * MADT  (APICs and IRQ routing, overrides, NMIs) ..
   see mainboard/island/aruma/acpi_tables.c:acpi_dump_apics()
 * HPET (timers)
 * FACS, RSDT, RSDP
 * FADT

The most nasty one is definitely the DSDT. Maybe this one can be
generated from the config.lb files. The result would have to be passed
through iasl or your favourite ASL compiler, and linked in the bios
image. 

Generating mp and pirq from the internal representation seems pretty
trivial once acpi is working, since both are a lot less complex.

   Stefan




From kfuchs at winternet.com  Thu Aug  4 20:09:55 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Thu, 4 Aug 2005 13:09:55 -0500 (CDT)
Subject: [LinuxBIOS] [Fwd: Info for LinuxBIOS Summit announcement]
Message-ID: <200508041809.j74I9tbw023167@tundra.winternet.com>

Which day is the LinuxBIOS workshop, Oct 11 or Oct 12?

The meeting details web page says Oct 11.
http://lacsi.rice.edu/symposium

The registration web page says Oct 12.
https://ssl.linklings.net/registrations/lacsi/

> MEETING DETAILS
> 
> The LinuxBIOS Summit will be at the 2005 LACSI Symposium, 
> October 11-13, 2005 in Santa Fe, New Mexico USA. See 
> lacsi.rice.edu/symposium.  We will 
> begin as a full-day workshop (among nine others) on the Symposium's 
> first day (October 11).  Then we'll have another 1.5 days to meet in 
> parallel with the Symposium.
>
> REGISTRATION
> 
> Register for the LACSI Symposium at
> https://ssl.linklings.net/registrations/lacsi/
> and select the LinuxBIOS Summit as your preferred workshop.  
> You'll have all the perquisites of a Symposium attendee (access to
> all workshops, reception, research presentations, panels, proceedings)
> as well as to the LinuxBIOS Summit meetings.  Registration is $350 until 
> September 5, then $400 until October 5 or on-site.
> There are also student rates.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From yinghailu at gmail.com  Thu Aug  4 22:25:39 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 4 Aug 2005 13:25:39 -0700
Subject: [LinuxBIOS] [Fwd: Info for LinuxBIOS Summit announcement]
In-Reply-To: <200508041809.j74I9tbw023167@tundra.winternet.com>
References: <200508041809.j74I9tbw023167@tundra.winternet.com>
Message-ID: <2ea3fae105080413257003c6c7@mail.gmail.com>

I guess LinuxBIOS track should be in Oct 12.

So I could attend 

Application-Specific Acceleration with FPGA Co-Processors (full day)
Organizer and contact person: Maya Gokhale (maya at lanl.gov; 505-665-9095)

or others Oct 11.

YH

On 8/4/05, Ken Fuchs <kfuchs at winternet.com> wrote:
> Which day is the LinuxBIOS workshop, Oct 11 or Oct 12?
> 
> The meeting details web page says Oct 11.
> http://lacsi.rice.edu/symposium
> 
> The registration web page says Oct 12.
> https://ssl.linklings.net/registrations/lacsi/
> 
> > MEETING DETAILS
> >
> > The LinuxBIOS Summit will be at the 2005 LACSI Symposium,
> > October 11-13, 2005 in Santa Fe, New Mexico USA. See
> > lacsi.rice.edu/symposium.  We will
> > begin as a full-day workshop (among nine others) on the Symposium's
> > first day (October 11).  Then we'll have another 1.5 days to meet in
> > parallel with the Symposium.
> >
> > REGISTRATION
> >
> > Register for the LACSI Symposium at
> > https://ssl.linklings.net/registrations/lacsi/
> > and select the LinuxBIOS Summit as your preferred workshop.
> > You'll have all the perquisites of a Symposium attendee (access to
> > all workshops, reception, research presentations, panels, proceedings)
> > as well as to the LinuxBIOS Summit meetings.  Registration is $350 until
> > September 5, then $400 until October 5 or on-site.
> > There are also student rates.
> 
> Sincerely,
> 
> Ken Fuchs <kfuchs at winternet.com>
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From rminnich at lanl.gov  Tue Aug  2 21:44:18 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 02 Aug 2005 13:44:18 -0600
Subject: [BULK] Re: [LinuxBIOS] Potential copyright issues with decompiling
	ACPI tables?
In-Reply-To: <2ea3fae1050804092844cf91c4@mail.gmail.com>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>	
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>	
	<1122586194.8576.23.camel@plipper.ccstar>	
	<20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>	
	<20050731094623.61e7600d@absurd>	
	<Pine.LNX.4.58.0507311927210.21749@enigma.lanl.gov>	
	<m3y87i3ztw.fsf@maxwell.lnxi.com>
	<2ea3fae1050804092844cf91c4@mail.gmail.com>
Message-ID: <42EFCD12.2050603@lanl.gov>

we all agree on it. Now we need someone with time to do it :-)

ron



From rminnich at lanl.gov  Tue Aug  2 21:54:03 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 02 Aug 2005 13:54:03 -0600
Subject: [LinuxBIOS] [Fwd: Info for LinuxBIOS Summit announcement]
In-Reply-To: <200508041809.j74I9tbw023167@tundra.winternet.com>
References: <200508041809.j74I9tbw023167@tundra.winternet.com>
Message-ID: <42EFCF5B.5040406@lanl.gov>

Ken Fuchs wrote:
> Which day is the LinuxBIOS workshop, Oct 11 or Oct 12?
> 
> The meeting details web page says Oct 11.
> http://lacsi.rice.edu/symposium
> 
> The registration web page says Oct 12.
> https://ssl.linklings.net/registrations/lacsi/

Thanks for catching that.

The day is oct. 11. Sorry for any confusion.

Also, be sure to register for the hotel by sep. 11.

thanks

ron



From rminnich at lanl.gov  Tue Aug  2 21:58:02 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Tue, 02 Aug 2005 13:58:02 -0600
Subject: [LinuxBIOS] [Fwd: Info for LinuxBIOS Summit announcement]
In-Reply-To: <2ea3fae105080413257003c6c7@mail.gmail.com>
References: <200508041809.j74I9tbw023167@tundra.winternet.com>
	<2ea3fae105080413257003c6c7@mail.gmail.com>
Message-ID: <42EFD04A.7030705@lanl.gov>

yhlu wrote:
> I guess LinuxBIOS track should be in Oct 12.
> 
> So I could attend 
> 
> Application-Specific Acceleration with FPGA Co-Processors (full day)
> Organizer and contact person: Maya Gokhale (maya at lanl.gov; 505-665-9095)

You are welcome to attend any parts of LACSI you wish; but the LinuxBIOS 
summit does start oct. 11.

ron



From yinghailu at gmail.com  Thu Aug  4 23:21:26 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 4 Aug 2005 14:21:26 -0700
Subject: [LinuxBIOS] [Fwd: Info for LinuxBIOS Summit announcement]
In-Reply-To: <42EFD04A.7030705@lanl.gov>
References: <200508041809.j74I9tbw023167@tundra.winternet.com>
	<2ea3fae105080413257003c6c7@mail.gmail.com>
	<42EFD04A.7030705@lanl.gov>
Message-ID: <2ea3fae105080414212ae7e6ce@mail.gmail.com>

Then how can attend two workshop at the same time?

I am thinking about addding linuxbios support for FPGA co-processor .....
So I would be there to see if someone can give out some co-processor to play.

YH

On 8/2/05, Ronald G Minnich <rminnich at lanl.gov> wrote:
> yhlu wrote:
> > I guess LinuxBIOS track should be in Oct 12.
> >
> > So I could attend
> >
> > Application-Specific Acceleration with FPGA Co-Processors (full day)
> > Organizer and contact person: Maya Gokhale (maya at lanl.gov; 505-665-9095)
> 
> You are welcome to attend any parts of LACSI you wish; but the LinuxBIOS
> summit does start oct. 11.
> 
> ron
>



From yinghailu at gmail.com  Thu Aug  4 23:23:14 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 4 Aug 2005 14:23:14 -0700
Subject: [BULK] Re: [LinuxBIOS] Potential copyright issues with
	decompiling ACPI tables?
In-Reply-To: <42EFCD12.2050603@lanl.gov>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
	<20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>
	<20050731094623.61e7600d@absurd>
	<Pine.LNX.4.58.0507311927210.21749@enigma.lanl.gov>
	<m3y87i3ztw.fsf@maxwell.lnxi.com>
	<2ea3fae1050804092844cf91c4@mail.gmail.com>
	<42EFCD12.2050603@lanl.gov>
Message-ID: <2ea3fae1050804142337c6c116@mail.gmail.com>

I just look at stefan's code, it looks good.
it only missed dsdt table creating...

SRAT?

YH

On 8/2/05, Ronald G Minnich <rminnich at lanl.gov> wrote:
> we all agree on it. Now we need someone with time to do it :-)
> 
> ron
>



From josiah at lanl.gov  Thu Aug  4 23:40:45 2005
From: josiah at lanl.gov (Josiah England)
Date: Thu, 04 Aug 2005 15:40:45 -0600
Subject: [LinuxBIOS] [Fwd: Info for LinuxBIOS Summit announcement]
In-Reply-To: <2ea3fae105080414212ae7e6ce@mail.gmail.com>
References: <200508041809.j74I9tbw023167@tundra.winternet.com>
	<2ea3fae105080413257003c6c7@mail.gmail.com> <42EFD04A.7030705@lanl.gov>
	<2ea3fae105080414212ae7e6ce@mail.gmail.com>
Message-ID: <1123191645.22107.48.camel@plipper.ccstar>

I'm with YH on this one...

Maya's team is presenting some of the work that is the most interesting
(to me).  It'd be a shame to miss it, especially considering the
potential for collaborative efforts.

Josiah

On Thu, 2005-08-04 at 14:21 -0700, yhlu wrote:
> Then how can attend two workshop at the same time?
> 
> I am thinking about addding linuxbios support for FPGA co-processor .....
> So I would be there to see if someone can give out some co-processor to play.
> 
> YH
> 
> On 8/2/05, Ronald G Minnich <rminnich at lanl.gov> wrote:
> > yhlu wrote:
> > > I guess LinuxBIOS track should be in Oct 12.
> > >
> > > So I could attend
> > >
> > > Application-Specific Acceleration with FPGA Co-Processors (full day)
> > > Organizer and contact person: Maya Gokhale (maya at lanl.gov; 505-665-9095)
> > 
> > You are welcome to attend any parts of LACSI you wish; but the LinuxBIOS
> > summit does start oct. 11.
> > 
> > ron
> >
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios




From rminnich at lanl.gov  Thu Aug  4 23:43:23 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 04 Aug 2005 15:43:23 -0600
Subject: [LinuxBIOS] [Fwd: Info for LinuxBIOS Summit announcement]
In-Reply-To: <1123191645.22107.48.camel@plipper.ccstar>
References: <200508041809.j74I9tbw023167@tundra.winternet.com>	
	<2ea3fae105080413257003c6c7@mail.gmail.com>
	<42EFD04A.7030705@lanl.gov>	
	<2ea3fae105080414212ae7e6ce@mail.gmail.com>
	<1123191645.22107.48.camel@plipper.ccstar>
Message-ID: <42F28BFB.6010902@lanl.gov>

Josiah England wrote:
> I'm with YH on this one...

Sorry, guys, but we need the time. This is our first one and there is 
lots of work to do. That said, you are of course welcome to attend 
Maya's session on oct. 11 -- you are paying for the whole symposium, 
after all.

ron




From yinghailu at gmail.com  Thu Aug  4 23:51:51 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 4 Aug 2005 14:51:51 -0700
Subject: [LinuxBIOS] [Fwd: Info for LinuxBIOS Summit announcement]
In-Reply-To: <42F28BFB.6010902@lanl.gov>
References: <200508041809.j74I9tbw023167@tundra.winternet.com>
	<2ea3fae105080413257003c6c7@mail.gmail.com>
	<42EFD04A.7030705@lanl.gov>
	<2ea3fae105080414212ae7e6ce@mail.gmail.com>
	<1123191645.22107.48.camel@plipper.ccstar> <42F28BFB.6010902@lanl.gov>
Message-ID: <2ea3fae105080414512cf36210@mail.gmail.com>

OK, I just need to talk to them to get some FPGA to play. So I don't
want to pay for the session.

YH

On 8/4/05, Ronald G Minnich <rminnich at lanl.gov> wrote:
> Josiah England wrote:
> > I'm with YH on this one...
> 
> Sorry, guys, but we need the time. This is our first one and there is
> lots of work to do. That said, you are of course welcome to attend
> Maya's session on oct. 11 -- you are paying for the whole symposium,
> after all.
> 
> ron
> 
>



From stepan at openbios.org  Fri Aug  5 01:20:32 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 5 Aug 2005 01:20:32 +0200
Subject: [BULK] Re: [LinuxBIOS] Potential copyright issues with
	decompiling ACPI tables?
In-Reply-To: <2ea3fae1050804142337c6c116@mail.gmail.com>
References: <200507282104.j6SL4RC7008842@tundra.winternet.com>
	<Pine.LNX.4.58.0507281522540.12404@enigma.lanl.gov>
	<1122586194.8576.23.camel@plipper.ccstar>
	<20050731014647.GB1777@greglaptop.hsd1.ca.comcast.net>
	<20050731094623.61e7600d@absurd>
	<Pine.LNX.4.58.0507311927210.21749@enigma.lanl.gov>
	<m3y87i3ztw.fsf@maxwell.lnxi.com>
	<2ea3fae1050804092844cf91c4@mail.gmail.com>
	<42EFCD12.2050603@lanl.gov>
	<2ea3fae1050804142337c6c116@mail.gmail.com>
Message-ID: <20050804232032.GB5198@openbios.org>

* yhlu <yinghailu at gmail.com> [050804 23:23]:
> I just look at stefan's code, it looks good.
> it only missed dsdt table creating...
 
Yepp. It does not do DSDT, since I created the APIC entries while the
system is running, by detecting the devices. The DSDT is compiled byte
code, so since we probably don't want to cope with creating it during
runtime, we will have to provide a much more complete hardware
description in Config.lb so we can create ASL source code.

And lots of things are hand crafted (Power Management tables). I bet
with a little more ACPI knowledge we can generate them from nice
looking, easily readable config files.

I'm not sure why we need IRQ overrides, it doesn't really seem to make a
difference in Linux. 

> SRAT?

SRAT is not there either.. IIRC the problem was that the LinuxBIOS table
does not hold a description of which memory belongs to which CPU, but
rather linear chunks, which was why I didn't do it.

   Stefan






From yinghailu at gmail.com  Fri Aug  5 03:12:42 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 4 Aug 2005 18:12:42 -0700
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <17137.60958.910871.640402@schifrin.suse.de>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
	<2ea3fae105080309503b144e24@mail.gmail.com>
	<20050803195316.GD8266@wotan.suse.de>
	<2ea3fae105080314022c9756ab@mail.gmail.com>
	<17137.60958.910871.640402@schifrin.suse.de>
Message-ID: <2ea3fae1050804181271d5a711@mail.gmail.com>

why 32bit kernel  could work at any cases?

YH

On 8/4/05, Torsten Duwe <duwe at suse.de> wrote:
> >>>>> "yhlu" == yhlu  <yinghailu at gmail.com> writes:
> 
>     yhlu> I believe, sometime the SB eat some byte...write to LPC.  YH
> 
>     >> > ps. other thing about flash_rom > 1. with 2.6 kernel 64 bit for
>     >> amd8111 based MB, you can not install 4G > or more in CPU0.  > 2. with
>     >> 2.6 kernel 64 bit for Nvidia ck804 based MB, you must install > 4G or
>     >> more in CPU0
> 
> But how is the (physical?) mapping of the LPC bus dependent on the amount of
> memory installed? If it's neither MMU, nor IOMMU, nor MTRR, it must be the
> chipset, as you suggest above!
> 
>         Torsten
> 
>



From maxim at kde.ru  Fri Aug  5 07:16:17 2005
From: maxim at kde.ru (Maxim Moroz)
Date: Fri, 05 Aug 2005 09:16:17 +0400
Subject: [LinuxBIOS] AMD Geode LX processor
Message-ID: <42F2F621.1010701@kde.ru>

Hello,

Is there any work on AMD Geode LX processor with GeodeLink architecture.
Any information appreciated.

Best Regards, Maxim Moroz.



From rminnich at lanl.gov  Fri Aug  5 07:26:00 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Thu, 04 Aug 2005 23:26:00 -0600
Subject: [LinuxBIOS] AMD Geode LX processor
In-Reply-To: <42F2F621.1010701@kde.ru>
References: <42F2F621.1010701@kde.ru>
Message-ID: <42F2F868.9090502@lanl.gov>

Maxim Moroz wrote:
> Hello,
> 
> Is there any work on AMD Geode LX processor with GeodeLink architecture.
> Any information appreciated.

Lots of interest, I have no info or boards, but it looks neat.

ron



From ak at suse.de  Fri Aug  5 11:12:02 2005
From: ak at suse.de (Andi Kleen)
Date: Fri, 5 Aug 2005 11:12:02 +0200
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <2ea3fae1050804181271d5a711@mail.gmail.com>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
	<2ea3fae105080309503b144e24@mail.gmail.com>
	<20050803195316.GD8266@wotan.suse.de>
	<2ea3fae105080314022c9756ab@mail.gmail.com>
	<17137.60958.910871.640402@schifrin.suse.de>
	<2ea3fae1050804181271d5a711@mail.gmail.com>
Message-ID: <20050805091202.GK8266@wotan.suse.de>

On Thu, Aug 04, 2005 at 06:12:42PM -0700, yhlu wrote:
> why 32bit kernel  could work at any cases?

Does it really?

-Andi



From marko.makela at hut.fi  Fri Aug  5 11:31:59 2005
From: marko.makela at hut.fi (Marko =?iso-8859-1?B?TeRrZWzk?=)
Date: Fri, 5 Aug 2005 12:31:59 +0300
Subject: [LinuxBIOS] Suggestions for a digital video recording system?
Message-ID: <20050805093159.GD3845@localhost.localdomain>

Hi all,

I was going to give LinuxBIOS a try in order to reduce the start-up time
of my VDR based digital TV tuner and recorder.  Currently, it takes 40
seconds to start up, of which slightly over 10 seconds is spent in BIOS.

Last night, I tried to migrate the system from a VIA686 based mainboard
to a i440ZX based one (Asus P2-99 with a 933 MHz Pentium 3 and 256 MB RAM).
The machine felt unreliable (often, it hanged with a black screen after
reset, sometimes even after power-on) and also old: there is no on-board
sound.

I have followed the development of VIA Mini-ITX (Epia) boards, and I would
like to know if there are OpenFirmware or LinuxBIOS based solutions, or how
far the Epia support of LinuxBIOS is from being useable?  I will need a
programmable wake-up timer (nvram-wakeup) and, if possible, wake-on-LAN.
The board should have either well-supported onboard video (VIA CLE266 is
a bit tricky) or an AGP slot.  Some PCI slots and IDE are needed as well.
Unless there is hardware MPEG-2 acceleration, the processor should be
equivalent to a 700 to 900 MHz Pentium 3.

	Marko



From yinghailu at gmail.com  Fri Aug  5 18:09:44 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 5 Aug 2005 09:09:44 -0700
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <20050805091202.GK8266@wotan.suse.de>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
	<2ea3fae105080309503b144e24@mail.gmail.com>
	<20050803195316.GD8266@wotan.suse.de>
	<2ea3fae105080314022c9756ab@mail.gmail.com>
	<17137.60958.910871.640402@schifrin.suse.de>
	<2ea3fae1050804181271d5a711@mail.gmail.com>
	<20050805091202.GK8266@wotan.suse.de>
Message-ID: <2ea3fae10508050909753087c5@mail.gmail.com>

Yes.

Sometime i suspect if ia32 emulation could cause problem. I will try
to disable that to test that.

YH

On 8/5/05, Andi Kleen <ak at suse.de> wrote:
> On Thu, Aug 04, 2005 at 06:12:42PM -0700, yhlu wrote:
> > why 32bit kernel  could work at any cases?
> 
> Does it really?
> 
> -Andi
>



From ak at suse.de  Fri Aug  5 18:14:37 2005
From: ak at suse.de (Andi Kleen)
Date: Fri, 5 Aug 2005 18:14:37 +0200
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <2ea3fae10508050909753087c5@mail.gmail.com>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
	<2ea3fae105080309503b144e24@mail.gmail.com>
	<20050803195316.GD8266@wotan.suse.de>
	<2ea3fae105080314022c9756ab@mail.gmail.com>
	<17137.60958.910871.640402@schifrin.suse.de>
	<2ea3fae1050804181271d5a711@mail.gmail.com>
	<20050805091202.GK8266@wotan.suse.de>
	<2ea3fae10508050909753087c5@mail.gmail.com>
Message-ID: <20050805161437.GW8266@wotan.suse.de>

On Fri, Aug 05, 2005 at 09:09:44AM -0700, yhlu wrote:
> Yes.

Ok that would wreck the chipset theory. 

> 
> Sometime i suspect if ia32 emulation could cause problem. I will try
> to disable that to test that.

I doubt it has anything to do with it.

-Andi




From yinghailu at gmail.com  Fri Aug  5 18:23:16 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 5 Aug 2005 09:23:16 -0700
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <20050805161437.GW8266@wotan.suse.de>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
	<2ea3fae105080309503b144e24@mail.gmail.com>
	<20050803195316.GD8266@wotan.suse.de>
	<2ea3fae105080314022c9756ab@mail.gmail.com>
	<17137.60958.910871.640402@schifrin.suse.de>
	<2ea3fae1050804181271d5a711@mail.gmail.com>
	<20050805091202.GK8266@wotan.suse.de>
	<2ea3fae10508050909753087c5@mail.gmail.com>
	<20050805161437.GW8266@wotan.suse.de>
Message-ID: <2ea3fae105080509234b362bf4@mail.gmail.com>

I can not figure out why behavior in AMD SB and NV SB is different.
one need less 4G installed in CPU0, and the other need more than 4G
installed in CPU0.

YH

On 8/5/05, Andi Kleen <ak at suse.de> wrote:
> On Fri, Aug 05, 2005 at 09:09:44AM -0700, yhlu wrote:
> > Yes.
> 
> Ok that would wreck the chipset theory.
> 
> >
> > Sometime i suspect if ia32 emulation could cause problem. I will try
> > to disable that to test that.
> 
> I doubt it has anything to do with it.
> 
> -Andi
> 
>



From stepan at openbios.org  Fri Aug  5 22:05:20 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 5 Aug 2005 22:05:20 +0200
Subject: [LinuxBIOS] First instruction in linuxbios
In-Reply-To: <51d803a905070109295701268d@mail.gmail.com>
References: <51d803a905070109295701268d@mail.gmail.com>
Message-ID: <20050805200520.GB12437@openbios.org>

* Jorge Cardona <jorgeecardona at gmail.com> [050701 18:29]:
> Hi.
> I'm new in this, and i'm reading the source and  i have a question, which one
> it's exactly the first instruction that the processor execute when the pc is
> booting?, in which file is it?

Here's a little summary I wrote a while ago.. don't know if it is still
correct and complete.

> I don't complete understand the relationship between a normal bios and the
> kernel, i think that the bios it's has to pass some data to the kernel, if
> that's true ?how exactly is that data passed to the kernel?

There are several possibilities. Either the information is placed at
well known addresses or in a certain address range, using a signature so
the kernel can find it. 
Or the Kernel does callbacks (intXX). 
 
> In linuxbios, how it's this issue handle?

LinuxBIOS provides tables: ACPI, MPTABLE, PIRQ table, and a LinuxBIOS
table which should some day obsolete all the other tables.

No callbacks. They are considered unsafe and error prone.

Stefan



-------------- next part --------------
Ok, 

I think I got it now, except some minor things. I would like to add this
explanation to my LinuxBIOS document. Please help me advance it with
some expert comments, since I feel rather like a novice in this part of
the code. Has there been anyone describing this in detail, while
still being understandable? I remember seeing something a long time ago
for v1, but I couldnt find it in the archives anymore.

It seems that my current approach, leaving everything up to failover.c
untouched, might not be the best way to go. From early_mtrr.inc on we
have XIP acceleration available, thus it seems that we hook in after
this point, and do everything afterwards in gcc, creating an extra hunk
with an extra .lds file to pack it all into. 


reset16.[inc|lds]
-----------------
 Description:
  * code placed at reset vector (0xfffffff0)
  * jump to _start in entry16.inc
  * jump to protected_start in entry32.inc (what is this good for??)

 Comments:
  reset16.lds supports ROMBASEs smaller than 0xffff0000. reset16.inc does
  not. Do we ever need anything else on x86 based systems? If not, I
  suggest to drop the conditionals.
  It seems to me that the second jump is later done by entry16.inc, and
  the reset vector is never reached. Is it used by something else?

entry16.[inc|lds]
-----------------
 Description:
  * linker script provides 16bit versions of the addresses (?)
  * switch to protected mode.
  * jump to __protected_start in entry32.inc
 
 Comments:
  Can someone enlighten me on the restriction comments here? given that 
  we are always on a standard x86 system, we are always above
  0xffff0000?

entry32.[inc|lds]
-----------------
 Description:
  * linker script is a noop.
  * sets up all segment registers to the same value. (ROM_CODE_SEG)
  * falls through to bist32.inc

 Comments:
  there's two entry points here, protected_start and __protected_start.
  Are they both needed? protected_start seems to do the same thing as
  the end of entry16.inc.
  The comment states that we do something with memory here. It seems
  this is wrong, since we are far before enabling memory.

bist32.inc
----------
 Description:
  * Checks EAX for BIST failures.
  * if everything is ok, falls through (skipping next 
    files that put code in different sections: reset16.inc,
    cpu_reset.inc, id.inc) On K8 this goes to early_mtrr.inc

early_mtrr.inc
--------------
 Description:
  * set up variable and fixed mtrrs.
  * set up XIP

 Comments:
  Will this hurt C-A-R? Can we somehow derive the XIP addresses from the
  information that we know, making XIP more solid?

failover.c
----------
 Description:
  * romcc generated code
  * if normal boot, we jump into normal image.
  * if cpu reset, we jump into __cpu_reset, which jumps into 
    __main (Where is this one? crt0.base? auto.inc?)
  * if we're running on the second CPU, we jump into normal/fallback
    image (???)
  * if no problems appeared, jump into normal image
  * otherwise fall through (to auto.c ??)

 Comments:
  What's HAVE_REGPARM_SUPPORT? There's a lot of conditions in this file.
  I did not follow all the branches yet. Maybe someone can explain more?
  it seems that __cpu_reset jumps into __main - does this mean the dram
  init survives a cpu reset?


> -------------- part 1: creating init code -----------------------------
>  1) compile romcc
>  2) create option table
>  3) process and compile romcc based code
>  4) create crt0.o from romcc based code
> 
> -------------- part 2: creating payload -------------------------------
>  5) compile all drivers
>  6) compile all objects
>  7) compile static device tree
>  8) link objects and static tree --> linuxbios.a
>  9) create linuxbios_c from start.o, drivers and linuxbios.a
>  a) create linuxbios_payload from linuxbios_c (with or w/o nrv2b)
> 
> -------------- part 3: final image ------------------------------------
>  b) create "linuxbios" from crt0.o (including linuxbios_payload via
>     linker script arch/i386/config/ldscript.lb)
>  c) create romimage linuxbios.rom from "linuxbios" with buildrom



From yinghailu at gmail.com  Fri Aug  5 22:34:23 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 5 Aug 2005 13:34:23 -0700
Subject: [LinuxBIOS] First instruction in linuxbios
In-Reply-To: <20050805200520.GB12437@openbios.org>
References: <51d803a905070109295701268d@mail.gmail.com>
	<20050805200520.GB12437@openbios.org>
Message-ID: <2ea3fae1050805133458a9fb24@mail.gmail.com>

early_mtrr.inc is not needed, and it is merged into car.inc and car_post.c

YH

On 8/5/05, Stefan Reinauer <stepan at openbios.org> wrote:
> * Jorge Cardona <jorgeecardona at gmail.com> [050701 18:29]:
> > Hi.
> > I'm new in this, and i'm reading the source and  i have a question, which one
> > it's exactly the first instruction that the processor execute when the pc is
> > booting?, in which file is it?
> 
> Here's a little summary I wrote a while ago.. don't know if it is still
> correct and complete.
> 
> > I don't complete understand the relationship between a normal bios and the
> > kernel, i think that the bios it's has to pass some data to the kernel, if
> > that's true ?how exactly is that data passed to the kernel?
> 
> There are several possibilities. Either the information is placed at
> well known addresses or in a certain address range, using a signature so
> the kernel can find it.
> Or the Kernel does callbacks (intXX).
> 
> > In linuxbios, how it's this issue handle?
> 
> LinuxBIOS provides tables: ACPI, MPTABLE, PIRQ table, and a LinuxBIOS
> table which should some day obsolete all the other tables.
> 
> No callbacks. They are considered unsafe and error prone.
> 
> Stefan
> 
> 
> 
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 
> 
>



From stepan at openbios.org  Sat Aug  6 14:10:05 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat, 6 Aug 2005 14:10:05 +0200
Subject: [LinuxBIOS] Solaris
In-Reply-To: <42B161B0.5070606@street-vision.com>
References: <1118859181.17017.12.camel@scrod>
	<20050616072928.GA12358@openbios.org>
	<42B161B0.5070606@street-vision.com>
Message-ID: <20050806121005.GB14410@openbios.org>

* Justin Cormack <justin at street-vision.com> [050616 13:25]:
> >Solaris on x86/amd64 does not contain any open firmware support. So
> >while using OpenBIOS to boot Solaris might be possible (if they don't
> >do legacy bios calls), it won't benefit from OpenBIOS' IEEE1275
> >compliance. This might change with OpenSolaris though--
> >
> There are some odd BIOS based interfaces in the x86 code (though at some 
> point it just builds a structure that looks like what comes out of the 
> Sun PROMS). Probably easiest to just port the Open Firmware support from 
> the Sparc part of the tree as its all there though.
 
definitely the cleanest solution. Volunteers? I can help on the OpenBIOS
side..

Stefan





From justin at street-vision.com  Sat Aug  6 14:59:45 2005
From: justin at street-vision.com (Justin Cormack)
Date: Sat, 6 Aug 2005 13:59:45 +0100
Subject: [LinuxBIOS] Solaris
In-Reply-To: <20050806121005.GB14410@openbios.org>
References: <1118859181.17017.12.camel@scrod>
	<20050616072928.GA12358@openbios.org>
	<42B161B0.5070606@street-vision.com>
	<20050806121005.GB14410@openbios.org>
Message-ID: <75DE14BD-7C69-4B64-A43C-AC7395E03E48@street-vision.com>


On 6 Aug 2005, at 13:10, Stefan Reinauer wrote:

> * Justin Cormack <justin at street-vision.com> [050616 13:25]:
>
>>> Solaris on x86/amd64 does not contain any open firmware support. So
>>> while using OpenBIOS to boot Solaris might be possible (if they  
>>> don't
>>> do legacy bios calls), it won't benefit from OpenBIOS' IEEE1275
>>> compliance. This might change with OpenSolaris though--
>>>
>>>
>> There are some odd BIOS based interfaces in the x86 code (though  
>> at some
>> point it just builds a structure that looks like what comes out of  
>> the
>> Sun PROMS). Probably easiest to just port the Open Firmware  
>> support from
>> the Sparc part of the tree as its all there though.
>>
>
> definitely the cleanest solution. Volunteers? I can help on the  
> OpenBIOS
> side..

Hopefully will have some time in a few weeks to look at it, and have  
some
spare old Opteron boards I could use. Will try to get them up and  
running
Linuxbios and booting Linux as a first step shortly.

Justin




From huangjen.wang at gmail.com  Tue Aug  9 02:49:23 2005
From: huangjen.wang at gmail.com (Huang-Jen Wang)
Date: Tue, 9 Aug 2005 08:49:23 +0800
Subject: [LinuxBIOS] some questions....
Message-ID: <4325815c05080817495ce0941a@mail.gmail.com>

Dear all ,
I have some questions , hope you can give me some idea
1.What is the difference between normal booting and fallback booting?
  When linuxbios will use normal booting and when linuxbios will use
  fallback booting? I remember I use the hdama code , and it always
use  fallback booting, and now my new porting it always use normal
booting.

2.VGA problem, I tried to add VGA, I have succeeded before when I use
hdama code , now I follow the same way , but I got a message
"Incorrect Expansion Rom  Header Signature ffff ", I trace the code
and found the rom_address become fc000000, not the fff80000 we have
set, could anyone tell me what mistakes I made?Does it related to my
question 1?

Thanks...



From yinghailu at gmail.com  Tue Aug  9 03:00:29 2005
From: yinghailu at gmail.com (yhlu)
Date: Mon, 8 Aug 2005 18:00:29 -0700
Subject: [LinuxBIOS] some questions....
In-Reply-To: <4325815c05080817495ce0941a@mail.gmail.com>
References: <4325815c05080817495ce0941a@mail.gmail.com>
Message-ID: <2ea3fae1050808180024df6fbf@mail.gmail.com>

1. every time, when the system execute failover.c and it will read
cmos to decide it will continue with fallback image or jump to normal.
2. a. did you put atix.rom in you rom? atix.rom is about 48KiB.
    b. In your MB Config.lb, you need to make sure your device num is
right. Otherwise it can not get 0xfff8000.

YH
   


On 8/8/05, Huang-Jen Wang <huangjen.wang at gmail.com> wrote:
> Dear all ,
> I have some questions , hope you can give me some idea
> 1.What is the difference between normal booting and fallback booting?
>   When linuxbios will use normal booting and when linuxbios will use
>   fallback booting? I remember I use the hdama code , and it always
> use  fallback booting, and now my new porting it always use normal
> booting.
> 
> 2.VGA problem, I tried to add VGA, I have succeeded before when I use
> hdama code , now I follow the same way , but I got a message
> "Incorrect Expansion Rom  Header Signature ffff ", I trace the code
> and found the rom_address become fc000000, not the fff80000 we have
> set, could anyone tell me what mistakes I made?Does it related to my
> question 1?
> 
> Thanks...
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From hemksu at yahoo.co.in  Tue Aug  9 05:31:51 2005
From: hemksu at yahoo.co.in (hema ku)
Date: Tue, 9 Aug 2005 04:31:51 +0100 (BST)
Subject: [LinuxBIOS] Re: LinuxBIOS Digest, Vol 6, Issue 12
Message-ID: <20050809033151.17601.qmail@web8401.mail.in.yahoo.com>

hello every body
  i am new to linuxbios , can add a linuxbios patch to
linux-2.4.21 /2.6.12 on this board , 

00:00.0 Host bridge: Intel Corp. 82845G/GL
[Brookdale-G] Chipset Host Bridge (rev 03)
00:02.0 VGA compatible controller: Intel Corp.
82845G/GL [Brookdale-G] Chipset Integrated Graphics
Device (rev 03)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub
#1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub
#2) (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub
#3) (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB USB2 (rev
02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI
Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corp. 82801DB LPC Interface
Controller (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801DB Ultra ATA
Storage Controller (rev 02)
00:1f.3 SMBus: Intel Corp. 82801DB/DBM SMBus
Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp.
82801DB AC'97 Audio Controller (rev 02)
03:0a.0 Ethernet controller: Broadcom Corporation
BCM4401 100Base-T (rev 01)
03:0b.0 Ethernet controller: Realtek Semiconductor
Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)


thanks in advance
hemanth


		
__________________________________________________________
How much free photo storage do you get? Store your friends 'n family snaps for FREE with Yahoo! Photos http://in.photos.yahoo.com



From bari at onelabs.com  Tue Aug  9 21:46:33 2005
From: bari at onelabs.com (Bari Ari)
Date: Tue, 09 Aug 2005 14:46:33 -0500
Subject: [LinuxBIOS] Re: LinuxBIOS Digest, Vol 6, Issue 12
In-Reply-To: <20050809033151.17601.qmail@web8401.mail.in.yahoo.com>
References: <20050809033151.17601.qmail@web8401.mail.in.yahoo.com>
Message-ID: <42F90819.6030105@onelabs.com>

hema ku wrote:
> hello every body
>   i am new to linuxbios , can add a linuxbios patch to
> linux-2.4.21 /2.6.12 on this board , 
-- snip --
> thanks in advance
> hemanth

Are you trying to ask us or tell us something?

-Bari



From jschildt at lnxi.com  Wed Aug 10 00:04:38 2005
From: jschildt at lnxi.com (Jason Schildt)
Date: Tue, 9 Aug 2005 16:04:38 -0600
Subject: [LinuxBIOS] New hdama commit
Message-ID: <20050809220437.GE3934@zoot.lnxi.com>

All,

I've just made a commit up to the public repository from the Linux
Networx repository mirror.  The changes only effect Opteron single/dual
core and hdama board specific code.
Regards,

--jason--

-- 

Jason W. Schildt	
LinuxBIOS Software Engineer   
Linux Networx      



From noodles at earth.li  Wed Aug 10 00:53:51 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Tue, 9 Aug 2005 23:53:51 +0100
Subject: [LinuxBIOS] New hdama commit
In-Reply-To: <20050809220437.GE3934@zoot.lnxi.com>
References: <20050809220437.GE3934@zoot.lnxi.com>
Message-ID: <20050809225351.GH12895@earth.li>

On Tue, Aug 09, 2005 at 04:04:38PM -0600, Jason Schildt wrote:
 
> I've just made a commit up to the public repository from the Linux
> Networx repository mirror.  The changes only effect Opteron single/dual
> core and hdama board specific code.

Untrue. Your commit also touched romcc.c and appears to have broken
every build except tyan-s2735.

Compare:

http://the.earth.li/~noodles/lb/2003/log.html
with
http://the.earth.li/~noodles/lb/2004/log.html


J.

-- 
Trust me, you wouldn't like us when we're angry.



From yinghailu at gmail.com  Wed Aug 10 01:47:56 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 9 Aug 2005 16:47:56 -0700
Subject: [LinuxBIOS] New hdama commit
In-Reply-To: <20050809220437.GE3934@zoot.lnxi.com>
References: <20050809220437.GE3934@zoot.lnxi.com>
Message-ID: <2ea3fae105080916478ce5fad@mail.gmail.com>

1. write_irq_tables changes is overwrite by you. that will broke all
other Opteron MB. Please change that back.

YH

On 8/9/05, Jason Schildt <jschildt at lnxi.com> wrote:
> All,
> 
> I've just made a commit up to the public repository from the Linux
> Networx repository mirror.  The changes only effect Opteron single/dual
> core and hdama board specific code.
> Regards,
> 
> --jason--
> 
> --
> 
> Jason W. Schildt
> LinuxBIOS Software Engineer
> Linux Networx
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From yinghailu at gmail.com  Wed Aug 10 01:48:53 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 9 Aug 2005 16:48:53 -0700
Subject: [LinuxBIOS] New hdama commit
In-Reply-To: <2ea3fae105080916478ce5fad@mail.gmail.com>
References: <20050809220437.GE3934@zoot.lnxi.com>
	<2ea3fae105080916478ce5fad@mail.gmail.com>
Message-ID: <2ea3fae10508091648580c8a77@mail.gmail.com>

Modified: trunk/LinuxBIOSv2/src/arch/i386/boot/tables.c
===================================================================
--- trunk/LinuxBIOSv2/src/arch/i386/boot/tables.c       2005-08-08
08:16:23 UTC (rev 2003)
+++ trunk/LinuxBIOSv2/src/arch/i386/boot/tables.c       2005-08-09
21:53:07 UTC (rev 2004)
@@ -23,7 +23,7 @@
       post_code(0x9a);

       /* This table must be betweeen 0xf0000 & 0x100000 */
-       rom_table_end = write_pirq_routing_table(rom_table_end);
+       rom_table_end = copy_pirq_routing_table(rom_table_end);
       rom_table_end = (rom_table_end + 1023) & ~1023;

       /* copy the smp block to address 0 */

On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> 1. write_irq_tables changes is overwrite by you. that will broke all
> other Opteron MB. Please change that back.
> 
> YH
> 
> On 8/9/05, Jason Schildt <jschildt at lnxi.com> wrote:
> > All,
> >
> > I've just made a commit up to the public repository from the Linux
> > Networx repository mirror.  The changes only effect Opteron single/dual
> > core and hdama board specific code.
> > Regards,
> >
> > --jason--
> >
> > --
> >
> > Jason W. Schildt
> > LinuxBIOS Software Engineer
> > Linux Networx
> >
> > _______________________________________________
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
> >
>



From yinghailu at gmail.com  Wed Aug 10 02:07:16 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 9 Aug 2005 17:07:16 -0700
Subject: [LinuxBIOS] New hdama commit
In-Reply-To: <2ea3fae105080916478ce5fad@mail.gmail.com>
References: <20050809220437.GE3934@zoot.lnxi.com>
	<2ea3fae105080916478ce5fad@mail.gmail.com>
Message-ID: <2ea3fae1050809170758ad603c@mail.gmail.com>

2. you overwite the enable ext id and apic id lifting 

YH

On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> 1. write_irq_tables changes is overwrite by you. that will broke all
> other Opteron MB. Please change that back.
> 
> YH
> 
> On 8/9/05, Jason Schildt <jschildt at lnxi.com> wrote:
> > All,
> >
> > I've just made a commit up to the public repository from the Linux
> > Networx repository mirror.  The changes only effect Opteron single/dual
> > core and hdama board specific code.
> > Regards,
> >
> > --jason--
> >
> > --
> >
> > Jason W. Schildt
> > LinuxBIOS Software Engineer
> > Linux Networx
> >
> > _______________________________________________
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
> >
>



From yinghailu at gmail.com  Wed Aug 10 02:20:25 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 9 Aug 2005 17:20:25 -0700
Subject: [LinuxBIOS] New hdama commit
In-Reply-To: <2ea3fae1050809170758ad603c@mail.gmail.com>
References: <20050809220437.GE3934@zoot.lnxi.com>
	<2ea3fae105080916478ce5fad@mail.gmail.com>
	<2ea3fae1050809170758ad603c@mail.gmail.com>
Message-ID: <2ea3fae10508091720c5a0ed6@mail.gmail.com>

3. are you sure the node1/core0 could start node1/core1?
Accorinding to my testing last year, node1/core1 only can be started
by node0/core0.

YH


On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> 2. you overwite the enable ext id and apic id lifting
> 
> YH
> 
> On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> > 1. write_irq_tables changes is overwrite by you. that will broke all
> > other Opteron MB. Please change that back.
> >
> > YH
> >
> > On 8/9/05, Jason Schildt <jschildt at lnxi.com> wrote:
> > > All,
> > >
> > > I've just made a commit up to the public repository from the Linux
> > > Networx repository mirror.  The changes only effect Opteron single/dual
> > > core and hdama board specific code.
> > > Regards,
> > >
> > > --jason--
> > >
> > > --
> > >
> > > Jason W. Schildt
> > > LinuxBIOS Software Engineer
> > > Linux Networx
> > >
> > > _______________________________________________
> > > LinuxBIOS mailing list
> > > LinuxBIOS at openbios.org
> > > http://www.openbios.org/mailman/listinfo/linuxbios
> > >
> >
>



From yinghailu at gmail.com  Wed Aug 10 02:45:51 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 9 Aug 2005 17:45:51 -0700
Subject: [LinuxBIOS] New hdama commit
In-Reply-To: <2ea3fae10508091720c5a0ed6@mail.gmail.com>
References: <20050809220437.GE3934@zoot.lnxi.com>
	<2ea3fae105080916478ce5fad@mail.gmail.com>
	<2ea3fae1050809170758ad603c@mail.gmail.com>
	<2ea3fae10508091720c5a0ed6@mail.gmail.com>
Message-ID: <2ea3fae105080917457c64840d@mail.gmail.com>

On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> 3. are you sure the node1/core0 could start node1/core1?
> Accorinding to my testing last year, node1/core1 only can be started
> by node0/core0.
> 
> YH

So you move "adding core1 to cpu_bus" from cpu_bus_scan to amd_sibling_init.

the result will be when you access the cpu_bus and call
amd_sibling_init, the amd_sibling_init will alter the cpu_bus and
append ...cpu on that. So if for 4 way dual core or 8 way dual core,
when disable CPU_INIT_SERIALIZE, if it could cause racing...

YH



From yinghailu at gmail.com  Wed Aug 10 02:56:21 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 9 Aug 2005 17:56:21 -0700
Subject: [LinuxBIOS] New hdama commit
In-Reply-To: <2ea3fae10508091720c5a0ed6@mail.gmail.com>
References: <20050809220437.GE3934@zoot.lnxi.com>
	<2ea3fae105080916478ce5fad@mail.gmail.com>
	<2ea3fae1050809170758ad603c@mail.gmail.com>
	<2ea3fae10508091720c5a0ed6@mail.gmail.com>
Message-ID: <2ea3fae105080917566d5e5c76@mail.gmail.com>

4. it's good, to move hardware mem hole support from raminit.c to
northbridge.c, So it will be dynamically. but problem is it will use
more MTRRs. So carry_on should be calculated in some way...

YH

On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> 3. are you sure the node1/core0 could start node1/core1?
> Accorinding to my testing last year, node1/core1 only can be started
> by node0/core0.
> 
> YH
> 
> 
> On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> > 2. you overwite the enable ext id and apic id lifting
> >
> > YH
> >
> > On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> > > 1. write_irq_tables changes is overwrite by you. that will broke all
> > > other Opteron MB. Please change that back.
> > >
> > > YH
> > >
> > > On 8/9/05, Jason Schildt <jschildt at lnxi.com> wrote:
> > > > All,
> > > >
> > > > I've just made a commit up to the public repository from the Linux
> > > > Networx repository mirror.  The changes only effect Opteron single/dual
> > > > core and hdama board specific code.
> > > > Regards,
> > > >
> > > > --jason--
> > > >
> > > > --
> > > >
> > > > Jason W. Schildt
> > > > LinuxBIOS Software Engineer
> > > > Linux Networx
> > > >
> > > > _______________________________________________
> > > > LinuxBIOS mailing list
> > > > LinuxBIOS at openbios.org
> > > > http://www.openbios.org/mailman/listinfo/linuxbios
> > > >
> > >
> >
>



From yinghailu at gmail.com  Wed Aug 10 03:18:14 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 9 Aug 2005 18:18:14 -0700
Subject: [LinuxBIOS] New hdama commit
In-Reply-To: <2ea3fae105080917566d5e5c76@mail.gmail.com>
References: <20050809220437.GE3934@zoot.lnxi.com>
	<2ea3fae105080916478ce5fad@mail.gmail.com>
	<2ea3fae1050809170758ad603c@mail.gmail.com>
	<2ea3fae10508091720c5a0ed6@mail.gmail.com>
	<2ea3fae105080917566d5e5c76@mail.gmail.com>
Message-ID: <2ea3fae105080918184ce40a06@mail.gmail.com>

5. 
+                       /* Enable extended apic id's and second core */
+                       val = pci_read_config32(dev_f0, 0x68);
+                       val |= (1 << 18) | (1 << 17) | ( 1 << 5);
+                       pci_write_config32(dev_f0, 0x68, val);

ext apic id mode is only need to enable for 8 way dual core system.

6.  incohere_ht.c overwrite my new changes need to be roll back.
7. debug.c need to rollback.


YH

On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> 4. it's good, to move hardware mem hole support from raminit.c to
> northbridge.c, So it will be dynamically. but problem is it will use
> more MTRRs. So carry_on should be calculated in some way...
> 
> YH
> 
> On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> > 3. are you sure the node1/core0 could start node1/core1?
> > Accorinding to my testing last year, node1/core1 only can be started
> > by node0/core0.
> >
> > YH
> >
> >
> > On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> > > 2. you overwite the enable ext id and apic id lifting
> > >
> > > YH
> > >
> > > On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> > > > 1. write_irq_tables changes is overwrite by you. that will broke all
> > > > other Opteron MB. Please change that back.
> > > >
> > > > YH
> > > >
> > > > On 8/9/05, Jason Schildt <jschildt at lnxi.com> wrote:
> > > > > All,
> > > > >
> > > > > I've just made a commit up to the public repository from the Linux
> > > > > Networx repository mirror.  The changes only effect Opteron single/dual
> > > > > core and hdama board specific code.
> > > > > Regards,
> > > > >
> > > > > --jason--
> > > > >
> > > > > --
> > > > >
> > > > > Jason W. Schildt
> > > > > LinuxBIOS Software Engineer
> > > > > Linux Networx
> > > > >
> > > > > _______________________________________________
> > > > > LinuxBIOS mailing list
> > > > > LinuxBIOS at openbios.org
> > > > > http://www.openbios.org/mailman/listinfo/linuxbios
> > > > >
> > > >
> > >
> >
>



From spidermantm at freenet.de  Wed Aug 10 12:55:17 2005
From: spidermantm at freenet.de (spidermantm at freenet.de)
Date: Wed, 10 Aug 2005 12:55:17 +0200
Subject: [LinuxBIOS] bios of single devices
Message-ID: <E1E2oEv-00083q-Cu@www13.emo.freenet-rz.de>



hello dear bios-workoholics,

does anybody know, if there is only one bios on
the motherboard, or

if every single hardware device or item of a PC-System, like hard-disk or
cd/dvd-rom drive or pci-card or floppy,
has an own little bios-chip,
for to be recognized
by BIOS on mainboard ???

the ques is, for example, if PC beginner simply
plug off such a device, while PC is switched on,
and "damage" this device,
that probably this device is not damaged,
cause you only need to re-flash this
little BIOS-chip or hardware-TM-brand-chip of concerning device ???

or ?

tuvm for response












From smithbone at gmail.com  Wed Aug 10 15:36:07 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 10 Aug 2005 08:36:07 -0500
Subject: [LinuxBIOS] bios of single devices
In-Reply-To: <E1E2oEv-00083q-Cu@www13.emo.freenet-rz.de>
References: <E1E2oEv-00083q-Cu@www13.emo.freenet-rz.de>
Message-ID: <8a0c367805081006363115a677@mail.gmail.com>

> if every single hardware device or item of a PC-System, like hard-disk or
> cd/dvd-rom drive or pci-card or floppy,
> has an own little bios-chip,

Not exactly. What those devices will have is a microcontroller or an
ASIC that is programmed to do the work.  It's not a BIOS per say but
it is code.  Most of the time its not user accessible unless you
happen to know some special things about the device.
  
> the ques is, for example, if PC beginner simply
> plug off such a device, while PC is switched on,
> and "damage" this device,
> that probably this device is not damaged,
> cause you only need to re-flash this
> little BIOS-chip or hardware-TM-brand-chip of concerning device ???

Nope.  Most of your failures are from manufacturing flaws in the
solder reflow process.  A joint that is not completely soldered will
over time fail and cease to conduct or conduct so little that the
device no longer works.
The reason this happens on power on/off most of the time is thermal
expansion.  Every time a device is powered on or off the joint goes
through a thermal cycle.  A bad joint only has N cycles before its no
good.  So when thermal cycles > N the device fails or starts doing
flaky things.
I'd guess in most cases the higher resistance of the joint causes a
slight shift in the timing of a signal and the device starts doing
flaky stuff.

Its really hard to find these joints in a manufacturing line.  In a
lot of cases the flaws are only evident via X-Ray of the joint. 
Current cost margins for devices do not allow the Mfg to 100% X-Ray
inspect all the boards.  So they work for a bit and get the process
tuned out until the process line yields a set of boards with a %
defect rate that's below what some exec or marketing person had deemed
acceptable.

Then they just start cranking out parts with spot checks here and there.

In most cases these flaws will pass the "test" and "burn in" phases
with no problems since the N level may equate to a week or so of use. 
Some times the temperature extremes and shock its exposed to in
shipping will be enough to push it over the edge.

When a device does have flashable firmware and the Mfg provides an
upgrade to "Fix" some issues a lot of those cases are where they have
enough field failures to identify where the timing is "marginal" and
apply better software to compensate.  In the case of devices with an
FPGA in them they can directly change the timing by adding buffers or
latches.

Hope this helps.

-- 
Richard A. Smith



From jschildt at lnxi.com  Wed Aug 10 16:34:19 2005
From: jschildt at lnxi.com (Jason Schildt)
Date: Wed, 10 Aug 2005 08:34:19 -0600
Subject: [BULK] Re: [LinuxBIOS] New hdama commit
In-Reply-To: <20050809225351.GH12895@earth.li>
References: <20050809220437.GE3934@zoot.lnxi.com>
	<20050809225351.GH12895@earth.li>
Message-ID: <20050810143418.GD4390@zoot.lnxi.com>

Oh dear. I've changed it back to the original.  Our build works with
both, so no loss on our side.
My apologies.

--jason--

On Tue, Aug 09, 2005 at 11:53:51PM +0100, Jonathan McDowell wrote:
> On Tue, Aug 09, 2005 at 04:04:38PM -0600, Jason Schildt wrote:
>  
> > I've just made a commit up to the public repository from the Linux
> > Networx repository mirror.  The changes only effect Opteron single/dual
> > core and hdama board specific code.
> 
> Untrue. Your commit also touched romcc.c and appears to have broken
> every build except tyan-s2735.
> 
> Compare:
> 
> http://the.earth.li/~noodles/lb/2003/log.html
> with
> http://the.earth.li/~noodles/lb/2004/log.html
> 
> 
> J.
> 
> -- 
> Trust me, you wouldn't like us when we're angry.
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios

-- 

Jason W. Schildt	
LinuxBIOS Software Engineer   
Linux Networx      



From yinghailu at gmail.com  Wed Aug 10 16:43:54 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 10 Aug 2005 07:43:54 -0700
Subject: [LinuxBIOS] New hdama commit
In-Reply-To: <2ea3fae105080917566d5e5c76@mail.gmail.com>
References: <20050809220437.GE3934@zoot.lnxi.com>
	<2ea3fae105080916478ce5fad@mail.gmail.com>
	<2ea3fae1050809170758ad603c@mail.gmail.com>
	<2ea3fae10508091720c5a0ed6@mail.gmail.com>
	<2ea3fae105080917566d5e5c76@mail.gmail.com>
Message-ID: <2ea3fae105081007435b067f2b@mail.gmail.com>

the init_ecc part need to skip the mem_hole region, You need put back
several line in init_ecc.

YH

On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> 4. it's good, to move hardware mem hole support from raminit.c to
> northbridge.c, So it will be dynamically. but problem is it will use
> more MTRRs. So carry_on should be calculated in some way...
> 
> YH
> 
> On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> > 3. are you sure the node1/core0 could start node1/core1?
> > Accorinding to my testing last year, node1/core1 only can be started
> > by node0/core0.
> >
> > YH
> >
> >
> > On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> > > 2. you overwite the enable ext id and apic id lifting
> > >
> > > YH
> > >
> > > On 8/9/05, yhlu <yinghailu at gmail.com> wrote:
> > > > 1. write_irq_tables changes is overwrite by you. that will broke all
> > > > other Opteron MB. Please change that back.
> > > >
> > > > YH
> > > >
> > > > On 8/9/05, Jason Schildt <jschildt at lnxi.com> wrote:
> > > > > All,
> > > > >
> > > > > I've just made a commit up to the public repository from the Linux
> > > > > Networx repository mirror.  The changes only effect Opteron single/dual
> > > > > core and hdama board specific code.
> > > > > Regards,
> > > > >
> > > > > --jason--
> > > > >
> > > > > --
> > > > >
> > > > > Jason W. Schildt
> > > > > LinuxBIOS Software Engineer
> > > > > Linux Networx
> > > > >
> > > > > _______________________________________________
> > > > > LinuxBIOS mailing list
> > > > > LinuxBIOS at openbios.org
> > > > > http://www.openbios.org/mailman/listinfo/linuxbios
> > > > >
> > > >
> > >
> >
>



From jschildt at lnxi.com  Wed Aug 10 17:19:24 2005
From: jschildt at lnxi.com (Jason Schildt)
Date: Wed, 10 Aug 2005 09:19:24 -0600
Subject: [LinuxBIOS] Undo all hdama changes.
Message-ID: <20050810151924.GH4390@zoot.lnxi.com>

All,

After looking at the problems this "simple" commit caused, I've rolled
it back to the revision before my commit (2005->2003).  I'll go over
these changes with Tom and Eric and try again later.
My apologies for any broken builds.

--jason--

-- 

Jason W. Schildt	
LinuxBIOS Software Engineer   
Linux Networx      



From yinghailu at gmail.com  Wed Aug 10 18:17:25 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 10 Aug 2005 09:17:25 -0700
Subject: [LinuxBIOS] Undo all hdama changes.
In-Reply-To: <20050810151924.GH4390@zoot.lnxi.com>
References: <20050810151924.GH4390@zoot.lnxi.com>
Message-ID: <2ea3fae105081009173a0da379@mail.gmail.com>

My idea about your changes
1. memhole move from raminit.c to northbridge.c, That is goog feature,
but need to keep my code in init_ecc, to skip the mem hole.
2. dual core: create entries in cpu_bus_scan or in amd_sibling_init,
later one may cause racing, if we disable CPU_INIT_SERILIZE on four
way dual core and eight dual core. You know we really need to disable
CPU_INIT_SERIALIZE otherwise init_ecc stage will take too long.
8x--->2.1x
3. you need to keep incoherent_ht.c ( K8_ALLOCATE_IO), I'm using that
for multiple CK804 early access...
4. ext apic id mode only need for 8 way dual core.
5. dual core, if it is disable the apic id of CPU should be the same
as pre-e0, instead of 0, 2, 4....
6. for CAR purpose, I can not k8_init_and_stop_secondaries, because I
need to go to __reset intead of __jmp to it. (somthing related to
stack switch).
7. We need to use write_irq_tables intead of copy_irq_tables, I have
append write_irq_tables in every MB irq_tables.c to call
copy_irq_table.
8. You need to keep CK804_DEVN_BASE=0 in some files, according to NV,
for ck804 if you change unit id, you may lose bus master support.

YH


On 8/10/05, Jason Schildt <jschildt at lnxi.com> wrote:
> All,
> 
> After looking at the problems this "simple" commit caused, I've rolled
> it back to the revision before my commit (2005->2003).  I'll go over
> these changes with Tom and Eric and try again later.
> My apologies for any broken builds.
> 
> --jason--
> 
> --
> 
> Jason W. Schildt
> LinuxBIOS Software Engineer
> Linux Networx
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From jschildt at lnxi.com  Wed Aug 10 18:27:33 2005
From: jschildt at lnxi.com (Jason Schildt)
Date: Wed, 10 Aug 2005 10:27:33 -0600
Subject: [LinuxBIOS] Undo all hdama changes.
In-Reply-To: <2ea3fae105081009173a0da379@mail.gmail.com>
References: <20050810151924.GH4390@zoot.lnxi.com>
	<2ea3fae105081009173a0da379@mail.gmail.com>
Message-ID: <20050810162733.GA9157@zoot.lnxi.com>

Thanks, YH.  I'll pass these by Tom and make the necessary changes so as
not to break everything.  I'll also submit a diff to the mailing list
before committing.

--jason--

On Wed, Aug 10, 2005 at 09:17:25AM -0700, yhlu wrote:
> My idea about your changes
> 1. memhole move from raminit.c to northbridge.c, That is goog feature,
> but need to keep my code in init_ecc, to skip the mem hole.
> 2. dual core: create entries in cpu_bus_scan or in amd_sibling_init,
> later one may cause racing, if we disable CPU_INIT_SERILIZE on four
> way dual core and eight dual core. You know we really need to disable
> CPU_INIT_SERIALIZE otherwise init_ecc stage will take too long.
> 8x--->2.1x
> 3. you need to keep incoherent_ht.c ( K8_ALLOCATE_IO), I'm using that
> for multiple CK804 early access...
> 4. ext apic id mode only need for 8 way dual core.
> 5. dual core, if it is disable the apic id of CPU should be the same
> as pre-e0, instead of 0, 2, 4....
> 6. for CAR purpose, I can not k8_init_and_stop_secondaries, because I
> need to go to __reset intead of __jmp to it. (somthing related to
> stack switch).
> 7. We need to use write_irq_tables intead of copy_irq_tables, I have
> append write_irq_tables in every MB irq_tables.c to call
> copy_irq_table.
> 8. You need to keep CK804_DEVN_BASE=0 in some files, according to NV,
> for ck804 if you change unit id, you may lose bus master support.
> 
> YH
> 
> 
> On 8/10/05, Jason Schildt <jschildt at lnxi.com> wrote:
> > All,
> > 
> > After looking at the problems this "simple" commit caused, I've rolled
> > it back to the revision before my commit (2005->2003).  I'll go over
> > these changes with Tom and Eric and try again later.
> > My apologies for any broken builds.
> > 
> > --jason--
> > 
> > --
> > 
> > Jason W. Schildt
> > LinuxBIOS Software Engineer
> > Linux Networx
> > 
> > _______________________________________________
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
> >

-- 

Jason W. Schildt	
LinuxBIOS Software Engineer   
Linux Networx      



From yinghailu at gmail.com  Wed Aug 10 18:33:42 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 10 Aug 2005 09:33:42 -0700
Subject: [LinuxBIOS] Undo all hdama changes.
In-Reply-To: <20050810162733.GA9157@zoot.lnxi.com>
References: <20050810151924.GH4390@zoot.lnxi.com>
	<2ea3fae105081009173a0da379@mail.gmail.com>
	<20050810162733.GA9157@zoot.lnxi.com>
Message-ID: <2ea3fae10508100933574cd1e@mail.gmail.com>

Yes, that would be easier if discuss one by one with diff.

YH



On 8/10/05, Jason Schildt <jschildt at lnxi.com> wrote:
> Thanks, YH.  I'll pass these by Tom and make the necessary changes so as
> not to break everything.  I'll also submit a diff to the mailing list
> before committing.
> 
> --jason--
> 
> On Wed, Aug 10, 2005 at 09:17:25AM -0700, yhlu wrote:
> > My idea about your changes
> > 1. memhole move from raminit.c to northbridge.c, That is goog feature,
> > but need to keep my code in init_ecc, to skip the mem hole.
> > 2. dual core: create entries in cpu_bus_scan or in amd_sibling_init,
> > later one may cause racing, if we disable CPU_INIT_SERILIZE on four
> > way dual core and eight dual core. You know we really need to disable
> > CPU_INIT_SERIALIZE otherwise init_ecc stage will take too long.
> > 8x--->2.1x
> > 3. you need to keep incoherent_ht.c ( K8_ALLOCATE_IO), I'm using that
> > for multiple CK804 early access...
> > 4. ext apic id mode only need for 8 way dual core.
> > 5. dual core, if it is disable the apic id of CPU should be the same
> > as pre-e0, instead of 0, 2, 4....
> > 6. for CAR purpose, I can not k8_init_and_stop_secondaries, because I
> > need to go to __reset intead of __jmp to it. (somthing related to
> > stack switch).
> > 7. We need to use write_irq_tables intead of copy_irq_tables, I have
> > append write_irq_tables in every MB irq_tables.c to call
> > copy_irq_table.
> > 8. You need to keep CK804_DEVN_BASE=0 in some files, according to NV,
> > for ck804 if you change unit id, you may lose bus master support.
> >
> > YH
> >
> >
> > On 8/10/05, Jason Schildt <jschildt at lnxi.com> wrote:
> > > All,
> > >
> > > After looking at the problems this "simple" commit caused, I've rolled
> > > it back to the revision before my commit (2005->2003).  I'll go over
> > > these changes with Tom and Eric and try again later.
> > > My apologies for any broken builds.
> > >
> > > --jason--
> > >
> > > --
> > >
> > > Jason W. Schildt
> > > LinuxBIOS Software Engineer
> > > Linux Networx
> > >
> > > _______________________________________________
> > > LinuxBIOS mailing list
> > > LinuxBIOS at openbios.org
> > > http://www.openbios.org/mailman/listinfo/linuxbios
> > >
> 
> --
> 
> Jason W. Schildt
> LinuxBIOS Software Engineer
> Linux Networx
>



From kfuchs at winternet.com  Wed Aug 10 22:40:48 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Wed, 10 Aug 2005 15:40:48 -0500 (CDT)
Subject: [LinuxBIOS] LinuxBIOS Summit
Message-ID: <200508102040.j7AKem8Z003034@tundra.winternet.com>

What topics will be covered at the LinuxBIOS Summit?

Will it be limited to technical issues and things that directly
affect technical issues such as access to chip set specifications,
NDA issues, new BIOS technologies and LinuxBIOS' competition, etc.?

Is making LinuxBIOS as popular and compelling as Linux and GNU/Linux
distributions a reasonable and desirable goal?

Would support of operating systems other than Linux such as OpenSolaris,
xBSD, Plan 9, and MS Windows 2000/XP be a reasonable goal?  Perhaps,
a payload similar to ADLO could be used for non-Linux OSes.

LinuxBIOS is now extremely well designed and all the core developers
should get huge bonuses or well-deserved Kudos!  However, sometimes
various mainboard builds break and some mainboard ports remain
incomplete.  We need to support more chip sets and mainboards.  How can
we do this? How can we make porting to new chip sets and mainboards easier?

We might try to generate a generic flash image for each mainboard
that people new to LinuxBIOS can download and use with minimal time
and effort required.  It could ask a few simple questions to customize
the boot with the option to store the answers to NVRAM.  This could
be taken to the extreme of a single Live CD that boots Linux and runs
a script that identifies the chip sets and mainboard and gives the user
the option of flashing his BIOS device with an appropriate LinuxBIOS
image (or one that at least supports all critical devices).

Will the LinuxBIOS Summit be rather open-ended like the above or will
there be a defined agenda or both?

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From yinghailu at gmail.com  Wed Aug 10 23:22:14 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 10 Aug 2005 14:22:14 -0700
Subject: [LinuxBIOS] LinuxBIOS Summit
In-Reply-To: <200508102040.j7AKem8Z003034@tundra.winternet.com>
References: <200508102040.j7AKem8Z003034@tundra.winternet.com>
Message-ID: <2ea3fae1050810142239abfe60@mail.gmail.com>

my ideas
1. acpi support?
2. OpenSolaris for AMD64 use OpenFirmware inferface
3. ADLO to support windows or FreeBSD
4. CAR in other x86 platform....
5. kernel_tiny and kexec ---------------
6. MIPS64 support with LinuxBIOS??
7. Native support to FreeBSD?
8. other chipset support plan/cordination: No double porting ....

YH

On 8/10/05, Ken Fuchs <kfuchs at winternet.com> wrote:
> What topics will be covered at the LinuxBIOS Summit?
> 
> Will it be limited to technical issues and things that directly
> affect technical issues such as access to chip set specifications,
> NDA issues, new BIOS technologies and LinuxBIOS' competition, etc.?
> 
> Is making LinuxBIOS as popular and compelling as Linux and GNU/Linux
> distributions a reasonable and desirable goal?
> 
> Would support of operating systems other than Linux such as OpenSolaris,
> xBSD, Plan 9, and MS Windows 2000/XP be a reasonable goal?  Perhaps,
> a payload similar to ADLO could be used for non-Linux OSes.
> 
> LinuxBIOS is now extremely well designed and all the core developers
> should get huge bonuses or well-deserved Kudos!  However, sometimes
> various mainboard builds break and some mainboard ports remain
> incomplete.  We need to support more chip sets and mainboards.  How can
> we do this? How can we make porting to new chip sets and mainboards easier?
> 
> We might try to generate a generic flash image for each mainboard
> that people new to LinuxBIOS can download and use with minimal time
> and effort required.  It could ask a few simple questions to customize
> the boot with the option to store the answers to NVRAM.  This could
> be taken to the extreme of a single Live CD that boots Linux and runs
> a script that identifies the chip sets and mainboard and gives the user
> the option of flashing his BIOS device with an appropriate LinuxBIOS
> image (or one that at least supports all critical devices).
> 
> Will the LinuxBIOS Summit be rather open-ended like the above or will
> there be a defined agenda or both?
> 
> Sincerely,
> 
> Ken Fuchs <kfuchs at winternet.com>
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From Stephen.Kimball at bench.com  Wed Aug 10 23:35:50 2005
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Wed, 10 Aug 2005 17:35:50 -0400
Subject: [LinuxBIOS] VGA support
Message-ID: <30ADB28314F8B744AB478FB5EDA044B30D3C10@nh-ex01.bench.com>

Could someone explain the different VGA options with LinuxBIOS?

I've read the testbios FAQ items.  This seems to be a utility program
that can be run after the system comes up to initialize a VGA card. Then
I suppose one could open an X window.

Then there are several LinuxBIOS Options that mention VGA:
   VGABIOS_START 
   PCI_VGA_RAM_IMAGE_START 
   CONFIG_CONSOLE_VGA
   CONFIG_LEGACY_VGABIOS

Some VGA options are more useful than others.  For example,
CONFIG_LEGACY_VGABIOS does not seem to be used.
I see CONFIG_CONSOLE_VGA enables logging to the VGA. 
Could someone write a FAQ describing how to make CONFIG_CONSOLE_VGA
work?
Thanks.

Steve



From yinghailu at gmail.com  Thu Aug 11 00:35:49 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 10 Aug 2005 15:35:49 -0700
Subject: [LinuxBIOS] VGA support
In-Reply-To: <30ADB28314F8B744AB478FB5EDA044B30D3C10@nh-ex01.bench.com>
References: <30ADB28314F8B744AB478FB5EDA044B30D3C10@nh-ex01.bench.com>
Message-ID: <2ea3fae10508101535621c922f@mail.gmail.com>

there is two kind of VGA that we need to support
1. onboard vga
2. addon card.

two CONFIG in MB Option.lb
#VGA Console
default CONFIG_CONSOLE_VGA=1
default CONFIG_PCI_ROM_RUN=1

CONFIG_PCI_ROM_RUN will make sure all the option rom will be called.

Also in MB Config.lb  You need to specify for your onboard VGA
                                        device pci 9.0 on  # PCI
                                                chip drivers/pci/onboard
                                                        device pci 9.0 on end
                                                        register
"rom_address" = "0xfff80000" #512k image
                                                        #register
"rom_address" = "0xfff00000" #1M image
                                                end
                                        end

Please make sure the device num should be right. Otherwise it can not
get exact ROM address.

Also when you plug add on display card to MB with onboard VGA, only
addon card will be used. That is the same as Normal BIOS.

For onboard VGA, You still need to modify your target Config.lb.
in noral section

romimage "normal"
#       48K for SCSI FW or ATI ROM
        option ROM_SIZE = 475136

It will leave space for vga option rom in flash.

So at last for your linuxbios.rom, you should do 
cat atix.rom linuxbios.rom > final_linuxbios.rom

you need to make sure the final_linuxbios.rom size is 512k or 1M.

please use dd to get you atix.rom when running Normal BIOS.

YH


On 8/10/05, Stephen.Kimball at bench.com <Stephen.Kimball at bench.com> wrote:
> Could someone explain the different VGA options with LinuxBIOS?
> 
> I've read the testbios FAQ items.  This seems to be a utility program
> that can be run after the system comes up to initialize a VGA card. Then
> I suppose one could open an X window.
> 
> Then there are several LinuxBIOS Options that mention VGA:
>    VGABIOS_START
>    PCI_VGA_RAM_IMAGE_START
>    CONFIG_CONSOLE_VGA
>    CONFIG_LEGACY_VGABIOS
> 
> Some VGA options are more useful than others.  For example,
> CONFIG_LEGACY_VGABIOS does not seem to be used.
> I see CONFIG_CONSOLE_VGA enables logging to the VGA.
> Could someone write a FAQ describing how to make CONFIG_CONSOLE_VGA
> work?
> Thanks.
> 
> Steve
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From ollie at lanl.gov  Thu Aug 11 00:41:02 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed, 10 Aug 2005 16:41:02 -0600
Subject: [LinuxBIOS] VGA support
In-Reply-To: <30ADB28314F8B744AB478FB5EDA044B30D3C10@nh-ex01.bench.com>
References: <30ADB28314F8B744AB478FB5EDA044B30D3C10@nh-ex01.bench.com>
Message-ID: <1123713662.5224.13.camel@logarithm.lanl.gov>

On Wed, 2005-08-10 at 17:35 -0400, Stephen.Kimball at bench.com wrote:
> Could someone explain the different VGA options with LinuxBIOS?
> 
> I've read the testbios FAQ items.  This seems to be a utility program
> that can be run after the system comes up to initialize a VGA card. Then
> I suppose one could open an X window.
> 
> Then there are several LinuxBIOS Options that mention VGA:
>    VGABIOS_START 

This one is obsolete, it was used for VIA/EPIA only.
I am going to remove it soon.

>    PCI_VGA_RAM_IMAGE_START 

This is were the VGABIOS is copy to in DRAM. By PCI spec, it should be
0xC0000 for x86.

>    CONFIG_CONSOLE_VGA

This control if you are going to use VGA console. If it is enable, you
can read message from VGA screen instead of serial console.

>    CONFIG_LEGACY_VGABIOS
> 

This one is obsolete too like VGABIOS_START.

> Some VGA options are more useful than others.  For example,
> CONFIG_LEGACY_VGABIOS does not seem to be used.
> I see CONFIG_CONSOLE_VGA enables logging to the VGA. 
> Could someone write a FAQ describing how to make CONFIG_CONSOLE_VGA
> work?
> Thanks.
> 
> Steve
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From yinghailu at gmail.com  Thu Aug 11 00:47:27 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 10 Aug 2005 15:47:27 -0700
Subject: [LinuxBIOS] VGA support
In-Reply-To: <1123713662.5224.13.camel@logarithm.lanl.gov>
References: <30ADB28314F8B744AB478FB5EDA044B30D3C10@nh-ex01.bench.com>
	<1123713662.5224.13.camel@logarithm.lanl.gov>
Message-ID: <2ea3fae105081015475dc0d61b@mail.gmail.com>

I add some lines 

http://www.linuxbios.org/index.php/VGA_support

Please check it and enrich it.

YH

On 8/10/05, Li-Ta Lo <ollie at lanl.gov> wrote:
> On Wed, 2005-08-10 at 17:35 -0400, Stephen.Kimball at bench.com wrote:
> > Could someone explain the different VGA options with LinuxBIOS?
> >
> > I've read the testbios FAQ items.  This seems to be a utility program
> > that can be run after the system comes up to initialize a VGA card. Then
> > I suppose one could open an X window.
> >
> > Then there are several LinuxBIOS Options that mention VGA:
> >    VGABIOS_START
> 
> This one is obsolete, it was used for VIA/EPIA only.
> I am going to remove it soon.
> 
> >    PCI_VGA_RAM_IMAGE_START
> 
> This is were the VGABIOS is copy to in DRAM. By PCI spec, it should be
> 0xC0000 for x86.
> 
> >    CONFIG_CONSOLE_VGA
> 
> This control if you are going to use VGA console. If it is enable, you
> can read message from VGA screen instead of serial console.
> 
> >    CONFIG_LEGACY_VGABIOS
> >
> 
> This one is obsolete too like VGABIOS_START.
> 
> > Some VGA options are more useful than others.  For example,
> > CONFIG_LEGACY_VGABIOS does not seem to be used.
> > I see CONFIG_CONSOLE_VGA enables logging to the VGA.
> > Could someone write a FAQ describing how to make CONFIG_CONSOLE_VGA
> > work?
> > Thanks.
> >
> > Steve
> >
> > _______________________________________________
> > LinuxBIOS mailing list
> > LinuxBIOS at openbios.org
> > http://www.openbios.org/mailman/listinfo/linuxbios
> --
> Li-Ta Lo <ollie at lanl.gov>
> Los Alamos National Lab
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From Stephen.Kimball at bench.com  Thu Aug 11 14:55:07 2005
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Thu, 11 Aug 2005 08:55:07 -0400
Subject: [LinuxBIOS] VGA support
Message-ID: <30ADB28314F8B744AB478FB5EDA044B30D3C11@nh-ex01.bench.com>

Thank you very much.  The new page is very helpful.

Let me ask a few questions. 
1. Does the new page describe onboard and addon card?
   I expect the MB Config.lb would change for an addon card?
   I assume the Config file would describe the PCI slots
   and steps 2 & 3 would be the same for an addon card.
2. testbios is a third choice, which is useful if the
   VGA image won't fit in the ROM device.
   Should you move the testbios FAQ info to the VGA support page?
3. Will there be a link from the Main page to the VGA Support page?

Steve

-----Original Message-----
From: yhlu [mailto:yinghailu at gmail.com] 
Sent: Wednesday, August 10, 2005 6:47 PM
To: Li-Ta Lo
Cc: Kimball, Stephen; LinuxBIOS
Subject: Re: [LinuxBIOS] VGA support

I add some lines 

http://www.linuxbios.org/index.php/VGA_support

Please check it and enrich it.

YH



From steve at digidescorp.com  Thu Aug 11 15:57:50 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Thu, 11 Aug 2005 08:57:50 -0500
Subject: [LinuxBIOS] Re: VGA support
Message-ID: <000001c59e7c$acfcd030$6ffea8c0@banana>

Yhlu writes:
> So at last for your linuxbios.rom, you should do 
> cat atix.rom linuxbios.rom > final_linuxbios.rom

I went through this exercise with my board last week, and this procedure
didn't work for me. Might be because there is nothing in the LB code
that prevents the memory range occupied by the video ROM from being
allocated to PCI devices.

What I finally ended up doing is creating a wrapper .S file for my
mainboard that pulls the video ROM into the compiled LB RAM image:

	.section .rodata.optionrom
	.globl	_vgarom_start
_vgarom_start:
	.incbin
"../../../../../src/mainboard/intel/xe7501devkit/vga.rom"
	.globl	_vgarom_end
_vgarom_end:

In Config.lb I reference a symbol defined in the wrapper:

    chip drivers/pci/onboard
        device pci 0.0 on end
            register "rom_address" = "_vgarom_start"
    end

...and in my mainboard chip.h I forward-declare the symbol, so static.c
can compile:

    extern unsigned char _vgarom_start[];

This strategy has the advantage of making the rom address independent of
changes in the size of LinuxBIOS or the payload. The disadvantage is
that the video ROM gets compiled into both the fallback and normal LB
RAM images (it takes up twice as much flash space as it needs to).

I am wondering if it might be useful for LB to support some kind of
flash partition structure (similar to Redboot) to allow storage of
things common to both fallback and normal images, or to support user
selection among two or more payloads.

------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"

 #include <standard.disclaimer>






From yinghailu at gmail.com  Thu Aug 11 18:24:36 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 11 Aug 2005 09:24:36 -0700
Subject: [LinuxBIOS] Re: VGA support
In-Reply-To: <000001c59e7c$acfcd030$6ffea8c0@banana>
References: <000001c59e7c$acfcd030$6ffea8c0@banana>
Message-ID: <2ea3fae105081109247b907a88@mail.gmail.com>

That is good, but the atix.rom will be compiled into normal image and
fallback image.

Also for Fallback image, you will make linuxbios_ram.rom too big.
finally image could be greater than 128K for four way and 8 way
system.

Maybe we can think about one way to let fallback image use the
atix.rom in normal image.

then the problem comes again: some time we need flash normal image
only and keep fallback image for safe, So You need to make sure
atix.rom in the exact same position.

YH



On 8/11/05, Steven J. Magnani <steve at digidescorp.com> wrote:
> Yhlu writes:
> > So at last for your linuxbios.rom, you should do
> > cat atix.rom linuxbios.rom > final_linuxbios.rom
> 
> I went through this exercise with my board last week, and this procedure
> didn't work for me. Might be because there is nothing in the LB code
> that prevents the memory range occupied by the video ROM from being
> allocated to PCI devices.
> 
> What I finally ended up doing is creating a wrapper .S file for my
> mainboard that pulls the video ROM into the compiled LB RAM image:
> 
>        .section .rodata.optionrom
>        .globl  _vgarom_start
> _vgarom_start:
>        .incbin
> "../../../../../src/mainboard/intel/xe7501devkit/vga.rom"
>        .globl  _vgarom_end
> _vgarom_end:
> 
> In Config.lb I reference a symbol defined in the wrapper:
> 
>    chip drivers/pci/onboard
>        device pci 0.0 on end
>            register "rom_address" = "_vgarom_start"
>    end
> 
> ...and in my mainboard chip.h I forward-declare the symbol, so static.c
> can compile:
> 
>    extern unsigned char _vgarom_start[];
> 
> This strategy has the advantage of making the rom address independent of
> changes in the size of LinuxBIOS or the payload. The disadvantage is
> that the video ROM gets compiled into both the fallback and normal LB
> RAM images (it takes up twice as much flash space as it needs to).
> 
> I am wondering if it might be useful for LB to support some kind of
> flash partition structure (similar to Redboot) to allow storage of
> things common to both fallback and normal images, or to support user
> selection among two or more payloads.
> 
> ------------------------------------------------------------------------
>  Steven J. Magnani               "I claim this network for MARS!
>  www.digidescorp.com              Earthling, return my space modulator!"
> 
>  #include <standard.disclaimer>
> 
> 
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From dbell at nxtv.com  Thu Aug 11 18:27:42 2005
From: dbell at nxtv.com (Doug Bell)
Date: Thu, 11 Aug 2005 09:27:42 -0700
Subject: [LinuxBIOS] BIOS Savior RD1-PMC4 on VIA EPIA-SP
Message-ID: <1123777662.19895.22.camel@Doug>

I am trying to use the PMC4 on the EPIA-SP ( vt8237 ) but can't write to
the internal flash. 

I have code that can read and write successfully on a SST49LF004
installed in the top socket. However, when I throw the switch to the
internal flash (PMC Pm49FL004 ) I can read the flash ID via the
registers at ffbc0000 and 0001, but I can't read the ID via the typical
jedec cycle. Interestingly ( or not ) I seem to read back the last byte
written out in my code, e.g. a 0x90 0x90 is read as the ID after
completing the sequence to enter product ID mode ( which ends with a
write of 0x90). 

I tried adding various sleeps to rule out timing issues. I am assuming
the vt8237 is operating in LPC mode as opposed to FWH; the datasheet for
the Pm49LF004 mentions it is read-compatible for FWH. I find it curious
that the 0x90 I mentioned above is the same BYTE i wrote out, rather
than some nibble-based variation like 99 or 00 (since LPC bus is 4
bits ). 

Any insight would be greatly appreciated. Thanks, Doug




From Narahari.Narasimhaiah at honeywell.com  Thu Aug 11 16:56:51 2005
From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10))
Date: Thu, 11 Aug 2005 07:56:51 -0700
Subject: [LinuxBIOS] Booting windows XP
Message-ID: <77ED2BF75D59D1439F90412CC5B10974228869F5@ie10-sahara.hiso.honeywell.com>


Hi,
I am from India.
We are trying to boot Windows XP through LinuxBIOS ( freebios + BochsBIOS ).
We could load the XP image into the RAM but the int-16 is called for ever
after many int 13 calls.
Could you please help me with this respect

With regards,
________________________Honeywell

Narahari Murthy N.
Honeywell Technology Solutions Lab - Bangalore
151/1, Doraisanipalya, Bannerghatta Road
Bangalore - 560076, India
Ph: 91-80-26588360 ext. 2318
ph_res: 91-80-22380923
mobile: 9880806206
e-mail: narahari.narasimhaiah at honeywell.com

" If you love something, set it free. If it comes back to you, it's yours.
If it doesn't, it never was"
"You cannot believe in God until you believe in yourself" - Swami
Vivekananda."
"Our greatest glory consists not in never falling, but in rising every time
we fall"
"In the end, we will remember not the words of our enemies, but the silence
of our friends"


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

From yinghailu at gmail.com  Thu Aug 11 18:32:07 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 11 Aug 2005 09:32:07 -0700
Subject: [LinuxBIOS] VGA support
In-Reply-To: <30ADB28314F8B744AB478FB5EDA044B30D3C11@nh-ex01.bench.com>
References: <30ADB28314F8B744AB478FB5EDA044B30D3C11@nh-ex01.bench.com>
Message-ID: <2ea3fae10508110932485966b6@mail.gmail.com>

1. No, the rom address for addon card is allocated by dev_...., So you
don't need to put that in MB Config.lb. And if you need put that in
Config.lb, the device will be onboard device in LinuxBIOS, You must
has your own driver for that, and the driver need to get ROM address
from ROM BAR, and use call..
2. Yes, But for Opteron HT, there is more stuff to be set, MMIO, and IO.
3. current VGA support in Porting guide. I guess We can put one link
to point to testbios in FAQ, anyway FAQ part need to better
re-orginze...

YH

On 8/11/05, Stephen.Kimball at bench.com <Stephen.Kimball at bench.com> wrote:
> Thank you very much.  The new page is very helpful.
> 
> Let me ask a few questions.
> 1. Does the new page describe onboard and addon card?
>   I expect the MB Config.lb would change for an addon card?
>   I assume the Config file would describe the PCI slots
>   and steps 2 & 3 would be the same for an addon card.
> 2. testbios is a third choice, which is useful if the
>   VGA image won't fit in the ROM device.
>   Should you move the testbios FAQ info to the VGA support page?
> 3. Will there be a link from the Main page to the VGA Support page?
> 
> Steve
> 
> -----Original Message-----
> From: yhlu [mailto:yinghailu at gmail.com]
> Sent: Wednesday, August 10, 2005 6:47 PM
> To: Li-Ta Lo
> Cc: Kimball, Stephen; LinuxBIOS
> Subject: Re: [LinuxBIOS] VGA support
> 
> I add some lines
> 
> http://www.linuxbios.org/index.php/VGA_support
> 
> Please check it and enrich it.
> 
> YH
>



From yinghailu at gmail.com  Thu Aug 11 18:56:24 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 11 Aug 2005 09:56:24 -0700
Subject: [LinuxBIOS] flash machine
Message-ID: <2ea3fae1050811095669f68ce5@mail.gmail.com>

Is there any device, that 
1. with USB 2.0 interface.
2. can be used under Linux

YH



From Stephen.Kimball at bench.com  Thu Aug 11 19:32:55 2005
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Thu, 11 Aug 2005 13:32:55 -0400
Subject: [LinuxBIOS] VGA support
Message-ID: <30ADB28314F8B744AB478FB5EDA044B30D3C13@nh-ex01.bench.com>

Yhlu writes:
> 3. current VGA support in Porting guide. I guess We can put one link
> to point to testbios in FAQ, anyway FAQ part need to better
> re-orginze...

I might not think to look in the Porting Guide for VGA Support.
I suggest it be another topic off the main page.  And maybe the Porting
Guide Page should include Ron's latest article - "Porting LinuxBIOS to
the AMD SC520"?  



From yinghailu at gmail.com  Thu Aug 11 20:58:24 2005
From: yinghailu at gmail.com (yhlu)
Date: Thu, 11 Aug 2005 11:58:24 -0700
Subject: [LinuxBIOS] VGA support
In-Reply-To: <30ADB28314F8B744AB478FB5EDA044B30D3C13@nh-ex01.bench.com>
References: <30ADB28314F8B744AB478FB5EDA044B30D3C13@nh-ex01.bench.com>
Message-ID: <2ea3fae105081111586ea95434@mail.gmail.com>

the Main page list is too long now.

YH

On 8/11/05, Stephen.Kimball at bench.com <Stephen.Kimball at bench.com> wrote:
> Yhlu writes:
> > 3. current VGA support in Porting guide. I guess We can put one link
> > to point to testbios in FAQ, anyway FAQ part need to better
> > re-orginze...
> 
> I might not think to look in the Porting Guide for VGA Support.
> I suggest it be another topic off the main page.  And maybe the Porting
> Guide Page should include Ron's latest article - "Porting LinuxBIOS to
> the AMD SC520"?
>



From jcarr at linuxmachines.com  Fri Aug 12 09:42:50 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Fri, 12 Aug 2005 00:42:50 -0700
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <200508031527.j73FR9fW016999@tundra.winternet.com>
References: <200508031527.j73FR9fW016999@tundra.winternet.com>
Message-ID: <42FC52FA.30800@linuxmachines.com>

On 08/03/2005 08:27 AM, Ken Fuchs wrote:

> BTW, my flash burner is an older Enhanced Willem Universal Programmer.
> I got mine for only $60 US over a year ago.  I've seen it for less
> than $40 on eBay a few weeks ago.  The newest model is going for about
> $50 US.  It does a LinuxBIOS flash in about 5 minutes; not bad for a
> $60 burner.  However, it does require changing DIP switches to match
> an image for each device it can program.  Great for the amateur or
> professional with a small budget.

The webpage that is linked rom the linuxbios FAQ says that it comes with
a USB cable. Are you able to control this device from Linux? It would be
a big hassle for me since I don't have any windows machines.

Thanks,
Jeff



From jcarr at linuxmachines.com  Fri Aug 12 10:19:10 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Fri, 12 Aug 2005 01:19:10 -0700
Subject: [LinuxBIOS] flash_rom output from a sis chipset
Message-ID: <42FC5B7E.7060706@linuxmachines.com>

I tried the linux bios flash_rom utility today on a sis based board. I
tried to read out the bios as a file. It failed. (output below)

flash_rom says: "Trying MD-2802 (M-Systems DiskOnChip Millennium
Module), 8 KB". Interestingly, the second google hit of "M-Systems
DiskOnChip Millennium 2802" was the linuxbios wiki :)

I thought I'd post the output for informative purposes. I'd dig more if
anyone was interested.

Is the BIOS chip on this machine really only 8KB in size? I find that
really hard to believe.

Jeff

lspci:
0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] SiS 645xx
(rev 51)
0000:00:01.0 PCI bridge: Silicon Integrated Systems [SiS]: Unknown
device 0003
0000:00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS963 [MuTIOL
Media IO] (rev 14)
0000:00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016
0000:00:02.3 FireWire (IEEE 1394): Silicon Integrated Systems [SiS]
FireWire Controller
0000:00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
0000:00:02.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem
Controller (rev a0)
0000:00:02.7 Multimedia audio controller: Silicon Integrated Systems
[SiS] Sound Controller (rev a0)
0000:00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0
Controller (rev 0f)
0000:00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0
Controller (rev 0f)
0000:00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0
Controller (rev 0f)
0000:00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0
Controller
0000:00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8169 Gigabit Ethernet (rev 10)
0000:00:0c.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus
Controller (rev 01)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350
[Mobility Radeon 9600 M10]

flash_rom -r output:
Calibrating timer since microsleep sucks ... takes a second
Setting up microsecond timing loop
796M loops per second
OK, calibrated, now do the deed
Trying Am29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Trying At29C040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying Mx29f002, 256 KB
probe_29f002: id1 0xff, id2 0xff
Trying SST29EE020A, 256 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST28SF040A, 512 KB
probe_28sf040: id1 0xff, id2 0xff
Trying SST39SF020A, 256 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST39VF020, 256 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF040, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF002A/B, 256 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF003A/B, 384 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF004A/B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying SST49LF008A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Trying Pm49FL004, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying W29C011, 128 KB
probe_jedec: id1 0xef, id2 0xd8
Trying W29C020C, 256 KB
probe_jedec: id1 0xff, id2 0xff
Trying W49F002U, 256 KB
probe_jedec: id1 0xff, id2 0xff
Trying M29F400BT, 512 KB
probe_m29f400bt: id1 0xff, id2 0xff
Trying 82802ab, 512 KB
probe_82802ab: id1 0xff, id2 0xff
Trying 82802ac, 1024 KB
probe_82802ab: id1 0xff, id2 0xff
Trying MD-2802 (M-Systems DiskOnChip Millennium Module), 8 KB
probe_md2802:
probe_md2802: *******************************
probe_md2802: * THIS IS A PRE ALPHA VERSION *
probe_md2802: * IN THE DEVELOPEMENT *********
probe_md2802: * PROCESS RIGHT NOW. **********
probe_md2802: *******************************
probe_md2802: * IF YOU ARE NOT A DEVELOPER **
probe_md2802: * THEN DO NOT TRY TO READ OR **
probe_md2802: * WRITE TO THIS DEVICE ********
probe_md2802: *******************************
probe_md2802:
probe_md2802: switching off reset mode ...
probe_md2802: switching off reset mode ... done
probe_md2802:
probe_md2802: switching off write protection ...
probe_md2802: switching off write protection ... done
probe_md2802:
probe_md2802: IPL_0x0000: 0x6d
probe_md2802: IPL_0x0001: 0x00
probe_md2802: IPL_0x0002: 0x01
probe_md2802: IPL_0x0003: 0x83
probe_md2802:
probe_md2802: ChipID: 0xed
probe_md2802: DOCStatus: 0xba
probe_md2802: FloorSelect: 0x00
probe_md2802: CDSNControl: 0xb0
probe_md2802: CDSNDeviceSelect: 0x70
probe_md2802: ECCConfiguration: 0xee
probe_md2802: CDSNSlowIO: 0xed
probe_md2802: ECCSyndrome0: 0xee
probe_md2802: ECCSyndrome1: 0xe6
probe_md2802: ECCSyndrome2: 0xed
probe_md2802: ECCSyndrome3: 0xb0
probe_md2802: ECCSyndrome4: 0xff
probe_md2802: ECCSyndrome5: 0xee
probe_md2802: AliasResolution: 0xf1
probe_md2802: ConfigurationInput: 0xe6
probe_md2802: ReadPipelineInitialization: 0xed
probe_md2802: LastDataRead: 0xc0
probe_md2802:
probe_md2802: checking ECCConfiguration toggle bit
probe_md2802: 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
probe_md2802: toggle result: 5/5
EEPROM not found
root at jcarr:/home/jcarr/linuxbios/LinuxBIOSv2/util/flash_and_burn#



From jcarr at linuxmachines.com  Fri Aug 12 10:40:17 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Fri, 12 Aug 2005 01:40:17 -0700
Subject: [LinuxBIOS] flash_rom output from a sis chipset
In-Reply-To: <42FC5B7E.7060706@linuxmachines.com>
References: <42FC5B7E.7060706@linuxmachines.com>
Message-ID: <42FC6071.8080603@linuxmachines.com>

On 08/12/2005 01:19 AM, Jeff Carr wrote:
> I tried the linux bios flash_rom utility today on a sis based board. I
> tried to read out the bios as a file. It failed. (output below)

I see now in the archive that the error: "EEPROM not found" came up on a
thread last year. The thread ended in "find out what chip it is". As far
as I know I can't see the BIOS chip on this portable. Oh well.

Then also something about using MTD. I guess I'll try that and see what
MTD reports.

> Is the BIOS chip on this machine really only 8KB in size? I find that
> really hard to believe.

I take it there aren't good programming manuals/data sheets for the
M-Systems line of chips? I found one crappy document via google. That
would be a shame; AMD and Intel seem real good about documenting their
flash ships.

Jeff



From kfuchs at winternet.com  Fri Aug 12 17:47:02 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Fri, 12 Aug 2005 10:47:02 -0500 (CDT)
Subject: [LinuxBIOS] BIOS Saver RD1
References: <42FC52FA.30800@linuxmachines.com>
Message-ID: <200508121547.j7CFl2en014246@tundra.winternet.com>

> On 08/03/2005 08:27 AM, Ken Fuchs wrote:

> > BTW, my flash burner is an older Enhanced Willem Universal 
> > Programmer.  I got mine for only $60 US over a year ago.  I've
> > seen it for less than $40 on eBay a few weeks ago.  The newest
> > model is going for about $50 US.  It does a LinuxBIOS flash in
> > about 5 minutes; not bad for a $60 burner.  However, it does
> > require changing DIP switches to match an image for each device it
> > can program.  Great for the amateur or professional with a small
> > budget.

Jeff Carr wrote:

> The webpage that is linked rom the linuxbios FAQ says that it 
> comes with a USB cable.

The USB cable is used to provide power only.  (I disconnect the USB
cable when inserting/removing a PLCC flash device, although the manual
doesn't mention this.  I just do it because it can't hurt and it might
be safer.)

The programmmer is controlled via a parallel port in EPP (Normal)
mode (This can checked/set in the COTS BIOS of most IBM PC
compatibles.)

> Are you able to control this device from Linux? 

The Enhanced Willem Universal Programmer comes with a CD containing a
MS Windows program that shows how the DIP switches should be set for
any supported device.  Of course, this program also erases, writes &
verifies BIOS image files among other things.

> It would be a big hassle for me since I don't have any windows
> machines.

I use MS Windows 2000 for the (Willem) EPROM3 software.

Here's a web page that suggests that there is a remote chance that
EPROM3 might run on Linux via Wine:

http://www.sdconsult.no/linux/wine-doc/hardware-trace.html

Has anyone tried to run EPROM3 on Linux via Wine?

The Willem CD Readme.txt mentions "win98/me", so it might be easier to
just borrow a MS Windows machine or get one free (many people are
giving away Pentium II and even lower MHz Pentium III machines).

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From yinghailu at gmail.com  Fri Aug 12 18:46:06 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 12 Aug 2005 09:46:06 -0700
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <200508121547.j7CFl2en014246@tundra.winternet.com>
References: <42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
Message-ID: <2ea3fae105081209467e5f189a@mail.gmail.com>

I hope I could get one with USB2 cable and it could work with Linux.

USB2 would be faster than others.

YH

On 8/12/05, Ken Fuchs <kfuchs at winternet.com> wrote:
> > On 08/03/2005 08:27 AM, Ken Fuchs wrote:
> 
> > > BTW, my flash burner is an older Enhanced Willem Universal
> > > Programmer.  I got mine for only $60 US over a year ago.  I've
> > > seen it for less than $40 on eBay a few weeks ago.  The newest
> > > model is going for about $50 US.  It does a LinuxBIOS flash in
> > > about 5 minutes; not bad for a $60 burner.  However, it does
> > > require changing DIP switches to match an image for each device it
> > > can program.  Great for the amateur or professional with a small
> > > budget.
> 
> Jeff Carr wrote:
> 
> > The webpage that is linked rom the linuxbios FAQ says that it
> > comes with a USB cable.
> 
> The USB cable is used to provide power only.  (I disconnect the USB
> cable when inserting/removing a PLCC flash device, although the manual
> doesn't mention this.  I just do it because it can't hurt and it might
> be safer.)
> 
> The programmmer is controlled via a parallel port in EPP (Normal)
> mode (This can checked/set in the COTS BIOS of most IBM PC
> compatibles.)
> 
> > Are you able to control this device from Linux?
> 
> The Enhanced Willem Universal Programmer comes with a CD containing a
> MS Windows program that shows how the DIP switches should be set for
> any supported device.  Of course, this program also erases, writes &
> verifies BIOS image files among other things.
> 
> > It would be a big hassle for me since I don't have any windows
> > machines.
> 
> I use MS Windows 2000 for the (Willem) EPROM3 software.
> 
> Here's a web page that suggests that there is a remote chance that
> EPROM3 might run on Linux via Wine:
> 
> http://www.sdconsult.no/linux/wine-doc/hardware-trace.html
> 
> Has anyone tried to run EPROM3 on Linux via Wine?
> 
> The Willem CD Readme.txt mentions "win98/me", so it might be easier to
> just borrow a MS Windows machine or get one free (many people are
> giving away Pentium II and even lower MHz Pentium III machines).
> 
> Sincerely,
> 
> Ken Fuchs <kfuchs at winternet.com>
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From smithbone at gmail.com  Fri Aug 12 19:08:08 2005
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 12 Aug 2005 12:08:08 -0500
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <2ea3fae105081209467e5f189a@mail.gmail.com>
References: <42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
Message-ID: <8a0c3678050812100839dc55f6@mail.gmail.com>

On 8/12/05, yhlu <yinghailu at gmail.com> wrote:
> I hope I could get one with USB2 cable and it could work with Linux.
> 
> USB2 would be faster than others.

I don't think it matters.  Your bottleneck is not the bandwith to the
programmer but the time it takes for the flash part to write a byte or
block.  Flash writes are slow.

-- 
Richard A. Smith



From yinghailu at gmail.com  Fri Aug 12 19:35:10 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 12 Aug 2005 10:35:10 -0700
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <8a0c3678050812100839dc55f6@mail.gmail.com>
References: <42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
Message-ID: <2ea3fae10508121035724c3bdc@mail.gmail.com>

you are right.

1. download image to burner buffer, NON USB need to 5s..., USB may only need 1s.
2. issue command to burn from buffer to flash. .... burner need 30s,
flash_rom need 10s.

YH

On 8/12/05, Richard Smith <smithbone at gmail.com> wrote:
> On 8/12/05, yhlu <yinghailu at gmail.com> wrote:
> > I hope I could get one with USB2 cable and it could work with Linux.
> >
> > USB2 would be faster than others.
> 
> I don't think it matters.  Your bottleneck is not the bandwith to the
> programmer but the time it takes for the flash part to write a byte or
> block.  Flash writes are slow.
> 
> --
> Richard A. Smith
>



From kfuchs at winternet.com  Fri Aug 12 21:19:09 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Fri, 12 Aug 2005 14:19:09 -0500 (CDT)
Subject: [LinuxBIOS] BIOS Saver RD1
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
Message-ID: <200508121919.j7CJJ9tI015058@tundra.winternet.com>

Sorry, you are both wrong.  The USB cable is used _only_ for power.
All data goes through the parallel port.  It is a slow (5 minutes to
burn and 2 minutes to verify), cheap burner, but I have found it to be
extremely reliable.

I was talking about the Enhanced Willem Universal Programmer.
Perhaps, the two of you were talking about another, possibly
hypothetical flash programmer.

Disclaimer: I'm not using the newest Willem programmer, but I think
even the newest Willem programmer still uses USB only for power (They
include the option of an AC adapter that can be used instead of the
USB cable - an option my USB only powered, older unit lacks).  

YH wrote:  

> you are right.

> 1. download image to burner buffer, NON USB need to 5s..., USB may only
> need 1s.
> 2. issue command to burn from buffer to flash. .... burner need 30s,
> flash_rom need 10s.

> On 8/12/05, yhlu <yinghailu at gmail.com> wrote:

> > I hope I could get one with USB2 cable and it could work with Linux.
> >
> > USB2 would be faster than others.

On 8/12/05, Richard Smith <smithbone at gmail.com> wrote:

> I don't think it matters.  Your bottleneck is not the bandwith to the
> programmer but the time it takes for the flash part to write a byte or
> block.  Flash writes are slow.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From yinghailu at gmail.com  Fri Aug 12 21:28:43 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 12 Aug 2005 12:28:43 -0700
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <200508121919.j7CJJ9tI015058@tundra.winternet.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
Message-ID: <2ea3fae1050812122862420f71@mail.gmail.com>

http://www.xeltek.com/home.php
http://www.xeltek.com/product.php?productid=16221  
It's about $549.00

but no Linux support.

Also there is some EEPROM emulator, then only about download time 1s.

YH

On 8/12/05, Ken Fuchs <kfuchs at winternet.com> wrote:
> Sorry, you are both wrong.  The USB cable is used _only_ for power.
> All data goes through the parallel port.  It is a slow (5 minutes to
> burn and 2 minutes to verify), cheap burner, but I have found it to be
> extremely reliable.
> 
> I was talking about the Enhanced Willem Universal Programmer.
> Perhaps, the two of you were talking about another, possibly
> hypothetical flash programmer.
> 
> Disclaimer: I'm not using the newest Willem programmer, but I think
> even the newest Willem programmer still uses USB only for power (They
> include the option of an AC adapter that can be used instead of the
> USB cable - an option my USB only powered, older unit lacks).
> 
> YH wrote:
> 
> > you are right.
> 
> > 1. download image to burner buffer, NON USB need to 5s..., USB may only
> > need 1s.
> > 2. issue command to burn from buffer to flash. .... burner need 30s,
> > flash_rom need 10s.
> 
> > On 8/12/05, yhlu <yinghailu at gmail.com> wrote:
> 
> > > I hope I could get one with USB2 cable and it could work with Linux.
> > >
> > > USB2 would be faster than others.
> 
> On 8/12/05, Richard Smith <smithbone at gmail.com> wrote:
> 
> > I don't think it matters.  Your bottleneck is not the bandwith to the
> > programmer but the time it takes for the flash part to write a byte or
> > block.  Flash writes are slow.
> 
> Sincerely,
> 
> Ken Fuchs <kfuchs at winternet.com>
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From smithbone at gmail.com  Fri Aug 12 21:42:19 2005
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 12 Aug 2005 14:42:19 -0500
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <200508121919.j7CJJ9tI015058@tundra.winternet.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
Message-ID: <8a0c3678050812124246f565c1@mail.gmail.com>

On 8/12/05, yhlu <yinghailu at gmail.com> wrote:
> you are right.
>
> 1. download image to burner buffer, NON USB need to 5s..., USB may only need 1s.
> 2. issue command to burn from buffer to flash. .... burner need 30s,
> flash_rom need 10s.

Ok.. So its the _device_ then thats non-optimal.  A usb2 device may or
may not be of any use.

We have a Batronix USB programmer.  It has a windows only interface
that really sucks.

I've been toying with writing a python cli for it.  Looking at the
windows program its obvious that the device downloads its frimware.
Each chip that is supported has its own firmware.  I've done a little
bit of looking and its some sort of EZ-usb setup.

I've haven't had the motivation but since you are asking about one I
will go back this weekend and look at harder.

If I can get some sort of cli for the batronix device it would be
really sweet.  Its a good little programmer but it just suffers from a
horrible software interface.  In fact, I've yet to use a  programmer
yet that I thought had interface worth a damn.

-- 
Richard A. Smith



From smithbone at gmail.com  Fri Aug 12 21:48:59 2005
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 12 Aug 2005 14:48:59 -0500
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <200508121919.j7CJJ9tI015058@tundra.winternet.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
Message-ID: <8a0c3678050812124861500106@mail.gmail.com>

On 8/12/05, Ken Fuchs <kfuchs at winternet.com> wrote:

> Sorry, you are both wrong.  The USB cable is used _only_ for power.
> All data goes through the parallel port.  It is a slow (5 minutes to
> burn and 2 minutes to verify), cheap burner, but I have found it to be
> extremely reliable.

I was refering to any usb programmer. USB 1 can do 12Mbps. or roughly
a 1MB/s but you can't program a flash at that rate.  So you ether
download the contents into the programmer or the programmer polls for
when the device is ready to accept the next byte.  In a polling setup
a USB 2.0 device my be just as slow a parallel port device because its
not the transport thats the problem.  Its the implementation.

USB 2 devices however by virtue of being newer may indeed be faster
but its not ncecssarly  because they are USB 2.

-- 
Richard A. Smith



From stepan at openbios.org  Fri Aug 12 22:12:32 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 12 Aug 2005 22:12:32 +0200
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <2ea3fae1050812122862420f71@mail.gmail.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
	<2ea3fae1050812122862420f71@mail.gmail.com>
Message-ID: <20050812201232.GA8267@openbios.org>

* yhlu <yinghailu at gmail.com> [050812 21:28]:
> http://www.xeltek.com/home.php
> http://www.xeltek.com/product.php?productid=16221  
> It's about $549.00
> 
> but no Linux support.
> 
> Also there is some EEPROM emulator, then only about download time 1s.


Eyeteck had a bios simulator and debug card for little money on their
web page..

http://www.eyeteck.com/usbbios/eindex.htm

but they don't seem to exist anymore, or have temporary trouble.

it reads some chinese government error message now.. no idea what it
means

Stefan






From jcarr at linuxmachines.com  Sat Aug 13 03:24:45 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Fri, 12 Aug 2005 18:24:45 -0700
Subject: [LinuxBIOS] No known linux compatable BIOS programmer ?
In-Reply-To: <200508121919.j7CJJ9tI015058@tundra.winternet.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>	<42FC52FA.30800@linuxmachines.com>	<200508121547.j7CFl2en014246@tundra.winternet.com>	<2ea3fae105081209467e5f189a@mail.gmail.com>	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
Message-ID: <42FD4BDD.7030500@linuxmachines.com>

On 08/12/2005 12:19 PM, Ken Fuchs wrote:
> Sorry, you are both wrong.  The USB cable is used _only_ for power.
> All data goes through the parallel port.  It is a slow (5 minutes to
> burn and 2 minutes to verify), cheap burner, but I have found it to be
> extremely reliable.
> 
> I was talking about the Enhanced Willem Universal Programmer.
> Perhaps, the two of you were talking about another, possibly
> hypothetical flash programmer.

Just to verify once again, there is no known linux bios programmer?

What about programming the chips in socket from within Linux; yes risky,
but this does work right? The reason I ask is because that means that we
do know *HOW* to program them, we just don't have an external device to
do it.

I guess this is just another project to start with a bunch of people
that know how to program fpga's.


Thanks for everyone's feedback to me as a new person here.

Jeff
BTW: you might be able to speed up the programming of the chip if you do
it in burst mode. Lots of NOR flash chips support this. Are PC bios
chips usually NOR or NAND or something else all together? The code I saw
for the M-Systems chip in my machine looked like it was doing the
classic NOR state machine triggers (write 0xAAA, 0x555, etc). So I'm
guessing they are more like NOR than NAND. NAND would suck anyway
because it's not very reliable. Using NAND would be insanely stupid! (IMHO)



From kfuchs at winternet.com  Sat Aug 13 07:47:08 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Sat, 13 Aug 2005 00:47:08 -0500
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable BIOS
	programmer ?]
In-Reply-To: <42FD4BDD.7030500@linuxmachines.com> (message from Jeff Carr on
	Fri, 12 Aug 2005 18:24:45 -0700)
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>	<42FC52FA.30800@linuxmachines.com>	<200508121547.j7CFl2en014246@tundra.winternet.com>	<2ea3fae105081209467e5f189a@mail.gmail.com>	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
	<42FD4BDD.7030500@linuxmachines.com>
Message-ID: <200508130547.j7D5l8D30326@ecstasy1.winternet.com>

>On 08/12/2005 12:19 PM, Ken Fuchs wrote:

>> Sorry, you are both wrong.  The USB cable is used _only_ for power.
>> All data goes through the parallel port.  It is a slow (5 minutes to
>> burn and 2 minutes to verify), cheap burner, but I have found it to be
>> extremely reliable.
>> 
>> I was talking about the Enhanced Willem Universal Programmer.
>> Perhaps, the two of you were talking about another, possibly
>> hypothetical flash programmer.

Jeff Carr wrote:

>Just to verify once again, there is no known linux bios programmer?

I don't know of any, but I haven't looked beyond the Enhanced Willem
Universal Programmer and its MS Windows program.

>What about programming the chips in socket from within Linux; yes risky,
>but this does work right? The reason I ask is because that means that we
>do know *HOW* to program them, we just don't have an external device to
>do it.

The RD1 BIOS Savior is what you need to make this a safe operation.
It adds a second flash (BIOS) device that works as a backup, once it is
successfully programmed.  It is installed in the BIOS socket and the
original BIOS chip is installed into it.  There is a pair of wire going
from the RD1 BIOS Savior to a sliding switch that mounts into the
provided slot cover.  In the ORG position, the original BIOS is active
and in the RD1 position, the RD1's BIOS device is active.  I used one
successfully on a Tyan S2885 system.

First copy the original BIOS to a file.  Next, boot in the ORG
position.  Move the switch to the RD1 position and flash the original
BIOS image to the RD1 flash device.  Test booting the RD1 flash device.
Repeat the last two steps until the RD1 flash device boots OK.  Now,
flash all development BIOS images to the original BIOS device which is
usually a higher quality device.  The RD1 BIOS image can be used in case
of a bad development BIOS image that doesn't boot.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From noodles at earth.li  Sat Aug 13 14:23:11 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Sat, 13 Aug 2005 13:23:11 +0100
Subject: [LinuxBIOS] Various Config.lb fixes.
Message-ID: <20050813122311.GF12535@earth.li>

Hi.

The attached patch fixes up the Config.lb files for the 4 targets that
buildtarget can't currently parse. These are Iwill-dk8s2,
technologic-ts5300, totalimpact-briq & newisys-khepri. None of them then
compile afterwards for me, but this at least gets them one step closer.
Is anyone working on these platforms who has a better fixup for it?

Also, Ollie, any word on the udelay stuff? Can you even give me your
quick hack to get things compiling so I can see if it's hiding any other
problems?

J.

-- 
] http://www.earth.li/~noodles/ []   What have I become, my sweetest   [
]  PGP/GPG Key @ the.earth.li   []               friend?               [
] via keyserver, web or email.  []                                     [
] RSA: 4DC4E7FD / DSA: 5B430367 []                                     [
-------------- next part --------------
Index: src/mainboard/technologic/ts5300/Options.lb
===================================================================
--- src/mainboard/technologic/ts5300/Options.lb	(revision 2008)
+++ src/mainboard/technologic/ts5300/Options.lb	(working copy)
@@ -32,6 +32,9 @@
 uses CC
 uses HOSTCC
 uses OBJCOPY
+uses DEFAULT_CONSOLE_LOGLEVEL
+uses MAXIMUM_CONSOLE_LOGLEVEL
+uses CONFIG_COMPRESS
 
 ## ROM_SIZE is the size of boot ROM that this board will use.
 default ROM_SIZE  = 256*1024
Index: targets/Iwill/dk8s2/Config.lb
===================================================================
--- targets/Iwill/dk8s2/Config.lb	(revision 2008)
+++ targets/Iwill/dk8s2/Config.lb	(working copy)
@@ -2,86 +2,18 @@
 # the Iwill DK8S2
 # This will make a target directory of ./dk8s2
 
-loadoptions
-
 target dk8s2
 
-uses ARCH
-uses CONFIG_COMPRESS
-uses CONFIG_IOAPIC
-uses CONFIG_ROM_STREAM
-uses CONFIG_ROM_STREAM_START
-uses CONFIG_SMP
-uses CONFIG_UDELAY_TSC
-uses CPU_FIXUP
-uses FALLBACK_SIZE
-uses HAVE_FALLBACK_BOOT
-uses HAVE_MP_TABLE
-uses HAVE_PIRQ_TABLE
-uses i586
-uses i686
-uses INTEL_PPRO_MTRR
-uses HEAP_SIZE
-uses IRQ_SLOT_COUNT
-uses k7
-uses k8
-uses MAINBOARD
-uses MAINBOARD_PART_NUMBER
-uses MAINBOARD_VENDOR
-#uses MEMORY_HOLE
-uses PAYLOAD_SIZE
-uses _RAMBASE
-uses _ROMBASE
-uses ROM_IMAGE_SIZE
-uses ROM_SECTION_OFFSET
-uses ROM_SECTION_SIZE
-uses ROM_SIZE
-uses STACK_SIZE
-uses USE_FALLBACK_IMAGE
-uses USE_OPTION_TABLE
-uses HAVE_OPTION_TABLE
-uses CONFIG_CHIP_CONFIGURE
- 
-uses CONFIG_CONSOLE_BTEXT
-uses CONFIG_CONSOLE_SERIAL8250
-uses TTYS0_BAUD
-uses DEFAULT_CONSOLE_LOGLEVEL
-uses MAXIMUM_CONSOLE_LOGLEVEL
-uses DEBUG
-uses CONFIG_MAX_CPUS
-uses CONFIG_LOGICAL_CPUS
-uses CONFIG_MAX_PHYSICAL_CPUS
-uses LINUXBIOS_EXTRA_VERSION
-uses XIP_ROM_SIZE
-uses XIP_ROM_BASE
+mainboard Iwill/DK8S2
 
-uses HAVE_HARD_RESET
-
-
-#
-#uses CONFIG_LSI_SCSI_FW_FIXUP
-
-
 option HAVE_HARD_RESET=1
 
 option HAVE_OPTION_TABLE=1
 option HAVE_MP_TABLE=1
-option CPU_FIXUP=1
-option CONFIG_UDELAY_TSC=0
-option i686=1
-option i586=1
-option INTEL_PPRO_MTRR=1
-option k7=1
-option k8=1
 option ROM_SIZE=1048576
 
-option CONFIG_CONSOLE_BTEXT=1
-
 option HAVE_FALLBACK_BOOT=1
   
-# use the new chip configure code.
-
-option CONFIG_CHIP_CONFIGURE=1
 #option CONFIG_LSI_SCSI_FW_FIXUP=1
 
 
@@ -98,7 +30,7 @@
 ###
 option CONFIG_SMP=1
 option CONFIG_MAX_CPUS=2
-option CONFIG_LOGICAL_CPUS=2
+#option CONFIG_LOGICAL_CPUS=2
 option CONFIG_MAX_PHYSICAL_CPUS=2
 #
 ###
@@ -142,7 +74,7 @@
 ###
 
 ## We do use compressed image
-option CONFIG_COMPRESS=1
+#option CONFIG_COMPRESS=1
 
 option CONFIG_CONSOLE_SERIAL8250=1
 option TTYS0_BAUD=115200
@@ -165,7 +97,7 @@
 ## At a maximum only compile in this level of debugging
 option MAXIMUM_CONSOLE_LOGLEVEL=7
 
-option DEBUG=1
+#option DEBUG=1
 
 #
 
@@ -210,7 +142,6 @@
 
 	option XIP_ROM_BASE = (_ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE)
 
-	mainboard Iwill/DK8S2
 	payload /usr/src/filo-0.4.1_btext/filo.elf
 #	payload /usr/src/filo-0.4.2/filo.elf
 end
@@ -229,8 +160,7 @@
 	option XIP_ROM_SIZE = 65536
 	option XIP_ROM_BASE = (_ROMBASE + ROM_IMAGE_SIZE - XIP_ROM_SIZE)
 
-	mainboard Iwill/DK8S2
-	payload /usr/src/filo-0.4.1_btext/filo.elf
+	payload ../../../payloads/filo.elf
 #	payload /usr/src/filo-0.4.2/filo.elf
 end
 
Index: targets/totalimpact/briq/Config.lb
===================================================================
--- targets/totalimpact/briq/Config.lb	(revision 2008)
+++ targets/totalimpact/briq/Config.lb	(working copy)
@@ -1,36 +1,10 @@
 # Config file for the Total Impact briQ
 # This will make a target directory of ./briq
 
-loadoptions
-
 target briq
+	
+mainboard totalimpact/briq
 
-uses CROSS_COMPILE 
-uses HAVE_OPTION_TABLE
-uses CONFIG_COMPRESS 
-uses DEFAULT_CONSOLE_LOGLEVEL 
-uses CONFIG_USE_INIT
-uses NO_POST
-uses CONFIG_CONSOLE_SERIAL8250 
-uses CONFIG_IDE_STREAM 
-uses IDE_BOOT_DRIVE
-uses IDE_SWAB IDE_OFFSET 
-uses ROM_SIZE
-uses _RESET
-uses _EXCEPTION_VECTORS
-uses _ROMBASE
-uses _ROMSTART
-uses _RAMBASE
-uses _RAMSTART
-uses STACK_SIZE
-uses HEAP_SIZE
-uses CONFIG_BRIQ_750FX 
-uses CONFIG_BRIQ_7400
-
-## use a cross compiler
-#option CROSS_COMPILE="powerpc-eabi-"
-#option CROSS_COMPILE="ppc_74xx-"
-
 ## Use stage 1 initialization code
 option CONFIG_USE_INIT=1
 
@@ -79,7 +53,6 @@
 	option CONFIG_BRIQ_750FX=1
 	#option CONFIG_BRIQ_7400=1
 
-	mainboard totalimpact/briq
 end
 
 buildrom ./linuxbios.rom ROM_SIZE "normal"
Index: targets/newisys/khepri/Config.lb
===================================================================
--- targets/newisys/khepri/Config.lb	(revision 2008)
+++ targets/newisys/khepri/Config.lb	(working copy)
@@ -2,77 +2,20 @@
 # Sample config file for Newisys Khepri systems
 #
 
-loadoptions
-
 # Target directory for khepri build
 target khepri
+	
+mainboard newisys/khepri
 
-# list of all used variables:
-uses ARCH
-uses CONFIG_COMPRESS
-uses CONFIG_IOAPIC
-uses CONFIG_ROM_STREAM
-uses CONFIG_ROM_STREAM_START
-uses CONFIG_UDELAY_TSC
-uses CPU_FIXUP
-uses FALLBACK_SIZE
-uses HAVE_FALLBACK_BOOT
-uses HAVE_MP_TABLE
-uses HAVE_PIRQ_TABLE
-uses HAVE_HARD_RESET
-uses i586
-uses i686
-uses INTEL_PPRO_MTRR
-uses HEAP_SIZE
-uses IRQ_SLOT_COUNT
-uses k7
-uses k8
-uses MAINBOARD_PART_NUMBER
-uses MAINBOARD_VENDOR
-uses CONFIG_SMP
-uses CONFIG_MAX_CPUS
-uses MEMORY_HOLE
-uses PAYLOAD_SIZE
-uses _RAMBASE
-uses _ROMBASE
-uses ROM_IMAGE_SIZE
-uses ROM_SECTION_OFFSET
-uses ROM_SECTION_SIZE
-uses ROM_SIZE
-uses STACK_SIZE
-uses USE_FALLBACK_IMAGE
-uses USE_OPTION_TABLE
-uses HAVE_OPTION_TABLE
-uses MAXIMUM_CONSOLE_LOGLEVEL
-uses DEFAULT_CONSOLE_LOGLEVEL
-uses CONFIG_CONSOLE_SERIAL8250
-uses MAINBOARD
-uses CONFIG_CHIP_CONFIGURE
-uses XIP_ROM_SIZE
-uses XIP_ROM_BASE
-uses LINUXBIOS_EXTRA_VERSION
-uses CC
-
 # set target C compiler to 32bit gcc.
 option CC="gcc -m32"
 
 # Configuration options.
 
-option CONFIG_CHIP_CONFIGURE=1
-
 option  MAXIMUM_CONSOLE_LOGLEVEL=8
 option  DEFAULT_CONSOLE_LOGLEVEL=8
 option  CONFIG_CONSOLE_SERIAL8250=1
 
-option CPU_FIXUP=1
-option CONFIG_UDELAY_TSC=0
-option i686=1
-option i586=1
-option INTEL_PPRO_MTRR=1
-option k7=1
-option k8=1
-
-
 # Size of the image. Khepri comes with 512k per default.
 option ROM_SIZE=524288
 
@@ -89,16 +32,14 @@
 	option USE_FALLBACK_IMAGE=0
 	option ROM_IMAGE_SIZE=0x10000
 	option LINUXBIOS_EXTRA_VERSION="-Khepri-Normal"
-	mainboard newisys/khepri
-	payload /usr/share/LinuxBIOS/tg3--ide_disk.zelf
+	payload ../../../payloads/tg3--ide_disk.zelf
 end
 
 romimage "fallback" 
 	option USE_FALLBACK_IMAGE=1
 	option ROM_IMAGE_SIZE=0x10000
 	option LINUXBIOS_EXTRA_VERSION="-Khepri-Fallback"
-	mainboard newisys/khepri
-	payload /usr/share/LinuxBIOS/tg3--ide_disk.zelf
+	payload ../../../payloads/tg3--ide_disk.zelf
 end
 
 buildrom ./khepri.rom ROM_SIZE "normal" "fallback"

From stuge-linuxbios at cdy.org  Sat Aug 13 14:30:14 2005
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Sat, 13 Aug 2005 14:30:14 +0200
Subject: [LinuxBIOS] No known linux compatable BIOS programmer ?
In-Reply-To: <42FD4BDD.7030500@linuxmachines.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
	<42FD4BDD.7030500@linuxmachines.com>
Message-ID: <20050813123014.790.qmail@cdy.org>

On Fri, Aug 12, 2005 at 06:24:45PM -0700, Jeff Carr wrote:
> What about programming the chips in socket from within Linux; yes
> risky, but this does work right?

Yes, indeed. Many use this as primary means of testing.


> The reason I ask is because that means that we do know *HOW* to
> program them, we just don't have an external device to do it.

Right. But the programming sequence for flash memory is always in the
data sheet, and manufacturers have those on their web sites.


> I guess this is just another project to start with a bunch of
> people that know how to program fpga's.

Perhaps not even an FPGA is needed, I've made an EPROM toy out of a
USB PIC microcontroller and two 12-bit counters. Really simple. Not
too quick though, took a good few minutes to read the 256kb EPROM,
but that's probably because the USB microcontroller only does low
speed USB (8kbps) while it's newer sibling does full speed at 12Mbps.

The problem with making a universal programmer is that the device
pinout and voltage changes too often, and a production programmer
should program and verify at several different voltages. The pin
drivers need to be programmable and fast and preferably indifferent
of voltage, which isn't a very common combination. But sure, it would
be possible to make a small series of a rather limited programmer
(256kbyte to 4mbyte devices, only standardized pinout) for, say $200
retail, but then you might as well pay twice as much and get the
"real" deal..


> BTW: you might be able to speed up the programming of the chip if
> you do it in burst mode. Lots of NOR flash chips support this. Are
> PC bios chips usually NOR or NAND or something else all together?
> The code I saw for the M-Systems chip in my machine looked like it
> was doing the classic NOR state machine triggers (write 0xAAA,
> 0x555, etc).

0xAA and 0x55 are part of a command sequence standardized by JEDEC
and used for just about all flash memory and even some EEPROMS. :)


> So I'm guessing they are more like NOR than NAND. NAND would suck
> anyway because it's not very reliable. Using NAND would be insanely
> stupid! (IMHO)

My guess is that NAND is more common, at least in PCs.


//Peter



From jcarr at linuxmachines.com  Sun Aug 14 11:26:43 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Sun, 14 Aug 2005 02:26:43 -0700
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable
	BIOS	programmer ?]
In-Reply-To: <200508130547.j7D5l8D30326@ecstasy1.winternet.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>	<42FC52FA.30800@linuxmachines.com>	<200508121547.j7CFl2en014246@tundra.winternet.com>	<2ea3fae105081209467e5f189a@mail.gmail.com>	<8a0c3678050812100839dc55f6@mail.gmail.com>	<200508121919.j7CJJ9tI015058@tundra.winternet.com>	<42FD4BDD.7030500@linuxmachines.com>
	<200508130547.j7D5l8D30326@ecstasy1.winternet.com>
Message-ID: <42FF0E53.4010902@linuxmachines.com>

On 08/12/2005 10:47 PM, Ken Fuchs wrote:

>>Just to verify once again, there is no known linux bios programmer?
> 
> I don't know of any, but I haven't looked beyond the Enhanced Willem
> Universal Programmer and its MS Windows program.

OK. I'll put that on my todo list of things to look for.

> The RD1 BIOS Savior is what you need to make this a safe operation.
> It adds a second flash (BIOS) device that works as a backup, once it is
> successfully programmed.  It is installed in the BIOS socket and the
> original BIOS chip is installed into it.  There is a pair of wire going
> from the RD1 BIOS Savior to a sliding switch that mounts into the
> provided slot cover.  In the ORG position, the original BIOS is active
> and in the RD1 position, the RD1's BIOS device is active.  I used one
> successfully on a Tyan S2885 system.

Yes, that's an essential tool.

> First copy the original BIOS to a file.

I'm still having problems with this. I haven't been able to convince
linux's mtd drivers to do this. I've tried many things so far to try to
save the BIOS to a file from within linux. Maybe this is also not what
people normally do.

I see the instructions in the wiki for pulling out the VIDEO BIOS.
Please tell me this is a standard in the PC world and we can just use
the video bios to init the video chip and wrap linuxbios around it. That
would be fantastic! Programming the video chips is going to be extremely
unlikely/impossible in most cases.
(linux-2.6.12.2/Documentation/power/video.txt is interesting reading)

I dumped my vgabios without a hitch:
root at jcarr:/home# dd if=/dev/mem of=vgabios.bin count=1 bs=64K skip=12
1+0 records in
1+0 records out
65536 bytes transferred in 0.012833 seconds (5106847 bytes/sec)
root at jcarr:/home# strings vgabios.bin |grep "ATI Tech"
(C) 1988-2003, ATI Technologies Inc. BK-ATI VER008.017M.097.000

I'm very surprised to have that work. Thats great though! I wonder how
that works. Can't the iomem window be expanded to show the whole bios
image then? Then it would be really really trivial to save your bios
image as a file! All you'd have to use is dd!

Anyway, I don't understand enough to know how this is being done. I
assume the BIOS is hooked up to the host bridge chip somehow. Or perhaps
it goes through ACPI somehow? I don't know how to figure out how the
kernel finds & maps the video bios. It seems to happen early on in the
boot process arch/i368/setup.c just hard codes an entry for it:

static struct resource video_rom_resource = {
        .name   = "Video ROM",
        .start  = 0xc0000,
        .end    = 0xc7fff,
        .flags  = IORESOURCE_BUSY | IORESOURCE_READONLY | IORESOURCE_MEM
};

Man, not a lot to go on there. I guess if it was possible to just memory
map the whole BIOS someone would have done that by now.

Is there a standard place that the videobios is stored in the bios flash?

Sorry about the rambling, it's been a long day of experiements. I got
annoyed about the changing location and size of the video bios so I made
the attached perl script to pull it out.
Jeff
BTW: strings vgabios.bin on my machine showed "pbd47ev.sab" which seemed
suspiciously like a DOS filename. google revealed SAB as a standard ASIC
file format. Makes me wonder what kind of software ATI uses to do their
ASIC designs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: save_vgabios.pl
Type: application/x-perl
Size: 448 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050814/b9d627f8/attachment.pl>

From yinghailu at gmail.com  Sun Aug 14 19:05:12 2005
From: yinghailu at gmail.com (yhlu)
Date: Sun, 14 Aug 2005 10:05:12 -0700
Subject: [LinuxBIOS] BIOS Saver RD1
In-Reply-To: <20050812201232.GA8267@openbios.org>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
	<2ea3fae1050812122862420f71@mail.gmail.com>
	<20050812201232.GA8267@openbios.org>
Message-ID: <2ea3fae105081410051e46c677@mail.gmail.com>

The xeltek ISP Header + 280U can be used for in-system programming.

http://www.xeltek.com/pages.php?pageid=8

That could be useful, if your mb don't have flash socket and flash os
soldered in.

YH

On 8/12/05, Stefan Reinauer <stepan at openbios.org> wrote:
> * yhlu <yinghailu at gmail.com> [050812 21:28]:
> > http://www.xeltek.com/home.php
> > http://www.xeltek.com/product.php?productid=16221
> > It's about $549.00
> >
> > but no Linux support.
> >
> > Also there is some EEPROM emulator, then only about download time 1s.
> 
> 
> Eyeteck had a bios simulator and debug card for little money on their
> web page..
> 
> http://www.eyeteck.com/usbbios/eindex.htm
> 
> but they don't seem to exist anymore, or have temporary trouble.
> 
> it reads some chinese government error message now.. no idea what it
> means
> 
> Stefan
> 
> 
> 
>



From jcarr at linuxmachines.com  Sun Aug 14 20:18:26 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Sun, 14 Aug 2005 11:18:26 -0700
Subject: [LinuxBIOS] Where to put datasheets in wiki?
Message-ID: <42FF8AF2.10909@linuxmachines.com>

I did lots of digging today to uncover what documentation I could find
on the M-Systems MD2802. I"m still just assuming that is what I have in
this machine because that's what flash_and_burn reports.

Is there somewhere on the website links to the datasheets should be put.
It takes a long time to track them down. It would be more productive if
we pool the effort.

Datasheets that available without NDA (most of them are nowdays) most
companies seem to have a rather liberal view on putting them on other
websites. I'd be of the opinion that we should just upload them to the
linuxbios wiki. That way we know the document will stay around. Lots of
these companies change the URL's over time so you have to start the
whole process over again. In addition to the actual PDF, a link to the
original site can remain also just incase the documents upstream are
updated. Then again, maybe uploading the PDF's isn't worth the effort?

The "Supported Chipsets" page seems like the right place to put the data
sheets and other documentation known about a specific chip.

Jeff



From talbotx at comcast.net  Mon Aug 15 06:51:58 2005
From: talbotx at comcast.net (Adam Talbot)
Date: Sun, 14 Aug 2005 21:51:58 -0700
Subject: [LinuxBIOS] No known linux compatable BIOS programmer ?
References: <2ea3fae10508121035724c3bdc@mail.gmail.com><42FC52FA.30800@linuxmachines.com><200508121547.j7CFl2en014246@tundra.winternet.com><2ea3fae105081209467e5f189a@mail.gmail.com><8a0c3678050812100839dc55f6@mail.gmail.com><200508121919.j7CJJ9tI015058@tundra.winternet.com><42FD4BDD.7030500@linuxmachines.com>
	<20050813123014.790.qmail@cdy.org>
Message-ID: <004901c5a155$15297de0$bc01a8c0@newflame>

I am using a top2005 USB based programmer. http://www.mcumall.com I have 
done over 100 flash's and had no problems with Linux bios and this 
programmer.
-Adam

----- Original Message ----- 
From: "Peter Stuge" <stuge-linuxbios at cdy.org>
To: <LinuxBIOS at openbios.org>
Sent: Saturday, August 13, 2005 5:30 AM
Subject: Re: [LinuxBIOS] No known linux compatable BIOS programmer ?


> On Fri, Aug 12, 2005 at 06:24:45PM -0700, Jeff Carr wrote:
>> What about programming the chips in socket from within Linux; yes
>> risky, but this does work right?
>
> Yes, indeed. Many use this as primary means of testing.
>
>
>> The reason I ask is because that means that we do know *HOW* to
>> program them, we just don't have an external device to do it.
>
> Right. But the programming sequence for flash memory is always in the
> data sheet, and manufacturers have those on their web sites.
>
>
>> I guess this is just another project to start with a bunch of
>> people that know how to program fpga's.
>
> Perhaps not even an FPGA is needed, I've made an EPROM toy out of a
> USB PIC microcontroller and two 12-bit counters. Really simple. Not
> too quick though, took a good few minutes to read the 256kb EPROM,
> but that's probably because the USB microcontroller only does low
> speed USB (8kbps) while it's newer sibling does full speed at 12Mbps.
>
> The problem with making a universal programmer is that the device
> pinout and voltage changes too often, and a production programmer
> should program and verify at several different voltages. The pin
> drivers need to be programmable and fast and preferably indifferent
> of voltage, which isn't a very common combination. But sure, it would
> be possible to make a small series of a rather limited programmer
> (256kbyte to 4mbyte devices, only standardized pinout) for, say $200
> retail, but then you might as well pay twice as much and get the
> "real" deal..
>
>
>> BTW: you might be able to speed up the programming of the chip if
>> you do it in burst mode. Lots of NOR flash chips support this. Are
>> PC bios chips usually NOR or NAND or something else all together?
>> The code I saw for the M-Systems chip in my machine looked like it
>> was doing the classic NOR state machine triggers (write 0xAAA,
>> 0x555, etc).
>
> 0xAA and 0x55 are part of a command sequence standardized by JEDEC
> and used for just about all flash memory and even some EEPROMS. :)
>
>
>> So I'm guessing they are more like NOR than NAND. NAND would suck
>> anyway because it's not very reliable. Using NAND would be insanely
>> stupid! (IMHO)
>
> My guess is that NAND is more common, at least in PCs.
>
>
> //Peter
>
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 





From jcarr at linuxmachines.com  Mon Aug 15 08:55:31 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Sun, 14 Aug 2005 23:55:31 -0700
Subject: [LinuxBIOS] No known linux compatable BIOS programmer ?
In-Reply-To: <004901c5a155$15297de0$bc01a8c0@newflame>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com><42FC52FA.30800@linuxmachines.com><200508121547.j7CFl2en014246@tundra.winternet.com><2ea3fae105081209467e5f189a@mail.gmail.com><8a0c3678050812100839dc55f6@mail.gmail.com><200508121919.j7CJJ9tI015058@tundra.winternet.com><42FD4BDD.7030500@linuxmachines.com>	<20050813123014.790.qmail@cdy.org>
	<004901c5a155$15297de0$bc01a8c0@newflame>
Message-ID: <43003C63.6070603@linuxmachines.com>

On 08/14/05 21:51, Adam Talbot wrote:
> I am using a top2005 USB based programmer. http://www.mcumall.com I have
> done over 100 flash's and had no problems with Linux bios and this
> programmer.

Just to clarify, are you saying that you have the top2005 sucessfully
hooked up to a linux machine? No windows machine? That would be great --
I'd order that one then.
Jeff

PS: If the mailing list admin could change the ______'s to just two __
then normal mail readers would not include the footer in a reply.

__
> 
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 




From talbotx at comcast.net  Mon Aug 15 08:56:15 2005
From: talbotx at comcast.net (Adam Talbot)
Date: Sun, 14 Aug 2005 23:56:15 -0700
Subject: [LinuxBIOS] No known linux compatable BIOS programmer ?
References: <2ea3fae10508121035724c3bdc@mail.gmail.com><42FC52FA.30800@linuxmachines.com><200508121547.j7CFl2en014246@tundra.winternet.com><2ea3fae105081209467e5f189a@mail.gmail.com><8a0c3678050812100839dc55f6@mail.gmail.com><200508121919.j7CJJ9tI015058@tundra.winternet.com><42FD4BDD.7030500@linuxmachines.com>	<20050813123014.790.qmail@cdy.org>
	<004901c5a155$15297de0$bc01a8c0@newflame>
	<43003C63.6070603@linuxmachines.com>
Message-ID: <009401c5a166$6e339ea0$bc01a8c0@newflame>

-Jeff
Have not tried the top2005 on a Linux system, the closest I have come is a 
windows box in VMware.
----- Original Message ----- 
From: "Jeff Carr" <jcarr at linuxmachines.com>
To: "Adam Talbot" <talbotx at comcast.net>
Cc: <LinuxBIOS at openbios.org>
Sent: Sunday, August 14, 2005 11:55 PM
Subject: Re: [LinuxBIOS] No known linux compatable BIOS programmer ?


> On 08/14/05 21:51, Adam Talbot wrote:
>> I am using a top2005 USB based programmer. http://www.mcumall.com I have
>> done over 100 flash's and had no problems with Linux bios and this
>> programmer.
>
> Just to clarify, are you saying that you have the top2005 sucessfully
> hooked up to a linux machine? No windows machine? That would be great --
> I'd order that one then.
> Jeff
>
> PS: If the mailing list admin could change the ______'s to just two __
> then normal mail readers would not include the footer in a reply.
>
> __
>>
>>
>> _______________________________________________
>> LinuxBIOS mailing list
>> LinuxBIOS at openbios.org
>> http://www.openbios.org/mailman/listinfo/linuxbios
>>
>
> 





From p.millar at physics.gla.ac.uk  Mon Aug 15 11:56:26 2005
From: p.millar at physics.gla.ac.uk (Paul Millar)
Date: Mon, 15 Aug 2005 10:56:26 +0100
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable
	=?iso-8859-1?q?BIOS=09programmer?= ?]
In-Reply-To: <42FF0E53.4010902@linuxmachines.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<200508130547.j7D5l8D30326@ecstasy1.winternet.com>
	<42FF0E53.4010902@linuxmachines.com>
Message-ID: <200508151056.38490.p.millar@physics.gla.ac.uk>

On Sunday 14 Aug 2005 10:26, Jeff Carr wrote:
> On 08/12/2005 10:47 PM, Ken Fuchs wrote:
> > I don't know of any, but I haven't looked beyond the Enhanced Willem
> > Universal Programmer and its MS Windows program.
>
> OK. I'll put that on my todo list of things to look for.

I have some user-land software for getting the Willem board working under 
Linux.

Back a little while back (while an impoverished student), I decided it was the 
best available burner that had publicly available schematics and PCB layout, 
so built it, planning on writing the software myself. (first PCB project, it 
was a miracle it worked :)

I wrote some software that handles some 27cxx chips (read, write, ...), but 
the code's written so it should be fairly easy to add support for other 
chips.

From the posts, I figured others might want the software too, so spend some of 
last weekend finishing off porting the software to using Linux's ppdev 
(rather than hitting the parallel port directly).  I got most of the way 
there (just some timing issues left) before my 5v regulator died.

So, I have some non-functional (but hopefully not too far off) software.  I 
hope to have the regulator fixed today, so should be able to hunt down the 
remaining bugs soon.

Would people be interested, either in the software or in helping improve it?

Cheers,

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050815/b5ea1548/attachment.sig>

From jcarr at linuxmachines.com  Mon Aug 15 15:23:09 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Mon, 15 Aug 2005 06:23:09 -0700
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable
	BIOS programmer ?]
In-Reply-To: <200508151056.38490.p.millar@physics.gla.ac.uk>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>	<200508130547.j7D5l8D30326@ecstasy1.winternet.com>	<42FF0E53.4010902@linuxmachines.com>
	<200508151056.38490.p.millar@physics.gla.ac.uk>
Message-ID: <4300973D.4020601@linuxmachines.com>

On 08/15/05 02:56, Paul Millar wrote:

> I have some user-land software for getting the Willem board working
> under Linux.

Sweet.

> Back a little while back (while an impoverished student), I decided 
> it was the best available burner that had publicly available
> schematics and PCB layout, so built it, planning on writing the
> software myself. (first PCB project, it was a miracle it worked :)

Cool.

> Would people be interested, either in the software or in helping 
> improve it?

I would. You said you built your own device, but I'm not a poor student
(anymore). Could you guess which of the three on the mcmull page:
http://www.mcumall.com/comersus/store/comersus_dynamicIndex.asp
would be the closest to the schematic you used?

I'd certainly be willing to make a go of it. If I can dig it up, there
were some guys that wrote a parallel jtag interface to program amd
flash. Maybe it would be useful. That was several years ago and the site
seems lost in the annals of history now. Maybe you wrote that too :)

Jeff



From jcarr at linuxmachines.com  Mon Aug 15 15:28:28 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Mon, 15 Aug 2005 06:28:28 -0700
Subject: [LinuxBIOS] No known linux compatable BIOS programmer ?
In-Reply-To: <009401c5a166$6e339ea0$bc01a8c0@newflame>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com><42FC52FA.30800@linuxmachines.com><200508121547.j7CFl2en014246@tundra.winternet.com><2ea3fae105081209467e5f189a@mail.gmail.com><8a0c3678050812100839dc55f6@mail.gmail.com><200508121919.j7CJJ9tI015058@tundra.winternet.com><42FD4BDD.7030500@linuxmachines.com>	<20050813123014.790.qmail@cdy.org>
	<004901c5a155$15297de0$bc01a8c0@newflame>
	<43003C63.6070603@linuxmachines.com>
	<009401c5a166$6e339ea0$bc01a8c0@newflame>
Message-ID: <4300987C.9050704@linuxmachines.com>

On 08/14/05 23:56, Adam Talbot wrote:

> Have not tried the top2005 on a Linux system, the closest I have come is
> a windows box in VMware.


OK; thanks for the info. I'll try to get Paul's code to work first I think.

I haven't had a windows box for many years & I'd rather avoid ever
having one again!
Jeff



From ollie at lanl.gov  Mon Aug 15 19:27:25 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon, 15 Aug 2005 11:27:25 -0600
Subject: [LinuxBIOS] Where to put datasheets in wiki?
In-Reply-To: <42FF8AF2.10909@linuxmachines.com>
References: <42FF8AF2.10909@linuxmachines.com>
Message-ID: <1124126845.5294.9.camel@logarithm.lanl.gov>

On Sun, 2005-08-14 at 11:18 -0700, Jeff Carr wrote:
> I did lots of digging today to uncover what documentation I could find
> on the M-Systems MD2802. I"m still just assuming that is what I have in
> this machine because that's what flash_and_burn reports.


I don't think you have M-system on our machine. As I said before, the 
problem you have is that flash_rom can not enable flash write on you
chipset so it just can't detect any flash chip.

> Is there somewhere on the website links to the datasheets should be put.
> It takes a long time to track them down. It would be more productive if
> we pool the effort.
> 
> Datasheets that available without NDA (most of them are nowdays) most
> companies seem to have a rather liberal view on putting them on other
> websites. I'd be of the opinion that we should just upload them to the
> linuxbios wiki. That way we know the document will stay around. Lots of
> these companies change the URL's over time so you have to start the
> whole process over again. In addition to the actual PDF, a link to the
> original site can remain also just incase the documents upstream are
> updated. Then again, maybe uploading the PDF's isn't worth the effort?
> 
> The "Supported Chipsets" page seems like the right place to put the data
> sheets and other documentation known about a specific chip.
> 
> Jeff
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From kfuchs at winternet.com  Mon Aug 15 20:44:40 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Mon, 15 Aug 2005 13:44:40 -0500 (CDT)
Subject: [LinuxBIOS] Booting windows XP
Message-ID: <200508151844.j7FIieDe001627@tundra.winternet.com>

Narahari Murthy N. wrote:

> We are trying to boot Windows XP through LinuxBIOS
> ( freebios + BochsBIOS ).  We could load the XP image
> into the RAM but the int-16 is called for ever after
> many int 13 calls. 

> Could you please help me with this respect 

Are you using ADLO (http://www.linuxbios.org/index.php/ADLO)?

Sincerely,

Ken Fuchs <kfuchs at winternet.com>





From kfuchs at winternet.com  Mon Aug 15 22:59:58 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Mon, 15 Aug 2005 15:59:58 -0500 (CDT)
Subject: [LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
	<2ea3fae1050812122862420f71@mail.gmail.com>
	<20050812201232.GA8267@openbios.org>
Message-ID: <200508152059.j7FKxwwn002444@tundra.winternet.com>

YH wrote:

> The xeltek ISP Header + 280U can be used for in-system programming.
> 
> http://www.xeltek.com/pages.php?pageid=8
> 
> That could be useful, if your mb don't have flash socket and flash os
> soldered in.

This would require one or more (a lot of them for the Xeltek ISP
Header) headers on the mainboard.  I couldn't find any information
about the Xeltek ISP Header.  It seems like it might even work on an
Enhanced Willem Universal Programmer.  It would be simpler to have a
single larger header, if the Xeltec ISP Header (adapter) needs to be
detached while the mainboard is operating.  I'd really prefer
something that can remain attached while the mainboard is in
operation.

------

It would even be possible to use the JTAG connector to flash the
system BIOS.  All Opteron mainboards must include "JTAG" circuits, but
usually don't include the two JTAG headers.  Adding the headers is
quite easy.  An open source Opteron JTAG flash programmer is probably
won't happen any time soon, although it shouldn't be too difficult to
do.  Anyone aware of an open source JTAG flash programmer of any kind?

Sincerely,

Ken Fuchs <kfuchs at winternet.com>

> On 8/12/05, Stefan Reinauer <stepan at openbios.org> wrote:
> > * yhlu <yinghailu at gmail.com> [050812 21:28]:
> > > http://www.xeltek.com/home.php
> > > http://www.xeltek.com/product.php?productid=16221
> > > It's about $549.00
> > >
> > > but no Linux support.
> > >
> > > Also there is some EEPROM emulator, then only about 
> download time 1s.
> > 
> > 
> > Eyeteck had a bios simulator and debug card for little 
> money on their
> > web page..
> > 
> > http://www.eyeteck.com/usbbios/eindex.htm
> > 
> > but they don't seem to exist anymore, or have temporary trouble.
> > 
> > it reads some chinese government error message now.. no idea what it
> > means
> > 
> > Stefan
> > 
> > 
> > 
> >
> 
> _______________________________________________
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios





From kfuchs at winternet.com  Mon Aug 15 23:50:16 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Mon, 15 Aug 2005 16:50:16 -0500 (CDT)
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatible
	BIOS programmer ?]
References: <200508151056.38490.p.millar@physics.gla.ac.uk>
	<2ea3fae10508121035724c3bdc@mail.gmail.com>
	<200508130547.j7D5l8D30326@ecstasy1.winternet.com>
	<42FF0E53.4010902@linuxmachines.com>
Message-ID: <200508152150.j7FLoGgc002617@tundra.winternet.com>

Paul Millar wrote:

> I have some user-land software for getting the Willem board 
> working under Linux.
...
> Would people be interested, either in the software or in 
> helping improve it?

I would definitely use the software, help debug and improve it.

I currently have an MS Windows 2000 machine whose only purpose is the
run the EPROM3 software on the Enhanced Willem Universal Programmer
board.  I'd be very happy to dedicate that machine to Linux service
instead.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>




From jcarr at linuxmachines.com  Tue Aug 16 02:04:23 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Mon, 15 Aug 2005 17:04:23 -0700
Subject: [LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]
In-Reply-To: <200508152059.j7FKxwwn002444@tundra.winternet.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>	<42FC52FA.30800@linuxmachines.com>	<200508121547.j7CFl2en014246@tundra.winternet.com>	<2ea3fae105081209467e5f189a@mail.gmail.com>	<8a0c3678050812100839dc55f6@mail.gmail.com>	<200508121919.j7CJJ9tI015058@tundra.winternet.com>	<2ea3fae1050812122862420f71@mail.gmail.com>	<20050812201232.GA8267@openbios.org>
	<200508152059.j7FKxwwn002444@tundra.winternet.com>
Message-ID: <43012D87.5070205@linuxmachines.com>

On 08/15/2005 01:59 PM, Ken Fuchs wrote:
> YH wrote:
> 
> 
>>The xeltek ISP Header + 280U can be used for in-system programming.
>>
>>http://www.xeltek.com/pages.php?pageid=8
>>
>>That could be useful, if your mb don't have flash socket and flash os
>>soldered in.

That's great; I just added it to the FAQ. The hardware development tools
links currently in the FAQ might be better off right on the main page.
Anyone seriously interested in helping linuxbios is going to need some
of those tools.

> This would require one or more (a lot of them for the Xeltek ISP
> Header) headers on the mainboard.  I couldn't find any information
> about the Xeltek ISP Header.  It seems like it might even work on an
> Enhanced Willem Universal Programmer.  It would be simpler to have a
> single larger header, if the Xeltec ISP Header (adapter) needs to be
> detached while the mainboard is operating.  I'd really prefer
> something that can remain attached while the mainboard is in
> operation.

Ya, there are such things floating around. I've seen in circuit
programmers before; this xeltek one looks like it may be hard to use.

> It would even be possible to use the JTAG connector to flash the
> system BIOS.  All Opteron mainboards must include "JTAG" circuits, but

You don't say!

> usually don't include the two JTAG headers.  Adding the headers is
> quite easy.  

Hmmm. two headers? Interesting.

> An open source Opteron JTAG flash programmer is probably
> won't happen any time soon, 

Holy (**& that's fantastic. It sure might happen soon! OK, I might be
getting ahead of myself. Are you sure the Opteron doesn't require a ITP
or similar debugging port? Or in other words: Can you single step/halt
the processor/dump registers using the JTAG port. Lets hope so;
otherwise you might not be able to do much via the JTAG port.

JTAG is a fantastic standard -- I'd expect it to be adopted for any new
chip entering the market.

> although it shouldn't be too difficult to
> do.  Anyone aware of an open source JTAG flash programmer of any kind?

Yes, there are at least two projects. I added a JTAG programming page to
the FAQ: http://linuxbios.org/index.php/JTAG/BSDL_Guide

So here are some questions then:

Do you know of any motherboards that leave the JTAG connections populated?

Do you have instructions for populating them on some motherboard I could
pick up?

Do you have links to the Opteron JTAG docs (these docs will tell you
what you can and can't do from the JTAG port)?

We will need the BSDL files for the Opteron. Now if only that was the
case for the Pentium M...

Have a nice day,
Jeff

Here is output of talking to a Xilinx FPGA & CPLD using a $25 jtag cable
from linux with all free software: (that's why everyone is switching to
JTAG -- cheaper manufacturing software/hardware costs)

jtag> cable parallel 0x378 DLC5
Initializing Xilinx DLC5 JTAG Parallel Cable III on parallel port at 0x378
jtag> detect
IR length: 14
Chain length: 2
Device Id: 00000101000001000110000010010011
  Manufacturer: Xilinx
  Unknown part!
Device Id: 00010001010000101000000010010011
  Manufacturer: Xilinx
  Part:         xc3s1000_ft256
  Stepping:     0
  Filename:     /usr/share/jtag/xilinx/xc3s1000_ft256/xc3s1000_ft256
chain.c(110) Part 0 without active instruction
chain.c(133) Part 0 without active instruction
chain.c(110) Part 0 without active instruction
jtag> instruction SAMPLE/PRELOAD
jtag> shift ir
chain.c(110) Part 0 without active instruction
jtag>



From stuge-linuxbios at cdy.org  Tue Aug 16 02:42:59 2005
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 16 Aug 2005 02:42:59 +0200
Subject: [LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]
In-Reply-To: <43012D87.5070205@linuxmachines.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
	<2ea3fae1050812122862420f71@mail.gmail.com>
	<20050812201232.GA8267@openbios.org>
	<200508152059.j7FKxwwn002444@tundra.winternet.com>
	<43012D87.5070205@linuxmachines.com>
Message-ID: <20050816004259.9696.qmail@cdy.org>

On Mon, Aug 15, 2005 at 05:04:23PM -0700, Jeff Carr wrote:
> >>The xeltek ISP Header + 280U can be used for in-system
> >>programming.
> >>
> >>http://www.xeltek.com/pages.php?pageid=8

I like how the 280U and 580U look.

I just sent Xeltek an email asking if they would be interested in
releasing specs for the USB communication, and offered to write Linux
software supporting their products.


//Peter



From jcarr at linuxmachines.com  Tue Aug 16 03:10:54 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Mon, 15 Aug 2005 18:10:54 -0700
Subject: [LinuxBIOS] Where to put datasheets in wiki?
In-Reply-To: <1124126845.5294.9.camel@logarithm.lanl.gov>
References: <42FF8AF2.10909@linuxmachines.com>
	<1124126845.5294.9.camel@logarithm.lanl.gov>
Message-ID: <43013D1E.8020609@linuxmachines.com>

On 08/15/2005 10:27 AM, Li-Ta Lo wrote:

> I don't think you have M-system on our machine. As I said before, the
> problem you have is that flash_rom can not enable flash write on you
> chipset so it just can't detect any flash chip.

Well, I ran flash_rom on a few random machines. Older, newer, etc.
flash_rom found a standard jedec flash chip on one machine:

probe_jedec: id1 0xbf, id2 0x60
SST49LF004A/B found at physical address: 0xfff80000
Part is SST49LF004A/B

But on all others, only mine did the probe_md2802 do anything that was
not just 0xff or 0x11. So I was just going on the assumption (perhaps
bad assumption) that it was finding *something*. In any case, there is
lots of work to do to increase what flash_rom can detect.

Perhaps there are other tools that should be tried. I start to wonder
that I shouldn't be using some other kernel device drivers instead
(mtd,jffs)? The PC_CHIPS_M810LR port guide does this so perhaps this is
the recommended route going foward?

Thanks for your feedback though,
Jeff


So this is just junk output? It would be nice if the wiki had "good"
output to compare things with.

probe_md2802: IPL_0x0000: 0x6d
probe_md2802: IPL_0x0001: 0x00
probe_md2802: IPL_0x0002: 0x01
probe_md2802: IPL_0x0003: 0x83
probe_md2802:
probe_md2802: ChipID: 0xed
probe_md2802: DOCStatus: 0xba
probe_md2802: FloorSelect: 0x00
probe_md2802: CDSNControl: 0xb0
probe_md2802: CDSNDeviceSelect: 0x70
probe_md2802: ECCConfiguration: 0xee
probe_md2802: CDSNSlowIO: 0xed
probe_md2802: ECCSyndrome0: 0xee
probe_md2802: ECCSyndrome1: 0xe6
probe_md2802: ECCSyndrome2: 0xed
probe_md2802: ECCSyndrome3: 0xb0
probe_md2802: ECCSyndrome4: 0xff
probe_md2802: ECCSyndrome5: 0xee
probe_md2802: AliasResolution: 0xf1
probe_md2802: ConfigurationInput: 0xe6
probe_md2802: ReadPipelineInitialization: 0xed
probe_md2802: LastDataRead: 0xc0



From jcarr at linuxmachines.com  Tue Aug 16 03:21:20 2005
From: jcarr at linuxmachines.com (Jeff Carr)
Date: Mon, 15 Aug 2005 18:21:20 -0700
Subject: [LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]
In-Reply-To: <20050816004259.9696.qmail@cdy.org>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>	<42FC52FA.30800@linuxmachines.com>	<200508121547.j7CFl2en014246@tundra.winternet.com>	<2ea3fae105081209467e5f189a@mail.gmail.com>	<8a0c3678050812100839dc55f6@mail.gmail.com>	<200508121919.j7CJJ9tI015058@tundra.winternet.com>	<2ea3fae1050812122862420f71@mail.gmail.com>	<20050812201232.GA8267@openbios.org>	<200508152059.j7FKxwwn002444@tundra.winternet.com>	<43012D87.5070205@linuxmachines.com>
	<20050816004259.9696.qmail@cdy.org>
Message-ID: <43013F90.60804@linuxmachines.com>

On 08/15/2005 05:42 PM, Peter Stuge wrote:
> On Mon, Aug 15, 2005 at 05:04:23PM -0700, Jeff Carr wrote:
> 
>>>>The xeltek ISP Header + 280U can be used for in-system
>>>>programming.
>>>>
>>>>http://www.xeltek.com/pages.php?pageid=8
> 
> I like how the 280U and 580U look.
> 
> I just sent Xeltek an email asking if they would be interested in
> releasing specs for the USB communication, and offered to write Linux
> software supporting their products.

Excellent; goodluck!

We need to dig up some old hat's in this arena. See if we can find a
lead on better in-socket options. The adapters for in socket programming
are rare and expensive I think (not lots of demand for that kind of
thing). For some chips, that's just going to be the only way things can
go of course.

Anyone care to estimate the percentage of socketed vs. non-socketed
BIOS's in the world's x86 machines shipped since 1990? since 2000?

Jeff



From Narahari.Narasimhaiah at honeywell.com  Tue Aug 16 08:23:37 2005
From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10))
Date: Mon, 15 Aug 2005 23:23:37 -0700
Subject: [LinuxBIOS] Booting windows XP
Message-ID: <77ED2BF75D59D1439F90412CC5B1097422B4E021@ie10-sahara.hiso.honeywell.com>


Hi,

I am using the ADLO bochs bios, itself.
I have an XP image directed to serial console. The redirection is done at
windows level, i.e. after the windows is loaded. 
Is it very essential that I have to have VGA support in the BIOS to boot
this kind of image?
I am sending you the log which describes the details of the problem. Please
find the log as an attachment.

Soliciting suggestions, directions and help, 
With regards,
narahari
 <<win_capt.TXT>> 
________________________Honeywell

Narahari Murthy N.
Honeywell Technology Solutions Lab - Bangalore
151/1, Doraisanipalya, Bannerghatta Road
Bangalore - 560076, India
Ph: 91-80-26588360 ext. 2318
ph_res: 91-80-22380923
mobile: 9880806206
e-mail: narahari.narasimhaiah at honeywell.com

" If you love something, set it free. If it comes back to you, it's yours.
If it doesn't, it never was"
"You cannot believe in God until you believe in yourself" - Swami
Vivekananda."
"Our greatest glory consists not in never falling, but in rising every time
we fall"
"In the end, we will remember not the words of our enemies, but the silence
of our friends"


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050815/4509e095/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: win_capt.TXT
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050815/4509e095/attachment.ksh>

From frieder.ferlemann at web.de  Tue Aug 16 08:46:12 2005
From: frieder.ferlemann at web.de (Frieder Ferlemann)
Date: Tue, 16 Aug 2005 08:46:12 +0200
Subject: [LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]
In-Reply-To: <20050816004259.9696.qmail@cdy.org>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>	<42FC52FA.30800@linuxmachines.com>	<200508121547.j7CFl2en014246@tundra.winternet.com>	<2ea3fae105081209467e5f189a@mail.gmail.com>	<8a0c3678050812100839dc55f6@mail.gmail.com>	<200508121919.j7CJJ9tI015058@tundra.winternet.com>	<2ea3fae1050812122862420f71@mail.gmail.com>	<20050812201232.GA8267@openbios.org>	<200508152059.j7FKxwwn002444@tundra.winternet.com>	<43012D87.5070205@linuxmachines.com>
	<20050816004259.9696.qmail@cdy.org>
Message-ID: <43018BB4.3010505@web.de>

Peter Stuge wrote:
> On Mon, Aug 15, 2005 at 05:04:23PM -0700, Jeff Carr wrote:
>>>>The xeltek ISP Header + 280U can be used for in-system
>>>>programming.
>>>>
>>>>http://www.xeltek.com/pages.php?pageid=8
> 
> I like how the 280U and 580U look.
> 
> I just sent Xeltek an email asking if they would be interested in
> releasing specs for the USB communication, and offered to write Linux
> software supporting their products.

Hi,

it seems that conitec had an alpha version of linux software
for their GALEP programmer.

http://www.conitec.net/english/software.htm

Greetings,

Frieder



From stuge-linuxbios at cdy.org  Tue Aug 16 16:48:19 2005
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Tue, 16 Aug 2005 16:48:19 +0200
Subject: [LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]
In-Reply-To: <43018BB4.3010505@web.de>
References: <200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
	<2ea3fae1050812122862420f71@mail.gmail.com>
	<20050812201232.GA8267@openbios.org>
	<200508152059.j7FKxwwn002444@tundra.winternet.com>
	<43012D87.5070205@linuxmachines.com>
	<20050816004259.9696.qmail@cdy.org> <43018BB4.3010505@web.de>
Message-ID: <20050816144819.8841.qmail@cdy.org>

On Tue, Aug 16, 2005 at 08:46:12AM +0200, Frieder Ferlemann wrote:
> it seems that conitec had an alpha version of linux software
> for their GALEP programmer.

It looks nice, now if it only came with a USB connector instead of
the parallell..


//Peter



From ollie at lanl.gov  Tue Aug 16 18:22:46 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue, 16 Aug 2005 10:22:46 -0600
Subject: [LinuxBIOS] Where to put datasheets in wiki?
In-Reply-To: <43013D1E.8020609@linuxmachines.com>
References: <42FF8AF2.10909@linuxmachines.com>
	<1124126845.5294.9.camel@logarithm.lanl.gov>
	<43013D1E.8020609@linuxmachines.com>
Message-ID: <1124209366.10933.5.camel@logarithm.lanl.gov>

On Mon, 2005-08-15 at 18:10 -0700, Jeff Carr wrote:
> On 08/15/2005 10:27 AM, Li-Ta Lo wrote:
> 
> > I don't think you have M-system on our machine. As I said before, the
> > problem you have is that flash_rom can not enable flash write on you
> > chipset so it just can't detect any flash chip.
> 
> Well, I ran flash_rom on a few random machines. Older, newer, etc.
> flash_rom found a standard jedec flash chip on one machine:
> 
> probe_jedec: id1 0xbf, id2 0x60
> SST49LF004A/B found at physical address: 0xfff80000
> Part is SST49LF004A/B
> 

I think it is the one.

> But on all others, only mine did the probe_md2802 do anything that was
> not just 0xff or 0x11. So I was just going on the assumption (perhaps
> bad assumption) that it was finding *something*. In any case, there is
> lots of work to do to increase what flash_rom can detect.
> 
> Perhaps there are other tools that should be tried. I start to wonder
> that I shouldn't be using some other kernel device drivers instead
> (mtd,jffs)? The PC_CHIPS_M810LR port guide does this so perhaps this is
> the recommended route going foward?
> 

I don't think other software will help for your case. Nobody know how to
enable flash write on your particular SiS chipset. Other software will
fail as well.

> Thanks for your feedback though,
> Jeff
> 
> 
> So this is just junk output? It would be nice if the wiki had "good"
> output to compare things with.
> 

I don't use DoC for a long time I have no idea what it is talking now.

> probe_md2802: IPL_0x0000: 0x6d
> probe_md2802: IPL_0x0001: 0x00
> probe_md2802: IPL_0x0002: 0x01
> probe_md2802: IPL_0x0003: 0x83
> probe_md2802:
> probe_md2802: ChipID: 0xed
> probe_md2802: DOCStatus: 0xba
> probe_md2802: FloorSelect: 0x00
> probe_md2802: CDSNControl: 0xb0
> probe_md2802: CDSNDeviceSelect: 0x70
> probe_md2802: ECCConfiguration: 0xee
> probe_md2802: CDSNSlowIO: 0xed
> probe_md2802: ECCSyndrome0: 0xee
> probe_md2802: ECCSyndrome1: 0xe6
> probe_md2802: ECCSyndrome2: 0xed
> probe_md2802: ECCSyndrome3: 0xb0
> probe_md2802: ECCSyndrome4: 0xff
> probe_md2802: ECCSyndrome5: 0xee
> probe_md2802: AliasResolution: 0xf1
> probe_md2802: ConfigurationInput: 0xe6
> probe_md2802: ReadPipelineInitialization: 0xed
> probe_md2802: LastDataRead: 0xc0
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From fgleich at cableone.net  Tue Aug 16 19:14:52 2005
From: fgleich at cableone.net (Frederick Gleicher)
Date: Tue, 16 Aug 2005 11:14:52 -0600
Subject: [LinuxBIOS] supported mb list
Message-ID: <43021F0C.60704@cableone.net>

Hello:
Where now is the list of the supported mb for linuxbios ? its' not 
readily evident on the website
Thanks,
F.Gleicher



From stepan at openbios.org  Tue Aug 16 20:01:21 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 16 Aug 2005 20:01:21 +0200
Subject: [LinuxBIOS] supported mb list
In-Reply-To: <43021F0C.60704@cableone.net>
References: <43021F0C.60704@cableone.net>
Message-ID: <20050816180121.GA15664@openbios.org>

* Frederick Gleicher <fgleich at cableone.net> [050816 19:14]:
> Hello:
> Where now is the list of the supported mb for linuxbios ? its' not 
> readily evident on the website

3rd link from top on the main page:
http://www.linuxbios.org/index.php/Supported_Motherboards

> Thanks,
> F.Gleicher
> 
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 



From kfuchs at winternet.com  Tue Aug 16 22:13:40 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Tue, 16 Aug 2005 15:13:40 -0500 (CDT)
Subject: [LinuxBIOS] In System Flash Programming [Was: BIOS Saver RD1]
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<42FC52FA.30800@linuxmachines.com>
	<200508121547.j7CFl2en014246@tundra.winternet.com>
	<2ea3fae105081209467e5f189a@mail.gmail.com>
	<8a0c3678050812100839dc55f6@mail.gmail.com>
	<200508121919.j7CJJ9tI015058@tundra.winternet.com>
	<2ea3fae1050812122862420f71@mail.gmail.com>
	<20050812201232.GA8267@openbios.org>
	<200508152059.j7FKxwwn002444@tundra.winternet.com>
	<43012D87.5070205@linuxmachines.com>
Message-ID: <200508162013.j7GKDeeP007642@tundra.winternet.com>

> Ken Fuchs wrote:

> > It would even be possible to use the JTAG connector to flash the
> > system BIOS.  All Opteron mainboards must include "JTAG" 
> > circuits, but

Jeff Carr wrote:

> You don't say!

Yes, AMD requires all Opteron (probably uniprocessor AMD64 too)
mainboards have the "JTAG" debugging circuits so AMD's Hardware Debug
Tool (HDT - requies a host with MS Windows 2000/XP & NDA) will run on
them.  Any Opteron mainboard without "JTAG" circuits would have to be
developed without AMD's support, so such mainboards probably don't
exist.

> > usually don't include the two JTAG headers.  Adding the headers is
> > quite easy.  

> Hmmm. two headers? Interesting.

Yes, one per Opteron processor.  Obviously only one would be needed to
flash the BIOS.

> > An open source Opteron JTAG flash programmer probably
> > won't happen any time soon, 

Sorry, I was just being pessimistic here.  I'm not even sure the
Opteron JTAG chains support flashing the BIOS device, but I would be
surprised if it didn't.

> Holy (**& that's fantastic. It sure might happen soon! OK, I might be
> getting ahead of myself. Are you sure the Opteron doesn't 
> require a ITP
> or similar debugging port? Or in other words: Can you single step/halt
> the processor/dump registers using the JTAG port. Lets hope so;
> otherwise you might not be able to do much via the JTAG port.

AMD requires a special JTAG port be used for the Opteron (AMD64).  The
AMD64 JTAG header is 2x13 with 0.05" spacing between pins.

The HDT software running on a MS Windows 2000/XP host can be used to
single step/halt the processor, dump registers and a whole lot more.

The American Arium ECM-50 can be attached using an Opteron Personality
Module via the JTAG (HDT) port.  Provides nice source level debugging.

> JTAG is a fantastic standard -- I'd expect it to be adopted 
> for any new chip entering the market.

It has been used for several years, AFAIK.

> > although it shouldn't be too difficult to do.  Anyone aware of
> > an open source JTAG flash programmer of any kind?

> Yes, there are at least two projects. I added a JTAG programming
> page to the FAQ: http://linuxbios.org/index.php/JTAG/BSDL_Guide

Thank you!

Macraigor Systems produces and sells the Raven or OCDemon device that
is required to attach to the AMD Opteron JTAG.  They also have GNU
software that allows one to use their OCD adapters (Raven & OCDemon):

http://www.macraigor.com/full_gnu.htm

> So here are some questions then:

> Do you know of any motherboards that leave the JTAG 
> connections populated?

I don't think any motherboards include JTAG headers, except possibly
Reference Design mainboards produced by chipset makers to demonstate
their chipsets to mainboard manufacturers.  However, even my nVidia
CK8-04 CRB mainboard did not come with JTAG headers.  However, the
toggle switch that enables JTAG access to one or both CPUs was
included.  Those 2x13 .05" headers must be expensive.

> Do you have instructions for populating them on some 
> motherboard I could pick up?

There are only two 2x13 .05" pads for the headers, so it should be
easy to see where they.  If the headers are keyed (have a missing
pin), one may need to look at the mainboard schematic to get the right
orientation.  You would need that in any case to get the ribbon cables
attached to the header with the proper orientation.

> Do you have links to the Opteron JTAG docs (these docs will tell you
> what you can and can't do from the JTAG port)?

Clearly, the Opteron JTAG docs are available on the AMD NDA web site,
but I suspect that the more basic JTAG information is available
without need for an NDA from 

> We will need the BSDL files for the Opteron. Now if only that was the
> case for the Pentium M...

The closest I could find was BSDL files for K6:

http://www.amd.com/epd/designing/tsdocs/3.bsdfiles/

Maybe, if the right person nicely asks the right person at AMD, they
would provide the BSDL files for the Opteron.  Couldn't hurt to try.

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From steve at digidescorp.com  Tue Aug 16 23:40:50 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Tue, 16 Aug 2005 16:40:50 -0500
Subject: [BULK] [LinuxBIOS] elfboot() can trash GDT
Message-ID: <001e01c5a2ab$2eecdef0$6ffea8c0@banana>

Eric wrote:

> We really can't sanely fix this when you are doing something that 
> seems to have no real justification.

Maybe I'm missing something, but it doesn't seem difficult to me to fix
this sanely...

--------------
--- src/arch/i386/boot/tables.c.orig	2005-08-16 16:27:20.000000000
-0500
+++ src/arch/i386/boot/tables.c	2005-08-16 16:17:41.766000000 -0500
@@ -7,6 +7,32 @@
 #include <arch/acpi.h>
 #include "linuxbios_table.h"
 
+// Global Descriptor Table, defined in c_start.S
+extern uint8_t gdt;
+extern uint8_t gdt_end;
+
+/* i386 lgdt argument */
+struct gdtarg {
+    unsigned short limit;
+    unsigned int base;
+} __attribute__((packed));
+
+// Copy GDT to new location and reload it
+// 2003-07 by SONE Takeshi
+// Ported from Etherboot to LinuxBIOS 2005-08 by Steve Magnani
+void move_gdt(unsigned long newgdt)
+{
+	uint16_t num_gdt_bytes = &gdt_end - &gdt;
+    struct gdtarg gdtarg;
+
+    printk_debug("Moving GDT to %#lx...", newgdt);
+    memcpy((void*)newgdt, &gdt, num_gdt_bytes);
+    gdtarg.base = newgdt;
+    gdtarg.limit = num_gdt_bytes - 1;
+    __asm__ __volatile__ ("lgdt %0\n\t" : : "m" (gdtarg));
+    printk_debug("ok\n");
+}
+
 struct lb_memory *write_tables(void)
 {
 	unsigned long low_table_start, low_table_end;
@@ -45,6 +71,10 @@
 		low_table_end = 0x500;
 	}
 
+	// Relocate the GDT to reserved memory, so it won't get
clobbered
+	move_gdt(low_table_end);
+	low_table_end += &gdt_end - &gdt;
+
 	/* The linuxbios table must be in 0-4K or 960K-1M */
 	write_linuxbios_table(
 			      low_table_start, low_table_end,
------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"
 
 #include <standard.disclaimer>






From jerj at coplanar.net  Tue Aug 16 23:44:54 2005
From: jerj at coplanar.net (Jeremy Jackson)
Date: Tue, 16 Aug 2005 17:44:54 -0400
Subject: [LinuxBIOS] AMD board support
In-Reply-To: <2ea3fae1050728104365b12269@mail.gmail.com>
References: <1122573869.13409.10.camel@scrod>
	<2ea3fae1050728104365b12269@mail.gmail.com>
Message-ID: <43025E56.5060700@coplanar.net>

yhlu wrote:

>S2865 support athlon64 instead of Opteron.
>
>athlon64 doesn't support ECC.
>
>I have tried to comment out lines in raminit.c and could boot the
>system with LinuxBIOS.
>
>the problem are
>1. it only supports one DIMM ...?
>2. Etherboot support 5721 may still have problem, Tim already put sth
>to support 5721 in Etherboot but have no time to verify that.
>
>YH
>  
>
I would be very interested to know if this board will become supported 
soon.    I know nVidia can be difficult to deal with.  In particular I 
would like to use this board with Linuxbios and boot from SATA.

I am also confused by the chipset name - nForce4 Ultra - is that the 
same as CK8-04?

Regards,

Jeremy



From yinghailu at gmail.com  Tue Aug 16 23:53:29 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 16 Aug 2005 14:53:29 -0700
Subject: [LinuxBIOS] AMD board support
In-Reply-To: <43025E56.5060700@coplanar.net>
References: <1122573869.13409.10.camel@scrod>
	<2ea3fae1050728104365b12269@mail.gmail.com>
	<43025E56.5060700@coplanar.net>
Message-ID: <2ea3fae10508161453772f0cac@mail.gmail.com>

It was there, and after comment out buffer checking in raminit.c, it
could work with one DIMM installed.

the ck804 pro should be superset of ultra.

YH

On 8/16/05, Jeremy Jackson <jerj at coplanar.net> wrote:
> yhlu wrote:
> 
> >S2865 support athlon64 instead of Opteron.
> >
> >athlon64 doesn't support ECC.
> >
> >I have tried to comment out lines in raminit.c and could boot the
> >system with LinuxBIOS.
> >
> >the problem are
> >1. it only supports one DIMM ...?
> >2. Etherboot support 5721 may still have problem, Tim already put sth
> >to support 5721 in Etherboot but have no time to verify that.
> >
> >YH
> >
> >
> I would be very interested to know if this board will become supported
> soon.    I know nVidia can be difficult to deal with.  In particular I
> would like to use this board with Linuxbios and boot from SATA.
> 
> I am also confused by the chipset name - nForce4 Ultra - is that the
> same as CK8-04?
> 
> Regards,
> 
> Jeremy
>



From jerj at coplanar.net  Wed Aug 17 01:13:43 2005
From: jerj at coplanar.net (Jeremy Jackson)
Date: Tue, 16 Aug 2005 19:13:43 -0400
Subject: [LinuxBIOS] AMD board support
In-Reply-To: <2ea3fae10508161453772f0cac@mail.gmail.com>
References: <1122573869.13409.10.camel@scrod>	
	<2ea3fae1050728104365b12269@mail.gmail.com>	
	<43025E56.5060700@coplanar.net>
	<2ea3fae10508161453772f0cac@mail.gmail.com>
Message-ID: <43027327.6090402@coplanar.net>

yhlu wrote:

>It was there, and after comment out buffer checking in raminit.c, it
>could work with one DIMM installed.
>
>the ck804 pro should be superset of ultra.
>
>YH
>  
>
Ok, good to know.  I want to be perfectly clear that SATA is working to 
boot from Linuxbios, before I order a sample board.

Thanks,

Jeremy



From yinghailu at gmail.com  Wed Aug 17 01:39:15 2005
From: yinghailu at gmail.com (yhlu)
Date: Tue, 16 Aug 2005 16:39:15 -0700
Subject: [LinuxBIOS] AMD board support
In-Reply-To: <43027327.6090402@coplanar.net>
References: <1122573869.13409.10.camel@scrod>
	<2ea3fae1050728104365b12269@mail.gmail.com>
	<43025E56.5060700@coplanar.net>
	<2ea3fae10508161453772f0cac@mail.gmail.com>
	<43027327.6090402@coplanar.net>
Message-ID: <2ea3fae10508161639560543a9@mail.gmail.com>

You need to talk to Tyan to see if they want to release the source
code for s2865 support.

YH

On 8/16/05, Jeremy Jackson <jerj at coplanar.net> wrote:
> yhlu wrote:
> 
> >It was there, and after comment out buffer checking in raminit.c, it
> >could work with one DIMM installed.
> >
> >the ck804 pro should be superset of ultra.
> >
> >YH
> >
> >
> Ok, good to know.  I want to be perfectly clear that SATA is working to
> boot from Linuxbios, before I order a sample board.
> 
> Thanks,
> 
> Jeremy
>



From justin at street-vision.com  Wed Aug 17 01:55:57 2005
From: justin at street-vision.com (Justin Cormack)
Date: Wed, 17 Aug 2005 00:55:57 +0100
Subject: [LinuxBIOS] AMD board support
In-Reply-To: <2ea3fae10508161639560543a9@mail.gmail.com>
References: <1122573869.13409.10.camel@scrod>
	<2ea3fae1050728104365b12269@mail.gmail.com>
	<43025E56.5060700@coplanar.net>
	<2ea3fae10508161453772f0cac@mail.gmail.com>
	<43027327.6090402@coplanar.net>
	<2ea3fae10508161639560543a9@mail.gmail.com>
Message-ID: <C19A3CD0-5CA2-4AD3-B96B-858527D5B10D@street-vision.com>



It would be nice if they did. In my case it would probably make the  
difference between buying Tyan vs buying Supermicro for most boards  
for the next few years at least. Probably only a few hundred boards.  
The reason is mainly not that it is an Athlon not Opteron board, just  
that it is the only ATX board that Tyan ships.


On 17 Aug 2005, at 00:39, yhlu wrote:

> You need to talk to Tyan to see if they want to release the source
> code for s2865 support.
>
> YH
>
> On 8/16/05, Jeremy Jackson <jerj at coplanar.net> wrote:
>
>> yhlu wrote:
>>
>>
>>> It was there, and after comment out buffer checking in raminit.c, it
>>> could work with one DIMM installed.
>>>
>>> the ck804 pro should be superset of ultra.
>>>
>>> YH
>>>
>>>
>>>
>> Ok, good to know.  I want to be perfectly clear that SATA is  
>> working to
>> boot from Linuxbios, before I order a sample board.
>>
>> Thanks,
>>
>> Jeremy
>>
>>
>
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>




From Narahari.Narasimhaiah at honeywell.com  Wed Aug 17 07:12:16 2005
From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10))
Date: Tue, 16 Aug 2005 22:12:16 -0700
Subject: [LinuxBIOS] (no subject)
Message-ID: <77ED2BF75D59D1439F90412CC5B1097422C30ADF@ie10-sahara.hiso.honeywell.com>


Hi,

Yes we are using ADLO bochs bios.
We do not have VGA support in our bios yet. 
Is it necessary to have VGA bios support to boot Windows XP?
The windows XP image we have has console redirected to serial port.

Please help me in this respect,

With regards,
narahari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050816/04dbdea8/attachment.html>

From Narahari.Narasimhaiah at honeywell.com  Wed Aug 17 13:39:43 2005
From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10))
Date: Wed, 17 Aug 2005 04:39:43 -0700
Subject: [LinuxBIOS] Booting windows XP
Message-ID: <77ED2BF75D59D1439F90412CC5B1097422CC7FFA@ie10-sahara.hiso.honeywell.com>


Hi,

Have any body tried to boot "embedded XP with console redirected to serial
port" using LinuxBIOS (freebios + ADLO bochs)?
Is it possible to boot XP with the LinuxBIOS that has no VGA support?

Please help me with this respect,

With regards,
narahari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050817/c7161e06/attachment.html>

From jerj at coplanar.net  Wed Aug 17 15:26:09 2005
From: jerj at coplanar.net (Jeremy Jackson)
Date: Wed, 17 Aug 2005 09:26:09 -0400
Subject: [LinuxBIOS] AMD board support
In-Reply-To: <2ea3fae10508161639560543a9@mail.gmail.com>
References: <1122573869.13409.10.camel@scrod>	
	<2ea3fae1050728104365b12269@mail.gmail.com>	
	<43025E56.5060700@coplanar.net>	
	<2ea3fae10508161453772f0cac@mail.gmail.com>	
	<43027327.6090402@coplanar.net>
	<2ea3fae10508161639560543a9@mail.gmail.com>
Message-ID: <43033AF1.60607@coplanar.net>

Ok, but when you say you commented out some things, which code was that 
based on?   Was it for a board that has been released?  (ie in linuxbios 
public repository?)

Regards,

Jeremy

yhlu wrote:

>You need to talk to Tyan to see if they want to release the source
>code for s2865 support.
>
>YH
>
>On 8/16/05, Jeremy Jackson <jerj at coplanar.net> wrote:
>  
>
>>yhlu wrote:
>>
>>    
>>
>>>It was there, and after comment out buffer checking in raminit.c, it
>>>could work with one DIMM installed.
>>>
>>>the ck804 pro should be superset of ultra.
>>>
>>>YH
>>>      
>>>




From yinghailu at gmail.com  Wed Aug 17 17:01:11 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 17 Aug 2005 08:01:11 -0700
Subject: [LinuxBIOS] Booting windows XP
In-Reply-To: <77ED2BF75D59D1439F90412CC5B1097422CC7FFA@ie10-sahara.hiso.honeywell.com>
References: <77ED2BF75D59D1439F90412CC5B1097422CC7FFA@ie10-sahara.hiso.honeywell.com>
Message-ID: <2ea3fae10508170801ec799f8@mail.gmail.com>

That depends XP, Can you try with NB and the MB without any VGA
onboard or addon card?

YH

On 8/17/05, Narahari, Narasimhaiah (IE10)
<Narahari.Narasimhaiah at honeywell.com> wrote:
> 
> 
> 
> Hi, 
> 
> Have any body tried to boot "embedded XP with console redirected to serial
> port" using LinuxBIOS (freebios + ADLO bochs)?
> 
> Is it possible to boot XP with the LinuxBIOS that has no VGA support? 
> 
> Please help me with this respect, 
> 
> With regards, 
> narahari 
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 
>



From yinghailu at gmail.com  Wed Aug 17 17:05:30 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 17 Aug 2005 08:05:30 -0700
Subject: [LinuxBIOS] AMD board support
In-Reply-To: <43033AF1.60607@coplanar.net>
References: <1122573869.13409.10.camel@scrod>
	<2ea3fae1050728104365b12269@mail.gmail.com>
	<43025E56.5060700@coplanar.net>
	<2ea3fae10508161453772f0cac@mail.gmail.com>
	<43027327.6090402@coplanar.net>
	<2ea3fae10508161639560543a9@mail.gmail.com>
	<43033AF1.60607@coplanar.net>
Message-ID: <2ea3fae1050817080522d7036b@mail.gmail.com>

For every MB, there should be one dir in src/mainboard/$MBVENDOR/$MBMODEL
and targets/$MBvENDOR/$MBMODEL

there are some lines in src/northbridge/amd/amdk8/raminit.c about
buffer or ecc bit checking need to be commend out.

Just let you sales window talk to Tyan, they would like to help.

YH

On 8/17/05, Jeremy Jackson <jerj at coplanar.net> wrote:
> Ok, but when you say you commented out some things, which code was that
> based on?   Was it for a board that has been released?  (ie in linuxbios
> public repository?)
> 
> Regards,
> 
> Jeremy
> 
> yhlu wrote:
> 
> >You need to talk to Tyan to see if they want to release the source
> >code for s2865 support.
> >
> >YH
> >
> >On 8/16/05, Jeremy Jackson <jerj at coplanar.net> wrote:
> >
> >
> >>yhlu wrote:
> >>
> >>
> >>
> >>>It was there, and after comment out buffer checking in raminit.c, it
> >>>could work with one DIMM installed.
> >>>
> >>>the ck804 pro should be superset of ultra.
> >>>
> >>>YH
> >>>
> >>>
> 
>



From hamish at prodigi.ch  Wed Aug 17 20:27:48 2005
From: hamish at prodigi.ch (Hamish Guthrie)
Date: Wed, 17 Aug 2005 20:27:48 +0200
Subject: [LinuxBIOS] Help with relocation of reset vector
Message-ID: <430381A4.6080806@prodigi.ch>

Hi All,

I recently had a disaster in that both my development system and backup 
servers had hard drive crashes within a few hours of each other, and I 
have lost some source, of which I have no other copies (ehem, no 
comments please!!).

For various reasons, I have a bit of real-mode code I execute before I 
vector off to LinuxBIOS. The normal boot vector, therefore executes this 
real-mode code, and once that is done executing, I want a clean 
interface to LinuxBIOS. The way I had implemented this previously was by 
somehow lowering the point at which the LinuxBIOS reset vector was 
created, and then doing a near jump to the LinuxBIOS vector. What I am 
wanting to achieve is the following memory map (considering the top 64k 
of flash only).

0xffff0000	Start of LinuxBIOS ROM space
0xffff7ff0	LinuxBIOS reset vector poing to LB entry point
0xffff8000	Start of realmode code
0xffff????	{jmp to LinuxBIOS reset vector}
0xfffffff0	Realmode vector

Of course, the realmode memory map can be ignored, as I already have the 
realmode code for that, and that on completion vectors to 0xffff7ff0

I want to create a binary, with correct relocation so that the binary 
can be executed in place at 0xffff0000 from a boot vector at 0xffff7ff0 
and still retain it's integrity.

I managed to do this about 3 or 4 months ago, but since then have been 
doing a lot of other stuff and have completely forgotten how I did it, 
and have got out of the 'LinuxBIOS mode' for the time being!. All I 
recall is that I did some trickery by having my own replacements of the 
creation of the LinuxBIOS vectors somewhere in my own tree, and that 
portion of the tree is now gone.

Is there possibly a generic way this can be done so that the placement 
of the vector can be parameterised?

Any help would be greatly appreciated.

TIA

Hamish



From adam at cfar.umd.edu  Wed Aug 17 18:53:14 2005
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Wed, 17 Aug 2005 12:53:14 -0400 (EDT)
Subject: [LinuxBIOS] Booting windows XP
In-Reply-To: <77ED2BF75D59D1439F90412CC5B1097422CC7FFA@ie10-sahara.hiso.honeywell.com>
References: <77ED2BF75D59D1439F90412CC5B1097422CC7FFA@ie10-sahara.hiso.honeywell.com>
Message-ID: <Pine.BSF.4.62.0508171252330.36578@www.missl.cs.umd.edu>

>
> Have any body tried to boot "embedded XP with console redirected to serial
> port" using LinuxBIOS (freebios + ADLO bochs)?

i'm not familar with embedded XP.

> Is it possible to boot XP with the LinuxBIOS that has no VGA support?

generally speaking yes.

-- 
Adam Sulmicki
http://www.eax.com 	The Supreme Headquarters of the 32 bit registers



From paul at astro.gla.ac.uk  Wed Aug 17 19:47:04 2005
From: paul at astro.gla.ac.uk (Paul Millar)
Date: Wed, 17 Aug 2005 18:47:04 +0100
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable
	BIOS programmer ?]
In-Reply-To: <4300973D.4020601@linuxmachines.com>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<200508151056.38490.p.millar@physics.gla.ac.uk>
	<4300973D.4020601@linuxmachines.com>
Message-ID: <200508171847.14557.paul@astro.gla.ac.uk>

On Monday 15 Aug 2005 14:23, Jeff Carr wrote:
> On 08/15/05 02:56, Paul Millar wrote:
> > Would people be interested, either in the software or in helping
> > improve it?
>
> I would. You said you built your own device, but I'm not a poor student
> (anymore). Could you guess which of the three on the mcmull page:
> http://www.mcumall.com/comersus/store/comersus_dynamicIndex.asp
> would be the closest to the schematic you used?

(three?  only two on that page that I could see ....)

The closest is the "Dual Power Willem Universal EPROM Programmer".

This looks to be the same design: it has the same number of chips, in the same 
locations.  The image quality isn't good enough to say more.  Visually, the 
only difference between this one and mine is someone has mounted the linear 
regulator vertically to make space for the USB connected (just for its +5v 
line).  Obviously, without schematics for the card, I can't say for sure.

The Enhanced Willem board looks quite funky and claims to be backwards 
compatible with the previous design, but I can't find schematics for it, nor 
any reference to it on the Willem pages:
  http://www.willem.org/

I was thinking of getting one of these (not so much of a poor student 
anymore), but without the schematics, it wouldn't be so much use.

> I'd certainly be willing to make a go of it. If I can dig it up, there
> were some guys that wrote a parallel jtag interface to program amd
> flash. Maybe it would be useful. That was several years ago and the site
> seems lost in the annals of history now. Maybe you wrote that too :)

Cool.  I'll stick the software somewhere useful.

Sadly, having fixed the regulator, I'm still stuck with the problem getting 
data off of the EPROM.  I've tested  the 4014 read circuitry (and software) 
by hot-wiring various EPROM-ZIF output bits to gnd or +5v and checking the 
output: this works correctly.  Addresses are clocked in OK.  Both /CE and /OE 
are low, yet the output is neither correct (well ... believable) nor 
consistent.

Ideas on how to debug this greatfully received.

Cheers,

Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050817/de92c327/attachment.sig>

From smithbone at gmail.com  Wed Aug 17 19:53:45 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 17 Aug 2005 12:53:45 -0500
Subject: [LinuxBIOS] Booting windows XP
In-Reply-To: <Pine.BSF.4.62.0508171252330.36578@www.missl.cs.umd.edu>
References: <77ED2BF75D59D1439F90412CC5B1097422CC7FFA@ie10-sahara.hiso.honeywell.com>
	<Pine.BSF.4.62.0508171252330.36578@www.missl.cs.umd.edu>
Message-ID: <8a0c36780508171053736717d7@mail.gmail.com>

> > Have any body tried to boot "embedded XP with console redirected to serial
> > port" using LinuxBIOS (freebios + ADLO bochs)?
> 

You are in uncharted waters.  IIRC W2k is the only OS of that family
that has been booted.  See the wiki and Adam's page.
 
> > Is it possible to boot XP with the LinuxBIOS that has no VGA support?
> 
> generally speaking yes.

No VGA will make it easier but who knows what kind of bios calls XP
makes along the way.

Can bochs itself boot the image?  That would be the first step.  That
way you have lots of debugging tools available.

-- 
Richard A. Smith



From smithbone at gmail.com  Wed Aug 17 20:29:55 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 17 Aug 2005 13:29:55 -0500
Subject: [LinuxBIOS] RD1 BIOS Savior [was Re: No known linux compatable
	BIOS programmer ?]
In-Reply-To: <200508171847.14557.paul@astro.gla.ac.uk>
References: <2ea3fae10508121035724c3bdc@mail.gmail.com>
	<200508151056.38490.p.millar@physics.gla.ac.uk>
	<4300973D.4020601@linuxmachines.com>
	<200508171847.14557.paul@astro.gla.ac.uk>
Message-ID: <8a0c3678050817112965915bfe@mail.gmail.com>

> > I'd certainly be willing to make a go of it. If I can dig it up, there
> > were some guys that wrote a parallel jtag interface to program amd
> > flash. Maybe it would be useful. That was several years ago and the site
> > seems lost in the annals of history now. Maybe you wrote that too :)
> 
> Cool.  I'll stick the software somewhere useful.

If you are really up for a challenge that involves a bit of RE.  Then
let me sugggest the batronix
http://www.batronix.com/electronic/index.shtml programmer.

This weekend I spent some time working with it and linux.  The device
has a USB Cypress an2131s.  The device firmware is downloaded into the
device and linux has all the tools to do this.   I was able to build
and dowload and the usb-test code and it sort of worked.  I need to
code up a bit toggle and see if I can get that to happen and verify I
_really_ am running my firmware.  I've grabbed the datasheets off of
cypress's website and I have the example test code so this shouldn't
be too hard.

The unit is basically a bunch of latches and bus drivers that are all
on some sort of make shift address/data bus.  I beeped out a lot of
the connections to the latches and although it will be a lot of work
it looks workable to RE all the connections to the programming socket
and how to drive it.

Some USB sniffing software should also help me figure out a few
things.  Perhaps I can figure out how to  get it to work with the
firmware(s) that come with the doze software.

> Sadly, having fixed the regulator, I'm still stuck with the problem getting
> data off of the EPROM.  I've tested  the 4014 read circuitry (and software)
> by hot-wiring various EPROM-ZIF output bits to gnd or +5v and checking the
> output: this works correctly.  Addresses are clocked in OK.  Both /CE and /OE
> are low, yet the output is neither correct (well ... believable) nor
> consistent.

In the past when we have blown up various things like this some of the
latches or bus drivers were also damaged.  They may appear to work but
fail when you load them real world.

When you toasted the regulator could you have overvoltaged Vcc?  If so
then every active part on there is suspect.

-- 
Richard A. Smith



From bari at onelabs.com  Wed Aug 17 21:06:29 2005
From: bari at onelabs.com (Bari Ari)
Date: Wed, 17 Aug 2005 15:06:29 -0400
Subject: [LinuxBIOS] Booting windows XP
In-Reply-To: <Pine.BSF.4.62.0508171252330.36578@www.missl.cs.umd.edu>
References: <77ED2BF75D59D1439F90412CC5B1097422CC7FFA@ie10-sahara.hiso.honeywell.com>
	<Pine.BSF.4.62.0508171252330.36578@www.missl.cs.umd.edu>
Message-ID: <20050817150629.qv6i9x2wqvk0w484@onelabs.com>

Quoting Adam Sulmicki <adam at cfar.umd.edu>:

>>
>> Have any body tried to boot "embedded XP with console redirected to serial
>> port" using LinuxBIOS (freebios + ADLO bochs)?
>
> i'm not familar with embedded XP.
>
Embedded XP is a set of tools and docs to build stripped down versions 
of XP. It
lets you build XP without features that during the old anti-trust suit 
where M$
claimed that these things couldn't be done :)

BIOS support for embedded XP should be the same as for XP.

-Bari




From yinghailu at gmail.com  Thu Aug 18 02:04:13 2005
From: yinghailu at gmail.com (yhlu)
Date: Wed, 17 Aug 2005 17:04:13 -0700
Subject: [LinuxBIOS] SimNow
Message-ID: <2ea3fae1050817170471148460@mail.gmail.com>

http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~100481,00.html

if you have bsd for your MB, You can play LinuxBIOS on that.

Next time, We don't need any target HW still can do LinuxBIOS dev.

YH



From Narahari.Narasimhaiah at honeywell.com  Fri Aug 19 11:51:46 2005
From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10))
Date: Fri, 19 Aug 2005 02:51:46 -0700
Subject: [LinuxBIOS] Using lilo
Message-ID: <77ED2BF75D59D1439F90412CC5B10974230619D1@ie10-sahara.hiso.honeywell.com>


Sir,

How do I use LILO to boot windows 2k?

With regards,
narahari

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

From stepan at openbios.org  Fri Aug 19 12:32:10 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 19 Aug 2005 12:32:10 +0200
Subject: [LinuxBIOS] Using lilo
In-Reply-To: <77ED2BF75D59D1439F90412CC5B10974230619D1@ie10-sahara.hiso.honeywell.com>
References: <77ED2BF75D59D1439F90412CC5B10974230619D1@ie10-sahara.hiso.honeywell.com>
Message-ID: <20050819103210.GA21590@openbios.org>

* Narahari, Narasimhaiah (IE10) <Narahari.Narasimhaiah at honeywell.com> [050819 11:51]:
> 
> Sir,
> 
> How do I use LILO to boot windows 2k?
 
The usual way is to use either NTLDR or grub. Lilo is obsolete.

http://www.togaware.com/linux/survivor/MS_Windows_NT_or.shtml
http://www.faqs.org/docs/Linux-mini/Multiboot-with-GRUB.html

Stefan





From smithbone at gmail.com  Fri Aug 19 18:17:47 2005
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 19 Aug 2005 11:17:47 -0500
Subject: [LinuxBIOS] Using lilo
In-Reply-To: <20050819103210.GA21590@openbios.org>
References: <77ED2BF75D59D1439F90412CC5B10974230619D1@ie10-sahara.hiso.honeywell.com>
	<20050819103210.GA21590@openbios.org>
Message-ID: <8a0c367805081909173be2f6ec@mail.gmail.com>

> >
> > How do I use LILO to boot windows 2k?
> 
> The usual way is to use either NTLDR or grub. Lilo is obsolete.
> 

IIRC I don't think grub works under the Bochs copy in LinuxBios but
its been awhile.  Adam?

I know for a fact that LILO does.  I don't think I'd call Lilo
obsolete yet.  I use it in some embedded setups where the BIOS has
issues with GRUB.

-- 
Richard A. Smith



From Morales at appro.com  Fri Aug 19 20:18:34 2005
From: Morales at appro.com (Edwin Morales)
Date: Fri, 19 Aug 2005 11:18:34 -0700
Subject: [LinuxBIOS] newbie question of lb
Message-ID: <4B21D6C08BC8BA4A9530E43C980E58B01C35DB@hawk.appro.com>

hi all,

 

new to linuxbios and just have some basic build questions.

 

-          how to care of the payload build error

- whether it be for etherboot or filo

 

any quick tips are appreciated, anything but rtfm

 

//ed

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

From stepan at openbios.org  Fri Aug 19 20:33:17 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 19 Aug 2005 20:33:17 +0200
Subject: [LinuxBIOS] newbie question of lb
In-Reply-To: <4B21D6C08BC8BA4A9530E43C980E58B01C35DB@hawk.appro.com>
References: <4B21D6C08BC8BA4A9530E43C980E58B01C35DB@hawk.appro.com>
Message-ID: <20050819183317.GA10280@openbios.org>

* Edwin Morales <Morales at appro.com> [050819 20:18]:
> hi all,
> 
> new to linuxbios and just have some basic build questions.
> 
>  
> 
> - how to care of the payload build error
 
what build error?

> - whether it be for etherboot or filo

What's your question?
 
> any quick tips are appreciated, anything but rtfm

try to be a bit more elaborate ;-)

http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
http://www.catb.org/~esr/faqs/smart-questions.html#writewell

Stefan





From smithbone at gmail.com  Fri Aug 19 20:46:05 2005
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 19 Aug 2005 13:46:05 -0500
Subject: [LinuxBIOS] newbie question of lb
In-Reply-To: <4B21D6C08BC8BA4A9530E43C980E58B01C35DB@hawk.appro.com>
References: <4B21D6C08BC8BA4A9530E43C980E58B01C35DB@hawk.appro.com>
Message-ID: <8a0c3678050819114664c94d68@mail.gmail.com>

> any quick tips are appreciated, anything but rtfm 

If you don't want RTFM (or RTFCode in LB's case) then you will have to
give us enough info in your question to actually try and give you an
answer.  :)

In LinuxBIOS there are no quick tips.  Its a _very_ hands on, use the
source Luke kind of deal.

-- 
Richard A. Smith



From hamish at prodigi.ch  Fri Aug 19 22:53:54 2005
From: hamish at prodigi.ch (Hamish Guthrie)
Date: Fri, 19 Aug 2005 22:53:54 +0200
Subject: [LinuxBIOS] newbie question of lb
In-Reply-To: <20050819183317.GA10280@openbios.org>
References: <4B21D6C08BC8BA4A9530E43C980E58B01C35DB@hawk.appro.com>
	<20050819183317.GA10280@openbios.org>
Message-ID: <430646E2.1090403@prodigi.ch>

Hi Edwin,

I am sending you a quotation from a very good member of the open source 
community - I do not want to detract from your question, at all, but 
some of Marty's suggestions are good value for money.

I quote my friend Marty Connor

"You need to do a better job asking for help.  You provide very little 
in the way of information, and then you literally beg for help.

If you are having trouble with a project, then at least demonstrate that 
you have read (or attempted to read) the documentation.  There is also a 
mailing list for help specifically with that software, if you can't 
figure out the documentation or examples.

Also, in debugging, you should attempt to create simple test cases, and 
when they fail, send input, output, and what you thought should happen 
to the appropriate list for analysis.  Otherwise, all we can do is guess 
what might be happening.

I want to encourage you to proceed, but I also want to strongly suggest 
that if you want help, you need to show that the time of the people 
trying to help you is not wasted.  You can do this by showing that 
progress you have made, by producing output, and explaining in more 
detail what you did.

If your English skills are a problem, please find a friend who has 
better skills, and have them help you, in exchange for help with 
something they need help with.

I hope you succeed, but even more I hope that in this process you 
develop better debugging skills, and improve your methods of asking for 
help."

Marty said it all.

Hamish

Stefan Reinauer wrote:
> * Edwin Morales <Morales at appro.com> [050819 20:18]:
> 
>>hi all,
>>
>>new to linuxbios and just have some basic build questions.
>>
>> 
>>
>>- how to care of the payload build error
> 
>  
> what build error?
> 
> 
>>- whether it be for etherboot or filo
> 
> 
> What's your question?
>  I applaud Alexander for helping you, but I also think that you need to do more work on your own to try and figure things out.

> 
>>any quick tips are appreciated, anything but rtfm
> 
> 
> try to be a bit more elaborate ;-)
> 
> http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
> http://www.catb.org/~esr/faqs/smart-questions.html#writewell
> 
> Stefan
> 
> 
> 



From Morales at appro.com  Fri Aug 19 20:54:38 2005
From: Morales at appro.com (Edwin Morales)
Date: Fri, 19 Aug 2005 11:54:38 -0700
Subject: [LinuxBIOS] newbie question of lb
Message-ID: <4B21D6C08BC8BA4A9530E43C980E58B01C35E0@hawk.appro.com>

just following the lb manual on amd64 .

when building the actual .rom file I get 
...'payloads/tg3--filo_hda2_vga.zelf'


regards,
--------
// ed
 
 

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Stefan Reinauer
Sent: Friday, August 19, 2005 11:33 AM
To: Edwin Morales
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] newbie question of lb

* Edwin Morales <Morales at appro.com> [050819 20:18]:
> hi all,
> 
> new to linuxbios and just have some basic build questions.
> 
>  
> 
> - how to care of the payload build error
 
what build error?

> - whether it be for etherboot or filo

What's your question?
 
> any quick tips are appreciated, anything but rtfm

try to be a bit more elaborate ;-)

http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
http://www.catb.org/~esr/faqs/smart-questions.html#writewell

Stefan



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




From stuge-linuxbios at cdy.org  Fri Aug 19 21:04:37 2005
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri, 19 Aug 2005 21:04:37 +0200
Subject: [LinuxBIOS] Using lilo
In-Reply-To: <8a0c367805081909173be2f6ec@mail.gmail.com>
References: <77ED2BF75D59D1439F90412CC5B10974230619D1@ie10-sahara.hiso.honeywell.com>
	<20050819103210.GA21590@openbios.org>
	<8a0c367805081909173be2f6ec@mail.gmail.com>
Message-ID: <20050819190437.4742.qmail@cdy.org>

On Fri, Aug 19, 2005 at 11:17:47AM -0500, Richard Smith wrote:
> I don't think I'd call Lilo obsolete yet.
> I use it in some embedded setups where the BIOS has issues with
> GRUB.

Call me conservative, but I use LILO everywhere. GRUB has caused me
nothing but trouble while LILO has worked flawlessly since that day
many years ago when I first started using it.


//Peter



From hamish at prodigi.ch  Fri Aug 19 23:04:40 2005
From: hamish at prodigi.ch (Hamish Guthrie)
Date: Fri, 19 Aug 2005 23:04:40 +0200
Subject: [LinuxBIOS] newbie question of lb
In-Reply-To: <4B21D6C08BC8BA4A9530E43C980E58B01C35E0@hawk.appro.com>
References: <4B21D6C08BC8BA4A9530E43C980E58B01C35E0@hawk.appro.com>
Message-ID: <43064968.70900@prodigi.ch>

So what???????????? --- there is not enough detail to even think about 
debugging


Edwin Morales wrote:
> just following the lb manual on amd64 .
> 
> when building the actual .rom file I get 
> ...'payloads/tg3--filo_hda2_vga.zelf'
> 
> 
> regards,
> --------
> // ed
>  
>  
> 
> -----Original Message-----
> From: linuxbios-bounces at openbios.org
> [mailto:linuxbios-bounces at openbios.org] On Behalf Of Stefan Reinauer
> Sent: Friday, August 19, 2005 11:33 AM
> To: Edwin Morales
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] newbie question of lb
> 
> * Edwin Morales <Morales at appro.com> [050819 20:18]:
> 
>>hi all,
>>
>>new to linuxbios and just have some basic build questions.
>>
>> 
>>
>>- how to care of the payload build error
> 
>  
> what build error?
> 
> 
>>- whether it be for etherboot or filo
> 
> 
> What's your question?
>  
> 
>>any quick tips are appreciated, anything but rtfm
> 
> 
> try to be a bit more elaborate ;-)
> 
> http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
> http://www.catb.org/~esr/faqs/smart-questions.html#writewell
> 
> Stefan
> 
> 
> 



From Morales at appro.com  Fri Aug 19 21:08:07 2005
From: Morales at appro.com (Edwin Morales)
Date: Fri, 19 Aug 2005 12:08:07 -0700
Subject: [LinuxBIOS] newbie question of lb
Message-ID: <4B21D6C08BC8BA4A9530E43C980E58B01C35E1@hawk.appro.com>

well it's looking for that file, so how is that built......

Regards,
--------
//  Ed
 
 

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Hamish Guthrie
Sent: Friday, August 19, 2005 2:05 PM
To: Edwin Morales
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] newbie question of lb

So what???????????? --- there is not enough detail to even think about 
debugging


Edwin Morales wrote:
> just following the lb manual on amd64 .
> 
> when building the actual .rom file I get 
> ...'payloads/tg3--filo_hda2_vga.zelf'
> 
> 
> regards,
> --------
> // ed
>  
>  
> 
> -----Original Message-----
> From: linuxbios-bounces at openbios.org
> [mailto:linuxbios-bounces at openbios.org] On Behalf Of Stefan Reinauer
> Sent: Friday, August 19, 2005 11:33 AM
> To: Edwin Morales
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] newbie question of lb
> 
> * Edwin Morales <Morales at appro.com> [050819 20:18]:
> 
>>hi all,
>>
>>new to linuxbios and just have some basic build questions.
>>
>> 
>>
>>- how to care of the payload build error
> 
>  
> what build error?
> 
> 
>>- whether it be for etherboot or filo
> 
> 
> What's your question?
>  
> 
>>any quick tips are appreciated, anything but rtfm
> 
> 
> try to be a bit more elaborate ;-)
> 
> http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
> http://www.catb.org/~esr/faqs/smart-questions.html#writewell
> 
> Stefan
> 
> 
> 

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




From mikey at wirelabs.net  Fri Aug 19 21:08:06 2005
From: mikey at wirelabs.net (Michal Szwaczko)
Date: Fri, 19 Aug 2005 21:08:06 +0200
Subject: [LinuxBIOS] Using lilo
In-Reply-To: <20050819190437.4742.qmail@cdy.org>
References: <77ED2BF75D59D1439F90412CC5B10974230619D1@ie10-sahara.hiso.honeywell.com>
	<20050819103210.GA21590@openbios.org>
	<8a0c367805081909173be2f6ec@mail.gmail.com>
	<20050819190437.4742.qmail@cdy.org>
Message-ID: <20050819190806.GA10773@tokyo>

On Fri, Aug 19, 2005 at 09:04:37PM +0200, Peter Stuge wrote:

> Call me conservative, but I use LILO everywhere. GRUB has caused me
> nothing but trouble while LILO has worked flawlessly since that day
> many years ago when I first started using it.

GRUB is much more flexible, and - if you read up a lot - it's easy.
I'd not say a word to you 2 years ago, because I was just that conservative 
and trusted lilo. Seems, the only hurdle was prejudice and wrong mindset
about GRUB. Since then, I use GRUB exclusively. So, maybe you should give it
a shot one more time. 

Regards,
-- 
[ .O. | Micha? 'Mikey' Szwaczko  | GPG Key#:0x653CBD53 ]
[ ..O | Developer/Troubleshooter | GNU Generation Now! ]
[ OOO | MSDOS is not dead. It just smells that way.    ]



From stepan at openbios.org  Fri Aug 19 21:13:36 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 19 Aug 2005 21:13:36 +0200
Subject: [LinuxBIOS] newbie question of lb
In-Reply-To: <4B21D6C08BC8BA4A9530E43C980E58B01C35E1@hawk.appro.com>
References: <4B21D6C08BC8BA4A9530E43C980E58B01C35E1@hawk.appro.com>
Message-ID: <20050819191336.GA24333@openbios.org>

* Edwin Morales <Morales at appro.com> [050819 21:08]:
> well it's looking for that file, so how is that built......
>  
> > when building the actual .rom file I get 
> > ...'payloads/tg3--filo_hda2_vga.zelf'

misleading, i read you got this file already.. 

compile etherboot from etherboot.org, and be sure to read the
configuration files and the documentation..

Stefan 





From hamish at prodigi.ch  Fri Aug 19 23:20:42 2005
From: hamish at prodigi.ch (Hamish Guthrie)
Date: Fri, 19 Aug 2005 23:20:42 +0200
Subject: [LinuxBIOS] newbie question of lb
In-Reply-To: <43064968.70900@prodigi.ch>
References: <4B21D6C08BC8BA4A9530E43C980E58B01C35E0@hawk.appro.com>
	<43064968.70900@prodigi.ch>
Message-ID: <43064D2A.9070107@prodigi.ch>

I am not sure if my previous post just failed to hit the net or what, 
but, to re-iterate!!!

Hi Edwin,

I am sending you a quotation from a very good member of the open source 
community - I do not want to detract from your question, at all, but 
some of Marty's suggestions are good value for money.

I quote my friend Marty Connor

"You need to do a better job asking for help.  You provide very little 
in the way of information, and then you literally beg for help.

If you are having trouble with a project, then at least demonstrate that 
you have read (or attempted to read) the documentation.  There is also a 
mailing list for help specifically with that software, if you can't 
figure out the documentation or examples.

Also, in debugging, you should attempt to create simple test cases, and 
when they fail, send input, output, and what you thought should happen 
to the appropriate list for analysis.  Otherwise, all we can do is guess 
what might be happening.

I want to encourage you to proceed, but I also want to strongly suggest 
that if you want help, you need to show that the time of the people 
trying to help you is not wasted.  You can do this by showing that 
progress you have made, by producing output, and explaining in more 
detail what you did.

If your English skills are a problem, please find a friend who has 
better skills, and have them help you, in exchange for help with 
something they need help with.

I hope you succeed, but even more I hope that in this process you 
develop better debugging skills, and improve your methods of asking for 
help."

Marty said it all. I think his advice is really good, and if you really 
want help, follow the above steps.

Hamish


Hamish Guthrie wrote:
> So what???????????? --- there is not enough detail to even think about 
> debugging
> 
> 
> Edwin Morales wrote:
> 
>> just following the lb manual on amd64 .
>>
>> when building the actual .rom file I get 
>> ...'payloads/tg3--filo_hda2_vga.zelf'
>>
>>
>> regards,
>> --------
>> // ed
>>  
>>  
>>
>> -----Original Message-----
>> From: linuxbios-bounces at openbios.org
>> [mailto:linuxbios-bounces at openbios.org] On Behalf Of Stefan Reinauer
>> Sent: Friday, August 19, 2005 11:33 AM
>> To: Edwin Morales
>> Cc: linuxbios at openbios.org
>> Subject: Re: [LinuxBIOS] newbie question of lb
>>
>> * Edwin Morales <Morales at appro.com> [050819 20:18]:
>>
>>> hi all,
>>>
>>> new to linuxbios and just have some basic build questions.
>>>
>>>
>>>
>>> - how to care of the payload build error
>>
>>
>>  
>> what build error?
>>
>>
>>> - whether it be for etherboot or filo
>>
>>
>>
>> What's your question?
>>  
>>
>>> any quick tips are appreciated, anything but rtfm
>>
>>
>>
>> try to be a bit more elaborate ;-)
>>
>> http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
>> http://www.catb.org/~esr/faqs/smart-questions.html#writewell
>>
>> Stefan
>>
>>
>>
> 



From Morales at appro.com  Fri Aug 19 21:33:54 2005
From: Morales at appro.com (Edwin Morales)
Date: Fri, 19 Aug 2005 12:33:54 -0700
Subject: [LinuxBIOS] newbie question of lb
Message-ID: <4B21D6C08BC8BA4A9530E43C980E58B01C35E4@hawk.appro.com>

sorry for the misleading information, my 'question asking skills' needs
much improvement

i'll check out etherboot.org

Regards,
--------
//  Ed 
 
 

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Friday, August 19, 2005 12:14 PM
To: Edwin Morales
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] newbie question of lb

* Edwin Morales <Morales at appro.com> [050819 21:08]:
> well it's looking for that file, so how is that built......
>  
> > when building the actual .rom file I get 
> > ...'payloads/tg3--filo_hda2_vga.zelf'

misleading, i read you got this file already.. 

compile etherboot from etherboot.org, and be sure to read the
configuration files and the documentation..

Stefan 






From stuge-linuxbios at cdy.org  Fri Aug 19 22:22:42 2005
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri, 19 Aug 2005 22:22:42 +0200
Subject: [LinuxBIOS] Using lilo
In-Reply-To: <20050819190806.GA10773@tokyo>
References: <77ED2BF75D59D1439F90412CC5B10974230619D1@ie10-sahara.hiso.honeywell.com>
	<20050819103210.GA21590@openbios.org>
	<8a0c367805081909173be2f6ec@mail.gmail.com>
	<20050819190437.4742.qmail@cdy.org> <20050819190806.GA10773@tokyo>
Message-ID: <20050819202242.3782.qmail@cdy.org>

On Fri, Aug 19, 2005 at 09:08:06PM +0200, Michal Szwaczko wrote:
> GRUB is much more flexible, and - if you read up a lot - it's easy.

I have had it set up on a couple of different systems and I think one
customer still has it, and configuration isn't the problem, while I
think it's totally stupid to invent a new naming scheme where a
common one already exists I don't have a problem adapting to it, but
my issues have been with reliability.


> I'd not say a word to you 2 years ago, because I was just that
> conservative and trusted lilo. Seems, the only hurdle was prejudice
> and wrong mindset about GRUB. Since then, I use GRUB exclusively.

I've tried it, so strike prejudice, but wrong mindset I'll admit to.
:)

The problem I had with reliability came from the fact that GRUB stage
1 loads stage 1.5 from fs, and if that fs got corrupted no OS could
be booted at all. I had to replace GRUB with MBR from DOS6 over the
phone with one person.


> So, maybe you should give it a shot one more time.

Some time, I surely will.


//Peter



From adam at cfar.umd.edu  Fri Aug 19 22:29:07 2005
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Fri, 19 Aug 2005 16:29:07 -0400 (EDT)
Subject: [LinuxBIOS] Using lilo
In-Reply-To: <8a0c367805081909173be2f6ec@mail.gmail.com>
References: <77ED2BF75D59D1439F90412CC5B10974230619D1@ie10-sahara.hiso.honeywell.com>
	<20050819103210.GA21590@openbios.org>
	<8a0c367805081909173be2f6ec@mail.gmail.com>
Message-ID: <Pine.BSF.4.62.0508191627560.13266@www.missl.cs.umd.edu>

>>> How do I use LILO to boot windows 2k?
>>
>> The usual way is to use either NTLDR or grub. Lilo is obsolete.
>>
>
> IIRC I don't think grub works under the Bochs copy in LinuxBios but
> its been awhile.  Adam?

looking at :

http://www.usenix.org/events/usenix03/tech/freenix03/agnew/agnew_html/

seems it was grub, but it mentions lilo would work too.




From smithbone at gmail.com  Fri Aug 19 22:50:13 2005
From: smithbone at gmail.com (Richard Smith)
Date: Fri, 19 Aug 2005 15:50:13 -0500
Subject: [LinuxBIOS] Using lilo
In-Reply-To: <Pine.BSF.4.62.0508191627560.13266@www.missl.cs.umd.edu>
References: <77ED2BF75D59D1439F90412CC5B10974230619D1@ie10-sahara.hiso.honeywell.com>
	<20050819103210.GA21590@openbios.org>
	<8a0c367805081909173be2f6ec@mail.gmail.com>
	<Pine.BSF.4.62.0508191627560.13266@www.missl.cs.umd.edu>
Message-ID: <8a0c36780508191350644c1101@mail.gmail.com>

> looking at :
> 
> http://www.usenix.org/events/usenix03/tech/freenix03/agnew/agnew_html/
> 
> seems it was grub, but it mentions lilo would work too.

Ah.. Ok.  I've got my wires crossed then.  Thinking on it a bit more I
believe its tinybios for the STPC that has the issue with grub.

-- 
Richard A. Smith



From yinghailu at gmail.com  Sat Aug 20 00:46:15 2005
From: yinghailu at gmail.com (yhlu)
Date: Fri, 19 Aug 2005 15:46:15 -0700
Subject: [LinuxBIOS] newbie question of lb
In-Reply-To: <4B21D6C08BC8BA4A9530E43C980E58B01C35E4@hawk.appro.com>
References: <4B21D6C08BC8BA4A9530E43C980E58B01C35E4@hawk.appro.com>
Message-ID: <2ea3fae105081915465681c0e8@mail.gmail.com>

http://www.linuxbios.org/index.php/Etherboot

YH

On 8/19/05, Edwin Morales <Morales at appro.com> wrote:
> sorry for the misleading information, my 'question asking skills' needs
> much improvement
> 
> i'll check out etherboot.org
> 
> Regards,
> --------
> //  Ed
> 
> 
> 
> -----Original Message-----
> From: Stefan Reinauer [mailto:stepan at openbios.org]
> Sent: Friday, August 19, 2005 12:14 PM
> To: Edwin Morales
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] newbie question of lb
> 
> * Edwin Morales <Morales at appro.com> [050819 21:08]:
> > well it's looking for that file, so how is that built......
> >
> > > when building the actual .rom file I get
> > > ...'payloads/tg3--filo_hda2_vga.zelf'
> 
> misleading, i read you got this file already..
> 
> compile etherboot from etherboot.org, and be sure to read the
> configuration files and the documentation..
> 
> Stefan
> 
> 
> 
> 
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From miernik at ffii.org  Sat Aug 20 08:17:35 2005
From: miernik at ffii.org (Miernik)
Date: Sat, 20 Aug 2005 08:17:35 +0200
Subject: [LinuxBIOS] can an Athlon64 work on a Tyan Tomcat K8S (S2850 G2N)
	board?
Message-ID: <20050820061735.3750.2.NOFFLE@localhost.localdomain.local>

Will Athlon64 CPUs work on a Tyan Tomcat K8S (S2850 G2N) motherboard and
will LinuxBIOS work in that configuration?

-- 
Miernik             _________________________  xmpp:miernik at amessage.info
___________________/_______________________/      mailto:miernik at ffii.org
Protect Europe from a legal disaster. Petition against software patents
http://www.noepatents.org/index_html?LANG=en




From yinghailu at gmail.com  Sat Aug 20 12:11:38 2005
From: yinghailu at gmail.com (yhlu)
Date: Sat, 20 Aug 2005 03:11:38 -0700
Subject: [LinuxBIOS] can an Athlon64 work on a Tyan Tomcat K8S (S2850 G2N)
	board?
In-Reply-To: <20050820061735.3750.2.NOFFLE@localhost.localdomain.local>
References: <20050820061735.3750.2.NOFFLE@localhost.localdomain.local>
Message-ID: <2ea3fae105082003111e748362@mail.gmail.com>

s2850 only support Opteron. LinuxBIOS support for s2850 is in the public tree.
http://www.linuxbios.org/index.php/Supported_Motherboards

YH

On 8/19/05, Miernik <miernik at ffii.org> wrote:
> Will Athlon64 CPUs work on a Tyan Tomcat K8S (S2850 G2N) motherboard and
> will LinuxBIOS work in that configuration?
> 
> --
> Miernik             _________________________  xmpp:miernik at amessage.info
> ___________________/_______________________/      mailto:miernik at ffii.org
> Protect Europe from a legal disaster. Petition against software patents
> http://www.noepatents.org/index_html?LANG=en
> 
> 
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



From miernik at ffii.org  Sat Aug 20 12:40:57 2005
From: miernik at ffii.org (Miernik)
Date: Sat, 20 Aug 2005 12:40:57 +0200
Subject: [LinuxBIOS] Re: can an Athlon64 work on a Tyan Tomcat K8S (S2850
	G2N) board?
References: <20050820061735.3750.2.NOFFLE@localhost.localdomain.local>
	<2ea3fae105082003111e748362@mail.gmail.com>
Message-ID: <20050820104057.3750.3.NOFFLE@localhost.localdomain.local>

yhlu <yinghailu at gmail.com> wrote:
> s2850 only support Opteron. LinuxBIOS support for s2850 is in the
> public tree.

So which LinuxBIOS supported Tyan motherboard support Athlon64 CPU?
Opterons are very expensive.

-- 
Miernik             _________________________  xmpp:miernik at amessage.info
___________________/_______________________/      mailto:miernik at ffii.org
                       Save Europe from Software Patents
                http://www.gnu.org/philosophy/savingeurope.html




From Narahari.Narasimhaiah at honeywell.com  Mon Aug 22 07:40:16 2005
From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10))
Date: Sun, 21 Aug 2005 22:40:16 -0700
Subject: [LinuxBIOS] RE: LinuxBIOS Digest, Vol 6, Issue 31
Message-ID: <77ED2BF75D59D1439F90412CC5B1097423216627@ie10-sahara.hiso.honeywell.com>

Hi,

Did Any body face problems using nt-loader to boot Windows 2K?

With regards,
narahari 

-----Original Message-----
From: linuxbios-bounces at openbios.org [mailto:linuxbios-bounces at openbios.org]
On Behalf Of linuxbios-request at openbios.org
Sent: Saturday, August 20, 2005 12:11 PM
To: linuxbios at openbios.org
Subject: LinuxBIOS Digest, Vol 6, Issue 31

Send LinuxBIOS mailing list submissions to
	linuxbios at openbios.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.openbios.org/mailman/listinfo/linuxbios
or, via email, send a message with subject or body 'help' to
	linuxbios-request at openbios.org

You can reach the person managing the list at
	linuxbios-owner at openbios.org

When replying, please edit your Subject line so it is more specific than
"Re: Contents of LinuxBIOS digest..."


Today's Topics:

   1. RE: newbie question of lb (Edwin Morales)
   2. Re: Using lilo (Michal Szwaczko)
   3. Re: newbie question of lb (Stefan Reinauer)
   4. Re: newbie question of lb (Hamish Guthrie)
   5. RE: newbie question of lb (Edwin Morales)
   6. Re: Using lilo (Peter Stuge)
   7. Re: Using lilo (Adam Sulmicki)
   8. Re: Using lilo (Richard Smith)
   9. Re: newbie question of lb (yhlu)
  10. can an Athlon64 work on a Tyan Tomcat K8S (S2850 G2N)	board?
      (Miernik)


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

Message: 1
Date: Fri, 19 Aug 2005 12:08:07 -0700
From: "Edwin Morales" <Morales at appro.com>
Subject: RE: [LinuxBIOS] newbie question of lb
To: <hamish at prodigi.ch>
Cc: linuxbios at openbios.org
Message-ID: <4B21D6C08BC8BA4A9530E43C980E58B01C35E1 at hawk.appro.com>
Content-Type: text/plain;	charset="us-ascii"

well it's looking for that file, so how is that built......

Regards,
--------
//  Ed
 
 

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Hamish Guthrie
Sent: Friday, August 19, 2005 2:05 PM
To: Edwin Morales
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] newbie question of lb

So what???????????? --- there is not enough detail to even think about
debugging


Edwin Morales wrote:
> just following the lb manual on amd64 .
> 
> when building the actual .rom file I get 
> ...'payloads/tg3--filo_hda2_vga.zelf'
> 
> 
> regards,
> --------
> // ed
>  
>  
> 
> -----Original Message-----
> From: linuxbios-bounces at openbios.org
> [mailto:linuxbios-bounces at openbios.org] On Behalf Of Stefan Reinauer
> Sent: Friday, August 19, 2005 11:33 AM
> To: Edwin Morales
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] newbie question of lb
> 
> * Edwin Morales <Morales at appro.com> [050819 20:18]:
> 
>>hi all,
>>
>>new to linuxbios and just have some basic build questions.
>>
>> 
>>
>>- how to care of the payload build error
> 
>  
> what build error?
> 
> 
>>- whether it be for etherboot or filo
> 
> 
> What's your question?
>  
> 
>>any quick tips are appreciated, anything but rtfm
> 
> 
> try to be a bit more elaborate ;-)
> 
> http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
> http://www.catb.org/~esr/faqs/smart-questions.html#writewell
> 
> Stefan
> 
> 
> 

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




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

Message: 2
Date: Fri, 19 Aug 2005 21:08:06 +0200
From: Michal Szwaczko <mikey at wirelabs.net>
Subject: Re: [LinuxBIOS] Using lilo
To: Peter Stuge <stuge-linuxbios at cdy.org>
Cc: linuxbios at openbios.org
Message-ID: <20050819190806.GA10773 at tokyo>
Content-Type: text/plain; charset=iso-8859-2

On Fri, Aug 19, 2005 at 09:04:37PM +0200, Peter Stuge wrote:

> Call me conservative, but I use LILO everywhere. GRUB has caused me
> nothing but trouble while LILO has worked flawlessly since that day
> many years ago when I first started using it.

GRUB is much more flexible, and - if you read up a lot - it's easy.
I'd not say a word to you 2 years ago, because I was just that conservative 
and trusted lilo. Seems, the only hurdle was prejudice and wrong mindset
about GRUB. Since then, I use GRUB exclusively. So, maybe you should give it
a shot one more time. 

Regards,
-- 
[ .O. | Micha? 'Mikey' Szwaczko  | GPG Key#:0x653CBD53 ]
[ ..O | Developer/Troubleshooter | GNU Generation Now! ]
[ OOO | MSDOS is not dead. It just smells that way.    ]



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

Message: 3
Date: Fri, 19 Aug 2005 21:13:36 +0200
From: Stefan Reinauer <stepan at openbios.org>
Subject: Re: [LinuxBIOS] newbie question of lb
To: Edwin Morales <Morales at appro.com>
Cc: linuxbios at openbios.org
Message-ID: <20050819191336.GA24333 at openbios.org>
Content-Type: text/plain; charset=us-ascii

* Edwin Morales <Morales at appro.com> [050819 21:08]:
> well it's looking for that file, so how is that built......
>  
> > when building the actual .rom file I get 
> > ...'payloads/tg3--filo_hda2_vga.zelf'

misleading, i read you got this file already.. 

compile etherboot from etherboot.org, and be sure to read the
configuration files and the documentation..

Stefan 





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

Message: 4
Date: Fri, 19 Aug 2005 23:20:42 +0200
From: Hamish Guthrie <hamish at prodigi.ch>
Subject: Re: [LinuxBIOS] newbie question of lb
To: hamish at prodigi.ch
Cc: linuxbios at openbios.org, Edwin Morales <Morales at appro.com>
Message-ID: <43064D2A.9070107 at prodigi.ch>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I am not sure if my previous post just failed to hit the net or what, 
but, to re-iterate!!!

Hi Edwin,

I am sending you a quotation from a very good member of the open source 
community - I do not want to detract from your question, at all, but 
some of Marty's suggestions are good value for money.

I quote my friend Marty Connor

"You need to do a better job asking for help.  You provide very little 
in the way of information, and then you literally beg for help.

If you are having trouble with a project, then at least demonstrate that 
you have read (or attempted to read) the documentation.  There is also a 
mailing list for help specifically with that software, if you can't 
figure out the documentation or examples.

Also, in debugging, you should attempt to create simple test cases, and 
when they fail, send input, output, and what you thought should happen 
to the appropriate list for analysis.  Otherwise, all we can do is guess 
what might be happening.

I want to encourage you to proceed, but I also want to strongly suggest 
that if you want help, you need to show that the time of the people 
trying to help you is not wasted.  You can do this by showing that 
progress you have made, by producing output, and explaining in more 
detail what you did.

If your English skills are a problem, please find a friend who has 
better skills, and have them help you, in exchange for help with 
something they need help with.

I hope you succeed, but even more I hope that in this process you 
develop better debugging skills, and improve your methods of asking for 
help."

Marty said it all. I think his advice is really good, and if you really 
want help, follow the above steps.

Hamish


Hamish Guthrie wrote:
> So what???????????? --- there is not enough detail to even think about 
> debugging
> 
> 
> Edwin Morales wrote:
> 
>> just following the lb manual on amd64 .
>>
>> when building the actual .rom file I get 
>> ...'payloads/tg3--filo_hda2_vga.zelf'
>>
>>
>> regards,
>> --------
>> // ed
>>  
>>  
>>
>> -----Original Message-----
>> From: linuxbios-bounces at openbios.org
>> [mailto:linuxbios-bounces at openbios.org] On Behalf Of Stefan Reinauer
>> Sent: Friday, August 19, 2005 11:33 AM
>> To: Edwin Morales
>> Cc: linuxbios at openbios.org
>> Subject: Re: [LinuxBIOS] newbie question of lb
>>
>> * Edwin Morales <Morales at appro.com> [050819 20:18]:
>>
>>> hi all,
>>>
>>> new to linuxbios and just have some basic build questions.
>>>
>>>
>>>
>>> - how to care of the payload build error
>>
>>
>>  
>> what build error?
>>
>>
>>> - whether it be for etherboot or filo
>>
>>
>>
>> What's your question?
>>  
>>
>>> any quick tips are appreciated, anything but rtfm
>>
>>
>>
>> try to be a bit more elaborate ;-)
>>
>> http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
>> http://www.catb.org/~esr/faqs/smart-questions.html#writewell
>>
>> Stefan
>>
>>
>>
> 



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

Message: 5
Date: Fri, 19 Aug 2005 12:33:54 -0700
From: "Edwin Morales" <Morales at appro.com>
Subject: RE: [LinuxBIOS] newbie question of lb
To: "Stefan Reinauer" <stepan at openbios.org>
Cc: linuxbios at openbios.org
Message-ID: <4B21D6C08BC8BA4A9530E43C980E58B01C35E4 at hawk.appro.com>
Content-Type: text/plain;	charset="us-ascii"

sorry for the misleading information, my 'question asking skills' needs
much improvement

i'll check out etherboot.org

Regards,
--------
//  Ed 
 
 

-----Original Message-----
From: Stefan Reinauer [mailto:stepan at openbios.org] 
Sent: Friday, August 19, 2005 12:14 PM
To: Edwin Morales
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] newbie question of lb

* Edwin Morales <Morales at appro.com> [050819 21:08]:
> well it's looking for that file, so how is that built......
>  
> > when building the actual .rom file I get 
> > ...'payloads/tg3--filo_hda2_vga.zelf'

misleading, i read you got this file already.. 

compile etherboot from etherboot.org, and be sure to read the
configuration files and the documentation..

Stefan 






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

Message: 6
Date: Fri, 19 Aug 2005 22:22:42 +0200
From: Peter Stuge <stuge-linuxbios at cdy.org>
Subject: Re: [LinuxBIOS] Using lilo
To: linuxbios at openbios.org
Message-ID: <20050819202242.3782.qmail at cdy.org>
Content-Type: text/plain; charset=us-ascii

On Fri, Aug 19, 2005 at 09:08:06PM +0200, Michal Szwaczko wrote:
> GRUB is much more flexible, and - if you read up a lot - it's easy.

I have had it set up on a couple of different systems and I think one
customer still has it, and configuration isn't the problem, while I
think it's totally stupid to invent a new naming scheme where a
common one already exists I don't have a problem adapting to it, but
my issues have been with reliability.


> I'd not say a word to you 2 years ago, because I was just that
> conservative and trusted lilo. Seems, the only hurdle was prejudice
> and wrong mindset about GRUB. Since then, I use GRUB exclusively.

I've tried it, so strike prejudice, but wrong mindset I'll admit to.
:)

The problem I had with reliability came from the fact that GRUB stage
1 loads stage 1.5 from fs, and if that fs got corrupted no OS could
be booted at all. I had to replace GRUB with MBR from DOS6 over the
phone with one person.


> So, maybe you should give it a shot one more time.

Some time, I surely will.


//Peter



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

Message: 7
Date: Fri, 19 Aug 2005 16:29:07 -0400 (EDT)
From: Adam Sulmicki <adam at cfar.umd.edu>
Subject: Re: [LinuxBIOS] Using lilo
To: Richard Smith <smithbone at gmail.com>
Cc: LinuxBIOS <linuxbios at openbios.org>
Message-ID: <Pine.BSF.4.62.0508191627560.13266 at www.missl.cs.umd.edu>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

>>> How do I use LILO to boot windows 2k?
>>
>> The usual way is to use either NTLDR or grub. Lilo is obsolete.
>>
>
> IIRC I don't think grub works under the Bochs copy in LinuxBios but
> its been awhile.  Adam?

looking at :

http://www.usenix.org/events/usenix03/tech/freenix03/agnew/agnew_html/

seems it was grub, but it mentions lilo would work too.




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

Message: 8
Date: Fri, 19 Aug 2005 15:50:13 -0500
From: Richard Smith <smithbone at gmail.com>
Subject: Re: [LinuxBIOS] Using lilo
To: Adam Sulmicki <adam at cfar.umd.edu>
Cc: LinuxBIOS <linuxbios at openbios.org>
Message-ID: <8a0c36780508191350644c1101 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

> looking at :
> 
> http://www.usenix.org/events/usenix03/tech/freenix03/agnew/agnew_html/
> 
> seems it was grub, but it mentions lilo would work too.

Ah.. Ok.  I've got my wires crossed then.  Thinking on it a bit more I
believe its tinybios for the STPC that has the issue with grub.

-- 
Richard A. Smith



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

Message: 9
Date: Fri, 19 Aug 2005 15:46:15 -0700
From: yhlu <yinghailu at gmail.com>
Subject: Re: [LinuxBIOS] newbie question of lb
To: Edwin Morales <Morales at appro.com>
Cc: linuxbios at openbios.org
Message-ID: <2ea3fae105081915465681c0e8 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

http://www.linuxbios.org/index.php/Etherboot

YH

On 8/19/05, Edwin Morales <Morales at appro.com> wrote:
> sorry for the misleading information, my 'question asking skills' needs
> much improvement
> 
> i'll check out etherboot.org
> 
> Regards,
> --------
> //  Ed
> 
> 
> 
> -----Original Message-----
> From: Stefan Reinauer [mailto:stepan at openbios.org]
> Sent: Friday, August 19, 2005 12:14 PM
> To: Edwin Morales
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] newbie question of lb
> 
> * Edwin Morales <Morales at appro.com> [050819 21:08]:
> > well it's looking for that file, so how is that built......
> >
> > > when building the actual .rom file I get
> > > ...'payloads/tg3--filo_hda2_vga.zelf'
> 
> misleading, i read you got this file already..
> 
> compile etherboot from etherboot.org, and be sure to read the
> configuration files and the documentation..
> 
> Stefan
> 
> 
> 
> 
> --
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>



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

Message: 10
Date: Sat, 20 Aug 2005 08:17:35 +0200
From: Miernik <miernik at ffii.org>
Subject: [LinuxBIOS] can an Athlon64 work on a Tyan Tomcat K8S (S2850
	G2N)	board?
To: linuxbios at openbios.org
Message-ID: <20050820061735.3750.2.NOFFLE at localhost.localdomain.local>

Will Athlon64 CPUs work on a Tyan Tomcat K8S (S2850 G2N) motherboard and
will LinuxBIOS work in that configuration?

-- 
Miernik             _________________________  xmpp:miernik at amessage.info
___________________/_______________________/      mailto:miernik at ffii.org
Protect Europe from a legal disaster. Petition against software patents
http://www.noepatents.org/index_html?LANG=en




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

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

End of LinuxBIOS Digest, Vol 6, Issue 31
****************************************



From smithbone at gmail.com  Mon Aug 22 09:34:55 2005
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 22 Aug 2005 02:34:55 -0500
Subject: Win2k booting was. Re: [LinuxBIOS] RE: LinuxBIOS Digest, Vol 6,
	Issue 31
In-Reply-To: <77ED2BF75D59D1439F90412CC5B1097423216627@ie10-sahara.hiso.honeywell.com>
References: <77ED2BF75D59D1439F90412CC5B1097423216627@ie10-sahara.hiso.honeywell.com>
Message-ID: <8a0c36780508220034360c655c@mail.gmail.com>

> 
> Did Any body face problems using nt-loader to boot Windows 2K?
> 
> With regards,
> narahari

Narahari,

First:  Please take the time to add a proper subject and trim your
message.  You replied to a digest and included the _entire_ digest. 
If you can't take the time and effort to format your message nicely
then most lists will not take the time to respond to you.

Re: your post. Most of the developers here are booting linux OS's so
you are not going to get much help unless you are pretty specific
about what problem you are seeing.  I think only about 5 of us or so
have messed with using ADLO and bochs bios to boot MS stuff.

You may also have to seek the help of the bochs people but again you
will need to provide more detail.  Ie.  What bios interrupt(s) you
think may not be working and what you have tried.  If you look at the
wiki there are links to a write up for the sucessful booting of w2k
from the author of ADLO.  Perhaps it has the info you seek.

-- 
Richard A. Smith



From ivan at logikom.net  Mon Aug 22 15:48:37 2005
From: ivan at logikom.net (ivan at logikom.net)
Date: Mon, 22 Aug 2005 15:48:37 +0200 (CEST)
Subject: [LinuxBIOS] LinuxBIOS
Message-ID: <3739.213.244.239.7.1124718517.squirrel@webmail.logikom.net>

Hi,
is it possible to install LinuxBIOS on Wyse WinTerm 3360SE (Geode CS5530,
Winbond W29C020C) and, if it is, where i can find necessary files (i tried
on
http://umn.dl.sourceforge.net/sourceforge/freebios/freebios-20010708.tar.gz
, but i couldn't find sources for this chipset)

Thanx,
Ivan.




From smithbone at gmail.com  Mon Aug 22 15:56:40 2005
From: smithbone at gmail.com (Richard Smith)
Date: Mon, 22 Aug 2005 08:56:40 -0500
Subject: [LinuxBIOS] LinuxBIOS
In-Reply-To: <3739.213.244.239.7.1124718517.squirrel@webmail.logikom.net>
References: <3739.213.244.239.7.1124718517.squirrel@webmail.logikom.net>
Message-ID: <8a0c36780508220656697e81d5@mail.gmail.com>

> is it possible to install LinuxBIOS on Wyse WinTerm 3360SE (Geode CS5530,
> Winbond W29C020C) and, if it is, where i can find necessary files (i tried

I think somebody is working on that chipset don't know if its fully
functional though.

> http://umn.dl.sourceforge.net/sourceforge/freebios/freebios-20010708.tar.gz
> , but i couldn't find sources for this chipset)

That's a way old snapshot. Try this instead.

http://linuxbios.org/index.php/Download_LinuxBIOS

-- 
Richard A. Smith



From a.borisov at tesv.tmb.ru  Mon Aug 22 16:00:04 2005
From: a.borisov at tesv.tmb.ru (Anton Borisov)
Date: Mon, 22 Aug 2005 18:00:04 +0400
Subject: [LinuxBIOS] LinuxBIOS
In-Reply-To: <3739.213.244.239.7.1124718517.squirrel@webmail.logikom.net>
References: <3739.213.244.239.7.1124718517.squirrel@webmail.logikom.net>
Message-ID: <20050822180004.08c533ff.a.borisov@tesv.tmb.ru>

On Mon, 22 Aug 2005 15:48:37 +0200 (CEST)
ivan at logikom.net wrote:

> Hi,
> is it possible to install LinuxBIOS on Wyse WinTerm 3360SE (Geode CS5530,
> Winbond W29C020C) and, if it is, where i can find necessary files (i tried
> on
> http://umn.dl.sourceforge.net/sourceforge/freebios/freebios-20010708.tar.gz
> , but i couldn't find sources for this chipset)

	why not use snapshots from http://snapshots.linuxbios.info?


-- 
Sincerely, Anton Borisov



From bchafy at ccs.neu.edu  Mon Aug 22 19:19:31 2005
From: bchafy at ccs.neu.edu (Bryan E. Chafy)
Date: Mon, 22 Aug 2005 13:19:31 -0400 (EDT)
Subject: [LinuxBIOS] LinuxBIOS
In-Reply-To: <3739.213.244.239.7.1124718517.squirrel@webmail.logikom.net> from
	"ivan@logikom.net" at Aug 22, 2005 03:48:37 PM
Message-ID: <E1E7FxL-0000MK-4o@denali.ccs.neu.edu>


Id be interested in knowing how far you get with this.

Ive got a couple of these, a 3350 and a t1010 (compaq variant of the 3360se).
As far as I know, nobody has been successful getting linux to completely
boot, but some have gotten very close.
Its a mostly standard gxm/geode design with extra flash, so the geode
code in LB ought to work.  You'll need a laplink cable
and some software if you flash onboard (ie not the hotflash method).

Here's some links:
http://www.ussg.iu.edu/hypermail/linux/kernel/0504.3/0926.html
http://winterm.gaast.net/main.php/intro.html
http://winterm.gaast.net/downloads/ for the software
you'll also need xfer.exe from wyse.

The cardbus bridge might cause trouble if you have a "WYSE Shamrock" 
chipset.  Im unsure what if any documentation there is on it.
(my 3350 uses a common TI bridge, the t1010 has the shamrock).
There's also a Lattice GAL soldered on there somewhere which could be
anything.




From stepan at openbios.org  Mon Aug 22 23:32:42 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon, 22 Aug 2005 23:32:42 +0200
Subject: [LinuxBIOS] LinuxBIOS
In-Reply-To: <20050822180004.08c533ff.a.borisov@tesv.tmb.ru>
References: <3739.213.244.239.7.1124718517.squirrel@webmail.logikom.net>
	<20050822180004.08c533ff.a.borisov@tesv.tmb.ru>
Message-ID: <20050822213242.GA9228@openbios.org>

* Anton Borisov <a.borisov at tesv.tmb.ru> [050822 16:00]:
> On Mon, 22 Aug 2005 15:48:37 +0200 (CEST)
> ivan at logikom.net wrote:
> 
> > Hi,
> > is it possible to install LinuxBIOS on Wyse WinTerm 3360SE (Geode CS5530,
> > Winbond W29C020C) and, if it is, where i can find necessary files (i tried
> > on
> > http://umn.dl.sourceforge.net/sourceforge/freebios/freebios-20010708.tar.gz
> > , but i couldn't find sources for this chipset)
> 
> 	why not use snapshots from http://snapshots.linuxbios.info?

It's http://snapshots.linuxbios.org/

future snapshots will come with commit log and build log..

Stefan





From wes.parish at paradise.net.nz  Tue Aug 23 10:51:25 2005
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Tue, 23 Aug 2005 20:51:25 +1200
Subject: [LinuxBIOS] Possibly OT, but wotthehell - restricted memory C code
Message-ID: <200508232051.26820.wes.parish@paradise.net.nz>

I came across the LinuxBIOS articles in LinuxJournal and got interested in the 
description of romcc and what it did.

Are there any books, articles, etc, (either C or Assembler) on writing code 
for a memory space as restricted and/or non-existent as romcc was written to 
handle?

Thanks

Wesley Parish
-- 
Clinersterton beademung, with all of love - RIP James Blish
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.



From avatarofvirgo at gmail.com  Wed Aug 24 07:41:17 2005
From: avatarofvirgo at gmail.com (Nathaniel Dube)
Date: Wed, 24 Aug 2005 00:41:17 -0500
Subject: [LinuxBIOS] Open Gaming Console
Message-ID: <200508240041.35258.AvatarofVirgo@gmail.com>

Has any one ever thought of making a gaming console using LinuxBIOS?  I would 
like to put one together using open standard hardware and with a linux based 
OS.

The goal, to create a openstandard/opensource game console.  Then game 
companies can make games for low prices since this system doesn't have to 
deal in royalties.

I hear the Xbox360 will be around $300 and the games $60.  I think that's 
complete bull spit.  I think it's time for people in the Linux world to make 
our own game console.

We made a operating system as an alternative to Windows now it's time to do 
the same with their game console.

We gave the computer world freedom now lets give the gaming world freedom so 
junior (as well as adults) aren't spending arm and leg for games, consoles 
and other parts.

It's not just money I want people to save but to give them back freedom in the 
technology they use.

The hardware side of this project is easy.  The hard part is putting together 
a small Linux OS for it and customizing LinuxBIOS for this kind of system.  
If any one wants to start such project let me know.  All I have are ideas, 
what I don't have is the knowledge to pull this off.

Which is why I need some of you talented people to help me start a project to 
pull this off.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050824/d9624a3f/attachment.sig>

From smithbone at gmail.com  Wed Aug 24 08:22:05 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 24 Aug 2005 01:22:05 -0500
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <200508240041.35258.AvatarofVirgo@gmail.com>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
Message-ID: <8a0c36780508232322699e4ae3@mail.gmail.com>

> The hardware side of this project is easy.  The hard part is putting together
> a small Linux OS for it and customizing LinuxBIOS for this kind of system.
> If any one wants to start such project let me know.  All I have are ideas,
> what I don't have is the knowledge to pull this off.

What hardware do you have in mind?  To me the software of this
actually seems like the easy part.  There are loads of ways to make a
small customized linux image.

http://www.emdebian.org/
http://familiar.handhelds.org/
http://www.linuxfromscratch.org/
http://openwrt.org/
http://www.damnsmalllinux.org/
http://www.pengutronix.de/software/ptxdist_en.html

Just to get started....

Not quite so small but has loads of stuff you would need..

http://www.geexbox.org/en/index.html

Horsepower wise though you are really going to have some beef to
compete with the graphics power of the Xbox or ps2 line of products. 
That means the later nvidia or ATI cards.

A gaming console is also going to need some sort of low noise, smaller
type case setup.

Neither of the above is cheap.  $300 is a would be a pretty good deal
for what you get if it wern't for the stupid DRM they use.  Although I
think ps2 has linux dev kit for it dosen't it?

-- 
Richard A. Smith



From avatarofvirgo at gmail.com  Wed Aug 24 09:11:28 2005
From: avatarofvirgo at gmail.com (Nathaniel Dube)
Date: Wed, 24 Aug 2005 02:11:28 -0500
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <8a0c36780508232322699e4ae3@mail.gmail.com>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
	<8a0c36780508232322699e4ae3@mail.gmail.com>
Message-ID: <200508240211.36580.AvatarofVirgo@gmail.com>

On Wednesday 24 August 2005 01:22 am, Richard Smith wrote:
> What hardware do you have in mind?

I'd like it to be designed so any retail hardware off the shelf will do, but 
if we are to start a small business making these things I would try the best 
I can to make something that would cost less then say current game consoles.  
So any hardware that would accomplish this would work.  I don't remember what 
the current XBOX cost, around $150 I think.  The XBOX360 I belive is going to 
be close to $300 when it comes out.  So it has to be hardware that would keep 
the over all price below the current consoles.

After all we wouldn't want to build a system that cost more then the xbox360, 
then people will get this idea that Linux systems are more expensive then MS 
systems.  We need to build something that says "Linux saves people money."

> To me the software of this 
> actually seems like the easy part.  There are loads of ways to make a
> small customized linux image.
>
> http://www.emdebian.org/
> http://familiar.handhelds.org/
> http://www.linuxfromscratch.org/
> http://openwrt.org/
> http://www.damnsmalllinux.org/
> http://www.pengutronix.de/software/ptxdist_en.html

It's easy when you know how. ;)  I've still a Linux newbie my self.  As of now 
I don't have the current knowledge to build a brand new Linux Distro from 
scratch.   But I will look at those links.  If you ever played with an Xbox 
you'll know that when you turn it on it loads to it's menu (with no game in 
it) pretty quick.  Which made me think to use LinuxBIOS.  Current BIOS 
wouldn't be able to pull this off.  When you put a game in the xbox it loads 
up right away.  no installing any thing except if you forgot to plug in your 
controller.  I want to build a open gaming system with the same principles of 
user friendlyness.  Many people have hacked the xbox to install a custom 
linux distro onto the xbox by replacing the "xbox live" menu entry with a 
Linux entry.

I want to build this new system with the same kind of easy to use menu system 
when you turn it on and I want it to have a menu entry to start up a regular 
sized distro if people want that to.  This new system will have the primary 
purpose of being an alternative to the xbox.

Because of legal reasons it may not be able to play encrypted dvds but should 
be able to play cds just fine.  But it should also be flexible enough so you 
can do any thing else with it.

The DVD part doesn't have to be a impossibility, if it became popular enough 
other companies might decide to make software to play encrypted movies on 
this system.  For this system to be devoted to open standards and be sold in 
stores I wouldn't be able to provide any software for dvds with out breaking 
retarded patent laws.  But that wouldn't stop other business from providing 
products to over come this.  That way who ever makes this system don't have 
to deal with royaltie issues.

> Horsepower wise though you are really going to have some beef to
> compete with the graphics power of the Xbox or ps2 line of products.
> That means the later nvidia or ATI cards.

I would use nvidia.  I find they have better support and drivers for Linux.  
Thought I would prefer to find hardware with open standard "chip sets" so any 
one can make open source drivers for them but I'm dreaming now.  I've seen 
some pretty nice video cards on newegg.com that's not to old that should be 
able to handle the latest games.  The first xbox had a 800 mhz CPU, it didn't 
even have a fan on the heat sink but the GPU did.

> A gaming console is also going to need some sort of low noise, smaller
> type case setup.

I've seen some nice microATX desktop cases on newegg.com.  So those should do 
nicely.  The thing to watch out for is heat and the power suplies they come 
with.  I've been told by some people the ones they have have crap power 
supplies and ended up getting their own.

> Neither of the above is cheap.  $300 is a would be a pretty good deal
> for what you get if it wern't for the stupid DRM they use.

Now that I re-think it, building this system by hand, we would end up making a 
gaming system that would cost more than current systems but cost less than 
current desktop computers at Best Buy.  And since this new system will be a 
hybrid of both I see no reason why this thing wouldn't sell like crazy.

> Although I think ps2 has linux dev kit for it dosen't it?

The first ps2 had one, it was a hard drive with linux installed on it and you 
just insert it into the ps2.  Sony came out with a newer thinner version of 
the ps2 and doesn't have the hard drive slot nor do they sell the kit any 
more.  Not in the US any way.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050824/88a29bfe/attachment.sig>

From smithbone at gmail.com  Wed Aug 24 10:05:40 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 24 Aug 2005 03:05:40 -0500
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <200508240211.36580.AvatarofVirgo@gmail.com>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
	<8a0c36780508232322699e4ae3@mail.gmail.com>
	<200508240211.36580.AvatarofVirgo@gmail.com>
Message-ID: <8a0c3678050824010517e00f14@mail.gmail.com>

On 8/24/05, Nathaniel Dube <avatarofvirgo at gmail.com> wrote:
> On Wednesday 24 August 2005 01:22 am, Richard Smith wrote:
> > What hardware do you have in mind?
> 
> I'd like it to be designed so any retail hardware off the shelf will do, but
> if we are to start a small business making these things I would try the best

Well LinuxBIOS only runs on a fairly small family of chipsets.  The
bulk of LinuxBIOS applications are in linux clusters or embedded
systems.  Neither of which would classify as "retail hardware" unless
you want to build game consoles out of dual Opteron boxes.  The higher
end VIA eden boards might qualify but support for them is still under
developement.

Actually a dual opteron and a recient PCI-Express video card would
probally make a pretty bad ass gameing machine. *grin*  Only cost you
about $2k

> the current XBOX cost, around $150 I think.  The XBOX360 I belive is going to
> be close to $300 when it comes out.  So it has to be hardware that would keep
> the over all price below the current consoles.

Going to be tough since those products are sold at a loss.

> you'll know that when you turn it on it loads to it's menu (with no game in
> it) pretty quick.  Which made me think to use LinuxBIOS.  Current BIOS

That would be an excellent use of LinuxBIOS and I'd love to see it
happen.  Boot time graphics however are currently _not_ one of LB's
strong points.  But I suppose that if you can get to a Linuxframe
buffer in say 1 or 2 seconds then you could load up a simple initrd
that would make that pretty easy.
 
> Now that I re-think it, building this system by hand, we would end up making a
> gaming system that would cost more than current systems but cost less than
> current desktop computers at Best Buy.  And since this new system will be a
> hybrid of both I see no reason why this thing wouldn't sell like crazy.

I'm sure thats what Indrema thought as well.  Making a commercial
product is a daunting task.  _Especially_ in the PC market.  I'm not
so sure it would be that much cheaper than a normal desktop.

This is kinda veering OT for linuxbios though.. So we should probally
take it off list.

-- 
Richard A. Smith



From Narahari.Narasimhaiah at honeywell.com  Wed Aug 24 16:14:32 2005
From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10))
Date: Wed, 24 Aug 2005 07:14:32 -0700
Subject: [LinuxBIOS] Booting windows 2000
Message-ID: <77ED2BF75D59D1439F90412CC5B109742355C2B5@ie10-sahara.hiso.honeywell.com>


Hi everyone,
	I've got a small question to ask.
	I am working with Dorado board which consist of SC2200 ( Geode
based) as the processor.
	I am trying to load windows 2000 with LILO as boot loader with
LinuxBIOS (LinuxBIOS + ADLO).
	I am not having VGA support.
	
	So I want to see the debug information on the serial (UART) port.
	I made serial port redirection at LinuxBIOS level.
	Is Serial port redirection possible after the Windows 2000 comes up.
	
	Can some one help me on serial port redirection at LILO level and OS
booting level also.
	
	I am sorry if I am not clear.
	
	I am struck up at this level.
	So any help can be really boost for me.
Thanks in advance,

Regards,
narahari

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

From stepan at openbios.org  Wed Aug 24 16:46:18 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed, 24 Aug 2005 16:46:18 +0200
Subject: [LinuxBIOS] Booting windows 2000
In-Reply-To: <77ED2BF75D59D1439F90412CC5B109742355C2B5@ie10-sahara.hiso.honeywell.com>
References: <77ED2BF75D59D1439F90412CC5B109742355C2B5@ie10-sahara.hiso.honeywell.com>
Message-ID: <20050824144617.GA1971@openbios.org>

* Narahari, Narasimhaiah (IE10) <Narahari.Narasimhaiah at honeywell.com> [050824 16:14]:
>         So I want to see the debug information on the serial (UART) port.
>         I made serial port redirection at LinuxBIOS level.
>         Is Serial port redirection possible after the Windows 2000 comes up.

What exactly do you expect? Windows 2000 is mainly a graphical user
interface. I don't think that it does any output via serial port.

>         Can some one help me on serial port redirection at LILO level and OS
> booting level also.
 
There's a pretty cool search engine, called "google" - www.google.com.
Have a look at:
http://www.linux.com/howtos/Remote-Serial-Console-HOWTO/configure-boot-loader-lilo.shtml


Stefan



From smithbone at gmail.com  Wed Aug 24 16:55:35 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 24 Aug 2005 09:55:35 -0500
Subject: [LinuxBIOS] Booting windows 2000
In-Reply-To: <20050824144617.GA1971@openbios.org>
References: <77ED2BF75D59D1439F90412CC5B109742355C2B5@ie10-sahara.hiso.honeywell.com>
	<20050824144617.GA1971@openbios.org>
Message-ID: <8a0c36780508240755527715fc@mail.gmail.com>

On 8/24/05, Stefan Reinauer <stepan at openbios.org> wrote:
> * Narahari, Narasimhaiah (IE10) <Narahari.Narasimhaiah at honeywell.com> [050824 16:14]:
> >         So I want to see the debug information on the serial (UART) port.
> >         I made serial port redirection at LinuxBIOS level.
> >         Is Serial port redirection possible after the Windows 2000 comes up.
> 
> What exactly do you expect? Windows 2000 is mainly a graphical user
> interface. I don't think that it does any output via serial port.
> 
> >         Can some one help me on serial port redirection at LILO level and OS
> > booting level also.

I think he means before w2k takes over.  

Bochs has serial output but you have to make sure its enabled.  I'm
not at work right now or I would tell you the exact #defines in BOCHS
to make sure are enabled.
Search the linuxbios archives for "bochs" and "serial debug".  Or you
can just look at the bochs code and search for "debug". One of those
#defines enables serial ouput.

When serial output is enabled you will be able to see all the stuff
that would normally have been sent to the vga screen.

You are using LinuxBIOS V1 I assume?

-- 
Richard A. Smith



From yinghai.lu at amd.com  Wed Aug 24 17:59:46 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 24 Aug 2005 08:59:46 -0700
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060B8@ssvlexmb2.amd.com>

All,

I have been hired by AMD to support LinuxBIOS development as it pertains
to AMD's product offerings.   Where appropriate I will also work on
items that benefit both AMD and LinuxBIOS community as a whole.  Please
do not hesitate to contact me regarding LinuxBIOS needs related to AMD
processors/products.

Regards

Yinghai Lu




From brhodes at visualcircuits.com  Wed Aug 24 18:04:26 2005
From: brhodes at visualcircuits.com (Brian Rhodes)
Date: Wed, 24 Aug 2005 11:04:26 -0500
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060B8@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060B8@ssvlexmb2.amd.com>
Message-ID: <1124899466.18284.18.camel@bugs.visualcircuits.>

Will this include alchemy?

On Wed, 2005-08-24 at 08:59 -0700, Lu, Yinghai wrote:
> All,
> 
> I have been hired by AMD to support LinuxBIOS development as it pertains
> to AMD's product offerings.   Where appropriate I will also work on
> items that benefit both AMD and LinuxBIOS community as a whole.  Please
> do not hesitate to contact me regarding LinuxBIOS needs related to AMD
> processors/products.
> 
> Regards
> 
> Yinghai Lu
> 
> 




From smithbone at gmail.com  Wed Aug 24 18:24:01 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 24 Aug 2005 11:24:01 -0500
Subject: [LinuxBIOS] Booting windows 2000
In-Reply-To: <8a0c36780508240755527715fc@mail.gmail.com>
References: <77ED2BF75D59D1439F90412CC5B109742355C2B5@ie10-sahara.hiso.honeywell.com>
	<20050824144617.GA1971@openbios.org>
	<8a0c36780508240755527715fc@mail.gmail.com>
Message-ID: <8a0c367805082409243f45b1a6@mail.gmail.com>

> > Can some one help me on serial port redirection at LILO level and OS
> > booting level also.

Look in util/ADLO/bochs/bios/rombios.c

Search for DEBUG_SERIAL and make sure

1) that it exists that way you actually have the version of rombios
with the serial output mods
2) the define is enabled 

Then all of the printf statements in rombios.c will go out the serial
port and anything that calls the bios to write a character to the
screen.  Which will include what LILO is trying to do.

Note that it also tries to the screen write bios call so if thats what
is hanging things it will still hang.
 For a true console redirection you will have to hack on the send()
routine to only call the uart_tx_byte() and not uart_tx_byte() and
wrch()

Hope this helps.

-- 
Richard A. Smith



From hamish at prodigi.ch  Wed Aug 24 20:31:30 2005
From: hamish at prodigi.ch (Hamish Guthrie)
Date: Wed, 24 Aug 2005 20:31:30 +0200
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060B8@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060B8@ssvlexmb2.amd.com>
Message-ID: <430CBD02.9080104@prodigi.ch>

Which product offerings will you be the interface for? I am currently 
maintaining the code for the Geode product.

Hamish

Lu, Yinghai wrote:
> All,
> 
> I have been hired by AMD to support LinuxBIOS development as it pertains
> to AMD's product offerings.   Where appropriate I will also work on
> items that benefit both AMD and LinuxBIOS community as a whole.  Please
> do not hesitate to contact me regarding LinuxBIOS needs related to AMD
> processors/products.
> 
> Regards
> 
> Yinghai Lu
> 
> 



From smithbone at gmail.com  Wed Aug 24 18:37:45 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 24 Aug 2005 11:37:45 -0500
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060B8@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060B8@ssvlexmb2.amd.com>
Message-ID: <8a0c3678050824093770a5596a@mail.gmail.com>

> I have been hired by AMD to support LinuxBIOS development as it pertains
> to AMD's product offerings.   Where appropriate I will also work on

We have been looking at replacing our STPC products with either a
Geode GX or LX setup.

Poor LinuxBIOS support has held this up somewhat.  

We curently are not paying a royality for our BIOS and we don't _ever_
want to do it again.

Whats the plan for "official" LinuxBIOS Geode GX and LX support?

-- 
Richard A. Smith



From richard.brunner at amd.com  Wed Aug 24 19:19:38 2005
From: richard.brunner at amd.com (Brunner, Richard)
Date: Wed, 24 Aug 2005 12:19:38 -0500
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
Message-ID: <C2BC72CDFC11A44083B660CAC2E9EA6702C9C546@SAUSEXMB1.amd.com>

Initially, our active focus will be on LinuxBIOS
support for AMD Opteron processors. We are still 
discussing internally what we can do for other
AMD product lines. Right now, we are taking it 
one step at a time. Got to start somewhere ...

Thanks!

	-Rich Brunner, AMD Fellow

> -----Original Message-----
> From: linuxbios-bounces at openbios.org 
> [mailto:linuxbios-bounces at openbios.org] On Behalf Of Richard Smith
> Sent: Wednesday, August 24, 2005 9:38 AM
> To: Lu, Yinghai
> Cc: linuxbios at openbios.org
> Subject: Re: [LinuxBIOS] Work at AMD to support LinuxBIOS
> 
> > I have been hired by AMD to support LinuxBIOS development 
> as it pertains
> > to AMD's product offerings.   Where appropriate I will also work on
> 
> We have been looking at replacing our STPC products with either a
> Geode GX or LX setup.
> 
> Poor LinuxBIOS support has held this up somewhat.  
> 
> We curently are not paying a royality for our BIOS and we don't _ever_
> want to do it again.
> 
> Whats the plan for "official" LinuxBIOS Geode GX and LX support?
> 
> -- 
> Richard A. Smith
> 
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
> 
> 




From yinghai.lu at AMD.com  Wed Aug 24 19:38:44 2005
From: yinghai.lu at AMD.com (Lu, Yinghai)
Date: Wed, 24 Aug 2005 10:38:44 -0700
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060BE@ssvlexmb2.amd.com>

Did you get enough doc about that?

YH

-----Original Message-----
From: Hamish Guthrie [mailto:hamish at prodigi.ch] 
Sent: Wednesday, August 24, 2005 11:32 AM
To: Lu, Yinghai
Cc: linuxbios at openbios.org
Subject: Re: [LinuxBIOS] Work at AMD to support LinuxBIOS

Which product offerings will you be the interface for? I am currently 
maintaining the code for the Geode product.

Hamish

Lu, Yinghai wrote:
> All,
> 
> I have been hired by AMD to support LinuxBIOS development as it
pertains
> to AMD's product offerings.   Where appropriate I will also work on
> items that benefit both AMD and LinuxBIOS community as a whole.
Please
> do not hesitate to contact me regarding LinuxBIOS needs related to AMD
> processors/products.
> 
> Regards
> 
> Yinghai Lu
> 
> 





From smithbone at gmail.com  Wed Aug 24 19:41:07 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 24 Aug 2005 12:41:07 -0500
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
In-Reply-To: <C2BC72CDFC11A44083B660CAC2E9EA6702C9C546@SAUSEXMB1.amd.com>
References: <C2BC72CDFC11A44083B660CAC2E9EA6702C9C546@SAUSEXMB1.amd.com>
Message-ID: <8a0c3678050824104121261cc3@mail.gmail.com>

On 8/24/05, Brunner, Richard <richard.brunner at amd.com> wrote:
> Initially, our active focus will be on LinuxBIOS
> support for AMD Opteron processors. We are still

I'm sure Ron, Eric and rest of the cluster gang will be happy to hear that.

> discussing internally what we can do for other
> AMD product lines.

IMHO the best thing you could possibly do for support of other AMD
product lines is to provide people like Hamish and I access to the
proper documentation for the chips, an agreement that allows the
generated source to be released under LinuxBIOS and an open line of
communication for some questions when we get stuck.

Do that and you will find your products will magically become
supported by the community who will then speak very nicely about AMD
_without_ a lot of additional effort on your part.

I do understand that may be a little easier said than done considering
your existing partnership with Insyde and General Software.

Thank for the info.  I'm really encouraged that AMD is looking at
official LinuxBIOS support for its products.

-- 
Richard A. Smith



From smithbone at gmail.com  Wed Aug 24 20:21:55 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 24 Aug 2005 13:21:55 -0500
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
In-Reply-To: <8a0c3678050824104121261cc3@mail.gmail.com>
References: <C2BC72CDFC11A44083B660CAC2E9EA6702C9C546@SAUSEXMB1.amd.com>
	<8a0c3678050824104121261cc3@mail.gmail.com>
Message-ID: <8a0c3678050824112111331cf2@mail.gmail.com>

>
> Do that and you will find your products will magically become
> supported by the community who will then speak very nicely about AMD
> _without_ a lot of additional effort on your part.
>

In fact I'll actually put my money where my mouth is on this.

Send me a LX DB800 board and if there is enough info on the developer
site. (which I'm already a member of) I'll make the port happen.  If
not I'll send it back.

Looks like there is a empty PLCC socket on the board.  If that's where
the BIOS goes then I won't need any special flashing tools.

Hamish you already have quite a bit of work done toward this don't you?


-- 
Richard A. Smith



From hamish at hatecke.ch  Wed Aug 24 22:39:37 2005
From: hamish at hatecke.ch (Hamish Guthrie)
Date: Wed, 24 Aug 2005 22:39:37 +0200
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
In-Reply-To: <8a0c3678050824112111331cf2@mail.gmail.com>
References: <C2BC72CDFC11A44083B660CAC2E9EA6702C9C546@SAUSEXMB1.amd.com>	<8a0c3678050824104121261cc3@mail.gmail.com>
	<8a0c3678050824112111331cf2@mail.gmail.com>
Message-ID: <430CDB09.20902@hatecke.ch>

I have done a lot of work on the GX1 platform, I also have a kindly 
loaned GX2 platform from AMD here, but my GX1 work is for a paying 
customer :), so that is taking priority ATM - I am not sure what the 
situation is with the newer processors - it appears as though there is 
third-party chipset support (SiS, if I am correct), and their docs are 
not necessarily of the highest standard IMHO. </END RANT!>

If they are still using VSA or VSA2 on the newer chips, I can give you a 
heads-up - it can be a trite tricky.

Hamish

Richard Smith wrote:
>>Do that and you will find your products will magically become
>>supported by the community who will then speak very nicely about AMD
>>_without_ a lot of additional effort on your part.
>>
> 
> 
> In fact I'll actually put my money where my mouth is on this.
> 
> Send me a LX DB800 board and if there is enough info on the developer
> site. (which I'm already a member of) I'll make the port happen.  If
> not I'll send it back.
> 
> Looks like there is a empty PLCC socket on the board.  If that's where
> the BIOS goes then I won't need any special flashing tools.
> 
> Hamish you already have quite a bit of work done toward this don't you?
> 
> 



From smithbone at gmail.com  Wed Aug 24 20:55:56 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 24 Aug 2005 13:55:56 -0500
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
In-Reply-To: <430CDB09.20902@hatecke.ch>
References: <C2BC72CDFC11A44083B660CAC2E9EA6702C9C546@SAUSEXMB1.amd.com>
	<8a0c3678050824104121261cc3@mail.gmail.com>
	<8a0c3678050824112111331cf2@mail.gmail.com>
	<430CDB09.20902@hatecke.ch>
Message-ID: <8a0c36780508241155bb161dc@mail.gmail.com>

On 8/24/05, Hamish Guthrie <hamish at hatecke.ch> wrote:

> I have done a lot of work on the GX1 platform, I also have a kindly
> loaned GX2 platform from AMD here, but my GX1 work is for a paying

Whats a GX2?  I don't see any thing with GX2 on the website.
 
> If they are still using VSA or VSA2 on the newer chips, I can give you a
> heads-up - it can be a trite tricky.

I thought that was whole point of the newer GX533 and the LX.  The are
using AMDs x86 stuff rather than the National Semi stuff.  If they are
still using VSA then I won't even bother.
No point in doing anything with SiS either.  You can't get an SiS
chipset(s) unless you talk huge quantities.

It will only be useful to me if its the GX533 or the LX and a CS5536
companion device.

Guess I need to go look at what info is in the developer site.

-- 
Richard A. Smith



From kfuchs at winternet.com  Wed Aug 24 23:27:50 2005
From: kfuchs at winternet.com (Ken Fuchs)
Date: Wed, 24 Aug 2005 16:27:50 -0500 (CDT)
Subject: [LinuxBIOS] Opteron nVidia CK8-04/nForce4 PCI Express support
Message-ID: <200508242127.j7OLRopJ021793@tundra.winternet.com>

Does the current LinuxBIOS code support PCI Express?  LinuxBIOS
contains PCI Express support code, but does it actually work?

Has anyone successfully used a PCI Express SATA controller via
LinuxBIOS with an nVidia CK8-04/nForce4 chipset?  Or a PCI Express
video card?  Or any PCI Express card or device?

I have an nVidia CK8-04 CRB mainboard.

Here's lspci output using LinuxBIOS (GNU Arch Rev 33) code, ported
from the Tyan S2895 to nVidia CK8-04 CRB (with Fedora Core 3 running):

# /sbin/lspci
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] MiscellDEaneous Control
01:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
01:01.0 ISA bridge: nVidia Corporation: Unknown device 0051 (rev a3)
01:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
01:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
01:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
01:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
01:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
01:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
01:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
01:0a.0 Ethernet controller: nVidia Corporation CK804 Ethernet Controller (rev a3)
01:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
04:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
04:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
04:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
04:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
04:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
04:0a.0 Ethernet controller: nVidia Corporation CK804 Ethernet Controller (rev a3)
04:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
# 

Here's lspci output using the original PhoenixBIOS (with FC 3 running):

# /sbin/lspci
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation: Unknown device 0051 (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
00:06.0 I interface: nVidia Corporation CK804 IDE (rev a2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
01:06.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (rev 43)
80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
80:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
80:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
80:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
80:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
# 

I'm not sure about the bus numbering being correct for LinuxBIOS.
Somewhere, I heard that the bus nmubers for certain devices had to be
multiples of 0x40 for the CK8-04 chipset, but I can't recall which
devices and why they had to be on bus 0, 40, 80, & C0.  As you can see
above, LinuxBIOS and PhoenixBIOS use very different bus numbers.

The onboard ATA, USB (pen drive) and Ethernet eth0 (didn't try eth1)
are working.

Right now, I'd like to test PCI Express.  It would be great to have a
PCI Express bus analyzer and execizer, but they are very expensive.
I think the cheapest and easiest way to test PCI Express is via
a PCI Express SATA controller or maybe a PCI Express video card.

I'm planning to get the following PCI Express cards:

Siig SCSAE012S1 SATA II PCI Express card
http://www.directron.com/scsae012s1.html

ATI Radeon X300 SE 128MB PCI Express card
http://www.ati.com/products/radeonx300/specs.html

Is there anything wrong with my plan to use either of these particular
PCI Express cards to test PCI Express on my nVidia CK8-04 CRB?

To test PCI Express with the video card I would need to use testbios
or the integrated VGA support of LinuxBIOS?  It seems that this could
get too complicated for just testing that PCI Express works.  The PCI
Express SATA controller seems much easier.  Is there an easier way to
test PCI Express with the PCI Express video card such as simply
reading and writing to its RAM (in other words, not using it as a
video device)?

Thank you!

Sincerely,

Ken Fuchs <kfuchs at winternet.com>



From yinghai.lu at amd.com  Wed Aug 24 23:42:55 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 24 Aug 2005 14:42:55 -0700
Subject: [LinuxBIOS] Opteron nVidia CK8-04/nForce4 PCI Express
 support
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E060C5@ssvlexmb2.amd.com>

I have tested Nvidia pci-e graphics card ( I forgot the model) and
Mellanox pci-e infiband card with all Tyan opteron based MB. All work
well.

Also I test another eight way four ck804 system with 4 infiband pci-e
card, it works well too.

YH

-----Original Message-----
From: linuxbios-bounces at openbios.org
[mailto:linuxbios-bounces at openbios.org] On Behalf Of Ken Fuchs
Sent: Wednesday, August 24, 2005 2:28 PM
To: LinuxBIOS at openbios.org
Subject: [LinuxBIOS] Opteron nVidia CK8-04/nForce4 PCI Express support

Does the current LinuxBIOS code support PCI Express?  LinuxBIOS
contains PCI Express support code, but does it actually work?

Has anyone successfully used a PCI Express SATA controller via
LinuxBIOS with an nVidia CK8-04/nForce4 chipset?  Or a PCI Express
video card?  Or any PCI Express card or device?

I have an nVidia CK8-04 CRB mainboard.

Here's lspci output using LinuxBIOS (GNU Arch Rev 33) code, ported
from the Tyan S2895 to nVidia CK8-04 CRB (with Fedora Core 3 running):

# /sbin/lspci
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
MiscellDEaneous Control
01:00.0 Memory controller: nVidia Corporation CK804 Memory Controller
(rev a3)
01:01.0 ISA bridge: nVidia Corporation: Unknown device 0051 (rev a3)
01:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
01:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
01:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
01:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
01:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev a3)
01:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev a3)
01:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
01:0a.0 Ethernet controller: nVidia Corporation CK804 Ethernet
Controller (rev a3)
01:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
04:00.0 Memory controller: nVidia Corporation CK804 Memory Controller
(rev a3)
04:01.0 Memory controller: nVidia Corporation CK804 Memory Controller
(rev a3)
04:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
04:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev a3)
04:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev a3)
04:0a.0 Ethernet controller: nVidia Corporation CK804 Ethernet
Controller (rev a3)
04:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
# 

Here's lspci output using the original PhoenixBIOS (with FC 3 running):

# /sbin/lspci
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller
(rev a3)
00:01.0 ISA bridge: nVidia Corporation: Unknown device 0051 (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97
Audio Controller (rev a2)
00:06.0 I interface: nVidia Corporation CK804 IDE (rev a2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
01:06.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+]
(rev 43)
80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller
(rev a3)
80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller
(rev a3)
80:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev a3)
80:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller
(rev a3)
80:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
80:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
80:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
# 

I'm not sure about the bus numbering being correct for LinuxBIOS.
Somewhere, I heard that the bus nmubers for certain devices had to be
multiples of 0x40 for the CK8-04 chipset, but I can't recall which
devices and why they had to be on bus 0, 40, 80, & C0.  As you can see
above, LinuxBIOS and PhoenixBIOS use very different bus numbers.

The onboard ATA, USB (pen drive) and Ethernet eth0 (didn't try eth1)
are working.

Right now, I'd like to test PCI Express.  It would be great to have a
PCI Express bus analyzer and execizer, but they are very expensive.
I think the cheapest and easiest way to test PCI Express is via
a PCI Express SATA controller or maybe a PCI Express video card.

I'm planning to get the following PCI Express cards:

Siig SCSAE012S1 SATA II PCI Express card
http://www.directron.com/scsae012s1.html

ATI Radeon X300 SE 128MB PCI Express card
http://www.ati.com/products/radeonx300/specs.html

Is there anything wrong with my plan to use either of these particular
PCI Express cards to test PCI Express on my nVidia CK8-04 CRB?

To test PCI Express with the video card I would need to use testbios
or the integrated VGA support of LinuxBIOS?  It seems that this could
get too complicated for just testing that PCI Express works.  The PCI
Express SATA controller seems much easier.  Is there an easier way to
test PCI Express with the PCI Express video card such as simply
reading and writing to its RAM (in other words, not using it as a
video device)?

Thank you!

Sincerely,

Ken Fuchs <kfuchs at winternet.com>

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





From Narahari.Narasimhaiah at honeywell.com  Thu Aug 25 07:46:00 2005
From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10))
Date: Wed, 24 Aug 2005 22:46:00 -0700
Subject: [LinuxBIOS] Booting win XP
Message-ID: <77ED2BF75D59D1439F90412CC5B10974235FC68F@ie10-sahara.hiso.honeywell.com>


Hi everyone,

Can any body let me know the order of interrupts the windows XP issues on
BIOS during booting?

With regards,
Narahari

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

From bari at onelabs.com  Thu Aug 25 07:58:42 2005
From: bari at onelabs.com (Bari Ari)
Date: Thu, 25 Aug 2005 01:58:42 -0400
Subject: [LinuxBIOS] Booting win XP
In-Reply-To: <77ED2BF75D59D1439F90412CC5B10974235FC68F@ie10-sahara.hiso.honeywell.com>
References: <77ED2BF75D59D1439F90412CC5B10974235FC68F@ie10-sahara.hiso.honeywell.com>
Message-ID: <20050825015842.euu0tvx6kfwc4o4g@onelabs.com>

Quoting "Narahari, Narasimhaiah (IE10)" <Narahari.Narasimhaiah at honeywell.com>:

>
> Hi everyone,
>
> Can any body let me know the order of interrupts the windows XP issues on
> BIOS during booting?

Have you looked through all the ADLO docs?:
http://www.linuxbios.org/index.php/ADLO

and especially here:
http://www.missl.cs.umd.edu/winint/index2.html

-Bari




From hamish at prodigi.ch  Thu Aug 25 15:34:23 2005
From: hamish at prodigi.ch (Hamish Guthrie)
Date: Thu, 25 Aug 2005 15:34:23 +0200
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
In-Reply-To: <8a0c36780508241155bb161dc@mail.gmail.com>
References: <C2BC72CDFC11A44083B660CAC2E9EA6702C9C546@SAUSEXMB1.amd.com>	<8a0c3678050824104121261cc3@mail.gmail.com>	<8a0c3678050824112111331cf2@mail.gmail.com>	<430CDB09.20902@hatecke.ch>
	<8a0c36780508241155bb161dc@mail.gmail.com>
Message-ID: <430DC8DF.5050603@prodigi.ch>

> Whats a GX2?  I don't see any thing with GX2 on the website.
> 
> I thought that was whole point of the newer GX533 and the LX.  The are
> using AMDs x86 stuff rather than the National Semi stuff.  If they are
> still using VSA then I won't even bother.
> No point in doing anything with SiS either.  You can't get an SiS
> chipset(s) unless you talk huge quantities.
> 
> It will only be useful to me if its the GX533 or the LX and a CS5536
> companion device.
> 
> Guess I need to go look at what info is in the developer site.
> 
The VSA/VSA2 enables more true VGA compatibility and enables the audio, 
among a few other things. For any device where there is a NSC/AMD 
companion chip (CS5530/CS5536), as far as my understanging goes, 
includes VSA, the SC1200 and a few of those other integrated devices 
also have the VSA.

The difference between what AMD/NSC call the GX1 and GX2 is simply the 
companion chip - CS5530=GX1 platform, CS5536=GX2

Hamish



From magicfox at magic.fr  Thu Aug 25 16:06:24 2005
From: magicfox at magic.fr (magicfox)
Date: Thu, 25 Aug 2005 16:06:24 +0200
Subject: [LinuxBIOS] Makefile definition of GCC_INC_DIR (linuxBIOSv2)
Message-ID: <430DD060.9040706@magic.fr>

I have some problem with language of messages for gcc
in GCC_INC_DIR definition.

gcc -print-search-dirs show (in French):
install_?s_: /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/
programmes: =/usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.4/:/usr/l...

LC_MESSAGES definition to 'en_UK' doesn't help me.

I'm not a sed expert but this new definition is right for me.

Original:
GCC_INC_DIR $(shell $(CC) --print-search-dirs | sed -ne
"s/install\(.*\)/\1include/gp")

New one:
GCC_INC_DIR $(shell $(CC) --print-search-dirs | sed -ne "1s/.* //p" |
sed -e s/$/include/")

Can somebody would test this with others languages than EN for gcc ?

Best regards





From smithbone at gmail.com  Thu Aug 25 18:15:05 2005
From: smithbone at gmail.com (Richard Smith)
Date: Thu, 25 Aug 2005 11:15:05 -0500
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
In-Reply-To: <430DC8DF.5050603@prodigi.ch>
References: <C2BC72CDFC11A44083B660CAC2E9EA6702C9C546@SAUSEXMB1.amd.com>
	<8a0c3678050824104121261cc3@mail.gmail.com>
	<8a0c3678050824112111331cf2@mail.gmail.com>
	<430CDB09.20902@hatecke.ch> <8a0c36780508241155bb161dc@mail.gmail.com>
	<430DC8DF.5050603@prodigi.ch>
Message-ID: <8a0c36780508250915457e1ac@mail.gmail.com>

> companion chip (CS5530/CS5536), as far as my understanging goes,
> includes VSA, the SC1200 and a few of those other integrated devices
> also have the VSA.

Ok.  I'll try to read some of the docs this weekend.  But if it does
use VSA for all the stuff  we will be much less interested.  I've read
nothing but bad things about VSA.

-- 
Richard A. Smith



From hamish at prodigi.ch  Thu Aug 25 20:47:42 2005
From: hamish at prodigi.ch (Hamish Guthrie)
Date: Thu, 25 Aug 2005 20:47:42 +0200
Subject: [LinuxBIOS] Work at AMD to support LinuxBIOS
In-Reply-To: <8a0c36780508250915457e1ac@mail.gmail.com>
References: <C2BC72CDFC11A44083B660CAC2E9EA6702C9C546@SAUSEXMB1.amd.com>	
	<8a0c3678050824104121261cc3@mail.gmail.com>	
	<8a0c3678050824112111331cf2@mail.gmail.com>	
	<430CDB09.20902@hatecke.ch>
	<8a0c36780508241155bb161dc@mail.gmail.com>	
	<430DC8DF.5050603@prodigi.ch>
	<8a0c36780508250915457e1ac@mail.gmail.com>
Message-ID: <430E124E.2050707@prodigi.ch>

Richard,

The VSA stuff actually works fine, but there are some technical issues 
(from a LinuxBIOS standpoint) which make it tricky. These issues I am 
sure are surmountable, and if AMD are really wanting to help LinuxBIOS, 
they may take note of this!!!!

I stand under correction as to the exact details of this, as I have seen 
no source for the VSA code, but, with a lot of analysis, the main VSA 
code gets executed under SMM, but that is not a detail we really need to 
be concered with, the issue is getting the VSA code loaded in the first 
place.

There is init code provided within the VSA code binary, which is easy to 
vector to, however, this is real-mode code, so I have looked at various 
ways of doing this - I have followed the x86emu route, but there are 
instructions used in this VSA code which are not supported by x86emu, 
and I have just not had the time to be able to look into this properly. 
Another suggestion (I believe from Stephan) is to look at executing this 
code in vm86 mode, but I have not tried that yet. The third alternative 
is to ping-pong back into real-mode after we have enough of the chipset 
initialised, but that looks like bad news.

I have an interim solution for situations where I want to use the VSA 
code, and that is to use unreal mode (yea, I am in assembler the whole 
way here), to initialise enough of the chipset and RAM in order to get 
to the point where I can vector to the VSA init code, shortly after 
returning from the VSA init code, I then jump to the real-mode LinuxBIOS 
entry-point, and just strip out the code from my LinuxBIOS version of 
the early init code and let LinuxBIOS do the rest.

What would be REALLY NICE - (hint - hint AMD, are you listening!), is if 
we could maybe get the source for the VSA init code, in which case, we 
*SHOULD* be able to write our own protected-mode init code to load the 
actual VSA code into RAM and do the initialisation correctly from within PM.

I can really only speak about the VSA code from a VGA point of view, and 
from that point of view it is actually quite elegant (although a proper 
silicon solution would have been much easier!). The VSA code for the VGA 
subsystem essentially simulates all of the legacy VGA hardware ports in 
software. These are generally used to set VGA modes and things, and are 
useful when initialising the VGA itself. Well, especially useful for 
using 'traditional' techniques (i.e. VGA BIOS calls, and the ELPIN VGA 
BIOS requires the VSA stuff to be loaded) when setting modes under X and 
for the framebuffer device. Once the VGA chipset is set-up, the VSA 
falls out of the picture completely, as the X and FB drivers from that 
point on ONLY ever access the hardware directly.

I believe the situation may be a little different with the VSA code for 
Audio, but I have not yet had to play with that too hard, so I cannot 
really comment, other than, yes, with LinuxBIOS, and my unreal-mode 
loader fudge, I have managed to get audio to work! How good it is, I 
have no idea - it is not part of my current bread winning project - I 
heard some sound, and that was it!

Hamish

Richard Smith wrote:
>>companion chip (CS5530/CS5536), as far as my understanging goes,
>>includes VSA, the SC1200 and a few of those other integrated devices
>>also have the VSA.
> 
> 
> Ok.  I'll try to read some of the docs this weekend.  But if it does
> use VSA for all the stuff  we will be much less interested.  I've read
> nothing but bad things about VSA.
> 



From steve at digidescorp.com  Thu Aug 25 19:05:00 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Thu, 25 Aug 2005 12:05:00 -0500
Subject: [LinuxBIOS] CMOS options questions
Message-ID: <001801c5a997$242ea640$6ffea8c0@banana>

Hi,

I am trying to finish up support for Intel's XE7501DEVKIT (E7501 Xeon
reference board) and have run into a snag getting CMOS options to work.

It looks like the factory BIOS uses pretty much the entire normal
128-byte region of the CMOS. So to support LB use of CMOS I will have to
use the upper 128 bytes.

Another option is to run this board without LB use of CMOS. But the
factory BIOS on this board does not like the changes LB makes to the
CMOS while booting. If I boot LB, then re-flash the factory BIOS and
boot it, the factory BIOS complains that the CMOS checksum is bad.

The questions:
* Is there any reason not to change hard-coded CMOS_IMAGE_SIZE constants

  from 128 to 256?

* Is there any reason not to change hard-coded accesses to RTC_BOOT_BYTE

  to equivalent read_option calls (accounting for the fact that the 
  fallback image, in which USE_OPTION_TABLE=0, may also need to be able 
  to read the 'boot byte' of the CMOS)?

* Is there any reason not to disable writing to CMOS (except for control

  registers) when HAVE_OPTION_TABLE = 0?


------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"
 
 #include <standard.disclaimer>






From steve at digidescorp.com  Thu Aug 25 19:14:06 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Thu, 25 Aug 2005 12:14:06 -0500
Subject: [LinuxBIOS] RE: CMOS options questions
Message-ID: <001901c5a998$663241e0$6ffea8c0@banana>

Without CMOS I think we are limited to a single image, i.e. no fallback.
So HAVE_OPTION_TABLE = 0 would imply HAVE_FALLBACK_BOOT = 0, and this
part can be disregarded:

> (accounting for the fact that the fallback image, in which 
> USE_OPTION_TABLE=0, may also need to be able to read the 
> 'boot byte' of the CMOS)

------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"
 
 #include <standard.disclaimer>






From halbmond at macnews.de  Thu Aug 25 21:51:36 2005
From: halbmond at macnews.de (Angel)
Date: Thu, 25 Aug 2005 21:51:36 +0200
Subject: [LinuxBIOS] Does LinuxBIOS support the Mac Mini?
Message-ID: <164300a7c9c0ccd72087b8ea350d0d0e@macnews.de>

Hello,

as LinuxBIOS is supporting the G4, I would like to know if it also 
supports the Mac Mini?
Unfortunately I couldn't find any information on the chipset, except 
that the northbridge and southbridge seem to be combined in a single 
chip.

Thanks in advance




From avatarofvirgo at gmail.com  Thu Aug 25 23:11:24 2005
From: avatarofvirgo at gmail.com (Nathaniel Dube)
Date: Thu, 25 Aug 2005 16:11:24 -0500
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <20050825140657.umbs993ypk8okcsc@onelabs.com>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
	<200508240211.36580.AvatarofVirgo@gmail.com>
	<20050825140657.umbs993ypk8okcsc@onelabs.com>
Message-ID: <200508251611.39363.AvatarofVirgo@gmail.com>

On Thursday 25 August 2005 01:06 pm, onelabs at onelabs.com wrote:
> The reality here is that you'd be building a new game platform and
> selling it at
> a loss (the same as Sony and M$) if you're trying to match their
> performance. In
> order to make a profit you'll have to sell games and accessories with
> enough profit margin to recoup your investments in the consoles.
>
> IMHO, your largest hurdle will probably be getting the funding to back your
> console business and attracting game developers to gamble on the
> investment.
>
> -Bari

Actually, I 'm not really focused on doing that now.  All I have to do is put 
up a site with downloads and instructions so any small business can put it 
together in half an hour or around that time.  It's not my interest to make 
any money off this.  Unless I put a donations thing on the site.

The goal is make it so any one with an all ready established business can 
download ISOs, the flash and buy their own hardware.  Flash what ever mother 
board LinuxBIO supports, put together what ever hardware they want and 
install the OS.  The only thing that would cost them any thing is the 
hardware.

The controllers all ready exist.  I saw some PC controllers that looked like 
xbox controllers.  Those should work out great.

This console would basicaly just be a cheap PC with a slimed down Linux Distro 
designed to act like the xbox OS and have LinuxBIOS so it boots up fast like 
the xbox.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050825/8dd14677/attachment.sig>

From stepan at openbios.org  Fri Aug 26 00:33:35 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 26 Aug 2005 00:33:35 +0200
Subject: [LinuxBIOS] Does LinuxBIOS support the Mac Mini?
In-Reply-To: <164300a7c9c0ccd72087b8ea350d0d0e@macnews.de>
References: <164300a7c9c0ccd72087b8ea350d0d0e@macnews.de>
Message-ID: <20050825223335.GA17534@openbios.org>

* Angel <halbmond at macnews.de> [050825 21:51]:
> Hello,
> 
> as LinuxBIOS is supporting the G4, I would like to know if it also 
> supports the Mac Mini?

LinuxBIOS supports the G4?

> Unfortunately I couldn't find any information on the chipset, except 
> that the northbridge and southbridge seem to be combined in a single 
> chip.

Can you send an lspci -vvv output of such a machine running Linux?

Stefan




From halbmond at macnews.de  Fri Aug 26 16:00:28 2005
From: halbmond at macnews.de (Angel)
Date: Fri, 26 Aug 2005 16:00:28 +0200
Subject: [LinuxBIOS] RE: Does LinuxBIOS support the Mac Mini?
Message-ID: <b8d3f3f268820c39809a6b49ebdec9a7@macnews.de>

Well, the wiki says it supports the PPC series MPC74xx, MPC4xx and 
MPC7xx. The CPU built in the Mac Mini is a MPC7447 (revision B I 
believe), so I think it should be supported, shouldn't it?
The wiki also says the Motorola northbridge MPC107 is supported. 
According to this page ( 
http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MPC107 
) this chipset seems to be only suitable for older CPU up to the 
MPC7410. I couldn't find any information about the chipset used in the 
Mac Mini. But as Apple is just an OEM, it should be from 
Motorola/Freescale as well.




From stepan at openbios.org  Fri Aug 26 16:11:20 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri, 26 Aug 2005 16:11:20 +0200
Subject: [LinuxBIOS] RE: Does LinuxBIOS support the Mac Mini?
In-Reply-To: <b8d3f3f268820c39809a6b49ebdec9a7@macnews.de>
References: <b8d3f3f268820c39809a6b49ebdec9a7@macnews.de>
Message-ID: <20050826141120.GA24803@openbios.org>

* Angel <halbmond at macnews.de> [050826 16:00]:
> http://e-www.motorola.com/webapp/sps/site/prod_summary.jsp?code=MPC107 
> ) this chipset seems to be only suitable for older CPU up to the 
> MPC7410. I couldn't find any information about the chipset used in the 
> Mac Mini. 

Can you send the output of "lspci -vvv" running on Linux on a Mac Mini?

Stefan





From Stephen.Kimball at bench.com  Fri Aug 26 23:22:24 2005
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Fri, 26 Aug 2005 17:22:24 -0400
Subject: [LinuxBIOS] VGA support
Message-ID: <30ADB28314F8B744AB478FB5EDA044B30D80EC@nh-ex01.bench.com>

I just got a VGA addon card to work on the nVidia nf4crb board.

Maybe my comments would be helpful to others.

 

1)       Turning on the VGA options in Options.lb (CONFIG_CONSOLE_VGA
and CONFIG_PCI_ROM_RUN) added more "stuff" than I could fit on a 512K
Flash device.  I had to use a pin compatible 1M Flash device.  Are there
other options if a larger Flash device is not available?  For example,
what are the Options.lb changes to run without a FALLBACK  or without
CMOS Options.  Are there ways to tell how much free Flash space you
have?

2)       I'd suggest the VGA Support page have a reference to the
FreeVGA article.

3)       The VGA support page should have a suggestion to check to see
that PCI bridges are set to enable forwarding of VGA memory mapped I/O.

4)       I needed to change src/devices/pci_rom.c in pci_rom_load() at
about line 88 to force the VGA ROM to be copied to
PCI_VGA_RAM_IMAGE_START (0xC0000).  The rom_data->class_hi test failed
when it shouldn't have?

 

The VGA support is very cool.  Thanks to all who made it work.

 

Steve

 

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

From steve at digidescorp.com  Sat Aug 27 15:18:43 2005
From: steve at digidescorp.com (Steve Magnani)
Date: Sat, 27 Aug 2005 08:18:43 -0500
Subject: [LinuxBIOS] VGA support
Message-ID: <WorldClient-F200508270818.AA18430062@digidescorp.com>

Hi Steve -

> what are the Options.lb changes to run without a FALLBACK 
> or without CMOS Options.  
I think ideally, to run without fallback, you'd just set
HAVE_FALLBACK_BOOT = 0 and change your target Config.lb to not build the
fallback image. But I don't think most config files are set up to work
that way. I set FALLBACK_SIZE and HAVE_FALLBACK_BOOT to 0, and use a
mainboard Config.lb file that looks like this:

    ##
    ## Build our reset vector (This is where linuxBIOS is entered)
    ##
    if HAVE_FALLBACK_BOOT
        if USE_FALLBACK_IMAGE 
               mainboardinit cpu/x86/16bit/reset16.inc 
               ldscript /cpu/x86/16bit/reset16.lds
        else
               mainboardinit cpu/x86/32bit/reset32.inc
               ldscript /cpu/x86/32bit/reset32.lds 
        end
    else
        mainboardinit cpu/x86/16bit/reset16.inc 
        ldscript /cpu/x86/16bit/reset16.lds
    end


> Are there ways to tell how much free Flash space you have?
I usually look at the linuxbios.rom file with a hex editor to see if
there's a large chunk of "FF"s. If so I try reducing ROM_SIZE and/or
ROM_IMAGE_SIZE, depending on where the FFs are.

Hope this helps.
------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"
 
 #include <standard.disclaimer>





From magicfox at magic.fr  Sun Aug 28 18:41:45 2005
From: magicfox at magic.fr (magicfox)
Date: Sun, 28 Aug 2005 18:41:45 +0200
Subject: [LinuxBIOS] [patch] LINUXBIOS_ASSEMBLER & GCC_INC_DIR definitions
Message-ID: <4311E949.7080006@magic.fr>

Hi,

1. If assembler version string contain parentheses like 
(i686-pc-linux-gnu), it breaks bash on Makefile.

2. No gcc message language depend of GCC_INC_DIR definition.

src_config.patch corrects items 1-2 vs last svn revision 2009 .

I have also a problem with udelay in ibm/e325 make

...
/LinuxBIOSv2/src/mainboard/ibm/e325/auto.c -o auto.inc
delay.c:9.1:
udelay already defined
make[1]: *** [auto.inc] Error 1

Please, can somebody help ?

Best regards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: src_config.patch
Type: application/patch
Size: 1150 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050828/f223eb42/attachment.bin>

From rminnich at lanl.gov  Sun Aug 28 19:44:33 2005
From: rminnich at lanl.gov (Ronald G Minnich)
Date: Sun, 28 Aug 2005 11:44:33 -0600
Subject: [LinuxBIOS] [Fwd: Bounce action notification]
Message-ID: <4311F801.10301@lanl.gov>

An embedded message was scrubbed...
From: mailman at openbios.org
Subject: Bounce action notification
Date: Sun, 28 Aug 2005 18:59:10 +0200
Size: 9477
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050828/e433fe8c/attachment.mht>

From ollie at lanl.gov  Mon Aug 29 06:19:15 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Sun, 28 Aug 2005 22:19:15 -0600
Subject: [LinuxBIOS] VGA support
In-Reply-To: <30ADB28314F8B744AB478FB5EDA044B30D80EC@nh-ex01.bench.com>
References: <30ADB28314F8B744AB478FB5EDA044B30D80EC@nh-ex01.bench.com>
Message-ID: <1125289156.5280.4.camel@logarithm.lanl.gov>

On Fri, 2005-08-26 at 17:22 -0400, Stephen.Kimball at bench.com wrote:
> 
> 2)       I?d suggest the VGA Support page have a reference to the
> FreeVGA article.
> 

I will try to do that. The VGA support page on the wiki was half done.
I was interrupted when I modifying the page and never have time to
finish it.

> 3)       The VGA support page should have a suggestion to check to see
> that PCI bridges are set to enable forwarding of VGA memory mapped
> I/O.
> 

Isn't it been build into the device enumeration code? Isn't the code
in allocate_vga_resource sufficient?

> 4)       I needed to change src/devices/pci_rom.c in pci_rom_load() at
> about line 88 to force the VGA ROM to be copied to
> PCI_VGA_RAM_IMAGE_START (0xC0000).  The rom_data->class_hi test failed
> when it shouldn?t have?
> 

What VGA are you using? Is it reporting wrong class code?

Is it the case that 4) failed so 3)failed too?

>  
> 
> The VGA support is very cool.  Thanks to all who made it work.
> 

Do you have any patch that have to be commit to the tree?
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From ollie at lanl.gov  Mon Aug 29 06:21:39 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Sun, 28 Aug 2005 22:21:39 -0600
Subject: [LinuxBIOS] [patch] LINUXBIOS_ASSEMBLER & GCC_INC_DIR definitions
In-Reply-To: <4311E949.7080006@magic.fr>
References: <4311E949.7080006@magic.fr>
Message-ID: <1125289300.5280.6.camel@logarithm.lanl.gov>

On Sun, 2005-08-28 at 18:41 +0200, magicfox wrote:
> Hi,
> 
> 1. If assembler version string contain parentheses like 
> (i686-pc-linux-gnu), it breaks bash on Makefile.
> 
> 2. No gcc message language depend of GCC_INC_DIR definition.
> 
> src_config.patch corrects items 1-2 vs last svn revision 2009 .
> 
> I have also a problem with udelay in ibm/e325 make
> 
> ...
> /LinuxBIOSv2/src/mainboard/ibm/e325/auto.c -o auto.inc
> delay.c:9.1:
> udelay already defined
> make[1]: *** [auto.inc] Error 1
> 

??? Somebody "fixed" the problem in the wrong way?

> Please, can somebody help ?
> 
> Best regards
> 
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From Narahari.Narasimhaiah at honeywell.com  Mon Aug 29 08:05:13 2005
From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10))
Date: Sun, 28 Aug 2005 23:05:13 -0700
Subject: [LinuxBIOS] Building LinuxBIOS
Message-ID: <77ED2BF75D59D1439F90412CC5B10974238ABEFB@ie10-sahara.hiso.honeywell.com>


Hi everybody,

I have got LinuxBIOS v2 from the net. Can any body tell me how to build it
for sc2200 geode processor?

With regards
narahari

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

From magicfox at magic.fr  Mon Aug 29 09:45:38 2005
From: magicfox at magic.fr (magicfox)
Date: Mon, 29 Aug 2005 09:45:38 +0200
Subject: [LinuxBIOS] [patch] LINUXBIOS_ASSEMBLER & GCC_INC_DIR definitions
In-Reply-To: <1125289300.5280.6.camel@logarithm.lanl.gov>
References: <4311E949.7080006@magic.fr>
	<1125289300.5280.6.camel@logarithm.lanl.gov>
Message-ID: <4312BD22.6000703@magic.fr>

Li-Ta Lo wrote :
> ??? Somebody "fixed" the problem in the wrong way?
> 
Of course me ! ;-)

I have to define udelay for emulation/qemu-i386,
else i get:
mainboard/emulation/qemu-i386/auto.c -o auto.inc
delay.c:6.23:
udelay undeclared
make[1]: *** [auto.inc] Error 1

ibm/e325 compile fine with original svn version 2009
What is the good way to correct problem with udelay ?

My last patch wasn't correct string version containing "'" who is 
breaking make process.
This new one do that. Please test it and apply.

Best regards


--- LinuxBIOSv2/src/config/Config.lb.orig	Tue Aug  2 18:28:38 2005
+++ LinuxBIOSv2/src/config/Config.lb	Sun Aug 28 23:15:50 2005
@@ -4,7 +4,7 @@

  makedefine CPP:= $(CC) -x assembler-with-cpp -DASSEMBLY -E
  makedefine LIBGCC_FILE_NAME := $(shell $(CC) -print-libgcc-file-name)
-makedefine GCC_INC_DIR := $(shell $(CC) -print-search-dirs | sed -ne 
"s/install: \(.*\)/\1include/gp")
+makedefine GCC_INC_DIR := $(shell $(CC) -print-search-dirs | sed -ne 
'1s/.* \(.*\)/\1include/p')

  makedefine CPPFLAGS := -I$(TOP)/src/include 
-I$(TOP)/src/arch/$(ARCH)/include -I$(GCC_INC_DIR) $(CPUFLAGS)
  makedefine CFLAGS := $(CPU_OPT) $(CPPFLAGS) -Os -nostdinc -nostdlib 
-fno-builtin  -Wall
--- LinuxBIOSv2/src/config/Options.lb.orig	Wed Aug 24 11:59:46 2005
+++ LinuxBIOSv2/src/config/Options.lb	Sun Aug 28 23:55:59 2005
@@ -152,7 +152,7 @@
  	comment "Build linker"
  end
  define LINUXBIOS_ASSEMBLER
-	default "$(shell  touch dummy.s ; $(CC) -c -Wa,-v dummy.s 2>&1; rm -f 
dummy.s dummy.o )"
+	default "$(shell  touch dummy.s ; $(CC) -c -Wa,-v dummy.s 2>&1 | sed 
-e 's/(.*)//g' -e \"s/'//g\"; rm -f dummy.s dummy.o )"
  	export always
  	format "\"%s\""
  	comment "Build assembler"



From Stephen.Kimball at bench.com  Mon Aug 29 17:44:16 2005
From: Stephen.Kimball at bench.com (Stephen.Kimball at bench.com)
Date: Mon, 29 Aug 2005 11:44:16 -0400
Subject: [LinuxBIOS] VGA support
Message-ID: <30ADB28314F8B744AB478FB5EDA044B30D3C28@nh-ex01.bench.com>


On Monday, August 29, 2005 12:19 AM, ollie at lanl.gov wrote:
 
> > 3)       The VGA support page should have a suggestion to check to see
> > that PCI bridges are set to enable forwarding of VGA memory mapped
> > I/O.
> > 
> Isn't it been build into the device enumeration code? Isn't the code
> in allocate_vga_resource sufficient?

I'm using the CK804, which has a PCI-to-PCI bridge to the VGA PCI card.
The CK804 code just happens to write the bit to enable the P2P bridge to claim all the legacy VGA addresses.  I'm not sure where it's written.  No, this is not done in allocate_vga_resource.  It's not conditionally compiled with CONFIG_CONSOLE_VGA. 

> > 4)       I needed to change src/devices/pci_rom.c in pci_rom_load() at
> > about line 88 to force the VGA ROM to be copied to
> > PCI_VGA_RAM_IMAGE_START (0xC0000).  The rom_data->class_hi test failed
> > when it shouldn't have?
> > 
>
> What VGA are you using? Is it reporting wrong class code?

I'm using a Tseng VGA card.  Here is the log output I got:

PCI: 02:06.0 init
rom address for PCI: 02:06.0 = fd000000
PCI Expansion ROM, signature 0xaa55,
        INIT size 0x8000, data ptr 0x0020
PCI ROM Image, Vendor 100c, Device 3208,
PCI ROM Image,  Class Code 000003, Code Type 00
Class Code mismatch ROM 00000003, dev 00030000
rom_data->class_hi=0 equal to 300??  <-------- I added this print message
pci_rom_load, copying non-VGA ROM Image from fd000000 to d0000, 8000 bytes
halt_sys: file /home/sjk/design_082305/freebios2-3/src/devices/emulator/x86emu/ops.c, line 4400
Devices initialized

>
> Do you have any patch that have to be commit to the tree?

I'd like to submit a lot of CK804 code with comments, but we haven't reviewed the changes with nVidia.  It probably has too many comments to pass a review. 

Steve



From ollie at lanl.gov  Mon Aug 29 18:17:13 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon, 29 Aug 2005 10:17:13 -0600
Subject: [LinuxBIOS] [patch] LINUXBIOS_ASSEMBLER & GCC_INC_DIR definitions
In-Reply-To: <4312BD22.6000703@magic.fr>
References: <4311E949.7080006@magic.fr>
	<1125289300.5280.6.camel@logarithm.lanl.gov>
	<4312BD22.6000703@magic.fr>
Message-ID: <1125332233.5276.2.camel@logarithm.lanl.gov>

On Mon, 2005-08-29 at 09:45 +0200, magicfox wrote:
> Li-Ta Lo wrote :
> > ??? Somebody "fixed" the problem in the wrong way?
> > 
> Of course me ! ;-)
> 
> I have to define udelay for emulation/qemu-i386,
> else i get:
> mainboard/emulation/qemu-i386/auto.c -o auto.inc
> delay.c:6.23:
> udelay undeclared
> make[1]: *** [auto.inc] Error 1
> 
> ibm/e325 compile fine with original svn version 2009
> What is the good way to correct problem with udelay ?
> 
> My last patch wasn't correct string version containing "'" who is 
> breaking make process.
> This new one do that. Please test it and apply.
> 
> Best regards
> 

I am no expert in seg/regex, are you sure your fix works for some other
language environment too? Someone in some Taiwanese mainboard company
met the same problem a few days ago.

> 
> --- LinuxBIOSv2/src/config/Config.lb.orig	Tue Aug  2 18:28:38 2005
> +++ LinuxBIOSv2/src/config/Config.lb	Sun Aug 28 23:15:50 2005
> @@ -4,7 +4,7 @@
> 
>   makedefine CPP:= $(CC) -x assembler-with-cpp -DASSEMBLY -E
>   makedefine LIBGCC_FILE_NAME := $(shell $(CC) -print-libgcc-file-name)
> -makedefine GCC_INC_DIR := $(shell $(CC) -print-search-dirs | sed -ne 
> "s/install: \(.*\)/\1include/gp")
> +makedefine GCC_INC_DIR := $(shell $(CC) -print-search-dirs | sed -ne 
> '1s/.* \(.*\)/\1include/p')
> 
>   makedefine CPPFLAGS := -I$(TOP)/src/include 
> -I$(TOP)/src/arch/$(ARCH)/include -I$(GCC_INC_DIR) $(CPUFLAGS)
>   makedefine CFLAGS := $(CPU_OPT) $(CPPFLAGS) -Os -nostdinc -nostdlib 
> -fno-builtin  -Wall
> --- LinuxBIOSv2/src/config/Options.lb.orig	Wed Aug 24 11:59:46 2005
> +++ LinuxBIOSv2/src/config/Options.lb	Sun Aug 28 23:55:59 2005
> @@ -152,7 +152,7 @@
>   	comment "Build linker"
>   end
>   define LINUXBIOS_ASSEMBLER
> -	default "$(shell  touch dummy.s ; $(CC) -c -Wa,-v dummy.s 2>&1; rm -f 
> dummy.s dummy.o )"
> +	default "$(shell  touch dummy.s ; $(CC) -c -Wa,-v dummy.s 2>&1 | sed 
> -e 's/(.*)//g' -e \"s/'//g\"; rm -f dummy.s dummy.o )"
>   	export always
>   	format "\"%s\""
>   	comment "Build assembler"
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From magicfox at magic.fr  Mon Aug 29 20:41:25 2005
From: magicfox at magic.fr (magicfox)
Date: Mon, 29 Aug 2005 20:41:25 +0200
Subject: [LinuxBIOS] [patch] LINUXBIOS_ASSEMBLER & GCC_INC_DIR	definitions
In-Reply-To: <1125332233.5276.2.camel@logarithm.lanl.gov>
References: <4311E949.7080006@magic.fr>
	<1125289300.5280.6.camel@logarithm.lanl.gov>
	<4312BD22.6000703@magic.fr>
	<1125332233.5276.2.camel@logarithm.lanl.gov>
Message-ID: <431356D5.7080204@magic.fr>

Li-Ta Lo wrote :
> I am no expert in seg/regex, are you sure your fix works for some other
> language environment too? Someone in some Taiwanese mainboard company
> met the same problem a few days ago.

Hi,

I quite sure because,

- for GCC_INC_DIR definition, i get the include path on the first line 
of "$(CC) -print-search-dirs" without any language reference string.

- for LINUXBIOS_ASSEMBLER, i strip any "(...)" and any "'" in string 
version causing a problem in my case of french version.
May be other string versions may be affected but not in my case.

Best regards
Thierry



From gwatson at lanl.gov  Mon Aug 29 21:08:00 2005
From: gwatson at lanl.gov (Greg Watson)
Date: Mon, 29 Aug 2005 13:08:00 -0600
Subject: [LinuxBIOS] RE: Does LinuxBIOS support the Mac Mini?
In-Reply-To: <b8d3f3f268820c39809a6b49ebdec9a7@macnews.de>
References: <b8d3f3f268820c39809a6b49ebdec9a7@macnews.de>
Message-ID: <5352A236-791A-4AB5-9BBF-E8B27424C50A@lanl.gov>

The short answer to your question is no, it's not supported. If the  
mini is like other Apple machines then getting chipset documentation  
is impossible. Of course, with the appropriate documentation, a mini  
port would be relatively straight forward.

Greg

On Aug 26, 2005, at 8:00 AM, Angel wrote:

> Well, the wiki says it supports the PPC series MPC74xx, MPC4xx and  
> MPC7xx. The CPU built in the Mac Mini is a MPC7447 (revision B I  
> believe), so I think it should be supported, shouldn't it?
> The wiki also says the Motorola northbridge MPC107 is supported.  
> According to this page ( http://e-www.motorola.com/webapp/sps/site/ 
> prod_summary.jsp?code=MPC107 ) this chipset seems to be only  
> suitable for older CPU up to the MPC7410. I couldn't find any  
> information about the chipset used in the Mac Mini. But as Apple is  
> just an OEM, it should be from Motorola/Freescale as well.
>
>
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
>




From dfeustel at verizon.net  Mon Aug 29 22:31:16 2005
From: dfeustel at verizon.net (Dave Feustel)
Date: Mon, 29 Aug 2005 15:31:16 -0500
Subject: [LinuxBIOS] Disk Passwords
Message-ID: <200508291531.16808.dfeustel@verizon.net>

Does Linux Bios support use of the disk user/administrative passwords and the 'freeze' function
as defined in the ATA specs?

Does Linux Bios boot OpenBSD?

Thanks,
Dave Feustel
-- 
Tired of having to defend against Malware?
(You know: trojans, viruses, SPYWARE, ADWARE, 
KEYLOGGERS, rootkits, worms and popups) 
Then Switch to OpenBSD with a KDE desktop!!!



From dfeustel at verizon.net  Mon Aug 29 23:26:45 2005
From: dfeustel at verizon.net (Dave Feustel)
Date: Mon, 29 Aug 2005 16:26:45 -0500
Subject: [LinuxBIOS] Disk Passwords
In-Reply-To: <200508291531.16808.dfeustel@verizon.net>
References: <200508291531.16808.dfeustel@verizon.net>
Message-ID: <200508291626.46173.dfeustel@verizon.net>

On Monday 29 August 2005 15:31, Dave Feustel wrote:
> Does Linux Bios support use of the disk user/administrative passwords and the 'freeze' function
> as defined in the ATA specs?
> 
> Does Linux Bios boot OpenBSD?
 
Followup Question: Does LinuxBios support AMD -X2 processors?

Thanks Again,
Dave Feustel
-- 
Tired of having to defend against Malware?
(You know: trojans, viruses, SPYWARE, ADWARE, 
KEYLOGGERS, rootkits, worms and popups) 
Then Switch to OpenBSD with a KDE desktop!!!



From Narahari.Narasimhaiah at honeywell.com  Tue Aug 30 10:32:39 2005
From: Narahari.Narasimhaiah at honeywell.com (Narahari, Narasimhaiah (IE10))
Date: Tue, 30 Aug 2005 01:32:39 -0700
Subject: [LinuxBIOS] Building LinuxBIOS
Message-ID: <77ED2BF75D59D1439F90412CC5B1097423A007CD@ie10-sahara.hiso.honeywell.com>


Hi everyone,

I have downloaded the LinuxBIOSv2.
I tried to build the target image by issuing <./buildtarget amb/solo>
command. The output as follows:

****************************************************************************
************************
$ ./buildtarget amd/solo
build_dir=amd/quartet/quartet
No linuxbios config script found. Rebuilding it..
C:\cygwin\bin\python.exe: can't open file
'/cygdrive/d/freebios-NWS-docs/LinuxBI
OS_downloaded/LinuxBIOS_most_recent/LinuxBIOSv2/util/newconfig/yapps2.py'
C:\cygwin\bin\python.exe: can't open file 'amd/quartet/quartet/config.py'
****************************************************************************
*************************

Please let me know how do I generate the config files?

Looking forward,
With regards,
narahari
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20050830/7e156c45/attachment.html>

From stepan at openbios.org  Tue Aug 30 10:38:30 2005
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue, 30 Aug 2005 10:38:30 +0200
Subject: [LinuxBIOS] Building LinuxBIOS
In-Reply-To: <77ED2BF75D59D1439F90412CC5B1097423A007CD@ie10-sahara.hiso.honeywell.com>
References: <77ED2BF75D59D1439F90412CC5B1097423A007CD@ie10-sahara.hiso.honeywell.com>
Message-ID: <20050830083830.GA32084@openbios.org>

* Narahari, Narasimhaiah (IE10) <Narahari.Narasimhaiah at honeywell.com> [050830 10:32]:
> 
> Hi everyone,
> 
> I have downloaded the LinuxBIOSv2.
> I tried to build the target image by issuing <./buildtarget amb/solo> command.
> The output as follows:
 

Using Windows to build LinuxBIOS is not supported at the moment.

> C:\cygwin\bin\python.exe: can't open file '/cygdrive/d/freebios-NWS-docs/LinuxBIOS_downloaded/LinuxBIOS_most_recent/LinuxBIOSv2/util/newconfig/yapps2.py'
> C:\cygwin\bin\python.exe: can't open file 'amd/quartet/quartet/config.py'

LinuxBIOSv2/util/newconfig/yapps2.py should be there.. Is your checkout
complete? 

> *****************************************************************************************************
> 
> Please let me know how do I generate the config files?
 
Use Linux.

Stefan






From smithbone at gmail.com  Tue Aug 30 10:59:22 2005
From: smithbone at gmail.com (Richard Smith)
Date: Tue, 30 Aug 2005 03:59:22 -0500
Subject: [LinuxBIOS] Building LinuxBIOS
In-Reply-To: <20050830083830.GA32084@openbios.org>
References: <77ED2BF75D59D1439F90412CC5B1097423A007CD@ie10-sahara.hiso.honeywell.com>
	<20050830083830.GA32084@openbios.org>
Message-ID: <8a0c367805083001591b8f4274@mail.gmail.com>

> >
> > Please let me know how do I generate the config files?
> 
> Use Linux.

We should probally add a 'Supported hosts'  or 'known-to-work' build
hosts to the wiki.  If nothing else then a warning that windows and
cygwin are  uncharted territory and not much effort has gone into
supporting them.

-- 
Richard A. Smith



From klt29 at freemail.hu  Tue Aug 30 11:06:13 2005
From: klt29 at freemail.hu (skb tdf)
Date: Tue, 30 Aug 2005 11:06:13 +0200 (CEST)
Subject: [LinuxBIOS] Compilation error (vga_fixup and mdelay)
Message-ID: <freemail.20050730110613.76502@fm10.freemail.hu>

Hello,

I'm a newbie with LinuxBIOS. I would like to make
LinuxBIOSv2 working on VIA EPIA-MII. Unfortunately I can't
compile from the source. I tried to make it based on
LinuxBIOS-AMD64.eps.

buildtarget via/epia-m

seems to be success but 'make' in via/epia-m/epia-m fails
with the following message:

crt0.S: Assembler messages:
crt0.S:166: Warning: indirect jmp without `*'
linuxbios_ram.o(.text+0x8bc): In function `vga_fixup':
: undefined reference to `setup_realmode_idt'
linuxbios_ram.o(.text+0x8cd): In function `vga_fixup':
: undefined reference to `do_vgabios'
linuxbios_ram.o(.text+0x8e0): In function `vga_fixup':
: undefined reference to `vga_enable_console'
linuxbios_ram.o(.text+0x22e1): In function `mdelay':
: undefined reference to `udelay'
collect2: ld returned 1 exit status
make[1]: *** [linuxbios_ram] Error 1
make: *** [normal/linuxbios.rom] Error 1

The case is same if I try to run

util/abuild.sh via/epia-m

Is there a description/doc/help how to build the bios?
Or is there some ready-to-burn binary image for VIA EPIA-MII?

Thx,

Sza2


_______________________________________________________________________
[freemail] extra 1GB-os postafi?kkal, ?nnek m?r van? http://freemail.hu





From noodles at earth.li  Tue Aug 30 11:11:56 2005
From: noodles at earth.li (Jonathan McDowell)
Date: Tue, 30 Aug 2005 10:11:56 +0100
Subject: [LinuxBIOS] Compilation error (vga_fixup and mdelay)
In-Reply-To: <freemail.20050730110613.76502@fm10.freemail.hu>
References: <freemail.20050730110613.76502@fm10.freemail.hu>
Message-ID: <20050830091155.GB2742@earth.li>

On Tue, Aug 30, 2005 at 11:06:13AM +0200, skb tdf wrote:
> I'm a newbie with LinuxBIOS. I would like to make
> LinuxBIOSv2 working on VIA EPIA-MII. Unfortunately I can't
> compile from the source. I tried to make it based on
> LinuxBIOS-AMD64.eps.
> 
> buildtarget via/epia-m
> 
> seems to be success but 'make' in via/epia-m/epia-m fails
> with the following message:
> 
> crt0.S: Assembler messages:
> crt0.S:166: Warning: indirect jmp without `*'
> linuxbios_ram.o(.text+0x8bc): In function `vga_fixup':
> : undefined reference to `setup_realmode_idt'
> linuxbios_ram.o(.text+0x8cd): In function `vga_fixup':
> : undefined reference to `do_vgabios'
> linuxbios_ram.o(.text+0x8e0): In function `vga_fixup':
> : undefined reference to `vga_enable_console'
> linuxbios_ram.o(.text+0x22e1): In function `mdelay':
> : undefined reference to `udelay'
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios_ram] Error 1
> make: *** [normal/linuxbios.rom] Error 1
> 
> The case is same if I try to run
> 
> util/abuild.sh via/epia-m
> 
> Is there a description/doc/help how to build the bios?
> Or is there some ready-to-burn binary image for VIA EPIA-MII?

EPIA-M(II) currently doesn't compile; like many other ports it has the
udelay problem. I've been meaning to run through all the svn commits
to try and find the one that broke this, but haven't had the time. I
thought Ollie knew how to fix this, but I haven't seen any reply from
anyone to the various queries asking about it.

J.

-- 
 [      A bug in the hand is better than one as yet undetected.       ]
 [ http://www.blackcatnetworks.co.uk/ - IPv6 enabled ADSL/dialup/colo ]



From spidermantm at freenet.de  Tue Aug 30 11:30:32 2005
From: spidermantm at freenet.de (spidermantm at freenet.de)
Date: Tue, 30 Aug 2005 11:30:32 +0200
Subject: [LinuxBIOS] BIOS
Message-ID: <E1EA2Rs-00052W-Lk@www3.emo.freenet-rz.de>

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


BIOS is BIOS
no matter if you use Linux or Unix or WindowsXP
XP is unix !

and me tried eternally times to get out of this list . . .
spiderman getting cobwebbed or what ???
meow.

wish to you what.
sincerely
and thank you for seeing that
puting is not the essence of life








From steve at digidescorp.com  Tue Aug 30 16:06:35 2005
From: steve at digidescorp.com (Steven J. Magnani)
Date: Tue, 30 Aug 2005 09:06:35 -0500
Subject: [LinuxBIOS] Building LinuxBIOS
Message-ID: <000401c5ad6c$0b20cf60$6ffea8c0@banana>

> Using Windows to build LinuxBIOS is not supported at the moment.

I've built LB under cygwin for several months, without problems. The
only three 'issues' I recall were (1) needing to install the cygwin
version of python, (I had tried the Windows version first), (2) needing
to install a cross-compiler (i.e. i686-linux-gnu) to compile properly,
and (3) needing cmos.options to be in UNIX format ('\n') not DOS
('\r\n').

The cross-compiler can be generated pretty easily using Dan Kegel's
crosstool (http://kegel.com/crosstool).

When I try to compile amd/quartet or amd/solo (on Linux OR cygwin) I get
the following error:

    incoherent_ht.c:153.7: 
    bad type specifier (
    make[1]: *** [auto.inc] Error 1

...but this is different than narahari's issue and probably something in
the source code that needs changing.

------------------------------------------------------------------------
 Steven J. Magnani               "I claim this network for MARS!
 www.digidescorp.com              Earthling, return my space modulator!"
 
 #include <standard.disclaimer>








From cro_marmot at comcast.net  Wed Aug 31 00:29:20 2005
From: cro_marmot at comcast.net (David Hendricks)
Date: Tue, 30 Aug 2005 16:29:20 -0600
Subject: [LinuxBIOS] BIOS
In-Reply-To: <E1EA2Rs-00052W-Lk@www3.emo.freenet-rz.de>
References: <E1EA2Rs-00052W-Lk@www3.emo.freenet-rz.de>
Message-ID: <20050830162920.66e18d57@sunder>

If you want off the list, go to:
http://www.linuxbios.org/mailman/listinfo/linuxbios and type in your
e-mail address at the bottom of the page and click "unsubscribe or edit
options." From there, you may unsubscribe. Mailman (The mailing list
program) will send confirmation with a link that you may then click to
permanently unsubscribe from the list.

Apologies for any inconvenience this may cause you.

On Tue, 30 Aug 2005 11:30:32 +0200
spidermantm at freenet.de wrote:

> Message
> 
> BIOS is BIOS
> no matter if you use Linux or Unix or WindowsXP
> XP is unix !
> 
> and me tried eternally times to get out of this list . . .
> spiderman getting cobwebbed or what ???
> meow.
> 
> wish to you what.
> sincerely
> and thank you for seeing that
> puting is not the essence of life
> 
> 
> 
> --



From vanag at telecom.ntua.gr  Wed Aug 31 19:50:34 2005
From: vanag at telecom.ntua.gr (Vasileios Anagnostopoulos)
Date: Wed, 31 Aug 2005 17:50:34 +0000
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <200508240041.35258.AvatarofVirgo@gmail.com>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
Message-ID: <200508311750.34880.vanag@telecom.ntua.gr>

Why don't we use VR5500A,

http://www.necel.com./micro/english/product/vr/vr5000series/index.html

it seems amazing and comes with a development kit (teacube) . Have you heard 
about it?

There is a lot of potential. We can even use

http://www.cirrus.com/en/products/pro/detail/P1061.html

which has DRM but a lot of useful features

we can also use
http://www.linuxdevices.com/news/NS7757625666.html
or
http://linuxdevices.com/news/NS7303651216.html

or

http://linuxdevices.com/news/NS2122942691.html (without the sdk of course)



From vanag at telecom.ntua.gr  Wed Aug 31 19:52:17 2005
From: vanag at telecom.ntua.gr (Vasileios Anagnostopoulos)
Date: Wed, 31 Aug 2005 17:52:17 +0000
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <200508240041.35258.AvatarofVirgo@gmail.com>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
Message-ID: <200508311752.17519.vanag@telecom.ntua.gr>

If you do not want mips/arm you can use Epia SP 13000 which can be supported 
quite easily with linuxbios !!!



From arc at Xiph.org  Wed Aug 31 17:55:06 2005
From: arc at Xiph.org (Arc)
Date: Wed, 31 Aug 2005 08:55:06 -0700
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <8a0c3678050824010517e00f14@mail.gmail.com>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
	<8a0c36780508232322699e4ae3@mail.gmail.com>
	<200508240211.36580.AvatarofVirgo@gmail.com>
	<8a0c3678050824010517e00f14@mail.gmail.com>
Message-ID: <20050831155506.GG15242@xiph.org>

On Wed, Aug 24, 2005 at 03:05:40AM -0500, Richard Smith wrote:
> 
> Well LinuxBIOS only runs on a fairly small family of chipsets.  The
> bulk of LinuxBIOS applications are in linux clusters or embedded
> systems.  Neither of which would classify as "retail hardware" unless
> you want to build game consoles out of dual Opteron boxes.  The higher
> end VIA eden boards might qualify but support for them is still under
> developement.

It can be ported.  *mantra*

> > the current XBOX cost, around $150 I think.  The XBOX360 I belive is going to
> > be close to $300 when it comes out.  So it has to be hardware that would keep
> > the over all price below the current consoles.
> 
> Going to be tough since those products are sold at a loss.

Actually I had an idea recently that I've been persuing, is a portable 
free player developed around VIA's CLE266+VT8235 chipsets.

Think of it.  Basic 3d acceleration from VIA CLE266, 640x480 lcd screen, 
slot loading cd burner+dvd, CompactFlash and CardBus slots, host usb, 
and firewire.

Could:
 * Play audio CDs and Ogg Vorbis (and others)
 * Rip audio CDs to CompactFlash
 * Watch DVDs
 * Play huge games (dvd sized!) 
 * Play multiplayer-network games via cardbus WIFI
 * Connect to USB keyboard/mouse to use as mini-laptop
 * Connect to TV and USB controllers for home use
 * Can download games and burn to CD

Can't beat the price of many handheld game players (Sony PSP $190, while 
this would cost closer to $350) but when you consider the cost of a 
seperate music player, the larger screen, and (this is the key to it)... 
you - don't have to pay $35/game!

Consider that, if the free software game community grows, with say 20 
"commercial quality" games and a few hundred smaller ones, the system 
beats the mainstream systems' price after just a few games.

To reduce cost (about $80) the CD drive could be an add-on option, 
plugging onto the bottom of the unit, leaving the unit smaller and under 
$300.  Plus, then a harddrive add-on could be produced as well. :-)

And as was suggested earlier in the thread, the circuit, case, etc could 
be under the GPL just like the GumStix, with the BIOS being GPL'ed, etc.  
allowing multiple manufacturers to produce these units.

I think the market is ready for a portable unit you can play at home, 
and which *CAN* but doesn't nessesarily have to be your portable music 
player too, which can run any number of different games, not just those 
which are licensed through a central authority.



From smithbone at gmail.com  Wed Aug 31 18:27:16 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 31 Aug 2005 11:27:16 -0500
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <20050831155506.GG15242@xiph.org>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
	<8a0c36780508232322699e4ae3@mail.gmail.com>
	<200508240211.36580.AvatarofVirgo@gmail.com>
	<8a0c3678050824010517e00f14@mail.gmail.com>
	<20050831155506.GG15242@xiph.org>
Message-ID: <8a0c367805083109277445e922@mail.gmail.com>

> And as was suggested earlier in the thread, the circuit, case, etc could
> be under the GPL just like the GumStix, with the BIOS being GPL'ed, etc.
> allowing multiple manufacturers to produce these units.
> 
> I think the market is ready for a portable unit you can play at home,
> and which *CAN* but doesn't nessesarily have to be your portable music
> player too, which can run any number of different games, not just those
> which are licensed through a central authority.

Oh.  I agree.  Look athe the success of projects like MythTV in fact I
would suggest that MythTV is a very good base to start since it has
really good media support all ready.

I don't want to discourage development at all.  A GPL game console
would be excellent and a great feather in the cap of LinuxBIOS.

Just don't be thinking you are going to get the same kind of
performance you get from a commercial unit without spending 2 to 3x
what they cost.  Haveing really a reallly good software engine may
help to minimize this but to get a _really_ good software engine you
have to have good knowledge of the hardware.  With the current
graphics landscape thats hard and boderline impossible to get.

One glimmer of hope. If you can work with these guys

http://lists.duskglow.com/mailman/listinfo/open-graphics

you might actually be able to drive a small market for it.

I'm interested in it since Bitworks is capable of producing board runs
on the level you are talking about.  Say like 25 - 100 units.  You can
do like the MegaSquirt people do.  Start an escrow account and take
orders until you get enough that you can have it built.  If the
schematics, and gerbers, and BOM are alreday done then thats a lot of
the cost of having a custom run built.

Of course whoever does the prototype(s) is going to pay a chunk. 
Perhaps you could seek some funding somewhere?  Most of the groundwork
issues could be worked out with COTS stuff thats available already.

-- 
Richard A. Smith



From bari at onelabs.com  Wed Aug 31 19:19:09 2005
From: bari at onelabs.com (Bari Ari)
Date: Wed, 31 Aug 2005 12:19:09 -0500
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <200508311750.34880.vanag@telecom.ntua.gr>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
	<200508311750.34880.vanag@telecom.ntua.gr>
Message-ID: <4315E68D.1070806@onelabs.com>

Vasileios Anagnostopoulos wrote:
> Why don't we use VR5500A,
> 
> http://www.necel.com./micro/english/product/vr/vr5000series/index.html

No 3-D graphics. NEC did have a nice 3d graphics accelerator that was 
used mainly in the Sega Dreamcast along with a Hitach SH-4 back in 2000.

The SH-5 is nice but only available as a core. SH-6 and 7 also looked 
great on paper - Fast cores, memory and FPU's.

> http://www.cirrus.com/en/products/pro/detail/P1061.html

No floating point or 3D graphics here again, 200MHz core, 100MHz shared 
bus for SDRAM and I/O. If it's around $5 like some Freescale iMX's
http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=01J4Fs2973
it might be nice for a handheld version of a game unit.

> http://www.linuxdevices.com/news/NS7757625666.html
> http://linuxdevices.com/news/NS7303651216.html
> http://linuxdevices.com/news/NS2122942691.html (without the sdk of course)

3D graphics support would be weak here again since the PCI bus would be 
choked by a 3D graphics controller hung off of it.

Network, sound, MPEG-2,3,4, playback and even some recording is working 
pretty well on several ARM, Mips and SH platforms.

The weak spot is always 3D graphics performance. Even the Intel PXA's 
with the 2700G accelerator 
http://developer.intel.com/design/pca/prodbref/300571.htm
performs at the level of a several generations old ATI or Nvidia controller.

ST Nomadik has lots to offer as well but weak in 3D graphics support
http://www.st.com/stonline/products/literature/bd/11196/stn8810.pdf

as does the Philips Nexperia's
http://www.semiconductors.philips.com/products/nexperia/index.html

and Equator
http://www.equator.com/

lots of multimedia to offer as well but weak in or without 3D graphics 
support.

Just my humble opinion, I could be wrong.

-Bari



From bari at onelabs.com  Wed Aug 31 19:24:33 2005
From: bari at onelabs.com (Bari Ari)
Date: Wed, 31 Aug 2005 12:24:33 -0500
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <200508311752.17519.vanag@telecom.ntua.gr>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
	<200508311752.17519.vanag@telecom.ntua.gr>
Message-ID: <4315E7D1.9020703@onelabs.com>

Vasileios Anagnostopoulos wrote:
> If you do not want mips/arm you can use Epia SP 13000 which can be supported 
> quite easily with linuxbios !!!

SP 13000 support is in the works.

epiOS is a Linux package with all the Epia driver support and tweaks:
http://www.epios.net/

Unichrome 3-D graphics support is already there with all the open source 
to the 3d and Mpeg accelerator libraries.
http://unichrome.sourceforge.net/

-Bari



From bari at onelabs.com  Wed Aug 31 19:55:22 2005
From: bari at onelabs.com (Bari Ari)
Date: Wed, 31 Aug 2005 12:55:22 -0500
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <20050831155506.GG15242@xiph.org>
References: <200508240041.35258.AvatarofVirgo@gmail.com>	<8a0c36780508232322699e4ae3@mail.gmail.com>	<200508240211.36580.AvatarofVirgo@gmail.com>	<8a0c3678050824010517e00f14@mail.gmail.com>
	<20050831155506.GG15242@xiph.org>
Message-ID: <4315EF0A.30308@onelabs.com>

Arc wrote:
> Consider that, if the free software game community grows, with say 20 
> "commercial quality" games and a few hundred smaller ones, the system 
> beats the mainstream systems' price after just a few games.
> 
> To reduce cost (about $80) the CD drive could be an add-on option, 
> plugging onto the bottom of the unit, leaving the unit smaller and under 
> $300.  Plus, then a harddrive add-on could be produced as well. :-)
> 
> And as was suggested earlier in the thread, the circuit, case, etc could 
> be under the GPL just like the GumStix, with the BIOS being GPL'ed, etc.  
> allowing multiple manufacturers to produce these units.
> 
> I think the market is ready for a portable unit you can play at home, 
> and which *CAN* but doesn't nessesarily have to be your portable music 
> player too, which can run any number of different games, not just those 
> which are licensed through a central authority.
> 

We've designed several systems like this in the past that were either 
handheld, STB, aerospace or automotive/telematics based on mips, arm, SH 
and x86.

Software support has always been the issue. It used to be a problem 
getting Linux to support all the multimedia. Now multimedia on Linux is 
working quite well.

You'll still need to get the interest of the game developers. Can they 
be made happy selling $5-$10 games if they need to invest millions in 
development to make the games exciting enough for players to buy?

-Bari



From smithbone at gmail.com  Wed Aug 31 20:38:09 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 31 Aug 2005 13:38:09 -0500
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <4315E68D.1070806@onelabs.com>
References: <200508240041.35258.AvatarofVirgo@gmail.com>
	<200508311750.34880.vanag@telecom.ntua.gr>
	<4315E68D.1070806@onelabs.com>
Message-ID: <8a0c367805083111382f4ea6d0@mail.gmail.com>

> 
> ST Nomadik has lots to offer as well but weak in 3D graphics support
> http://www.st.com/stonline/products/literature/bd/11196/stn8810.pdf

I've had a pretty piss poor experience with STPC and ST.  So i'd have
to recommend against any of thier products.
 
> as does the Philips Nexperia's
> http://www.semiconductors.philips.com/products/nexperia/index.html

I'm currently in the tail end of a large project that uses the PNX1500
and I can 100% say that working with this chip would be a large
undertaking.  The developement system _sucks_.  One of the worst I've
used.  You thought a LinuxBIOS setup and compile was difficult
somtimes.  Its a breeze compared to the Phillips PNX stuff.  Imagine
if linux bios was 5 times its current size and the entire build system
was written in perl.

All of the example source and system libraries come with headers that
explictly forbid using the code or library in conjunction with _any_
open source type code.  On top of that the chip (1500) is buggy.

All that said its a hauling ass video processing chip.  We are doing
realtime MPEG video encoding with it.  But dosen't have any 3D
graphics capabilities.

TrollTech has some sort of linux offering for the Nexperia phone
platform but I've not looked at it.

-- 
Richard A. Smith



From bari at onelabs.com  Wed Aug 31 21:00:11 2005
From: bari at onelabs.com (Bari Ari)
Date: Wed, 31 Aug 2005 14:00:11 -0500
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <8a0c367805083111382f4ea6d0@mail.gmail.com>
References: <200508240041.35258.AvatarofVirgo@gmail.com>	
	<200508311750.34880.vanag@telecom.ntua.gr>	
	<4315E68D.1070806@onelabs.com>
	<8a0c367805083111382f4ea6d0@mail.gmail.com>
Message-ID: <4315FE3B.9010502@onelabs.com>

Richard Smith wrote:

> I'm currently in the tail end of a large project that uses the PNX1500
> and I can 100% say that working with this chip would be a large
> undertaking.  The developement system _sucks_.  One of the worst I've
> used.  You thought a LinuxBIOS setup and compile was difficult
> somtimes.  Its a breeze compared to the Phillips PNX stuff.  Imagine
> if linux bios was 5 times its current size and the entire build system
> was written in perl.
> 
> All of the example source and system libraries come with headers that
> explictly forbid using the code or library in conjunction with _any_
> open source type code.  On top of that the chip (1500) is buggy.
> 
> All that said its a hauling ass video processing chip.  We are doing
> realtime MPEG video encoding with it.  But dosen't have any 3D
> graphics capabilities.

Linux on the Nomadik and the Nexperia's would be lot's of work with 
little support I agree. Philips never seems to release any source.

To bad SH never evolved since they had great floating point units. SH-6 
or 7's with PCIe and larger caches would be great for multimedia and 
clusters.
http://www.eetimes.com/story/OEG20020118S0007

ARM has lots of Linux support but I have never found production silicon 
of an ARM core with FPU's and PCIe.

http://www.arm.linux.org.uk/
http://www.arm.com/

-Bari



From talbotx at comcast.net  Wed Aug 31 21:01:12 2005
From: talbotx at comcast.net (Adam Talbot)
Date: Wed, 31 Aug 2005 12:01:12 -0700
Subject: [LinuxBIOS] Open Gaming Console
In-Reply-To: <8a0c367805083111382f4ea6d0@mail.gmail.com>
References: <200508240041.35258.AvatarofVirgo@gmail.com>	<200508311750.34880.vanag@telecom.ntua.gr>	<4315E68D.1070806@onelabs.com>
	<8a0c367805083111382f4ea6d0@mail.gmail.com>
Message-ID: <4315FE78.8010900@comcast.net>

Would there be any thing wrong with using something along the lines of a 
SFF based computer. Something like.
http://global.shuttle.com/Product/barebone/brb_OverView.asp?B_id=26

Some of the older systems are cheap, and we dont need buy/build a nice 
case and power supply. The box comes in at around $180 for the case, 
power supply and motherboard. I dont think we will be able to build an 
itx based system for less. These systems are very fast and allows for us 
to use any graphics card we want. 
Just an idea.

-Adam Talbot


Richard Smith wrote:

>>ST Nomadik has lots to offer as well but weak in 3D graphics support
>>http://www.st.com/stonline/products/literature/bd/11196/stn8810.pdf
>>    
>>
>
>I've had a pretty piss poor experience with STPC and ST.  So i'd have
>to recommend against any of thier products.
> 
>  
>
>>as does the Philips Nexperia's
>>http://www.semiconductors.philips.com/products/nexperia/index.html
>>    
>>
>
>I'm currently in the tail end of a large project that uses the PNX1500
>and I can 100% say that working with this chip would be a large
>undertaking.  The developement system _sucks_.  One of the worst I've
>used.  You thought a LinuxBIOS setup and compile was difficult
>somtimes.  Its a breeze compared to the Phillips PNX stuff.  Imagine
>if linux bios was 5 times its current size and the entire build system
>was written in perl.
>
>All of the example source and system libraries come with headers that
>explictly forbid using the code or library in conjunction with _any_
>open source type code.  On top of that the chip (1500) is buggy.
>
>All that said its a hauling ass video processing chip.  We are doing
>realtime MPEG video encoding with it.  But dosen't have any 3D
>graphics capabilities.
>
>TrollTech has some sort of linux offering for the Nexperia phone
>platform but I've not looked at it.
>
>  
>




From sc at drccomputer.com  Wed Aug 31 21:10:11 2005
From: sc at drccomputer.com (Steve Casselman)
Date: Wed, 31 Aug 2005 12:10:11 -0700 (PDT)
Subject: [LinuxBIOS] Etherboot BIOS.
In-Reply-To: <20050831155506.GG15242@xiph.org>
Message-ID: <20050831191012.58276.qmail@web309.biz.mail.mud.yahoo.com>

I was wondering how difficult/useful it would be to
have a very small bios that boots enough to get on the
network and then loads the working bios from there. I
keep making little changes (printing stuff out) and it
is a pain to keep burning Roms. This would also let
you have as big a bios as you want. In a cluster you
could make a bios change just by updating one file. 

Steve



From Peter.VanEchaute at bench.com  Wed Aug 31 21:13:37 2005
From: Peter.VanEchaute at bench.com (Peter.VanEchaute at bench.com)
Date: Wed, 31 Aug 2005 15:13:37 -0400
Subject: [LinuxBIOS] PCI Express add-on cards and Expansion Roms
Message-ID: <30ADB28314F8B744AB478FB5EDA044B31182E0@nh-ex01.bench.com>

Hello All,

 

I am trying to work on getting a PCI-E card working and came across an error that I am wondering if I need to worry about.  Below shows that the VGA ROM is loading, but not the ROM from the PCI-E card (at the bottom).  Both of these cards are in slots and not onboard.  The PCI-E card is an Ethernet card.  As the device is getting a bus and resources seemingly just fine, I would think that the ROM would have been found.  My question is ... do all add-on cards need to load an expansion ROM or can they run just fine without it?  The error in question is "Incorrect Expansion ROM Header Signature ffff".

 

FYI on devices:

00:01.0 is the PCI-PCI bridge

02:06.0 is the VGA card on the PCI-PCI bridge

00:02.0 is the PCI-E bridge

04:00.0 is the ethernet card on the PCI-E bridge

 

PCI: 00:01.0 1c <- [0x0000001000 - 0x0000001fff] bus 2 io

PCI: 00:01.0 20 <- [0x00fc000000 - 0x00fdffffff] bus 2 mem

PCI: 02:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem

PCI: 02:06.0 14 <- [0x0000001000 - 0x00000010ff] io

PCI: 02:06.0 30 <- [0x00fd000000 - 0x00fdffffff] rom

 

PCI: 00:02.0 1c <- [0x0000002000 - 0x0000002fff] bus 4 io

PCI: 00:02.0 20 <- [0x00fe000000 - 0x00fe0fffff] bus 4 mem

PCI: 04:00.0 10 <- [0x00fe020000 - 0x00fe023fff] mem

PCI: 04:00.0 18 <- [0x0000002000 - 0x00000020ff] io

PCI: 04:00.0 30 <- [0x00fe000000 - 0x00fe01ffff] rom

 

 

PCI: 00:01.0 bridge ctrl <- 000b

PCI: 00:01.0 cmd <- 147

PCI: 02:06.0 cmd <- 143

 

PCI: 00:02.0 bridge ctrl <- 0007

PCI: 00:02.0 cmd <- 547

PCI: 04:00.0 cmd <- 143

 

 

PCI: 02:06.0 init

rom address for PCI: 02:06.0 = fd000000

Class Code mismatch ROM 00000003, dev 00030000

copying VGA ROM Image from fd000000 to c0000, 8000 bytes

halt_sys: file /home/vanecp/design/freebios2-3/src/devices/emulator/x86emu/ops.c

, line 4400

PCI: 04:00.0 init

rom address for PCI: 04:00.0 = fe000000

Incorrect Expansion ROM Header Signature ffff

Devices initialized

 

 

 

Cheers,
Peter Van Echaute



 

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

From smithbone at gmail.com  Wed Aug 31 21:22:43 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 31 Aug 2005 14:22:43 -0500
Subject: [LinuxBIOS] Etherboot BIOS.
In-Reply-To: <20050831191012.58276.qmail@web309.biz.mail.mud.yahoo.com>
References: <20050831155506.GG15242@xiph.org>
	<20050831191012.58276.qmail@web309.biz.mail.mud.yahoo.com>
Message-ID: <8a0c3678050831122272d12b0f@mail.gmail.com>

On 8/31/05, Steve Casselman <sc at drccomputer.com> wrote:
> I was wondering how difficult/useful it would be to

Considering its already done.  Not very.

The real question is "is the hardware you want to do this on supported?"

-- 
Richard A. Smith



From smithbone at gmail.com  Wed Aug 31 22:14:53 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 31 Aug 2005 15:14:53 -0500
Subject: [LinuxBIOS] Etherboot BIOS.
In-Reply-To: <20050831195226.12111.qmail@web311.biz.mail.mud.yahoo.com>
References: <8a0c3678050831122272d12b0f@mail.gmail.com>
	<20050831195226.12111.qmail@web311.biz.mail.mud.yahoo.com>
Message-ID: <8a0c36780508311314296ee58@mail.gmail.com>

On 8/31/05, Steve Casselman <sc at drccomputer.com> wrote:

> Yes. So I would just use linuxbios to boot and then
> use etherboot to boot the linuxbios I want (which
> would then load the kernal?) The etherboot I see being
> used is an elf loader. Is linuxbios compiled in elf
> format?

Ah.  I misread your desires.  So no I was incorrect.  Its not done.

Thats a interesting idea but I think its going to run into some
issues.  Many of the chipset registers can only be played with after
reset.

getting linuxbios build as an elf shouldn't be too hard but splitting
linuxbios up into core "only do once" and "repeatable" sections may be
more difficult.

I'm not guru enough with the ld magic to know so someone else will
have to comment.

-- 
Richard A. Smith



From yinghai.lu at amd.com  Wed Aug 31 22:24:35 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 31 Aug 2005 13:24:35 -0700
Subject: [LinuxBIOS] Etherboot BIOS.
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08A86@ssvlexmb2.amd.com>

get one USB ROM emulator...

It could be usefull etherboot to load etherboot to test ehterboot.

YH


-----Original Message-----
From: linuxbios-bounces at openbios.org on behalf of Steve Casselman
Sent: Wed 8/31/2005 12:10 PM
To: LinuxBios at openbios.org
Subject: [LinuxBIOS] Etherboot BIOS.
 
I was wondering how difficult/useful it would be to
have a very small bios that boots enough to get on the
network and then loads the working bios from there. I
keep making little changes (printing stuff out) and it
is a pain to keep burning Roms. This would also let
you have as big a bios as you want. In a cluster you
could make a bios change just by updating one file. 

Steve

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


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

From klt29 at freemail.hu  Wed Aug 31 22:28:32 2005
From: klt29 at freemail.hu (skb tdf)
Date: Wed, 31 Aug 2005 22:28:32 +0200 (CEST)
Subject: [LinuxBIOS] VIA EPIA-MII + fastboot (2.03)
Message-ID: <freemail.20050731222832.52391@fm10.freemail.hu>

Hi,

Although I know, LinuxBIOS != VIA fastboot (and mainly
closed source), I have no idea where can I get answer to my
question (There was no success on Via forum or Google).

Since LinuxBIOS can not be compile for EPIA-MII I tried to
reach my aim with fastboot (2.03). After a few hours, it
seems that system is not so far from ready, but
unfortunately still not finished. On the serial debug line I
got the following info:

...
...
...
User Routine 1:Jun 25 2004,18:02:57
VIA WINCE FastBoot/FreeBoot Loader V2.03 for EPIA-M2 Jun 25
2004,18:02:51
Zero memory:0x06000000...
User Routine 2
0,1,2,3,4,
Check DOC... fail.
Finding Primary/Master IDE...
Enter FindDevice
IssueIdentify
Identify IDE Device : Heads:16 SectorsPerTrack:63 MBLK:1
Return from (IDE_COMMAND_IDENTIFY)
Sanity check
FastBootRom:Boot from IDE device:0x31
h/w reset status byte:50
Boot partition found!
(File System ID = 0xff83)
Found file system used by Linux.(File System ID = 0x83)
User Routine 3
+init_text_mode()
-init_text_mode()
Current cursor is at (0,0)
Move loader function from rom to ram
Packet found_os = 0Set VESA VGA mode(for non-MVP4)...
Call jump_loader ()
Enter loader
ReservedRootDirSectors = 0x205, filesys_id = 0xff83
Heads = 0xfe0a, SectorsPerTrack = 0x1
BytesPerSector = 0x0, SectorsPerFat = 0x0
nkimg_cluster = 0xffffffff, nkimg_length = 0xffffffff
KernelPath = hda1:/boot/vmlinuz-m2 
found_os = 0x2
found_os = 0x2
Enter FindDevice
IssueIdentify
Identify IDE Device : Heads:16 SectorsPerTrack:63 MBLK:1
Return from (IDE_COMMAND_IDENTIFY)
Sanity check
h/w reset status byte:50
Try to load Linux(0xff83) at dev 0x31
error code:0x1!
Partition starts at 0x3f
Path = /boot/vmlinuz-m2
Enter LoadKernel()
mount succ
Found filename is vmlinuz-m2
File "/boot/vmlinuz-m2" is Found!
ELF Header check ok!
Enter ParsePHDR()
PHDR 0, type=1, Offset=0x001000, Addr=0x010000,
Size=0x000a5c, MemSize=0x004a60
Checksum 0 = 0x6f860000
Clean memory range 0x10a5c - 0x14a60
PHDR 1, type=1, Offset=0x002000, Addr=0x091000,
Size=0x00002c, MemSize=0x00002c
Checksum 1 = 0x30d0000
Clean memory range 0x9102c - 0x9102c
PHDR 2, type=1, Offset=0x003000, Addr=0x100000,
Size=0x13d529, MemSize=0x13d529
Checksum 2 = 0x5b140000
Clean memory range 0x23d529 - 0x23d529

But after this there is no any activity. Can anybody help?
(Maybe this question is off-topic but I think there are
other people who tried fastboot like me).

Thx,

Sza2


_______________________________________________________________________
[freemail] extra 1GB-os postafi?kkal, ?nnek m?r van? http://freemail.hu





From smithbone at gmail.com  Wed Aug 31 22:31:00 2005
From: smithbone at gmail.com (Richard Smith)
Date: Wed, 31 Aug 2005 15:31:00 -0500
Subject: [LinuxBIOS] Etherboot BIOS.
In-Reply-To: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08A86@ssvlexmb2.amd.com>
References: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08A86@ssvlexmb2.amd.com>
Message-ID: <8a0c367805083113311bdbb2c@mail.gmail.com>

> get one USB ROM emulator...
>  
>  It could be usefull etherboot to load etherboot to test ehterboot.

Depending on what package the flash is in he may or may not be able to
use one.  If you can then yes a ROM emulator is a godsend.  TSOP's
make it much harder.

-- 
Richard A. Smith



From yinghai.lu at amd.com  Wed Aug 31 22:36:32 2005
From: yinghai.lu at amd.com (Lu, Yinghai)
Date: Wed, 31 Aug 2005 13:36:32 -0700
Subject: [LinuxBIOS] PCI Express add-on cards and Expansion Roms
Message-ID: <6F7DA19D05F3CF40B890C7CA2DB13A4201E08A87@ssvlexmb2.amd.com>


option rom purposes
1. patch chip bugs
2. installed BIOS call, so OS can boot from SCSI...
3. PXE boot from network...
4. Some UO for setup.
5. VGA card, init ....

So depend what card that you are going to use.

YH


-----Original Message-----
From: linuxbios-bounces at openbios.org on behalf of Peter.VanEchaute at bench.com
Sent: Wed 8/31/2005 12:13 PM
To: linuxbios at openbios.org
Subject: [LinuxBIOS] PCI Express add-on cards and Expansion Roms
 
Hello All,

 

I am trying to work on getting a PCI-E card working and came across an error that I am wondering if I need to worry about.  Below shows that the VGA ROM is loading, but not the ROM from the PCI-E card (at the bottom).  Both of these cards are in slots and not onboard.  The PCI-E card is an Ethernet card.  As the device is getting a bus and resources seemingly just fine, I would think that the ROM would have been found.  My question is ... do all add-on cards need to load an expansion ROM or can they run just fine without it?  The error in question is "Incorrect Expansion ROM Header Signature ffff".

 

FYI on devices:

00:01.0 is the PCI-PCI bridge

02:06.0 is the VGA card on the PCI-PCI bridge

00:02.0 is the PCI-E bridge

04:00.0 is the ethernet card on the PCI-E bridge

 

PCI: 00:01.0 1c <- [0x0000001000 - 0x0000001fff] bus 2 io

PCI: 00:01.0 20 <- [0x00fc000000 - 0x00fdffffff] bus 2 mem

PCI: 02:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem

PCI: 02:06.0 14 <- [0x0000001000 - 0x00000010ff] io

PCI: 02:06.0 30 <- [0x00fd000000 - 0x00fdffffff] rom

 

PCI: 00:02.0 1c <- [0x0000002000 - 0x0000002fff] bus 4 io

PCI: 00:02.0 20 <- [0x00fe000000 - 0x00fe0fffff] bus 4 mem

PCI: 04:00.0 10 <- [0x00fe020000 - 0x00fe023fff] mem

PCI: 04:00.0 18 <- [0x0000002000 - 0x00000020ff] io

PCI: 04:00.0 30 <- [0x00fe000000 - 0x00fe01ffff] rom

 

 

PCI: 00:01.0 bridge ctrl <- 000b

PCI: 00:01.0 cmd <- 147

PCI: 02:06.0 cmd <- 143

 

PCI: 00:02.0 bridge ctrl <- 0007

PCI: 00:02.0 cmd <- 547

PCI: 04:00.0 cmd <- 143

 

 

PCI: 02:06.0 init

rom address for PCI: 02:06.0 = fd000000

Class Code mismatch ROM 00000003, dev 00030000

copying VGA ROM Image from fd000000 to c0000, 8000 bytes

halt_sys: file /home/vanecp/design/freebios2-3/src/devices/emulator/x86emu/ops.c

, line 4400

PCI: 04:00.0 init

rom address for PCI: 04:00.0 = fe000000

Incorrect Expansion ROM Header Signature ffff

Devices initialized

 

 

 

Cheers,
Peter Van Echaute



 


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

From ollie at lanl.gov  Wed Aug 31 23:47:41 2005
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed, 31 Aug 2005 15:47:41 -0600
Subject: [LinuxBIOS] PCI Express add-on cards and Expansion Roms
In-Reply-To: <30ADB28314F8B744AB478FB5EDA044B31182E0@nh-ex01.bench.com>
References: <30ADB28314F8B744AB478FB5EDA044B31182E0@nh-ex01.bench.com>
Message-ID: <1125524862.6513.1.camel@logarithm.lanl.gov>

On Wed, 2005-08-31 at 15:13 -0400, Peter.VanEchaute at bench.com wrote:
> Hello All,
> 
>  
> 
> I am trying to work on getting a PCI-E card working and came across an
> error that I am wondering if I need to worry about.  Below shows that
> the VGA ROM is loading, but not the ROM from the PCI-E card (at the
> bottom).  Both of these cards are in slots and not onboard.  The PCI-E
> card is an Ethernet card.  As the device is getting a bus and
> resources seemingly just fine, I would think that the ROM would have
> been found.  My question is ? do all add-on cards need to load an
> expansion ROM or can they run just fine without it?  The error in
> question is ?Incorrect Expansion ROM Header Signature ffff?.
> 
>  

Are you sure there is anything on the expansion rom?

> 
> FYI on devices:
> 
> 00:01.0 is the PCI-PCI bridge
> 
> 02:06.0 is the VGA card on the PCI-PCI bridge
> 
> 00:02.0 is the PCI-E bridge
> 
> 04:00.0 is the ethernet card on the PCI-E bridge
> 
>  
> 
> PCI: 00:01.0 1c <- [0x0000001000 - 0x0000001fff] bus 2 io
> 
> PCI: 00:01.0 20 <- [0x00fc000000 - 0x00fdffffff] bus 2 mem
> 
> PCI: 02:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
> 
> PCI: 02:06.0 14 <- [0x0000001000 - 0x00000010ff] io
> 
> PCI: 02:06.0 30 <- [0x00fd000000 - 0x00fdffffff] rom
> 
>  
> 
> PCI: 00:02.0 1c <- [0x0000002000 - 0x0000002fff] bus 4 io
> 
> PCI: 00:02.0 20 <- [0x00fe000000 - 0x00fe0fffff] bus 4 mem
> 
> PCI: 04:00.0 10 <- [0x00fe020000 - 0x00fe023fff] mem
> 
> PCI: 04:00.0 18 <- [0x0000002000 - 0x00000020ff] io
> 
> PCI: 04:00.0 30 <- [0x00fe000000 - 0x00fe01ffff] rom
> 
>  
> 
>  
> 
> PCI: 00:01.0 bridge ctrl <- 000b
> 
> PCI: 00:01.0 cmd <- 147
> 
> PCI: 02:06.0 cmd <- 143
> 
>  
> 
> PCI: 00:02.0 bridge ctrl <- 0007
> 
> PCI: 00:02.0 cmd <- 547
> 
> PCI: 04:00.0 cmd <- 143
> 
>  
> 
>  
> 
> PCI: 02:06.0 init
> 
> rom address for PCI: 02:06.0 = fd000000
> 
> Class Code mismatch ROM 00000003, dev 00030000
> 
> copying VGA ROM Image from fd000000 to c0000, 8000 bytes
> 
> halt_sys:
> file /home/vanecp/design/freebios2-3/src/devices/emulator/x86emu/ops.c
> 
> , line 4400
> 
> PCI: 04:00.0 init
> 
> rom address for PCI: 04:00.0 = fe000000
> 
> Incorrect Expansion ROM Header Signature ffff
> 
> Devices initialized
> 
>  
> 
>  
> 
>  
> 
> Cheers,
> Peter Van Echaute
> 
> 
> 
>  
> 
> 
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab




From Peter.VanEchaute at bench.com  Wed Aug 31 23:58:04 2005
From: Peter.VanEchaute at bench.com (Peter.VanEchaute at bench.com)
Date: Wed, 31 Aug 2005 17:58:04 -0400
Subject: [LinuxBIOS] PCI Express add-on cards and Expansion Roms
Message-ID: <30ADB28314F8B744AB478FB5EDA044B31182E1@nh-ex01.bench.com>

No, I am not sure.  I haven't gotten the card to work with my LinuxBIOS yet.  I have seen it work with a Pheonix BIOS and FC3 kernel with the driver.  So I know it works.  The Pheonix BIOS doesn't show me an output of what it is doing as it loads.

So I am looking for a direction of why it isn't working yet.  I was thinking it might be the lack of executing a ROM, but didn't want to waste my time going down a path not needed.  It seems that I should look deeper into the register set on my PCI-E device for the slot and the PCI-E expansion register space for why it isn't working yet.

-Pete



-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Wednesday, August 31, 2005 5:48 PM
To: Van Echaute, Peter
Cc: LinuxBIOS
Subject: Re: [LinuxBIOS] PCI Express add-on cards and Expansion Roms

On Wed, 2005-08-31 at 15:13 -0400, Peter.VanEchaute at bench.com wrote:
> Hello All,
> 
>  
> 
> I am trying to work on getting a PCI-E card working and came across an
> error that I am wondering if I need to worry about.  Below shows that
> the VGA ROM is loading, but not the ROM from the PCI-E card (at the
> bottom).  Both of these cards are in slots and not onboard.  The PCI-E
> card is an Ethernet card.  As the device is getting a bus and
> resources seemingly just fine, I would think that the ROM would have
> been found.  My question is ... do all add-on cards need to load an
> expansion ROM or can they run just fine without it?  The error in
> question is "Incorrect Expansion ROM Header Signature ffff".
> 
>  

Are you sure there is anything on the expansion rom?

> 
> FYI on devices:
> 
> 00:01.0 is the PCI-PCI bridge
> 
> 02:06.0 is the VGA card on the PCI-PCI bridge
> 
> 00:02.0 is the PCI-E bridge
> 
> 04:00.0 is the ethernet card on the PCI-E bridge
> 
>  
> 
> PCI: 00:01.0 1c <- [0x0000001000 - 0x0000001fff] bus 2 io
> 
> PCI: 00:01.0 20 <- [0x00fc000000 - 0x00fdffffff] bus 2 mem
> 
> PCI: 02:06.0 10 <- [0x00fc000000 - 0x00fcffffff] mem
> 
> PCI: 02:06.0 14 <- [0x0000001000 - 0x00000010ff] io
> 
> PCI: 02:06.0 30 <- [0x00fd000000 - 0x00fdffffff] rom
> 
>  
> 
> PCI: 00:02.0 1c <- [0x0000002000 - 0x0000002fff] bus 4 io
> 
> PCI: 00:02.0 20 <- [0x00fe000000 - 0x00fe0fffff] bus 4 mem
> 
> PCI: 04:00.0 10 <- [0x00fe020000 - 0x00fe023fff] mem
> 
> PCI: 04:00.0 18 <- [0x0000002000 - 0x00000020ff] io
> 
> PCI: 04:00.0 30 <- [0x00fe000000 - 0x00fe01ffff] rom
> 
>  
> 
>  
> 
> PCI: 00:01.0 bridge ctrl <- 000b
> 
> PCI: 00:01.0 cmd <- 147
> 
> PCI: 02:06.0 cmd <- 143
> 
>  
> 
> PCI: 00:02.0 bridge ctrl <- 0007
> 
> PCI: 00:02.0 cmd <- 547
> 
> PCI: 04:00.0 cmd <- 143
> 
>  
> 
>  
> 
> PCI: 02:06.0 init
> 
> rom address for PCI: 02:06.0 = fd000000
> 
> Class Code mismatch ROM 00000003, dev 00030000
> 
> copying VGA ROM Image from fd000000 to c0000, 8000 bytes
> 
> halt_sys:
> file /home/vanecp/design/freebios2-3/src/devices/emulator/x86emu/ops.c
> 
> , line 4400
> 
> PCI: 04:00.0 init
> 
> rom address for PCI: 04:00.0 = fe000000
> 
> Incorrect Expansion ROM Header Signature ffff
> 
> Devices initialized
> 
>  
> 
>  
> 
>  
> 
> Cheers,
> Peter Van Echaute
> 
> 
> 
>  
> 
> 
> -- 
> LinuxBIOS mailing list
> LinuxBIOS at openbios.org
> http://www.openbios.org/mailman/listinfo/linuxbios
-- 
Li-Ta Lo <ollie at lanl.gov>
Los Alamos National Lab