From ebiederman at lnxi.com  Tue Jun  1 00:42:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 00:42:01 2004
Subject: Large mmio resources and 4G+ of RAM...
Message-ID: <m3u0xvg6dr.fsf@maxwell.lnxi.com>

For the longest time I have been fighting what to do with machines
that have 4GB or more of memory and large memory mapped I/O resources.
As the conflict in memory space can cause a loss of 1/2GB of memory.
Which does not tend to be good for performance.

Looking the large memory mapped I/O resources all have 64bit BARs.  So
I am just going to modify the LinuxBIOS resource allocator to put
64bit BARs on x86-64 boxes at least above the top of memory.

There are a couple of short term hacks that I can do with relocating
memory but on the Opteron the more memory I add the more problems
I run into.  And moving BARS above 4G looks like the right term
fix.

Any objections?

Eric



From stepan at openbios.org  Tue Jun  1 02:05:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Jun  1 02:05:00 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <m3u0xvg6dr.fsf@maxwell.lnxi.com>
References: <m3u0xvg6dr.fsf@maxwell.lnxi.com>
Message-ID: <20040601072721.GA8331@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [040601 08:05]:
> Looking the large memory mapped I/O resources all have 64bit BARs.  So
> I am just going to modify the LinuxBIOS resource allocator to put
> 64bit BARs on x86-64 boxes at least above the top of memory.
> 
> There are a couple of short term hacks that I can do with relocating
> memory but on the Opteron the more memory I add the more problems
> I run into.  And moving BARS above 4G looks like the right term
> fix.

When running a 32bit operating system (like linux/x86) does this mean
that I am able to see more of my memory, but my pci devices will vanish?

Stefan


From mdeschamps at mangrove-systems.com  Tue Jun  1 02:21:01 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Tue Jun  1 02:21:01 2004
Subject: LinuxBios documentation
In-Reply-To: <9C391686-B0C3-11D8-B4CF-0003931B4D6A@gnat.ca>
References: <9C391686-B0C3-11D8-B4CF-0003931B4D6A@gnat.ca>
Message-ID: <1086074915.17249.64.camel@Calliphara>

Le ven 28/05/2004 ? 18:25, Nathanael Noblet a ?crit :
> On Friday, May 28, 2004, at 08:52 AM, Mathieu Deschamps wrote:
> > For the time being, i'am at writing doc and well
> > this is a needed step, first it helps me understand in the whole,
> > second i've been ordered to do so.
> >
> > I would gladly help ... what I could is bringing my doc to you and
> > LinuxBios people.
> > But I write it in french since i'll prepare a 'conference'  at
> > my university based upon it: hey, my intented audience is frenchy.
> 
> I can translate it to english for you.

So everythings seems OK. Let's do it.
For me, since I got a realeaseable version , I let it on the maillist
and/or on your mail. On the latter, this will be done in one or two
weeks.

mathieu.


From ebiederman at lnxi.com  Tue Jun  1 02:29:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 02:29:01 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <20040601072721.GA8331@openbios.org>
References: <m3u0xvg6dr.fsf@maxwell.lnxi.com>
	<20040601072721.GA8331@openbios.org>
Message-ID: <m3u0xvemtt.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [040601 08:05]:
> > Looking the large memory mapped I/O resources all have 64bit BARs.  So
> > I am just going to modify the LinuxBIOS resource allocator to put
> > 64bit BARs on x86-64 boxes at least above the top of memory.
> > 
> > There are a couple of short term hacks that I can do with relocating
> > memory but on the Opteron the more memory I add the more problems
> > I run into.  And moving BARS above 4G looks like the right term
                                                              ^long
> > fix.
> 
> When running a 32bit operating system (like linux/x86) does this mean
> that I am able to see more of my memory, but my pci devices will vanish?

Essentially.  Although the pci devices don't vanish you likely can't use
them because some of their BARS have values that 32bit kernels can't
cope with.  lspci should let you see that though.   A 32bit kernel
with PAE enabled could code but no one has written the code.

I don't have a problem with adding an option to disable this for 32bit
kernels.  I am just tired of optimizing 64bit machines for 32bit
kernels.

I need to be a little bit careful here as AMD's IO-APICs have 64bit
BARs but are only 4K.  So I might want to put in a size filter.  Plus
I need to ensure the bridges have enough resources to move things.

Eric


From stepan at openbios.org  Tue Jun  1 03:11:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Jun  1 03:11:00 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <m3u0xvemtt.fsf@maxwell.lnxi.com>
References: <m3u0xvg6dr.fsf@maxwell.lnxi.com> <20040601072721.GA8331@openbios.org> <m3u0xvemtt.fsf@maxwell.lnxi.com>
Message-ID: <20040601083327.GB9244@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [040601 09:53]:
> Essentially.  Although the pci devices don't vanish you likely can't use
> them because some of their BARS have values that 32bit kernels can't
> cope with.  lspci should let you see that though.   A 32bit kernel
> with PAE enabled could code but no one has written the code.
 
Are there any drawbacks to that solution? This should be addressed to
the Linux kernel developers. Given the advantages this brings, this
would probably something people would like to see.

> I don't have a problem with adding an option to disable this for 32bit
> kernels.  I am just tired of optimizing 64bit machines for 32bit
> kernels.
 
The silver bullet would be an option in the cmos option table to trigger
the one or the other behaviour. Or maybe it is enough to just put the
PCI BARs into 32bit address space whenever it fits there, taking the
amount of RAM into regard.
I agree it does not make sense to _optimize_ for 32bit kernels.
Essentially there are two groups of potential LinuxBIOS users in this
case: Those with small amounts of RAM (ie amd64 based embedded
solutions) might use 32bit code because it's easy to test it on many
PCs. Those with large amounts of RAM don't want to use a 32bit kernel
anyways. With more than about 1G of RAM 32bit Linux performance breaks
down noticably compared to the 64bit variant.

Stefan




From ebiederman at lnxi.com  Tue Jun  1 03:25:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 03:25:01 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <20040601083327.GB9244@openbios.org>
References: <m3u0xvg6dr.fsf@maxwell.lnxi.com>
	<20040601072721.GA8331@openbios.org> <m3u0xvemtt.fsf@maxwell.lnxi.com>
	<20040601083327.GB9244@openbios.org>
Message-ID: <m3smdfd5od.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [040601 09:53]:
> > Essentially.  Although the pci devices don't vanish you likely can't use
> > them because some of their BARS have values that 32bit kernels can't
> > cope with.  lspci should let you see that though.   A 32bit kernel
> > with PAE enabled could code but no one has written the code.
>  
> Are there any drawbacks to that solution? This should be addressed to
> the Linux kernel developers. Given the advantages this brings, this
> would probably something people would like to see.

struct resource {} needs to be defined in terms of u64 instead of
unsigned long.  I know just that tweak was discussed and there were
some problems with that.

> > I don't have a problem with adding an option to disable this for 32bit
> > kernels.  I am just tired of optimizing 64bit machines for 32bit
> > kernels.
>  
> The silver bullet would be an option in the cmos option table to trigger
> the one or the other behaviour. 

Right that is what I was thinking.

> Or maybe it is enough to just put the
> PCI BARs into 32bit address space whenever it fits there, taking the
> amount of RAM into regard.

Except for some very small filters that starts requiring a filter
that is too smart.  I think ultimately it is going to the bridge
bars that are going to limit me.  So I may only be able to apply
this to prefetchable memory regions.  But that should still cover
the large mmio regions with 64bit BARs.

> I agree it does not make sense to _optimize_ for 32bit kernels.
> Essentially there are two groups of potential LinuxBIOS users in this
> case: Those with small amounts of RAM (ie amd64 based embedded
> solutions) might use 32bit code because it's easy to test it on many
> PCs. Those with large amounts of RAM don't want to use a 32bit kernel
> anyways. With more than about 1G of RAM 32bit Linux performance breaks
> down noticably compared to the 64bit variant.

Interesting.  Most of my customers have compute intensive apps and I
don't think see the break down anywhere near that soon.

Eric


From mdeschamps at mangrove-systems.com  Tue Jun  1 07:40:01 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Tue Jun  1 07:40:01 2004
Subject: About memory allocation code ...
In-Reply-To: <Pine.LNX.4.44.0405271518280.23982-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0405271518280.23982-100000@maxroach.lanl.gov>
Message-ID: <1086094096.17249.72.camel@Calliphara>

Hello,

I got something something i cant get rid of. 
In the src/lib directory, it holds memory allocations
and relatives progs. Why are they redefined ? 
I mean couldn't we use standard's definitions ?
I've seen there are debug dumps mechanisms but 
surely as in standard's def.?

Could you enlighten me on this point ?

Thanks
mathieu


From rminnich at lanl.gov  Tue Jun  1 07:47:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun  1 07:47:00 2004
Subject: Chipsets: status page?
In-Reply-To: <200405281631.04833.joshua@joshuawise.com>
Message-ID: <Pine.LNX.4.44.0406010708460.15065-100000@maxroach.lanl.gov>

On Fri, 28 May 2004, Joshua Wise wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I read the FAQ looking for information on chipsets supported in LinuxBIOS, and 
> it pointed me towards the status page, however I can only find information 
> about mainboards on that page. Am I looking in the wrong place? For 
> reference, I'm wondering if the AMD-760 and the VIA VT82C686 are supported.

they're supported.

see the tyan guiness.

ron



From rminnich at lanl.gov  Tue Jun  1 08:56:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun  1 08:56:01 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <m3u0xvg6dr.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406010817440.15466-100000@maxroach.lanl.gov>

On 1 Jun 2004, Eric W. Biederman wrote:

> There are a couple of short term hacks that I can do with relocating
> memory but on the Opteron the more memory I add the more problems
> I run into.  And moving BARS above 4G looks like the right term
> fix.
> 
> Any objections?

How are we going to cover the case of booting 32-bit kernels?

ron



From rminnich at lanl.gov  Tue Jun  1 09:00:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun  1 09:00:01 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <m3u0xvemtt.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406010819090.15466-100000@maxroach.lanl.gov>

just FYI, making BARS live above the 32-bit limit will break every single
linux cluster here at LANL, and will also disable Plan 9.

With BARS under the 32-bit limit, you can boot anything. With BARS above 
that limit, you immediately limit what you can boot. 

I think what really ought to happen is we fix linux early boot to do what
we wanted in the beginning of this project 5 years ago: linux should do
BAR optimization for the kernel that is running.

In principle, I like your BAR fix, but setting up BARS that are optimized
for 64-bit kernels should be a (normally disabled)  option.

I wonder if we can put BAR reallocation into a payload?

thanks

ron




From bari at onelabs.com  Tue Jun  1 09:48:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Tue Jun  1 09:48:00 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
Message-ID: <40BC9CD2.2000105@onelabs.com>


-------- Original Message --------
Subject: Re: Linuxbios and Linspire laptop
Date: Tue, 01 Jun 2004 10:10:43 -0500
From: Bari Ari <bari at onelabs.com>
To: Jan Macek <miernik at ctnet.pl>
CC: Richard Stallman <rms at gnu.org>
References: <E1BSJLs-0005OB-ON at fencepost.gnu.org> 
<40B25E08.8030401 at onelabs.com> <20040601140614.GA945 at jaworz.ctnet.pl>

Jan Macek wrote:
> What about the Linspire Mobile PC laptop?
> Is there really anything missing to got something working at all 
> (proprietary-BIOS-free)?
> Let's say we don't care about power management, lid etc. We just want 
> to be able to use GNU operating system without booting aby proprietary 
> firmware. Is there anything _essenstial_ missing now, the board was 
> said to be the same as VIA EPIA. 

If it's the same as a supported Epia then the port is well on its way.
Can you find out what they use for the keyboard controller?

You may have to care about power management, SystemBIOS reflashing and
the lid etc. or those features may not work depending on how they did
the hardware design. Like I have said before there is really no standard
for this. Hardware guys like myself typically use whatever I/O pins are
left over to solve these issues and then make it work with firmware
attached to the keyboard BIOS.

I'd really like to pick a laptop with a chipset with plenty of life left
like the new Intel 9xx series due out very shortly.

http://slashdot.org/articles/04/05/31/2211233.shtml?tid=137&tid=152&tid=185

http://www.anandtech.com/showdoc.html?i=2064&p=5

>>Send us an Intel chipset laptop with a Renesas super I/O and we have a 
>>winner!
> 
> 
> I set up a page with some information about LinuxBIOS, and links to 
> some of your posts. Please take a look if I got it right and what 
> might I add:
> http://www.miernik.ctnet.pl/linuxbios/

Looks good so far!

Regards,

Bari Ari






From stepan at openbios.org  Tue Jun  1 09:56:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Jun  1 09:56:00 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <40BC9CD2.2000105@onelabs.com>
References: <40BC9CD2.2000105@onelabs.com>
Message-ID: <20040601151753.GA14291@openbios.org>

* Bari Ari <bari at onelabs.com> [040601 17:12]:
> You may have to care about power management, SystemBIOS reflashing and
> the lid etc. or those features may not work depending on how they did
> the hardware design. Like I have said before there is really no standard
> for this.

Power management and lid close detection is a matter of someone
implementing the needed ACPI tables for that. ACPI support is 
basically implemented in LinuxBIOS but each system type needs it's
specific set of tables for ACPI to do any good.

Stefan




From bari at onelabs.com  Tue Jun  1 09:56:22 2004
From: bari at onelabs.com (Bari Ari)
Date: Tue Jun  1 09:56:22 2004
Subject: Chipsets: status page?
In-Reply-To: <Pine.LNX.4.44.0406010708460.15065-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406010708460.15065-100000@maxroach.lanl.gov>
Message-ID: <40BC9E90.1060705@onelabs.com>

ron minnich wrote:

> On Fri, 28 May 2004, Joshua Wise wrote:
>>I read the FAQ looking for information on chipsets supported in LinuxBIOS, and 
>>it pointed me towards the status page, however I can only find information 
>>about mainboards on that page. Am I looking in the wrong place? For 
>>reference, I'm wondering if the AMD-760 and the VIA VT82C686 are supported.
> 
> 
> they're supported.
> 
> see the tyan guiness.
> 

The "current project status" is organized around and listed by the 
mainboards supported. I've been tempted several times myself to 
translate that list along with the src listing of chipsets with a status 
listing by chipsets vs mainboards.

-Bari




From bari at onelabs.com  Tue Jun  1 10:07:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Tue Jun  1 10:07:00 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <20040601151753.GA14291@openbios.org>
References: <40BC9CD2.2000105@onelabs.com> <20040601151753.GA14291@openbios.org>
Message-ID: <40BCA128.8060400@onelabs.com>

Stefan Reinauer wrote:

> * Bari Ari <bari at onelabs.com> [040601 17:12]:
> 
>>You may have to care about power management, SystemBIOS reflashing and
>>the lid etc. or those features may not work depending on how they did
>>the hardware design. Like I have said before there is really no standard
>>for this.
> 
> 
> Power management and lid close detection is a matter of someone
> implementing the needed ACPI tables for that. ACPI support is 
> basically implemented in LinuxBIOS but each system type needs it's
> specific set of tables for ACPI to do any good.
> 

That's if they got ACPI right in their hardware design. Laptop hardware 
designers use the keyboard micro to solve lots of issues since these 
micros have lots of GPIO pins along with timers and other function 
blocks that are easily programmed.

-Bari






From stepan at openbios.org  Tue Jun  1 10:08:16 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Jun  1 10:08:16 2004
Subject: ACPI DSDT
Message-ID: <20040601152953.GB14291@openbios.org>

Hi,

one thing that is generically missing in LinuxBIOS' ACPI implementation
is the detailed system description table (DSDT The part telling whether 
there is a lid and how detect whether it is open or closed)

The DSDT is written in ASL which is compiled to AML bytecode using an
ASL compiler (ie. Intel's iasl) Thus, a LinuxBIOS port implementing a
DSDT needs either to come with a precompiled DSDT or it needs an
installed ASL compiler. What is the preferred default behaviour? Do we
want to add ASL source code or rather have something that keeps the
build requirements for those boards as small as possible. 
Or we can pack both the ASL and AML version of the DSDT and have the 
build process use the precompiled code only. This on the other hand
requires developers to take care that they check in a new binary version
when they change something to the ASL code. CVS is not doing too well
with binary stuff.. 

Opinions?

Stefan



From stepan at openbios.org  Tue Jun  1 10:11:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Jun  1 10:11:01 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <40BCA128.8060400@onelabs.com>
References: <40BC9CD2.2000105@onelabs.com> <20040601151753.GA14291@openbios.org> <40BCA128.8060400@onelabs.com>
Message-ID: <20040601153351.GA14579@openbios.org>

* Bari Ari <bari at onelabs.com> [040601 17:30]:
> That's if they got ACPI right in their hardware design. Laptop hardware 
> designers use the keyboard micro to solve lots of issues since these 
> micros have lots of GPIO pins along with timers and other function 
> blocks that are easily programmed.

ACPI does not change the fact that you have to trigger some GPIOs to get
things to work. It just moves the description of these GPIOs to the
firmware rather than having the OS implement them new for each
mainboard(!) 

While LinuxBIOS' goal is to let Linux do it, I guarantee that either
these ACPI tables are put in LinuxBIOS or the features won't be
available in Linux for the next decade or so.

Stefan



From ebiederman at lnxi.com  Tue Jun  1 10:17:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 10:17:00 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <Pine.LNX.4.44.0406010819090.15466-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406010819090.15466-100000@maxroach.lanl.gov>
Message-ID: <m33c5fxp4l.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> just FYI, making BARS live above the 32-bit limit will break every single
> linux cluster here at LANL, and will also disable Plan 9.

Only for the hardware where the BARs move.  
 
> With BARS under the 32-bit limit, you can boot anything. With BARS above 
> that limit, you immediately limit what you can boot. 

Yes.  And largely I see that as a good thing.
 
> I think what really ought to happen is we fix linux early boot to do what
> we wanted in the beginning of this project 5 years ago: linux should do
> BAR optimization for the kernel that is running.

There are enough other bits you need to twiddle I don't think
you can implement that generically.
 
> In principle, I like your BAR fix, but setting up BARS that are optimized
> for 64-bit kernels should be a (normally disabled)  option.

For old clusters I agree that it should be normally disabled.
 
> I wonder if we can put BAR reallocation into a payload?

The amount of code should be just a handful of lines so I don't think
that will be necessary.  Especially since I have to go through a very
limited number of bridge BARs.

Eric


From ebiederman at lnxi.com  Tue Jun  1 10:21:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 10:21:01 2004
Subject: About memory allocation code ...
In-Reply-To: <1086094096.17249.72.camel@Calliphara>
References: <Pine.LNX.4.44.0405271518280.23982-100000@maxroach.lanl.gov>
	<1086094096.17249.72.camel@Calliphara>
Message-ID: <m365abuvsw.fsf@maxwell.lnxi.com>

Mathieu Deschamps <mdeschamps at mangrove-systems.com> writes:

> Hello,
> 
> I got something something i cant get rid of. 
> In the src/lib directory, it holds memory allocations
> and relatives progs. Why are they redefined ? 
> I mean couldn't we use standard's definitions ?
> I've seen there are debug dumps mechanisms but 
> surely as in standard's def.?
>
> Could you enlighten me on this point ?

Consider what it means to be a stand-alone program on the hardware.
Consider why every kernel does the same thing.

Eric


From bari at onelabs.com  Tue Jun  1 10:21:24 2004
From: bari at onelabs.com (Bari Ari)
Date: Tue Jun  1 10:21:24 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <20040601153351.GA14579@openbios.org>
References: <40BC9CD2.2000105@onelabs.com> <20040601151753.GA14291@openbios.org> <40BCA128.8060400@onelabs.com> <20040601153351.GA14579@openbios.org>
Message-ID: <40BCA485.2020104@onelabs.com>

Stefan Reinauer wrote:

> While LinuxBIOS' goal is to let Linux do it, I guarantee that either
> these ACPI tables are put in LinuxBIOS or the features won't be
> available in Linux for the next decade or so.

The offer still stands:

I'd really like to pick a laptop with a chipset with plenty of life left
like the new Intel 9xx series due out very shortly.

http://slashdot.org/articles/04/05/31/2211233.shtml?tid=137&tid=152&tid=185

http://www.anandtech.com/showdoc.html?i=2064&p=5

Send us an Intel chipset laptop with a Renesas super I/O and we have a 
winner (for a LinuxBIOS laptop)!

-Bari






From bari at onelabs.com  Tue Jun  1 10:50:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Tue Jun  1 10:50:01 2004
Subject: ACPI DSDT
In-Reply-To: <20040601152953.GB14291@openbios.org>
References: <20040601152953.GB14291@openbios.org>
Message-ID: <40BCAB5F.5010408@onelabs.com>

Stefan Reinauer wrote:

> Hi,
> 
> one thing that is generically missing in LinuxBIOS' ACPI implementation
> is the detailed system description table (DSDT The part telling whether 
> there is a lid and how detect whether it is open or closed)
> 
> The DSDT is written in ASL which is compiled to AML bytecode using an
> ASL compiler (ie. Intel's iasl) Thus, a LinuxBIOS port implementing a
> DSDT needs either to come with a precompiled DSDT or it needs an
> installed ASL compiler. What is the preferred default behaviour? Do we
> want to add ASL source code or rather have something that keeps the
> build requirements for those boards as small as possible. 
> Or we can pack both the ASL and AML version of the DSDT and have the 
> build process use the precompiled code only. This on the other hand
> requires developers to take care that they check in a new binary version
> when they change something to the ASL code. CVS is not doing too well
> with binary stuff.. 
> 
> Opinions?

Some links on ASL and DSDT:

http://developer.intel.com/technology/iapc/acpi/downloads.htm

http://www.acpi.info/toolkit.htm

http://www.cpqlinux.com/acpi-howto.html

http://acpi.sourceforge.net/dsdt/index.php

-Bari




From YhLu at tyan.com  Tue Jun  1 11:53:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun  1 11:53:01 2004
Subject: Large mmio resources and 4G+ of RAM...
Message-ID: <3174569B9743D511922F00A0C94314230506464F@TYANWEB>

Eric,

There is something called Memory lifting or memory remapping for Opteron.
For example if 2G for one Opteron and two ways system.

Then the CPU 0 will use [0,2G), and CPU 1 will use [4G, 6G).

If the RAM for CPU is above 4G, then We must lost 1/2G for MMIO range, the
reason is Opteron only has two reg for RAM LOW and HIGH limit. And there is
no other regs to record the memory hole. But it seems Intel CPU has more
regs to remember the memory hole.

Regards

YH




From camilledalmeras at yahoo.com  Tue Jun  1 12:05:01 2004
From: camilledalmeras at yahoo.com (Ben Johnson)
Date: Tue Jun  1 12:05:01 2004
Subject: MSI 694t pro supported?
Message-ID: <20040601172654.94850.qmail@web50405.mail.yahoo.com>

Hi everybody,

I perused through the documentation, but as I am
really no specialist, I couldn't tell if Linuxbios
would work with my motherboard, nor the way to put the
whole thing up and running in the eventuality it would
-is there any step-by-step howto for dummies like I ?
The reason I ask is because the 694t's (aka 6309 v.5)
bios is buggy as hell, and the kind folks at MSI do
not offer support anymore. Hope not to be too much a
burden on the list, my apologies if I am. Thank you
for your attention, here's the output of lspci -vv:

0000:00:00.0 Host bridge: VIA Technologies, Inc.
VT82C693A/694x [Apollo PRO133x] (rev c4)
        Control: I/O- Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr-
DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
        Latency: 8
        Region 0: Memory at e0000000 (32-bit,
prefetchable)
        Capabilities: [a0] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+
ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP-
GART64- 64bit- FW- Rate=<none>
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2-
AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0
PME-

0000:00:01.0 PCI bridge: VIA Technologies, Inc.
VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00
[Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr-
DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01,
sec-latency=0
        Memory behind bridge: dde00000-dfefffff
        Prefetchable memory behind bridge:
cdc00000-ddcfffff
        BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort-
>Reset- FastB2B-
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2-
AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0
PME-

0000:00:07.0 ISA bridge: VIA Technologies, Inc.
VT82C686 [Apollo Super South] (rev 40)
        Subsystem: VIA Technologies, Inc. VT82C686/A
PCI to ISA Bridge
        Control: I/O+ Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr-
DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2-
AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0
PME-

0000:00:07.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master
IDE (rev 06) (prog-if 8a [Master SecP PriP])
        Subsystem: VIA Technologies, Inc.
VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus
Master IDE
        Control: I/O+ Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Region 4: I/O ports at ff00 [size=16]
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2-
AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0
PME-

0000:00:07.2 USB Controller: VIA Technologies, Inc.
VT82xxxxx UHCI USB 1.1 Controller (rev 1a) (prog-if 00
[UHCI])
        Subsystem: VIA Technologies, Inc. (Wrong ID)
USB Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle-
MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr-
DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64, Cache Line Size: 0x08 (32 bytes)
        Interrupt: pin D routed to IRQ 10
        Region 4: I/O ports at dc00 [size=32]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1- D2-
AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0
PME-

0000:00:07.4 Bridge: VIA Technologies, Inc. VT82C686
[Apollo Super ACPI] (rev 40)
        Subsystem: VIA Technologies, Inc. VT82C686
[Apollo Super ACPI]
        Control: I/O- Mem- BusMaster- SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Capabilities: [68] Power Management version 2
                Flags: PMEClk- DSI- D1- D2-
AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0
PME-

0000:00:0f.0 Ethernet controller: Macronix, Inc.
[MXIC] MX987x5 (rev 25)
        Control: I/O+ Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (2000ns min, 14000ns max), Cache
Line Size: 0x08 (32 bytes)
        Interrupt: pin A routed to IRQ 5
        Region 0: I/O ports at d800 [size=dff80000]
        Region 1: Memory at dfffff00 (32-bit,
non-prefetchable) [size=256]
        Expansion ROM at 00040000 [disabled]
        Capabilities: [44] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2+
AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0
PME-

0000:00:10.0 Network controller: PLX Technology, Inc.:
Unknown device 1151 (rev 01)
        Subsystem: PLX Technology, Inc.: Unknown
device 1151
        Control: I/O+ Mem+ BusMaster- SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr-
DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 3
        Region 0: Memory at dffffe80 (32-bit,
non-prefetchable)
        Region 1: I/O ports at d400 [size=128]
        Region 2: I/O ports at d000 [size=8]

0000:00:11.0 Multimedia audio controller: C-Media
Electronics Inc CM8738 (rev 10)
        Subsystem: Hercules: Unknown device a650
        Control: I/O+ Mem- BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr-
DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (500ns min, 6000ns max)
        Interrupt: pin A routed to IRQ 10
        Region 0: I/O ports at cc00
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+
AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0
PME-

0000:01:00.0 VGA compatible controller: nVidia
Corporation NV11 [GeForce2 MX/MX 400] (rev a1)
(prog-if 00 [VGA])
        Subsystem: Asustek Computer, Inc.: Unknown
device 4055
        Control: I/O+ Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr-
DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (1250ns min, 250ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at de000000 (32-bit,
non-prefetchable) [size=dfef0000]
        Region 1: Memory at d0000000 (32-bit,
prefetchable) [size=128M]
        Expansion ROM at 00010000 [disabled]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2-
AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0
PME-
        Capabilities: [44] AGP version 2.0
                Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA-
ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP-
GART64- 64bit- FW- Rate=<none>

Cheers!


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 


From ebiederman at lnxi.com  Tue Jun  1 12:16:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 12:16:00 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <3174569B9743D511922F00A0C94314230506464F@TYANWEB>
References: <3174569B9743D511922F00A0C94314230506464F@TYANWEB>
Message-ID: <m3vfib2n3l.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> There is something called Memory lifting or memory remapping for Opteron.
> For example if 2G for one Opteron and two ways system.
> 
> Then the CPU 0 will use [0,2G), and CPU 1 will use [4G, 6G).
> 
> If the RAM for CPU is above 4G, then We must lost 1/2G for MMIO range, the
> reason is Opteron only has two reg for RAM LOW and HIGH limit. And there is
> no other regs to record the memory hole. But it seems Intel CPU has more
> regs to remember the memory hole.

Memory lifting is nice.  And in certain specific instances it is useful.
On the Opteron it is possible to move either Memory controllers, or
DIMMS.  At 4G per memory controller it does not work to move memory
controllers, at paired singled sided 2G DIMMS you can't move DIMMS.

So the other solution is to move the large MMIO resources.  Moving the
MMIO resources has the advantage that
A) It is simple.
B) It works in all circumstances (baring issues with bridges)
C) Is needed if you have many large MMIO regions.
D) It works on all CPUs.
E) A 32bit kernel could support it with highmem type tricks...

So I think I would rather pursue moving the large MMIO resources
first.  The limited utility of memory lifting doesn't inspire me
to worry about it.  

Although the few circumstances the Opteron memory lifting applies to
may be the only cases people really care about loosing that much
memory.

Eric


From ebiederman at lnxi.com  Tue Jun  1 12:24:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 12:24:00 2004
Subject: Resource Allocation for Option Rom
In-Reply-To: <20040529095934.GC7236@openbios.org>
References: <20040527210837.GA8689@openbios.org>
	<Pine.LNX.4.44.0405271520460.23982-100000@maxroach.lanl.gov>
	<20040527212505.GA9346@openbios.org> <m3fz9jvrk8.fsf@maxwell.lnxi.com>
	<20040529095934.GC7236@openbios.org>
Message-ID: <m3r7sz2mr0.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [040529 05:29]:
> > Stefan Reinauer <stepan at openbios.org> writes:
> > > indeed true. But for x86 hardware, putting all of the x86 emulator in
> > > rom is less elegant than vm86 stuff, even though I have no clue about
> > > the later.
> > 
> > Last I heard some Option Roms switch to 32bit mode.  You can't do
> > that in vm86 mode.  In general using vm86 is a way to put your fate
> > in someone else's hands.
>  
> Uh, this was the kind of thing I was scared would be the case. what
> happens in such a case? Is there any way to trap this and at least
> safely state that the device can't be supported?

Yes.  What happens with a vm86 based implementation is you need an
emulator for all of the slow path cases.  At which point a pure
emulator is likely simpler.  Plus vm86 is currently deprecated.
 
> > We could possibly call the option roms directly but unless the space
> > cost is high an open source emulator is a good choice.
> 
> So the goal should rather be to reduce the size of the emulator than to
> introduce different code paths for different platforms it seems.

Stefan you should not need different code paths for different platforms.
And code size is secondary to correctness, but it is and will remain
an important consideration.

Eric


From YhLu at tyan.com  Tue Jun  1 12:24:27 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun  1 12:24:27 2004
Subject: =?GB2312?B?tPC4tDogTGFyZ2UgbW1pbyByZXNvdXJjZXMgYW5kIDRHKyBvZiBS?=
	=?GB2312?B?QU0uLi4=?=
Message-ID: <3174569B9743D511922F00A0C943142305064656@TYANWEB>

Then in LinuxBIOS We can access the memory in 64 bit mode directly. And
maybe do the memory check and test. Memory problem is a big problem in
system integration.

Some time 8 ways system, every cpu has 4 dimm, total memay will be
4G*4*8=128G.

Regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?1? 10:41
???: YhLu
??: Stefan Reinauer; LinuxBIOS
??: Re: Large mmio resources and 4G+ of RAM...

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> There is something called Memory lifting or memory remapping for Opteron.
> For example if 2G for one Opteron and two ways system.
> 
> Then the CPU 0 will use [0,2G), and CPU 1 will use [4G, 6G).
> 
> If the RAM for CPU is above 4G, then We must lost 1/2G for MMIO range, the
> reason is Opteron only has two reg for RAM LOW and HIGH limit. And there
is
> no other regs to record the memory hole. But it seems Intel CPU has more
> regs to remember the memory hole.

Memory lifting is nice.  And in certain specific instances it is useful.
On the Opteron it is possible to move either Memory controllers, or
DIMMS.  At 4G per memory controller it does not work to move memory
controllers, at paired singled sided 2G DIMMS you can't move DIMMS.

So the other solution is to move the large MMIO resources.  Moving the
MMIO resources has the advantage that
A) It is simple.
B) It works in all circumstances (baring issues with bridges)
C) Is needed if you have many large MMIO regions.
D) It works on all CPUs.
E) A 32bit kernel could support it with highmem type tricks...

So I think I would rather pursue moving the large MMIO resources
first.  The limited utility of memory lifting doesn't inspire me
to worry about it.  

Although the few circumstances the Opteron memory lifting applies to
may be the only cases people really care about loosing that much
memory.

Eric


From rminnich at lanl.gov  Tue Jun  1 15:26:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun  1 15:26:00 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <40BC9CD2.2000105@onelabs.com>
Message-ID: <Pine.LNX.4.44.0406011448321.17922-100000@maxroach.lanl.gov>

lindows/linspire never got back to me re a laptop port. 

no interest at their end.

ron



From rminnich at lanl.gov  Tue Jun  1 15:28:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun  1 15:28:00 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <40BCA128.8060400@onelabs.com>
Message-ID: <Pine.LNX.4.44.0406011450120.17922-100000@maxroach.lanl.gov>

word from someone who knows that acpi tables have many errors. Windows 
drivers work around the bugs in acpi tables. Linux follows the spec 
closely, hence the problems people see with linux+acpi. 

ron



From rminnich at lanl.gov  Tue Jun  1 15:30:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun  1 15:30:01 2004
Subject: ACPI DSDT
In-Reply-To: <20040601152953.GB14291@openbios.org>
Message-ID: <Pine.LNX.4.44.0406011451150.17922-100000@maxroach.lanl.gov>

or you can translate the acpi tables to Something Else (e.g. e-expressions 
-- it works) and use that instead. 

acpi is a big problem, partly due to the binary nature and partly because 
it is so broken on so many platforms.

ron



From bari at onelabs.com  Tue Jun  1 15:35:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Tue Jun  1 15:35:01 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <Pine.LNX.4.44.0406011448321.17922-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406011448321.17922-100000@maxroach.lanl.gov>
Message-ID: <40BCEE37.90308@onelabs.com>

ron minnich wrote:

> lindows/linspire never got back to me re a laptop port. 
> 
> no interest at their end.
> 

The Linspire laptop http://www.sub300.com/port.htm pretty much an Epia 
with a keyboard controller. Not very glamorous but if it has a Renesas 
keyboard super I/O controller I might be interested and getting it up 
under LinuxBIOS.

-Bari





From rminnich at lanl.gov  Tue Jun  1 15:56:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun  1 15:56:01 2004
Subject: MSI 694t pro supported?
In-Reply-To: <20040601172654.94850.qmail@web50405.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0406011517530.17922-100000@maxroach.lanl.gov>

On Tue, 1 Jun 2004, Ben Johnson wrote:

> 0000:00:00.0 Host bridge: VIA Technologies, Inc.
> VT82C693A/694x [Apollo PRO133x] (rev c4)

I don't believe we support this one. 

ron



From rminnich at lanl.gov  Tue Jun  1 16:02:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun  1 16:02:01 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <m33c5fxp4l.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406011452540.17922-100000@maxroach.lanl.gov>

On 1 Jun 2004, Eric W. Biederman wrote:

> ron minnich <rminnich at lanl.gov> writes:
> 
> > just FYI, making BARS live above the 32-bit limit will break every single
> > linux cluster here at LANL, and will also disable Plan 9.
> 
> Only for the hardware where the BARs move.  

guess I missed something in your writeup. Are you saying that moving all
BARs above 2^32 won't cause trouble for a 32-bit mode linux or freebsd or
plan 9 or ...

> > With BARS under the 32-bit limit, you can boot anything. With BARS above 
> > that limit, you immediately limit what you can boot. 
> 
> Yes.  And largely I see that as a good thing.

But do the potential users of linuxbios systems that as a good thing? I
understand the motivation, but sometimes customers (including us) do silly
things, such as run K8s in 32-bit mode (it's actually a good thing as a K8
is a better Xeon than a Xeon, at least for our programs).

As long as it is an option I don't mind however. 

> > In principle, I like your BAR fix, but setting up BARS that are optimized
> > for 64-bit kernels should be a (normally disabled)  option.
> 
> For old clusters I agree that it should be normally disabled.

for our new cluster (Lightning) first boot is into 32-bit linux for now, 
and will likely stay that way for a while as that system runs as 32-bits 
(not my decision ...)

This change can hurt new clusters. 

ron



From steve at nexpath.com  Tue Jun  1 17:19:01 2004
From: steve at nexpath.com (Steve Gehlbach)
Date: Tue Jun  1 17:19:01 2004
Subject: ACPI DSDT
In-Reply-To: <Pine.LNX.4.44.0406011451150.17922-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406011451150.17922-100000@maxroach.lanl.gov>
Message-ID: <40BD04CE.6030405@nexpath.com>

ron minnich wrote:

>acpi is a big problem, partly due to the binary nature and partly because 
>it is so broken on so many platforms.
>
>ron
>  
>

Speaking of ACPI and problems, which are commented on in this article, 
is this Intel announcement of open sourcing the BIOS something new?

http://news.com.com/Intel+to+open+code+for+booting+up+PCs%2C+servers/2100-7337_3-5223860.html?tag=nefd.top

-Steve



From bari at onelabs.com  Tue Jun  1 17:37:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Tue Jun  1 17:37:01 2004
Subject: ACPI DSDT
In-Reply-To: <40BD04CE.6030405@nexpath.com>
References: <Pine.LNX.4.44.0406011451150.17922-100000@maxroach.lanl.gov> <40BD04CE.6030405@nexpath.com>
Message-ID: <40BD0AA4.4030505@onelabs.com>

Here's the official Intel statement:

http://www.intel.com/pressroom/archive/releases/20040601corp_a.htm

-Bari

Steve Gehlbach wrote:

> ron minnich wrote:
> 
>> acpi is a big problem, partly due to the binary nature and partly 
>> because it is so broken on so many platforms.
>>
>> ron
>>  
>>
> 
> Speaking of ACPI and problems, which are commented on in this article, 
> is this Intel announcement of open sourcing the BIOS something new?
> 
> http://news.com.com/Intel+to+open+code+for+booting+up+PCs%2C+servers/2100-7337_3-5223860.html?tag=nefd.top 
> 
> 
> -Steve
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 
> 




From rminnich at lanl.gov  Tue Jun  1 17:45:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun  1 17:45:01 2004
Subject: ACPI DSDT
In-Reply-To: <40BD04CE.6030405@nexpath.com>
Message-ID: <Pine.LNX.4.44.0406011635480.17922-100000@maxroach.lanl.gov>

On Tue, 1 Jun 2004, Steve Gehlbach wrote:

> Speaking of ACPI and problems, which are commented on in this article, 
> is this Intel announcement of open sourcing the BIOS something new?
> 
> http://news.com.com/Intel+to+open+code+for+booting+up+PCs%2C+servers/2100-7337_3-5223860.html?tag=nefd.top

You are not going to get the hardware startup code in Tiano. You're going
to get the code that runs on top of the hardware startup code, and gives
you a DOS-like startup system. Don't expect to suddenly see northbridge
code on the intel web site. Part of the goal of Tiano/EFI is to make the 
release of such information unneeded. 

There is a silver lining. Supposedly, the interfaces from the hidden 
hardware code to Tiano will be public. This means you can conceivably 
chuck Tiano and put your own thing in its place, which could be ... a 
Linux kernel! You might need a small shim from the hidden hardware code to 
Linux, which could in turn be ... LinuxBIOS!

This is how Linux NetWorx built the Alpha LinuxBIOS: 
- hidden hardware code (Alpha SROM) [ not changed, left in place]
- LinuxBIOS [with Alpha support, minus memory setup code]
- Linux

Worked fine, should work for Tiano platforms. In other words, the binary 
support code for Tiano could solve some problems for us: 
- if we don't get the specs for the Intel chips (likely), then we can 
  just leave the "hidden hardware code" in place, and flash over
  Tiano, replacing Tiano with LinuxBIOS. I believe Linux Labs 
  did something like this for their ClearWater port 2 years or so ago.
- Makes porting to other Intel mobos easier. 

Why the CPL, not the GPL? So that 3rd party vendors can add
incompatibilities -- err, value -- and charge you for it.

Put another way, Tiano could be a linuxbios payload. I don't have much use
for a Tiano/EFI payload, however. Tiano/EFI is very complex and if I'm
going to put a complex thing like that into flash I'd much rather it be
linux. I don't want something that's most of the work of an OS but not
much of the capability, which pretty much describes Tiano/EFI.

I'm intrigued that they are open sourcing it. I had for years only heard 
that it would be available under a type of NDA. I think LinuxBIOS is part 
of the push for open sourcing this type of software. But I doubt you're 
going to see Phoenix et. al. open source their 'value-added' Tiano, which 
means a source fork is built into the model. That's trouble for us as 
customers -- we already suffer daily with all these BIOS extensions and 
undocumented, hidden gotchas. We already say this once: there was supposed 
to be a standard "hand off" on IA64 for startup. I found out that this 
"standard" handoff was modified by several vendors: it was no longer 
standard. Let's hope the "hidden hardware code" to Tiano interface remains 
standard. 

Also, if this code is anything like the EFI code, it won't build under 
Linux, only builds under Windows. It won't "just work" for us. 

All that said, I think Intel is doing a good thing by open sourcing the
Tiano system, and I congratulate them on doing so.

ron




From rminnich at lanl.gov  Tue Jun  1 19:09:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun  1 19:09:01 2004
Subject: ACPI DSDT
In-Reply-To: <40BD0AA4.4030505@onelabs.com>
Message-ID: <Pine.LNX.4.44.0406011830320.17922-100000@maxroach.lanl.gov>

On Tue, 1 Jun 2004, Bari Ari wrote:

> Here's the official Intel statement:
> 
> http://www.intel.com/pressroom/archive/releases/20040601corp_a.htm

gee, no mention of linuxbios :-)

ron



From YhLu at tyan.com  Tue Jun  1 19:30:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun  1 19:30:01 2004
Subject: USB Boot
Message-ID: <3174569B9743D511922F00A0C9431423050646C5@TYANWEB>

Some good news.

In OHCI, bulk transfer works well.

Status: it can read sector 0 and sector 68, after that it will reboot the
system.

Regards

YH


From ebiederman at lnxi.com  Tue Jun  1 22:05:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 22:05:01 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <Pine.LNX.4.44.0406011452540.17922-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406011452540.17922-100000@maxroach.lanl.gov>
Message-ID: <m38yf6wsby.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 1 Jun 2004, Eric W. Biederman wrote:
> 
> > ron minnich <rminnich at lanl.gov> writes:
> > 
> > > just FYI, making BARS live above the 32-bit limit will break every single
> > > linux cluster here at LANL, and will also disable Plan 9.
> > 
> > Only for the hardware where the BARs move.  
> 
> guess I missed something in your writeup. Are you saying that moving all
> BARs above 2^32 won't cause trouble for a 32-bit mode linux or freebsd or
> plan 9 or ...

You can't move all BARs just 64bit BARs.  So you will lose some devices
like infiniband but not everything.  And because of limited bars to
filter things through on logical pci-pci bridges I can't throw
every 64bit BAR above 4G.
 
> > > With BARS under the 32-bit limit, you can boot anything. With BARS above 
> > > that limit, you immediately limit what you can boot. 
> > 
> > Yes.  And largely I see that as a good thing.
> 
> But do the potential users of linuxbios systems that as a good thing? I
> understand the motivation, but sometimes customers (including us) do silly
> things, such as run K8s in 32-bit mode (it's actually a good thing as a K8
> is a better Xeon than a Xeon, at least for our programs).

I had customers 3 years ago who wanted 6GB of ram.  I have been
telling salesmen that they can't sell nodes with more than 4GB of
RAM several times a year since then, because you can't use more
RAM then that in 2 MPI processes.  Customers coming from 64bit boxes
don't get why commodity machines have the silly size limits on things,
that the hardware can reasonably do.

So the demand exists.

> As long as it is an option I don't mind however. 

At this stage it would be silly not to have an option.
 
> > > In principle, I like your BAR fix, but setting up BARS that are optimized
> > > for 64-bit kernels should be a (normally disabled)  option.
> > 
> > For old clusters I agree that it should be normally disabled.
> 
> for our new cluster (Lightning) first boot is into 32-bit linux for now, 
> and will likely stay that way for a while as that system runs as 32-bits 
> (not my decision ...)
> 
> This change can hurt new clusters. 

We are still in the transition where 64bit support is maturing but if we
don't push forward we will hurt more.  x86 boxes have been > 32bit for
quite a while.  

It is a lot easier for me to explain why things suck in a 32bit kernel
and not in a 64bit kernel then the other way around.

As for things like beoboot some news.

1) Kexec is slowly making it's way into the kernel, the system call
   number as of 2.6.7-rc1 is reserved in Linus's tree. 

2) Getting a kexec that will work on x86-64 is one of the things high
   on my TODO list..  It really isn't going to be hard I just need to 
   make a little time.

3) There already exist kexec ports to ppc32 and ppc64.

I have no intention to push stable production machines to 64bits, 
I might encourage but things that work don't need to be messed with.
For new machines especially looking into next year I want 64bit
kernels.  Even if they have a 32bit user space I want 64bit kernels.

Eric


From ebiederman at lnxi.com  Tue Jun  1 23:04:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 23:04:01 2004
Subject: ACPI DSDT
In-Reply-To: <40BD04CE.6030405@nexpath.com>
References: <Pine.LNX.4.44.0406011451150.17922-100000@maxroach.lanl.gov>
	<40BD04CE.6030405@nexpath.com>
Message-ID: <m365aashx5.fsf@maxwell.lnxi.com>

Steve Gehlbach <steve at nexpath.com> writes:

> ron minnich wrote:
> 
> > acpi is a big problem, partly due to the binary nature and partly because it
> > is so broken on so many platforms.
> >
> >ron
> >
> 
> Speaking of ACPI and problems, which are commented on in this article, is this
> Intel announcement of open sourcing the BIOS something new?

EFI/Tiano uses ACPI so you don't get out of that loop.  

That Intel will be releasing code is new, although there have been some
sympathies in that direction.  I'm really not interested until they actually
release something.

Eric


From ebiederman at lnxi.com  Tue Jun  1 23:11:59 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 23:11:59 2004
Subject: ACPI DSDT
In-Reply-To: <20040601152953.GB14291@openbios.org>
References: <20040601152953.GB14291@openbios.org>
Message-ID: <m31xkyshoh.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
> 
> one thing that is generically missing in LinuxBIOS' ACPI implementation
> is the detailed system description table (DSDT The part telling whether 
> there is a lid and how detect whether it is open or closed)
> 
> The DSDT is written in ASL which is compiled to AML bytecode using an
> ASL compiler (ie. Intel's iasl) Thus, a LinuxBIOS port implementing a
> DSDT needs either to come with a precompiled DSDT or it needs an
> installed ASL compiler. What is the preferred default behaviour? 

Code we can correct and maintain so an ASL compiler.

> Do we
> want to add ASL source code or rather have something that keeps the
> build requirements for those boards as small as possible. 

We can put the code in the tree if necessary.

> Or we can pack both the ASL and AML version of the DSDT and have the 
> build process use the precompiled code only. This on the other hand
> requires developers to take care that they check in a new binary version
> when they change something to the ASL code. CVS is not doing too well
> with binary stuff.. 

Not having the source is really not GPL compatible.  We need the
preferred form for making modifications.

We certainly need to provide this information, as all motherboard
specific information is the province of the motherboard firmware.
However I'm not at all convinced that the ACPI tables are the right
approach.

At any rate we need to really solve some of the more mundane issues
like irq routing properly before we go to far with this.

Eric


From ebiederman at lnxi.com  Tue Jun  1 23:16:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 23:16:00 2004
Subject: ACPI DSDT
In-Reply-To: <Pine.LNX.4.44.0406011635480.17922-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406011635480.17922-100000@maxroach.lanl.gov>
Message-ID: <m3y8n6r2x7.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> Worked fine.

The alpha port worked but it is not something I savor repeating,
there were too many real limitations.

There are some things that I find strongly architecturally questionable
about Tiano, in the context of Intel hardware.  Unfortunately neither
Tiano or the Intel hardware I am thinking about has been released...

Consider what it takes to maintain a cache-as-ram implementation.

Eric


From YhLu at tyan.com  Tue Jun  1 23:22:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun  1 23:22:00 2004
Subject: =?GB2312?B?tPC4tDogVVNCIEJvb3Q=?=
Message-ID: <3174569B9743D511922F00A0C9431423050646DE@TYANWEB>

OHCI usb boot ok now.

But it is some slow, only 173KB/S, 

Full speed should be 12Mbps/8 = 1500KB/s

Regards

YH


Mounted fat
Image checksum: 000047da
Loading Linux version 2.6.5 (root at tst288xsuse9) #11 SMP Mon May 10 14:58:17
PDT 2004...
segment 1 addr:0x00010000 file:0x0000543c mem:0x0001a764 phdr:0xefe86654
loading... clearing... ok
segment 2 addr:0x00091000 file:0x00000000 mem:0x00000070 phdr:0xefe86674
loading... clearing... ok
segment 3 addr:0x00100000 file:0x001f5a40 mem:0x00700000 phdr:0xefe86694
loading... clearing... ok
segment 4 addr:0x00800000 file:0x005c418e mem:0x005c418e phdr:0xefe866b4
loading... clearing... ok
Loaded 8122378 bytes in 46722ms (173KB/s




-----????-----
???: YhLu 
????: 2004?6?1? 17:53
???: Steven James
??: ron minnich; Jay Miller; ebiederman at lnxi.com; LinuxBIOS
??: USB Boot

Some good news.

In OHCI, bulk transfer works well.

Status: it can read sector 0 and sector 68, after that it will reboot the
system.

Regards

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


From hansolofalcon at worldnet.att.net  Tue Jun  1 23:27:01 2004
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Tue Jun  1 23:27:01 2004
Subject: Magazine article on USB and Embedded systems
Message-ID: <000a01c4485d$2e0bcc20$6401a8c0@who5>

Hello from Gregg C Levine
An article in last months issue of ECN discusses the problems and
circumstances regarding the USB port. Specifically the use of the port
in embedded systems. At the end the editor of the magazine, who also
happened to be the article's author, asked for any messages from
people who succeeded in using a USB port in a non M$ system. 

I mentioned in that message, my efforts at getting my system to make
better use of its USB ports, those efforts included using a CF reader,
and a pair of Thumb Drives.
And of course my next efforts. I also included in those next efforts,
those that are following the work of Mr. James. For those that are
interested I will be happy to forward a copy of that message to the
author.

Since we've been discussing the merits of just such a setup, and how
to do that I mentioned it, and referred the author to the web site,
and to examine the archives on the site, or wherever they are stored.

 I'm sure he'll be able to find them. I don't think he'll want to
print anything on the Linux BIOS efforts, however, without double
checking things, such as posting a message to the list regarding the
work.  
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi




From ebiederman at lnxi.com  Tue Jun  1 23:30:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 23:30:01 2004
Subject: =?gb2312?b?tPC4tA==?=: Large mmio resources and 4G+ of RAM...
In-Reply-To: <3174569B9743D511922F00A0C943142305064656@TYANWEB>
References: <3174569B9743D511922F00A0C943142305064656@TYANWEB>
Message-ID: <m3u0xur25a.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Then in LinuxBIOS We can access the memory in 64 bit mode directly. 

We already do, on the Opteron.

> And
> maybe do the memory check and test. Memory problem is a big problem in
> system integration.

Unless you spend days at it you cannot do a good memory check/test.
I don't want to wait days while my system boots.  A cursory check
That verifies the memory doesn't totally suck is ok.  But I don't
want to see anything that conveys the impression that LinuxBIOS
has actually checked the memory.

The best tests I know of involve monitoring for ECC errors while
the system is being stressed.

> Some time 8 ways system, every cpu has 4 dimm, total memay will be
> 4G*4*8=128G.

I'm not certain you can plug that many 4G dimms into an Opteron.  At the
very least they are a challenge to come by...

As for setting up and debugging memory the first system with LinuxBIOS
on the Opteron Lighting had 6TB of ram...

Eric


From ebiederman at lnxi.com  Tue Jun  1 23:42:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 23:42:00 2004
Subject: =?gb2312?b?tPC4tA==?=: USB Boot
In-Reply-To: <3174569B9743D511922F00A0C9431423050646DE@TYANWEB>
References: <3174569B9743D511922F00A0C9431423050646DE@TYANWEB>
Message-ID: <m3wu2qo8k8.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> OHCI usb boot ok now.
> 
> But it is some slow, only 173KB/S, 
> 
> Full speed should be 12Mbps/8 = 1500KB/s

Congratulations.

Eric



From ebiederman at lnxi.com  Tue Jun  1 23:53:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  1 23:53:00 2004
Subject: Hibernation?
In-Reply-To: <1084545894.40a4db667ef56@www.mailshell.com>
References: <1084545894.40a4db667ef56@www.mailshell.com>
Message-ID: <m3smdeo7xa.fsf@maxwell.lnxi.com>

<lbios_kk at redfenix.com> writes:

> I'm sure if someone has thought of doing this before, but I haven't found
> mention of it anywhere.
> 
> 
> Has any work been done toward the goal of "Hibernation"?  I'm writing of the
> type that would use a separate partition equal to ram + swap space to store the
> current memory state.  If no one has done any work to this effect, how difficult
> would it be?  I may be willing to help the effort.  I've never programmed for a
> BIOS, but I've done mmap() stuff before.

For suspend to RAM there is legitimate BIOS involvement.

For all else the OS can do it.

As for the OS independence argument.  I don't see the point of
making the hardware abstraction layer hardware independent.


Eric


From stepan at openbios.org  Wed Jun  2 03:32:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Jun  2 03:32:00 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <Pine.LNX.4.44.0406011450120.17922-100000@maxroach.lanl.gov>
References: <40BCA128.8060400@onelabs.com> <Pine.LNX.4.44.0406011450120.17922-100000@maxroach.lanl.gov>
Message-ID: <20040602085457.GA23428@openbios.org>

* ron minnich <rminnich at lanl.gov> [040601 22:50]:
> word from someone who knows that acpi tables have many errors. Windows 
> drivers work around the bugs in acpi tables. Linux follows the spec 
> closely, hence the problems people see with linux+acpi. 

Ron, 

you are perfectly right with the fact that ACPI tables are very often
buggy. But this strengthens the case against (some) commercial bios writers
rather than against ACPI as a concept. Still it is a sound argument that
the complexity of something that could be really simple drives bios
writers to include these bugs.

Yet, there's often the case of ACPI tables working around bugs in
Windows' ACPI implementation which can cause problems on Linux. Another
one of the most stupid things I've ever seen is that ACPI can have
different code paths for different OSes.  Thus, of course ACPI writers
go the usual way: "Works with Windows, we can ship it." I have seen
quite a couple boards that were able to cope fine with Linux ACPI after
Linux has been told to pass the Windows ID string to the ACPI code.

One thing that is generally good about ACPI (well in some sense) is that
it is free of callbacks, which I often hear as a disadvantage of Open
Firmware's interface. (While dropping callbacks in OF is just a matter
of directly providing the FCode drivers to the OS and let a hosted Open 
Source OF implementation use it there)

Stefan



From stepan at openbios.org  Wed Jun  2 04:07:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Jun  2 04:07:00 2004
Subject: ACPI DSDT
In-Reply-To: <m31xkyshoh.fsf@maxwell.lnxi.com>
References: <20040601152953.GB14291@openbios.org> <m31xkyshoh.fsf@maxwell.lnxi.com>
Message-ID: <20040602093000.GD23428@openbios.org>

Hi,

* Eric W. Biederman <ebiederman at lnxi.com> [040602 06:33]:
> We certainly need to provide this information, as all motherboard
> specific information is the province of the motherboard firmware.
> However I'm not at all convinced that the ACPI tables are the right
> approach.
 
Can you go a bit into detail with this? In earlier discussions I
understood your standpoint as clearly on the table based side. Whether
such a table is called ACPI or LBTable is imho just a minor
implementation detail with the one being supported by more OSes and
companies while the other is definitely the one with the cleaner design.

> At any rate we need to really solve some of the more mundane issues
> like irq routing properly before we go to far with this.

Much of this can be described in ACPI tables, dropping the need for
MPtables and PIRQ tables. I think the modular concept of LinuxBIOS
really allows developers to address one issue without hurting
another. The current way of irq routing is less than elegant, I agree,
but it does it's job, taking the all-monthly fixing behind into regard.

Stefan



From stepan at openbios.org  Wed Jun  2 04:40:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Jun  2 04:40:01 2004
Subject: ACPI DSDT
In-Reply-To: <40BD04CE.6030405@nexpath.com>
References: <Pine.LNX.4.44.0406011451150.17922-100000@maxroach.lanl.gov> <40BD04CE.6030405@nexpath.com>
Message-ID: <20040602100233.GE23428@openbios.org>

* Steve Gehlbach <steve at nexpath.com> [040602 00:35]:
> 
> Speaking of ACPI and problems, which are commented on in this article, 
> is this Intel announcement of open sourcing the BIOS something new?
> 
> http://news.com.com/Intel+to+open+code+for+booting+up+PCs%2C+servers/2100-7337_3-5223860.html?tag=nefd.top

What did they change, the license?  They have had parts of EFI sources
on their web server for quite some years now. Reading the EFI
specification should be enough reason not to look into the code. It's
really all-embracing.  Besides that the source license was critical for
firmware developers (IANAL). 

Standards are a fine thing. Let's have everybody implement it's own.

Stefan


From ebiederman at lnxi.com  Wed Jun  2 04:56:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jun  2 04:56:01 2004
Subject: ACPI DSDT
In-Reply-To: <20040602093000.GD23428@openbios.org>
References: <20040601152953.GB14291@openbios.org>
	<m31xkyshoh.fsf@maxwell.lnxi.com>
	<20040602093000.GD23428@openbios.org>
Message-ID: <m3d64il0rd.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi,
> 
> * Eric W. Biederman <ebiederman at lnxi.com> [040602 06:33]:
> > We certainly need to provide this information, as all motherboard
> > specific information is the province of the motherboard firmware.
> > However I'm not at all convinced that the ACPI tables are the right
> > approach.
>  
> Can you go a bit into detail with this? In earlier discussions I
> understood your standpoint as clearly on the table based side. Whether
> such a table is called ACPI or LBTable is imho just a minor
> implementation detail with the one being supported by more OSes and
> companies while the other is definitely the one with the cleaner design.

At that point I was thinking AML...
Tables are certainly a good thing.  A bad excuse for byte code...
 
> > At any rate we need to really solve some of the more mundane issues
> > like irq routing properly before we go to far with this.
> 
> Much of this can be described in ACPI tables, dropping the need for
> MPtables and PIRQ tables. I think the modular concept of LinuxBIOS
> really allows developers to address one issue without hurting
> another. The current way of irq routing is less than elegant, I agree,
> but it does it's job, taking the all-monthly fixing behind into regard.

I guess what I am after is enough structure so that it is hard to implement
something wrong.  Either it is implemented correctly or it is not implemented.
We largely have this in LinuxBIOS because we use the information we export.
This is not a property I want to loose.

Eric


From stuge-linuxbios at cdy.org  Wed Jun  2 06:41:01 2004
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed Jun  2 06:41:01 2004
Subject: USB Boot
In-Reply-To: <3174569B9743D511922F00A0C9431423050646DE@TYANWEB>
References: <3174569B9743D511922F00A0C9431423050646DE@TYANWEB>
Message-ID: <20040602120358.GC14222@foo.birdnet.se>

On Tue, Jun 01, 2004 at 09:42:20PM -0700, YhLu wrote:
> OHCI usb boot ok now.

Agree with Eric, congratulations! :)


> But it is some slow, only 173KB/S, 
> 
> Full speed should be 12Mbps/8 = 1500KB/s

Actually not. 12Mbps is the speed on the USB wire and each of the
protocols in the stack and in the application causes some overhead,
as you know.

I don't know much specifically about USB storage but I'd guesstimate
the maximum possible throughput somewhere between 1000kb/s and
1400kb/s. The simplest optimization is to increase the block
transfer size to always try to transfer full 64kb, if that hasn't
been done already.

Great to have a complete USB boot solution anyway!


//Peter


From jmiller at actuality-systems.com  Wed Jun  2 07:20:00 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Wed Jun  2 07:20:00 2004
Subject: testbios info?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F14AE7A@mail.local.ActualitySystems.com>

Can someone post a quick rundown on testbios?

I know that you get the vgabios from the card, and run that through
testbios.  But how do you get linuxbios to use the results?

I'm missing something.

Thanks,

Jay Miller
Actuality Systems, Inc.
jmiller at acutality-systems.com





From c.petersen at peterschen.de  Wed Jun  2 08:11:01 2004
From: c.petersen at peterschen.de (Christoph Petersen)
Date: Wed Jun  2 08:11:01 2004
Subject: LinuxBIOS available for Asus A7N8X
Message-ID: <200406021210.i52CAkK03279@nwn.definitive.org>

Hi,

is LinuxBIOS available for the Asus A7N8X Deluxe mainboard?
Better to say: Would I crash my ROM when I try to flash it with
LinuxBIOS.

I'm really interested in LinuxBIOS for use in quick boot devices such as
mp3-player for car's which based on computers.

Greets
Christoph





From rminnich at lanl.gov  Wed Jun  2 08:27:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 08:27:00 2004
Subject: Large mmio resources and 4G+ of RAM...
In-Reply-To: <m38yf6wsby.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406020749180.24798-100000@maxroach.lanl.gov>

On 1 Jun 2004, Eric W. Biederman wrote:

> At this stage it would be silly not to have an option.

well then we are on the same page, I'm looking forward to having it boot 
with no legacy 32-bit nonsense in there :-)

ron



From rminnich at lanl.gov  Wed Jun  2 08:30:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 08:30:00 2004
Subject: ACPI DSDT
In-Reply-To: <m365aashx5.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406020750030.24798-100000@maxroach.lanl.gov>

On 1 Jun 2004, Eric W. Biederman wrote:

> That Intel will be releasing code is new, although there have been some
> sympathies in that direction.  I'm really not interested until they actually
> release something.

Should probably also mention: there's lots of binary in this EFI/Tiano 
thing. Binary drivers, for example. The goal is that EFI/Tiano should 
provide a framework for a mostly binary system (chipsets, drivers, etc. 
are binary).

ron



From rminnich at lanl.gov  Wed Jun  2 08:32:51 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 08:32:51 2004
Subject: ACPI DSDT
In-Reply-To: <m3y8n6r2x7.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406020751180.24798-100000@maxroach.lanl.gov>

On 1 Jun 2004, Eric W. Biederman wrote:

> The alpha port worked but it is not something I savor repeating,
> there were too many real limitations.

yes, but by golly we sure got some use out of it! We appreciated your work 
:-)

> There are some things that I find strongly architecturally questionable
> about Tiano, in the context of Intel hardware.  Unfortunately neither
> Tiano or the Intel hardware I am thinking about has been released...

agreed. Let's see if we get much more than PR.

ron



From rminnich at lanl.gov  Wed Jun  2 08:36:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 08:36:01 2004
Subject: Magazine article on USB and Embedded systems
In-Reply-To: <000a01c4485d$2e0bcc20$6401a8c0@who5>
Message-ID: <Pine.LNX.4.44.0406020753040.24798-100000@maxroach.lanl.gov>

I think that these experiences only strengthen my feeling that we want 
linux in there as the bios. We're going to recreate all that work. Anybody 
ready to squeeze 2.6 in there? We all want it but nobody has had time yet.

ron



From rminnich at lanl.gov  Wed Jun  2 08:38:54 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 08:38:54 2004
Subject: =?gb2312?b?tPC4tA==?=: Large mmio resources and 4G+ of RAM...
In-Reply-To: <m3u0xur25a.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406020754010.24798-100000@maxroach.lanl.gov>

On 1 Jun 2004, Eric W. Biederman wrote:

> Unless you spend days at it you cannot do a good memory check/test. I
> don't want to wait days while my system boots.  A cursory check That
> verifies the memory doesn't totally suck is ok.  But I don't want to see
> anything that conveys the impression that LinuxBIOS has actually checked
> the memory.

yes, bios memory tests are completely useless, have only found a memory 
error for me when the DIMM was half out of its socket!

ron



From rminnich at lanl.gov  Wed Jun  2 08:41:44 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 08:41:44 2004
Subject: Hibernation?
In-Reply-To: <m3smdeo7xa.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406020754500.24798-100000@maxroach.lanl.gov>

FYI, the Xen project is now demonstrating linux suspension under Xen. 

Interesting stuff.

ron



From rsmith at bitworks.com  Wed Jun  2 09:00:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Wed Jun  2 09:00:01 2004
Subject: testbios info?
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F14AE7A@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F14AE7A@mail.local.ActualitySystems.com>
Message-ID: <40BDE2B6.3090708@bitworks.com>

Jay Miller wrote:

> Can someone post a quick rundown on testbios?
> 
> I know that you get the vgabios from the card, and run that through
> testbios.  But how do you get linuxbios to use the results?
> 
> I'm missing something.

Not really.  Right now thats it.  Testbios is the testbed for getting 
the emulation layer working good enough to include into linuxBIOS.

I beleive that ollie is working on mergeing in testbios into the v2 core 
now that it supports int10 replacemnet.





From ollie at lanl.gov  Wed Jun  2 10:45:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Jun  2 10:45:01 2004
Subject: testbios info?
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F14AE7A@mail.local.ActualitySystems.com>
References: 	 <E8F8DBCB0468204E856114A2CD20741F14AE7A@mail.local.ActualitySystems.com>
Message-ID: <1086192461.22884.6.camel@exponential.lanl.gov>

On Wed, 2004-06-02 at 06:40, Jay Miller wrote:
> Can someone post a quick rundown on testbios?
> 
> I know that you get the vgabios from the card, and run that through
> testbios.  But how do you get linuxbios to use the results?
> 

Currently it is only used as a userspace program to init VGA cards
after Linux is booted. After getting more test case and feedback,
I will try to merge it in to LinuxBIOS.

The emulator will be one of the init/configure method of the generic
VGA device driver.

Ollie

> I'm missing something.
> 
> Thanks,
> 
> Jay Miller
> Actuality Systems, Inc.
> jmiller at acutality-systems.com
> 
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rminnich at lanl.gov  Wed Jun  2 10:55:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 10:55:01 2004
Subject: testbios info?
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F14AE7A@mail.local.ActualitySystems.com>
Message-ID: <Pine.LNX.4.44.0406021017330.25637-100000@maxroach.lanl.gov>

On Wed, 2 Jun 2004, Jay Miller wrote:

> Can someone post a quick rundown on testbios?
> 
> I know that you get the vgabios from the card, and run that through
> testbios.  But how do you get linuxbios to use the results?

linuxbios does not use testbios yet. You run testbios under linux. Sorry, 
this is coming but not done yet.

ron



From rminnich at lanl.gov  Wed Jun  2 10:57:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 10:57:01 2004
Subject: LinuxBIOS available for Asus A7N8X
In-Reply-To: <200406021210.i52CAkK03279@nwn.definitive.org>
Message-ID: <Pine.LNX.4.44.0406021018550.25637-100000@maxroach.lanl.gov>

what's the chipset? send lspci.

ron



From rminnich at lanl.gov  Wed Jun  2 11:01:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 11:01:01 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <20040602085457.GA23428@openbios.org>
Message-ID: <Pine.LNX.4.44.0406021013140.25637-100000@maxroach.lanl.gov>

On Wed, 2 Jun 2004, Stefan Reinauer wrote:

> One thing that is generally good about ACPI (well in some sense) is that
> it is free of callbacks, which I often hear as a disadvantage of Open
> Firmware's interface. (While dropping callbacks in OF is just a matter
> of directly providing the FCode drivers to the OS and let a hosted Open
> Source OF implementation use it there)

What would be neat is to decompile an ACPI table from binary, and ship 
that in the linuxbios image. THen you get most flexibility.

Or am I nuts?

ron



From adam at cfar.umd.edu  Wed Jun  2 11:14:00 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Wed Jun  2 11:14:00 2004
Subject: ACPI DSDT
In-Reply-To: <Pine.LNX.4.44.0406011635480.17922-100000@maxroach.lanl.gov>
Message-ID: <20040602123546.Q97335-100000@www.missl.cs.umd.edu>

also, one of the huge advantages of the linuxBIOS Is that it allows to
workaround bugs in the hardware and firmware. If we decide to go with
Tiano's hardware startup code we lose some of this flexibility. something
to keep in mind.

it reminds me all the nightmare linux has with its binary only modules and
hal's. There's no binary only driver for driver foo for linux on ppc? too
bad

On Tue, 1 Jun 2004, ron minnich wrote:

> On Tue, 1 Jun 2004, Steve Gehlbach wrote:
>
> > Speaking of ACPI and problems, which are commented on in this article,
> > is this Intel announcement of open sourcing the BIOS something new?
> >
> > http://news.com.com/Intel+to+open+code+for+booting+up+PCs%2C+servers/2100-7337_3-5223860.html?tag=nefd.top
>
> You are not going to get the hardware startup code in Tiano. You're going
> to get the code that runs on top of the hardware startup code, and gives
> you a DOS-like startup system. Don't expect to suddenly see northbridge
> code on the intel web site. Part of the goal of Tiano/EFI is to make the
> release of such information unneeded.
>
> There is a silver lining. Supposedly, the interfaces from the hidden
> hardware code to Tiano will be public. This means you can conceivably
> chuck Tiano and put your own thing in its place, which could be ... a
> Linux kernel! You might need a small shim from the hidden hardware code to
> Linux, which could in turn be ... LinuxBIOS!
>
> This is how Linux NetWorx built the Alpha LinuxBIOS:
> - hidden hardware code (Alpha SROM) [ not changed, left in place]
> - LinuxBIOS [with Alpha support, minus memory setup code]
> - Linux
>
> Worked fine, should work for Tiano platforms. In other words, the binary
> support code for Tiano could solve some problems for us:
> - if we don't get the specs for the Intel chips (likely), then we can
>   just leave the "hidden hardware code" in place, and flash over
>   Tiano, replacing Tiano with LinuxBIOS. I believe Linux Labs
>   did something like this for their ClearWater port 2 years or so ago.
> - Makes porting to other Intel mobos easier.
>
> Why the CPL, not the GPL? So that 3rd party vendors can add
> incompatibilities -- err, value -- and charge you for it.
>
> Put another way, Tiano could be a linuxbios payload. I don't have much use
> for a Tiano/EFI payload, however. Tiano/EFI is very complex and if I'm
> going to put a complex thing like that into flash I'd much rather it be
> linux. I don't want something that's most of the work of an OS but not
> much of the capability, which pretty much describes Tiano/EFI.
>
> I'm intrigued that they are open sourcing it. I had for years only heard
> that it would be available under a type of NDA. I think LinuxBIOS is part
> of the push for open sourcing this type of software. But I doubt you're
> going to see Phoenix et. al. open source their 'value-added' Tiano, which
> means a source fork is built into the model. That's trouble for us as
> customers -- we already suffer daily with all these BIOS extensions and
> undocumented, hidden gotchas. We already say this once: there was supposed
> to be a standard "hand off" on IA64 for startup. I found out that this
> "standard" handoff was modified by several vendors: it was no longer
> standard. Let's hope the "hidden hardware code" to Tiano interface remains
> standard.
>
> Also, if this code is anything like the EFI code, it won't build under
> Linux, only builds under Windows. It won't "just work" for us.
>
> All that said, I think Intel is doing a good thing by open sourcing the
> Tiano system, and I congratulate them on doing so.
>
> ron
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From adam at cfar.umd.edu  Wed Jun  2 11:15:00 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Wed Jun  2 11:15:00 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <Pine.LNX.4.44.0406021013140.25637-100000@maxroach.lanl.gov>
Message-ID: <20040602124111.A97335-100000@www.missl.cs.umd.edu>

> > One thing that is generally good about ACPI (well in some sense) is that
> > it is free of callbacks, which I often hear as a disadvantage of Open
> > Firmware's interface. (While dropping callbacks in OF is just a matter
> > of directly providing the FCode drivers to the OS and let a hosted Open
> > Source OF implementation use it there)
>
> What would be neat is to decompile an ACPI table from binary, and ship
> that in the linuxbios image. THen you get most flexibility.

FWIW, this shows how to move your ACPI's DSDT table from bios to linux
kernel, perhaps potentially elimitnating need for it in linuxbios
altogether.

http://home.fhtw-berlin.de/~s0502837/r31/



From YhLu at tyan.com  Wed Jun  2 11:17:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jun  2 11:17:01 2004
Subject: =?GB2312?B?tPC4tDogTWFnYXppbmUgYXJ0aWNsZSBvbiBVU0IgYW5kIEVtYmVk?=
	=?GB2312?B?ZGVkIHN5c3RlbXM=?=
Message-ID: <3174569B9743D511922F00A0C9431423050646EC@TYANWEB>

I agree. We can use LinuxBIOS + boot from USB stick, the elf or
kernel+rootfs is in usb stick. 

After that we can use everything about USB in Kernel.

Regards

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?6?2? 6:54
???: Gregg C Levine
??: Linuxbios
??: Re: Magazine article on USB and Embedded systems

I think that these experiences only strengthen my feeling that we want 
linux in there as the bios. We're going to recreate all that work. Anybody 
ready to squeeze 2.6 in there? We all want it but nobody has had time yet.

ron

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


From YhLu at tyan.com  Wed Jun  2 11:19:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jun  2 11:19:01 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogTGFyZ2UgbW1pbyByZXNvdXJjZXMgYW5kIDRH?=
	=?GB2312?B?KyBvZiBSQU0uLi4=?=
Message-ID: <3174569B9743D511922F00A0C9431423050646ED@TYANWEB>

So need to use memtest to test memory?

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?6?2? 6:55
???: Eric W. Biederman
??: YhLu; Stefan Reinauer; LinuxBIOS
??: Re: ??: Large mmio resources and 4G+ of RAM...

On 1 Jun 2004, Eric W. Biederman wrote:

> Unless you spend days at it you cannot do a good memory check/test. I
> don't want to wait days while my system boots.  A cursory check That
> verifies the memory doesn't totally suck is ok.  But I don't want to see
> anything that conveys the impression that LinuxBIOS has actually checked
> the memory.

yes, bios memory tests are completely useless, have only found a memory 
error for me when the DIMM was half out of its socket!

ron


From rminnich at lanl.gov  Wed Jun  2 11:24:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 11:24:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogTGFyZ2UgbW1pbyByZXNvdXJjZXMgYW5kIDRH?=
 =?GB2312?B?KyBvZiBSQU0uLi4=?=
In-Reply-To: <3174569B9743D511922F00A0C9431423050646ED@TYANWEB>
Message-ID: <Pine.LNX.4.44.0406021046060.25637-100000@maxroach.lanl.gov>

On Wed, 2 Jun 2004, YhLu wrote:

> So need to use memtest to test memory?

don't test it at all. Just use it, the kernel will find the problems more 
effectively than memtest will.

Besides many problems only occur after the system has been on for a while.

ron



From backblue at netcabo.pt  Wed Jun  2 11:33:01 2004
From: backblue at netcabo.pt (backblue)
Date: Wed Jun  2 11:33:01 2004
Subject: LinuxBIOS available for Asus A7N8X
In-Reply-To: <Pine.LNX.4.44.0406021018550.25637-100000@maxroach.lanl.gov>
References: <200406021210.i52CAkK03279@nwn.definitive.org>
	<Pine.LNX.4.44.0406021018550.25637-100000@maxroach.lanl.gov>
Message-ID: <20040601180002.6d15c281@fork.ketic.com>

One of my boards are like that one, chipset it's nforce2.

On Wed, 2 Jun 2004 10:19:00 -0600 (MDT)
ron minnich <rminnich at lanl.gov> wrote:

> what's the chipset? send lspci.
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Wed Jun  2 11:35:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  2 11:35:01 2004
Subject: LinuxBIOS available for Asus A7N8X
In-Reply-To: <20040601180002.6d15c281@fork.ketic.com>
Message-ID: <Pine.LNX.4.44.0406021057390.25637-100000@maxroach.lanl.gov>

On Tue, 1 Jun 2004, backblue wrote:

> One of my boards are like that one, chipset it's nforce2.

no luck.

ron



From jmiller at actuality-systems.com  Wed Jun  2 11:45:01 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Wed Jun  2 11:45:01 2004
Subject: testbios info?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F14AEA4@mail.local.ActualitySystems.com>

Thanks!  I just did not know when to run it, but now I should be able to
get it working.

-J

-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Wednesday, June 02, 2004 12:08 PM
To: Jay Miller
Cc: LinuxBIOS
Subject: Re: testbios info?

On Wed, 2004-06-02 at 06:40, Jay Miller wrote:
> Can someone post a quick rundown on testbios?
> 
> I know that you get the vgabios from the card, and run that through
> testbios.  But how do you get linuxbios to use the results?
> 

Currently it is only used as a userspace program to init VGA cards
after Linux is booted. After getting more test case and feedback,
I will try to merge it in to LinuxBIOS.

The emulator will be one of the init/configure method of the generic
VGA device driver.

Ollie

> I'm missing something.
> 
> Thanks,
> 
> Jay Miller
> Actuality Systems, Inc.
> jmiller at acutality-systems.com
> 
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 





From ollie at lanl.gov  Wed Jun  2 11:47:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Jun  2 11:47:01 2004
Subject: testbios info?
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F14AEA4@mail.local.ActualitySystems.com>
References: 	 <E8F8DBCB0468204E856114A2CD20741F14AEA4@mail.local.ActualitySystems.com>
Message-ID: <1086196196.22884.15.camel@exponential.lanl.gov>

On Wed, 2004-06-02 at 11:03, Jay Miller wrote:
> Thanks!  I just did not know when to run it, but now I should be able to
> get it working.
> 

did you get the lates version ? The ssh in LANL is broken today so I 
can't commit my working version to the CVS.

Ollie

> -J
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Wednesday, June 02, 2004 12:08 PM
> To: Jay Miller
> Cc: LinuxBIOS
> Subject: Re: testbios info?
> 
> On Wed, 2004-06-02 at 06:40, Jay Miller wrote:
> > Can someone post a quick rundown on testbios?
> > 
> > I know that you get the vgabios from the card, and run that through
> > testbios.  But how do you get linuxbios to use the results?
> > 
> 
> Currently it is only used as a userspace program to init VGA cards
> after Linux is booted. After getting more test case and feedback,
> I will try to merge it in to LinuxBIOS.
> 
> The emulator will be one of the init/configure method of the generic
> VGA device driver.
> 
> Ollie
> 
> > I'm missing something.
> > 
> > Thanks,
> > 
> > Jay Miller
> > Actuality Systems, Inc.
> > jmiller at acutality-systems.com
> > 
> > 
> > 
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > 
> 
> 
> 
> 



From jmiller at actuality-systems.com  Wed Jun  2 11:51:00 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Wed Jun  2 11:51:00 2004
Subject: testbios info?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F14AEA9@mail.local.ActualitySystems.com>

No I don't think I have your fixes.  Would it be possible to get a
tarball?

Thanks,

J
-----Original Message-----
From: Li-Ta Lo [mailto:ollie at lanl.gov] 
Sent: Wednesday, June 02, 2004 1:10 PM
To: Jay Miller
Cc: LinuxBIOS
Subject: RE: testbios info?

On Wed, 2004-06-02 at 11:03, Jay Miller wrote:
> Thanks!  I just did not know when to run it, but now I should be able
to
> get it working.
> 

did you get the lates version ? The ssh in LANL is broken today so I 
can't commit my working version to the CVS.

Ollie

> -J
> 
> -----Original Message-----
> From: Li-Ta Lo [mailto:ollie at lanl.gov] 
> Sent: Wednesday, June 02, 2004 12:08 PM
> To: Jay Miller
> Cc: LinuxBIOS
> Subject: Re: testbios info?
> 
> On Wed, 2004-06-02 at 06:40, Jay Miller wrote:
> > Can someone post a quick rundown on testbios?
> > 
> > I know that you get the vgabios from the card, and run that through
> > testbios.  But how do you get linuxbios to use the results?
> > 
> 
> Currently it is only used as a userspace program to init VGA cards
> after Linux is booted. After getting more test case and feedback,
> I will try to merge it in to LinuxBIOS.
> 
> The emulator will be one of the init/configure method of the generic
> VGA device driver.
> 
> Ollie
> 
> > I'm missing something.
> > 
> > Thanks,
> > 
> > Jay Miller
> > Actuality Systems, Inc.
> > jmiller at acutality-systems.com
> > 
> > 
> > 
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > 
> 
> 
> 
> 





From stepan at openbios.org  Wed Jun  2 12:42:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Jun  2 12:42:00 2004
Subject: testbios info?
In-Reply-To: <1086196196.22884.15.camel@exponential.lanl.gov>
References: <E8F8DBCB0468204E856114A2CD20741F14AEA4@mail.local.ActualitySystems.com> <1086196196.22884.15.camel@exponential.lanl.gov>
Message-ID: <20040602180501.GA29361@openbios.org>

* Li-Ta Lo <ollie at lanl.gov> [040602 19:09]:
> On Wed, 2004-06-02 at 11:03, Jay Miller wrote:
> 
> did you get the lates version ? The ssh in LANL is broken today so I 
> can't commit my working version to the CVS.

Are you sure it's a LANL problem? I've had problems with the CVS-via-SSH
checkout the last few days as I had earlier with anonymous checkout.
Only every one in ten attempts gets through, but I did not give up..

Stefan



From ollie at lanl.gov  Wed Jun  2 13:38:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Jun  2 13:38:01 2004
Subject: testbios info?
In-Reply-To: <20040602180501.GA29361@openbios.org>
References: 	 <E8F8DBCB0468204E856114A2CD20741F14AEA4@mail.local.ActualitySystems.com>
	 <1086196196.22884.15.camel@exponential.lanl.gov>
	 <20040602180501.GA29361@openbios.org>
Message-ID: <1086202852.22884.19.camel@exponential.lanl.gov>

On Wed, 2004-06-02 at 12:05, Stefan Reinauer wrote:
> * Li-Ta Lo <ollie at lanl.gov> [040602 19:09]:
> > On Wed, 2004-06-02 at 11:03, Jay Miller wrote:
> > 
> > did you get the lates version ? The ssh in LANL is broken today so I 
> > can't commit my working version to the CVS.
> 
> Are you sure it's a LANL problem? I've had problems with the CVS-via-SSH
> checkout the last few days as I had earlier with anonymous checkout.
> Only every one in ten attempts gets through, but I did not give up..
> 

They are both. I have problems to do anonymous pserver for some other 
sourceforge projects yesterday from my home. And today the netwrok
guys at LANL added new restirctions for using SSH inside LANL.

Ollie

> Stefan
> 



From miernik at ctnet.pl  Wed Jun  2 13:47:00 2004
From: miernik at ctnet.pl (Miernik)
Date: Wed Jun  2 13:47:00 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
References: <Pine.LNX.4.44.0406011448321.17922-100000@maxroach.lanl.gov> <40BCEE37.90308@onelabs.com>
Message-ID: <20040602185630.1F9C.a.NOFFLE%miernik@ctnet.pl.local>

Bari Ari <bari at onelabs.com> wrote:
> 
> The Linspire laptop http://www.sub300.com/port.htm pretty much an Epia 
> with a keyboard controller. 

BTW: Is it an EPIA or EPIA-M ?

> Not very glamorous but if it has a Renesas 
> keyboard super I/O controller I might be interested and getting it up 
> under LinuxBIOS.

Can someone who has the Linspire laptop, and is willing to open the 
case voiding the warranty, could check what is the keyboard controller?

Bari, how do you recognize the keyboard controller chip?
Are there any example images?

-- 
    Miernik         _________________________  xmpp:miernik at amessage.info
___________________/__ tel: +48888299997 __/      mailto:miernik at ctnet.pl
http://www.miernik.ctnet.pl/



From bari at onelabs.com  Wed Jun  2 14:31:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Jun  2 14:31:00 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <20040602185630.1F9C.a.NOFFLE%miernik@ctnet.pl.local>
References: <Pine.LNX.4.44.0406011448321.17922-100000@maxroach.lanl.gov> <40BCEE37.90308@onelabs.com> <20040602185630.1F9C.a.NOFFLE%miernik@ctnet.pl.local>
Message-ID: <40BE30C4.9040208@onelabs.com>

Miernik wrote:

> Bari Ari <bari at onelabs.com> wrote:
> 
>>The Linspire laptop http://www.sub300.com/port.htm pretty much an Epia 
>>with a keyboard controller. 
> 
> 
> BTW: Is it an EPIA or EPIA-M ?
> 
I really have no idea. That's what someone else had posted.

>>Not very glamorous but if it has a Renesas 
>>keyboard super I/O controller I might be interested and getting it up 
>>under LinuxBIOS.
> 
> 
> Can someone who has the Linspire laptop, and is willing to open the 
> case voiding the warranty, could check what is the keyboard controller?
> 
> Bari, how do you recognize the keyboard controller chip?
> Are there any example images?
> 
They just look like another chip. You have to check the part numbers to 
find out.

-Bari




From linuxbios at matter.net  Wed Jun  2 18:23:01 2004
From: linuxbios at matter.net (Larry Matter)
Date: Wed Jun  2 18:23:01 2004
Subject: Filo and cardbus (EPIA MII)
Message-ID: <64111.148.87.1.171.1086219915.squirrel@mail.matter.net>

I have an EPIA MII, which has an on-board CF adapter.  Unfortunately it is
not an IDE interface, but rather cardbus.

I know I could just buy a cheap CF-IDE adaptor, but it just seems a shame
that I can't boot from a CF card in that slot.

I was wondering how difficult it would be to add support to FILO to enable
that device and read from it.   I'm not familiar with device drivers, but
it seems to me that enough of the pieces of the puzzle are there (open
source drivers for the hardware, e.g. yenta socket) and that a solution
could be crafted.

Has anyone else considered it?

Thanks,
Larry Matter


From ebiederman at lnxi.com  Wed Jun  2 19:42:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jun  2 19:42:00 2004
Subject: Magazine article on USB and Embedded systems
In-Reply-To: <Pine.LNX.4.44.0406020753040.24798-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406020753040.24798-100000@maxroach.lanl.gov>
Message-ID: <m3oeo1ppb3.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> I think that these experiences only strengthen my feeling that we want 
> linux in there as the bios. We're going to recreate all that work. Anybody 
> ready to squeeze 2.6 in there? We all want it but nobody has had time yet.

Pretty much:

Grab the tiny patch and kexec and have fun.
http://selenic.com/tiny-about

Things never go as planned but as soon as I am done with my current
linuxbios port I will likely have some time.  This 32Mb rom seems
to have enough room in it..

Eric



From ebiederman at lnxi.com  Wed Jun  2 19:42:35 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jun  2 19:42:35 2004
Subject: [Fwd: Re: Linuxbios and Linspire laptop]
In-Reply-To: <Pine.LNX.4.44.0406021013140.25637-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406021013140.25637-100000@maxroach.lanl.gov>
Message-ID: <m3smddppfm.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Wed, 2 Jun 2004, Stefan Reinauer wrote:
> 
> > One thing that is generally good about ACPI (well in some sense) is that
> > it is free of callbacks, which I often hear as a disadvantage of Open
> > Firmware's interface. (While dropping callbacks in OF is just a matter
> > of directly providing the FCode drivers to the OS and let a hosted Open
> > Source OF implementation use it there)
> 
> What would be neat is to decompile an ACPI table from binary, and ship 
> that in the linuxbios image. THen you get most flexibility.
> 
> Or am I nuts?

We need to be careful of copyright consideration there.
But otherwise it looks like a possible idea.

Eric


From YhLu at tyan.com  Wed Jun  2 20:47:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jun  2 20:47:00 2004
Subject: =?GB2312?B?tPC4tDogTWFnYXppbmUgYXJ0aWNsZSBvbiBVU0IgYW5kIEVtYmVk?=
	=?GB2312?B?ZGVkIHN5c3RlbXM=?=
Message-ID: <3174569B9743D511922F00A0C94314230506475D@TYANWEB>

That's kernel, how about rootfs or initrd?

Regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?2? 15:29
???: ron minnich
??: Gregg C Levine; Linuxbios
??: Re: Magazine article on USB and Embedded systems

ron minnich <rminnich at lanl.gov> writes:

> I think that these experiences only strengthen my feeling that we want 
> linux in there as the bios. We're going to recreate all that work. Anybody

> ready to squeeze 2.6 in there? We all want it but nobody has had time yet.

Pretty much:

Grab the tiny patch and kexec and have fun.
http://selenic.com/tiny-about

Things never go as planned but as soon as I am done with my current
linuxbios port I will likely have some time.  This 32Mb rom seems
to have enough room in it..

Eric

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


From YhLu at tyan.com  Wed Jun  2 22:00:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jun  2 22:00:01 2004
Subject: w86327hf superio.c
Message-ID: <3174569B9743D511922F00A0C943142305064765@TYANWEB>

Someone overwrite the superio.c for w86327hf.

Before that it enter_ext_func mode and enable HWM of Winbond.

Regards

YH


From John.Usher at perth.maptek.com.au  Wed Jun  2 22:14:00 2004
From: John.Usher at perth.maptek.com.au (John Usher (Maptek))
Date: Wed Jun  2 22:14:00 2004
Subject: romcc questions
Message-ID: <20E0F651F8B82F45ABCBACC58A2D995B35B3B8@mexper1>

Hi, I'm trying to get freebios2 going on a VT8606/VT82C686B board with a
533MHz VIA C3 processor.
 
When trying to compile romcc, it gets to simple_test26 but reports it is
out of registers.
 
Can someone give me some indication of what is going on here?
 
Thanks...
 
...John...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040602/b00f312c/attachment.html>

From onixware at bigfoot.com  Wed Jun  2 23:12:01 2004
From: onixware at bigfoot.com (Anton Borisov)
Date: Wed Jun  2 23:12:01 2004
Subject: recommendations to run LB on ASUS A7V8X, TX97E
Message-ID: <E1BVjvk-000Av9-00@tmb.ru>

Hi.
	I wonder whether these motherboards supported? First based on VIA KT400 chipset, second - very famous :)
	What kind of PLCC should I use? M-Systems?


-- 
??? ???  3 08:31:54 MSD 2004


From YhLu at tyan.com  Wed Jun  2 23:20:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jun  2 23:20:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogtPC4tDogW0NPTU1JVF0gcm9tY2MgMC42MyBh?=
	=?GB2312?B?bmQgc29tZSBmaXhlcy4uLg==?=
Message-ID: <3174569B9743D511922F00A0C94314230506476B@TYANWEB>

Eric,
I add in console.c
static void printo_debug(const char *str) __attribute__((noinline))
{
	print_debug(str);
}

About only chang print_debug in auto.c 

It said
./romcc -O2 -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
make[1]: *** [auto.inc] Segmentation fault

./romcc -O -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
make[1]: *** [auto.inc] Segmentation fault

regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?5?28? 11:42
???: YhLu
??: LinuxBIOS
??: Re: ??: ??: [COMMIT] romcc 0.63 and some fixes...

YhLu <YhLu at tyan.com> writes:

> After I get USB boot done, I will try that and modify the auto.c.....

Ok.  

A quick update.

In playing around I wrote the function:

static void printo_debug(const char *str) __attribute__((noinline))
{
	print_debug(str);
}

And started replacing the calls to print_debug one by one.
On the port I am currently working on I managed to shave off 4K
pretty quickly.

So it looks like for the really commonly called functions we
will need 2 names.  One inline that will be inlined the other that won't.

It is not a very elegant solution but it works and is not very hard to
manage.

Eric


From ebiederman at lnxi.com  Thu Jun  3 03:00:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun  3 03:00:00 2004
Subject: romcc questions
In-Reply-To: <20E0F651F8B82F45ABCBACC58A2D995B35B3B8@mexper1>
References: <20E0F651F8B82F45ABCBACC58A2D995B35B3B8@mexper1>
Message-ID: <m37jup9hgn.fsf@maxwell.lnxi.com>

"John Usher (Maptek)" <John.Usher at perth.maptek.com.au> writes:

> Hi, I'm trying to get freebios2 going on a VT8606/VT82C686B board with a
> 533MHz VIA C3 processor.
>  
> When trying to compile romcc, it gets to simple_test26 but reports it is
> out of registers.
>  
> Can someone give me some indication of what is going on here?

simple_test26 is one of the regression tests.  In particular it
is a register pressure test and it only works when romcc has been
given the options to enable all of the registers.  You can use make -k
to get through all of the regression tests if you want.

You should not need to build romcc independently of LinuxBIOS right
now.  The normal build process should ensure it is build before you
need it.

Eric


From ebiederman at lnxi.com  Thu Jun  3 03:06:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun  3 03:06:01 2004
Subject: =?gb2312?b?tPC4tA==?=: =?gb2312?b?tPC4tA==?=:
  =?gb2312?b?tPC4tA==?=: [COMMIT] romcc 0.63 and some fixes...
In-Reply-To: <3174569B9743D511922F00A0C94314230506476B@TYANWEB>
References: <3174569B9743D511922F00A0C94314230506476B@TYANWEB>
Message-ID: <m33c5d9h76.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> I add in console.c
> static void printo_debug(const char *str) __attribute__((noinline))
> {
> 	print_debug(str);
> }
> 
> About only chang print_debug in auto.c 
> 
> It said
> ./romcc -O2 -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
> make[1]: *** [auto.inc] Segmentation fault
> 
> ./romcc -O -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
> make[1]: *** [auto.inc] Segmentation fault

Cool, my first bug report.  I knew I had touched to much code
for the new release to run without a hitch.  

Could you look at the core dump with gdb and give me a back trace?
That should help even if I can't reproduce the problem on this end.

Eric




From ebiederman at lnxi.com  Thu Jun  3 03:09:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun  3 03:09:01 2004
Subject: =?gb2312?b?tPC4tA==?=: Magazine article on USB and Embedded
  systems
In-Reply-To: <3174569B9743D511922F00A0C94314230506475D@TYANWEB>
References: <3174569B9743D511922F00A0C94314230506475D@TYANWEB>
Message-ID: <m3y8n582gx.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> That's kernel, how about rootfs or initrd?

I have some preliminary work but I need to dust off two years
of bitrot, before it is usable again.


Eric


From ebiederman at lnxi.com  Thu Jun  3 03:12:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun  3 03:12:01 2004
Subject: ACPI DSDT
In-Reply-To: <20040602100233.GE23428@openbios.org>
References: <Pine.LNX.4.44.0406011451150.17922-100000@maxroach.lanl.gov>
	<40BD04CE.6030405@nexpath.com> <20040602100233.GE23428@openbios.org>
Message-ID: <m3u0xt82da.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Standards are a fine thing. Let's have everybody implement it's own.

One thing about EFI that really sucks is that it is just absolutely
chock full of pointers in it's interfaces.  Which makes it extremely ugly
to support on platforms with both a 32/64bit platforms.  At least that
is what it looks like to me.

Eric


From rsmith at bitworks.com  Thu Jun  3 03:34:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Thu Jun  3 03:34:01 2004
Subject: testbios and the system timer 
In-Reply-To: <20040602180501.GA29361@openbios.org>
References: <E8F8DBCB0468204E856114A2CD20741F14AEA4@mail.local.ActualitySystems.com> <1086196196.22884.15.camel@exponential.lanl.gov> <20040602180501.GA29361@openbios.org>
Message-ID: <40BEE7BD.60104@bitworks.com>

I've been pouring over various logs from testbios and what my M1 Vbios 
does in various conditions.  Man what a bitch.

One thing I've found testbios dosen't handle properly is the 8254 system 
timer.  In numerious locations my Vbios is writing a 0x00 to IO 0x43 and 
then does 2 reads from 0x40.  So its latching the value of counter 0 and 
then reading it out.

I'm guesing that what it uses for delays.  Since I'm lucky enought to 
have the Vbios source I did some grep work and found out that indeed it 
uses timer 0 for delays.  With preset delays ranging from 2uS all the 
way to 50mS and a generic delay that delays CX number of 1mS loops.

The delay routine is written such that it polls for a rollover to mark 
the increment of 838.1 ns.  For this to happen the latch values must be 
equal.  In a system where the cpu instructions are running much faster 
than one timer clock cycle I guess would not be much of a problem.

Of course the emulator totally munges this system since the elapsed 
timer ticks between timer reads for the emulator is way longer than one 
timer tick and its just blind chance when the timer delay routine reads 
the value it needs.

What I don't understand though was how this ever was reliable.  Don't 
ISA cycles take ~.6us to complete?   So 1 out and 2 ins to the legach 
time thats 1.8us which should be 2 ticks so the routine should miss.  I 
must not fully understand the delay routine.  (Yes I have permission to 
post this snippit)

Consider the following:

DX = entry latch value
AX = sucessive latch values
BX = number of loops to do

enter:
	read timer and store in DX
loop:
	read the timer place result in AX

	sub AX,DX
	neg AX
	or  AX,AX
	jnz check_loops

	and bl,not 1
	dec bx
	dec bx

check_loops:

	cmp ax,bx
	jb  loop

exit:

Am I missing somthing?

What i've noticed that the emulator causes the Vbios to get stuck in 
some delay loops.  Eventually it probally would exit but its currently 
making my logs huge and causing the knashing of much teeth.

So I'm thinking that the emulator needs to intercept reads and writes to 
the system timer and provide a fake timer that increments 1 tick per 
some x instructions emulated.  And hopfully the chips and the bioses 
that need this won't mind that the actuall delay is longer than what was 
requested.

Any comments before I hack this in?

I'm off to bed.




From KingCrab at gmx.net  Thu Jun  3 03:52:00 2004
From: KingCrab at gmx.net (Markus Wolters)
Date: Thu Jun  3 03:52:00 2004
Subject: Linuxbios available for via kt400 chipset?
Message-ID: <17638.1086254057@www29.gmx.net>

Has anyone linuxbios running on a asus a7v8x-x with kt400? 
 
regards Markus 

-- 
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info



From stepan at openbios.org  Thu Jun  3 05:31:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Jun  3 05:31:01 2004
Subject: pirq checking
Message-ID: <20040603105347.GA5401@openbios.org>

Hi,

the current pirq code defines intel_irq_routing_table as const, thus
making it potentially readonly. 
OTOH the code in arch/i386/boot/pirq_routing.c tries to correct the 
checksum and size entries in that table.

I think that table should not be declared const, especially since we
might want to create it dynamically later on.

Opinions?

Stefan




From rminnich at lanl.gov  Thu Jun  3 08:53:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 08:53:00 2004
Subject: w86327hf superio.c
In-Reply-To: <3174569B9743D511922F00A0C943142305064765@TYANWEB>
Message-ID: <Pine.LNX.4.44.0406030814360.1943-100000@maxroach.lanl.gov>

On Wed, 2 Jun 2004, YhLu wrote:

> Someone overwrite the superio.c for w86327hf.
> 
> Before that it enter_ext_func mode and enable HWM of Winbond.

that's our fault. The code for this part was really out of date in the way
it worked, because it did not use Eric's new generic PNP functions, and we
couldn't figure out what should stay and what should go.  Can you send me
a patch for what you think should happen and we'll put that support back
in.

thanks

ron



From ollie at lanl.gov  Thu Jun  3 09:47:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Jun  3 09:47:00 2004
Subject: testbios and the system timer
In-Reply-To: <40BEE7BD.60104@bitworks.com>
References: 	 <E8F8DBCB0468204E856114A2CD20741F14AEA4@mail.local.ActualitySystems.com>
	 <1086196196.22884.15.camel@exponential.lanl.gov>
	 <20040602180501.GA29361@openbios.org>  <40BEE7BD.60104@bitworks.com>
Message-ID: <1086275374.9627.2.camel@exponential.lanl.gov>

On Thu, 2004-06-03 at 02:56, Richard Smith wrote:
> 
> What i've noticed that the emulator causes the Vbios to get stuck in 
> some delay loops.  Eventually it probally would exit but its currently 
> making my logs huge and causing the knashing of much teeth.
> 
> So I'm thinking that the emulator needs to intercept reads and writes to 
> the system timer and provide a fake timer that increments 1 tick per 
> some x instructions emulated.  And hopfully the chips and the bioses 
> that need this won't mind that the actuall delay is longer than what was 
> requested.
> 

The original emulator in xfree86 use the system's gettimeofdate to 
emulate the timer.  Since we are not going to have that function in
linuxbios, I removed it.

Probably we need an other way to emulate the timer.

Ollie

> Any comments before I hack this in?
> 
> I'm off to bed.
> 
> 



From zoiah at zoiah.net  Thu Jun  3 09:55:01 2004
From: zoiah at zoiah.net (Erik Smit)
Date: Thu Jun  3 09:55:01 2004
Subject: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken
Message-ID: <20040603151727.GB29004@matryoshka.zylon.net>

Hi People,

Just like the subject says: the form at
http://www.linuxbios.org/help/index.html gives a really cute 404.

Should I therefore mail my request for help to the mailing list or
should I wait until the form gets back working?

Regards,

Erik Smit



From dwh at lanl.gov  Thu Jun  3 09:59:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Jun  3 09:59:01 2004
Subject: The 'help me!' form on http://www.linuxbios.org/help/index.html
 is broken
In-Reply-To: <20040603151727.GB29004@matryoshka.zylon.net>
Message-ID: <Pine.LNX.4.44.0406030920360.12573-100000@ccs-mail.lanl.gov>

Works fine as far as I can tell, I am not getting the 404. But feel free 
to post here anyway if it's more convenient for you.

On Thu, 3 Jun 2004, Erik Smit wrote:

> Hi People,
> 
> Just like the subject says: the form at
> http://www.linuxbios.org/help/index.html gives a really cute 404.
> 
> Should I therefore mail my request for help to the mailing list or
> should I wait until the form gets back working?
> 
> Regards,
> 
> Erik Smit
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rminnich at lanl.gov  Thu Jun  3 10:01:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 10:01:01 2004
Subject: pirq checking
In-Reply-To: <20040603105347.GA5401@openbios.org>
Message-ID: <Pine.LNX.4.44.0406030922491.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Stefan Reinauer wrote:

> the current pirq code defines intel_irq_routing_table as const, thus
> making it potentially readonly. 

should be const due to execute-in-place issues. 


> OTOH the code in arch/i386/boot/pirq_routing.c tries to correct the 
> checksum and size entries in that table.

that's my fault I bet. 

> I think that table should not be declared const, especially since we
> might want to create it dynamically later on.

no, leave const unless we ALWAYS copy to memory and then work with it.

ron



From zoiah at zoiah.net  Thu Jun  3 10:11:00 2004
From: zoiah at zoiah.net (Erik Smit)
Date: Thu Jun  3 10:11:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406030920360.12573-100000@ccs-mail.lanl.gov>
References: <20040603151727.GB29004@matryoshka.zylon.net> <Pine.LNX.4.44.0406030920360.12573-100000@ccs-mail.lanl.gov>
Message-ID: <20040603153327.GC29004@matryoshka.zylon.net>

Strange, I get a 404 at
http://www.linuxbios.org/cgi-bin/linuxbios/help.cgi when I click the
'submit form' button.

Anyhow, here's my information.

I have a 'Lex CV860A' which is untested at
http://www.linuxbios.org/status/index.html.

The flash device is a "AMIC A29002".

I tried the freebios/src/mainboard/lex/cv860a/example.config with both a
memtest86+ payload and filo payload.

At first this does not compile due to what seems to be something that
was forgotten in the freebios/src/southbridge/via/vt82c686/southbridge.c 
file.

+++ freebios.cvs060304/src/southbridge/via/vt82c686/southbridge.c       2002-10-11 01:55:17.000000000 +0200
+++ freebios/src/southbridge/via/vt82c686/southbridge.c 2004-06-03 20:11:04.000000000 +0200
@@ -93,7 +93,7 @@
        // 0x80 is enable com port b, 0x1 is to make it com2, 0x8 is enable com port a as com1
        enables = 0x80 | 0x1 | 0x8 ;
        if (dev) {
-               pci_write_config_byte(0, devfn, 0x83, enables);
+               pci_write_config_byte(dev, 0x83, enables);
        }
        // note: this is also a redo of some port of assembly, but we want everything up.
        // set com1 to 115 kbaud

After flashing the machine does not boot or give any output over the
serial port.

We have a nullmodem cable from the ttyS0 to another machine which I'm
sure is functioning because the linuxkernel and getty are able to work 
over it. 

I have added 'option SERIAL_POST=1' to the configfile and retried but
still nothing appears on the serial line.

Anything else I can try to debug this problem?

This is the lspci output:

debian:/# lspci
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 05)
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP]
0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06)
0000:00:07.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 1a)
0000:00:07.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 1a)
0000:00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
0000:00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
0000:00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a)
debian:/# lspci -n
0000:00:00.0 Class 0600: 1106:0601 (rev 05)
0000:00:01.0 Class 0604: 1106:8601
0000:00:07.0 Class 0601: 1106:0686 (rev 40)
0000:00:07.1 Class 0101: 1106:0571 (rev 06)
0000:00:07.2 Class 0c03: 1106:3038 (rev 1a)
0000:00:07.3 Class 0c03: 1106:3038 (rev 1a)
0000:00:07.4 Class 0680: 1106:3057 (rev 40)
0000:00:07.5 Class 0401: 1106:3058 (rev 50)
0000:00:08.0 Class 0200: 10ec:8139 (rev 10)
0000:00:09.0 Class 0200: 10ec:8139 (rev 10)
0000:00:0b.0 Class 0200: 10ec:8139 (rev 10)
0000:01:00.0 Class 0300: 1023:8500 (rev 6a)

Regards,

Erik Smit


On Thu, Jun 03, 2004 at 09:21:58AM -0600, Hendricks David W. wrote:
> Works fine as far as I can tell, I am not getting the 404. But feel free 
> to post here anyway if it's more convenient for you.
> 
> On Thu, 3 Jun 2004, Erik Smit wrote:
> 
> > Hi People,
> > 
> > Just like the subject says: the form at
> > http://www.linuxbios.org/help/index.html gives a really cute 404.
> > 
> > Should I therefore mail my request for help to the mailing list or
> > should I wait until the form gets back working?
> > 
> > Regards,
> > 
> > Erik Smit
> > 
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > 
> 


From dwh at lanl.gov  Thu Jun  3 10:12:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Jun  3 10:12:00 2004
Subject: recommendations to run LB on ASUS A7V8X, TX97E
In-Reply-To: <E1BVjvk-000Av9-00@tmb.ru>
Message-ID: <Pine.LNX.4.44.0406030931320.12573-100000@ccs-mail.lanl.gov>

Sorry, I don't think either of those will run with LinuxBIOS in the 
immediate future. There has been extensive work done on VIA platforms, 
particularly the EPIA. Perhaps some of that work could be ported to the 
KT400, but I'm not sure if anyone on this list is actively working on such 
a project.

On Thu, 3 Jun 2004, Anton Borisov wrote:

> Hi.
> 	I wonder whether these motherboards supported? First based on VIA KT400 chipset, second - very famous :)
> 	What kind of PLCC should I use? M-Systems?
> 
> 
> 



From rminnich at lanl.gov  Thu Jun  3 10:13:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 10:13:00 2004
Subject: testbios and the system timer
In-Reply-To: <1086275374.9627.2.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0406030935270.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Li-Ta Lo wrote:

> Probably we need an other way to emulate the timer.

can we just read the timer?

ron



From rminnich at lanl.gov  Thu Jun  3 10:14:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 10:14:00 2004
Subject: The 'help me!' form on http://www.linuxbios.org/help/index.html
 is broken
In-Reply-To: <20040603151727.GB29004@matryoshka.zylon.net>
Message-ID: <Pine.LNX.4.44.0406030936271.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Erik Smit wrote:

> Just like the subject says: the form at
> http://www.linuxbios.org/help/index.html gives a really cute 404.

my fault. 

I gave up on that because the messages I got through it were useless.

ron



From rminnich at lanl.gov  Thu Jun  3 10:15:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 10:15:01 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html
 is broken)
In-Reply-To: <20040603153327.GC29004@matryoshka.zylon.net>
Message-ID: <Pine.LNX.4.44.0406030937470.2716-100000@maxroach.lanl.gov>

I think that ought to work as a via epia, use V2.

ron



From zoiah at zoiah.net  Thu Jun  3 10:19:02 2004
From: zoiah at zoiah.net (Erik Smit)
Date: Thu Jun  3 10:19:02 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406030937470.2716-100000@maxroach.lanl.gov>
References: <20040603153327.GC29004@matryoshka.zylon.net> <Pine.LNX.4.44.0406030937470.2716-100000@maxroach.lanl.gov>
Message-ID: <20040603154155.GD29004@matryoshka.zylon.net>

On Thu, Jun 03, 2004 at 09:37:53AM -0600, ron minnich wrote:
> I think that ought to work as a via epia, use V2.

freebios2?

Well, the EPIA has a vt8231 southbridge where this board has a vt82c686.
Won't this give problems?

Regards,

Erik Smit



From ollie at lanl.gov  Thu Jun  3 10:21:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Jun  3 10:21:00 2004
Subject: testbios and the system timer
In-Reply-To: <Pine.LNX.4.44.0406030935270.2716-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406030935270.2716-100000@maxroach.lanl.gov>
Message-ID: <1086277435.9627.5.camel@exponential.lanl.gov>

On Thu, 2004-06-03 at 09:35, ron minnich wrote:
> On Thu, 3 Jun 2004, Li-Ta Lo wrote:
> 
> > Probably we need an other way to emulate the timer.
> 
> can we just read the timer?
> 
> ron
> 

richard's point is that the emulator is much slower than the
timer. The delay loop is facing overflow problem with the
"emulated" io access to the "physical" counter.

Ollie 



From rminnich at lanl.gov  Thu Jun  3 10:22:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 10:22:01 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html
 is broken)
In-Reply-To: <20040603154155.GD29004@matryoshka.zylon.net>
Message-ID: <Pine.LNX.4.44.0406030944330.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Erik Smit wrote:

> Well, the EPIA has a vt8231 southbridge where this board has a vt82c686.
> Won't this give problems?

There used to be 8231 support. If think they are similar enough it could 
work.

ron



From rminnich at lanl.gov  Thu Jun  3 10:25:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 10:25:01 2004
Subject: testbios and the system timer
In-Reply-To: <1086277435.9627.5.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0406030946210.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Li-Ta Lo wrote:

> richard's point is that the emulator is much slower than the
> timer. The delay loop is facing overflow problem with the
> "emulated" io access to the "physical" counter.

oops, sorry. Too much email this morning. I did not read his note 
carefully enough.

Actually I'm surprised that the emulator is that much slower than an old 
8086. 


OK, now what do we do ...

Ah, we could use the TSC, right?

ron



From YhLu at tyan.com  Thu Jun  3 11:10:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Jun  3 11:10:01 2004
Subject: =?GB2312?B?tPC4tDogdzg2MzI3aGYgc3VwZXJpby5j?=
Message-ID: <3174569B9743D511922F00A0C943142305064777@TYANWEB>

It call the generic PNP function, but before that should enter ext_function
mode, otherwise nothing in the superio can be changed.

Regards

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?6?3? 7:16
???: YhLu
??: ebiederman at lnxi.com; Gregg C Levine; Linuxbios
??: Re: w86327hf superio.c

On Wed, 2 Jun 2004, YhLu wrote:

> Someone overwrite the superio.c for w86327hf.
> 
> Before that it enter_ext_func mode and enable HWM of Winbond.

that's our fault. The code for this part was really out of date in the way
it worked, because it did not use Eric's new generic PNP functions, and we
couldn't figure out what should stay and what should go.  Can you send me
a patch for what you think should happen and we'll put that support back
in.

thanks

ron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: superio.c
Type: application/octet-stream
Size: 6148 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040603/d273cc08/attachment.obj>

From zoiah at zoiah.net  Thu Jun  3 11:20:01 2004
From: zoiah at zoiah.net (Erik Smit)
Date: Thu Jun  3 11:20:01 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406030944330.2716-100000@maxroach.lanl.gov>
References: <20040603154155.GD29004@matryoshka.zylon.net> <Pine.LNX.4.44.0406030944330.2716-100000@maxroach.lanl.gov>
Message-ID: <20040603164315.GA15995@matryoshka.zylon.net>

On Thu, Jun 03, 2004 at 09:44:56AM -0600, ron minnich wrote:
> On Thu, 3 Jun 2004, Erik Smit wrote:
> 
> > Well, the EPIA has a vt8231 southbridge where this board has a vt82c686.
> > Won't this give problems?
> 
> There used to be 8231 support. If think they are similar enough it could 
> work.

I just tried to build freebios2/targets/via/epia by running
buildtarget on it and then running make. This is on the cvs of today. I
got the following error:

/opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c: In function `check_pirq_routing_table':
/opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:21: error: assignment of read-only variable `intel_irq_routing_table'
/opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:42: error: assignment of read-only member `checksum'
make[1]: *** [pirq_routing.o] Error 1

I just commented these two lines out since they only appear to be used
when something is broken. Then it compiled fine.

Then I flashed in the resulting linuxbios.bin using uniflash since
flash_and_burn doesn't support the AMIC A29002 chip on this board.

Still, after rebooting, nothing appears on the serial port. Can I
conclude from this that this board is not yet supported (out of the
box)?

Is there anything else I can try or maybe help debug the problem? 

Regards,

Erik Smit



From dag at bamse.as  Thu Jun  3 11:26:00 2004
From: dag at bamse.as (Dag Hovland)
Date: Thu Jun  3 11:26:00 2004
Subject: What DiskOnChip?
Message-ID: <40BF56C0.2030003@bamse.as>

Hello

I wanted to try linuxbios on my computer and read on your homepage that 
only DiskOnChip Millennium is supported. They seem to have went out of 
production, and the Norwegian salesman recommended the DiskOnChip 2000 
models as a replacement. Do they work too or will I have to find a 
Millennium-edition?

I apologize if this is the totally wrong place to post this, in that 
case I would be happy if someone could point me in the right direction.

Yours,
Dag Hovland



From rminnich at lanl.gov  Thu Jun  3 11:32:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 11:32:01 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html
 is broken)
In-Reply-To: <20040603164315.GA15995@matryoshka.zylon.net>
Message-ID: <Pine.LNX.4.44.0406031054560.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Erik Smit wrote:

> Then I flashed in the resulting linuxbios.bin using uniflash since
> flash_and_burn doesn't support the AMIC A29002 chip on this board.

linuxbios.rom -- you got the wrong file. sorry about that.

ron



From rminnich at lanl.gov  Thu Jun  3 11:33:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 11:33:00 2004
Subject: What DiskOnChip?
In-Reply-To: <40BF56C0.2030003@bamse.as>
Message-ID: <Pine.LNX.4.44.0406031055330.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Dag Hovland wrote:

> I wanted to try linuxbios on my computer and read on your homepage that 
> only DiskOnChip Millennium is supported. 

WOW, how did you infer that from the web page? I need to change it if it 
says something like that.

ron



From stuge-linuxbios at cdy.org  Thu Jun  3 11:41:01 2004
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Thu Jun  3 11:41:01 2004
Subject: testbios and the system timer
In-Reply-To: <40BEE7BD.60104@bitworks.com>
References: <E8F8DBCB0468204E856114A2CD20741F14AEA4@mail.local.ActualitySystems.com> <1086196196.22884.15.camel@exponential.lanl.gov> <20040602180501.GA29361@openbios.org> <40BEE7BD.60104@bitworks.com>
Message-ID: <20040603170359.GA19199@foo.birdnet.se>

On Thu, Jun 03, 2004 at 03:56:29AM -0500, Richard Smith wrote:
> timer.  In numerious locations my Vbios is writing a 0x00 to IO 0x43 and 
> then does 2 reads from 0x40.  So its latching the value of counter 0 and 
> then reading it out.

Right, it also sets counter mode 0, zero detection interrupt. Are
there any hints of the code actually using the interrupt anywhere?


> I'm guesing that what it uses for delays.

Indeed. It's the only way I know for measuring <ms without rdtsc.


> The delay routine is written such that it polls for a rollover to mark 
> the increment of 838.1 ns.  For this to happen the latch values must be 
> equal.  In a system where the cpu instructions are running much faster 
> than one timer clock cycle I guess would not be much of a problem.

838.1ns is one tick, not a complete 16-bit rollover, right?


> What I don't understand though was how this ever was reliable.

[..]

> Consider the following:
[..asm..]
> Am I missing somthing?

The resolution could be lowered.. Are there any writes to 0x40
setting a divisor? If not, then the snippet will simply not be
reliable down to the exact iteration.

Since the code uses jb to detect when to stop looping the count
doesn't have to be an exact match. Even if an extra tick passes,
the loop will still end.

I don't think the timing is critical in any other way than that it
should be as short as possible to keep the user happy, but with a
minimum limit decided by hardware.


//Peter


From zoiah at zoiah.net  Thu Jun  3 11:44:00 2004
From: zoiah at zoiah.net (Erik Smit)
Date: Thu Jun  3 11:44:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406031054560.2716-100000@maxroach.lanl.gov>
References: <20040603164315.GA15995@matryoshka.zylon.net> <Pine.LNX.4.44.0406031054560.2716-100000@maxroach.lanl.gov>
Message-ID: <20040603170712.GB15995@matryoshka.zylon.net>

On Thu, Jun 03, 2004 at 10:55:14AM -0600, ron minnich wrote:
> On Thu, 3 Jun 2004, Erik Smit wrote:
> 
> > Then I flashed in the resulting linuxbios.bin using uniflash since
> > flash_and_burn doesn't support the AMIC A29002 chip on this board.
> 
> linuxbios.rom -- you got the wrong file. sorry about that.

Sorry, that was a typo, I did infact take linuxbios.rom. (There isn't
even a linuxbios.bin. :)

Regards,

Erik Smit


From YhLu at tyan.com  Thu Jun  3 12:21:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Jun  3 12:21:00 2004
Subject: [COMMIT] romcc 0.63 and some fixes...
Message-ID: <3174569B9743D511922F00A0C94314230506478A@TYANWEB>

Eric,

The 
printo_debug("this mainboard is only designed for 2 cpus\r\n");

causes the segment dump.

Another problem. After only change print_debug in raminit.c, the final image
size get bigger from 68663 to 70203.

Regards

YH



-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?3? 1:31
???: YhLu
??: LinuxBIOS
??: Re: ??: ??: ??: [COMMIT] romcc 0.63 and some fixes...

YhLu <YhLu at tyan.com> writes:

> Eric,
> I add in console.c
> static void printo_debug(const char *str) __attribute__((noinline))
> {
> 	print_debug(str);
> }
> 
> About only chang print_debug in auto.c 
> 
> It said
> ./romcc -O2 -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
> make[1]: *** [auto.inc] Segmentation fault
> 
> ./romcc -O -mcpu=k8 -o auto.inc --label-prefix=auto ./auto.E
> make[1]: *** [auto.inc] Segmentation fault

Cool, my first bug report.  I knew I had touched to much code
for the new release to run without a hitch.  

Could you look at the core dump with gdb and give me a back trace?
That should help even if I can't reproduce the problem on this end.

Eric



From stepan at openbios.org  Thu Jun  3 12:36:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Jun  3 12:36:01 2004
Subject: recommendations to run LB on ASUS A7V8X, TX97E
In-Reply-To: <Pine.LNX.4.44.0406030931320.12573-100000@ccs-mail.lanl.gov>
References: <E1BVjvk-000Av9-00@tmb.ru> <Pine.LNX.4.44.0406030931320.12573-100000@ccs-mail.lanl.gov>
Message-ID: <20040603175834.GA10376@openbios.org>

* Hendricks David W. <dwh at lanl.gov> [040603 17:34]:
> Sorry, I don't think either of those will run with LinuxBIOS in the 
> immediate future. There has been extensive work done on VIA platforms, 
> particularly the EPIA. Perhaps some of that work could be ported to the 
> KT400, but I'm not sure if anyone on this list is actively working on such 
> a project.

I've not seen enough information (data sheets) available without NDA to 
make this happen. Might be that I looked in the wrong places though. If
you don't buy a lot of motherboards, you normally don't get this kind of
information from VIA.

  Stefan



From zoiah at zoiah.net  Thu Jun  3 13:08:00 2004
From: zoiah at zoiah.net (Erik Smit)
Date: Thu Jun  3 13:08:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <20040603170712.GB15995@matryoshka.zylon.net>
References: <20040603164315.GA15995@matryoshka.zylon.net> <Pine.LNX.4.44.0406031054560.2716-100000@maxroach.lanl.gov> <20040603170712.GB15995@matryoshka.zylon.net>
Message-ID: <20040603183035.GA27687@matryoshka.zylon.net>

On Thu, Jun 03, 2004 at 07:07:12PM +0200, Erik Smit wrote:
> On Thu, Jun 03, 2004 at 10:55:14AM -0600, ron minnich wrote:
> > On Thu, 3 Jun 2004, Erik Smit wrote:
> > 
> > > Then I flashed in the resulting linuxbios.bin using uniflash since
> > > flash_and_burn doesn't support the AMIC A29002 chip on this board.
> > 
> > linuxbios.rom -- you got the wrong file. sorry about that.
> 
> Sorry, that was a typo, I did infact take linuxbios.rom. (There isn't
> even a linuxbios.bin. :)

Still, after rebooting, nothing appears on the serial port. Can I
conclude from this that this board is not yet supported (out of the
box)?

Is there anything else I can try or maybe help debug the problem?

Also, is it possible to sponsor one (or more) boards or perhaps fund
somebody to work on this?

Regards,

Erik Smit


From rminnich at lanl.gov  Thu Jun  3 13:34:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 13:34:00 2004
Subject: testbios and the system timer
In-Reply-To: <20040603170359.GA19199@foo.birdnet.se>
Message-ID: <Pine.LNX.4.44.0406031255320.2716-100000@maxroach.lanl.gov>

what about this. Build a composite timer with the top X bits coming from 
TSC, and the bottom Y bits coming from the time-of-day counter. Would that 
work?

ron



From rminnich at lanl.gov  Thu Jun  3 13:38:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 13:38:01 2004
Subject: testbios and the system timer 
In-Reply-To: <40BEE7BD.60104@bitworks.com>
Message-ID: <Pine.LNX.4.44.0406031259230.2716-100000@maxroach.lanl.gov>

OK, I finally read this in detail and I'm sorry for my noise on this 
subject. 

I think it would be useful to keep an 'emulated instruction count' in the 
emulator, and have a virtual timer that increments very X (pick a number) 
instructions. X can be constant across different architectures as we are 
somewhat divorced from time (it's an emulator). 

The emulated timer would increment every emulated instruction count ticks. 

Would this do it?

ron



From rminnich at lanl.gov  Thu Jun  3 13:41:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 13:41:01 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html
 is broken)
In-Reply-To: <20040603170712.GB15995@matryoshka.zylon.net>
Message-ID: <Pine.LNX.4.44.0406031302410.2716-100000@maxroach.lanl.gov>

with the fuctory bios in place, make sure that your minicom setup is 
right. Let me know.

ron



From rminnich at lanl.gov  Thu Jun  3 13:44:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 13:44:00 2004
Subject: recommendations to run LB on ASUS A7V8X, TX97E
In-Reply-To: <20040603175834.GA10376@openbios.org>
Message-ID: <Pine.LNX.4.44.0406031306380.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Stefan Reinauer wrote:

> I've not seen enough information (data sheets) available without NDA to
> make this happen. Might be that I looked in the wrong places though. If
> you don't buy a lot of motherboards, you normally don't get this kind of
> information from VIA.

It depends. At times via has been incredibly helpful, but not in all 
cases. If you can make the case for this they might be able to help you.

ron



From stepan at openbios.org  Thu Jun  3 14:42:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Jun  3 14:42:01 2004
Subject: pirq checking
In-Reply-To: <Pine.LNX.4.44.0406030922491.2716-100000@maxroach.lanl.gov>
References: <20040603105347.GA5401@openbios.org> <Pine.LNX.4.44.0406030922491.2716-100000@maxroach.lanl.gov>
Message-ID: <20040603200435.GB10376@openbios.org>

* ron minnich <rminnich at lanl.gov> [040603 17:23]:
> > the current pirq code defines intel_irq_routing_table as const, thus
> > making it potentially readonly. 
> 
> should be const due to execute-in-place issues. 

What's the benefit in this case? we have dram long before this code is
run, and the table is really small. Should it be copied to ram
completely maybe?

> > OTOH the code in arch/i386/boot/pirq_routing.c tries to correct the 
> > checksum and size entries in that table.
> 
> that's my fault I bet. 
 
Nope, parts of that is my fault. But I still think it is a good idea to
go towards dynamic table creation.

Well.. maybe this discussion should be left for later..

Stefan




From rminnich at lanl.gov  Thu Jun  3 14:48:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 14:48:00 2004
Subject: pirq checking
In-Reply-To: <20040603200435.GB10376@openbios.org>
Message-ID: <Pine.LNX.4.44.0406031410031.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Stefan Reinauer wrote:

> * ron minnich <rminnich at lanl.gov> [040603 17:23]:
> > > the current pirq code defines intel_irq_routing_table as const, thus
> > > making it potentially readonly. 
> > 
> > should be const due to execute-in-place issues. 
> 
> What's the benefit in this case? we have dram long before this code is
> run, and the table is really small. Should it be copied to ram
> completely maybe?

the only reason is that in the execute in place case you can't write to 
it. Leaving it as const will catch bugs involving people writing to it. 
That's all. 

> Nope, parts of that is my fault. But I still think it is a good idea to
> go towards dynamic table creation.

yes. we're just not there. 

ron



From rsmith at bitworks.com  Thu Jun  3 15:10:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Thu Jun  3 15:10:01 2004
Subject: testbios and the system timer
In-Reply-To: <20040603170359.GA19199@foo.birdnet.se>
References: <E8F8DBCB0468204E856114A2CD20741F14AEA4@mail.local.ActualitySystems.com> <1086196196.22884.15.camel@exponential.lanl.gov> <20040602180501.GA29361@openbios.org> <40BEE7BD.60104@bitworks.com> <20040603170359.GA19199@foo.birdnet.se>
Message-ID: <40BF8AFA.1050705@bitworks.com>

Peter Stuge wrote:

> On Thu, Jun 03, 2004 at 03:56:29AM -0500, Richard Smith wrote:
> 
>>timer.  In numerious locations my Vbios is writing a 0x00 to IO 0x43 and 
>>then does 2 reads from 0x40.  So its latching the value of counter 0 and 
>>then reading it out.
> 
> Right, it also sets counter mode 0, zero detection interrupt. Are
> there any hints of the code actually using the interrupt anywhere?

Um... I don't know.  What would I look for?  I don't thing so but that 
does explain why linux whines about "too many timer interrutps" occurring.

>>The delay routine is written such that it polls for a rollover to mark 
>>the increment of 838.1 ns.  For this to happen the latch values must be 
>>equal.  In a system where the cpu instructions are running much faster 
>>than one timer clock cycle I guess would not be much of a problem.
>  
> 838.1ns is one tick, not a complete 16-bit rollover, right?

Yeah sorry.  838.1 ns is one tick.  I said rollover which would be 50mS
Re-looking at the delay routine I see I was mistaken as the delay 
routine counts ticks.

Looking at the delay routine is just confusing.  There's a comment that 
says 4 bx counts equals .4290 * 4 or 2uS.  So that tells me the VBios 
thinks the system timer must be running at 2.386 Mhz rather than the 
1.19318 Mhz my PC hardware book claims.

All this tells me that I don't understand timer access in a modern 
system.  The code as written just dosen't seem like it would work on a 
4.77 Mhz XT.

> The resolution could be lowered.. Are there any writes to 0x40
> setting a divisor? If not, then the snippet will simply not be
> reliable down to the exact iteration.
> 
> Since the code uses jb to detect when to stop looping the count
> doesn't have to be an exact match. Even if an extra tick passes,
> the loop will still end.

I don't understand.  The part I'm refering to is the

         sub     ax,dx
         neg     ax

	or	ax,ax
	jnz	delay_a

This will only skip the jump (and do the BX decrement) if ax is zero. 
For ax to be zero the result of the 2's complement subtraction must be 
zero or the when the 2 reads are the same number.  But I just don't see 
how this would happen repeatably at .6us per ISA IO.

Ate the timer reads really and ISA IO?  I guess if those reads are 
happening much faster then it would work.  Where does the timer live 
now? int the northbridge perhpas?  Thats could be the issue.  If the 
northbridge  responded to the IO it would happen at cpu clock rates and 
all would be well.




From rsmith at bitworks.com  Thu Jun  3 15:11:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Thu Jun  3 15:11:00 2004
Subject: testbios and the system timer
In-Reply-To: <Pine.LNX.4.44.0406031259230.2716-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406031259230.2716-100000@maxroach.lanl.gov>
Message-ID: <40BF8B3D.6090301@bitworks.com>

ron minnich wrote:

> OK, I finally read this in detail and I'm sorry for my noise on this 
> subject. 
> 
> I think it would be useful to keep an 'emulated instruction count' in the 
> emulator, and have a virtual timer that increments very X (pick a number) 
> instructions. X can be constant across different architectures as we are 
> somewhat divorced from time (it's an emulator). 
> 
> The emulated timer would increment every emulated instruction count ticks. 
> 
> Would this do it?

Yes. I think it would.  Got any ideas on the implementation?   I'm ready 
to try an implement this.





From rminnich at lanl.gov  Thu Jun  3 15:39:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 15:39:00 2004
Subject: testbios and the system timer
In-Reply-To: <40BF8B3D.6090301@bitworks.com>
Message-ID: <Pine.LNX.4.44.0406031500110.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Richard Smith wrote:

> Yes. I think it would.  Got any ideas on the implementation?   I'm ready 
> to try an implement this.

in the main loop for instruction decode there is a single instruction 
dispatch function. Create a global counter (emulate_counter?) and 
increment it once each time the dispatch function returns. 

You can in the emulator redirect I/O port access to a function. Write the 
code to handle read/write on those ports and use the emulate_counter to 
drive the clock value.

ron



From rminnich at lanl.gov  Thu Jun  3 15:40:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun  3 15:40:00 2004
Subject: testbios and the system timer
In-Reply-To: <40BF8AFA.1050705@bitworks.com>
Message-ID: <Pine.LNX.4.44.0406031502020.2716-100000@maxroach.lanl.gov>

On Thu, 3 Jun 2004, Richard Smith wrote:

> This will only skip the jump (and do the BX decrement) if ax is zero. 
> For ax to be zero the result of the 2's complement subtraction must be 
> zero or the when the 2 reads are the same number.  But I just don't see 
> how this would happen repeatably at .6us per ISA IO.

All I know is BIOS code sucks and it looks like VGA BIOS code is worse 
than BIOS code. IT's amazing that any of it ever worked at all.

ron



From rsmith at bitworks.com  Thu Jun  3 16:01:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Thu Jun  3 16:01:01 2004
Subject: testbios and the system timer
In-Reply-To: <Pine.LNX.4.44.0406031502020.2716-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406031502020.2716-100000@maxroach.lanl.gov>
Message-ID: <40BF96E5.1020400@bitworks.com>

ron minnich wrote:

> On Thu, 3 Jun 2004, Richard Smith wrote:
> 
> 
>>This will only skip the jump (and do the BX decrement) if ax is zero. 
>>For ax to be zero the result of the 2's complement subtraction must be 
>>zero or the when the 2 reads are the same number.  But I just don't see 
>>how this would happen repeatably at .6us per ISA IO.
> 

Hold up.  I'm baked.  Gotta get more sleep.  The above is obviously 
wrong.  Its should be when they differ by 2.




From YhLu at tyan.com  Thu Jun  3 17:45:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Jun  3 17:45:01 2004
Subject: [COMMIT] romcc 0.63 and some fixes...
Message-ID: <3174569B9743D511922F00A0C9431423050647C9@TYANWEB>

./romcc -mcpu=k8 -O2 ./auto.E > auto.inc
make[1]: *** [auto.inc] Error 139




From ebiederman at lnxi.com  Thu Jun  3 18:58:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun  3 18:58:01 2004
Subject: [COMMIT] romcc 0.63 and some fixes...
In-Reply-To: <3174569B9743D511922F00A0C943142305064779@TYANWEB>
References: <3174569B9743D511922F00A0C943142305064779@TYANWEB>
Message-ID: <m3hdtsgoiu.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I'm not familiar the gdb, and if you like I can send the auto.E to you.

That would be good thanks.

I guess slightly simpler would be to do:
Which will ensure core file generation is not turned off.
Then you can do.

ulimit -c unlimited

make

find . -name 'core*' -print
find . -name 'romcc' -print

And send me (off list) the file named core file and the file named
romcc, that the above find commands found.   This feels like gcc
miscompiled romcc or something like that.

"ulimit -c unlimited"          ensures core generation is enabled.
"make"                         does the build that fails
"find . -name 'core*' -print"  locates core file generated by the sigsegv
"find . -name 'romcc' -print"  locates the romcc binary you were running.

If it is a compilation error I really need to see what the binaries
look like.  If it a bug in romcc I should be able to feed in your
auto.E and reproduce this.

Some very strange things are going on and I don't know how to call
it.  Running dmesg and seeing if the oom killer kicked in would
also be interesting.  romcc tends to be a bit of a memory hog.  Not
so much that it has been unusable but I am grasping at straws.

It looks like my next step in instrumenting romcc is to start
catching signals like sigsegv so I can exit moderately gracefully
when they occur.

My coworkers have been using the romcc with no ill effects so I am
truly mystified, as to what is going wrong.


Thanks, 
Eric

P.S.

Brain storming on naming conventions, I think the sanest thing to do
is to indicate a function is not inline by appending an underscore
to it's name.  So we will have print_debug(str) and
pring_debug_(str)....  Unless there are any objections.




From ebiederman at lnxi.com  Thu Jun  3 19:09:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun  3 19:09:01 2004
Subject: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
In-Reply-To: <1086275862.31673.21.camel@Calliphara>
References: <1086275862.31673.21.camel@Calliphara>
Message-ID: <m3d64ggnzw.fsf@maxwell.lnxi.com>

Mathieu Deschamps <mdeschamps at mangrove-systems.com> writes:

> Hello,
> 
> Since i have mostly 'directly choose' Filo, i haven't had
> much time asking for the difference between Linuxbios native's Elfboot
> and Linuxbios native's filo. I know you did made some work around
> theses... 

The native ``filo'' is scheduled for deletion, it touches hardwaremain
which it should not.  As implemented it is a maintenance nightmare and
an implementation of policy and I refuse to support it, in the core of
LinuxBIOS.  Until just a little while ago I thought it was much less
intrusive so was not forcing the issue.
 
> (i have read the doc of Sone Takeshi and i have the features of filo.)
> 
> Could you explain me what differences there are and/or whether 
> this one best suited for DoC or CF or other types i'am ignoring ?
> Please also let me know what type of filesys elfboot boots, and other
> thing about support

ELF boot is a minimal loader just good enough to load something real
out off some device.   ELF boot just grabs an ELF image at the offset
in a device it is pointed at.  The image can be sparse so it can exist
with partition tables and filesystems.  The trivial solution is to put
a partition right after partition table for the ELF image.  More
interesting forms of coexistance are possible by noone has implemented
more than a proof of concept.

If you want to use filo which understand filesystems and partitions
get the real one. It has been developing faster and it appears to have
more features.

Eric


From YhLu at tyan.com  Thu Jun  3 19:27:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Jun  3 19:27:01 2004
Subject: [COMMIT] romcc 0.63 and some fixes...
Message-ID: <3174569B9743D511922F00A0C9431423050647EA@TYANWEB>

I will add RAM to test again.

Regards

YH


From YhLu at tyan.com  Thu Jun  3 20:01:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Jun  3 20:01:01 2004
Subject: =?GB2312?B?tPC4tDogW0NPTU1JVF0gcm9tY2MgMC42MyBhbmQgc29tZSBmaXhl?=
	=?GB2312?B?cy4uLg==?=
Message-ID: <3174569B9743D511922F00A0C9431423050647F4@TYANWEB>

Just sent out the core.

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?3? 17:23
???: YhLu
??: LinuxBIOS
??: Re: [COMMIT] romcc 0.63 and some fixes...

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I'm not familiar the gdb, and if you like I can send the auto.E to you.

That would be good thanks.

I guess slightly simpler would be to do:
Which will ensure core file generation is not turned off.
Then you can do.

ulimit -c unlimited

make

find . -name 'core*' -print
find . -name 'romcc' -print

And send me (off list) the file named core file and the file named
romcc, that the above find commands found.   This feels like gcc
miscompiled romcc or something like that.

"ulimit -c unlimited"          ensures core generation is enabled.
"make"                         does the build that fails
"find . -name 'core*' -print"  locates core file generated by the sigsegv
"find . -name 'romcc' -print"  locates the romcc binary you were running.

If it is a compilation error I really need to see what the binaries
look like.  If it a bug in romcc I should be able to feed in your
auto.E and reproduce this.

Some very strange things are going on and I don't know how to call
it.  Running dmesg and seeing if the oom killer kicked in would
also be interesting.  romcc tends to be a bit of a memory hog.  Not
so much that it has been unusable but I am grasping at straws.

It looks like my next step in instrumenting romcc is to start
catching signals like sigsegv so I can exit moderately gracefully
when they occur.

My coworkers have been using the romcc with no ill effects so I am
truly mystified, as to what is going wrong.


Thanks, 
Eric

P.S.

Brain storming on naming conventions, I think the sanest thing to do
is to indicate a function is not inline by appending an underscore
to it's name.  So we will have print_debug(str) and
pring_debug_(str)....  Unless there are any objections.



From ebiederman at lnxi.com  Thu Jun  3 20:22:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun  3 20:22:01 2004
Subject: =?gb2312?b?tPC4tA==?=: [COMMIT] romcc 0.63 and some fixes...
In-Reply-To: <3174569B9743D511922F00A0C9431423050647F4@TYANWEB>
References: <3174569B9743D511922F00A0C9431423050647F4@TYANWEB>
Message-ID: <m3llj4aydb.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Just sent out the core.

Thanks.  I have done the basic tracking.  And it is clearly a code
bug.  

tdominates depends on some code analysis that is not currently
present in expand_function_call, and I wind up with a null pointer
dereference.  I need to stare at the code a little more but  should
take just a little bit to fix... 

The back trace is:
#0  tdominates (state=0xbfffb78c, dom=0x829fbd0, sub=0x86f7698)
    at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:16019
#1  0x0805c41f in expand_function_call (state=0xbfffb78c, me=0x8204290, fcall=0x829fbd0)
    at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14422
#2  0x0805c747 in inline_function (state=0xbfffb78c, me=0x8204290, arg=0x0)
    at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14599
#3  0x0805c838 in inline_functions (state=0xbfffb78c, func=0x8204290)
    at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14606
#4  0x0805cd20 in join_functions (state=0xbfffb78c) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:14801
#5  0x08065efd in optimize (state=0xbfffb78c) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:21488
#6  0x0806a4c7 in compile (filename=0xbfffecf8 "./auto.E", compiler=0x0, arch=0x0)
    at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:24910
#7  0x0806a638 in main (argc=1, argv=0xbfffd93c) at /home/yhlu/xx/xx/freebios2/util/romcc/romcc.c:25029
(gdb) 


Eric


From bari at onelabs.com  Thu Jun  3 21:29:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Jun  3 21:29:00 2004
Subject: Looking for Laptop Candidates for LinuxBIOS Port
Message-ID: <40BFE436.8090103@onelabs.com>

We are in search of good candidates for laptops for a LinuxBIOS Port.

These will be the easiest to port:

Intel laptops with Intel integrated graphics, not ATI or nVidia graphics

Intel Chipsets

(TBA) i915
http://www.tbreak.com/reviews/article.php?id=305
These should be out in the next month or so.

855GM
http://developer.intel.com/design/chipsets/mobile/855gm.htm?iid=dev_chips855fam+855gm&

852GME
http://developer.intel.com/design/chipsets/mobile/855GME.htm?iid=dev_chips855fam+855gme&

852GM
http://developer.intel.com/design/chipsets/mobile/852gm.htm

852GMV
http://developer.intel.com/design/chipsets/mobile/852gmv.htm


Along with any of these Renesas keyboard/system controllers:

http://www.renesas.com/eng/products/mpumcu/16bit/h8s/2100/


Everyone please crack open those lids and check your lspci's.

Go down in LinuxBIOS history as the one that came up with the winner!

-Bari








From mdeschamps at mangrove-systems.com  Fri Jun  4 03:11:01 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Fri Jun  4 03:11:01 2004
Subject: Difference between Linxubios native's Elfboot and Linuxbios
	native's Filo
In-Reply-To: <m3d64ggnzw.fsf@maxwell.lnxi.com>
References: <1086275862.31673.21.camel@Calliphara>
	 <m3d64ggnzw.fsf@maxwell.lnxi.com>
Message-ID: <1086337222.31673.79.camel@Calliphara>

Le ven 04/06/2004 ? 02:34, Eric W. Biederman a ?crit :
> Mathieu Deschamps <mdeschamps at mangrove-systems.com> writes:
> 
> > Hello,
> > 
> > Since i have mostly 'directly choose' Filo, i haven't had
> > much time asking for the difference between Linuxbios native's Elfboot
> > and Linuxbios native's filo. I know you did made some work around
> > theses... 
> 
> The native ``filo'' is scheduled for deletion, it touches hardwaremain
> which it should not.  As implemented it is a maintenance nightmare and
> an implementation of policy and I refuse to support it, in the core of
> LinuxBIOS.  Until just a little while ago I thought it was much less
> intrusive so was not forcing the issue.

ok I understand.

>  
> > (i have read the doc of Sone Takeshi and i have the features of filo.)
> > 
> > Could you explain me what differences there are and/or whether 
> > this one best suited for DoC or CF or other types i'am ignoring ?
> > Please also let me know what type of filesys elfboot boots, and other
> > thing about support
> 
> ELF boot is a minimal loader just good enough to load something real
> out off some device.   ELF boot just grabs an ELF image at the offset
> in a device it is pointed at.  The image can be sparse so it can exist
> with partition tables and filesystems.  The trivial solution is to put
> a partition right after partition table for the ELF image.  More
> interesting forms of coexistance are possible by noone has implemented
> more than a proof of concept.
> 
> If you want to use filo which understand filesystems and partitions
> get the real one. It has been developing faster and it appears to have
> more features.

Ok, this week I'am a bit brain-slowed, so I recap to see if I catch
the whole meaning:

you say that filo shouldn't be inside Linuxbios in the way 
it forces implementation/maintenance that isn't clean.
So that's it : 
letting payload type program to modify 'Linuxbios core' is not
acceptable, is it ?
Then you say, what I can is to adopt the outside filo solution 
'the real one' that has not the above burden, and that have moreover
a lots of feature the inside's filo haven't.

(I have made a tool lbcc to build, to configure a rom and I
 seek also it to do the payload whatever is your payload program.
 But i felt troubled by coding the 'payload maker' because i hadn't
 clearly seen the "2 filos" even if I felt them.) 

Thanks for the explaination but.. err i still can't make myself answer
to theses questions.

-Can ELF boot onto CF , DoC or even CDROM and others instead of normal
hard disk ?
-Can it boot kernel from ext2, ext3, iso9660 or others ?
-Can it understand image like bzImage or others?

You see I would like to make truely a list of payload solutions in a
tab, and to tick whatever this solution or this other can this or that.
So that somebody's look on my tab, can say "-ok, this is my solution for
my build config, and it handles that filesys, support that image format"

mathieu




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


From zoiah at zoiah.net  Fri Jun  4 05:15:01 2004
From: zoiah at zoiah.net (Erik Smit)
Date: Fri Jun  4 05:15:01 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406031302410.2716-100000@maxroach.lanl.gov>
References: <20040603170712.GB15995@matryoshka.zylon.net> <Pine.LNX.4.44.0406031302410.2716-100000@maxroach.lanl.gov>
Message-ID: <20040604103753.GA10515@matryoshka.zylon.net>

On Thu, Jun 03, 2004 at 01:04:10PM -0600, ron minnich wrote:
> with the fuctory bios in place, make sure that your minicom setup is 
> right. Let me know.

My terminal setup is right since I actually give the reboot command
through the serial connection.

I just put the linuxbios.rom I build for the EPIA on an actual VIA
EPIA-V we have here. It boots up to this point:

 LinuxBIOS-1.1.6.0Fallback Fri Jun 4 00:34:01 CEST 2004 starting... 
 87 is the comm register 
 SMBus controller enabled 
 vt8601 init starting 
 00000000 is the north 
                      1106 0601 
 0120d4 is the computed timing 
                              NOP 
 PRECHARGE 
 DUMMY READS 
 CBR 
 MRS 
 NORMAL 
 set ref. rate 
 enable multi-page open 
 Slot 00 is SDRAM 20000000 bytes  
 0100 is the chip size 
 000e is the MA type 
 Slot 01smbus_error: 04 
 Device Error 
  is empty 
 Slot 02smbus_error: 04 
 Device Error 
  is empty 
 Slot 03smbus_error: 04 
 Device Error 
  is empty 
 vt8601 done

Then it starts to constantly repeat this:
 00:06 11 01 06 06 00 90 22 05 00 00 06 00 00 00 00  
 10:08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
 20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
 30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00  
 40:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
 50:ac 08 80 00 00 00 40 40 4e 00 00 00 40 40 40 40  
 60:3f 00 00 30 e4 e4 e4 00 42 ac 65 0d 08 7f 00 00  
 70:00 00 00 00 00 00 00 00 01 f0 00 00 00 00 00 00  
 80:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
 90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
 a0:02 00 20 00 03 02 00 07 00 00 00 00 08 02 00 00  
 b0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
 c0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
 d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
 e0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
 f0:00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 00 

I've tried different payloads but the same stuff happens. Anything I can
do about this?

Also, I've checked out the freebios(1) source and build an EPIA rom from
this and this does probably boot with the same filo payload and actually
boots a linux kernel and works, yay!

Also2, the cvs checkout of today still give this error on building:

/opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c: In function `check_pirq_routing_table':
/opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:21: error: assignment of read-only variable `intel_irq_routing_table'
/opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:42: error: assignment of read-only member `checksum'
make[1]: *** [pirq_routing.o] Error 1

I 'solved' this by commenting out the two lines, but I'm sure this is
not right. Any proper way to solve this?

Regards,

Erik Smit


From jmiller at actuality-systems.com  Fri Jun  4 09:08:00 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Fri Jun  4 09:08:00 2004
Subject: Tool Versions
Message-ID: <E8F8DBCB0468204E856114A2CD20741F14AF5C@mail.local.ActualitySystems.com>

I'm still having trouble building etherboot .zelf images.  It appears
that the file size in the elf header is corrupt, and someone here
suggested that I may have a buggy version of Perl.  Here are the
versions in my toolchain:

Red Hat 9.0 box with:

Gcc 3.3.3
Python 2.2.2
Perl 5.8.4 (latest & greatest)
Binutils-2.15

Any thoughts?

Thanks,

Jay Miller
Actuality Systems, Inc.
jmiller at acutality-systems.com





From rminnich at lanl.gov  Fri Jun  4 10:06:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jun  4 10:06:00 2004
Subject: Difference between Linxubios native's Elfboot and Linuxbios
 native's Filo
In-Reply-To: <1086337222.31673.79.camel@Calliphara>
Message-ID: <Pine.LNX.4.44.0406040914550.12300-100000@maxroach.lanl.gov>

On 4 Jun 2004, Mathieu Deschamps wrote:

> > The native ``filo'' is scheduled for deletion, it touches hardwaremain
> > which it should not.  As implemented it is a maintenance nightmare and
> > an implementation of policy and I refuse to support it, in the core of
> > LinuxBIOS.  Until just a little while ago I thought it was much less
> > intrusive so was not forcing the issue.
> 
> ok I understand.


well, I am afraid I do not. 

No one has contacted any of the other core maintainers of linuxbios and
vetted this suggestion of scheduling components for deletion. This
suggestion of deleting the embedded filo came out of left field, at least 
to me. Major changes on this level need discussion!

LinuxBIOS is a cooperative project. People add things from time to time
that others do not like. Every other core member of this project has added
software, at times, that I was not totally happy with, but I also have not
deleted such software because it is the nature of shared open source
projects that you can't keep everyone 100% happy all of the time. There
are things in both V1 and V2 I dislike very much, but I recognize the
right of authorship and the differences of opinion that come with
different people writing different code.

I should probably remind everyone here that this project was started by
LANL, and that the control of this project remains at LANL. We are a
non-profit, and I hope neutral, third party. I have had questions from
time to time about whether this or that commercial entity has too much
control of the project, and my response has always been: "Don't worry,
calm down, LANL is neutral here and can make sure we play fair". This 
type of query is serious. At one point I had a commercial company 
hinting about legal action as they felt that another company was 
holding back on releasing code to CVS. I was able to calm that one 
down too, simply by pointing out the role that LANL plays. 

LANL has a duty to provide a level playing ground for all involved. We can
not and will not allow deletions of subsystems deemed important by users
without some amount of discussion first, followed by some sort of
agreement. We had hoped to hash these issues out at the linuxbios summit
but were unable to bring that meeting to fruition.

Short form: I would ask all involved not to take actions that could lead 
to consequences we will all regret. 

ron



From rminnich at lanl.gov  Fri Jun  4 10:10:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jun  4 10:10:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html
 is broken)
In-Reply-To: <20040604103753.GA10515@matryoshka.zylon.net>
Message-ID: <Pine.LNX.4.44.0406040932340.12300-100000@maxroach.lanl.gov>

The 8231 is not seeing the smbus. Damn. 

I don't know what to tell you at this point.

ron



From rminnich at lanl.gov  Fri Jun  4 10:14:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jun  4 10:14:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html
 is broken)
In-Reply-To: <20040604103753.GA10515@matryoshka.zylon.net>
Message-ID: <Pine.LNX.4.44.0406040935360.12300-100000@maxroach.lanl.gov>

On Fri, 4 Jun 2004, Erik Smit wrote:

> 
>  LinuxBIOS-1.1.6.0Fallback Fri Jun 4 00:34:01 CEST 2004 starting... 
>  87 is the comm register 
>  SMBus controller enabled 
>  vt8601 init starting 
>  00000000 is the north 
>                       1106 0601 
>  0120d4 is the computed timing 
>                               NOP 
>  PRECHARGE 
>  DUMMY READS 
>  CBR 
>  MRS 
>  NORMAL 
>  set ref. rate 
>  enable multi-page open 
>  Slot 00 is SDRAM 20000000 bytes  
>  0100 is the chip size 
>  000e is the MA type 
>  Slot 01smbus_error: 04 
>  Device Error 
>   is empty 
>  Slot 02smbus_error: 04 
>  Device Error 
>   is empty 
>  Slot 03smbus_error: 04 
>  Device Error 
>   is empty 
>  vt8601 done
> 
> Then it starts to constantly repeat this:
>  00:06 11 01 06 06 00 90 22 05 00 00 06 00 00 00 00  
>  10:08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>  20:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>  30:00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00  
>  40:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>  50:ac 08 80 00 00 00 40 40 4e 00 00 00 40 40 40 40  
>  60:3f 00 00 30 e4 e4 e4 00 42 ac 65 0d 08 7f 00 00  
>  70:00 00 00 00 00 00 00 00 01 f0 00 00 00 00 00 00  
>  80:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>  90:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>  a0:02 00 20 00 03 02 00 07 00 00 00 00 08 02 00 00  
>  b0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>  c0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>  d0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>  e0:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>  f0:00 00 00 00 00 00 01 01 00 00 00 00 00 00 00 00 
> 
 I've tried different payloads but the same stuff happens. Anything I can
> do about this?

it found the memory and I think is programming it incorrectly. 

Sorry for the previous wrong comment. 
> 
> Also, I've checked out the freebios(1) source and build an EPIA rom from
> this and this does probably boot with the same filo payload and actually
> boots a linux kernel and works, yay!

ok, weird. 

> Also2, the cvs checkout of today still give this error on building:
> 
> /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c: In function `check_pirq_routing_table':
> /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:21: error: assignment of read-only variable `intel_irq_routing_table'
> /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:42: error: assignment of read-only member `checksum'
> make[1]: *** [pirq_routing.o] Error 1

Ollie or Stepan or Greg or David or I need to fix this. Anyone?

ron



From ebiederman at lnxi.com  Fri Jun  4 10:26:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Jun  4 10:26:01 2004
Subject: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
In-Reply-To: <Pine.LNX.4.44.0406040914550.12300-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406040914550.12300-100000@maxroach.lanl.gov>
Message-ID: <m38yf3gw4z.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:
> 
> well, I am afraid I do not. 
> 
> No one has contacted any of the other core maintainers of linuxbios and
> vetted this suggestion of scheduling components for deletion. This
> suggestion of deleting the embedded filo came out of left field, at least 
> to me. Major changes on this level need discussion!

Exactly. No ever even discussed including it.  No one ever discussed
changing our long standing compromise.  When I heard about it clear
it was on the edge of a line I would not cross.  And now that I have
actually had a chance to look I see that it is over that line.

Now there are some real issues that need to be solved to make it simpler
for users and sometime when I am not so mad I can barely talk.  I will do
something.

Eric


From ollie at lanl.gov  Fri Jun  4 10:38:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Jun  4 10:38:01 2004
Subject: Lex CV860A (was: The 'help me!' form on
	http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406040935360.12300-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406040935360.12300-100000@maxroach.lanl.gov>
Message-ID: <1086364858.14281.1.camel@exponential.lanl.gov>

On Fri, 2004-06-04 at 09:36, ron minnich wrote:

> > Also2, the cvs checkout of today still give this error on building:
> > 
> > /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c: In function `check_pirq_routing_table':
> > /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:21: error: assignment of read-only variable `intel_irq_routing_table'
> > /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:42: error: assignment of read-only member `checksum'
> > make[1]: *** [pirq_routing.o] Error 1
> 
> Ollie or Stepan or Greg or David or I need to fix this. Anyone?
> 

It is the const keyword. Why we don't have this problem before ?
Is the function actually been called in other platform ?

Ollie



From rminnich at lanl.gov  Fri Jun  4 10:40:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jun  4 10:40:01 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html
 is broken)
In-Reply-To: <1086364858.14281.1.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0406041002180.12300-100000@maxroach.lanl.gov>

On Fri, 4 Jun 2004, Li-Ta Lo wrote:

> It is the const keyword. Why we don't have this problem before ?
> Is the function actually been called in other platform ?

yes, that's what is so weird. This just started happening but I can find 
no changes that would have made it start happening. Weird.

ron



From ollie at lanl.gov  Fri Jun  4 10:44:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Jun  4 10:44:01 2004
Subject: Lex CV860A (was: The 'help me!' form on
	http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406041002180.12300-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406041002180.12300-100000@maxroach.lanl.gov>
Message-ID: <1086365192.14281.5.camel@exponential.lanl.gov>

On Fri, 2004-06-04 at 10:02, ron minnich wrote:
> On Fri, 4 Jun 2004, Li-Ta Lo wrote:
> 
> > It is the const keyword. Why we don't have this problem before ?
> > Is the function actually been called in other platform ?
> 
> yes, that's what is so weird. This just started happening but I can find 
> no changes that would have made it start happening. Weird.
> 
> ron
> 

What is the targe he is building ? EPIA ?

Ollie




From mdeschamps at mangrove-systems.com  Fri Jun  4 10:54:00 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Fri Jun  4 10:54:00 2004
Subject: Difference between Linxubios native's Elfboot and Linuxbios
	native's Filo
In-Reply-To: <Pine.LNX.4.44.0406040914550.12300-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406040914550.12300-100000@maxroach.lanl.gov>
Message-ID: <1086364916.31673.128.camel@Calliphara>

Hum.. I wasn't intended to be a media you use to rise such a polemic..

But from polemic can rise good things, and now that i'am part :

Le ven 04/06/2004 ? 17:29, ron minnich a ?crit :
> On 4 Jun 2004, Mathieu Deschamps wrote:
> 
> > > The native ``filo'' is scheduled for deletion, it touches hardwaremain
> > > which it should not.  As implemented it is a maintenance nightmare and
> > > an implementation of policy and I refuse to support it, in the core of
> > > LinuxBIOS.  Until just a little while ago I thought it was much less
> > > intrusive so was not forcing the issue.
> > 
> > ok I understand.
> 
> 
> well, I am afraid I do not. 
> 
> No one has contacted any of the other core maintainers of linuxbios and
> vetted this suggestion of scheduling components for deletion. This
> suggestion of deleting the embedded filo came out of left field, at least 
> to me. Major changes on this level need discussion!
> 
> LinuxBIOS is a cooperative project. People add things from time to time
> that others do not like. Every other core member of this project has added
> software, at times, that I was not totally happy with, but I also have not
> deleted such software because it is the nature of shared open source
> projects that you can't keep everyone 100% happy all of the time. There
> are things in both V1 and V2 I dislike very much, but I recognize the
> right of authorship and the differences of opinion that come with
> different people writing different code.

I do agree... even if IMHO mainteners are not clearly identified.

> 
> I should probably remind everyone here that this project was started by
> LANL, and that the control of this project remains at LANL. We are a
> non-profit, and I hope neutral, third party. I have had questions from
> time to time about whether this or that commercial entity has too much
> control of the project, and my response has always been: "Don't worry,
> calm down, LANL is neutral here and can make sure we play fair". This 
> type of query is serious. At one point I had a commercial company 
> hinting about legal action as they felt that another company was 
> holding back on releasing code to CVS. I was able to calm that one 
> down too, simply by pointing out the role that LANL plays. 

Trying to understand the hows and the whys, obvious I'am not targeted...

I hope so, or YOUR OpenSource banner you rise means nothing if,for
instance, features request can't be clearly openly answered, don't you
think ?
Anyway, I don't feel targeted concerning making majors changes :-)
nor I'am concerned on lack of concertation.  

For the rest, maybe i'am sensible but I have to say that commercial
entity do not all aim at same thing or at least does not behave all the
same. 
What I'am gaining with Linuxbios experience I'll try to give back in
somehow i could, don't you feel this ?.


mathieu
> LANL has a duty to provide a level playing ground for all involved. We can
> not and will not allow deletions of subsystems deemed important by users
> without some amount of discussion first, followed by some sort of
> agreement. We had hoped to hash these issues out at the linuxbios summit
> but were unable to bring that meeting to fruition.
> 
> Short form: I would ask all involved not to take actions that could lead 
> to consequences we will all regret. 
> 
> ron
> 
> 







From stuge-linuxbios at cdy.org  Fri Jun  4 15:12:01 2004
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri Jun  4 15:12:01 2004
Subject: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
In-Reply-To: <1086364916.31673.128.camel@Calliphara>
References: <Pine.LNX.4.44.0406040914550.12300-100000@maxroach.lanl.gov> <1086364916.31673.128.camel@Calliphara>
Message-ID: <20040604203434.GC18664@foo.birdnet.se>

On Fri, Jun 04, 2004 at 06:01:56PM +0200, Mathieu Deschamps wrote:
> What I'am gaining with Linuxbios experience I'll try to give back in
> somehow i could, don't you feel this ?.

I agree! :) I think the lbcc script can be very useful!


> > We had hoped to hash these issues out at the linuxbios summit
> > but were unable to bring that meeting to fruition.
> > 
> > Short form: I would ask all involved not to take actions that
> > could lead to consequences we will all regret.

I hope this doesn't have to become a big problem, we should be able
to just talk about it and straighten any issues out. It has been
done online before.

Just my EUR .02. :)


//Peter


From rminnich at lanl.gov  Fri Jun  4 16:44:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jun  4 16:44:00 2004
Subject: Difference between Linxubios native's Elfboot and Linuxbios
 native's Filo
In-Reply-To: <20040604203434.GC18664@foo.birdnet.se>
Message-ID: <Pine.LNX.4.44.0406041606240.15028-100000@maxroach.lanl.gov>

On Fri, 4 Jun 2004, Peter Stuge wrote:

> I hope this doesn't have to become a big problem, we should be able
> to just talk about it and straighten any issues out. It has been
> done online before.

We'll all cool off over the weekend and work it out next week.

thanks

ron



From stepan at openbios.org  Fri Jun  4 16:52:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Jun  4 16:52:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406041002180.12300-100000@maxroach.lanl.gov>
References: <1086364858.14281.1.camel@exponential.lanl.gov> <Pine.LNX.4.44.0406041002180.12300-100000@maxroach.lanl.gov>
Message-ID: <20040604221446.GC22441@openbios.org>

* ron minnich <rminnich at lanl.gov> [040604 18:02]:
> On Fri, 4 Jun 2004, Li-Ta Lo wrote:
> 
> > It is the const keyword. Why we don't have this problem before ?
> > Is the function actually been called in other platform ?
> 
> yes, that's what is so weird. This just started happening but I can find 
> no changes that would have made it start happening. Weird.

It depends on the compiler version you are using. Gcc behaves different
every minor version now. My gcc (3.3.3, SUSE 9.1) shows the same thing 
as a warning.

Stefan


From stepan at openbios.org  Fri Jun  4 16:53:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Jun  4 16:53:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406040932340.12300-100000@maxroach.lanl.gov>
References: <20040604103753.GA10515@matryoshka.zylon.net> <Pine.LNX.4.44.0406040932340.12300-100000@maxroach.lanl.gov>
Message-ID: <20040604221615.GD22441@openbios.org>

* ron minnich <rminnich at lanl.gov> [040604 17:33]:
> The 8231 is not seeing the smbus. Damn. 
> 
> I don't know what to tell you at this point.

Is it not? The log seems to indicate ram has been found in slot0

Stefan





From gwatson at lanl.gov  Fri Jun  4 16:57:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Fri Jun  4 16:57:00 2004
Subject: briQ status
Message-ID: <56250BC2-B675-11D8-8EEE-000393A47A5C@lanl.gov>

For those interested in PPC boards, I just managed to get the briQ 
talking over serial console. (More on the board at 
http://www.totalimpact.com/products/the_briq/the_briq.html). Output 
below.

Hopefully we'll demo this board running Clustermatic at the USENIX BOF.

Greg

Board initialized...
LinuxBIOS-1.1.6 Fri Jun 4 16:13:35 MDT 2004 rebooting...
Finding PCI configuration type.
Enumerating static devices...
Enumerating buses...
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1014/0105] enabled
PCI: 00:06.0 [10ad/0565] ops
PCI: 00:06.0 [10ad/0565] enabled
PCI: 00:06.1 [10ad/0105] ops
PCI: 00:06.1 [10ad/0105] enabled
PCI: 00:07.0 [1022/2000] enabled
PCI: pci_scan_bus returning with max=00
done
Allocating resources...
ASSIGN RESOURCES, bus 0
PCI: 00:06.1 10 <- [0x00001040 - 0x00001047] io
PCI: 00:06.1 14 <- [0x00001050 - 0x00001053] io
PCI: 00:06.1 18 <- [0x00001048 - 0x0000104f] io
PCI: 00:06.1 1c <- [0x00001054 - 0x00001057] io
PCI: 00:06.1 20 <- [0x00001020 - 0x0000102f] io
PCI: 00:06.1 24 <- [0x00001030 - 0x0000103f] io
PCI: 00:07.0 10 <- [0x00001000 - 0x0000101f] io
PCI: 00:07.0 14 <- [0xfebfffe0 - 0xfebfffff] mem
ASSIGNED RESOURCES, bus 0
done.
Enabling resourcess...
PCI: 00:00.0 cmd <- 147
PCI: 00:06.0 cmd <- 147
PCI: 00:06.1 cmd <- 145
PCI: 00:07.0 cmd <- 143
done.
Initializing devices...
PCI: 00:06.0 init
Configure W83C553F ISA Bridge (Function 0)
W83C553F configuration complete
PCI: 00:06.1 init
Configure W83C553F IDE (Function 1)
ide bus offset = 0x1f1
IDE configuration complete
Devices initialized
totalram: 1024M
Initializing CPU #0
PowerPC 7400 CPU, version 2.9
CPU #0 Initialized
Wrote linuxbios table at: 00000010 - 00000174  checksum 9bf0

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

Trying polled ide
Waiting for ide disks to spin up
This is a hard coded delay and longer than necessary.
..
found PCI IDE controller 10ad:0105 prog_if=0x8f
primary channel: native PCI mode



From stuge-linuxbios at cdy.org  Fri Jun  4 19:31:00 2004
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri Jun  4 19:31:00 2004
Subject: testbios and the system timer
In-Reply-To: <40BF8AFA.1050705@bitworks.com>
References: <E8F8DBCB0468204E856114A2CD20741F14AEA4@mail.local.ActualitySystems.com> <1086196196.22884.15.camel@exponential.lanl.gov> <20040602180501.GA29361@openbios.org> <40BEE7BD.60104@bitworks.com> <20040603170359.GA19199@foo.birdnet.se> <40BF8AFA.1050705@bitworks.com>
Message-ID: <20040605005358.GA29314@foo.birdnet.se>

On Thu, Jun 03, 2004 at 03:32:58PM -0500, Richard Smith wrote:
> Peter Stuge wrote:
> 
> >On Thu, Jun 03, 2004 at 03:56:29AM -0500, Richard Smith wrote:
> >
> >>timer.  In numerious locations my Vbios is writing a 0x00 to IO 0x43 and 
> >>then does 2 reads from 0x40.  So its latching the value of counter 0 and 
> >>then reading it out.
> >
> >Right, it also sets counter mode 0, zero detection interrupt. Are
> >there any hints of the code actually using the interrupt anywhere?
> 
> Um... I don't know.  What would I look for?

Someone writing a segment/offset pair to 0000:0020. (I.e. installing
an interrupt handler for IRQ0/INT8.)

> I don't thing so but that does explain why linux whines about "too
> many timer interrutps" occurring.

Yes, if the io accesses are let through the emulator to the real
hardware, that's certainly the reason.

You could probably test this, I did some quick testing and it looks
like Linux sets the timer divisor so that timer 0 runs at 1kHz.
Verify this (grep 0: /proc/interrupts && sleep && grep) followed by
a timed run of testbios. If there are extra interrupts on IRQ 0, the
real hardware was touched.


[..]
> Looking at the delay routine is just confusing.

I agree.


> There's a comment that says 4 bx counts equals .4290 * 4 or 2uS.
> So that tells me the VBios thinks the system timer must be running
> at 2.386 Mhz rather than the 1.19318 Mhz my PC hardware book claims.

1193180Hz doesn't change, that's the 4.77MHz clock divided by four,
your hardware book is correct. I used Ralf Brown's interrupt/port
list to refresh my own memory.


> All this tells me that I don't understand timer access in a modern 
> system.  The code as written just dosen't seem like it would work on a 
> 4.77 Mhz XT.

It may not neccessarily do so. The M1 is a PCI bus chip, right? I
can easily imagine that ATI didn't make the video BIOS XT compatible
for a graphics controller targeted at newer/mobile/embedded systems.


[..snip..]

> This will only skip the jump (and do the BX decrement) if ax is
> zero. For ax to be zero the result of the 2's complement
> subtraction must be zero or the when the 2 reads are the same
> number.  But I just don't see how this would happen repeatably
> at .6us per ISA IO.

Hmm. Let's have another look at the code.

Ok. Pseudocode:

procedure delay(someunit) {
	bx=someunit
	dx=read_timer()
	do {
		ax=read_timer()
		ax=-(ax-dx)
		if(ax==0)
			bx=bx-(bx mod 2)-2
	} while(ax<bx)
}

It doesn't make a whole lot of sense, but eventually the loop will
end, since -(the_original_timer-current_timer) always gets compared
with the requested delay. If the (16bit) timer wraps, bx is
decreased but that's not really neccessary for the loop to ever end.

Conclusion; it not a very precise delay, it's just a suitably short
delay. :)


> Ate the timer reads really and ISA IO?

At least they used to be, port accesses on 486/Pentium took forever
and that's when I last did stuff like this and payed any attention
to how long it took. :)


> I guess if those reads are happening much faster then it would work.
> Where does the timer live now? int the northbridge perhpas?  Thats
> could be the issue.  If the northbridge  responded to the IO it
> would happen at cpu clock rates and all would be well.

Sure, it's part of the northbridge, but all sorts of buses are there,
I'd just put the timer where it has always been, on an ISA bus, to
minimize breakage. Although, lately I guess ISA isn't included in
chipsets, at least externally. LPC is handy for things like this and
of course runs a lot faster at 33MHz.


//Peter


From stuge-linuxbios at cdy.org  Fri Jun  4 20:18:01 2004
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri Jun  4 20:18:01 2004
Subject: Difference between Linxubios native's Elfboot and Linuxbios native's Filo
In-Reply-To: <Pine.LNX.4.44.0406041606240.15028-100000@maxroach.lanl.gov>
References: <20040604203434.GC18664@foo.birdnet.se> <Pine.LNX.4.44.0406041606240.15028-100000@maxroach.lanl.gov>
Message-ID: <20040605014050.GB29314@foo.birdnet.se>

On Fri, Jun 04, 2004 at 04:06:41PM -0600, ron minnich wrote:
> > I hope this doesn't have to become a big problem, we should be able
> > to just talk about it and straighten any issues out. It has been
> > done online before.
> 
> We'll all cool off over the weekend and work it out next week.

Sounds good. Kick back and enjoy a can or two of <insert favorite
beverage here> in the sun, if you happen to live near some summer. :)


> thanks

No problem. Hope you all have a nice weekend!


//Peter


From YhLu at tyan.com  Fri Jun  4 20:24:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jun  4 20:24:00 2004
Subject: intel 875P support
Message-ID: <3174569B9743D511922F00A0C9431423055352FC@TYANWEB>

Who is working on intel 875P northbridge?

Regards

YH


From YhLu at tyan.com  Fri Jun  4 20:37:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jun  4 20:37:00 2004
Subject: Intel Chipset support in V2
Message-ID: <3174569B9743D511922F00A0C9431423055352FF@TYANWEB>

Ron,

Any plan to move the intel chipset support from V1 to V2? I mean E750x and
82801xx.

Regards

YH


From YhLu at tyan.com  Fri Jun  4 20:55:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jun  4 20:55:01 2004
Subject: CPL and GPL
Message-ID: <3174569B9743D511922F00A0C943142305535301@TYANWEB>

It seems one EFI implementation in 32 bit.

What's the major difference between CPL and GPL?

Regards

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?6?1? 17:31
???: Bari Ari
??: Steve Gehlbach; Stefan Reinauer; linuxbios at clustermatic.org
??: Re: ACPI DSDT

On Tue, 1 Jun 2004, Bari Ari wrote:

> Here's the official Intel statement:
> 
> http://www.intel.com/pressroom/archive/releases/20040601corp_a.htm

gee, no mention of linuxbios :-)

ron

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


From stepan at openbios.org  Sat Jun  5 04:49:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat Jun  5 04:49:01 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406040935360.12300-100000@maxroach.lanl.gov>
References: <20040604103753.GA10515@matryoshka.zylon.net> <Pine.LNX.4.44.0406040935360.12300-100000@maxroach.lanl.gov>
Message-ID: <20040605101215.GA30671@openbios.org>

* ron minnich <rminnich at lanl.gov> [040604 17:36]:
> > Also2, the cvs checkout of today still give this error on building:
> > 
> > /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c: In function `check_pirq_routing_table':
> > /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:21: error: assignment of read-only variable `intel_irq_routing_table'
> > /opt/linuxbios/freebios2/src/arch/i386/boot/pirq_routing.c:42: error: assignment of read-only member `checksum'
> > make[1]: *** [pirq_routing.o] Error 1
> 
> Ollie or Stepan or Greg or David or I need to fix this. Anyone?

I will comment the two table fixing functions out for now until we
generate this table dynamically

Stefan



From stepan at openbios.org  Sat Jun  5 05:06:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat Jun  5 05:06:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <20040605101215.GA30671@openbios.org>
References: <20040604103753.GA10515@matryoshka.zylon.net> <Pine.LNX.4.44.0406040935360.12300-100000@maxroach.lanl.gov> <20040605101215.GA30671@openbios.org>
Message-ID: <20040605102940.GA30765@openbios.org>

* Stefan Reinauer <stepan at openbios.org> [040605 12:12]:
> I will comment the two table fixing functions out for now until we
> generate this table dynamically

The table is checked twice, once the original and once the copy. 
Since the checking of the original does not change the fact whether the
the table is copied at all, I will unify these and only check the copy
of the pirq table. There we can change checksum and length as we wish.

Stefan



From stepan at openbios.org  Sat Jun  5 05:15:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat Jun  5 05:15:01 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <20040605102940.GA30765@openbios.org>
References: <20040604103753.GA10515@matryoshka.zylon.net> <Pine.LNX.4.44.0406040935360.12300-100000@maxroach.lanl.gov> <20040605101215.GA30671@openbios.org> <20040605102940.GA30765@openbios.org>
Message-ID: <20040605103835.GA31006@openbios.org>

* Stefan Reinauer <stepan at openbios.org> [040605 12:29]:
> * Stefan Reinauer <stepan at openbios.org> [040605 12:12]:
> > I will comment the two table fixing functions out for now until we
> > generate this table dynamically
> 
> The table is checked twice, once the original and once the copy. 
> Since the checking of the original does not change the fact whether the
> the table is copied at all, I will unify these and only check the copy
> of the pirq table. There we can change checksum and length as we wish.

If noone is going to object the attached patch, I am going to submit
this soon.

Stefan

-------------- next part --------------
Index: arch/i386/boot/pirq_routing.c
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/arch/i386/boot/pirq_routing.c,v
retrieving revision 1.8
diff -u -r1.8 pirq_routing.c
--- arch/i386/boot/pirq_routing.c	15 Apr 2004 17:33:20 -0000	1.8
+++ arch/i386/boot/pirq_routing.c	5 Jun 2004 10:36:43 -0000
@@ -3,29 +3,24 @@
 #include <string.h>
 
 #if (DEBUG==1 && HAVE_PIRQ_TABLE==1)
-void check_pirq_routing_table(void)
+static void check_pirq_routing_table(struct irq_routing_table *rt)
 {
-	const uint8_t *addr;
-	const struct irq_routing_table *rt;
+	uint8_t *addr = (uint8_t *)rt;
+	uint8_t sum=0;
 	int i;
-	uint8_t sum;
 
-	printk_info("Checking IRQ routing tables...\n");
+	printk_info("Checking IRQ routing table consistency...\n");
 
 #if defined(IRQ_SLOT_COUNT)
-	if (sizeof(intel_irq_routing_table) != intel_irq_routing_table.size) {
+	if (sizeof(struct irq_routing_table) != rt->size) {
 		printk_warning("Inconsistent IRQ routing table size (0x%x/0x%x)\n",
-			       sizeof(intel_irq_routing_table),
-			       intel_irq_routing_table.size
+			       sizeof(struct irq_routing_table),
+			       rt->size
 			);
-		intel_irq_routing_table.size=sizeof(intel_irq_routing_table);
+		rt->size=sizeof(struct irq_routing_table);
 	}
 #endif
 
-	rt = &intel_irq_routing_table;
-	addr = (uint8_t *)rt;
-
-	sum = 0;
 	for (i = 0; i < rt->size; i++)
 		sum += addr[i];
 
@@ -43,7 +38,7 @@
 	}
 
 	if (rt->signature != PIRQ_SIGNATURE || rt->version != PIRQ_VERSION ||
-	    rt->size % 16 || rt->size < sizeof(struct irq_routing_table)) {
+	    rt->size % 16 ) {
 		printk_warning("%s:%6d:%s() - "
 			       "Interrupt Routing Table not valid\n",
 			       __FILE__, __LINE__, __FUNCTION__);
@@ -63,7 +58,7 @@
 	printk_info("done.\n");
 }
 
-int verify_copy_pirq_routing_table(unsigned long addr)
+static int verify_copy_pirq_routing_table(unsigned long addr)
 {
 	int i;
 	uint8_t *rt_orig, *rt_curr;
@@ -78,6 +73,9 @@
 		}
 	}
 	printk_info("done\n");
+	
+	check_routing_table((struct irq_routing_table *)addr);
+	
 	return 0;
 }
 #else
Index: arch/i386/boot/tables.c
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/arch/i386/boot/tables.c,v
retrieving revision 1.7
diff -u -r1.7 tables.c
--- arch/i386/boot/tables.c	15 Apr 2004 17:33:20 -0000	1.7
+++ arch/i386/boot/tables.c	5 Jun 2004 10:36:44 -0000
@@ -46,7 +46,6 @@
 	low_table_end = 16;
 
 	post_code(0x9a);
-	check_pirq_routing_table();
 
 	/* This table must be betweeen 0xf0000 & 0x100000 */
 	rom_table_end = copy_pirq_routing_table(rom_table_end);
Index: arch/i386/include/arch/pirq_routing.h
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/arch/i386/include/arch/pirq_routing.h,v
retrieving revision 1.2
diff -u -r1.2 pirq_routing.h
--- arch/i386/include/arch/pirq_routing.h	23 Mar 2004 17:39:22 -0000	1.2
+++ arch/i386/include/arch/pirq_routing.h	5 Jun 2004 10:36:44 -0000
@@ -39,12 +39,6 @@
 
 extern const struct irq_routing_table intel_irq_routing_table;
 
-#if (DEBUG==1 && HAVE_PIRQ_TABLE==1)
-void check_pirq_routing_table(void);
-#else
-#define check_pirq_routing_table() do {} while(0)
-#endif
-
 #if HAVE_PIRQ_TABLE==1
 unsigned long copy_pirq_routing_table(unsigned long start);
 #else

From stepan at openbios.org  Sat Jun  5 05:28:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Sat Jun  5 05:28:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <20040605103835.GA31006@openbios.org>
References: <20040604103753.GA10515@matryoshka.zylon.net> <Pine.LNX.4.44.0406040935360.12300-100000@maxroach.lanl.gov> <20040605101215.GA30671@openbios.org> <20040605102940.GA30765@openbios.org> <20040605103835.GA31006@openbios.org>
Message-ID: <20040605105130.GA31616@openbios.org>

* Stefan Reinauer <stepan at openbios.org> [040605 12:38]:
> Index: arch/i386/boot/pirq_routing.c
> ===================================================================
> RCS file: /cvsroot/freebios/freebios2/src/arch/i386/boot/pirq_routing.c,v
> retrieving revision 1.8
> diff -u -r1.8 pirq_routing.c
> --- arch/i386/boot/pirq_routing.c	15 Apr 2004 17:33:20 -0000	1.8
> +++ arch/i386/boot/pirq_routing.c	5 Jun 2004 10:36:43 -0000
> @@ -78,6 +73,9 @@
>  		}
>  	}
>  	printk_info("done\n");
> +	
> +	check_routing_table((struct irq_routing_table *)addr);
> +	
>  	return 0;
>  }
>  #else

This should be check_pirq_routing_table() of course.

Stefan





From zoiah at zoiah.net  Sat Jun  5 08:02:00 2004
From: zoiah at zoiah.net (Erik Smit)
Date: Sat Jun  5 08:02:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406040935360.12300-100000@maxroach.lanl.gov>
References: <20040604103753.GA10515@matryoshka.zylon.net> <Pine.LNX.4.44.0406040935360.12300-100000@maxroach.lanl.gov>
Message-ID: <20040605132506.GB10690@matryoshka.zylon.net>

On Fri, Jun 04, 2004 at 09:36:36AM -0600, ron minnich wrote:
>  I've tried different payloads but the same stuff happens. Anything I can
> > do about this?
> 
> it found the memory and I think is programming it incorrectly. 
> 
> Sorry for the previous wrong comment. 

Is there anything I can do about this? Maybe help debugging? I have
tried changing the slot the memory is in but the same stuff happens.

Regards,

Erik Smit


From rminnich at lanl.gov  Sat Jun  5 12:23:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sat Jun  5 12:23:00 2004
Subject: Intel Chipset support in V2
In-Reply-To: <3174569B9743D511922F00A0C9431423055352FF@TYANWEB>
Message-ID: <Pine.LNX.4.44.0406051144420.22589-100000@maxroach.lanl.gov>

On Fri, 4 Jun 2004, YhLu wrote:

> Any plan to move the intel chipset support from V1 to V2? I mean E750x and
> 82801xx.

it depends on someone having the time. 

I would like to see it happen, but our interest in 32-bit platforms is not 
as broad as it once was,  so it's going to be someone else (or us when we 
get time). 

thanks

ron



From rminnich at lanl.gov  Sat Jun  5 12:23:48 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sat Jun  5 12:23:48 2004
Subject: CPL and GPL
In-Reply-To: <3174569B9743D511922F00A0C943142305535301@TYANWEB>
Message-ID: <Pine.LNX.4.44.0406051145490.22589-100000@maxroach.lanl.gov>

On Fri, 4 Jun 2004, YhLu wrote:

> What's the major difference between CPL and GPL?

CPL is very BSD-like, so a vendor can modify and redistribute binary, so a
fork is guaranteed. Forked BIOSes are a really bad thing for customers.

ron



From rminnich at lanl.gov  Sat Jun  5 12:37:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sat Jun  5 12:37:01 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html
 is broken)
In-Reply-To: <20040605103835.GA31006@openbios.org>
Message-ID: <Pine.LNX.4.44.0406051200081.22589-100000@maxroach.lanl.gov>

looks ok to me.

ron



From pyro at linuxlabs.com  Sat Jun  5 12:49:00 2004
From: pyro at linuxlabs.com (Steven James)
Date: Sat Jun  5 12:49:00 2004
Subject: Intel Chipset support in V2
In-Reply-To: <Pine.LNX.4.44.0406051144420.22589-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406051144420.22589-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.58.0406051811490.28503@ucontrol.mobiledns.com>

Greetings,

I have an interest in it when I get time, but we've seen how time has
worked out for me lately :-(

G'day,
sjames


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


On Sat, 5 Jun 2004, ron minnich wrote:

> On Fri, 4 Jun 2004, YhLu wrote:
>
> > Any plan to move the intel chipset support from V1 to V2? I mean E750x and
> > 82801xx.
>
> it depends on someone having the time.
>
> I would like to see it happen, but our interest in 32-bit platforms is not
> as broad as it once was,  so it's going to be someone else (or us when we
> get time).
>
> thanks
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>


From stepan at openbios.org  Mon Jun  7 05:03:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Mon Jun  7 05:03:00 2004
Subject: Lex CV860A (was: The 'help me!' form on http://www.linuxbios.org/help/index.html is broken)
In-Reply-To: <Pine.LNX.4.44.0406051200081.22589-100000@maxroach.lanl.gov>
References: <20040605103835.GA31006@openbios.org> <Pine.LNX.4.44.0406051200081.22589-100000@maxroach.lanl.gov>
Message-ID: <20040607102610.GA20147@openbios.org>

* ron minnich <rminnich at lanl.gov> [040605 20:00]:
> looks ok to me.

Ok. Checked in.



From kfuchs at winternet.com  Mon Jun  7 08:43:01 2004
From: kfuchs at winternet.com (Ken Fuchs)
Date: Mon Jun  7 08:43:01 2004
Subject: http://www.linuxbios.org/developer/download/
Message-ID: <200406071406.i57E6L5O008224@tundra.winternet.com>

Sorry, there doesn't appear to be a webmaster e-mail address for
linuxbios.org, so I'm sending this web site update request to the
LinuxBIOS mailing list.

Please correct the cvs commands' hostname.  It should be
cvs.sourceforge.net, not cvs.freebios.sourceforge.net.

It would also be helpful to suggest that the environment variable
CVS_RSH be set to ssh prior to using any cvs command (example for bash
below):

$ export CVS_RSH=ssh

Sincerely,

Ken Fuchs <kfuchs at winternet.com>


From mdeschamps at mangrove-systems.com  Mon Jun  7 08:44:01 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Mon Jun  7 08:44:01 2004
Subject: Difference between Linxubios native's Elfboot and Linuxbios
	native's Filo
In-Reply-To: <20040604203434.GC18664@foo.birdnet.se>
References: <Pine.LNX.4.44.0406040914550.12300-100000@maxroach.lanl.gov>
	 <1086364916.31673.128.camel@Calliphara>
	 <20040604203434.GC18664@foo.birdnet.se>
Message-ID: <1086616384.31673.165.camel@Calliphara>

Le ven 04/06/2004 ? 22:34, Peter Stuge a ?crit :
> On Fri, Jun 04, 2004 at 06:01:56PM +0200, Mathieu Deschamps wrote:
> > What I'am gaining with Linuxbios experience I'll try to give back in
> > somehow i could, don't you feel this ?.
> 
> I agree! :) I think the lbcc script can be very useful!

 thank you :) yes maybe it will if it's shared and credited.
For now, it needs some pipe work to connect to linuxbios utils and
LANL's guidance and everybody's credit/opinion.

Le sam 05/06/2004 ? 03:40, Peter Stuge a ?crit : 
> On Fri, Jun 04, 2004 at 04:06:41PM -0600, ron minnich wrote:
> > > I hope this doesn't have to become a big problem, we should be able
> > > to just talk about it and straighten any issues out. It has been
> > > done online before.
> > 
> > We'll all cool off over the weekend and work it out next week.
> 
> Sounds good. Kick back and enjoy a can or two of <insert favorite
> beverage here> in the sun, if you happen to live near some summer. :)
> 
> 
> > thanks
> 
> No problem. Hope you all have a nice weekend!

yes it was i got sunburnt but i'am cool off that's ok now :)

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

> 
> 
> > > We had hoped to hash these issues out at the linuxbios summit
> > > but were unable to bring that meeting to fruition.
> > > 
> > > Short form: I would ask all involved not to take actions that
> > > could lead to consequences we will all regret.
> 
> I hope this doesn't have to become a big problem, we should be able
> to just talk about it and straighten any issues out. It has been
> done online before.
> 
> Just my EUR .02. :)
> 
> 
> //Peter
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 


From ebiederman at lnxi.com  Mon Jun  7 14:56:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jun  7 14:56:00 2004
Subject: Intel Chipset support in V2
In-Reply-To: <3174569B9743D511922F00A0C9431423055352FF@TYANWEB>
References: <3174569B9743D511922F00A0C9431423055352FF@TYANWEB>
Message-ID: <m3k6yj3ypz.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Ron,
> 
> Any plan to move the intel chipset support from V1 to V2? I mean E750x and
> 82801xx.

Right now implementing the newer intel chipsets in v2 is taking
with the code I am working on.  

Eric


From ebiederman at lnxi.com  Mon Jun  7 15:03:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jun  7 15:03:01 2004
Subject: =?gb2312?b?tPC4tA==?=: [COMMIT] romcc 0.63 and some fixes...
In-Reply-To: <m3llj4aydb.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C9431423050647F4@TYANWEB>
	<m3llj4aydb.fsf@maxwell.lnxi.com>
Message-ID: <m3fz973yec.fsf@maxwell.lnxi.com>

ebiederman at lnxi.com (Eric W. Biederman) writes:

> YhLu <YhLu at tyan.com> writes:
> 
> > Just sent out the core.
> 
> Thanks.  I have done the basic tracking.  And it is clearly a code
> bug.  

With the bug fix in place I am seeing what looks like another bug.

For the moment you can avoid this by removing the printo_debug
from generate_row.  That still runs out of registers but the
compiler does not crash.

I would dearly love to see a version of this code that works
when you do broad changes, like you did.  At the moment the code does
work well enough that if you change a couple of functions at a time,
you get some benefit.

Eric


From YhLu at tyan.com  Mon Jun  7 15:31:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Jun  7 15:31:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogW0NPTU1JVF0gcm9tY2MgMC42MyBhbmQgc29t?=
	=?GB2312?B?ZSBmaXhlcy4uLg==?=
Message-ID: <3174569B9743D511922F00A0C943142305535373@TYANWEB>

I see. The code is getting larger.

Also the reboot in OS can not work.

Regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?7? 13:29
???: YhLu; LinuxBIOS
??: Re: ??: [COMMIT] romcc 0.63 and some fixes...

ebiederman at lnxi.com (Eric W. Biederman) writes:

> YhLu <YhLu at tyan.com> writes:
> 
> > Just sent out the core.
> 
> Thanks.  I have done the basic tracking.  And it is clearly a code
> bug.  

With the bug fix in place I am seeing what looks like another bug.

For the moment you can avoid this by removing the printo_debug
from generate_row.  That still runs out of registers but the
compiler does not crash.

I would dearly love to see a version of this code that works
when you do broad changes, like you did.  At the moment the code does
work well enough that if you change a couple of functions at a time,
you get some benefit.

Eric


From YhLu at tyan.com  Mon Jun  7 15:32:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Jun  7 15:32:00 2004
Subject: Intel Chipset support in V2
Message-ID: <3174569B9743D511922F00A0C943142305535374@TYANWEB>

Which chipsets are you working on?

Regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?7? 13:22
???: YhLu
??: ron minnich; LinuxBIOS
??: Re: Intel Chipset support in V2

YhLu <YhLu at tyan.com> writes:

> Ron,
> 
> Any plan to move the intel chipset support from V1 to V2? I mean E750x and
> 82801xx.

Right now implementing the newer intel chipsets in v2 is taking
with the code I am working on.  

Eric


From ebiederman at lnxi.com  Mon Jun  7 15:53:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jun  7 15:53:00 2004
Subject: =?gb2312?b?tPC4tA==?=: =?gb2312?b?tPC4tA==?=: [COMMIT] romcc
  0.63 and some fixes...
In-Reply-To: <3174569B9743D511922F00A0C943142305535373@TYANWEB>
References: <3174569B9743D511922F00A0C943142305535373@TYANWEB>
Message-ID: <m3y8mzysko.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> I see. The code is getting larger.

Not quite.  There is less generated code, but it requires
extra registers to hold the return addresses so the register
pressure is higher.

Some of that extra register pressure may be artificial and
go away when this bug is fixed.  Some of it may result from
poor choices of the register allocator, and may be remedied
by enhancing the register allocator.  There is hope of
remedies as the kind of code presented to the register
allocator is very different when code is not inlined.

> Also the reboot in OS can not work.

Hmm.  At least with reboot=hard that should work on the Opterons.
I have not tested that lately though.

Eric


From ebiederman at lnxi.com  Mon Jun  7 15:55:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jun  7 15:55:01 2004
Subject: Intel Chipset support in V2
In-Reply-To: <3174569B9743D511922F00A0C943142305535374@TYANWEB>
References: <3174569B9743D511922F00A0C943142305535374@TYANWEB>
Message-ID: <m3u0xnyshq.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Which chipsets are you working on?

Lindenhurst, mostly.

I can't release/say much until the actual product release.

Eric


From ebiederman at lnxi.com  Tue Jun  8 01:33:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  8 01:33:00 2004
Subject: Tool Versions
In-Reply-To: <E8F8DBCB0468204E856114A2CD20741F14AF5C@mail.local.ActualitySystems.com>
References: <E8F8DBCB0468204E856114A2CD20741F14AF5C@mail.local.ActualitySystems.com>
Message-ID: <m3fz96sfh4.fsf@maxwell.lnxi.com>

"Jay Miller" <jmiller at actuality-systems.com> writes:

> I'm still having trouble building etherboot .zelf images.  It appears
> that the file size in the elf header is corrupt, and someone here
> suggested that I may have a buggy version of Perl.  Here are the
> versions in my toolchain:
> 
> Red Hat 9.0 box with:
> 
> Gcc 3.3.3
> Python 2.2.2
> Perl 5.8.4 (latest & greatest)
> Binutils-2.15
> 
> Any thoughts?

What is lang set to?  If it is not a byte encoding that is likely the
issue.  I don't quite know why that makes a difference but it seems to.

Eric


From ebiederman at lnxi.com  Tue Jun  8 02:38:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  8 02:38:01 2004
Subject: Bootloaders and LinuxBIOS
Message-ID: <m3aczescg0.fsf@maxwell.lnxi.com>

As the freebiosv1 tree grew and developed we had a lot of disagreement
about bootloaders.  What should linuxbios do in condition X.  It was
clear that there was no way that in the linuxbios tree itself we could
satisfy all of the developers.  You can see remnants of this in
the freebios1 tree in src/lib/linuxbiosmain.c

Coming into this confusion I proposed a truce, that would give us
greater flexibility and allow a single LinuxBIOS source tree for
everyone.  That was to have a really stupid bootloader in LinuxBIOS
that was smart enough to load a real bootloader.  That is where
elfboot comes from.  

To prove my concept I ported etherboot to run under LinuxBIOS as that 
was the only bootloader I could find that actually had real
hardware drivers.  In this scenario the fact that etherboot 
well with my style of booting was no longer a threat because people
were free to use their own code.  Etherboot was also choosen because
of it's strong core team of maintainers and you can all see the
results of that decision today.

Out of this concept we had additional bootloaders written or ported:
ADLO, FILO, OpenBIOS, baremetal, linux kernel, etc.

So from everything I can see this concept has been a success.  I have
seen no complaints.  We don't have more because it is not the easiest
thing to write standalone code to the bare metal.  But this is
something time and starting to catch up on our LinuxBIOS ports 
has been overcoming.

One of the large reasons I was a great proponet of the simple/stupid
bootloader in LinuxBIOS to load a real one is that draws a line around
what functionality LinuxBIOS shall provide.  Anything over that line
is code bloat.

Several months ago as I was involved in other things Yhlu noted that
FILO had been added to LinuxBIOS without a word.   The way he described
it I thought it was as a driver to elfboot.  I expressed my concerns
at that time, but I really have not had time to do anything.  And if
it was a driver it was seriously pushing the line I had drawn against
feature bloat, and really coming close to starting another bootloader
feature war but it was perhaps ok.  

Later I finally had time to start syncing my code with the main
LinuxBIOS and I saw what that code actually was, and I was shocked.
This code had crossed the line, it had broken the truce, it was
feature bloat.  Not to talk about how useless a disk based bootloader
is without a configuration file.  From that moment on I have not
seen a reasonable solution besides deleting that code from LinuxBIOS.

Last time we had this conversation 2 problems were mentioned that
this code solves.
1) People have a hard time setting up an external payload.
2) There are not any bootloaders for the ppc that run under LinuxBIOS.

To the problem of setting up an external payload I propose we can
include FILO into the tree like baremetal and simply make it the
default payload.  If you don't change anything it will get built.
That solves the problem without breaking the design.

To the problem of there not being any bootloaders for the ppc that
run under LinuxBIOS.  I respond that one of the x86 based bootloaders
would not be hard to port, or better yet we can just use a kernel
with kexec built in.  Although I would strongly be with the amount of
embedded activity that happens with the ppc if none of the native
ppc bootloaders could not be easily adopted.

In addition I have seen noone except the guys at LANL who are even
interested in the built in FILO. 

I have a few additional technical objections as well.  Just like when
someone tried to include etherboot the code in the LinuxBIOS tree has
languished, and is much less capable a solution.

Having to support bootloaders places an additional burden upon the
LinuxBIOS code that must be considered when the code must be
refactored or cleaned up.  And we have not even succeed in a
sufficiently clean and stable API that we are willing to freeze the
core interfaces and make stable releases from the LinuxBIOS tree, only
adding new ports or extensions to the existing API that cannot
possibly break old ports.

So does someone have a reason to keep the built-in FILO besides being
lazy slobs who want something-for-nothing and are not willing to put
in the work to make production quality solutions?

Eric


From ebiederman at lnxi.com  Tue Jun  8 02:41:02 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  8 02:41:02 2004
Subject: testbios and the system timer
In-Reply-To: <Pine.LNX.4.44.0406031500110.2716-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406031500110.2716-100000@maxroach.lanl.gov>
Message-ID: <m37juiscbk.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:
> You can in the emulator redirect I/O port access to a function. Write the 
> code to handle read/write on those ports and use the emulate_counter to 
> drive the clock value.

Let me ask this quick question.  Does the emulator restrict port I/O to
just the resources on a particular VGA device?   If not that is something
we need to do to implement to ensure we flush these kinds of issues
into the open and ensure the emulator is portable.

Eric


From stepan at openbios.org  Tue Jun  8 05:26:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Jun  8 05:26:01 2004
Subject: [PROPOSAL] extended payload handling
Message-ID: <20040608104930.GA6799@openbios.org>

There has been a similar proposal on this list a while ago, but nothing 
happened so far, so I want to put this pack to discussion.

Objectives
----------

1.) 
LinuxBIOS is kind of hard to set up for project newbies, since it 
does not only require manually tweaking the configuration files for
basically every situation, but also necessarily needs an external
payload to do anything useful.
LinuxBIOS currently sets a high barrier due to the modular concepts it
uses.

 - LinuxBIOS itself is sometimes very sensitive to the build
   environment. See requirement for setting LANG for example.

 - For a project outsider it is hard to determine the best payload
   solution for a specific purpose. There is basically no information
   except the mailing list archives.

 - Config files have to be tweaked to explicitly suit the user's
   directory structure. There is no proposal, nothing that works out of
   the box. One just _has to_ edit the config files.

 - LinuxBIOS requires the user to specify a size for the payload instead
   of determining the required size and doing the needed calculations
   itself. This is very hand-crufted and can be pretty mind wasting.
 
2.) 
LinuxBIOS can currently execute one payload. For greater flexibility and
isolated development cycles of the firmware related code parts/projects
LinuxBIOS should allow payload chains, ie. executing multiple payloads
one after the other.

LinuxBIOS wants to keep up it's modularity, letting each module do it's
job. This possibility of not doing more than one task should be passed 
on to the payloads. 


Solution
--------

Feature plugins like "testbios" should not be merged into LinuxBIOS'
core code. Instead they should be implemented as a payload. Since we
want to load an operating system later on, we also need to be able to
load more than one payload. Implementing ELFLOAD in each such plugin is
inadequate. Instead LinuxBIOS should execute multiple payloads the same
way it executes multiple "drivers" now.

 * LinuxBIOS therefore needs a way to automatically determine payload
   sizes when building the image and later when executing payloads.
   Hardcoding the size values in the config files is inadequate and will
   lead to unnecessary overhead

 * LinuxBIOS at runtime needs to go through the list of available
   payloads, either by having a linked list of payload start points
   or by scanning the flash rom.

 * LinuxBIOS should, to be consequent, remove all streaming code except
   CONFIG_ROM_STREAM

 * Payloads should have the possibility to add their own enhancements to 
   the LinuxBIOS table.

 * A least one payload should be "default payload" with the possibility 
   to build this automatically and link it into the image. 

   This is why I checked the "util/extensions" directory into v2 during
   the last discussion. It should hold possible choices to payloads that
   can automatically be built and included. Potentially one could add
   more payloads by symlinking their source tree to this directory to make
   it available to LinuxBIOS without major reconfiguration.
   People feel a lot safer with creating a symlink than with changing
   config files they do not fully understand.

   Since these can later be executed in row by elfboot, the minimum
   overhead design of LinuxBIOS itself will not be hurt.

   At this point I want to put an idea to discussion: If we are going
   more and more modular and some of us think the current tree is too 
   bloated: Why do we not modularize code like pci resource allocation
   into a payload as well. My favorite bootloader may already do this 
   and I can't stand this bloat everywhere, you know ;) Even though this
   may sound funny, I am serious about this issue. I do not see why 
   allocating PCI resources should really be part of the lowlevel code,
   except for the fact that the NEXT payload in row, potentially Linux
   itself is too stupid to do that. Bummer.

 * LinuxBIOS configuration should have an easier mechanism for choosing 
   payloads from the "default" directory, allowing them to be built
   automatically. Right now I am doing:

     cd filo-0.4.2
     linux32 make CC="gcc -m32" LD="ld -melf_i386"
     cd ..
     freebios2/targets/buildtarget amd/solo $PWD/freebios2
     cd build-solo
     make
     cd ..
     cp build-solo/solo.rom .

   My target Config.lb comes with these constructs:
     target  ../../../../build-solo
     payload ../../filo-0.4.2/filo.elf

   So I build everything completely out of the freebios2 tree, because
   building in-tree sucks. The only thing left is to get filo and the
   other payloads to build out-of-tree as well.
   
Comments?
Discussion?
Assassination attempts?

     Stefan






From gwatson at lanl.gov  Tue Jun  8 07:58:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Tue Jun  8 07:58:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608104930.GA6799@openbios.org>
References: <20040608104930.GA6799@openbios.org>
Message-ID: <D5C5007A-B94E-11D8-B023-000393A47A5C@lanl.gov>

Stefan,

I think this is a reasonable idea, particularly your suggestion of 
making linuxbios more modular. One of my main beefs with the payload 
strategy is that each payload has to provide it's own set of, 
potentially buggy, driver code. If we have 5 payloads then we have 5 
sets of drivers that all do the same thing slightly differently. If the 
drivers were modular enough so that a payload could call them directly, 
then this would go a long way to addressing these concerns.

Regards,

Greg

On Jun 8, 2004, at 4:49 AM, Stefan Reinauer wrote:

> There has been a similar proposal on this list a while ago, but nothing
> happened so far, so I want to put this pack to discussion.
>
> Objectives
> ----------
>
> 1.)
> LinuxBIOS is kind of hard to set up for project newbies, since it
> does not only require manually tweaking the configuration files for
> basically every situation, but also necessarily needs an external
> payload to do anything useful.
> LinuxBIOS currently sets a high barrier due to the modular concepts it
> uses.
>
>  - LinuxBIOS itself is sometimes very sensitive to the build
>    environment. See requirement for setting LANG for example.
>
>  - For a project outsider it is hard to determine the best payload
>    solution for a specific purpose. There is basically no information
>    except the mailing list archives.
>
>  - Config files have to be tweaked to explicitly suit the user's
>    directory structure. There is no proposal, nothing that works out of
>    the box. One just _has to_ edit the config files.
>
>  - LinuxBIOS requires the user to specify a size for the payload 
> instead
>    of determining the required size and doing the needed calculations
>    itself. This is very hand-crufted and can be pretty mind wasting.
>
> 2.)
> LinuxBIOS can currently execute one payload. For greater flexibility 
> and
> isolated development cycles of the firmware related code parts/projects
> LinuxBIOS should allow payload chains, ie. executing multiple payloads
> one after the other.
>
> LinuxBIOS wants to keep up it's modularity, letting each module do it's
> job. This possibility of not doing more than one task should be passed
> on to the payloads.
>
>
> Solution
> --------
>
> Feature plugins like "testbios" should not be merged into LinuxBIOS'
> core code. Instead they should be implemented as a payload. Since we
> want to load an operating system later on, we also need to be able to
> load more than one payload. Implementing ELFLOAD in each such plugin is
> inadequate. Instead LinuxBIOS should execute multiple payloads the same
> way it executes multiple "drivers" now.
>
>  * LinuxBIOS therefore needs a way to automatically determine payload
>    sizes when building the image and later when executing payloads.
>    Hardcoding the size values in the config files is inadequate and 
> will
>    lead to unnecessary overhead
>
>  * LinuxBIOS at runtime needs to go through the list of available
>    payloads, either by having a linked list of payload start points
>    or by scanning the flash rom.
>
>  * LinuxBIOS should, to be consequent, remove all streaming code except
>    CONFIG_ROM_STREAM
>
>  * Payloads should have the possibility to add their own enhancements 
> to
>    the LinuxBIOS table.
>
>  * A least one payload should be "default payload" with the possibility
>    to build this automatically and link it into the image.
>
>    This is why I checked the "util/extensions" directory into v2 during
>    the last discussion. It should hold possible choices to payloads 
> that
>    can automatically be built and included. Potentially one could add
>    more payloads by symlinking their source tree to this directory to 
> make
>    it available to LinuxBIOS without major reconfiguration.
>    People feel a lot safer with creating a symlink than with changing
>    config files they do not fully understand.
>
>    Since these can later be executed in row by elfboot, the minimum
>    overhead design of LinuxBIOS itself will not be hurt.
>
>    At this point I want to put an idea to discussion: If we are going
>    more and more modular and some of us think the current tree is too
>    bloated: Why do we not modularize code like pci resource allocation
>    into a payload as well. My favorite bootloader may already do this
>    and I can't stand this bloat everywhere, you know ;) Even though 
> this
>    may sound funny, I am serious about this issue. I do not see why
>    allocating PCI resources should really be part of the lowlevel code,
>    except for the fact that the NEXT payload in row, potentially Linux
>    itself is too stupid to do that. Bummer.
>
>  * LinuxBIOS configuration should have an easier mechanism for choosing
>    payloads from the "default" directory, allowing them to be built
>    automatically. Right now I am doing:
>
>      cd filo-0.4.2
>      linux32 make CC="gcc -m32" LD="ld -melf_i386"
>      cd ..
>      freebios2/targets/buildtarget amd/solo $PWD/freebios2
>      cd build-solo
>      make
>      cd ..
>      cp build-solo/solo.rom .
>
>    My target Config.lb comes with these constructs:
>      target  ../../../../build-solo
>      payload ../../filo-0.4.2/filo.elf
>
>    So I build everything completely out of the freebios2 tree, because
>    building in-tree sucks. The only thing left is to get filo and the
>    other payloads to build out-of-tree as well.
>
> Comments?
> Discussion?
> Assassination attempts?
>
>      Stefan
>
>
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From mdeschamps at mangrove-systems.com  Tue Jun  8 08:32:00 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Tue Jun  8 08:32:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608104930.GA6799@openbios.org>
References: <20040608104930.GA6799@openbios.org>
Message-ID: <1086702128.1197.17.camel@Calliphara>

Hello,

I found it clear but :)

> 2.) 
> LinuxBIOS can currently execute one payload. For greater flexibility and
> isolated development cycles of the firmware related code parts/projects
> LinuxBIOS should allow payload chains, ie. executing multiple payloads
> one after the other.
> 
Ok but How are you calling this if it's not
a bootloader chaining or payload chain ?

LinuxBIOS - (ETHERBOOT - IDE PATCH) - LINUX

because this were made ...
More, 
I've reported that is was and that this works. I've also
reported some boot chains examples to illustrate a section :

 LB - ETHERBOOT - ADLO - LILO - LINUX


What have i missed ?



mathieu
> LinuxBIOS wants to keep up it's modularity, letting each module do it's
> job. This possibility of not doing more than one task should be passed 
> on to the payloads. 
> 




From stepan at openbios.org  Tue Jun  8 08:35:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Jun  8 08:35:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <D5C5007A-B94E-11D8-B023-000393A47A5C@lanl.gov>
References: <20040608104930.GA6799@openbios.org> <D5C5007A-B94E-11D8-B023-000393A47A5C@lanl.gov>
Message-ID: <20040608135906.GB9691@openbios.org>

* Greg Watson <gwatson at lanl.gov> [040608 15:22]:
> I think this is a reasonable idea, particularly your suggestion of 
> making linuxbios more modular. One of my main beefs with the payload 
> strategy is that each payload has to provide it's own set of, 
> potentially buggy, driver code. If we have 5 payloads then we have 5 
> sets of drivers that all do the same thing slightly differently. If the 
> drivers were modular enough so that a payload could call them directly, 
> then this would go a long way to addressing these concerns.

As far as I can tell the only drivers involved would be output drivers,
ie. video output and serial output. There the extensible LinuxBIOS table
could come into play. The video driver could store a pointer to the
framebuffer, the resolution and maybe even a font, to save duplicates.
Serial is only a kilobyte or so of a driver i think.

Have I forgotten something?


Stefan



From stepan at openbios.org  Tue Jun  8 08:41:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Jun  8 08:41:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <1086702128.1197.17.camel@Calliphara>
References: <20040608104930.GA6799@openbios.org> <1086702128.1197.17.camel@Calliphara>
Message-ID: <20040608140440.GA10447@openbios.org>

* Mathieu Deschamps <mdeschamps at mangrove-systems.com> [040608 15:42]:
> > LinuxBIOS can currently execute one payload. For greater flexibility and
> > isolated development cycles of the firmware related code parts/projects
> > LinuxBIOS should allow payload chains, ie. executing multiple payloads
> > one after the other.
> > 
> Ok but How are you calling this if it's not
> a bootloader chaining or payload chain ?
> 
> LinuxBIOS - (ETHERBOOT - IDE PATCH) - LINUX
 
I don't exactly get the problem. Etherboot would probably be the end of
the in-rom payload chain, since it does not return from execution but
pass control to Linux, which is not stored in ROM in the above scenario.

> I've reported that is was and that this works. I've also
> reported some boot chains examples to illustrate a section :
> 
>  LB - ETHERBOOT - ADLO - LILO - LINUX
 
Again, at this point Etherboot would be the end of the in-rom payload
chain. But possibly ADLO could be moved to ROM before Etherboot is
started.

Stefan



From rsmith at bitworks.com  Tue Jun  8 09:29:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jun  8 09:29:00 2004
Subject: testbios and the system timer
In-Reply-To: <m37juiscbk.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0406031500110.2716-100000@maxroach.lanl.gov> <m37juiscbk.fsf@maxwell.lnxi.com>
Message-ID: <40C5D2C3.2070103@bitworks.com>

Eric W. Biederman wrote:

>>You can in the emulator redirect I/O port access to a function. Write the 
>>code to handle read/write on those ports and use the emulate_counter to 
>>drive the clock value.
> 
> Let me ask this quick question.  Does the emulator restrict port I/O to
> just the resources on a particular VGA device?   If not that is something
> we need to do to implement to ensure we flush these kinds of issues
> into the open and ensure the emulator is portable.

No. It allows full access to all IO ports. Otherwise it would have never 
been able to get to the system timer.

So not only will it have to emulate x86 instructions it will have to 
emulate some of the generic x86 hardware setup.







From stepan at openbios.org  Tue Jun  8 09:37:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Jun  8 09:37:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <1086704404.1197.35.camel@Calliphara>
References: <20040608104930.GA6799@openbios.org> <1086702128.1197.17.camel@Calliphara> <20040608140440.GA10447@openbios.org> <1086704404.1197.35.camel@Calliphara>
Message-ID: <20040608150053.GB10945@openbios.org>

* Mathieu Deschamps <mdeschamps at mangrove-systems.com> [040608 16:20]:
> > I don't exactly get the problem. Etherboot would probably be the end of
> > the in-rom payload chain, since it does not return from execution but
> > pass control to Linux, which is not stored in ROM in the above scenario.
> 	Ok we agree, I try to be clearer, i redo:
> 
> you said in above  LinuxBIOS should allow payload chains, ie. executing
> multiple payloads one after the other.
 
> Isn't it already was it can with the chain we're describing in here ?
> Or are you considering that it is not since it passes control up to a 
> certain constant point ? 

Not really. It works because the payload you use is a bootloader. This
is a very hard restriction, as PCI resource allocation, or testbios are
no bootloaders, and thus do not need and should really not have an ELF
loader like LinuxBIOS itself has.

Bootloaders are always the end of the chain.

> > But possibly ADLO could be moved to ROM before Etherboot is
> > started.
> 
> 	Really ? but if ADLO, as you underlined it, is out-rom is it 
> for a good reason  : a lack of inrom space. So logically it must be
> filled to the top and got no bytes left

The space left depends really very much on the flash device you use. 
Optimistically, LinuxBIOS itself, without PCI resource allocation 
should only eat up around 32k with some fiddling. Compared to 256 or
512kbyte flash devices there is plenty of room for additions. If not
ADLO then something else.

I am not arguing that ADLO should go to rom or should not. What I am
trying to say is, that 

* if we decide, that having FILO inside of LinuxBIOS is a break in 
  design, we should be consequent and split everything but DRAM init 
  and ELF loader out, including

* if there is enough space in rom, any payload should be able to receive
  and give back control. The payload view of things is nice, but either
  do it right or have a way around it if needed.

* payloads should be able to leave information in the LinuxBIOS table,
  so that following payloads don't have to do the same work over and
  over.

I see a certain point in not having function callbacks, even if I think
it's a dubious one in a full open source environment, but I am not going
to argue about this. It's not really needed, EOD.

> How could we move it to ROM in such condition ? Oh I catch it :
> LinuxBios does return from execution nor Etherboot, that IS space
> on to write is it what you mean ?

My proposal does not care for anything after code is loaded from IDE. It
should not, since, as Eric pointed out, this is bloat. And it is, since
either one loads a kernel from a raw device, which is not solid enough
for productive use, or one has to include filesystems and whatever. This
code belongs out of the LinuxBIOS core, as does PCI resource allocation.

Stefan





From mdeschamps at mangrove-systems.com  Tue Jun  8 10:43:00 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Tue Jun  8 10:43:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608150053.GB10945@openbios.org>
References: <20040608104930.GA6799@openbios.org>
	 <1086702128.1197.17.camel@Calliphara> <20040608140440.GA10447@openbios.org>
	 <1086704404.1197.35.camel@Calliphara> <20040608150053.GB10945@openbios.org>
Message-ID: <1086709947.1197.82.camel@Calliphara>

Le mar 08/06/2004 ? 17:00, Stefan Reinauer a ?crit :
> * Mathieu Deschamps <mdeschamps at mangrove-systems.com> [040608 16:20]:
> > > I don't exactly get the problem. Etherboot would probably be the end of
> > > the in-rom payload chain, since it does not return from execution but
> > > pass control to Linux, which is not stored in ROM in the above scenario.
> > 	Ok we agree, I try to be clearer, i redo:
> > 
> > you said in above  LinuxBIOS should allow payload chains, ie. executing
> > multiple payloads one after the other.
>  
> > Isn't it already was it can with the chain we're describing in here ?
> > Or are you considering that it is not since it passes control up to a 
> > certain constant point ? 
> 
> Not really. It works because the payload you use is a bootloader. This
> is a very hard restriction, as PCI resource allocation, or testbios are
> no bootloaders, and thus do not need and should really not have an ELF
> loader like LinuxBIOS itself has.
 oh right... same when you build a the hello world example to test
LinuxBios boot time : it no a boot loader. It is a ... I realized
this difference i've reported it as bootloaders and booters. But I don't
know if it's a good name... what do you think ?

> 
> Bootloaders are always the end of the chain.
> 
> > > But possibly ADLO could be moved to ROM before Etherboot is
> > > started.
> > 
> > 	Really ? but if ADLO, as you underlined it, is out-rom is it 
> > for a good reason  : a lack of inrom space. So logically it must be
> > filled to the top and got no bytes left
> 
> The space left depends really very much on the flash device you use. 
> Optimistically, LinuxBIOS itself, without PCI resource allocation 
> should only eat up around 32k with some fiddling. Compared to 256 or
> 512kbyte flash devices there is plenty of room for additions. If not
> ADLO then something else.
	yes. but no to forget the VGABIOS that's 64k also or rather 50k
> 
> I am not arguing that ADLO should go to rom or should not. What I am
> trying to say is, that 
> 
> * if we decide, that having FILO inside of LinuxBIOS is a break in 
>   design, we should be consequent and split everything but DRAM init 
>   and ELF loader out, including
>
	So if i'am not mistaking, this would leave a LinuxBios core very thin
while 'modules' adding fonctions, facilities and commodities would 
make it thicker...  an architecture that has proven it efficiency...


> * if there is enough space in rom, any payload should be able to receive
>   and give back control. The payload view of things is nice, but either
>   do it right or have a way around it if needed.
	

> 
> * payloads should be able to leave information in the LinuxBIOS table,
>   so that following payloads don't have to do the same work over and
>   over.
	yes . if it's the role a the LinuxBIOS table...hum sure it is.

> 
> I see a certain point in not having function callbacks, even if I think
> it's a dubious one in a full open source environment, but I am not going
> to argue about this. It's not really needed, EOD.

	for now, i also can't see the use of such a possibility... 

> 
> > How could we move it to ROM in such condition ? Oh I catch it :
> > LinuxBios does return from execution nor Etherboot, that IS space
> > on to write is it what you mean ?

sorry I mean : " Oh I catch it : LinuxBios does NOT return from
execution nor Etherboot,"

> 
> My proposal does not care for anything after code is loaded from IDE. It
> should not, since, as Eric pointed out, this is bloat. And it is, since
> either one loads a kernel from a raw device, which is not solid enough
> for productive use, or one has to include filesystems and whatever. This
> code belongs out of the LinuxBIOS core, as does PCI resource allocation.
> 
	hum.. it is before so ? that makes me wonder more... 
	

> Stefan
> 
> 
> 
> 


From yhlu at tyan.com  Tue Jun  8 11:04:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Tue Jun  8 11:04:00 2004
Subject: Bootloaders and LinuxBIOS
In-Reply-To: <m3aczescg0.fsf@maxwell.lnxi.com>
Message-ID: <200406081503.i58F3LK09434@nwn.definitive.org>

Eric,

Maybe someone add some build instruction for Etherboot for LinuxBIOS would
solve the payload building problem.

Regards

YH

-----????-----
???: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] ?? Eric W. Biederman
????: 2004?6?8? 1:04
???: LinuxBIOS
??: Bootloaders and LinuxBIOS


As the freebiosv1 tree grew and developed we had a lot of disagreement
about bootloaders.  What should linuxbios do in condition X.  It was
clear that there was no way that in the linuxbios tree itself we could
satisfy all of the developers.  You can see remnants of this in
the freebios1 tree in src/lib/linuxbiosmain.c

Coming into this confusion I proposed a truce, that would give us
greater flexibility and allow a single LinuxBIOS source tree for
everyone.  That was to have a really stupid bootloader in LinuxBIOS
that was smart enough to load a real bootloader.  That is where
elfboot comes from.  

To prove my concept I ported etherboot to run under LinuxBIOS as that 
was the only bootloader I could find that actually had real
hardware drivers.  In this scenario the fact that etherboot 
well with my style of booting was no longer a threat because people
were free to use their own code.  Etherboot was also choosen because
of it's strong core team of maintainers and you can all see the
results of that decision today.

Out of this concept we had additional bootloaders written or ported:
ADLO, FILO, OpenBIOS, baremetal, linux kernel, etc.

So from everything I can see this concept has been a success.  I have
seen no complaints.  We don't have more because it is not the easiest
thing to write standalone code to the bare metal.  But this is
something time and starting to catch up on our LinuxBIOS ports 
has been overcoming.

One of the large reasons I was a great proponet of the simple/stupid
bootloader in LinuxBIOS to load a real one is that draws a line around
what functionality LinuxBIOS shall provide.  Anything over that line
is code bloat.

Several months ago as I was involved in other things Yhlu noted that
FILO had been added to LinuxBIOS without a word.   The way he described
it I thought it was as a driver to elfboot.  I expressed my concerns
at that time, but I really have not had time to do anything.  And if
it was a driver it was seriously pushing the line I had drawn against
feature bloat, and really coming close to starting another bootloader
feature war but it was perhaps ok.  

Later I finally had time to start syncing my code with the main
LinuxBIOS and I saw what that code actually was, and I was shocked.
This code had crossed the line, it had broken the truce, it was
feature bloat.  Not to talk about how useless a disk based bootloader
is without a configuration file.  From that moment on I have not
seen a reasonable solution besides deleting that code from LinuxBIOS.

Last time we had this conversation 2 problems were mentioned that
this code solves.
1) People have a hard time setting up an external payload.
2) There are not any bootloaders for the ppc that run under LinuxBIOS.

To the problem of setting up an external payload I propose we can
include FILO into the tree like baremetal and simply make it the
default payload.  If you don't change anything it will get built.
That solves the problem without breaking the design.

To the problem of there not being any bootloaders for the ppc that
run under LinuxBIOS.  I respond that one of the x86 based bootloaders
would not be hard to port, or better yet we can just use a kernel
with kexec built in.  Although I would strongly be with the amount of
embedded activity that happens with the ppc if none of the native
ppc bootloaders could not be easily adopted.

In addition I have seen noone except the guys at LANL who are even
interested in the built in FILO. 

I have a few additional technical objections as well.  Just like when
someone tried to include etherboot the code in the LinuxBIOS tree has
languished, and is much less capable a solution.

Having to support bootloaders places an additional burden upon the
LinuxBIOS code that must be considered when the code must be
refactored or cleaned up.  And we have not even succeed in a
sufficiently clean and stable API that we are willing to freeze the
core interfaces and make stable releases from the LinuxBIOS tree, only
adding new ports or extensions to the existing API that cannot
possibly break old ports.

So does someone have a reason to keep the built-in FILO besides being
lazy slobs who want something-for-nothing and are not willing to put
in the work to make production quality solutions?

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



From gwatson at lanl.gov  Tue Jun  8 11:09:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Tue Jun  8 11:09:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608135906.GB9691@openbios.org>
References: <20040608104930.GA6799@openbios.org> <D5C5007A-B94E-11D8-B023-000393A47A5C@lanl.gov> <20040608135906.GB9691@openbios.org>
Message-ID: <83626981-B969-11D8-B023-000393A47A5C@lanl.gov>

On Jun 8, 2004, at 7:59 AM, Stefan Reinauer wrote:

> * Greg Watson <gwatson at lanl.gov> [040608 15:22]:
>> I think this is a reasonable idea, particularly your suggestion of
>> making linuxbios more modular. One of my main beefs with the payload
>> strategy is that each payload has to provide it's own set of,
>> potentially buggy, driver code. If we have 5 payloads then we have 5
>> sets of drivers that all do the same thing slightly differently. If 
>> the
>> drivers were modular enough so that a payload could call them 
>> directly,
>> then this would go a long way to addressing these concerns.
>
> As far as I can tell the only drivers involved would be output drivers,
> ie. video output and serial output. There the extensible LinuxBIOS 
> table
> could come into play. The video driver could store a pointer to the
> framebuffer, the resolution and maybe even a font, to save duplicates.
> Serial is only a kilobyte or so of a driver i think.
>
> Have I forgotten something?
>

PCI device code and resource information should be available for 
payloads to use. A payload should not have to re-probe for devices on 
the PCI bus.

Greg



From ebiederman at lnxi.com  Tue Jun  8 11:33:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  8 11:33:01 2004
Subject: testbios and the system timer
In-Reply-To: <40C5D2C3.2070103@bitworks.com>
References: <Pine.LNX.4.44.0406031500110.2716-100000@maxroach.lanl.gov>
	<m37juiscbk.fsf@maxwell.lnxi.com> <40C5D2C3.2070103@bitworks.com>
Message-ID: <m3u0xmoujp.fsf@maxwell.lnxi.com>

Richard Smith <rsmith at bitworks.com> writes:

> Eric W. Biederman wrote:
> 
> >> You can in the emulator redirect I/O port access to a function. Write the
> >> code to handle read/write on those ports and use the emulate_counter to drive
> 
> >> the clock value.
> > Let me ask this quick question.  Does the emulator restrict port I/O to
> > just the resources on a particular VGA device?   If not that is something
> > we need to do to implement to ensure we flush these kinds of issues
> > into the open and ensure the emulator is portable.
> 
> No. It allows full access to all IO ports. Otherwise it would have never been
> able to get to the system timer.

I was afraid of that.

> So not only will it have to emulate x86 instructions it will have to emulate
> some of the generic x86 hardware setup.

Exactly.  But in this case emulation is more predictable than making
certain your hardware is setup in a legacy conforming mode.


Eric


From frannk_m1 at yahoo.com  Tue Jun  8 11:36:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Jun  8 11:36:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <83626981-B969-11D8-B023-000393A47A5C@lanl.gov>
Message-ID: <20040608170003.86804.qmail@web13808.mail.yahoo.com>

Finally, someone has recognized the lack of support with
LinuxBios. About 6 months ago we decide to do an x86 based
project but abandoned it because of the lack of support for this
bootloader. The code is disorganized and in disarray as far as
I'm concerend. We were on a tight schedule and didn't have the
luxury of spending a lot of time trying to understand the code
layout. This was due in part to the lack of badly needed
documentation and code organization. We decided to base our
design on a powerpc and go with u-boot.
Hopefully by the time we decide to do cost reduced version,
LinuxBios will be usable for the masses and not just for an
elite group of people who assume everybody else uses the x86 for
everyday use.:-(

--- Greg Watson <gwatson at lanl.gov> wrote:
> 
> On Jun 8, 2004, at 7:59 AM, Stefan Reinauer wrote:
> 
> > * Greg Watson <gwatson at lanl.gov> [040608 15:22]:
> >> I think this is a reasonable idea, particularly your
> suggestion of
> >> making linuxbios more modular. One of my main beefs with
> the payload
> >> strategy is that each payload has to provide it's own set
> of,
> >> potentially buggy, driver code. If we have 5 payloads then
> we have 5
> >> sets of drivers that all do the same thing slightly
> differently. If 
> >> the
> >> drivers were modular enough so that a payload could call
> them 
> >> directly,
> >> then this would go a long way to addressing these concerns.
> >
> > As far as I can tell the only drivers involved would be
> output drivers,
> > ie. video output and serial output. There the extensible
> LinuxBIOS 
> > table
> > could come into play. The video driver could store a pointer
> to the
> > framebuffer, the resolution and maybe even a font, to save
> duplicates.
> > Serial is only a kilobyte or so of a driver i think.
> >
> > Have I forgotten something?
> >
> 
> PCI device code and resource information should be available
> for 
> payloads to use. A payload should not have to re-probe for
> devices on 
> the PCI bus.
> 
> Greg
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 


From dwh at lanl.gov  Tue Jun  8 11:46:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Tue Jun  8 11:46:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608170003.86804.qmail@web13808.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0406081108590.15681-100000@ccs-mail.lanl.gov>

IIRC, that's what Greg's addition of FILO for PPC was all about.

On Tue, 8 Jun 2004, Frank wrote:

> Finally, someone has recognized the lack of support with
> LinuxBios. About 6 months ago we decide to do an x86 based
> project but abandoned it because of the lack of support for this
> bootloader. The code is disorganized and in disarray as far as
> I'm concerend. We were on a tight schedule and didn't have the
> luxury of spending a lot of time trying to understand the code
> layout. This was due in part to the lack of badly needed
> documentation and code organization. We decided to base our
> design on a powerpc and go with u-boot.
> Hopefully by the time we decide to do cost reduced version,
> LinuxBios will be usable for the masses and not just for an
> elite group of people who assume everybody else uses the x86 for
> everyday use.:-(
> 
> --- Greg Watson <gwatson at lanl.gov> wrote:
> > 
> > On Jun 8, 2004, at 7:59 AM, Stefan Reinauer wrote:
> > 
> > > * Greg Watson <gwatson at lanl.gov> [040608 15:22]:
> > >> I think this is a reasonable idea, particularly your
> > suggestion of
> > >> making linuxbios more modular. One of my main beefs with
> > the payload
> > >> strategy is that each payload has to provide it's own set
> > of,
> > >> potentially buggy, driver code. If we have 5 payloads then
> > we have 5
> > >> sets of drivers that all do the same thing slightly
> > differently. If 
> > >> the
> > >> drivers were modular enough so that a payload could call
> > them 
> > >> directly,
> > >> then this would go a long way to addressing these concerns.
> > >
> > > As far as I can tell the only drivers involved would be
> > output drivers,
> > > ie. video output and serial output. There the extensible
> > LinuxBIOS 
> > > table
> > > could come into play. The video driver could store a pointer
> > to the
> > > framebuffer, the resolution and maybe even a font, to save
> > duplicates.
> > > Serial is only a kilobyte or so of a driver i think.
> > >
> > > Have I forgotten something?
> > >
> > 
> > PCI device code and resource information should be available
> > for 
> > payloads to use. A payload should not have to re-probe for
> > devices on 
> > the PCI bus.
> > 
> > Greg
> > 
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> Friends.  Fun.  Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/ 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rsmith at bitworks.com  Tue Jun  8 11:58:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jun  8 11:58:00 2004
Subject: testbios and the system timer
In-Reply-To: <m3u0xmoujp.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0406031500110.2716-100000@maxroach.lanl.gov>	<m37juiscbk.fsf@maxwell.lnxi.com> <40C5D2C3.2070103@bitworks.com> <m3u0xmoujp.fsf@maxwell.lnxi.com>
Message-ID: <40C5F5C1.5010708@bitworks.com>

Eric W. Biederman wrote:

>>No. It allows full access to all IO ports. Otherwise it would have never been
>>able to get to the system timer.
>  
> I was afraid of that.
> 
>>So not only will it have to emulate x86 instructions it will have to emulate
>>some of the generic x86 hardware setup.
> 
> Exactly.  But in this case emulation is more predictable than making
> certain your hardware is setup in a legacy conforming mode.

Hey, I'm totaly in agreement with you.  No convincing necessary. *grin*

It probally dosen't have to go all the way emulating a legacy PC 
enviroment but it looks like a few things will have to be dealt with. 
Restricting IO to legacy VGA registers and the allocated card IO 
locations is a good idea.  That should flush out any other issues of 
this sort.  There probally aren't that many though.

In other news I recompiled my VBIOS with the delay routine just doing a 
'ret' rathen then all that crazy timer stuff and testbios now completes 
on my target rather than going into the infinite loop it did before.

Still don't get a signon message but it does do pretty much the same 
thing that ADLO+vbios does.  H & V sync with the timeings correct for 
text mode but only a black screen. So thats some progress.  Interesting 
to note that running the no-delay vbios on my desktop PCI works the same 
as with the delays.



From YhLu at tyan.com  Tue Jun  8 11:59:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun  8 11:59:00 2004
Subject: =?GB2312?B?tPC4tDogW1BST1BPU0FMXSBleHRlbmRlZCBwYXlsb2FkIGhhbmRs?=
	=?GB2312?B?aW5n?=
Message-ID: <3174569B9743D511922F00A0C9431423055353C4@TYANWEB>

Maybe someone can port the Etherboot to powerpc. And it should be some easy.

Regards

YH

-----????-----
???: Frank [mailto:frannk_m1 at yahoo.com] 
????: 2004?6?8? 10:00
???: Greg Watson; Stefan Reinauer
??: LinuxBIOS
??: Re: [PROPOSAL] extended payload handling

Finally, someone has recognized the lack of support with
LinuxBios. About 6 months ago we decide to do an x86 based
project but abandoned it because of the lack of support for this
bootloader. The code is disorganized and in disarray as far as
I'm concerend. We were on a tight schedule and didn't have the
luxury of spending a lot of time trying to understand the code
layout. This was due in part to the lack of badly needed
documentation and code organization. We decided to base our
design on a powerpc and go with u-boot.
Hopefully by the time we decide to do cost reduced version,
LinuxBios will be usable for the masses and not just for an
elite group of people who assume everybody else uses the x86 for
everyday use.:-(

--- Greg Watson <gwatson at lanl.gov> wrote:
> 
> On Jun 8, 2004, at 7:59 AM, Stefan Reinauer wrote:
> 
> > * Greg Watson <gwatson at lanl.gov> [040608 15:22]:
> >> I think this is a reasonable idea, particularly your
> suggestion of
> >> making linuxbios more modular. One of my main beefs with
> the payload
> >> strategy is that each payload has to provide it's own set
> of,
> >> potentially buggy, driver code. If we have 5 payloads then
> we have 5
> >> sets of drivers that all do the same thing slightly
> differently. If 
> >> the
> >> drivers were modular enough so that a payload could call
> them 
> >> directly,
> >> then this would go a long way to addressing these concerns.
> >
> > As far as I can tell the only drivers involved would be
> output drivers,
> > ie. video output and serial output. There the extensible
> LinuxBIOS 
> > table
> > could come into play. The video driver could store a pointer
> to the
> > framebuffer, the resolution and maybe even a font, to save
> duplicates.
> > Serial is only a kilobyte or so of a driver i think.
> >
> > Have I forgotten something?
> >
> 
> PCI device code and resource information should be available
> for 
> payloads to use. A payload should not have to re-probe for
> devices on 
> the PCI bus.
> 
> Greg
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From frannk_m1 at yahoo.com  Tue Jun  8 12:15:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Jun  8 12:15:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <Pine.LNX.4.44.0406081108590.15681-100000@ccs-mail.lanl.gov>
Message-ID: <20040608173916.88092.qmail@web13804.mail.yahoo.com>

You missed the point!
If I wanted a bootloader for the PPC I would use u-boot and
that's what I did. But if I wanted a bootloader for the X86
platform I would have liked to use LinuxBios. U-BOOT is
synonymous with the PPC. LinuxBios should be synonymous with the
X86 just like PMON is with the MIPS platform. Take a long look
at u-boot and you'll find support for just about every PPC  and
the number of drivers are abundant. I can port u-boot to a new
PPC based board in about 3 days tops. There is no way I can port
LinuxBios to a new X86 based board in that amount of time. You
should focus your efforts on improving LinuxBios for the X86 and
not waste time trying to make it work for the PPC. If I wanted a
bootloader I would use u-boot not LinuxBios. I have heard of
other people abandoning LinuxBios and going to u-boot in that
past, just like I did...
--- "Hendricks David W." <dwh at lanl.gov> wrote:
> IIRC, that's what Greg's addition of FILO for PPC was all
> about.
> 
> On Tue, 8 Jun 2004, Frank wrote:
> 
> > Finally, someone has recognized the lack of support with
> > LinuxBios. About 6 months ago we decide to do an x86 based
> > project but abandoned it because of the lack of support for
> this
> > bootloader. The code is disorganized and in disarray as far
> as
> > I'm concerend. We were on a tight schedule and didn't have
> the
> > luxury of spending a lot of time trying to understand the
> code
> > layout. This was due in part to the lack of badly needed
> > documentation and code organization. We decided to base our
> > design on a powerpc and go with u-boot.
> > Hopefully by the time we decide to do cost reduced version,
> > LinuxBios will be usable for the masses and not just for an
> > elite group of people who assume everybody else uses the x86
> for
> > everyday use.:-(
> > 
> > --- Greg Watson <gwatson at lanl.gov> wrote:
> > > 
> > > On Jun 8, 2004, at 7:59 AM, Stefan Reinauer wrote:
> > > 
> > > > * Greg Watson <gwatson at lanl.gov> [040608 15:22]:
> > > >> I think this is a reasonable idea, particularly your
> > > suggestion of
> > > >> making linuxbios more modular. One of my main beefs
> with
> > > the payload
> > > >> strategy is that each payload has to provide it's own
> set
> > > of,
> > > >> potentially buggy, driver code. If we have 5 payloads
> then
> > > we have 5
> > > >> sets of drivers that all do the same thing slightly
> > > differently. If 
> > > >> the
> > > >> drivers were modular enough so that a payload could
> call
> > > them 
> > > >> directly,
> > > >> then this would go a long way to addressing these
> concerns.
> > > >
> > > > As far as I can tell the only drivers involved would be
> > > output drivers,
> > > > ie. video output and serial output. There the extensible
> > > LinuxBIOS 
> > > > table
> > > > could come into play. The video driver could store a
> pointer
> > > to the
> > > > framebuffer, the resolution and maybe even a font, to
> save
> > > duplicates.
> > > > Serial is only a kilobyte or so of a driver i think.
> > > >
> > > > Have I forgotten something?
> > > >
> > > 
> > > PCI device code and resource information should be
> available
> > > for 
> > > payloads to use. A payload should not have to re-probe for
> > > devices on 
> > > the PCI bus.
> > > 
> > > Greg
> > > 
> > > _______________________________________________
> > > Linuxbios mailing list
> > > Linuxbios at clustermatic.org
> > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > 
> > 
> > 	
> > 		
> > __________________________________
> > Do you Yahoo!?
> > Friends.  Fun.  Try the all-new Yahoo! Messenger.
> > http://messenger.yahoo.com/ 
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 


From rsmith at bitworks.com  Tue Jun  8 12:21:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jun  8 12:21:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608170003.86804.qmail@web13808.mail.yahoo.com>
References: <20040608170003.86804.qmail@web13808.mail.yahoo.com>
Message-ID: <40C5FAFE.8070301@bitworks.com>

Frank wrote:

> Hopefully by the time we decide to do cost reduced version,
> LinuxBios will be usable for the masses and not just for an
> elite group of people who assume everybody else uses the x86 for
> everyday use.:-(

I think the above is a little harsh.

As long as I've been on this list LinuxBIOS has always been about 
getting dirty with the code and making it to do what you need it to do 
for your specific applicaiton.  Along the way many good people have put 
a _lot_ of effort into trying to take all these individual needs and 
produce some sort of API that could be re-useable by the next person. 
But at this level that's really hard.

We've always known the level of documentation sucks.  If you ask we will 
tell you it sucks.  Just none of the people who really know the core 
have time to pull off and re-hash it.

 From what it started with and considering the odds stacked against it 
LB has make _huge_ advancements.  It x86 specific becuse that's what all 
the core developers use.  For LinuxBios to make the jump to 
multi-platform it will take an investment of developers such as yourself 
getting dirty in the core and makeing it happen.  I don't think any of 
the developers just "assume" the world uses x86.  x86 just happens to be 
most of what thier world is right now.

I understand your time requirements prevented you from jumping in on 
this project but until _someone_ takes the initiative and brings LB 
forward on non-x86 platforms it won't ever meet your "masses" criteria.

So I'd suggest that if you really wanted LB available with all the extra 
features for your platform you should revise your tone a bit.  Whiners 
don't get the best of support from coders.




From frannk_m1 at yahoo.com  Tue Jun  8 12:34:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Jun  8 12:34:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <40C5FAFE.8070301@bitworks.com>
Message-ID: <20040608175738.72173.qmail@web13805.mail.yahoo.com>

You missed the point as well!
I was not complaining or whining as you put it about not having
support for the PPC. I was complaining about the lack of support
for new users to use it for the X86 platform. Leave the "other"
processor alone and focus on what you do best, the X86 platform.
As far as I'm concerned you will _never_ have as much support
for the PPC as u-boot does and u-boot will never have the
support for the X86 as LinuxBios does. But it speaks volumes
about the readability of the code when someone switches
directions just so they don't have to go thru the pain of trying
understand your code base. I am not a novice, I have been doing
this for over 20 years. I have ported or written bootloaders for
just about every platform out there. The trick is to use the
bootloader for a particular processor that has the most traction
for a particular architecture.

--- Richard Smith <rsmith at bitworks.com> wrote:
> Frank wrote:
> 
> > Hopefully by the time we decide to do cost reduced version,
> > LinuxBios will be usable for the masses and not just for an
> > elite group of people who assume everybody else uses the x86
> for
> > everyday use.:-(
> 
> I think the above is a little harsh.
> 
> As long as I've been on this list LinuxBIOS has always been
> about 
> getting dirty with the code and making it to do what you need
> it to do 
> for your specific applicaiton.  Along the way many good people
> have put 
> a _lot_ of effort into trying to take all these individual
> needs and 
> produce some sort of API that could be re-useable by the next
> person. 
> But at this level that's really hard.
> 
> We've always known the level of documentation sucks.  If you
> ask we will 
> tell you it sucks.  Just none of the people who really know
> the core 
> have time to pull off and re-hash it.
> 
>  From what it started with and considering the odds stacked
> against it 
> LB has make _huge_ advancements.  It x86 specific becuse
> that's what all 
> the core developers use.  For LinuxBios to make the jump to 
> multi-platform it will take an investment of developers such
> as yourself 
> getting dirty in the core and makeing it happen.  I don't
> think any of 
> the developers just "assume" the world uses x86.  x86 just
> happens to be 
> most of what thier world is right now.
> 
> I understand your time requirements prevented you from jumping
> in on 
> this project but until _someone_ takes the initiative and
> brings LB 
> forward on non-x86 platforms it won't ever meet your "masses"
> criteria.
> 
> So I'd suggest that if you really wanted LB available with all
> the extra 
> features for your platform you should revise your tone a bit. 
> Whiners 
> don't get the best of support from coders.
> 
> 


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 


From rsmith at bitworks.com  Tue Jun  8 12:49:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jun  8 12:49:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608175738.72173.qmail@web13805.mail.yahoo.com>
References: <20040608175738.72173.qmail@web13805.mail.yahoo.com>
Message-ID: <40C601B3.4030109@bitworks.com>

Frank wrote:

> You missed the point as well!

Yes. seems I did. If your mail read less critical to me it might have 
been clearer.  Anyway. My apologies for going on the defensive.

> support for the X86 as LinuxBios does. But it speaks volumes
> about the readability of the code when someone switches
> directions just so they don't have to go thru the pain of trying
> understand your code base.

I'll not disagree with you there.  I haven't messed with v2 much but v1 
does take a lot to navigate and grok.

Are you talking v1 or v2?



From frannk_m1 at yahoo.com  Tue Jun  8 12:54:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Jun  8 12:54:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <40C601B3.4030109@bitworks.com>
Message-ID: <20040608181802.97073.qmail@web13804.mail.yahoo.com>

and that's another problem. Why V1 and V2...
--- Richard Smith <rsmith at bitworks.com> wrote:
> Frank wrote:
> 
> > You missed the point as well!
> 
> Yes. seems I did. If your mail read less critical to me it
> might have 
> been clearer.  Anyway. My apologies for going on the
> defensive.
> 
> > support for the X86 as LinuxBios does. But it speaks volumes
> > about the readability of the code when someone switches
> > directions just so they don't have to go thru the pain of
> trying
> > understand your code base.
> 
> I'll not disagree with you there.  I haven't messed with v2
> much but v1 
> does take a lot to navigate and grok.
> 
> Are you talking v1 or v2?
> 



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 


From YhLu at tyan.com  Tue Jun  8 12:56:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun  8 12:56:01 2004
Subject: =?GB2312?B?tPC4tDogW1BST1BPU0FMXSBleHRlbmRlZCBwYXlsb2FkIGhhbmRs?=
	=?GB2312?B?aW5n?=
Message-ID: <3174569B9743D511922F00A0C9431423055353D4@TYANWEB>

Can you explain deailed about the difference between uboot and Linuxbios?

YH

-----????-----
???: Frank [mailto:frannk_m1 at yahoo.com] 
????: 2004?6?8? 10:58
???: Richard Smith
??: Greg Watson; Stefan Reinauer; LinuxBIOS
??: Re: [PROPOSAL] extended payload handling

You missed the point as well!
I was not complaining or whining as you put it about not having
support for the PPC. I was complaining about the lack of support
for new users to use it for the X86 platform. Leave the "other"
processor alone and focus on what you do best, the X86 platform.
As far as I'm concerned you will _never_ have as much support
for the PPC as u-boot does and u-boot will never have the
support for the X86 as LinuxBios does. But it speaks volumes
about the readability of the code when someone switches
directions just so they don't have to go thru the pain of trying
understand your code base. I am not a novice, I have been doing
this for over 20 years. I have ported or written bootloaders for
just about every platform out there. The trick is to use the
bootloader for a particular processor that has the most traction
for a particular architecture.

--- Richard Smith <rsmith at bitworks.com> wrote:
> Frank wrote:
> 
> > Hopefully by the time we decide to do cost reduced version,
> > LinuxBios will be usable for the masses and not just for an
> > elite group of people who assume everybody else uses the x86
> for
> > everyday use.:-(
> 
> I think the above is a little harsh.
> 
> As long as I've been on this list LinuxBIOS has always been
> about 
> getting dirty with the code and making it to do what you need
> it to do 
> for your specific applicaiton.  Along the way many good people
> have put 
> a _lot_ of effort into trying to take all these individual
> needs and 
> produce some sort of API that could be re-useable by the next
> person. 
> But at this level that's really hard.
> 
> We've always known the level of documentation sucks.  If you
> ask we will 
> tell you it sucks.  Just none of the people who really know
> the core 
> have time to pull off and re-hash it.
> 
>  From what it started with and considering the odds stacked
> against it 
> LB has make _huge_ advancements.  It x86 specific becuse
> that's what all 
> the core developers use.  For LinuxBios to make the jump to 
> multi-platform it will take an investment of developers such
> as yourself 
> getting dirty in the core and makeing it happen.  I don't
> think any of 
> the developers just "assume" the world uses x86.  x86 just
> happens to be 
> most of what thier world is right now.
> 
> I understand your time requirements prevented you from jumping
> in on 
> this project but until _someone_ takes the initiative and
> brings LB 
> forward on non-x86 platforms it won't ever meet your "masses"
> criteria.
> 
> So I'd suggest that if you really wanted LB available with all
> the extra 
> features for your platform you should revise your tone a bit. 
> Whiners 
> don't get the best of support from coders.
> 
> 


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From rsmith at bitworks.com  Tue Jun  8 13:15:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jun  8 13:15:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608181802.97073.qmail@web13804.mail.yahoo.com>
References: <20040608181802.97073.qmail@web13804.mail.yahoo.com>
Message-ID: <40C607B0.6020501@bitworks.com>

Frank wrote:

> and that's another problem. Why V1 and V2...

V1 was deemed un-maintainable.  All the memory init code has to be done 
in assembly with registers only and its very difficult stuff to write. 
There are also several issues with the config files.

Eric wrote romcc which compiles C code that runs without RAM.  And the 
LANL guys did a re-work on the config file parser.  The merging of the 2 
  new major sub-systems essentially became V2. [If I left 
anything/anyone out please someone correct me, I was but a spectator for 
all this]

The V2 tree was then started with a fresh clean slate and the goal to 
correct some of the infrastructure problems with V1.

V1 is still around for people like me who haven't been able to make the 
port to V2.  Like you I'm still under too much time pressure and until I 
can make my video work the effort to go to V2 dosen't make sense.  One I 
can deliver a proto to my customer then I'll go look at V2.

If you are starting from scratch then don't even bother with V1 except 
for reference only.  V2 is the future.  Hopefully you can help it be a 
better future than V1 had.




From YhLu at tyan.com  Tue Jun  8 13:28:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun  8 13:28:00 2004
Subject: [COMMIT] romcc 0.63 and some fixes...
Message-ID: <3174569B9743D511922F00A0C9431423055353E0@TYANWEB>

linuxbios image is 71069 bytes; only 65536 allowed

after change some print_debug to printo_debug, it gets bigger. Before that
it about 68000.

Regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?7? 14:19
???: YhLu
??: LinuxBIOS
??: Re: ??: ??: [COMMIT] romcc 0.63 and some fixes...

YhLu <YhLu at tyan.com> writes:

> I see. The code is getting larger.

Not quite.  There is less generated code, but it requires
extra registers to hold the return addresses so the register
pressure is higher.

Some of that extra register pressure may be artificial and
go away when this bug is fixed.  Some of it may result from
poor choices of the register allocator, and may be remedied
by enhancing the register allocator.  There is hope of
remedies as the kind of code presented to the register
allocator is very different when code is not inlined.

> Also the reboot in OS can not work.

Hmm.  At least with reboot=hard that should work on the Opterons.
I have not tested that lately though.

Eric


From frannk_m1 at yahoo.com  Tue Jun  8 13:51:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Jun  8 13:51:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <40C607B0.6020501@bitworks.com>
Message-ID: <20040608191456.87664.qmail@web13806.mail.yahoo.com>

Someone mentioned ROMCC when I first started to inquire about
V2. But it wasn't in the source tree for V2 and I had to not
only go searching for it I had to figure out how to use it.:-(
That is another selling point for u-boot. When I download the
toolchain (ELDK3) I get everything in one place. From what I
know about ROMCC, it looks like the answer to the "stack in
cache" trick. 
I am not trying to flame or put down LB. I'm just trying to
point out it's shortcomings. I was only trying to provide some
constructive criticism. In about 6 months we will revisit V2 and
try to see if we can use it for our cost reduced version of the
existing product. Hopefully I won't be pressed for time as I am
now and will be able to contribute something.:-)

--- Richard Smith <rsmith at bitworks.com> wrote:
> Frank wrote:
> 
> > and that's another problem. Why V1 and V2...
> 
> V1 was deemed un-maintainable.  All the memory init code has
> to be done 
> in assembly with registers only and its very difficult stuff
> to write. 
> There are also several issues with the config files.
> 
> Eric wrote romcc which compiles C code that runs without RAM. 
> And the 
> LANL guys did a re-work on the config file parser.  The
> merging of the 2 
>   new major sub-systems essentially became V2. [If I left 
> anything/anyone out please someone correct me, I was but a
> spectator for 
> all this]
> 
> The V2 tree was then started with a fresh clean slate and the
> goal to 
> correct some of the infrastructure problems with V1.
> 
> V1 is still around for people like me who haven't been able to
> make the 
> port to V2.  Like you I'm still under too much time pressure
> and until I 
> can make my video work the effort to go to V2 dosen't make
> sense.  One I 
> can deliver a proto to my customer then I'll go look at V2.
> 
> If you are starting from scratch then don't even bother with
> V1 except 
> for reference only.  V2 is the future.  Hopefully you can help
> it be a 
> better future than V1 had.
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 


From dwh at lanl.gov  Tue Jun  8 13:56:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Tue Jun  8 13:56:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608173916.88092.qmail@web13804.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0406081254370.23293-100000@ccs-mail.lanl.gov>

On Tue, 8 Jun 2004, Frank wrote:
> You missed the point!

Yes, I did miss the point (I should've read more closely).

> at u-boot and you'll find support for just about every PPC  and
> the number of drivers are abundant. I can port u-boot to a new
> PPC based board in about 3 days tops. There is no way I can port
> LinuxBios to a new X86 based board in that amount of time. 

I haven't looked at u-boot code much, so I cannot compare ease of porting 
to a new board. However, LB doesn't seem all bad in that area from where I 
stand. Of course it's going to be difficult if you switch architectures, 
but once the initial work is done it's a piece of cake. I was get an Iwill 
DK8S2 (Dual opteron board) running in less than 3 days simply by 
duplicating the Arima HDAMA (Another dual Opteron board) code and tweaking 
some config files, and I'm just a student working here and not some l33t 
hacker like Eric or Ron. No hacking on assembly code (Or even C code for 
that matter) was required. 

As far as architectures go, LinuxBIOS has run on Alphas, x86, x86-64, 
and now PPC. It's portable. And since freebios2 is took a huge leap in 
reducing the amount of assembly required to do a port, it should be easier 
now than it was before.

On Tue, 8 Jun 2004, Frank wrote:
> not waste time trying to make it work for the PPC. If I wanted a
> bootloader I would use u-boot not LinuxBios. I have heard of
> other people abandoning LinuxBios and going to u-boot in that
> past, just like I did...

You ought to try FILO as a payload for LinuxBIOS. I think it accomplishes 
what you wanted a year ago ( 
http://www.clustermatic.org/pipermail/linuxbios/2003-June/003789.html ).

> --- "Hendricks David W." <dwh at lanl.gov> wrote:
> > IIRC, that's what Greg's addition of FILO for PPC was all
> > about.
> > 
> > On Tue, 8 Jun 2004, Frank wrote:
> > 
> > > Finally, someone has recognized the lack of support with
> > > LinuxBios. About 6 months ago we decide to do an x86 based
> > > project but abandoned it because of the lack of support for
> > this
> > > bootloader. The code is disorganized and in disarray as far
> > as
> > > I'm concerend. We were on a tight schedule and didn't have
> > the
> > > luxury of spending a lot of time trying to understand the
> > code
> > > layout. This was due in part to the lack of badly needed
> > > documentation and code organization. We decided to base our
> > > design on a powerpc and go with u-boot.
> > > Hopefully by the time we decide to do cost reduced version,
> > > LinuxBios will be usable for the masses and not just for an
> > > elite group of people who assume everybody else uses the x86
> > for
> > > everyday use.:-(
> > > 
> > > --- Greg Watson <gwatson at lanl.gov> wrote:
> > > > 
> > > > On Jun 8, 2004, at 7:59 AM, Stefan Reinauer wrote:
> > > > 
> > > > > * Greg Watson <gwatson at lanl.gov> [040608 15:22]:
> > > > >> I think this is a reasonable idea, particularly your
> > > > suggestion of
> > > > >> making linuxbios more modular. One of my main beefs
> > with
> > > > the payload
> > > > >> strategy is that each payload has to provide it's own
> > set
> > > > of,
> > > > >> potentially buggy, driver code. If we have 5 payloads
> > then
> > > > we have 5
> > > > >> sets of drivers that all do the same thing slightly
> > > > differently. If 
> > > > >> the
> > > > >> drivers were modular enough so that a payload could
> > call
> > > > them 
> > > > >> directly,
> > > > >> then this would go a long way to addressing these
> > concerns.
> > > > >
> > > > > As far as I can tell the only drivers involved would be
> > > > output drivers,
> > > > > ie. video output and serial output. There the extensible
> > > > LinuxBIOS 
> > > > > table
> > > > > could come into play. The video driver could store a
> > pointer
> > > > to the
> > > > > framebuffer, the resolution and maybe even a font, to
> > save
> > > > duplicates.
> > > > > Serial is only a kilobyte or so of a driver i think.
> > > > >
> > > > > Have I forgotten something?
> > > > >
> > > > 
> > > > PCI device code and resource information should be
> > available
> > > > for 
> > > > payloads to use. A payload should not have to re-probe for
> > > > devices on 
> > > > the PCI bus.
> > > > 
> > > > Greg
> > > > 
> > > > _______________________________________________
> > > > Linuxbios mailing list
> > > > Linuxbios at clustermatic.org
> > > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > > 
> > > 
> > > 	
> > > 		
> > > __________________________________
> > > Do you Yahoo!?
> > > Friends.  Fun.  Try the all-new Yahoo! Messenger.
> > > http://messenger.yahoo.com/ 
> > > _______________________________________________
> > > Linuxbios mailing list
> > > Linuxbios at clustermatic.org
> > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > > 
> > 
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> Friends.  Fun.  Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/ 
> 



From dwh at lanl.gov  Tue Jun  8 14:03:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Tue Jun  8 14:03:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608175738.72173.qmail@web13805.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0406081321540.23293-100000@ccs-mail.lanl.gov>

On Tue, 8 Jun 2004, Frank wrote:
> for new users to use it for the X86 platform. Leave the "other"
> processor alone and focus on what you do best, the X86 platform.
> As far as I'm concerned you will _never_ have as much support
> for the PPC as u-boot does and u-boot will never have the
> support for the X86 as LinuxBios does. But it speaks volumes

The objectives of the LANL people are mostly centered around clustering 
and HPC, not mass production. If someone wants to experiment with PPC 
clustering and sees a niche for LinuxBIOS that other BIOS options cannot 
satisfy, then we do what we can to support it. We're not competing with 
u-boot or trying to convert any of their users, we're merely satisfying 
our own (As selfish as it sounds). 


> --- Richard Smith <rsmith at bitworks.com> wrote:
> > Frank wrote:
> > 
> > > Hopefully by the time we decide to do cost reduced version,
> > > LinuxBios will be usable for the masses and not just for an
> > > elite group of people who assume everybody else uses the x86
> > for
> > > everyday use.:-(
> > 
> > I think the above is a little harsh.
> > 
> > As long as I've been on this list LinuxBIOS has always been
> > about 
> > getting dirty with the code and making it to do what you need
> > it to do 
> > for your specific applicaiton.  Along the way many good people
> > have put 
> > a _lot_ of effort into trying to take all these individual
> > needs and 
> > produce some sort of API that could be re-useable by the next
> > person. 
> > But at this level that's really hard.
> > 
> > We've always known the level of documentation sucks.  If you
> > ask we will 
> > tell you it sucks.  Just none of the people who really know
> > the core 
> > have time to pull off and re-hash it.
> > 
> >  From what it started with and considering the odds stacked
> > against it 
> > LB has make _huge_ advancements.  It x86 specific becuse
> > that's what all 
> > the core developers use.  For LinuxBios to make the jump to 
> > multi-platform it will take an investment of developers such
> > as yourself 
> > getting dirty in the core and makeing it happen.  I don't
> > think any of 
> > the developers just "assume" the world uses x86.  x86 just
> > happens to be 
> > most of what thier world is right now.
> > 
> > I understand your time requirements prevented you from jumping
> > in on 
> > this project but until _someone_ takes the initiative and
> > brings LB 
> > forward on non-x86 platforms it won't ever meet your "masses"
> > criteria.
> > 
> > So I'd suggest that if you really wanted LB available with all
> > the extra 
> > features for your platform you should revise your tone a bit. 
> > Whiners 
> > don't get the best of support from coders.
> > 
> > 
> 
> 
> 	
> 		
> __________________________________
> Do you Yahoo!?
> Friends.  Fun.  Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/ 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From dwh at lanl.gov  Tue Jun  8 14:25:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Tue Jun  8 14:25:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608104930.GA6799@openbios.org>
Message-ID: <Pine.LNX.4.44.0406081338460.23293-100000@ccs-mail.lanl.gov>

On Tue, 8 Jun 2004, Stefan Reinauer wrote:
> 2.) 
> LinuxBIOS can currently execute one payload. For greater flexibility and
> isolated development cycles of the firmware related code parts/projects
> LinuxBIOS should allow payload chains, ie. executing multiple payloads
> one after the other.

Sounds good. How would you suggest bringing up payloads in a certain 
order? Say you wanted a payload to boot a SCSI controller and then another 
payload to boot off a SCSI disk? You'd need a certain order, and you'd 
have to make certain one payload didn't wipe out another. 

There are also instances where one might wish to keep the payload in tact 
even after the operating system has booted, such as using OpenBIOS as a 
LinuxBIOS payload. 

Thoughts?

On Tue, 8 Jun 2004, Stefan Reinauer wrote:
> Feature plugins like "testbios" should not be merged into LinuxBIOS'
> core code. Instead they should be implemented as a payload. Since we

What about VGA, which requires testbios? If it were to be run 
strictly as a payload, we would have practically no useful BIOS 
information display on the screen before the bootloader or Linux comes up. 

(I have a feeling I missed the point, again)



From ebiederman at lnxi.com  Tue Jun  8 15:13:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  8 15:13:00 2004
Subject: [COMMIT] romcc 0.63 and some fixes...
In-Reply-To: <3174569B9743D511922F00A0C9431423055353E0@TYANWEB>
References: <3174569B9743D511922F00A0C9431423055353E0@TYANWEB>
Message-ID: <m3ekopg4y8.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> linuxbios image is 71069 bytes; only 65536 allowed
> 
> after change some print_debug to printo_debug, it gets bigger. Before that
> it about 68000.

Ouch.  I guess it must be some of the missed opportunities for
optimization.  Or the increase in moving values around in
registers.

So in theory it works, but we are having a hard time applying it :(

Do you have any significant size regression with just switching to the
new romcc.

Eric


From YhLu at tyan.com  Tue Jun  8 15:17:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun  8 15:17:01 2004
Subject: =?GB2312?B?tPC4tDogW0NPTU1JVF0gcm9tY2MgMC42MyBhbmQgc29tZSBmaXhl?=
	=?GB2312?B?cy4uLg==?=
Message-ID: <3174569B9743D511922F00A0C9431423055353F3@TYANWEB>

I wonder it get bigger. Just change the print_debug to printo_debug.

Because call printo_debug is bigger than inline print_debug, or the
__attirbute__ (noinline) doesn't take effective.??

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?8? 13:39
???: YhLu
??: LinuxBIOS
??: Re: [COMMIT] romcc 0.63 and some fixes...

YhLu <YhLu at tyan.com> writes:

> linuxbios image is 71069 bytes; only 65536 allowed
> 
> after change some print_debug to printo_debug, it gets bigger. Before that
> it about 68000.

Ouch.  I guess it must be some of the missed opportunities for
optimization.  Or the increase in moving values around in
registers.

So in theory it works, but we are having a hard time applying it :(

Do you have any significant size regression with just switching to the
new romcc.

Eric


From ebiederman at lnxi.com  Tue Jun  8 15:30:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun  8 15:30:00 2004
Subject: =?gb2312?b?tPC4tA==?=: [COMMIT] romcc 0.63 and some fixes...
In-Reply-To: <3174569B9743D511922F00A0C9431423055353F3@TYANWEB>
References: <3174569B9743D511922F00A0C9431423055353F3@TYANWEB>
Message-ID: <m3aczd7or0.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> I wonder it get bigger. Just change the print_debug to printo_debug.
> 
> Because call printo_debug is bigger than inline print_debug, or the
> __attirbute__ (noinline) doesn't take effective.??

__attribute__ ((noinline)) is mandatory is it must take effect.

The best way to see the code difference is to diff the two
version of auto.inc

So it looks like something/somewhere gets bigger.  Possibly
the non-inline call does something really with the register allocation
and we get a lot of register shuffling going on.

I have not seen this case yet.  Tracking down this issue is a very
delicate operation.  Somewhere a heuristic sucks and is causing this.

Eric




From bari at onelabs.com  Tue Jun  8 15:40:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Tue Jun  8 15:40:01 2004
Subject: =?GB2312?B?tPC4tDogW1BST1BPU0FMXSBleHRlbmRlZCBwYXlsb2FkIGhhbg==?=
 =?GB2312?B?ZGxpbmc=?=
In-Reply-To: <3174569B9743D511922F00A0C9431423055353D4@TYANWEB>
References: <3174569B9743D511922F00A0C9431423055353D4@TYANWEB>
Message-ID: <40C62A3D.9070905@onelabs.com>

YhLu wrote:

> Can you explain deailed about the difference between uboot and Linuxbios?

Here's the entire README from U-Boot:

http://cvs.sourceforge.net/viewcvs.py/u-boot/u-boot/README?rev=HEAD


Here's the section of the README from U-Boot that covers init. The
differences to LinuxBIOS should be apparent like no ROMCC in U-Boot:

The following is not intended to be a complete description of every
implementation detail. However, it should help to understand the
inner workings of U-Boot and make it easier to port it to custom
hardware.


Initial Stack, Global Data:
---------------------------

The implementation of U-Boot is complicated by the fact that U-Boot
starts running out of ROM (flash memory), usually without access to
system RAM (because the memory controller is not initialized yet).
This means that we don't have writable Data or BSS segments, and BSS
is not initialized as zero. To be able to get a C environment working
at all, we have to allocate at least a minimal stack. Implementation
options for this are defined and restricted by the CPU used: Some CPU
models provide on-chip memory (like the IMMR area on MPC8xx and
MPC826x processors), on others (parts of) the data cache can be
locked as (mis-) used as memory, etc.

	Chris Hallinan posted a good summary of	 these	issues	to  the
	u-boot-users mailing list:

	Subject: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)?
	From: "Chris Hallinan" <clh at net1plus.com>
	Date: Mon, 10 Feb 2003 16:43:46 -0500 (22:43 MET)
	...

	Correct me if I'm wrong, folks, but the way I understand it
	is this: Using DCACHE as initial RAM for Stack, etc, does not
	require any physical RAM backing up the cache. The cleverness
	is that the cache is being used as a temporary supply of
	necessary storage before the SDRAM controller is setup. It's
	beyond the scope of this list to expain the details, but you
	can see how this works by studying the cache architecture and
	operation in the architecture and processor-specific manuals.

	OCM is On Chip Memory, which I believe the 405GP has 4K. It
	is another option for the system designer to use as an
	initial stack/ram area prior to SDRAM being available. Either
	option should work for you. Using CS 4 should be fine if your
	board designers haven't used it for something that would
	cause you grief during the initial boot! It is frequently not
	used.

	CFG_INIT_RAM_ADDR should be somewhere that won't interfere
	with your processor/board/system design. The default value
	you will find in any recent u-boot distribution in
	Walnut405.h should work for you. I'd set it to a value larger
	than your SDRAM module. If you have a 64MB SDRAM module, set
	it above 400_0000. Just make sure your board has no resources
	that are supposed to respond to that address! That code in
	start.S has been around a while and should work as is when
	you get the config right.

	-Chris Hallinan
	DS4.COM, Inc.

It is essential to remember this, since it has some impact on the C
code for the initialization procedures:

* Initialized global data (data segment) is read-only. Do not attempt
  to write it.

* Do not use any unitialized global data (or implicitely initialized
  as zero data - BSS segment) at all - this is undefined, initiali-
  zation is performed later (when relocating to RAM).

* Stack space is very limited. Avoid big data buffers or things like
  that.

Having only the stack as writable memory limits means we cannot use
normal global data to share information beween the code. But it
turned out that the implementation of U-Boot can be greatly
simplified by making a global data structure (gd_t) available to all
functions. We could pass a pointer to this data as argument to _all_
functions, but this would bloat the code. Instead we use a feature of
the GCC compiler (Global Register Variables) to share the data: we
place a pointer (gd) to the global data into a register which we
reserve for this purpose.

When choosing a register for such a purpose we are restricted by the
relevant  (E)ABI  specifications for the current architecture, and by
GCC's implementation.

For PowerPC, the following registers have specific use:
	R1:	stack pointer
	R2:	TOC pointer
	R3-R4:	parameter passing and return values
	R5-R10: parameter passing
	R13:	small data area pointer
	R30:	GOT pointer
	R31:	frame pointer

	(U-Boot also uses R14 as internal GOT pointer.)

    ==> U-Boot will use R29 to hold a pointer to the global data

    Note: on PPC, we could use a static initializer (since the
    address of the global data structure is known at compile time),
    but it turned out that reserving a register results in somewhat
    smaller code - although the code savings are not that big (on
    average for all boards 752 bytes for the whole U-Boot image,
    624 text + 127 data).

On ARM, the following registers are used:

	R0:	function argument word/integer result
	R1-R3:	function argument word
	R9:	GOT pointer
	R10:	stack limit (used only if stack checking if enabled)
	R11:	argument (frame) pointer
	R12:	temporary workspace
	R13:	stack pointer
	R14:	link register
	R15:	program counter

    ==> U-Boot will use R8 to hold a pointer to the global data


Memory Management:
------------------

U-Boot runs in system state and uses physical addresses, i.e. the
MMU is not used either for address mapping nor for memory protection.

The available memory is mapped to fixed addresses using the memory
controller. In this process, a contiguous block is formed for each
memory type (Flash, SDRAM, SRAM), even when it consists of several
physical memory banks.

U-Boot is installed in the first 128 kB of the first Flash bank (on
TQM8xxL modules this is the range 0x40000000 ... 0x4001FFFF). After
booting and sizing and initializing DRAM, the code relocates itself
to the upper end of DRAM. Immediately below the U-Boot code some
memory is reserved for use by malloc() [see CFG_MALLOC_LEN
configuration setting]. Below that, a structure with global Board
Info data is placed, followed by the stack (growing downward).

Additionally, some exception handler code is copied to the low 8 kB
of DRAM (0x00000000 ... 0x00001FFF).

So a typical memory configuration with 16 MB of DRAM could look like
this:

	0x0000 0000	Exception Vector code
	      :
	0x0000 1FFF
	0x0000 2000	Free for Application Use
	      :
	      :

	      :
	      :
	0x00FB FF20	Monitor Stack (Growing downward)
	0x00FB FFAC	Board Info Data and permanent copy of global data
	0x00FC 0000	Malloc Arena
	      :
	0x00FD FFFF
	0x00FE 0000	RAM Copy of Monitor Code
	...		eventually: LCD or video framebuffer
	...		eventually: pRAM (Protected RAM - unchanged by reset)
	0x00FF FFFF	[End of RAM]


System Initialization:
----------------------

In the reset configuration, U-Boot starts at the reset entry point
(on most PowerPC systens at address 0x00000100). Because of the reset
configuration for CS0# this is a mirror of the onboard Flash memory.
To be able to re-map memory U-Boot then jumps to its link address.
To be able to implement the initialization code in C, a (small!)
initial stack is set up in the internal Dual Ported RAM (in case CPUs
which provide such a feature like MPC8xx or MPC8260), or in a locked
part of the data cache. After that, U-Boot initializes the CPU core,
the caches and the SIU.

Next, all (potentially) available memory banks are mapped using a
preliminary mapping. For example, we put them on 512 MB boundaries
(multiples of 0x20000000: SDRAM on 0x00000000 and 0x20000000, Flash
on 0x40000000 and 0x60000000, SRAM on 0x80000000). Then UPM A is
programmed for SDRAM access. Using the temporary configuration, a
simple memory test is run that determines the size of the SDRAM
banks.

When there is more than one SDRAM bank, and the banks are of
different size, the largest is mapped first. For equal size, the first
bank (CS2#) is mapped first. The first mapping is always for address
0x00000000, with any additional banks following immediately to create
contiguous memory starting from 0.

Then, the monitor installs itself at the upper end of the SDRAM area
and allocates memory for use by malloc() and for the global Board
Info data; also, the exception vector code is copied to the low RAM
pages, and the final stack is set up.

Only after this relocation will you have a "normal" C environment;
until that you are restricted in several ways, mostly because you are
running from ROM, and because the code will have to be relocated to a
new address in RAM.


U-Boot Porting Guide:
----------------------

[Based on messages by Jerry Van Baren in the U-Boot-Users mailing
list, October 2002]


int main (int argc, char *argv[])
{
	sighandler_t no_more_time;

	signal (SIGALRM, no_more_time);
	alarm (PROJECT_DEADLINE - toSec (3 * WEEK));

	if (available_money > available_manpower) {
		pay consultant to port U-Boot;
		return 0;
	}

	Download latest U-Boot source;

	Subscribe to u-boot-users mailing list;

	if (clueless) {
		email ("Hi, I am new to U-Boot, how do I get started?");
	}

	while (learning) {
		Read the README file in the top level directory;
		Read http://www.denx.de/twiki/bin/view/DULG/Manual ;
		Read the source, Luke;
	}

	if (available_money > toLocalCurrency ($2500)) {
		Buy a BDI2000;
	} else {
		Add a lot of aggravation and time;
	}

	Create your own board support subdirectory;

	Create your own board config file;

	while (!running) {
		do {
			Add / modify source code;
		} until (compiles);
		Debug;
		if (clueless)
			email ("Hi, I am having problems...");
	}
	Send patch file to Wolfgang;

	return 0;
}

void no_more_time (int sig)
{
      hire_a_guru();
}







From YhLu at tyan.com  Tue Jun  8 15:44:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun  8 15:44:01 2004
Subject: [PROPOSAL] extended payload handling
Message-ID: <3174569B9743D511922F00A0C9431423055353FE@TYANWEB>

Eric,

What's your idea abut that? They are use cache as ram. ....

Regards

YH

-----????-----
???: Bari Ari [mailto:bari at onelabs.com] 
????: 2004?6?8? 14:06
???: YhLu
??: LinuxBIOS
??: Re: ??: [PROPOSAL] extended payload handling

YhLu wrote:

> Can you explain deailed about the difference between uboot and Linuxbios?

Here's the entire README from U-Boot:

http://cvs.sourceforge.net/viewcvs.py/u-boot/u-boot/README?rev=HEAD


Here's the section of the README from U-Boot that covers init. The
differences to LinuxBIOS should be apparent like no ROMCC in U-Boot:

The following is not intended to be a complete description of every
implementation detail. However, it should help to understand the
inner workings of U-Boot and make it easier to port it to custom
hardware.


Initial Stack, Global Data:
---------------------------

The implementation of U-Boot is complicated by the fact that U-Boot
starts running out of ROM (flash memory), usually without access to
system RAM (because the memory controller is not initialized yet).
This means that we don't have writable Data or BSS segments, and BSS
is not initialized as zero. To be able to get a C environment working
at all, we have to allocate at least a minimal stack. Implementation
options for this are defined and restricted by the CPU used: Some CPU
models provide on-chip memory (like the IMMR area on MPC8xx and
MPC826x processors), on others (parts of) the data cache can be
locked as (mis-) used as memory, etc.

	Chris Hallinan posted a good summary of	 these	issues	to  the
	u-boot-users mailing list:

	Subject: RE: [U-Boot-Users] RE: More On Memory Bank x (nothingness)?
	From: "Chris Hallinan" <clh at net1plus.com>
	Date: Mon, 10 Feb 2003 16:43:46 -0500 (22:43 MET)
	...

	Correct me if I'm wrong, folks, but the way I understand it
	is this: Using DCACHE as initial RAM for Stack, etc, does not
	require any physical RAM backing up the cache. The cleverness
	is that the cache is being used as a temporary supply of
	necessary storage before the SDRAM controller is setup. It's
	beyond the scope of this list to expain the details, but you
	can see how this works by studying the cache architecture and
	operation in the architecture and processor-specific manuals.

	OCM is On Chip Memory, which I believe the 405GP has 4K. It
	is another option for the system designer to use as an
	initial stack/ram area prior to SDRAM being available. Either
	option should work for you. Using CS 4 should be fine if your
	board designers haven't used it for something that would
	cause you grief during the initial boot! It is frequently not
	used.

	CFG_INIT_RAM_ADDR should be somewhere that won't interfere
	with your processor/board/system design. The default value
	you will find in any recent u-boot distribution in
	Walnut405.h should work for you. I'd set it to a value larger
	than your SDRAM module. If you have a 64MB SDRAM module, set
	it above 400_0000. Just make sure your board has no resources
	that are supposed to respond to that address! That code in
	start.S has been around a while and should work as is when
	you get the config right.

	-Chris Hallinan
	DS4.COM, Inc.

It is essential to remember this, since it has some impact on the C
code for the initialization procedures:

* Initialized global data (data segment) is read-only. Do not attempt
  to write it.

* Do not use any unitialized global data (or implicitely initialized
  as zero data - BSS segment) at all - this is undefined, initiali-
  zation is performed later (when relocating to RAM).

* Stack space is very limited. Avoid big data buffers or things like
  that.

Having only the stack as writable memory limits means we cannot use
normal global data to share information beween the code. But it
turned out that the implementation of U-Boot can be greatly
simplified by making a global data structure (gd_t) available to all
functions. We could pass a pointer to this data as argument to _all_
functions, but this would bloat the code. Instead we use a feature of
the GCC compiler (Global Register Variables) to share the data: we
place a pointer (gd) to the global data into a register which we
reserve for this purpose.

When choosing a register for such a purpose we are restricted by the
relevant  (E)ABI  specifications for the current architecture, and by
GCC's implementation.

For PowerPC, the following registers have specific use:
	R1:	stack pointer
	R2:	TOC pointer
	R3-R4:	parameter passing and return values
	R5-R10: parameter passing
	R13:	small data area pointer
	R30:	GOT pointer
	R31:	frame pointer

	(U-Boot also uses R14 as internal GOT pointer.)

    ==> U-Boot will use R29 to hold a pointer to the global data

    Note: on PPC, we could use a static initializer (since the
    address of the global data structure is known at compile time),
    but it turned out that reserving a register results in somewhat
    smaller code - although the code savings are not that big (on
    average for all boards 752 bytes for the whole U-Boot image,
    624 text + 127 data).

On ARM, the following registers are used:

	R0:	function argument word/integer result
	R1-R3:	function argument word
	R9:	GOT pointer
	R10:	stack limit (used only if stack checking if enabled)
	R11:	argument (frame) pointer
	R12:	temporary workspace
	R13:	stack pointer
	R14:	link register
	R15:	program counter

    ==> U-Boot will use R8 to hold a pointer to the global data


Memory Management:
------------------

U-Boot runs in system state and uses physical addresses, i.e. the
MMU is not used either for address mapping nor for memory protection.

The available memory is mapped to fixed addresses using the memory
controller. In this process, a contiguous block is formed for each
memory type (Flash, SDRAM, SRAM), even when it consists of several
physical memory banks.

U-Boot is installed in the first 128 kB of the first Flash bank (on
TQM8xxL modules this is the range 0x40000000 ... 0x4001FFFF). After
booting and sizing and initializing DRAM, the code relocates itself
to the upper end of DRAM. Immediately below the U-Boot code some
memory is reserved for use by malloc() [see CFG_MALLOC_LEN
configuration setting]. Below that, a structure with global Board
Info data is placed, followed by the stack (growing downward).

Additionally, some exception handler code is copied to the low 8 kB
of DRAM (0x00000000 ... 0x00001FFF).

So a typical memory configuration with 16 MB of DRAM could look like
this:

	0x0000 0000	Exception Vector code
	      :
	0x0000 1FFF
	0x0000 2000	Free for Application Use
	      :
	      :

	      :
	      :
	0x00FB FF20	Monitor Stack (Growing downward)
	0x00FB FFAC	Board Info Data and permanent copy of global data
	0x00FC 0000	Malloc Arena
	      :
	0x00FD FFFF
	0x00FE 0000	RAM Copy of Monitor Code
	...		eventually: LCD or video framebuffer
	...		eventually: pRAM (Protected RAM - unchanged by
reset)
	0x00FF FFFF	[End of RAM]


System Initialization:
----------------------

In the reset configuration, U-Boot starts at the reset entry point
(on most PowerPC systens at address 0x00000100). Because of the reset
configuration for CS0# this is a mirror of the onboard Flash memory.
To be able to re-map memory U-Boot then jumps to its link address.
To be able to implement the initialization code in C, a (small!)
initial stack is set up in the internal Dual Ported RAM (in case CPUs
which provide such a feature like MPC8xx or MPC8260), or in a locked
part of the data cache. After that, U-Boot initializes the CPU core,
the caches and the SIU.

Next, all (potentially) available memory banks are mapped using a
preliminary mapping. For example, we put them on 512 MB boundaries
(multiples of 0x20000000: SDRAM on 0x00000000 and 0x20000000, Flash
on 0x40000000 and 0x60000000, SRAM on 0x80000000). Then UPM A is
programmed for SDRAM access. Using the temporary configuration, a
simple memory test is run that determines the size of the SDRAM
banks.

When there is more than one SDRAM bank, and the banks are of
different size, the largest is mapped first. For equal size, the first
bank (CS2#) is mapped first. The first mapping is always for address
0x00000000, with any additional banks following immediately to create
contiguous memory starting from 0.

Then, the monitor installs itself at the upper end of the SDRAM area
and allocates memory for use by malloc() and for the global Board
Info data; also, the exception vector code is copied to the low RAM
pages, and the final stack is set up.

Only after this relocation will you have a "normal" C environment;
until that you are restricted in several ways, mostly because you are
running from ROM, and because the code will have to be relocated to a
new address in RAM.


U-Boot Porting Guide:
----------------------

[Based on messages by Jerry Van Baren in the U-Boot-Users mailing
list, October 2002]


int main (int argc, char *argv[])
{
	sighandler_t no_more_time;

	signal (SIGALRM, no_more_time);
	alarm (PROJECT_DEADLINE - toSec (3 * WEEK));

	if (available_money > available_manpower) {
		pay consultant to port U-Boot;
		return 0;
	}

	Download latest U-Boot source;

	Subscribe to u-boot-users mailing list;

	if (clueless) {
		email ("Hi, I am new to U-Boot, how do I get started?");
	}

	while (learning) {
		Read the README file in the top level directory;
		Read http://www.denx.de/twiki/bin/view/DULG/Manual ;
		Read the source, Luke;
	}

	if (available_money > toLocalCurrency ($2500)) {
		Buy a BDI2000;
	} else {
		Add a lot of aggravation and time;
	}

	Create your own board support subdirectory;

	Create your own board config file;

	while (!running) {
		do {
			Add / modify source code;
		} until (compiles);
		Debug;
		if (clueless)
			email ("Hi, I am having problems...");
	}
	Send patch file to Wolfgang;

	return 0;
}

void no_more_time (int sig)
{
      hire_a_guru();
}






From yhlu at tyan.com  Tue Jun  8 18:30:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Tue Jun  8 18:30:00 2004
Subject: Intel 875 support
In-Reply-To: <Pine.LNX.4.44.0406051200081.22589-100000@maxroach.lanl.gov>
Message-ID: <200406082229.i58MTNK11783@nwn.definitive.org>

Ron,

I would start to add Intel 875 support. I check there are two via
northbridge support in V2. Which one is more mature?

Regards

YH



From stepan at openbios.org  Wed Jun  9 03:40:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Jun  9 03:40:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <83626981-B969-11D8-B023-000393A47A5C@lanl.gov>
References: <20040608104930.GA6799@openbios.org> <D5C5007A-B94E-11D8-B023-000393A47A5C@lanl.gov> <20040608135906.GB9691@openbios.org> <83626981-B969-11D8-B023-000393A47A5C@lanl.gov>
Message-ID: <20040609090427.GA16607@openbios.org>

* Greg Watson <gwatson at lanl.gov> [040608 18:33]:
> 
> PCI device code and resource information should be available for 
> payloads to use. A payload should not have to re-probe for devices on 
> the PCI bus.

I fully agree. That information should go to the LB table. OTOH it would
be a nice option to leave the whole pci device probing away if one
happens to have a payload that does this already. 

Stefan





From stepan at openbios.org  Wed Jun  9 06:27:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Jun  9 06:27:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608191456.87664.qmail@web13806.mail.yahoo.com>
References: <40C607B0.6020501@bitworks.com> <20040608191456.87664.qmail@web13806.mail.yahoo.com>
Message-ID: <20040609115057.GA24213@openbios.org>

* Frank <frannk_m1 at yahoo.com> [040608 21:14]:
> Someone mentioned ROMCC when I first started to inquire about
> V2. But it wasn't in the source tree for V2 and I had to not
> only go searching for it I had to figure out how to use it.:-(

It is, since a very long time now. freebios2/util/romcc/ 
And it is built and used automatically since when building LinuxBIOS v2.

Feel free to come back with questions to this list when you are
evaluating firmware for your next project. :-)

Stefan



From stepan at openbios.org  Wed Jun  9 07:51:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Jun  9 07:51:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <1086709947.1197.82.camel@Calliphara>
References: <20040608104930.GA6799@openbios.org> <1086702128.1197.17.camel@Calliphara> <20040608140440.GA10447@openbios.org> <1086704404.1197.35.camel@Calliphara> <20040608150053.GB10945@openbios.org> <1086709947.1197.82.camel@Calliphara>
Message-ID: <20040609131446.GA24263@openbios.org>

* Mathieu Deschamps <mdeschamps at mangrove-systems.com> [040608 17:52]:
> > Not really. It works because the payload you use is a bootloader. This
> > is a very hard restriction, as PCI resource allocation, or testbios are
> > no bootloaders, and thus do not need and should really not have an ELF
> > loader like LinuxBIOS itself has.

>  oh right... same when you build a the hello world example to test
> LinuxBios boot time : it no a boot loader. It is a ... I realized
> this difference i've reported it as bootloaders and booters. But I don't
> know if it's a good name... what do you think ?

I think just "payload" is fine in LinuxBIOS context. Or, since it's not
an intermediary it might be considered an OS or just a lowlevel
application.

> > Optimistically, LinuxBIOS itself, without PCI resource allocation 
> > should only eat up around 32k with some fiddling. Compared to 256 or
> > 512kbyte flash devices there is plenty of room for additions. If not
> > ADLO then something else.
> 	yes. but no to forget the VGABIOS that's 64k also or rather 50k
 
Except for onboard graphics adapters this is placed on the graphics card
rom and does not need to be packed into the system rom.

> > * if we decide, that having FILO inside of LinuxBIOS is a break in 
> >   design, we should be consequent and split everything but DRAM init 
> >   and ELF loader out, including
> >
> 	So if i'am not mistaking, this would leave a LinuxBios core very thin
> while 'modules' adding fonctions, facilities and commodities would 
> make it thicker...  an architecture that has proven it efficiency...
 
Yes, exactly. Commercial BIOS does a very similar thing, and of all
things commercial BIOS does, this is actually among the best.

> > * payloads should be able to leave information in the LinuxBIOS table,
> >   so that following payloads don't have to do the same work over and
> >   over.
> 	yes . if it's the role a the LinuxBIOS table...hum sure it is.
 
The LinuxBIOS table is an enhancable table that can have new entries
defined without breaking the parsability of old well-known entries. If a
payload does not know how to parse a LB table section created by
LinuxBIOS core or another payload, it would automatically simply ignore it.

> > I see a certain point in not having function callbacks, even if I think
> > it's a dubious one in a full open source environment, but I am not going
> > to argue about this. It's not really needed, EOD.
> 
> 	for now, i also can't see the use of such a possibility... 
 
Well, console output, memory management and all of these have to be
realized by every payload itself, thus producing a small code overhead.
While offering the ability to make things self contained and thus solid,
it also contains the possibility to include new bug sources.. It's
really philosophical in an open source project and there's lots of other
things to do.

Stefan






From stuge-linuxbios at cdy.org  Wed Jun  9 07:57:01 2004
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed Jun  9 07:57:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608191456.87664.qmail@web13806.mail.yahoo.com>
References: <40C607B0.6020501@bitworks.com> <20040608191456.87664.qmail@web13806.mail.yahoo.com>
Message-ID: <20040609132053.GB21595@foo.birdnet.se>

On Tue, Jun 08, 2004 at 12:14:56PM -0700, Frank wrote:
> I am not trying to flame or put down LB. I'm just trying to
> point out it's shortcomings.

Thanks! I think you'll be glad to see that a lot has changed since
your last visit, no thanks to me though. :)

Since you're familiar with the problem I assume you've also had your
share of x86 bugs and un/misdocumented "features" - which also have
had some effect on LB structure, since noone really knew about the
horrors in some of the mainboards/chips/configurations out there.


//Peter


From rminnich at lanl.gov  Wed Jun  9 21:27:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  9 21:27:01 2004
Subject: testbios and the system timer
In-Reply-To: <m37juiscbk.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406092051060.11467-100000@maxroach.lanl.gov>

On 8 Jun 2004, Eric W. Biederman wrote:

> ron minnich <rminnich at lanl.gov> writes:
> > You can in the emulator redirect I/O port access to a function. Write the 
> > code to handle read/write on those ports and use the emulate_counter to 
> > drive the clock value.
> 
> Let me ask this quick question.  Does the emulator restrict port I/O to
> just the resources on a particular VGA device?   If not that is something
> we need to do to implement to ensure we flush these kinds of issues
> into the open and ensure the emulator is portable.

well, yes if you wish it to. That stuff is pretty configurable. Ollie is 
much more current than me on it -- he's hacking it.

ron



From rminnich at lanl.gov  Wed Jun  9 21:40:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  9 21:40:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608135906.GB9691@openbios.org>
Message-ID: <Pine.LNX.4.44.0406092102420.11467-100000@maxroach.lanl.gov>

no, it's just that right now some payloads redo work that linuxbios 
already does. linuxbios walks the pci bus, then the payload does it. 
There's some issues here we need to work out. 

I think with sufficient goodwill and willingness to compromise we can 
figure this out, so let's try to keep the discussion polite and technical.

thanks

ron



From rminnich at lanl.gov  Wed Jun  9 22:03:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun  9 22:03:01 2004
Subject: Intel 875 support
In-Reply-To: <200406082353.i58NrpoS018949@mailproxy2.lanl.gov>
Message-ID: <Pine.LNX.4.44.0406092125430.11467-100000@maxroach.lanl.gov>

On Tue, 8 Jun 2004, Yinghai Lu wrote:

> I would start to add Intel 875 support. I check there are two via
> northbridge support in V2. Which one is more mature?

oh, I have to say the more solid one is the 8601, but you'll need to  
modify it for what I assume is the 875 use of DDR.

ron



From kevin at koconnor.net  Wed Jun  9 22:45:01 2004
From: kevin at koconnor.net (Kevin O'Connor)
Date: Wed Jun  9 22:45:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608104930.GA6799@openbios.org>
References: <20040608104930.GA6799@openbios.org>
Message-ID: <20040610040905.GA24980@ohio.localdomain>

On Tue, Jun 08, 2004 at 12:49:38PM +0200, Stefan Reinauer wrote:
> Feature plugins like "testbios" should not be merged into LinuxBIOS'
> core code. Instead they should be implemented as a payload. Since we
> want to load an operating system later on, we also need to be able to
> load more than one payload. Implementing ELFLOAD in each such plugin is
> inadequate. Instead LinuxBIOS should execute multiple payloads the same
> way it executes multiple "drivers" now.

Hi Stefan,

If I understand your proposal correctly, one of the major issues will be
ensuring that the payloads don't step on each other or linuxbios when they
run.

Wouldn't it be simpler to just link linuxbios and all the payloads together
at compile time?  Essentially, that is what your proposal is doing, except
it does it at run time.

So, couldn't an __init tag be created (a la linux) that marks functions to
be run prior to the bootloader.  With this feature, modules could then be
created entirely separate from the linuxbios core that just define a single
__init entry point.  A simple post-build script could then collect all the
user's modules, scan them for __init functions, create a stub function that
executes the __init functions, and then link the whole mess into the final
linuxbios target..

The above seems functionally equivalent to me, but conceptually simpler;
did I miss something?
-Kevin


From kevin at koconnor.net  Wed Jun  9 22:58:00 2004
From: kevin at koconnor.net (Kevin O'Connor)
Date: Wed Jun  9 22:58:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040610040905.GA24980@ohio.localdomain>
References: <20040608104930.GA6799@openbios.org> <20040610040905.GA24980@ohio.localdomain>
Message-ID: <20040610042230.GA25086@ohio.localdomain>

This is a reply to myself.

On Thu, Jun 10, 2004 at 12:09:05AM -0400, Kevin O'Connor wrote:
> So, couldn't an __init tag be created (a la linux) that marks functions to
> be run prior to the bootloader.  With this feature, modules could then be
> created entirely separate from the linuxbios core that just define a single
> __init entry point.  A simple post-build script could then collect all the
> user's modules, scan them for __init functions, create a stub function that
> executes the __init functions, and then link the whole mess into the final
> linuxbios target..

Sorry, I meant s/__init/module_init/


From ebiederman at lnxi.com  Thu Jun 10 00:02:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun 10 00:02:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040609090427.GA16607@openbios.org>
References: <20040608104930.GA6799@openbios.org>
	<D5C5007A-B94E-11D8-B023-000393A47A5C@lanl.gov>
	<20040608135906.GB9691@openbios.org>
	<83626981-B969-11D8-B023-000393A47A5C@lanl.gov>
	<20040609090427.GA16607@openbios.org>
Message-ID: <m3smd4c766.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Greg Watson <gwatson at lanl.gov> [040608 18:33]:
> > 
> > PCI device code and resource information should be available for 
> > payloads to use. A payload should not have to re-probe for devices on 
> > the PCI bus.
> 
> I fully agree. That information should go to the LB table. 

That has been the tentative plan for quite a while.  So far
I have just had more pressing concerns and no immediate need
so I haven't implemented it.

> OTOH it would be a nice option to leave the whole pci device probing
> away if one happens to have a payload that does this already. 

Probing is not the interesting thing in LinuxBIOS the interesting
thing is resource allocation.  And with OpenFirmware doing it I can
see some point in not predoing it.  But the pci enumeration is quite
cheap so I don't see that it would be much of a problem, especially
as it allows us to concentrate the board specific information in
LinuxBIOS.

What is gained most by exporting this in the LinuxBIOS table is
avoiding broken PCI devices.  And possibly some information about
non-standard PCI bars.

Eric


From ebiederman at lnxi.com  Thu Jun 10 00:10:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun 10 00:10:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <3174569B9743D511922F00A0C9431423055353FE@TYANWEB>
References: <3174569B9743D511922F00A0C9431423055353FE@TYANWEB>
Message-ID: <m3oensc6te.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> What's your idea abut that? They are use cache as ram. ....


From ebiederman at lnxi.com  Thu Jun 10 00:50:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun 10 00:50:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <D5C5007A-B94E-11D8-B023-000393A47A5C@lanl.gov>
References: <20040608104930.GA6799@openbios.org>
	<D5C5007A-B94E-11D8-B023-000393A47A5C@lanl.gov>
Message-ID: <m3hdtkc4yi.fsf@maxwell.lnxi.com>

Greg Watson <gwatson at lanl.gov> writes:

> Stefan,
> 
> I think this is a reasonable idea, particularly your suggestion of making
> linuxbios more modular. One of my main beefs with the payload strategy is that
> each payload has to provide it's own set of, potentially buggy, driver code. If
> we have 5 payloads then we have 5 sets of drivers that all do the same thing
> slightly differently. If the drivers were modular enough so that a payload could
> call them directly, then this would go a long way to addressing these concerns.


The historical perspective on this is interesting.

On the alpha there is/was a bootloader known as MILO.  MILO reused
kernel drivers directly from the kernel build tree.  I think
this was actually inspired by the design of the SRM as I have
heard the SRM uses VMS drivers.  Anyway in practices MILO was
tied to a single kernel version from which it could uses drivers.
In theory MILO was only tied to a kernel major version, but
even switch to a kernel with a different minor version was a pain.

Then look at etherboot or oskit or u-boot, or the BSDs just about any
project that has it's own set of native hardware drivers.  They work
and evolve and are not unmaintainable relics before their time.
Between related projects you will often seen code sharing or being
heavily influenced by other projects but never direct code reuse.

Given that code reuse is a mantra in some circles of the software
world.  That sharing fails and not sharing works appears
non-intuitive.  I can only guess about the reasons for this but here
are a couple.  Writing reusable generic code is at least 3X as
difficult as writing code for a specific purpose, and most driver
code is not designed to used directly in multiple projects.   By not
sharing code directly reasonable expectations about the difficulty of
adding new features are set appropriately.  

Another way of looking at it is that synchronization and coherency in
the large is hard.  Things scale better by having their own private 
resources instead of shared resources that can't scale.  This appears
to apply to software source bases as well as hard drives, memory, and
the like.

Eric




From rminnich at lanl.gov  Thu Jun 10 17:28:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun 10 17:28:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <m3smd4c766.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406101645390.19133-100000@maxroach.lanl.gov>

On 9 Jun 2004, Eric W. Biederman wrote:

> Probing is not the interesting thing in LinuxBIOS the interesting thing
> is resource allocation.  And with OpenFirmware doing it I can see some
> point in not predoing it.  But the pci enumeration is quite cheap so I
> don't see that it would be much of a problem, especially as it allows us
> to concentrate the board specific information in LinuxBIOS.

The issue that concerns me is the "buggy hardware" issue, which has 
happened just often enough to be really painful. The worst-case was the 
VT8601, which if not handled properly would lock up the north bridge, or 
the Acer north bridge that also had a few tricks up its sleeve, and so on. 

I can't expect every boot loader out there to get this one right. PCI 
enumeration is *almost* always simple and cheap.

ron



From stepan at openbios.org  Fri Jun 11 05:44:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Jun 11 05:44:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <Pine.LNX.4.44.0406081338460.23293-100000@ccs-mail.lanl.gov>
References: <20040608104930.GA6799@openbios.org> <Pine.LNX.4.44.0406081338460.23293-100000@ccs-mail.lanl.gov>
Message-ID: <20040611110823.GA13970@openbios.org>

* Hendricks David W. <dwh at lanl.gov> [040608 21:48]:
> On Tue, 8 Jun 2004, Stefan Reinauer wrote:
> > LinuxBIOS can currently execute one payload. For greater flexibility and
> > isolated development cycles of the firmware related code parts/projects
> > LinuxBIOS should allow payload chains, ie. executing multiple payloads
> > one after the other.
> 
> Sounds good. How would you suggest bringing up payloads in a certain 
> order? Say you wanted a payload to boot a SCSI controller and then another 
> payload to boot off a SCSI disk? You'd need a certain order, and you'd 
> have to make certain one payload didn't wipe out another. 
 
The order could be coded in the config file. Scenarios with getting this
from cmos could exist, but I think the order is pretty constant

> There are also instances where one might wish to keep the payload in tact 
> even after the operating system has booted, such as using OpenBIOS as a 
> LinuxBIOS payload. 
 
In such a case, the payload should take care of staying resident itself. 
Everything else would probably require callbacks.

> > Feature plugins like "testbios" should not be merged into LinuxBIOS'
> > core code. Instead they should be implemented as a payload. Since we
> 
> What about VGA, which requires testbios? If it were to be run 
> strictly as a payload, we would have practically no useful BIOS 
> information display on the screen before the bootloader or Linux comes up. 

Currently, with the ati rage xl graphics card, you won't get any output
before pci resource allocation is done and the init drivers get executed
If PCI resource allocation would be a seperate payload, then testbios
could also run directly after that.

Stefan



From stepan at openbios.org  Fri Jun 11 07:03:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Fri Jun 11 07:03:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040610040905.GA24980@ohio.localdomain>
References: <20040608104930.GA6799@openbios.org> <20040610040905.GA24980@ohio.localdomain>
Message-ID: <20040611122753.GA14945@openbios.org>

* Kevin O'Connor <kevin at koconnor.net> [040610 06:09]:
> If I understand your proposal correctly, one of the major issues will be
> ensuring that the payloads don't step on each other or linuxbios when they
> run.
 
Yes, mostly. They must not overwrite LinuxBIOS in memory. And there needs 
to be a mechanism within linuxbios that allows to execute many of them.

> Wouldn't it be simpler to just link linuxbios and all the payloads together
> at compile time?  Essentially, that is what your proposal is doing, except
> it does it at run time.

It actually would be simpler, yes. But as far as I understood the common
discussion here, people prefer having a strict border between linuxbios
and it's payloads. 
 
> So, couldn't an __init tag be created (a la linux) that marks functions to
> be run prior to the bootloader.  With this feature, modules could then be
> created entirely separate from the linuxbios core that just define a single
> __init entry point.  A simple post-build script could then collect all the
> user's modules, scan them for __init functions, create a stub function that
> executes the __init functions, and then link the whole mess into the final
> linuxbios target..
> 
> The above seems functionally equivalent to me, but conceptually simpler;
> did I miss something?

Functionally it is equivalent, yes.

   Stefan



From adam at cfar.umd.edu  Fri Jun 11 10:11:01 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Fri Jun 11 10:11:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040611122753.GA14945@openbios.org>
Message-ID: <20040611114202.P16891-100000@www.missl.cs.umd.edu>

> * Kevin O'Connor <kevin at koconnor.net> [040610 06:09]:
> > If I understand your proposal correctly, one of the major issues will be
> > ensuring that the payloads don't step on each other or linuxbios when they
> > run.
>
> Yes, mostly. They must not overwrite LinuxBIOS in memory. And there needs
> to be a mechanism within linuxbios that allows to execute many of them.

but ADLO does just exactly that... but then ADLO is an exception not the
rule here... necessiated by support of Legacy Applications.

Adam




From ollie at lanl.gov  Fri Jun 11 11:00:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Jun 11 11:00:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040611122753.GA14945@openbios.org>
References: <20040608104930.GA6799@openbios.org>
	 <20040610040905.GA24980@ohio.localdomain>
	 <20040611122753.GA14945@openbios.org>
Message-ID: <1086971082.4486.117.camel@exponential.lanl.gov>

On Fri, 2004-06-11 at 06:27, Stefan Reinauer wrote:
> * Kevin O'Connor <kevin at koconnor.net> [040610 06:09]:
> > If I understand your proposal correctly, one of the major issues will be
> > ensuring that the payloads don't step on each other or linuxbios when they
> > run.
>  
> Yes, mostly. They must not overwrite LinuxBIOS in memory. And there needs 
> to be a mechanism within linuxbios that allows to execute many of them.
> 
> > Wouldn't it be simpler to just link linuxbios and all the payloads together
> > at compile time?  Essentially, that is what your proposal is doing, except
> > it does it at run time.
> 

(What I am going to say proabably will offense a lot of people. I have 
to say sorry in advance.)

The reason we are having this discussion is due to some POLICY, someone
does not want these MECHANISMs to be linked with the CORE LinuxBIOS to
jeopardize the PURITY of it. The only way to hold this POLICY and to 
maintain the PURITY is to seperate these MECHANISMs out and use ELFLOAD
as firewall.

This project/software is going to be exactly as what I predicted a few
years ago: it is going to be an OS. Well, it is not that bad as the 
original idea of LinuxBIOS is to use an OS to boot an OS. The question
is who is who and which is which. The discussion I have read so far 
can be categorised into these two:

	1. Monolithic v.s. Micro Kernel - do we want to put and link
	everything into one program or as seperated PAYLOADs
	(processes/servers?) and use some complicated Inter Payload
	Communiction (IPC) to exachange information and reuse 
	implementation?

	2. Reimplementing an OS called DOS - I read topics about the
	order of loading PAYLOADs and how or should they overlay
	each other. I also found people talking about something as
	Terminated but Stay Resident (TSR). Sooner or later we will
	face the problem of 640K and the solution would be HIMEM.SYS.

Before we going to discuss this any further we should ask ourself, do we
really want to go this way? History probably repeat it self or not, but
do we want to repeat the history?

Ollie




From yhlu at tyan.com  Fri Jun 11 18:16:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Fri Jun 11 18:16:00 2004
Subject: =?gb2312?B?tPC4tDogSW50ZWwgQ2hpcHNldCBzdXBwb3J0IGluIFYy?=
In-Reply-To: <Pine.LNX.4.58.0406051811490.28503@ucontrol.mobiledns.com>
Message-ID: <200406112215.i5BMFgK26851@nwn.definitive.org>

James,

It seems the E7501 in V1 is done by you, When can you move that to V2? I
mean translate.

I hope to change that to support 875. The AMD K8 northbridge is too
different to intel MCH.

Regards

YH

-----????-----
???: Steven James [mailto:pyro at linuxlabs.com] 
????: Saturday, June 05, 2004 11:13 AM
???: ron minnich
??: YhLu; LinuxBIOS
??: Re: Intel Chipset support in V2

Greetings,

I have an interest in it when I get time, but we've seen how time has
worked out for me lately :-(

G'day,
sjames


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


On Sat, 5 Jun 2004, ron minnich wrote:

> On Fri, 4 Jun 2004, YhLu wrote:
>
> > Any plan to move the intel chipset support from V1 to V2? I mean E750x
and
> > 82801xx.
>
> it depends on someone having the time.
>
> I would like to see it happen, but our interest in 32-bit platforms is not
> as broad as it once was,  so it's going to be someone else (or us when we
> get time).
>
> thanks
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From mdeschamps at mangrove-systems.com  Mon Jun 14 03:56:01 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Mon Jun 14 03:56:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <1086971082.4486.117.camel@exponential.lanl.gov>
References: <20040608104930.GA6799@openbios.org>
	 <20040610040905.GA24980@ohio.localdomain>
	 <20040611122753.GA14945@openbios.org>
	 <1086971082.4486.117.camel@exponential.lanl.gov>
Message-ID: <1087204046.12814.111.camel@Calliphara>

I agree with what is said here, except if I may...

I need to react to your questions and This topic is NOT
a question of purity of code or of something nor only a policy...
Brief : 
this is a stacke...

But let admitting that the question of extending the payload handling
seems central and IMHO Linuxbios cannot spare this evolve.

This still lives, provided it doesn't jeopardize theses
fondations (and i think these are still goals):


-LinuxBios is govern by the less possible code writing
 (letting Linuxbios be truely an OS would neck twist this at very short
term) 

-LinuxBios aims no specific target or rather potentially everyone
 (architecture as application field of this technology) 

-LinuxBios is to answer to the lack of 'modernity' of common BIOS, to
answer to nowdays applications, theses BIOS :

	-support old DOS fonctions we don't want, theses are useless
	 for non-DOS-based OS, and they are more and more present.
		(again shall we, not to redo what DOS have done and now
		 we don't need nor want ?)

	-are based upon the executant/orderer scheme as mirror 	  	 	
reflection to the master/slave scheme of the hardware controler, 	 this
approch leds to ennoying limitations and has rise
	 norms and rules which asserves rather than they freed.

	 This scheme *was* logical, and inspires straight in the line 	 	 the
old net working style, in the same relationship of 	 	  communication. 
	   

	 Since the begining, 20 years ago, the interconnection of net ,
 	 changed that old scheme to new one though at this time they 	 	 
couldn't figure how up this could led (or maybe could they)

	 My questions: 

	 Would we return that new scheme to the oldiest
	 part of a computer ? 
	 (further in)
	 Is this good to be inspired by that scheme and return it back 
	 in the opposite way out ? 

	 

Considering this and letting myself, just for the fun, being affimative
twice here is my reflexion :

With the networking growth and the all-communicative state of the demand
and its consequence, interoperabilty; can't LinuxBios implements an
upper abstraction so to take over the forsaid scheme and answer in the
whole to that demand ?

Precisely,
That demand is wide spread and, to get Linuxbios customized to this or
that type of application (whether it's for clustering or embedding or
whatever) without requiering week of port or customing is 
impossible as it goes. 

 There is another way, to the 2 mentionned there after (fore admitting
the second is a one :)

 As payload can be distant or local, why not handling payloads as modern
 network handles packets ? I know this could sound wierd or crazy but to
 my sense it is not.

 and I too, have to say sorry if I confused the thing, but i feel like
this needed to be said.


mathieu.

Le ven 11/06/2004 ? 18:24, Li-Ta Lo a ?crit :
> On Fri, 2004-06-11 at 06:27, Stefan Reinauer wrote:
> > * Kevin O'Connor <kevin at koconnor.net> [040610 06:09]:
> > > If I understand your proposal correctly, one of the major issues will be
> > > ensuring that the payloads don't step on each other or linuxbios when they
> > > run.
> >  
> > Yes, mostly. They must not overwrite LinuxBIOS in memory. And there needs 
> > to be a mechanism within linuxbios that allows to execute many of them.
> > 
> > > Wouldn't it be simpler to just link linuxbios and all the payloads together
> > > at compile time?  Essentially, that is what your proposal is doing, except
> > > it does it at run time.
> > 
> 
> (What I am going to say proabably will offense a lot of people. I have 
> to say sorry in advance.)
> 
> The reason we are having this discussion is due to some POLICY, someone
> does not want these MECHANISMs to be linked with the CORE LinuxBIOS to
> jeopardize the PURITY of it. The only way to hold this POLICY and to 
> maintain the PURITY is to seperate these MECHANISMs out and use ELFLOAD
> as firewall.
> 
> This project/software is going to be exactly as what I predicted a few
> years ago: it is going to be an OS. Well, it is not that bad as the 
> original idea of LinuxBIOS is to use an OS to boot an OS. The question
> is who is who and which is which. The discussion I have read so far 
> can be categorised into these two:
> 
> 	1. Monolithic v.s. Micro Kernel - do we want to put and link
> 	everything into one program or as seperated PAYLOADs
> 	(processes/servers?) and use some complicated Inter Payload
> 	Communiction (IPC) to exachange information and reuse 
> 	implementation?
> 
> 	2. Reimplementing an OS called DOS - I read topics about the
> 	order of loading PAYLOADs and how or should they overlay
> 	each other. I also found people talking about something as
> 	Terminated but Stay Resident (TSR). Sooner or later we will
> 	face the problem of 640K and the solution would be HIMEM.SYS.
> 
> Before we going to discuss this any further we should ask ourself, do we
> really want to go this way? History probably repeat it self or not, but
> do we want to repeat the history?
> 
> Ollie
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 


From mdeschamps at mangrove-systems.com  Mon Jun 14 06:45:01 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Mon Jun 14 06:45:01 2004
Subject: Doc translation
Message-ID: <1087214070.12814.194.camel@Calliphara>

Hello LinuxBiosers,

I have finish my reporting activities, i'am submiting
my work. It is has been done during my training period of
2 months or so. This was a short time and maybe I'am not
experimenced enough to give something to more experimenced people,
but maybe not ;)


Actually, this documentation is 'nowby' oriented,
it's complete, from null cable making to kernel
tweaking, and LinuxBios matter for sure.

Stefan, indeed I don't know whatever it will stuff
your initial papers which were one of my source.

I submit it for 2 reasons :

Because LinuxBios gives me, as a newbie, some real piece of hardness
and some good piece of joy. 
I'd like to share this document so that the first could be
reduce in the advantage of the second piece.

Because it is a duty and a chance of OpenSource design, taking
advantage of everybody experience twice : be quickly started
and confirmed with BIOS developpement, and being commented/corrected
when it's your go to release something.

Nathanael, thanks for your proposition.
I tryed to be as clear as possible,
If you find difficulties, you can mail me.

It is a great project to work on. I congratulate
everybody that made it what it is now, and people
at LANL that started and support it.

Cordialy,
mathieu


-------------- next part --------------
A non-text attachment was scrubbed...
Name: CommunityRelease1 LinuxBios.sxw
Type: application/vnd.sun.xml.writer
Size: 461124 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040614/03147f14/attachment.sxw>

From ebiederman at lnxi.com  Mon Jun 14 11:31:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jun 14 11:31:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608104930.GA6799@openbios.org>
References: <20040608104930.GA6799@openbios.org>
Message-ID: <m3659uf54i.fsf@maxwell.lnxi.com>


> 2.) 
> LinuxBIOS can currently execute one payload. For greater flexibility and
> isolated development cycles of the firmware related code parts/projects
> LinuxBIOS should allow payload chains, ie. executing multiple payloads
> one after the other.
> 
> LinuxBIOS wants to keep up it's modularity, letting each module do it's
> job. This possibility of not doing more than one task should be passed 
> on to the payloads. 


Stepping back a moment.  I see the line at elfload is that the
hardware is sufficiently initialized that we can run stand-alone
programs.

Motherboard specific information should be passed between the BIOS
and the OS which allows a general purpose OS to be built that
does not need to know how each chip is hooked up on each motherboard.

The only argument I have seen for payload chaining is testbios.  I do
not see a reason to exclude this from LinuxBIOS.  It fits in nicely as
an init method for a generic pc compatible vga device.  As long as
this code can be compiled out for those boards that don't have a slot
you can plug in a vga compatible card into all is good.

As the discussion has shown multiple payloads are one form of runtime
service and we once we add one a whole lot more are wanted.


....

My take on runtime services is if they are provided at all they belong
in their own personality/bootloader.   If you want the ability to
switch personalities it is simple enough to add an elf loader to
load other personalities.


Eric



From ebiederman at lnxi.com  Mon Jun 14 12:40:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jun 14 12:40:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040608104930.GA6799@openbios.org>
References: <20040608104930.GA6799@openbios.org>
Message-ID: <m31xkif1xa.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> There has been a similar proposal on this list a while ago, but nothing 
> happened so far, so I want to put this pack to discussion.
> 
> Objectives
> ----------
> 
> 1.) 
> LinuxBIOS is kind of hard to set up for project newbies, since it 
> does not only require manually tweaking the configuration files for
> basically every situation, but also necessarily needs an external
> payload to do anything useful.
> LinuxBIOS currently sets a high barrier due to the modular concepts it
> uses.


>  - LinuxBIOS itself is sometimes very sensitive to the build
>    environment. See requirement for setting LANG for example.

?  The only time I have heard this is with buggy perl when building
   etherboot.
 
>  - For a project outsider it is hard to determine the best payload
>    solution for a specific purpose. There is basically no information
>    except the mailing list archives.

That are documentation is sketchy is a problem.  Half the problem is
that many of the payloads are not terribly mature.  ADLO for example
has to be hacked for each board for example.  That can only be fixed
by fixing the payloads.

>  - Config files have to be tweaked to explicitly suit the user's
>    directory structure. There is no proposal, nothing that works out of
>    the box. One just _has to_ edit the config files.

Agree that is an issue.  
 
>  - LinuxBIOS requires the user to specify a size for the payload instead
>    of determining the required size and doing the needed calculations
>    itself. This is very hand-crufted and can be pretty mind wasting.


I sort of agree.  This is more a matter of reserving a whole you can
place a payload in.  Ideally the payloads can be flashed
independently.  In any case this should be once per board port, and
not something the user needs to mess with. 

And a couple more.

- Too many linuxbios options need to be specified in the top level
  configuration file, or they don't work.

- We don't have stable releases.  You get snapshot of they day instead.



>  * LinuxBIOS therefore needs a way to automatically determine payload
>    sizes when building the image and later when executing payloads.
>    Hardcoding the size values in the config files is inadequate and will
>    lead to unnecessary overhead

There is certainly an issue with flash device layout here.  But I
don't think it is quite as simple as your intuition.
 
>  * LinuxBIOS should, to be consequent, remove all streaming code except
>    CONFIG_ROM_STREAM

On some platforms like the alpha after you have loaded yourself
from an srom.  Or if your primary ROM chip is a Disk-On-Chip that you
need code for reading a ROM.  The IDE driver is certainly interesting.

>  * Payloads should have the possibility to add their own enhancements to 
>    the LinuxBIOS table.

They do they can rewrite it.

>  * A least one payload should be "default payload" with the possibility 
>    to build this automatically and link it into the image. 

To make things easier I largely agree. 
 
>    This is why I checked the "util/extensions" directory into v2 during
>    the last discussion. It should hold possible choices to payloads that
>    can automatically be built and included. Potentially one could add
>    more payloads by symlinking their source tree to this directory to make
>    it available to LinuxBIOS without major reconfiguration.
>    People feel a lot safer with creating a symlink than with changing
>    config files they do not fully understand.

Likely but....

>    Since these can later be executed in row by elfboot, the minimum
>    overhead design of LinuxBIOS itself will not be hurt.
> 
>    At this point I want to put an idea to discussion: If we are going
>    more and more modular and some of us think the current tree is too 
>    bloated: Why do we not modularize code like pci resource allocation
>    into a payload as well. My favorite bootloader may already do this 
>    and I can't stand this bloat everywhere, you know ;) Even though this
>    may sound funny, I am serious about this issue. I do not see why 
>    allocating PCI resources should really be part of the lowlevel code,
>    except for the fact that the NEXT payload in row, potentially Linux
>    itself is too stupid to do that. Bummer.

You cannot use hardware unless it has been allocated resources.  You
cannot do device resource allocation except by looking at all devices.
So largely this is a catch 22 type situation.

The problem with implementing device resource allocation in Linux is
that it requires motherboard specific knowledge.   Frequently onboard
devices have BARs in non-standard locations, the kernel does not know
about, or there are non-enumerable devices like sio chips that have
resources as well.

If a general purpose way of exporting the motherboard specific
information (which devices are present and how they are hooked up) 
can be developed.  And we can teach Linux to use it.  Possibly making
it a CONFIG_EMBEDDED option.  I have no problem with pushing out most
of the code and letting Linux handle it.  And I am even willing to
help with that as time permits.   But until such time as we can reset
OS's expectations of what to expect from the hardware/firmware
combination I am not ready to remove that code.

Beyond that the pci enumeration code is totally optional.  The
mainboard code just needs not to call it.   

There are couple of sticky points I see.  On boxes like the Opteron I
have a hard time seeing how to setup something that is reasonably sane
with hypertransport routing without find which resources are needed by
the devices.  I also have a hard time seeing how much memory you can
report and how to set the memory BARs without knowing how large
your memory mapped pci resources are.

Absolute minimal size and trivial configuration are conflicting
goals.  Getting things as small as possible will require some serious
user tweaking of configuration and possibly likely even the code.
For example to remove the calls into the pci configuration code
requires changing the motherboard code.


>  * LinuxBIOS configuration should have an easier mechanism for choosing 
>    payloads from the "default" directory, allowing them to be built
>    automatically. Right now I am doing:
> 
>      cd filo-0.4.2
>      linux32 make CC="gcc -m32" LD="ld -melf_i386"
>      cd ..
>      freebios2/targets/buildtarget amd/solo $PWD/freebios2
>      cd build-solo
>      make
>      cd ..
>      cp build-solo/solo.rom .
> 
>    My target Config.lb comes with these constructs:
>      target  ../../../../build-solo
>      payload ../../filo-0.4.2/filo.elf
> 
>    So I build everything completely out of the freebios2 tree, because
>    building in-tree sucks. The only thing left is to get filo and the
>    other payloads to build out-of-tree as well.

Hmm.  I always have payload set to something like: 

payload ../../bootloader.ebi

So the symlink part comes naturally.  

Given that building out of the tree is our encouraged state.  What we
likely need to do is to actually have something like configuration
that sets up the environment for the user.  

That way it can be as simple as:
../freebios2/configure --mainboard=arima/hdama 
make

What I should probably do is dig out the LinuxBIOS source rpms that I
use and see if there is something that the community can adopt from
them.

Eric


From nathanael at gnat.ca  Mon Jun 14 13:14:00 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Mon Jun 14 13:14:00 2004
Subject: Doc translation
In-Reply-To: <1087214070.12814.194.camel@Calliphara>
Message-ID: <2F6C5209-BE32-11D8-B076-0003931B4D6A@gnat.ca>

On Monday, June 14, 2004, at 04:54 AM, Mathieu Deschamps wrote:

> Hello LinuxBiosers,
>
> I have finish my reporting activities, i'am submiting
> my work. It is has been done during my training period of
> 2 months or so. This was a short time and maybe I'am not
> experimenced enough to give something to more experimenced people,
> but maybe not ;)
>

Um wow!, I don't know if anyone else downloaded and started reading 
that (I don't know who knows french on this list). In anycase, 
Mathieu's "summary" of LinuxBIOS is 91 pages long and 19 000 words. 
It'll take a little while to translate completely. I've done a couple 
pages so far, but can't do this on a full time basis, so it'll be 
awhile before its all done.

-- 
Nathanael D. Noblet
Gnat Solutions
412 - 135 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/



From ebiederman at lnxi.com  Mon Jun 14 13:49:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jun 14 13:49:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <1086971082.4486.117.camel@exponential.lanl.gov>
References: <20040608104930.GA6799@openbios.org>
	<20040610040905.GA24980@ohio.localdomain>
	<20040611122753.GA14945@openbios.org>
	<1086971082.4486.117.camel@exponential.lanl.gov>
Message-ID: <m3wu2adk5c.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Fri, 2004-06-11 at 06:27, Stefan Reinauer wrote:
> > * Kevin O'Connor <kevin at koconnor.net> [040610 06:09]:
> > > If I understand your proposal correctly, one of the major issues will be
> > > ensuring that the payloads don't step on each other or linuxbios when they
> > > run.
> >  
> > Yes, mostly. They must not overwrite LinuxBIOS in memory. And there needs 
> > to be a mechanism within linuxbios that allows to execute many of them.
> > 
> > > Wouldn't it be simpler to just link linuxbios and all the payloads together
> > > at compile time?  Essentially, that is what your proposal is doing, except
> > > it does it at run time.
> > 
> 
> (What I am going to say proabably will offense a lot of people. I have 
> to say sorry in advance.)
> 
> The reason we are having this discussion is due to some POLICY, someone
> does not want these MECHANISMs to be linked with the CORE LinuxBIOS to
> jeopardize the PURITY of it. The only way to hold this POLICY and to 
> maintain the PURITY is to seperate these MECHANISMs out and use ELFLOAD
> as firewall.

Exactly whenever you change the interface as visible to the outside
world of a piece of software you need to examine very closely what you
are doing and to discuss it.  Things are much more serious, and the
consequences are much more significant than a purely internal change.

Especially something like firmware that people are reluctant to
touch after it works.
 
> This project/software is going to be exactly as what I predicted a few
> years ago: it is going to be an OS. Well, it is not that bad as the 
> original idea of LinuxBIOS is to use an OS to boot an OS. The question
> is who is who and which is which. The discussion I have read so far 
> can be categorised into these two:
> 
> 	1. Monolithic v.s. Micro Kernel - do we want to put and link
> 	everything into one program or as seperated PAYLOADs
> 	(processes/servers?) and use some complicated Inter Payload
> 	Communiction (IPC) to exachange information and reuse 
> 	implementation?
> 
> 	2. Reimplementing an OS called DOS - I read topics about the
> 	order of loading PAYLOADs and how or should they overlay
> 	each other. I also found people talking about something as
> 	Terminated but Stay Resident (TSR). Sooner or later we will
> 	face the problem of 640K and the solution would be HIMEM.SYS.
> 
> Before we going to discuss this any further we should ask ourself, do we
> really want to go this way? History probably repeat it self or not, but
> do we want to repeat the history?

I don't think we want to becoming an OS.

History happens to be easy to repeat because people are familiar and
comfortable with it.


From dwh at lanl.gov  Mon Jun 14 13:56:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Jun 14 13:56:01 2004
Subject: Doc translation
In-Reply-To: <2F6C5209-BE32-11D8-B076-0003931B4D6A@gnat.ca>
Message-ID: <Pine.LNX.4.44.0406141320320.2176-100000@ccs-mail.lanl.gov>

It certainly did look impressive... All sorts of charts and stuff :) It'll 
be interesting to read it when it's translated.

On Mon, 14 Jun 2004, Nathanael Noblet wrote:

> On Monday, June 14, 2004, at 04:54 AM, Mathieu Deschamps wrote:
> 
> > Hello LinuxBiosers,
> >
> > I have finish my reporting activities, i'am submiting
> > my work. It is has been done during my training period of
> > 2 months or so. This was a short time and maybe I'am not
> > experimenced enough to give something to more experimenced people,
> > but maybe not ;)
> >
> 
> Um wow!, I don't know if anyone else downloaded and started reading 
> that (I don't know who knows french on this list). In anycase, 
> Mathieu's "summary" of LinuxBIOS is 91 pages long and 19 000 words. 
> It'll take a little while to translate completely. I've done a couple 
> pages so far, but can't do this on a full time basis, so it'll be 
> awhile before its all done.
> 
> 



From rminnich at lanl.gov  Mon Jun 14 13:59:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jun 14 13:59:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <m31xkif1xa.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0406141320090.2123-100000@maxroach.lanl.gov>

On 14 Jun 2004, Eric W. Biederman wrote:

> - Too many linuxbios options need to be specified in the top level
>   configuration file, or they don't work.

yes, that's on my list too.

> - We don't have stable releases.  You get snapshot of they day instead.

yes.

I'm not so sure I get this 'bloated' discussion. LinuxBIOS is around 32K. 
What's bloat? linuxbios overall is about the size of 'cat'.

ron



From bari at onelabs.com  Mon Jun 14 14:47:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Mon Jun 14 14:47:01 2004
Subject: Doc translation
In-Reply-To: <Pine.LNX.4.44.0406141320320.2176-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0406141320320.2176-100000@ccs-mail.lanl.gov>
Message-ID: <40CE0705.9070005@onelabs.com>

Hendricks David W. wrote:

> It certainly did look impressive... All sorts of charts and stuff :) It'll 
> be interesting to read it when it's translated.

>>Um wow!, I don't know if anyone else downloaded and started reading 
>>that (I don't know who knows french on this list). In anycase, 
>>Mathieu's "summary" of LinuxBIOS is 91 pages long and 19 000 words. 
>>It'll take a little while to translate completely. I've done a couple 
>>pages so far, but can't do this on a full time basis, so it'll be 
>>awhile before its all done.

Please post whatever you have to the list as you go along. I'll pass it 
along to some of the technical writers/editors for editing, so that we 
end up with a nicely written document (at least in English).

-Bari




From dwh at lanl.gov  Mon Jun 14 15:21:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Jun 14 15:21:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <Pine.LNX.4.44.0406141320090.2123-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.44.0406141445210.2176-100000@ccs-mail.lanl.gov>

On Mon, 14 Jun 2004, ron minnich wrote:
> I'm not so sure I get this 'bloated' discussion. LinuxBIOS is around 32K. 
> What's bloat? linuxbios overall is about the size of 'cat'.

Closer to dog, actually :)
http://jl.photodex.com/dog/dog-1.7.tar.gz



From rminnich at lanl.gov  Mon Jun 14 15:23:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jun 14 15:23:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <Pine.LNX.4.44.0406141445210.2176-100000@ccs-mail.lanl.gov>
Message-ID: <Pine.LNX.4.44.0406141447350.2123-100000@maxroach.lanl.gov>

On Mon, 14 Jun 2004, Hendricks David W. wrote:

> On Mon, 14 Jun 2004, ron minnich wrote:
> > I'm not so sure I get this 'bloated' discussion. LinuxBIOS is around 32K. 
> > What's bloat? linuxbios overall is about the size of 'cat'.
> 
> Closer to dog, actually :)
> http://jl.photodex.com/dog/dog-1.7.tar.gz

oh, I don't know david :-)

-rwxr-xr-x    1 root     root        19154 Jul  1  2002 /bin/cat

ron



From John.Usher at perth.maptek.com.au  Mon Jun 14 20:29:00 2004
From: John.Usher at perth.maptek.com.au (John Usher (Maptek))
Date: Mon Jun 14 20:29:00 2004
Subject: cvs freebios locked?
Message-ID: <20E0F651F8B82F45ABCBACC58A2D995B033328@mexper1>

Hi all,
 
I'm trying to 'cvs co freebios', but am getting 'waiting for xxxxxx's
lock in /cvsroot/freebios/freebios/src/northsouthbridge/sis'.
 
This was been happening for 16+ hours now.
 
What is the story with that?
 
...ta...john....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040614/a88dba43/attachment.html>

From hansolofalcon at worldnet.att.net  Mon Jun 14 21:37:01 2004
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Mon Jun 14 21:37:01 2004
Subject: cvs freebios locked?
In-Reply-To: <20E0F651F8B82F45ABCBACC58A2D995B033328@mexper1>
Message-ID: <000201c45285$3653b500$6401a8c0@who5>

Hello from Gregg C Levine
Check your CVS command string. SF updated to a newer release of BIND,
and it has a problem with the way the domains were arranged from the
earlier versions. So it becomes like this: 
"#cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios
login" and then: 

"#cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios
co modulename". (With out the quotes or pound marks. And the line wrap
included by my mailer.)

Were you using the instructions from the website, ( www.linuxbios.org
) or from your own notes?

I had a similar situation about a month earlier, and that's how I
found out, I also checked to see what SF did to cause this. The
project page was updates, (http://sourceforge.net/cvs/?group_id=3206 )
but not the website pages. Ron we need to update the home page's
commands, RSN.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of John Usher
(Maptek)
Sent: Monday, June 14, 2004 9:54 PM
To: linuxbios at clustermatic.org
Subject: cvs freebios locked?

Hi all,
?
I'm trying to 'cvs co freebios', but am getting 'waiting for xxxxxx's
lock in /cvsroot/freebios/freebios/src/northsouthbridge/sis'.
?
This was been happening for 16+ hours now.
?
What is the story with that?
?
...ta...john....



From John.Usher at perth.maptek.com.au  Mon Jun 14 23:09:00 2004
From: John.Usher at perth.maptek.com.au (John Usher (Maptek))
Date: Mon Jun 14 23:09:00 2004
Subject: cvs freebios locked?
Message-ID: <20E0F651F8B82F45ABCBACC58A2D995B35B3E9@mexper1>


>Hello from Gregg C Levine
>Check your CVS command string. SF updated to a newer release of BIND,
>and it has a problem with the way the domains were arranged from the
>earlier versions. So it becomes like this: 
>"#cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios
>login" and then: 
>

Yeah. I discovered that cvs.freebios.sourceforge.net does nothing but
time out for me.

>"#cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios
>co modulename". (With out the quotes or pound marks. And the line wrap
>included by my mailer.)

The 'co' is working fine until it gets to that sis directory, so I've
got all the mainboard stuff etc down...

My command is equivalent to the above though I have CVSROOT set rather
than using the -d flag. However, I would expect it to not work at all if
wrong, not get half of it then complain about a lock on the repository.
Its obviously only meant to be a temporary lock as well, because cvs
retries every thirty seconds.

There is a specific user with the lock on the .../northsouthbridge/sis
directory, I just don't want to post it on here.

...john...


From gwatson at lanl.gov  Tue Jun 15 09:02:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Tue Jun 15 09:02:00 2004
Subject: cvs freebios locked? [PMX:#]
In-Reply-To: <20E0F651F8B82F45ABCBACC58A2D995B35B3E9@mexper1>
References: <20E0F651F8B82F45ABCBACC58A2D995B35B3E9@mexper1>
Message-ID: <EA039CB7-BED6-11D8-A562-000393A47A5C@lanl.gov>

Strange. I just tried to co both freebios and freebios2 using 
pserver:anonymous and they both worked fine. Try removing the entire 
tree and start from scratch.

Greg

On Jun 14, 2004, at 10:34 PM, John Usher (Maptek) wrote:

>
>
>> Hello from Gregg C Levine
>> Check your CVS command string. SF updated to a newer release of BIND,
>> and it has a problem with the way the domains were arranged from the
>> earlier versions. So it becomes like this:
>> "#cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios
>> login" and then:
>>
>
> Yeah. I discovered that cvs.freebios.sourceforge.net does nothing but
> time out for me.
>
>> "#cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios
>> co modulename". (With out the quotes or pound marks. And the line wrap
>> included by my mailer.)
>
> The 'co' is working fine until it gets to that sis directory, so I've
> got all the mainboard stuff etc down...
>
> My command is equivalent to the above though I have CVSROOT set rather
> than using the -d flag. However, I would expect it to not work at all 
> if
> wrong, not get half of it then complain about a lock on the repository.
> Its obviously only meant to be a temporary lock as well, because cvs
> retries every thirty seconds.
>
> There is a specific user with the lock on the .../northsouthbridge/sis
> directory, I just don't want to post it on here.
>
> ...john...
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From wisaacs at io.com  Tue Jun 15 14:26:00 2004
From: wisaacs at io.com (Wayne Isaacs)
Date: Tue Jun 15 14:26:00 2004
Subject: current available doc
Message-ID: <001101c45312$1c97e590$0201a8c0@brilliant>

Is there still a DOC in production which plugs directly into the ROM socket?
W. Isaacs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040615/2b9840c1/attachment.html>

From rminnich at lanl.gov  Tue Jun 15 14:34:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun 15 14:34:01 2004
Subject: current available doc
In-Reply-To: <001101c45312$1c97e590$0201a8c0@brilliant>
Message-ID: <Pine.LNX.4.44.0406151358420.12326-100000@maxroach.lanl.gov>

On Tue, 15 Jun 2004, Wayne Isaacs wrote:

> Is there still a DOC in production which plugs directly into the ROM socket?


there is not "the" ROM socket, so your question is hard to answer. But 
yes, there are some mobos left (I THINK) that will take a DOC. Very few, 
however.

thanks

ron



From John.Usher at perth.maptek.com.au  Tue Jun 15 20:30:01 2004
From: John.Usher at perth.maptek.com.au (John Usher (Maptek))
Date: Tue Jun 15 20:30:01 2004
Subject: cvs freebios locked? [PMX:#]
Message-ID: <20E0F651F8B82F45ABCBACC58A2D995B35B3F4@mexper1>

It all sorted itself out overnight for me.

Thanks people...

...John...

-----Original Message-----
From: Greg Watson [mailto:gwatson at lanl.gov] 
Sent: Tuesday, 15 June 2004 10:19 PM
To: John Usher (Maptek)
Cc: Gregg C Levine; linuxbios at clustermatic.org
Subject: Re: cvs freebios locked? [PMX:#]


Strange. I just tried to co both freebios and freebios2 using 
pserver:anonymous and they both worked fine. Try removing the entire 
tree and start from scratch.

Greg

On Jun 14, 2004, at 10:34 PM, John Usher (Maptek) wrote:

>
>
>> Hello from Gregg C Levine
>> Check your CVS command string. SF updated to a newer release of BIND,
>> and it has a problem with the way the domains were arranged from the
>> earlier versions. So it becomes like this:
>> "#cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios
>> login" and then:
>>
>
> Yeah. I discovered that cvs.freebios.sourceforge.net does nothing but
> time out for me.
>
>> "#cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/freebios
>> co modulename". (With out the quotes or pound marks. And the line
wrap
>> included by my mailer.)
>
> The 'co' is working fine until it gets to that sis directory, so I've
> got all the mainboard stuff etc down...
>
> My command is equivalent to the above though I have CVSROOT set rather
> than using the -d flag. However, I would expect it to not work at all 
> if
> wrong, not get half of it then complain about a lock on the
repository.
> Its obviously only meant to be a temporary lock as well, because cvs
> retries every thirty seconds.
>
> There is a specific user with the lock on the .../northsouthbridge/sis
> directory, I just don't want to post it on here.
>
> ...john...
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From skinkie at xs4all.nl  Wed Jun 16 10:42:00 2004
From: skinkie at xs4all.nl (Stefan de Konink)
Date: Wed Jun 16 10:42:00 2004
Subject: Has anyone heard about EPIA MII FastBoot ROM Utility? < GPL Issue
Message-ID: <40D07066.3060005@xs4all.nl>

Hello all,

I'm trying to boot from the CF reader on the VIA Epia platform. After 
reading forums and mailinglist this could be possible by the FastBoot 
Utility.

http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip

But I was a bit surpriced what I found in there...
grep linux `find` and look at the 'loader*.obj'-files.


Can somebody confirm this is _not_ distributed GPL code as a binary?


Greetings,

Stefan de Konink


From ollie at lanl.gov  Wed Jun 16 11:18:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Jun 16 11:18:00 2004
Subject: Phantom Devices
Message-ID: <1087404189.4486.177.camel@exponential.lanl.gov>

Hello,

I am porting LinuxBIOS to the AMD Serenade mainboard and
encountered another problem with the device enumeration/
resource allcation.

The Serenade is almost exactly like the HDAMA or E325 but the
two CPUs are connected by LDT0 on each one and the NCHT to
8131/8111 is on LDT2 on CPU0. I reused the mainboard/hdama and
CAREFULLY change the .c code to reflaect the difference in LDT.
I didn't change the Config.lb because the "bus" hierachy is
the same. After I boot with the image I found that the dynamic
device structures converted from the static device structures
are NOT connected to the real devices found in the pci bus scan.
So I have a set of dynamic device strucures without any corresponding
physical device (PHANTOMs) and another set of dynamic devices
structures having no "static" device information from the Config.lb.

The problem is caused by having uninitialized or incorrectly initialized
bus->children. The dynamic device structures converted from static
devices are on the other "link" (I would rather call it 'branch') of the
"parent" i.e. they are the children of another "bus". The 
pci_scan_get_dev() or ht_scan_get_devs() can not find the pre-created 
device structures on this WRONG "bus/link" when scaning the bus/chain 
so it created a new instance.

How can I solve this problem ? Does the "link" keyword in the
config file actually been used ? I tried to change the "link"
for 8131/8111 in the config file but it made no difference.

Ollie

 
 



From bari at onelabs.com  Wed Jun 16 11:22:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Jun 16 11:22:01 2004
Subject: Linux Centrino Notebook
Message-ID: <40D0792D.5020002@onelabs.com>

IBM now has a Linux notebook with Tier1 support. Maybe this is a laptop 
to get LinuxBIOS up on.

http://www.theinquirer.net/?article=16550

http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=2049168&storeId=1&catalogId=-840&langId=-1

Anyone have one of these yet?

-Bari




From ebiederman at lnxi.com  Wed Jun 16 11:56:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jun 16 11:56:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <Pine.LNX.4.44.0406141320090.2123-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406141320090.2123-100000@maxroach.lanl.gov>
Message-ID: <m34qpbwh2y.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 14 Jun 2004, Eric W. Biederman wrote:
> 
> I'm not so sure I get this 'bloated' discussion. LinuxBIOS is around 32K. 
> What's bloat? linuxbios overall is about the size of 'cat'.

Ron can I have you version of romcc?.  We have several ports
that are routinely smacking up against the 64K limit during
development.  The last E7501 port I did in the freebios1 tree
LinuxBIOS was running about 40K.  With romcc inlining everything
we are worse in the freebios2 tree. 

As far as bloat baring Stefan's concerns about redundancy between
LinuxBIOS and OpenBIOS (the resource allocation code).  Is not so
much about the features we have to day, but more a feeling much more
will be the pebble that starts the avalanche.  Or maybe we feel
we have seen the pebble, and we are watching it bounce downhill with
dread.

The bottom line is that to keep size under control you constantly
have to be paying attention to size, just as you have to constantly
watch correctness and performance.  The long term trends in the industry
are for very slow romsize growth.

Anyway even at 32K you are twice as big as my cat :)
 ls -l /bin/cat
-rwxr-xr-x    1 root     root        15000 2003-10-04 17:10 /bin/cat*

Eric


From YhLu at tyan.com  Wed Jun 16 12:01:23 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jun 16 12:01:23 2004
Subject: =?gb2312?B?tPC4tDogTGludXggQ2VudHJpbm8gTm90ZWJvb2s=?=
Message-ID: <3174569B9743D511922F00A0C9431423055356F6@TYANWEB>

What's the Northbridge?

-----????-----
???: Bari Ari [mailto:bari at onelabs.com] 
????: Wednesday, June 16, 2004 9:46 AM
???: linuxbios at clustermatic.org
??: Linux Centrino Notebook

IBM now has a Linux notebook with Tier1 support. Maybe this is a laptop 
to get LinuxBIOS up on.

http://www.theinquirer.net/?article=16550

http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=
2049168&storeId=1&catalogId=-840&langId=-1

Anyone have one of these yet?

-Bari


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


From YhLu at tyan.com  Wed Jun 16 12:21:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jun 16 12:21:01 2004
Subject: =?gb2312?B?tPC4tDogW1BST1BPU0FMXSBleHRlbmRlZCBwYXlsb2FkIGhhbmRs?=
	=?gb2312?B?aW5n?=
Message-ID: <3174569B9743D511922F00A0C9431423055356F9@TYANWEB>

Eric,

Did you ever translate the E7501 into C?

Regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: Wednesday, June 16, 2004 10:25 AM
???: ron minnich
??: Stefan Reinauer; LinuxBIOS
??: Re: [PROPOSAL] extended payload handling

ron minnich <rminnich at lanl.gov> writes:

> On 14 Jun 2004, Eric W. Biederman wrote:
> 
> I'm not so sure I get this 'bloated' discussion. LinuxBIOS is around 32K. 
> What's bloat? linuxbios overall is about the size of 'cat'.

Ron can I have you version of romcc?.  We have several ports
that are routinely smacking up against the 64K limit during
development.  The last E7501 port I did in the freebios1 tree
LinuxBIOS was running about 40K.  With romcc inlining everything
we are worse in the freebios2 tree. 

As far as bloat baring Stefan's concerns about redundancy between
LinuxBIOS and OpenBIOS (the resource allocation code).  Is not so
much about the features we have to day, but more a feeling much more
will be the pebble that starts the avalanche.  Or maybe we feel
we have seen the pebble, and we are watching it bounce downhill with
dread.

The bottom line is that to keep size under control you constantly
have to be paying attention to size, just as you have to constantly
watch correctness and performance.  The long term trends in the industry
are for very slow romsize growth.

Anyway even at 32K you are twice as big as my cat :)
 ls -l /bin/cat
-rwxr-xr-x    1 root     root        15000 2003-10-04 17:10 /bin/cat*

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


From bari at onelabs.com  Wed Jun 16 13:19:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Jun 16 13:19:00 2004
Subject: =?GB2312?B?tPC4tDogTGludXggQ2VudHJpbm8gTm90ZWJvb2s=?=
In-Reply-To: <3174569B9743D511922F00A0C9431423055356F6@TYANWEB>
References: <3174569B9743D511922F00A0C9431423055356F6@TYANWEB>
Message-ID: <40D09516.2050308@onelabs.com>

YhLu wrote:

> What's the Northbridge?

Seems the IBM data sheet is keeping that a secret (not important enough
to list it for most buyers) but the data sheet does list the new Intel
PRO/Wireless 2200BG, 802.11b/g, 2.4GHz, Mini PCI adapter with Linux support.

-Bari




From tony_cheng at pcmagic.net  Wed Jun 16 14:31:01 2004
From: tony_cheng at pcmagic.net (root)
Date: Wed Jun 16 14:31:01 2004
Subject: Building Tyan AMD64 s2882 Linux BIOS
In-Reply-To: <3174569B9743D511922F00A0C9431423055356F9@TYANWEB>
References: <3174569B9743D511922F00A0C9431423055356F9@TYANWEB>
Message-ID: <1087415858.15119.20.camel@linux.site>

Mr. Yh,

I'm glag to see you here. I saw your name on the LinuxBIOS web site and
know you are the owner of Tyan AMD64 motherboard.

I'm building the Linux BIOS using your Tyan s2882. The AMD opteron 2
CPUs system for my comany, we are evaluating Tyan s2882 board for a
embeded Storage Server. I have some questions maybe you can enlighten
me.  

1. I get a lot of warning messages from compiler when I build, is that
normal? I use Suse Linux 9.1, GCC 3.3.3

2. I only get Fallback BIOS build sucessfully, Normal BIOS will break
during the build, is that the way it is?

3. I see your ROM_SECTION_SIZE was set to about 98K, you must have a
very small payload and use a flash utilty to program the Flash. I set
the ROM_SECTION_SIZE to 512K, but I'm still have trouble to get a Linux
Kernel to fit into the Flash. Do you have any recommandation about the
payload?  if you can send your payload "tg3--ide_disk_com1_2.zelf" to me
just for a testing purpose that will be great!


Thanks 

Tony



From YhLu at tyan.com  Wed Jun 16 14:39:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jun 16 14:39:00 2004
Subject: =?gb2312?B?tPC4tDogQnVpbGRpbmcgVHlhbiBBTUQ2NCBzMjg4MiBMaW51eCBC?=
	=?gb2312?B?SU9T?=
Message-ID: <3174569B9743D511922F00A0C943142305535713@TYANWEB>

Tony,

Where did you get the source code?

Via CVS or linuxbios snapshot?

The update source code should be compiled no problem under RH 9 for i386.

ROM_SECTION_SIZE should be 128K for fallback.

If you want to boot local
1. Etherboot: you can build ide_disk.zelf 
2. FILO: it can understand file system and kernel + rootfs instead of elf
format
3. FILO_IN_Etherboot: I port the FILO into Etherboot and add boot from sata
and it can boot from usb disk too.

Regards

YH
-----????-----
???: root [mailto:tony_cheng at pcmagic.net] 
????: Wednesday, June 16, 2004 12:58 PM
???: YhLu
??: LinuxBIOS
??: Building Tyan AMD64 s2882 Linux BIOS


Mr. Yh,

I'm glag to see you here. I saw your name on the LinuxBIOS web site and
know you are the owner of Tyan AMD64 motherboard.

I'm building the Linux BIOS using your Tyan s2882. The AMD opteron 2
CPUs system for my comany, we are evaluating Tyan s2882 board for a
embeded Storage Server. I have some questions maybe you can enlighten
me.  

1. I get a lot of warning messages from compiler when I build, is that
normal? I use Suse Linux 9.1, GCC 3.3.3

2. I only get Fallback BIOS build sucessfully, Normal BIOS will break
during the build, is that the way it is?

3. I see your ROM_SECTION_SIZE was set to about 98K, you must have a
very small payload and use a flash utilty to program the Flash. I set
the ROM_SECTION_SIZE to 512K, but I'm still have trouble to get a Linux
Kernel to fit into the Flash. Do you have any recommandation about the
payload?  if you can send your payload "tg3--ide_disk_com1_2.zelf" to me
just for a testing purpose that will be great!


Thanks 

Tony


From tony_cheng at pcmagic.net  Wed Jun 16 15:04:00 2004
From: tony_cheng at pcmagic.net (Tony Cheng)
Date: Wed Jun 16 15:04:00 2004
Subject: Building Tyan AMD64 s2882 Linux BIOS
References: <3174569B9743D511922F00A0C943142305535713@TYANWEB>
Message-ID: <006b01c453e0$9cc4f630$932614ac@trans.corp>

Yh,

The source code I've got is coming from CVS, but it's about one or two month
ago. I get the code and did do anything with it until now. I will update the
code and try again.

I will try Redhat 9.0, last time I try it, I saw the version of GCC on
redhat 9.0 is lower than the required version mentioned by LinuxBIOS-AMD64,
Author by Stefan Reinauer

I'm not fully understand the paylod idea yet, but I will do some research on
my side.

I'm really appriciate the response you guys have given to me. I'm starting
to feel much more confident with LinuxBIOS now.

Some people in my company is a little hesitate about the LinuxBIOS as we use
Phoenix BIOS before and afraid of the free Software, I will make a strong
case for them because the good community I saw here.

Tony


----- Original Message ----- 
From: "YhLu" <YhLu at tyan.com>
To: <tony_cheng at pcmagic.net>
Cc: "LinuxBIOS" <linuxbios at clustermatic.org>
Sent: Wednesday, June 16, 2004 1:06 PM
Subject: ??: Building Tyan AMD64 s2882 Linux BIOS


> Tony,
>
> Where did you get the source code?
>
> Via CVS or linuxbios snapshot?
>
> The update source code should be compiled no problem under RH 9 for i386.
>
> ROM_SECTION_SIZE should be 128K for fallback.
>
> If you want to boot local
> 1. Etherboot: you can build ide_disk.zelf
> 2. FILO: it can understand file system and kernel + rootfs instead of elf
> format
> 3. FILO_IN_Etherboot: I port the FILO into Etherboot and add boot from
sata
> and it can boot from usb disk too.
>
> Regards
>
> YH
> -----????-----
> ???: root [mailto:tony_cheng at pcmagic.net]
> ????: Wednesday, June 16, 2004 12:58 PM
> ???: YhLu
> ??: LinuxBIOS
> ??: Building Tyan AMD64 s2882 Linux BIOS
>
>
> Mr. Yh,
>
> I'm glag to see you here. I saw your name on the LinuxBIOS web site and
> know you are the owner of Tyan AMD64 motherboard.
>
> I'm building the Linux BIOS using your Tyan s2882. The AMD opteron 2
> CPUs system for my comany, we are evaluating Tyan s2882 board for a
> embeded Storage Server. I have some questions maybe you can enlighten
> me.
>
> 1. I get a lot of warning messages from compiler when I build, is that
> normal? I use Suse Linux 9.1, GCC 3.3.3
>
> 2. I only get Fallback BIOS build sucessfully, Normal BIOS will break
> during the build, is that the way it is?
>
> 3. I see your ROM_SECTION_SIZE was set to about 98K, you must have a
> very small payload and use a flash utilty to program the Flash. I set
> the ROM_SECTION_SIZE to 512K, but I'm still have trouble to get a Linux
> Kernel to fit into the Flash. Do you have any recommandation about the
> payload?  if you can send your payload "tg3--ide_disk_com1_2.zelf" to me
> just for a testing purpose that will be great!
>
>
> Thanks
>
> Tony
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From dwh at lanl.gov  Wed Jun 16 15:07:13 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Wed Jun 16 15:07:13 2004
Subject: Building Tyan AMD64 s2882 Linux BIOS
In-Reply-To: <1087415858.15119.20.camel@linux.site>
Message-ID: <Pine.LNX.4.44.0406161421010.2176-100000@ccs-mail.lanl.gov>

On Wed, 16 Jun 2004, root wrote:
> 1. I get a lot of warning messages from compiler when I build, is that
> normal? I use Suse Linux 9.1, GCC 3.3.3

What sort of errors? There are some print statements such as #warning 
"FIXME handle interleaved nodes" that are harmless. 

> 2. I only get Fallback BIOS build sucessfully, Normal BIOS will break
> during the build, is that the way it is?

No, normal and fallback should both build. Can you please send us a log?



From YhLu at tyan.com  Wed Jun 16 15:16:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jun 16 15:16:01 2004
Subject: =?gb2312?B?tPC4tDogQnVpbGRpbmcgVHlhbiBBTUQ2NCBzMjg4MiBMaW51eCBC?=
	=?gb2312?B?SU9T?=
Message-ID: <3174569B9743D511922F00A0C94314230553571D@TYANWEB>

For Linux based Server, LinuxBIOS would be better than any other commercial
BIOS.

OS has been in GPL, So BIOS should be there too.

Regards

YH

-----????-----
???: Tony Cheng [mailto:tony_cheng at pcmagic.net] 
????: Wednesday, June 16, 2004 1:29 PM
???: YhLu
??: LinuxBIOS
??: Re: Building Tyan AMD64 s2882 Linux BIOS

Yh,

The source code I've got is coming from CVS, but it's about one or two month
ago. I get the code and did do anything with it until now. I will update the
code and try again.

I will try Redhat 9.0, last time I try it, I saw the version of GCC on
redhat 9.0 is lower than the required version mentioned by LinuxBIOS-AMD64,
Author by Stefan Reinauer

I'm not fully understand the paylod idea yet, but I will do some research on
my side.

I'm really appriciate the response you guys have given to me. I'm starting
to feel much more confident with LinuxBIOS now.

Some people in my company is a little hesitate about the LinuxBIOS as we use
Phoenix BIOS before and afraid of the free Software, I will make a strong
case for them because the good community I saw here.

Tony


----- Original Message ----- 
From: "YhLu" <YhLu at tyan.com>
To: <tony_cheng at pcmagic.net>
Cc: "LinuxBIOS" <linuxbios at clustermatic.org>
Sent: Wednesday, June 16, 2004 1:06 PM
Subject: ??: Building Tyan AMD64 s2882 Linux BIOS


> Tony,
>
> Where did you get the source code?
>
> Via CVS or linuxbios snapshot?
>
> The update source code should be compiled no problem under RH 9 for i386.
>
> ROM_SECTION_SIZE should be 128K for fallback.
>
> If you want to boot local
> 1. Etherboot: you can build ide_disk.zelf
> 2. FILO: it can understand file system and kernel + rootfs instead of elf
> format
> 3. FILO_IN_Etherboot: I port the FILO into Etherboot and add boot from
sata
> and it can boot from usb disk too.
>
> Regards
>
> YH
> -----????-----
> ???: root [mailto:tony_cheng at pcmagic.net]
> ????: Wednesday, June 16, 2004 12:58 PM
> ???: YhLu
> ??: LinuxBIOS
> ??: Building Tyan AMD64 s2882 Linux BIOS
>
>
> Mr. Yh,
>
> I'm glag to see you here. I saw your name on the LinuxBIOS web site and
> know you are the owner of Tyan AMD64 motherboard.
>
> I'm building the Linux BIOS using your Tyan s2882. The AMD opteron 2
> CPUs system for my comany, we are evaluating Tyan s2882 board for a
> embeded Storage Server. I have some questions maybe you can enlighten
> me.
>
> 1. I get a lot of warning messages from compiler when I build, is that
> normal? I use Suse Linux 9.1, GCC 3.3.3
>
> 2. I only get Fallback BIOS build sucessfully, Normal BIOS will break
> during the build, is that the way it is?
>
> 3. I see your ROM_SECTION_SIZE was set to about 98K, you must have a
> very small payload and use a flash utilty to program the Flash. I set
> the ROM_SECTION_SIZE to 512K, but I'm still have trouble to get a Linux
> Kernel to fit into the Flash. Do you have any recommandation about the
> payload?  if you can send your payload "tg3--ide_disk_com1_2.zelf" to me
> just for a testing purpose that will be great!
>
>
> Thanks
>
> Tony
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>


From ebiederman at lnxi.com  Wed Jun 16 15:20:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jun 16 15:20:00 2004
Subject: =?gb2312?b?tPC4tA==?=: [PROPOSAL] extended payload handling
In-Reply-To: <3174569B9743D511922F00A0C9431423055356F9@TYANWEB>
References: <3174569B9743D511922F00A0C9431423055356F9@TYANWEB>
Message-ID: <m3oenjb58j.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Did you ever translate the E7501 into C?

No.  But as a first pass you should still be able to skip that
step in V2.  Romcc generates assembly as an intermediate step.

Since the point primarily is not a good E7501 port but to get
skeleton code for other Intel based ports.  I don't think it
will matter.

Of course maintenance will be a major pain if the code is not
translated into C.

Oh, BTW. One of the things I forgot and was one of the
motivators of my last romcc release is that I can now pass parameters
in and out of romcc compiled code.  So I should be able to clean
up the handling of BIST checking on the Opteron port.  Currently
it is an ugly hack in assembly so I don't know if I have pushed
that to the public tree or not.

Eric




From adam at cfar.umd.edu  Wed Jun 16 15:23:01 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Wed Jun 16 15:23:01 2004
Subject: Linux Centrino Notebook
In-Reply-To: <40D0792D.5020002@onelabs.com>
Message-ID: <20040616164739.Q14638-100000@www.missl.cs.umd.edu>

> IBM now has a Linux notebook with Tier1 support. Maybe this is a laptop
> to get LinuxBIOS up on.
>
> http://www.theinquirer.net/?article=16550
>
> http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=2049168&storeId=1&catalogId=-840&langId=-1
> Anyone have one of these yet?

how did you get that IBM url?

it does list my IBM Thinkpad 2373GEU

hopefully it means they will improve ACPI support on it.




From adam at cfar.umd.edu  Wed Jun 16 15:26:01 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Wed Jun 16 15:26:01 2004
Subject: Has anyone heard about EPIA MII FastBoot ROM Utility? < GPL
 Issue
In-Reply-To: <40D07066.3060005@xs4all.nl>
Message-ID: <20040616164845.B14638-100000@www.missl.cs.umd.edu>

> I'm trying to boot from the CF reader on the VIA Epia platform. After
> reading forums and mailinglist this could be possible by the FastBoot
> Utility.
>
> http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
>
> But I was a bit surpriced what I found in there...
> grep linux `find` and look at the 'loader*.obj'-files.
>
>
> Can somebody confirm this is _not_ distributed GPL code as a binary?

fyi, you can get to this page from :

	http://www.viaarena.com/?PageID=343

you can do:
	wget http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
	unzip fastboot%20v2.01.zip
  	strings */*/loader?.obj | grep -i linux

it gives you stuff like :

_linuxbios_versionR
_linuxbios_extra_versionX
_linuxbios_build`
_linuxbios_compile_timef
_linuxbios_compile_byp
_linuxbios_compile_hostv
_linuxbios_compile_domainz
_linuxbios_compiler~
_linuxbios_linker
_linuxbios_assembler


etc, etc.

also that http page mentioned above has contact info. perhaps something to
inquire at.





From bari at onelabs.com  Wed Jun 16 15:35:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Jun 16 15:35:01 2004
Subject: Linux Centrino Notebook
In-Reply-To: <20040616164739.Q14638-100000@www.missl.cs.umd.edu>
References: <20040616164739.Q14638-100000@www.missl.cs.umd.edu>
Message-ID: <40D0B501.8080000@onelabs.com>

Adam Sulmicki wrote:
>>http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=2049168&storeId=1&catalogId=-840&langId=-1
>>Anyone have one of these yet?
> 
> 
> how did you get that IBM url?

http://www.ibm.com/us/

Click - "Products & Sevices"

http://www.ibm.com/products/us/

Click - "Notebooks"

http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?storeId=1&catalogId=-840&langId=-1&categoryId=2035724

Click - "T Series" on left of page

http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=2072541&storeId=1&catalogId=-840&langId=-1&dualCurrId=73

Click - "View all models"

http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=2049168&storeId=1&catalogId=-840&langId=-1

/waste time




From adam at cfar.umd.edu  Wed Jun 16 15:47:01 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Wed Jun 16 15:47:01 2004
Subject: Linux Centrino Notebook
In-Reply-To: <40D0B501.8080000@onelabs.com>
Message-ID: <20040616171212.I14638-100000@www.missl.cs.umd.edu>

so there's no proof that those notebooks listed here are the same ones as
the ones listed at Register as "Tier 1" notebooks :-(

On Wed, 16 Jun 2004, Bari Ari wrote:

> Adam Sulmicki wrote:
> >>http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=2049168&storeId=1&catalogId=-840&langId=-1
> >>Anyone have one of these yet?
> >
> >
> > how did you get that IBM url?
>
> http://www.ibm.com/us/
>
> Click - "Products & Sevices"
>
> http://www.ibm.com/products/us/
>
> Click - "Notebooks"
>
> http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?storeId=1&catalogId=-840&langId=-1&categoryId=2035724
>
> Click - "T Series" on left of page
>
> http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=2072541&storeId=1&catalogId=-840&langId=-1&dualCurrId=73
>
> Click - "View all models"
>
> http://www-132.ibm.com/webapp/wcs/stores/servlet/CategoryDisplay?categoryId=2049168&storeId=1&catalogId=-840&langId=-1
>
> /waste time
>
>



From bari at onelabs.com  Wed Jun 16 16:04:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Jun 16 16:04:00 2004
Subject: Linux Centrino Notebook
In-Reply-To: <20040616171212.I14638-100000@www.missl.cs.umd.edu>
References: <20040616171212.I14638-100000@www.missl.cs.umd.edu>
Message-ID: <40D0BBAE.6060705@onelabs.com>

Adam Sulmicki wrote:

> so there's no proof that those notebooks listed here are the same ones as
> the ones listed at Register as "Tier 1" notebooks :-(

http://www-1.ibm.com/press/PressServletForm.wss?MenuChoice=pressreleases&TemplateName=ShowPressReleaseTemplate&SelectString=t1.docunid=7163&TableName=DataheadApplicationClass&SESSIONKEY=any&WindowTitle=Press+Release&STATUS=publish






From mdeschamps at mangrove-systems.com  Thu Jun 17 07:34:00 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Thu Jun 17 07:34:00 2004
Subject: Doc translation
In-Reply-To: <2F6C5209-BE32-11D8-B076-0003931B4D6A@gnat.ca>
References: <2F6C5209-BE32-11D8-B076-0003931B4D6A@gnat.ca>
Message-ID: <1087461314.27196.29.camel@Calliphara>

Le lun 14/06/2004 ? 20:39, Nathanael Noblet a ?crit :
> On Monday, June 14, 2004, at 04:54 AM, Mathieu Deschamps wrote:
> 
> > Hello LinuxBiosers,
> >
> > I have finish my reporting activities, i'am submiting
> > my work. It is has been done during my training period of
> > 2 months or so. This was a short time and maybe I'am not
> > experimenced enough to give something to more experimenced people,
> > but maybe not ;)
> >
> 
> Um wow!, I don't know if anyone else downloaded and started reading 
> that (I don't know who knows french on this list). In anycase, 
> Mathieu's "summary" of LinuxBIOS is 91 pages long and 19 000 words. 
> It'll take a little while to translate completely. I've done a couple 
> pages so far, but can't do this on a full time basis, so it'll be 
> awhile before its all done.


h?h? who ever said it was a summary ? 
it is rather a 'complete' study Linuxbios and embedding, that's why
that's 90 pages.
The first thing I've learn from Linuxbios is :
'You got to like reading or at least not be disgusted by grepping into
 mailarchive' 

ain't it so ? 

Seriously as a study there's my research path explanations and stuffs 
that no one care here : i've started from nothing.

In my avant-propos (forewords), I said that (roughly)

"[...] I try to write this document taking into consideration
3 types of readers : mangrove developpers, linuxbios community,
university teachers. "

...that's is true but some pages could be overlapped or dropped.


Some part that would be of low interest for us have to be dropped for
it looks like um ...no so monolitic.

	the section in 'L'Etude' called 'Organisation' is one of theses.
	the section in 'L'Etude' called 'Etude de faisabilit?' just explains to
non initiate the pros and cons Linuxbios has.

It already saves some pages.

Moreover, Nathanael see the positive of that :
You needn't translate some chart that are already in english :)


mathieu


From matt at rolec.ltd.uk  Thu Jun 17 08:30:01 2004
From: matt at rolec.ltd.uk (Matt Jarvis)
Date: Thu Jun 17 08:30:01 2004
Subject: Has anyone heard about EPIA MII FastBoot ROM Utility? < GPL Issue
In-Reply-To: <20040616164845.B14638-100000@www.missl.cs.umd.edu>
References: <20040616164845.B14638-100000@www.missl.cs.umd.edu>
Message-ID: <40D1A239.8090602@rolec.ltd.uk>

This wouldn't surprise me. Via did the same with the Waste sources, 
built their own version for the PadlockSL utility without mention of the 
fact it was GPL Waste source based. They withdrew the code from their 
webpage when it was put to them that it was a GPL infringement. They 
dont seem to understand the concept of the GPL very well.


Adam Sulmicki wrote:
>>I'm trying to boot from the CF reader on the VIA Epia platform. After
>>reading forums and mailinglist this could be possible by the FastBoot
>>Utility.
>>
>>http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
>>
>>But I was a bit surpriced what I found in there...
>>grep linux `find` and look at the 'loader*.obj'-files.
>>
>>
>>Can somebody confirm this is _not_ distributed GPL code as a binary?
> 
> 
> fyi, you can get to this page from :
> 
> 	http://www.viaarena.com/?PageID=343
> 
> you can do:
> 	wget http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
> 	unzip fastboot%20v2.01.zip
>   	strings */*/loader?.obj | grep -i linux
> 
> it gives you stuff like :
> 
> _linuxbios_versionR
> _linuxbios_extra_versionX
> _linuxbios_build`
> _linuxbios_compile_timef
> _linuxbios_compile_byp
> _linuxbios_compile_hostv
> _linuxbios_compile_domainz
> _linuxbios_compiler~
> _linuxbios_linker
> _linuxbios_assembler
> 
> 
> etc, etc.
> 
> also that http page mentioned above has contact info. perhaps something to
> inquire at.
> 
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios

-- 
Matt Jarvis
Technical Development Manager
Rolec Music Ltd
210 Belgravia Works, Marlborough Road, London, UK N19 4NF
Tel: +44 207 281 4776 Fax : +44 207 281 4565
mailto: matt at rolec.ltd.uk
web: www.rolecmusic.com

This email is strictly confidential and intended solely for the
addressee(s). It may contain personal and confidential information and
as such may be protected by the Data Protection Act 1998. If this email
has come to you in error you must take no action based on it, nor must
you copy or show it to anyone; please reply to this email and highlight
the error.

Any views or opinions expressed within this email are those of the
author, and do not necessarily represent those of the company.

Although we have taken steps to ensure that this email and attachments
are free from any virus, we advise that in keeping with good computer
practice the recipient should ensure they are actually virus free.


From skinkie at xs4all.nl  Thu Jun 17 09:05:00 2004
From: skinkie at xs4all.nl (Stefan de Konink)
Date: Thu Jun 17 09:05:00 2004
Subject: Has anyone heard about EPIA MII FastBoot ROM Utility? < GPL
 Issue
In-Reply-To: <40D1A239.8090602@rolec.ltd.uk>
Message-ID: <20040617161456.B29832-100000@xs1.xs4all.nl>

Today I discussed it with a collegue of me. He said it is the way you
bring this to VIA, if there is any force, like they do when you infridge
their patents, it just disappears from their website.
At the moment they claim to give a OEM (or a end user) source code (one C
file with compile instructions for VC++ 1.5 (!)).
Probably someone should gently point out that what they give is object
code. And with the question if the want to participate in the LinuxBIOS
code, source for the VGA initialisation for example :)

Two months ago I had basically the same problem with Acer (BenQ) about
their AccessPoints basically they did the same thing as Linksys. With the
new products they got Wind River...
The FSF coundn't do anything because there was no link to find except for
the Linux Kernel.

So I presume the EPIA-toyers like the FastBios product the same als the
LinuxBIOS project. Though the LinuxBIOS claims to be unstable for the
board (sounds scary) while 'their' VIA building provides a 'working'
package based on LinuxBIOS.

Is anybody of the developers group able to take some action?


Stefan

On Thu, 17 Jun 2004, Matt Jarvis wrote:

> This wouldn't surprise me. Via did the same with the Waste sources,
> built their own version for the PadlockSL utility without mention of the
> fact it was GPL Waste source based. They withdrew the code from their
> webpage when it was put to them that it was a GPL infringement. They
> dont seem to understand the concept of the GPL very well.
>
>
> Adam Sulmicki wrote:
> >>I'm trying to boot from the CF reader on the VIA Epia platform. After
> >>reading forums and mailinglist this could be possible by the FastBoot
> >>Utility.
> >>
> >>http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
> >>
> >>But I was a bit surpriced what I found in there...
> >>grep linux `find` and look at the 'loader*.obj'-files.
> >>
> >>
> >>Can somebody confirm this is _not_ distributed GPL code as a binary?
> >
> >
> > fyi, you can get to this page from :
> >
> > 	http://www.viaarena.com/?PageID=343
> >
> > you can do:
> > 	wget http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
> > 	unzip fastboot%20v2.01.zip
> >   	strings */*/loader?.obj | grep -i linux
> >
> > it gives you stuff like :
> >
> > _linuxbios_versionR
> > _linuxbios_extra_versionX
> > _linuxbios_build`
> > _linuxbios_compile_timef
> > _linuxbios_compile_byp
> > _linuxbios_compile_hostv
> > _linuxbios_compile_domainz
> > _linuxbios_compiler~
> > _linuxbios_linker
> > _linuxbios_assembler
> >
> >
> > etc, etc.
> >
> > also that http page mentioned above has contact info. perhaps something to
> > inquire at.
> >
> >
> >
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
>
> --
> Matt Jarvis
> Technical Development Manager
> Rolec Music Ltd
> 210 Belgravia Works, Marlborough Road, London, UK N19 4NF
> Tel: +44 207 281 4776 Fax : +44 207 281 4565
> mailto: matt at rolec.ltd.uk
> web: www.rolecmusic.com
>
> This email is strictly confidential and intended solely for the
> addressee(s). It may contain personal and confidential information and
> as such may be protected by the Data Protection Act 1998. If this email
> has come to you in error you must take no action based on it, nor must
> you copy or show it to anyone; please reply to this email and highlight
> the error.
>
> Any views or opinions expressed within this email are those of the
> author, and do not necessarily represent those of the company.
>
> Although we have taken steps to ensure that this email and attachments
> are free from any virus, we advise that in keeping with good computer
> practice the recipient should ensure they are actually virus free.
>



From bari at onelabs.com  Thu Jun 17 11:22:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Jun 17 11:22:00 2004
Subject: More EFI Stories
Message-ID: <40D1CB41.4060006@onelabs.com>

http://www.kernelthread.com/publications/firmware/

http://developers.slashdot.org/article.pl?sid=04/06/17/1222234

I feel the pain already.




From kok at surfbest.net  Thu Jun 17 12:26:00 2004
From: kok at surfbest.net (Jan Kok)
Date: Thu Jun 17 12:26:00 2004
Subject: current available doc
In-Reply-To: <Pine.LNX.4.44.0406151358420.12326-100000@maxroach.lanl.gov>
Message-ID: <000101c45493$cc25ede0$1601a8c0@Dell1>

I just came across a 32-pin DIP to 32-pin PLCC adapter that might work
for plugging a DOC into a motherboard with a PLCC socket for the BIOS
chip.

It's the ADP-32PLCC at
http://www.emutec.com/pjetadpt.html

The price is $95 at http://www.embeddedtools.net/ETN_Old/promjet.htm

Cheers,
- Jan

> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of ron minnich
> Sent: Tuesday, June 15, 2004 1:59 PM
> To: Wayne Isaacs
> Cc: linuxbios at clustermatic.org
> Subject: Re: current available doc
> 
> On Tue, 15 Jun 2004, Wayne Isaacs wrote:
> 
> > Is there still a DOC in production which plugs directly into the ROM
> socket?
> 
> 
> there is not "the" ROM socket, so your question is hard to answer. But
> yes, there are some mobos left (I THINK) that will take a DOC. Very
few,
> however.
> 
> thanks
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios




From kfuchs at winternet.com  Thu Jun 17 17:44:01 2004
From: kfuchs at winternet.com (Ken Fuchs)
Date: Thu Jun 17 17:44:01 2004
Subject: Future support for Nvidia "Crush" CK8-04 (AMD-8111 replacement plus)?
Message-ID: <200406172310.i5HNAIt9011107@tundra.winternet.com>

Hi,

The "Crush" CK8-04 is an interesting AMD-8111 "replacement" that adds
PCI Express x20, USB 2.0, SATA-150, GbE, 24-bit 96KHz 7.1 audio to
what the AMD-8111 provides (broken USB 2.0):

http://www.xbitlabs.com/news/chipsets/display/20040405142953.html

Is anyone out there interested in LinuxBIOS support for this chip?

What are the prospects of LinuxBIOS supporting this chip?

Iwill which has been working with Nvdia on this chip will release its
dual Opteron mainboard DK8E based on the CK08-04 in August/Sept:

http://www.xbitlabs.com/news/chipsets/display/20040526125019.html

Sincerely,

Ken Fuchs <kfuchs at winternet.com>


From rminnich at lanl.gov  Thu Jun 17 17:59:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun 17 17:59:00 2004
Subject: Future support for Nvidia "Crush" CK8-04 (AMD-8111 replacement
 plus)?
In-Reply-To: <200406172310.i5HNAIt9011107@tundra.winternet.com>
Message-ID: <Pine.LNX.4.44.0406171724410.6067-100000@maxroach.lanl.gov>

On Thu, 17 Jun 2004, Ken Fuchs wrote:

> Is anyone out there interested in LinuxBIOS support for this chip?

yes, there is a lot of interest. 

> What are the prospects of LinuxBIOS supporting this chip?

it's up to nvidia. No word yet that I know of. 

> Iwill which has been working with Nvdia on this chip will release its
> dual Opteron mainboard DK8E based on the CK08-04 in August/Sept:

neat. Let's hope for the best.

ron



From YhLu at tyan.com  Thu Jun 17 21:32:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Jun 17 21:32:00 2004
Subject: =?gb2312?B?tPC4tDogRnV0dXJlIHN1cHBvcnQgZm9yIE52aWRpYSAiQ3J1c2gi?=
	=?gb2312?B?IENLOC0wNCAoQU1ELTgxMTEgcmVwbGFjZW1lbnQgcGx1cyk/?=
Message-ID: <3174569B9743D511922F00A0C9431423055357F3@TYANWEB>

Don't worry. Maybe before you get the MB, the LinuxBIOS for the chipset is
ready, but it's in Tyan MB (S2895).  Nvdia has promised to us that it will
help us to get it done.

Regards

YH

-----????-----
???: Ken Fuchs [mailto:kfuchs at winternet.com] 
????: Thursday, June 17, 2004 4:10 PM
???: linuxbios at clustermatic.org
??: Future support for Nvidia "Crush" CK8-04 (AMD-8111 replacement plus)?

Hi,

The "Crush" CK8-04 is an interesting AMD-8111 "replacement" that adds
PCI Express x20, USB 2.0, SATA-150, GbE, 24-bit 96KHz 7.1 audio to
what the AMD-8111 provides (broken USB 2.0):

http://www.xbitlabs.com/news/chipsets/display/20040405142953.html

Is anyone out there interested in LinuxBIOS support for this chip?

What are the prospects of LinuxBIOS supporting this chip?

Iwill which has been working with Nvdia on this chip will release its
dual Opteron mainboard DK8E based on the CK08-04 in August/Sept:

http://www.xbitlabs.com/news/chipsets/display/20040526125019.html

Sincerely,

Ken Fuchs <kfuchs at winternet.com>
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From linuxbios at xdr.com  Fri Jun 18 09:01:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Fri Jun 18 09:01:01 2004
Subject: Question about AGP
Message-ID: <200406181426.i5IEQeEL017675@xdr.com>

Is the bios supposed to initialize the AGP registers?

I'm trying to get AGP working for EPIA-M. I'm wondering if linux itself
takes care of everything or whether the bios has to initialize some stuff.

-Dave


From dwh at lanl.gov  Fri Jun 18 09:45:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Jun 18 09:45:01 2004
Subject: Future support for Nvidia "Crush" CK8-04 (AMD-8111 replacement
 plus)?
In-Reply-To: <200406172310.i5HNAIt9011107@tundra.winternet.com>
Message-ID: <Pine.LNX.4.44.0406180904480.2176-100000@ccs-mail.lanl.gov>

Yeah, nVidia's become a major player in the mainboard chipset market in a 
very short time. Unfortunately, they have a bad reputation for sharing 
documentation, but that may change if they wish to survive against 
competitors like Via and Intel.

By the way, both those links gave me 404 errors.

On Thu, 17 Jun 2004, Ken Fuchs wrote:

> Hi,
> 
> The "Crush" CK8-04 is an interesting AMD-8111 "replacement" that adds
> PCI Express x20, USB 2.0, SATA-150, GbE, 24-bit 96KHz 7.1 audio to
> what the AMD-8111 provides (broken USB 2.0):
> 
> http://www.xbitlabs.com/news/chipsets/display/20040405142953.html
> 
> Is anyone out there interested in LinuxBIOS support for this chip?
> 
> What are the prospects of LinuxBIOS supporting this chip?
> 
> Iwill which has been working with Nvdia on this chip will release its
> dual Opteron mainboard DK8E based on the CK08-04 in August/Sept:
> 
> http://www.xbitlabs.com/news/chipsets/display/20040526125019.html
> 
> Sincerely,
> 
> Ken Fuchs <kfuchs at winternet.com>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rminnich at lanl.gov  Fri Jun 18 09:57:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jun 18 09:57:01 2004
Subject: Question about AGP [PMX:#]
In-Reply-To: <200406181426.i5IEQeEL017675@xdr.com>
Message-ID: <Pine.LNX.4.44.0406180922270.14969-100000@maxroach.lanl.gov>

On Fri, 18 Jun 2004, Dave Ashley wrote:

> Is the bios supposed to initialize the AGP registers?
> 
> I'm trying to get AGP working for EPIA-M. I'm wondering if linux itself
> takes care of everything or whether the bios has to initialize some stuff.
> 

which version of linuxbios? V2? 

These are the northbridge agp registers? I thought we maybe did that. 
Ollie?

ron



From firstone5 at hotmail.com  Fri Jun 18 17:12:00 2004
From: firstone5 at hotmail.com (M. Renee Hopkins)
Date: Fri Jun 18 17:12:00 2004
Subject: Question about AGP
Message-ID: <BAY19-F11GXSXCWV8S00005f3ec@hotmail.com>

AGP worked with linuxbios V1 a couple months ago, but didn't seem to go into 
4X, but stayed in 1X I believe.  Also, I tried IVTV, but linuxbios didn't 
set the PCI card to 'bus master'.  Any tips would be appreciated.


I've not tried V2.


>From: Dave Ashley <linuxbios at xdr.com>
>To: linuxbios at clustermatic.org
>Subject: Question about AGP
>Date: Fri, 18 Jun 2004 07:26:40 -0700
>
>Is the bios supposed to initialize the AGP registers?
>
>I'm trying to get AGP working for EPIA-M. I'm wondering if linux itself
>takes care of everything or whether the bios has to initialize some stuff.
>
>-Dave
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios

_________________________________________________________________
Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! 
http://join.msn.click-url.com/go/onm00200362ave/direct/01/



From ollie at lanl.gov  Sat Jun 19 11:02:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Sat Jun 19 11:02:01 2004
Subject: Question about AGP [PMX:#]
In-Reply-To: <Pine.LNX.4.44.0406180922270.14969-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406180922270.14969-100000@maxroach.lanl.gov>
Message-ID: <1087662514.15061.5.camel@exponential.lanl.gov>

On Fri, 2004-06-18 at 09:23, ron minnich wrote:
> On Fri, 18 Jun 2004, Dave Ashley wrote:
> 
> > Is the bios supposed to initialize the AGP registers?
> > 
> > I'm trying to get AGP working for EPIA-M. I'm wondering if linux itself
> > takes care of everything or whether the bios has to initialize some stuff.
> > 
> 
> which version of linuxbios? V2? 
> 
> These are the northbridge agp registers? I thought we maybe did that. 
> Ollie?
> 

The only thing we have to do in LinuxBIOS is allocate MEM resource
for AGP aperature and set the size information in the northbridge
resigters. It is done in K8 but I have no idea if it is done for
the EPIA.

The linux apg driver does almost everything we need to actually use
the agp controller (like setting gart table, 2X v.s. 4X etc.)

Ollie




From stepan at openbios.org  Sun Jun 20 10:57:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Sun Jun 20 10:57:01 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <1087204046.12814.111.camel@Calliphara>
References: <20040608104930.GA6799@openbios.org> <20040610040905.GA24980@ohio.localdomain> <20040611122753.GA14945@openbios.org> <1086971082.4486.117.camel@exponential.lanl.gov> <1087204046.12814.111.camel@Calliphara>
Message-ID: <20040620162342.GB17960@openbios.org>

* Mathieu Deschamps <mdeschamps at mangrove-systems.com> [040614 11:07]:
>  There is another way, to the 2 mentionned there after (fore admitting
> the second is a one :)
> 
>  As payload can be distant or local, why not handling payloads as modern
>  network handles packets ? I know this could sound wierd or crazy but to
>  my sense it is not.
 
This sounds interesting. How would that work? It's possible to load
remote payloads with etherboot. Is that what you mean?

>  and I too, have to say sorry if I confused the thing, but i feel like
> this needed to be said.

I appreciate your sometimes flowery way of describing things even if it
is hard for me to follow (which is due to my lack of french knowledge,
when it comes down to your fine document)

Stefan


From kfuchs at winternet.com  Mon Jun 21 10:08:01 2004
From: kfuchs at winternet.com (Ken Fuchs)
Date: Mon Jun 21 10:08:01 2004
Subject: AMD64 emulators and other hardware based LinuxBIOS developing tools
Message-ID: <200406211534.i5LFYbJt007134@tundra.winternet.com>

I'm looking for a good/adequate tool for LinuxBIOS software
integration/development for dual Opteron mainboards.

The American Arium has recently added AMD64 support to their ECM-50
emulator.  I've heard that the ECM-50 is $11K plus $4K for AMD64
module and $1.5K for support for a total of $16.5K.  I've looked for
other AMD64 emulators, but didn't find any.  Are there cheaper AMD64
emulators?

Something less than an in-circuit emulator may suffice.  Maybe a bus
analyzer that simply filters and records bus signals on the mainboard.
The bus analyzed could be the processor bus, PCI bus, etc.

I'm looking for at least a POST card.  Maybe a POST card with extra
features.

I suppose even a processor adapter that allows processor pins to be
probed with a logic analyzer might do as well.

What hardware tools (emulators, bus analyzers, POST card, etc.) would
you recommend for LinuxBIOS integration/development for dual Opteron
mainboards?

------

Thank you Ron, YH and David for your comments concerning Nvidia CK8-04
support in LinuxBIOS!  It was/is most appreciated!

Sincerely,

Ken Fuchs <kfuchs at winternet.com>


From mdeschamps at mangrove-systems.com  Mon Jun 21 10:25:00 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Mon Jun 21 10:25:00 2004
Subject: [PROPOSAL] extended payload handling
In-Reply-To: <20040620162342.GB17960@openbios.org>
References: <20040608104930.GA6799@openbios.org>
	 <20040610040905.GA24980@ohio.localdomain>
	 <20040611122753.GA14945@openbios.org>
	 <1086971082.4486.117.camel@exponential.lanl.gov>
	 <1087204046.12814.111.camel@Calliphara>
	 <20040620162342.GB17960@openbios.org>
Message-ID: <1087832172.11291.216.camel@Calliphara>

Le dim 20/06/2004 ? 18:23, Stefan Reinauer a ?crit :
> * Mathieu Deschamps <mdeschamps at mangrove-systems.com> [040614 11:07]:
> >  There is another way, to the 2 mentionned there after (fore admitting
> > the second is a one :)
> > 
> >  As payload can be distant or local, why not handling payloads as modern
> >  network handles packets ? I know this could sound wierd or crazy but to
> >  my sense it is not.
>  
> This sounds interesting. How would that work? It's possible to load
> remote payloads with etherboot. Is that what you mean?

Brief State:
No but that's quite in the view, like the a modular approch.

Complete State:
IMHO, with what i've seen and read, I consider not the payload simply
as just an OS ...and well that the topic : extended payload handling. 

So maybe you'll say that now i've seek to far in the way. Ok, that makes
some reading but : 

-It is wide scaled and borrows from the good suggestions/needs of every
one.
 
-This design is really worthy when networking and if local,it needs some
sort of loopback. But it is admitted it networks.

-So... not oriented... but in favor of clustering and embedding rather
than others : anyway theses are the main application I think ?


 Let's move in deeper:
    
It seems clear it  to clarify the payload thing, even before saying we
are going to extend the payload handling.

During my works i couln't find clearly a definition of payload or rather
limitations. If I digested it well, actually, a payload is a polymorph
container of what is not Linuxbios-seemingly.

Moreover, it seems underway, drafts making almost everything a payload,
there is pro and cons, but i like this idea, suggest vastness...

Generally speaking, the good side is a part of project that's not
defined, has illimited lifetime, because it'll morph and adapt to
current needs. 

The bad is in the pratical coding and designing, that swinging nature
pouring into this needs/fonctions or that needs/fonctions leads to
unconstance properties, and this undef is bad to 'computing' common
sense :). It has to have some stablity to prevent deprecation.

The payload is some kind of concept that needs definition, to seize its
properties to fix them down. Ok enough foresaying, some of my
proposition are truely science fiction rather than operationnal, but
other don't. 

 			DRAFT EXTENDED PAYLOAD

 I see four... five properties for now :
	1-  Where/Spread   	  : internal, local or distant.
		its nature is pure internal to linuxbios or
		is local to machine or has networking capacities
		(single hardware component sharing : realtime payload 		 servers)

	2-  Who/Nature   	  : OS, BOOTLOADER or Core Program.
		A core program could be a bios hardware component init. code
(linuxbios components) or to-end-finality program like a
securisation/authentification protocole before booting OS.		

	3-  When/How long/Lifetime: 
		*Once  : instant use and kill and overwrite memory,
		*TSR   : instant use and teminated but memory reserved, 
		*Illimited : a real bios service (e.g.IRQ) always alife, 			    
memory reserved
	4-  How/Ressources	  : pure volatile, LB tables, distant. 
	5-  How deep/Intensity	  : raw i/o or bios init

 This properties combines to will to suit every needs.

 Basically, as suggested Ollie there is a Kernel, rather a core and...

	' - do we want to put and link
        everything into one program or as seperated PAYLOADs
        (processes/servers?) and use some complicated Inter Payload
        Communiction (IPC) to exachange information and reuse 
        implementation?'

... Yes shortly, that's what i like.

    It needs IPC or rather a abstract payload layer with a somehow
communication based upon the Linuxbios Table. Not as heavy as IPC but i
feel no shame getting inspired by that strong accredited
fondation?

    	The core has a programmed (boot sequence) tasklist definied for
example in the config file (with a somewhat order). So basically, you'll
asked the core to wait uppon the arrival of the payload containing the
code that initialize the controler, that boot the OS, or that is the OS.

	Whether it come from distant packets sendings or local. Ok for
now it is pure local-local... But in the near future ?  bootloader/Os
chain in Etherboot  is already distant and that a clue. The paylaod
architecture i propose should thus integrate this idea.

 Today's Pros    : some piece modular, somewhat easy to set but hard to
		   port
'Potential' Pros : interoperability, self-determined, 'intelligence'.

	Look by the time the Real Time Clock is set, it could know, after a
defined timeout has expired (because it cannot do it with local
ressource), that this core componant (core program ?) it tries to
initialize, has been done, onto another server. 

	Ok that lead to some fiction but that we are not that far of... so
maybe if the lan controler is init, and inter lxbios request layer (to
my mind here would be the real comparison with IPC) is set it could ask
to the foresaid server some assistance ? Why not reduce port to the
maximun and centalized it in the core ?

	But back to ground, the core indeed should contain memory managment,
cpu managment and  basic io to pci bridge, the rest should be modules
that are loaded upon linuxbios config file tweakings.

	Truely (a little) less that LB's core part does for now, so that there
would be low in-trash and full reuse and encapsulation. And the core
will have hat abstract payload layer that understand those declinaisons.


Fo examples, some scenarii and their corresponding attributions : 
	*You like your Linuxbios to initialize your SCSI controler :
		1- Internal (a Linuxbios component)
		2- Core Program (a module)
		3- Once (to boot os and then the kernel redo SCSI)
		4- volatile (here because once)
		5- bios init
	*You like it to init your graph chipset in order to display
	a linuxbios splashscreen.
		1- local
		2- Core Program
		3- Once/TSR depending what OS will set then
		4- volatile/LB table
		5- raw i/o or bios full init
	*You like to choose etherboot to be you bootloader it is
		1- distant
		2- bt ldr
		3- depends if you what to have some session like
		handling but normally it should be Once
		4- LB table/distant
		5- raw i/o or bios init


ok, anyway it is a draft... again that
is long ...


mathieu.



> 
> >  and I too, have to say sorry if I confused the thing, but i feel like
> > this needed to be said.
> 
> I appreciate your sometimes flowery way of describing things even if it
> is hard for me to follow (which is due to my lack of french knowledge,
> when it comes down to your fine document)

 ha ah.. Thanks.. i'am part of people that thinks, 'smiling' while
reading a 90 pages long technical document is not a luxury...
it is a compulsary ;)

> 
> Stefan
> 


From YhLu at tyan.com  Mon Jun 21 12:25:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Jun 21 12:25:00 2004
Subject: E7501 support in V2
Message-ID: <3174569B9743D511922F00A0C94314230553587C@TYANWEB>

Eric,

I finish the translate raminit.inc to E7501. But in compiling stage, it used
up the regs.

In the K8, there is enable_mmx_sse.inc to enable cpu access more regs for
romcc.

So the problem is
1. Can I use the enable_mmx_sse.inc for Xeon without change? It has MMX and
sse too.

2. how about the romcc cpu flag. Or just use -mcpu=k8?

Regards


YH


From leo.currie at strath.ac.uk  Tue Jun 22 04:13:01 2004
From: leo.currie at strath.ac.uk (Leo Currie)
Date: Tue Jun 22 04:13:01 2004
Subject: PCChips M810
Message-ID: <40D7FE42.1090804@strath.ac.uk>

Hello list.

Is it still possible to build for the PC-Chips M810LR?
I have been looking at the instructions here:
http://www.linuxbios.org/developer/portguides/M810LR/index.html
but they seem quite out of date.

Thanks.

Leo



From rminnich at lanl.gov  Tue Jun 22 08:53:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun 22 08:53:00 2004
Subject: PCChips M810
In-Reply-To: <40D7FE42.1090804@strath.ac.uk>
Message-ID: <Pine.LNX.4.44.0406220819220.24696-100000@maxroach.lanl.gov>

they're out of data but may still work. 

I thought that board was dead ...

ron



From linuxbios at xdr.com  Tue Jun 22 09:11:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Tue Jun 22 09:11:01 2004
Subject: Question about AGP
Message-ID: <200406221437.i5MEbS5L011966@xdr.com>

Regarding the EPIA-M, I've determined more about the situation. The CLE266
comes up with the AGP memory area mapped at 0, but AGP is disabled. The
actual memory area is defined by pci device 00.0 memory resource #0 at offset
$10 in pci config space. When linuxbios goes to try to assign space for this,
it gives up after it decides the resource is read-only.

What's happening is the bit to enable AGP (00.0 byte $88 bit 1) if set to
0 causes the upper 4 bits of the longword at $10 to always read back 0.
So in order to actually configure that region you need to set the bit to 1.
But if you set the bit to 1 and the region is still set to the default value
of 0 the system locks up because you're now stepping on RAM.

So to initialize agp on epia-m you need to
1) Write some safe value to the memory region at 00.0 offset $10, say
$e0000000. It won't read back as $e0000000, it'll still read back as $00000000.
2) Enable 00.0 byte $88 bit 1 (bits go from 0 to 7)
3) Set graphics aperture size to 128 mbytes by writing $80 to 00.0 byte $84.
4) Fall through to normal pci resource allocation

I haven't implemented this yet within linuxbios V1 but I will try it out and
post again.

-Dave


From dwh at lanl.gov  Tue Jun 22 10:28:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Tue Jun 22 10:28:00 2004
Subject: PCChips M810
In-Reply-To: <Pine.LNX.4.44.0406220819220.24696-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.44.0406220953400.2176-100000@ccs-mail.lanl.gov>

It appears that it's been discontinued. It's based on the antiquated 
SiS730 chipset.

On Tue, 22 Jun 2004, ron minnich wrote:

> they're out of data but may still work. 
> 
> I thought that board was dead ...
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From linuxbios at xdr.com  Tue Jun 22 13:38:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Tue Jun 22 13:38:00 2004
Subject: Question about AGP (epia-m)
Message-ID: <200406221905.i5MJ5G7i013320@xdr.com>

>I haven't implemented this yet within linuxbios V1 but I will try it out and
>post again.

It's pretty irritating. When I turn 00.0 byte $88 bit 1 to 1, the MB
locks up. Turning that bit on enables the graphics aperture. I'm going to
just do it in a userspace program, which works fine.

I can put this in V1 src/mainboard/via/epia-m/earlysetup.inc at the top:
// set AGP aperture size to 128M
	movl	$CONFIG_ADDR(0, 0x00, 0x84), %eax
	movb	$0x80, %dl
	PCI_WRITE_CONFIG_BYTE
// enable AGP
	movl	$CONFIG_ADDR(0, 0x00, 0xa9), %eax
	movb	$0x01, %dl
	PCI_WRITE_CONFIG_BYTE
// Move AGP to safe place before enabling
	movl	$CONFIG_ADDR(0, 0x00, 0x10), %eax
	movl	$0xe0000000,%edx
	PCI_WRITE_CONFIG_DWORD

However if I follow this with
	movl	$CONFIG_ADDR(0, 0x00, 0x88), %eax
	movb	$2,%dl
	PCI_WRITE_CONFIG_BYTE

Then it locks up. I had thought it might be because the GART is supposed
to be in system memory, so if I try and turn it on before DRAM is ready, the
AGP system might try to read a page of the GART into its cache, and this
results in a fault since the memory isn't there. So I tried doing the last
turn on bit later after DRAM is initialized, but that didn't help.

-Dave


From mrobinson at fuzzymuzzle.com  Tue Jun 22 22:10:01 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Tue Jun 22 22:10:01 2004
Subject: Porting Linux BIOS
Message-ID: <40D8FA35.8060706@fuzzymuzzle.com>

Hello,

How much modification is typically involved in porting LinuxBIOS to a 
currently unsupported motherboard?  I'd like to attempt (keyword) to do 
this on a motherboard not listed on your site.  The major modifications 
are supporting the chipset and the memory type if they're not already 
supported, correct?  Anyways, I'm going to attempt this and may (will) 
be asking for further help at later dates, LOL.

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com



From YhLu at tyan.com  Tue Jun 22 22:35:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun 22 22:35:00 2004
Subject: E7501 support in V2
Message-ID: <3174569B9743D511922F00A0C943142305535955@TYANWEB>

After change some variable to const, the auto.c can be compiled.

Any one would like to help to check the code? Steven James?

Regards

YH

-----????-----
???: YhLu 
????: 2004?6?21? 10:54
???: ebiederman at lnxi.com
??: ron minnich; Stefan Reinauer; LinuxBIOS
??: E7501 support in V2

Eric,

I finish the translate raminit.inc to E7501. But in compiling stage, it used
up the regs.

In the K8, there is enable_mmx_sse.inc to enable cpu access more regs for
romcc.

So the problem is
1. Can I use the enable_mmx_sse.inc for Xeon without change? It has MMX and
sse too.

2. how about the romcc cpu flag. Or just use -mcpu=k8?

Regards


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


From rminnich at lanl.gov  Tue Jun 22 23:52:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jun 22 23:52:00 2004
Subject: Porting Linux BIOS
In-Reply-To: <40D8FA35.8060706@fuzzymuzzle.com>
Message-ID: <Pine.LNX.4.44.0406222318520.32104-100000@maxroach.lanl.gov>

it depends on the chipset type. Can you give us some lspci output and we 
can see what is possible?

ron



From mrobinson at fuzzymuzzle.com  Wed Jun 23 00:04:01 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Wed Jun 23 00:04:01 2004
Subject: Porting Linux BIOS
In-Reply-To: <Pine.LNX.4.44.0406222318520.32104-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0406222318520.32104-100000@maxroach.lanl.gov>
Message-ID: <40D91511.2010701@fuzzymuzzle.com>

Ron,

I'm not sure what mobo I'm going to use yet, before I buy one I want to 
make sure it's at least reasonably possible to get LinuxBIOS running on 
it.  I've heard that the Asus SiS mobos won't work because of the flash 
chip.  Is this just because of the pinout or is it because of actual 
software compatibility.  I can always solder my own socket onto the 
board if necessary.  I've been looking at the Asus boards and most of 
the compatible boards on your site seem to use the SiS chipset that many 
of the Asus's do.  Can you give me any insight on the chip compatibility 
problem?  Most of the SiS chips in the Asus boards seem very close in 
model number to the ones you guys have got working.

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com

ron minnich wrote:

>it depends on the chipset type. Can you give us some lspci output and we 
>can see what is possible?
>
>ron
>
>
>
>
>  
>



From mdeschamps at mangrove-systems.com  Wed Jun 23 03:33:01 2004
From: mdeschamps at mangrove-systems.com (Mathieu Deschamps)
Date: Wed Jun 23 03:33:01 2004
Subject: Doc translation
In-Reply-To: <1087461314.27196.29.camel@Calliphara>
References: <2F6C5209-BE32-11D8-B076-0003931B4D6A@gnat.ca>
	 <1087461314.27196.29.camel@Calliphara>
Message-ID: <1087980333.11291.224.camel@Calliphara>

Hello

I'am going off for a moment for the dev. but i will go on
following work and talking of LinuxBios. keep this up   :)
if you want to contact me please cc, mathdesc at yahoo dot fr 

later.
mathieu


From rminnich at lanl.gov  Wed Jun 23 08:12:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jun 23 08:12:01 2004
Subject: Porting Linux BIOS
In-Reply-To: <40D91511.2010701@fuzzymuzzle.com>
Message-ID: <Pine.LNX.4.44.0406230737520.3121-100000@maxroach.lanl.gov>

don't plan to solder flash parts and sockets on and off. For some parts it 
is almost impossible. 

The issue with Asus is not the flash part anyway, it's the hidden bits 
that control important functions like SPD. 

Any reason not to just go to tyan or cwlinux.com and buy a board with 
linuxbios installed?

ron



From rsmith at bitworks.com  Wed Jun 23 10:58:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Wed Jun 23 10:58:01 2004
Subject: Resource Allocation for Option Rom
In-Reply-To: <m3fz9lnnie.fsf@maxwell.lnxi.com>
References: <1085687516.5653.51.camel@exponential.lanl.gov>	<m3d64ptylq.fsf@maxwell.lnxi.com>	<1085690660.5653.72.camel@exponential.lanl.gov> <m3fz9lnnie.fsf@maxwell.lnxi.com>
Message-ID: <40D9AED6.608@bitworks.com>

Eric W. Biederman wrote:

> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> 
>>On Thu, 2004-05-27 at 14:16, Eric W. Biederman wrote:
>>
>>>We could probably reserve a hole for this purpose, which
>>>is a good idea except for bridges. 
>>>
>>
>>Can we just treat it as MEM resource and reuse the MEM resource
>>allocation code ?
> 
> 
> Yes that would be the easy way to reserver an area for the rom
> to be enabled.  If the BAR is not large this should not be a problem.
>  

Did this happen?  I'm trying to get a plug in PCI video card up with 
ADLO and I need the option rom to be enabled.  I can do it direcly in my 
mainboard code for a hack but If there was anything to test I though I 
would try.





From ollie at lanl.gov  Wed Jun 23 13:20:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Jun 23 13:20:01 2004
Subject: Resource Allocation for Option Rom
In-Reply-To: <40D9AED6.608@bitworks.com>
References: <1085687516.5653.51.camel@exponential.lanl.gov>
	 <m3d64ptylq.fsf@maxwell.lnxi.com>
	 <1085690660.5653.72.camel@exponential.lanl.gov>
	 <m3fz9lnnie.fsf@maxwell.lnxi.com>  <40D9AED6.608@bitworks.com>
Message-ID: <1088016424.8331.2.camel@exponential.lanl.gov>

On Wed, 2004-06-23 at 10:24, Richard Smith wrote:
> Eric W. Biederman wrote:
> 
> > Li-Ta Lo <ollie at lanl.gov> writes:
> > 
> > 
> >>On Thu, 2004-05-27 at 14:16, Eric W. Biederman wrote:
> >>
> >>>We could probably reserve a hole for this purpose, which
> >>>is a good idea except for bridges. 
> >>>
> >>
> >>Can we just treat it as MEM resource and reuse the MEM resource
> >>allocation code ?
> > 
> > 
> > Yes that would be the easy way to reserver an area for the rom
> > to be enabled.  If the BAR is not large this should not be a problem.
> >  
> 
> Did this happen?  I'm trying to get a plug in PCI video card up with 
> ADLO and I need the option rom to be enabled.  I can do it direcly in my 
> mainboard code for a hack but If there was anything to test I though I 
> would try.
> 
> 

How is testbios doing on your side ?

Ollie




From dwh at lanl.gov  Wed Jun 23 15:43:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Wed Jun 23 15:43:01 2004
Subject: Porting Linux BIOS
In-Reply-To: <40D91511.2010701@fuzzymuzzle.com>
Message-ID: <Pine.LNX.4.44.0406231503540.2176-100000@ccs-mail.lanl.gov>

Right now I'd have to say the best supported mainboards currently are VIA 
EPIA M2 and Opteron mainboards using the AMD8111 southbridge. Asus does weird 
things with their SMbus and hasn't been very cooperative in the past with 
documentation, so I would not recommend that you risk money on them.

Though if you have a high threshold for pain, you can try one of the newer 
VIA chipsets like the KT400 and hope they're generous enough with 
documentation to complete a port. Some other VIA stuff is supported, so 
that might help with a new port.

On Wed, 23 Jun 2004, Michael Robinson wrote:

> Ron,
> 
> I'm not sure what mobo I'm going to use yet, before I buy one I want to 
> make sure it's at least reasonably possible to get LinuxBIOS running on 
> it.  I've heard that the Asus SiS mobos won't work because of the flash 
> chip.  Is this just because of the pinout or is it because of actual 
> software compatibility.  I can always solder my own socket onto the 
> board if necessary.  I've been looking at the Asus boards and most of 
> the compatible boards on your site seem to use the SiS chipset that many 
> of the Asus's do.  Can you give me any insight on the chip compatibility 
> problem?  Most of the SiS chips in the Asus boards seem very close in 
> model number to the ones you guys have got working.
> 
> Thanks,
> Michael Robinson
> mrobinson at fuzzymuzzle.com
> www.fuzzymuzzle.com
> 
> ron minnich wrote:
> 
> >it depends on the chipset type. Can you give us some lspci output and we 
> >can see what is possible?
> >
> >ron
> >
> >
> >
> >
> >  
> >
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From mrobinson at fuzzymuzzle.com  Wed Jun 23 17:19:01 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Wed Jun 23 17:19:01 2004
Subject: Porting Linux BIOS
In-Reply-To: <40D9D726.90302@fuzzymuzzle.com>
References: <Pine.LNX.4.44.0406230737520.3121-100000@maxroach.lanl.gov> <40D9D726.90302@fuzzymuzzle.com>
Message-ID: <40DA0819.3060405@fuzzymuzzle.com>

If it came to that, I could desolder and resolder components (hardware 
hacking/construction is my specialty - http://www.fuzzymuzzle.com).  
What I really want to do though is buy a board on whether it supports my 
needs, not whether it currently supports LinuxBIOS.  I'll check out the 
Tyans and see what they have.

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com

>
> ron minnich wrote:
>
>> don't plan to solder flash parts and sockets on and off. For some 
>> parts it is almost impossible.
>> The issue with Asus is not the flash part anyway, it's the hidden 
>> bits that control important functions like SPD.
>> Any reason not to just go to tyan or cwlinux.com and buy a board with 
>> linuxbios installed?
>>
>> ron
>>
>>
>>
>>
>>  
>>
>
>



From mrobinson at fuzzymuzzle.com  Wed Jun 23 18:42:00 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Wed Jun 23 18:42:00 2004
Subject: Porting Linux BIOS
In-Reply-To: <Pine.LNX.4.44.0406231503540.2176-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0406231503540.2176-100000@ccs-mail.lanl.gov>
Message-ID: <40DA1BAA.3080302@fuzzymuzzle.com>

David,

Are all Via EPIA motherboards fairly well supported or just the EPIA 
M2?  I would assume since the EPIA M2 uses the:

- VIA CLE266 North Bridge
- VIA VT8235 South Bridge

that any of there other EPIA motherboards that use this chipset should 
be fairly compatible.  Am I correct in this assumption or are there 
other important factors that can't be easily fixed?

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com


Hendricks David W. wrote:

>Right now I'd have to say the best supported mainboards currently are VIA 
>EPIA M2 and Opteron mainboards using the AMD8111 southbridge. Asus does weird 
>things with their SMbus and hasn't been very cooperative in the past with 
>documentation, so I would not recommend that you risk money on them.
>
>Though if you have a high threshold for pain, you can try one of the newer 
>VIA chipsets like the KT400 and hope they're generous enough with 
>documentation to complete a port. Some other VIA stuff is supported, so 
>that might help with a new port.
>
>On Wed, 23 Jun 2004, Michael Robinson wrote:
>
>  
>
>>Ron,
>>
>>I'm not sure what mobo I'm going to use yet, before I buy one I want to 
>>make sure it's at least reasonably possible to get LinuxBIOS running on 
>>it.  I've heard that the Asus SiS mobos won't work because of the flash 
>>chip.  Is this just because of the pinout or is it because of actual 
>>software compatibility.  I can always solder my own socket onto the 
>>board if necessary.  I've been looking at the Asus boards and most of 
>>the compatible boards on your site seem to use the SiS chipset that many 
>>of the Asus's do.  Can you give me any insight on the chip compatibility 
>>problem?  Most of the SiS chips in the Asus boards seem very close in 
>>model number to the ones you guys have got working.
>>
>>Thanks,
>>Michael Robinson
>>mrobinson at fuzzymuzzle.com
>>www.fuzzymuzzle.com
>>
>>ron minnich wrote:
>>
>>    
>>
>>>it depends on the chipset type. Can you give us some lspci output and we 
>>>can see what is possible?
>>>
>>>ron
>>>
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Linuxbios mailing list
>>Linuxbios at clustermatic.org
>>http://www.clustermatic.org/mailman/listinfo/linuxbios
>>
>>    
>>
>
>
>
>
>  
>



From mlleinin at hpcn.ca.sandia.gov  Wed Jun 23 18:57:01 2004
From: mlleinin at hpcn.ca.sandia.gov (Matt L. Leininger)
Date: Wed Jun 23 18:57:01 2004
Subject: AMD Opteron bug fix in BIOS
Message-ID: <1088036523.15761.1084.camel@trinity>

The Inquirer is reporting that the Opteron bug announced earlier this
week can be fixed by the BIOS.  AMD has been supportive of LinuxBIOS. 
Anyone know if AMD has supplied the necessary information to get a fix
into LinuxBIOS?

http://www.theinquirer.net/?article=16774
 
 Thanks,

  - Matt



From mrobinson at fuzzymuzzle.com  Wed Jun 23 23:03:00 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Wed Jun 23 23:03:00 2004
Subject: Porting Linux BIOS
In-Reply-To: <Pine.LNX.4.44.0406231503540.2176-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0406231503540.2176-100000@ccs-mail.lanl.gov>
Message-ID: <40DA58B5.8010509@fuzzymuzzle.com>

Lucky for me the after further investigation the EPIA M2 seems to meet 
my requirements perfectly.  I was wondering though, the AMI BIOS that 
comes on the board is used to switch between the video output modes and 
many other hardware features.  Are these settings now configured through 
Linux then since LinuxBIOS does minimal hardware configuration?  Or are 
they still setup in the BIOS (LinuxBIOS), or are they not supported 
currently?

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com

Hendricks David W. wrote:

>Right now I'd have to say the best supported mainboards currently are VIA 
>EPIA M2 and Opteron mainboards using the AMD8111 southbridge. Asus does weird 
>things with their SMbus and hasn't been very cooperative in the past with 
>documentation, so I would not recommend that you risk money on them.
>
>Though if you have a high threshold for pain, you can try one of the newer 
>VIA chipsets like the KT400 and hope they're generous enough with 
>documentation to complete a port. Some other VIA stuff is supported, so 
>that might help with a new port.
>
>On Wed, 23 Jun 2004, Michael Robinson wrote:
>
>  
>
>>Ron,
>>
>>I'm not sure what mobo I'm going to use yet, before I buy one I want to 
>>make sure it's at least reasonably possible to get LinuxBIOS running on 
>>it.  I've heard that the Asus SiS mobos won't work because of the flash 
>>chip.  Is this just because of the pinout or is it because of actual 
>>software compatibility.  I can always solder my own socket onto the 
>>board if necessary.  I've been looking at the Asus boards and most of 
>>the compatible boards on your site seem to use the SiS chipset that many 
>>of the Asus's do.  Can you give me any insight on the chip compatibility 
>>problem?  Most of the SiS chips in the Asus boards seem very close in 
>>model number to the ones you guys have got working.
>>
>>Thanks,
>>Michael Robinson
>>mrobinson at fuzzymuzzle.com
>>www.fuzzymuzzle.com
>>
>>ron minnich wrote:
>>
>>    
>>
>>>it depends on the chipset type. Can you give us some lspci output and we 
>>>can see what is possible?
>>>
>>>ron
>>>
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Linuxbios mailing list
>>Linuxbios at clustermatic.org
>>http://www.clustermatic.org/mailman/listinfo/linuxbios
>>
>>    
>>
>
>
>
>
>  
>



From linuxbios at matter.net  Thu Jun 24 02:35:01 2004
From: linuxbios at matter.net (Larry Matter)
Date: Thu Jun 24 02:35:01 2004
Subject: Has anyone heard about EPIA MII FastBoot ROM Utility? < 
     GPLIssue
In-Reply-To: <20040617161456.B29832-100000@xs1.xs4all.nl>
References: <40D1A239.8090602@rolec.ltd.uk>
    <20040617161456.B29832-100000@xs1.xs4all.nl>
Message-ID: <37239.192.168.1.140.1088064107.squirrel@mail.matter.net>

I asked about this and this is the reply I got:

  After checking with our engineers, we found the source code of VIA Fast
boot ROM
does not contain the GPL source code.
  Only one structure's members definitions are the same as the Linux BIOS.
The
remaining parts are not.
  We think it doesn't break the GPL.

Larry

> Today I discussed it with a collegue of me. He said it is the way you
> bring this to VIA, if there is any force, like they do when you infridge
> their patents, it just disappears from their website.
> At the moment they claim to give a OEM (or a end user) source code (one C
> file with compile instructions for VC++ 1.5 (!)).
> Probably someone should gently point out that what they give is object
> code. And with the question if the want to participate in the LinuxBIOS
> code, source for the VGA initialisation for example :)
>
> Two months ago I had basically the same problem with Acer (BenQ) about
> their AccessPoints basically they did the same thing as Linksys. With the
> new products they got Wind River...
> The FSF coundn't do anything because there was no link to find except for
> the Linux Kernel.
>
> So I presume the EPIA-toyers like the FastBios product the same als the
> LinuxBIOS project. Though the LinuxBIOS claims to be unstable for the
> board (sounds scary) while 'their' VIA building provides a 'working'
> package based on LinuxBIOS.
>
> Is anybody of the developers group able to take some action?
>
>
> Stefan
>
> On Thu, 17 Jun 2004, Matt Jarvis wrote:
>
>> This wouldn't surprise me. Via did the same with the Waste sources,
>> built their own version for the PadlockSL utility without mention of the
>> fact it was GPL Waste source based. They withdrew the code from their
>> webpage when it was put to them that it was a GPL infringement. They
>> dont seem to understand the concept of the GPL very well.
>>
>>
>> Adam Sulmicki wrote:
>> >>I'm trying to boot from the CF reader on the VIA Epia platform. After
>> >>reading forums and mailinglist this could be possible by the FastBoot
>> >>Utility.
>> >>
>> >>http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
>> >>
>> >>But I was a bit surpriced what I found in there...
>> >>grep linux `find` and look at the 'loader*.obj'-files.
>> >>
>> >>
>> >>Can somebody confirm this is _not_ distributed GPL code as a binary?
>> >
>> >
>> > fyi, you can get to this page from :
>> >
>> > 	http://www.viaarena.com/?PageID=343
>> >
>> > you can do:
>> > 	wget http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
>> > 	unzip fastboot%20v2.01.zip
>> >   	strings */*/loader?.obj | grep -i linux
>> >
>> > it gives you stuff like :
>> >
>> > _linuxbios_versionR
>> > _linuxbios_extra_versionX
>> > _linuxbios_build`
>> > _linuxbios_compile_timef
>> > _linuxbios_compile_byp
>> > _linuxbios_compile_hostv
>> > _linuxbios_compile_domainz
>> > _linuxbios_compiler~
>> > _linuxbios_linker
>> > _linuxbios_assembler
>> >
>> >
>> > etc, etc.
>> >
>> > also that http page mentioned above has contact info. perhaps
>> something to
>> > inquire at.
>> >
>> >
>> >
>> > _______________________________________________
>> > Linuxbios mailing list
>> > Linuxbios at clustermatic.org
>> > http://www.clustermatic.org/mailman/listinfo/linuxbios
>>
>> --
>> Matt Jarvis
>> Technical Development Manager
>> Rolec Music Ltd
>> 210 Belgravia Works, Marlborough Road, London, UK N19 4NF
>> Tel: +44 207 281 4776 Fax : +44 207 281 4565
>> mailto: matt at rolec.ltd.uk
>> web: www.rolecmusic.com
>>
>> This email is strictly confidential and intended solely for the
>> addressee(s). It may contain personal and confidential information and
>> as such may be protected by the Data Protection Act 1998. If this email
>> has come to you in error you must take no action based on it, nor must
>> you copy or show it to anyone; please reply to this email and highlight
>> the error.
>>
>> Any views or opinions expressed within this email are those of the
>> author, and do not necessarily represent those of the company.
>>
>> Although we have taken steps to ensure that this email and attachments
>> are free from any virus, we advise that in keeping with good computer
>> practice the recipient should ensure they are actually virus free.
>>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From skinkie at xs4all.nl  Thu Jun 24 03:17:00 2004
From: skinkie at xs4all.nl (Stefan de Konink)
Date: Thu Jun 24 03:17:00 2004
Subject: Has anyone heard about EPIA MII FastBoot ROM Utility? <     
 GPLIssue
In-Reply-To: <37239.192.168.1.140.1088064107.squirrel@mail.matter.net>
Message-ID: <20040624103437.T15738-100000@xs1.xs4all.nl>

Do you agree with them?

My understanding of the GPL is, if you extend a program or use an other
GPL program you must license it as GPL. That is probably also true for
using the same member definitions. imho

Stefan


ps. next to that I find it strange why they even mention FreeBIOS in their
bios... though I hope they open their code anyway.

On Thu, 24 Jun 2004, Larry Matter wrote:

> I asked about this and this is the reply I got:
>
>   After checking with our engineers, we found the source code of VIA Fast
> boot ROM
> does not contain the GPL source code.
>   Only one structure's members definitions are the same as the Linux BIOS.
> The
> remaining parts are not.
>   We think it doesn't break the GPL.
>
> Larry
>
> > Today I discussed it with a collegue of me. He said it is the way you
> > bring this to VIA, if there is any force, like they do when you infridge
> > their patents, it just disappears from their website.
> > At the moment they claim to give a OEM (or a end user) source code (one C
> > file with compile instructions for VC++ 1.5 (!)).
> > Probably someone should gently point out that what they give is object
> > code. And with the question if the want to participate in the LinuxBIOS
> > code, source for the VGA initialisation for example :)
> >
> > Two months ago I had basically the same problem with Acer (BenQ) about
> > their AccessPoints basically they did the same thing as Linksys. With the
> > new products they got Wind River...
> > The FSF coundn't do anything because there was no link to find except for
> > the Linux Kernel.
> >
> > So I presume the EPIA-toyers like the FastBios product the same als the
> > LinuxBIOS project. Though the LinuxBIOS claims to be unstable for the
> > board (sounds scary) while 'their' VIA building provides a 'working'
> > package based on LinuxBIOS.
> >
> > Is anybody of the developers group able to take some action?
> >
> >
> > Stefan
> >
> > On Thu, 17 Jun 2004, Matt Jarvis wrote:
> >
> >> This wouldn't surprise me. Via did the same with the Waste sources,
> >> built their own version for the PadlockSL utility without mention of the
> >> fact it was GPL Waste source based. They withdrew the code from their
> >> webpage when it was put to them that it was a GPL infringement. They
> >> dont seem to understand the concept of the GPL very well.
> >>
> >>
> >> Adam Sulmicki wrote:
> >> >>I'm trying to boot from the CF reader on the VIA Epia platform. After
> >> >>reading forums and mailinglist this could be possible by the FastBoot
> >> >>Utility.
> >> >>
> >> >>http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
> >> >>
> >> >>But I was a bit surpriced what I found in there...
> >> >>grep linux `find` and look at the 'loader*.obj'-files.
> >> >>
> >> >>
> >> >>Can somebody confirm this is _not_ distributed GPL code as a binary?
> >> >
> >> >
> >> > fyi, you can get to this page from :
> >> >
> >> > 	http://www.viaarena.com/?PageID=343
> >> >
> >> > you can do:
> >> > 	wget http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
> >> > 	unzip fastboot%20v2.01.zip
> >> >   	strings */*/loader?.obj | grep -i linux
> >> >
> >> > it gives you stuff like :
> >> >
> >> > _linuxbios_versionR
> >> > _linuxbios_extra_versionX
> >> > _linuxbios_build`
> >> > _linuxbios_compile_timef
> >> > _linuxbios_compile_byp
> >> > _linuxbios_compile_hostv
> >> > _linuxbios_compile_domainz
> >> > _linuxbios_compiler~
> >> > _linuxbios_linker
> >> > _linuxbios_assembler
> >> >
> >> >
> >> > etc, etc.
> >> >
> >> > also that http page mentioned above has contact info. perhaps
> >> something to
> >> > inquire at.
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Linuxbios mailing list
> >> > Linuxbios at clustermatic.org
> >> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >>
> >> --
> >> Matt Jarvis
> >> Technical Development Manager
> >> Rolec Music Ltd
> >> 210 Belgravia Works, Marlborough Road, London, UK N19 4NF
> >> Tel: +44 207 281 4776 Fax : +44 207 281 4565
> >> mailto: matt at rolec.ltd.uk
> >> web: www.rolecmusic.com
> >>
> >> This email is strictly confidential and intended solely for the
> >> addressee(s). It may contain personal and confidential information and
> >> as such may be protected by the Data Protection Act 1998. If this email
> >> has come to you in error you must take no action based on it, nor must
> >> you copy or show it to anyone; please reply to this email and highlight
> >> the error.
> >>
> >> Any views or opinions expressed within this email are those of the
> >> author, and do not necessarily represent those of the company.
> >>
> >> Although we have taken steps to ensure that this email and attachments
> >> are free from any virus, we advise that in keeping with good computer
> >> practice the recipient should ensure they are actually virus free.
> >>
> >
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From ebiederman at lnxi.com  Thu Jun 24 04:05:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun 24 04:05:01 2004
Subject: FYI: I am rewriting cpu initialization....
Message-ID: <m3llidgv2f.fsf@maxwell.lnxi.com>

Since the freebios2 tree was started we have not revisited
the cpu initialization code.  And now that it seems there
are little tweaks needed for every cpu rev, I am starting
that process.

So far I have just barely made a dent but I do have 
code that will accurately identify the cpu, and look
up it's initialization routine.  A goal is to allow
building firmware that can support multiple vendors cpu in the same
sockets, as is common in the socket 7 category.

I'm not quite certain where I am going to wind up but I don't
expect I will have anything in the public tree before next
week.  

If anyone has some thoughts they want to share while I am reworking
cpu initialization feel free to speak up.

Eric


From rminnich at lanl.gov  Thu Jun 24 09:34:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jun 24 09:34:00 2004
Subject: Porting Linux BIOS
In-Reply-To: <40DA58B5.8010509@fuzzymuzzle.com>
Message-ID: <Pine.LNX.4.44.0406240900490.13454-100000@maxroach.lanl.gov>

the preference is for linux to do all this stuff. 

linuxbios motto: 
"Let Linux Do It"

ron



From dwh at lanl.gov  Thu Jun 24 09:45:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Jun 24 09:45:01 2004
Subject: Porting Linux BIOS
In-Reply-To: <40DA1BAA.3080302@fuzzymuzzle.com>
Message-ID: <Pine.LNX.4.44.0406240911560.2176-100000@ccs-mail.lanl.gov>

The EPIA M2 is the best one that I know of. Dave Ashley is probably the 
best person to ask about the EPIA platform, he's done extensive work on 
it.

On Wed, 23 Jun 2004, Michael Robinson wrote:

> David,
> 
> Are all Via EPIA motherboards fairly well supported or just the EPIA 
> M2?  I would assume since the EPIA M2 uses the:
> 
> - VIA CLE266 North Bridge
> - VIA VT8235 South Bridge
> 
> that any of there other EPIA motherboards that use this chipset should 
> be fairly compatible.  Am I correct in this assumption or are there 
> other important factors that can't be easily fixed?
> 
> Thanks,
> Michael Robinson
> mrobinson at fuzzymuzzle.com
> www.fuzzymuzzle.com
> 
> 
> Hendricks David W. wrote:
> 
> >Right now I'd have to say the best supported mainboards currently are VIA 
> >EPIA M2 and Opteron mainboards using the AMD8111 southbridge. Asus does weird 
> >things with their SMbus and hasn't been very cooperative in the past with 
> >documentation, so I would not recommend that you risk money on them.
> >
> >Though if you have a high threshold for pain, you can try one of the newer 
> >VIA chipsets like the KT400 and hope they're generous enough with 
> >documentation to complete a port. Some other VIA stuff is supported, so 
> >that might help with a new port.
> >
> >On Wed, 23 Jun 2004, Michael Robinson wrote:
> >
> >  
> >
> >>Ron,
> >>
> >>I'm not sure what mobo I'm going to use yet, before I buy one I want to 
> >>make sure it's at least reasonably possible to get LinuxBIOS running on 
> >>it.  I've heard that the Asus SiS mobos won't work because of the flash 
> >>chip.  Is this just because of the pinout or is it because of actual 
> >>software compatibility.  I can always solder my own socket onto the 
> >>board if necessary.  I've been looking at the Asus boards and most of 
> >>the compatible boards on your site seem to use the SiS chipset that many 
> >>of the Asus's do.  Can you give me any insight on the chip compatibility 
> >>problem?  Most of the SiS chips in the Asus boards seem very close in 
> >>model number to the ones you guys have got working.
> >>
> >>Thanks,
> >>Michael Robinson
> >>mrobinson at fuzzymuzzle.com
> >>www.fuzzymuzzle.com
> >>
> >>ron minnich wrote:
> >>
> >>    
> >>
> >>>it depends on the chipset type. Can you give us some lspci output and we 
> >>>can see what is possible?
> >>>
> >>>ron
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>_______________________________________________
> >>Linuxbios mailing list
> >>Linuxbios at clustermatic.org
> >>http://www.clustermatic.org/mailman/listinfo/linuxbios
> >>
> >>    
> >>
> >
> >
> >
> >
> >  
> >
> 



From dwh at lanl.gov  Thu Jun 24 09:58:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Jun 24 09:58:01 2004
Subject: Has anyone heard about EPIA MII FastBoot ROM Utility? <     
 GPLIssue
In-Reply-To: <20040624103437.T15738-100000@xs1.xs4all.nl>
Message-ID: <Pine.LNX.4.44.0406240916150.2176-100000@ccs-mail.lanl.gov>

Does someone want to write a nice elaborate letter to the FSF to see if 
there's a genuine GPL violation going on here?

On Thu, 24 Jun 2004, Stefan de Konink wrote:

> Do you agree with them?
> 
> My understanding of the GPL is, if you extend a program or use an other
> GPL program you must license it as GPL. That is probably also true for
> using the same member definitions. imho
> 
> Stefan
> 
> 
> ps. next to that I find it strange why they even mention FreeBIOS in their
> bios... though I hope they open their code anyway.
> 
> On Thu, 24 Jun 2004, Larry Matter wrote:
> 
> > I asked about this and this is the reply I got:
> >
> >   After checking with our engineers, we found the source code of VIA Fast
> > boot ROM
> > does not contain the GPL source code.
> >   Only one structure's members definitions are the same as the Linux BIOS.
> > The
> > remaining parts are not.
> >   We think it doesn't break the GPL.
> >
> > Larry
> >
> > > Today I discussed it with a collegue of me. He said it is the way you
> > > bring this to VIA, if there is any force, like they do when you infridge
> > > their patents, it just disappears from their website.
> > > At the moment they claim to give a OEM (or a end user) source code (one C
> > > file with compile instructions for VC++ 1.5 (!)).
> > > Probably someone should gently point out that what they give is object
> > > code. And with the question if the want to participate in the LinuxBIOS
> > > code, source for the VGA initialisation for example :)
> > >
> > > Two months ago I had basically the same problem with Acer (BenQ) about
> > > their AccessPoints basically they did the same thing as Linksys. With the
> > > new products they got Wind River...
> > > The FSF coundn't do anything because there was no link to find except for
> > > the Linux Kernel.
> > >
> > > So I presume the EPIA-toyers like the FastBios product the same als the
> > > LinuxBIOS project. Though the LinuxBIOS claims to be unstable for the
> > > board (sounds scary) while 'their' VIA building provides a 'working'
> > > package based on LinuxBIOS.
> > >
> > > Is anybody of the developers group able to take some action?
> > >
> > >
> > > Stefan
> > >
> > > On Thu, 17 Jun 2004, Matt Jarvis wrote:
> > >
> > >> This wouldn't surprise me. Via did the same with the Waste sources,
> > >> built their own version for the PadlockSL utility without mention of the
> > >> fact it was GPL Waste source based. They withdrew the code from their
> > >> webpage when it was put to them that it was a GPL infringement. They
> > >> dont seem to understand the concept of the GPL very well.
> > >>
> > >>
> > >> Adam Sulmicki wrote:
> > >> >>I'm trying to boot from the CF reader on the VIA Epia platform. After
> > >> >>reading forums and mailinglist this could be possible by the FastBoot
> > >> >>Utility.
> > >> >>
> > >> >>http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
> > >> >>
> > >> >>But I was a bit surpriced what I found in there...
> > >> >>grep linux `find` and look at the 'loader*.obj'-files.
> > >> >>
> > >> >>
> > >> >>Can somebody confirm this is _not_ distributed GPL code as a binary?
> > >> >
> > >> >
> > >> > fyi, you can get to this page from :
> > >> >
> > >> > 	http://www.viaarena.com/?PageID=343
> > >> >
> > >> > you can do:
> > >> > 	wget http://downloads.viaarena.com/WinCE/Apr04/fastboot%20v2.01.zip
> > >> > 	unzip fastboot%20v2.01.zip
> > >> >   	strings */*/loader?.obj | grep -i linux
> > >> >
> > >> > it gives you stuff like :
> > >> >
> > >> > _linuxbios_versionR
> > >> > _linuxbios_extra_versionX
> > >> > _linuxbios_build`
> > >> > _linuxbios_compile_timef
> > >> > _linuxbios_compile_byp
> > >> > _linuxbios_compile_hostv
> > >> > _linuxbios_compile_domainz
> > >> > _linuxbios_compiler~
> > >> > _linuxbios_linker
> > >> > _linuxbios_assembler
> > >> >
> > >> >
> > >> > etc, etc.
> > >> >
> > >> > also that http page mentioned above has contact info. perhaps
> > >> something to
> > >> > inquire at.
> > >> >
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > Linuxbios mailing list
> > >> > Linuxbios at clustermatic.org
> > >> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > >>
> > >> --
> > >> Matt Jarvis
> > >> Technical Development Manager
> > >> Rolec Music Ltd
> > >> 210 Belgravia Works, Marlborough Road, London, UK N19 4NF
> > >> Tel: +44 207 281 4776 Fax : +44 207 281 4565
> > >> mailto: matt at rolec.ltd.uk
> > >> web: www.rolecmusic.com
> > >>
> > >> This email is strictly confidential and intended solely for the
> > >> addressee(s). It may contain personal and confidential information and
> > >> as such may be protected by the Data Protection Act 1998. If this email
> > >> has come to you in error you must take no action based on it, nor must
> > >> you copy or show it to anyone; please reply to this email and highlight
> > >> the error.
> > >>
> > >> Any views or opinions expressed within this email are those of the
> > >> author, and do not necessarily represent those of the company.
> > >>
> > >> Although we have taken steps to ensure that this email and attachments
> > >> are free from any virus, we advise that in keeping with good computer
> > >> practice the recipient should ensure they are actually virus free.
> > >>
> > >
> > > _______________________________________________
> > > Linuxbios mailing list
> > > Linuxbios at clustermatic.org
> > > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > >
> >
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From mrobinson at fuzzymuzzle.com  Thu Jun 24 10:53:01 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Thu Jun 24 10:53:01 2004
Subject: Porting Linux BIOS
In-Reply-To: <Pine.LNX.4.44.0406240911560.2176-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0406240911560.2176-100000@ccs-mail.lanl.gov>
Message-ID: <40DAFF54.4060201@fuzzymuzzle.com>

I guess I'll go with the MII then and buy the BIOS piggy back so I don't 
have to desolder the existing PLCC socket.  Is CPU compatibility an 
issue?  As long as I'm using an x86 processor the asm should be 
compatible.  Are there other small differences in processor 
initialization that could make them at this point incompatible with 
LinuxBIOS?  The reason I'm asking is the MII supports two CPUs, the Eden 
600 and the C3 10000 and I wasn't sure if they had any small 
initialization differences or if the CPU selection even mattered.  If it 
does matter I'll ask Dave Ashley what the differences are between the two.

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com

Hendricks David W. wrote:

>The EPIA M2 is the best one that I know of. Dave Ashley is probably the 
>best person to ask about the EPIA platform, he's done extensive work on 
>it.
>
>On Wed, 23 Jun 2004, Michael Robinson wrote:
>
>  
>
>>David,
>>
>>Are all Via EPIA motherboards fairly well supported or just the EPIA 
>>M2?  I would assume since the EPIA M2 uses the:
>>
>>- VIA CLE266 North Bridge
>>- VIA VT8235 South Bridge
>>
>>that any of there other EPIA motherboards that use this chipset should 
>>be fairly compatible.  Am I correct in this assumption or are there 
>>other important factors that can't be easily fixed?
>>
>>Thanks,
>>Michael Robinson
>>mrobinson at fuzzymuzzle.com
>>www.fuzzymuzzle.com
>>
>>
>>Hendricks David W. wrote:
>>
>>    
>>
>>>Right now I'd have to say the best supported mainboards currently are VIA 
>>>EPIA M2 and Opteron mainboards using the AMD8111 southbridge. Asus does weird 
>>>things with their SMbus and hasn't been very cooperative in the past with 
>>>documentation, so I would not recommend that you risk money on them.
>>>
>>>Though if you have a high threshold for pain, you can try one of the newer 
>>>VIA chipsets like the KT400 and hope they're generous enough with 
>>>documentation to complete a port. Some other VIA stuff is supported, so 
>>>that might help with a new port.
>>>
>>>On Wed, 23 Jun 2004, Michael Robinson wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>Ron,
>>>>
>>>>I'm not sure what mobo I'm going to use yet, before I buy one I want to 
>>>>make sure it's at least reasonably possible to get LinuxBIOS running on 
>>>>it.  I've heard that the Asus SiS mobos won't work because of the flash 
>>>>chip.  Is this just because of the pinout or is it because of actual 
>>>>software compatibility.  I can always solder my own socket onto the 
>>>>board if necessary.  I've been looking at the Asus boards and most of 
>>>>the compatible boards on your site seem to use the SiS chipset that many 
>>>>of the Asus's do.  Can you give me any insight on the chip compatibility 
>>>>problem?  Most of the SiS chips in the Asus boards seem very close in 
>>>>model number to the ones you guys have got working.
>>>>
>>>>Thanks,
>>>>Michael Robinson
>>>>mrobinson at fuzzymuzzle.com
>>>>www.fuzzymuzzle.com
>>>>
>>>>ron minnich wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>it depends on the chipset type. Can you give us some lspci output and we 
>>>>>can see what is possible?
>>>>>
>>>>>ron
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>_______________________________________________
>>>>Linuxbios mailing list
>>>>Linuxbios at clustermatic.org
>>>>http://www.clustermatic.org/mailman/listinfo/linuxbios
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>
>
>
>
>  
>



From ebiederman at lnxi.com  Thu Jun 24 11:41:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun 24 11:41:00 2004
Subject: Has anyone heard about EPIA MII FastBoot ROM Utility? <      GPLIssue
In-Reply-To: <Pine.LNX.4.44.0406240916150.2176-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0406240916150.2176-100000@ccs-mail.lanl.gov>
Message-ID: <m3smck7uj8.fsf@maxwell.lnxi.com>

"Hendricks David W." <dwh at lanl.gov> writes:

> Does someone want to write a nice elaborate letter to the FSF to see if 
> there's a genuine GPL violation going on here?

Since the copyright is not assigned to the FSF what they can do is limited
but they may be able to assist in this matter.

Skimming the symbols it clearly appears that elfboot from LinuxBIOS
is begin reused.  Hopefully via can be convinced to comply with the
GPL.

Eric


From ollie at lanl.gov  Thu Jun 24 12:00:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Jun 24 12:00:01 2004
Subject: Using Cache As Ram for K8
Message-ID: <1088098025.8331.135.camel@exponential.lanl.gov>

Hello,

I have successfully used the cache in the K8 processor as RAM on
the AMD Serenade mainboard. The cache as ram is used as a tiny
stack space for the code generated by GCC which replace the need
for a register only C complier like ROMCC. Now the whole LinuxBIOS
C code can be compiled by GCC.

There are few problems remaining. The first thing is I can only
use 7 cache lines of cache (448 bytes) reliably in the K8. The
access to the 8th cache line is unstable and the access to the
9th cache line hangs the processor. The other problem is the
optimize_connection() function for multi-processor configuration
runs unstably under CAR. It does not overflow the stack, it's just
plain unstable for some reason. So I can only configure the mainboard
as Uniprocessor.

Is there anyone has any idea about these problems ? If we can solve
these two problems, Cache As Ram can be used routinly for K8 and 
probably we can try to extend it to some other processors.

YHLu,
Do you have any dual K8 EVB with HDT pin out and works "perfectly"
under normal (ROMCC) LinuxBIOS ? The ROMCC LinuxBIOS deos not work
for the AMD Serenade board 100% (I still have the phantom device s
problem) and the s2885 board we have does not have the pin out.

Eric,
What is the "effective" or "equalvalent" stack size of ROMCC ?
Is 448 bytes of stack adquant for ROMCC "linted" code in general ?


Ollie
  



From tony_cheng at pcmagic.net  Thu Jun 24 13:06:00 2004
From: tony_cheng at pcmagic.net (Tony Cheng)
Date: Thu Jun 24 13:06:00 2004
Subject: Using Cache As Ram for K8
References: <1088098025.8331.135.camel@exponential.lanl.gov>
Message-ID: <009f01c45a19$bc477b60$932614ac@trans.corp>

It's great to hear that AMD CPU allow software to access Cache, it's
absolutely not allowed in the Intel CPU which I just finish working on.

I guess you must turned off cache completely and CPUs are not prefetching,
snooping and ete. before you use it as memory, right? I'm not that
knowledgable at this point with AMD Opteron. but this is pretty intrigueing.
I will try it someday, I hope AMD supports this type of use. In another
word, AMD will not scew up the cache data software saved at the background
and SW saving data to it doesn't impact CPU function.

I'm really try to ask you about another question, you have mentioned the AMD
Serenade Mainboard, Do you have the LinuxBIOS source code for this AMD
Serenade Mainboard? I couldn't find it in the Sorceforge CVS. (Only AMD Solo
and Quatet are available there)

I have a Tyan board, and Yh gave me some latest code which works great. But
Tyan doesn't have a HDT Header. AMD Serenade will be a good chioce for us to
try some our code and watch it using an American Arium.

Thanks

Tony

----- Original Message ----- 
From: "Li-Ta Lo" <ollie at lanl.gov>
To: "LinuxBIOS" <linuxbios at clustermatic.org>; "Eric Biederman"
<ebiederman at lnxi.com>; "YhLu" <YhLu at tyan.com>
Sent: Thursday, June 24, 2004 10:27 AM
Subject: Using Cache As Ram for K8


> Hello,
>
> I have successfully used the cache in the K8 processor as RAM on
> the AMD Serenade mainboard. The cache as ram is used as a tiny
> stack space for the code generated by GCC which replace the need
> for a register only C complier like ROMCC. Now the whole LinuxBIOS
> C code can be compiled by GCC.
>
> There are few problems remaining. The first thing is I can only
> use 7 cache lines of cache (448 bytes) reliably in the K8. The
> access to the 8th cache line is unstable and the access to the
> 9th cache line hangs the processor. The other problem is the
> optimize_connection() function for multi-processor configuration
> runs unstably under CAR. It does not overflow the stack, it's just
> plain unstable for some reason. So I can only configure the mainboard
> as Uniprocessor.
>
> Is there anyone has any idea about these problems ? If we can solve
> these two problems, Cache As Ram can be used routinly for K8 and
> probably we can try to extend it to some other processors.
>
> YHLu,
> Do you have any dual K8 EVB with HDT pin out and works "perfectly"
> under normal (ROMCC) LinuxBIOS ? The ROMCC LinuxBIOS deos not work
> for the AMD Serenade board 100% (I still have the phantom device s
> problem) and the s2885 board we have does not have the pin out.
>
> Eric,
> What is the "effective" or "equalvalent" stack size of ROMCC ?
> Is 448 bytes of stack adquant for ROMCC "linted" code in general ?
>
>
> Ollie
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From skinkie at xs4all.nl  Thu Jun 24 15:51:01 2004
From: skinkie at xs4all.nl (Stefan de Konink)
Date: Thu Jun 24 15:51:01 2004
Subject: Has anyone heard about EPIA MII FastBoot ROM Utility? <     
 GPLIssue
In-Reply-To: <m3smck7uj8.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0406240916150.2176-100000@ccs-mail.lanl.gov> <m3smck7uj8.fsf@maxwell.lnxi.com>
Message-ID: <40DB4522.7030204@xs4all.nl>

This definately should be brought polite probably just by asking to 
bring their sources to GPL land could probably be a *hint*. I also agree 
this can go two ways: LinuxBIOS gets adopted by Asus, Via, etc. or they 
are going to shout: 'Always GPL licenses in the way', with forgetting to 
mention the profit they make on the boards because it is now Linux/WinCE 
compatible and thus used more.

license-violation at fsf.org (Ted Teah helped me before on a GPL case) can 
be mailed, though you must be the IP/copyright-holder if you want to get 
some help.


Stefan


From ebiederman at lnxi.com  Thu Jun 24 16:59:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun 24 16:59:00 2004
Subject: Using Cache As Ram for K8
In-Reply-To: <1088098025.8331.135.camel@exponential.lanl.gov>
References: <1088098025.8331.135.camel@exponential.lanl.gov>
Message-ID: <m37jtwfv73.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Hello,
> 
> I have successfully used the cache in the K8 processor as RAM on
> the AMD Serenade mainboard. The cache as ram is used as a tiny
> stack space for the code generated by GCC which replace the need
> for a register only C complier like ROMCC. Now the whole LinuxBIOS
> C code can be compiled by GCC.

Note this certainly will not work for older cpus.  But there is less
complexity there so hopefully romcc is sufficient.
 
> There are few problems remaining. The first thing is I can only
> use 7 cache lines of cache (448 bytes) reliably in the K8. The
> access to the 8th cache line is unstable and the access to the
> 9th cache line hangs the processor. The other problem is the
> optimize_connection() function for multi-processor configuration
> runs unstably under CAR. It does not overflow the stack, it's just
> plain unstable for some reason. So I can only configure the mainboard
> as Uniprocessor.

Most likely it is the cross cpu probes, causing cache invalidates.
You may be able to ``improperly'' setup caching of memory (no cross
cpu probes) while you are initializing the memory controllers.

I wonder if some part of that cache line access problems are
the swapping between L1 and L2.  Although that sounds unlikely.
 
> Is there anyone has any idea about these problems ? If we can solve
> these two problems, Cache As Ram can be used routinly for K8 and 
> probably we can try to extend it to some other processors.

Ollie while in theory the cache as RAM idea works.  When I have implemented
it has been a case of fixing it with every cpu rev.  Whereas romcc while it
is harder, only needs to be stabilized once.  And you don't need to load
a microcode update just so your code can run.

Before we do this routinely I would really like some buy off from AMD
that they would support this.  But anyway...

On the fun side it would be extremely interesting is if you could get
enough  memory working to start paging and we could go into 64bit mode :)
That is likely tempting fate too much.....

> Eric,
> What is the "effective" or "equalvalent" stack size of ROMCC ?
> Is 448 bytes of stack adquant for ROMCC "linted" code in general ?

8 (gpr) + 8 (mmx) + 8 (sse) registers each 4 bytes long = 96 bytes.
Looking at the hdama configuration my max inline depth is 14
procedures so that likely totals to another 14 *4 = 56 bytes in
return addresses.  So 448 bytes would be a small improvement.  

Note generally I have noticed romcc compiled does not even use all of
the registers... 

Eric


From ebiederman at lnxi.com  Thu Jun 24 17:08:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun 24 17:08:00 2004
Subject: AMD64 emulators and other hardware based LinuxBIOS developing tools
In-Reply-To: <200406211534.i5LFYbJt007134@tundra.winternet.com>
References: <200406211534.i5LFYbJt007134@tundra.winternet.com>
Message-ID: <m33c4kfut6.fsf@maxwell.lnxi.com>

Ken Fuchs <kfuchs at winternet.com> writes:

> I'm looking for a good/adequate tool for LinuxBIOS software
> integration/development for dual Opteron mainboards.
> 
> The American Arium has recently added AMD64 support to their ECM-50
> emulator.  I've heard that the ECM-50 is $11K plus $4K for AMD64
> module and $1.5K for support for a total of $16.5K.  I've looked for
> other AMD64 emulators, but didn't find any.  Are there cheaper AMD64
> emulators?
> 
> Something less than an in-circuit emulator may suffice.  Maybe a bus
> analyzer that simply filters and records bus signals on the mainboard.
> The bus analyzed could be the processor bus, PCI bus, etc.
> 
> I'm looking for at least a POST card.  Maybe a POST card with extra
> features.
> 
> I suppose even a processor adapter that allows processor pins to be
> probed with a logic analyzer might do as well.
> 
> What hardware tools (emulators, bus analyzers, POST card, etc.) would
> you recommend for LinuxBIOS integration/development for dual Opteron
> mainboards?

Primarily a serial console is used.   Which can be a pain to bootstrap
but after that all is fine. 

There are other less expensive ways to get to the jtag pins then with
an arium.

A lot of POST cards I have looked at have problems on recent
boards. 5V instead of 3.3V.  Or there is not a slot on a bus
that does subtractive decode, so you can't get the appropriate
traffic.

There are other tricks like using a logic analyzing to watch the lpc
bus.

But for the most part I recommend just using a serial port and
if that is not sufficient look at better alternatives.

Eric


From bari at onelabs.com  Thu Jun 24 17:48:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Jun 24 17:48:00 2004
Subject: Using Cache As Ram for K8
In-Reply-To: <m37jtwfv73.fsf@maxwell.lnxi.com>
References: <1088098025.8331.135.camel@exponential.lanl.gov> <m37jtwfv73.fsf@maxwell.lnxi.com>
Message-ID: <40DB60A6.7010804@onelabs.com>

Eric W. Biederman wrote:

>>Eric,
>>What is the "effective" or "equalvalent" stack size of ROMCC ?
>>Is 448 bytes of stack adquant for ROMCC "linted" code in general ?
> 
> 
> 8 (gpr) + 8 (mmx) + 8 (sse) registers each 4 bytes long = 96 bytes.
> Looking at the hdama configuration my max inline depth is 14
> procedures so that likely totals to another 14 *4 = 56 bytes in
> return addresses.  So 448 bytes would be a small improvement.  
> 
> Note generally I have noticed romcc compiled does not even use all of
> the registers... 
> 
For comparison when using U-Boot for PPC:

"Note: on PPC, we could use a static initializer (since the address of 
the global data structure is known at compile time), but it turned out 
that reserving a register results in somewhat smaller code - although 
the code savings are not that big (on average for all boards 752 bytes 
for the whole U-Boot image, 624 text + 127 data)."

-Bari





From stepan at openbios.org  Thu Jun 24 18:19:00 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Thu Jun 24 18:19:00 2004
Subject: Using Cache As Ram for K8
In-Reply-To: <m37jtwfv73.fsf@maxwell.lnxi.com>
References: <1088098025.8331.135.camel@exponential.lanl.gov> <m37jtwfv73.fsf@maxwell.lnxi.com>
Message-ID: <20040624234630.GA30661@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [040625 00:27]:
> On the fun side it would be extremely interesting is if you could get
> enough  memory working to start paging and we could go into 64bit mode :)
> That is likely tempting fate too much.....
 
Ack! With all C code compiled by gcc this sounds like a reasonable goal.
But will any payloads work with this?

> > Eric,
> > What is the "effective" or "equalvalent" stack size of ROMCC ?
> > Is 448 bytes of stack adquant for ROMCC "linted" code in general ?
> 
> 8 (gpr) + 8 (mmx) + 8 (sse) registers each 4 bytes long = 96 bytes.
> Looking at the hdama configuration my max inline depth is 14
> procedures so that likely totals to another 14 *4 = 56 bytes in
> return addresses.  So 448 bytes would be a small improvement.  
 
With current CVS the code shrinks from about 90k object size to 10k.
This is actually not bad for a small improvement. I have not tried major
hand tuning with romcc's anti-inline tags yet.

Stefan



From mrobinson at fuzzymuzzle.com  Thu Jun 24 18:31:00 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Thu Jun 24 18:31:00 2004
Subject: DiskOnChip Questions
Message-ID: <40DB6A83.9000306@fuzzymuzzle.com>

Hey guys,

Please bear with me, I have some questions that are probably pretty 
basic but I can't find the answers anywhere.  My first question is what 
does the DiskOnChip provide to the LinuxBIOs project that the standard 
flash chip can't?  My second is that I'm going to be using the VIA EPIA 
MII motherboard which has a PLCC BIOS, as far as I can tell PLCC 
DiskOnChips aren't very readily available.  Should I use a DIP to PLCC 
adapter; how did the other people who used this board do it?  My final 
question is how do I pick the size of the DiskOnChip.  What is 
LinuxBIOS's typical size requirement; do motherboards have a maximum 
BIOS size limitation?  If BIOSs do have a maximum size limitation how do 
I figure it out, VIA says says the BIOS for my board is 2/4Mbit flash 
memory.  Sorry if these seem very basic.

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com



From ebiederman at lnxi.com  Thu Jun 24 19:05:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jun 24 19:05:00 2004
Subject: Using Cache As Ram for K8
In-Reply-To: <20040624234630.GA30661@openbios.org>
References: <1088098025.8331.135.camel@exponential.lanl.gov>
	<m37jtwfv73.fsf@maxwell.lnxi.com>
	<20040624234630.GA30661@openbios.org>
Message-ID: <m3pt7o8ojn.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [040625 00:27]:
> > On the fun side it would be extremely interesting is if you could get
> > enough  memory working to start paging and we could go into 64bit mode :)
> > That is likely tempting fate too much.....
>  
> Ack! With all C code compiled by gcc this sounds like a reasonable goal.
> But will any payloads work with this?

Besides the kernel?  For the payloads it does not matter. Having an
ELF loader that does both 32bit and 64bit is not hard, and the code
already exists in etherboot.  One of the advantages of LinuxBIOS
is that we don't have to run in the same processor mode as our
payloads.  We can switch processor word size or endianness and things
should continue to work.

Even with romcc an x86-64 port would not be hard.  There are just
some interesting complications in using a minimal 4K page table
that I have been avoiding.  Thinking about it though the extra
programmer visible registers might just make it worth it, especially
combined with non-inlining.  

One of these days I must take the time to generate a 64bit ELF
executable from an Opteron kernel. 
 
> > > Eric,
> > > What is the "effective" or "equalvalent" stack size of ROMCC ?
> > > Is 448 bytes of stack adquant for ROMCC "linted" code in general ?
> > 
> > 8 (gpr) + 8 (mmx) + 8 (sse) registers each 4 bytes long = 96 bytes.
> > Looking at the hdama configuration my max inline depth is 14
> > procedures so that likely totals to another 14 *4 = 56 bytes in
> > return addresses.  So 448 bytes would be a small improvement.  
>  
> With current CVS the code shrinks from about 90k object size to 10k.
???
I don't know where the 90k comes from.  But the code compiled
with romcc should likely fall into the 10k real without inlining.
Currently it is about 30k-40k.

My basic objection is that I have been down the cache as ram path
once, and decided there was less maintenance in doing romcc.  After writing
romcc I still feel that way.  Not having to worry about a BIOS breaking
because of a new processor and is a relief.

> This is actually not bad for a small improvement. I have not tried major
> hand tuning with romcc's anti-inline tags yet.

In theory it should be similar in code size.  In practice things aren't
quite usable yet.

Eric


From rsmith at bitworks.com  Thu Jun 24 19:56:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Thu Jun 24 19:56:01 2004
Subject: Resource Allocation for Option Rom
In-Reply-To: <1088016424.8331.2.camel@exponential.lanl.gov>
References: <1085687516.5653.51.camel@exponential.lanl.gov>	 <m3d64ptylq.fsf@maxwell.lnxi.com>	 <1085690660.5653.72.camel@exponential.lanl.gov>	 <m3fz9lnnie.fsf@maxwell.lnxi.com>  <40D9AED6.608@bitworks.com> <1088016424.8331.2.camel@exponential.lanl.gov>
Message-ID: <40DB7E93.5080905@bitworks.com>

Li-Ta Lo wrote:

>>Did this happen?  I'm trying to get a plug in PCI video card up with 
>>ADLO and I need the option rom to be enabled.  I can do it direcly in my 
>>mainboard code for a hack but If there was anything to test I though I 
>>would try.
>>
> How is testbios doing on your side ?

It's proving very useful.

I have tested it on another pc with my M1 eval PCI card and on that 
machine I can boot with the Vbios removed, run testbios and I get a 
signon message.  Yay.

So my other test pc must have some problem with not setting up access to 
  a0000-bffff properly when you boot a card with out a bios.  Just like 
you suspected.

So now that I have a golden path with the emulator I have been doing log 
comparisons between the eval card in the pc vs in our target board.

Comparing IO accesses I don't find any meaningfull differences. So I 
upped the logging to include memory reads/writes as well.  Looks like 
when the vbios trys to do a memory test on a0000 it fails.

I've also managed to make our COTS bios from the previous rev of this 
board boot as well.  It does option ROM scans and booting that bios with 
the PCI eval card stuck in does exactly the same thing as my linuxbios 
setup + emulator does.  The COTS bios also has a vid mem test and if I 
enable that it will fail as well.

So now I've got failure under both linux bios and a COTS bios using a 
PCI eval card that is known to work.

So its pretty much got to be some sort of hardware problem with access 
to the legacy VGA range.  Something fscked with the northbridge perhaps. 
  I'm hacking up the vbios source to do the a0000 test over and over and 
tomorow we are going to see where those accesses are really going if at all.

As far as testbios is concerned the only mod it would need to work with 
my stock ATI bios is the timer IO access trapping and reporting back a 
consistant value.

Its not really an issue for me since the ATI vbios works fine under 
testbios with the problematic ATI delay hacked to just return rather 
than delay.  The delay provided by the emulator appears to be enough. 
   Thats what I've been using for all my testing so far.



From linuxbios at matter.net  Fri Jun 25 01:52:01 2004
From: linuxbios at matter.net (Larry Matter)
Date: Fri Jun 25 01:52:01 2004
Subject: DiskOnChip Questions
In-Reply-To: <40DB6A83.9000306@fuzzymuzzle.com>
References: <40DB6A83.9000306@fuzzymuzzle.com>
Message-ID: <37630.192.168.1.140.1088147947.squirrel@mail.matter.net>

> what
> does the DiskOnChip provide to the LinuxBIOs project that the standard
> flash chip can't?

More than 2 megabits of storage.

> My second is that I'm going to be using the VIA EPIA
> MII motherboard which has a PLCC BIOS, as far as I can tell PLCC
> DiskOnChips aren't very readily available.  Should I use a DIP to PLCC
> adapter; how did the other people who used this board do it?

The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE
adapter.  Using FILO you can boot from the CF.

> My final
> question is how do I pick the size of the DiskOnChip.

So if you're going to go for the CF <> IDE, then it just needs to be as
big as your root partition (or even just an initrd).   There are many
other alternatives depending on network, disk, etc.

And if you've been following this list for a bit you'll know that you
can't (yet) boot off of the CF adapter on the EPIA MII.

One last word of advice, get a bios savior.

Larry


From ollie at lanl.gov  Fri Jun 25 09:27:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Jun 25 09:27:01 2004
Subject: Using Cache As Ram for K8
In-Reply-To: <009f01c45a19$bc477b60$932614ac@trans.corp>
References: <1088098025.8331.135.camel@exponential.lanl.gov>
	 <009f01c45a19$bc477b60$932614ac@trans.corp>
Message-ID: <1088175250.15464.1.camel@exponential.lanl.gov>

On Thu, 2004-06-24 at 12:33, Tony Cheng wrote:
> It's great to hear that AMD CPU allow software to access Cache, it's
> absolutely not allowed in the Intel CPU which I just finish working on.
> 
> I guess you must turned off cache completely and CPUs are not prefetching,
> snooping and ete. before you use it as memory, right? I'm not that
> knowledgable at this point with AMD Opteron. but this is pretty intrigueing.
> I will try it someday, I hope AMD supports this type of use. In another
> word, AMD will not scew up the cache data software saved at the background
> and SW saving data to it doesn't impact CPU function.
> 
> I'm really try to ask you about another question, you have mentioned the AMD
> Serenade Mainboard, Do you have the LinuxBIOS source code for this AMD
> Serenade Mainboard? I couldn't find it in the Sorceforge CVS. (Only AMD Solo
> and Quatet are available there)
> 

The AMD Serenade board support for ROMCC LinuxBIOS is in the CVS. Please
do a "cvs update -dP". The cache as ram version is not committed yet.

Ollie




From ollie at lanl.gov  Fri Jun 25 09:44:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Jun 25 09:44:00 2004
Subject: Using Cache As Ram for K8
In-Reply-To: <m37jtwfv73.fsf@maxwell.lnxi.com>
References: <1088098025.8331.135.camel@exponential.lanl.gov>
	 <m37jtwfv73.fsf@maxwell.lnxi.com>
Message-ID: <1088176272.15464.21.camel@exponential.lanl.gov>

On Thu, 2004-06-24 at 16:27, Eric W. Biederman wrote:
> > There are few problems remaining. The first thing is I can only
> > use 7 cache lines of cache (448 bytes) reliably in the K8. The
> > access to the 8th cache line is unstable and the access to the
> > 9th cache line hangs the processor. The other problem is the
> > optimize_connection() function for multi-processor configuration
> > runs unstably under CAR. It does not overflow the stack, it's just
> > plain unstable for some reason. So I can only configure the mainboard
> > as Uniprocessor.
> 
> Most likely it is the cross cpu probes, causing cache invalidates.
> You may be able to ``improperly'' setup caching of memory (no cross
> cpu probes) while you are initializing the memory controllers.
> 

That is exactly the point I don't understand. In theory, the AP is
halted and HT routing disabled on powerup before the first instruction
is even executed. But to what extend is the processor "halted", does it
still try to maintain cache coherence ? And how about the northbridge
in the processor ? Obviously, the northbridge is in a working state
when the processor is halted, what is the impact of northbridge on the
cache of the processor ?

> On the fun side it would be extremely interesting is if you could get
> enough  memory working to start paging and we could go into 64bit mode :)
> That is likely tempting fate too much.....
> 

Why does CAR have anything to do with entering 64bit mode ?

Ollie



From mrobinson at fuzzymuzzle.com  Fri Jun 25 10:22:01 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Fri Jun 25 10:22:01 2004
Subject: [Fwd: Re: DiskOnChip Questions]
Message-ID: <40DC4961.3080108@fuzzymuzzle.com>

---The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE 
adapter. Using FILO you can boot from the CF.---

So I'd flash FILO to the BIOS, then it would load the LinuxBIOS kernel 
image, and then the kernel image would do whatever you want LinuxBIOS to 
do, right? Or am I wrong... It says FILO loads a "boot image", whats the 
definition of a "boot image", is it just the kernel?

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com



Larry Matter wrote:

>>what
>>does the DiskOnChip provide to the LinuxBIOs project that the standard
>>flash chip can't?
>>    
>>
>
>More than 2 megabits of storage.
>
>  
>
>>My second is that I'm going to be using the VIA EPIA
>>MII motherboard which has a PLCC BIOS, as far as I can tell PLCC
>>DiskOnChips aren't very readily available.  Should I use a DIP to PLCC
>>adapter; how did the other people who used this board do it?
>>    
>>
>
>The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE
>adapter.  Using FILO you can boot from the CF.
>  
>
>  
>
>>My final
>>question is how do I pick the size of the DiskOnChip.
>>    
>>
>
>So if you're going to go for the CF <> IDE, then it just needs to be as
>big as your root partition (or even just an initrd).   There are many
>other alternatives depending on network, disk, etc.
>
>And if you've been following this list for a bit you'll know that you
>can't (yet) boot off of the CF adapter on the EPIA MII.
>
>One last word of advice, get a bios savior.
>
>Larry
>
>
>
>  
>




From dwh at lanl.gov  Fri Jun 25 10:40:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Jun 25 10:40:01 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <40DC4961.3080108@fuzzymuzzle.com>
Message-ID: <Pine.LNX.4.44.0406250954430.2176-100000@ccs-mail.lanl.gov>

Sounds about right. Put your kernel on an IDE device with a filesystem 
(FILO supports EXT2/3, Reiser, XFS, etc) and use FILO as your LinuxBIOS 
payload (payload /where/filo/is/located/filo.elf in your 
targets/via/epia-m/Config.lb file). You also need to tell FILO where 
yoru kernel is located and give it any options you want passed to the 
kernel in the "AUTOBOOT_FILE" line, which should look something like 
a LILO prompt: hda1:/kernel root/dev/hda3 console=ttyS0,115200 

Boot image generally implies kernel. 

On Fri, 25 Jun 2004, Michael Robinson wrote:

> ---The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE 
> adapter. Using FILO you can boot from the CF.---
> 
> So I'd flash FILO to the BIOS, then it would load the LinuxBIOS kernel 
> image, and then the kernel image would do whatever you want LinuxBIOS to 
> do, right? Or am I wrong... It says FILO loads a "boot image", whats the 
> definition of a "boot image", is it just the kernel?
> 
> Thanks,
> Michael Robinson
> mrobinson at fuzzymuzzle.com
> www.fuzzymuzzle.com
> 
> 
> 
> Larry Matter wrote:
> 
> >>what
> >>does the DiskOnChip provide to the LinuxBIOs project that the standard
> >>flash chip can't?
> >>    
> >>
> >
> >More than 2 megabits of storage.
> >
> >  
> >
> >>My second is that I'm going to be using the VIA EPIA
> >>MII motherboard which has a PLCC BIOS, as far as I can tell PLCC
> >>DiskOnChips aren't very readily available.  Should I use a DIP to PLCC
> >>adapter; how did the other people who used this board do it?
> >>    
> >>
> >
> >The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE
> >adapter.  Using FILO you can boot from the CF.
> >  
> >
> >  
> >
> >>My final
> >>question is how do I pick the size of the DiskOnChip.
> >>    
> >>
> >
> >So if you're going to go for the CF <> IDE, then it just needs to be as
> >big as your root partition (or even just an initrd).   There are many
> >other alternatives depending on network, disk, etc.
> >
> >And if you've been following this list for a bit you'll know that you
> >can't (yet) boot off of the CF adapter on the EPIA MII.
> >
> >One last word of advice, get a bios savior.
> >
> >Larry
> >
> >
> >
> >  
> >
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From mrobinson at fuzzymuzzle.com  Fri Jun 25 10:52:01 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Fri Jun 25 10:52:01 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <Pine.LNX.4.44.0406250954430.2176-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0406250954430.2176-100000@ccs-mail.lanl.gov>
Message-ID: <40DC5058.8040304@fuzzymuzzle.com>

So in my case FILO is booting the actual Linux kernel that you will be 
using when you perform tasks on the computer?  So if you were using a 
DiskOnChip your Linux distribution kernel would be on the actual 
DiskOnChip?  I was under the impression that the LinuxBIOS kernel was on 
the DiskOnChip and the distribution kernel was on a hard drive.  Could 
you please clarify.

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com

Hendricks David W. wrote:

>Sounds about right. Put your kernel on an IDE device with a filesystem 
>(FILO supports EXT2/3, Reiser, XFS, etc) and use FILO as your LinuxBIOS 
>payload (payload /where/filo/is/located/filo.elf in your 
>targets/via/epia-m/Config.lb file). You also need to tell FILO where 
>yoru kernel is located and give it any options you want passed to the 
>kernel in the "AUTOBOOT_FILE" line, which should look something like 
>a LILO prompt: hda1:/kernel root/dev/hda3 console=ttyS0,115200 
>
>Boot image generally implies kernel. 
>
>On Fri, 25 Jun 2004, Michael Robinson wrote:
>
>  
>
>>---The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE 
>>adapter. Using FILO you can boot from the CF.---
>>
>>So I'd flash FILO to the BIOS, then it would load the LinuxBIOS kernel 
>>image, and then the kernel image would do whatever you want LinuxBIOS to 
>>do, right? Or am I wrong... It says FILO loads a "boot image", whats the 
>>definition of a "boot image", is it just the kernel?
>>
>>Thanks,
>>Michael Robinson
>>mrobinson at fuzzymuzzle.com
>>www.fuzzymuzzle.com
>>
>>
>>
>>Larry Matter wrote:
>>
>>    
>>
>>>>what
>>>>does the DiskOnChip provide to the LinuxBIOs project that the standard
>>>>flash chip can't?
>>>>   
>>>>
>>>>        
>>>>
>>>More than 2 megabits of storage.
>>>
>>> 
>>>
>>>      
>>>
>>>>My second is that I'm going to be using the VIA EPIA
>>>>MII motherboard which has a PLCC BIOS, as far as I can tell PLCC
>>>>DiskOnChips aren't very readily available.  Should I use a DIP to PLCC
>>>>adapter; how did the other people who used this board do it?
>>>>   
>>>>
>>>>        
>>>>
>>>The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE
>>>adapter.  Using FILO you can boot from the CF.
>>> 
>>>
>>> 
>>>
>>>      
>>>
>>>>My final
>>>>question is how do I pick the size of the DiskOnChip.
>>>>   
>>>>
>>>>        
>>>>
>>>So if you're going to go for the CF <> IDE, then it just needs to be as
>>>big as your root partition (or even just an initrd).   There are many
>>>other alternatives depending on network, disk, etc.
>>>
>>>And if you've been following this list for a bit you'll know that you
>>>can't (yet) boot off of the CF adapter on the EPIA MII.
>>>
>>>One last word of advice, get a bios savior.
>>>
>>>Larry
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>Linuxbios mailing list
>>Linuxbios at clustermatic.org
>>http://www.clustermatic.org/mailman/listinfo/linuxbios
>>
>>    
>>
>
>
>
>
>  
>



From dwh at lanl.gov  Fri Jun 25 10:57:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Jun 25 10:57:00 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <40DC5058.8040304@fuzzymuzzle.com>
Message-ID: <Pine.LNX.4.44.0406251019470.2176-100000@ccs-mail.lanl.gov>

You can do it that way, too. The method suggested earlier was to use the 
distribution kernel on the compact flash device. If you want a stripped 
kernel to fit alongside LinuxBIOS on your BIOS ROM, you can do that as 
well (Look at targets/arima/hdama/Config.kernelimage.lb for an example). 
You could then use Kexec or Two Kernel Monte (kmonte) to boot 
another kernel.

So I guess what we need to figure out is how you want to boot your kernel. 
Do you want it to be booted off an IDE device or the same flash part 
alongside your BIOS?

On Fri, 25 Jun 2004, Michael Robinson wrote:

> So in my case FILO is booting the actual Linux kernel that you will be 
> using when you perform tasks on the computer?  So if you were using a 
> DiskOnChip your Linux distribution kernel would be on the actual 
> DiskOnChip?  I was under the impression that the LinuxBIOS kernel was on 
> the DiskOnChip and the distribution kernel was on a hard drive.  Could 
> you please clarify.
> 
> Thanks,
> Michael Robinson
> mrobinson at fuzzymuzzle.com
> www.fuzzymuzzle.com
> 
> Hendricks David W. wrote:
> 
> >Sounds about right. Put your kernel on an IDE device with a filesystem 
> >(FILO supports EXT2/3, Reiser, XFS, etc) and use FILO as your LinuxBIOS 
> >payload (payload /where/filo/is/located/filo.elf in your 
> >targets/via/epia-m/Config.lb file). You also need to tell FILO where 
> >yoru kernel is located and give it any options you want passed to the 
> >kernel in the "AUTOBOOT_FILE" line, which should look something like 
> >a LILO prompt: hda1:/kernel root/dev/hda3 console=ttyS0,115200 
> >
> >Boot image generally implies kernel. 
> >
> >On Fri, 25 Jun 2004, Michael Robinson wrote:
> >
> >  
> >
> >>---The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE 
> >>adapter. Using FILO you can boot from the CF.---
> >>
> >>So I'd flash FILO to the BIOS, then it would load the LinuxBIOS kernel 
> >>image, and then the kernel image would do whatever you want LinuxBIOS to 
> >>do, right? Or am I wrong... It says FILO loads a "boot image", whats the 
> >>definition of a "boot image", is it just the kernel?
> >>
> >>Thanks,
> >>Michael Robinson
> >>mrobinson at fuzzymuzzle.com
> >>www.fuzzymuzzle.com
> >>
> >>
> >>
> >>Larry Matter wrote:
> >>
> >>    
> >>
> >>>>what
> >>>>does the DiskOnChip provide to the LinuxBIOs project that the standard
> >>>>flash chip can't?
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>More than 2 megabits of storage.
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>My second is that I'm going to be using the VIA EPIA
> >>>>MII motherboard which has a PLCC BIOS, as far as I can tell PLCC
> >>>>DiskOnChips aren't very readily available.  Should I use a DIP to PLCC
> >>>>adapter; how did the other people who used this board do it?
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE
> >>>adapter.  Using FILO you can boot from the CF.
> >>> 
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>My final
> >>>>question is how do I pick the size of the DiskOnChip.
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>So if you're going to go for the CF <> IDE, then it just needs to be as
> >>>big as your root partition (or even just an initrd).   There are many
> >>>other alternatives depending on network, disk, etc.
> >>>
> >>>And if you've been following this list for a bit you'll know that you
> >>>can't (yet) boot off of the CF adapter on the EPIA MII.
> >>>
> >>>One last word of advice, get a bios savior.
> >>>
> >>>Larry
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>_______________________________________________
> >>Linuxbios mailing list
> >>Linuxbios at clustermatic.org
> >>http://www.clustermatic.org/mailman/listinfo/linuxbios
> >>
> >>    
> >>
> >
> >
> >
> >
> >  
> >
> 



From mrobinson at fuzzymuzzle.com  Fri Jun 25 11:13:00 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Fri Jun 25 11:13:00 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <Pine.LNX.4.44.0406251019470.2176-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0406251019470.2176-100000@ccs-mail.lanl.gov>
Message-ID: <40DC5551.50205@fuzzymuzzle.com>

David,

LinuxBIOS has its own kernel correct?  Or is LinuxBIOS not really a 
Linux kernel, but boots a Linux kernel that can be stored on the 
DiskOnChip or HDD?  I just want to verify how it works because I've 
heard so many references to multiple kernels that I'm not sure exactly 
how the whole process works.  In response to your last question I'd like 
to boot my distro off of hard disk if I'm thinking correctly.

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com

Hendricks David W. wrote:

>You can do it that way, too. The method suggested earlier was to use the 
>distribution kernel on the compact flash device. If you want a stripped 
>kernel to fit alongside LinuxBIOS on your BIOS ROM, you can do that as 
>well (Look at targets/arima/hdama/Config.kernelimage.lb for an example). 
>You could then use Kexec or Two Kernel Monte (kmonte) to boot 
>another kernel.
>
>So I guess what we need to figure out is how you want to boot your kernel. 
>Do you want it to be booted off an IDE device or the same flash part 
>alongside your BIOS?
>
>On Fri, 25 Jun 2004, Michael Robinson wrote:
>
>  
>
>>So in my case FILO is booting the actual Linux kernel that you will be 
>>using when you perform tasks on the computer?  So if you were using a 
>>DiskOnChip your Linux distribution kernel would be on the actual 
>>DiskOnChip?  I was under the impression that the LinuxBIOS kernel was on 
>>the DiskOnChip and the distribution kernel was on a hard drive.  Could 
>>you please clarify.
>>
>>Thanks,
>>Michael Robinson
>>mrobinson at fuzzymuzzle.com
>>www.fuzzymuzzle.com
>>
>>Hendricks David W. wrote:
>>
>>    
>>
>>>Sounds about right. Put your kernel on an IDE device with a filesystem 
>>>(FILO supports EXT2/3, Reiser, XFS, etc) and use FILO as your LinuxBIOS 
>>>payload (payload /where/filo/is/located/filo.elf in your 
>>>targets/via/epia-m/Config.lb file). You also need to tell FILO where 
>>>yoru kernel is located and give it any options you want passed to the 
>>>kernel in the "AUTOBOOT_FILE" line, which should look something like 
>>>a LILO prompt: hda1:/kernel root/dev/hda3 console=ttyS0,115200 
>>>
>>>Boot image generally implies kernel. 
>>>
>>>On Fri, 25 Jun 2004, Michael Robinson wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>---The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE 
>>>>adapter. Using FILO you can boot from the CF.---
>>>>
>>>>So I'd flash FILO to the BIOS, then it would load the LinuxBIOS kernel 
>>>>image, and then the kernel image would do whatever you want LinuxBIOS to 
>>>>do, right? Or am I wrong... It says FILO loads a "boot image", whats the 
>>>>definition of a "boot image", is it just the kernel?
>>>>
>>>>Thanks,
>>>>Michael Robinson
>>>>mrobinson at fuzzymuzzle.com
>>>>www.fuzzymuzzle.com
>>>>
>>>>
>>>>
>>>>Larry Matter wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>>what
>>>>>>does the DiskOnChip provide to the LinuxBIOs project that the standard
>>>>>>flash chip can't?
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>More than 2 megabits of storage.
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>My second is that I'm going to be using the VIA EPIA
>>>>>>MII motherboard which has a PLCC BIOS, as far as I can tell PLCC
>>>>>>DiskOnChips aren't very readily available.  Should I use a DIP to PLCC
>>>>>>adapter; how did the other people who used this board do it?
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE
>>>>>adapter.  Using FILO you can boot from the CF.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>My final
>>>>>>question is how do I pick the size of the DiskOnChip.
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>So if you're going to go for the CF <> IDE, then it just needs to be as
>>>>>big as your root partition (or even just an initrd).   There are many
>>>>>other alternatives depending on network, disk, etc.
>>>>>
>>>>>And if you've been following this list for a bit you'll know that you
>>>>>can't (yet) boot off of the CF adapter on the EPIA MII.
>>>>>
>>>>>One last word of advice, get a bios savior.
>>>>>
>>>>>Larry
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>_______________________________________________
>>>>Linuxbios mailing list
>>>>Linuxbios at clustermatic.org
>>>>http://www.clustermatic.org/mailman/listinfo/linuxbios
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>
>
>
>
>  
>



From dwh at lanl.gov  Fri Jun 25 11:55:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Jun 25 11:55:01 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <40DC5551.50205@fuzzymuzzle.com>
Message-ID: <Pine.LNX.4.44.0406251101120.2176-100000@ccs-mail.lanl.gov>

LinuxBIOS does not have its own kernel. The way it usually works is either 
LinuxBIOS boots a kernel from flash or LinuxBIOS boots a payload (eg FILO 
or Etherboot) which then boots a kernel. LinuxBIOS is its own entity in 
either case.

If you have an IDE hard disk, you can use LinuxBIOS and FILO to boot your 
kernel off that hard disk and its existing filesystem as you would with 
LILO or GRUB. FILO can be downloaded here: 
http://te.to/~ts1/filo/ .

Basically this is what I would do with your hardware:
1. Download FILO, edit the Config file.
	Change the AUTOBOOT_FILE line to let FILO know where your kernel 
is located and also pass any extra kernel parameters. Example:
hda2:/boot/x86_64 root=/dev/hda2 console=ttyS0,115200 console=tty0 vga=792 
video=atyfb:mode:1024x768
	Look under "# Filesystems" and enable whichever filesystem(s) you 
require to read your kernel.
	Run "make" to generate filo.elf

2. Open your freebios2/targets/via/epia-m/Config.lb file and edit the 
"payload" lines. There should be two of them, one under romimage "normal" 
and one under romimage "fallback". Change them to point to filo.elf. For 
example:
	payload /usr/src/filo-0.4.2/filo.elf

3. cd to freebios2/targets and run "./buildtarget via/epia-m/"
4. cd to via/epia-m/epia-m and run "make"
5. If all goes well, you should now have linuxbios.rom. Burn it on a spare 
flash part (You can try the flash_rom utility in 
freebios2/util/flash_and_burn), hook up a serial connection to another 
computer, power cycle and see what happens.

On Fri, 25 Jun 2004, Michael Robinson wrote:

> David,
> 
> LinuxBIOS has its own kernel correct?  Or is LinuxBIOS not really a 
> Linux kernel, but boots a Linux kernel that can be stored on the 
> DiskOnChip or HDD?  I just want to verify how it works because I've 
> heard so many references to multiple kernels that I'm not sure exactly 
> how the whole process works.  In response to your last question I'd like 
> to boot my distro off of hard disk if I'm thinking correctly.
> 
> Thanks,
> Michael Robinson
> mrobinson at fuzzymuzzle.com
> www.fuzzymuzzle.com
> 
> Hendricks David W. wrote:
> 
> >You can do it that way, too. The method suggested earlier was to use the 
> >distribution kernel on the compact flash device. If you want a stripped 
> >kernel to fit alongside LinuxBIOS on your BIOS ROM, you can do that as 
> >well (Look at targets/arima/hdama/Config.kernelimage.lb for an example). 
> >You could then use Kexec or Two Kernel Monte (kmonte) to boot 
> >another kernel.
> >
> >So I guess what we need to figure out is how you want to boot your kernel. 
> >Do you want it to be booted off an IDE device or the same flash part 
> >alongside your BIOS?
> >
> >On Fri, 25 Jun 2004, Michael Robinson wrote:
> >
> >  
> >
> >>So in my case FILO is booting the actual Linux kernel that you will be 
> >>using when you perform tasks on the computer?  So if you were using a 
> >>DiskOnChip your Linux distribution kernel would be on the actual 
> >>DiskOnChip?  I was under the impression that the LinuxBIOS kernel was on 
> >>the DiskOnChip and the distribution kernel was on a hard drive.  Could 
> >>you please clarify.
> >>
> >>Thanks,
> >>Michael Robinson
> >>mrobinson at fuzzymuzzle.com
> >>www.fuzzymuzzle.com
> >>
> >>Hendricks David W. wrote:
> >>
> >>    
> >>
> >>>Sounds about right. Put your kernel on an IDE device with a filesystem 
> >>>(FILO supports EXT2/3, Reiser, XFS, etc) and use FILO as your LinuxBIOS 
> >>>payload (payload /where/filo/is/located/filo.elf in your 
> >>>targets/via/epia-m/Config.lb file). You also need to tell FILO where 
> >>>yoru kernel is located and give it any options you want passed to the 
> >>>kernel in the "AUTOBOOT_FILE" line, which should look something like 
> >>>a LILO prompt: hda1:/kernel root/dev/hda3 console=ttyS0,115200 
> >>>
> >>>Boot image generally implies kernel. 
> >>>
> >>>On Fri, 25 Jun 2004, Michael Robinson wrote:
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>---The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE 
> >>>>adapter. Using FILO you can boot from the CF.---
> >>>>
> >>>>So I'd flash FILO to the BIOS, then it would load the LinuxBIOS kernel 
> >>>>image, and then the kernel image would do whatever you want LinuxBIOS to 
> >>>>do, right? Or am I wrong... It says FILO loads a "boot image", whats the 
> >>>>definition of a "boot image", is it just the kernel?
> >>>>
> >>>>Thanks,
> >>>>Michael Robinson
> >>>>mrobinson at fuzzymuzzle.com
> >>>>www.fuzzymuzzle.com
> >>>>
> >>>>
> >>>>
> >>>>Larry Matter wrote:
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>>>>what
> >>>>>>does the DiskOnChip provide to the LinuxBIOs project that the standard
> >>>>>>flash chip can't?
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>More than 2 megabits of storage.
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>My second is that I'm going to be using the VIA EPIA
> >>>>>>MII motherboard which has a PLCC BIOS, as far as I can tell PLCC
> >>>>>>DiskOnChips aren't very readily available.  Should I use a DIP to PLCC
> >>>>>>adapter; how did the other people who used this board do it?
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE
> >>>>>adapter.  Using FILO you can boot from the CF.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>My final
> >>>>>>question is how do I pick the size of the DiskOnChip.
> >>>>>>  
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>So if you're going to go for the CF <> IDE, then it just needs to be as
> >>>>>big as your root partition (or even just an initrd).   There are many
> >>>>>other alternatives depending on network, disk, etc.
> >>>>>
> >>>>>And if you've been following this list for a bit you'll know that you
> >>>>>can't (yet) boot off of the CF adapter on the EPIA MII.
> >>>>>
> >>>>>One last word of advice, get a bios savior.
> >>>>>
> >>>>>Larry
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>_______________________________________________
> >>>>Linuxbios mailing list
> >>>>Linuxbios at clustermatic.org
> >>>>http://www.clustermatic.org/mailman/listinfo/linuxbios
> >>>>
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >
> >
> >
> >
> >  
> >
> 



From linuxbios at matter.net  Fri Jun 25 11:56:59 2004
From: linuxbios at matter.net (Larry Matter)
Date: Fri Jun 25 11:56:59 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <Pine.LNX.4.44.0406251019470.2176-100000@ccs-mail.lanl.gov>
References: <40DC5058.8040304@fuzzymuzzle.com>
    <Pine.LNX.4.44.0406251019470.2176-100000@ccs-mail.lanl.gov>
Message-ID: <2895.192.168.1.137.1088184285.squirrel@mail.matter.net>

> If you want a stripped
> kernel to fit alongside LinuxBIOS on your BIOS ROM, you can do that as
> well (Look at targets/arima/hdama/Config.kernelimage.lb for an example).

Last time I looked (or "googled" rather) it was not possible to squeeze a
kernel (plus linuxBios) into a 2 megabit bios rom.  Has this changed or
are you talking about mobos with bigger roms?

Thanks,
Larry


From rminnich at lanl.gov  Fri Jun 25 12:05:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jun 25 12:05:01 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <Pine.LNX.4.44.0406251101120.2176-100000@ccs-mail.lanl.gov>
Message-ID: <Pine.LNX.4.44.0406251131140.22766-100000@maxroach.lanl.gov>

On Fri, 25 Jun 2004, Hendricks David W. wrote:

> LinuxBIOS does not have its own kernel. The way it usually works is either 
> LinuxBIOS boots a kernel from flash or LinuxBIOS boots a payload (eg FILO 
> or Etherboot) which then boots a kernel. LinuxBIOS is its own entity in 
> either case.

I should jump in here and mention that the intent of the project, when we 
started, was: Linux == BIOS, i.e. LinuxBIOS. 

The shrinking flash parts changed our plans but not the name. 

I would still prefer, overall, to have kept linux in the flash as the real 
BIOS, but that is impossible on many platforms; hence the 'payload' 
concept. 

ron



From rminnich at lanl.gov  Fri Jun 25 12:05:26 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jun 25 12:05:26 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <2895.192.168.1.137.1088184285.squirrel@mail.matter.net>
Message-ID: <Pine.LNX.4.44.0406251132270.22766-100000@maxroach.lanl.gov>

On Fri, 25 Jun 2004, Larry Matter wrote:

> Last time I looked (or "googled" rather) it was not possible to squeeze
> a kernel (plus linuxBios) into a 2 megabit bios rom.  Has this changed
> or are you talking about mobos with bigger roms?

bigger roms.

ron



From dwh at lanl.gov  Fri Jun 25 12:08:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Jun 25 12:08:01 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <2895.192.168.1.137.1088184285.squirrel@mail.matter.net>
Message-ID: <Pine.LNX.4.44.0406251132210.2176-100000@ccs-mail.lanl.gov>

My mistake, I'm thinking of the 8Mb ROMs I use for other mainboards. Can 
an EPIA take a SST49LF080? Those aren't too expensive, and you can fit a 
decent-sized 2.6 kernel alongside LinuxBIOS on one.

On Fri, 25 Jun 2004, Larry Matter wrote:

> > If you want a stripped
> > kernel to fit alongside LinuxBIOS on your BIOS ROM, you can do that as
> > well (Look at targets/arima/hdama/Config.kernelimage.lb for an example).
> 
> Last time I looked (or "googled" rather) it was not possible to squeeze a
> kernel (plus linuxBios) into a 2 megabit bios rom.  Has this changed or
> are you talking about mobos with bigger roms?
> 
> Thanks,
> Larry
> 



From mrobinson at fuzzymuzzle.com  Fri Jun 25 12:09:01 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Fri Jun 25 12:09:01 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <Pine.LNX.4.44.0406251101120.2176-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0406251101120.2176-100000@ccs-mail.lanl.gov>
Message-ID: <40DC628D.8030905@fuzzymuzzle.com>

Sounds great, thanks for the help.  I have one other question though, 
LinuxBIOS will fit on a 4Mbit flash chip if my root filesystem in on a 
hard drive, correct?  Also, the specs for the VIA EPIA MII say the BIOS 
is 2/4Mbit, does this mean I can use either size or does it mean that it 
only works with one of these sizes?

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com

Hendricks David W. wrote:

>LinuxBIOS does not have its own kernel. The way it usually works is either 
>LinuxBIOS boots a kernel from flash or LinuxBIOS boots a payload (eg FILO 
>or Etherboot) which then boots a kernel. LinuxBIOS is its own entity in 
>either case.
>
>If you have an IDE hard disk, you can use LinuxBIOS and FILO to boot your 
>kernel off that hard disk and its existing filesystem as you would with 
>LILO or GRUB. FILO can be downloaded here: 
>http://te.to/~ts1/filo/ .
>
>Basically this is what I would do with your hardware:
>1. Download FILO, edit the Config file.
>	Change the AUTOBOOT_FILE line to let FILO know where your kernel 
>is located and also pass any extra kernel parameters. Example:
>hda2:/boot/x86_64 root=/dev/hda2 console=ttyS0,115200 console=tty0 vga=792 
>video=atyfb:mode:1024x768
>	Look under "# Filesystems" and enable whichever filesystem(s) you 
>require to read your kernel.
>	Run "make" to generate filo.elf
>
>2. Open your freebios2/targets/via/epia-m/Config.lb file and edit the 
>"payload" lines. There should be two of them, one under romimage "normal" 
>and one under romimage "fallback". Change them to point to filo.elf. For 
>example:
>	payload /usr/src/filo-0.4.2/filo.elf
>
>3. cd to freebios2/targets and run "./buildtarget via/epia-m/"
>4. cd to via/epia-m/epia-m and run "make"
>5. If all goes well, you should now have linuxbios.rom. Burn it on a spare 
>flash part (You can try the flash_rom utility in 
>freebios2/util/flash_and_burn), hook up a serial connection to another 
>computer, power cycle and see what happens.
>
>On Fri, 25 Jun 2004, Michael Robinson wrote:
>
>  
>
>>David,
>>
>>LinuxBIOS has its own kernel correct?  Or is LinuxBIOS not really a 
>>Linux kernel, but boots a Linux kernel that can be stored on the 
>>DiskOnChip or HDD?  I just want to verify how it works because I've 
>>heard so many references to multiple kernels that I'm not sure exactly 
>>how the whole process works.  In response to your last question I'd like 
>>to boot my distro off of hard disk if I'm thinking correctly.
>>
>>Thanks,
>>Michael Robinson
>>mrobinson at fuzzymuzzle.com
>>www.fuzzymuzzle.com
>>
>>Hendricks David W. wrote:
>>
>>    
>>
>>>You can do it that way, too. The method suggested earlier was to use the 
>>>distribution kernel on the compact flash device. If you want a stripped 
>>>kernel to fit alongside LinuxBIOS on your BIOS ROM, you can do that as 
>>>well (Look at targets/arima/hdama/Config.kernelimage.lb for an example). 
>>>You could then use Kexec or Two Kernel Monte (kmonte) to boot 
>>>another kernel.
>>>
>>>So I guess what we need to figure out is how you want to boot your kernel. 
>>>Do you want it to be booted off an IDE device or the same flash part 
>>>alongside your BIOS?
>>>
>>>On Fri, 25 Jun 2004, Michael Robinson wrote:
>>>
>>> 
>>>
>>>      
>>>
>>>>So in my case FILO is booting the actual Linux kernel that you will be 
>>>>using when you perform tasks on the computer?  So if you were using a 
>>>>DiskOnChip your Linux distribution kernel would be on the actual 
>>>>DiskOnChip?  I was under the impression that the LinuxBIOS kernel was on 
>>>>the DiskOnChip and the distribution kernel was on a hard drive.  Could 
>>>>you please clarify.
>>>>
>>>>Thanks,
>>>>Michael Robinson
>>>>mrobinson at fuzzymuzzle.com
>>>>www.fuzzymuzzle.com
>>>>
>>>>Hendricks David W. wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>Sounds about right. Put your kernel on an IDE device with a filesystem 
>>>>>(FILO supports EXT2/3, Reiser, XFS, etc) and use FILO as your LinuxBIOS 
>>>>>payload (payload /where/filo/is/located/filo.elf in your 
>>>>>targets/via/epia-m/Config.lb file). You also need to tell FILO where 
>>>>>yoru kernel is located and give it any options you want passed to the 
>>>>>kernel in the "AUTOBOOT_FILE" line, which should look something like 
>>>>>a LILO prompt: hda1:/kernel root/dev/hda3 console=ttyS0,115200 
>>>>>
>>>>>Boot image generally implies kernel. 
>>>>>
>>>>>On Fri, 25 Jun 2004, Michael Robinson wrote:
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>---The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE 
>>>>>>adapter. Using FILO you can boot from the CF.---
>>>>>>
>>>>>>So I'd flash FILO to the BIOS, then it would load the LinuxBIOS kernel 
>>>>>>image, and then the kernel image would do whatever you want LinuxBIOS to 
>>>>>>do, right? Or am I wrong... It says FILO loads a "boot image", whats the 
>>>>>>definition of a "boot image", is it just the kernel?
>>>>>>
>>>>>>Thanks,
>>>>>>Michael Robinson
>>>>>>mrobinson at fuzzymuzzle.com
>>>>>>www.fuzzymuzzle.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>Larry Matter wrote:
>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>>what
>>>>>>>>does the DiskOnChip provide to the LinuxBIOs project that the standard
>>>>>>>>flash chip can't?
>>>>>>>> 
>>>>>>>>
>>>>>>>>      
>>>>>>>>
>>>>>>>>           
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>More than 2 megabits of storage.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>My second is that I'm going to be using the VIA EPIA
>>>>>>>>MII motherboard which has a PLCC BIOS, as far as I can tell PLCC
>>>>>>>>DiskOnChips aren't very readily available.  Should I use a DIP to PLCC
>>>>>>>>adapter; how did the other people who used this board do it?
>>>>>>>> 
>>>>>>>>
>>>>>>>>      
>>>>>>>>
>>>>>>>>           
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>The trend seems to be NOT to use DiskOnChip but rather a CF <> IDE
>>>>>>>adapter.  Using FILO you can boot from the CF.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>My final
>>>>>>>>question is how do I pick the size of the DiskOnChip.
>>>>>>>> 
>>>>>>>>
>>>>>>>>      
>>>>>>>>
>>>>>>>>           
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>So if you're going to go for the CF <> IDE, then it just needs to be as
>>>>>>>big as your root partition (or even just an initrd).   There are many
>>>>>>>other alternatives depending on network, disk, etc.
>>>>>>>
>>>>>>>And if you've been following this list for a bit you'll know that you
>>>>>>>can't (yet) boot off of the CF adapter on the EPIA MII.
>>>>>>>
>>>>>>>One last word of advice, get a bios savior.
>>>>>>>
>>>>>>>Larry
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    
>>>>>>>
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>_______________________________________________
>>>>>>Linuxbios mailing list
>>>>>>Linuxbios at clustermatic.org
>>>>>>http://www.clustermatic.org/mailman/listinfo/linuxbios
>>>>>>
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>
>
>
>
>  
>



From mrobinson at fuzzymuzzle.com  Fri Jun 25 12:16:01 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Fri Jun 25 12:16:01 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <Pine.LNX.4.44.0406251132210.2176-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0406251132210.2176-100000@ccs-mail.lanl.gov>
Message-ID: <40DC6429.8070800@fuzzymuzzle.com>

 From what I've read on Via's site the EPIAs use a 2/4Mbit ROM, what is 
the limiting factor as to how big the ROM can be?

Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com

Hendricks David W. wrote:

>My mistake, I'm thinking of the 8Mb ROMs I use for other mainboards. Can 
>an EPIA take a SST49LF080? Those aren't too expensive, and you can fit a 
>decent-sized 2.6 kernel alongside LinuxBIOS on one.
>
>On Fri, 25 Jun 2004, Larry Matter wrote:
>
>  
>
>>>If you want a stripped
>>>kernel to fit alongside LinuxBIOS on your BIOS ROM, you can do that as
>>>well (Look at targets/arima/hdama/Config.kernelimage.lb for an example).
>>>      
>>>
>>Last time I looked (or "googled" rather) it was not possible to squeeze a
>>kernel (plus linuxBios) into a 2 megabit bios rom.  Has this changed or
>>are you talking about mobos with bigger roms?
>>
>>Thanks,
>>Larry
>>
>>    
>>
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios
>
>
>
>  
>



From dwh at lanl.gov  Fri Jun 25 12:20:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Jun 25 12:20:00 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <40DC628D.8030905@fuzzymuzzle.com>
Message-ID: <Pine.LNX.4.44.0406251140560.2176-100000@ccs-mail.lanl.gov>

LinuxBIOS is actually very small (64KB), it will fit easily on a 256KB 
flash part. However, you must be careful about the size of your part. If 
you have a 256KB flash part, then you need to adjust the ROM_SIZE in 
your Config.lb file accordingly:
option ROM_SIZE=256*1024
If you're on a 512KB flash part, then it should be this:
option ROM_SIZE=512*1024

Also, on a 512KB flash part, you can concatinate a 256KB linuxbios.rom 
twice into another file and burn that instead, so long as the file size 
is 512KB.

On Fri, 25 Jun 2004, Michael Robinson wrote:

> Sounds great, thanks for the help.  I have one other question though, 
> LinuxBIOS will fit on a 4Mbit flash chip if my root filesystem in on a 
> hard drive, correct?  Also, the specs for the VIA EPIA MII say the BIOS 
> is 2/4Mbit, does this mean I can use either size or does it mean that it 
> only works with one of these sizes?
> 
> Thanks,
> Michael Robinson
> mrobinson at fuzzymuzzle.com
> www.fuzzymuzzle.com
> 



From mrobinson at fuzzymuzzle.com  Fri Jun 25 12:45:01 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Fri Jun 25 12:45:01 2004
Subject: LVDS Support
Message-ID: <40DC6AE6.9070306@fuzzymuzzle.com>

The VIA EPIA MII can be bought with an LVDS port on it and I was 
wondering the compatibility of this.  Obviously its not supported under 
LinuxBIOS, but would it work under Linux?  A guy told me that the LCD 
panel had to be supported by VIA's BIOS for it to work.  Should Linux be 
able to setup something like this since LinuxBIOS leaves most of that 
stuff to Linux or does it have to be done by the BIOS (ie if Linux 
doesn't support LVDS)?

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com



From mrobinson at fuzzymuzzle.com  Fri Jun 25 12:53:00 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Fri Jun 25 12:53:00 2004
Subject: LVDS Support
In-Reply-To: <40DC6AE6.9070306@fuzzymuzzle.com>
References: <40DC6AE6.9070306@fuzzymuzzle.com>
Message-ID: <40DC6C9D.3020902@fuzzymuzzle.com>

It looks like LVDS is a BIOS only thing, all of the pages on getting it 
running under Linux refer you back to the BIOS... Hmm...

Michael Robinson wrote:

> The VIA EPIA MII can be bought with an LVDS port on it and I was 
> wondering the compatibility of this.  Obviously its not supported 
> under LinuxBIOS, but would it work under Linux?  A guy told me that 
> the LCD panel had to be supported by VIA's BIOS for it to work.  
> Should Linux be able to setup something like this since LinuxBIOS 
> leaves most of that stuff to Linux or does it have to be done by the 
> BIOS (ie if Linux doesn't support LVDS)?
>
> Thanks,
> Michael Robinson
> mrobinson at fuzzymuzzle.com
> www.fuzzymuzzle.com
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
>
>



From tony_cheng at pcmagic.net  Fri Jun 25 12:53:25 2004
From: tony_cheng at pcmagic.net (Tony Cheng)
Date: Fri Jun 25 12:53:25 2004
Subject: CVS Server down? 
References: <1088098025.8331.135.camel@exponential.lanl.gov>	 <009f01c45a19$bc477b60$932614ac@trans.corp> <1088175250.15464.1.camel@exponential.lanl.gov>
Message-ID: <40DC6D06.10707@pcmagic.net>

Does the CVS server down?

I get a "timed out" message like below.  I can access the CVS about 10 
days ago.


$ cvs 
-d:pserver:anonymous at cvs.freebios.sourceforge.net:/cvsroot/freebios login
Logging in to 
:pserver:anonymous at cvs.freebios.sourceforge.net:2401/cvsroot/freebios
CVS password:

cvs [login aborted]: connect to 
cvs.freebios.sourceforge.net(66.35.250.209):2401 failed: Connection 
timed out

Tony


Li-Ta Lo wrote:

>The AMD Serenade board support for ROMCC LinuxBIOS is in the CVS. Please
>do a "cvs update -dP". The cache as ram version is not committed yet.
>
>Ollie
>
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios
>
>
>  
>





From dwh at lanl.gov  Fri Jun 25 13:49:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Jun 25 13:49:01 2004
Subject: CVS Server down? 
In-Reply-To: <40DC6D06.10707@pcmagic.net>
Message-ID: <Pine.LNX.4.44.0406251311420.2176-100000@ccs-mail.lanl.gov>

Guess it's that time of year again when Sourceforge starts to buckle.

Those of us blessed with developer access tend to have a higher rate 
of success when syncing to the CVS tree. Here's a snapshot from about 3 
minutes ago:
http://www.flagen.com/~sc/linux/lb/cvs_snapshots/freebios2-06252004.tar.bz2

On Fri, 25 Jun 2004, Tony Cheng wrote:

> Does the CVS server down?
> 
> I get a "timed out" message like below.  I can access the CVS about 10 
> days ago.
> 
> 
> $ cvs 
> -d:pserver:anonymous at cvs.freebios.sourceforge.net:/cvsroot/freebios login
> Logging in to 
> :pserver:anonymous at cvs.freebios.sourceforge.net:2401/cvsroot/freebios
> CVS password:
> 
> cvs [login aborted]: connect to 
> cvs.freebios.sourceforge.net(66.35.250.209):2401 failed: Connection 
> timed out
> 
> Tony
> 
> 
> Li-Ta Lo wrote:
> 
> >The AMD Serenade board support for ROMCC LinuxBIOS is in the CVS. Please
> >do a "cvs update -dP". The cache as ram version is not committed yet.
> >
> >Ollie
> >
> >
> >_______________________________________________
> >Linuxbios mailing list
> >Linuxbios at clustermatic.org
> >http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
> >
> >  
> >
> 
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rsmith at bitworks.com  Fri Jun 25 13:51:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Jun 25 13:51:00 2004
Subject: LVDS Support
In-Reply-To: <40DC6C9D.3020902@fuzzymuzzle.com>
References: <40DC6AE6.9070306@fuzzymuzzle.com> <40DC6C9D.3020902@fuzzymuzzle.com>
Message-ID: <40DC7A86.8020408@bitworks.com>

Michael Robinson wrote:

> It looks like LVDS is a BIOS only thing, all of the pages on getting it 
> running under Linux refer you back to the BIOS... Hmm...
>

Thats because thats normally a bios/vbios type deal.  When you are 
dealing with a panel direct its a whole different ball game.

Do you know if the LVDS is part of the EPIA video system or if its 
seperate descrete chips?

LVDS has a couple of flavors depending on what type of panel you are 
talking to.  So the vbios will normally query the system bios for a 
panel type or some bios config setting.  Based on the panel type it will 
set the internal chip registers or toggle gpio lines to put descrete 
chips in the right mode.

CRTC Timeings are also panel specific.  There are VESA timeings but lots 
of panels still need tweaking.

some linux fb drivers and X drivers can deal with these issues but for 
legacy VGA mode the vbios enables some video sytem trickery.






From hansolofalcon at worldnet.att.net  Fri Jun 25 14:14:01 2004
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Fri Jun 25 14:14:01 2004
Subject: CVS Server down? 
In-Reply-To: <Pine.LNX.4.44.0406251311420.2176-100000@ccs-mail.lanl.gov>
Message-ID: <000501c45aec$8bd091a0$6401a8c0@who5>

Hello from Gregg C Levine
Tony are you accessing the CVS storage via the instructions on the
regular Linux BIOS website? Or on the Source Forge instructions page?
Of the two the Source Forge instructions page are correct. And in fact
I just checked, these pages, the ones at 
http://sourceforge.net/cvs/?group_id=3206 are correct. The ones that
are up at the regular website are not, they are over due for updating.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi

> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Hendricks David W.
> Sent: Friday, June 25, 2004 3:16 PM
> To: Tony Cheng
> Cc: Li-Ta Lo; LinuxBIOS
> Subject: Re: CVS Server down?
> 
> Guess it's that time of year again when Sourceforge starts to
buckle.
> 
> Those of us blessed with developer access tend to have a higher rate
> of success when syncing to the CVS tree. Here's a snapshot from
about 3
> minutes ago:
>
http://www.flagen.com/~sc/linux/lb/cvs_snapshots/freebios2-06252004.ta
r.bz2
> 
> On Fri, 25 Jun 2004, Tony Cheng wrote:
> 
> > Does the CVS server down?
> >
> > I get a "timed out" message like below.  I can access the CVS
about 10
> > days ago.
> >
> >
> > $ cvs
> >
-d:pserver:anonymous at cvs.freebios.sourceforge.net:/cvsroot/freebios
login
> > Logging in to
> >
:pserver:anonymous at cvs.freebios.sourceforge.net:2401/cvsroot/freebios
> > CVS password:
> >
> > cvs [login aborted]: connect to
> > cvs.freebios.sourceforge.net(66.35.250.209):2401 failed:
Connection
> > timed out
> >
> > Tony
> >
> >
> > Li-Ta Lo wrote:
> >
> > >The AMD Serenade board support for ROMCC LinuxBIOS is in the CVS.
> Please
> > >do a "cvs update -dP". The cache as ram version is not committed
yet.
> > >
> > >Ollie
> > >
> > >
> > >_______________________________________________
> > >Linuxbios mailing list
> > >Linuxbios at clustermatic.org
> > >http://www.clustermatic.org/mailman/listinfo/linuxbios
> > >
> > >
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From ebiederman at lnxi.com  Fri Jun 25 14:21:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Jun 25 14:21:01 2004
Subject: Using Cache As Ram for K8
In-Reply-To: <1088176272.15464.21.camel@exponential.lanl.gov>
References: <1088098025.8331.135.camel@exponential.lanl.gov>
	<m37jtwfv73.fsf@maxwell.lnxi.com>
	<1088176272.15464.21.camel@exponential.lanl.gov>
Message-ID: <m3k6xv8lkz.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Thu, 2004-06-24 at 16:27, Eric W. Biederman wrote:
> > > There are few problems remaining. The first thing is I can only
> > > use 7 cache lines of cache (448 bytes) reliably in the K8. The
> > > access to the 8th cache line is unstable and the access to the
> > > 9th cache line hangs the processor. The other problem is the
> > > optimize_connection() function for multi-processor configuration
> > > runs unstably under CAR. It does not overflow the stack, it's just
> > > plain unstable for some reason. So I can only configure the mainboard
> > > as Uniprocessor.
> > 
> > Most likely it is the cross cpu probes, causing cache invalidates.
> > You may be able to ``improperly'' setup caching of memory (no cross
> > cpu probes) while you are initializing the memory controllers.
> > 
> 
> That is exactly the point I don't understand. In theory, the AP is
> halted and HT routing disabled on powerup before the first instruction
> is even executed. But to what extend is the processor "halted", does it
> still try to maintain cache coherence ? 

Yes.  Only the instruction dispatch unit is halted.  The other functionality
continues to work.  Intel cpus do this to some extent as well.  Although
I think a halted processor does is quite.

Look at what disable_probes does in the hypertransport initialization.
Those are the control bits of to see if another cpu is asked about
cache coherency.

> And how about the northbridge
> in the processor ? Obviously, the northbridge is in a working state
> when the processor is halted, what is the impact of northbridge on the
> cache of the processor ?

The northbridge should not generate any requests on it's own.

> > On the fun side it would be extremely interesting is if you could get
> > enough  memory working to start paging and we could go into 64bit mode :)
> > That is likely tempting fate too much.....
> > 
> 
> Why does CAR have anything to do with entering 64bit mode ?

64bit mode can only be entered with paging enabled.  With 64K of L1
cache there is enough space to hold the page tables.  Roughly
(4K+4K+4K+4K + 4K + 4K) =  24K is needed to map 4G of memory without
using a hack of page table.  That is not something we want to use
before some kind of memory is initialized because it would waste rom
space much worse than romcc. 

.....

Now that Intel in ``Intel Pentium 4 Processors on 90num Process Specification update''
R28 has let the cat out of the bag I cant vent a little.  Intel is formally
supporting cache as ram in their newest cpus, and there have been enough
issues having romcc and not having to worry about them has been a
relief.  This may just be a temporary case of teething pains but...

Eric


From ebiederman at lnxi.com  Fri Jun 25 14:25:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Jun 25 14:25:00 2004
Subject: [Fwd: Re: DiskOnChip Questions]
In-Reply-To: <40DC6429.8070800@fuzzymuzzle.com>
References: <Pine.LNX.4.44.0406251132210.2176-100000@ccs-mail.lanl.gov>
	<40DC6429.8070800@fuzzymuzzle.com>
Message-ID: <m3fz8j8le7.fsf@maxwell.lnxi.com>

Michael Robinson <mrobinson at fuzzymuzzle.com> writes:

>  From what I've read on Via's site the EPIAs use a 2/4Mbit ROM, what is the
> limiting factor as to how big the ROM can be?

For an ISA or X-bus part the number of address lines. 
  4Mbit is the limit in a normal 32pin configuration.
For an LPC part the size of the chip you can buy.

AMD and Intel have switched over to using the LPC bus in their
chipsets a year or two ago.  I don't know what VIA has done, but
I expect their are also using the LPC bus by now.

Eric


From mrobinson at fuzzymuzzle.com  Fri Jun 25 14:42:00 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Fri Jun 25 14:42:00 2004
Subject: LVDS Support
In-Reply-To: <40DC7A86.8020408@bitworks.com>
References: <40DC6AE6.9070306@fuzzymuzzle.com> <40DC6C9D.3020902@fuzzymuzzle.com> <40DC7A86.8020408@bitworks.com>
Message-ID: <40DC8636.7060602@fuzzymuzzle.com>

 From what I've read it appears that the actual GPU is built into the 
Northbridge with integrated 8x AGP but the output is handled by 
different chips depending on what format you want to output in (ie 
Composite, VGA, LVDS).  The chipset homepage is here: 
http://www.via.com.tw/en/c-series/cle266.jsp and apparently the LVDS 
chip is a Chrontel 7019A (VIA's part number for it is the LVDS-01).  
I've uploaded the PDF datasheet for the LVDS-01 here: 
http://www.fuzzymuzzle.com/uploads/LVDS-01.pdf  I'll Google this chip 
and see if anyone else has had any luck with it on Linux.

Thanks,
Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com

Richard Smith wrote:

> Michael Robinson wrote:
>
>> It looks like LVDS is a BIOS only thing, all of the pages on getting 
>> it running under Linux refer you back to the BIOS... Hmm...
>>
>
> Thats because thats normally a bios/vbios type deal.  When you are 
> dealing with a panel direct its a whole different ball game.
>
> Do you know if the LVDS is part of the EPIA video system or if its 
> seperate descrete chips?
>
> LVDS has a couple of flavors depending on what type of panel you are 
> talking to.  So the vbios will normally query the system bios for a 
> panel type or some bios config setting.  Based on the panel type it 
> will set the internal chip registers or toggle gpio lines to put 
> descrete chips in the right mode.
>
> CRTC Timeings are also panel specific.  There are VESA timeings but 
> lots of panels still need tweaking.
>
> some linux fb drivers and X drivers can deal with these issues but for 
> legacy VGA mode the vbios enables some video sytem trickery.
>
>
>
>
>
>
>



From mrobinson at fuzzymuzzle.com  Fri Jun 25 15:07:00 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Fri Jun 25 15:07:00 2004
Subject: LVDS Support
In-Reply-To: <40DC8636.7060602@fuzzymuzzle.com>
References: <40DC6AE6.9070306@fuzzymuzzle.com> <40DC6C9D.3020902@fuzzymuzzle.com> <40DC7A86.8020408@bitworks.com> <40DC8636.7060602@fuzzymuzzle.com>
Message-ID: <40DC8C26.4050300@fuzzymuzzle.com>

Well, it seems that the SiS driver supports it, just search for 7019 
(all references to it in Google are without the "A") on this page:  
http://www.xfree86.org/4.4.0/sis.4.html  So it must be fairly easy to 
port the code to the VIA, although the SiS driver most likely takes into 
account that the BIOS contains display information.  All references to 
the 7019 go to the SiS driver, it must be the only one that implements 
the LVDS interface.


Michael Robinson wrote:

> From what I've read it appears that the actual GPU is built into the 
> Northbridge with integrated 8x AGP but the output is handled by 
> different chips depending on what format you want to output in (ie 
> Composite, VGA, LVDS).  The chipset homepage is here: 
> http://www.via.com.tw/en/c-series/cle266.jsp and apparently the LVDS 
> chip is a Chrontel 7019A (VIA's part number for it is the LVDS-01).  
> I've uploaded the PDF datasheet for the LVDS-01 here: 
> http://www.fuzzymuzzle.com/uploads/LVDS-01.pdf  I'll Google this chip 
> and see if anyone else has had any luck with it on Linux.
>
> Thanks,
> Michael Robinson
> mrobinson at fuzzymuzzle.com
> www.fuzzymuzzle.com
>
> Richard Smith wrote:
>
>> Michael Robinson wrote:
>>
>>> It looks like LVDS is a BIOS only thing, all of the pages on getting 
>>> it running under Linux refer you back to the BIOS... Hmm...
>>>
>>
>> Thats because thats normally a bios/vbios type deal.  When you are 
>> dealing with a panel direct its a whole different ball game.
>>
>> Do you know if the LVDS is part of the EPIA video system or if its 
>> seperate descrete chips?
>>
>> LVDS has a couple of flavors depending on what type of panel you are 
>> talking to.  So the vbios will normally query the system bios for a 
>> panel type or some bios config setting.  Based on the panel type it 
>> will set the internal chip registers or toggle gpio lines to put 
>> descrete chips in the right mode.
>>
>> CRTC Timeings are also panel specific.  There are VESA timeings but 
>> lots of panels still need tweaking.
>>
>> some linux fb drivers and X drivers can deal with these issues but 
>> for legacy VGA mode the vbios enables some video sytem trickery.
>>
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
>
>



From rminnich at lanl.gov  Fri Jun 25 15:16:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jun 25 15:16:01 2004
Subject: CVS Server down? 
In-Reply-To: <40DC6D06.10707@pcmagic.net>
Message-ID: <Pine.LNX.4.44.0406251443200.24857-100000@maxroach.lanl.gov>

On Fri, 25 Jun 2004, Tony Cheng wrote:

> $ cvs 
> -d:pserver:anonymous at cvs.freebios.sourceforge.net:/cvsroot/freebios login
> Logging in to 
> :pserver:anonymous at cvs.freebios.sourceforge.net:2401/cvsroot/freebios
> CVS password:
> 

sorry, change to 
cvs.sourceforge.net

take the freebios out

ron



From YhLu at tyan.com  Fri Jun 25 15:41:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jun 25 15:41:00 2004
Subject: E7501 support in V2
Message-ID: <3174569B9743D511922F00A0C943142305535B46@TYANWEB>

Eric,

I made some progress. Till now it can not start other CPUs. And post code is
75. What can cause that?

Regards

YH

LinuxBIOS-1.1.62.0_Fallback Fri Jun 25 12:32:23 PDT 2004 starting...
SMBus controller enabled
Ram1.00
Setting RCOMP registers.
PCI: 00:00.00
00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00
50: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 10 00 00 00 09 00 44 00
80: 00 00 71 00 00 00 00 00 00 a0 31 02 80 00 00 00
90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 44 c0 50 11 00 08 ff 03 00 00 00 00 00 00 00 00
d0: 02 28 00 0e 03 00 00 33 80 69 31 b5 00 00 00 00
e0: 1d 1d 00 00 00 00 00 00 54 48 00 00 00 00 00 00
f0: 00 00 00 00 74 00 00 40 40 0f 00 00 00 00 00 00
0000002c <-358015d9
00000080 <-00000bb1
00000088 <-00000080
00000058 <-33333000
0000005c <-33333333
00000060 <-04030201
00000064 <-08070605
00000068 <-00000000
0000006c <-00000000
00000070 <-00000000
00000074 <-00000000
00000078 <-3901041f
0000007c <-00650000
00000088 <-d20a9800
0000008c <-0000000f
000000c4 <-03ff2000
000000c8 <-00000000
000000e0 <-0000001c
000000d8 <-00000000
000000f4 <-40300002
00001050 <-00000030
PCI: 00:00.00
00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 80 35
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00
50: 04 00 00 00 00 00 00 00 00 30 33 33 33 33 33 33
60: 01 02 03 04 05 06 07 08 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 1f 04 01 39 09 00 65 00
80: b1 0b 71 00 00 00 00 00 00 98 0a d2 8f 00 00 00
90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 44 c0 50 11 00 20 ff 03 00 00 00 00 00 00 00 00
d0: 02 28 00 0e 03 00 00 33 80 09 31 b5 00 00 00 00
e0: 1c 1d 00 00 00 00 00 00 54 48 00 00 00 00 00 00
f0: 00 00 00 00 76 00 30 40 40 0f 00 00 00 00 00 00
Ram2.00
Reading SPD data...
setting based on SPD data...
page size =00000011 00000011
width =00000008 00000008
page size =00000011 00000011
width =00000008 00000008
page size =00000000 00000000
width =00000000 00000000
page size =00000000 00000000
width =00000000 00000000
done
Ram3
Ram Enable 1
Ram Enable 2
Ram Enable 3
Ram Enable 4
Ram Enable 5
Ram Enable 6
Ram Enable 7
Ram Enable 8
Ram Enable 9
Ram Enable 10
Ram Enable 11
dimm size =00000020 00000020
dimm size =00000020 00000020
dimm size =00000000 00000000
dimm size =00000000 00000000
Initializing ECC state...
ECC state initialized.
PCI: 00:00.00
00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 80 35
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00
50: 04 00 0d 00 00 00 00 00 00 30 33 33 33 33 33 33
60: 10 20 30 40 40 40 40 40 00 00 00 00 00 00 00 00
70: 44 44 00 00 00 00 00 00 14 02 01 39 79 02 67 20
80: b1 0b 71 00 00 00 00 00 00 98 10 d2 8c 00 00 00
90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 44 c0 50 11 00 c0 40 00 50 00 00 00 00 00 00 00
d0: 02 28 00 0e 03 00 00 33 80 09 31 b5 00 00 00 00
e0: 1c 1d 00 00 00 00 00 00 54 48 00 00 00 00 00 00
f0: 00 00 00 00 76 00 30 40 40 0f 00 00 00 00 00 00
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.62.0_Fallback Fri Jun 25 12:32:23 PDT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating static devices...
Enumerating: intel E7501 Northbridge
Enumerating: Intel 82801er Southbridge
Enumerating: Winbond w83627hf
Enumerating buses...
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [8086/254c] enabled
PCI: 00:00.1 [8086/2541] enabled
PCI: 00:02.0 [8086/2543] enabled
PCI: 00:06.0 [8086/2549] enabled
PCI: 00:1d.0 [8086/24d2] ops
PCI: 00:1d.0 [8086/24d2] enabled
PCI: 00:1d.1 [8086/24d4] ops
PCI: 00:1d.1 [8086/24d4] enabled
PCI: 00:1d.2 [8086/24d7] ops
PCI: 00:1d.2 [8086/24d7] enabled
PCI: 00:1d.3 [8086/24de] ops
PCI: 00:1d.3 [8086/24de] enabled
PCI: 00:1d.7 [8086/24dd] ops
PCI: 00:1d.7 [8086/24dd] enabled
PCI: 00:1e.0 [8086/244e] enabled
PCI: 00:1f.0 [8086/24d0] bus ops
PCI: 00:1f.0 [8086/24d0] enabled
PCI: 00:1f.1 [8086/24db] ops
PCI: 00:1f.1 [8086/24db] enabled
PCI: 00:1f.2 [8086/24df] enabled
PCI: 00:1f.3 [8086/24d3] enabled
PCI: 00:1f.5 [8086/24d5] ops
PCI: 00:1f.5 [8086/24d5] enabled
PCI: 00:1f.6 [8086/24d6] ops
PCI: 00:1f.6 [8086/24d6] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:1c.0 [8086/1461] enabled
PCI: 01:1d.0 [8086/1460] enabled
PCI: 01:1e.0 [8086/1461] enabled
PCI: 01:1f.0 [8086/1460] enabled
PCI: pci_scan_bus for bus 2
PCI: 02:01.0 [8086/1010] enabled
PCI: 02:01.1 [8086/1010] enabled
PCI: pci_scan_bus returning with max=02
PCI: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: pci_scan_bus returning with max=03
PCI: pci_scan_bus for bus 4
PCI: 04:02.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=04
scan_static_bus for PCI: 00:1f.0
scan_static_bus done
PCI: pci_scan_bus returning with max=04
done
Allocating resources...
Allocating VGA resource PCI: 04:02.0
ASSIGN RESOURCES, bus 0
PCI: 00:02.0 1c <- [0x00001000 - 0x00001fff] bus 1 io
PCI: 00:02.0 24 <- [0xfe300000 - 0xfe2fffff] bus 1 prefmem
PCI: 00:02.0 20 <- [0xfe100000 - 0xfe2fffff] bus 1 mem
ASSIGN RESOURCES, bus 1
PCI: 01:1c.0 10 <- [0xfe200000 - 0xfe200fff] mem
PCI: 01:1d.0 1c <- [0x00001000 - 0x00001fff] bus 2 io
PCI: 01:1d.0 24 <- [0xfe300000 - 0xfe2fffff] bus 2 prefmem
PCI: 01:1d.0 20 <- [0xfe100000 - 0xfe1fffff] bus 2 mem
ASSIGN RESOURCES, bus 2
PCI: 02:01.0 10 <- [0xfe100000 - 0xfe11ffff] mem
PCI: 02:01.0 20 <- [0x00001000 - 0x0000103f] io
PCI: 02:01.1 10 <- [0xfe120000 - 0xfe13ffff] mem
PCI: 02:01.1 20 <- [0x00001040 - 0x0000107f] io
ASSIGNED RESOURCES, bus 2
PCI: 01:1e.0 10 <- [0xfe201000 - 0xfe201fff] mem
PCI: 01:1f.0 1c <- [0x00002000 - 0x00001fff] bus 3 io
PCI: 01:1f.0 24 <- [0xfe300000 - 0xfe2fffff] bus 3 prefmem
PCI: 01:1f.0 20 <- [0xfe200000 - 0xfe1fffff] bus 3 mem
ASSIGNED RESOURCES, bus 1
PCI: 00:1d.0 20 <- [0x00003480 - 0x0000349f] io
PCI: 00:1d.1 20 <- [0x000034a0 - 0x000034bf] io
PCI: 00:1d.2 20 <- [0x000034c0 - 0x000034df] io
PCI: 00:1d.3 20 <- [0x000034e0 - 0x000034ff] io
PCI: 00:1d.7 10 <- [0xfe300000 - 0xfe3003ff] mem
PCI: 00:1e.0 1c <- [0x00002000 - 0x00002fff] bus 4 io
PCI: 00:1e.0 24 <- [0xfe300000 - 0xfe2fffff] bus 4 prefmem
PCI: 00:1e.0 20 <- [0xfd000000 - 0xfe0fffff] bus 4 mem
ASSIGN RESOURCES, bus 4
PCI: 04:02.0 10 <- [0xfd000000 - 0xfdffffff] mem
PCI: 04:02.0 14 <- [0x00002000 - 0x000020ff] io
PCI: 04:02.0 18 <- [0xfe000000 - 0xfe000fff] mem
ASSIGNED RESOURCES, bus 4
PCI: 00:1f.0 00 <- [0x00000000 - 0xffffffff] io
PCI: 00:1f.0 00 <- [0x00000000 - 0xffffffff] mem
PCI: 00:1f.1 10 <- [0x00003840 - 0x00003847] io
PCI: 00:1f.1 14 <- [0x00003880 - 0x00003883] io
PCI: 00:1f.1 18 <- [0x00003850 - 0x00003857] io
PCI: 00:1f.1 1c <- [0x00003890 - 0x00003893] io
PCI: 00:1f.1 20 <- [0x00003820 - 0x0000382f] io
PCI: 00:1f.1 24 <- [0xfe301000 - 0xfe3013ff] mem
PCI: 00:1f.2 10 <- [0x00003860 - 0x00003867] io
PCI: 00:1f.2 14 <- [0x000038a0 - 0x000038a3] io
PCI: 00:1f.2 18 <- [0x00003870 - 0x00003877] io
PCI: 00:1f.2 1c <- [0x000038b0 - 0x000038b3] io
PCI: 00:1f.2 20 <- [0x00003830 - 0x0000383f] io
PCI: 00:1f.3 20 <- [0x00003800 - 0x0000381f] io
PCI: 00:1f.5 18 <- [0xfe302000 - 0xfe3021ff] mem
PCI: 00:1f.5 1c <- [0xfe303000 - 0xfe3030ff] mem
PCI: 00:1f.6 10 <- [0x00003000 - 0x000030ff] io
PCI: 00:1f.6 14 <- [0x00003400 - 0x0000347f] io
ASSIGNED RESOURCES, bus 0
done.
Enabling resourcess...
PCI: 00:00.0 cmd <- 146
PCI: 00:00.1 cmd <- 140
PCI: 00:02.0 bridge ctrl <- 0003
PCI: 00:02.0 cmd <- 147
PCI: 01:1c.0 cmd <- 142
PCI: 01:1d.0 bridge ctrl <- 0003
PCI: 01:1d.0 cmd <- 147
PCI: 02:01.0 cmd <- 143
PCI: 02:01.1 cmd <- 143
PCI: 01:1e.0 cmd <- 142
PCI: 01:1f.0 bridge ctrl <- 0003
PCI: 01:1f.0 cmd <- 147
PCI: 00:06.0 cmd <- 140
PCI: 00:1d.0 cmd <- 141
PCI: 00:1d.1 cmd <- 141
PCI: 00:1d.2 cmd <- 141
PCI: 00:1d.3 cmd <- 141
PCI: 00:1d.7 cmd <- 142
PCI: 00:1e.0 bridge ctrl <- 000b
PCI: 00:1e.0 cmd <- 147
PCI: 04:02.0 cmd <- 1c3
PCI: 00:1f.0 cmd <- 14f
PCI: 00:1f.1 cmd <- 143
PCI: 00:1f.2 cmd <- 141
PCI: 00:1f.3 cmd <- 141
PCI: 00:1f.5 cmd <- 142
PCI: 00:1f.6 cmd <- 141
done.
Initializing devices...
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 00:1d.0 init
PCI: 00:1d.1 init
PCI: 00:1d.2 init
PCI: 00:1d.3 init
PCI: 00:1d.7 init
PCI: 00:1f.0 init
ioapic southbridge enabled 2186
Southbridge apic id = 2000000
set power on after power fail
RTC Init
Invalid CMOS LB checksum
PCI: 00:1f.1 init
Devices initialized
remap_high is 0
totalram: 4096M
Initializing CPU #0
Enabling cache...
Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) type: WB
Setting fixed MTRRs(24-88) type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
Setting variable MTRR 4, base: 3840MB, range:  128MB, type WB
Setting variable MTRR 5, base: 4096MB, range:  128MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's
call intel_enable_fixed_mtrr()
call intel_enable_var_mtrr()
Leave setup_mtrrs
done.

Max cpuid index    : 2
Vendor ID          : GenuineIntel
Processor Type     : 0x00
Processor Family   : 0x0f
Processor Model    : 0x02
Processor Mask     : 0x00
Processor Stepping : 0x04
Feature flags      : 0x3febfbff

Cache/TLB descriptor values: 1 reads required
Desc 0x50 : UNKNOWN
Desc 0x5b : UNKNOWN
Desc 0x66 : UNKNOWN
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x40 : No L2 cache
Desc 0x70 : UNKNOWN
Desc 0x7b : UNKNOWN
Desc 0x00 : null



MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Updating microcode
microcode_info: sig = 0x00000f24 pf=0x00000002 rev = 0x00000000
Setting up local apic... apic_id: 0 done.
CPU #0 Initialized


From YhLu at tyan.com  Fri Jun 25 16:09:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jun 25 16:09:01 2004
Subject: E7501 support in V2
Message-ID: <3174569B9743D511922F00A0C943142305535B51@TYANWEB>

Eric,

I find the problem, need to call init_timer in p6 cpu fixup. It works well
now.

Some code should be moved to p6 or even p5.

For example:
apic_timper.c
enable_mmx_sse.inc/disable_mmx_sse.inc

regards

YH


-----????-----
???: YhLu 
????: 2004?6?25? 14:12
???: ebiederman at lnxi.com
??: ron minnich; Stefan Reinauer; LinuxBIOS
??: Re: E7501 support in V2

Eric,

I made some progress. Till now it can not start other CPUs. And post code is
75. What can cause that?

Regards

YH

LinuxBIOS-1.1.62.0_Fallback Fri Jun 25 12:32:23 PDT 2004 starting...
SMBus controller enabled
Ram1.00
Setting RCOMP registers.
PCI: 00:00.00
00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00
50: 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 10 00 00 00 09 00 44 00
80: 00 00 71 00 00 00 00 00 00 a0 31 02 80 00 00 00
90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 44 c0 50 11 00 08 ff 03 00 00 00 00 00 00 00 00
d0: 02 28 00 0e 03 00 00 33 80 69 31 b5 00 00 00 00
e0: 1d 1d 00 00 00 00 00 00 54 48 00 00 00 00 00 00
f0: 00 00 00 00 74 00 00 40 40 0f 00 00 00 00 00 00
0000002c <-358015d9
00000080 <-00000bb1
00000088 <-00000080
00000058 <-33333000
0000005c <-33333333
00000060 <-04030201
00000064 <-08070605
00000068 <-00000000
0000006c <-00000000
00000070 <-00000000
00000074 <-00000000
00000078 <-3901041f
0000007c <-00650000
00000088 <-d20a9800
0000008c <-0000000f
000000c4 <-03ff2000
000000c8 <-00000000
000000e0 <-0000001c
000000d8 <-00000000
000000f4 <-40300002
00001050 <-00000030
PCI: 00:00.00
00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 80 35
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00
50: 04 00 00 00 00 00 00 00 00 30 33 33 33 33 33 33
60: 01 02 03 04 05 06 07 08 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 1f 04 01 39 09 00 65 00
80: b1 0b 71 00 00 00 00 00 00 98 0a d2 8f 00 00 00
90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 44 c0 50 11 00 20 ff 03 00 00 00 00 00 00 00 00
d0: 02 28 00 0e 03 00 00 33 80 09 31 b5 00 00 00 00
e0: 1c 1d 00 00 00 00 00 00 54 48 00 00 00 00 00 00
f0: 00 00 00 00 76 00 30 40 40 0f 00 00 00 00 00 00
Ram2.00
Reading SPD data...
setting based on SPD data...
page size =00000011 00000011
width =00000008 00000008
page size =00000011 00000011
width =00000008 00000008
page size =00000000 00000000
width =00000000 00000000
page size =00000000 00000000
width =00000000 00000000
done
Ram3
Ram Enable 1
Ram Enable 2
Ram Enable 3
Ram Enable 4
Ram Enable 5
Ram Enable 6
Ram Enable 7
Ram Enable 8
Ram Enable 9
Ram Enable 10
Ram Enable 11
dimm size =00000020 00000020
dimm size =00000020 00000020
dimm size =00000000 00000000
dimm size =00000000 00000000
Initializing ECC state...
ECC state initialized.
PCI: 00:00.00
00: 86 80 4c 25 06 00 90 00 01 00 00 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 d9 15 80 35
30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00
40: 09 00 05 11 00 00 00 00 00 00 00 00 00 00 00 00
50: 04 00 0d 00 00 00 00 00 00 30 33 33 33 33 33 33
60: 10 20 30 40 40 40 40 40 00 00 00 00 00 00 00 00
70: 44 44 00 00 00 00 00 00 14 02 01 39 79 02 67 20
80: b1 0b 71 00 00 00 00 00 00 98 10 d2 8c 00 00 00
90: 00 00 00 00 00 00 00 00 55 05 55 05 01 02 38 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 44 c0 50 11 00 c0 40 00 50 00 00 00 00 00 00 00
d0: 02 28 00 0e 03 00 00 33 80 09 31 b5 00 00 00 00
e0: 1c 1d 00 00 00 00 00 00 54 48 00 00 00 00 00 00
f0: 00 00 00 00 76 00 30 40 40 0f 00 00 00 00 00 00
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.62.0_Fallback Fri Jun 25 12:32:23 PDT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating static devices...
Enumerating: intel E7501 Northbridge
Enumerating: Intel 82801er Southbridge
Enumerating: Winbond w83627hf
Enumerating buses...
PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [8086/254c] enabled
PCI: 00:00.1 [8086/2541] enabled
PCI: 00:02.0 [8086/2543] enabled
PCI: 00:06.0 [8086/2549] enabled
PCI: 00:1d.0 [8086/24d2] ops
PCI: 00:1d.0 [8086/24d2] enabled
PCI: 00:1d.1 [8086/24d4] ops
PCI: 00:1d.1 [8086/24d4] enabled
PCI: 00:1d.2 [8086/24d7] ops
PCI: 00:1d.2 [8086/24d7] enabled
PCI: 00:1d.3 [8086/24de] ops
PCI: 00:1d.3 [8086/24de] enabled
PCI: 00:1d.7 [8086/24dd] ops
PCI: 00:1d.7 [8086/24dd] enabled
PCI: 00:1e.0 [8086/244e] enabled
PCI: 00:1f.0 [8086/24d0] bus ops
PCI: 00:1f.0 [8086/24d0] enabled
PCI: 00:1f.1 [8086/24db] ops
PCI: 00:1f.1 [8086/24db] enabled
PCI: 00:1f.2 [8086/24df] enabled
PCI: 00:1f.3 [8086/24d3] enabled
PCI: 00:1f.5 [8086/24d5] ops
PCI: 00:1f.5 [8086/24d5] enabled
PCI: 00:1f.6 [8086/24d6] ops
PCI: 00:1f.6 [8086/24d6] enabled
PCI: pci_scan_bus for bus 1
PCI: 01:1c.0 [8086/1461] enabled
PCI: 01:1d.0 [8086/1460] enabled
PCI: 01:1e.0 [8086/1461] enabled
PCI: 01:1f.0 [8086/1460] enabled
PCI: pci_scan_bus for bus 2
PCI: 02:01.0 [8086/1010] enabled
PCI: 02:01.1 [8086/1010] enabled
PCI: pci_scan_bus returning with max=02
PCI: pci_scan_bus for bus 3
PCI: pci_scan_bus returning with max=03
PCI: pci_scan_bus returning with max=03
PCI: pci_scan_bus for bus 4
PCI: 04:02.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=04
scan_static_bus for PCI: 00:1f.0
scan_static_bus done
PCI: pci_scan_bus returning with max=04
done
Allocating resources...
Allocating VGA resource PCI: 04:02.0
ASSIGN RESOURCES, bus 0
PCI: 00:02.0 1c <- [0x00001000 - 0x00001fff] bus 1 io
PCI: 00:02.0 24 <- [0xfe300000 - 0xfe2fffff] bus 1 prefmem
PCI: 00:02.0 20 <- [0xfe100000 - 0xfe2fffff] bus 1 mem
ASSIGN RESOURCES, bus 1
PCI: 01:1c.0 10 <- [0xfe200000 - 0xfe200fff] mem
PCI: 01:1d.0 1c <- [0x00001000 - 0x00001fff] bus 2 io
PCI: 01:1d.0 24 <- [0xfe300000 - 0xfe2fffff] bus 2 prefmem
PCI: 01:1d.0 20 <- [0xfe100000 - 0xfe1fffff] bus 2 mem
ASSIGN RESOURCES, bus 2
PCI: 02:01.0 10 <- [0xfe100000 - 0xfe11ffff] mem
PCI: 02:01.0 20 <- [0x00001000 - 0x0000103f] io
PCI: 02:01.1 10 <- [0xfe120000 - 0xfe13ffff] mem
PCI: 02:01.1 20 <- [0x00001040 - 0x0000107f] io
ASSIGNED RESOURCES, bus 2
PCI: 01:1e.0 10 <- [0xfe201000 - 0xfe201fff] mem
PCI: 01:1f.0 1c <- [0x00002000 - 0x00001fff] bus 3 io
PCI: 01:1f.0 24 <- [0xfe300000 - 0xfe2fffff] bus 3 prefmem
PCI: 01:1f.0 20 <- [0xfe200000 - 0xfe1fffff] bus 3 mem
ASSIGNED RESOURCES, bus 1
PCI: 00:1d.0 20 <- [0x00003480 - 0x0000349f] io
PCI: 00:1d.1 20 <- [0x000034a0 - 0x000034bf] io
PCI: 00:1d.2 20 <- [0x000034c0 - 0x000034df] io
PCI: 00:1d.3 20 <- [0x000034e0 - 0x000034ff] io
PCI: 00:1d.7 10 <- [0xfe300000 - 0xfe3003ff] mem
PCI: 00:1e.0 1c <- [0x00002000 - 0x00002fff] bus 4 io
PCI: 00:1e.0 24 <- [0xfe300000 - 0xfe2fffff] bus 4 prefmem
PCI: 00:1e.0 20 <- [0xfd000000 - 0xfe0fffff] bus 4 mem
ASSIGN RESOURCES, bus 4
PCI: 04:02.0 10 <- [0xfd000000 - 0xfdffffff] mem
PCI: 04:02.0 14 <- [0x00002000 - 0x000020ff] io
PCI: 04:02.0 18 <- [0xfe000000 - 0xfe000fff] mem
ASSIGNED RESOURCES, bus 4
PCI: 00:1f.0 00 <- [0x00000000 - 0xffffffff] io
PCI: 00:1f.0 00 <- [0x00000000 - 0xffffffff] mem
PCI: 00:1f.1 10 <- [0x00003840 - 0x00003847] io
PCI: 00:1f.1 14 <- [0x00003880 - 0x00003883] io
PCI: 00:1f.1 18 <- [0x00003850 - 0x00003857] io
PCI: 00:1f.1 1c <- [0x00003890 - 0x00003893] io
PCI: 00:1f.1 20 <- [0x00003820 - 0x0000382f] io
PCI: 00:1f.1 24 <- [0xfe301000 - 0xfe3013ff] mem
PCI: 00:1f.2 10 <- [0x00003860 - 0x00003867] io
PCI: 00:1f.2 14 <- [0x000038a0 - 0x000038a3] io
PCI: 00:1f.2 18 <- [0x00003870 - 0x00003877] io
PCI: 00:1f.2 1c <- [0x000038b0 - 0x000038b3] io
PCI: 00:1f.2 20 <- [0x00003830 - 0x0000383f] io
PCI: 00:1f.3 20 <- [0x00003800 - 0x0000381f] io
PCI: 00:1f.5 18 <- [0xfe302000 - 0xfe3021ff] mem
PCI: 00:1f.5 1c <- [0xfe303000 - 0xfe3030ff] mem
PCI: 00:1f.6 10 <- [0x00003000 - 0x000030ff] io
PCI: 00:1f.6 14 <- [0x00003400 - 0x0000347f] io
ASSIGNED RESOURCES, bus 0
done.
Enabling resourcess...
PCI: 00:00.0 cmd <- 146
PCI: 00:00.1 cmd <- 140
PCI: 00:02.0 bridge ctrl <- 0003
PCI: 00:02.0 cmd <- 147
PCI: 01:1c.0 cmd <- 142
PCI: 01:1d.0 bridge ctrl <- 0003
PCI: 01:1d.0 cmd <- 147
PCI: 02:01.0 cmd <- 143
PCI: 02:01.1 cmd <- 143
PCI: 01:1e.0 cmd <- 142
PCI: 01:1f.0 bridge ctrl <- 0003
PCI: 01:1f.0 cmd <- 147
PCI: 00:06.0 cmd <- 140
PCI: 00:1d.0 cmd <- 141
PCI: 00:1d.1 cmd <- 141
PCI: 00:1d.2 cmd <- 141
PCI: 00:1d.3 cmd <- 141
PCI: 00:1d.7 cmd <- 142
PCI: 00:1e.0 bridge ctrl <- 000b
PCI: 00:1e.0 cmd <- 147
PCI: 04:02.0 cmd <- 1c3
PCI: 00:1f.0 cmd <- 14f
PCI: 00:1f.1 cmd <- 143
PCI: 00:1f.2 cmd <- 141
PCI: 00:1f.3 cmd <- 141
PCI: 00:1f.5 cmd <- 142
PCI: 00:1f.6 cmd <- 141
done.
Initializing devices...
PNP: 002e.0 init
PNP: 002e.2 init
PNP: 002e.5 init
PNP: 002e.b init
PCI: 00:1d.0 init
PCI: 00:1d.1 init
PCI: 00:1d.2 init
PCI: 00:1d.3 init
PCI: 00:1d.7 init
PCI: 00:1f.0 init
ioapic southbridge enabled 2186
Southbridge apic id = 2000000
set power on after power fail
RTC Init
Invalid CMOS LB checksum
PCI: 00:1f.1 init
Devices initialized
remap_high is 0
totalram: 4096M
Initializing CPU #0
Enabling cache...
Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) type: WB
Setting fixed MTRRs(24-88) type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 2048MB, type WB
Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB
Setting variable MTRR 2, base: 3072MB, range:  512MB, type WB
Setting variable MTRR 3, base: 3584MB, range:  256MB, type WB
Setting variable MTRR 4, base: 3840MB, range:  128MB, type WB
Setting variable MTRR 5, base: 4096MB, range:  128MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's
call intel_enable_fixed_mtrr()
call intel_enable_var_mtrr()
Leave setup_mtrrs
done.

Max cpuid index    : 2
Vendor ID          : GenuineIntel
Processor Type     : 0x00
Processor Family   : 0x0f
Processor Model    : 0x02
Processor Mask     : 0x00
Processor Stepping : 0x04
Feature flags      : 0x3febfbff

Cache/TLB descriptor values: 1 reads required
Desc 0x50 : UNKNOWN
Desc 0x5b : UNKNOWN
Desc 0x66 : UNKNOWN
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x00 : null
Desc 0x40 : No L2 cache
Desc 0x70 : UNKNOWN
Desc 0x7b : UNKNOWN
Desc 0x00 : null



MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Updating microcode
microcode_info: sig = 0x00000f24 pf=0x00000002 rev = 0x00000000
Setting up local apic... apic_id: 0 done.
CPU #0 Initialized
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From bari at onelabs.com  Fri Jun 25 16:20:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Jun 25 16:20:00 2004
Subject: LVDS Support
In-Reply-To: <40DC8C26.4050300@fuzzymuzzle.com>
References: <40DC6AE6.9070306@fuzzymuzzle.com> <40DC6C9D.3020902@fuzzymuzzle.com> <40DC7A86.8020408@bitworks.com> <40DC8636.7060602@fuzzymuzzle.com> <40DC8C26.4050300@fuzzymuzzle.com>
Message-ID: <40DC9D84.2010807@onelabs.com>

The data sheet:

http://www.chrontel.com/products/7019.htm

The 7019 is controlled via SPD so if you can access the SPD bus to the 
7019 you should be able to make use of the SiS driver source. That may 
get you part of the way there. To get everything you want done you may 
need to get the full data sheet.

-Bari

Michael Robinson wrote:

> Well, it seems that the SiS driver supports it, just search for 7019 
> (all references to it in Google are without the "A") on this page:  
> http://www.xfree86.org/4.4.0/sis.4.html  So it must be fairly easy to 
> port the code to the VIA, although the SiS driver most likely takes into 
> account that the BIOS contains display information.  All references to 
> the 7019 go to the SiS driver, it must be the only one that implements 
> the LVDS interface.





From mrobinson at fuzzymuzzle.com  Fri Jun 25 17:45:01 2004
From: mrobinson at fuzzymuzzle.com (Michael Robinson)
Date: Fri Jun 25 17:45:01 2004
Subject: LVDS Support
In-Reply-To: <40DC9D84.2010807@onelabs.com>
References: <40DC6AE6.9070306@fuzzymuzzle.com> <40DC6C9D.3020902@fuzzymuzzle.com> <40DC7A86.8020408@bitworks.com> <40DC8636.7060602@fuzzymuzzle.com> <40DC8C26.4050300@fuzzymuzzle.com> <40DC9D84.2010807@onelabs.com>
Message-ID: <40DCB113.1030006@fuzzymuzzle.com>

I'd have to get the board before I can figure out what kind of input 
signal its using and how the board is controlling it through its SPD 
interface.  The chip can accept two digital signals and one variable 
voltage signal as input (which must be RGB to output LVDS).  If the 7019 
is using the variable voltage input than it's probably just pulling the 
video right off of the CLE266's VGA port (RGB).  Since the VIA VT1622A 
(TV Encoder) only accepts YCrCb (whatever this is) and RGB, it seems 
like the only thing that would make sense for the CLE266 to output would 
be VGA (that way it can use one signal for the VGA port, TV encoder, and 
the LVDS transmitter).  In this scenario the standard VGA driver with a 
driver to control the 7019 should work (in theory).  The only other 
signal the 7019 could possibly accept is a digital signal (which I doubt 
the CLE266 can output, or would choose to output due to the above 
mentioned facts).

Michael Robinson
mrobinson at fuzzymuzzle.com
www.fuzzymuzzle.com

Bari Ari wrote:

> The data sheet:
>
> http://www.chrontel.com/products/7019.htm
>
> The 7019 is controlled via SPD so if you can access the SPD bus to the 
> 7019 you should be able to make use of the SiS driver source. That may 
> get you part of the way there. To get everything you want done you may 
> need to get the full data sheet.
>
> -Bari
>
> Michael Robinson wrote:
>
>> Well, it seems that the SiS driver supports it, just search for 7019 
>> (all references to it in Google are without the "A") on this page:  
>> http://www.xfree86.org/4.4.0/sis.4.html  So it must be fairly easy to 
>> port the code to the VIA, although the SiS driver most likely takes 
>> into account that the BIOS contains display information.  All 
>> references to the 7019 go to the SiS driver, it must be the only one 
>> that implements the LVDS interface.
>
>
>
>
>
>
>



From tony_cheng at pcmagic.net  Fri Jun 25 17:51:00 2004
From: tony_cheng at pcmagic.net (Tony Cheng)
Date: Fri Jun 25 17:51:00 2004
Subject: Serenade BIOS
References: <1088098025.8331.135.camel@exponential.lanl.gov>	 <m37jtwfv73.fsf@maxwell.lnxi.com> <1088176272.15464.21.camel@exponential.lanl.gov>
Message-ID: <40DCB29C.2080103@pcmagic.net>

Hi Ollie,

The Serenade BIOS I've got from CVS Server can not build. Do you see 
this also?  The payload size of my binary is about 55k.

The error messages are as follow:

objcopy -O binary linuxbios_c linuxbios_payload.bin
./nrv2b e linuxbios_payload.bin linuxbios_payload.nrv2b
input/output = 67188/26767 = 2.510
cp linuxbios_payload.nrv2b linuxbios_payload
gcc -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
/usr/bin/ld: section .id [ffffffd8 -> ffffffef] overlaps section 
.payload [ffff9750 -> ffffffe2]
collect2: ld returned 1 exit status
make[1]: *** [linuxbios] Error 1
make[1]: Leaving directory 
`/root/dl/freebios2/targets/amd/serenade/serenade/fallback'
make: *** [fallback-rom] Error 1


Thanks

Tony






From ebiederman at lnxi.com  Fri Jun 25 18:58:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Jun 25 18:58:00 2004
Subject: E7501 support in V2
In-Reply-To: <3174569B9743D511922F00A0C943142305535B51@TYANWEB>
References: <3174569B9743D511922F00A0C943142305535B51@TYANWEB>
Message-ID: <m3659f5flw.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I find the problem, need to call init_timer in p6 cpu fixup. It works well
> now.
> 
> Some code should be moved to p6 or even p5.
> 
> For example:
> apic_timper.c
> enable_mmx_sse.inc/disable_mmx_sse.inc

Except for the Opteron init_timer is really not appropriate as a
cpu thing.  In general it is a motherboard type decision.  It is
one of the rough areas in V2 right now.

For the rest you can see why I am in the process of reworking
the cpu initialization code.

Eric


From ebiederman at lnxi.com  Fri Jun 25 19:12:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Jun 25 19:12:00 2004
Subject: [COMMIT] romcc 0.63 and some fixes...
In-Reply-To: <3174569B9743D511922F00A0C94314230506478A@TYANWEB>
References: <3174569B9743D511922F00A0C94314230506478A@TYANWEB>
Message-ID: <m31xk35eyo.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> The 
> printo_debug("this mainboard is only designed for 2 cpus\r\n");
> 
> causes the segment dump.

A update on this...

I took some time and tracked the problem down.  So far
I have exposed 2 problems in romcc with your code.

The first that was causing the core dump I have fixed.

The second is a little more insidious.  Basically
when call/return instructions are introduced the control
flow graph is no longer a graph.  Because the structure
changes depending on which path you take through the code.

What happens currently is I treat it like a graph and get
a conservative estimate on the control flow structure.  So no
incorrect transformations happen to the code.  However there are a
number of cases and your code was one where code that is correct
does not appear to be.  Because it appears that there are additional
paths to a basic block, when there are not.  

The result is some legitimate cases will not compile.  And likely
that some optimization opportunities are lost.  I suspect the lost
optimization opportunities are responsible for the code size growth.

Without calls and returns the dominance relationship between
instructions is transitive. Instruction X dominates instruction Y if
you must execute X before Y.  With call/return pairs the dominance
relationship is no longer quite transitive which is going to take
some delicate manipulation to let romcc understand this without
breaking it.

I am going to spend a little more time looking at this and when I am
done I am going to commit however many fixes/enhancements that I have.


Eric


From YhLu at tyan.com  Fri Jun 25 19:28:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jun 25 19:28:00 2004
Subject: =?gb2312?B?tPC4tDogW0NPTU1JVF0gcm9tY2MgMC42MyBhbmQgc29tZSBmaXhl?=
	=?gb2312?B?cy4uLg==?=
Message-ID: <3174569B9743D511922F00A0C943142305535B8A@TYANWEB>

So next week, we can get the updated romcc?

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?25? 17:41
???: YhLu
??: LinuxBIOS
??: Re: [COMMIT] romcc 0.63 and some fixes...

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> The 
> printo_debug("this mainboard is only designed for 2 cpus\r\n");
> 
> causes the segment dump.

A update on this...

I took some time and tracked the problem down.  So far
I have exposed 2 problems in romcc with your code.

The first that was causing the core dump I have fixed.

The second is a little more insidious.  Basically
when call/return instructions are introduced the control
flow graph is no longer a graph.  Because the structure
changes depending on which path you take through the code.

What happens currently is I treat it like a graph and get
a conservative estimate on the control flow structure.  So no
incorrect transformations happen to the code.  However there are a
number of cases and your code was one where code that is correct
does not appear to be.  Because it appears that there are additional
paths to a basic block, when there are not.  

The result is some legitimate cases will not compile.  And likely
that some optimization opportunities are lost.  I suspect the lost
optimization opportunities are responsible for the code size growth.

Without calls and returns the dominance relationship between
instructions is transitive. Instruction X dominates instruction Y if
you must execute X before Y.  With call/return pairs the dominance
relationship is no longer quite transitive which is going to take
some delicate manipulation to let romcc understand this without
breaking it.

I am going to spend a little more time looking at this and when I am
done I am going to commit however many fixes/enhancements that I have.


Eric


From ebiederman at lnxi.com  Fri Jun 25 19:55:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Jun 25 19:55:01 2004
Subject: =?gb2312?b?tPC4tA==?=: [COMMIT] romcc 0.63 and some fixes...
In-Reply-To: <3174569B9743D511922F00A0C943142305535B8A@TYANWEB>
References: <3174569B9743D511922F00A0C943142305535B8A@TYANWEB>
Message-ID: <m33c4jp0wx.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> So next week, we can get the updated romcc?

That is the plan.

I don't know how much it will fix beyond the segfault issue...

Eric


From YhLu at tyan.com  Fri Jun 25 19:58:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jun 25 19:58:01 2004
Subject: [COMMIT] romcc 0.63 and some fixes...
Message-ID: <3174569B9743D511922F00A0C943142305535B93@TYANWEB>

Next week, I will work on i82875 support.

Regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?25? 18:24
???: YhLu
??: LinuxBIOS
??: Re: ??: [COMMIT] romcc 0.63 and some fixes...

YhLu <YhLu at tyan.com> writes:

> So next week, we can get the updated romcc?

That is the plan.

I don't know how much it will fix beyond the segfault issue...

Eric


From mshields at yarcom.com  Sat Jun 26 13:32:00 2004
From: mshields at yarcom.com (Mike Shields)
Date: Sat Jun 26 13:32:00 2004
Subject: LinuxBIOS and Win2K
Message-ID: <MAEFIGNMAKJIAOBANGNDEEMGEDAA.mshields@yarcom.com>

Greetings,

Mike Shields here. I am new to the list and to LinuxBIOS in general. I have
searched the list archives and have read Adam Agnew's (et al) paper on
booting Win2K on top of the stackable Open Source BIOS, as well as several
other papers by William Arbaugh and coauthors on secure booting and secure
BIOS.

I am a consultant for SPAWAR (part of the US Navy) working on a project to
make USN computers running windows more secure. I have been asked to give a
short presentation to some SPAWAR and FNMOC people on June 29th as part of a
project conference. The points I need to cover are the differences between
current BIOS and LinuxBIOS and the advantages of the latter. We are trying
to convince Dell (SPAWAR has a huge contract with Dell to supply computers
to the navy) to give us the information to port LinuxBIOS to their systems.
One misconception I must deal with is that many people think Windows won't
load over LinuxBIOS (I have Adam's paper showing otherwise).

I know very little about LinuxBIOS other than what I have read on
www.linuxbios.org, my scans of the archive, and a short paper form Nicholus
Andrews at Linux Labs. I was hoping to get some success stories on booting
windows on top of LinuxBIOS, or other information I could use in my short
presentation.

Thanks,
Mike
Michael K. Shields, Ph.D.
YarCom Inc.
350 S. Center St., Suite 500, Reno, NV 89501-2114 US
v:336-783-0054 f:336-217-8227 c:336-407-2190
e:mshields at yarcom.com http://www.yarcom.com





From ebiederman at lnxi.com  Sun Jun 27 20:32:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Jun 27 20:32:01 2004
Subject: LinuxBIOS and Win2K
In-Reply-To: <MAEFIGNMAKJIAOBANGNDEEMGEDAA.mshields@yarcom.com>
References: <MAEFIGNMAKJIAOBANGNDEEMGEDAA.mshields@yarcom.com>
Message-ID: <m3r7s0igp0.fsf@maxwell.lnxi.com>

"Mike Shields" <mshields at yarcom.com> writes:

> Greetings,
> 
> Mike Shields here. I am new to the list and to LinuxBIOS in general. I have
> searched the list archives and have read Adam Agnew's (et al) paper on
> booting Win2K on top of the stackable Open Source BIOS, as well as several
> other papers by William Arbaugh and coauthors on secure booting and secure
> BIOS.
> 
> I am a consultant for SPAWAR (part of the US Navy) working on a project to
> make USN computers running windows more secure. I have been asked to give a
> short presentation to some SPAWAR and FNMOC people on June 29th as part of a
> project conference. The points I need to cover are the differences between
> current BIOS and LinuxBIOS and the advantages of the latter. We are trying
> to convince Dell (SPAWAR has a huge contract with Dell to supply computers
> to the navy) to give us the information to port LinuxBIOS to their systems.
> One misconception I must deal with is that many people think Windows won't
> load over LinuxBIOS (I have Adam's paper showing otherwise).

The simple proof is that ADLO uses the BIOS from bochs simply ported
to real hardware, and bochs loads windows regularly.

You will also likely need to work with the cpu and chipset vendors
to get the information needed to port LinuxBIOS.  Usually motherboard
vendors do not get beyond motherboard schematics information
wise. Simply because they don't make the chips on the motherboards.
At this time I don't have a clue how much overlap you will have with
the current work.

If it makes any difference you can use the name freebios as that
is an alias of LinuxBIOS, that is not quite so Linux centric :)

> I know very little about LinuxBIOS other than what I have read on
> www.linuxbios.org, my scans of the archive, and a short paper form Nicholus
> Andrews at Linux Labs. I was hoping to get some success stories on booting
> windows on top of LinuxBIOS, or other information I could use in my short
> presentation.

There are a few rough edges with ADLO currently.  (For some reason it
has some motherboard specific code.)  So in doing a production
deployment you will be breaking ground.

So some advantages of an open source BIOS.
1) It is open source so you can implement any boot policy you choose,
   and can implement.
2) LinuxBIOS is open source so you don't have to worry about security
   through obscurity, the code can be and is peer reviewed.
3) The core of LinuxBIOS is simpler and at a higher level then
   a traditional BIOS so it is easier to port.  Being in C
   it certainly widens the pool of people who can work on the project.
4) A security implementation in LinuxBIOS would be about security for
   the user, instead of about ensuring hardware is trusted.
5) As a research/prototype platform you have much more control of
   what ultimately is going on.
6) LinuxBIOS is the firmware of choice for supercomputers at top
   secret government labs, so we must be doing something right :)
7) If you were really creative with BIOS level controll you could run
   a monitor in System Management Mode that could keep an eye on
   Windows.

I have a very hard time seeing Windows and security as anything but an
oxymoron.  Not that Linux is much better.  The old security study on
MULTICs security is fascinating on that subject.  I also don't see a
major role of the firmware tightening up security.  That being said I
have no problems with booting Windows from LinuxBIOS.

Eric



From ollie at lanl.gov  Mon Jun 28 09:39:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Jun 28 09:39:00 2004
Subject: Serenade BIOS
In-Reply-To: <40DCB29C.2080103@pcmagic.net>
References: <1088098025.8331.135.camel@exponential.lanl.gov>
	 <m37jtwfv73.fsf@maxwell.lnxi.com>
	 <1088176272.15464.21.camel@exponential.lanl.gov>
	 <40DCB29C.2080103@pcmagic.net>
Message-ID: <1088435209.5698.5.camel@exponential.lanl.gov>

On Fri, 2004-06-25 at 17:17, Tony Cheng wrote:
> Hi Ollie,
> 
> The Serenade BIOS I've got from CVS Server can not build. Do you see 
> this also?  The payload size of my binary is about 55k.
> 
> The error messages are as follow:
> 
> objcopy -O binary linuxbios_c linuxbios_payload.bin
> ./nrv2b e linuxbios_payload.bin linuxbios_payload.nrv2b
> input/output = 67188/26767 = 2.510
> cp linuxbios_payload.nrv2b linuxbios_payload
> gcc -nostdlib -nostartfiles -static -o linuxbios -T ldscript.ld crt0.o
> /usr/bin/ld: section .id [ffffffd8 -> ffffffef] overlaps section 
> .payload [ffff9750 -> ffffffe2]
> collect2: ld returned 1 exit status
> make[1]: *** [linuxbios] Error 1
> make[1]: Leaving directory 
> `/root/dl/freebios2/targets/amd/serenade/serenade/fallback'
> make: *** [fallback-rom] Error 1
> 

It is the 64kB size limit problem. Please set the

option  MAXIMUM_CONSOLE_LOGLEVEL=8
option  DEFAULT_CONSOLE_LOGLEVEL=8

in Config.lb to some lower value.

Ollie

> 
> Thanks
> 
> Tony
> 
> 
> 
> 



From rsmith at bitworks.com  Mon Jun 28 13:10:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Mon Jun 28 13:10:01 2004
Subject: LinuxBIOS and Win2K
In-Reply-To: <m3r7s0igp0.fsf@maxwell.lnxi.com>
References: <MAEFIGNMAKJIAOBANGNDEEMGEDAA.mshields@yarcom.com> <m3r7s0igp0.fsf@maxwell.lnxi.com>
Message-ID: <40E06589.5020006@bitworks.com>

Eric W. Biederman wrote:

> There are a few rough edges with ADLO currently.  (For some reason it
> has some motherboard specific code.)  So in doing a production
> deployment you will be breaking ground.

The motherboard specific code is to enable and disable the shadowing 
control when ADLO copies itself and the vbios to RAM.  So to do this in 
a generic manner LB would have to have to provide a payload with a 
method of doing this.

If you got any ideas I might be able to scratch up some time to 
implement them.  It would be for V1 though I don't do V2 yet.







From adam at cfar.umd.edu  Mon Jun 28 15:56:01 2004
From: adam at cfar.umd.edu (Adam Sulmicki)
Date: Mon Jun 28 15:56:01 2004
Subject: LinuxBIOS and Win2K
In-Reply-To: <40E06589.5020006@bitworks.com>
Message-ID: <20040628172638.E99811-100000@www.missl.cs.umd.edu>

the idea we toyed with was a generic callback which would enable this
specific feature... still it was somewhat tricky given that ADLO
sometimes loads itself over the LinuxBIOS

On Mon, 28 Jun 2004, Richard Smith wrote:

> Eric W. Biederman wrote:
>
> > There are a few rough edges with ADLO currently.  (For some reason it
> > has some motherboard specific code.)  So in doing a production
> > deployment you will be breaking ground.
>
> The motherboard specific code is to enable and disable the shadowing
> control when ADLO copies itself and the vbios to RAM.  So to do this in
> a generic manner LB would have to have to provide a payload with a
> method of doing this.
>
> If you got any ideas I might be able to scratch up some time to
> implement them.  It would be for V1 though I don't do V2 yet.
>
>
>
>
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From jmiller at actuality-systems.com  Mon Jun 28 16:51:00 2004
From: jmiller at actuality-systems.com (Jay Miller)
Date: Mon Jun 28 16:51:00 2004
Subject: Etherboot USB Updates?
Message-ID: <E8F8DBCB0468204E856114A2CD20741F14B46E@mail.local.ActualitySystems.com>

Hi Yinghai,

Have you made any updates to the USB support published as a patch to
etherboot 5.2.4?

If not, would it be possible to get the configuration files you use to
generate a working tg3--filo.zelf?

I still am having problems getting elfboot to load the payload without
dying.

Thanks,

Jay Miller
781-229-7812x117
Actuality Systems, Inc.
jmiller at acutality-systems.com





From YhLu at tyan.com  Mon Jun 28 16:55:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Jun 28 16:55:00 2004
Subject: =?GB2312?B?tPC4tDogRXRoZXJib290IFVTQiBVcGRhdGVzPw==?=
Message-ID: <3174569B9743D511922F00A0C943142305535C4A@TYANWEB>

http://sourceforge.net/tracker/index.php?func=detail&aid=943300&group_id=423
3&atid=304233

Regards

YH
-----????-----
???: Jay Miller [mailto:jmiller at actuality-systems.com] 
????: 2004?6?28? 15:15
???: YhLu
??: linuxbios at clustermatic.org
??: Etherboot USB Updates?

Hi Yinghai,

Have you made any updates to the USB support published as a patch to
etherboot 5.2.4?

If not, would it be possible to get the configuration files you use to
generate a working tg3--filo.zelf?

I still am having problems getting elfboot to load the payload without
dying.

Thanks,

Jay Miller
781-229-7812x117
Actuality Systems, Inc.
jmiller at acutality-systems.com




From ebiederman at lnxi.com  Mon Jun 28 17:36:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jun 28 17:36:00 2004
Subject: LinuxBIOS and Win2K
In-Reply-To: <20040628172638.E99811-100000@www.missl.cs.umd.edu>
References: <20040628172638.E99811-100000@www.missl.cs.umd.edu>
Message-ID: <m38ye7z3ks.fsf@maxwell.lnxi.com>

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

> the idea we toyed with was a generic callback which would enable this
> specific feature... still it was somewhat tricky given that ADLO
> sometimes loads itself over the LinuxBIOS

For V2 every port I have done has simply left those areas enabled
as RAM, which obviates the need for any call backs.

That code is not motherboard specific it is cpu/chipset specific,
which is something else entirely.


> On Mon, 28 Jun 2004, Richard Smith wrote:
> 
> > Eric W. Biederman wrote:
> >
> > > There are a few rough edges with ADLO currently.  (For some reason it
> > > has some motherboard specific code.)  So in doing a production
> > > deployment you will be breaking ground.
> >
> > The motherboard specific code is to enable and disable the shadowing
> > control when ADLO copies itself and the vbios to RAM.  So to do this in
> > a generic manner LB would have to have to provide a payload with a
> > method of doing this.

What I was thinking of was things like pirq tables.  I seem to recall
those still being hard coded.

> > If you got any ideas I might be able to scratch up some time to
> > implement them.  It would be for V1 though I don't do V2 yet.

Any significant changes like always leaving the shadow areas enabled,
we can easily implement in both v1 and v2.  And things like
pirq tables can be copied from wherever LinuxBIOS puts them.  If it
would help we can place pointers to the information in the LinuxBIOS table
to make things easier to deal with.

My basic point in all of this is that there were some rough area's
but nothing that be overcome with time.

Eric


From ebiederman at lnxi.com  Mon Jun 28 17:39:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jun 28 17:39:01 2004
Subject: LinuxBIOS and Win2K
In-Reply-To: <MAEFIGNMAKJIAOBANGNDEEMGEDAA.mshields@yarcom.com>
References: <MAEFIGNMAKJIAOBANGNDEEMGEDAA.mshields@yarcom.com>
Message-ID: <m34qovz3f6.fsf@maxwell.lnxi.com>

"Mike Shields" <mshields at yarcom.com> writes:

> I know very little about LinuxBIOS other than what I have read on
> www.linuxbios.org, my scans of the archive, and a short paper form Nicholus
> Andrews at Linux Labs. I was hoping to get some success stories on booting
> windows on top of LinuxBIOS, or other information I could use in my short
> presentation.

Ok there is one big advantage I forgot to mention.

- Simplicity.

When auditing and verifing code simplicity is a huge plus.  And the only
really complicated part of LinuxBIOS loading windows would be the code
that actually loads windows.  All of those ugly BIOS callbacks.

Eric


From leidenfrost at corscience.de  Tue Jun 29 09:08:03 2004
From: leidenfrost at corscience.de (Thomas Leidenfrost)
Date: Tue Jun 29 09:08:03 2004
Subject: s: binary-file for Geode GX1 + Cx5530 & TFT
Message-ID: <40E1800E.4000104@corscience.de>

Hi there,

I'm using the AW-B651-Board with the NS Geode CPU and the Cx5530. 
Reading the archive I found out, that some people were using a similar 
combination, so I wanted to ask, if somebody can send me a binary file I 
can simply flash? (the original Bios is backupped in a seperate ROM).

Next thing is, that my board has two monitor-outputs, the ordinary 
15-pole-DIN and a flatpanel-connector on the board? Is there support for 
  the flatpanel-connector?

Thanks in advance,

Tom.



From rsmith at bitworks.com  Tue Jun 29 10:10:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jun 29 10:10:01 2004
Subject: LinuxBIOS and Win2K
In-Reply-To: <m38ye7z3ks.fsf@maxwell.lnxi.com>
References: <20040628172638.E99811-100000@www.missl.cs.umd.edu> <m38ye7z3ks.fsf@maxwell.lnxi.com>
Message-ID: <40E18CE2.8070900@bitworks.com>

Eric W. Biederman wrote:

>>the idea we toyed with was a generic callback which would enable this
>>specific feature... still it was somewhat tricky given that ADLO
>>sometimes loads itself over the LinuxBIOS
> 
> 
> For V2 every port I have done has simply left those areas enabled
> as RAM, which obviates the need for any call backs.

I don't think thats enough.  You have to route reads to the bios area 
and writes to RAM and then when its done route reads back to RAM so ADLO 
has to mess with some registers.

> That code is not motherboard specific it is cpu/chipset specific,
> which is something else entirely.

Yeah. motherboard was the wrong term.  You used it first though. *grin*

> Any significant changes like always leaving the shadow areas enabled,
> we can easily implement in both v1 and v2.  And things like
> pirq tables can be copied from wherever LinuxBIOS puts them.  If it
> would help we can place pointers to the information in the LinuxBIOS table
> to make things easier to deal with.

pointers to code that would enable/disable the various functions? or 
pointers to some data struct that would instruct the code how to do then 
enable/disable?

They can be pretty different.  On the matsonic 7308e motherboard this 
was a simple out() to a location.  With the 440bx chipset this is a 
config space write.



From YhLu at tyan.com  Tue Jun 29 11:16:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jun 29 11:16:01 2004
Subject: E7501 support in V2
Message-ID: <3174569B9743D511922F00A0C943142305535CCC@TYANWEB>

Eric,

When can you commit cpu releated changes in the public tree?

Please advise if I could commit E7501/P62h2/82801EB-R into the v2 now or
after you commit CPU stuffs.

Regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?6?25? 17:27
???: YhLu
??: ron minnich; Stefan Reinauer; LinuxBIOS
??: Re: E7501 support in V2

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I find the problem, need to call init_timer in p6 cpu fixup. It works well
> now.
> 
> Some code should be moved to p6 or even p5.
> 
> For example:
> apic_timper.c
> enable_mmx_sse.inc/disable_mmx_sse.inc

Except for the Opteron init_timer is really not appropriate as a
cpu thing.  In general it is a motherboard type decision.  It is
one of the rough areas in V2 right now.

For the rest you can see why I am in the process of reworking
the cpu initialization code.

Eric


From stepan at openbios.org  Tue Jun 29 12:29:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Tue Jun 29 12:29:01 2004
Subject: qemu target
Message-ID: <20040629175702.GA4708@openbios.org>

Hi LinuxBIOS hackers,

I checked in a new target: emulation/qemu-i386

It allows to exchange the BIOS image of the multi target CPU emulator
QEMU (http://fabrice.bellard.free.fr/qemu/) with a LinuxBIOS image.

Since failsafe handling does not make much sense in an emulator, 
I only have one image built, with more space being available for the
payload. The payload is about 155k, the image is 256k and LinuxBIOS 
occupies 64k, so there's quite some room left.

Now, LinuxBIOS starts and executes all the romcc generated code in
auto.c. But after that output suddenly stops. All of the resource
allocation seems completely skipped. The first thing I get after this 
is when the payload has taken over. What can I do to get the output of
the gcc compiled code again?

In the beginning it did show these messages, but I was unable to
reproduce this behaviour, unfortunately.

I would guess it is not really skipped, since otherwise the payload is
not executed. Attached see a log of the serial console and a log of port
80 activity.

Can anyone point me into how to debug this? I am a bit confused. Am I
using crappy compilers again?

LinuxBIOS-1.1.6-OpenBIOS Mon Jun 28 16:54:53 CEST 2004 starting...
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
boot eax = 0xe1fb007
boot ebx = 0x3ff5878
boot arg = 0x3ff5878
Bootloader: elfboot
Version: 1.3
Searching for LinuxBIOS tables...
Found canidate at: 00000500
header checksum o.k.
table checksum o.k.
record count o.k.
Found LinuxBIOS table at: 00000500
0x00000000000000 0x00000000000000 1748
0x000000000006d4 0x00000000000000 67107116

00000000000006d4-0000000004000000
RAM 64 MB
Current location: 0x100000-0x1982e7
Relocating to 0x3f67d10-0x3fffff7... ok
forth started.
initializing memory...done
Initializing PCI devices...
0:0.0 - 8086:1237 - /pci/pci8086,1237 - host
0:1.0 - 8086:7000 - /pci/pci8086,7000 - isa
0:1.1 - 8086:7010 - /pci/pci8086,7010 - ide
0:2.0 - 1234:1111 - /pci/pci1234,1111 - display
0:3.0 - 10ec:8029 - /pci/pci10ec,8029 - ethernet
ide0: [io ports 0x1f0-0x1f7,0x3f6]
    drive0 [ATA disk]: QEMU HARDDISK
ide1: [io ports 0x170-0x177,0x376]
    drive0 [ATAPI cdrom]: QEMU CD-ROM
Welcome to OpenBIOS v1.0.RC1
Built on Jun 28 2004 17:29
  Type 'help' for detailed information

[x86] Booting default not supported.

0 > ok
0 >

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

Port80 log:
outb: 0080 10
outb: 0080 05
outb: 0080 11
outb: 0080 12
outb: 0080 13
outb: 0080 fe
outb: 0080 80
outb: 0080 39
outb: 0080 40
outb: 0080 5f
outb: 0080 24
outb: 0080 25
outb: 0080 55
outb: 0080 66
outb: 0080 88
outb: 0080 89
outb: 0080 70
outb: 0080 60
outb: 0080 6a
outb: 0080 92
outb: 0080 9b
outb: 0080 75
outb: 0080 9a
outb: 0080 96
outb: 0080 f8
outb: 0080 fe





From miernik at ctnet.pl  Tue Jun 29 18:14:00 2004
From: miernik at ctnet.pl (Miernik)
Date: Tue Jun 29 18:14:00 2004
Subject: long
Message-ID: <20040629231607.67F4.59.NOFFLE%miernik@ctnet.pl.local>

I have posted this to linux-fbdev-users 
http://sourceforge.net/mailarchive/forum.php?thread_id=4854738&forum_id=2358
but nobody anwsered, so maybe here someone will know.

I use the framebuffer with this line in my /boot/grub/menu.lst :
kernel /boot/vmlinuz-2.4.24-1-386 root=/dev/hda1 ro video=sisfb:mode:1152x864x16,rate:70

My video card is (output of lspci -vv):

0000:01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 630/730 PCI/AGP VGA Display Adapter (rev 31) (prog-if 00 [VGA])
        Subsystem: Silicon Integrated Systems [SiS] 630/730 PCI/AGP VGA Display Adapter
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        BIST result: 00
        Region 0: Memory at c0000000 (32-bit, prefetchable) [size=128M]
        Region 1: Memory at cfee0000 (32-bit, non-prefetchable) [size=128K]
        Region 2: I/O ports at bc00 [size=128]
        Capabilities: [40] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] AGP version 2.0
                Status: RQ=16 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- GP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- Rate=<none>

It's a video card build in a PCChips M810L REV7.0 motherboard.
The CPU is AMD Duron 600 MHz.
Of course I use the fbdev X driver.

The problem I have it takes 6.7 seconds to switch from console to X
with <Alt><F7>. The 6.7 s time is very consistent, every time I
measure it. It"s very long and annoying.

The other direction (X->console with <Alt><F1>) its about immediate.

During that 6.7 seconds the a rough outline of what is supposed to be
on the screen is displayed. For example if the Galeon web browser is
on the screen, then it displays the area where Galeon menus and other
controls are in a block of grey, the area of the webpage in a block of
black, and the URL box as a block of white.

What might be the reason, and is there anything to be done about this?

In kern.log doring boot I get:

May 28 18:25:49 jaworz kernel: sisfb: Video ROM found and mapped to c00c0000
May 28 18:25:49 jaworz kernel: sisfb: Framebuffer at 0xc0000000, mapped to 0xe00ab000, size 8192k
May 28 18:25:49 jaworz kernel: sisfb: MMIO at 0xcfee0000, mapped to 0xe08ac000, size 128k
May 28 18:25:49 jaworz kernel: sisfb: Memory heap starting at 4096K
May 28 18:25:49 jaworz kernel: sisfb: CRT1 DDC supported
May 28 18:25:49 jaworz kernel: sisfb: CRT1 DDC level: 2
May 28 18:25:49 jaworz kernel: sisfb: Monitor range H 31-61KHz, V 60-75Hz, Max. dotclock 78MHz
May 28 18:25:49 jaworz kernel: sisfb: WARNING: Refresh rate exceeds monitor specs!
May 28 18:25:49 jaworz kernel: sisfb: Mode is 1152x864x16 (60Hz)
May 28 18:25:49 jaworz kernel: sisfb: Initial vbflags 0x0
May 28 18:25:49 jaworz kernel: Console: switching to colour frame buffer device 144x54
May 28 18:25:49 jaworz kernel: sisfb: Installed SISFB_GET_INFO ioctl (80046ef8)
May 28 18:25:49 jaworz kernel: sisfb: Installed SISFB_GET_VBRSTATUS ioctl (80046ef9)
May 28 18:25:49 jaworz kernel: sisfb: 2D acceleration is enabled, scrolling mode ypan
May 28 18:25:49 jaworz kernel: fb0: SIS 730 frame buffer device, Version 1.6.16
May 28 18:25:49 jaworz kernel: sisfb: (C) 2001-2003 Thomas Winischhofer. All rights reserved.

And then a line like that appears every several minutes all the time
the computer is on:

May 28 18:26:04 jaworz kernel: sisfb: Unsupported rate 60 for 1152x864
May 28 18:26:04 jaworz kernel: sisfb: WARNING: Refresh rate exceeds monitor specs!
May 28 18:26:07 jaworz kernel: sisfb: Unsupported rate 60 for 1152x864
May 28 18:26:07 jaworz kernel: sisfb: WARNING: Refresh rate exceeds monitor specs!
May 28 18:26:27 jaworz kernel: sisfb: Unsupported rate 60 for 1152x864
May 28 18:26:27 jaworz kernel: sisfb: WARNING: Refresh rate exceeds monitor specs!


I do not yet run LinuxBIOS on this mainboard. I plan to (that's what I 
bought this motherboard for) but I first want to fix this issue.

Or maybe flashing it with LinuxBIOS will magically fix the problem?

-- 
    Miernik         _________________________  xmpp:miernik at amessage.info
___________________/__ tel: +48888299997 __/      mailto:miernik at ctnet.pl
http://www.miernik.ctnet.pl/



From ebiederman at lnxi.com  Tue Jun 29 21:24:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jun 29 21:24:01 2004
Subject: qemu target
In-Reply-To: <20040629175702.GA4708@openbios.org>
References: <20040629175702.GA4708@openbios.org>
Message-ID: <m34qotwybe.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> Hi LinuxBIOS hackers,
> 
> I checked in a new target: emulation/qemu-i386

> Now, LinuxBIOS starts and executes all the romcc generated code in
> auto.c. But after that output suddenly stops. All of the resource
> allocation seems completely skipped. The first thing I get after this 
> is when the payload has taken over. What can I do to get the output of
> the gcc compiled code again?

Try commenting out console_init();  It looks like something
bad is going on there.    The post codes seem to be working so
you can likely use those to narrow down what is going wrong.
 
> In the beginning it did show these messages, but I was unable to
> reproduce this behaviour, unfortunately.
> 
> I would guess it is not really skipped, since otherwise the payload is
> not executed. Attached see a log of the serial console and a log of port
> 80 activity.
> 
> Can anyone point me into how to debug this? I am a bit confused. Am I
> using crappy compilers again?

Possibly it is an emulator bug.  But seriously dig into console_init()
using port 0x80 or just by commenting/uncommenting pieces until you
know what breaks.

Eric


From miernik at ctnet.pl  Tue Jun 29 23:13:00 2004
From: miernik at ctnet.pl (Miernik)
Date: Tue Jun 29 23:13:00 2004
Subject: long time of switch console->X (fast opposite way)
References: <20040629231607.67F4.59.NOFFLE%miernik@ctnet.pl.local>
Message-ID: <20040630042211.67F4.60.NOFFLE%miernik@ctnet.pl.local>

Miernik <miernik at ctnet.pl> wrote:
> I have posted this to linux-fbdev-users 
> http://sourceforge.net/mailarchive/forum.php?thread_id=4854738&forum_id=2358
> but nobody anwsered, so maybe here someone will know.

Sorry, subject should have been this way, I was to paste it after the 
post, but forgot.

-- 
    Miernik         _________________________  xmpp:miernik at amessage.info
___________________/__ tel: +48888299997 __/      mailto:miernik at ctnet.pl
http://www.miernik.ctnet.pl/



From ebiederman at lnxi.com  Wed Jun 30 02:57:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jun 30 02:57:00 2004
Subject: E7501 support in V2
In-Reply-To: <3174569B9743D511922F00A0C943142305535CCC@TYANWEB>
References: <3174569B9743D511922F00A0C943142305535CCC@TYANWEB>
Message-ID: <m3isd9sb83.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> When can you commit cpu releated changes in the public tree?

It is going to be a little while yet. Cleanups take a little while
to work through.  And I don't want to rush it very much because once
you start using something stupid decisions are more difficult to correct.
 
> Please advise if I could commit E7501/P62h2/82801EB-R into the v2 now or
> after you commit CPU stuffs.

That stuff looks largely independent.  Hmm.  But to make it
work you have to do some cpu stuff....

Everything I am doing I am putting under cpu/x86/blah so putting in
your code should not affect me.  It will mean I will have to go back
and correct a few more things, but I don't want to be a hold up.

Eric


From stepan at openbios.org  Wed Jun 30 05:35:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Jun 30 05:35:01 2004
Subject: qemu target
In-Reply-To: <m34qotwybe.fsf@maxwell.lnxi.com>
References: <20040629175702.GA4708@openbios.org> <m34qotwybe.fsf@maxwell.lnxi.com>
Message-ID: <20040630110303.GB15261@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [040630 04:53]:
> Try commenting out console_init();  It looks like something
> bad is going on there.    The post codes seem to be working so
> you can likely use those to narrow down what is going wrong.
 
hm. commenting console_init() out does not change anything. But thanks
for the direction. I'll look into this
 
> Possibly it is an emulator bug.  But seriously dig into console_init()
> using port 0x80 or just by commenting/uncommenting pieces until you
> know what breaks.


Stefan



From ebiederman at lnxi.com  Wed Jun 30 11:40:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jun 30 11:40:01 2004
Subject: qemu target
In-Reply-To: <20040630110303.GB15261@openbios.org>
References: <20040629175702.GA4708@openbios.org>
	<m34qotwybe.fsf@maxwell.lnxi.com>
	<20040630110303.GB15261@openbios.org>
Message-ID: <m3oen1rmzb.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [040630 04:53]:
> > Try commenting out console_init();  It looks like something
> > bad is going on there.    The post codes seem to be working so
> > you can likely use those to narrow down what is going wrong.
>  
> hm. commenting console_init() out does not change anything. But thanks
> for the direction. I'll look into this

Ok then most likely you have managed to get the debugging printk's
compiled out or something like that.  It should be possible to insert
a -g statement into the build and then to step through the code execution
with gdb.  qemu appears to have support for gdb stubs.

The real interesting part is what is the debug level set to.  And you can
get that with port 0x80.

Maybe we are attempting to use cmos options and that is not properly implemented?

Eric


From stepan at openbios.org  Wed Jun 30 12:10:01 2004
From: stepan at openbios.org (Stefan Reinauer)
Date: Wed Jun 30 12:10:01 2004
Subject: qemu target
In-Reply-To: <m3oen1rmzb.fsf@maxwell.lnxi.com>
References: <20040629175702.GA4708@openbios.org> <m34qotwybe.fsf@maxwell.lnxi.com> <20040630110303.GB15261@openbios.org> <m3oen1rmzb.fsf@maxwell.lnxi.com>
Message-ID: <20040630173848.GA21144@openbios.org>

* Eric W. Biederman <ebiederman at lnxi.com> [040630 19:10]:
> Ok then most likely you have managed to get the debugging printk's
> compiled out or something like that.  It should be possible to insert
> a -g statement into the build and then to step through the code execution
> with gdb.  qemu appears to have support for gdb stubs.
> 
> The real interesting part is what is the debug level set to.  And you can
> get that with port 0x80.
> 
> Maybe we are attempting to use cmos options and that is not properly implemented?

Actually that sounds very reasonable. all my builds where this happens
are built without cmos support, and in this case the get_option()
function always returns -2 iirc. 

I will give it a try enabling option tables 

Stefan



From YhLu at tyan.com  Wed Jun 30 22:33:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jun 30 22:33:00 2004
Subject: =?GB2312?B?tPC4tDogRTc1MDEgc3VwcG9ydCBpbiBWMg==?=
Message-ID: <3174569B9743D511922F00A0C943142305535E67@TYANWEB>

Just check in E7501/ICH5R support into V2. the MB is tyan/s2735

Regards

YH


Intel E7501 P64H2 ICH5R support
CVS: ----------------------------------------------------------------------
CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS:    src/cpu/p6/Config.lb src/cpu/p6/cpufixup.c
CVS:    src/include/device/pci_ids.h
CVS:    src/superio/winbond/w83627hf/superio.c
CVS: Added Files:
CVS:    src/cpu/p6/apic_timer.c src/cpu/p6/chip.h
CVS:    src/cpu/p6/disable_mmx_sse.inc src/cpu/p6/enable_mmx_sse.inc
CVS:    src/mainboard/tyan/s2735/Config.lb
CVS:    src/mainboard/tyan/s2735/auto.c
CVS:    src/mainboard/tyan/s2735/chip.h
CVS:    src/mainboard/tyan/s2735/cmos.layout
CVS:    src/mainboard/tyan/s2735/failover.c
CVS:    src/mainboard/tyan/s2735/irq_tables.c
CVS:    src/mainboard/tyan/s2735/mainboard.c
CVS:    src/mainboard/tyan/s2735/mptable.c
CVS:    src/northbridge/intel/e7501/Config.lb
CVS:    src/northbridge/intel/e7501/chip.h
CVS:    src/northbridge/intel/e7501/debug.c
CVS:    src/northbridge/intel/e7501/e7501.h
CVS:    src/northbridge/intel/e7501/northbridge.c
CVS:    src/northbridge/intel/e7501/raminit.c
CVS:    src/northbridge/intel/e7501/raminit.h
CVS:    src/northbridge/intel/e7501/reset_test.c
CVS:    src/southbridge/intel/i82801er/Config.lb
CVS:    src/southbridge/intel/i82801er/cmos_failover.c
CVS:    src/southbridge/intel/i82801er/i82801er.c
CVS:    src/southbridge/intel/i82801er/i82801er.h
CVS:    src/southbridge/intel/i82801er/i82801er_ac97.c
CVS:    src/southbridge/intel/i82801er/i82801er_early_smbus.c
CVS:    src/southbridge/intel/i82801er/i82801er_ide.c
CVS:    src/southbridge/intel/i82801er/i82801er_lpc.c
CVS:    src/southbridge/intel/i82801er/i82801er_nic.c
CVS:    src/southbridge/intel/i82801er/i82801er_pci.c
CVS:    src/southbridge/intel/i82801er/i82801er_reset.c
CVS:    src/southbridge/intel/i82801er/i82801er_sata.c
CVS:    src/southbridge/intel/i82801er/i82801er_smbus.c
CVS:    src/southbridge/intel/i82801er/i82801er_usb.c
CVS:    src/southbridge/intel/i82801er/i82801er_usb2.c
CVS:    src/southbridge/intel/i82870/82870.h
CVS:    src/southbridge/intel/i82870/Config.lb
CVS:    src/southbridge/intel/i82870/p64h2_ioapic.c
CVS:    src/southbridge/intel/i82870/p64h2_pci_parity.c
....

Others in targets/tyan/s2735


From ebiederman at lnxi.com  Wed Jun 30 22:49:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jun 30 22:49:00 2004
Subject: qemu target
In-Reply-To: <20040630173848.GA21144@openbios.org>
References: <20040629175702.GA4708@openbios.org>
	<m34qotwybe.fsf@maxwell.lnxi.com>
	<20040630110303.GB15261@openbios.org>
	<m3oen1rmzb.fsf@maxwell.lnxi.com>
	<20040630173848.GA21144@openbios.org>
Message-ID: <m3k6xopdfg.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at openbios.org> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [040630 19:10]:
> > Ok then most likely you have managed to get the debugging printk's
> > compiled out or something like that.  It should be possible to insert
> > a -g statement into the build and then to step through the code execution
> > with gdb.  qemu appears to have support for gdb stubs.
> > 
> > The real interesting part is what is the debug level set to.  And you can
> > get that with port 0x80.
> > 
> > Maybe we are attempting to use cmos options and that is not properly
> implemented?
> 
> 
> Actually that sounds very reasonable. all my builds where this happens
> are built without cmos support, and in this case the get_option()
> function always returns -2 iirc. 
> 
> I will give it a try enabling option tables 

Actually I was suggesting disabling option tables, to work around
this issue.

Anyway good luck.

Eric


From ebiederman at lnxi.com  Wed Jun 30 23:20:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jun 30 23:20:00 2004
Subject: CPU refactoring status....
In-Reply-To: <m3isd9sb83.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C943142305535CCC@TYANWEB>
	<m3isd9sb83.fsf@maxwell.lnxi.com>
Message-ID: <m3eknwpbze.fsf_-_@maxwell.lnxi.com>

Ok before I head to bed and get some sleep here is a quick status
update of my refactoring the cpu initialization code.

The cpu tree for x86 cpu now looks like:

cpu/x86/mtrr
cpu/x86/lapic
cpu/x86/fpu
cpu/x86/mmx
cpu/x86/sse
... One directory for each generic feature we may want to reuse

cpu/intel/model_f0x/
cpu/intel/model_f1x/
cpu/intel/model_f2x/
cpu/intel/model_f3x/
... One directory for each core that is supported.
    The numbers are the significant bits from cpuid.
    Stepping differences are conglerated together.

cpu/intel/socket_mPGA603/
cpu/intel/socket_mPGA604_533Mhz/
cpu/intel/socket_mPGA604_800Mhz/
... One directory for each socket we support.
    These will use the dir directive to suck in the appropriate cores.

cpu/amd/model_fxx/ 
... So far for Opteron AMD really only has one core, with multiple steppings

cpu/amd/socket_940/
cpu/amd/socket_939/
cpu/amd/socket_754/
... But there are currently 3 sockets I need to support.

cpu/x86/socket7
... Generic sockets supported my multiple vendors go here.


arch/i386/lib/cpu.c now computes the vendor and device information
of each cpu with cpuid.  And then looks up the appropriate code in a
table.

I have sorted out cpus in the device tree and assigning their
apic id's in the static tree.

The next big task is to get make the SMP cpu initialization methods
normal device tree methods.  I have everything ready to do that
except I need a good way to get the information in the struct
mem_range array by sizeram().   My gut feel is that I want to
incorporate the sizeram functionality into the resource allocator,
we will see.

As for the rest of the pieces I have started on there are still
a lot of details to flesh out but the with the structure there
it is just a matter of taking the time to do everything.

Eric