From ebiederman at lnxi.com  Mon Mar  1 12:46:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar  1 12:46:01 2004
Subject: Canterwood/Springdale
In-Reply-To: <Pine.LNX.4.44.0402261218400.20308-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0402261218400.20308-100000@maxroach.lanl.gov>
Message-ID: <m3u118h1y0.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Thu, 26 Feb 2004, James Weir wrote:
> 
> > Can anyone let me know if the documentation for the above chipsets is freely
> > available/already ported to linuxbios and does the documentation require a
> > NDA of any kind?
> 
> Are these new intel chipsets? Intel has changed policy, it seems, and will
> no longer release chipset info. I'm not sure how this is going to play
> out.

Well if you have a big enough carrot it looks like it still works...
 
> It seems the itanium secrecy policies are percolating down to the rest of 
> intel's chipset groups.

At least it is trying.

Eric


From ebiederman at lnxi.com  Mon Mar  1 13:23:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar  1 13:23:01 2004
Subject: Prefmem of bus 3
In-Reply-To: <Pine.LNX.4.44.0402271225280.31881-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0402271225280.31881-100000@maxroach.lanl.gov>
Message-ID: <m3ptbwh09b.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Fri, 27 Feb 2004, YhLu wrote:
> 
> > Have you ever tested myrinet card on K8 MB under LinuxBIOS?
> 
> we have a 1408-node K8 machine with myrinet working under linuxbios, and a 
> 256-node K8 machine working with linuxbios. Arima HDAMA mainboards.
> 
> I wonder what's going on here, I have not had time to look in detail.

So the problem appears to be that the prefmem region on the upper bus
is to large.

I wonder if why this work on LANL clusters and not on others is the
result of code skew.

Lightning nodes with myrinet only seem to have one prefmem region.

Yet another reminder that I really need to finish syncing up the code bases.

Eric


From ollie at lanl.gov  Mon Mar  1 13:38:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Mar  1 13:38:00 2004
Subject: Prefmem of bus 3
In-Reply-To: <m3ptbwh09b.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0402271225280.31881-100000@maxroach.lanl.gov>
	 <m3ptbwh09b.fsf@maxwell.lnxi.com>
Message-ID: <1078167428.10012.95.camel@exponential.lanl.gov>

On Mon, 2004-03-01 at 11:48, Eric W. Biederman wrote:
> ron minnich <rminnich at lanl.gov> writes:
> 
> > On Fri, 27 Feb 2004, YhLu wrote:
> > 
> > > Have you ever tested myrinet card on K8 MB under LinuxBIOS?
> > 
> > we have a 1408-node K8 machine with myrinet working under linuxbios, and a 
> > 256-node K8 machine working with linuxbios. Arima HDAMA mainboards.
> > 
> > I wonder what's going on here, I have not had time to look in detail.
> 
> So the problem appears to be that the prefmem region on the upper bus
> is to large.
> 
> I wonder if why this work on LANL clusters and not on others is the
> result of code skew.
> 
> Lightning nodes with myrinet only seem to have one prefmem region.
> 
> Yet another reminder that I really need to finish syncing up the code bases.
> 

I think there is some problem in the resource allocation code so it can 
not handle devices with 2 prefmem.

Is the code just picking the "largest" resource ? I am really confused
by the code in devices.c

Ollie




From ebiederman at lnxi.com  Mon Mar  1 15:41:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar  1 15:41:01 2004
Subject: Prefmem of bus 3
In-Reply-To: <1078167428.10012.95.camel@exponential.lanl.gov>
References: <Pine.LNX.4.44.0402271225280.31881-100000@maxroach.lanl.gov>
	<m3ptbwh09b.fsf@maxwell.lnxi.com>
	<1078167428.10012.95.camel@exponential.lanl.gov>
Message-ID: <m3ekscffaf.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> I think there is some problem in the resource allocation code so it can 
> not handle devices with 2 prefmem.

Maybe.  I know there was some kind of problem on the opteron, early on but I forget
what.  The code for all resource types is the same so if we can handle
two resources on a bus of the same type it should not be quite as simple as that.

> Is the code just picking the "largest" resource ? I am really confused
> by the code in devices.c

No.

The code should be quite simple but it is recursive and highly
abstracted which makes it hard to follow.

The high level overview is the code works in two passes.
The first pass is to determine the size of the resource window needed.
The second pass is to determine the actual resource assignments.

There are many was to assign resources on a bus.  After some
experiences with tight memory situations I implemented a near optimal
solution.  The solution is optimal if all of your resources are a
power of 2 in size.

Basically the code is a loop.  For each iteration the
code finds the largest unassigned resource.  Then the resource
constraints of that resource are considered and padding between
the previous resources and the current resources are inserted if
necessary.  Then we get into the next iteration.

The reason this is optimal if all of your resources are a power of
two in size is because if your previous resource is a larger or equal
power of two no padding will be needed for the current resource.

The situation Yhlu has is below and it is weird.  The resources are
assigned properly but when the are clumped together into a range
register on the bus that value is incorrect.  Which is very weird.

YhLu has:

ASSIGN RESOURCES, bus 3
PCI: 03:03.0 10 <- [0xe0000000 - 0xefffffff] prefmem
PCI: 03:03.0 18 <- [0xf0000000 - 0xf3ffffff] prefmem

And then on bus 2:

PCI: 01:02.0 24 <- [0xe0000000 - 0xffffffff] bus 3 prefmem

The bus 3 prefmem should be
PCI: 01:02.0 24 <- [0xe0000000 - 0xf3ffffff] bus 3 prefmem

So it looks like stuck bits or something.

Ollie can you get a boot log from Orange?  Unless they are different types
of infiniband adapters things should be fairly comparable.

Eric


From YhLu at tyan.com  Mon Mar  1 15:47:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Mar  1 15:47:01 2004
Subject: =?GB2312?B?tPC4tDogUHJlZm1lbSBvZiBidXMgMw==?=
Message-ID: <3174569B9743D511922F00A0C9431423041D28E7@TYANWEB>

Some devie has two mem regions( non-pref) and it works.

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?1? 13:07
???: Li-Ta Lo
??: ron minnich; YhLu; LinuxBIOS
??: Re: Prefmem of bus 3

Li-Ta Lo <ollie at lanl.gov> writes:

> I think there is some problem in the resource allocation code so it can 
> not handle devices with 2 prefmem.

Maybe.  I know there was some kind of problem on the opteron, early on but I
forget
what.  The code for all resource types is the same so if we can handle
two resources on a bus of the same type it should not be quite as simple as
that.

> Is the code just picking the "largest" resource ? I am really confused
> by the code in devices.c

No.

The code should be quite simple but it is recursive and highly
abstracted which makes it hard to follow.

The high level overview is the code works in two passes.
The first pass is to determine the size of the resource window needed.
The second pass is to determine the actual resource assignments.

There are many was to assign resources on a bus.  After some
experiences with tight memory situations I implemented a near optimal
solution.  The solution is optimal if all of your resources are a
power of 2 in size.

Basically the code is a loop.  For each iteration the
code finds the largest unassigned resource.  Then the resource
constraints of that resource are considered and padding between
the previous resources and the current resources are inserted if
necessary.  Then we get into the next iteration.

The reason this is optimal if all of your resources are a power of
two in size is because if your previous resource is a larger or equal
power of two no padding will be needed for the current resource.

The situation Yhlu has is below and it is weird.  The resources are
assigned properly but when the are clumped together into a range
register on the bus that value is incorrect.  Which is very weird.

YhLu has:

ASSIGN RESOURCES, bus 3
PCI: 03:03.0 10 <- [0xe0000000 - 0xefffffff] prefmem
PCI: 03:03.0 18 <- [0xf0000000 - 0xf3ffffff] prefmem

And then on bus 2:

PCI: 01:02.0 24 <- [0xe0000000 - 0xffffffff] bus 3 prefmem

The bus 3 prefmem should be
PCI: 01:02.0 24 <- [0xe0000000 - 0xf3ffffff] bus 3 prefmem

So it looks like stuck bits or something.

Ollie can you get a boot log from Orange?  Unless they are different types
of infiniband adapters things should be fairly comparable.

Eric


From YhLu at tyan.com  Mon Mar  1 15:51:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Mar  1 15:51:01 2004
Subject: =?GB2312?B?tPC4tDogUHJlZm1lbSBvZiBidXMgMw==?=
Message-ID: <3174569B9743D511922F00A0C9431423041D28E8@TYANWEB>

Some time you said that arima board connect all PCI-X slots of amd 8131 irq
to amd 8111 ioapic intead of 8131.

So even disable ioapic of 8131, device on PCI-X still works properly.

After enable ioapic of 8131, devices that are not using prefmem works well.

YH.

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?1? 10:48
???: ron minnich
??: YhLu; ebiederman at lnxi.com; LinuxBIOS
??: Re: Prefmem of bus 3

ron minnich <rminnich at lanl.gov> writes:

> On Fri, 27 Feb 2004, YhLu wrote:
> 
> > Have you ever tested myrinet card on K8 MB under LinuxBIOS?
> 
> we have a 1408-node K8 machine with myrinet working under linuxbios, and a

> 256-node K8 machine working with linuxbios. Arima HDAMA mainboards.
> 
> I wonder what's going on here, I have not had time to look in detail.

So the problem appears to be that the prefmem region on the upper bus
is to large.

I wonder if why this work on LANL clusters and not on others is the
result of code skew.

Lightning nodes with myrinet only seem to have one prefmem region.

Yet another reminder that I really need to finish syncing up the code bases.

Eric


From sheltraw at unm.edu  Tue Mar  2 17:42:00 2004
From: sheltraw at unm.edu (Daniel Sheltraw)
Date: Tue Mar  2 17:42:00 2004
Subject: BIOS calls
Message-ID: <1078268482.4045124282a31@webmail2.unm.edu>

Hello LinuxBIOS list

Does LinuxBIOS have a protected-mode API that can be used in 
kernel-space to config devices similar to the old DOS-based
BIOS calls in real-mode?

Thank you,
Daniel Sheltraw


From ebiederman at lnxi.com  Tue Mar  2 18:09:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Mar  2 18:09:00 2004
Subject: pci_scan_get_dev() in pci_scan_bus()
In-Reply-To: <1078186620.10012.108.camel@exponential.lanl.gov>
References: <1078186620.10012.108.camel@exponential.lanl.gov>
Message-ID: <m3brne962y.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> I am reading the device tree/resource allocation code 
> and trying to add more doxygen stuff. One thing I am not
> queit sure is the pci_scan_get_dev() in pci_scan_bus().
> 
> 	for (devfn = min_devfn; devfn <= max_devfn; devfn++) {
> 		uint32_t id, class;
> 		uint8_t hdr_type;
> 
> 		/* First thing setup the device structure */
> 		dev = pci_scan_get_dev(&old_devices, devfn);
> 
> My understanding is some pci devices are static devices too
> and are already "enumerated" befor the pci_scan_bus() (actually,
> the dev_enumerate()) is called and they are on the device
> tree (or list) by the time pci_scan_bus() is called. The
> pci_scan_get_dev() try to find the device under enumeration
> on that list. Am I correct ?

Yes.  

Eric


From rminnich at lanl.gov  Tue Mar  2 18:09:07 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar  2 18:09:07 2004
Subject: BIOS calls
In-Reply-To: <1078268482.4045124282a31@webmail2.unm.edu>
Message-ID: <Pine.LNX.4.44.0403021627560.19371-100000@maxroach.lanl.gov>

On Tue, 2 Mar 2004, Daniel Sheltraw wrote:

> Does LinuxBIOS have a protected-mode API that can be used in 
> kernel-space to config devices similar to the old DOS-based
> BIOS calls in real-mode?

no, intentionally not. We don't ever want to get back into that nightmare 
unless it becomes hopelessly unavoidable.

ron



From sheltraw at unm.edu  Tue Mar  2 18:23:01 2004
From: sheltraw at unm.edu (Daniel Sheltraw)
Date: Tue Mar  2 18:23:01 2004
Subject: BIOS calls
In-Reply-To: <Pine.LNX.4.44.0403021627560.19371-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403021627560.19371-100000@maxroach.lanl.gov>
Message-ID: <1078270941.40451bdd642da@webmail2.unm.edu>

Quoting ron minnich <rminnich at lanl.gov>:

> On Tue, 2 Mar 2004, Daniel Sheltraw wrote:
> 
> > Does LinuxBIOS have a protected-mode API that can be used in 
> > kernel-space to config devices similar to the old DOS-based
> > BIOS calls in real-mode?
> 
> no, intentionally not. We don't ever want to get back into that
> nightmare 
> unless it becomes hopelessly unavoidable.
> 
> ron
> 
> 
Ron

I have been used Linux and RTAI-Linux to develop a hard real-time
application called RTStim which is used in functional neuroimaging
experimentation. RTStim makes use of two video cards. One card is
controlled by normal Linux and provides a GUI to RTStim. The other
card provides visual stimuli to subjects. To configure the second 
video card we have been using Linux's ability to configure video
while still in real mode by modifying the lilo config file. It would
be fantastic if we could eliminate the modification of this config 
file in the installation of RTStim. If we had a BIOS call to do
such a thing that would be ideal.

Do you know how to access such configuration ROM for video while
in protected-mode.?

Thanks again,
daniel 





 













From rminnich at lanl.gov  Tue Mar  2 18:27:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar  2 18:27:01 2004
Subject: BIOS calls
In-Reply-To: <1078270941.40451bdd642da@webmail2.unm.edu>
Message-ID: <Pine.LNX.4.44.0403021645330.19371-100000@maxroach.lanl.gov>

yes, we can help you with this. Let me talk to you next week, or Ollie 
and/or David hendricks can fill you in. But we can start up (some, not 
all, yet) cards from user mode.

ron



From firstone5 at hotmail.com  Wed Mar  3 10:46:01 2004
From: firstone5 at hotmail.com (first last)
Date: Wed Mar  3 10:46:01 2004
Subject: EPIA-M 6000 or M-10000  Frame buffer + linuxbios +/- VGA
Message-ID: <BAY10-F40Q9cAgjHXwK0000f148@hotmail.com>

Does anyone have a working snapshot of this?  I've tried building
the list from 2003-07-05 cvs and patch of Ashley, as well as cvs co of 
freebios2 tree
and found varying degrees of limited success.  If someone on the list has a 
working
snapshot or pointer, that could save some time here.

I appreciate and commend all those who have worked on this great project.  
The boots
done here using freebios v1 and v2 come in under several seconds to init 
level 3.  This project has great potential.


Many thanks in advance.

M. R.

_________________________________________________________________
Get business advice and resources to improve your work life, from bCentral. 
http://special.msn.com/bcentral/loudclear.armx



From ollie at lanl.gov  Wed Mar  3 11:05:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Mar  3 11:05:01 2004
Subject: BIOS calls
In-Reply-To: <1078270941.40451bdd642da@webmail2.unm.edu>
References: <Pine.LNX.4.44.0403021627560.19371-100000@maxroach.lanl.gov>
	 <1078270941.40451bdd642da@webmail2.unm.edu>
Message-ID: <1078331081.10012.120.camel@exponential.lanl.gov>

On Tue, 2004-03-02 at 16:42, Daniel Sheltraw wrote:
> Quoting ron minnich <rminnich at lanl.gov>:
> 
> > On Tue, 2 Mar 2004, Daniel Sheltraw wrote:
> > 
> > > Does LinuxBIOS have a protected-mode API that can be used in 
> > > kernel-space to config devices similar to the old DOS-based
> > > BIOS calls in real-mode?
> > 
> > no, intentionally not. We don't ever want to get back into that
> > nightmare 
> > unless it becomes hopelessly unavoidable.
> > 
> > ron
> > 
> > 
> Ron
> 
> I have been used Linux and RTAI-Linux to develop a hard real-time
> application called RTStim which is used in functional neuroimaging
> experimentation. RTStim makes use of two video cards. One card is
> controlled by normal Linux and provides a GUI to RTStim. The other
> card provides visual stimuli to subjects. To configure the second 
> video card we have been using Linux's ability to configure video
> while still in real mode by modifying the lilo config file. It would
> be fantastic if we could eliminate the modification of this config 
> file in the installation of RTStim. If we had a BIOS call to do
> such a thing that would be ideal.
> 
> Do you know how to access such configuration ROM for video while
> in protected-mode.?
> 

If the only thing you want to deal with is VGA, you don't need any
legacy bios call facility. We have emulators which can init the
VGA card in user mode.

BTW, are you using BOTH card in the same system ? Don't they conflict
each other ?

Ollie




From jbors at mail.ru  Wed Mar  3 12:08:01 2004
From: jbors at mail.ru (=?koi8-r?Q?=22?=Dmitry Borisov=?koi8-r?Q?=22=20?=)
Date: Wed Mar  3 12:08:01 2004
Subject: EPIA-M 6000 or M-10000  Frame buffer + linuxbios +/- VGA
In-Reply-To: <BAY10-F40Q9cAgjHXwK0000f148@hotmail.com>
Message-ID: <E1Aya9Y-000CkU-00.jbors-mail-ru@f11.mail.ru>

Subject: EPIA-M 6000 or M-10000  Frame buffer + linuxbios +/- VGA

> 
> Does anyone have a working snapshot of this?  I've tried building
> the list from 2003-07-05 cvs and patch of Ashley, as well as cvs co of 
> freebios2 tree
> and found varying degrees of limited success.  If someone on the list has a 
> working
> snapshot or pointer, that could save some time here.
> 
> I appreciate and commend all those who have worked on this great project.  
> The boots
> done here using freebios v1 and v2 come in under several seconds to init 
> level 3.  This project has great potential.
> 
> 
> Many thanks in advance.
> 
> M. R.
> 

Well, all I did is just took the snapshot as of 2003-07-05, aplpied Dave's patch on it and added filo as payload.
Also for my purposes I've made some changes to have pcx logo working( still waiting for Ron's update on joining EPIA changes into the cvs ).
It gives me linuxbios+ vga+ splash until linux starts.
Dmitry/



From tdeclerck at 3WARE.com  Wed Mar  3 21:33:00 2004
From: tdeclerck at 3WARE.com (Tina Declerck)
Date: Wed Mar  3 21:33:00 2004
Subject: PCI card bios accessibility
Message-ID: <A1964EDB64C8094DA12D2271C04B812601504574@tabby>

Hello,

I am new to this list so I apologize if this question has already been
answered.  I didn't see it
in the archives. 

- Does the Linux BIOS do discovery on PCI slots for the existance of cards?

- Will it use PCI configuration space to locate the Basic Address Register
(BAR) to locate bios
   on a PCI card and load it?  Specifically, this is regarding a 3ware RAID
card.

Thank you,

Tina


DISCLAIMER: The information contained in this electronic mail transmission
is intended by 3ware for the use of the named individual or entity to which
it is directed and may contain information that is confidential or
privileged and should not be disseminated without prior approval from 3ware 




From stuge-linuxbios at cdy.org  Wed Mar  3 21:49:01 2004
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Wed Mar  3 21:49:01 2004
Subject: PCI card bios accessibility
In-Reply-To: <A1964EDB64C8094DA12D2271C04B812601504574@tabby>
References: <A1964EDB64C8094DA12D2271C04B812601504574@tabby>
Message-ID: <20040304030859.GG22905@foo.birdnet.se>

Hi!

On Wed, Mar 03, 2004 at 06:55:32PM -0800, Tina Declerck wrote:
> - Does the Linux BIOS do discovery on PCI slots for the existance
> of cards?

Yes, LinuxBIOS enumerates PCI buses behind hosts and bridges.


> - Will it use PCI configuration space to locate the Basic Address
> Register (BAR) to locate bios on a PCI card and load it?

There is initial work being done with VGA cards and progress indicates
that this may actually be possible to do even though LinuxBIOS runs
in protected mode and currently doesn't (want to) provide legacy BIOS
services. (i.e. int15h et.al.)


> Specifically, this is regarding a 3ware RAID card.

Right. Other peripheral cards vary in their behavior/requirements but I
personally think that a kernel driver should be able to do all neccessary
hardware initialization beyond PCI configuration. Providing a BIOS onboard
a storage controller would be useful primarily for booting legacy
operating systems off the connected storage. (Bonus: Hardware becomes
architecture independent - runs on anything with a PCI bus.)


> DISCLAIMER: The information contained in this electronic mail transmission
> is intended by 3ware for the use of the named individual or entity to which
> it is directed and may contain information that is confidential or
> privileged and should not be disseminated without prior approval from 3ware

I like 3ware and your products in general (just ordered a 7506-4), but I'm
afraid that this kind of disclaimer is useless at best, counterproductive at
worst - especially in open source environments.


Regards,

//Peter


From info at schihei.de  Thu Mar  4 09:02:01 2004
From: info at schihei.de (Heiko Joerg Schick)
Date: Thu Mar  4 09:02:01 2004
Subject: Question on LinuxBIOS Bios Stack
Message-ID: <40473BF6.3040405@schihei.de>

Hello,

I can remember that (I think) 6 month ago, a system call
LOBOS was used to boot the later used Linux Kernel. Now I
saw in the document "Flexibility in ROM: A Stackable
Open Source BIOS" that a quite more complex firmware stack
is used, with the following components:
- LinuxBIOS
- ADLO
- Grub Bootloader
- Windows 2000, Linux, ...

I this always the case and how it is realized on other
platforms, like PowerPC???

Thanks in advance !!!

Regards,
    Heiko



From firstone5 at hotmail.com  Thu Mar  4 10:30:01 2004
From: firstone5 at hotmail.com (first last)
Date: Thu Mar  4 10:30:01 2004
Subject: EPIA-M 6000 or M-10000 Frame buffer + linuxbios +/- VGA
Message-ID: <BAY10-F32TdHKjYelTA00003101@hotmail.com>

Ron,

Any time frame for those Borisov changes to go into CVS?

Regards,
M. R.




>From: "Dmitry Borisov" <jbors at mail.ru>
>Reply-To: "Dmitry Borisov" <jbors at mail.ru>
>To: linuxbios at clustermatic.org
>Subject: Re: EPIA-M 6000 or M-10000  Frame buffer + linuxbios +/- VGA
>Date: Wed, 03 Mar 2004 20:27:28 +0300
>
>Subject: EPIA-M 6000 or M-10000  Frame buffer + linuxbios +/- VGA
>
> >
> > Does anyone have a working snapshot of this?  I've tried building
> > the list from 2003-07-05 cvs and patch of Ashley, as well as cvs co of
> > freebios2 tree
> > and found varying degrees of limited success.  If someone on the list 
>has a
> > working
> > snapshot or pointer, that could save some time here.
> >
> > I appreciate and commend all those who have worked on this great 
>project.
> > The boots
> > done here using freebios v1 and v2 come in under several seconds to init
> > level 3.  This project has great potential.
> >
> >
> > Many thanks in advance.
> >
> > M. R.
> >
>
>Well, all I did is just took the snapshot as of 2003-07-05, aplpied Dave's 
>patch on it and added filo as payload.
>Also for my purposes I've made some changes to have pcx logo working( still 
>waiting for Ron's update on joining EPIA changes into the cvs ).
>It gives me linuxbios+ vga+ splash until linux starts.
>Dmitry/
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios

_________________________________________________________________
Fast. Reliable. Get MSN 9 Dial-up - 3 months for the price of 1! 
(Limited-time Offer) http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/



From rminnich at lanl.gov  Thu Mar  4 11:35:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar  4 11:35:00 2004
Subject: PCI card bios accessibility
In-Reply-To: <A1964EDB64C8094DA12D2271C04B812601504574@tabby>
Message-ID: <Pine.LNX.4.44.0403040953480.2899-100000@maxroach.lanl.gov>

On Wed, 3 Mar 2004, Tina Declerck wrote:

> - Does the Linux BIOS do discovery on PCI slots for the existance of cards?

yes

> 
> - Will it use PCI configuration space to locate the Basic Address Register
> (BAR) to locate bios
>    on a PCI card and load it?  Specifically, this is regarding a 3ware RAID
> card.

This is done now in user mode via emulation, for a number of reasons, and 
this emulation will move to linuxbios in a month or so.

ron



From rminnich at lanl.gov  Thu Mar  4 12:30:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar  4 12:30:00 2004
Subject: EPIA-M 6000 or M-10000 Frame buffer + linuxbios +/- VGA
In-Reply-To: <BAY10-F32TdHKjYelTA00003101@hotmail.com>
Message-ID: <Pine.LNX.4.44.0403041047580.3365-100000@maxroach.lanl.gov>

On Thu, 4 Mar 2004, first last wrote:

> Any time frame for those Borisov changes to go into CVS?

well, I have asked him to send a cvs diff -u, so that I can just apply the 
patch. 

I didn't realize how much demand there was ...

Also do the ports for these boards now use SPD for sizing DRAM? That is a 
concern for me.

ron



From jbors at mail.ru  Thu Mar  4 14:39:01 2004
From: jbors at mail.ru (=?koi8-r?Q?=22?=Dmitry Borisov=?koi8-r?Q?=22=20?=)
Date: Thu Mar  4 14:39:01 2004
Subject: EPIA-M 6000 or M-10000 Frame buffer + linuxbios +/- VGA
In-Reply-To: <Pine.LNX.4.44.0403041047580.3365-100000@maxroach.lanl.gov>
Message-ID: <E1Ayyzy-000OL5-00.jbors-mail-ru@f10.mail.ru>

> 
> On Thu, 4 Mar 2004, first last wrote:
> 
> > Any time frame for those Borisov changes to go into CVS?
> 
> well, I have asked him to send a cvs diff -u, so that I can just apply the 
> patch. 
> 
> I didn't realize how much demand there was ...
> 
> Also do the ports for these boards now use SPD for sizing DRAM? That is a 
> concern for me.
> 
> ron

Ron,
What I see from CVS and version that works for me( as of Jul-2003 ) that they are different quite a lot( for EPIA-M part ). If you can make a decision of which one should stay I would make a patch then.
BTW: I was not able to make the patched current version to work with the same stability as patched July's version.
I'll wait for your take on that. 
Dmitry/


From yhlu at tyan.com  Thu Mar  4 22:55:00 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Thu Mar  4 22:55:00 2004
Subject: Prefmem of bus 3
In-Reply-To: <3174569B9743D511922F00A0C9431423041D28E8@TYANWEB>
Message-ID: <200403050354.i253s0012490@nwn.definitive.org>

Ron, 

I have verified the myerinet card with s2882 in LinuxBIOS. It works well.

Eric,

I wonder if round function in pci_device.c cause the bus prefmem region
calculation problem.

Also according to suggestion from quadrics and amd, it seems that BIOS and
kernel need to be patched to allow the prefmem region ( after mmio_basek) to
be put the mtrr as write-back to get the better perfmormance. i.e. 2.5us->1.
8us 0-byte ping pong. So may need to change the write_linuxbios_table and
update the struct mem_reagion.

I have attached the boot log with QM card. 
Also found the display mmio region of 0:18:1 is shown ad 0:18.0, but the
real reg content is right. But the prefmem region register of 1:2:0 is not
the same as 0xe0000000 to 0xffffffff, and it (0x24) is "01 e0 f1 ff"

Can some one send me the boot log of quadrics on other K8 board?

Regards

YH.

-----????-----
???: YhLu 
????: 2004?3?1? 13:15
???: ebiederman at lnxi.com; ron minnich
??: LinuxBIOS
??: ??: Prefmem of bus 3

Some time you said that arima board connect all PCI-X slots of amd 8131 irq
to amd 8111 ioapic intead of 8131.

So even disable ioapic of 8131, device on PCI-X still works properly.

After enable ioapic of 8131, devices that are not using prefmem works well.

YH.

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?1? 10:48
???: ron minnich
??: YhLu; ebiederman at lnxi.com; LinuxBIOS
??: Re: Prefmem of bus 3

ron minnich <rminnich at lanl.gov> writes:

> On Fri, 27 Feb 2004, YhLu wrote:
> 
> > Have you ever tested myrinet card on K8 MB under LinuxBIOS?
> 
> we have a 1408-node K8 machine with myrinet working under linuxbios, and a

> 256-node K8 machine working with linuxbios. Arima HDAMA mainboards.
> 
> I wonder what's going on here, I have not had time to look in detail.

So the problem appears to be that the prefmem region on the upper bus
is to large.

I wonder if why this work on LANL clusters and not on others is the
result of code skew.

Lightning nodes with myrinet only seem to have one prefmem region.

Yet another reminder that I really need to finish syncing up the code bases.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s2882_QM_regs.zip
Type: application/octet-stream
Size: 8242 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040304/3260eaf8/attachment.obj>

From yhlu at tyan.com  Thu Mar  4 22:56:50 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Thu Mar  4 22:56:50 2004
Subject: Prefmem of bus 3
In-Reply-To: <3174569B9743D511922F00A0C9431423041D28E8@TYANWEB>
Message-ID: <200403050354.i253sM012496@nwn.definitive.org>

Ron, 

I have verified the myerinet card with s2882 in LinuxBIOS. It works well.

Eric,

I wonder if round function in pci_device.c cause the bus prefmem region
calculation problem.

Also according to suggestion from quadrics and amd, it seems that BIOS and
kernel need to be patched to allow the prefmem region ( after mmio_basek) to
be put the mtrr as write-back to get the better perfmormance. i.e. 2.5us->1.
8us 0-byte ping pong. So may need to change the write_linuxbios_table and
update the struct mem_reagion.

I have attached the boot log with QM card. 
Also found the display mmio region of 0:18:1 is shown ad 0:18.0, but the
real reg content is right. But the prefmem region register of 1:2:0 is not
the same as 0xe0000000 to 0xffffffff, and it (0x24) is "01 e0 f1 ff"

Can some one send me the boot log of quadrics on other K8 board?

Regards

YH.

-----????-----
???: YhLu 
????: 2004?3?1? 13:15
???: ebiederman at lnxi.com; ron minnich
??: LinuxBIOS
??: ??: Prefmem of bus 3

Some time you said that arima board connect all PCI-X slots of amd 8131 irq
to amd 8111 ioapic intead of 8131.

So even disable ioapic of 8131, device on PCI-X still works properly.

After enable ioapic of 8131, devices that are not using prefmem works well.

YH.

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?1? 10:48
???: ron minnich
??: YhLu; ebiederman at lnxi.com; LinuxBIOS
??: Re: Prefmem of bus 3

ron minnich <rminnich at lanl.gov> writes:

> On Fri, 27 Feb 2004, YhLu wrote:
> 
> > Have you ever tested myrinet card on K8 MB under LinuxBIOS?
> 
> we have a 1408-node K8 machine with myrinet working under linuxbios, and a

> 256-node K8 machine working with linuxbios. Arima HDAMA mainboards.
> 
> I wonder what's going on here, I have not had time to look in detail.

So the problem appears to be that the prefmem region on the upper bus
is to large.

I wonder if why this work on LANL clusters and not on others is the
result of code skew.

Lightning nodes with myrinet only seem to have one prefmem region.

Yet another reminder that I really need to finish syncing up the code bases.

Eric
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s2882_QM_regs.zip
Type: application/octet-stream
Size: 8242 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040304/ba95b7d6/attachment.obj>

From rminnich at lanl.gov  Thu Mar  4 23:18:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar  4 23:18:01 2004
Subject: EPIA-M 6000 or M-10000 Frame buffer + linuxbios +/- VGA
In-Reply-To: <E1Ayyzy-000OL5-00.jbors-mail-ru@f10.mail.ru>
Message-ID: <Pine.LNX.4.44.0403042137110.7453-100000@maxroach.lanl.gov>

On Thu, 4 Mar 2004, [koi8-r] "Dmitry Borisov[koi8-r] "  wrote:

> What I see from CVS and version that works for me( as of Jul-2003 )
> that they are different quite a lot( for EPIA-M part ). 


Dave Ashley, what do you think?

Dmitry, send me the diff -u for both versions of linuxbios. 

ron



From rminnich at lanl.gov  Fri Mar  5 00:27:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar  5 00:27:01 2004
Subject: Prefmem of bus 3
In-Reply-To: <200403050414.i254EQNY004463@mailproxy3.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403042245280.7453-100000@maxroach.lanl.gov>

On Thu, 4 Mar 2004, Yinghai Lu wrote:

> Also according to suggestion from quadrics and amd, it seems that BIOS and
> kernel need to be patched to allow the prefmem region ( after mmio_basek) to
> be put the mtrr as write-back to get the better perfmormance. i.e. 2.5us->1.
> 8us 0-byte ping pong. So may need to change the write_linuxbios_table and
> update the struct mem_reagion.

I don't think the bios should do that. This setting of the mtrr for a 
particular card, on a particular motherboard, with a particular CPU, OS, 
and library, is really not a matter for the BIOS to decide. This is a job 
for /dev/mtrr. 

ron



From rminnich at lanl.gov  Fri Mar  5 00:28:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar  5 00:28:01 2004
Subject: Prefmem of bus 3
In-Reply-To: <200403050414.i254EQNY004463@mailproxy3.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403042246490.7453-100000@maxroach.lanl.gov>

On Thu, 4 Mar 2004, Yinghai Lu wrote:

> I wonder if round function in pci_device.c cause the bus prefmem region
>calculation problem.

I am almost certain that Ollie had worked out the problem, but I can not 
check as I am in Vega$ (meeting, not gambling away my life's savings).

Ollie, did you know why this was happening.

ron



From yhlu at tyan.com  Fri Mar  5 06:11:01 2004
From: yhlu at tyan.com (Yinghai Lu)
Date: Fri Mar  5 06:11:01 2004
Subject: Prefmem of bus 3
In-Reply-To: <Pine.LNX.4.44.0403042246490.7453-100000@maxroach.lanl.gov>
Message-ID: <200403051110.i25BAC014211@nwn.definitive.org>

I'm in trip, otherwise I would add some output for that function. 

If the quadrics card can work with hdama, then need to look at the boot log
at  that.

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?3?4? 21:48
???: Yinghai Lu
??: 'YhLu'@mailproxy3.lanl.gov; ebiederman at lnxi.com; LinuxBIOS
??: re: Prefmem of bus 3

On Thu, 4 Mar 2004, Yinghai Lu wrote:

> I wonder if round function in pci_device.c cause the bus prefmem region
>calculation problem.

I am almost certain that Ollie had worked out the problem, but I can not 
check as I am in Vega$ (meeting, not gambling away my life's savings).

Ollie, did you know why this was happening.

ron



From tdeclerck at 3WARE.com  Fri Mar  5 11:51:00 2004
From: tdeclerck at 3WARE.com (Tina Declerck)
Date: Fri Mar  5 11:51:00 2004
Subject: PCI card bios accessibility
Message-ID: <A1964EDB64C8094DA12D2271C04B812601504584@tabby>


On Thurs, 4 Mar 2004, ron minnich wrote:
Ron,

Thank you for the quick response

> On Wed, 3 Mar 2004, Tina Declerck wrote:
>> - Will it use PCI configuration space to locate the Basic Address
Register
>> (BAR) to locate bios
>>    on a PCI card and load it?  Specifically, this is regarding a 3ware
RAID
>> card.
>
> This is done now in user mode via emulation, for a number of reasons, and 
> this emulation will move to linuxbios in a month or so.
>
That's good to hear.  We'd like to do some testing in-house once this is
available.

-Tina



DISCLAIMER: The information contained in this electronic mail transmission
is intended by 3ware for the use of the named individual or entity to which
it is directed and may contain information that is confidential or
privileged and should not be disseminated without prior approval from 3ware 




From ollie at lanl.gov  Fri Mar  5 12:02:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar  5 12:02:01 2004
Subject: PCI card bios accessibility
In-Reply-To: <A1964EDB64C8094DA12D2271C04B812601504584@tabby>
References: <A1964EDB64C8094DA12D2271C04B812601504584@tabby>
Message-ID: <1078507307.10012.129.camel@exponential.lanl.gov>

On Fri, 2004-03-05 at 10:12, Tina Declerck wrote:
> On Thurs, 4 Mar 2004, ron minnich wrote:
> Ron,
> 
> Thank you for the quick response
> 
> > On Wed, 3 Mar 2004, Tina Declerck wrote:
> >> - Will it use PCI configuration space to locate the Basic Address
> Register
> >> (BAR) to locate bios
> >>    on a PCI card and load it?  Specifically, this is regarding a 3ware
> RAID
> >> card.
> >
> > This is done now in user mode via emulation, for a number of reasons, and 
> > this emulation will move to linuxbios in a month or so.
> >
> That's good to hear.  We'd like to do some testing in-house once this is
> available.
> 

Why do you want to do this ? AFIAK, 3ware one of the few open source 
friendly vendors, the driver in the kernel can pretty much handle
anything.

Ollie




From tdeclerck at 3WARE.com  Fri Mar  5 12:38:01 2004
From: tdeclerck at 3WARE.com (Tina Declerck)
Date: Fri Mar  5 12:38:01 2004
Subject: PCI card bios accessibility
Message-ID: <A1964EDB64C8094DA12D2271C04B812601504585@tabby>

Hi Ollie,
> 
> > On Wed, 3 Mar 2004, Tina Declerck wrote:
> >> - Will it use PCI configuration space to locate the Basic Address
> Register
> >> (BAR) to locate bios
> >>    on a PCI card and load it?  Specifically, this is regarding a 3ware
> RAID
> >> card.
> >
> > This is done now in user mode via emulation, for a number of reasons,
and 
> > this emulation will move to linuxbios in a month or so.
> >
> That's good to hear.  We'd like to do some testing in-house once this is
> available.
> 

> Why do you want to do this ? AFIAK, 3ware one of the few open source 
> friendly vendors, the driver in the kernel can pretty much handle
> anything.

Thank you.  I'm not questioning the functionality of the driver, however,
some customers like to configure 3ware RAID using the 3ware bios.  If it
is called during the system boot the driver isn't involved. This is not
taking anything from existing functionality but trying to see if
the functions currently available with other BIOSes is or will be available
with the Linux BIOS.

Thank you,

Tina


DISCLAIMER: The information contained in this electronic mail transmission
is intended by 3ware for the use of the named individual or entity to which
it is directed and may contain information that is confidential or
privileged and should not be disseminated without prior approval from 3ware 




From ollie at lanl.gov  Fri Mar  5 15:35:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar  5 15:35:01 2004
Subject: boot_complete in hardwaremain() ?
Message-ID: <1078520107.10012.135.camel@exponential.lanl.gov>

Eric,

Is the boot_complete parameter in hardwaremain() still
used in freebios2 ? I found it is xor %ebp, %ebp in asm
and then passed to hardwaremain().

Ollie
  



From rsmith at bitworks.com  Fri Mar  5 16:32:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Fri Mar  5 16:32:00 2004
Subject: PCI card bios accessibility
In-Reply-To: <A1964EDB64C8094DA12D2271C04B812601504585@tabby>
References: <A1964EDB64C8094DA12D2271C04B812601504585@tabby>
Message-ID: <4048F654.4080507@bitworks.com>

Tina Declerck wrote:

> Thank you.  I'm not questioning the functionality of the driver, however,
> some customers like to configure 3ware RAID using the 3ware bios.  If it
> is called during the system boot the driver isn't involved. This is not
> taking anything from existing functionality but trying to see if
> the functions currently available with other BIOSes is or will be available
> with the Linux BIOS.

Hmmm... There will probally to be a lot of work then to make this go 
good enough for you.  You are talking lots of video and keyboard input 
functions.  LB provides only minimal system bios service suppport.  Even 
though the video bios may run under the emulator theres lots of support 
bios calls that are just empty functions.    The bulk of the bios 
emulation has just been toward getting the video card up enough that it 
can produce text and that a framebuffer driver can take over and take it 
up the rest of the way. (or the X driver)

I'm not saying it can't ever work but that someone is going to have to 
spend a lot of time filling in the necesary bios code.  You guys have 
control over your bios so you may be able to minimize the dependency on 
system bios services.

No need to wait for integration into LB to test though. The emulator is 
available now and runs as a user program.  It's probally a good idea to 
give it a whirl on your card and see what int services it whines about.

> DISCLAIMER: The information contained in this electronic mail transmission
> is intended by 3ware for the use of the named individual or entity to which
> it is directed and may contain information that is confidential or
> privileged and should not be disseminated without prior approval from 3ware 

You my want to drop this for list posts. I know on some lists people 
will refuse to answer posts that contain verbage like this.

-- 
Richard A. Smith
rsmith at bitworks.com




From ebiederman at lnxi.com  Fri Mar  5 16:54:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar  5 16:54:00 2004
Subject: boot_complete in hardwaremain() ?
In-Reply-To: <1078520107.10012.135.camel@exponential.lanl.gov>
References: <1078520107.10012.135.camel@exponential.lanl.gov>
Message-ID: <m3llmfos0g.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> Is the boot_complete parameter in hardwaremain() still
> used in freebios2 ? I found it is xor %ebp, %ebp in asm
> and then passed to hardwaremain().

Yes.  There is a second path in.  It is only set when memory is
already initialized.

Watch what happens when you run /sbin/reboot on a hdama.


Eric


From ollie at lanl.gov  Fri Mar  5 17:50:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar  5 17:50:01 2004
Subject: pci_scan_get_dev() in pci_scan_bus()
In-Reply-To: <m3brne962y.fsf@maxwell.lnxi.com>
References: <1078186620.10012.108.camel@exponential.lanl.gov>
	 <m3brne962y.fsf@maxwell.lnxi.com>
Message-ID: <1078528207.10012.138.camel@exponential.lanl.gov>

On Tue, 2004-03-02 at 16:34, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > Eric,
> > 
> > I am reading the device tree/resource allocation code 
> > and trying to add more doxygen stuff. One thing I am not
> > queit sure is the pci_scan_get_dev() in pci_scan_bus().
> > 
> > 	for (devfn = min_devfn; devfn <= max_devfn; devfn++) {
> > 		uint32_t id, class;
> > 		uint8_t hdr_type;
> > 
> > 		/* First thing setup the device structure */
> > 		dev = pci_scan_get_dev(&old_devices, devfn);
> > 
> > My understanding is some pci devices are static devices too
> > and are already "enumerated" befor the pci_scan_bus() (actually,
> > the dev_enumerate()) is called and they are on the device
> > tree (or list) by the time pci_scan_bus() is called. The
> > pci_scan_get_dev() try to find the device under enumeration
> > on that list. Am I correct ?
> 
> Yes.  
> 

What happen if a device is listed as a static device in the
config file but does not actually exist in the physical system ?

Ollie




From ebiederman at lnxi.com  Fri Mar  5 18:25:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar  5 18:25:01 2004
Subject: pci_scan_get_dev() in pci_scan_bus()
In-Reply-To: <1078528207.10012.138.camel@exponential.lanl.gov>
References: <1078186620.10012.108.camel@exponential.lanl.gov>
	<m3brne962y.fsf@maxwell.lnxi.com>
	<1078528207.10012.138.camel@exponential.lanl.gov>
Message-ID: <m3znaulumy.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> What happen if a device is listed as a static device in the
> config file but does not actually exist in the physical system ?

The device won't go away.  But it can legitimately show up as
a disabled device in the device tree.

I'm not certain when you would want to report a device statically
that may or may not be there.

Regardless showing up as disabled is effectively gone so it should
not be a real limitation.

Eric


From ebiederman at lnxi.com  Fri Mar  5 18:39:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar  5 18:39:00 2004
Subject: Question on LinuxBIOS Bios Stack
In-Reply-To: <40488DDB.6050109@schihei.de>
References: <40488DDB.6050109@schihei.de>
Message-ID: <m3vfliltzt.fsf@maxwell.lnxi.com>

Heiko Joerg Schick <info at schihei.de> writes:

> Hello Eric,
> 
> I've found an an article from you about LinuxBIOS. It would
> be great if you can answer some short question about the
> project.
> 
> 
> I can remember that (I think) 6 month ago, a system call
> LOBOS was used to boot the later used Linux Kernel. Now I
> saw in the document "Flexibility in ROM: A Stackable
> Open Source BIOS" that a quite more complex firmware stack
> is used, with the following components:
> - LinuxBIOS
> - ADLO
> - Bochs BIOS
> - Grub Bootloader
> - Windows 2000, Linux, ...
> 
> I this always the case and how it is realized on other
> platforms, like PowerPC???

LinuxBIOS is the core piece that initialized the hardware.  Then it loads
and executable in the ELF file format from the rom.  That executable
can be the final kernel, or it can currently be one of the following bootloaders:
ADLO
etherboot.
Linux Kernel with LOBOS/2 kernel monte/Kexec support
FILO
9Load
OpenBIOS
....

It is very simple and flexible.  As for the PowerPC I think they are
directly loading the kernel.  All that is required of the bootloader
is that it be able to run on the bare hardware making no firmware
calls.  Like an OS typically does.

Eric


From rminnich at lanl.gov  Fri Mar  5 22:02:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar  5 22:02:00 2004
Subject: PCI card bios accessibility
In-Reply-To: <A1964EDB64C8094DA12D2271C04B812601504584@tabby>
Message-ID: <Pine.LNX.4.44.0403052021510.16055-100000@maxroach.lanl.gov>

get back to me re VGA in a month or so.

ron



From ebiederman at lnxi.com  Sat Mar  6 05:42:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Mar  6 05:42:00 2004
Subject: PCI card bios accessibility
In-Reply-To: <A1964EDB64C8094DA12D2271C04B812601504585@tabby>
References: <A1964EDB64C8094DA12D2271C04B812601504585@tabby>
Message-ID: <m3k71y6xlu.fsf@maxwell.lnxi.com>

Tina Declerck <tdeclerck at 3ware.com> writes:

> Thank you.  I'm not questioning the functionality of the driver, however,
> some customers like to configure 3ware RAID using the 3ware bios.  If it
> is called during the system boot the driver isn't involved. This is not
> taking anything from existing functionality but trying to see if
> the functions currently available with other BIOSes is or will be available
> with the Linux BIOS.


Wrong assumption.  The long term plan is to call the linux driver
to boot off of cards.  The linux kernel will be used in our bootloader.
I am in the process of working out the size constraint issues.

The perception of a significant chunk of our customer base is that if
you can't do it from linux you can't do it.  So classic PC-BIOS
firmware compatibility is simply a nice to have, and I don't see it
extending beyond an optional feature.

Video cards have a special place in nuisance list.  But what
a video card requires from firmware is different from what a RAID card
with a menu to configure things requires.  And even the video card
BIOS support will be optional.

Eric


From linuxbios at xdr.com  Sat Mar  6 23:54:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Sat Mar  6 23:54:00 2004
Subject: EPIA-M 6000 or M-10000 Frame buffer + linuxbios +/- VGA
Message-ID: <200403070514.i275EVEM032756@xdr.com>

Ron asked:
>>What I see from CVS and version that works for me( as of Jul-2003 )
>Dave Ashley, what do you think?

I think Ron Minnich needs to get involved + get my patch working solidly
with the current version of linux bios :^). I'm using my version based on that
July snapshot of linuxbios, from my point of view it is rock solid. So
the question of stability when applying my patch to the latest version isn't
really something I can offer much help on, I haven't been updating my version
of linuxbios as changes have been made.

However my guess is it is related to the vgabios callbacks I implemented.
The docs I have (CLE266 bios porting guide as I recall) talk about what
callbacks have to be implemented. I'm not implementing all of them. I didn't
even understand the docs completely, and there are INT calls that being used
that aren't even mentioned. The way to address that might be to run the bios
emulator on the original vgabios and see how *it* sets up the registers for
the callbacks.

I had a problem where if the motherboard got hot, the vga bios would just
hang. I never figured out the cause, I hacked around it. Once an INT comes in
with an invalid number, I pop out of the vgabios mode. That is a real hack
where I restore the stack pointer to its original value before switching into
16 bit mode, or something...I don't recall exactly. It's in my patch. But
if anything changed related to invoking the vga bios, my hack will probably be
broken.

As I recall now that I think about it, I had to push more registers at
some point than the code originally pushed. I can't even remember the context
but I think it was vga related. I recall posting to this mailing list about
it, I think Eric B. had some comment about already fixing this in V2. It
was some really subtle problem as I recall...In thinking more about it I
think this was related to V2 of linuxbios and I was using an older compiler to
build it and my compiler was not making use of some register to store a local
variable, so it wasn't push/poping it, so when calling the vgabios and it
ended up trashing the register it was never preserved. This was V2 but perhaps
it applies to V1 as well...

At any rate I think the best thing I can do to contribute is to get an
epia-m into Ron's hands, and this is already accomplished. I don't think
I've really helped any though just now :^(...

All I can say though is linuxbios works perfectly well for my needs.

-Dave


From rminnich at lanl.gov  Sun Mar  7 22:02:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Mar  7 22:02:00 2004
Subject: EPIA-M 6000 or M-10000 Frame buffer + linuxbios +/- VGA
 [PMX:#]
In-Reply-To: <200403070514.i275EVEM032756@xdr.com>
Message-ID: <Pine.LNX.4.44.0403072022020.15012-100000@maxroach.lanl.gov>

Also, I really do want to bring this platform forward to V2 ...

ron



From ollie at lanl.gov  Mon Mar  8 11:03:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Mar  8 11:03:00 2004
Subject: pci_scan_get_dev() in pci_scan_bus()
In-Reply-To: <m3znaulumy.fsf@maxwell.lnxi.com>
References: <1078186620.10012.108.camel@exponential.lanl.gov>
	 <m3brne962y.fsf@maxwell.lnxi.com>
	 <1078528207.10012.138.camel@exponential.lanl.gov>
	 <m3znaulumy.fsf@maxwell.lnxi.com>
Message-ID: <1078762987.10012.141.camel@exponential.lanl.gov>

On Fri, 2004-03-05 at 16:52, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > What happen if a device is listed as a static device in the
> > config file but does not actually exist in the physical system ?
> 
> The device won't go away.  But it can legitimately show up as
> a disabled device in the device tree.
> 
> I'm not certain when you would want to report a device statically
> that may or may not be there.
> 

That happens for the processor. We list two cpus in current k8 mainboard
config files. But if there is only one cpu install, we will have a lot
of "absent" devices.

Ollie

> Regardless showing up as disabled is effectively gone so it should
> not be a real limitation.
> 
> Eric
> 



From rminnich at lanl.gov  Mon Mar  8 11:18:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar  8 11:18:01 2004
Subject: NXTV's current linuxbios patch [PMX:#]
In-Reply-To: <200311042200.hA4M0kEq019341@xdr.com>
Message-ID: <Pine.LNX.4.44.0403080936200.20026-100000@maxroach.lanl.gov>

I just now committed the 7/03 changes from Dave to the current tree, much 
of this had to be done by hand. 

It appeared to be ok, however, I hope I have not just broken things for 
anyone, although epia-m does not appear to be working on V1 so i assume 
this is ok.

Dave, can you check this out? Particularly raminit.inc, northbridge.c, and 
mainboard.c


ron



From firstone5 at hotmail.com  Mon Mar  8 13:43:00 2004
From: firstone5 at hotmail.com (first last)
Date: Mon Mar  8 13:43:00 2004
Subject: NXTV's current linuxbios patch [PMX:#]
Message-ID: <BAY10-F1226xwkLMKpv000119b2@hotmail.com>

I look forward to testing releases when ready.


>From: ron minnich <rminnich at lanl.gov>
>To: Dave Ashley <linuxbios at xdr.com>
>CC: linuxbios at clustermatic.org
>Subject: Re: NXTV's current linuxbios patch [PMX:#]
>Date: Mon, 8 Mar 2004 09:37:56 -0700 (MST)
>
>I just now committed the 7/03 changes from Dave to the current tree, much
>of this had to be done by hand.
>
>It appeared to be ok, however, I hope I have not just broken things for
>anyone, although epia-m does not appear to be working on V1 so i assume
>this is ok.
>
>Dave, can you check this out? Particularly raminit.inc, northbridge.c, and
>mainboard.c
>
>
>ron
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios

_________________________________________________________________
Store more e-mails with MSN Hotmail Extra Storage ? 4 plans to choose from! 
http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/



From linuxbios at xdr.com  Mon Mar  8 18:12:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Mon Mar  8 18:12:01 2004
Subject: NXTV's current linuxbios patch [PMX:#]
Message-ID: <200403082332.i28NWTBP007097@xdr.com>

Ron asked:
>Dave, can you check this out? Particularly raminit.inc, northbridge.c, and 
>mainboard.c

mainboard.c has come errors, "dev" isn't declared in one of the functions,
nor is "i":
Index: src/mainboard/via/epia-m/mainboard.c
===================================================================
RCS file: /cvsroot/freebios/freebios/src/mainboard/via/epia-m/mainboard.c,v
retrieving revision 1.9
diff -r1.9 mainboard.c
89d88
<       struct pci_dev *dev;
99a99,100
>       struct pci_dev *dev;
>       int i;


vgabios.c needs to have the vgarestart label defined:
Index: src/arch/i386/lib/vgabios.c
===================================================================
RCS file: /cvsroot/freebios/freebios/src/arch/i386/lib/vgabios.c,v
retrieving revision 1.11
diff -r1.11 vgabios.c
142,143c142,143
< "     ljmpl   $0x10, $1f\n"
< "1:\n"
---
> "     ljmpl   $0x10, $vgarestart\n"
> "vgarestart:\n"


My example.config:
Index: src/mainboard/via/epia-m/example.config
===================================================================
RCS file: /cvsroot/freebios/freebios/src/mainboard/via/epia-m/example.config,v
retrieving revision 1.6
diff -r1.6 example.config
2c2
< # LinuxBIOS config file for: VIA epia-m mini-itx
---
> # LinuxBIOS config file for: VIA epia mini-itx
5,6d4
< target /opt/cwlinux/buildrom/epia-m
< 
12d9
< # option SERIAL_POST=1
14d10
< # option TTYS0_BAUD=57600
16a13
> option HAVE_FRAMEBUFFER=1
32,33c29,40
< payload /opt/cwlinux/etherboot/src/bin32/via-rhine.ebi
< # payload /opt/cwlinux/memtest86/memtest
---
> #payload /ram/rtl8139.ebi
> #target /ram/epia-m
> 
> option CONFIG_VGABIOS=1
> option CONFIG_REALMODE_IDT=1
> dir src/bioscall
> option CONFIG_PCIBIOS=1
> option VGABIOS_START=0xfffe0000
> addaction romimage dd if=../vgabios.bin of=romimage bs=65536 seek=2 conv=sync conv=notrunc
> option CONFIG_EPIAMVERSIONSTRING="5.0.0E-" __DATE__ " " __TIME__
> target /ram/freebios/obj
> payload /code/bootfiles/etherboot/via6105m.ebi


When I build and attach my payload and my vgabios.bin, I get into linux
...
ip_conntrack version 2.1 (1016 buckets, 8128 max) - 292 bytes per conntrack     
ip_tables: (C) 2000-2002 Netfilter core team                                    
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.                             
NET4: Ethernet Bridge 008 for NET4.0                                            
802.1Q VLAN Support v1.8 Ben Greear <greearb at candelatech.com>                   
All bugs added by David S. Miller <davem at redhat.com>                            
RAMDISK: Compressed image found at block 0                                      
Freeing initrd memory: 302k freed                                               
VFS: Mounted root (ext2 filesystem) readonly.                                   
Freeing unused kernel memory: 272k freed                                        
EXT2-fs warning: checktime reached, running e2fsck is recommended               
Kernel panic: Attempted to kill init!                                           


So I'm not sure what the problem is...
BTW I got all kinds of warnings:
/ram/freebios/src/cpu/p6/mtrr.c: In function `set_var_mtrr':
/ram/freebios/src/cpu/p6/mtrr.c:132: warning: unused variable `tmp'
/ram/freebios/src/cpu/p6/mtrr.c: At top level:
/ram/freebios/src/cpu/p6/mtrr.c:29: warning: `rcsid' defined but not used
gcc ... -o l2_cache.o /ram/freebios/src/cpu/p6/l2_cache.c
/ram/freebios/src/cpu/p6/l2_cache.c:33: warning: `rcsid' defined but not used
gcc ... -o pcibios.o /ram/freebios/src/bioscall/pcibios.c
/ram/freebios/src/bioscall/pcibios.c: In function `pcibios':
/ram/freebios/src/bioscall/pcibios.c:122: warning: passing arg 3 of `pci_read_config_dword' from incompatible pointer type
/ram/freebios/src/bioscall/pcibios.c:41: warning: unused variable `edi'
/ram/freebios/src/bioscall/pcibios.c:42: warning: unused variable `esi'
/ram/freebios/src/bioscall/pcibios.c:43: warning: unused variable `ebp'
/ram/freebios/src/bioscall/pcibios.c:44: warning: unused variable `esp'
/ram/freebios/src/bioscall/pcibios.c:45: warning: unused variable `ebx'
/ram/freebios/src/bioscall/pcibios.c:46: warning: unused variable `edx'
/ram/freebios/src/bioscall/pcibios.c:47: warning: unused variable `ecx'
/ram/freebios/src/bioscall/pcibios.c:49: warning: unused variable `flags'
/ram/freebios/src/include/cpu/p5/io.h: At top level:
/ram/freebios/src/bioscall/pcibios.c:3: warning: `rcsid' defined but not used
rm -f linuxbios.a

Don't know if these are related...

Hope this helps...

-Dave


From rminnich at lanl.gov  Mon Mar  8 18:54:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar  8 18:54:01 2004
Subject: NXTV's current linuxbios patch [PMX:#]
In-Reply-To: <200403082332.i28NWTBP007097@xdr.com>
Message-ID: <Pine.LNX.4.44.0403081714360.22885-100000@maxroach.lanl.gov>

try it now ...

ron



From rminnich at lanl.gov  Mon Mar  8 20:08:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar  8 20:08:01 2004
Subject: amd 8111 smbus controller definitions
Message-ID: <Pine.LNX.4.44.0403081828190.22885-100000@maxroach.lanl.gov>

Where are these: 

#define SMBGSTATUS 0xe0
#define SMBGCTL    0xe2
#define SMBHSTADDR 0xe4
#define SMBHSTDAT  0xe6
#define SMBHSTCMD  0xe8
#define SMBHSTFIFO 0xe9

defined, i.e. what book? The 8111 book is self-contradictory and sketchy. 
Pointers welcome.

ron



From bari at onelabs.com  Mon Mar  8 20:58:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Mon Mar  8 20:58:01 2004
Subject: A Motherboard That Doesn't Require An OS
Message-ID: <404D29FB.40009@onelabs.com>

Slashdot has an article on: A Motherboard That Doesn't Require An OS

http://slashdot.org/article.pl?sid=04/03/08/2319215

When does a BIOS become an OS?... and all the usual humorous comments.

I guess you could do the same thing with LinuxBIOS if you just load 
Linux with all the drivers from your boot Flash and just say "it's all 
just BIOS and no OS".

-Bari




From rminnich at lanl.gov  Mon Mar  8 21:09:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar  8 21:09:00 2004
Subject: A Motherboard That Doesn't Require An OS
In-Reply-To: <404D29FB.40009@onelabs.com>
Message-ID: <Pine.LNX.4.44.0403081929350.25433-100000@maxroach.lanl.gov>

On Mon, 8 Mar 2004, Bari Ari wrote:

> I guess you could do the same thing with LinuxBIOS if you just load
> Linux with all the drivers from your boot Flash and just say "it's all
> just BIOS and no OS".

Yes, I had the same idea. I think the approach those guys are taking with 
that board is a long-term nightmare, short-term pretty fun.

ron



From rminnich at lanl.gov  Mon Mar  8 21:45:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar  8 21:45:00 2004
Subject: NXTV's current linuxbios patch [PMX:#]
In-Reply-To: <200403082332.i28NWTBP007097@xdr.com>
Message-ID: <Pine.LNX.4.44.0403082005030.25661-100000@maxroach.lanl.gov>

dave, can you diff cvs-current against your known-good july linuxbios?

This sounds like a memory setup problem.

ron



From firstone5 at hotmail.com  Mon Mar  8 22:09:01 2004
From: firstone5 at hotmail.com (first last)
Date: Mon Mar  8 22:09:01 2004
Subject: NXTV's current linuxbios patch [PMX:#]
Message-ID: <BAY10-F978a1fYt6rnm00011fc0@hotmail.com>

This is the latest cvs co of freebios on epia-m with one 256MB DDR RAM 
(128MB
hangs).  This uses vgabios.bin, filo payload, and boots into kernel OK.  
Note that
VGA BIOS is not turned on/ detected.  In a few cases, upon hot swaping flash 
after
boot of older freebios, soft boot will yield VGA, but will disappear upon 
hard reset.


snip<>

rite config byte bus 0, devfn 0x88, reg 0x50, val 0x81
Write config byte bus 0, devfn 0x80, reg 0x4, val 0x7
Write config byte bus 0, devfn 0x81, reg 0x4, val 0x7
Write config byte bus 0, devfn 0x82, reg 0x4, val 0x7
Write config byte bus 0, devfn 0x0, reg 0x61, val 0xff
Write config byte bus 0, devfn 0x0, reg 0xac, val 0x2f
Write config byte bus 0, devfn 0x0, reg 0xae, val 0x4
INSTALL REAL-MODE IDT
DO THE VGA BIOS
NO VGA FOUND
Checking IRQ routing tables...
/usr/src/OMS/cvs030804a/freebios/src/arch/i386/lib/pirq_routing.c:    
30:check_0
done.
Copying IRQ routing tables to 0xf0000...done.
Verifing priq routing tables copy at 0xf0000...failed
Wrote linuxbios table at: 00000500 - 00000660  checksum e140

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

    37:init_bytes() - zkernel_start:0xfffc0000  zkernel_mask:0x0000ffff
Found ELF candiate at offset 0
header_offset is 0
Try to load at offset 0x0
malloc Enter, size 32, free_mem_ptr 00012db0
malloc 0x00012db0
New segment addr 0x100000 size 0x26400 offset 0xc0 filesize 0xc368
(cleaned up) New segment addr 0x100000 size 0x26400 offset 0xc0 filesize 
0xc368
lb: [0x0000000000004000, 0x00000000000524ec)
malloc Enter, size 32, free_mem_ptr 00012dd0
malloc 0x00012dd0
New segment addr 0x126400 size 0x48 offset 0xc440 filesize 0x48
(cleaned up) New segment addr 0x126400 size 0x48 offset 0xc440 filesize 0x48
lb: [0x0000000000004000, 0x00000000000524ec)
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000026400 filesz: 
0x08
[ 0x0000000000100000, 000000000010c368, 0x0000000000126400) <- 
00000000000000c0
Clearing Segment: addr: 0x000000000010c368 memsz: 0x000000000001a098
Loading Segment: addr: 0x0000000000126400 memsz: 0x0000000000000048 filesz: 
0x08
[ 0x0000000000126400, 0000000000126448, 0x0000000000126448) <- 
000000000000c440
Loaded segments
verified segments
closed down stream
Jumping to boot code at 0x108c54
entry    = 0x00108c54
lb_start = 0x00004000
lb_size  = 0x0004e4ec
adjust   = 0x07eadb14
buffer   = 0x07e63628
     elf_boot_notes = 0x0000c2e0
adjusted_boot_notes = 0x07eb9df4
FILO version 0.4.1 (root at localhost) Mon Mar 15 23:02:20 EST 2004
collect_sys_info: boot eax = 0xe1fb007
collect_sys_info: boot ebx = 0x7eb9df4
collect_sys_info: boot arg = 0x7eb9df4
malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks)
malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks)
collect_elfboot_info: Bootloader: elfboot
collect_elfboot_info: Version: 1.2
malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks)
collect_linuxbios_info: Searching for LinuxBIOS tables...
find_lb_table: Found canidate at: 00000500
find_lb_table: header checksum o.k.
find_lb_table: table checksum o.k.
find_lb_table: record count o.k.
collect_linuxbios_info: Found LinuxBIOS table at: 00000500
malloc_diag: alloc: 96 bytes (3 blocks), free: 16280 bytes (1 blocks)
convert_memmap: 0x00000000000000 0x000000000006c4 16
convert_memmap: 0x000000000006c4 0x0000000009f93c 1
convert_memmap: 0x00000000100000 0x00000007e00000 1
collect_sys_info: 00000000000006c4-00000000000a0000
collect_sys_info: 0000000000100000-0000000007f00000
collect_sys_info: RAM 127 MB
relocate: Current location: 0x100000-0x126447
relocate: Relocating to 0x7ed9bb0-0x7effff7... ok
setup_timers: CPU 600 MHz
pci_init: Scanning PCI: found 11 devices
malloc_diag: alloc: 240 bytes (4 blocks), free: 16136 bytes (1 blocks)
pci_init: 00:00.0 1106:3123 0600 00
pci_init: 00:01.0 1106:b091 0604 00
pci_init: 00:0d.0 1106:3044 0c00 10
pci_init: 00:10.0 1106:3038 0c03 00
pci_init: 00:10.1 1106:3038 0c03 00
pci_init: 00:10.2 1106:3038 0c03 00
pci_init: 00:10.3 1106:3104 0c03 20
pci_init: 00:11.0 1106:3177 0601 00
pci_init: 00:11.1 1106:0571 0101 8a
pci_init: 00:11.5 1106:3059 0401 00
pci_init: 00:12.0 1106:3065 0200 00
boot: hdc1:/boot/fvmlinuz  root=/dev/hdc1 devfs=mount hda=ide-scsi acpi=ht
malloc_diag: alloc: 320 bytes (5 blocks), free: 16056 bytes (1 blocks)
malloc_diag: alloc: 336 bytes (6 blocks), free: 16040 bytes (1 blocks)
file_open: dev=hdc1, path=/boot/fvmlinuz
find_ide_controller: found PCI IDE controller 1106:0571 prog_if=0x8a
find_ide_controller: secodary channel: compatibility mode
find_ide_controller: cmd_base=0x170 ctrl_base=0x374
ide_software_reset: Waiting for ide1 to become ready for reset... ok
init_drive: Testing for hdc
init_drive: Probing for hdc
init_drive: LBA mode, sectors=160086528
init_drive: Init device params... ok
hdc: LBA 81GB: Maxtor 98196H8
devopen: Partition 1 start 63 length 12287457
Mounted reiserfs
malloc_diag: alloc: 320 bytes (5 blocks), free: 16056 bytes (1 blocks)
elf_load: Not a bootable ELF image
malloc_diag: alloc: 336 bytes (6 blocks), free: 16040 bytes (1 blocks)
file_open: dev=hdc1, path=/boot/fvmlinuz
devopen: already open
malloc_diag: alloc: 320 bytes (5 blocks), free: 16056 bytes (1 blocks)
Found Linux version 2.4.25 (root at localhost) #11 Sat Mar 6 02:57:2.
init_linux_params: Setting up paramters at 0x90000
set_memory_size: 00000000000006c4 - 00000000000a0000
set_memory_size: 0000000000100000 - 0000000007f00000
set_memory_size: ramtop=0x7f00000
set_memory_size: ext_mem_k=64512, alt_mem_k=129024
parse_command_line: original command line: " root=/dev/hdc1 devfs=mount 
hda=ide"
parse_command_line: kernel command line at 0x91000
parse_command_line: kernel command line (47 bytes): "root=/dev/hdc1 
devfs=mount"
load_linux_kernel: offset=0x1600 addr=0x100000 size=0x1057b2
Loading kernel... ok
start_linux: eip=0x100000
Jumping to entry point...



>From: ron minnich <rminnich at lanl.gov>
>To: Dave Ashley <linuxbios at xdr.com>
>CC: linuxbios at clustermatic.org
>Subject: Re: NXTV's current linuxbios patch [PMX:#]
>Date: Mon, 8 Mar 2004 20:05:29 -0700 (MST)
>
>dave, can you diff cvs-current against your known-good july linuxbios?
>
>This sounds like a memory setup problem.
>
>ron
>
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios

_________________________________________________________________
One-click access to Hotmail from any Web page ? download MSN Toolbar now! 
http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/



From ebiederman at lnxi.com  Mon Mar  8 23:18:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar  8 23:18:01 2004
Subject: pci_scan_get_dev() in pci_scan_bus()
In-Reply-To: <1078762987.10012.141.camel@exponential.lanl.gov>
References: <1078186620.10012.108.camel@exponential.lanl.gov>
	<m3brne962y.fsf@maxwell.lnxi.com>
	<1078528207.10012.138.camel@exponential.lanl.gov>
	<m3znaulumy.fsf@maxwell.lnxi.com>
	<1078762987.10012.141.camel@exponential.lanl.gov>
Message-ID: <m3r7w2hbls.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Fri, 2004-03-05 at 16:52, Eric W. Biederman wrote:
> > Li-Ta Lo <ollie at lanl.gov> writes:
> > 
> > > What happen if a device is listed as a static device in the
> > > config file but does not actually exist in the physical system ?
> > 
> > The device won't go away.  But it can legitimately show up as
> > a disabled device in the device tree.
> > 
> > I'm not certain when you would want to report a device statically
> > that may or may not be there.
> > 
> 
> That happens for the processor. We list two cpus in current k8 mainboard
> config files. But if there is only one cpu install, we will have a lot
> of "absent" devices.

Well we will have an absent bus.  But everything should work properly.
It would not hurt to test it and make certain though.  It works in principle,
and should be easy to fix if the practice does not match.

Eric


From ebiederman at lnxi.com  Tue Mar  9 00:42:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Mar  9 00:42:01 2004
Subject: Video initialization, and bootloaders...
Message-ID: <m3k71uh7pt.fsf@maxwell.lnxi.com>

Thinking out loud again...

The basic requirement of the BIOS core is to place the hardware in 
in legacy compatibility mode, which all OS software expect to find
the system in.  This really includes setting up a VGA compatible
adapter if it is present.

So if the emulator is small and a compile time option I don't have a
problem with putting it in LinuxBIOS exclusively for early video
initialization of plug in video cards.  Running code through emulation
is likely to give us the most predictable results of boards working
across different systems, especially non-x86 hardware.


From ebiederman at lnxi.com  Tue Mar  9 01:09:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Mar  9 01:09:00 2004
Subject: BCC...
Message-ID: <m3fzcih6h8.fsf@maxwell.lnxi.com>

The PCBIOS compatibility code in rombios.c has quite a few warts.
Primary among them is that it written in a nasty mix of asm and 16bit
C code.  With the biggest problem seeming to be that bcc is a limited
16bit compiler.  

In real mode there is 256K that we can place a real mode BIOS in.  If
all we do is stick to what a PCBIOS can do now, and don't attempt
to extend it, but just be a good implementation 256K should be enough
to do whatever is needed.

I don't know if gcc using 32bit overrides in 16bit mode would be
better than a pure 16bit C compiler.  

Just looking at rombios.c earlier today the worst of it appears to be
that rombios.c is a nasty mess, and that rombios.c does not support
pci.  So most of it to me does not appear to be a compiler issue at
all, just that rombios.c needs to be rewritten in a more maintainable
style.

I need to look a little more closely but I suspect getting bcc to
accept a fairly complete gcc syntax including inline asm support would
not be hard.  Nor do I think getting bcc to output to gas assembly
instead of it's own assembler would be to bad.  Except possibly
that gas 16bit support is quite limited.  

So if the issues keeping us from using 16bit C compiler are primarily
cosmetic I don't see why they can't be fixed.  Long term I don't even
want to touch a compatibility layer.  I want to use something much
simpler and much more powerful.  

Eric


From rminnich at lanl.gov  Tue Mar  9 01:11:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar  9 01:11:00 2004
Subject: Video initialization, and bootloaders...
In-Reply-To: <m3k71uh7pt.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403082329340.26947-100000@maxroach.lanl.gov>

On 8 Mar 2004, Eric W. Biederman wrote:

> An important thing to verify here is that the standard cpu
> identification steps will show the emulated cpu to be a 386 or whatever
> minimal processor we support.  And we should tightly restrict the
> emulated codes access to memory, presenting it with a virtual not a real
> view of what is going on.  Keeping the code chained as much as possible.

That is pretty much what we are doing now. We will be plugging the 
emulator into linuxbios, Ollie is working out the design. 

> I think the simplest path to a flexible LinuxBIOS solution is to have a
> native LinuxBIOS loader like etherboot, the Linux kernel or possibly
> something much simpler act as a switch between the different
> personalities we can wear, PCBIOS openfirmware, efi, arc, etc.  And we
> will boot with whichever one the user selects.

I'm currenly liking FILO or the linux kernel the best. 

> Using a bootloader as a switch to select among the others is the only
> easy way I can see to have my cake and it too with supporting multiple
> personalities.  You get only one at a time but I think that is easier to
> verify.

we'll see how it goes...

ron



From rminnich at lanl.gov  Tue Mar  9 01:14:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar  9 01:14:01 2004
Subject: BCC...
In-Reply-To: <m3fzcih6h8.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403082333230.26947-100000@maxroach.lanl.gov>

On 8 Mar 2004, Eric W. Biederman wrote:

> 
> The PCBIOS compatibility code in rombios.c has quite a few warts.
> Primary among them is that it written in a nasty mix of asm and 16bit C
> code.  With the biggest problem seeming to be that bcc is a limited
> 16bit compiler.

I don't much like this code. 

> In real mode there is 256K that we can place a real mode BIOS in.  If
> all we do is stick to what a PCBIOS can do now, and don't attempt to
> extend it, but just be a good implementation 256K should be enough to do
> whatever is needed.

we're back to square one. Why do this when we can do emulation? I think I 
don't see what you're planning here.

> I don't know if gcc using 32bit overrides in 16bit mode would be
> better than a pure 16bit C compiler.  

one less compiler is always good to me.

> So if the issues keeping us from using 16bit C compiler are primarily
> cosmetic I don't see why they can't be fixed.  Long term I don't even
> want to touch a compatibility layer.  I want to use something much
> simpler and much more powerful.

I don't see the reason long term for rombios.c or 16bit C compilers. I 
guess I'm missing something.

ron



From rminnich at lanl.gov  Tue Mar  9 01:18:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar  9 01:18:00 2004
Subject: 8111 question answered. 
Message-ID: <Pine.LNX.4.44.0403082335480.26947-100000@maxroach.lanl.gov>

I just plain forget that the SMBUS subsystem is system management 
interface, not the smbus controller interface. Never mind that question.

ron



From ebiederman at lnxi.com  Tue Mar  9 01:31:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Mar  9 01:31:01 2004
Subject: BCC...
In-Reply-To: <Pine.LNX.4.44.0403082333230.26947-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403082333230.26947-100000@maxroach.lanl.gov>
Message-ID: <m3llmaa4m8.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 8 Mar 2004, Eric W. Biederman wrote:
> 
> > 
> > The PCBIOS compatibility code in rombios.c has quite a few warts.
> > Primary among them is that it written in a nasty mix of asm and 16bit C
> > code.  With the biggest problem seeming to be that bcc is a limited
> > 16bit compiler.
> 
> I don't much like this code. 
> 
> > In real mode there is 256K that we can place a real mode BIOS in.  If
> > all we do is stick to what a PCBIOS can do now, and don't attempt to
> > extend it, but just be a good implementation 256K should be enough to do
> > whatever is needed.
> 
> we're back to square one. Why do this when we can do emulation? I think I 
> don't see what you're planning here.

Not for video support.  This is for actually running freedos, freebsd,
and netbsd and windows etc.  All of those unconverted operating
systems.
 
> > I don't know if gcc using 32bit overrides in 16bit mode would be
> > better than a pure 16bit C compiler.  
> 
> one less compiler is always good to me.

Maybe.  It certainly simplifies the tool chain if you can do it.
 
> > So if the issues keeping us from using 16bit C compiler are primarily
> > cosmetic I don't see why they can't be fixed.  Long term I don't even
> > want to touch a compatibility layer.  I want to use something much
> > simpler and much more powerful.
> 
> I don't see the reason long term for rombios.c or 16bit C compilers. I 
> guess I'm missing something.

rombios.c or whatever the PCBIOS compatibility layer winds up being
must be 16bit code, (even if it has 32bit extensions all over the
place).  I'm not certain gcc can be convinced to do a reasonable job
of 16bit C code.

So I guess the first attempt at cleaning up rombios.c should do it
with gcc. 32bit code with 16bit prefixes.  If that does not work we
can get bcc out of the closet and make it usable.

COTS hardware is there and is valued because it does not impose
conversion time tables on software.  This needs to apply to the
firmware as well.  So for the short term we need it.

In the long term we can simply drop that compatibility layer.  But
at the same time we need to spec an interface that distribution makes
can use to make bootable media.  Something we can be certain of
providing on all ports that aim to support general purpose software.

Eric


From ebiederman at lnxi.com  Tue Mar  9 01:39:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Mar  9 01:39:00 2004
Subject: Video initialization, and bootloaders...
In-Reply-To: <Pine.LNX.4.44.0403082329340.26947-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403082329340.26947-100000@maxroach.lanl.gov>
Message-ID: <m3hdwya48n.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 8 Mar 2004, Eric W. Biederman wrote:
> 
> > An important thing to verify here is that the standard cpu
> > identification steps will show the emulated cpu to be a 386 or whatever
> > minimal processor we support.  And we should tightly restrict the
> > emulated codes access to memory, presenting it with a virtual not a real
> > view of what is going on.  Keeping the code chained as much as possible.
> 
> That is pretty much what we are doing now. We will be plugging the 
> emulator into linuxbios, Ollie is working out the design. 

Right.
 
> > I think the simplest path to a flexible LinuxBIOS solution is to have a
> > native LinuxBIOS loader like etherboot, the Linux kernel or possibly
> > something much simpler act as a switch between the different
> > personalities we can wear, PCBIOS openfirmware, efi, arc, etc.  And we
> > will boot with whichever one the user selects.
> 
> I'm currenly liking FILO or the linux kernel the best. 

The Linux kernel is my favored candidate as a general purpose bootloader.
FILO has it's uses especially for interactive use.  FILO at least at
the moment is not targeted at the behind the scenes long term stable
interfaces that let a bootloader fade into the background and be forgotten.

If we are going to have a native LinuxBIOS personality this is something
we need to consider agree to and write up.

> > Using a bootloader as a switch to select among the others is the only
> > easy way I can see to have my cake and it too with supporting multiple
> > personalities.  You get only one at a time but I think that is easier to
> > verify.
> 
> we'll see how it goes...

Yes.

Eric



From rminnich at lanl.gov  Tue Mar  9 09:50:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar  9 09:50:01 2004
Subject: BCC...
In-Reply-To: <m3llmaa4m8.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403090808370.30487-100000@maxroach.lanl.gov>

On 8 Mar 2004, Eric W. Biederman wrote:

> Not for video support.  This is for actually running freedos, freebsd,
> and netbsd and windows etc.  All of those unconverted operating
> systems.

ok. I'll leave windows to you :)

> rombios.c or whatever the PCBIOS compatibility layer winds up being must
> be 16bit code, (even if it has 32bit extensions all over the place).  
> I'm not certain gcc can be convinced to do a reasonable job of 16bit C
> code.

what's wrong with what we did for vga extensions, a 16-bit hook into 
32-bit code? It has worked well for those who wanted native vga.

ron




From rminnich at lanl.gov  Tue Mar  9 09:51:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar  9 09:51:01 2004
Subject: Video initialization, and bootloaders...
In-Reply-To: <m3hdwya48n.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403090810420.30487-100000@maxroach.lanl.gov>

On 9 Mar 2004, Eric W. Biederman wrote:

> The Linux kernel is my favored candidate as a general purpose bootloader.

yes, assuming it fits. We didn't call it linuxbios for no reason: the plan
has always been to use linux. We got forced into other options for space
reasons at first.

The attraction of FILO is that it lets users, today, boot an install CDROM 
and load up a system.

ron




From firstone5 at hotmail.com  Tue Mar  9 10:23:00 2004
From: firstone5 at hotmail.com (first last)
Date: Tue Mar  9 10:23:00 2004
Subject: FW: Re: NXTV's current linuxbios patch [PMX:#]
Message-ID: <BAY10-F120fAFeURtvE00010231@hotmail.com>

Note: this was not successful for VGA

>>This is the latest cvs co of freebios on epia-m with one 256MB DDR RAM 
>>(128MB
>>hangs).  This uses vgabios.bin, filo payload, and boots into kernel OK.  
>>Note that
>>VGA BIOS is not turned on/ detected.  In a few cases, upon hot swaping 
>>flash after
>>boot of older freebios, soft boot will yield VGA, but will disappear upon 
>>hard reset.
>>
>>
>>snip<>
>>
>>rite config byte bus 0, devfn 0x88, reg 0x50, val 0x81
>>Write config byte bus 0, devfn 0x80, reg 0x4, val 0x7
>>Write config byte bus 0, devfn 0x81, reg 0x4, val 0x7
>>Write config byte bus 0, devfn 0x82, reg 0x4, val 0x7
>>Write config byte bus 0, devfn 0x0, reg 0x61, val 0xff
>>Write config byte bus 0, devfn 0x0, reg 0xac, val 0x2f
>>Write config byte bus 0, devfn 0x0, reg 0xae, val 0x4
>>INSTALL REAL-MODE IDT
>>DO THE VGA BIOS
>>NO VGA FOUND
>>Checking IRQ routing tables...
>>/usr/src/OMS/cvs030804a/freebios/src/arch/i386/lib/pirq_routing.c:    
>>30:check_0
>>done.
>>Copying IRQ routing tables to 0xf0000...done.
>>Verifing priq routing tables copy at 0xf0000...failed
>>Wrote linuxbios table at: 00000500 - 00000660  checksum e140
>>
>>Welcome to elfboot, the open sourced starter.
>>January 2002, Eric Biederman.
>>Version 1.2
>>
>>    37:init_bytes() - zkernel_start:0xfffc0000  zkernel_mask:0x0000ffff
>>Found ELF candiate at offset 0
>>header_offset is 0
>>Try to load at offset 0x0
>>malloc Enter, size 32, free_mem_ptr 00012db0
>>malloc 0x00012db0
>>New segment addr 0x100000 size 0x26400 offset 0xc0 filesize 0xc368
>>(cleaned up) New segment addr 0x100000 size 0x26400 offset 0xc0 filesize 
>>0xc368
>>lb: [0x0000000000004000, 0x00000000000524ec)
>>malloc Enter, size 32, free_mem_ptr 00012dd0
>>malloc 0x00012dd0
>>New segment addr 0x126400 size 0x48 offset 0xc440 filesize 0x48
>>(cleaned up) New segment addr 0x126400 size 0x48 offset 0xc440 filesize 
>>0x48
>>lb: [0x0000000000004000, 0x00000000000524ec)
>>Dropping non PT_LOAD segment
>>Dropping non PT_LOAD segment
>>Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000026400 
>>filesz: 0x08
>>[ 0x0000000000100000, 000000000010c368, 0x0000000000126400) <- 
>>00000000000000c0
>>Clearing Segment: addr: 0x000000000010c368 memsz: 0x000000000001a098
>>Loading Segment: addr: 0x0000000000126400 memsz: 0x0000000000000048 
>>filesz: 0x08
>>[ 0x0000000000126400, 0000000000126448, 0x0000000000126448) <- 
>>000000000000c440
>>Loaded segments
>>verified segments
>>closed down stream
>>Jumping to boot code at 0x108c54
>>entry    = 0x00108c54
>>lb_start = 0x00004000
>>lb_size  = 0x0004e4ec
>>adjust   = 0x07eadb14
>>buffer   = 0x07e63628
>>     elf_boot_notes = 0x0000c2e0
>>adjusted_boot_notes = 0x07eb9df4
>>FILO version 0.4.1 (root at localhost) Mon Mar 15 23:02:20 EST 2004
>>collect_sys_info: boot eax = 0xe1fb007
>>collect_sys_info: boot ebx = 0x7eb9df4
>>collect_sys_info: boot arg = 0x7eb9df4
>>malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks)
>>malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks)
>>collect_elfboot_info: Bootloader: elfboot
>>collect_elfboot_info: Version: 1.2
>>malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks)
>>collect_linuxbios_info: Searching for LinuxBIOS tables...
>>find_lb_table: Found canidate at: 00000500
>>find_lb_table: header checksum o.k.
>>find_lb_table: table checksum o.k.
>>find_lb_table: record count o.k.
>>collect_linuxbios_info: Found LinuxBIOS table at: 00000500
>>malloc_diag: alloc: 96 bytes (3 blocks), free: 16280 bytes (1 blocks)
>>convert_memmap: 0x00000000000000 0x000000000006c4 16
>>convert_memmap: 0x000000000006c4 0x0000000009f93c 1
>>convert_memmap: 0x00000000100000 0x00000007e00000 1
>>collect_sys_info: 00000000000006c4-00000000000a0000
>>collect_sys_info: 0000000000100000-0000000007f00000
>>collect_sys_info: RAM 127 MB
>>relocate: Current location: 0x100000-0x126447
>>relocate: Relocating to 0x7ed9bb0-0x7effff7... ok
>>setup_timers: CPU 600 MHz
>>pci_init: Scanning PCI: found 11 devices
>>malloc_diag: alloc: 240 bytes (4 blocks), free: 16136 bytes (1 blocks)
>>pci_init: 00:00.0 1106:3123 0600 00
>>pci_init: 00:01.0 1106:b091 0604 00
>>pci_init: 00:0d.0 1106:3044 0c00 10
>>pci_init: 00:10.0 1106:3038 0c03 00
>>pci_init: 00:10.1 1106:3038 0c03 00
>>pci_init: 00:10.2 1106:3038 0c03 00
>>pci_init: 00:10.3 1106:3104 0c03 20
>>pci_init: 00:11.0 1106:3177 0601 00
>>pci_init: 00:11.1 1106:0571 0101 8a
>>pci_init: 00:11.5 1106:3059 0401 00
>>pci_init: 00:12.0 1106:3065 0200 00
>>boot: hdc1:/boot/fvmlinuz  root=/dev/hdc1 devfs=mount hda=ide-scsi acpi=ht
>>malloc_diag: alloc: 320 bytes (5 blocks), free: 16056 bytes (1 blocks)
>>malloc_diag: alloc: 336 bytes (6 blocks), free: 16040 bytes (1 blocks)
>>file_open: dev=hdc1, path=/boot/fvmlinuz
>>find_ide_controller: found PCI IDE controller 1106:0571 prog_if=0x8a
>>find_ide_controller: secodary channel: compatibility mode
>>find_ide_controller: cmd_base=0x170 ctrl_base=0x374
>>ide_software_reset: Waiting for ide1 to become ready for reset... ok
>>init_drive: Testing for hdc
>>init_drive: Probing for hdc
>>init_drive: LBA mode, sectors=160086528
>>init_drive: Init device params... ok
>>hdc: LBA 81GB: Maxtor 98196H8
>>devopen: Partition 1 start 63 length 12287457
>>Mounted reiserfs
>>malloc_diag: alloc: 320 bytes (5 blocks), free: 16056 bytes (1 blocks)
>>elf_load: Not a bootable ELF image
>>malloc_diag: alloc: 336 bytes (6 blocks), free: 16040 bytes (1 blocks)
>>file_open: dev=hdc1, path=/boot/fvmlinuz
>>devopen: already open
>>malloc_diag: alloc: 320 bytes (5 blocks), free: 16056 bytes (1 blocks)
>>Found Linux version 2.4.25 (root at localhost) #11 Sat Mar 6 02:57:2.
>>init_linux_params: Setting up paramters at 0x90000
>>set_memory_size: 00000000000006c4 - 00000000000a0000
>>set_memory_size: 0000000000100000 - 0000000007f00000
>>set_memory_size: ramtop=0x7f00000
>>set_memory_size: ext_mem_k=64512, alt_mem_k=129024
>>parse_command_line: original command line: " root=/dev/hdc1 devfs=mount 
>>hda=ide"
>>parse_command_line: kernel command line at 0x91000
>>parse_command_line: kernel command line (47 bytes): "root=/dev/hdc1 
>>devfs=mount"
>>load_linux_kernel: offset=0x1600 addr=0x100000 size=0x1057b2
>>Loading kernel... ok
>>start_linux: eip=0x100000
>>Jumping to entry point...
>>
>>
>>
>>>From: ron minnich <rminnich at lanl.gov>
>>>To: Dave Ashley <linuxbios at xdr.com>
>>>CC: linuxbios at clustermatic.org
>>>Subject: Re: NXTV's current linuxbios patch [PMX:#]
>>>Date: Mon, 8 Mar 2004 20:05:29 -0700 (MST)
>>>
>>>dave, can you diff cvs-current against your known-good july linuxbios?
>>>
>>>This sounds like a memory setup problem.
>>>
>>>ron
>>>
>>>_______________________________________________
>>>Linuxbios mailing list
>>>Linuxbios at clustermatic.org
>>>http://www.clustermatic.org/mailman/listinfo/linuxbios
>>
>>_________________________________________________________________
>>One-click access to Hotmail from any Web page ? download MSN Toolbar now! 
>>http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/
>>
>>_______________________________________________
>>Linuxbios mailing list
>>Linuxbios at clustermatic.org
>>http://www.clustermatic.org/mailman/listinfo/linuxbios
>

_________________________________________________________________
Frustrated with dial-up? Lightning-fast Internet access for as low as 
$29.95/month. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/



From ollie at lanl.gov  Tue Mar  9 12:00:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Mar  9 12:00:01 2004
Subject: pci_scan_get_dev() in pci_scan_bus()
In-Reply-To: <m3r7w2hbls.fsf@maxwell.lnxi.com>
References: <1078186620.10012.108.camel@exponential.lanl.gov>
	 <m3brne962y.fsf@maxwell.lnxi.com>
	 <1078528207.10012.138.camel@exponential.lanl.gov>
	 <m3znaulumy.fsf@maxwell.lnxi.com>
	 <1078762987.10012.141.camel@exponential.lanl.gov>
	 <m3r7w2hbls.fsf@maxwell.lnxi.com>
Message-ID: <1078852827.10012.158.camel@exponential.lanl.gov>

On Mon, 2004-03-08 at 21:45, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > On Fri, 2004-03-05 at 16:52, Eric W. Biederman wrote:
> > > Li-Ta Lo <ollie at lanl.gov> writes:
> > > 
> > > > What happen if a device is listed as a static device in the
> > > > config file but does not actually exist in the physical system ?
> > > 
> > > The device won't go away.  But it can legitimately show up as
> > > a disabled device in the device tree.
> > > 
> > > I'm not certain when you would want to report a device statically
> > > that may or may not be there.
> > > 
> > 
> > That happens for the processor. We list two cpus in current k8 mainboard
> > config files. But if there is only one cpu install, we will have a lot
> > of "absent" devices.
> 
> Well we will have an absent bus.  But everything should work properly.
> It would not hurt to test it and make certain though.  It works in principle,
> and should be easy to fix if the practice does not match.
> 

On thing I am worry about is there are some code calling the "device 
driver" no matter if the device really exist. One example is the
pci_scan_bus() which calls the enable_dev() when it found the device
on the list of "static->dynamic" devices. What if the enable_dev() does
something nasty and lock the machine ?

Ollie




From awinner at walkabout-comp.com  Tue Mar  9 13:37:00 2004
From: awinner at walkabout-comp.com (Anthony Winner)
Date: Tue Mar  9 13:37:00 2004
Subject: OEM looking at LinuxBIOS
Message-ID: <001d01c40609$953dbca0$3b0201c0@hhengineering.local>

Hello all,

I work for a OEM and I'm playing with the idea of using linuxBIOS, I have
all of the technical info for the machine short of the actual source code to
the Phoenix BIOS we use now as it was done by a contractor before I joined
the company.

Are there any pointers for a 'from scratch', implementation?

Should I start with the old code or start fresh from the new freebios2 tree?

For reference, the machine is a Intel PIII with a 82830 Northbridge, a
82801ca Southbridge, TI pci1450 card bus controller, and a pair of SMC SIO
chips....

Anthony Winner
WalkAbout Computers
awinner at walkabout-comp.com
(561)712-1200  x221




From dwh at lanl.gov  Tue Mar  9 14:13:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Tue Mar  9 14:13:00 2004
Subject: OEM looking at LinuxBIOS
In-Reply-To: <001d01c40609$953dbca0$3b0201c0@hhengineering.local>
Message-ID: <Pine.LNX.4.44.0403091224340.26401-100000@ccs-mail.lanl.gov>

There is already 82803 and 82801ca code in the freebios1 tree, might as 
well put it to good use :) I think Eric Beiderman was even able to fix 
SPD, at least on the MCH4 (Or something).

On Tue, 9 Mar 2004, Anthony Winner wrote:

> Hello all,
> 
> I work for a OEM and I'm playing with the idea of using linuxBIOS, I have
> all of the technical info for the machine short of the actual source code to
> the Phoenix BIOS we use now as it was done by a contractor before I joined
> the company.
> 
> Are there any pointers for a 'from scratch', implementation?
> 
> Should I start with the old code or start fresh from the new freebios2 tree?
> 
> For reference, the machine is a Intel PIII with a 82830 Northbridge, a
> 82801ca Southbridge, TI pci1450 card bus controller, and a pair of SMC SIO
> chips....
> 
> Anthony Winner
> WalkAbout Computers
> awinner at walkabout-comp.com
> (561)712-1200  x221
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From ollie at lanl.gov  Tue Mar  9 16:59:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Mar  9 16:59:01 2004
Subject: Prefmem of bus 3
In-Reply-To: <m3ekscffaf.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0402271225280.31881-100000@maxroach.lanl.gov>
	 <m3ptbwh09b.fsf@maxwell.lnxi.com>
	 <1078167428.10012.95.camel@exponential.lanl.gov>
	 <m3ekscffaf.fsf@maxwell.lnxi.com>
Message-ID: <1078870760.10012.164.camel@exponential.lanl.gov>

On Mon, 2004-03-01 at 14:06, Eric W. Biederman wrote:
> 
> There are many was to assign resources on a bus.  After some
> experiences with tight memory situations I implemented a near optimal
> solution.  The solution is optimal if all of your resources are a
> power of 2 in size.
> 
> Basically the code is a loop.  For each iteration the
> code finds the largest unassigned resource.  Then the resource
> constraints of that resource are considered and padding between
> the previous resources and the current resources are inserted if
> necessary.  Then we get into the next iteration.
> 

I still don't understand this. Do you mean that now the resource
allocation is not sequential (in the order of devices been enumerated) 
and not continuous (there are gaps in allocated address) ?

Ollie

> The reason this is optimal if all of your resources are a power of
> two in size is because if your previous resource is a larger or equal
> power of two no padding will be needed for the current resource.
> 




From ebiederman at lnxi.com  Tue Mar  9 17:59:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Mar  9 17:59:01 2004
Subject: Prefmem of bus 3
In-Reply-To: <1078870760.10012.164.camel@exponential.lanl.gov>
References: <Pine.LNX.4.44.0402271225280.31881-100000@maxroach.lanl.gov>
	<m3ptbwh09b.fsf@maxwell.lnxi.com>
	<1078167428.10012.95.camel@exponential.lanl.gov>
	<m3ekscffaf.fsf@maxwell.lnxi.com>
	<1078870760.10012.164.camel@exponential.lanl.gov>
Message-ID: <m3znap61pw.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Mon, 2004-03-01 at 14:06, Eric W. Biederman wrote:
> > 
> > There are many was to assign resources on a bus.  After some
> > experiences with tight memory situations I implemented a near optimal
> > solution.  The solution is optimal if all of your resources are a
> > power of 2 in size.
> > 
> > Basically the code is a loop.  For each iteration the
> > code finds the largest unassigned resource.  Then the resource
> > constraints of that resource are considered and padding between
> > the previous resources and the current resources are inserted if
> > necessary.  Then we get into the next iteration.
> > 
> 
> I still don't understand this. Do you mean that now the resource
> allocation is not sequential (in the order of devices been enumerated) 
> and not continuous (there are gaps in allocated address) ?

Correct.   

The reason the allocation is not sequential (in the order of devices
been enumerated) is to reduce the number of gaps in the allocated
addresses.

So a thought problem to help put this in perspective.

First all resources are a power of 2 in size must be that same
power of 2 aligned.

So if I have 3 resources A,B,C with the following sizes:

A: 8K
B: 256M
C: 4K

Allocating them sequentially would use 756M of address space.
After allocating A you need nearly 256M of padding to get B 256M
aligned.  C takes nearly 256M due to padding.

Allocating them largest to smallest (B,A,C) uses just 512M of address
space.  Because the alignment necessary for A is present at the end
of B, and the alignment necessary for A is present at the end of C.


Eric

> 
> > The reason this is optimal if all of your resources are a power of
> > two in size is because if your previous resource is a larger or equal
> > power of two no padding will be needed for the current resource.
> > 


From YhLu at tyan.com  Tue Mar  9 22:48:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Mar  9 22:48:01 2004
Subject: Prefmem of bus 3
Message-ID: <3174569B9743D511922F00A0C94314230466CFDD@TYANWEB>

Eric,

I print out the allocating spew and found the align calculation seems not
correct.

PCI: 01:02.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
PCI: 03:03.0 10 *  [0x00000000 - 0x0fffffff] prefmem
PCI: 03:03.0 18 *  [0x10000000 - 0x13ffffff] prefmem
<null> compute_allocate_prefmem: base: 14000000 size: 14000000 align: 28
gran: 20 done

When computing limit in pci_set_device of pci_device.c, only using align.
So will produce limit=0xffffffff, instead of 0xf3ffffff.

So maybe need to using gran together with align and base to calculate the
limit.

Regards

YH



Allocating resources...
Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0
gran: 0
PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
PCI: 01:01.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
PCI: 02:0a.0 10 *  [0x00000000 - 0x000000ff] io
PCI: 02:0a.1 10 *  [0x00000400 - 0x000004ff] io
<null> compute_allocate_io: base: 00000500 size: 00001000 align: 12 gran: 12
done
PCI: 01:01.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
<null> compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20
gran: 20 done
PCI: 01:01.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
PCI: 02:09.0 10 *  [0x00000000 - 0x0000ffff] mem
PCI: 02:09.0 18 *  [0x00010000 - 0x0001ffff] mem
PCI: 02:09.1 10 *  [0x00020000 - 0x0002ffff] mem
PCI: 02:09.1 18 *  [0x00030000 - 0x0003ffff] mem
PCI: 02:0a.0 14 *  [0x00040000 - 0x0004ffff] mem
PCI: 02:0a.0 1c *  [0x00050000 - 0x0005ffff] mem
PCI: 02:0a.1 14 *  [0x00060000 - 0x0006ffff] mem
PCI: 02:0a.1 1c *  [0x00070000 - 0x0007ffff] mem
<null> compute_allocate_mem: base: 00080000 size: 00100000 align: 20 gran:
20 done
PCI: 01:02.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
<null> compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12
done
PCI: 01:02.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
PCI: 03:03.0 10 *  [0x00000000 - 0x0fffffff] prefmem
PCI: 03:03.0 18 *  [0x10000000 - 0x13ffffff] prefmem
<null> compute_allocate_prefmem: base: 14000000 size: 14000000 align: 28
gran: 20 done
PCI: 01:02.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
<null> compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran:
20 done
PCI: 01:03.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
PCI: 04:01.0 missing read_resources
PCI: 04:06.0 14 *  [0x00000000 - 0x000000ff] io
PCI: 04:05.0 18 *  [0x00000400 - 0x0000047f] io
PCI: 04:05.0 10 *  [0x00000480 - 0x000004bf] io
PCI: 04:05.0 14 *  [0x000004c0 - 0x000004cf] io
<null> compute_allocate_io: base: 000004d0 size: 00001000 align: 12 gran: 12
done
PCI: 01:03.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
PCI: 04:01.0 missing read_resources
<null> compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20
gran: 20 done
PCI: 01:03.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
PCI: 04:01.0 missing read_resources
PCI: 04:06.0 10 *  [0x00000000 - 0x00ffffff] mem
PCI: 04:05.0 20 *  [0x01000000 - 0x0101ffff] mem
PCI: 04:00.0 10 *  [0x01020000 - 0x01020fff] mem
PCI: 04:00.1 10 *  [0x01021000 - 0x01021fff] mem
PCI: 04:05.0 1c *  [0x01022000 - 0x01022fff] mem
PCI: 04:06.0 18 *  [0x01023000 - 0x01023fff] mem
PCI: 04:00.2 10 *  [0x01024000 - 0x010240ff] mem
PCI: 04:00.2 14 *  [0x01025000 - 0x0102501f] mem
<null> compute_allocate_mem: base: 01025020 size: 01100000 align: 24 gran:
20 done
PCI: 01:04.5 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 01:01.0 1c *  [0x00000000 - 0x00000fff] io
PCI: 01:03.0 1c *  [0x00001000 - 0x00001fff] io
PCI: 01:02.0 1c *  [0x00002000 - 0x00001fff] io
PCI: 01:04.2 10 *  [0x00002000 - 0x0000201f] io
PCI: 01:04.1 20 *  [0x00002020 - 0x0000202f] io
<null> compute_allocate_io: base: 00002030 size: 00003000 align: 12 gran: 12
done
PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
PCI: 01:04.5 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 01:02.0 24 *  [0x00000000 - 0x13ffffff] prefmem
PCI: 01:03.0 20 *  [0x14000000 - 0x150fffff] mem
PCI: 01:01.0 20 *  [0x15100000 - 0x151fffff] mem
PCI: 01:01.0 24 *  [0x15200000 - 0x151fffff] prefmem
PCI: 01:02.0 20 *  [0x15200000 - 0x151fffff] mem
PCI: 01:03.0 24 *  [0x15200000 - 0x151fffff] prefmem
PCI: 01:01.1 10 *  [0x15200000 - 0x15200fff] mem
PCI: 01:02.1 10 *  [0x15201000 - 0x15201fff] mem
<null> compute_allocate_mem: base: 15202000 size: 15300000 align: 28 gran:
20 done
PCI: 00:18.0 c0 *  [0x00001000 - 0x00003fff] io
<null> compute_allocate_io: base: 00004000 size: 00003c00 align: 12 gran: 0
done
Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0
gran: 0
PCI: 00:18.0 b8 *  [0x00000000 - 0x152fffff] mem
<null> compute_allocate_mem: base: 15300000 size: 15300000 align: 28 gran: 0
done
Root Device compute_allocate_io: base: 00001000 size: 00003c00 align: 12
gran: 0
PCI: 00:18.0 c0 *  [0x00001000 - 0x00003fff] io
<null> compute_allocate_io: base: 00004000 size: 00003000 align: 12 gran: 0
done
Root Device compute_allocate_mem: base: e0000000 size: 15300000 align: 28
gran: 0
PCI: 00:18.0 b8 *  [0xe0000000 - 0xf52fffff] mem
<null> compute_allocate_mem: base: f5300000 size: 15300000 align: 28 gran: 0
done

-----????-----
???: YhLu 
????: 2004?3?1? 13:10
???: 'ebiederman at lnxi.com'; ron minnich
??: LinuxBIOS
??: ??: Prefmem of bus 3

Some time you said that arima board connect all PCI-X slots of amd 8131 irq
to amd 8111 ioapic intead of 8131.

So even disable ioapic of 8131, device on PCI-X still works properly.

After enable ioapic of 8131, devices that are not using prefmem works well.

YH.

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?1? 10:48
???: ron minnich
??: YhLu; ebiederman at lnxi.com; LinuxBIOS
??: Re: Prefmem of bus 3

ron minnich <rminnich at lanl.gov> writes:

> On Fri, 27 Feb 2004, YhLu wrote:
> 
> > Have you ever tested myrinet card on K8 MB under LinuxBIOS?
> 
> we have a 1408-node K8 machine with myrinet working under linuxbios, and a

> 256-node K8 machine working with linuxbios. Arima HDAMA mainboards.
> 
> I wonder what's going on here, I have not had time to look in detail.

So the problem appears to be that the prefmem region on the upper bus
is to large.

I wonder if why this work on LANL clusters and not on others is the
result of code skew.

Lightning nodes with myrinet only seem to have one prefmem region.

Yet another reminder that I really need to finish syncing up the code bases.

Eric


From YhLu at tyan.com  Tue Mar  9 22:50:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Mar  9 22:50:00 2004
Subject: =?GB2312?B?tPC4tDogUHJlZm1lbSBvZiBidXMgMw==?=
Message-ID: <3174569B9743D511922F00A0C94314230466CFDE@TYANWEB>

I mean

        /* Get the base address */
        base = resource->base;
        /* Get the resource alignment */
        align = 1UL << resource->align;

        /* Get the limit (rounded up) */
        limit = base + ((resource->size + align - 1UL) & ~(align - 1UL))
-1UL;

should be changed.

-----????-----
???: YhLu 
????: 2004?3?9? 20:14
???: YhLu; ebiederman at lnxi.com; ron minnich
??: LinuxBIOS
??: re: Prefmem of bus 3

Eric,

I print out the allocating spew and found the align calculation seems not
correct.

PCI: 01:02.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
PCI: 03:03.0 10 *  [0x00000000 - 0x0fffffff] prefmem
PCI: 03:03.0 18 *  [0x10000000 - 0x13ffffff] prefmem
<null> compute_allocate_prefmem: base: 14000000 size: 14000000 align: 28
gran: 20 done

When computing limit in pci_set_device of pci_device.c, only using align.
So will produce limit=0xffffffff, instead of 0xf3ffffff.

So maybe need to using gran together with align and base to calculate the
limit.

Regards

YH



Allocating resources...
Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0
gran: 0
PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
PCI: 01:01.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
PCI: 02:0a.0 10 *  [0x00000000 - 0x000000ff] io
PCI: 02:0a.1 10 *  [0x00000400 - 0x000004ff] io
<null> compute_allocate_io: base: 00000500 size: 00001000 align: 12 gran: 12
done
PCI: 01:01.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
<null> compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20
gran: 20 done
PCI: 01:01.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
PCI: 02:09.0 10 *  [0x00000000 - 0x0000ffff] mem
PCI: 02:09.0 18 *  [0x00010000 - 0x0001ffff] mem
PCI: 02:09.1 10 *  [0x00020000 - 0x0002ffff] mem
PCI: 02:09.1 18 *  [0x00030000 - 0x0003ffff] mem
PCI: 02:0a.0 14 *  [0x00040000 - 0x0004ffff] mem
PCI: 02:0a.0 1c *  [0x00050000 - 0x0005ffff] mem
PCI: 02:0a.1 14 *  [0x00060000 - 0x0006ffff] mem
PCI: 02:0a.1 1c *  [0x00070000 - 0x0007ffff] mem
<null> compute_allocate_mem: base: 00080000 size: 00100000 align: 20 gran:
20 done
PCI: 01:02.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
<null> compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12
done
PCI: 01:02.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
PCI: 03:03.0 10 *  [0x00000000 - 0x0fffffff] prefmem
PCI: 03:03.0 18 *  [0x10000000 - 0x13ffffff] prefmem
<null> compute_allocate_prefmem: base: 14000000 size: 14000000 align: 28
gran: 20 done
PCI: 01:02.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
<null> compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran:
20 done
PCI: 01:03.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
PCI: 04:01.0 missing read_resources
PCI: 04:06.0 14 *  [0x00000000 - 0x000000ff] io
PCI: 04:05.0 18 *  [0x00000400 - 0x0000047f] io
PCI: 04:05.0 10 *  [0x00000480 - 0x000004bf] io
PCI: 04:05.0 14 *  [0x000004c0 - 0x000004cf] io
<null> compute_allocate_io: base: 000004d0 size: 00001000 align: 12 gran: 12
done
PCI: 01:03.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
PCI: 04:01.0 missing read_resources
<null> compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20
gran: 20 done
PCI: 01:03.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
PCI: 04:01.0 missing read_resources
PCI: 04:06.0 10 *  [0x00000000 - 0x00ffffff] mem
PCI: 04:05.0 20 *  [0x01000000 - 0x0101ffff] mem
PCI: 04:00.0 10 *  [0x01020000 - 0x01020fff] mem
PCI: 04:00.1 10 *  [0x01021000 - 0x01021fff] mem
PCI: 04:05.0 1c *  [0x01022000 - 0x01022fff] mem
PCI: 04:06.0 18 *  [0x01023000 - 0x01023fff] mem
PCI: 04:00.2 10 *  [0x01024000 - 0x010240ff] mem
PCI: 04:00.2 14 *  [0x01025000 - 0x0102501f] mem
<null> compute_allocate_mem: base: 01025020 size: 01100000 align: 24 gran:
20 done
PCI: 01:04.5 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 01:01.0 1c *  [0x00000000 - 0x00000fff] io
PCI: 01:03.0 1c *  [0x00001000 - 0x00001fff] io
PCI: 01:02.0 1c *  [0x00002000 - 0x00001fff] io
PCI: 01:04.2 10 *  [0x00002000 - 0x0000201f] io
PCI: 01:04.1 20 *  [0x00002020 - 0x0000202f] io
<null> compute_allocate_io: base: 00002030 size: 00003000 align: 12 gran: 12
done
PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
PCI: 01:04.5 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 01:02.0 24 *  [0x00000000 - 0x13ffffff] prefmem
PCI: 01:03.0 20 *  [0x14000000 - 0x150fffff] mem
PCI: 01:01.0 20 *  [0x15100000 - 0x151fffff] mem
PCI: 01:01.0 24 *  [0x15200000 - 0x151fffff] prefmem
PCI: 01:02.0 20 *  [0x15200000 - 0x151fffff] mem
PCI: 01:03.0 24 *  [0x15200000 - 0x151fffff] prefmem
PCI: 01:01.1 10 *  [0x15200000 - 0x15200fff] mem
PCI: 01:02.1 10 *  [0x15201000 - 0x15201fff] mem
<null> compute_allocate_mem: base: 15202000 size: 15300000 align: 28 gran:
20 done
PCI: 00:18.0 c0 *  [0x00001000 - 0x00003fff] io
<null> compute_allocate_io: base: 00004000 size: 00003c00 align: 12 gran: 0
done
Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0
gran: 0
PCI: 00:18.0 b8 *  [0x00000000 - 0x152fffff] mem
<null> compute_allocate_mem: base: 15300000 size: 15300000 align: 28 gran: 0
done
Root Device compute_allocate_io: base: 00001000 size: 00003c00 align: 12
gran: 0
PCI: 00:18.0 c0 *  [0x00001000 - 0x00003fff] io
<null> compute_allocate_io: base: 00004000 size: 00003000 align: 12 gran: 0
done
Root Device compute_allocate_mem: base: e0000000 size: 15300000 align: 28
gran: 0
PCI: 00:18.0 b8 *  [0xe0000000 - 0xf52fffff] mem
<null> compute_allocate_mem: base: f5300000 size: 15300000 align: 28 gran: 0
done

-----????-----
???: YhLu 
????: 2004?3?1? 13:10
???: 'ebiederman at lnxi.com'; ron minnich
??: LinuxBIOS
??: ??: Prefmem of bus 3

Some time you said that arima board connect all PCI-X slots of amd 8131 irq
to amd 8111 ioapic intead of 8131.

So even disable ioapic of 8131, device on PCI-X still works properly.

After enable ioapic of 8131, devices that are not using prefmem works well.

YH.

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?1? 10:48
???: ron minnich
??: YhLu; ebiederman at lnxi.com; LinuxBIOS
??: Re: Prefmem of bus 3

ron minnich <rminnich at lanl.gov> writes:

> On Fri, 27 Feb 2004, YhLu wrote:
> 
> > Have you ever tested myrinet card on K8 MB under LinuxBIOS?
> 
> we have a 1408-node K8 machine with myrinet working under linuxbios, and a

> 256-node K8 machine working with linuxbios. Arima HDAMA mainboards.
> 
> I wonder what's going on here, I have not had time to look in detail.

So the problem appears to be that the prefmem region on the upper bus
is to large.

I wonder if why this work on LANL clusters and not on others is the
result of code skew.

Lightning nodes with myrinet only seem to have one prefmem region.

Yet another reminder that I really need to finish syncing up the code bases.

Eric


From YhLu at tyan.com  Tue Mar  9 23:09:01 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Mar  9 23:09:01 2004
Subject: =?GB2312?B?tPC4tDogUHJlZm1lbSBvZiBidXMgMw==?=
Message-ID: <3174569B9743D511922F00A0C94314230466CFE3@TYANWEB>

Eric,

If change to 

        /* Get the base address */
        base = resource->base;
        /* Get the resource alignment */
        gran = 1UL << resource->gran;

        /* Get the limit (rounded up) */
        limit = base + ((resource->size + gran - 1UL) & ~(gran - 1UL)) -1UL;

quadrics will work.

Regards

YH.

-----????-----
???: YhLu 
????: 2004?3?9? 20:16
???: YhLu; 'ebiederman at lnxi.com'; 'ron minnich'
??: 'LinuxBIOS'
??: ??: Prefmem of bus 3

I mean

        /* Get the base address */
        base = resource->base;
        /* Get the resource alignment */
        align = 1UL << resource->align;

        /* Get the limit (rounded up) */
        limit = base + ((resource->size + align - 1UL) & ~(align - 1UL))
-1UL;

should be changed.

-----????-----
???: YhLu 
????: 2004?3?9? 20:14
???: YhLu; ebiederman at lnxi.com; ron minnich
??: LinuxBIOS
??: re: Prefmem of bus 3

Eric,

I print out the allocating spew and found the align calculation seems not
correct.

PCI: 01:02.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
PCI: 03:03.0 10 *  [0x00000000 - 0x0fffffff] prefmem
PCI: 03:03.0 18 *  [0x10000000 - 0x13ffffff] prefmem
<null> compute_allocate_prefmem: base: 14000000 size: 14000000 align: 28
gran: 20 done

When computing limit in pci_set_device of pci_device.c, only using align.
So will produce limit=0xffffffff, instead of 0xf3ffffff.

So maybe need to using gran together with align and base to calculate the
limit.

Regards

YH



Allocating resources...
Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0
gran: 0
PCI: 00:18.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
PCI: 01:01.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
PCI: 02:0a.0 10 *  [0x00000000 - 0x000000ff] io
PCI: 02:0a.1 10 *  [0x00000400 - 0x000004ff] io
<null> compute_allocate_io: base: 00000500 size: 00001000 align: 12 gran: 12
done
PCI: 01:01.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
<null> compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20
gran: 20 done
PCI: 01:01.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
PCI: 02:09.0 10 *  [0x00000000 - 0x0000ffff] mem
PCI: 02:09.0 18 *  [0x00010000 - 0x0001ffff] mem
PCI: 02:09.1 10 *  [0x00020000 - 0x0002ffff] mem
PCI: 02:09.1 18 *  [0x00030000 - 0x0003ffff] mem
PCI: 02:0a.0 14 *  [0x00040000 - 0x0004ffff] mem
PCI: 02:0a.0 1c *  [0x00050000 - 0x0005ffff] mem
PCI: 02:0a.1 14 *  [0x00060000 - 0x0006ffff] mem
PCI: 02:0a.1 1c *  [0x00070000 - 0x0007ffff] mem
<null> compute_allocate_mem: base: 00080000 size: 00100000 align: 20 gran:
20 done
PCI: 01:02.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
<null> compute_allocate_io: base: 00000000 size: 00000000 align: 12 gran: 12
done
PCI: 01:02.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
PCI: 03:03.0 10 *  [0x00000000 - 0x0fffffff] prefmem
PCI: 03:03.0 18 *  [0x10000000 - 0x13ffffff] prefmem
<null> compute_allocate_prefmem: base: 14000000 size: 14000000 align: 28
gran: 20 done
PCI: 01:02.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
<null> compute_allocate_mem: base: 00000000 size: 00000000 align: 20 gran:
20 done
PCI: 01:03.0 compute_allocate_io: base: 00000000 size: 00000000 align: 12
gran: 12
PCI: 04:01.0 missing read_resources
PCI: 04:06.0 14 *  [0x00000000 - 0x000000ff] io
PCI: 04:05.0 18 *  [0x00000400 - 0x0000047f] io
PCI: 04:05.0 10 *  [0x00000480 - 0x000004bf] io
PCI: 04:05.0 14 *  [0x000004c0 - 0x000004cf] io
<null> compute_allocate_io: base: 000004d0 size: 00001000 align: 12 gran: 12
done
PCI: 01:03.0 compute_allocate_prefmem: base: 00000000 size: 00000000 align:
20 gran: 20
PCI: 04:01.0 missing read_resources
<null> compute_allocate_prefmem: base: 00000000 size: 00000000 align: 20
gran: 20 done
PCI: 01:03.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
PCI: 04:01.0 missing read_resources
PCI: 04:06.0 10 *  [0x00000000 - 0x00ffffff] mem
PCI: 04:05.0 20 *  [0x01000000 - 0x0101ffff] mem
PCI: 04:00.0 10 *  [0x01020000 - 0x01020fff] mem
PCI: 04:00.1 10 *  [0x01021000 - 0x01021fff] mem
PCI: 04:05.0 1c *  [0x01022000 - 0x01022fff] mem
PCI: 04:06.0 18 *  [0x01023000 - 0x01023fff] mem
PCI: 04:00.2 10 *  [0x01024000 - 0x010240ff] mem
PCI: 04:00.2 14 *  [0x01025000 - 0x0102501f] mem
<null> compute_allocate_mem: base: 01025020 size: 01100000 align: 24 gran:
20 done
PCI: 01:04.5 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 01:01.0 1c *  [0x00000000 - 0x00000fff] io
PCI: 01:03.0 1c *  [0x00001000 - 0x00001fff] io
PCI: 01:02.0 1c *  [0x00002000 - 0x00001fff] io
PCI: 01:04.2 10 *  [0x00002000 - 0x0000201f] io
PCI: 01:04.1 20 *  [0x00002020 - 0x0000202f] io
<null> compute_allocate_io: base: 00002030 size: 00003000 align: 12 gran: 12
done
PCI: 00:18.0 compute_allocate_mem: base: 00000000 size: 00000000 align: 20
gran: 20
PCI: 01:04.5 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 01:02.0 24 *  [0x00000000 - 0x13ffffff] prefmem
PCI: 01:03.0 20 *  [0x14000000 - 0x150fffff] mem
PCI: 01:01.0 20 *  [0x15100000 - 0x151fffff] mem
PCI: 01:01.0 24 *  [0x15200000 - 0x151fffff] prefmem
PCI: 01:02.0 20 *  [0x15200000 - 0x151fffff] mem
PCI: 01:03.0 24 *  [0x15200000 - 0x151fffff] prefmem
PCI: 01:01.1 10 *  [0x15200000 - 0x15200fff] mem
PCI: 01:02.1 10 *  [0x15201000 - 0x15201fff] mem
<null> compute_allocate_mem: base: 15202000 size: 15300000 align: 28 gran:
20 done
PCI: 00:18.0 c0 *  [0x00001000 - 0x00003fff] io
<null> compute_allocate_io: base: 00004000 size: 00003c00 align: 12 gran: 0
done
Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0
gran: 0
PCI: 00:18.0 b8 *  [0x00000000 - 0x152fffff] mem
<null> compute_allocate_mem: base: 15300000 size: 15300000 align: 28 gran: 0
done
Root Device compute_allocate_io: base: 00001000 size: 00003c00 align: 12
gran: 0
PCI: 00:18.0 c0 *  [0x00001000 - 0x00003fff] io
<null> compute_allocate_io: base: 00004000 size: 00003000 align: 12 gran: 0
done
Root Device compute_allocate_mem: base: e0000000 size: 15300000 align: 28
gran: 0
PCI: 00:18.0 b8 *  [0xe0000000 - 0xf52fffff] mem
<null> compute_allocate_mem: base: f5300000 size: 15300000 align: 28 gran: 0
done

-----????-----
???: YhLu 
????: 2004?3?1? 13:10
???: 'ebiederman at lnxi.com'; ron minnich
??: LinuxBIOS
??: ??: Prefmem of bus 3

Some time you said that arima board connect all PCI-X slots of amd 8131 irq
to amd 8111 ioapic intead of 8131.

So even disable ioapic of 8131, device on PCI-X still works properly.

After enable ioapic of 8131, devices that are not using prefmem works well.

YH.

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?1? 10:48
???: ron minnich
??: YhLu; ebiederman at lnxi.com; LinuxBIOS
??: Re: Prefmem of bus 3

ron minnich <rminnich at lanl.gov> writes:

> On Fri, 27 Feb 2004, YhLu wrote:
> 
> > Have you ever tested myrinet card on K8 MB under LinuxBIOS?
> 
> we have a 1408-node K8 machine with myrinet working under linuxbios, and a

> 256-node K8 machine working with linuxbios. Arima HDAMA mainboards.
> 
> I wonder what's going on here, I have not had time to look in detail.

So the problem appears to be that the prefmem region on the upper bus
is to large.

I wonder if why this work on LANL clusters and not on others is the
result of code skew.

Lightning nodes with myrinet only seem to have one prefmem region.

Yet another reminder that I really need to finish syncing up the code bases.

Eric


From rminnich at lanl.gov  Wed Mar 10 17:20:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 10 17:20:00 2004
Subject: =?GB2312?B?tPC4tDogUHJlZm1lbSBvZiBidXMgMw==?=
In-Reply-To: <3174569B9743D511922F00A0C94314230466CFDE@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403101533020.10422-100000@maxroach.lanl.gov>

On Tue, 9 Mar 2004, YhLu wrote:

> I mean
> 
>         /* Get the base address */
>         base = resource->base;
>         /* Get the resource alignment */
>         align = 1UL << resource->align;
> 
>         /* Get the limit (rounded up) */
>         limit = base + ((resource->size + align - 1UL) & ~(align - 1UL))
> -1UL;

I am thinking now about what you said. Granularity is the units of
allocation. Alignment is the alignment of the data.

Examples: 64 byte granularity, 32-byte alignment, you can see that 
          addresses of 32, 64, 96, etc. are acceptable. 
          64 byte granularity, 64 byte alignment, only addresses of
          64, 128, ... are acceptable.

If memory serves, behind a bridge, the memory space granularity is 16 bits 
(or is it 20? memory fails). Alignment is more or less the size of the 
resource. 

Looking at quadrics, the resource is 28 bits, so that will have to be the 
alignment, and granularity is 20 bits. 

So the expression above is wrong, I think you are correct. It will work in 
many cases but fail in some. I think it should  be this:

   limit = base + ((resource->size + gran - 1UL) & ~(gran - 1UL))  -1UL

as you already said.

I.e. take the base, add a size rounded up to gran, and add it to base.

ron




From ebiederman at lnxi.com  Wed Mar 10 20:14:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Mar 10 20:14:00 2004
Subject: =?gb2312?b?tPC4tA==?=: Prefmem of bus 3
In-Reply-To: <Pine.LNX.4.44.0403101533020.10422-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403101533020.10422-100000@maxroach.lanl.gov>
Message-ID: <m3llm8w44q.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Tue, 9 Mar 2004, YhLu wrote:
> 
> > I mean
> > 
> >         /* Get the base address */
> >         base = resource->base;
> >         /* Get the resource alignment */
> >         align = 1UL << resource->align;
> > 
> >         /* Get the limit (rounded up) */
> >         limit = base + ((resource->size + align - 1UL) & ~(align - 1UL))
> > -1UL;
> 
> I am thinking now about what you said. Granularity is the units of
> allocation. Alignment is the alignment of the data.
> 
> Examples: 64 byte granularity, 32-byte alignment, you can see that 
>           addresses of 32, 64, 96, etc. are acceptable. 
>           64 byte granularity, 64 byte alignment, only addresses of
>           64, 128, ... are acceptable.
> 
> If memory serves, behind a bridge, the memory space granularity is 16 bits 
> (or is it 20? memory fails). Alignment is more or less the size of the 
> resource. 
> 
> Looking at quadrics, the resource is 28 bits, so that will have to be the 
> alignment, and granularity is 20 bits. 
> 
> So the expression above is wrong, I think you are correct. It will work in 
> many cases but fail in some. I think it should  be this:
> 
>    limit = base + ((resource->size + gran - 1UL) & ~(gran - 1UL))  -1UL
> 
> as you already said.
> 
> I.e. take the base, add a size rounded up to gran, and add it to base.

That is right.   I feel quite silly that is the code that is sitting in
my tree and I feel for not getting it pushed out earlier.   I'm going
to many directions at once or something like that.

It has the additional comment:

	/* Get the resource granularity */
	gran = 1UL << resource->gran;

	/* For a non bridge resource granularity and alignment are the same.
	 * For a bridge resource align is the largest needed alignment below
	 * the bridge.  While the granularity is simply how many low bits of the
	 * address cannot be set.
	 */
	
	/* Get the limit (rounded up) */
	limit = base + ((resource->size + gran - 1UL) & ~(gran - 1UL)) -1UL;

I will get this committed shortly.  At least I chose sane names so this
could be reasoned out.

Eric


From rminnich at lanl.gov  Wed Mar 10 23:03:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 10 23:03:00 2004
Subject: =?gb2312?b?tPC4tA==?=: Prefmem of bus 3
In-Reply-To: <m3llm8w44q.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403102123090.15276-100000@maxroach.lanl.gov>

On 10 Mar 2004, Eric W. Biederman wrote:

> 
> It has the additional comment:
> 
> 	/* Get the resource granularity */
> 	gran = 1UL << resource->gran;
> 
> 	/* For a non bridge resource granularity and alignment are the same.
> 	 * For a bridge resource align is the largest needed alignment below
> 	 * the bridge.  While the granularity is simply how many low bits of the
> 	 * address cannot be set.
> 	 */
> 	
> 	/* Get the limit (rounded up) */
> 	limit = base + ((resource->size + gran - 1UL) & ~(gran - 1UL)) -1UL;

not to worry, Ollie and I fixed it too. We're going to have some real 
collisions when you commit. 

We are using the round() function for clarity, e.g.
	limit = base + round(resource->size, gran) - 1UL;

ron



From YhLu at tyan.com  Wed Mar 10 23:36:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 10 23:36:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogUHJlZm1lbSBvZiBidXMgMw==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D0D9@TYANWEB>

You'd better commit the additional commet made by Eirc.

> 	/* For a non bridge resource granularity and alignment are the same.
> 	 * For a bridge resource align is the largest needed alignment below
> 	 * the bridge.  While the granularity is simply how many low bits of
the
> 	 * address cannot be set.
> 	 */


YH.

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?3?10? 20:24
???: Eric W. Biederman
??: YhLu; 'LinuxBIOS'
??: Re: ??: Prefmem of bus 3

On 10 Mar 2004, Eric W. Biederman wrote:

> 
> It has the additional comment:
> 
> 	/* Get the resource granularity */
> 	gran = 1UL << resource->gran;
> 
> 	/* For a non bridge resource granularity and alignment are the same.
> 	 * For a bridge resource align is the largest needed alignment below
> 	 * the bridge.  While the granularity is simply how many low bits of
the
> 	 * address cannot be set.
> 	 */
> 	
> 	/* Get the limit (rounded up) */
> 	limit = base + ((resource->size + gran - 1UL) & ~(gran - 1UL)) -1UL;

not to worry, Ollie and I fixed it too. We're going to have some real 
collisions when you commit. 

We are using the round() function for clarity, e.g.
	limit = base + round(resource->size, gran) - 1UL;

ron


From YhLu at tyan.com  Wed Mar 10 23:48:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 10 23:48:01 2004
Subject: ACPI support
Message-ID: <3174569B9743D511922F00A0C94314230466D0DC@TYANWEB>

Stefan,

It seems that you put some code about acpi in the tree.

What's your plan about that? 

Can I use that together with ACPI support in Kernel to make "shutdown -h
now" to be real shutdown the power?

Regards

YH



From stepan at suse.de  Thu Mar 11 05:54:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Mar 11 05:54:00 2004
Subject: ACPI support
In-Reply-To: <3174569B9743D511922F00A0C94314230466D0DC@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D0DC@TYANWEB>
Message-ID: <20040311111438.GB6156@suse.de>

* YhLu <YhLu at tyan.com> [040311 06:14]:
> Stefan,
> 
> It seems that you put some code about acpi in the tree.
> 
> What's your plan about that? 

I created some basic framework for dynamic ACPI table creation, but it
is by no means a complete ACPI implementation. Plan is to also support
powermanagement on AMD64 (and hopefully get ACPI going for other ports
as well)
 
> Can I use that together with ACPI support in Kernel to make "shutdown -h
> now" to be real shutdown the power?

Currently, no. Not all information is provided by LinuxBIOS yet to make 
this work. (Much of it can be generated from the device tree) 
The ACPI implementation currently only allows to utilize the HPET timer
in Linux (which is not possible without ACPI at all)

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From ebiederman at lnxi.com  Thu Mar 11 05:55:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Mar 11 05:55:01 2004
Subject: ACPI support
In-Reply-To: <3174569B9743D511922F00A0C94314230466D0DC@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D0DC@TYANWEB>
Message-ID: <m38yi7vd8r.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Stefan,
> 
> It seems that you put some code about acpi in the tree.
> 
> What's your plan about that? 

Currently ACPI support exists simply to provide the extra ACPI tables.
No AML currently exists.

We need to get enough IRQ information in the device tree so we can
auto generate these kinds of tables.

> Can I use that together with ACPI support in Kernel to make "shutdown -h
> now" to be real shutdown the power?

That would not be the worst thing to implement.  However we have not
gone there yet.

If the BIOS has to implement services an interpreted byte code where
the kernel provides the interpreter at least gives the kernel guys
the option of catching bugs, and working around them.  I completely
prefer AML over BIOS callbacks. 

Is AML turing complete?

It would be nice if the hardware was standardized enough that simple
things like this were architectural instead of needing BIOS work.

Eric


From phreak_show at gmx.de  Thu Mar 11 07:19:01 2004
From: phreak_show at gmx.de (Stefan)
Date: Thu Mar 11 07:19:01 2004
Subject: COMPAQ Armada 1530D
Message-ID: <40505E34.2020309@gmx.de>

Hi LinuxBIOS-users ;)

I got a compaq armada 1530d notebook, is it possible to run linuxbios on 
it? Is there a command to enter ? thx


From rminnich at lanl.gov  Thu Mar 11 08:54:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 11 08:54:00 2004
Subject: ACPI support
In-Reply-To: <20040311111438.GB6156@suse.de>
Message-ID: <Pine.LNX.4.44.0403110714390.19316-100000@maxroach.lanl.gov>

As it happens the real important thing (which we hope to get to) is SRAT 
tables, so that Linux with NUMA support will work on K8. 

Yep, it really matters, as somebody from IBM explained to me recently.

ron



From rminnich at lanl.gov  Thu Mar 11 08:55:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 11 08:55:01 2004
Subject: ACPI support
In-Reply-To: <m38yi7vd8r.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403110716000.19316-100000@maxroach.lanl.gov>

On 11 Mar 2004, Eric W. Biederman wrote:

> If the BIOS has to implement services an interpreted byte code where the
> kernel provides the interpreter at least gives the kernel guys the
> option of catching bugs, and working around them.  I completely prefer
> AML over BIOS callbacks.

YES!

> Is AML turing complete?

I am sure it is. I am sure that it would be able to pass the Turing test, 
it is so complex :-)

ron



From rminnich at lanl.gov  Thu Mar 11 08:56:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 11 08:56:01 2004
Subject: COMPAQ Armada 1530D
In-Reply-To: <40505E34.2020309@gmx.de>
Message-ID: <Pine.LNX.4.44.0403110716450.19316-100000@maxroach.lanl.gov>

On Thu, 11 Mar 2004, Stefan wrote:

> I got a compaq armada 1530d notebook, is it possible to run linuxbios on 
> it? Is there a command to enter ? thx

lspci

ron



From stepan at suse.de  Thu Mar 11 09:10:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Mar 11 09:10:01 2004
Subject: ACPI support
In-Reply-To: <Pine.LNX.4.44.0403110716000.19316-100000@maxroach.lanl.gov>
References: <m38yi7vd8r.fsf@maxwell.lnxi.com> <Pine.LNX.4.44.0403110716000.19316-100000@maxroach.lanl.gov>
Message-ID: <20040311143009.GA8456@suse.de>

* ron minnich <rminnich at lanl.gov> [040311 15:16]:
> On 11 Mar 2004, Eric W. Biederman wrote:
> 
> > If the BIOS has to implement services an interpreted byte code where the
> > kernel provides the interpreter at least gives the kernel guys the
> > option of catching bugs, and working around them.  I completely prefer
> > AML over BIOS callbacks.
> 
> YES!

In case of broken 16bit bioses there might be a point. But for us I
don't really see the difference. If it's broken, we can fix it. Even
when using callbacks, can't we?
 
   Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From ebiederman at lnxi.com  Thu Mar 11 10:04:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Mar 11 10:04:00 2004
Subject: [COMMIT] linuxbios 1.1.6....
Message-ID: <m3smgfjt4z.fsf@maxwell.lnxi.com>

I have needed to sync my code base with the main tree for a while,
and I finally find a little bit of time.  While what I have is not
quite perfect it is the best I can do and should not be too hard to
keep up with.  I will try to keep things in smaller steps next round.
freebios2 is stabilizing so it getting harder to implement a big
disruptive change :)

The radical changes are how the K8 early setup and memory
initialization is accomplished.  The whole processes normally only
needs a single reset at the very begging of the boot now.  I suspect
I have broken several Opteron platforms with the changes needed to
support this.  The hdama and solo ports should still work.

The other radical change is I have finally written some generic super
code in place and I removed the place holder structures com_ports
and lpt_ports from chip.h.  I think this only affects ports using
the winbond w83627thf chip.  It looked like an exact clone of
the pc87360 code and I don't believe the two chips are identical.
The pc87360/superio.c is not fully functional at only 78 lines of
code so it should be simple enough to fix.

The other big user visible change is that it is now possible to 
specify static resource assignments in Config.lb generically.
A snippet of the hdama/Config.lb is:

		superio NSC/pc87360 link 1
			pnp 2e.0 off  # Floppy 
				 io 0x60 = 0x3f0
				irq 0x70 = 6
				drq 0x74 = 2
			pnp 2e.1 off  # Parallel Port
				 io 0x60 = 0x378
				irq 0x70 = 7
			pnp 2e.2 off # Com 2
				 io 0x60 = 0x2f8
				irq 0x70 = 3
			pnp 2e.3 on  # Com 1
				 io 0x60 = 0x3f8
				irq 0x70 = 4
			pnp 2e.4 off # SWC
			pnp 2e.5 off # Mouse
			pnp 2e.6 on  # Keyboard
				 io 0x60 = 0x60
				 io 0x62 = 0x64
				irq 0x70 = 1
			pnp 2e.7 off # GPIO
			pnp 2e.8 off # ACB
			pnp 2e.9 off # FSCM
			pnp 2e.a off # WDT  


My full commit comments are below.

Holler and I will help fix the breakage I have caused.


- Moved hlt() to it's own header.
- Reworked pnp superio device support.  Now complete superio support is less than 100 lines.
- Added support for hard coding resource assignments in Config.lb
- Minor bug fixes to romcc
- Initial support for catching the x86 processor BIST error codes.  I've only seen
  this trigger once in production during a very suspcious reset but...
- added raminit_test to test the code paths in raminit.c for the Opteron
- Removed the IORESOURCE_SET bit and added IORESOURCE_ASSIGNED and IORESOURCE_STORED
  so we can tell what we have really done.
- Added generic AGP/IOMMU setting code to x86
- Added an implementation of memmove and removed reserved identifiers from memcpy
- Added minimal support for booting on pre b3 stepping K8 cores
- Moved the checksum on amd8111 boards because our default location was on top of
  extended RTC registers
- On the Hdama added support for enabling i2c hub so we can get at the temperature
  sensors.  Not that i2c bus was implemented well enough to make that useful.
- Redid the Opteron port so we should only need one reset and most of memory initialization
  is done in cpu_fixup.  This is much, much faster.
- Attempted to make the VGA IO region assigment work.  The code seems to work now...
- Redid the error handling in amdk8/raminit.c to distinguish between a bad value
  and a smbus error, and moved memory clearing out to cpufixup.
- Removed CONFIG_KEYBOARD as it was useless.  See pc87360/superio.c for how to 
  setup a legacy keyboard properly.
- Reworked the register values for standard hardware, moving the defintions from
  chip.h into the headers of the initialization routines.  This is much saner
  and is actually implemented.
- Made the hdama port an under clockers BIOS.  I debuged so many interesting problems.
- On amd8111_lpc added setup of architectural/legacy hardware
- Enabled PCI error reporting as much as possible.
- Enhanded build_opt_tbl to generate a header of the cmos option locations so
  that romcc compiled code can query the cmos options.
- In romcc gracefully handle function names that degenerate into function pointers
- Bumped the version to 1.1.6 as we are getting closer to 2.0

TODO finish optimizing the HT links of non dual boards
TODO make all Opteron board work again
TODO convert all superio devices to use the new helpers
TODO convert the via/epia to freebios2 conventions
TODO cpu fixup/setup by cpu type
TODO update romcc so I can pass in values from assembly code
TODO irq routing in the device tree.

Eric


Modified Files:
   src/arch/i386/include/arch/romcc_io.h src/arch/i386/lib/cpu.c
   src/arch/i386/smp/start_stop.c
   src/arch/ppc/boot/linuxbios_table.c src/config/Config.lb
   src/config/Options.lb src/cpu/i386/entry16.inc
   src/cpu/i386/entry32.inc src/cpu/k8/cpufixup.c
   src/cpu/k8/earlymtrr.c src/cpu/k8/earlymtrr.inc
   src/cpu/k8/enable_mmx_sse.inc src/cpu/p6/Config.lb
   src/cpu/p6/boot_cpu.c src/cpu/p6/earlymtrr.c src/cpu/p6/mtrr.c
   src/devices/Config.lb src/devices/chip.c src/devices/device.c
   src/devices/device_util.c src/devices/hypertransport.c
   src/devices/pci_device.c src/include/string.h
   src/include/uart8250.h src/include/cpu/k8/mtrr.h
   src/include/cpu/p6/mtrr.h src/include/device/chip.h
   src/include/device/device.h
   src/include/device/hypertransport.h
   src/include/device/pci_def.h src/include/device/pnp.h
   src/include/device/resource.h src/include/pc80/mc146818rtc.h
   src/lib/Config.lb src/lib/memcpy.c src/lib/uart8250.c
   src/mainboard/amd/quartet/Config.lb
   src/mainboard/amd/solo/Config.lb src/mainboard/amd/solo/auto.c
   src/mainboard/amd/solo/cmos.layout
   src/mainboard/amd/solo/failover.c
   src/mainboard/amd/solo/mptable.c
   src/mainboard/arima/hdama/Config.lb
   src/mainboard/arima/hdama/auto.c
   src/mainboard/arima/hdama/cmos.layout
   src/mainboard/arima/hdama/failover.c
   src/mainboard/arima/hdama/irq_tables.c
   src/mainboard/arima/hdama/mainboard.c
   src/mainboard/newisys/khepri/Config.lb
   src/mainboard/newisys/khepri/auto.c
   src/mainboard/tyan/s2881/hypertransport.c
   src/northbridge/amd/amdk8/Config.lb
   src/northbridge/amd/amdk8/amdk8.h
   src/northbridge/amd/amdk8/coherent_ht.c
   src/northbridge/amd/amdk8/cpu_rev.c
   src/northbridge/amd/amdk8/early_ht.c
   src/northbridge/amd/amdk8/misc_control.c
   src/northbridge/amd/amdk8/northbridge.c
   src/northbridge/amd/amdk8/raminit.c
   src/northbridge/amd/amdk8/raminit.h
   src/northbridge/amd/amdk8/reset_test.c src/pc80/Config.lb
   src/pc80/keyboard.c src/pc80/mc146818rtc_early.c
   src/pc80/serial.c src/pc80/serial.inc
   src/southbridge/amd/amd8111/Config.lb
   src/southbridge/amd/amd8111/amd8111.c
   src/southbridge/amd/amd8111/amd8111_acpi.c
   src/southbridge/amd/amd8111/amd8111_early_smbus.c
   src/southbridge/amd/amd8111/amd8111_ide.c
   src/southbridge/amd/amd8111/amd8111_lpc.c
   src/southbridge/amd/amd8111/amd8111_usb.c
   src/southbridge/amd/amd8111/amd8111_usb2.c
   src/southbridge/amd/amd8131/amd8131_bridge.c
   src/superio/NSC/pc87360/chip.h
   src/superio/NSC/pc87360/superio.c util/newconfig/config.g
   util/options/build_opt_tbl.c util/romcc/Makefile
   util/romcc/romcc.c
Added Files:
   src/arch/i386/include/arch/hlt.h
   src/arch/i386/include/arch/smp/lapic.h src/cpu/i386/bist32.inc
   src/cpu/i386/bist32_fail.inc src/cpu/p6/pgtbl.c
   src/devices/pnp_device.c src/include/cpu/p6/pgtbl.h
   src/include/device/hypertransport_def.h
   src/include/device/pnp_def.h src/include/pc80/keyboard.h
   src/lib/memmove.c src/northbridge/amd/amdk8/incoherent_ht.c
   src/northbridge/amd/amdk8/raminit_test.c src/pc80/isa-dma.c
   src/southbridge/amd/amd8111/amd8111_pci.c
   src/superio/NSC/pc87360/pc87360.h
   src/superio/NSC/pc87360/pc87360_early_serial.c
   util/romcc/tests/fail_test6.c util/romcc/tests/fail_test7.c
   util/romcc/tests/fail_test8.c
Removed Files:
   src/mainboard/arima/hdama/example-fallback.config
   src/mainboard/arima/hdama/example-normal.config
   src/mainboard/tyan/s2880/static_devices.c.orig
   src/northbridge/amd/amdk8/mcf0_control.c
----------------------------------------------------------------------


From ebiederman at lnxi.com  Thu Mar 11 10:15:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Mar 11 10:15:01 2004
Subject: ACPI support
In-Reply-To: <20040311143009.GA8456@suse.de>
References: <m38yi7vd8r.fsf@maxwell.lnxi.com>
	<Pine.LNX.4.44.0403110716000.19316-100000@maxroach.lanl.gov>
	<20040311143009.GA8456@suse.de>
Message-ID: <m3d67jfkym.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * ron minnich <rminnich at lanl.gov> [040311 15:16]:
> > On 11 Mar 2004, Eric W. Biederman wrote:
> > 
> > > If the BIOS has to implement services an interpreted byte code where the
> > > kernel provides the interpreter at least gives the kernel guys the
> > > option of catching bugs, and working around them.  I completely prefer
> > > AML over BIOS callbacks.
> > 
> > YES!
> 
> In case of broken 16bit bioses there might be a point. But for us I
> don't really see the difference. If it's broken, we can fix it. Even
> when using callbacks, can't we?

We should.  An installed BIOS has an amazing amount of initeria if it is
some little thing.

With AML you can load a new version from the OS without having to flash
you BIOS so it is safer.

Plus there are issues of needed multiple entry points 32bit 64bit and
possibly 16bit depending on which mode the processor is operating in.  With
byte code you only need to provide one version.

Basically byte code seems much more optional than a magic function you
can call.  But in the practical it should be possible to fix the
firmware, and reflash if we did provide callbacks.  I just like to err
as far as possible on the side of caution.

My preference is to provide no code that is run after the OS loads,
and just to specify some static table entries.  The rest is
essentially a fallback position.

Eric


From phreak_show at gmx.de  Thu Mar 11 10:16:03 2004
From: phreak_show at gmx.de (Stefan)
Date: Thu Mar 11 10:16:03 2004
Subject: COMPAQ Armada 1530D
Message-ID: <40508797.9070608@gmx.de>

Hi there,
I ran the lspci on my notebook, here's the result:

phreak:~# lspci
00:00.0 Host Bridge: OPTi Inc. 82C701 [FireStar Plus] (rev 10)
00:01.0 ISA Bridge: OPTi Inc. 82C700 (rev 10)
00:02.0 VGA compatible controller: Cirrus Logic GD 7548
00:11.0 CardBus bridge: Texas Instruments PCI 1131 (rev 01)
00:11.1 CardBus bridge: Texas Instruments PCI 1131 (rev 01)
00:14.0 IDE interface: OPTi Inc. 82C825 [Firebridge 2] (rev 12)

Hope you can use this reply, thx & greetings


From ebiederman at lnxi.com  Thu Mar 11 10:21:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Mar 11 10:21:01 2004
Subject: ACPI support
In-Reply-To: <Pine.LNX.4.44.0403110714390.19316-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403110714390.19316-100000@maxroach.lanl.gov>
Message-ID: <m3znancrid.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> As it happens the real important thing (which we hope to get to) is SRAT 
> tables, so that Linux with NUMA support will work on K8. 
> 
> Yep, it really matters, as somebody from IBM explained to me recently.

On K8 with a 64bit NUMA kernel it should not matter, because
the kernel can look and see where everything is.

In the general case or with a 32bit kernel is makes sense.  I believe
the SRAT table is not an AML table so it really should not be hard
to accommodate.

Eric


From ebiederman at lnxi.com  Thu Mar 11 10:29:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Mar 11 10:29:01 2004
Subject: TODO: K8 CG stepping support
Message-ID: <m3vflbcr51.fsf@maxwell.lnxi.com>

Just an FYI there is some work needed to support the latest K8 steppings
mostly they are Athlon64s.  And that is the one item I forgot to put
on my todo list...

Eric


From ebiederman at lnxi.com  Thu Mar 11 10:37:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Mar 11 10:37:00 2004
Subject: OEM looking at LinuxBIOS
In-Reply-To: <Pine.LNX.4.44.0403091224340.26401-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0403091224340.26401-100000@ccs-mail.lanl.gov>
Message-ID: <m3r7vzcqrw.fsf@maxwell.lnxi.com>

"Hendricks David W." <dwh at lanl.gov> writes:

> There is already 82803 and 82801ca code in the freebios1 tree, might as 
> well put it to good use :) I think Eric Beiderman was even able to fix 
> SPD, at least on the MCH4 (Or something).
> 
> On Tue, 9 Mar 2004, Anthony Winner wrote:
> 
> > Hello all,
> > 
> > I work for a OEM and I'm playing with the idea of using linuxBIOS, I have
> > all of the technical info for the machine short of the actual source code to
> > the Phoenix BIOS we use now as it was done by a contractor before I joined
> > the company.
> > 
> > Are there any pointers for a 'from scratch', implementation?
> > 
> > Should I start with the old code or start fresh from the new freebios2 tree?
> >
> > For reference, the machine is a Intel PIII with a 82830 Northbridge, a
> > 82801ca Southbridge, TI pci1450 card bus controller, and a pair of SMC SIO
> > chips....

I don't think we have good support for th 82830 at this time so the freebios2
tree would be the one to work with.  You get romcc so you can code the
memory initialization in C.  If you know what you are doing a huge chunk of
assembly is tolerable.  But doing things in C prevents a lot of stupid typos.

I just looked the code in the freebios1 tree for the 82830 does not even
attempt to do SPD based memory initialization so it will not work with
arbitrary memory.  So definitely freebios2 using some of the freebios1
code as reference. 

I don't think the freebios1 tree can code with a pair of superio chips either.

The freebios2 tree comes with multiple devices of the same type trivially.

Eric


From ebiederman at lnxi.com  Thu Mar 11 10:54:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Mar 11 10:54:01 2004
Subject: TODO: K8 CG stepping support
In-Reply-To: <20040311155442.GA26918@suse.de>
References: <m3vflbcr51.fsf@maxwell.lnxi.com> <20040311155442.GA26918@suse.de>
Message-ID: <m31xnz8ibe.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [040311 16:58]:
> > Just an FYI there is some work needed to support the latest K8 steppings
> > mostly they are Athlon64s.  And that is the one item I forgot to put
> > on my todo list...
> 
> Can you give some details?

There are some memory controller enhancements. 2T timings I think.
And possibly some memory loading requirements.  There are one or two
other things, power control or irq stuff.  And I think there one or
two errata.

It is nothing huge but it should all be covered in the latest
BIOS programmers guide and the revision guide for the K8.  And I
believe the CG stepping is publicly documented now so anyone who wants
to look through things and make certain we are uptodate should be able
to do it just by wading through the docs.

AMD keeps enhancing things and their processor keeps getting
better.  We poor BIOS guys just have to keep up.

Oh and there is the cpu name string that we could fill in if
we felt so inclined.  I don't think I have ever gotten that far.

I'm busy working on a different port so I don't think I will refresh
Opteron code past the C0 stepping any time soon.

Anyway it is probably more important to make certain we have
the normal Opteron ports working before we get to far into that.

I am just trying to flush my queue of outstanding issues before they
start suffering from bit rot.

A lot of the code I flushed today has been running on Lightning and
Orange for a while.  I think everything except the cleaned up superio.

Eric



From rminnich at lanl.gov  Thu Mar 11 10:56:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 11 10:56:01 2004
Subject: ACPI support
In-Reply-To: <m3d67jfkym.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403110916330.19648-100000@maxroach.lanl.gov>

On 11 Mar 2004, Eric W. Biederman wrote:

> Basically byte code seems much more optional than a magic function you
> can call.  But in the practical it should be possible to fix the
> firmware, and reflash if we did provide callbacks.  I just like to err
> as far as possible on the side of caution.

and byte code you can call is probably bad for keeping the processor 
cache, TLBs, etc. nice and current. 

> My preference is to provide no code that is run after the OS loads, and
> just to specify some static table entries.  The rest is essentially a
> fallback position.


yep.

ron



From rminnich at lanl.gov  Thu Mar 11 10:56:07 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 11 10:56:07 2004
Subject: COMPAQ Armada 1530D
In-Reply-To: <40508797.9070608@gmx.de>
Message-ID: <Pine.LNX.4.44.0403110917140.19648-100000@maxroach.lanl.gov>

On Thu, 11 Mar 2004, Stefan wrote:

> Hi there,
> I ran the lspci on my notebook, here's the result:
> 
> phreak:~# lspci
> 00:00.0 Host Bridge: OPTi Inc. 82C701 [FireStar Plus] (rev 10)
> 00:01.0 ISA Bridge: OPTi Inc. 82C700 (rev 10)
> 00:02.0 VGA compatible controller: Cirrus Logic GD 7548
> 00:11.0 CardBus bridge: Texas Instruments PCI 1131 (rev 01)
> 00:11.1 CardBus bridge: Texas Instruments PCI 1131 (rev 01)
> 00:14.0 IDE interface: OPTi Inc. 82C825 [Firebridge 2] (rev 12)

no chance, probably, sorry.

ron



From rminnich at lanl.gov  Thu Mar 11 10:57:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 11 10:57:00 2004
Subject: ACPI support
In-Reply-To: <m3znancrid.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403110917310.19648-100000@maxroach.lanl.gov>

On 11 Mar 2004, Eric W. Biederman wrote:

> On K8 with a 64bit NUMA kernel it should not matter, because
> the kernel can look and see where everything is.

well, according to the ibm guys, linux does not know how to find out where
physical dram (i.e. which CPU) is attached on K8 without SRAT. If you're
saying they may be wrong, I'm happy.

ron



From bari at onelabs.com  Thu Mar 11 11:24:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Mar 11 11:24:00 2004
Subject: COMPAQ Armada 1530D
In-Reply-To: <Pine.LNX.4.44.0403110917140.19648-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403110917140.19648-100000@maxroach.lanl.gov>
Message-ID: <4050980C.5090109@onelabs.com>

ron minnich wrote:
> On Thu, 11 Mar 2004, Stefan wrote:
> 
> 
>>Hi there,
>>I ran the lspci on my notebook, here's the result:
>>
>>phreak:~# lspci
>>00:00.0 Host Bridge: OPTi Inc. 82C701 [FireStar Plus] (rev 10)
>>00:01.0 ISA Bridge: OPTi Inc. 82C700 (rev 10)
>>00:02.0 VGA compatible controller: Cirrus Logic GD 7548
>>00:11.0 CardBus bridge: Texas Instruments PCI 1131 (rev 01)
>>00:11.1 CardBus bridge: Texas Instruments PCI 1131 (rev 01)
>>00:14.0 IDE interface: OPTi Inc. 82C825 [Firebridge 2] (rev 12)
> 
> 
> no chance, probably, sorry.

The Opti parts were released back in 1996-1998. I'm sure my NDA's on 
these have long expired but the Opti site doesn't post the data sheets 
and mine have long vanished into the museum of old cpu's/chipsets along 
with my Z8 and CDP1802 manuals.

-Bari




From linuxbios at chvojka.at  Thu Mar 11 13:52:01 2004
From: linuxbios at chvojka.at (linuxbios at chvojka.at)
Date: Thu Mar 11 13:52:01 2004
Subject: Epia-M IDE HowTo
Message-ID: <1079032404.4050ba5468fe6@chvojka.at>

Hi,
I have a EPIA-M (ME6000) and I want to use Linuxbios for my HTPC.

So I want to boot from hd.
Is there anywhere a good HowTo for this.

The HowTo in the cvs for talks only about etherboot.

greetz



From PLancashire at columbia.com  Thu Mar 11 14:16:00 2004
From: PLancashire at columbia.com (Lancashire, Pete)
Date: Thu Mar 11 14:16:00 2004
Subject: Is there a list or site for ...
Message-ID: <1C31A4EA8D9A024D8C6F40AB43CB120411616C@USHQ-EX1.columbia.csc>

 
sorry to bother every one with a non linux bios question

I'm going to set up a small cluster at home for self
education. cost as can be expected is a concern. For
now i'm looking at a cluster of 4-8 boxes.

I've looked at using used PC's but the best prices
i've seen for anything with a >1 Ghz Processor is
$200 or more.

On the flip side Wal Mart of all places has a box for
$200. No fancy or fast. but better then any used price
ive come across.

Anyway.. does someone know of a mailing list or site
for those of us who have not won a lottery ?

tia,

-pete


From Antony at Soft-Solutions.co.uk  Thu Mar 11 14:28:01 2004
From: Antony at Soft-Solutions.co.uk (Antony Stone)
Date: Thu Mar 11 14:28:01 2004
Subject: Is there a list or site for ...
In-Reply-To: <1C31A4EA8D9A024D8C6F40AB43CB120411616C@USHQ-EX1.columbia.csc>
References: <1C31A4EA8D9A024D8C6F40AB43CB120411616C@USHQ-EX1.columbia.csc>
Message-ID: <200403111949.18553.Antony@Soft-Solutions.co.uk>

On Thursday 11 March 2004 7:36 pm, Lancashire, Pete wrote:

> I'm going to set up a small cluster at home for self
> education. cost as can be expected is a concern. For
> now i'm looking at a cluster of 4-8 boxes.
>
> I've looked at using used PC's but the best prices
> i've seen for anything with a >1 Ghz Processor is
> $200 or more.
>
> Anyway.. does someone know of a mailing list or site
> for those of us who have not won a lottery ?

http://www.ebay.com ?

Antony.

-- 
Abandon hope, all ye who enter here.
You'll feel much better about things once you do.

                                                     Please reply to the list;
                                                           please don't CC me.



From jbors at mail.ru  Thu Mar 11 14:56:00 2004
From: jbors at mail.ru (=?koi8-r?Q?=22?=Dmitry Borisov=?koi8-r?Q?=22=20?=)
Date: Thu Mar 11 14:56:00 2004
Subject: Epia-M IDE HowTo
In-Reply-To: <1079032404.4050ba5468fe6@chvojka.at>
Message-ID: <E1B1Wcj-0001oA-00.jbors-mail-ru@f15.mail.ru>

There is none yet.
Even though you can search through linuxbios archives to get started.

From dwh at lanl.gov  Thu Mar 11 16:29:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 11 16:29:01 2004
Subject: Epia-M IDE HowTo
In-Reply-To: <1079032404.4050ba5468fe6@chvojka.at>
Message-ID: <Pine.LNX.4.44.0403111429550.10302-100000@ccs-mail.lanl.gov>

Etherboot (http://www.etherboot.org/) can boot Linux off a hard disk by 
using 'ide-disk' as a payload. I like to use FILO 
(http://te.to/~ts1/filo/) since it provides an optional interface sort of 
like command-line LILO for loading a kernel (I switch kernels often).

First you'll just need to make the appropriate Etherboot or FILO payload 
(Usually .elf or .zelf). As I recall, for etherboot you need to 
./configure and then make allelfs or a specific driver (make tulip, make 
via-rhine, make ide-disk, etc). For FILO you need to edit a config file 
and give it a default kernel to boot ( hda1:/boot/vmlinuz ), the 
filesystem your kernel image is on (ext3, reiser, xfs, etc). After that, 
just run 'make' and it'll create filo.elf.

After you have your payload, place it somewhere and edit your LinuxBIOS 
config, usually something like 
freebios2/targets/mainboard_vendor/mainboard_model/Config.lb. Change 
the 'payload' line to point to wherever your new payload is located, for 
example: payload /tmp/filo.elf.



On Thu, 11 Mar 2004 linuxbios at chvojka.at wrote:

> Hi,
> I have a EPIA-M (ME6000) and I want to use Linuxbios for my HTPC.
> 
> So I want to boot from hd.
> Is there anywhere a good HowTo for this.
> 
> The HowTo in the cvs for talks only about etherboot.
> 
> greetz
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From dwh at lanl.gov  Thu Mar 11 16:40:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 11 16:40:01 2004
Subject: Is there a list or site for ...
In-Reply-To: <1C31A4EA8D9A024D8C6F40AB43CB120411616C@USHQ-EX1.columbia.csc>
Message-ID: <Pine.LNX.4.44.0403111450590.10302-100000@ccs-mail.lanl.gov>

Clustermatic.org

You can make a BProc (Beowulf distributed processing space) cluster out of 
pretty much anything. One of the clusters here at Los Alamos National 
Laboratory boots Clustermatic software out of flash using our LinuxBIOS 
(shameless plug). It saves money since we don't need a hard disk or CD-ROM 
drive.

On Thu, 11 Mar 2004, Lancashire, Pete wrote:

>  
> sorry to bother every one with a non linux bios question
> 
> I'm going to set up a small cluster at home for self
> education. cost as can be expected is a concern. For
> now i'm looking at a cluster of 4-8 boxes.
> 
> I've looked at using used PC's but the best prices
> i've seen for anything with a >1 Ghz Processor is
> $200 or more.
> 
> On the flip side Wal Mart of all places has a box for
> $200. No fancy or fast. but better then any used price
> ive come across.
> 
> Anyway.. does someone know of a mailing list or site
> for those of us who have not won a lottery ?
> 
> tia,
> 
> -pete
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From dwh at lanl.gov  Thu Mar 11 16:56:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 11 16:56:01 2004
Subject: [COMMIT] linuxbios 1.1.6....
In-Reply-To: <m3smgfjt4z.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403111513490.14086-100000@ccs-mail.lanl.gov>

Looks to work on the HDAMA, but the S2885 is horribly broken. Good thing 
next week is my spring break :)



From YhLu at tyan.com  Thu Mar 11 17:16:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 11 17:16:01 2004
Subject: =?GB2312?B?tPC4tDogW0NPTU1JVF0gbGludXhiaW9zIDEuMS42Li4uLg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D114@TYANWEB>

I'm working on it.

-----????-----
???: Hendricks David W. [mailto:dwh at lanl.gov] 
????: 2004?3?11? 14:17
???: Eric W. Biederman
??: LinuxBIOS
??: Re: [COMMIT] linuxbios 1.1.6....

Looks to work on the HDAMA, but the S2885 is horribly broken. Good thing 
next week is my spring break :)

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


From bari at onelabs.com  Thu Mar 11 17:20:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Mar 11 17:20:01 2004
Subject: Is there a list or site for ...
In-Reply-To: <1C31A4EA8D9A024D8C6F40AB43CB120411616C@USHQ-EX1.columbia.csc>
References: <1C31A4EA8D9A024D8C6F40AB43CB120411616C@USHQ-EX1.columbia.csc>
Message-ID: <4050EB90.6030006@onelabs.com>

Lancashire, Pete wrote:

>  
> sorry to bother every one with a non linux bios question
> 
> I'm going to set up a small cluster at home for self
> education. cost as can be expected is a concern. For
> now i'm looking at a cluster of 4-8 boxes.
> 
> I've looked at using used PC's but the best prices
> i've seen for anything with a >1 Ghz Processor is
> $200 or more.
> 
> On the flip side Wal Mart of all places has a box for
> $200. No fancy or fast. but better then any used price
> ive come across.
> 
> Anyway.. does someone know of a mailing list or site
> for those of us who have not won a lottery ?

http://www.pricewatch.com/





From yfede at tiscali.it  Thu Mar 11 17:25:01 2004
From: yfede at tiscali.it (yfede)
Date: Thu Mar 11 17:25:01 2004
Subject: Elitegroup ECS K7SOM+ supported?
Message-ID: <001801c407ba$b83cf290$2f00a8c0@home>

Hello,
Is there any possibility to use linuxbios on a Elitegroup ECS K7SOM+
motherboard?
Do I have to get it from the CVS repository directly?
The link to the daily snapshot on www.linuxbios.org site doesn't seem to
work: http://cvs.sourceforge.net/cvstarballs/freebios-cvsroot.tar.gz

Thanks in advance,
    Fede.



From bari at onelabs.com  Thu Mar 11 17:40:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Mar 11 17:40:01 2004
Subject: Elitegroup ECS K7SOM+ supported?
In-Reply-To: <001801c407ba$b83cf290$2f00a8c0@home>
References: <001801c407ba$b83cf290$2f00a8c0@home>
Message-ID: <4050F03F.1030504@onelabs.com>

yfede wrote:

> Hello,
> Is there any possibility to use linuxbios on a Elitegroup ECS K7SOM+
> motherboard?
> Do I have to get it from the CVS repository directly?
> The link to the daily snapshot on www.linuxbios.org site doesn't seem to
> work: http://cvs.sourceforge.net/cvstarballs/freebios-cvsroot.tar.gz
> 

That link is bad, it should be:
http://cvs.sourceforge.net/cvstarballs/freebios-cvsroot.tar.bz2

-Bari




From stepan at suse.de  Thu Mar 11 17:42:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Mar 11 17:42:00 2004
Subject: Elitegroup ECS K7SOM+ supported?
In-Reply-To: <001801c407ba$b83cf290$2f00a8c0@home>
References: <001801c407ba$b83cf290$2f00a8c0@home>
Message-ID: <20040311225836.GA32509@suse.de>

* yfede <yfede at tiscali.it> [040311 23:46]:
> The link to the daily snapshot on www.linuxbios.org site doesn't seem to
> work: http://cvs.sourceforge.net/cvstarballs/freebios-cvsroot.tar.gz

http://snapshots.linuxbios.org/

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From YhLu at tyan.com  Thu Mar 11 18:00:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 11 18:00:01 2004
Subject: =?GB2312?B?tPC4tDogW0NPTU1JVF0gbGludXhiaW9zIDEuMS42Li4uLg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D11A@TYANWEB>

Eric,

After using you new code, I got

Any idea

Regards

YH


Found ELF candiate at offset 0
Loading Etherboot version: 5.2.0
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0x44d27 offset 0xb0 filesize 0x6010
(cleaned up) New segment addr 0x20000 size 0x44d27 offset 0xb0 filesize
0x6010
Loading Segment: addr: 0x00000000effb7f38 memsz: 0x0000000000016064 filesz:
0x0000000000006010
Clearing Segment: addr: 0x00000000effbdf48 memsz: 0x0000000000010054
Loading Segment: addr: 0x0000000000036064 memsz: 0x000000000002ecc3 filesz:
0x0000000000000000
    39:stream_skip() - overflowed source buffer
ERROR: Skip of 65620 bytes skiped 8000 bytes
Cannot Load ELF Image



-----????-----
???: YhLu 
????: 2004?3?11? 14:43
???: Hendricks David W.; Eric W. Biederman
??: LinuxBIOS
??: ??: [COMMIT] linuxbios 1.1.6....

I'm working on it.

-----????-----
???: Hendricks David W. [mailto:dwh at lanl.gov] 
????: 2004?3?11? 14:17
???: Eric W. Biederman
??: LinuxBIOS
??: Re: [COMMIT] linuxbios 1.1.6....

Looks to work on the HDAMA, but the S2885 is horribly broken. Good thing 
next week is my spring break :)

_______________________________________________
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 ollie at lanl.gov  Thu Mar 11 18:04:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 11 18:04:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?= [COMMIT] linuxbios 1.1.6....
In-Reply-To: <3174569B9743D511922F00A0C94314230466D11A@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D11A@TYANWEB>
Message-ID: <1079047518.10012.172.camel@exponential.lanl.gov>

On Thu, 2004-03-11 at 16:27, YhLu wrote:
> Eric,
> 
> After using you new code, I got
> 
> Any idea
> 
> Regards
> 

I can't even pass the ht enumeration. How did you do that ?

Ollie

> YH
> 
> 
> Found ELF candiate at offset 0
> Loading Etherboot version: 5.2.0
> Dropping non PT_LOAD segment
> New segment addr 0x20000 size 0x44d27 offset 0xb0 filesize 0x6010
> (cleaned up) New segment addr 0x20000 size 0x44d27 offset 0xb0 filesize
> 0x6010
> Loading Segment: addr: 0x00000000effb7f38 memsz: 0x0000000000016064 filesz:
> 0x0000000000006010
> Clearing Segment: addr: 0x00000000effbdf48 memsz: 0x0000000000010054
> Loading Segment: addr: 0x0000000000036064 memsz: 0x000000000002ecc3 filesz:
> 0x0000000000000000
>     39:stream_skip() - overflowed source buffer
> ERROR: Skip of 65620 bytes skiped 8000 bytes
> Cannot Load ELF Image
> 
> 
> 
> -----????-----
> ???: YhLu 
> ????: 2004?3?11? 14:43
> ???: Hendricks David W.; Eric W. Biederman
> ??: LinuxBIOS
> ??: ??: [COMMIT] linuxbios 1.1.6....
> 
> I'm working on it.
> 
> -----????-----
> ???: Hendricks David W. [mailto:dwh at lanl.gov] 
> ????: 2004?3?11? 14:17
> ???: Eric W. Biederman
> ??: LinuxBIOS
> ??: Re: [COMMIT] linuxbios 1.1.6....
> 
> Looks to work on the HDAMA, but the S2885 is horribly broken. Good thing 
> next week is my spring break :)
> 
> _______________________________________________
> 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 YhLu at tyan.com  Thu Mar 11 18:05:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 11 18:05:00 2004
Subject: =?GB2312?B?tPC4tDogW0NPTU1JVF0gbGludXhiaW9zIDEuMS42Li4uLg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D11C@TYANWEB>

Old code produce
Found ELF candiate at offset 0
Loading Etherboot version: 5.2.0
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0x44d27 offset 0xb0 filesize 0x6010
(cleaned up) New segment addr 0x20000 size 0x44d27 offset 0xb0 filesize
0x6010
Loading Segment: addr: 0x00000000dffd7d38 memsz: 0x0000000000006164 filesz:
0x0000000000006010
Clearing Segment: addr: 0x00000000dffddd48 memsz: 0x0000000000000154
Loading Segment: addr: 0x0000000000026164 memsz: 0x000000000003ebc3 filesz:
0x0000000000000000
Clearing Segment: addr: 0x0000000000026164 memsz: 0x000000000003ebc3
Jumping to boot code at 0x20000
ROM segment 0x0000 length 0x0000 reloc 0x00020000
CPU 1855 Mhz
Etherboot 5.2.0 (GPL) http://etherboot.org Tagged ELF for [TG3][IDE]
Relocating _text from: [00026010,00066440) to [dfebfbd0,dff00000)
Probing pci nic...

-----????-----
???: YhLu 
????: 2004?3?11? 15:28
???: YhLu; Hendricks David W.; Eric W. Biederman
??: LinuxBIOS
??: ??: [COMMIT] linuxbios 1.1.6....

Eric,

After using you new code, I got

Any idea

Regards

YH


Found ELF candiate at offset 0
Loading Etherboot version: 5.2.0
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0x44d27 offset 0xb0 filesize 0x6010
(cleaned up) New segment addr 0x20000 size 0x44d27 offset 0xb0 filesize
0x6010
Loading Segment: addr: 0x00000000effb7f38 memsz: 0x0000000000016064 filesz:
0x0000000000006010
Clearing Segment: addr: 0x00000000effbdf48 memsz: 0x0000000000010054
Loading Segment: addr: 0x0000000000036064 memsz: 0x000000000002ecc3 filesz:
0x0000000000000000
    39:stream_skip() - overflowed source buffer
ERROR: Skip of 65620 bytes skiped 8000 bytes
Cannot Load ELF Image



-----????-----
???: YhLu 
????: 2004?3?11? 14:43
???: Hendricks David W.; Eric W. Biederman
??: LinuxBIOS
??: ??: [COMMIT] linuxbios 1.1.6....

I'm working on it.

-----????-----
???: Hendricks David W. [mailto:dwh at lanl.gov] 
????: 2004?3?11? 14:17
???: Eric W. Biederman
??: LinuxBIOS
??: Re: [COMMIT] linuxbios 1.1.6....

Looks to work on the HDAMA, but the S2885 is horribly broken. Good thing 
next week is my spring break :)

_______________________________________________
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 YhLu at tyan.com  Thu Mar 11 18:12:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 11 18:12:01 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogW0NPTU1JVF0gbGludXhiaW9zIDEuMS42Li4u?=
	=?GB2312?B?Lg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D11E@TYANWEB>

I'm testing that on s2880 now.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?11? 15:25
???: YhLu
??: Hendricks David W.; Eric W. Biederman; LinuxBIOS
??: Re: ??: [COMMIT] linuxbios 1.1.6....

On Thu, 2004-03-11 at 16:27, YhLu wrote:
> Eric,
> 
> After using you new code, I got
> 
> Any idea
> 
> Regards
> 

I can't even pass the ht enumeration. How did you do that ?

Ollie

> YH
> 
> 
> Found ELF candiate at offset 0
> Loading Etherboot version: 5.2.0
> Dropping non PT_LOAD segment
> New segment addr 0x20000 size 0x44d27 offset 0xb0 filesize 0x6010
> (cleaned up) New segment addr 0x20000 size 0x44d27 offset 0xb0 filesize
> 0x6010
> Loading Segment: addr: 0x00000000effb7f38 memsz: 0x0000000000016064
filesz:
> 0x0000000000006010
> Clearing Segment: addr: 0x00000000effbdf48 memsz: 0x0000000000010054
> Loading Segment: addr: 0x0000000000036064 memsz: 0x000000000002ecc3
filesz:
> 0x0000000000000000
>     39:stream_skip() - overflowed source buffer
> ERROR: Skip of 65620 bytes skiped 8000 bytes
> Cannot Load ELF Image
> 
> 
> 
> -----????-----
> ???: YhLu 
> ????: 2004?3?11? 14:43
> ???: Hendricks David W.; Eric W. Biederman
> ??: LinuxBIOS
> ??: ??: [COMMIT] linuxbios 1.1.6....
> 
> I'm working on it.
> 
> -----????-----
> ???: Hendricks David W. [mailto:dwh at lanl.gov] 
> ????: 2004?3?11? 14:17
> ???: Eric W. Biederman
> ??: LinuxBIOS
> ??: Re: [COMMIT] linuxbios 1.1.6....
> 
> Looks to work on the HDAMA, but the S2885 is horribly broken. Good thing 
> next week is my spring break :)
> 
> _______________________________________________
> 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 YhLu at tyan.com  Thu Mar 11 22:32:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 11 22:32:00 2004
Subject: (no subject)
Message-ID: <3174569B9743D511922F00A0C94314230466D155@TYANWEB>

Ron,

Please commit the changes in tyan dir to make tyan MB to work with 1.1.6
that Eric committed today.

Only two is outside of tyan dir.

Src/southbridge/amd/amd8131/amd8131_bridge.c

static void ioapic_enable(device_t dev)
{       
        uint32_t value;
        value = pci_read_config32(dev, 0x44);
        if (dev->enable) {
                value |= ((1 << 1) | (1 << 0));
        } else {
                value &= ~((1 << 1) | (1 << 0));
        }
        pci_write_config32(dev, 0x44, value);
        
//BY LYH
        value = pci_read_config32(dev, 0x4);
        value |= 6;
        pci_write_config32(dev, 0x4, value);
//BY LYH END
}

The other one is amd8151_agp.c

Regards

YH


-------------- next part --------------
A non-text attachment was scrubbed...
Name: fb2_tyan_change_021104.diff.bz2
Type: application/octet-stream
Size: 15896 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040311/2a966192/attachment.obj>

From bios-list at cox.net  Thu Mar 11 23:08:01 2004
From: bios-list at cox.net (Edgar Lovecraft)
Date: Thu Mar 11 23:08:01 2004
Subject: Tyan Tomcat i845GL (S2098)
Message-ID: <jbm.20040311222927.86490a44@User21>

I am not new to linux, just linuxBIOS :)
cool thing I think, thanks to all for making such a thing possible.
Now for my question....
I am looking to develop a linuxbios for the Tyan Tomcat i845GL (S2098) MB,
it uses the i845GL chipset.  I have seen some posts in the archives about
'do you support this yet' but did not find any conclusive answers.  I am
very willing to make this work if no else has, but I do need some pointers
(or would greatly appreciate them) to get started.  This board does have a
4MB flash so I would like to keep the BIOS in the BIOS (basically just be
able to boot and have all that I can cram in the space available).
As I said, I do have plenty of linux compile experience, and perhaps I am
being a little gun shy on this, but I really really do not want to go
and start makeing expensive paper weights.
So any and all comments/pointers/help would be greatly appreciated, as
would any pointers to 'best practices' and the such.
Thanks again in advance!

snipit from the Tyan spec sheet if any of this helps:
Processor
 ? Single mPGA478 ZIF socket
 ? Supports one Intel? Pentium? 4 processor or
    Celeron (mPGA478) processor
 ? Onboard VRM (VRM 9.1 spec)
 ? Front-Side Bus support for 400MHz

Chipset
 ? Intel? 845GL chipset
 ? MCH + ICH4 + FWH
 ? ITE IT8712F LPC I/O ASIC
--

--EAL--




From rminnich at lanl.gov  Thu Mar 11 23:27:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 11 23:27:01 2004
Subject: (no subject)
In-Reply-To: <3174569B9743D511922F00A0C94314230466D155@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403112148180.22995-100000@maxroach.lanl.gov>

ok, we will get this tomorrow morning and test it here as well. 

It would also be helpful if you add a comment for such changes but we will 
try to understand what you have done.

ron



From YhLu at tyan.com  Thu Mar 11 23:42:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 11 23:42:01 2004
Subject: Tyan Changes for 1.1.6
Message-ID: <3174569B9743D511922F00A0C94314230466D157@TYANWEB>

1. AMD 8131: ioapic : PCI master mem/io enable. The segment I have added in
old version, in 1.1.6 Eric remove that. --- It is needed for other MBs
except arima --because it connects all apic to 8111.
2. Some correction in AMD8151.
3. Add superio/Winbond/w83627hf.
4. other changs in tyan dir.  (auto.c failover.c cmos.layout from arima dir)
	(Config.lb changes for option_table.h building and superio ...)
	(Increase the heap size to make elfboot work).

YH


-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?3?11? 20:49
???: YhLu
??: linuxbios at clustermatic.org
??: Re: (no subject)

ok, we will get this tomorrow morning and test it here as well. 

It would also be helpful if you add a comment for such changes but we will 
try to understand what you have done.

ron


From YhLu at tyan.com  Fri Mar 12 00:07:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 00:07:00 2004
Subject: =?GB2312?B?tPC4tDogVHlhbiBDaGFuZ2VzIGZvciAxLjEuNg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D15A@TYANWEB>

Eric,

In the 1.1.6, you have move clearing memory from auto.c to k8/cpufixup.c. Is
there any way to disable it for fast booting?

Regards

YH

-----????-----
???: YhLu 
????: 2004?3?11? 21:10
???: ron minnich
??: linuxbios at clustermatic.org
??: Tyan Changes for 1.1.6

1. AMD 8131: ioapic : PCI master mem/io enable. The segment I have added in
old version, in 1.1.6 Eric remove that. --- It is needed for other MBs
except arima --because it connects all apic to 8111.
2. Some correction in AMD8151.
3. Add superio/Winbond/w83627hf.
4. other changs in tyan dir.  (auto.c failover.c cmos.layout from arima dir)
	(Config.lb changes for option_table.h building and superio ...)
	(Increase the heap size to make elfboot work).

YH


-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?3?11? 20:49
???: YhLu
??: linuxbios at clustermatic.org
??: Re: (no subject)

ok, we will get this tomorrow morning and test it here as well. 

It would also be helpful if you add a comment for such changes but we will 
try to understand what you have done.

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


From YhLu at tyan.com  Fri Mar 12 01:26:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 01:26:00 2004
Subject: =?GB2312?B?tPC4tDogVHlhbiBDaGFuZ2VzIGZvciAxLjEuNg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D15D@TYANWEB>

Eric,

Have you test the 1.1.6 with kernel 2.6?

Regards

YH.

-----????-----
???: YhLu 
????: 2004?3?11? 21:34
???: YhLu; ron minnich
??: linuxbios at clustermatic.org
??: ??: Tyan Changes for 1.1.6

Eric,

In the 1.1.6, you have move clearing memory from auto.c to k8/cpufixup.c. Is
there any way to disable it for fast booting?

Regards

YH

-----????-----
???: YhLu 
????: 2004?3?11? 21:10
???: ron minnich
??: linuxbios at clustermatic.org
??: Tyan Changes for 1.1.6

1. AMD 8131: ioapic : PCI master mem/io enable. The segment I have added in
old version, in 1.1.6 Eric remove that. --- It is needed for other MBs
except arima --because it connects all apic to 8111.
2. Some correction in AMD8151.
3. Add superio/Winbond/w83627hf.
4. other changs in tyan dir.  (auto.c failover.c cmos.layout from arima dir)
	(Config.lb changes for option_table.h building and superio ...)
	(Increase the heap size to make elfboot work).

YH


-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?3?11? 20:49
???: YhLu
??: linuxbios at clustermatic.org
??: Re: (no subject)

ok, we will get this tomorrow morning and test it here as well. 

It would also be helpful if you add a comment for such changes but we will 
try to understand what you have done.

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


From maillists at petrolhead.com  Fri Mar 12 05:46:01 2004
From: maillists at petrolhead.com (maillists at petrolhead.com)
Date: Fri Mar 12 05:46:01 2004
Subject: How does pre memory C code work on K8.
Message-ID: <10D204DE080CA744A64FC11EBC67A177093D30@portacabin.no-ip.org>

Something has been troubling me for some time which is how the code manages
to run before the memory controllers are configured. The assembler I can see
has no accesses to memory, but the C code does, is their some magic gcc
switch that makes it be entirely register based?

It's troubled me for a while one the memories up then I'm more than happy
but before that I'm a little bemused.

Many thanks

Chris


From stepan at suse.de  Fri Mar 12 06:08:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Fri Mar 12 06:08:01 2004
Subject: How does pre memory C code work on K8.
In-Reply-To: <10D204DE080CA744A64FC11EBC67A177093D30@portacabin.no-ip.org>
References: <10D204DE080CA744A64FC11EBC67A177093D30@portacabin.no-ip.org>
Message-ID: <20040312112908.GA23159@suse.de>

* maillists at petrolhead.com <maillists at petrolhead.com> [040312 12:04]:
> Something has been troubling me for some time which is how the code manages
> to run before the memory controllers are configured. The assembler I can see
> has no accesses to memory, but the C code does, is their some magic gcc
> switch that makes it be entirely register based?

The early initialization code of LinuxBIOS v1.1.x (upcoming v2) is
written in C, but it does not use GCC for compilation, but Eric
Biederman's ROMCC. This fine piece of software compiles C code to
Assembler that does not use any RAM at all. All values are kept in
registers. This allows only a certain complexity of the algorithms used,
but it is perfectly fine to get RAM working.

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From bari at onelabs.com  Fri Mar 12 08:39:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Mar 12 08:39:00 2004
Subject: Tyan Tomcat i845GL (S2098)
In-Reply-To: <jbm.20040311222927.86490a44@User21>
References: <jbm.20040311222927.86490a44@User21>
Message-ID: <4051C2DB.1060007@onelabs.com>

Edgar Lovecraft wrote:

> I am looking to develop a linuxbios for the Tyan Tomcat i845GL (S2098) MB,
> it uses the i845GL chipset.  

Send LSPCI.

-Bari




From rminnich at lanl.gov  Fri Mar 12 09:41:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 09:41:01 2004
Subject: How does pre memory C code work on K8.
In-Reply-To: <10D204DE080CA744A64FC11EBC67A177093D30@portacabin.no-ip.org>
Message-ID: <Pine.LNX.4.44.0403120802150.22995-100000@maxroach.lanl.gov>

On Fri, 12 Mar 2004 maillists at petrolhead.com wrote:

> Something has been troubling me for some time which is how the code manages
> to run before the memory controllers are configured. The assembler I can see
> has no accesses to memory, but the C code does, is their some magic gcc
> switch that makes it be entirely register based?

check out romcc. uses no memory. very neat.

ron



From rminnich at lanl.gov  Fri Mar 12 10:03:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 10:03:00 2004
Subject: your mail
In-Reply-To: <3174569B9743D511922F00A0C94314230466D155@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403120823370.29105-100000@maxroach.lanl.gov>

On Thu, 11 Mar 2004, YhLu wrote:

> Please commit the changes in tyan dir to make tyan MB to work with 1.1.6
> that Eric committed today.

These patches are now applied. 

Please test. 

Somebody please tell me why we have src/pc80/serial.c and 
src/pc80/serial_2.c ...

ron
> //BY LYH
>         value = pci_read_config32(dev, 0x4);
>         value |= 6;
>         pci_write_config32(dev, 0x4, value);
> //BY LYH END


if anyone wants to replace '6' with a symbolic name, that is fine by me 
:-)

ron



From ebiederman at lnxi.com  Fri Mar 12 10:25:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 12 10:25:01 2004
Subject: OEM looking at LinuxBIOS
In-Reply-To: <000501c40834$38e28f30$3b0201c0@hhengineering.local>
References: <000501c40834$38e28f30$3b0201c0@hhengineering.local>
Message-ID: <m3r7vyoyge.fsf@maxwell.lnxi.com>

"Anthony Winner" <awinner at walkabout-comp.com> writes:

> Eric,
> 
> Thanks, will start with the freebios2 tree. Which of the howto's is a good
> 'from scratch' roadmap to get me started....

I really don't know the state of the howto's at this point.

Generally good advice is to examine another port that is similar.

Eric

 
> Anthony Winner
> WalkAbout Computers
> awinner at walkabout-comp.com
> (561)712-1200  x221
> 
> 
> -----Original Message-----
> From: linuxbios-admin at clustermatic.org
> [mailto:linuxbios-admin at clustermatic.org]On Behalf Of Eric W. Biederman
> Sent: Thursday, March 11, 2004 11:06 AM
> To: Hendricks David W.
> Cc: Anthony Winner; linuxbios at clustermatic.org
> Subject: Re: OEM looking at LinuxBIOS
> 
> 
> "Hendricks David W." <dwh at lanl.gov> writes:
> 
> > There is already 82803 and 82801ca code in the freebios1 tree, might as
> > well put it to good use :) I think Eric Beiderman was even able to fix
> > SPD, at least on the MCH4 (Or something).
> >
> > On Tue, 9 Mar 2004, Anthony Winner wrote:
> >
> > > Hello all,
> > >
> > > I work for a OEM and I'm playing with the idea of using linuxBIOS, I
> have
> > > all of the technical info for the machine short of the actual source
> code to
> > > the Phoenix BIOS we use now as it was done by a contractor before I
> joined
> > > the company.
> > >
> > > Are there any pointers for a 'from scratch', implementation?
> > >
> > > Should I start with the old code or start fresh from the new freebios2
> tree?
> > >
> > > For reference, the machine is a Intel PIII with a 82830 Northbridge, a
> > > 82801ca Southbridge, TI pci1450 card bus controller, and a pair of SMC
> SIO
> > > chips....
> 
> I don't think we have good support for th 82830 at this time so the
> freebios2
> tree would be the one to work with.  You get romcc so you can code the
> memory initialization in C.  If you know what you are doing a huge chunk of
> assembly is tolerable.  But doing things in C prevents a lot of stupid
> typos.
> 
> I just looked the code in the freebios1 tree for the 82830 does not even
> attempt to do SPD based memory initialization so it will not work with
> arbitrary memory.  So definitely freebios2 using some of the freebios1
> code as reference.
> 
> I don't think the freebios1 tree can code with a pair of superio chips
> either.
> 
> The freebios2 tree comes with multiple devices of the same type trivially.
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


From rminnich at lanl.gov  Fri Mar 12 10:41:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 10:41:01 2004
Subject: OEM looking at LinuxBIOS
In-Reply-To: <m3r7vyoyge.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403120902170.29105-100000@maxroach.lanl.gov>

On 12 Mar 2004, Eric W. Biederman wrote:

> I really don't know the state of the howto's at this point.

we have yet to do a HOWTO for freebios2, in part because the tree has been 
in so much flux that any HOWTO would be out of date very quickly.

ron



From ebiederman at lnxi.com  Fri Mar 12 11:13:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 12 11:13:00 2004
Subject: =?gb2312?b?tPC4tA==?=: Tyan Changes for 1.1.6
In-Reply-To: <3174569B9743D511922F00A0C94314230466D15A@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D15A@TYANWEB>
Message-ID: <m365danhko.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> In the 1.1.6, you have move clearing memory from auto.c to k8/cpufixup.c. Is
> there any way to disable it for fast booting?

Don't enable ECC.

Memory clearing is only done for correctness.  ECC memory does not
work properly unless initialized.

I think the Opteron setup now is down to the minimal needed for
things to work.  You only observe one reset correct?

> 1. AMD 8131: ioapic : PCI master mem/io enable. The segment I have added in
> old version, in 1.1.6 Eric remove that. --- It is needed for other MBs
> except arima --because it connects all apic to 8111.

As Ron mentioned later this needs a comment.  In the general case we should
not be enabling bus master DMA by default.  I tend to remove bus master
enables before remembering any special circumstances of the chip.

> 2. Some correction in AMD8151.
> 3. Add superio/Winbond/w83627hf.

Thanks that looks correct.  And it was nice to see my changes were
that simple to follow.

> 4. other changs in tyan dir.  (auto.c failover.c cmos.layout from arima dir)
> 	(Config.lb changes for option_table.h building and superio ...)
> 	(Increase the heap size to make elfboot work).

Hmm.  Can we throw in a sanity check to ensure we don't run out of heap?
I assume that is what was happening.

Does the 4-way s4880 work?  I'm not quite certain how my changes would
affect it.

Eric


From ebiederman at lnxi.com  Fri Mar 12 11:16:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 12 11:16:00 2004
Subject: =?gb2312?b?tPC4tA==?=: Tyan Changes for 1.1.6
In-Reply-To: <3174569B9743D511922F00A0C94314230466D15D@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D15D@TYANWEB>
Message-ID: <m31xnynhiw.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> Have you test the 1.1.6 with kernel 2.6?

Not the final version but earlier ones.

2.6 is fun because the option names have changed, so it is easy
to leave things like serial console disabled.

Eric


From rminnich at lanl.gov  Fri Mar 12 11:18:33 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 11:18:33 2004
Subject: =?gb2312?b?tPC4tA==?=: Tyan Changes for 1.1.6
In-Reply-To: <m365danhko.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403120934471.29105-100000@maxroach.lanl.gov>

On 12 Mar 2004, Eric W. Biederman wrote:

> Don't enable ECC.

Or, one thing I'd like to try:
	- make sure ECC interrupts are disabled
	- enable cache
	- clear memory with cache enabled
	- cld to make sure it's all flushed

I am assuming you are writing with cache disabled to avoid ecc errors on 
loading cache lines. It's a shame we can't do the 'zero-filled cache line' 
trick that some architectures allow, as you can ZFOD a cache line and 
blast it out to memory -- or can we do that trick? But I wonder if this 
other hack would work. Anyone tried it?

> I think the Opteron setup now is down to the minimal needed for
> things to work.  You only observe one reset correct?

we only see one I think.

> As Ron mentioned later this needs a comment.  In the general case we should
> not be enabling bus master DMA by default.  I tend to remove bus master
> enables before remembering any special circumstances of the chip.

Or dynamically figuring it out would be best. What are the rules here? I 
have not checked. How would you know to enable this dynamically?

> > 3. Add superio/Winbond/w83627hf.
> 
> Thanks that looks correct.  And it was nice to see my changes were
> that simple to follow.

Your new pnp stuff looks very well done.

ron



From rminnich at lanl.gov  Fri Mar 12 11:22:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 11:22:00 2004
Subject: =?gb2312?b?tPC4tA==?=: Tyan Changes for 1.1.6
In-Reply-To: <m31xnynhiw.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403120938480.29105-100000@maxroach.lanl.gov>

On 12 Mar 2004, Eric W. Biederman wrote:

> 2.6 is fun because the option names have changed, so it is easy
> to leave things like serial console disabled.
> 

I think David Hendricks tried this. David? 
ron



From ebiederman at lnxi.com  Fri Mar 12 11:28:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 12 11:28:01 2004
Subject: How does pre memory C code work on K8.
In-Reply-To: <10D204DE080CA744A64FC11EBC67A177093D30@portacabin.no-ip.org>
References: <10D204DE080CA744A64FC11EBC67A177093D30@portacabin.no-ip.org>
Message-ID: <m3wu5qm2au.fsf@maxwell.lnxi.com>

maillists at petrolhead.com writes:

> Something has been troubling me for some time which is how the code manages
> to run before the memory controllers are configured. The assembler I can see
> has no accesses to memory, but the C code does, is their some magic gcc
> switch that makes it be entirely register based?

Unfortunately gcc's architecture does not appear to have the necessary
support so I wrote romcc to do this.
 
> It's troubled me for a while one the memories up then I'm more than happy
> but before that I'm a little bemused.

It is also possible to store data in the dcache if you can reliably
lock in cache blocks.  Your code still needs to run out of NOR flash.
The PowerPC supports this.  On x86 I have not seen any publicly
documented and supported way to do this yet...  I have done it and
liked the results so much I implemented romcc.

Eric


From ollie at lanl.gov  Fri Mar 12 11:32:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 12 11:32:00 2004
Subject: Tyan Changes for 1.1.6
In-Reply-To: <3174569B9743D511922F00A0C94314230466D157@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D157@TYANWEB>
Message-ID: <1079110426.10012.178.camel@exponential.lanl.gov>

On Thu, 2004-03-11 at 22:09, YhLu wrote:
> 1. AMD 8131: ioapic : PCI master mem/io enable. The segment I have added in
> old version, in 1.1.6 Eric remove that. --- It is needed for other MBs
> except arima --because it connects all apic to 8111.
> 2. Some correction in AMD8151.
> 3. Add superio/Winbond/w83627hf.

Are you mix up with w83627hf and w83627thf ? In code it is w83627hf but 
in in the source code directory it is w83627thf.

Ollie




From rminnich at lanl.gov  Fri Mar 12 11:40:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 11:40:01 2004
Subject: How does pre memory C code work on K8.
In-Reply-To: <m3wu5qm2au.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403121000330.29105-100000@maxroach.lanl.gov>

On 12 Mar 2004, Eric W. Biederman wrote:

> It is also possible to store data in the dcache if you can reliably
> lock in cache blocks.  Your code still needs to run out of NOR flash.
> The PowerPC supports this.  On x86 I have not seen any publicly
> documented and supported way to do this yet...  I have done it and
> liked the results so much I implemented romcc.

Note that Greg Watson's PPC port of LinuxBIOS uses this 'early cacne' 
support. 

It would be nice to see this capability in the K8++

ron



From ollie at lanl.gov  Fri Mar 12 11:42:43 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 12 11:42:43 2004
Subject: your mail
In-Reply-To: <Pine.LNX.4.44.0403120823370.29105-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403120823370.29105-100000@maxroach.lanl.gov>
Message-ID: <1079110896.10012.180.camel@exponential.lanl.gov>

On Fri, 2004-03-12 at 08:24, ron minnich wrote:
> On Thu, 11 Mar 2004, YhLu wrote:
> 
> > Please commit the changes in tyan dir to make tyan MB to work with 1.1.6
> > that Eric committed today.
> 
> These patches are now applied. 
> 
> Please test. 


Ron, did you commited everything in YhLu's patch ? There
are some files missing.

Ollie

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



From rminnich at lanl.gov  Fri Mar 12 11:46:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 11:46:01 2004
Subject: Tyan Changes for 1.1.6
In-Reply-To: <1079110426.10012.178.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403121001400.29105-100000@maxroach.lanl.gov>

On Fri, 12 Mar 2004, Li-Ta Lo wrote:

> Are you mix up with w83627hf and w83627thf ? In code it is w83627hf but 
> in in the source code directory it is w83627thf.

I screwed up and forgot to do a cvs add!

hold on.

ron




From rminnich at lanl.gov  Fri Mar 12 11:48:37 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 11:48:37 2004
Subject: Tyan Changes for 1.1.6
In-Reply-To: <1079110426.10012.178.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403121003050.29105-100000@maxroach.lanl.gov>

On Fri, 12 Mar 2004, Li-Ta Lo wrote:

> Are you mix up with w83627hf and w83627thf ? In code it is w83627hf but 
> in in the source code directory it is w83627thf.

committed, thanks for catching my mistake Ollie!

Please cvs update everyone :-)

ron



From rminnich at lanl.gov  Fri Mar 12 11:51:22 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 11:51:22 2004
Subject: your mail
In-Reply-To: <1079110896.10012.180.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403121005130.29105-100000@maxroach.lanl.gov>

On Fri, 12 Mar 2004, Li-Ta Lo wrote:

> Ron, did you commited everything in YhLu's patch ? There
> are some files missing.

any others? send me the list. sorry.

ron



From ebiederman at lnxi.com  Fri Mar 12 11:55:02 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 12 11:55:02 2004
Subject: =?gb2312?b?tPC4tA==?=: Tyan Changes for 1.1.6
In-Reply-To: <Pine.LNX.4.44.0403120934471.29105-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403120934471.29105-100000@maxroach.lanl.gov>
Message-ID: <m37jxqhtq2.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 12 Mar 2004, Eric W. Biederman wrote:
> 
> > Don't enable ECC.
> 
> Or, one thing I'd like to try:
> 	- make sure ECC interrupts are disabled
> 	- enable cache
> 	- clear memory with cache enabled
> 	- cld to make sure it's all flushed
> 
> I am assuming you are writing with cache disabled to avoid ecc errors on 
> loading cache lines. It's a shame we can't do the 'zero-filled cache line' 
> trick that some architectures allow, as you can ZFOD a cache line and 
> blast it out to memory -- or can we do that trick? But I wonder if this 
> other hack would work. Anyone tried it?

I am setting the caching attributes on the memory I am clearing to
Write-Combining in the MTRRs which is better than ZFOD because it
bypasses the cache.  This runs at nearly the theoretical speed of
memory and has done so for years.  This is the way I have always coded
this on x86.  I guess you have not needed to look at that section
of code?

> > I think the Opteron setup now is down to the minimal needed for
> > things to work.  You only observe one reset correct?
> 
> we only see one I think.

The strategy is I setup HT and everything very early with what should
work.  And then in the generic code I come back and redo the
calculations but I don't trigger a reset unless things are incorrect.
So if the early code is complete there should only be a single reset
very early on in the boot process.  If not you will see additional
resets.

> > As Ron mentioned later this needs a comment.  In the general case we should
> > not be enabling bus master DMA by default.  I tend to remove bus master
> > enables before remembering any special circumstances of the chip.
> 
> Or dynamically figuring it out would be best. What are the rules here? I 
> have not checked. How would you know to enable this dynamically?

The rules are unless something is a legacy device the device driver
has enough information to enable bus mastering.  Generating interrupts
is part of what bus mastering enables.  The ioapic on the 8131 is
a legacy ISA type device so we need to enable bus mastering in
LinuxBIOS.  The linux kernel does not have enough information to do
that.


> > > 3. Add superio/Winbond/w83627hf.
> > 
> > Thanks that looks correct.  And it was nice to see my changes were
> > that simple to follow.
> 
> Your new pnp stuff looks very well done.

Thanks :)

Eric



From ollie at lanl.gov  Fri Mar 12 11:58:53 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 12 11:58:53 2004
Subject: your mail
In-Reply-To: <Pine.LNX.4.44.0403121005130.29105-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403121005130.29105-100000@maxroach.lanl.gov>
Message-ID: <1079111528.10012.182.camel@exponential.lanl.gov>

On Fri, 2004-03-12 at 10:05, ron minnich wrote:
> On Fri, 12 Mar 2004, Li-Ta Lo wrote:
> 
> > Ron, did you commited everything in YhLu's patch ? There
> > are some files missing.
> 
> any others? send me the list. sorry.
> 

It builds now, I am burnning the image.

Ollie

> ron
> 



From ebiederman at lnxi.com  Fri Mar 12 12:01:30 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 12 12:01:30 2004
Subject: Tyan Changes for 1.1.6
In-Reply-To: <1079110426.10012.178.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230466D157@TYANWEB>
	<1079110426.10012.178.camel@exponential.lanl.gov>
Message-ID: <m3u10uf094.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Thu, 2004-03-11 at 22:09, YhLu wrote:
> > 1. AMD 8131: ioapic : PCI master mem/io enable. The segment I have added in
> > old version, in 1.1.6 Eric remove that. --- It is needed for other MBs
> > except arima --because it connects all apic to 8111.
> > 2. Some correction in AMD8151.
> > 3. Add superio/Winbond/w83627hf.
> 
> Are you mix up with w83627hf and w83627thf ? In code it is w83627hf but 
> in in the source code directory it is w83627thf.

His patch adds a w83627hf.  The w83627thf is still a broken clone of the
NSC/pc87360 and should either be fixed or killed.

Eric


From rminnich at lanl.gov  Fri Mar 12 12:05:05 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 12:05:05 2004
Subject: =?gb2312?b?tPC4tA==?=: Tyan Changes for 1.1.6
In-Reply-To: <m37jxqhtq2.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403121018370.29105-100000@maxroach.lanl.gov>

On 12 Mar 2004, Eric W. Biederman wrote:

> I am setting the caching attributes on the memory I am clearing to
> Write-Combining in the MTRRs which is better than ZFOD because it
> bypasses the cache.  This runs at nearly the theoretical speed of
> memory and has done so for years.  This is the way I have always coded
> this on x86.  I guess you have not needed to look at that section
> of code?

That's how I remember it working, but I thought maybe something special 
had been done on K8 as it is just not running fast. 

We may be talking a different ZFOD. In MIPS you could create a ZFOD cache 
line in one instruction and blast it to memory when invalidate happened. I 
don't see the K8 beating this but I will have to look more at the code. 

I just noticed that clearing a Gbyte takes several tens of seconds.  I
don't see how this could be theoretical memory speed. Something's not
working right. We'll look some more. Overall it's still quite nice, so 
don't take my comments as anything but observations. 


ron



From rminnich at lanl.gov  Fri Mar 12 12:07:40 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 12:07:40 2004
Subject: Tyan Changes for 1.1.6
In-Reply-To: <m3u10uf094.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403121022380.29105-100000@maxroach.lanl.gov>

On 12 Mar 2004, Eric W. Biederman wrote:

> His patch adds a w83627hf.  The w83627thf is still a broken clone of the
> NSC/pc87360 and should either be fixed or killed.

yeah I started that for the IBM e325 and in the middle got yanked off for 
a different fire drill :-(

which will show the value of waiting, since between Eric and YhLu my work 
goes to almost zero :-)

ron



From ollie at lanl.gov  Fri Mar 12 12:10:24 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 12 12:10:24 2004
Subject: your mail
In-Reply-To: <1079111528.10012.182.camel@exponential.lanl.gov>
References: <Pine.LNX.4.44.0403121005130.29105-100000@maxroach.lanl.gov>
	 <1079111528.10012.182.camel@exponential.lanl.gov>
Message-ID: <1079112377.10012.184.camel@exponential.lanl.gov>

On Fri, 2004-03-12 at 10:12, Li-Ta Lo wrote:
> On Fri, 2004-03-12 at 10:05, ron minnich wrote:
> > On Fri, 12 Mar 2004, Li-Ta Lo wrote:
> > 
> > > Ron, did you commited everything in YhLu's patch ? There
> > > are some files missing.
> > 
> > any others? send me the list. sorry.
> > 
> 
> It builds now, I am burnning the image.
> 


Bad news, it stops right after ht_reset, just like 
yeaterday :-(.

Ollie




From rminnich at lanl.gov  Fri Mar 12 12:13:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 12:13:01 2004
Subject: your mail
In-Reply-To: <1079112377.10012.184.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403121033110.29105-100000@maxroach.lanl.gov>

On Fri, 12 Mar 2004, Li-Ta Lo wrote:

> Bad news, it stops right after ht_reset, just like 
> yeaterday :-(.

so, to sum up, the 2885 fails today, but the HDAMA works, right?

ron



From ollie at lanl.gov  Fri Mar 12 12:16:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 12 12:16:01 2004
Subject: your mail
In-Reply-To: <Pine.LNX.4.44.0403121033110.29105-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403121033110.29105-100000@maxroach.lanl.gov>
Message-ID: <1079113029.10012.186.camel@exponential.lanl.gov>

On Fri, 2004-03-12 at 10:33, ron minnich wrote:
> On Fri, 12 Mar 2004, Li-Ta Lo wrote:
> 
> > Bad news, it stops right after ht_reset, just like 
> > yeaterday :-(.
> 
> so, to sum up, the 2885 fails today, but the HDAMA works, right?
> 

haven't tried on hdama yet. hdama works yeaterday.

Ollie

> ron
> 



From ebiederman at lnxi.com  Fri Mar 12 12:21:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 12 12:21:01 2004
Subject: Tyan Changes for 1.1.6
In-Reply-To: <Pine.LNX.4.44.0403121022380.29105-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403121022380.29105-100000@maxroach.lanl.gov>
Message-ID: <m3wu5qdkf4.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 12 Mar 2004, Eric W. Biederman wrote:
> 
> > His patch adds a w83627hf.  The w83627thf is still a broken clone of the
> > NSC/pc87360 and should either be fixed or killed.
> 
> yeah I started that for the IBM e325 and in the middle got yanked off for 
> a different fire drill :-(
> 
> which will show the value of waiting, since between Eric and YhLu my work 
> goes to almost zero :-)

Well some days you do get lucky.  If every one waited nothing would
ever happen.


Eric


From rminnich at lanl.gov  Fri Mar 12 12:24:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 12:24:00 2004
Subject: Tyan Changes for 1.1.6
In-Reply-To: <m3wu5qdkf4.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403121044210.29105-100000@maxroach.lanl.gov>

On 12 Mar 2004, Eric W. Biederman wrote:

> Well some days you do get lucky.  If every one waited nothing would
> ever happen.

I don't know, maybe if we all waited then cosmic rays would write all our 
software for us. Of course it might take a while.

ron



From ebiederman at lnxi.com  Fri Mar 12 12:32:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 12 12:32:01 2004
Subject: Tyan Changes for 1.1.6
In-Reply-To: <Pine.LNX.4.44.0403121044210.29105-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403121044210.29105-100000@maxroach.lanl.gov>
Message-ID: <m3u10u6j38.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 12 Mar 2004, Eric W. Biederman wrote:
> 
> > Well some days you do get lucky.  If every one waited nothing would
> > ever happen.
> 
> I don't know, maybe if we all waited then cosmic rays would write all our 
> software for us. Of course it might take a while.

Ron even the labs don't have enough machines to catch this event
when it happens.  Much less the rest of us on smaller budgets...

Besides which I think the cosmic rays and their kin will succeed in taking
apart my body before they manage to write good code.

Ron do you know if on the physicists have succeeded in making an improbability
generate yet?  That would solve so many things.  Heck someone might
even figure what question 42 is the answer to.

Eric


From ebiederman at lnxi.com  Fri Mar 12 12:35:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 12 12:35:01 2004
Subject: your mail
In-Reply-To: <1079112377.10012.184.camel@exponential.lanl.gov>
References: <Pine.LNX.4.44.0403121005130.29105-100000@maxroach.lanl.gov>
	<1079111528.10012.182.camel@exponential.lanl.gov>
	<1079112377.10012.184.camel@exponential.lanl.gov>
Message-ID: <m3oer26j17.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Fri, 2004-03-12 at 10:12, Li-Ta Lo wrote:
> > On Fri, 2004-03-12 at 10:05, ron minnich wrote:
> > > On Fri, 12 Mar 2004, Li-Ta Lo wrote:
> > > 
> > > > Ron, did you commited everything in YhLu's patch ? There
> > > > are some files missing.
> > > 
> > > any others? send me the list. sorry.
> > > 
> > 
> > It builds now, I am burnning the image.
> > 
> 
> 
> Bad news, it stops right after ht_reset, just like 
> yeaterday :-(.

Can we get a serial console log so we can see the details?

Eric


From ollie at lanl.gov  Fri Mar 12 12:37:37 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 12 12:37:37 2004
Subject: your mail
In-Reply-To: <Pine.LNX.4.44.0403121033110.29105-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403121033110.29105-100000@maxroach.lanl.gov>
Message-ID: <1079114198.10012.188.camel@exponential.lanl.gov>

On Fri, 2004-03-12 at 10:33, ron minnich wrote:
> On Fri, 12 Mar 2004, Li-Ta Lo wrote:
> 
> > Bad news, it stops right after ht_reset, just like 
> > yeaterday :-(.
> 
> so, to sum up, the 2885 fails today, but the HDAMA works, right?
> 
> ron
> 

Ron, Our s2885 may be dead. I can't bot with factory bios
neither.

Ollie




From rminnich at lanl.gov  Fri Mar 12 12:41:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 12:41:01 2004
Subject: Tyan Changes for 1.1.6
In-Reply-To: <m3u10u6j38.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403121100140.29105-100000@maxroach.lanl.gov>

On 12 Mar 2004, Eric W. Biederman wrote:

> Ron do you know if on the physicists have succeeded in making an
> improbability generate yet?

I think it exists! It's used to generate the Federal budget each year!

ron



From rminnich at lanl.gov  Fri Mar 12 12:43:35 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 12:43:35 2004
Subject: your mail
In-Reply-To: <1079114198.10012.188.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403121100550.29105-100000@maxroach.lanl.gov>

On Fri, 12 Mar 2004, Li-Ta Lo wrote:

> Ron, Our s2885 may be dead. I can't bot with factory bios
> neither.

turn off power, disconnect power supply from motherboard, wait at least 45
seconds.  Reconnect power, with factory bios, then turn it on. This has
happened several times. I don't know what it is.

ron



From ollie at lanl.gov  Fri Mar 12 12:47:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 12 12:47:00 2004
Subject: your mail
In-Reply-To: <m3oer26j17.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0403121005130.29105-100000@maxroach.lanl.gov>
	 <1079111528.10012.182.camel@exponential.lanl.gov>
	 <1079112377.10012.184.camel@exponential.lanl.gov>
	 <m3oer26j17.fsf@maxwell.lnxi.com>
Message-ID: <1079114754.10012.191.camel@exponential.lanl.gov>

On Fri, 2004-03-12 at 11:02, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > On Fri, 2004-03-12 at 10:12, Li-Ta Lo wrote:
> > > On Fri, 2004-03-12 at 10:05, ron minnich wrote:
> > > > On Fri, 12 Mar 2004, Li-Ta Lo wrote:
> > > > 
> > > > > Ron, did you commited everything in YhLu's patch ? There
> > > > > are some files missing.
> > > > 
> > > > any others? send me the list. sorry.
> > > > 
> > > 
> > > It builds now, I am burnning the image.
> > > 
> > 
> > 
> > Bad news, it stops right after ht_reset, just like 
> > yeaterday :-(.
> 
> Can we get a serial console log so we can see the details?
> 


There is no much log to show, it is just three lines. I can make it up 
with my head.

LinuxBIOS 1.1.6 something starting .....
0002 CPU inited
ht reset _


Then dead.

Ollie




From YhLu at tyan.com  Fri Mar 12 13:19:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 13:19:01 2004
Subject: =?GB2312?B?tPC4tDogeW91ciBtYWls?=
Message-ID: <3174569B9743D511922F00A0C94314230466D177@TYANWEB>

Please forget about serial_2.c, and I used it send console info to two
console port.

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?3?12? 7:25
???: YhLu
??: linuxbios at clustermatic.org
??: Re: your mail

On Thu, 11 Mar 2004, YhLu wrote:

> Please commit the changes in tyan dir to make tyan MB to work with 1.1.6
> that Eric committed today.

These patches are now applied. 

Please test. 

Somebody please tell me why we have src/pc80/serial.c and 
src/pc80/serial_2.c ...

ron
> //BY LYH
>         value = pci_read_config32(dev, 0x4);
>         value |= 6;
>         pci_write_config32(dev, 0x4, value);
> //BY LYH END


if anyone wants to replace '6' with a symbolic name, that is fine by me 
:-)

ron


From rminnich at lanl.gov  Fri Mar 12 13:22:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 13:22:00 2004
Subject: =?GB2312?B?tPC4tDogeW91ciBtYWls?=
In-Reply-To: <3174569B9743D511922F00A0C94314230466D177@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403121141430.29105-100000@maxroach.lanl.gov>

On Fri, 12 Mar 2004, YhLu wrote:

> Please forget about serial_2.c, and I used it send console info to two
> console port.

oh, then it actually sounds important. I had forgotten this. 

ron



From YhLu at tyan.com  Fri Mar 12 13:25:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 13:25:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogVHlhbiBDaGFuZ2VzIGZvciAxLjEuNg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D179@TYANWEB>

> Eric,
> 
> In the 1.1.6, you have move clearing memory from auto.c to k8/cpufixup.c.
Is
> there any way to disable it for fast booting?

Don't enable ECC.

Memory clearing is only done for correctness.  ECC memory does not
work properly unless initialized.

I think the Opteron setup now is down to the minimal needed for
things to work.  You only observe one reset correct?


YHLU: One reset is right, but the output of the very beginning is not neat.

> 1. AMD 8131: ioapic : PCI master mem/io enable. The segment I have added
in
> old version, in 1.1.6 Eric remove that. --- It is needed for other MBs
> except arima --because it connects all apic to 8111.

As Ron mentioned later this needs a comment.  In the general case we should
not be enabling bus master DMA by default.  I tend to remove bus master
enables before remembering any special circumstances of the chip.


YHLU: but the code in amd8131_bridge.c and not in general code. (devices
dir)

> 2. Some correction in AMD8151.
> 3. Add superio/Winbond/w83627hf.

Thanks that looks correct.  And it was nice to see my changes were
that simple to follow.

> 4. other changs in tyan dir.  (auto.c failover.c cmos.layout from arima
dir)
> 	(Config.lb changes for option_table.h building and superio ...)
> 	(Increase the heap size to make elfboot work).

Hmm.  Can we throw in a sanity check to ensure we don't run out of heap?
I assume that is what was happening.

Does the 4-way s4880 work?  I'm not quite certain how my changes would
affect it.

YHLU: I will double check that, it not, need to increade the heap size
again.

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


From ebiederman at lnxi.com  Fri Mar 12 13:27:35 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 12 13:27:35 2004
Subject: S2885 failing on 1.1.6
In-Reply-To: <1079114754.10012.191.camel@exponential.lanl.gov>
References: <Pine.LNX.4.44.0403121005130.29105-100000@maxroach.lanl.gov>
	<1079111528.10012.182.camel@exponential.lanl.gov>
	<1079112377.10012.184.camel@exponential.lanl.gov>
	<m3oer26j17.fsf@maxwell.lnxi.com>
	<1079114754.10012.191.camel@exponential.lanl.gov>
Message-ID: <m3ptbhnbfy.fsf_-_@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Fri, 2004-03-12 at 11:02, Eric W. Biederman wrote:
> > Li-Ta Lo <ollie at lanl.gov> writes:
> > 
> > > On Fri, 2004-03-12 at 10:12, Li-Ta Lo wrote:
> > > > On Fri, 2004-03-12 at 10:05, ron minnich wrote:
> > > > > On Fri, 12 Mar 2004, Li-Ta Lo wrote:
> > > > > 
> > > > > > Ron, did you commited everything in YhLu's patch ? There
> > > > > > are some files missing.
> > > > > 
> > > > > any others? send me the list. sorry.
> > > > > 
> > > > 
> > > > It builds now, I am burnning the image.
> > > > 
> > > 
> > > 
> > > Bad news, it stops right after ht_reset, just like 
> > > yeaterday :-(.
> > 
> > Can we get a serial console log so we can see the details?
> > 
> 
> 
> There is no much log to show, it is just three lines. I can make it up 
> with my head.
> 
> LinuxBIOS 1.1.6 something starting .....
> 0002 CPU inited
> ht reset _


On something like:
LinuxBIOS-1.1.5.8pre1Normal Thu Mar 11 03:54:23 MST 2004 starting...
setting up resource map....done.
00000002 nodes initialized.
ht reset -


> Then dead.

I suspect it has to do with the different hypertransport
layout between that board and the s2880 and the hdama.  Either the
reset code is punching the wrong register, or we are messing with the
wrong hypertransport bus.

Why you flashed the entire chip is something I don't want to
contemplate, instead of leaving fallback alone is something I don't
want to contemplate :)

Eric


From YhLu at tyan.com  Fri Mar 12 13:31:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 13:31:01 2004
Subject: =?GB2312?B?tPC4tDogVHlhbiBDaGFuZ2VzIGZvciAxLjEuNg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D17A@TYANWEB>

W83627hf and w83627thf is different, please refer to the func number diff.

YH.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?12? 8:54
???: YhLu
??: ron minnich; LinuxBIOS
??: Re: Tyan Changes for 1.1.6

On Thu, 2004-03-11 at 22:09, YhLu wrote:
> 1. AMD 8131: ioapic : PCI master mem/io enable. The segment I have added
in
> old version, in 1.1.6 Eric remove that. --- It is needed for other MBs
> except arima --because it connects all apic to 8111.
> 2. Some correction in AMD8151.
> 3. Add superio/Winbond/w83627hf.

Are you mix up with w83627hf and w83627thf ? In code it is w83627hf but 
in in the source code directory it is w83627thf.

Ollie



From YhLu at tyan.com  Fri Mar 12 13:33:47 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 13:33:47 2004
Subject: =?GB2312?B?tPC4tDogeW91ciBtYWls?=
Message-ID: <3174569B9743D511922F00A0C94314230466D17B@TYANWEB>

On s2885?

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?12? 9:26
???: ron minnich
??: YhLu; LinuxBIOS
??: Re: your mail

On Fri, 2004-03-12 at 10:12, Li-Ta Lo wrote:
> On Fri, 2004-03-12 at 10:05, ron minnich wrote:
> > On Fri, 12 Mar 2004, Li-Ta Lo wrote:
> > 
> > > Ron, did you commited everything in YhLu's patch ? There
> > > are some files missing.
> > 
> > any others? send me the list. sorry.
> > 
> 
> It builds now, I am burnning the image.
> 


Bad news, it stops right after ht_reset, just like 
yeaterday :-(.

Ollie



From YhLu at tyan.com  Fri Mar 12 13:37:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 13:37:01 2004
Subject: =?GB2312?B?tPC4tDogeW91ciBtYWls?=
Message-ID: <3174569B9743D511922F00A0C94314230466D17C@TYANWEB>

I will double check that on S2885.

It already works on S2880 and S2882.

YH.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?12? 10:06
???: Eric W. Biederman
??: ron minnich; YhLu; LinuxBIOS
??: Re: your mail

On Fri, 2004-03-12 at 11:02, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > On Fri, 2004-03-12 at 10:12, Li-Ta Lo wrote:
> > > On Fri, 2004-03-12 at 10:05, ron minnich wrote:
> > > > On Fri, 12 Mar 2004, Li-Ta Lo wrote:
> > > > 
> > > > > Ron, did you commited everything in YhLu's patch ? There
> > > > > are some files missing.
> > > > 
> > > > any others? send me the list. sorry.
> > > > 
> > > 
> > > It builds now, I am burnning the image.
> > > 
> > 
> > 
> > Bad news, it stops right after ht_reset, just like 
> > yeaterday :-(.
> 
> Can we get a serial console log so we can see the details?
> 


There is no much log to show, it is just three lines. I can make it up 
with my head.

LinuxBIOS 1.1.6 something starting .....
0002 CPU inited
ht reset _


Then dead.

Ollie



From dwh at lanl.gov  Fri Mar 12 13:45:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Mar 12 13:45:01 2004
Subject: =?gb2312?b?tPC4tA==?=: Tyan Changes for 1.1.6
In-Reply-To: <Pine.LNX.4.44.0403120938480.29105-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403121200190.14792-200000@ccs-mail.lanl.gov>

Oh yeah, I've been using 2.6.3 on the S2885 for a while now. The AGPGART 
driver has an issue that requires it to be compiled statically into the 
kernel, so that sort of breaks functionality of your FIXGART script that 
does the magic with IORRs and such.

I'll attach my .config, tested on the S2885, in case others want to skip 
through the configuration process with a 'make oldconfig.'

On Fri, 12 Mar 2004, ron minnich wrote:

> On 12 Mar 2004, Eric W. Biederman wrote:
> 
> > 2.6 is fun because the option names have changed, so it is easy
> > to leave things like serial console disabled.
> > 
> 
> I think David Hendricks tried this. David? 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 
-------------- next part --------------
#
# Automatically generated make config: don't edit
#
CONFIG_X86_64=y
CONFIG_64BIT=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_X86_CMPXCHG=y
CONFIG_EARLY_PRINTK=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_GENERIC_ISA_DMA=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_CLEAN_COMPILE is not set
# CONFIG_STANDALONE is not set
CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_EMBEDDED is not set
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
CONFIG_MK8=y
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_MSR=m
# CONFIG_X86_CPUID is not set
CONFIG_X86_IO_APIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_MTRR=y
CONFIG_SMP=y
# CONFIG_PREEMPT is not set
# CONFIG_K8_NUMA is not set
CONFIG_HAVE_DEC_LOCK=y
CONFIG_NR_CPUS=2
CONFIG_GART_IOMMU=y
CONFIG_X86_MCE=y

#
# Power management options
#
# CONFIG_PM is not set

#
# ACPI (Advanced Configuration and Power Interface) Support
#
# CONFIG_ACPI is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
# CONFIG_HOTPLUG is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=y
CONFIG_COMPAT=y
CONFIG_UID16=y

#
# Device Drivers
#

#
# Generic Driver Options
#

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_CML1=y
# CONFIG_PARPORT_SERIAL is not set
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_OTHER is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play support
#

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_LBD=y

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_IDEDISK_STROKE is not set
# CONFIG_BLK_DEV_IDECD is not set
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_TASKFILE_IO=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_CMD640 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_ADMA=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_DMA_NONPCI is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_SCSI=y
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
# CONFIG_BLK_DEV_SD is not set
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_REPORT_LUNS is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_SATA is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
CONFIG_SCSI_QLA2XXX=y
# CONFIG_SCSI_QLA21XX is not set
# CONFIG_SCSI_QLA22XX is not set
# CONFIG_SCSI_QLA2300 is not set
# CONFIG_SCSI_QLA2322 is not set
# CONFIG_SCSI_QLA6312 is not set
# CONFIG_SCSI_QLA6322 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_DEBUG is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_OUI_DB=y

#
# Device Drivers
#

#
# Texas Instruments PCILynx requires I2C
#
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
# CONFIG_IEEE1394_VIDEO1394 is not set
# CONFIG_IEEE1394_SBP2 is not set
# CONFIG_IEEE1394_ETH1394 is not set
# CONFIG_IEEE1394_DV1394 is not set
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_CMP=m
# CONFIG_IEEE1394_AMDTP is not set

#
# I2O device support
#

#
# Macintosh device drivers
#

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETLINK_DEV is not set
CONFIG_UNIX=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set

#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set

#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
# CONFIG_IP_NF_FTP is not set
# CONFIG_IP_NF_IRC is not set
# CONFIG_IP_NF_TFTP is not set
# CONFIG_IP_NF_AMANDA is not set
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
# CONFIG_IP_NF_NAT_LOCAL is not set
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
CONFIG_B44=m
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
CONFIG_EEPRO100=m
# CONFIG_EEPRO100_PIO is not set
CONFIG_E100=m
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_VIA_RHINE is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SK98LIN is not set
CONFIG_TIGON3=m

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# Bluetooth support
#
# CONFIG_BT is not set

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=y
# CONFIG_LP_CONSOLE is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
# CONFIG_DRM is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HANGCHECK_TIMER is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#
# CONFIG_FB is not set
# CONFIG_VIDEO_SELECT is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_UHCI_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_BLUETOOTH_TTY is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set

#
# USB Human Interface Devices (HID)
#
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set

#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_XPAD is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set

#
# USB Multimedia devices
#
# CONFIG_USB_DABUSB is not set

#
# Video4Linux support is needed for USB Multimedia device support
#

#
# USB Network adaptors
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_BRLVGER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_TEST is not set

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
CONFIG_REISERFS_CHECK=y
CONFIG_REISERFS_PROC_INFO=y
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y

#
# DOS/FAT/NT Filesystems
#
# CONFIG_FAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
# CONFIG_DEVPTS_FS_XATTR is not set
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_EXPORTFS is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Profiling support
#
# CONFIG_PROFILING is not set

#
# Kernel hacking
#
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_FRAME_POINTER=y

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y

From ollie at lanl.gov  Fri Mar 12 15:05:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 12 15:05:00 2004
Subject: your mail
In-Reply-To: <1079110896.10012.180.camel@exponential.lanl.gov>
References: <Pine.LNX.4.44.0403120823370.29105-100000@maxroach.lanl.gov>
	 <1079110896.10012.180.camel@exponential.lanl.gov>
Message-ID: <1079123190.10012.198.camel@exponential.lanl.gov>

On Fri, 2004-03-12 at 10:01, Li-Ta Lo wrote:
> On Fri, 2004-03-12 at 08:24, ron minnich wrote:
> > On Thu, 11 Mar 2004, YhLu wrote:
> > 
> > > Please commit the changes in tyan dir to make tyan MB to work with 1.1.6
> > > that Eric committed today.
> > 
> > These patches are now applied. 
> > 
> > Please test. 
> 
> 
> Ron, did you commited everything in YhLu's patch ? There
> are some files missing.
> 


YhLu,

You removed s2882/intel_nic.c and s2885/broadcom_nic.c. Do you
really mean to do that ? Should we cvs rm these files ?

Ollie




From YhLu at tyan.com  Fri Mar 12 15:40:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 15:40:00 2004
Subject: =?GB2312?B?tPC4tDogeW91ciBtYWls?=
Message-ID: <3174569B9743D511922F00A0C94314230466D18F@TYANWEB>

You can keep the two files.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?12? 12:27
???: ron minnich
??: YhLu; LinuxBIOS
??: Re: your mail

On Fri, 2004-03-12 at 10:01, Li-Ta Lo wrote:
> On Fri, 2004-03-12 at 08:24, ron minnich wrote:
> > On Thu, 11 Mar 2004, YhLu wrote:
> > 
> > > Please commit the changes in tyan dir to make tyan MB to work with
1.1.6
> > > that Eric committed today.
> > 
> > These patches are now applied. 
> > 
> > Please test. 
> 
> 
> Ron, did you commited everything in YhLu's patch ? There
> are some files missing.
> 


YhLu,

You removed s2882/intel_nic.c and s2885/broadcom_nic.c. Do you
really mean to do that ? Should we cvs rm these files ?

Ollie



From rminnich at lanl.gov  Fri Mar 12 15:46:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 12 15:46:00 2004
Subject: S2885 failing on 1.1.6
In-Reply-To: <m3ptbhnbfy.fsf_-_@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403121407050.31151-100000@maxroach.lanl.gov>

On 12 Mar 2004, Eric W. Biederman wrote:

> Why you flashed the entire chip is something I don't want to
> contemplate, instead of leaving fallback alone is something I don't
> want to contemplate :)
> 

it's a test node, we don't worry about fallback on this one.
ron



From YhLu at tyan.com  Fri Mar 12 16:27:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 16:27:00 2004
Subject: =?GB2312?B?tPC4tDogUzI4ODUgZmFpbGluZyBvbiAxLjEuNg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D19E@TYANWEB>

Eric,

The problem caused by 

ht_setup_chain(). in northbridge/amd/amdk8/incoherent_ht.c

The S2885 CPU link0 is connected to 8151 and link 2 is connected to 8131.

The ht_setup_chain() seems not to be complete as the ht_scan_chain in
devices/hypertransport.c

Regards

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?3?12? 13:07
???: Eric W. Biederman
??: Li-Ta Lo; YhLu; LinuxBIOS
??: Re: S2885 failing on 1.1.6

On 12 Mar 2004, Eric W. Biederman wrote:

> Why you flashed the entire chip is something I don't want to
> contemplate, instead of leaving fallback alone is something I don't
> want to contemplate :)
> 

it's a test node, we don't worry about fallback on this one.
ron


From ollie at lanl.gov  Fri Mar 12 17:02:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 12 17:02:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?= S2885 failing on 1.1.6
In-Reply-To: <3174569B9743D511922F00A0C94314230466D19E@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D19E@TYANWEB>
Message-ID: <1079130234.25319.3.camel@exponential.lanl.gov>

On Fri, 2004-03-12 at 14:54, YhLu wrote:
> Eric,
> 
> The problem caused by 
> 
> ht_setup_chain(). in northbridge/amd/amdk8/incoherent_ht.c
> 
> The S2885 CPU link0 is connected to 8151 and link 2 is connected to 8131.
> 
> The ht_setup_chain() seems not to be complete as the ht_scan_chain in
> devices/hypertransport.c
> 

I change the reset code to 

static void hard_reset(void)
{
        set_bios_reset();

        /* enable cf9 */
        pci_write_config8(PCI_DEV(1, 0x04, 3), 0x41, 0xf1);
        /* reset */
        outb(0x0e, 0x0cf9);
}

static void soft_reset(void)
{
        set_bios_reset();
        pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1);
}

Now it works.


Is that PCI(1, ...) mean another link ?

Ollie



From YhLu at tyan.com  Fri Mar 12 17:18:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 17:18:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogUzI4ODUgZmFpbGluZyBvbiAxLjEuNg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D1A7@TYANWEB>

0 should be bus.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?12? 14:24
???: YhLu
??: ron minnich; Eric W. Biederman; LinuxBIOS
??: Re: ??: S2885 failing on 1.1.6

On Fri, 2004-03-12 at 14:54, YhLu wrote:
> Eric,
> 
> The problem caused by 
> 
> ht_setup_chain(). in northbridge/amd/amdk8/incoherent_ht.c
> 
> The S2885 CPU link0 is connected to 8151 and link 2 is connected to 8131.
> 
> The ht_setup_chain() seems not to be complete as the ht_scan_chain in
> devices/hypertransport.c
> 

I change the reset code to 

static void hard_reset(void)
{
        set_bios_reset();

        /* enable cf9 */
        pci_write_config8(PCI_DEV(1, 0x04, 3), 0x41, 0xf1);
        /* reset */
        outb(0x0e, 0x0cf9);
}

static void soft_reset(void)
{
        set_bios_reset();
        pci_write_config8(PCI_DEV(1, 0x04, 0), 0x47, 1);
}

Now it works.


Is that PCI(1, ...) mean another link ?

Ollie


From ollie at lanl.gov  Fri Mar 12 17:21:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 12 17:21:01 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= S2885 failing on 1.1.6
In-Reply-To: <3174569B9743D511922F00A0C94314230466D1A7@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D1A7@TYANWEB>
Message-ID: <1079131259.25319.5.camel@exponential.lanl.gov>

On Fri, 2004-03-12 at 15:45, YhLu wrote:
> 0 should be bus.
> 

Then why change it to bus 1 fix the problem ?

Ollie




From YhLu at tyan.com  Fri Mar 12 17:24:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 17:24:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogtPC4tDogUzI4ODUgZmFpbGluZyBvbiAxLjEu?=
	=?GB2312?B?Ng==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D1AB@TYANWEB>

Maybe after the ht-scan in auto.c

Amd8131 and amd8111 is in bus 1. and bus 0 is used by 8151.

YH

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?12? 14:41
???: YhLu
??: ron minnich; Eric W. Biederman; LinuxBIOS
??: Re: ??: ??: S2885 failing on 1.1.6

On Fri, 2004-03-12 at 15:45, YhLu wrote:
> 0 should be bus.
> 

Then why change it to bus 1 fix the problem ?

Ollie



From YhLu at tyan.com  Fri Mar 12 17:29:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 17:29:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogtPC4tDogUzI4ODUgZmFpbGluZyBvbiAxLjEu?=
	=?GB2312?B?Ng==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D1AC@TYANWEB>

After the ht-scan in devices/hypertransport.c,

Ams8131/amd8111 will be in bus 3. bus 1 will be used by 8151.

YH.

-----????-----
???: YhLu 
????: 2004?3?12? 14:44
???: 'Li-Ta Lo'
??: ron minnich; Eric W. Biederman; LinuxBIOS
??: ??: ??: ??: S2885 failing on 1.1.6

Maybe after the ht-scan in auto.c

Amd8131 and amd8111 is in bus 1. and bus 0 is used by 8151.

YH

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?12? 14:41
???: YhLu
??: ron minnich; Eric W. Biederman; LinuxBIOS
??: Re: ??: ??: S2885 failing on 1.1.6

On Fri, 2004-03-12 at 15:45, YhLu wrote:
> 0 should be bus.
> 

Then why change it to bus 1 fix the problem ?

Ollie



From YhLu at tyan.com  Fri Mar 12 17:48:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 17:48:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogVHlhbiBDaGFuZ2VzIGZvciAxLjEuNg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D1B2@TYANWEB>

With 1.1.5 is OK, but failed with 1.1.6.

-----????-----
???: Hendricks David W. [mailto:dwh at lanl.gov] 
????: 2004?3?12? 11:06
???: ron minnich
??: Eric W. Biederman; YhLu; 'linuxbios at clustermatic.org'
??: Re: ??: Tyan Changes for 1.1.6

Oh yeah, I've been using 2.6.3 on the S2885 for a while now. The AGPGART 
driver has an issue that requires it to be compiled statically into the 
kernel, so that sort of breaks functionality of your FIXGART script that 
does the magic with IORRs and such.

I'll attach my .config, tested on the S2885, in case others want to skip 
through the configuration process with a 'make oldconfig.'

On Fri, 12 Mar 2004, ron minnich wrote:

> On 12 Mar 2004, Eric W. Biederman wrote:
> 
> > 2.6 is fun because the option names have changed, so it is easy
> > to leave things like serial console disabled.
> > 
> 
> I think David Hendricks tried this. David? 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 


From christian at visual-page.de  Fri Mar 12 18:46:01 2004
From: christian at visual-page.de (Christian Gmeiner)
Date: Fri Mar 12 18:46:01 2004
Subject: Asus Cusi-FX
Message-ID: <001f01c4088f$568a3460$0600a8c0@blackbox>

Hi Mailinglist.

I find the project very good and it could speed up the starting of my Video Disc Recorder - VDR - dramaticly.
But before i spend money i want to know, if the ASUS Cusi-Fx Mainboard is supported.

Thanks, Christian Gmeiner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040312/87c3f61e/attachment.html>

From dwh at lanl.gov  Fri Mar 12 18:59:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Mar 12 18:59:00 2004
Subject: Asus Cusi-FX
In-Reply-To: <001f01c4088f$568a3460$0600a8c0@blackbox>
Message-ID: <Pine.LNX.4.44.0403121713090.23348-100000@ccs-mail.lanl.gov>

Asus stuff typically is not supported because they do weird things with 
their SMBus. It uses a SiS630, however, so maybe it's not a totally lost 
cause. Perhaps Ollie Lho can give us his opinion on this.

Is it possible to use another mainboard with the SiS630? I'm really 
skeptical about support on Asus mainboards.

On Sat, 13 Mar 2004, Christian Gmeiner wrote:

> Hi Mailinglist.
> 
> I find the project very good and it could speed up the starting of my Video Disc Recorder - VDR - dramaticly.
> But before i spend money i want to know, if the ASUS Cusi-Fx Mainboard is supported.
> 
> Thanks, Christian Gmeiner



From bari at onelabs.com  Fri Mar 12 19:02:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Mar 12 19:02:00 2004
Subject: Asus Cusi-FX
In-Reply-To: <001f01c4088f$568a3460$0600a8c0@blackbox>
References: <001f01c4088f$568a3460$0600a8c0@blackbox>
Message-ID: <40525471.5020704@onelabs.com>

Christian Gmeiner wrote:

> Hi Mailinglist.
>  
> I find the project very good and it could speed up the starting of my 
> Video Disc Recorder - VDR - dramaticly.
> But before i spend money i want to know, if the ASUS Cusi-Fx Mainboard 
> is supported.

Send LSPCI.

-Bari




From YhLu at tyan.com  Fri Mar 12 19:42:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 12 19:42:01 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogVHlhbiBDaGFuZ2VzIGZvciAxLjEuNg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D1D3@TYANWEB>

Increase heap size will make it work.

-----????-----
???: YhLu 
????: 2004?3?12? 15:15
???: Hendricks David W.; ron minnich
??: Eric W. Biederman; 'linuxbios at clustermatic.org'
??: ??: ??: Tyan Changes for 1.1.6

With 1.1.5 is OK, but failed with 1.1.6.

-----????-----
???: Hendricks David W. [mailto:dwh at lanl.gov] 
????: 2004?3?12? 11:06
???: ron minnich
??: Eric W. Biederman; YhLu; 'linuxbios at clustermatic.org'
??: Re: ??: Tyan Changes for 1.1.6

Oh yeah, I've been using 2.6.3 on the S2885 for a while now. The AGPGART 
driver has an issue that requires it to be compiled statically into the 
kernel, so that sort of breaks functionality of your FIXGART script that 
does the magic with IORRs and such.

I'll attach my .config, tested on the S2885, in case others want to skip 
through the configuration process with a 'make oldconfig.'

On Fri, 12 Mar 2004, ron minnich wrote:

> On 12 Mar 2004, Eric W. Biederman wrote:
> 
> > 2.6 is fun because the option names have changed, so it is easy
> > to leave things like serial console disabled.
> > 
> 
> I think David Hendricks tried this. David? 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From bari at onelabs.com  Fri Mar 12 19:56:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Mar 12 19:56:01 2004
Subject: [Fwd: Re: Asus Cusi-FX]
Message-ID: <40526191.7090809@onelabs.com>


-------- Original Message --------
Subject: Re: Asus Cusi-FX
Date: Sat, 13 Mar 2004 01:28:11 +0100
From: Christian Gmeiner <christian at visual-page.de>
To: Bari Ari <bari at onelabs.com>
References: <001f01c4088f$568a3460$0600a8c0 at blackbox> 
<40525471.5020704 at onelabs.com>


> Christian Gmeiner wrote:
>
> > Hi Mailinglist.
> >
> > I find the project very good and it could speed up the starting of my
> > Video Disc Recorder - VDR - dramaticly.
> > But before i spend money i want to know, if the ASUS Cusi-Fx Mainboard
> > is supported.
>
> Send LSPCI.

vdr root # lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 21)
00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0)
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513
00:01.1 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 10/100
Ethernet (rev 83)
00:01.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller
(rev 07)
00:01.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller
(rev 07)
00:02.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual
PCI-to-PCI bridge (AGP)
00:0d.0 Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus
DVD Decoder (rev 02)
00:0e.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS630
GUI Accelerator+3D (rev 21)

Greets,
Christian










From bari at onelabs.com  Fri Mar 12 20:14:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Mar 12 20:14:00 2004
Subject: Asus Cusi-FX
In-Reply-To: <Pine.LNX.4.44.0403121713090.23348-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0403121713090.23348-100000@ccs-mail.lanl.gov>
Message-ID: <405265F0.2070801@onelabs.com>

Hendricks David W. wrote:

> Asus stuff typically is not supported because they do weird things with 
> their SMBus. 

Lots of motherboards get it wrong with how they mux the SMBus with the 
DDC on the VGA connector.

Bari




From YhLu at tyan.com  Sat Mar 13 00:26:01 2004
From: YhLu at tyan.com (YhLu)
Date: Sat Mar 13 00:26:01 2004
Subject: Tyan Changes for 1.1.6
Message-ID: <3174569B9743D511922F00A0C94314230466D1FF@TYANWEB>

Eric,

It seems all the pnp_device init are not called.

Regards

YH.

Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD 8111
Enumerating: Winbond w83627hf
Enumerating buses...PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
amdk8_scan_chains max: 0 starting...
Hyper transport scan link: 0 max: 1
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] bus ops
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] ops
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] bus ops
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] ops
PCI: 01:02.1 [1022/7451] enabled
PCI: 01:03.0 [1022/7460] bus ops
PCI: 01:03.0 [1022/7460] enabled
PCI: 01:04.0 [1022/7468] bus ops
PCI: 01:04.0 [1022/7468] enabled
PCI: 01:04.1 [1022/7469] ops
PCI: 01:04.1 [1022/7469] enabled
PCI: 01:04.2 [1022/746a] enabled
PCI: 01:04.3 [1022/746b] ops
PCI: 01:04.3 [1022/746b] enabled
PCI: 01:04.5 [1022/746d] ops
PCI: 01:04.5 [1022/746d] disabled
PCI: 01:04.6 [1022/746e] ops
PCI: 01:04.6 [1022/746e] disabled
PCI: pci_scan_bus for bus 2
PCI: 02:06.0 [9005/801f] enabled
PCI: 02:06.1 [9005/801f] enabled
PCI: 02:09.0 [14e4/16a7] enabled
PCI: 02:09.1 [14e4/16a7] 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 for bus 4
PCI: 04:00.0 [1022/7464] ops
PCI: 04:00.0 [1022/7464] enabled
PCI: 04:00.1 [1022/7464] ops
PCI: 04:00.1 [1022/7464] enabled
PCI: 04:00.2 [1022/7463] ops
PCI: 04:00.2 [1022/7463] enabled
PCI: 04:01.0 [1022/7462] ops
PCI: 04:01.0 [1022/7462] disabled
PCI: 04:06.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=04
PNP: 002e.0 disabled
PNP: 002e.1 disabled
PNP: 002e.2 enabled
PNP: 002e.3 disabled
PNP: 002e.5 enabled
PNP: 002e.6 disabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
PNP: 002e.b disabled
PCI: pci_scan_bus returning with max=04
Hyper transport scan link: 0 new max: 4
Hypertransport scan link done
amdk8_scan_chains max: 4 done
amdk8_scan_chains max: 4 starting...
amdk8_scan_chains max: 4 done
PCI: pci_scan_bus returning with max=04
done
Allocating resources...
PNP: 002e.8 missing read_resources
PNP: 002e.9 missing read_resources
Allocating VGA resource
ASSIGN RESOURCES, bus 0
PCI: 00:18.0 c0 <- [0x00001000 - 0x00003fff] node 0 link 0 io
PCI: 00:18.0 b8 <- [0xfc000000 - 0xfd2fffff] node 0 link 0 mem
ASSIGN RESOURCES, bus 1
PCI: 01:01.0 1c <- [0x00001000 - 0x00001fff] bus 2 io
PCI: 01:01.0 24 <- [0xfd200000 - 0xfd1fffff] bus 2 prefmem
PCI: 01:01.0 20 <- [0xfd100000 - 0xfd1fffff] bus 2 mem
ASSIGN RESOURCES, bus 2
PCI: 02:06.0 10 <- [0x00001000 - 0x000010ff] io
PCI: 02:06.0 14 <- [0xfd140000 - 0xfd141fff] mem
PCI: 02:06.0 1c <- [0x00001400 - 0x000014ff] io
PCI: 02:06.1 10 <- [0x00001800 - 0x000018ff] io
PCI: 02:06.1 14 <- [0xfd142000 - 0xfd143fff] mem
PCI: 02:06.1 1c <- [0x00001c00 - 0x00001cff] io
PCI: 02:09.0 10 <- [0xfd100000 - 0xfd10ffff] mem
PCI: 02:09.0 18 <- [0xfd110000 - 0xfd11ffff] mem
PCI: 02:09.1 10 <- [0xfd120000 - 0xfd12ffff] mem
PCI: 02:09.1 18 <- [0xfd130000 - 0xfd13ffff] mem
ASSIGNED RESOURCES, bus 2
PCI: 01:01.1 10 <- [0xfd200000 - 0xfd200fff] mem
PCI: 01:02.0 1c <- [0x00003000 - 0x00002fff] bus 3 io
PCI: 01:02.0 24 <- [0xfd200000 - 0xfd1fffff] bus 3 prefmem
PCI: 01:02.0 20 <- [0xfd200000 - 0xfd1fffff] bus 3 mem
PCI: 01:02.1 10 <- [0xfd201000 - 0xfd201fff] mem
PCI: 01:03.0 1c <- [0x00002000 - 0x00002fff] bus 4 io
PCI: 01:03.0 24 <- [0xfd200000 - 0xfd1fffff] bus 4 prefmem
PCI: 01:03.0 20 <- [0xfc000000 - 0xfd0fffff] bus 4 mem
ASSIGN RESOURCES, bus 4
PCI: 04:00.0 10 <- [0xfd000000 - 0xfd000fff] mem
PCI: 04:00.1 10 <- [0xfd001000 - 0xfd001fff] mem
PCI: 04:00.2 10 <- [0xfd003000 - 0xfd0030ff] mem
PCI: 04:00.2 14 <- [0xfd004000 - 0xfd00401f] mem
PCI: 04:06.0 10 <- [0xfc000000 - 0xfcffffff] mem
PCI: 04:06.0 14 <- [0x00002000 - 0x000020ff] io
PCI: 04:06.0 18 <- [0xfd002000 - 0xfd002fff] mem
ASSIGNED RESOURCES, bus 4
PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] io
PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] mem
ASSIGN RESOURCES, bus 0
PNP: 002e.2 60 <- [0x000003f8 - 0x000003ff] io
PNP: 002e.2 70 <- [0x00000004 - 0x00000004] irq
PNP: 002e.5 60 <- [0x00000060 - 0x00000060] io
PNP: 002e.5 62 <- [0x00000064 - 0x00000064] io
PNP: 002e.5 70 <- [0x00000001 - 0x00000001] irq
PNP: 002e.5 72 <- [0x0000000c - 0x0000000c] irq
PNP: 002e.8 missing set_resources
PNP: 002e.9 missing set_resources
ASSIGNED RESOURCES, bus 0
PCI: 01:04.1 20 <- [0x00003420 - 0x0000342f] io
PCI: 01:04.2 10 <- [0x00003400 - 0x0000341f] io
PCI: 01:04.3 58 <- [0x00003000 - 0x000030ff] io
ASSIGNED RESOURCES, bus 1
PCI: 00:18.3 94 <- [0xf8000000 - 0xfbffffff] mem <gart>
PCI: 00:19.3 94 <- [0xf8000000 - 0xfbffffff] mem <gart>
ASSIGNED RESOURCES, bus 0
done.
Enabling resourcess...
PCI: 00:18.0 cmd <- 140
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 147
PCI: 02:06.0 cmd <- 143
PCI: 02:06.1 cmd <- 143
PCI: 02:09.0 cmd <- 142
PCI: 02:09.1 cmd <- 142
PCI: 01:01.1 cmd <- 146
PCI: 01:02.0 bridge ctrl <- 0003
PCI: 01:02.0 cmd <- 147
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 000b
PCI: 01:03.0 cmd <- 147
PCI: 04:00.0 cmd <- 142
PCI: 04:00.1 cmd <- 142
PCI: 04:00.2 cmd <- 142
PCI: 04:06.0 cmd <- 1c3
PCI: 01:04.0 cmd <- 14f
PNP: 002e.8 missing enable_resources
PNP: 002e.9 missing enable_resources
PCI: 01:04.1 cmd <- 141
PCI: 01:04.2 cmd <- 141
PCI: 01:04.3 cmd <- 141
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
PCI: 00:19.0 cmd <- 140
PCI: 00:19.1 cmd <- 140
PCI: 00:19.2 cmd <- 140
PCI: 00:19.3 cmd <- 140
done.
Initializing devices...
PCI: 00:18.0 init
NB: Function 0 Misc Control.. done.
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:19.0 init
NB: Function 0 Misc Control.. done.
PCI: 00:19.3 init
NB: Function 3 Misc Control.. done.
PCI: 01:01.0 init
PCI: 01:02.0 init
PCI: 01:03.0 init
PCI: 01:04.0 init
RTC Init
enabling HPET @0xfed00000
PCI: 01:04.1 init
IDE1 IDE0 PCI: 01:04.3 init
set power on after power fail
PCI: 04:00.0 init
PCI: 04:00.1 init
PCI: 04:00.2 init
Devices initialized


From ts1 at tsn.or.jp  Sat Mar 13 04:46:00 2004
From: ts1 at tsn.or.jp (Takeshi Sone)
Date: Sat Mar 13 04:46:00 2004
Subject: BCC...
In-Reply-To: <Pine.LNX.4.44.0403090808370.30487-100000@maxroach.lanl.gov>
References: <m3llmaa4m8.fsf@maxwell.lnxi.com> <Pine.LNX.4.44.0403090808370.30487-100000@maxroach.lanl.gov>
Message-ID: <20040313100707.GA6285@tsn.or.jp>

On Tue, Mar 09, 2004 at 08:10:32AM -0700, ron minnich wrote:
> On 8 Mar 2004, Eric W. Biederman wrote:
> > rombios.c or whatever the PCBIOS compatibility layer winds up being must
> > be 16bit code, (even if it has 32bit extensions all over the place).  
> > I'm not certain gcc can be convinced to do a reasonable job of 16bit C
> > code.
> 
> what's wrong with what we did for vga extensions, a 16-bit hook into 
> 32-bit code? It has worked well for those who wanted native vga.

Some OSs call 16-bit BIOS services in VM86 mode.
In that case you can't switch to 32-bit mode by yourself.

Eric, how about modifying GCC to generate true 16-bit code?

-- 
Takeshi


From christian at visual-page.de  Sat Mar 13 09:03:00 2004
From: christian at visual-page.de (Christian Gmeiner)
Date: Sat Mar 13 09:03:00 2004
Subject: Asus Cusi-FX
References: <Pine.LNX.4.44.0403121713090.23348-100000@ccs-mail.lanl.gov> <405265F0.2070801@onelabs.com>
Message-ID: <000701c40907$27ecfc00$0600a8c0@blackbox>

> Hendricks David W. wrote:
>
> > Asus stuff typically is not supported because they do weird things with
> > their SMBus.
>
> Lots of motherboards get it wrong with how they mux the SMBus with the
> DDC on the VGA connector.
>

Does this mean, linuxbios supports my mainboard?

Christian




From rminnich at lanl.gov  Sat Mar 13 10:48:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sat Mar 13 10:48:00 2004
Subject: BCC...
In-Reply-To: <20040313100707.GA6285@tsn.or.jp>
Message-ID: <Pine.LNX.4.44.0403130909000.6347-100000@maxroach.lanl.gov>

On Sat, 13 Mar 2004, Takeshi Sone wrote:

> Some OSs call 16-bit BIOS services in VM86 mode.
> In that case you can't switch to 32-bit mode by yourself.

how about we list those OSes, see if they can be fixed, or if we don't 
care.

what does windows do?

ron



From ebiederman at lnxi.com  Sun Mar 14 00:20:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Mar 14 00:20:01 2004
Subject: BCC...
In-Reply-To: <Pine.LNX.4.44.0403130909000.6347-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403130909000.6347-100000@maxroach.lanl.gov>
Message-ID: <m3u10s2d25.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Sat, 13 Mar 2004, Takeshi Sone wrote:
> 
> > Some OSs call 16-bit BIOS services in VM86 mode.
> > In that case you can't switch to 32-bit mode by yourself.
> 
> how about we list those OSes, see if they can be fixed, or if we don't 
> care.
> 
> what does windows do?
VM86 mode...  At least the windows 9x kernel.  NT?

The important point to note is that gas has a directive ``.code16gcc''
which directs gas to assemble 32bit code that runs in 16bit mode and
in vm86 mode.  So if we can fit everything in 256K we are fine.

So when doing a rewrite of rombios.c that is readable we should try
that.  256K is a little tight I admit but if we don't go beyond simple
standard features it is enough.

The fundamental point here is that you can write 32bit code that
will run in VM86 mode.

Eric


From awinner at walkabout-comp.com  Mon Mar 15 07:40:01 2004
From: awinner at walkabout-comp.com (Anthony Winner)
Date: Mon Mar 15 07:40:01 2004
Subject: OEM looking at LinuxBIOS
In-Reply-To: <m3r7vyoyge.fsf@maxwell.lnxi.com>
Message-ID: <002b01c40a8e$c30ab870$3b0201c0@hhengineering.local>

OK, will just dive in and see what happens, and use the list for any
problems...



Thanks,

Anthony Winner
WalkAbout Computers
awinner at walkabout-comp.com
(561)712-1200  x221


-----Original Message-----
From: Eric W. Biederman [mailto:eric at lnxi.com]On Behalf Of Eric W.
Biederman
Sent: Friday, March 12, 2004 10:52 AM
To: Awinner at walkabout-comp.com
Cc: LinuxBIOS
Subject: Re: OEM looking at LinuxBIOS


"Anthony Winner" <awinner at walkabout-comp.com> writes:

> Eric,
>
> Thanks, will start with the freebios2 tree. Which of the howto's is a good
> 'from scratch' roadmap to get me started....

I really don't know the state of the howto's at this point.

Generally good advice is to examine another port that is similar.

Eric


> Anthony Winner
> WalkAbout Computers
> awinner at walkabout-comp.com
> (561)712-1200  x221
>
>
> -----Original Message-----
> From: linuxbios-admin at clustermatic.org
> [mailto:linuxbios-admin at clustermatic.org]On Behalf Of Eric W. Biederman
> Sent: Thursday, March 11, 2004 11:06 AM
> To: Hendricks David W.
> Cc: Anthony Winner; linuxbios at clustermatic.org
> Subject: Re: OEM looking at LinuxBIOS
>
>
> "Hendricks David W." <dwh at lanl.gov> writes:
>
> > There is already 82803 and 82801ca code in the freebios1 tree, might as
> > well put it to good use :) I think Eric Beiderman was even able to fix
> > SPD, at least on the MCH4 (Or something).
> >
> > On Tue, 9 Mar 2004, Anthony Winner wrote:
> >
> > > Hello all,
> > >
> > > I work for a OEM and I'm playing with the idea of using linuxBIOS, I
> have
> > > all of the technical info for the machine short of the actual source
> code to
> > > the Phoenix BIOS we use now as it was done by a contractor before I
> joined
> > > the company.
> > >
> > > Are there any pointers for a 'from scratch', implementation?
> > >
> > > Should I start with the old code or start fresh from the new freebios2
> tree?
> > >
> > > For reference, the machine is a Intel PIII with a 82830 Northbridge, a
> > > 82801ca Southbridge, TI pci1450 card bus controller, and a pair of SMC
> SIO
> > > chips....
>
> I don't think we have good support for th 82830 at this time so the
> freebios2
> tree would be the one to work with.  You get romcc so you can code the
> memory initialization in C.  If you know what you are doing a huge chunk
of
> assembly is tolerable.  But doing things in C prevents a lot of stupid
> typos.
>
> I just looked the code in the freebios1 tree for the 82830 does not even
> attempt to do SPD based memory initialization so it will not work with
> arbitrary memory.  So definitely freebios2 using some of the freebios1
> code as reference.
>
> I don't think the freebios1 tree can code with a pair of superio chips
> either.
>
> The freebios2 tree comes with multiple devices of the same type trivially.
>
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios




From matt at rolec.ltd.uk  Mon Mar 15 07:49:00 2004
From: matt at rolec.ltd.uk (Matt Jarvis)
Date: Mon Mar 15 07:49:00 2004
Subject: linuxbios on epia
Message-ID: <1079356283.10189.6.camel@localhost.localdomain>

Hi

I'm having a small problem getting Linuxbios to run on an epia 5000.
Everything appears to work fine, and I can load my payload of either
Etherboot or Filo, but once it gets to actually booting my kernel, the
output on the serial console stops at :

Jumping to entry point...

Is this a problem with my kernel ( the same kernel boots fine with the
standard epia bios ) ? I've tried booting both a standard kernel and an
elf image of the kernel, with the same outcome. The full output from
Linuxbios is below, I hope someone can help with this problem. Thanks in
advance

Matt

LinuxBIOS-1.0.0 Mon Mar 15 12:50:20 GMT 2004 starting...
Enabled first bank of RAM: 0x04000000 bytes
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.0.0 Mon Mar 15 12:50:20 GMT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Scanning PCI bus...PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/0601]
PCI: 00:01.0 [1106/8601]
PCI: 00:11.0 [1106/8231]
PCI: 00:11.1 [1106/0571]
PCI: 00:11.2 [1106/3038]
PCI: 00:11.3 [1106/3038]
PCI: 00:11.4 [1106/8235]
PCI: 00:11.5 [1106/3058]
PCI: 00:11.6 [1106/3068]
PCI: 00:12.0 [1106/3065]
PCI: pci_scan_bus for bus 1
PCI: pci_scan_bus returning with max=01
PCI: pci_scan_bus returning with max=01
done
Allocating PCI resources...
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
ASSIGN RESOURCES, bus 0
PCI: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io
PCI: 00:01.0 24 <- [0xfeb00000 - 0xfeafffff] bus 1 prefmem
PCI: 00:01.0 20 <- [0xfeb00000 - 0xfeafffff] bus 1 mem
PCI: 00:11.1 20 <- [0x00001c40 - 0x00001c4f] io
PCI: 00:11.2 20 <- [0x00001c00 - 0x00001c1f] io
PCI: 00:11.3 20 <- [0x00001c20 - 0x00001c3f] io
PCI: 00:11.5 10 <- [0x00001000 - 0x000010ff] io
PCI: 00:11.5 14 <- [0x00001c50 - 0x00001c53] io
PCI: 00:11.5 18 <- [0x00001c60 - 0x00001c63] io
PCI: 00:11.6 10 <- [0x00001400 - 0x000014ff] io
PCI: 00:12.0 10 <- [0x00001800 - 0x000018ff] io
PCI: 00:12.0 14 <- [0xfeb00000 - 0xfeb000ff] mem
ASSIGNED RESOURCES, bus 0
done.
Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06
PCI: 00:01.0 cmd <- 07
PCI: 00:11.0 cmd <- 87
PCI: 00:11.1 cmd <- 81
PCI: 00:11.2 cmd <- 01
PCI: 00:11.3 cmd <- 01
PCI: 00:11.4 cmd <- 00
PCI: 00:11.5 cmd <- 01
PCI: 00:11.6 cmd <- 01
PCI: 00:12.0 cmd <- 83
done.
Initializing PCI devices...
PCI devices initialized
Disable Cache
Bank2 64MB (MA type 0x8)
bank 4 MA 0x0: 0 bytes
bank 4 MA 0x8: 0 bytes
bank 4 MA 0xe: 0 bytes
Enable Cache
Total 64MB + frame buffer 0MB
Enabling shadow DRAM at 0xC0000-0xFFFFF: done
totalram: 64M
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:   64MB, 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    : 1
Vendor ID          : CentaurHauls
Processor Type     : 0x00
Processor Family   : 0x06
Processor Model    : 0x07
Processor Mask     : 0x00
Processor Stepping : 0x03
Feature flags      : 0x00803035
                                                                                                                                                             
                                                                                                                                                             
MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled
                                                                                                                                                             
Disabling local apic...done.
CPU #0 Initialized
Mainboard fixup
IDE enable in reg. 50 is 0x7
set IDE reg. 50 to 0x7
IRQs in reg. 4c are 0x4
setting reg. 4c to 0x4
enables in reg 0x40 0x8
enables in reg 0x40 read back as 0xb
enables in reg 0x9 0x8f
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x81
command in reg 0x4 reads back as 0x7
Ethernet fixup
Configuring VIA LAN
0
                                                                                                                                                             
LinuxBIOS-1.0.0 Mon Mar 15 12:58:49 GMT 2004 starting...
Enabled first bank of RAM: 0x04000000 bytes
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.0.0 Mon Mar 15 12:58:49 GMT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Scanning PCI bus...PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/0601]
PCI: 00:01.0 [1106/8601]
PCI: 00:11.0 [1106/8231]
PCI: 00:11.1 [1106/0571]
PCI: 00:11.2 [1106/3038]
PCI: 00:11.3 [1106/3038]
PCI: 00:11.4 [1106/8235]
PCI: 00:11.5 [1106/3058]
PCI: 00:11.6 [1106/3068]
PCI: 00:12.0 [1106/3065]
PCI: pci_scan_bus for bus 1
PCI: pci_scan_bus returning with max=01
PCI: pci_scan_bus returning with max=01
done
Allocating PCI resources...
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
ASSIGN RESOURCES, bus 0
PCI: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io
PCI: 00:01.0 24 <- [0xfeb00000 - 0xfeafffff] bus 1 prefmem
PCI: 00:01.0 20 <- [0xfeb00000 - 0xfeafffff] bus 1 mem
PCI: 00:11.1 20 <- [0x00001c40 - 0x00001c4f] io
PCI: 00:11.2 20 <- [0x00001c00 - 0x00001c1f] io
PCI: 00:11.3 20 <- [0x00001c20 - 0x00001c3f] io
PCI: 00:11.5 10 <- [0x00001000 - 0x000010ff] io
PCI: 00:11.5 14 <- [0x00001c50 - 0x00001c53] io
PCI: 00:11.5 18 <- [0x00001c60 - 0x00001c63] io
PCI: 00:11.6 10 <- [0x00001400 - 0x000014ff] io
PCI: 00:12.0 10 <- [0x00001800 - 0x000018ff] io
PCI: 00:12.0 14 <- [0xfeb00000 - 0xfeb000ff] mem
ASSIGNED RESOURCES, bus 0
done.
Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06
PCI: 00:01.0 cmd <- 07
PCI: 00:11.0 cmd <- 87
PCI: 00:11.1 cmd <- 81
PCI: 00:11.2 cmd <- 01
PCI: 00:11.3 cmd <- 01
PCI: 00:11.4 cmd <- 00
PCI: 00:11.5 cmd <- 01
PCI: 00:11.6 cmd <- 01
PCI: 00:12.0 cmd <- 83
done.
Initializing PCI devices...
PCI devices initialized
Disable Cache
Bank2 64MB (MA type 0x8)
bank 4 MA 0x0: 0 bytes
bank 4 MA 0x8: 0 bytes
bank 4 MA 0xe: 0 bytes
Enable Cache
Total 64MB + frame buffer 0MB
Enabling shadow DRAM at 0xC0000-0xFFFFF: done
totalram: 64M
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:   64MB, 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    : 1
Vendor ID          : CentaurHauls
Processor Type     : 0x00
Processor Family   : 0x06
Processor Model    : 0x07
Processor Mask     : 0x00
Processor Stepping : 0x03
Feature flags      : 0x00803035
                                                                                                                                                             
                                                                                                                                                             
MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled
                                                                                                                                                             
Disabling local apic...done.
CPU #0 Initialized
Mainboard fixup
IDE enable in reg. 50 is 0x7
set IDE reg. 50 to 0x7
IRQs in reg. 4c are 0x4
setting reg. 4c to 0x4
enables in reg 0x40 0x8
enables in reg 0x40 read back as 0xb
enables in reg 0x9 0x8f
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x81
command in reg 0x4 reads back as 0x7
Ethernet fixup
Configuring VIA LAN
RTC Init
RTC: Checksum invalid zeroing cmos
Invalid CMOS LB checksum
Final mainboard fixup
Southbridge fixup
IDE enable in reg. 50 is 0x7
set IDE reg. 50 to 0x7
IRQs in reg. 4c are 0x4
setting reg. 4c to 0x4
enables in reg 0x40 0xb
enables in reg 0x40 read back as 0xb
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
Ethernet fixup
Configuring VIA LAN
RTC Init
Invalid CMOS LB checksum
setting southbridge
Assigning IRQ 12 to 0:11.2
  Readback = 12
Assigning IRQ 12 to 0:11.3
  Readback = 12
Assigning IRQ 10 to 0:11.5
  Readback = 10
Assigning IRQ 10 to 0:11.6
  Readback = 10
setting ethernet
Assigning IRQ 11 to 0:12.0
  Readback = 11
setting pci slot
Checking IRQ routing tables...
/home/matt/freebios/src/arch/i386/lib/pirq_routing.c:   
30:check_pirq_routing_table() - irq_routing_table located at: 0x00009a20
done.
Copying IRQ routing tables to 0xf0000...done.
Verifing priq routing tables copy at 0xf0000...succeed
Wrote linuxbios table at: 00000500 - 000006a0  checksum 7bb5
                                                                                                                                                             
Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.2
                                                                                                                                                             
    37:init_bytes() - zkernel_start:0xfff00000  zkernel_mask:0x0000ffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x25f20 offset 0xc0 filesize 0xbea8
(cleaned up) New segment addr 0x100000 size 0x25f20 offset 0xc0 filesize
0xbea8
New segment addr 0x125f20 size 0x48 offset 0xbf80 filesize 0x48
(cleaned up) New segment addr 0x125f20 size 0x48 offset 0xbf80 filesize
0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000025f20
filesz: 0x000000000000bea8
Clearing Segment: addr: 0x000000000010bea8 memsz: 0x000000000001a078
Loading Segment: addr: 0x0000000000125f20 memsz: 0x0000000000000048
filesz: 0x0000000000000048
Jumping to boot code at 0x1088dc
FILO version 0.4.1 (root at fedora.rolec.ltd.uk) Mon Mar 15 12:57:54 GMT
2004
collect_sys_info: boot eax = 0xe1fb007
collect_sys_info: boot ebx = 0x3fb9df4
collect_sys_info: boot arg = 0x3fb9df4
malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks)
malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks)
collect_elfboot_info: Bootloader: elfboot
collect_elfboot_info: Version: 1.2
malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks)
collect_linuxbios_info: Searching for LinuxBIOS tables...
find_lb_table: Found canidate at: 00000500
find_lb_table: header checksum o.k.
find_lb_table: table checksum o.k.
find_lb_table: record count o.k.
collect_linuxbios_info: Found LinuxBIOS table at: 00000500
malloc_diag: alloc: 128 bytes (3 blocks), free: 16248 bytes (1 blocks)
convert_memmap: 0x00000000000000 0x00000000000700 16
convert_memmap: 0x00000000000700 0x0000000009f900 1
convert_memmap: 0x000000000c0000 0x00000000030000 1
convert_memmap: 0x000000000f0000 0x00000000000400 16
convert_memmap: 0x000000000f0400 0x00000003f0fc00 1
collect_sys_info: 0000000000000700-00000000000a0000
collect_sys_info: 00000000000c0000-00000000000f0000
collect_sys_info: 00000000000f0400-0000000004000000
collect_sys_info: RAM 64 MB
relocate: Current location: 0x100000-0x125f67
relocate: Relocating to 0x3fda090-0x3fffff7... ok
setup_timers: CPU 533 MHz
pci_init: Scanning PCI: found 10 devices
malloc_diag: alloc: 256 bytes (4 blocks), free: 16120 bytes (1 blocks)
pci_init: 00:00.0 1106:0601 0600 00
pci_init: 00:01.0 1106:8601 0604 00
pci_init: 00:11.0 1106:8231 0601 00
pci_init: 00:11.1 1106:0571 0101 8a
pci_init: 00:11.2 1106:3038 0c03 00
pci_init: 00:11.3 1106:3038 0c03 00
pci_init: 00:11.4 1106:8235 0000 00
pci_init: 00:11.5 1106:3058 0401 00
pci_init: 00:11.6 1106:3068 0780 00
pci_init: 00:12.0 1106:3065 0200 00
Press <Enter> for default boot, or <Esc> for boot prompt... timed out
boot: hda1:/boot/rolecsplash console=tty0 console=ttyS0,115200
malloc_diag: alloc: 328 bytes (5 blocks), free: 16048 bytes (1 blocks)
malloc_diag: alloc: 344 bytes (6 blocks), free: 16032 bytes (1 blocks)
file_open: dev=hda1, path=/boot/rolecsplash
find_ide_controller: found PCI IDE controller 1106:0571 prog_if=0x8a
find_ide_controller: primary channel: compatibility mode
find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4
ide_software_reset: Waiting for ide0 to become ready for reset... ok
init_drive: Testing for hda
init_drive: Probing for hda
init_drive: LBA mode, sectors=39102336
init_drive: Init device params... ok
hda: LBA 20GB: ST320014A
devopen: Partition 1 start 32 length 3127264
Mounted ext2fs
malloc_diag: alloc: 328 bytes (5 blocks), free: 16048 bytes (1 blocks)
elf_load: Not a bootable ELF image
malloc_diag: alloc: 344 bytes (6 blocks), free: 16032 bytes (1 blocks)
file_open: dev=hda1, path=/boot/rolecsplash
devopen: already open
malloc_diag: alloc: 328 bytes (5 blocks), free: 16048 bytes (1 blocks)
Found Linux version 2.4.24splash (root at rolec) #5 Thu Jan 15 12:13:33 GMT
2004 (protocol 0x203) (loadflags 0x1) bzImage.
init_linux_params: Setting up paramters at 0x90000
set_memory_size: 0000000000000700 - 00000000000a0000
set_memory_size: 00000000000c0000 - 00000000000f0000
set_memory_size: 00000000000f0400 - 0000000004000000
set_memory_size: ramtop=0x4000000
set_memory_size: ext_mem_k=64512, alt_mem_k=64512
parse_command_line: original command line: "console=tty0
console=ttyS0,115200"
parse_command_line: kernel command line at 0x91000
parse_command_line: kernel command line (33 bytes): "console=tty0
console=ttyS0,115200"
load_linux_kernel: offset=0x1600 addr=0x100000 size=0xe667d
Loading kernel... ok
start_linux: eip=0x100000
Jumping to entry point...




From ebiederman at lnxi.com  Mon Mar 15 08:25:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar 15 08:25:00 2004
Subject: linuxbios on epia
In-Reply-To: <1079356283.10189.6.camel@localhost.localdomain>
References: <1079356283.10189.6.camel@localhost.localdomain>
Message-ID: <m3ekrudxlg.fsf@maxwell.lnxi.com>

Matt Jarvis <matt at rolec.ltd.uk> writes:

> Hi
> 
> I'm having a small problem getting Linuxbios to run on an epia 5000.
> Everything appears to work fine, and I can load my payload of either
> Etherboot or Filo, but once it gets to actually booting my kernel, the
> output on the serial console stops at :
> 
> Jumping to entry point...
> 
> Is this a problem with my kernel ( the same kernel boots fine with the
> standard epia bios ) ? I've tried booting both a standard kernel and an
> elf image of the kernel, with the same outcome. 

You have run mkelfImage on that bzImage?   Possibly you don't have
serial console support compiled in.  Or possibly you are probing
for ISA devices in a way which fails under LinuxBIOS.  (That is rare
but I have seen ISA device probes kill a booting kernel).

What kernel is this that you are having problems with?

To go much farther on the debugging the easy step to do is to
get an early serial console patch and apply that so you get some
kernel output...

Eric



From rminnich at lanl.gov  Mon Mar 15 08:37:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 15 08:37:00 2004
Subject: linuxbios on epia
In-Reply-To: <1079356283.10189.6.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.44.0403150658360.4428-100000@maxroach.lanl.gov>

take out the tty0= line. You have no vga. Sometimes this fixes it.

ron



From rminnich at lanl.gov  Mon Mar 15 08:38:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 15 08:38:01 2004
Subject: linuxbios on epia
In-Reply-To: <m3ekrudxlg.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403150659480.4428-100000@maxroach.lanl.gov>

On 15 Mar 2004, Eric W. Biederman wrote:

> To go much farther on the debugging the easy step to do is to get an
> early serial console patch and apply that so you get some kernel
> output...
> 

if you can't find this let me know and I'll send it.

I'll also put it on the web page, I think.

ron



From bios-list at cox.net  Mon Mar 15 10:36:00 2004
From: bios-list at cox.net (Edgar Lovecraft)
Date: Mon Mar 15 10:36:00 2004
Subject: Tyan Tomcat i845GL (S2098)
In-Reply-To: <4051C2DB.1060007@onelabs.com>
References: <jbm.20040311222927.86490a44@User21>
  <4051C2DB.1060007@onelabs.com>
Message-ID: <jbm.20040315095756.f137a19c@User21>

Bari Ari wrote:
> 
> Edgar Lovecraft wrote:
> 
> > I am looking to develop a linuxbios for the Tyan Tomcat i845GL (S2098)
> > MB, it uses the i845GL chipset.
> 
> Send LSPCI.
> 
-- 
Possibly more than you wanted, but here is "lspci" and then "lspci -v"

lspci output:
00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host 
Bridge (rev 03)
00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] 
Chipset Integrated Graphics Device (rev 03)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corp. 82801DB ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 02)
00:1f.3 SMBus: Intel Corp. 82801DB SMBus (rev 02)
01:03.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 
10)
01:06.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 
10)

lspci -v output:
00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host 
Bridge (rev 03)
	Subsystem: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge
	Flags: bus master, fast devsel, latency 0
	Memory at e8000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [e4] #09 [1105]

00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] 
Chipset Integrated Graphics Device (rev 03) (prog-if 00 [VGA])
	Subsystem: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated 
Graphics Device
	Flags: bus master, fast devsel, latency 0, IRQ 10
	Memory at e0000000 (32-bit, prefetchable) [size=128M]
	Memory at ec100000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: [d0] Power Management version 1

00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 02) (prog-if 
00 [UHCI])
	Subsystem: Intel Corp. 82801DB USB (Hub #1)
	Flags: bus master, medium devsel, latency 0, IRQ 10
	I/O ports at d800 [size=32]

00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 02) (prog-if 
00 [UHCI])
	Subsystem: Intel Corp.: Unknown device 24c2
	Flags: bus master, medium devsel, latency 0, IRQ 3
	I/O ports at d000 [size=32]

00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 02) (prog-if 
00 [UHCI])
	Subsystem: Intel Corp.: Unknown device 24c2
	Flags: bus master, medium devsel, latency 0, IRQ 5
	I/O ports at d400 [size=32]

00:1d.7 USB Controller: Intel Corp. 82801DB USB EHCI Controller (rev 02) 
(prog-if 20 [EHCI])
	Subsystem: Intel Corp. 82801DB USB EHCI Controller
	Flags: bus master, medium devsel, latency 0, IRQ 12
	Memory at ec180000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2

00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev 82) (prog-if 
00 [Normal decode])
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: ec000000-ec0fffff

00:1f.0 ISA bridge: Intel Corp. 82801DB ISA Bridge (LPC) (rev 02)
	Flags: bus master, medium devsel, latency 0

00:1f.1 IDE interface: Intel Corp. 82801DB ICH4 IDE (rev 02) (prog-if 8a 
[Master SecP PriP])
	Subsystem: Intel Corp.: Unknown device 24c2
	Flags: bus master, medium devsel, latency 0, IRQ 5
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at <unassigned>
	I/O ports at f000 [size=16]
	Memory at 3f800000 (32-bit, non-prefetchable) [size=1K]

00:1f.3 SMBus: Intel Corp. 82801DB SMBus (rev 02)
	Subsystem: Intel Corp.: Unknown device 24c2
	Flags: medium devsel, IRQ 9
	I/O ports at 0500 [size=32]

01:03.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 
10)
	Subsystem: Intel Corp. EtherExpress PRO/100 S Server Adapter
	Flags: bus master, medium devsel, latency 32, IRQ 15
	Memory at ec041000 (32-bit, non-prefetchable) [size=4K]
	I/O ports at c000 [size=64]
	Memory at ec000000 (32-bit, non-prefetchable) [size=128K]
	Capabilities: [dc] Power Management version 2

01:06.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 
10)
	Subsystem: Intel Corp. EtherExpress PRO/100 S Server Adapter
	Flags: bus master, medium devsel, latency 32, IRQ 11
	Memory at ec040000 (32-bit, non-prefetchable) [size=4K]
	I/O ports at c400 [size=64]
	Memory at ec020000 (32-bit, non-prefetchable) [size=128K]
	Capabilities: [dc] Power Management version 2


--EAL--




From bari at onelabs.com  Mon Mar 15 11:02:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Mon Mar 15 11:02:00 2004
Subject: Tyan Tomcat i845GL (S2098)
In-Reply-To: <jbm.20040315095756.f137a19c@User21>
References: <jbm.20040311222927.86490a44@User21>  <4051C2DB.1060007@onelabs.com> <jbm.20040315095756.f137a19c@User21>
Message-ID: <4055D912.9010202@onelabs.com>

Edgar Lovecraft wrote:
>>>I am looking to develop a linuxbios for the Tyan Tomcat i845GL (S2098)
>>>MB, it uses the i845GL chipset.
>>
>>Send LSPCI.
>>
"Jia Jianwei" <JJia at Fortinet.com> was working on the 845 a couple months 
ago:


The source tree is changed but very similar,  As you know, many boards have
the same chipset, but have different superio and pci devices. And we also
merged some ethernet drivers and file system so that we can download from a
TFTP server in very early stage. If I can finish the BIOS on this board, Of
course I'll contribute some general code to freebios so that more developers
can benifit from it.

Jianwei

----- Original Message -----
From: "ron minnich" <rminnich at lanl.gov>
To: "Jia Jianwei" <JJia at Fortinet.com>
Cc: <linuxbios at clustermatic.org>
Sent: Monday, January 19, 2004 2:29 PM
Subject: Re: 82845GV DDR SDRAM initialization



 >> On Mon, 19 Jan 2004, Jia Jianwei wrote:
 >>
 >
 >>> > Thank you very much!
 >>> > I'm using V1 and have changed a lot to fit our own need.
 >
 >>
 >> now you are worrying me ...
 >>
 >> what are you changing? If possible we'd like to merge 845 support back
 >> into the tree.
 >>
 >> ron






From ollie at lanl.gov  Mon Mar 15 11:16:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Mar 15 11:16:01 2004
Subject: Asus Cusi-FX
In-Reply-To: <Pine.LNX.4.44.0403121713090.23348-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0403121713090.23348-100000@ccs-mail.lanl.gov>
Message-ID: <1079368682.25319.8.camel@exponential.lanl.gov>

On Fri, 2004-03-12 at 17:20, Hendricks David W. wrote:
> Asus stuff typically is not supported because they do weird things with 
> their SMBus. It uses a SiS630, however, so maybe it's not a totally lost 
> cause. Perhaps Ollie Lho can give us his opinion on this.
> 

Asus usually use their own undocumented ASIC for SMBus and other stuff.
We have no way to get SPD.

Ollie

> Is it possible to use another mainboard with the SiS630? I'm really 
> skeptical about support on Asus mainboards.
> 




From donbrown at usa.net  Mon Mar 15 11:31:00 2004
From: donbrown at usa.net (Don Brown)
Date: Mon Mar 15 11:31:00 2004
Subject: Supported AMD64 Combinations
In-Reply-To: <20040315160200.11860.98243.Mailman@nwn.definitive.org>
Message-ID: <000001c40aad$f8bb7030$6401a8c0@DEMOLAPTOP>

What are the best supported LinuxBIOS combinations for AMD 64 bit CPU
and motherboard?

Cheers, Don Brown
Atlanta GA




From YhLu at tyan.com  Mon Mar 15 13:14:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Mar 15 13:14:00 2004
Subject: =?GB2312?B?tPC4tDogVHlhbiBDaGFuZ2VzIGZvciAxLjEuNg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D23C@TYANWEB>

Ron/Eric,

It seems all the pnp_device init are not called.

Regards

YH.

Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD 8111
Enumerating: Winbond w83627hf
Enumerating buses...PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
amdk8_scan_chains max: 0 starting...
Hyper transport scan link: 0 max: 1
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] bus ops
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] ops
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] bus ops
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] ops
PCI: 01:02.1 [1022/7451] enabled
PCI: 01:03.0 [1022/7460] bus ops
PCI: 01:03.0 [1022/7460] enabled
PCI: 01:04.0 [1022/7468] bus ops
PCI: 01:04.0 [1022/7468] enabled
PCI: 01:04.1 [1022/7469] ops
PCI: 01:04.1 [1022/7469] enabled
PCI: 01:04.2 [1022/746a] enabled
PCI: 01:04.3 [1022/746b] ops
PCI: 01:04.3 [1022/746b] enabled
PCI: 01:04.5 [1022/746d] ops
PCI: 01:04.5 [1022/746d] disabled
PCI: 01:04.6 [1022/746e] ops
PCI: 01:04.6 [1022/746e] disabled
PCI: pci_scan_bus for bus 2
PCI: 02:06.0 [9005/801f] enabled
PCI: 02:06.1 [9005/801f] enabled
PCI: 02:09.0 [14e4/16a7] enabled
PCI: 02:09.1 [14e4/16a7] 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 for bus 4
PCI: 04:00.0 [1022/7464] ops
PCI: 04:00.0 [1022/7464] enabled
PCI: 04:00.1 [1022/7464] ops
PCI: 04:00.1 [1022/7464] enabled
PCI: 04:00.2 [1022/7463] ops
PCI: 04:00.2 [1022/7463] enabled
PCI: 04:01.0 [1022/7462] ops
PCI: 04:01.0 [1022/7462] disabled
PCI: 04:06.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=04
PNP: 002e.0 disabled
PNP: 002e.1 disabled
PNP: 002e.2 enabled
PNP: 002e.3 disabled
PNP: 002e.5 enabled
PNP: 002e.6 disabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
PNP: 002e.b disabled
PCI: pci_scan_bus returning with max=04
Hyper transport scan link: 0 new max: 4
Hypertransport scan link done
amdk8_scan_chains max: 4 done
amdk8_scan_chains max: 4 starting...
amdk8_scan_chains max: 4 done
PCI: pci_scan_bus returning with max=04
done
Allocating resources...
PNP: 002e.8 missing read_resources
PNP: 002e.9 missing read_resources
Allocating VGA resource
ASSIGN RESOURCES, bus 0
PCI: 00:18.0 c0 <- [0x00001000 - 0x00003fff] node 0 link 0 io
PCI: 00:18.0 b8 <- [0xfc000000 - 0xfd2fffff] node 0 link 0 mem
ASSIGN RESOURCES, bus 1
PCI: 01:01.0 1c <- [0x00001000 - 0x00001fff] bus 2 io
PCI: 01:01.0 24 <- [0xfd200000 - 0xfd1fffff] bus 2 prefmem
PCI: 01:01.0 20 <- [0xfd100000 - 0xfd1fffff] bus 2 mem
ASSIGN RESOURCES, bus 2
PCI: 02:06.0 10 <- [0x00001000 - 0x000010ff] io
PCI: 02:06.0 14 <- [0xfd140000 - 0xfd141fff] mem
PCI: 02:06.0 1c <- [0x00001400 - 0x000014ff] io
PCI: 02:06.1 10 <- [0x00001800 - 0x000018ff] io
PCI: 02:06.1 14 <- [0xfd142000 - 0xfd143fff] mem
PCI: 02:06.1 1c <- [0x00001c00 - 0x00001cff] io
PCI: 02:09.0 10 <- [0xfd100000 - 0xfd10ffff] mem
PCI: 02:09.0 18 <- [0xfd110000 - 0xfd11ffff] mem
PCI: 02:09.1 10 <- [0xfd120000 - 0xfd12ffff] mem
PCI: 02:09.1 18 <- [0xfd130000 - 0xfd13ffff] mem
ASSIGNED RESOURCES, bus 2
PCI: 01:01.1 10 <- [0xfd200000 - 0xfd200fff] mem
PCI: 01:02.0 1c <- [0x00003000 - 0x00002fff] bus 3 io
PCI: 01:02.0 24 <- [0xfd200000 - 0xfd1fffff] bus 3 prefmem
PCI: 01:02.0 20 <- [0xfd200000 - 0xfd1fffff] bus 3 mem
PCI: 01:02.1 10 <- [0xfd201000 - 0xfd201fff] mem
PCI: 01:03.0 1c <- [0x00002000 - 0x00002fff] bus 4 io
PCI: 01:03.0 24 <- [0xfd200000 - 0xfd1fffff] bus 4 prefmem
PCI: 01:03.0 20 <- [0xfc000000 - 0xfd0fffff] bus 4 mem
ASSIGN RESOURCES, bus 4
PCI: 04:00.0 10 <- [0xfd000000 - 0xfd000fff] mem
PCI: 04:00.1 10 <- [0xfd001000 - 0xfd001fff] mem
PCI: 04:00.2 10 <- [0xfd003000 - 0xfd0030ff] mem
PCI: 04:00.2 14 <- [0xfd004000 - 0xfd00401f] mem
PCI: 04:06.0 10 <- [0xfc000000 - 0xfcffffff] mem
PCI: 04:06.0 14 <- [0x00002000 - 0x000020ff] io
PCI: 04:06.0 18 <- [0xfd002000 - 0xfd002fff] mem
ASSIGNED RESOURCES, bus 4
PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] io
PCI: 01:04.0 00 <- [0x00000000 - 0xffffffff] mem
ASSIGN RESOURCES, bus 0
PNP: 002e.2 60 <- [0x000003f8 - 0x000003ff] io
PNP: 002e.2 70 <- [0x00000004 - 0x00000004] irq
PNP: 002e.5 60 <- [0x00000060 - 0x00000060] io
PNP: 002e.5 62 <- [0x00000064 - 0x00000064] io
PNP: 002e.5 70 <- [0x00000001 - 0x00000001] irq
PNP: 002e.5 72 <- [0x0000000c - 0x0000000c] irq
PNP: 002e.8 missing set_resources
PNP: 002e.9 missing set_resources
ASSIGNED RESOURCES, bus 0
PCI: 01:04.1 20 <- [0x00003420 - 0x0000342f] io
PCI: 01:04.2 10 <- [0x00003400 - 0x0000341f] io
PCI: 01:04.3 58 <- [0x00003000 - 0x000030ff] io
ASSIGNED RESOURCES, bus 1
PCI: 00:18.3 94 <- [0xf8000000 - 0xfbffffff] mem <gart>
PCI: 00:19.3 94 <- [0xf8000000 - 0xfbffffff] mem <gart>
ASSIGNED RESOURCES, bus 0
done.
Enabling resourcess...
PCI: 00:18.0 cmd <- 140
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 147
PCI: 02:06.0 cmd <- 143
PCI: 02:06.1 cmd <- 143
PCI: 02:09.0 cmd <- 142
PCI: 02:09.1 cmd <- 142
PCI: 01:01.1 cmd <- 146
PCI: 01:02.0 bridge ctrl <- 0003
PCI: 01:02.0 cmd <- 147
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 000b
PCI: 01:03.0 cmd <- 147
PCI: 04:00.0 cmd <- 142
PCI: 04:00.1 cmd <- 142
PCI: 04:00.2 cmd <- 142
PCI: 04:06.0 cmd <- 1c3
PCI: 01:04.0 cmd <- 14f
PNP: 002e.8 missing enable_resources
PNP: 002e.9 missing enable_resources
PCI: 01:04.1 cmd <- 141
PCI: 01:04.2 cmd <- 141
PCI: 01:04.3 cmd <- 141
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
PCI: 00:19.0 cmd <- 140
PCI: 00:19.1 cmd <- 140
PCI: 00:19.2 cmd <- 140
PCI: 00:19.3 cmd <- 140
done.
Initializing devices...
PCI: 00:18.0 init
NB: Function 0 Misc Control.. done.
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:19.0 init
NB: Function 0 Misc Control.. done.
PCI: 00:19.3 init
NB: Function 3 Misc Control.. done.
PCI: 01:01.0 init
PCI: 01:02.0 init
PCI: 01:03.0 init
PCI: 01:04.0 init
RTC Init
enabling HPET @0xfed00000
PCI: 01:04.1 init
IDE1 IDE0 PCI: 01:04.3 init
set power on after power fail
PCI: 04:00.0 init
PCI: 04:00.1 init
PCI: 04:00.2 init
Devices initialized


From ebiederman at lnxi.com  Mon Mar 15 13:28:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar 15 13:28:00 2004
Subject: =?gb2312?b?tPC4tA==?=: Tyan Changes for 1.1.6
In-Reply-To: <3174569B9743D511922F00A0C94314230466D23C@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D23C@TYANWEB>
Message-ID: <m3znaivsxk.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Ron/Eric,
> 
> It seems all the pnp_device init are not called.

Right.  That looks like what is happening.  I'm buried in 
another bug hunt at the moment...

Eric


From dwh at lanl.gov  Mon Mar 15 13:41:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Mar 15 13:41:01 2004
Subject: Supported AMD64 Combinations
In-Reply-To: <000001c40aad$f8bb7030$6401a8c0@DEMOLAPTOP>
Message-ID: <Pine.LNX.4.44.0403151158030.3847-100000@ccs-mail.lanl.gov>

If you need VGA, the Tyan S2885. yhlu at tyan.com is actively working on 
LinuxBIOS for the Tyan mainboards.

The Arima Rioworks HDAMA is also being worked on and currently powers 
Lightning, which currently holds #6 on the top 500 list (top500.org).

On Mon, 15 Mar 2004, Don Brown wrote:

> 
> What are the best supported LinuxBIOS combinations for AMD 64 bit CPU
> and motherboard?
> 
> Cheers, Don Brown
> Atlanta GA
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From dwh at lanl.gov  Mon Mar 15 13:43:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Mar 15 13:43:00 2004
Subject: Supported AMD64 Combinations
In-Reply-To: <000001c40aad$f8bb7030$6401a8c0@DEMOLAPTOP>
Message-ID: <Pine.LNX.4.44.0403151203350.3847-100000@ccs-mail.lanl.gov>

Oh, I should've asked if you're looking into socket 754, 940, or 939 CPUs.

On Mon, 15 Mar 2004, Don Brown wrote:

> 
> What are the best supported LinuxBIOS combinations for AMD 64 bit CPU
> and motherboard?
> 
> Cheers, Don Brown
> Atlanta GA
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From linuxbios at smashed.demon.co.uk  Mon Mar 15 14:16:01 2004
From: linuxbios at smashed.demon.co.uk (James Weir)
Date: Mon Mar 15 14:16:01 2004
Subject: Quick Offlist Question
In-Reply-To: <Pine.LNX.4.44.0403151203350.3847-100000@ccs-mail.lanl.gov>
Message-ID: <E1B2xug-0009sL-0V@anchor-post-31.mail.demon.net>

Hi All,

A little off-list but I am sure someone on the list will probably be able to
help.  I am looking to set up a PC104+ system for high performance frame
grabbing (MPEG or M-JPEG Compression) and have been looking at various
processor cards ranging from 233/300MHz Geode processors to Transmeta Crusoe
type boards with speeds of 533/800MHz have any of you guys and gals used
these sorts of boards and if so how have you found the performance, and
secondly has anyone used linuxbios on these boards to help speed up the
boot.

Cheers All,

James.



From dwh at lanl.gov  Mon Mar 15 14:25:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Mar 15 14:25:01 2004
Subject: Quick Offlist Question
In-Reply-To: <E1B2xug-0009sL-0V@anchor-post-31.mail.demon.net>
Message-ID: <Pine.LNX.4.44.0403151246350.3847-100000@ccs-mail.lanl.gov>

Does the EPIA have hardware MPEG compression?

On Mon, 15 Mar 2004, James Weir wrote:

> Hi All,
> 
> A little off-list but I am sure someone on the list will probably be able to
> help.  I am looking to set up a PC104+ system for high performance frame
> grabbing (MPEG or M-JPEG Compression) and have been looking at various
> processor cards ranging from 233/300MHz Geode processors to Transmeta Crusoe
> type boards with speeds of 533/800MHz have any of you guys and gals used
> these sorts of boards and if so how have you found the performance, and
> secondly has anyone used linuxbios on these boards to help speed up the
> boot.
> 
> Cheers All,
> 
> James.
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From nathanael at gnat.ca  Mon Mar 15 14:44:00 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Mon Mar 15 14:44:00 2004
Subject: Quick Offlist Question
In-Reply-To: <Pine.LNX.4.44.0403151246350.3847-100000@ccs-mail.lanl.gov>
Message-ID: <33DCDDDA-76BC-11D8-A181-0003931B4D6A@gnat.ca>

On Monday, March 15, 2004, at 11:46 AM, Hendricks David W. wrote:

> Does the EPIA have hardware MPEG compression?

epia-M does.
-- 
Nathanael D. Noblet
Gnat Solutions
412 - 135 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/



From linuxbios at smashed.demon.co.uk  Mon Mar 15 15:36:01 2004
From: linuxbios at smashed.demon.co.uk (James Weir)
Date: Mon Mar 15 15:36:01 2004
Subject: Quick Offlist Question
In-Reply-To: <33DCDDDA-76BC-11D8-A181-0003931B4D6A@gnat.ca>
Message-ID: <E1B2zA2-000Eqh-0V@anchor-post-31.mail.demon.net>

Thanks guys,

I really need it to be a pc104+ form factor board, I am intending to use a
separate pc104+ framegrabber.

James.

-----Original Message-----
From: linuxbios-admin at clustermatic.org
[mailto:linuxbios-admin at clustermatic.org] On Behalf Of Nathanael Noblet
Sent: 15 March 2004 20:06
To: Hendricks David W.
Cc: James Weir; LinuxBIOS
Subject: Re: Quick Offlist Question


On Monday, March 15, 2004, at 11:46 AM, Hendricks David W. wrote:

> Does the EPIA have hardware MPEG compression?

epia-M does.
-- 
Nathanael D. Noblet
Gnat Solutions
412 - 135 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/

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



From dwh at lanl.gov  Mon Mar 15 17:25:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Mar 15 17:25:00 2004
Subject: Kernel 2.6.4 + AGP + Tyan S2885
Message-ID: <Pine.LNX.4.44.0403151539360.13962-100000@ccs-mail.lanl.gov>

Good news for S2885 users, looks like the just-released 2.6.4 kernel has 
better AGP support than the previous 2.6 kernels. I could successfully 
load the nVidia video BIOS with the emulator, load the agpgart module 
(amd64_agp), and start X with AGP support. 



From dwh at lanl.gov  Mon Mar 15 18:46:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Mar 15 18:46:01 2004
Subject: ECC init on K8 systems
Message-ID: <Pine.LNX.4.44.0403151646550.13962-100000@ccs-mail.lanl.gov>

Just out of curiosity, why does the ECC scrubber zero only 2M chunks at 
once? Also, it seems that there's an 84ms built in delay. Is this 
something that can be tweaked to specific hardware? I was hoping that I 
could bring the delay down by using SCRUB_81_9us or bigger chunks or 
something.



From bari at onelabs.com  Mon Mar 15 22:14:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Mon Mar 15 22:14:00 2004
Subject: Quick Offlist Question
In-Reply-To: <E1B2xug-0009sL-0V@anchor-post-31.mail.demon.net>
References: <E1B2xug-0009sL-0V@anchor-post-31.mail.demon.net>
Message-ID: <405676A1.7040205@onelabs.com>

James Weir wrote:

> Hi All,
> 
> A little off-list but I am sure someone on the list will probably be able to
> help.  I am looking to set up a PC104+ system for high performance frame
> grabbing (MPEG or M-JPEG Compression) and have been looking at various
> processor cards ranging from 233/300MHz Geode processors to Transmeta Crusoe
> type boards with speeds of 533/800MHz have any of you guys and gals used
> these sorts of boards and if so how have you found the performance, and
> secondly has anyone used linuxbios on these boards to help speed up the
> boot.

I'd build my own for the application, but for low volume off the shelf, 
look at a board like:

http://www.globalamericaninc.com/products_services/pc104/3001118.php

Up to 800 MHz Via Eden CPU + Savage4 Video for MPEG playback. 800MHz may 
be fast enough for XviD or MPEG encoding at your target resolution.

-Bari





From rminnich at lanl.gov  Tue Mar 16 03:18:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar 16 03:18:01 2004
Subject: Tyan Tomcat i845GL (S2098)
In-Reply-To: <jbm.20040315095756.f137a19c@User21>
Message-ID: <Pine.LNX.4.44.0403160139080.11479-100000@maxroach.lanl.gov>

at this point, here at LANL, our focus is 64-bit boards and embedded stuff 
like EPIA, so this one falls through the cracks here. We can assist you 
with porting but can not do the work ourselves. 

So if you want an assisted port letus know.

ron



From matt at rolec.ltd.uk  Tue Mar 16 03:50:01 2004
From: matt at rolec.ltd.uk (Matt Jarvis)
Date: Tue Mar 16 03:50:01 2004
Subject: epia and vga
Message-ID: <1079428311.5770.9.camel@localhost.localdomain>

Thanks to Ron and Eric's kind words yesterday, and me kicking my brain
into gear, I got Linuxbios and Filo up and running on my epia yesterday.
However, I now have a couple of other issues which I've come to a dead
halt with. I've been trying to add vga support, having extracted the
original vga bios using dd as per the Epia How To. This appears to be
detected correctly during boot and the screen turns on, then flickers
with some garbage on it. If I have agpgart enabled in the kernel I get a
hard kernel hang when the agp chipset is detected - is this normal ?
I've tried this with a 2.4.24 and 2.4.22 kernel with the same result.
Also I never actually get any output on the VGA, just random noise and
colours every couple of seconds. The memory on my Epia is also detected
incorrectly as 64K rather than 128K. Can anyone point me in the right
direction here ? Thanks, 

Matt


LinuxBIOS-1.0.0 Mon Mar 15 17:26:20 GMT 2004 starting...
Enabled first bank of RAM: 0x04000000 bytes
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.0.0 Mon Mar 15 17:26:20 GMT 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Scanning PCI bus...PCI: pci_scan_bus for bus 0
PCI: 00:00.0 [1106/0601]
PCI: 00:01.0 [1106/8601]
PCI: 00:11.0 [1106/8231]
PCI: 00:11.1 [1106/0571]
PCI: 00:11.2 [1106/3038]
PCI: 00:11.3 [1106/3038]
PCI: 00:11.4 [1106/8235]
PCI: 00:11.5 [1106/3058]
PCI: 00:11.6 [1106/3068]
PCI: 00:12.0 [1106/3065]
PCI: pci_scan_bus for bus 1
PCI: 01:00.0 [1023/8500]
PCI: pci_scan_bus returning with max=01
PCI: pci_scan_bus returning with max=01
done
Allocating PCI resources...
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
PCI: 00:00.0 register 10(00000008), read-only ignoring it
ASSIGN RESOURCES, bus 0
PCI: 00:01.0 1c <- [0x00001000 - 0x00000fff] bus 1 io
PCI: 00:01.0 24 <- [0xfe900000 - 0xfe8fffff] bus 1 prefmem
PCI: 00:01.0 20 <- [0xfd800000 - 0xfe8fffff] bus 1 mem
ASSIGN RESOURCES, bus 1
PCI: 01:00.0 10 <- [0xfd800000 - 0xfdffffff] mem
PCI: 01:00.0 14 <- [0xfe800000 - 0xfe81ffff] mem
PCI: 01:00.0 18 <- [0xfe000000 - 0xfe7fffff] mem
ASSIGNED RESOURCES, bus 1
PCI: 00:11.1 20 <- [0x00001c40 - 0x00001c4f] io
PCI: 00:11.2 20 <- [0x00001c00 - 0x00001c1f] io
PCI: 00:11.3 20 <- [0x00001c20 - 0x00001c3f] io
PCI: 00:11.5 10 <- [0x00001000 - 0x000010ff] io
PCI: 00:11.5 14 <- [0x00001c50 - 0x00001c53] io
PCI: 00:11.5 18 <- [0x00001c60 - 0x00001c63] io
PCI: 00:11.6 10 <- [0x00001400 - 0x000014ff] io
PCI: 00:12.0 10 <- [0x00001800 - 0x000018ff] io
PCI: 00:12.0 14 <- [0xfe900000 - 0xfe9000ff] mem
ASSIGNED RESOURCES, bus 0
Allocating VGA resource
done.
Enabling PCI resourcess...PCI: 00:00.0 cmd <- 06
PCI: 00:01.0 cmd <- 07
PCI: 00:11.0 cmd <- 87
PCI: 00:11.1 cmd <- 81
PCI: 00:11.2 cmd <- 01
PCI: 00:11.3 cmd <- 01
PCI: 00:11.4 cmd <- 00
PCI: 00:11.5 cmd <- 01
PCI: 00:11.6 cmd <- 01
PCI: 00:12.0 cmd <- 83
PCI: 01:00.0 cmd <- 03
done.
Initializing PCI devices...
PCI devices initialized
Disable Cache
Bank2 64MB (MA type 0x8)
bank 4 MA 0x0: 0 bytes
bank 4 MA 0x8: 0 bytes
bank 4 MA 0xe: 0 bytes
Enable Cache
Total 60MB + frame buffer 4MB
Enabling shadow DRAM at 0xC0000-0xFFFFF: done
totalram: 60M
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:   32MB, type WB
Setting variable MTRR 1, base:   32MB, range:   16MB, type WB
Setting variable MTRR 2, base:   48MB, range:    8MB, type WB
Setting variable MTRR 3, base:   56MB, range:    4MB, 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    : 1
Vendor ID          : CentaurHauls
Processor Type     : 0x00
Processor Family   : 0x06
Processor Model    : 0x07
Processor Mask     : 0x00
Processor Stepping : 0x03
Feature flags      : 0x00803035
                                                                                
                                                                                
MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled
                                                                                
Disabling local apic...done.
CPU #0 Initialized
Mainboard fixup
IDE enable in reg. 50 is 0x7
set IDE reg. 50 to 0x7
IRQs in reg. 4c are 0x4
setting reg. 4c to 0x4
enables in reg 0x40 0x8
enables in reg 0x40 read back as 0xb
enables in reg 0x9 0x8f
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x81
command in reg 0x4 reads back as 0x7
Ethernet fixup
Configuring VIA LAN
RTC Init
RTC: Checksum invalid zeroing cmos
Invalid CMOS LB checksum
Final mainboard fixup
Southbridge fixup
IDE enable in reg. 50 is 0x7
set IDE reg. 50 to 0x7
IRQs in reg. 4c are 0x4
setting reg. 4c to 0x4
enables in reg 0x40 0xb
enables in reg 0x40 read back as 0xb
enables in reg 0x9 0x8a
enables in reg 0x9 read back as 0x8a
command in reg 0x4 0x7
command in reg 0x4 reads back as 0x7
Ethernet fixup
Configuring VIA LAN
RTC Init
Invalid CMOS LB checksum
setting southbridge
Assigning IRQ 12 to 0:11.2
  Readback = 12
Assigning IRQ 12 to 0:11.3
  Readback = 12
Assigning IRQ 10 to 0:11.5
  Readback = 10
Assigning IRQ 10 to 0:11.6
  Readback = 10
setting ethernet
Assigning IRQ 11 to 0:12.0
  Readback = 11
setting pci slot
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1023, did=8500
0x55 0xaa 0x60 0xeb 0x53 0x37 0x34 0x30 0x30 0x30 0x37 0xc2 0x8a 0x2a
0x2a 0x520biosint: # 0x1a, eax 0xb109 ebx 0x100 ecx 0x100 edx 0xa699
biosint: ebp 0x10fd8 esp 0xfc9 edi 0x2 esi 0x13484
biosint: ip 0x5ef4 cs 0xc000 flags 0x16
0xb109: bus 1 devfn 0x0 reg 0x2 val 0x8500
biosint: # 0x25, eax 0xc000 ebx 0x100 ecx 0x8500 edx 0x3c2
biosint: ebp 0x10fd8 esp 0xfc7 edi 0x2 esi 0x13484
biosint: ip 0x232f cs 0xc000 flags 0x246
biosint: Unsupport int #0x25
biosint: # 0x1a, eax 0xb108 ebx 0x80000000 ecx 0x82351180 edx 0x3c4
biosint: ebp 0x10fd8 esp 0xfc5 edi 0xfb esi 0x13484
biosint: ip 0x261a cs 0xc000 flags 0x287
0xb108: bus 0 devfn 0x0 reg 0xfb val 0xa0
Checking IRQ routing tables...
/home/matt/freebios/src/arch/i386/lib/pirq_routing.c:   
30:check_pirq_routing_0done.
Copying IRQ routing tables to 0xf0000...done.
Verifing priq routing tables copy at 0xf0000...succeed
Wrote linuxbios table at: 00000500 - 000006a0  checksum a371
                                                                                
Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.2
                                                                                
    37:init_bytes() - zkernel_start:0xfffd0000  zkernel_mask:0x0000ffff
Found ELF candiate at offset 0
New segment addr 0x100000 size 0x26440 offset 0xc0 filesize 0xc3a8
(cleaned up) New segment addr 0x100000 size 0x26440 offset 0xc0 filesize
0xc3a8
New segment addr 0x126440 size 0x48 offset 0xc480 filesize 0x48
(cleaned up) New segment addr 0x126440 size 0x48 offset 0xc480 filesize
0x48
Dropping non PT_LOAD segment
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000026440
filesz: 0x08Clearing Segment: addr: 0x000000000010c3a8 memsz:
0x000000000001a098
Loading Segment: addr: 0x0000000000126440 memsz: 0x0000000000000048
filesz: 0x08Jumping to boot code at 0x108c5c
FILO version 0.4.1 (root at fedora.rolec.ltd.uk) Mon Mar 15 17:15:57 GMT
2004
collect_sys_info: boot eax = 0xe1fb007
collect_sys_info: boot ebx = 0x3bb9df4
collect_sys_info: boot arg = 0x3bb9df4
malloc_diag: alloc: 0 bytes (0 blocks), free: 16376 bytes (1 blocks)
malloc_diag: alloc: 24 bytes (1 blocks), free: 16352 bytes (1 blocks)
collect_elfboot_info: Bootloader: elfboot
collect_elfboot_info: Version: 1.2
malloc_diag: alloc: 40 bytes (2 blocks), free: 16336 bytes (1 blocks)
collect_linuxbios_info: Searching for LinuxBIOS tables...
find_lb_table: Found canidate at: 00000500
find_lb_table: header checksum o.k.
find_lb_table: table checksum o.k.
find_lb_table: record count o.k.
collect_linuxbios_info: Found LinuxBIOS table at: 00000500
malloc_diag: alloc: 128 bytes (3 blocks), free: 16248 bytes (1 blocks)
convert_memmap: 0x00000000000000 0x00000000000700 16
convert_memmap: 0x00000000000700 0x0000000009f900 1
convert_memmap: 0x000000000c0000 0x00000000030000 1
convert_memmap: 0x000000000f0000 0x00000000000400 16
convert_memmap: 0x000000000f0400 0x00000003b0fc00 1
collect_sys_info: 0000000000000700-00000000000a0000
collect_sys_info: 00000000000c0000-00000000000f0000
collect_sys_info: 00000000000f0400-0000000003c00000
collect_sys_info: RAM 60 MB
relocate: Current location: 0x100000-0x126487
relocate: Relocating to 0x3bd9b70-0x3bffff7... ok
setup_timers: CPU 533 MHz
pci_init: Scanning PCI: found 11 devices
malloc_diag: alloc: 272 bytes (4 blocks), free: 16104 bytes (1 blocks)
pci_init: 00:00.0 1106:0601 0600 00
pci_init: 00:01.0 1106:8601 0604 00
pci_init: 01:00.0 1023:8500 0300 00
pci_init: 00:11.0 1106:8231 0601 00
pci_init: 00:11.1 1106:0571 0101 8a
pci_init: 00:11.2 1106:3038 0c03 00
pci_init: 00:11.3 1106:3038 0c03 00
pci_init: 00:11.4 1106:8235 0000 00
pci_init: 00:11.5 1106:3058 0401 00
pci_init: 00:11.6 1106:3068 0780 00
pci_init: 00:12.0 1106:3065 0200 00
Press <Enter> for default boot, or <Esc> for boot prompt... timed out
boot: hda1:/boot/linuxbios initrd=/boot/initrd.splash acpi=off
splash=silent vg0malloc_diag: alloc: 400 bytes (5 blocks), free: 15976
bytes (1 blocks)
malloc_diag: alloc: 416 bytes (6 blocks), free: 15960 bytes (1 blocks)
file_open: dev=hda1, path=/boot/linuxbios
find_ide_controller: found PCI IDE controller 1106:0571 prog_if=0x8a
find_ide_controller: primary channel: compatibility mode
find_ide_controller: cmd_base=0x1f0 ctrl_base=0x3f4
ide_software_reset: Waiting for ide0 to become ready for reset... ok
init_drive: Testing for hda
init_drive: Probing for hda
init_drive: LBA mode, sectors=39102336
init_drive: Init device params... ok
hda: LBA 20GB: ST320014A
devopen: Partition 1 start 32 length 3127264
Mounted ext2fs
malloc_diag: alloc: 400 bytes (5 blocks), free: 15976 bytes (1 blocks)
elf_load: Not a bootable ELF image
malloc_diag: alloc: 416 bytes (6 blocks), free: 15960 bytes (1 blocks)
file_open: dev=hda1, path=/boot/linuxbios
devopen: already open
malloc_diag: alloc: 400 bytes (5 blocks), free: 15976 bytes (1 blocks)
Found Linux version 2.4.22 (root at rolec) #5 Tue Mar 16 07:37:51 GMT 2004
(protoc.init_linux_params: Setting up paramters at 0x90000
set_memory_size: 0000000000000700 - 00000000000a0000
set_memory_size: 00000000000c0000 - 00000000000f0000
set_memory_size: 00000000000f0400 - 0000000003c00000
set_memory_size: ramtop=0x3c00000
set_memory_size: ext_mem_k=60416, alt_mem_k=60416
parse_command_line: original command line: "initrd=/boot/initrd.splash
acpi=off"parse_command_line: kernel command line at 0x91000
malloc_diag: alloc: 432 bytes (6 blocks), free: 15944 bytes (1 blocks)
parse_command_line: initrd=/boot/initrd.splash
parse_command_line: kernel command line (64 bytes): "acpi=off
splash=silent vga"load_linux_kernel: offset=0x1600 addr=0x100000
size=0xe20e6
Loading kernel... ok
file_open: dev=<NULL>, path=/boot/initrd.splash
load_initrd: start=0x3bcd000 end=0x3bd97d8
Loading initrd... ok
malloc_diag: alloc: 400 bytes (5 blocks), free: 15976 bytes (1 blocks)
start_linux: eip=0x100000
Jumping to entry point...
Linux version 2.4.22 (root at rolec) (gcc version 3.3.1) #5 Tue Mar 16
07:37:51 GM4BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000700 - 00000000000a0000 (usable)
 BIOS-e820: 0000000000100000 - 0000000003c00000 (usable)
60MB LOWMEM available.
hm, page 00000000 reserved twice.
On node 0 totalpages: 15360
zone(0): 4096 pages.
zone(1): 11264 pages.
zone(2): 0 pages.
Kernel command line: acpi=off splash=silent vga=791 console=tty0
console=ttyS0,0Initializing CPU#0
Detected 533.365 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 1064.96 BogoMIPS
Memory: 58252k/61440k available (1233k kernel code, 2800k reserved, 342k
data, )Checking if this processor honours the WP bit even in supervisor
mode... Ok.
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: Centaur VIA Samuel 2 stepping 03
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch at atnf.csiro.au)
mtrr: detected mtrr type: Intel
ACPI: Subsystem revision 20030813
ACPI: Interpreter disabled.
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: ACPI tables contain no PCI IRQ routing entries
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router default [1106/8231] at 00:11.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI edttyS00 at 0x03f8 (irq = 4) is a 16550A
via-rhine.c:v1.10-LK1.1.19  July-12-2003  Written by Donald Becker
  http://www.scyld.com/network/via-rhine.html
eth0: VIA VT6102 Rhine-II at 0x1800, 00:40:63:c9:ba:8f, IRQ 11.
eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link
45e1.
PPP generic driver version 2.4.2
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 25M
agpgart: Detected Via Apollo PLE133 chipset




From bios-list at cox.net  Tue Mar 16 04:16:01 2004
From: bios-list at cox.net (Edgar Lovecraft)
Date: Tue Mar 16 04:16:01 2004
Subject: Tyan Tomcat i845GL (S2098)
In-Reply-To: <Pine.LNX.4.44.0403160139080.11479-100000@maxroach.lanl.gov>
References: <jbm.20040315095756.f137a19c@User21>
  <Pine.LNX.4.44.0403160139080.11479-100000@maxroach.lanl.gov>
Message-ID: <jbm.20040316033807.6ceab00a@User21>

ron minnich wrote:
> 
> at this point, here at LANL, our focus is 64-bit boards and embedded
> stuff like EPIA, so this one falls through the cracks here. We can
> assist you with porting but can not do the work ourselves.
> 
> So if you want an assisted port letus know.
> 
-- 
Even though it is noce to have someone else do the work for you, I am very
willing to have an assisted port.  I have just been gathering information
and did not want to reinvent the wheel if it had already been done.  I 
have not 'jumed right in' yet, nor have I compiled anything.  I will go
through the docs that are available again and start compiling and testing
and see what happens.
Before I do so, are there any major gotchas I need to look out for?
Any kind of quick hints that you can give me will be greatly appreciated,
things like is the 2.4 kernel better for this than the 2.6, or, when all 
else fails, toss the computer in front of the nearest rig passing by sort
of thing.
Thanks for the support, I am sure I will need some if it does not work
fairly easily (or give me something that I understand in the errors :)
Other than this list, are there any other 'good' references to look at
when things don't work?
Laslty, are there any white-papers that cover the differences between what
is being done at the linuxbios level vs. the linux kernel level with 
devices and such? (I am just one of those people that likes to know the 
how and why of everything :)
Thanks again!
--EAL--




From hss at stapf.com  Tue Mar 16 10:16:01 2004
From: hss at stapf.com (Holger-Steffen Stapf)
Date: Tue Mar 16 10:16:01 2004
Subject: VIA EPIA
Message-ID: <34034.145.253.97.11.1079451024.squirrel@www.stapf.com>

Hi,

anyone testet the BIOS on VIA EPIA M2??

regards

HSS


From firstone5 at hotmail.com  Tue Mar 16 10:40:01 2004
From: firstone5 at hotmail.com (M. Renee Hopkins)
Date: Tue Mar 16 10:40:01 2004
Subject: VIA EPIA
Message-ID: <BAY10-F88QdfJnfR1Ek000159eb@hotmail.com>

Freebios V1 still doesn't work for EPIA-M I as far as I can tell.

My CVS check out and build of Tue Mar 9 10:23:00 2004  was unsuccessful.  It 
seems that something is missing which properly activates VGA modes.  I'm not 
sure if Ron or Dave have the time to finish this up, even though it's so 
close....

If I knew more about the init process, I'd support the effort myself.




>From: "Holger-Steffen Stapf" <hss at stapf.com>
>To: linuxbios at clustermatic.org
>Subject: VIA EPIA
>Date: Tue, 16 Mar 2004 16:30:24 +0100 (CET)
>
>Hi,
>
>anyone testet the BIOS on VIA EPIA M2??
>
>regards
>
>HSS
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios

_________________________________________________________________
Frustrated with dial-up? Lightning-fast Internet access for as low as 
$29.95/month. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/



From firstone5 at hotmail.com  Tue Mar 16 10:42:14 2004
From: firstone5 at hotmail.com (M. Renee Hopkins)
Date: Tue Mar 16 10:42:14 2004
Subject: VIA EPIA
Message-ID: <BAY10-F95I2lreZkHYr0002b432@hotmail.com>

Freebios V1 still doesn't work for EPIA-M I as far as I can tell.

My CVS check out and build of Tue Mar 9 10:23:00 2004  was unsuccessful.  It 
seems that something is missing which properly activates VGA modes.  I'm not 
sure if Ron or Dave have the time to finish this up, even though it's so 
close....

If I knew more about the init process, I'd support the effort myself.




>From: "Holger-Steffen Stapf" <hss at stapf.com>
>To: linuxbios at clustermatic.org
>Subject: VIA EPIA
>Date: Tue, 16 Mar 2004 16:30:24 +0100 (CET)
>
>Hi,
>
>anyone testet the BIOS on VIA EPIA M2??
>
>regards
>
>HSS
>_______________________________________________
>Linuxbios mailing list
>Linuxbios at clustermatic.org
>http://www.clustermatic.org/mailman/listinfo/linuxbios

_________________________________________________________________
One-click access to Hotmail from any Web page ? download MSN Toolbar now! 
http://clk.atdmt.com/AVE/go/onm00200413ave/direct/01/



From justin at street-vision.com  Tue Mar 16 11:13:01 2004
From: justin at street-vision.com (Justin Cormack)
Date: Tue Mar 16 11:13:01 2004
Subject: Quick Offlist Question
In-Reply-To: <E1B2zA2-000Eqh-0V@anchor-post-31.mail.demon.net>
References: <E1B2zA2-000Eqh-0V@anchor-post-31.mail.demon.net>
Message-ID: <1079454912.29938.3033.camel@lotte.street-vision.com>

I seem to remember that

http://www.milesie.co.uk/shop/asp/product1.asp?Product=334

is supported in linuxbios - has PC104 slot. I havent used these with
Linuxbios but they are nice machines otherwise. Geode 300Mhz.


On Mon, 2004-03-15 at 20:58, James Weir wrote:
> Thanks guys,
> 
> I really need it to be a pc104+ form factor board, I am intending to use a
> separate pc104+ framegrabber.
> 
> James.
> 
> -----Original Message-----
> From: linuxbios-admin at clustermatic.org
> [mailto:linuxbios-admin at clustermatic.org] On Behalf Of Nathanael Noblet
> Sent: 15 March 2004 20:06
> To: Hendricks David W.
> Cc: James Weir; LinuxBIOS
> Subject: Re: Quick Offlist Question
> 
> 
> On Monday, March 15, 2004, at 11:46 AM, Hendricks David W. wrote:
> 
> > Does the EPIA have hardware MPEG compression?
> 
> epia-M does.



From rminnich at lanl.gov  Tue Mar 16 12:01:48 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar 16 12:01:48 2004
Subject: epia and vga
In-Reply-To: <1079428311.5770.9.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.44.0403161023170.15117-100000@maxroach.lanl.gov>

is this epia or epia-m?

If epia, you want V2. I think you have epia-m however, can you get me in 
sync on this?

ron



From rminnich at lanl.gov  Tue Mar 16 12:03:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar 16 12:03:01 2004
Subject: Tyan Tomcat i845GL (S2098)
In-Reply-To: <jbm.20040316033807.6ceab00a@User21>
Message-ID: <Pine.LNX.4.44.0403161024110.15117-100000@maxroach.lanl.gov>

if you are going to do this, go ahead and look at existing V2 ports. For 
your chipset, I think that looking at K8 would be very confusing. Look at 
PPC and EPIA ports. Just try to get a feel for how it gets put together 
and then think a bit about the =830 and then talk to us about what you 
want to do. If you go V2, all the code will be C; you want to go V2 :-)

ron



From rminnich at lanl.gov  Tue Mar 16 12:13:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar 16 12:13:00 2004
Subject: VIA EPIA
In-Reply-To: <BAY10-F88QdfJnfR1Ek000159eb@hotmail.com>
Message-ID: <Pine.LNX.4.44.0403161035380.15117-100000@maxroach.lanl.gov>

I want to get a V2 port of EPIA-M, then do vga next.

ron



From jbors at mail.ru  Tue Mar 16 12:30:00 2004
From: jbors at mail.ru (=?koi8-r?Q?=22?=Dmitry Borisov=?koi8-r?Q?=22=20?=)
Date: Tue Mar 16 12:30:00 2004
Subject: epia and vga
In-Reply-To: <Pine.LNX.4.44.0403161023170.15117-100000@maxroach.lanl.gov>
Message-ID: <E1B3Ik4-0003DC-00.jbors-mail-ru@f22.mail.ru>

Subject: Re: epia and vga

> 
> is this epia or epia-m?
> 
> If epia, you want V2. I think you have epia-m however, can you get me in 
> sync on this?
> 
> ron
> 

It is EPIA-500 with PLE133( not M ). It should work just fine with CVS tree. Last time I did check on that at least...
Dmitry/




From rminnich at lanl.gov  Tue Mar 16 12:59:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar 16 12:59:00 2004
Subject: epia and vga
In-Reply-To: <E1B3Ik4-0003DC-00.jbors-mail-ru@f22.mail.ru>
Message-ID: <Pine.LNX.4.44.0403161120480.15465-100000@maxroach.lanl.gov>

On Tue, 16 Mar 2004, [koi8-r] "Dmitry Borisov[koi8-r] "  wrote:

> It is EPIA-500 with PLE133( not M ). It should work just fine with CVS
> tree. Last time I did check on that at least... Dmitry/

you should use V2 for basic EPIA. Memory support is way better.

ron



From cforney at opus.com  Tue Mar 16 16:53:00 2004
From: cforney at opus.com (Craig C Forney)
Date: Tue Mar 16 16:53:00 2004
Subject: AMD K8 memory bug with more than 2 banks
In-Reply-To: <20040312184501.25805.61407.Mailman@nwn.definitive.org>
Message-ID: <001e01c40ba3$cd150c60$6400a8c0@opusone>

I ran into a problem with a Dual Opeteron cPCI board we developed with 4
banks of memory.  It showed up when the third and fourth banks were
populated.  I narrowed it down to a problem in src/amd/amdk8/raminit.c.
There is a '+' where there should be a '*', causing the SPD settings to
get corrupted, which causes bizarre results which varies depending on
the memory parameters read from the DIMMs.  One possible result is that
some DIMMs will work marginally because one or more of their settings
has been corrupted.

This patch seems to resolve the problem.  I'm not sure if anybody else
out there is accessing 4 banks of memory via the Opteron memory
interface, so it might be just us, but it would probably be a good idea
to commit this patch to the freebios2 source tree.  Can someone take
this on?

Thanks,

Craig Forney
Opus Innovations LLC

diff -Naur raminit.c.orig raminit.c
--- raminit.c.orig	2004-03-16 13:25:05.000000000 -0800
+++ raminit.c	2004-03-16 13:42:30.000000000 -0800
@@ -924,7 +924,7 @@
 		sz.side2 = 0;
 	}
 	map = pci_read_config32(ctrl->f2, DRAM_BANK_ADDR_MAP);
-	map &= ~(0xf << (index + 4));
+	map &= ~(0xf << (index * 4));
 
 	/* For each base register.
 	 * Place the dimm size in 32 MB quantities in the bits 31 - 21.




From frannk_m1 at yahoo.com  Tue Mar 16 22:39:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Mar 16 22:39:01 2004
Subject: SIS chipset
Message-ID: <20040317040145.8808.qmail@web13804.mail.yahoo.com>

I have an ADVANTECH board based on the SIS 552 chipset. Is there
any support for this board and chip set. I looked at the status:
http://www.linuxbios.org/status/index.html
There is an entry for SIS but no notes. I am on a very tight
schedule and any help will be greatly appreciated...

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From frannk_m1 at yahoo.com  Wed Mar 17 01:21:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 01:21:01 2004
Subject: making without a payload
Message-ID: <20040317064306.96978.qmail@web13807.mail.yahoo.com>

I want to eventually use linuxbios to boot linux but for right
now I just wnat to build it for my motherbord without a payload.
How do i do this..

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From matt at rolec.ltd.uk  Wed Mar 17 03:05:01 2004
From: matt at rolec.ltd.uk (Matt Jarvis)
Date: Wed Mar 17 03:05:01 2004
Subject: epia and vga
In-Reply-To: <Pine.LNX.4.44.0403161023170.15117-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403161023170.15117-100000@maxroach.lanl.gov>
Message-ID: <1079512069.5771.9.camel@localhost.localdomain>

Yes, it's a standard epia. I'm running bios version 0207 - which is
where the VGA bios is from. I'll give V2 a go today. 


On Tue, 2004-03-16 at 17:23, ron minnich wrote:
> is this epia or epia-m?
> 
> If epia, you want V2. I think you have epia-m however, can you get me in 
> sync on this?
> 
> ron
-- 
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  Wed Mar 17 09:02:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Mar 17 09:02:01 2004
Subject: SIS chipset
In-Reply-To: <20040317040145.8808.qmail@web13804.mail.yahoo.com>
References: <20040317040145.8808.qmail@web13804.mail.yahoo.com>
Message-ID: <40586032.90202@onelabs.com>

Frank wrote:
> I have an ADVANTECH board based on the SIS 552 chipset. Is there
> any support for this board and chip set. I looked at the status:
> http://www.linuxbios.org/status/index.html
> There is an entry for SIS but no notes. I am on a very tight
> schedule and any help will be greatly appreciated...

SiS used to post the LinuxBIOS on their website, it's also in the V1 source.

-Bari




From linuxbios at huebner.it  Wed Mar 17 09:54:01 2004
From: linuxbios at huebner.it (linuxbios at huebner.it)
Date: Wed Mar 17 09:54:01 2004
Subject: test mail - just delete
Message-ID: <20040317151612.GA10111@huebner.it>

 


From rminnich at lanl.gov  Wed Mar 17 11:33:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 17 11:33:00 2004
Subject: making without a payload
In-Reply-To: <20040317064306.96978.qmail@web13807.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403170955050.23850-100000@maxroach.lanl.gov>

On Tue, 16 Mar 2004, Frank wrote:

> I want to eventually use linuxbios to boot linux but for right
> now I just wnat to build it for my motherbord without a payload.
> How do i do this..

payload /dev/null

ron



From rminnich at lanl.gov  Wed Mar 17 11:37:31 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 17 11:37:31 2004
Subject: making without a payload
In-Reply-To: <20040317064306.96978.qmail@web13807.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403170955170.23850-100000@maxroach.lanl.gov>

actually for empty payloads I also do payload /etc/hosts. 

It's useful to have a known pattern in there.

ron



From dwh at lanl.gov  Wed Mar 17 12:11:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Wed Mar 17 12:11:01 2004
Subject: making without a payload
In-Reply-To: <20040317064306.96978.qmail@web13807.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403171033310.5512-100000@ccs-mail.lanl.gov>

Specify some bogus payload, like /etc/hosts.

On Tue, 16 Mar 2004, Frank wrote:

> I want to eventually use linuxbios to boot linux but for right
> now I just wnat to build it for my motherbord without a payload.
> How do i do this..
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - More reliable, more storage, less spam
> http://mail.yahoo.com
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From frannk_m1 at yahoo.com  Wed Mar 17 13:46:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 13:46:00 2004
Subject: making without a payload
In-Reply-To: <Pine.LNX.4.44.0403171033310.5512-100000@ccs-mail.lanl.gov>
Message-ID: <20040317190837.59711.qmail@web13804.mail.yahoo.com>

Got it, thank you...
--- "Hendricks David W." <dwh at lanl.gov> wrote:
> Specify some bogus payload, like /etc/hosts.
> 
> On Tue, 16 Mar 2004, Frank wrote:
> 
> > I want to eventually use linuxbios to boot linux but for
> right
> > now I just wnat to build it for my motherbord without a
> payload.
> > How do i do this..
> > 
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - More reliable, more storage, less spam
> > http://mail.yahoo.com
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > 
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From frannk_m1 at yahoo.com  Wed Mar 17 13:47:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 13:47:00 2004
Subject: making without a payload
In-Reply-To: <Pine.LNX.4.44.0403170955170.23850-100000@maxroach.lanl.gov>
Message-ID: <20040317190939.25226.qmail@web13802.mail.yahoo.com>

Thank you again...
--- ron minnich <rminnich at lanl.gov> wrote:
> actually for empty payloads I also do payload /etc/hosts. 
> 
> It's useful to have a known pattern in there.
> 
> ron
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From frannk_m1 at yahoo.com  Wed Mar 17 13:49:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 13:49:00 2004
Subject: SIS chipset
In-Reply-To: <40586032.90202@onelabs.com>
Message-ID: <20040317191207.29134.qmail@web13808.mail.yahoo.com>

The "Vl" webiste???

--- Bari Ari <bari at onelabs.com> wrote:
> Frank wrote:
> > I have an ADVANTECH board based on the SIS 552 chipset. Is
> there
> > any support for this board and chip set. I looked at the
> status:
> > http://www.linuxbios.org/status/index.html
> > There is an entry for SIS but no notes. I am on a very tight
> > schedule and any help will be greatly appreciated...
> 
> SiS used to post the LinuxBIOS on their website, it's also in
> the V1 source.
> 
> -Bari
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From dwh at lanl.gov  Wed Mar 17 14:23:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Wed Mar 17 14:23:01 2004
Subject: SIS chipset
In-Reply-To: <20040317191207.29134.qmail@web13808.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403171241350.5512-100000@ccs-mail.lanl.gov>

I think he means the "freebios" directory in the CVS tree ( 
http://cvs.sourceforge.net/viewcvs.py/freebios/freebios/ ) as opposed to 
"freebios2."

On Wed, 17 Mar 2004, Frank wrote:

> The "Vl" webiste???
> 
> --- Bari Ari <bari at onelabs.com> wrote:
> > Frank wrote:
> > > I have an ADVANTECH board based on the SIS 552 chipset. Is
> > there
> > > any support for this board and chip set. I looked at the
> > status:
> > > http://www.linuxbios.org/status/index.html
> > > There is an entry for SIS but no notes. I am on a very tight
> > > schedule and any help will be greatly appreciated...
> > 
> > SiS used to post the LinuxBIOS on their website, it's also in
> > the V1 source.
> > 
> > -Bari
> > 
> > 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - More reliable, more storage, less spam
> http://mail.yahoo.com
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From frannk_m1 at yahoo.com  Wed Mar 17 14:38:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 14:38:00 2004
Subject: SIS chipset
In-Reply-To: <Pine.LNX.4.44.0403171241350.5512-100000@ccs-mail.lanl.gov>
Message-ID: <20040317200044.69888.qmail@web13804.mail.yahoo.com>

Forgive me for my ignorance but now I am really confused. What
is the difference between Freebios, Freebios2 and LinuxBios. I
thought they were one in the same.:-(

--- "Hendricks David W." <dwh at lanl.gov> wrote:
> I think he means the "freebios" directory in the CVS tree ( 
> http://cvs.sourceforge.net/viewcvs.py/freebios/freebios/ ) as
> opposed to 
> "freebios2."
> 
> On Wed, 17 Mar 2004, Frank wrote:
> 
> > The "Vl" webiste???
> > 
> > --- Bari Ari <bari at onelabs.com> wrote:
> > > Frank wrote:
> > > > I have an ADVANTECH board based on the SIS 552 chipset.
> Is
> > > there
> > > > any support for this board and chip set. I looked at the
> > > status:
> > > > http://www.linuxbios.org/status/index.html
> > > > There is an entry for SIS but no notes. I am on a very
> tight
> > > > schedule and any help will be greatly appreciated...
> > > 
> > > SiS used to post the LinuxBIOS on their website, it's also
> in
> > > the V1 source.
> > > 
> > > -Bari
> > > 
> > > 
> > 
> > 
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - More reliable, more storage, less spam
> > http://mail.yahoo.com
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > 
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From linuxbios at huebner.it  Wed Mar 17 14:54:01 2004
From: linuxbios at huebner.it (linuxbios at huebner.it)
Date: Wed Mar 17 14:54:01 2004
Subject: ASUS P2B-DS and MD2202-D32
Message-ID: <20040317201656.GA10928@huebner.it>

Hi all,

want to use an ASUS P2B-DS dual P-III mainboard with a MD2202-D32 DoC
device for LinuxBIOS. In the moment I test it with a 2.6.4 kernel.
This board uses a 440bx chip set.
I hot swapped the BIOS Flash chip and the DoC while the board was powered
on and Linux was running.
When I modprobe nftl and docprobe I get the following messages in
/var/log/messages:

kernel: NFTL driver: nftlcore.c $Revision: 1.94 $, nftlmount.c
$Revision: 1.34 $
kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffc8000
kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffca000

[...]

kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffec000
kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffee000
kernel: No recognized DiskOnChip devices found

No my question now is how to initialize the 440bx to get the DoC
recognized.


Thank you in advance,
Andreas



From nathanael at gnat.ca  Wed Mar 17 15:17:01 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Wed Mar 17 15:17:01 2004
Subject: SIS chipset
In-Reply-To: <20040317200044.69888.qmail@web13804.mail.yahoo.com>
Message-ID: <2992F09D-7853-11D8-B113-0003931B4D6A@gnat.ca>

On Wednesday, March 17, 2004, at 12:00 PM, Frank wrote:

> Forgive me for my ignorance but now I am really confused. What
> is the difference between Freebios, Freebios2 and LinuxBios. I
> thought they were one in the same.:-(

freebios was started before linuxbios. LinuxBIOS "took over" freebios, 
but didn't change the cvs name. V1 of freebios/linuxbios is the CVS 
module freebios. Freebios2 is LinuxBIOS version 2.

that's as I understand it... no guarantees.

-- 
Nathanael D. Noblet
Gnat Solutions
412 - 135 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/



From frannk_m1 at yahoo.com  Wed Mar 17 15:41:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 15:41:00 2004
Subject: SIS chipset
In-Reply-To: <2992F09D-7853-11D8-B113-0003931B4D6A@gnat.ca>
Message-ID: <20040317210329.66281.qmail@web13803.mail.yahoo.com>

OK, thanks...
--- Nathanael Noblet <nathanael at gnat.ca> wrote:
> 
> On Wednesday, March 17, 2004, at 12:00 PM, Frank wrote:
> 
> > Forgive me for my ignorance but now I am really confused.
> What
> > is the difference between Freebios, Freebios2 and LinuxBios.
> I
> > thought they were one in the same.:-(
> 
> freebios was started before linuxbios. LinuxBIOS "took over"
> freebios, 
> but didn't change the cvs name. V1 of freebios/linuxbios is
> the CVS 
> module freebios. Freebios2 is LinuxBIOS version 2.
> 
> that's as I understand it... no guarantees.
> 
> -- 
> Nathanael D. Noblet
> Gnat Solutions
> 412 - 135 Gorge Road E
> Victoria, BC V9A 1L1
> 
> T/F 250.385.4613
> 
> http://www.gnat.ca/
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From rminnich at lanl.gov  Wed Mar 17 15:45:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 17 15:45:01 2004
Subject: SIS chipset
In-Reply-To: <2992F09D-7853-11D8-B113-0003931B4D6A@gnat.ca>
Message-ID: <Pine.LNX.4.44.0403171406320.23850-100000@maxroach.lanl.gov>

On Wed, 17 Mar 2004, Nathanael Noblet wrote:

> freebios was started before linuxbios. LinuxBIOS "took over" freebios, 
> but didn't change the cvs name. V1 of freebios/linuxbios is the CVS 
> module freebios. Freebios2 is LinuxBIOS version 2.

it's weirder than that. We built the first linuxbios using openbios as the 
starting point. Jeff Garzik found freebios, set up the sourceforge account 
with that name, and I made the mods to turn it into linuxbios. But the 
name stuck.

ron




From bari at onelabs.com  Wed Mar 17 15:52:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Mar 17 15:52:00 2004
Subject: SIS chipset
In-Reply-To: <2992F09D-7853-11D8-B113-0003931B4D6A@gnat.ca>
References: <2992F09D-7853-11D8-B113-0003931B4D6A@gnat.ca>
Message-ID: <4058C047.9070309@onelabs.com>

Nathanael Noblet wrote:

> 
> On Wednesday, March 17, 2004, at 12:00 PM, Frank wrote:
> 
>> Forgive me for my ignorance but now I am really confused. What
>> is the difference between Freebios, Freebios2 and LinuxBios. I
>> thought they were one in the same.:-(
> 
> 
> freebios was started before linuxbios. LinuxBIOS "took over" freebios, 
> but didn't change the cvs name. V1 of freebios/linuxbios is the CVS 
> module freebios. Freebios2 is LinuxBIOS version 2.

FreeBios = LinuxBIOS.

LinuxBIOS was forked when Eric wrote RomCC last year. V2 (Version2) is 
the new LinuxBIOS source tree that is the 100% C version of LinuxBIOS. 
V1 (Version  1) is the old LinuxBIOS source that used assembly and C.

"romcc is a C compiler that does not use a stack.  Instead it keeps
all variables in registers.

Currently LinuxBIOS has a lot of assembly code simply because memory
initialization is difficult in the general case.  This code cannot be
written with a standard compiler because there is no memory to put
a stack in.  Nor on x86 are there cache blocks that can be locked into
place.  As code generated with romcc does not use a stack it can be
used during memory initialization."

-Bari




From frannk_m1 at yahoo.com  Wed Mar 17 16:05:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 16:05:00 2004
Subject: SIS chipset
In-Reply-To: <4058C047.9070309@onelabs.com>
Message-ID: <20040317212715.98539.qmail@web13809.mail.yahoo.com>

This is very good information everyone and everyone is lot nicer
then that "other" (ppc) boot loader group. Where can I get more
information on RomCC and how do I incorporate that into my
LinuxBios build. Does RomCC replace GCC...

--- Bari Ari <bari at onelabs.com> wrote:
> Nathanael Noblet wrote:
> 
> > 
> > On Wednesday, March 17, 2004, at 12:00 PM, Frank wrote:
> > 
> >> Forgive me for my ignorance but now I am really confused.
> What
> >> is the difference between Freebios, Freebios2 and
> LinuxBios. I
> >> thought they were one in the same.:-(
> > 
> > 
> > freebios was started before linuxbios. LinuxBIOS "took over"
> freebios, 
> > but didn't change the cvs name. V1 of freebios/linuxbios is
> the CVS 
> > module freebios. Freebios2 is LinuxBIOS version 2.
> 
> FreeBios = LinuxBIOS.
> 
> LinuxBIOS was forked when Eric wrote RomCC last year. V2
> (Version2) is 
> the new LinuxBIOS source tree that is the 100% C version of
> LinuxBIOS. 
> V1 (Version  1) is the old LinuxBIOS source that used assembly
> and C.
> 
> "romcc is a C compiler that does not use a stack.  Instead it
> keeps
> all variables in registers.
> 
> Currently LinuxBIOS has a lot of assembly code simply because
> memory
> initialization is difficult in the general case.  This code
> cannot be
> written with a standard compiler because there is no memory to
> put
> a stack in.  Nor on x86 are there cache blocks that can be
> locked into
> place.  As code generated with romcc does not use a stack it
> can be
> used during memory initialization."
> 
> -Bari
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From frannk_m1 at yahoo.com  Wed Mar 17 16:11:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 16:11:00 2004
Subject: SIS chipset
In-Reply-To: <4058C047.9070309@onelabs.com>
Message-ID: <20040317213406.19701.qmail@web13801.mail.yahoo.com>

Where can I get RomCC...
--- Bari Ari <bari at onelabs.com> wrote:
> Nathanael Noblet wrote:
> 
> > 
> > On Wednesday, March 17, 2004, at 12:00 PM, Frank wrote:
> > 
> >> Forgive me for my ignorance but now I am really confused.
> What
> >> is the difference between Freebios, Freebios2 and
> LinuxBios. I
> >> thought they were one in the same.:-(
> > 
> > 
> > freebios was started before linuxbios. LinuxBIOS "took over"
> freebios, 
> > but didn't change the cvs name. V1 of freebios/linuxbios is
> the CVS 
> > module freebios. Freebios2 is LinuxBIOS version 2.
> 
> FreeBios = LinuxBIOS.
> 
> LinuxBIOS was forked when Eric wrote RomCC last year. V2
> (Version2) is 
> the new LinuxBIOS source tree that is the 100% C version of
> LinuxBIOS. 
> V1 (Version  1) is the old LinuxBIOS source that used assembly
> and C.
> 
> "romcc is a C compiler that does not use a stack.  Instead it
> keeps
> all variables in registers.
> 
> Currently LinuxBIOS has a lot of assembly code simply because
> memory
> initialization is difficult in the general case.  This code
> cannot be
> written with a standard compiler because there is no memory to
> put
> a stack in.  Nor on x86 are there cache blocks that can be
> locked into
> place.  As code generated with romcc does not use a stack it
> can be
> used during memory initialization."
> 
> -Bari
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From bari at onelabs.com  Wed Mar 17 16:18:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Mar 17 16:18:01 2004
Subject: SIS chipset
In-Reply-To: <20040317212715.98539.qmail@web13809.mail.yahoo.com>
References: <20040317212715.98539.qmail@web13809.mail.yahoo.com>
Message-ID: <4058C642.2020400@onelabs.com>

Frank wrote:

> This is very good information everyone and everyone is lot nicer
> then that "other" (ppc) boot loader group. 
"LinuxBIOS...the bootloader for grown-ups"... I'm only kidding.

Where can I get more
> information on RomCC and how do I incorporate that into my
> LinuxBios build. Does RomCC replace GCC...

"Consider the source" Frank :) and look through the archives 
http://www.missl.cs.umd.edu/archives/linuxbios/
-Bari




From dwh at lanl.gov  Wed Mar 17 16:18:08 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Wed Mar 17 16:18:08 2004
Subject: SIS chipset
In-Reply-To: <20040317213406.19701.qmail@web13801.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403171440240.5512-100000@ccs-mail.lanl.gov>

It's in the freebios2 tree: 
http://cvs.sourceforge.net/viewcvs.py/freebios/freebios2/util/romcc/



On Wed, 17 Mar 2004, Frank wrote:

> Where can I get RomCC...
> --- Bari Ari <bari at onelabs.com> wrote:
> > Nathanael Noblet wrote:
> > 
> > > 
> > > On Wednesday, March 17, 2004, at 12:00 PM, Frank wrote:
> > > 
> > >> Forgive me for my ignorance but now I am really confused.
> > What
> > >> is the difference between Freebios, Freebios2 and
> > LinuxBios. I
> > >> thought they were one in the same.:-(
> > > 
> > > 
> > > freebios was started before linuxbios. LinuxBIOS "took over"
> > freebios, 
> > > but didn't change the cvs name. V1 of freebios/linuxbios is
> > the CVS 
> > > module freebios. Freebios2 is LinuxBIOS version 2.
> > 
> > FreeBios = LinuxBIOS.
> > 
> > LinuxBIOS was forked when Eric wrote RomCC last year. V2
> > (Version2) is 
> > the new LinuxBIOS source tree that is the 100% C version of
> > LinuxBIOS. 
> > V1 (Version  1) is the old LinuxBIOS source that used assembly
> > and C.
> > 
> > "romcc is a C compiler that does not use a stack.  Instead it
> > keeps
> > all variables in registers.
> > 
> > Currently LinuxBIOS has a lot of assembly code simply because
> > memory
> > initialization is difficult in the general case.  This code
> > cannot be
> > written with a standard compiler because there is no memory to
> > put
> > a stack in.  Nor on x86 are there cache blocks that can be
> > locked into
> > place.  As code generated with romcc does not use a stack it
> > can be
> > used during memory initialization."
> > 
> > -Bari
> > 
> > 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - More reliable, more storage, less spam
> http://mail.yahoo.com
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From dwh at lanl.gov  Wed Mar 17 16:20:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Wed Mar 17 16:20:01 2004
Subject: SIS chipset
In-Reply-To: <4058C642.2020400@onelabs.com>
Message-ID: <Pine.LNX.4.44.0403171442080.5512-100000@ccs-mail.lanl.gov>

Might also want to check out this thread: 
http://www.clustermatic.org/pipermail/linuxbios/2004-March/006892.html

It answers many questions one might have about romcc.

On Wed, 17 Mar 2004, Bari Ari wrote:

> Frank wrote:
> 
> > This is very good information everyone and everyone is lot nicer
> > then that "other" (ppc) boot loader group. 
> "LinuxBIOS...the bootloader for grown-ups"... I'm only kidding.
> 
> Where can I get more
> > information on RomCC and how do I incorporate that into my
> > LinuxBios build. Does RomCC replace GCC...
> 
> "Consider the source" Frank :) and look through the archives 
> http://www.missl.cs.umd.edu/archives/linuxbios/
> -Bari
> 
> 



From bari at onelabs.com  Wed Mar 17 16:21:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Mar 17 16:21:00 2004
Subject: SIS chipset
In-Reply-To: <20040317213406.19701.qmail@web13801.mail.yahoo.com>
References: <20040317213406.19701.qmail@web13801.mail.yahoo.com>
Message-ID: <4058C6FF.2090803@onelabs.com>

Frank wrote:

> Where can I get RomCC...

http://cvs.sourceforge.net/cvstarballs/freebios-cvsroot.tar.bz2

-Bari




From rminnich at lanl.gov  Wed Mar 17 16:24:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 17 16:24:00 2004
Subject: SIS chipset
In-Reply-To: <20040317212715.98539.qmail@web13809.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403171446060.23850-100000@maxroach.lanl.gov>

On Wed, 17 Mar 2004, Frank wrote:

> This is very good information everyone and everyone is lot nicer
> then that "other" (ppc) boot loader group. Where can I get more
> information on RomCC and how do I incorporate that into my
> LinuxBios build. Does RomCC replace GCC...

romcc is only needed for a few .c files until memory is turned on. The 
rest is normal gcc.

You should just cvs checkout freebios2 not freebios and it is all in 
there.

ron



From rminnich at lanl.gov  Wed Mar 17 16:26:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 17 16:26:00 2004
Subject: SIS chipset
In-Reply-To: <4058C642.2020400@onelabs.com>
Message-ID: <Pine.LNX.4.44.0403171448040.23850-100000@maxroach.lanl.gov>

I should also add that on v2 romcc is of course integrated into the build.

ron



From frannk_m1 at yahoo.com  Wed Mar 17 16:32:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 16:32:01 2004
Subject: SIS chipset
In-Reply-To: <Pine.LNX.4.44.0403171440240.5512-100000@ccs-mail.lanl.gov>
Message-ID: <20040317215457.76504.qmail@web13803.mail.yahoo.com>

Got it!
Thank you very much...
--- "Hendricks David W." <dwh at lanl.gov> wrote:
> It's in the freebios2 tree: 
>
http://cvs.sourceforge.net/viewcvs.py/freebios/freebios2/util/romcc/
> 
> 
> 
> On Wed, 17 Mar 2004, Frank wrote:
> 
> > Where can I get RomCC...
> > --- Bari Ari <bari at onelabs.com> wrote:
> > > Nathanael Noblet wrote:
> > > 
> > > > 
> > > > On Wednesday, March 17, 2004, at 12:00 PM, Frank wrote:
> > > > 
> > > >> Forgive me for my ignorance but now I am really
> confused.
> > > What
> > > >> is the difference between Freebios, Freebios2 and
> > > LinuxBios. I
> > > >> thought they were one in the same.:-(
> > > > 
> > > > 
> > > > freebios was started before linuxbios. LinuxBIOS "took
> over"
> > > freebios, 
> > > > but didn't change the cvs name. V1 of freebios/linuxbios
> is
> > > the CVS 
> > > > module freebios. Freebios2 is LinuxBIOS version 2.
> > > 
> > > FreeBios = LinuxBIOS.
> > > 
> > > LinuxBIOS was forked when Eric wrote RomCC last year. V2
> > > (Version2) is 
> > > the new LinuxBIOS source tree that is the 100% C version
> of
> > > LinuxBIOS. 
> > > V1 (Version  1) is the old LinuxBIOS source that used
> assembly
> > > and C.
> > > 
> > > "romcc is a C compiler that does not use a stack.  Instead
> it
> > > keeps
> > > all variables in registers.
> > > 
> > > Currently LinuxBIOS has a lot of assembly code simply
> because
> > > memory
> > > initialization is difficult in the general case.  This
> code
> > > cannot be
> > > written with a standard compiler because there is no
> memory to
> > > put
> > > a stack in.  Nor on x86 are there cache blocks that can be
> > > locked into
> > > place.  As code generated with romcc does not use a stack
> it
> > > can be
> > > used during memory initialization."
> > > 
> > > -Bari
> > > 
> > > 
> > 
> > 
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - More reliable, more storage, less spam
> > http://mail.yahoo.com
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > 
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From frannk_m1 at yahoo.com  Wed Mar 17 16:34:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 16:34:01 2004
Subject: SIS chipset
In-Reply-To: <Pine.LNX.4.44.0403171442080.5512-100000@ccs-mail.lanl.gov>
Message-ID: <20040317215627.59629.qmail@web13808.mail.yahoo.com>

You guys are great...
--- "Hendricks David W." <dwh at lanl.gov> wrote:
> Might also want to check out this thread: 
>
http://www.clustermatic.org/pipermail/linuxbios/2004-March/006892.html
> 
> It answers many questions one might have about romcc.
> 
> On Wed, 17 Mar 2004, Bari Ari wrote:
> 
> > Frank wrote:
> > 
> > > This is very good information everyone and everyone is lot
> nicer
> > > then that "other" (ppc) boot loader group. 
> > "LinuxBIOS...the bootloader for grown-ups"... I'm only
> kidding.
> > 
> > Where can I get more
> > > information on RomCC and how do I incorporate that into my
> > > LinuxBios build. Does RomCC replace GCC...
> > 
> > "Consider the source" Frank :) and look through the archives
> 
> > http://www.missl.cs.umd.edu/archives/linuxbios/
> > -Bari
> > 
> > 
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From frannk_m1 at yahoo.com  Wed Mar 17 16:35:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 16:35:01 2004
Subject: SIS chipset
In-Reply-To: <Pine.LNX.4.44.0403171448040.23850-100000@maxroach.lanl.gov>
Message-ID: <20040317215751.14332.qmail@web13810.mail.yahoo.com>

Cool...
--- ron minnich <rminnich at lanl.gov> wrote:
> I should also add that on v2 romcc is of course integrated
> into the build.
> 
> ron
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From frannk_m1 at yahoo.com  Wed Mar 17 17:04:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 17:04:01 2004
Subject: SIS chipset
In-Reply-To: <Pine.LNX.4.44.0403171448040.23850-100000@maxroach.lanl.gov>
Message-ID: <20040317222634.97186.qmail@web13804.mail.yahoo.com>

I must be missing something here but in freebios v1 there is
plenty of supprt for the SIS chip sets. I downloaded freebios2
(thanks you everyone for the information) but I don't see any
support for the SIS chips. I thought freebios2 was a superset of
freebios1 and would therefore have all of the freebios support
plus some. it doesn't appear to be that way. Am I missing
something...

--- ron minnich <rminnich at lanl.gov> wrote:
> I should also add that on v2 romcc is of course integrated
> into the build.
> 
> ron
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From nathanael at gnat.ca  Wed Mar 17 17:20:01 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Wed Mar 17 17:20:01 2004
Subject: SIS chipset
In-Reply-To: <20040317222634.97186.qmail@web13804.mail.yahoo.com>
Message-ID: <6DDC1BA2-7864-11D8-87F5-0003931B4D6A@gnat.ca>

On Wednesday, March 17, 2004, at 02:26 PM, Frank wrote:

> I must be missing something here but in freebios v1 there is
> plenty of supprt for the SIS chip sets. I downloaded freebios2
> (thanks you everyone for the information) but I don't see any
> support for the SIS chips. I thought freebios2 was a superset of
> freebios1 and would therefore have all of the freebios support
> plus some. it doesn't appear to be that way. Am I missing
> something...

Not superset, improved, rewritten port of freebios1. Freebios1 had some 
limitations / weaknesses in that it was difficult to add a new board. 
Memory initialization was difficult and lots of the code was assembly, 
which speaking for myself isn't a skill many people excel at I would 
imagine.

Freebios2 addresses some of the problems developers were having with 
freebios1. Although I am completely unfamiliar with the amd64 stuff 
alot of what freebios2 does is facilitate that arch so the features and 
such could be added. New boards should be started on freebios2, any 
existing code from freebios1 can be brought into freebios2 I would 
imagine as it is needed. (You have to realize I am not a freebios 
developer) just trying to answer some of the questions I think I know 
the answers to so the developers can develop.

-- 
Nathanael D. Noblet
Gnat Solutions
412 - 135 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/



From bari at onelabs.com  Wed Mar 17 17:24:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Mar 17 17:24:00 2004
Subject: SIS chipset
In-Reply-To: <20040317222634.97186.qmail@web13804.mail.yahoo.com>
References: <20040317222634.97186.qmail@web13804.mail.yahoo.com>
Message-ID: <4058D5BB.5040902@onelabs.com>

Frank wrote:

> I must be missing something here but in freebios v1 there is
> plenty of supprt for the SIS chip sets. I downloaded freebios2
> (thanks you everyone for the information) but I don't see any
> support for the SIS chips. I thought freebios2 was a superset of
> freebios1 and would therefore have all of the freebios support
> plus some. it doesn't appear to be that way. Am I missing
> something...

Version2 doesn't have all the earlier sources because nobody has 
volunteered to port all the V1 sources over yet.

-Bari




From frannk_m1 at yahoo.com  Wed Mar 17 17:25:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 17:25:00 2004
Subject: SIS chipset
In-Reply-To: <6DDC1BA2-7864-11D8-87F5-0003931B4D6A@gnat.ca>
Message-ID: <20040317224741.89525.qmail@web13805.mail.yahoo.com>

Thanks for the response. So to the experts out there:
I want to add the SIS 630 based board support from freebios to
freebios2.
Is there a HOWTO I can reference to do this...
--- Nathanael Noblet <nathanael at gnat.ca> wrote:
> 
> On Wednesday, March 17, 2004, at 02:26 PM, Frank wrote:
> 
> > I must be missing something here but in freebios v1 there is
> > plenty of supprt for the SIS chip sets. I downloaded
> freebios2
> > (thanks you everyone for the information) but I don't see
> any
> > support for the SIS chips. I thought freebios2 was a
> superset of
> > freebios1 and would therefore have all of the freebios
> support
> > plus some. it doesn't appear to be that way. Am I missing
> > something...
> 
> Not superset, improved, rewritten port of freebios1. Freebios1
> had some 
> limitations / weaknesses in that it was difficult to add a new
> board. 
> Memory initialization was difficult and lots of the code was
> assembly, 
> which speaking for myself isn't a skill many people excel at I
> would 
> imagine.
> 
> Freebios2 addresses some of the problems developers were
> having with 
> freebios1. Although I am completely unfamiliar with the amd64
> stuff 
> alot of what freebios2 does is facilitate that arch so the
> features and 
> such could be added. New boards should be started on
> freebios2, any 
> existing code from freebios1 can be brought into freebios2 I
> would 
> imagine as it is needed. (You have to realize I am not a
> freebios 
> developer) just trying to answer some of the questions I think
> I know 
> the answers to so the developers can develop.
> 
> -- 
> Nathanael D. Noblet
> Gnat Solutions
> 412 - 135 Gorge Road E
> Victoria, BC V9A 1L1
> 
> T/F 250.385.4613
> 
> http://www.gnat.ca/
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From frannk_m1 at yahoo.com  Wed Mar 17 17:28:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 17:28:01 2004
Subject: SIS chipset
In-Reply-To: <4058D5BB.5040902@onelabs.com>
Message-ID: <20040317225049.1775.qmail@web13804.mail.yahoo.com>

Then what is the structure. I have to know this before I port a
board over. Is there a target I can use as a model. U-BOOT was
quite easy to extend and add additional boards. I would just
pick an exsisting board that was similar to mine and have a
working port in about 3 days. I have a very bad feeling I won't
be able to do this as quickly with freebios2 from freebios...

--- Bari Ari <bari at onelabs.com> wrote:
> Frank wrote:
> 
> > I must be missing something here but in freebios v1 there is
> > plenty of supprt for the SIS chip sets. I downloaded
> freebios2
> > (thanks you everyone for the information) but I don't see
> any
> > support for the SIS chips. I thought freebios2 was a
> superset of
> > freebios1 and would therefore have all of the freebios
> support
> > plus some. it doesn't appear to be that way. Am I missing
> > something...
> 
> Version2 doesn't have all the earlier sources because nobody
> has 
> volunteered to port all the V1 sources over yet.
> 
> -Bari
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From rminnich at lanl.gov  Wed Mar 17 18:38:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 17 18:38:01 2004
Subject: SIS chipset
In-Reply-To: <20040317222634.97186.qmail@web13804.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403171700000.28908-100000@maxroach.lanl.gov>

freebios2 is a clean sheet from scratch redo. 

ron



From rminnich at lanl.gov  Wed Mar 17 18:39:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 17 18:39:01 2004
Subject: SIS chipset
In-Reply-To: <20040317224741.89525.qmail@web13805.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403171701070.28908-100000@maxroach.lanl.gov>

On Wed, 17 Mar 2004, Frank wrote:

> Thanks for the response. So to the experts out there:
> I want to add the SIS 630 based board support from freebios to
> freebios2.

we are forever in your debt :-)


> Is there a HOWTO I can reference to do this...

there is no real howto for v2 :-(

ron



From rminnich at lanl.gov  Wed Mar 17 18:55:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 17 18:55:00 2004
Subject: SIS chipset
In-Reply-To: <20040317225049.1775.qmail@web13804.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403171702020.28908-100000@maxroach.lanl.gov>

On Wed, 17 Mar 2004, Frank wrote:

> Then what is the structure. I have to know this before I port a board
> over. Is there a target I can use as a model. U-BOOT was quite easy to
> extend and add additional boards. I would just pick an exsisting board
> that was similar to mine and have a working port in about 3 days. I have
> a very bad feeling I won't be able to do this as quickly with freebios2
> from freebios...

it's a little harder, as there is learning curve. 

But I just added the ibm e325 in a few minutes. The epia took me longer as 
i rewrote the startup. 

In summary, if there is chipset support in linuxbios, you can do a new 
platform in a few minutes. With no chipset support it takes longer. 

ron



From dwh at lanl.gov  Wed Mar 17 19:29:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Wed Mar 17 19:29:01 2004
Subject: flash_rom support for AMD64
Message-ID: <Pine.LNX.4.44.0403171747260.19188-100000@ccs-mail.lanl.gov>

Has anyone else attempted to use flash_rom on an AMD64 platform? Ollie 
figured out that the BIOS offset was incorrectly set, but even after 
fixing that the flash_rom program still gives us a lot of errors in 64-bit 
SuSE 9 while working perfectly in 32-bit Gentoo.



From YhLu at tyan.com  Wed Mar 17 19:38:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 17 19:38:01 2004
Subject: =?gb2312?B?tPC4tDogZmxhc2hfcm9tIHN1cHBvcnQgZm9yIEFNRDY0?=
Message-ID: <3174569B9743D511922F00A0C94314230466D481@TYANWEB>

Which MB or flash chip model?

-----????-----
???: Hendricks David W. [mailto:dwh at lanl.gov] 
????: 2004?3?17? 16:52
???: linuxbios at clustermatic.org
??: flash_rom support for AMD64

Has anyone else attempted to use flash_rom on an AMD64 platform? Ollie 
figured out that the BIOS offset was incorrectly set, but even after 
fixing that the flash_rom program still gives us a lot of errors in 64-bit 
SuSE 9 while working perfectly in 32-bit Gentoo.

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


From frannk_m1 at yahoo.com  Wed Mar 17 21:43:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 21:43:00 2004
Subject: changing the default paylolad
Message-ID: <20040318030601.86186.qmail@web13806.mail.yahoo.com>

Sorry for what may appear to be a stupid question but the answer
isn't really obvious since various config files are scattered
all over the place. How do I specify which file I am going to
use for the payload. I tried changing the make.base file and the
Makefile but have been unsuccessful so far. I want to use a text
file (/etc/hosts) but can't figure out where to make the change...

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From nathanael at gnat.ca  Wed Mar 17 22:00:01 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Wed Mar 17 22:00:01 2004
Subject: changing the default paylolad
In-Reply-To: <20040318030601.86186.qmail@web13806.mail.yahoo.com>
Message-ID: <93E64D66-788B-11D8-85A3-0003931B4D6A@gnat.ca>

for version 2 look in the build/targets directory. I can't remember the 
exact file. but grep for payload

On Wednesday, March 17, 2004, at 07:06 PM, Frank wrote:

> Sorry for what may appear to be a stupid question but the answer
> isn't really obvious since various config files are scattered
> all over the place. How do I specify which file I am going to
> use for the payload. I tried changing the make.base file and the
> Makefile but have been unsuccessful so far. I want to use a text
> file (/etc/hosts) but can't figure out where to make the change...
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - More reliable, more storage, less spam
> http://mail.yahoo.com
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>
-- 
Nathanael D. Noblet
Gnat Solutions
412 - 135 Gorge Road E
Victoria, BC V9A 1L1

T/F 250.385.4613

http://www.gnat.ca/



From frannk_m1 at yahoo.com  Wed Mar 17 23:27:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Wed Mar 17 23:27:00 2004
Subject: changing the default paylolad
In-Reply-To: <93E64D66-788B-11D8-85A3-0003931B4D6A@gnat.ca>
Message-ID: <20040318044948.42191.qmail@web13803.mail.yahoo.com>

I'm using V1 and  found it in the *.config file. 
Thanks...
--- Nathanael Noblet <nathanael at gnat.ca> wrote:
> for version 2 look in the build/targets directory. I can't
> remember the 
> exact file. but grep for payload
> 
> On Wednesday, March 17, 2004, at 07:06 PM, Frank wrote:
> 
> > Sorry for what may appear to be a stupid question but the
> answer
> > isn't really obvious since various config files are
> scattered
> > all over the place. How do I specify which file I am going
> to
> > use for the payload. I tried changing the make.base file and
> the
> > Makefile but have been unsuccessful so far. I want to use a
> text
> > file (/etc/hosts) but can't figure out where to make the
> change...
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - More reliable, more storage, less spam
> > http://mail.yahoo.com
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> >
> -- 
> Nathanael D. Noblet
> Gnat Solutions
> 412 - 135 Gorge Road E
> Victoria, BC V9A 1L1
> 
> T/F 250.385.4613
> 
> http://www.gnat.ca/
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From linuxbios at huebner.it  Thu Mar 18 02:54:01 2004
From: linuxbios at huebner.it (linuxbios at huebner.it)
Date: Thu Mar 18 02:54:01 2004
Subject: ASUS P2B-DS and MD2202-D32
In-Reply-To: <20040317201656.GA10928@huebner.it>
References: <20040317201656.GA10928@huebner.it>
Message-ID: <20040318081652.GA12728@huebner.it>

Hi all,

here is the output of lspci:

00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev
02)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev
02)
00:04.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02)
00:04.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01)
00:04.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01)
00:04.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 02)
00:06.0 SCSI storage controller: Adaptec AHA-2940U2/W / 7890
01:00.0 VGA compatible controller: nVidia Corporation NV15 Bladerunner
(GeForce2 Ultra) (rev a4)


and the output of lspci -v:

00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev
02)
  Flags: bus master, medium devsel, latency 64
  Memory at e4000000 (32-bit, prefetchable) [size=64M]
  Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev
02) (prog-if 00 [Normal decode])
  Flags: bus master, 66Mhz, medium devsel, latency 64
  Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
  Memory behind bridge: d6000000-d7dfffff
  Prefetchable memory behind bridge: d7f00000-e3ffffff

00:04.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02)
  Flags: bus master, medium devsel, latency 0

00:04.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01) (prog-if
80 [Master])
  Flags: bus master, medium devsel, latency 32
  I/O ports at d800 [size=16]

00:04.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01) (prog-if
00 [UHCI])
  Flags: bus master, medium devsel, latency 32, IRQ 19
  I/O ports at d400 [size=32]

00:04.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 02)
  Flags: medium devsel, IRQ 9

00:06.0 SCSI storage controller: Adaptec AHA-2940U2/W / 7890
  Subsystem: Adaptec 2940U2W SCSI Controller
  Flags: bus master, medium devsel, latency 32, IRQ 19
  BIST result: 00
  I/O ports at d000 [disabled] [size=256]
  Memory at d5800000 (64-bit, non-prefetchable) [size=4K]
  Expansion ROM at <unassigned> [disabled] [size=128K]
  Capabilities: [dc] Power Management version 1

01:00.0 VGA compatible controller: nVidia Corporation NV15 Bladerunner
(GeForce2 Ultra) (rev a4) (prog-if 00 [VGA])
  Subsystem: Elsa AG: Unknown device 0c56
  Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 16
  Memory at d6000000 (32-bit, non-prefetchable) [size=16M]
  Memory at d8000000 (32-bit, prefetchable) [size=128M]
  Expansion ROM at d7ff0000 [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Capabilities: [44] AGP version 2.0



On Wed, Mar 17, 2004 at 09:16:56PM +0100, linuxbios at huebner.it wrote:
> Hi all,
> 
> want to use an ASUS P2B-DS dual P-III mainboard with a MD2202-D32 DoC
> device for LinuxBIOS. In the moment I test it with a 2.6.4 kernel.
> This board uses a 440bx chip set.
> I hot swapped the BIOS Flash chip and the DoC while the board was powered
> on and Linux was running.
> When I modprobe nftl and docprobe I get the following messages in
> /var/log/messages:
> 
> kernel: NFTL driver: nftlcore.c $Revision: 1.94 $, nftlmount.c
> $Revision: 1.34 $
> kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffc8000
> kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffca000
> 
> [...]
> 
> kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffec000
> kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffee000
> kernel: No recognized DiskOnChip devices found
> 
> No my question now is how to initialize the 440bx to get the DoC
> recognized.
> 
> 
> Thank you in advance,
> Andreas
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


From vberdin at eazix.com  Thu Mar 18 07:55:00 2004
From: vberdin at eazix.com (Victor Berdin)
Date: Thu Mar 18 07:55:00 2004
Subject: SST49LF008A-WH
Message-ID: <001501c40ceb$a75d1640$6e3fa8c0@eazix.com>

Hi,

I checked the device list section but failed to find the
mentioned chip. The closest one however is an
SST49LF004. I would like to know if I can use Linux
BIOS project in order to replace the original BIOSware?
And if so, where can I start?

My target board is an AMD GX2 Geode (NatSemi)
SBC. `lspci -v` results are listed below. Any help/advice
are greately appreciated.

P.S., I really don't mind trashing this company hardware
;o) ... but it's best if I can make Linux work wonders on
this device without killing innocent transistors.

TIA and best regards - Vic


------------------
00:01.0 Host bridge: National Semiconductor Corporation: Unknown device 0028
(rev 21)
Subsystem: National Semiconductor Corporation: Unknown device 0028
Flags: bus master, 66Mhz, medium devsel, latency 248
I/O ports at ac1c [size=4]
00:01.1 VGA compatible controller: National Semiconductor Corporation:
Unknown device 0030 (prog-if 00 [VGA])
Subsystem: National Semiconductor Corporation: Unknown device 0030
Flags: 66Mhz, medium devsel
Memory at 41000000 (32-bit, non-prefetchable) [size=16M]
Memory at 40ffc000 (32-bit, non-prefetchable) [size=16K]
Memory at 40ff8000 (32-bit, non-prefetchable) [size=16K]
Memory at 40ff4000 (32-bit, non-prefetchable) [size=16K]
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C
(rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Flags: bus master, medium devsel, latency 64, IRQ 11
I/O ports at ee00 [size=256]
Memory at efffdf00 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
00:0f.0 ISA bridge: National Semiconductor Corporation: Unknown device 002b
(rev 13)
Subsystem: National Semiconductor Corporation: Unknown device 002b
Flags: 66Mhz, medium devsel
I/O ports at 6000 [size=8]
I/O ports at 6100 [size=256]
I/O ports at 6200 [size=64]
I/O ports at 1000 [size=32]
I/O ports at 9d00 [size=128]
I/O ports at 9c00 [size=64]
00:0f.2 IDE interface: National Semiconductor Corporation: Unknown device
002d (prog-if 80 [Master])
Subsystem: National Semiconductor Corporation: Unknown device 002d
Flags: bus master, 66Mhz, medium devsel, latency 0
I/O ports at eff0 [size=16]
00:0f.3 Multimedia audio controller: National Semiconductor Corporation:
Unknown device 002e
Subsystem: National Semiconductor Corporation: Unknown device 002e
Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11
I/O ports at ed80 [size=128]
00:0f.4 USB Controller: National Semiconductor Corporation: Unknown device
002f (rev 06) (prog-if 10 [OHCI])
Subsystem: National Semiconductor Corporation: Unknown device 002f
Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11
Memory at effff000 (32-bit, non-prefetchable) [size=4K]
00:0f.5 USB Controller: National Semiconductor Corporation: Unknown device
002f (rev 06) (prog-if 10 [OHCI])
Subsystem: National Semiconductor Corporation: Unknown device 002f
Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 10
Memory at efffe000 (32-bit, non-prefetchable) [size=4K]
---------------



From andreas.huebner at hp.com  Thu Mar 18 08:03:01 2004
From: andreas.huebner at hp.com (Huebner, Andreas)
Date: Thu Mar 18 08:03:01 2004
Subject: ASUS P2B-DS and MD2202-D32
Message-ID: <0295B57A4D11E44C94685AD72B2C5C850BAB9D@bbnexc02.emea.cpqcorp.net>

Hi all,

I want to use an ASUS P2B-DS dual P-III mainboard with a MD2202-D32 DoC
device for LinuxBIOS. In the moment I test it with a 2.6.4 kernel.
This board uses a 440bx chip set.
I hot swapped the BIOS Flash chip and the DoC while the board was
powered
on and Linux was running.
When I modprobe nftl and docprobe I get the following messages in
/var/log/messages:

kernel: NFTL driver: nftlcore.c $Revision: 1.94 $, nftlmount.c
$Revision: 1.34 $
kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffc8000
kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffca000

[...]

kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffec000
kernel: Possible DiskOnChip with unknown ChipID FF found at 0xfffee000
kernel: No recognized DiskOnChip devices found

No my question now is how to initialize the 440bx to get the DoC
recognized.


Here is the output of lspci. Everything except the VGA controller is
onboard.

00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev
02)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev
02)
00:04.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02)
00:04.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01)
00:04.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01)
00:04.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 02)
00:06.0 SCSI storage controller: Adaptec AHA-2940U2/W / 7890
01:00.0 VGA compatible controller: nVidia Corporation NV15 Bladerunner
(GeForce2 Ultra) (rev a4)


and the output of lspci -v:

00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev
02)
  Flags: bus master, medium devsel, latency 64
  Memory at e4000000 (32-bit, prefetchable) [size=64M]
  Capabilities: [a0] AGP version 1.0

00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev
02) (prog-if 00 [Normal decode])
  Flags: bus master, 66Mhz, medium devsel, latency 64
  Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
  Memory behind bridge: d6000000-d7dfffff
  Prefetchable memory behind bridge: d7f00000-e3ffffff

00:04.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02)
  Flags: bus master, medium devsel, latency 0

00:04.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01) (prog-if
80 [Master])
  Flags: bus master, medium devsel, latency 32
  I/O ports at d800 [size=16]

00:04.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01) (prog-if
00 [UHCI])
  Flags: bus master, medium devsel, latency 32, IRQ 19
  I/O ports at d400 [size=32]

00:04.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 02)
  Flags: medium devsel, IRQ 9

00:06.0 SCSI storage controller: Adaptec AHA-2940U2/W / 7890
  Subsystem: Adaptec 2940U2W SCSI Controller
  Flags: bus master, medium devsel, latency 32, IRQ 19
  BIST result: 00
  I/O ports at d000 [disabled] [size=256]
  Memory at d5800000 (64-bit, non-prefetchable) [size=4K]
  Expansion ROM at <unassigned> [disabled] [size=128K]
  Capabilities: [dc] Power Management version 1

01:00.0 VGA compatible controller: nVidia Corporation NV15 Bladerunner
(GeForce2 Ultra) (rev a4) (prog-if 00 [VGA])
  Subsystem: Elsa AG: Unknown device 0c56
  Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 16
  Memory at d6000000 (32-bit, non-prefetchable) [size=16M]
  Memory at d8000000 (32-bit, prefetchable) [size=128M]
  Expansion ROM at d7ff0000 [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Capabilities: [44] AGP version 2.0


Thank you in advance,
Andreas


From rminnich at lanl.gov  Thu Mar 18 10:30:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 18 10:30:01 2004
Subject: changing the default paylolad
In-Reply-To: <20040318030601.86186.qmail@web13806.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403180851320.3673-100000@maxroach.lanl.gov>

On Wed, 17 Mar 2004, Frank wrote:

> Sorry for what may appear to be a stupid question but the answer
> isn't really obvious since various config files are scattered
> all over the place. How do I specify which file I am going to
> use for the payload. I tried changing the make.base file and the
> Makefile but have been unsuccessful so far. I want to use a text
> file (/etc/hosts) but can't figure out where to make the change...

which version again? 

You are a bit off in the weeds so if you are on V1 start over. I think you 
ought to read one of these: 

bash-2.05b$ ls freebios/HOWTO/*
freebios/HOWTO/ALIM1631_M1535D  freebios/HOWTO/K7SEM   
freebios/HOWTO/SiS630
freebios/HOWTO/EPIA             freebios/HOWTO/L440GX

Probably the SiS630

ron



From rminnich at lanl.gov  Thu Mar 18 10:35:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 18 10:35:01 2004
Subject: SST49LF008A-WH
In-Reply-To: <001501c40ceb$a75d1640$6e3fa8c0@eazix.com>
Message-ID: <Pine.LNX.4.44.0403180857250.3673-100000@maxroach.lanl.gov>

On Thu, 18 Mar 2004, Victor Berdin wrote:

> My target board is an AMD GX2 Geode (NatSemi)
> SBC. `lspci -v` results are listed below. Any help/advice
> are greately appreciated.

lotsa unknown devices there, send lspci -n instead.

Are data books available?

ron



From rminnich at lanl.gov  Thu Mar 18 10:38:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 18 10:38:00 2004
Subject: changing the default paylolad
In-Reply-To: <Pine.LNX.4.44.0403180851320.3673-100000@maxroach.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403180900070.3673-100000@maxroach.lanl.gov>

note that at clustermatic.org, we have the LACSI tutorial CD. On that CD 
is the tutorial presentation, including a section on building V2 
linuxbios.

ron



From frannk_m1 at yahoo.com  Thu Mar 18 10:44:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Thu Mar 18 10:44:01 2004
Subject: changing the default paylolad
In-Reply-To: <Pine.LNX.4.44.0403180851320.3673-100000@maxroach.lanl.gov>
Message-ID: <20040318160626.68762.qmail@web13804.mail.yahoo.com>

Thanks I found it already ("payload") in the config file.
Actually I'm using a SIS55x based board from advantech. I built
it successfully and the code looks like it's correct. This
config is for the SIS Demo board so I have to go thru and make
sure there aren't any board specific base addresses. I am not
naive enough to think it will boot the first time so I'm going
to order a Rom Emulator with a tracing function. I have one in
mind, do you have any suggestions?
Thanks again for your help...
--- ron minnich <rminnich at lanl.gov> wrote:
> On Wed, 17 Mar 2004, Frank wrote:
> 
> > Sorry for what may appear to be a stupid question but the
> answer
> > isn't really obvious since various config files are
> scattered
> > all over the place. How do I specify which file I am going
> to
> > use for the payload. I tried changing the make.base file and
> the
> > Makefile but have been unsuccessful so far. I want to use a
> text
> > file (/etc/hosts) but can't figure out where to make the
> change...
> 
> which version again? 
> 
> You are a bit off in the weeds so if you are on V1 start over.
> I think you 
> ought to read one of these: 
> 
> bash-2.05b$ ls freebios/HOWTO/*
> freebios/HOWTO/ALIM1631_M1535D  freebios/HOWTO/K7SEM   
> freebios/HOWTO/SiS630
> freebios/HOWTO/EPIA             freebios/HOWTO/L440GX
> 
> Probably the SiS630
> 
> ron
> 

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From frannk_m1 at yahoo.com  Thu Mar 18 10:53:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Thu Mar 18 10:53:01 2004
Subject: changing the default paylolad
In-Reply-To: <Pine.LNX.4.44.0403180900070.3673-100000@maxroach.lanl.gov>
Message-ID: <20040318161602.18233.qmail@web13811.mail.yahoo.com>

Thanks, I'll check it out...
--- ron minnich <rminnich at lanl.gov> wrote:
> note that at clustermatic.org, we have the LACSI tutorial CD.
> On that CD 
> is the tutorial presentation, including a section on building
> V2 
> linuxbios.
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From bari at onelabs.com  Thu Mar 18 10:55:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Mar 18 10:55:01 2004
Subject: SST49LF008A-WH
In-Reply-To: <Pine.LNX.4.44.0403180857250.3673-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403180857250.3673-100000@maxroach.lanl.gov>
Message-ID: <4059CC3E.6080102@onelabs.com>

ron minnich wrote:
> On Thu, 18 Mar 2004, Victor Berdin wrote:
> 
> 
>>My target board is an AMD GX2 Geode (NatSemi)
>>SBC. `lspci -v` results are listed below. Any help/advice
>>are greately appreciated.
> 
> 
> lotsa unknown devices there, send lspci -n instead.
> 
> Are data books available?

Now that the GX2 is AMD there is hope for this.

http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_9864,00.html
http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_9864%5E9867,00.html

AMD alos has a developer site that you need to have authorization to get on.
http://wwwd.amd.com/amd/developer.nsf/

The docs plus access to your local AMD FAE should be all you need.

-Bari




From rminnich at lanl.gov  Thu Mar 18 11:12:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 18 11:12:01 2004
Subject: changing the default paylolad
In-Reply-To: <20040318160626.68762.qmail@web13804.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403180934360.3673-100000@maxroach.lanl.gov>

just slam the flash part in and see what happens. Sometimes it "just 
works"

A post card is very useful. You may get far enough with that that you 
don't need a rom emulator.

ron



From ollie at lanl.gov  Thu Mar 18 11:52:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 18 11:52:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?= flash_rom support for AMD64
In-Reply-To: <3174569B9743D511922F00A0C94314230466D481@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D481@TYANWEB>
Message-ID: <1079630063.25319.14.camel@exponential.lanl.gov>

On Wed, 2004-03-17 at 18:06, YhLu wrote:
> Which MB or flash chip model?
> 

Tyan s2885 with sst49lf040.

Ollie




From YhLu at tyan.com  Thu Mar 18 12:28:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 18 12:28:00 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogZmxhc2hfcm9tIHN1cHBvcnQgZm9yIEFNRDY0?=
Message-ID: <3174569B9743D511922F00A0C94314230466D4CB@TYANWEB>

The rom that shipped with s2885 should be pmc49fl004.
The flash_rom already include support amd8111 and pmc49fl004.

YH

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?18? 9:14
???: YhLu
??: Hendricks David W.; LinuxBIOS
??: Re: ??: flash_rom support for AMD64

On Wed, 2004-03-17 at 18:06, YhLu wrote:
> Which MB or flash chip model?
> 

Tyan s2885 with sst49lf040.

Ollie



From ollie at lanl.gov  Thu Mar 18 12:33:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 18 12:33:01 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= flash_rom support for AMD64
In-Reply-To: <3174569B9743D511922F00A0C94314230466D4CB@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D4CB@TYANWEB>
Message-ID: <1079632544.25319.17.camel@exponential.lanl.gov>

On Thu, 2004-03-18 at 10:57, YhLu wrote:
> The rom that shipped with s2885 should be pmc49fl004.
> The flash_rom already include support amd8111 and pmc49fl004.
> 

Yea, we just try to add some more support for different flash parts.
The point is, it works FINE under 32-bits mode but fails in 64-bits
mode. Did you try to flash in 64-bits mode ?

Ollie

> YH
> 
> -----????-----
> ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????: 2004?3?18? 9:14
> ???: YhLu
> ??: Hendricks David W.; LinuxBIOS
> ??: Re: ??: flash_rom support for AMD64
> 
> On Wed, 2004-03-17 at 18:06, YhLu wrote:
> > Which MB or flash chip model?
> > 
> 
> Tyan s2885 with sst49lf040.
> 
> Ollie
> 
> 



From YhLu at tyan.com  Thu Mar 18 12:37:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 18 12:37:00 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogtPC4tDogZmxhc2hfcm9tIHN1cHBvcnQgZm9y?=
	=?gb2312?B?IEFNRDY0?=
Message-ID: <3174569B9743D511922F00A0C94314230466D4CD@TYANWEB>

So you mean the flash_rom is 64 bit?
I think I have tried that Kernel(64bit)+initrd (64 bit) (64 bit lib and 32
bit libs) + flash_rom (32 bit). It's OK.

YH

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?18? 9:56
???: YhLu
??: Hendricks David W.; LinuxBIOS
??: Re: ??: ??: flash_rom support for AMD64

On Thu, 2004-03-18 at 10:57, YhLu wrote:
> The rom that shipped with s2885 should be pmc49fl004.
> The flash_rom already include support amd8111 and pmc49fl004.
> 

Yea, we just try to add some more support for different flash parts.
The point is, it works FINE under 32-bits mode but fails in 64-bits
mode. Did you try to flash in 64-bits mode ?

Ollie

> YH
> 
> -----????-----
> ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????: 2004?3?18? 9:14
> ???: YhLu
> ??: Hendricks David W.; LinuxBIOS
> ??: Re: ??: flash_rom support for AMD64
> 
> On Wed, 2004-03-17 at 18:06, YhLu wrote:
> > Which MB or flash chip model?
> > 
> 
> Tyan s2885 with sst49lf040.
> 
> Ollie
> 
> 


From ollie at lanl.gov  Thu Mar 18 12:40:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 18 12:40:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= =?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?=
	flash_rom support for AMD64
In-Reply-To: <3174569B9743D511922F00A0C94314230466D4CD@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D4CD@TYANWEB>
Message-ID: <1079632953.25319.19.camel@exponential.lanl.gov>

On Thu, 2004-03-18 at 11:05, YhLu wrote:
> So you mean the flash_rom is 64 bit?
> I think I have tried that Kernel(64bit)+initrd (64 bit) (64 bit lib and 32
> bit libs) + flash_rom (32 bit). It's OK.
> 

I don't know if the lib is 64bit. It should be. The flash_rom
should be 64bit too.

Ollie




From YhLu at tyan.com  Thu Mar 18 12:59:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 18 12:59:00 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogtPC4tDogtPC4tDogZmxhc2hfcm9tIHN1cHBv?=
	=?gb2312?B?cnQgZm9yIEFNRDY0?=
Message-ID: <3174569B9743D511922F00A0C94314230466D4CF@TYANWEB>

In the Suse 9 for amd64, I can not find pci/pci.h.

Where I can find the pcilib for amd64?

YH

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?18? 10:03
???: YhLu
??: Hendricks David W.; LinuxBIOS
??: Re: ??: ??: ??: flash_rom support for AMD64

On Thu, 2004-03-18 at 11:05, YhLu wrote:
> So you mean the flash_rom is 64 bit?
> I think I have tried that Kernel(64bit)+initrd (64 bit) (64 bit lib and 32
> bit libs) + flash_rom (32 bit). It's OK.
> 

I don't know if the lib is 64bit. It should be. The flash_rom
should be 64bit too.

Ollie



From dwh at lanl.gov  Thu Mar 18 13:03:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 18 13:03:00 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogtPC4tDogtPC4tDogZmxhc2hfcm9tIHN1cHBv?=
 =?gb2312?B?cnQgZm9yIEFNRDY0?=
In-Reply-To: <3174569B9743D511922F00A0C94314230466D4CF@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403181124280.19188-100000@ccs-mail.lanl.gov>

yast -i pciutils and yast -i pciutils-devel

On Thu, 18 Mar 2004, YhLu wrote:

> In the Suse 9 for amd64, I can not find pci/pci.h.
> 
> Where I can find the pcilib for amd64?
> 
> YH
> 
> -----????????-----
> ??????: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????????: 2004??3??18?? 10:03
> ??????: YhLu
> ????: Hendricks David W.; LinuxBIOS
> ????: Re: ????: ????: ????: flash_rom support for AMD64
> 
> On Thu, 2004-03-18 at 11:05, YhLu wrote:
> > So you mean the flash_rom is 64 bit?
> > I think I have tried that Kernel(64bit)+initrd (64 bit) (64 bit lib and 32
> > bit libs) + flash_rom (32 bit). It's OK.
> > 
> 
> I don't know if the lib is 64bit. It should be. The flash_rom
> should be 64bit too.
> 
> Ollie
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rminnich at lanl.gov  Thu Mar 18 13:04:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 18 13:04:01 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogtPC4tDogtPC4tDogZmxhc2hfcm9tIHN1cHBv?=
 =?gb2312?B?cnQgZm9yIEFNRDY0?=
In-Reply-To: <3174569B9743D511922F00A0C94314230466D4CF@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403181126310.3673-100000@maxroach.lanl.gov>

On Thu, 18 Mar 2004, YhLu wrote:

> In the Suse 9 for amd64, I can not find pci/pci.h.
> 
> Where I can find the pcilib for amd64?

yes, suse includes pciutils in /sbin but no libpci.a or includes. 

You have to get the pci-utils and install them yourself. I will send you 
the .tgz if you wish.

ron



From rminnich at lanl.gov  Thu Mar 18 13:05:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 18 13:05:01 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogtPC4tDogtPC4tDogZmxhc2hfcm9tIHN1cHBv?=
 =?gb2312?B?cnQgZm9yIEFNRDY0?=
In-Reply-To: <Pine.LNX.4.44.0403181124280.19188-100000@ccs-mail.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403181127150.3673-100000@maxroach.lanl.gov>

On Thu, 18 Mar 2004, Hendricks David W. wrote:

> yast -i pciutils and yast -i pciutils-devel

david keeps making me feel silly :-)

yes, that will do it.

ron



From ollie at lanl.gov  Thu Mar 18 13:08:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 18 13:08:01 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= =?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= flash_rom support for AMD64
In-Reply-To: <3174569B9743D511922F00A0C94314230466D4CF@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D4CF@TYANWEB>
Message-ID: <1079634625.25319.21.camel@exponential.lanl.gov>

On Thu, 2004-03-18 at 11:28, YhLu wrote:
> In the Suse 9 for amd64, I can not find pci/pci.h.
> 
> Where I can find the pcilib for amd64?
> 

You have to install it from source, I believe.

Ollie

> YH
> 
> -----????-----
> ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????: 2004?3?18? 10:03
> ???: YhLu
> ??: Hendricks David W.; LinuxBIOS
> ??: Re: ??: ??: ??: flash_rom support for AMD64
> 
> On Thu, 2004-03-18 at 11:05, YhLu wrote:
> > So you mean the flash_rom is 64 bit?
> > I think I have tried that Kernel(64bit)+initrd (64 bit) (64 bit lib and 32
> > bit libs) + flash_rom (32 bit). It's OK.
> > 
> 
> I don't know if the lib is 64bit. It should be. The flash_rom
> should be 64bit too.
> 
> Ollie
> 
> 



From rminnich at lanl.gov  Thu Mar 18 13:13:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 18 13:13:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?= =?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?=
 =?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= =?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?=
 flash_rom support for AMD64
In-Reply-To: <1079634625.25319.21.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403181135000.3673-100000@maxroach.lanl.gov>

On Thu, 18 Mar 2004, Li-Ta Lo wrote:

> You have to install it from source, I believe.

be sure to enable intel configuration types 1 and 2. The standard bios 
hides the 8151 bridge.

ron



From YhLu at tyan.com  Thu Mar 18 13:44:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 18 13:44:01 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogtPC4tDogtPC4tDogtPC4tDogZmxhc2hfcm9t?=
	=?gb2312?B?IHN1cHBvcnQgZm9yIEFNRDY0?=
Message-ID: <3174569B9743D511922F00A0C94314230466D4D7@TYANWEB>

Stuck after 3.

It seems it doesn't allow write mmio.

int probe_49fl004 (struct flashchip * flash)
{       
        volatile char * bios = flash->virt_addr;
        unsigned char  id1, id2;
        printf("3\n");
        *(volatile char *) (bios + 0x5555) = 0xAA;
        myusec_delay(10);      
        printf("4\n");
        *(volatile char *) (bios + 0x2AAA) = 0x55;
        myusec_delay(10);   
        printf("5\n");
        *(volatile char *) (bios + 0x5555) = 0x90;

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?3?18? 10:35
???: Li-Ta Lo
??: YhLu; Hendricks David W.; LinuxBIOS
??: Re: ??: ??: ??: ??: flash_rom support for AMD64

On Thu, 18 Mar 2004, Li-Ta Lo wrote:

> You have to install it from source, I believe.

be sure to enable intel configuration types 1 and 2. The standard bios 
hides the 8151 bridge.

ron


From ollie at lanl.gov  Thu Mar 18 14:27:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 18 14:27:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= =?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= =?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?=
	flash_rom support for AMD64
In-Reply-To: <3174569B9743D511922F00A0C94314230466D4D7@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D4D7@TYANWEB>
Message-ID: <1079639386.25319.24.camel@exponential.lanl.gov>

On Thu, 2004-03-18 at 12:13, YhLu wrote:
> Stuck after 3.
> 
> It seems it doesn't allow write mmio.
> 
> int probe_49fl004 (struct flashchip * flash)
> {       
>         volatile char * bios = flash->virt_addr;
>         unsigned char  id1, id2;
>         printf("3\n");
>         *(volatile char *) (bios + 0x5555) = 0xAA;
>         myusec_delay(10);      
>         printf("4\n");
>         *(volatile char *) (bios + 0x2AAA) = 0x55;
>         myusec_delay(10);   
>         printf("5\n");
>         *(volatile char *) (bios + 0x5555) = 0x90;
> 


There is some arithmeatic error in old flash_rom, please
cvs update.

Ollie




From YhLu at tyan.com  Thu Mar 18 14:40:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 18 14:40:01 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogtPC4tDogtPC4tDogtPC4tDogtPC4tDogZmxh?=
	=?gb2312?B?c2hfcm9tIHN1cHBvcnQgZm9yIEFNRDY0?=
Message-ID: <3174569B9743D511922F00A0C94314230466D4E8@TYANWEB>

It works with pm49lf004 under 64 bit.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?18? 11:50
???: YhLu
??: ron minnich; Hendricks David W.; LinuxBIOS
??: Re: ??: ??: ??: ??: ??: flash_rom support for AMD64

On Thu, 2004-03-18 at 12:13, YhLu wrote:
> Stuck after 3.
> 
> It seems it doesn't allow write mmio.
> 
> int probe_49fl004 (struct flashchip * flash)
> {       
>         volatile char * bios = flash->virt_addr;
>         unsigned char  id1, id2;
>         printf("3\n");
>         *(volatile char *) (bios + 0x5555) = 0xAA;
>         myusec_delay(10);      
>         printf("4\n");
>         *(volatile char *) (bios + 0x2AAA) = 0x55;
>         myusec_delay(10);   
>         printf("5\n");
>         *(volatile char *) (bios + 0x5555) = 0x90;
> 


There is some arithmeatic error in old flash_rom, please
cvs update.

Ollie



From ollie at lanl.gov  Thu Mar 18 15:34:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 18 15:34:00 2004
Subject: [COMMIT] linuxbios 1.1.6....
In-Reply-To: <m3smgfjt4z.fsf@maxwell.lnxi.com>
References: <m3smgfjt4z.fsf@maxwell.lnxi.com>
Message-ID: <1079643390.25319.26.camel@exponential.lanl.gov>

On Thu, 2004-03-11 at 08:33, Eric W. Biederman wrote:

> - Attempted to make the VGA IO region assigment work.  The code seems to work now...

Eric,

What have to done with this one ?

Ollie




From dwh at lanl.gov  Thu Mar 18 15:43:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 18 15:43:01 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogtPC4tDogtPC4tDogtPC4tDogtPC4tDogZmxh?=
 =?gb2312?B?c2hfcm9tIHN1cHBvcnQgZm9yIEFNRDY0?=
In-Reply-To: <3174569B9743D511922F00A0C94314230466D4E8@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403181308270.25934-100000@ccs-mail.lanl.gov>

I have verified this.

The SST part still won't flash under 64-bit SuSE, however.

On Thu, 18 Mar 2004, YhLu wrote:

> It works with pm49lf004 under 64 bit.
> 
> -----????????-----
> ??????: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????????: 2004??3??18?? 11:50
> ??????: YhLu
> ????: ron minnich; Hendricks David W.; LinuxBIOS
> ????: Re: ????: ????: ????: ????: ????: flash_rom support for AMD64
> 
> On Thu, 2004-03-18 at 12:13, YhLu wrote:
> > Stuck after 3.
> > 
> > It seems it doesn't allow write mmio.
> > 
> > int probe_49fl004 (struct flashchip * flash)
> > {       
> >         volatile char * bios = flash->virt_addr;
> >         unsigned char  id1, id2;
> >         printf("3\n");
> >         *(volatile char *) (bios + 0x5555) = 0xAA;
> >         myusec_delay(10);      
> >         printf("4\n");
> >         *(volatile char *) (bios + 0x2AAA) = 0x55;
> >         myusec_delay(10);   
> >         printf("5\n");
> >         *(volatile char *) (bios + 0x5555) = 0x90;
> > 
> 
> 
> There is some arithmeatic error in old flash_rom, please
> cvs update.
> 
> Ollie
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From YhLu at tyan.com  Thu Mar 18 15:45:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 18 15:45:01 2004
Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiDnrZTlpI06?=
	=?utf-8?B?IOetlOWkjTog562U5aSNOiBmbGFzaF9yb20gc3VwcG9ydCBmb3IgQU1ENjQ=?=
Message-ID: <3174569B9743D511922F00A0C94314230466D4EF@TYANWEB>

Does it work in 32 bit?

-----????-----
???: Hendricks David W. [mailto:dwh at lanl.gov] 
????: 2004?3?18? 13:06
???: YhLu
??: Li-Ta Lo; ron minnich; LinuxBIOS
??: Re: ????: ????: ????: ????: ????: ????: flash_rom support for AMD64

I have verified this.

The SST part still won't flash under 64-bit SuSE, however.

On Thu, 18 Mar 2004, YhLu wrote:

> It works with pm49lf004 under 64 bit.
> 
> -----????????-----
> ??????: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????????: 2004??3??18?? 11:50
> ??????: YhLu
> ????: ron minnich; Hendricks David W.; LinuxBIOS
> ????: Re: ????: ????: ????: ????: ????: flash_rom support for AMD64
> 
> On Thu, 2004-03-18 at 12:13, YhLu wrote:
> > Stuck after 3.
> > 
> > It seems it doesn't allow write mmio.
> > 
> > int probe_49fl004 (struct flashchip * flash)
> > {       
> >         volatile char * bios = flash->virt_addr;
> >         unsigned char  id1, id2;
> >         printf("3\n");
> >         *(volatile char *) (bios + 0x5555) = 0xAA;
> >         myusec_delay(10);      
> >         printf("4\n");
> >         *(volatile char *) (bios + 0x2AAA) = 0x55;
> >         myusec_delay(10);   
> >         printf("5\n");
> >         *(volatile char *) (bios + 0x5555) = 0x90;
> > 
> 
> 
> There is some arithmeatic error in old flash_rom, please
> cvs update.
> 
> Ollie
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 


From dwh at lanl.gov  Thu Mar 18 15:47:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 18 15:47:00 2004
Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiDnrZTlpI06?=
 =?utf-8?B?IOetlOWkjTog562U5aSNOiBmbGFzaF9yb20gc3VwcG9ydCBmb3IgQU1ENjQ=?=
 [PMX:#]
In-Reply-To: <3174569B9743D511922F00A0C94314230466D4EF@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403181408420.25934-100000@ccs-mail.lanl.gov>

Yes. The SST part will flash under 32-bit Gentoo, but not 64-bit SuSE. 

The PM part will flash using either 32-bit or 64-bit environments. 

On Thu, 18 Mar 2004, YhLu wrote:

> Does it work in 32 bit?
> 
> -----????????????-----
> ?????????: Hendricks David W. [mailto:dwh at lanl.gov] 
> ????????????: 2004???3???18??? 13:06
> ?????????: YhLu
> ??????: Li-Ta Lo; ron minnich; LinuxBIOS
> ??????: Re: ????????: ????????: ????????: ????????: ????????: ????????: flash_rom support for AMD64
> 
> I have verified this.
> 
> The SST part still won't flash under 64-bit SuSE, however.
> 
> On Thu, 18 Mar 2004, YhLu wrote:
> 
> > It works with pm49lf004 under 64 bit.
> > 
> > -----????????????????-----
> > ????????????: Li-Ta Lo [mailto:ollie at lanl.gov] 
> > ????????????????: 2004????3????18???? 11:50
> > ????????????: YhLu
> > ????????: ron minnich; Hendricks David W.; LinuxBIOS
> > ????????: Re: ????????: ????????: ????????: ????????: ????????: flash_rom support for AMD64
> > 
> > On Thu, 2004-03-18 at 12:13, YhLu wrote:
> > > Stuck after 3.
> > > 
> > > It seems it doesn't allow write mmio.
> > > 
> > > int probe_49fl004 (struct flashchip * flash)
> > > {       
> > >         volatile char * bios = flash->virt_addr;
> > >         unsigned char  id1, id2;
> > >         printf("3\n");
> > >         *(volatile char *) (bios + 0x5555) = 0xAA;
> > >         myusec_delay(10);      
> > >         printf("4\n");
> > >         *(volatile char *) (bios + 0x2AAA) = 0x55;
> > >         myusec_delay(10);   
> > >         printf("5\n");
> > >         *(volatile char *) (bios + 0x5555) = 0x90;
> > > 
> > 
> > 
> > There is some arithmeatic error in old flash_rom, please
> > cvs update.
> > 
> > Ollie
> > 
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > 
> 



From dwh at lanl.gov  Thu Mar 18 15:54:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 18 15:54:01 2004
Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiDnrZTlpI06?=
 =?utf-8?B?IOetlOWkjTog562U5aSNOiBmbGFzaF9yb20gc3VwcG9ydCBmb3IgQU1ENjQ=?=
 [PMX:#]
In-Reply-To: <Pine.LNX.4.44.0403181408420.25934-100000@ccs-mail.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403181414300.25934-100000@ccs-mail.lanl.gov>

I should clarify that statement. The SST49LF040 part will flash with 
errors under 64-bit SuSE resulting in an unusable part. The PM part will 
flash properly in both 32-bit and 64-bit environments.

On Thu, 18 Mar 2004, Hendricks David W. wrote:

> Yes. The SST part will flash under 32-bit Gentoo, but not 64-bit SuSE. 
> 
> The PM part will flash using either 32-bit or 64-bit environments. 
> 
> On Thu, 18 Mar 2004, YhLu wrote:
> 
> > Does it work in 32 bit?
> > 
> > -----????????????-----
> > ?????????: Hendricks David W. [mailto:dwh at lanl.gov] 
> > ????????????: 2004???3???18??? 13:06
> > ?????????: YhLu
> > ??????: Li-Ta Lo; ron minnich; LinuxBIOS
> > ??????: Re: ????????: ????????: ????????: ????????: ????????: ????????: flash_rom support for AMD64
> > 
> > I have verified this.
> > 
> > The SST part still won't flash under 64-bit SuSE, however.
> > 
> > On Thu, 18 Mar 2004, YhLu wrote:
> > 
> > > It works with pm49lf004 under 64 bit.
> > > 
> > > -----????????????????-----
> > > ????????????: Li-Ta Lo [mailto:ollie at lanl.gov] 
> > > ????????????????: 2004????3????18???? 11:50
> > > ????????????: YhLu
> > > ????????: ron minnich; Hendricks David W.; LinuxBIOS
> > > ????????: Re: ????????: ????????: ????????: ????????: ????????: flash_rom support for AMD64
> > > 
> > > On Thu, 2004-03-18 at 12:13, YhLu wrote:
> > > > Stuck after 3.
> > > > 
> > > > It seems it doesn't allow write mmio.
> > > > 
> > > > int probe_49fl004 (struct flashchip * flash)
> > > > {       
> > > >         volatile char * bios = flash->virt_addr;
> > > >         unsigned char  id1, id2;
> > > >         printf("3\n");
> > > >         *(volatile char *) (bios + 0x5555) = 0xAA;
> > > >         myusec_delay(10);      
> > > >         printf("4\n");
> > > >         *(volatile char *) (bios + 0x2AAA) = 0x55;
> > > >         myusec_delay(10);   
> > > >         printf("5\n");
> > > >         *(volatile char *) (bios + 0x5555) = 0x90;
> > > > 
> > > 
> > > 
> > > There is some arithmeatic error in old flash_rom, please
> > > cvs update.
> > > 
> > > 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 YhLu at tyan.com  Thu Mar 18 15:59:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 18 15:59:01 2004
Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiDnrZTlpI06?=
	=?utf-8?B?IOetlOWkjTog562U5aSNOiDnrZTlpI06IGZsYXNoX3JvbSBzdXBwb3J0IGZv?=
	=?utf-8?B?ciBBTUQ2NCBbUE1YOiNd?=
Message-ID: <3174569B9743D511922F00A0C94314230466D4F2@TYANWEB>

Can you try by block instead of sector?

YH

-----????-----
???: Hendricks David W. [mailto:dwh at lanl.gov] 
????: 2004?3?18? 13:16
???: YhLu
??: Li-Ta Lo; ron minnich; LinuxBIOS
??: Re: ????: ????: ????: ????: ????: ????: ????: flash_rom support for
AMD64 [PMX:#]

I should clarify that statement. The SST49LF040 part will flash with 
errors under 64-bit SuSE resulting in an unusable part. The PM part will 
flash properly in both 32-bit and 64-bit environments.

On Thu, 18 Mar 2004, Hendricks David W. wrote:

> Yes. The SST part will flash under 32-bit Gentoo, but not 64-bit SuSE. 
> 
> The PM part will flash using either 32-bit or 64-bit environments. 
> 
> On Thu, 18 Mar 2004, YhLu wrote:
> 
> > Does it work in 32 bit?
> > 
> > -----????????????-----
> > ?????????: Hendricks David W. [mailto:dwh at lanl.gov] 
> > ????????????: 2004???3???18??? 13:06
> > ?????????: YhLu
> > ??????: Li-Ta Lo; ron minnich; LinuxBIOS
> > ??????: Re: ????????: ????????: ????????: ????????: ????????: ????????:
flash_rom support for AMD64
> > 
> > I have verified this.
> > 
> > The SST part still won't flash under 64-bit SuSE, however.
> > 
> > On Thu, 18 Mar 2004, YhLu wrote:
> > 
> > > It works with pm49lf004 under 64 bit.
> > > 
> > > -----????????????????-----
> > > ????????????: Li-Ta Lo [mailto:ollie at lanl.gov] 
> > > ????????????????: 2004????3????18???? 11:50
> > > ????????????: YhLu
> > > ????????: ron minnich; Hendricks David W.; LinuxBIOS
> > > ????????: Re: ????????: ????????: ????????: ????????: ????????:
flash_rom support for AMD64
> > > 
> > > On Thu, 2004-03-18 at 12:13, YhLu wrote:
> > > > Stuck after 3.
> > > > 
> > > > It seems it doesn't allow write mmio.
> > > > 
> > > > int probe_49fl004 (struct flashchip * flash)
> > > > {       
> > > >         volatile char * bios = flash->virt_addr;
> > > >         unsigned char  id1, id2;
> > > >         printf("3\n");
> > > >         *(volatile char *) (bios + 0x5555) = 0xAA;
> > > >         myusec_delay(10);      
> > > >         printf("4\n");
> > > >         *(volatile char *) (bios + 0x2AAA) = 0x55;
> > > >         myusec_delay(10);   
> > > >         printf("5\n");
> > > >         *(volatile char *) (bios + 0x5555) = 0x90;
> > > > 
> > > 
> > > 
> > > There is some arithmeatic error in old flash_rom, please
> > > cvs update.
> > > 
> > > 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 ollie at lanl.gov  Thu Mar 18 16:04:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 18 16:04:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= =?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= =?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= =?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= flash_rom support for AMD64 [PMX:#]
In-Reply-To: <3174569B9743D511922F00A0C94314230466D4F2@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D4F2@TYANWEB>
Message-ID: <1079645213.25319.29.camel@exponential.lanl.gov>

On Thu, 2004-03-18 at 14:28, YhLu wrote:
> Can you try by block instead of sector?
> 

It is highly possible that our flash part is too old.
We jsut tried to flash a 080 part with exactly the same
040 driver without any error.

Ollie



From dwh at lanl.gov  Thu Mar 18 16:06:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 18 16:06:01 2004
Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiDnrZTlpI06?=
 =?utf-8?B?IOetlOWkjTog562U5aSNOiDnrZTlpI06IGZsYXNoX3JvbSBzdXBwb3J0IGZv?=
 =?utf-8?B?ciBBTUQ2NCBbUE1YOiNd?=
In-Reply-To: <3174569B9743D511922F00A0C94314230466D4F2@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403181426010.25934-100000@ccs-mail.lanl.gov>

Something very strange just happened. Ollie and I tried using a 
SST49LF080A and it worked perfectly. The specifications on this part and 
the 49LF040 are exactly the same except for the device ID.

Perhaps there's a bug in the 49LF040? We do not have any 49LF040A parts in 
our lab at the moment that we can test with.

On Thu, 18 Mar 2004, YhLu wrote:

> Can you try by block instead of sector?
> 
> YH
> 
> -----????????????-----
> ?????????: Hendricks David W. [mailto:dwh at lanl.gov] 
> ????????????: 2004???3???18??? 13:16
> ?????????: YhLu
> ??????: Li-Ta Lo; ron minnich; LinuxBIOS
> ??????: Re: ????????: ????????: ????????: ????????: ????????: ????????: ????????: flash_rom support for
> AMD64 [PMX:#]
> 
> I should clarify that statement. The SST49LF040 part will flash with 
> errors under 64-bit SuSE resulting in an unusable part. The PM part will 
> flash properly in both 32-bit and 64-bit environments.
> 
> On Thu, 18 Mar 2004, Hendricks David W. wrote:
> 
> > Yes. The SST part will flash under 32-bit Gentoo, but not 64-bit SuSE. 
> > 
> > The PM part will flash using either 32-bit or 64-bit environments. 
> > 
> > On Thu, 18 Mar 2004, YhLu wrote:
> > 
> > > Does it work in 32 bit?
> > > 
> > > -----?????????????????????????-----
> > > ???????????????????: Hendricks David W. [mailto:dwh at lanl.gov] 
> > > ????????????????????????????: 2004??????3??????18??????? 13:06
> > > ???????????????????: YhLu
> > > ??????????????: Li-Ta Lo; ron minnich; LinuxBIOS
> > > ????????????: Re: ????????????????: ????????????????: ????????????????: ????????????????: ????????????????: ????????????????:
> flash_rom support for AMD64
> > > 
> > > I have verified this.
> > > 
> > > The SST part still won't flash under 64-bit SuSE, however.
> > > 
> > > On Thu, 18 Mar 2004, YhLu wrote:
> > > 
> > > > It works with pm49lf004 under 64 bit.
> > > > 
> > > > -----??????????????????????????????????-----
> > > > ?????????????????????????: Li-Ta Lo [mailto:ollie at lanl.gov] 
> > > > ?????????????????????????????????: 2004?????????3??????????18????????? 11:50
> > > > ??????????????????????????: YhLu
> > > > ?????????????????: ron minnich; Hendricks David W.; LinuxBIOS
> > > > ?????????????????: Re: ????????????????: ????????????????: ????????????????: ????????????????: ????????????????:
> flash_rom support for AMD64
> > > > 
> > > > On Thu, 2004-03-18 at 12:13, YhLu wrote:
> > > > > Stuck after 3.
> > > > > 
> > > > > It seems it doesn't allow write mmio.
> > > > > 
> > > > > int probe_49fl004 (struct flashchip * flash)
> > > > > {       
> > > > >         volatile char * bios = flash->virt_addr;
> > > > >         unsigned char  id1, id2;
> > > > >         printf("3\n");
> > > > >         *(volatile char *) (bios + 0x5555) = 0xAA;
> > > > >         myusec_delay(10);      
> > > > >         printf("4\n");
> > > > >         *(volatile char *) (bios + 0x2AAA) = 0x55;
> > > > >         myusec_delay(10);   
> > > > >         printf("5\n");
> > > > >         *(volatile char *) (bios + 0x5555) = 0x90;
> > > > > 
> > > > 
> > > > 
> > > > There is some arithmeatic error in old flash_rom, please
> > > > cvs update.
> > > > 
> > > > 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 dwh at lanl.gov  Thu Mar 18 16:09:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 18 16:09:01 2004
Subject: SST49LF008A-WH
In-Reply-To: <001501c40ceb$a75d1640$6e3fa8c0@eazix.com>
Message-ID: <Pine.LNX.4.44.0403181429540.587-100000@ccs-mail.lanl.gov>

Good news, the SST49LF080A has now been tested and works with flash_rom. 
The changes will be committed shortly. 

On Thu, 18 Mar 2004, Victor Berdin wrote:

> Hi,
> 
> I checked the device list section but failed to find the
> mentioned chip. The closest one however is an
> SST49LF004. I would like to know if I can use Linux
> BIOS project in order to replace the original BIOSware?
> And if so, where can I start?
> 
> My target board is an AMD GX2 Geode (NatSemi)
> SBC. `lspci -v` results are listed below. Any help/advice
> are greately appreciated.
> 
> P.S., I really don't mind trashing this company hardware
> ;o) ... but it's best if I can make Linux work wonders on
> this device without killing innocent transistors.
> 
> TIA and best regards - Vic
> 
> 
> ------------------
> 00:01.0 Host bridge: National Semiconductor Corporation: Unknown device 0028
> (rev 21)
> Subsystem: National Semiconductor Corporation: Unknown device 0028
> Flags: bus master, 66Mhz, medium devsel, latency 248
> I/O ports at ac1c [size=4]
> 00:01.1 VGA compatible controller: National Semiconductor Corporation:
> Unknown device 0030 (prog-if 00 [VGA])
> Subsystem: National Semiconductor Corporation: Unknown device 0030
> Flags: 66Mhz, medium devsel
> Memory at 41000000 (32-bit, non-prefetchable) [size=16M]
> Memory at 40ffc000 (32-bit, non-prefetchable) [size=16K]
> Memory at 40ff8000 (32-bit, non-prefetchable) [size=16K]
> Memory at 40ff4000 (32-bit, non-prefetchable) [size=16K]
> 00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C
> (rev 10)
> Subsystem: Realtek Semiconductor Co., Ltd. RT8139
> Flags: bus master, medium devsel, latency 64, IRQ 11
> I/O ports at ee00 [size=256]
> Memory at efffdf00 (32-bit, non-prefetchable) [size=256]
> Capabilities: [50] Power Management version 2
> 00:0f.0 ISA bridge: National Semiconductor Corporation: Unknown device 002b
> (rev 13)
> Subsystem: National Semiconductor Corporation: Unknown device 002b
> Flags: 66Mhz, medium devsel
> I/O ports at 6000 [size=8]
> I/O ports at 6100 [size=256]
> I/O ports at 6200 [size=64]
> I/O ports at 1000 [size=32]
> I/O ports at 9d00 [size=128]
> I/O ports at 9c00 [size=64]
> 00:0f.2 IDE interface: National Semiconductor Corporation: Unknown device
> 002d (prog-if 80 [Master])
> Subsystem: National Semiconductor Corporation: Unknown device 002d
> Flags: bus master, 66Mhz, medium devsel, latency 0
> I/O ports at eff0 [size=16]
> 00:0f.3 Multimedia audio controller: National Semiconductor Corporation:
> Unknown device 002e
> Subsystem: National Semiconductor Corporation: Unknown device 002e
> Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11
> I/O ports at ed80 [size=128]
> 00:0f.4 USB Controller: National Semiconductor Corporation: Unknown device
> 002f (rev 06) (prog-if 10 [OHCI])
> Subsystem: National Semiconductor Corporation: Unknown device 002f
> Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11
> Memory at effff000 (32-bit, non-prefetchable) [size=4K]
> 00:0f.5 USB Controller: National Semiconductor Corporation: Unknown device
> 002f (rev 06) (prog-if 10 [OHCI])
> Subsystem: National Semiconductor Corporation: Unknown device 002f
> Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 10
> Memory at efffe000 (32-bit, non-prefetchable) [size=4K]
> ---------------
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From ollie at lanl.gov  Thu Mar 18 16:21:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 18 16:21:01 2004
Subject: SST49LF008A-WH
In-Reply-To: <Pine.LNX.4.44.0403181429540.587-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0403181429540.587-100000@ccs-mail.lanl.gov>
Message-ID: <1079646250.25319.35.camel@exponential.lanl.gov>

On Thu, 2004-03-18 at 14:31, Hendricks David W. wrote:
> Good news, the SST49LF080A has now been tested and works with flash_rom. 
> The changes will be committed shortly. 
> 

David,

He was asking about 008 no 080. But it is no big deal, you can add all
these flash parts with these ids by reuse the driver for 040.

SST49LF002A 0001H 57H
SST49LF003A 0001H 1BH
SST49LF004A 0001H 60H
SST49LF008A 0001H 5AH

Ollie

> On Thu, 18 Mar 2004, Victor Berdin wrote:
> 
> > Hi,
> > 
> > I checked the device list section but failed to find the
> > mentioned chip. The closest one however is an
> > SST49LF004. I would like to know if I can use Linux
> > BIOS project in order to replace the original BIOSware?
> > And if so, where can I start?
> > 
> > My target board is an AMD GX2 Geode (NatSemi)
> > SBC. `lspci -v` results are listed below. Any help/advice
> > are greately appreciated.
> > 
> > P.S., I really don't mind trashing this company hardware
> > ;o) ... but it's best if I can make Linux work wonders on
> > this device without killing innocent transistors.
> > 
> > TIA and best regards - Vic
> > 
> > 
> > ------------------
> > 00:01.0 Host bridge: National Semiconductor Corporation: Unknown device 0028
> > (rev 21)
> > Subsystem: National Semiconductor Corporation: Unknown device 0028
> > Flags: bus master, 66Mhz, medium devsel, latency 248
> > I/O ports at ac1c [size=4]
> > 00:01.1 VGA compatible controller: National Semiconductor Corporation:
> > Unknown device 0030 (prog-if 00 [VGA])
> > Subsystem: National Semiconductor Corporation: Unknown device 0030
> > Flags: 66Mhz, medium devsel
> > Memory at 41000000 (32-bit, non-prefetchable) [size=16M]
> > Memory at 40ffc000 (32-bit, non-prefetchable) [size=16K]
> > Memory at 40ff8000 (32-bit, non-prefetchable) [size=16K]
> > Memory at 40ff4000 (32-bit, non-prefetchable) [size=16K]
> > 00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C
> > (rev 10)
> > Subsystem: Realtek Semiconductor Co., Ltd. RT8139
> > Flags: bus master, medium devsel, latency 64, IRQ 11
> > I/O ports at ee00 [size=256]
> > Memory at efffdf00 (32-bit, non-prefetchable) [size=256]
> > Capabilities: [50] Power Management version 2
> > 00:0f.0 ISA bridge: National Semiconductor Corporation: Unknown device 002b
> > (rev 13)
> > Subsystem: National Semiconductor Corporation: Unknown device 002b
> > Flags: 66Mhz, medium devsel
> > I/O ports at 6000 [size=8]
> > I/O ports at 6100 [size=256]
> > I/O ports at 6200 [size=64]
> > I/O ports at 1000 [size=32]
> > I/O ports at 9d00 [size=128]
> > I/O ports at 9c00 [size=64]
> > 00:0f.2 IDE interface: National Semiconductor Corporation: Unknown device
> > 002d (prog-if 80 [Master])
> > Subsystem: National Semiconductor Corporation: Unknown device 002d
> > Flags: bus master, 66Mhz, medium devsel, latency 0
> > I/O ports at eff0 [size=16]
> > 00:0f.3 Multimedia audio controller: National Semiconductor Corporation:
> > Unknown device 002e
> > Subsystem: National Semiconductor Corporation: Unknown device 002e
> > Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11
> > I/O ports at ed80 [size=128]
> > 00:0f.4 USB Controller: National Semiconductor Corporation: Unknown device
> > 002f (rev 06) (prog-if 10 [OHCI])
> > Subsystem: National Semiconductor Corporation: Unknown device 002f
> > Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11
> > Memory at effff000 (32-bit, non-prefetchable) [size=4K]
> > 00:0f.5 USB Controller: National Semiconductor Corporation: Unknown device
> > 002f (rev 06) (prog-if 10 [OHCI])
> > Subsystem: National Semiconductor Corporation: Unknown device 002f
> > Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 10
> > Memory at efffe000 (32-bit, non-prefetchable) [size=4K]
> > ---------------
> > 
> > _______________________________________________
> > 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 dwh at lanl.gov  Thu Mar 18 16:42:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 18 16:42:00 2004
Subject: SST49LF008A-WH
In-Reply-To: <1079646250.25319.35.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403181503290.1262-100000@ccs-mail.lanl.gov>

Good point. Committed :)

On Thu, 18 Mar 2004, Li-Ta Lo wrote:

> On Thu, 2004-03-18 at 14:31, Hendricks David W. wrote:
> > Good news, the SST49LF080A has now been tested and works with flash_rom. 
> > The changes will be committed shortly. 
> > 
> 
> David,
> 
> He was asking about 008 no 080. But it is no big deal, you can add all
> these flash parts with these ids by reuse the driver for 040.
> 
> SST49LF002A 0001H 57H
> SST49LF003A 0001H 1BH
> SST49LF004A 0001H 60H
> SST49LF008A 0001H 5AH
> 
> Ollie
> 
> > On Thu, 18 Mar 2004, Victor Berdin wrote:
> > 
> > > Hi,
> > > 
> > > I checked the device list section but failed to find the
> > > mentioned chip. The closest one however is an
> > > SST49LF004. I would like to know if I can use Linux
> > > BIOS project in order to replace the original BIOSware?
> > > And if so, where can I start?
> > > 
> > > My target board is an AMD GX2 Geode (NatSemi)
> > > SBC. `lspci -v` results are listed below. Any help/advice
> > > are greately appreciated.
> > > 
> > > P.S., I really don't mind trashing this company hardware
> > > ;o) ... but it's best if I can make Linux work wonders on
> > > this device without killing innocent transistors.
> > > 
> > > TIA and best regards - Vic
> > > 
> > > 
> > > ------------------
> > > 00:01.0 Host bridge: National Semiconductor Corporation: Unknown device 0028
> > > (rev 21)
> > > Subsystem: National Semiconductor Corporation: Unknown device 0028
> > > Flags: bus master, 66Mhz, medium devsel, latency 248
> > > I/O ports at ac1c [size=4]
> > > 00:01.1 VGA compatible controller: National Semiconductor Corporation:
> > > Unknown device 0030 (prog-if 00 [VGA])
> > > Subsystem: National Semiconductor Corporation: Unknown device 0030
> > > Flags: 66Mhz, medium devsel
> > > Memory at 41000000 (32-bit, non-prefetchable) [size=16M]
> > > Memory at 40ffc000 (32-bit, non-prefetchable) [size=16K]
> > > Memory at 40ff8000 (32-bit, non-prefetchable) [size=16K]
> > > Memory at 40ff4000 (32-bit, non-prefetchable) [size=16K]
> > > 00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C
> > > (rev 10)
> > > Subsystem: Realtek Semiconductor Co., Ltd. RT8139
> > > Flags: bus master, medium devsel, latency 64, IRQ 11
> > > I/O ports at ee00 [size=256]
> > > Memory at efffdf00 (32-bit, non-prefetchable) [size=256]
> > > Capabilities: [50] Power Management version 2
> > > 00:0f.0 ISA bridge: National Semiconductor Corporation: Unknown device 002b
> > > (rev 13)
> > > Subsystem: National Semiconductor Corporation: Unknown device 002b
> > > Flags: 66Mhz, medium devsel
> > > I/O ports at 6000 [size=8]
> > > I/O ports at 6100 [size=256]
> > > I/O ports at 6200 [size=64]
> > > I/O ports at 1000 [size=32]
> > > I/O ports at 9d00 [size=128]
> > > I/O ports at 9c00 [size=64]
> > > 00:0f.2 IDE interface: National Semiconductor Corporation: Unknown device
> > > 002d (prog-if 80 [Master])
> > > Subsystem: National Semiconductor Corporation: Unknown device 002d
> > > Flags: bus master, 66Mhz, medium devsel, latency 0
> > > I/O ports at eff0 [size=16]
> > > 00:0f.3 Multimedia audio controller: National Semiconductor Corporation:
> > > Unknown device 002e
> > > Subsystem: National Semiconductor Corporation: Unknown device 002e
> > > Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11
> > > I/O ports at ed80 [size=128]
> > > 00:0f.4 USB Controller: National Semiconductor Corporation: Unknown device
> > > 002f (rev 06) (prog-if 10 [OHCI])
> > > Subsystem: National Semiconductor Corporation: Unknown device 002f
> > > Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11
> > > Memory at effff000 (32-bit, non-prefetchable) [size=4K]
> > > 00:0f.5 USB Controller: National Semiconductor Corporation: Unknown device
> > > 002f (rev 06) (prog-if 10 [OHCI])
> > > Subsystem: National Semiconductor Corporation: Unknown device 002f
> > > Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 10
> > > Memory at efffe000 (32-bit, non-prefetchable) [size=4K]
> > > ---------------
> > > 
> > > _______________________________________________
> > > 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 dwh at lanl.gov  Thu Mar 18 19:01:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Mar 18 19:01:00 2004
Subject: AMD K8 memory bug with more than 2 banks
In-Reply-To: <001e01c40ba3$cd150c60$6400a8c0@opusone>
Message-ID: <Pine.LNX.4.44.0403181706070.2693-100000@ccs-mail.lanl.gov>

I have applied your fix and booted it up on a Tyan S2885 mainboard with 
four banks full, but have not noticed any change in non-reserved 
registers on the AMD 8111. Can you please elaborate on exactly what 
changes I might observe? I want to check out the specifications on the 
memory we're using and make sure we're getting the right values.

On Tue, 16 Mar 2004, Craig C Forney wrote:

> 
> I ran into a problem with a Dual Opeteron cPCI board we developed with 4
> banks of memory.  It showed up when the third and fourth banks were
> populated.  I narrowed it down to a problem in src/amd/amdk8/raminit.c.
> There is a '+' where there should be a '*', causing the SPD settings to
> get corrupted, which causes bizarre results which varies depending on
> the memory parameters read from the DIMMs.  One possible result is that
> some DIMMs will work marginally because one or more of their settings
> has been corrupted.
> 
> This patch seems to resolve the problem.  I'm not sure if anybody else
> out there is accessing 4 banks of memory via the Opteron memory
> interface, so it might be just us, but it would probably be a good idea
> to commit this patch to the freebios2 source tree.  Can someone take
> this on?
> 
> Thanks,
> 
> Craig Forney
> Opus Innovations LLC
> 
> diff -Naur raminit.c.orig raminit.c
> --- raminit.c.orig	2004-03-16 13:25:05.000000000 -0800
> +++ raminit.c	2004-03-16 13:42:30.000000000 -0800
> @@ -924,7 +924,7 @@
>  		sz.side2 = 0;
>  	}
>  	map = pci_read_config32(ctrl->f2, DRAM_BANK_ADDR_MAP);
> -	map &= ~(0xf << (index + 4));
> +	map &= ~(0xf << (index * 4));
>  
>  	/* For each base register.
>  	 * Place the dimm size in 32 MB quantities in the bits 31 - 21.
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From YhLu at tyan.com  Thu Mar 18 19:53:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 18 19:53:01 2004
Subject: =?gb2312?B?tPC4tDogQU1EIEs4IG1lbW9yeSBidWcgd2l0aCBtb3JlIHRoYW4g?=
	=?gb2312?B?MiBiYW5rcw==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D553@TYANWEB>

According to data sheet, should do the change.

-----????-----
???: Hendricks David W. [mailto:dwh at lanl.gov] 
????: 2004?3?18? 16:23
???: Craig C Forney
??: linuxbios at clustermatic.org
??: Re: AMD K8 memory bug with more than 2 banks

I have applied your fix and booted it up on a Tyan S2885 mainboard with 
four banks full, but have not noticed any change in non-reserved 
registers on the AMD 8111. Can you please elaborate on exactly what 
changes I might observe? I want to check out the specifications on the 
memory we're using and make sure we're getting the right values.

On Tue, 16 Mar 2004, Craig C Forney wrote:

> 
> I ran into a problem with a Dual Opeteron cPCI board we developed with 4
> banks of memory.  It showed up when the third and fourth banks were
> populated.  I narrowed it down to a problem in src/amd/amdk8/raminit.c.
> There is a '+' where there should be a '*', causing the SPD settings to
> get corrupted, which causes bizarre results which varies depending on
> the memory parameters read from the DIMMs.  One possible result is that
> some DIMMs will work marginally because one or more of their settings
> has been corrupted.
> 
> This patch seems to resolve the problem.  I'm not sure if anybody else
> out there is accessing 4 banks of memory via the Opteron memory
> interface, so it might be just us, but it would probably be a good idea
> to commit this patch to the freebios2 source tree.  Can someone take
> this on?
> 
> Thanks,
> 
> Craig Forney
> Opus Innovations LLC
> 
> diff -Naur raminit.c.orig raminit.c
> --- raminit.c.orig	2004-03-16 13:25:05.000000000 -0800
> +++ raminit.c	2004-03-16 13:42:30.000000000 -0800
> @@ -924,7 +924,7 @@
>  		sz.side2 = 0;
>  	}
>  	map = pci_read_config32(ctrl->f2, DRAM_BANK_ADDR_MAP);
> -	map &= ~(0xf << (index + 4));
> +	map &= ~(0xf << (index * 4));
>  
>  	/* For each base register.
>  	 * Place the dimm size in 32 MB quantities in the bits 31 - 21.
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

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


From rminnich at lanl.gov  Thu Mar 18 20:00:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 18 20:00:00 2004
Subject: =?gb2312?B?tPC4tDogQU1EIEs4IG1lbW9yeSBidWcgd2l0aCBtb3JlIHRoYW4g?=
 =?gb2312?B?MiBiYW5rcw==?=
In-Reply-To: <3174569B9743D511922F00A0C94314230466D553@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403181821590.7734-100000@maxroach.lanl.gov>

On Thu, 18 Mar 2004, YhLu wrote:

> According to data sheet, should do the change.

David, if Craig verifies this change works and it appears to cause no harm 
I think you can commit it.

ron



From ebiederman at lnxi.com  Thu Mar 18 21:57:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Mar 18 21:57:01 2004
Subject: AMD K8 memory bug with more than 2 banks
In-Reply-To: <Pine.LNX.4.44.0403181706070.2693-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0403181706070.2693-100000@ccs-mail.lanl.gov>
Message-ID: <m3y8pxjz1x.fsf@maxwell.lnxi.com>

"Hendricks David W." <dwh at lanl.gov> writes:

> I have applied your fix and booted it up on a Tyan S2885 mainboard with 
> four banks full, but have not noticed any change in non-reserved 
> registers on the AMD 8111. Can you please elaborate on exactly what 
> changes I might observe? I want to check out the specifications on the 
> memory we're using and make sure we're getting the right values.

The fix is correct.    And it was a good catch.  My apologies
for the delay in communicating.

That line is one half of a read/modify write cycle and all it does
is to clear the old value out of the register.  The per
DIMM value is 4 bits long, which is the reason for multiplying by 4.


The index values will be 0,1,2,3....

Eric



From stepan at suse.de  Fri Mar 19 06:17:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Fri Mar 19 06:17:01 2004
Subject: Unions?
Message-ID: <20040319114025.GA32766@suse.de>

./romcc -mcpu=k8 -O2 ./auto.E > auto.inc
path.h:31.13: 
unions not yet supported

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Fri Mar 19 09:16:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Fri Mar 19 09:16:01 2004
Subject: Status AMD64 ram init
Message-ID: <20040319143848.GA6187@suse.de>

Excerpt from current solo build:

LinuxBIOS-1.1.6.0-Fallback Fr M?r 19 14:43:18 CET 2004 starting...              
setting up resource map....done.                                                
ht reset -                                                                      
                                                                                
LinuxBIOS-1.1.6.0-Fallback Fr M?r 19 14:43:18 CET 2004 starting...              
setting up resource map....done.                                                
Ram1.00                                                                         
Ram2.00                                                                         
Bad SPD value                                                                   

Using the default hynix PC2100U 256MB DDR 266MHz CL2.5 modules.
I'm building a debug image which dumps the spd roms...

Stefan
  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Fri Mar 19 10:27:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Fri Mar 19 10:27:01 2004
Subject: Status AMD64 ram init
In-Reply-To: <20040319143848.GA6187@suse.de>
References: <20040319143848.GA6187@suse.de>
Message-ID: <20040319155030.GB18123@suse.de>

* Stefan Reinauer <stepan at suse.de> [040319 15:38]:
> Ram1.00
> Ram2.00
> Bad SPD value

        low = spd_read_byte(device, 6); /* (low byte) */
        if (low < 0) goto hw_err;
        value = value | (low & 0xff);
        if ((value != 72) && (value &= 64)) goto val_err;
                              ^^^^^^^^^^^
It seems this should be value != 64 as well?
  
Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Fri Mar 19 10:50:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Fri Mar 19 10:50:00 2004
Subject: Status AMD64 ram init [resolved]
In-Reply-To: <20040319155030.GB18123@suse.de>
References: <20040319143848.GA6187@suse.de> <20040319155030.GB18123@suse.de>
Message-ID: <20040319161322.GA25641@suse.de>

* Stefan Reinauer <stepan at suse.de> [040319 16:50]:
>         low = spd_read_byte(device, 6); /* (low byte) */
>         if (low < 0) goto hw_err;
>         value = value | (low & 0xff);
>         if ((value != 72) && (value &= 64)) goto val_err;
>                               ^^^^^^^^^^^
> It seems this should be value != 64 as well?
  
works and commited.

Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From frannk_m1 at yahoo.com  Fri Mar 19 17:37:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Fri Mar 19 17:37:00 2004
Subject: code flow
Message-ID: <20040319230008.90707.qmail@web13811.mail.yahoo.com>

Is there a document that describes the code flow for freebios.
Specifically, I'm trying to figure out the booting process. I've
configured and compiled the code for the sis550 but I don't see
how the LPC is being configured. The only way I can get the
ipl.S to be assembled is to define the docipl  rule in the
config file. I need to use the LPC bridge for a custom board I
will eventually be porting freebios to but I still want to be
able to boot from the standard flash device. The way the
existing  code works is the only way you can compile in the ipl
stuff is to define docipl. I will also need to access the LPC
bridge to do I2C when reading the spd on the sodimm module. Can
anyone suggest how i can include the ipl stuff without the
docipl stuff. Another eason I don't want to use the docipl stuff
is because the python scripts changes the rom base address to
0x80000. I want the rom base address to be 0xf0000.
Any help will greatly appreciated...

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com


From celina.miranda at eazix.com  Sat Mar 20 04:15:01 2004
From: celina.miranda at eazix.com (Ina Miranda)
Date: Sat Mar 20 04:15:01 2004
Subject: Geode gx2
Message-ID: <A685AADAD189DF48B9A09B734A0A508B40A97E@eazix-win2ks0.eazix.com>

Hi, 
 
I?d just like to ask if LinuxBIOS is compatible with Geode GX2 chipset.
 
Thanks,
Ina

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.567 / Virus Database: 358 - Release Date: 1/24/2004
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040320/2a05e38d/attachment.html>

From rminnich at lanl.gov  Sat Mar 20 09:14:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sat Mar 20 09:14:01 2004
Subject: Geode gx2
In-Reply-To: <A685AADAD189DF48B9A09B734A0A508B40A97E@eazix-win2ks0.eazix.com>
Message-ID: <Pine.LNX.4.44.0403200737000.29591-100000@maxroach.lanl.gov>

On Sat, 20 Mar 2004, Ina Miranda wrote:

> I?d just like to ask if LinuxBIOS is compatible with Geode GX2 chipset.

we don't know yet. Anyone who wants to look is welcome.

ron



From ebiederman at lnxi.com  Sat Mar 20 19:14:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sat Mar 20 19:14:01 2004
Subject: Status AMD64 ram init [resolved]
In-Reply-To: <20040319161322.GA25641@suse.de>
References: <20040319143848.GA6187@suse.de> <20040319155030.GB18123@suse.de>
	<20040319161322.GA25641@suse.de>
Message-ID: <m3r7vnqb78.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * Stefan Reinauer <stepan at suse.de> [040319 16:50]:
> >         low = spd_read_byte(device, 6); /* (low byte) */
> >         if (low < 0) goto hw_err;
> >         value = value | (low & 0xff);
> >         if ((value != 72) && (value &= 64)) goto val_err;
> >                               ^^^^^^^^^^^
> > It seems this should be value != 64 as well?
>   
> works and commited.

Thanks.  This appears to fix all of Eric's typo's week :)

Eric


From christer at weinigel.se  Sun Mar 21 13:37:01 2004
From: christer at weinigel.se (Christer Weinigel)
Date: Sun Mar 21 13:37:01 2004
Subject: Geode gx2
In-Reply-To: <A685AADAD189DF48B9A09B734A0A508B40A97E@eazix-win2ks0.eazix.com>
References: <A685AADAD189DF48B9A09B734A0A508B40A97E@eazix-win2ks0.eazix.com>
Message-ID: <m3fzc2rpou.fsf@zoo.weinigel.se>

"Ina Miranda" <celina.miranda at eazix.com> writes:

> Hi, 
>  
> I?d just like to ask if LinuxBIOS is compatible with Geode GX2 chipset.

As far as I know there is no LinuxBIOS port to the GX2.  I did browse
the preliminary GX2 data sheets last winter and it seems that enough
documentation is publically available to do a LinuxBIOS port to the
processor.  There are major changes between the GX1 and GX2 though, so
it would be a completely new port of LinuxBIOS, I don't think there's
much of the GX1 port that can be reused.

  /Christer (mostly hacking RedBoot on PPC and Cris right now)

-- 
"Just how much can I get away with and still go to heaven?"

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel <christer at weinigel.se>  http://www.weinigel.se


From rminnich at lanl.gov  Mon Mar 22 00:01:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 22 00:01:01 2004
Subject: code flow
In-Reply-To: <20040319230008.90707.qmail@web13811.mail.yahoo.com>
Message-ID: <Pine.LNX.4.44.0403212224150.25069-100000@maxroach.lanl.gov>

let's start at the start.

Do you want to boot from DoC or not? do you plan to use DoC at all?

I got confused by your letter.

ron



From stepan at suse.de  Mon Mar 22 10:03:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Mar 22 10:03:00 2004
Subject: AMD64+FILO -> Detected floating bus
Message-ID: <20040322152659.GA6777@suse.de>

Hi,

with LinuxBIOS 1.1.6 and Filo 0.4.1 I am getting a floating IDE bus
on the Solo machines now. This has worked before with older versions,
but I am not sure what might cause this breakage..

Any ideas?

Best regards,
  Stefan Reinauer
  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Mon Mar 22 11:37:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Mar 22 11:37:00 2004
Subject: unreliably booting off a BCM5701.
Message-ID: <20040322170110.GA6915@suse.de>

Hi,

1.1.6 seems really picky when using etherboot for network booting.
The link seems very often to go up and down at will, before a real 
boot happens. See attached log. 

Any idea?

  Regards,
    Stefan

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

LinuxBIOS-1.1.6.0-Fallback Mo M?r 22 17:42:39 CET 2004 starting...
setting up resource map....done.
ht reset -

LinuxBIOS-1.1.6.0-Fallback Mo M?r 22 17:42:39 CET 2004 starting...
setting up resource map....done.
Initializing memory:  done
Clearing LinuxBIOS memory:  done
Testing DRAM : 00000000-00100000
DRAM fill: 00000000-00100000
00100000
DRAM filled
DRAM verify: 00000000-00100000
00100000
DRAM verified
Done.
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
Jumping to LinuxBIOS.
ROM segment 0xb7fa length 0xff3e reloc 0x00020000
CPU 1650 Mhz
Etherboot 5.3.6 (GPL) http://etherboot.org Tagged ELF for [TG3][IDE]
Relocating _text from: [000264e0,00058510) to [1fecdfd0,1ff00000)
Boot from (N)etwork or (Q)uit? ^TProbing pci nic...
[tg3-5701]Ethernet addr: 00:04:76:E0:11:99
Tigon3 [partno(3C996B-T) rev 0105 PHY(5701)] (PCI:33MHz:32-bit)
Link is up at 1000 Mbps, full duplex. TX RX flow control
Searching for server (DHCP)...
.Link is down.
Link is up at 1000 Mbps, full duplex. TX RX flow control
Link is down.
Link is up at 1000 Mbps, full duplex. TX RX flow control
Link is down.
Link is up at 1000 Mbps, full duplex. TX RX flow control
.Link is down.

[..]

Link is up at 1000 Mbps, full duplex. TX RX flow control
..Me: 192.168.0.2, Server: 192.168.0.1
Loading 192.168.0.1:kernel.elf ...(ELF)... ...........  [..] ......done
Firmware type: LinuxBIOS




-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From gwatson at lanl.gov  Mon Mar 22 11:38:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Mon Mar 22 11:38:00 2004
Subject: AMD64+FILO -> Detected floating bus
In-Reply-To: <20040322152659.GA6777@suse.de>
References: <20040322152659.GA6777@suse.de>
Message-ID: <9FC513A8-7C22-11D8-80C6-000393A47A5C@lanl.gov>

Stefan,

Is the floating bus message coming from Filo or LinuxBIOS?

Greg

On 22/03/2004, at 8:26 AM, Stefan Reinauer wrote:

> Hi,
>
> with LinuxBIOS 1.1.6 and Filo 0.4.1 I am getting a floating IDE bus
> on the Solo machines now. This has worked before with older versions,
> but I am not sure what might cause this breakage..
>
> Any ideas?
>
> Best regards,
>   Stefan Reinauer
>
> -- 
>   Stefan Reinauer, SUSE LINUX AG
> Head of Architecture Development
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From stepan at suse.de  Mon Mar 22 11:44:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Mar 22 11:44:00 2004
Subject: AMD64+FILO -> Detected floating bus
In-Reply-To: <9FC513A8-7C22-11D8-80C6-000393A47A5C@lanl.gov>
References: <20040322152659.GA6777@suse.de> <9FC513A8-7C22-11D8-80C6-000393A47A5C@lanl.gov>
Message-ID: <20040322170435.GA7104@suse.de>

* Greg Watson <gwatson at lanl.gov> [040322 18:01]:
> Stefan,
> 
> Is the floating bus message coming from Filo or LinuxBIOS?


From rminnich at lanl.gov  Mon Mar 22 11:58:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 22 11:58:00 2004
Subject: "up", "down"
Message-ID: <Pine.LNX.4.44.0403221020520.29318-100000@maxroach.lanl.gov>

which bus numbers do these correspond to again? I should know this but 
don't.

thanks

ron



From stepan at suse.de  Mon Mar 22 12:06:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Mar 22 12:06:01 2004
Subject: "up", "down"
In-Reply-To: <Pine.LNX.4.44.0403221020520.29318-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403221020520.29318-100000@maxroach.lanl.gov>
Message-ID: <20040322172902.GA8839@suse.de>

* ron minnich <rminnich at lanl.gov> [040322 18:21]:
> 
> which bus numbers do these correspond to again? I should know this but 
> don't.
  
It refers to the Hypertransport Links, Down (LDT0), Across (LDT1), UP
(LDT2). Is that what you mean?

Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From rminnich at lanl.gov  Mon Mar 22 12:07:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 22 12:07:00 2004
Subject: "up", "down"
In-Reply-To: <20040322172902.GA8839@suse.de>
Message-ID: <Pine.LNX.4.44.0403221029260.29318-100000@maxroach.lanl.gov>

On Mon, 22 Mar 2004, Stefan Reinauer wrote:

> It refers to the Hypertransport Links, Down (LDT0), Across (LDT1), UP
> (LDT2). Is that what you mean?

yes, thanks. 

I think I picked these names, and if I did I will take the blame: they are 
hard to remember. 

Should we bite the bullet and change the names? ldt0, ldt1, ldt2?

ron



From stepan at suse.de  Mon Mar 22 12:13:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Mar 22 12:13:00 2004
Subject: "up", "down"
In-Reply-To: <Pine.LNX.4.44.0403221029260.29318-100000@maxroach.lanl.gov>
References: <20040322172902.GA8839@suse.de> <Pine.LNX.4.44.0403221029260.29318-100000@maxroach.lanl.gov>
Message-ID: <20040322173636.GA8922@suse.de>

* ron minnich <rminnich at lanl.gov> [040322 18:30]:
> > It refers to the Hypertransport Links, Down (LDT0), Across (LDT1), UP
> > (LDT2). 
> 
> I think I picked these names, and if I did I will take the blame: they are 
> hard to remember. 
 
These names are also spread across several pieces of AMD64 and
Hypertransport documentation, since it illustrates hypertransport
graphs of different wiring quite nice. Still, it's unclear from a
technical point of view.

> Should we bite the bullet and change the names? ldt0, ldt1, ldt2?

Should not be too hard, since we are not really using them heavily. I
still have some defines used in coherent_ht.c which should go away 
and replaced by something more sophisticated.

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From gwatson at lanl.gov  Mon Mar 22 12:15:01 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Mon Mar 22 12:15:01 2004
Subject: AMD64+FILO -> Detected floating bus
In-Reply-To: <20040322170435.GA7104@suse.de>
References: <20040322152659.GA6777@suse.de> <9FC513A8-7C22-11D8-80C6-000393A47A5C@lanl.gov> <20040322170435.GA7104@suse.de>
Message-ID: <B40EAD63-7C27-11D8-80C6-000393A47A5C@lanl.gov>

Good. That means it wasn't my fault :-). I updated the IDE support in 
LinuxBIOS recently, so I thought it may have been that. Looks like 
something must have changed in Filo.

Greg


On 22/03/2004, at 10:04 AM, Stefan Reinauer wrote:

> * Greg Watson <gwatson at lanl.gov> [040322 18:01]:
>> Stefan,
>>
>> Is the floating bus message coming from Filo or LinuxBIOS?
>
> From Filo. It seems that there are no devices detected on the bus.
> Strange enough, since the Maxtor harddrive was installed using
> LinuxBIOS and Filo a while ago..
>
>   Stefan
>
> -- 
>   Stefan Reinauer, SUSE LINUX AG
> Head of Architecture Development
>



From stepan at suse.de  Mon Mar 22 12:21:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Mar 22 12:21:01 2004
Subject: unreliably booting off a BCM5701.
In-Reply-To: <20040322170110.GA6915@suse.de>
References: <20040322170110.GA6915@suse.de>
Message-ID: <20040322174456.GA9378@suse.de>

* Stefan Reinauer <stepan at suse.de> [040322 18:01]:
> Link is up at 1000 Mbps, full duplex. TX RX flow control
> ..Me: 192.168.0.2, Server: 192.168.0.1
> Loading 192.168.0.1:kernel.elf ...(ELF)... ...........  [..] ......done
> Firmware type: LinuxBIOS

Also, I could not get beyound this point with a Linux 2.6.5rc1 kernel.
Linux 2.4.x boots through to userland... It looks like a kernel issue,
but could it come from mkelfImage?

Stefan

  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From rminnich at lanl.gov  Mon Mar 22 12:25:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 22 12:25:01 2004
Subject: "up", "down"
In-Reply-To: <20040322173636.GA8922@suse.de>
Message-ID: <Pine.LNX.4.44.0403221047440.29318-100000@maxroach.lanl.gov>

On Mon, 22 Mar 2004, Stefan Reinauer wrote:

> * ron minnich <rminnich at lanl.gov> [040322 18:30]:
> > > It refers to the Hypertransport Links, Down (LDT0), Across (LDT1), UP
> > > (LDT2). 
> > 
> > I think I picked these names, and if I did I will take the blame: they are 
> > hard to remember. 
>  
> These names are also spread across several pieces of AMD64 and
> Hypertransport documentation, since it illustrates hypertransport
> graphs of different wiring quite nice. Still, it's unclear from a
> technical point of view.

arg. So we can pick either one and it won't sync with different bits of 
documentation.

how about:
ldt0_down, ldt1_across, ldt2_up?

ron



From stepan at suse.de  Mon Mar 22 12:31:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Mar 22 12:31:01 2004
Subject: "up", "down"
In-Reply-To: <Pine.LNX.4.44.0403221047440.29318-100000@maxroach.lanl.gov>
References: <20040322173636.GA8922@suse.de> <Pine.LNX.4.44.0403221047440.29318-100000@maxroach.lanl.gov>
Message-ID: <20040322175439.GA9536@suse.de>

* ron minnich <rminnich at lanl.gov> [040322 18:48]:
> arg. So we can pick either one and it won't sync with different bits of 
> documentation.
> 
> how about:
> ldt0_down, ldt1_across, ldt2_up?

I think going with LDT[012] is safe. A comment in one or two algorithms
explaining down, up, across should be enough... 
I vote for ldt[012] for the names, as it will allow machines with
possibly more links without changing the names

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From rminnich at lanl.gov  Mon Mar 22 12:32:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 22 12:32:01 2004
Subject: "up", "down"
In-Reply-To: <20040322175439.GA9536@suse.de>
Message-ID: <Pine.LNX.4.44.0403221055230.29318-100000@maxroach.lanl.gov>

On Mon, 22 Mar 2004, Stefan Reinauer wrote:

> * ron minnich <rminnich at lanl.gov> [040322 18:48]:
> > arg. So we can pick either one and it won't sync with different bits of 
> > documentation.
> > 
> > how about:
> > ldt0_down, ldt1_across, ldt2_up?
> 
> I think going with LDT[012] is safe. A comment in one or two algorithms
> explaining down, up, across should be enough... 
> I vote for ldt[012] for the names, as it will allow machines with
> possibly more links without changing the names

OK we'll try to cut this in soon. Or if you want to go for it that's fine 
too.

ron



From ollie at lanl.gov  Mon Mar 22 12:37:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Mar 22 12:37:00 2004
Subject: "up", "down"
In-Reply-To: <20040322173636.GA8922@suse.de>
References: <20040322172902.GA8839@suse.de>
	 <Pine.LNX.4.44.0403221029260.29318-100000@maxroach.lanl.gov>
	 <20040322173636.GA8922@suse.de>
Message-ID: <1079978432.25319.76.camel@exponential.lanl.gov>

On Mon, 2004-03-22 at 10:36, Stefan Reinauer wrote:
> * ron minnich <rminnich at lanl.gov> [040322 18:30]:
> > > It refers to the Hypertransport Links, Down (LDT0), Across (LDT1), UP
> > > (LDT2). 
> > 
> > I think I picked these names, and if I did I will take the blame: they are 
> > hard to remember. 
>  
> These names are also spread across several pieces of AMD64 and
> Hypertransport documentation, since it illustrates hypertransport
> graphs of different wiring quite nice. Still, it's unclear from a
> technical point of view.
> 
> > Should we bite the bullet and change the names? ldt0, ldt1, ldt2?
> 
> Should not be too hard, since we are not really using them heavily. I
> still have some defines used in coherent_ht.c which should go away 
> and replaced by something more sophisticated.
> 

>From my understanding of the AMD docs, the mapping between LDT0-2 to
up, down, across is not that simple and static. "Up" can be either
LTD0 or LDT1 or LDT2 so as for "down" and "across".

The terminology 'link' is heavily and badly overloaded in LinuxBIOS,
we have link for HT links and link for how many branches a device
has (bridges have two 'links'), and there are some other link I have
no idea about.

The same happens for the field name "enable" of some structures. Some
of them are verbs (enable() operation), some others are actually
adjectives (been 'enabled'). I though that I am the ONLY who can't
speak English in LinuxBIOS project.

Ollie




From YhLu at tyan.com  Mon Mar 22 12:42:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Mar 22 12:42:01 2004
Subject: =?gb2312?B?tPC4tDogdW5yZWxpYWJseSBib290aW5nIG9mZiBhIEJDTTU3MDEu?=
Message-ID: <3174569B9743D511922F00A0C94314230466D661@TYANWEB>

Stefan,

You may try to increase the heap size in config. I meet such problem in
S2882 and solved that by increasing heap size.

Regards

YH

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?22? 9:45
???: linuxbios at clustermatic.org
??: Re: unreliably booting off a BCM5701.

* Stefan Reinauer <stepan at suse.de> [040322 18:01]:
> Link is up at 1000 Mbps, full duplex. TX RX flow control
> ..Me: 192.168.0.2, Server: 192.168.0.1
> Loading 192.168.0.1:kernel.elf ...(ELF)... ...........  [..] ......done
> Firmware type: LinuxBIOS

Also, I could not get beyound this point with a Linux 2.6.5rc1 kernel.
Linux 2.4.x boots through to userland... It looks like a kernel issue,
but could it come from mkelfImage?

Stefan

  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From stepan at suse.de  Mon Mar 22 12:42:13 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Mar 22 12:42:13 2004
Subject: "up", "down"
In-Reply-To: <Pine.LNX.4.44.0403221055230.29318-100000@maxroach.lanl.gov>
References: <20040322175439.GA9536@suse.de> <Pine.LNX.4.44.0403221055230.29318-100000@maxroach.lanl.gov>
Message-ID: <20040322180608.GA9716@suse.de>

* ron minnich <rminnich at lanl.gov> [040322 18:55]:
> OK we'll try to cut this in soon. Or if you want to go for it that's fine 
> too.

Looking through the code I only find 2 occurences of the UP/DOWN/ACROSS
names:

Config.lb:
   register "up" = "{.chip = &amd8131, .ht_width=16, .ht_speed=600}"

Is this information ever being used? Otherwise I suggest we get rid of
it completely. 

The other is auto.c and coherent_ht.c:
  #define CONNECTION_0_2 UP
  #define CONNECTION_1_3 UP

Any others?


Stefan


-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Mon Mar 22 12:55:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Mar 22 12:55:01 2004
Subject: unreliably booting off a BCM5701.
In-Reply-To: <3174569B9743D511922F00A0C94314230466D661@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D661@TYANWEB>
Message-ID: <20040322181850.GA10687@suse.de>

* YhLu <YhLu at tyan.com> [040322 19:12]:
> Stefan,
> 
> You may try to increase the heap size in config. I meet such problem in
> S2882 and solved that by increasing heap size.
> 
> Regards
> YH

I've set stack size to 16k and heap size to 40k, according to what's
done on the s2885.. didn't work though.

Together with the Filo ide issues, it looks like something's wrong with
the pci devices?

   Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From YhLu at tyan.com  Mon Mar 22 12:56:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Mar 22 12:56:01 2004
Subject: =?gb2312?B?tPC4tDogdW5yZWxpYWJseSBib290aW5nIG9mZiBhIEJDTTU3MDEu?=
Message-ID: <3174569B9743D511922F00A0C94314230466D666@TYANWEB>

The bus number changes?

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?22? 10:19
???: YhLu
??: linuxbios at clustermatic.org
??: Re: unreliably booting off a BCM5701.

* YhLu <YhLu at tyan.com> [040322 19:12]:
> Stefan,
> 
> You may try to increase the heap size in config. I meet such problem in
> S2882 and solved that by increasing heap size.
> 
> Regards
> YH

I've set stack size to 16k and heap size to 40k, according to what's
done on the s2885.. didn't work though.

Together with the Filo ide issues, it looks like something's wrong with
the pci devices?

   Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From ebiederman at lnxi.com  Mon Mar 22 13:18:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar 22 13:18:00 2004
Subject: "up", "down"
In-Reply-To: <20040322180608.GA9716@suse.de>
References: <20040322175439.GA9536@suse.de>
	<Pine.LNX.4.44.0403221055230.29318-100000@maxroach.lanl.gov>
	<20040322180608.GA9716@suse.de>
Message-ID: <m3u10glnr6.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * ron minnich <rminnich at lanl.gov> [040322 18:55]:
> > OK we'll try to cut this in soon. Or if you want to go for it that's fine 
> > too.
> 
> Looking through the code I only find 2 occurences of the UP/DOWN/ACROSS
> names:
> 
> Config.lb:
>    register "up" = "{.chip = &amd8131, .ht_width=16, .ht_speed=600}"
> 
> Is this information ever being used? Otherwise I suggest we get rid of
> it completely. 

It is currently unused.  I don't think it ever has been.
 
> The other is auto.c and coherent_ht.c:
>   #define CONNECTION_0_2 UP
>   #define CONNECTION_1_3 UP
> 
> Any others?

All I know about.

Eric


From ebiederman at lnxi.com  Mon Mar 22 13:20:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar 22 13:20:01 2004
Subject: "up", "down"
In-Reply-To: <1079978432.25319.76.camel@exponential.lanl.gov>
References: <20040322172902.GA8839@suse.de>
	<Pine.LNX.4.44.0403221029260.29318-100000@maxroach.lanl.gov>
	<20040322173636.GA8922@suse.de>
	<1079978432.25319.76.camel@exponential.lanl.gov>
Message-ID: <m3ptb4lnnd.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Mon, 2004-03-22 at 10:36, Stefan Reinauer wrote:
> > * ron minnich <rminnich at lanl.gov> [040322 18:30]:
> > > > It refers to the Hypertransport Links, Down (LDT0), Across (LDT1), UP
> > > > (LDT2). 
> > > 
> > > I think I picked these names, and if I did I will take the blame: they are 
> > > hard to remember. 
> >  
> > These names are also spread across several pieces of AMD64 and
> > Hypertransport documentation, since it illustrates hypertransport
> > graphs of different wiring quite nice. Still, it's unclear from a
> > technical point of view.
> > 
> > > Should we bite the bullet and change the names? ldt0, ldt1, ldt2?
> > 
> > Should not be too hard, since we are not really using them heavily. I
> > still have some defines used in coherent_ht.c which should go away 
> > and replaced by something more sophisticated.
> > 
> 
> >From my understanding of the AMD docs, the mapping between LDT0-2 to
> up, down, across is not that simple and static. "Up" can be either
> LTD0 or LDT1 or LDT2 so as for "down" and "across".
> 
> The terminology 'link' is heavily and badly overloaded in LinuxBIOS,
> we have link for HT links and link for how many branches a device
> has (bridges have two 'links'), and there are some other link I have
> no idea about.
> 
> The same happens for the field name "enable" of some structures. Some
> of them are verbs (enable() operation), some others are actually
> adjectives (been 'enabled'). I though that I am the ONLY who can't
> speak English in LinuxBIOS project.

The challenge is the lack of good alternative names.  Suggestions
for better alternatives are welcome before we freeze the freebios2
tree.

Eric


From ebiederman at lnxi.com  Mon Mar 22 13:27:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar 22 13:27:00 2004
Subject: unreliably booting off a BCM5701.
In-Reply-To: <20040322174456.GA9378@suse.de>
References: <20040322170110.GA6915@suse.de> <20040322174456.GA9378@suse.de>
Message-ID: <m3lllslnbx.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * Stefan Reinauer <stepan at suse.de> [040322 18:01]:
> > Link is up at 1000 Mbps, full duplex. TX RX flow control
> > ..Me: 192.168.0.2, Server: 192.168.0.1
> > Loading 192.168.0.1:kernel.elf ...(ELF)... ...........  [..] ......done
> > Firmware type: LinuxBIOS
> 
> Also, I could not get beyound this point with a Linux 2.6.5rc1 kernel.
> Linux 2.4.x boots through to userland... It looks like a kernel issue,
> but could it come from mkelfImage?

Possibly.  Either that or you got hit with the changes to the
2.6.x config option changes.  I have booted a 2.6 kernel.  So unless
it is a very recent change things should still work.

Have you tried memtest86?  I am quite curious to if your memory
is working solidly.  With all of your bootloaders going haywire
I really don't know what to think.

This might be a glitch in 5.3.recent as well.  I have not looked
in detail at what is going on there.  I can't think of anything
that would cause a failure like that.

Eric


From don at bowery.com  Mon Mar 22 14:42:00 2004
From: don at bowery.com (Don Elwell)
Date: Mon Mar 22 14:42:00 2004
Subject: mkelfImage initrd help
Message-ID: <405F45D3.8040306@bowery.com>

Hello,

Not sure if this is the right place for this question but I'm not sure 
where else to send the message.

I'm having trouble booting a Linux kernel/initrd image.  My original 
goal was:

LinuxBIOS->Etherboot->Linux (single mkelfImage kernel/initrd)

In the course of troubleshooting this problem I'm working with one of 
two configurations:

Original BIOS->Etherboot via Floppy->Linux (single mkelfImage 
kernel/initrd).

and

Original BIOS->ISOLinux->Linux (separate kernel and initrd).


Booting the kernel/initrd via the CD-ROM works great.  Booting via 
Etherboot doesn't.  I get kernel panics indicating that the kernel can't 
mount its root fs.

I've modified the mkelfImage convert_params.c file to print out 
everything.  Just before the "Jumping to Linux" line, I added code to 
print out the first 512 bytes of the initrd image.  The values printed 
match perfectly with the first 512 bytes of my initrd image.  The kernel 
table values for the initrd also look good: ramdisk at 0x800000.

I also added code in the Linux kernel do_mounts.c file (just after the 
"RAMDISK: could not find valid ramdisk image") to print out the first 
512 bytes of the buf buffer.  At this point, the values in no way match 
the values in the initrd image (nor to those printed out in 
convert_params.c).

Anyone got any insight on what might be happening here or how to 
continue debugging this?

Thanks,

-don




From stepan at suse.de  Mon Mar 22 15:20:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Mar 22 15:20:00 2004
Subject: unreliably booting off a BCM5701.
In-Reply-To: <m3lllslnbx.fsf@maxwell.lnxi.com>
References: <20040322170110.GA6915@suse.de> <20040322174456.GA9378@suse.de> <m3lllslnbx.fsf@maxwell.lnxi.com>
Message-ID: <20040322204314.GA11093@suse.de>

* Eric W. Biederman <ebiederman at lnxi.com> [040322 19:59]:
> Stefan Reinauer <stepan at suse.de> writes:
> > Also, I could not get beyound this point with a Linux 2.6.5rc1 kernel.
> > Linux 2.4.x boots through to userland... It looks like a kernel issue,
> > but could it come from mkelfImage?
> 
> Possibly.  Either that or you got hit with the changes to the
> 2.6.x config option changes.  I have booted a 2.6 kernel.  So unless
> it is a very recent change things should still work.
 
I definitely have booted 2.6 kernels up to 2.6.2 under LinuxBIOS as
well. 

> Have you tried memtest86?  I am quite curious to if your memory
> is working solidly.  With all of your bootloaders going haywire
> I really don't know what to think.

No memtest yet, but filo and etherboot, and linux kernel 2.4 - When they
get loaded, they seem to work seamlessly...

> This might be a glitch in 5.3.recent as well.  I have not looked
> in detail at what is going on there.  I can't think of anything
> that would cause a failure like that.

5.3.recent?
  

  Stefan


-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From rminnich at lanl.gov  Mon Mar 22 16:36:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 22 16:36:01 2004
Subject: two changes to make building EPIA work
Message-ID: <Pine.LNX.4.44.0403221455150.29318-100000@maxroach.lanl.gov>

First, src/include/cpu/cpufixup.h is changed to follow the common
linuxbios usage.

#if CPU_FIXUP == 1 
#  if (k8==1)
#warning "====>Temporary notice that we are using k8 cpufixup"
#    define cpufixup(mem) k8_cpufixup(mem)
#  elif (k7==1)
#warning "====>Temporary notice that we are using k7 cpufixup"
#    define cpufixup(mem) k7_cpufixup(mem)
#  elif (i786==1)
#warning "====>Temporary notice that we are using i786 cpufixup"
#    define cpufixup(mem) i786_cpufixup(mem)
#  elif (i686==1)
#warning "====>Temporary notice that we are using i686 cpufixup"
#    define cpufixup(mem) p6_cpufixup(mem)
#  endif
#else
#warning "====>YOU DID NOT DEFINE ONE OF: k8, k7, i786, i686"
#  define cpufixup(mem) do {} while(0)
#endif


note that it is compare to 1, not just an #ifdef. We are leaving the 
warning in for a while to make sure people see this. In the EPIA, the 
symbol k8 even if defined to 1 would end up needing k8_cpufixup, which is 
wrong. 

Just a reminder, make your stuff testing against ==1, not ifdef.

Second, a subtle change in the config tool. 

IF: a symbol is always exported and has no default value, AND the value is 
not set by the time the config tool is generating makefile settings, then 
you will get an error, not just a warning.

One error in the EPIA build process was because the symbol 'k8' was 
defined but had no value. 

I don't think this will break anything, but you never know. Watch your K8 
builds carefully. We're hoping this fixes the latest EPIA problems.

ron



From rminnich at lanl.gov  Mon Mar 22 17:01:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 22 17:01:01 2004
Subject: All K8 builds now broken
Message-ID: <Pine.LNX.4.44.0403221523220.1622-100000@maxroach.lanl.gov>

Sorry. Greg just found that nobody nowhere was setting a few crucial 
variables, like k8. He is tracking down the missing settings. You can too 
if you wish. 

It's amazing how a simple problem has uncovered such a den of snakes, but 
that's the way it goes sometimes.

ron



From rminnich at lanl.gov  Mon Mar 22 17:46:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 22 17:46:00 2004
Subject: mkelfImage initrd help
In-Reply-To: <405F45D3.8040306@bowery.com>
Message-ID: <Pine.LNX.4.44.0403221608230.1885-100000@maxroach.lanl.gov>

On Mon, 22 Mar 2004, Don Elwell wrote:

> LinuxBIOS->Etherboot->Linux (single mkelfImage kernel/initrd)

we do this now.

> Booting the kernel/initrd via the CD-ROM works great.  Booting via 
> Etherboot doesn't.  I get kernel panics indicating that the kernel can't 
> mount its root fs.

can you send the string?

I wonder if by some chance etherboot is doing something to IDE that makes 
it work "correctly" for the kernel in the CD-ROM case.

> I also added code in the Linux kernel do_mounts.c file (just after the 
> "RAMDISK: could not find valid ramdisk image") to print out the first 
> 512 bytes of the buf buffer.  At this point, the values in no way match 
> the values in the initrd image (nor to those printed out in 
> convert_params.c).

hmm. etherboot problem? What kind of ethernet chip?

ron



From ebiederman at lnxi.com  Mon Mar 22 21:43:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar 22 21:43:01 2004
Subject: All K8 builds now broken
In-Reply-To: <Pine.LNX.4.44.0403221523220.1622-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403221523220.1622-100000@maxroach.lanl.gov>
Message-ID: <m3vfkw2r0d.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> Sorry. Greg just found that nobody nowhere was setting a few crucial 
> variables, like k8. He is tracking down the missing settings. You can too 
> if you wish. 

Would you please explain?

Is it this in the cpu part or something else?
cpu k8 "cpu0"
	register "up" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }"
end

It is a fact that we must setup the coherent HT domain before we can
read the static configuration in LinuxBIOS so setting the register
information in the configuration file is way to late to use.

> It's amazing how a simple problem has uncovered such a den of snakes, but 
> that's the way it goes sometimes.

Details please?

Eric


From frannk_m1 at yahoo.com  Mon Mar 22 21:58:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Mon Mar 22 21:58:00 2004
Subject: Resident SIS expert
Message-ID: <20040322223255.33172.qmail@web13801.mail.yahoo.com>

I'm trying to figure out how to reroute i/o amd memory space
from the pci space to the LBC Bridge. Anyone out there know
which registers to touch in the SSI550. I have the SIS register
programming but it doesn't describe which registers have to be
touched to accomplish this.

__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html


From rminnich at lanl.gov  Mon Mar 22 22:16:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 22 22:16:01 2004
Subject: All K8 builds now broken
In-Reply-To: <m3vfkw2r0d.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403222030060.3418-100000@maxroach.lanl.gov>

This all started while trying to build EPIA and finding it was now 
failing.

The problem began with the cpufixup.h code. This code did things like 
this:

#if defined(k8)
#define cpufixup() k8_cpufixup()
#elif defined(k7)

etc. 

First, this is about the only code that doesn't test a value, but instead 
tests a variable being defined. Second, in the Makefile.settings we found:
-Dk8=

OK, so k8 is defined, but has no value. the "#if define(k8)" code succeeds
as k8 is defined, and #defines cpufixup to k8_cpufixup. The Epia, which is
not a K8, fails to build as it does not have k8_cpufixup symbol defined,
which makes sense as it is not a K8.

So we changed the cpufixup.h to this:
#if (k8 == 1)
etc. 

which is much more in the way linuxbios has used defines for the last 3 
years or so (Eric, you being the person who pushed us in that direction)
:-)

So we were testing for k8 == 1, and the Makefile.settings had set k8 to 
nothing. 

Unfortunately, in gcc, if you define a variable but don't set its value, 
the preprocessor sets it to 1. So Epia builds still failed as 
#if (k8 == 1)

still succeeded.. 

So more looking. Turns out that in src/config/Options.lb, the variable k8 
is defined as
- default none
- export always

which means that even if k8 is never set, it is always exported. In other 
words, a config variable with value 'none' is exported to 
Makefile.settings, which is just plain wrong. The value should be defined 
before it is exported. 

Greg knows the full set of changes, but basically it is no longer allowed 
to export a variable whose value is 'none'. You have to set it if it gets 
exported. 

This will fix the Epia build. It may not break any other builds; Greg 
explained to me that he has things worked out and I am being too 
pessimistic. 

We'll see tomorow for our builds and we'll let you know.

ron



From rminnich at lanl.gov  Mon Mar 22 22:16:44 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Mar 22 22:16:44 2004
Subject: All K8 builds now broken
In-Reply-To: <m3vfkw2r0d.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403222039510.3418-100000@maxroach.lanl.gov>

On 22 Mar 2004, Eric W. Biederman wrote:

> Is it this in the cpu part or something else?
> cpu k8 "cpu0"
> 	register "up" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }"
> end

forgot to add, it has nothing to do with this.

ron



From gwatson at lanl.gov  Mon Mar 22 23:05:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Mon Mar 22 23:05:00 2004
Subject: two changes to make building EPIA work
In-Reply-To: <Pine.LNX.4.44.0403221455150.29318-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403221455150.29318-100000@maxroach.lanl.gov>
Message-ID: <92349A96-7C82-11D8-BA3D-000393A47A5C@lanl.gov>

Close, but no banana.

The new rules for options are as follows:

1. Options declared as 'default none' and 'export always' MUST have a 
value set or a default value assigned. Any options of this type that 
are still undefined when processing of config files is finished will 
result in a fatal error.

2. All options declared as 'export always' and those declared as 
'export used' that have a value set, or the default value altered, will 
result in an entry in Makefile.settings and ldoptions (for numeric 
values only.)

3. The appropriate way to test for a variable is '#if VAR==0' or '#if 
VAR==1'. Tests using '#ifdef VAR' or '#if defined(VAR)' may produced 
incorrect results.

So far I've checked the epia and arima configurations and they build 
ok. I'll check the others tomorrow before I commit the changes.

Regards,

Greg



On 22/03/2004, at 3:00 PM, ron minnich wrote:

>
> First, src/include/cpu/cpufixup.h is changed to follow the common
> linuxbios usage.
>
> #if CPU_FIXUP == 1
> #  if (k8==1)
> #warning "====>Temporary notice that we are using k8 cpufixup"
> #    define cpufixup(mem) k8_cpufixup(mem)
> #  elif (k7==1)
> #warning "====>Temporary notice that we are using k7 cpufixup"
> #    define cpufixup(mem) k7_cpufixup(mem)
> #  elif (i786==1)
> #warning "====>Temporary notice that we are using i786 cpufixup"
> #    define cpufixup(mem) i786_cpufixup(mem)
> #  elif (i686==1)
> #warning "====>Temporary notice that we are using i686 cpufixup"
> #    define cpufixup(mem) p6_cpufixup(mem)
> #  endif
> #else
> #warning "====>YOU DID NOT DEFINE ONE OF: k8, k7, i786, i686"
> #  define cpufixup(mem) do {} while(0)
> #endif
>
>
> note that it is compare to 1, not just an #ifdef. We are leaving the
> warning in for a while to make sure people see this. In the EPIA, the
> symbol k8 even if defined to 1 would end up needing k8_cpufixup, which 
> is
> wrong.
>
> Just a reminder, make your stuff testing against ==1, not ifdef.
>
> Second, a subtle change in the config tool.
>
> IF: a symbol is always exported and has no default value, AND the 
> value is
> not set by the time the config tool is generating makefile settings, 
> then
> you will get an error, not just a warning.
>
> One error in the EPIA build process was because the symbol 'k8' was
> defined but had no value.
>
> I don't think this will break anything, but you never know. Watch your 
> K8
> builds carefully. We're hoping this fixes the latest EPIA problems.
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From ebiederman at lnxi.com  Tue Mar 23 02:18:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Mar 23 02:18:00 2004
Subject: All K8 builds now broken
In-Reply-To: <Pine.LNX.4.44.0403222030060.3418-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403222030060.3418-100000@maxroach.lanl.gov>
Message-ID: <m3d6740zp5.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> This all started while trying to build EPIA and finding it was now 
> failing.
> 
> The problem began with the cpufixup.h code. This code did things like 
> this:
> 
> #if defined(k8)
> #define cpufixup() k8_cpufixup()
> #elif defined(k7)
> 
> etc. 

Ok I suspect that code came early on and never got cleaned up.

What this sounded like was a bug in existing code that caused things to work
incorrectly.  So at least on the Opteron things worked correctly.

We need to go in and add better cpu selection support in the code.
What I am thinking it to extract the vendor and model number for the
cpu and with that select the code to run similarly to how we handle
other devices.

Given the number of small details that need to be verified when a new
cpu comes out.  Microcode on the Xeons, memory controller enhancements
on the Opterons, etc  I would rather have the build break on a new
cpu than have everything just almost work silently.

> So we changed the cpufixup.h to this:
> #if (k8 == 1)
> etc. 
> 
> which is much more in the way linuxbios has used defines for the last 3 
> years or so (Eric, you being the person who pushed us in that direction)
> :-)

Yes.  

Eric


From gwatson at lanl.gov  Tue Mar 23 09:12:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Tue Mar 23 09:12:00 2004
Subject: All K8 builds now broken
In-Reply-To: <m3d6740zp5.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0403222030060.3418-100000@maxroach.lanl.gov> <m3d6740zp5.fsf@maxwell.lnxi.com>
Message-ID: <4F9A2750-7CD7-11D8-BA3D-000393A47A5C@lanl.gov>

On 23/03/2004, at 12:50 AM, Eric W. Biederman wrote:

> Ok I suspect that code came early on and never got cleaned up.
>
> What this sounded like was a bug in existing code that caused things 
> to work
> incorrectly.  So at least on the Opteron things worked correctly.
>
> We need to go in and add better cpu selection support in the code.
> What I am thinking it to extract the vendor and model number for the
> cpu and with that select the code to run similarly to how we handle
> other devices.
>
> Given the number of small details that need to be verified when a new
> cpu comes out.  Microcode on the Xeons, memory controller enhancements
> on the Opterons, etc  I would rather have the build break on a new
> cpu than have everything just almost work silently.
>
>>

This is probably a good idea, but note that the x86 and ppc 
architectures do things very differently. To start with ppc doesn't 
have the hierarchical arrangement that is used in x86. This leads to a 
much simpler setup, though it does duplicate some code, but in any 
event I don't want this to change. Also, the pre-C configuration is 
completely different (romcc is not used). However this is done, it will 
need to take these architectural differences into account.

Greg



From ebiederman at lnxi.com  Tue Mar 23 10:19:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Mar 23 10:19:01 2004
Subject: All K8 builds now broken
In-Reply-To: <4F9A2750-7CD7-11D8-BA3D-000393A47A5C@lanl.gov>
References: <Pine.LNX.4.44.0403222030060.3418-100000@maxroach.lanl.gov>
	<m3d6740zp5.fsf@maxwell.lnxi.com>
	<4F9A2750-7CD7-11D8-BA3D-000393A47A5C@lanl.gov>
Message-ID: <m3zna7k1ch.fsf@maxwell.lnxi.com>

Greg Watson <gwatson at lanl.gov> writes:

> On 23/03/2004, at 12:50 AM, Eric W. Biederman wrote:
> 
> > Ok I suspect that code came early on and never got cleaned up.
> >
> > What this sounded like was a bug in existing code that caused things to work
> > incorrectly.  So at least on the Opteron things worked correctly.
> >
> > We need to go in and add better cpu selection support in the code.
> > What I am thinking it to extract the vendor and model number for the
> > cpu and with that select the code to run similarly to how we handle
> > other devices.
> >
> > Given the number of small details that need to be verified when a new
> > cpu comes out.  Microcode on the Xeons, memory controller enhancements
> > on the Opterons, etc  I would rather have the build break on a new
> > cpu than have everything just almost work silently.
> >
> >>
> 
> This is probably a good idea, but note that the x86 and ppc architectures do
> things very differently. To start with ppc doesn't have the hierarchical
> arrangement that is used in x86. This leads to a much simpler setup, though it
> does duplicate some code, but in any event I don't want this to change. Also,
> the pre-C configuration is completely different (romcc is not used). However
> this is done, it will need to take these architectural differences into account.

Given that ppc and x86 have different name spaces for cpu identification
we cannot share the implementation.  Like pci and superio devices
similar but different.

What I would like to do is rewrite the architecture specific cpu_initialize 
so that it finds the type of a cpu and the dispatches to code that
is totally cpu specific.  If we have any code reuse it will be by
calling library functions in the cpu specific code.

Once that happens compilation should be reduced to a set of
which basic cpu types do you want to compile support in for.
When cpus made by multiple vendors can share the same socket
that is quite an interesting proposition.

Eric


From ollie at lanl.gov  Tue Mar 23 10:58:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Mar 23 10:58:01 2004
Subject: Resident SIS expert
In-Reply-To: <20040322223255.33172.qmail@web13801.mail.yahoo.com>
References: <20040322223255.33172.qmail@web13801.mail.yahoo.com>
Message-ID: <1080058915.25319.86.camel@exponential.lanl.gov>

On Mon, 2004-03-22 at 15:32, Frank wrote:
> I'm trying to figure out how to reroute i/o amd memory space
> from the pci space to the LBC Bridge. Anyone out there know
> which registers to touch in the SSI550. I have the SIS register
> programming but it doesn't describe which registers have to be
> touched to accomplish this.
> 


What do you mean by mapping PCI IO/MEM space to LPC bridge ?
LPC bridge bridges ISA devices which have different address
space than PCI.

Ollie




From frannk_m1 at yahoo.com  Tue Mar 23 11:21:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Mar 23 11:21:01 2004
Subject: Resident SIS expert
In-Reply-To: <1080058915.25319.86.camel@exponential.lanl.gov>
Message-ID: <20040323164415.19819.qmail@web13801.mail.yahoo.com>

You just answered my question, I think. So you're saying if I
access i/o port 0x3f8 (com1) or the lpt port the access will be
forworded to the LPC bus?
I thought the LPC was just another bridge on the PCI bus and you
had to setup the I/O and Memory base address regitsters just
like any other PCI bridge device.
Sorry for asking what appears to be a stupid question, but I
come from the MIPS and PPC part of the world. I haven't done any
P.C. programming in 15 years...

--- Li-Ta Lo <ollie at lanl.gov> wrote:
> On Mon, 2004-03-22 at 15:32, Frank wrote:
> > I'm trying to figure out how to reroute i/o amd memory space
> > from the pci space to the LBC Bridge. Anyone out there know
> > which registers to touch in the SSI550. I have the SIS
> register
> > programming but it doesn't describe which registers have to
> be
> > touched to accomplish this.
> > 
> 
> 
> What do you mean by mapping PCI IO/MEM space to LPC bridge ?
> LPC bridge bridges ISA devices which have different address
> space than PCI.
> 
> Ollie
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html


From frannk_m1 at yahoo.com  Tue Mar 23 11:26:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Mar 23 11:26:01 2004
Subject: Resident SIS expert
In-Reply-To: <1080058915.25319.86.camel@exponential.lanl.gov>
Message-ID: <20040323164940.36304.qmail@web13809.mail.yahoo.com>

I have Intel's LPC Hardware Specification but it doesn't go in
detail from a software point of view. Do you know where I can
get a software specification...
--- Li-Ta Lo <ollie at lanl.gov> wrote:
> On Mon, 2004-03-22 at 15:32, Frank wrote:
> > I'm trying to figure out how to reroute i/o amd memory space
> > from the pci space to the LBC Bridge. Anyone out there know
> > which registers to touch in the SSI550. I have the SIS
> register
> > programming but it doesn't describe which registers have to
> be
> > touched to accomplish this.
> > 
> 
> 
> What do you mean by mapping PCI IO/MEM space to LPC bridge ?
> LPC bridge bridges ISA devices which have different address
> space than PCI.
> 
> Ollie
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html


From ollie at lanl.gov  Tue Mar 23 11:35:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Mar 23 11:35:01 2004
Subject: Resident SIS expert
In-Reply-To: <20040323164940.36304.qmail@web13809.mail.yahoo.com>
References: <20040323164940.36304.qmail@web13809.mail.yahoo.com>
Message-ID: <1080061111.25319.88.camel@exponential.lanl.gov>

On Tue, 2004-03-23 at 09:49, Frank wrote:
> I have Intel's LPC Hardware Specification but it doesn't go in
> detail from a software point of view. Do you know where I can
> get a software specification...


You have to find out the LPC superio chip docs. AFIAK,
550 an its own LPC embedded. Did you get the full doc
from SiS ?

Ollie




From frannk_m1 at yahoo.com  Tue Mar 23 11:49:01 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Mar 23 11:49:01 2004
Subject: Resident SIS expert
In-Reply-To: <1080061111.25319.88.camel@exponential.lanl.gov>
Message-ID: <20040323171235.17884.qmail@web13806.mail.yahoo.com>

Yes, we signed an NDA and have all of the documentation. But the
manual is very poorly written and it is ver difficult to find
anything. I have read the register programming manual a hundred
times and cannot figure out where you set the BAR registers for
the LPC bridge.:-(
It has registers to set the base address for the ACPI and other
devices hanging off of the LPC but I cannot find the register
that say "map this i/o or memory address space and define the
size of the address space". 
I have a feeling they gave us an incomplete manual.:-(

--- Li-Ta Lo <ollie at lanl.gov> wrote:
> On Tue, 2004-03-23 at 09:49, Frank wrote:
> > I have Intel's LPC Hardware Specification but it doesn't go
> in
> > detail from a software point of view. Do you know where I
> can
> > get a software specification...
> 
> 
> You have to find out the LPC superio chip docs. AFIAK,
> 550 an its own LPC embedded. Did you get the full doc
> from SiS ?
> 
> Ollie
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html


From ollie at lanl.gov  Tue Mar 23 11:56:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Mar 23 11:56:01 2004
Subject: Resident SIS expert
In-Reply-To: <20040323171235.17884.qmail@web13806.mail.yahoo.com>
References: <20040323171235.17884.qmail@web13806.mail.yahoo.com>
Message-ID: <1080062366.25319.91.camel@exponential.lanl.gov>

On Tue, 2004-03-23 at 10:12, Frank wrote:
> Yes, we signed an NDA and have all of the documentation. But the
> manual is very poorly written and it is ver difficult to find
> anything. I have read the register programming manual a hundred
> times and cannot figure out where you set the BAR registers for
> the LPC bridge.:-(
> It has registers to set the base address for the ACPI and other
> devices hanging off of the LPC but I cannot find the register
> that say "map this i/o or memory address space and define the
> size of the address space". 
> I have a feeling they gave us an incomplete manual.:-(


Believe me, that's the best they can offer ;-). Those LPC
devices are legacy which have "well know" fixe address.

Ollie




From frannk_m1 at yahoo.com  Tue Mar 23 12:08:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Mar 23 12:08:00 2004
Subject: Resident SIS expert
In-Reply-To: <1080062366.25319.91.camel@exponential.lanl.gov>
Message-ID: <20040323173143.64845.qmail@web13811.mail.yahoo.com>

Ok,
Just to confirm what I think you are saying:
If I access I/O port 0x3f8 (COM1) it automagically goes to the
LPC bus??

--- Li-Ta Lo <ollie at lanl.gov> wrote:
> On Tue, 2004-03-23 at 10:12, Frank wrote:
> > Yes, we signed an NDA and have all of the documentation. But
> the
> > manual is very poorly written and it is ver difficult to
> find
> > anything. I have read the register programming manual a
> hundred
> > times and cannot figure out where you set the BAR registers
> for
> > the LPC bridge.:-(
> > It has registers to set the base address for the ACPI and
> other
> > devices hanging off of the LPC but I cannot find the
> register
> > that say "map this i/o or memory address space and define
> the
> > size of the address space". 
> > I have a feeling they gave us an incomplete manual.:-(
> 
> 
> Believe me, that's the best they can offer ;-). Those LPC
> devices are legacy which have "well know" fixe address.
> 
> Ollie
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html


From ollie at lanl.gov  Tue Mar 23 12:14:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Mar 23 12:14:00 2004
Subject: Resident SIS expert
In-Reply-To: <20040323173143.64845.qmail@web13811.mail.yahoo.com>
References: <20040323173143.64845.qmail@web13811.mail.yahoo.com>
Message-ID: <1080063476.25319.96.camel@exponential.lanl.gov>

On Tue, 2004-03-23 at 10:31, Frank wrote:
> Ok,
> Just to confirm what I think you are saying:
> If I access I/O port 0x3f8 (COM1) it automagically goes to the
> LPC bus??
> 

It depends on what you mean by "goes to the LPC bus". It will
go to the COM1 device "via" the LPC bus. If you want to access
other device, you need to access some other magic io ports.

Ollie




From frannk_m1 at yahoo.com  Tue Mar 23 13:28:00 2004
From: frannk_m1 at yahoo.com (Frank)
Date: Tue Mar 23 13:28:00 2004
Subject: Resident SIS expert
In-Reply-To: <1080063476.25319.96.camel@exponential.lanl.gov>
Message-ID: <20040323185148.57692.qmail@web13804.mail.yahoo.com>

That's exactly what I was getting at: accessing all legacy
devices by referencing their address space causes an LBC bus
transaction.
Thanks for clearing that up. Like I said I have been doing
mostly MIPS and PPC development (The Gods have been kind) and
haven't done any PC embedded programming for the past 15
years...

--- Li-Ta Lo <ollie at lanl.gov> wrote:
> On Tue, 2004-03-23 at 10:31, Frank wrote:
> > Ok,
> > Just to confirm what I think you are saying:
> > If I access I/O port 0x3f8 (COM1) it automagically goes to
> the
> > LPC bus??
> > 
> 
> It depends on what you mean by "goes to the LPC bus". It will
> go to the COM1 device "via" the LPC bus. If you want to access
> other device, you need to access some other magic io ports.
> 
> Ollie
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html


From don at bowery.com  Tue Mar 23 16:38:01 2004
From: don at bowery.com (Don Elwell)
Date: Tue Mar 23 16:38:01 2004
Subject: mkelfImage initrd help
In-Reply-To: <Pine.LNX.4.44.0403221608230.1885-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403221608230.1885-100000@maxroach.lanl.gov>
Message-ID: <4060B2AC.3030402@bowery.com>

Thanks Ron,

Attached is the serial dump of what is happening -- stuff in double 
braces [[ ]] are notes from me.  From the attached logs and additional 
debug prints in the kernel and the convert_params.c file I'm pretty 
convinced its *not* mkelfImage.  I think mkelfImage is doing exactly 
what its supposed to do.

I think it still could be Etherboot but I think its more likely 
something with the kernel and/or the version of the kernel I'm using. 
I've come to this conclusion because the initrd data (stuff at 0x800000) 
just before the mkelfImage/convert_params.c handoff to Linux is perfect. 
  I'm in the process of building new and different kernel versions to 
see if it makes a difference.  What version of the kernel have you used 
successfully with Etherboot/single mkelfImage?

Perhaps you'll see something that I don't.  I'm starting to have "can't 
see the forest from the trees" issues...

-don



ron minnich wrote:

> On Mon, 22 Mar 2004, Don Elwell wrote:
> 
> 
>>LinuxBIOS->Etherboot->Linux (single mkelfImage kernel/initrd)
> 
> 
> we do this now.
> 
> 
>>Booting the kernel/initrd via the CD-ROM works great.  Booting via 
>>Etherboot doesn't.  I get kernel panics indicating that the kernel can't 
>>mount its root fs.
> 
> 
> can you send the string?
> 
> I wonder if by some chance etherboot is doing something to IDE that makes 
> it work "correctly" for the kernel in the CD-ROM case.
> 
> 
>>I also added code in the Linux kernel do_mounts.c file (just after the 
>>"RAMDISK: could not find valid ramdisk image") to print out the first 
>>512 bytes of the buf buffer.  At this point, the values in no way match 
>>the values in the initrd image (nor to those printed out in 
>>convert_params.c).
> 
> 
> hmm. etherboot problem? What kind of ethernet chip?
> 
> ron
> 
-------------- next part --------------
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.2.2 (GPL) http://etherboot.org Tagged ELF (Multiboot) for [3C90X]
Relocating _text from: [00014240,00023bf0) to [0f6f0650,0f700000)
Boot from (N)etwork or (Q)uit? N

Probing pci nic...
[3c9805]

3C90X Driver 2.00 Copyright 1999 LightSys Technology Services, Inc.
Portions Copyright 1999 Steve Smith
Provided with ABSOLUTELY NO WARRANTY.
-------------------------------------------------------------------------------
MAC Address = 00:01:03:D6:46:4A
Connectors present: 10Base-T / 100Base-TX.
Searching for server (DHCP)...
..Me: 192.168.0.230, Server: 192.168.0.13, Gateway 192.168.0.1
Loading 192.168.0.13:dir911t.sys ...(ELF)... [[dots removed]] .....done
Issuing RESET:
hello world
count_elf_notes 0f6fe2f0
elf_note = 0f6fe2fc
elf_namesz = 0000000a
elf_descsz = 00000004
elf_type   = 00000005
elf_name = 0f6fe308
elf_desc = 0f6fe314
elf_note = 0f6fe318
elf_namesz = 0000000a
elf_descsz = 00000004
elf_type   = 00000006
elf_name = 0f6fe324
elf_desc = 0f6fe330
elf_note = 0f6fe334
elf_namesz = 0000000a
elf_descsz = 0000028c
elf_type   = 00000008
elf_name = 0f6fe340
elf_desc = 0f6fe34c
elf_note = 0f6fe5d8
elf_namesz = 00000000
elf_descsz = 0000000a
elf_type   = 00000002
elf_name = 0f6fe5e4
elf_desc = 0f6fe5e4
elf_note = 0f6fe5f0
elf_namesz = 00000000
elf_descsz = 00000006
elf_type   = 00000003
elf_name = 0f6fe5fc
elf_desc = 0f6fe5fc
elf_note = 0f6fe604
elf_namesz = 00000000
elf_descsz = 00000007
elf_type   = 00000001
elf_name = 0f6fe610
elf_desc = 0f6fe610
elf_note = 0f6fe618
elf_namesz = 00000000
elf_descsz = 00000080
elf_type   = 00000006
elf_name = 0f6fe624
elf_desc = 0f6fe624
elf_note = 0f6fe6a4
elf_namesz = 00000000
elf_descsz = 00000001
elf_type   = 00000004
elf_name = 0f6fe6b0
elf_desc = 0f6fe6b0
Firmware type: PCBIOS
EXT_MEM_K=00000156
ALT_MEM_K=0001013a
print_offsets
orig_x               =00000000
orig_y               =00000001
ext_mem_k            =00000002
orig_video_page      =00000004
orig_video_mode      =00000006
orig_video_cols      =00000007
unused2              =00000008
orig_video_ega_bx    =0000000a
unused3              =0000000c
orig_video_lines     =0000000e
orig_video_isVGA     =0000000f
orig_video_points    =00000010
lfb_width            =00000012
lfb_height           =00000014
lfb_depth            =00000016
lfb_base             =00000018
lfb_size             =0000001c
cl_magic             =00000020
cl_offset            =00000022
lfb_linelength       =00000024
red_size             =00000026
red_pos              =00000027
green_size           =00000028
green_pos            =00000029
blue_size            =0000002a
blue_pos             =0000002b
rsvd_size            =0000002c
rsvd_pos             =0000002d
vesapm_seg           =0000002e
vesapm_off           =00000030
pages                =00000032
reserved4            =00000034
apm_bios_info        =00000040
drive_info           =00000080
sys_desc_table       =000000a0
alt_mem_k            =000001e0
reserved5            =000001e4
e820_map_nr          =000001e8
reserved6            =000001e9
mount_root_rdonly    =000001f2
reserved7            =000001f4
ramdisk_flags        =000001f8
reserved8            =000001fa
orig_root_dev        =000001fc
reserved9            =000001fe
aux_device_info      =000001ff
reserved10           =00000200
param_block_signature=00000202
param_block_version  =00000206
reserved11           =00000208
loader_type          =00000210
loader_flags         =00000211
reserved12           =00000212
kernel_start         =00000214
initrd_start         =00000218
initrd_size          =0000021c
reserved13           =00000220
e820_map             =000002d0
reserved16           =00000550
command_line         =00000800
reserved17           =00000900
print_linux_params
orig_x           =00000000
orig_y           =00000019
orig_video_page  =00000000
orig_video_mode  =00000000
orig_video_cols  =00000050
orig_video_lines =00000019
orig_video_ega_bx=00000000
orig_video_isVGA =00000001
orig_video_points=00000010
sys_dest_table_len=00000000
ext_mem_k        =00000156
alt_mem_k        =0001013a
e820_map_nr      =00000007
addr[00000000]         =0000000000000000
size[00000000]         =000000000009fc00
type[00000000]         =0001631400000001
addr[00000001]         =000000000009fc00
size[00000001]         =0000000000000400
type[00000001]         =0001631400000002
addr[00000002]         =00000000000f0000
size[00000002]         =0000000000010000
type[00000002]         =0001631400000002
addr[00000003]         =0000000000100000
size[00000003]         =000000000f6f0000
type[00000003]         =0001631400000001
addr[00000004]         =000000000f7f0000
size[00000004]         =0000000000003000
type[00000004]         =0001631400000004
addr[00000005]         =000000000f7f3000
size[00000005]         =000000000000d000
type[00000005]         =0001631400000003
addr[00000006]         =00000000fec00000
size[00000006]         =0000000001400000
type[00000006]         =0001631400000002
addr[00000007]         =0000000000000000
size[00000007]         =0000000000000000
type[00000007]         =0001631400000000
addr[00000008]         =0000000000000000
size[00000008]         =0000000000000000
type[00000008]         =0001631400000000
addr[00000009]         =0000000000000000
size[00000009]         =0000000000000000
type[00000009]         =0001631400000000
addr[0000000a]         =0000000000000000
size[0000000a]         =0000000000000000
type[0000000a]         =0001631400000000
addr[0000000b]         =0000000000000000
size[0000000b]         =0000000000000000
type[0000000b]         =0001631400000000
addr[0000000c]         =0000000000000000
size[0000000c]         =0000000000000000
type[0000000c]         =0001631400000000
addr[0000000d]         =0000000000000000
size[0000000d]         =0000000000000000
type[0000000d]         =0001631400000000
addr[0000000e]         =0000000000000000
size[0000000e]         =0000000000000000
type[0000000e]         =0001631400000000
addr[0000000f]         =0000000000000000
size[0000000f]         =0000000000000000
type[0000000f]         =0001631400000000
addr[00000010]         =0000000000000000
size[00000010]         =0000000000000000
type[00000010]         =0001631400000000
addr[00000011]         =0000000000000000
size[00000011]         =0000000000000000
type[00000011]         =0001631400000000
addr[00000012]         =0000000000000000
size[00000012]         =0000000000000000
type[00000012]         =0001631400000000
addr[00000013]         =0000000000000000
size[00000013]         =0000000000000000
type[00000013]         =0001631400000000
addr[00000014]         =0000000000000000
size[00000014]         =0000000000000000
type[00000014]         =0001631400000000
addr[00000015]         =0000000000000000
size[00000015]         =0000000000000000
type[00000015]         =0001631400000000
addr[00000016]         =0000000000000000
size[00000016]         =0000000000000000
type[00000016]         =0001631400000000
addr[00000017]         =0000000000000000
size[00000017]         =0000000000000000
type[00000017]         =0001631400000000
addr[00000018]         =0000000000000000
size[00000018]         =0000000000000000
type[00000018]         =0001631400000000
addr[00000019]         =0000000000000000
size[00000019]         =0000000000000000
type[00000019]         =0001631400000000
addr[0000001a]         =0000000000000000
size[0000001a]         =0000000000000000
type[0000001a]         =0001631400000000
addr[0000001b]         =0000000000000000
size[0000001b]         =0000000000000000
type[0000001b]         =0001631400000000
addr[0000001c]         =0000000000000000
size[0000001c]         =0000000000000000
type[0000001c]         =0001631400000000
addr[0000001d]         =0000000000000000
size[0000001d]         =0000000000000000
type[0000001d]         =0001631400000000
addr[0000001e]         =0000000000000000
size[0000001e]         =0000000000000000
type[0000001e]         =0001631400000000
addr[0000001f]         =0000000000000000
size[0000001f]         =0000000000000000
type[0000001f]         =0001631400000000
mount_root_rdonly=0000ffff
ramdisk_flags    =00000000
orig_root_dev    =00000300
aux_device_info  =00000000
param_block_signature=53726448
loader_type      =00000050
loader_flags     =00000000
initrd_start     =00800000
initrd_size      =0011c08e
cl_magic         =0000a33f
cl_offset        =00000800
command_line     =ramdisk_size=40960 root=/dev/ram0 devfs=nomount console=ttyS0,115200 rw 

[[ Here is where I dump the first 512 bytes at 0x800000.  They match perfectly
   with the first 512 bytes of my initrd image ]]

Jumping to Linux
Linux version 2.4.25-lck1 (root at pzdev3) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #20 Mon Mar 22 17:22:41 EST 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000f7f0000 (usable)
 BIOS-e820: 000000000f7f0000 - 000000000f7f3000 (ACPI NVS)
 BIOS-e820: 000000000f7f3000 - 000000000f800000 (ACPI data)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
247MB LOWMEM available.

[[ The next 4 lines are debug statements inserted by me ]]
INITRD_START = 0x00800000
INITRD_SIZE = 0x0011C08E
initrd_start = 0xC0800000
initrd_end = 0xC091C08E

On node 0 totalpages: 63472
zone(0): 4096 pages.
zone(1): 59376 pages.
zone(2): 0 pages.
Kernel command line: ramdisk_size=40960 root=/dev/ram0 devfs=nomount console=ttyS0,115200 rw 
Found and enabled local APIC!
Initializing CPU#0
Detected 2000.010 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 3973.12 BogoMIPS
Memory: 243820k/253888k available (3850k kernel code, 9680k reserved, 1526k data, 160k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 128K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel(R) Celeron(R) CPU 2.00GHz stepping 07
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1999.1205 MHz.
..... host bus clock speed is 99.1960 MHz.
cpu: 0, clocks: 199960, slice: 99980
CPU0<T0:199952,T1:99968,D:4,S:99980,C:199960>
mtrr: v1.40 (20010327) Richard Gooch (rgooch at atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb430, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 00:1f.1
Transparent bridge - Intel Corp. 82801BA/CA/DB/EB PCI Bridge
PCI: Using IRQ router PIIX/ICH [8086/24c0] at 00:1f.0
PCI: Found IRQ 11 for device 00:1f.1
PCI: Sharing IRQ 11 with 00:02.0
PCI: Sharing IRQ 11 with 01:00.0
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
Coda Kernel/Venus communications, v5.3.18, coda at cs.cmu.edu
devfs: v1.12c (20020818) Richard Gooch (rgooch at atnf.csiro.au)
devfs: boot_options: 0x0
Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
udf: registering filesystem
SGI XFS with no debug enabled
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
i2c-proc.o version 2.6.1 (20010830)
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Non-volatile memory driver v1.2
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 40960K size 1024 blocksize
loop: loaded (max 8 devices)
PCI: Found IRQ 11 for device 01:00.0
PCI: Sharing IRQ 11 with 00:02.0
PCI: Sharing IRQ 11 with 00:1f.1
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
See Documentation/networking/vortex.txt
01:00.0: 3Com PCI 3c980C Python-T at 0xc000. Vers LK1.1.18-ac
 00:01:03:d6:46:4a, IRQ 11
  product code 4b50 rev 00.14 date 02-16-01
  8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
  MII transceiver found at address 24, status 782d.
  Enabling bus-master transmits and whole-frame receives.
01:00.0: scatter/gather enabled. h/w checksums enabled
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 196M
agpgart: Detected an Intel(R) 845G Chipset.
agpgart: Detected 8060K stolen memory.
agpgart: AGP aperture is 128M @ 0xd0000000
[drm] Initialized tdfx 1.0.0 20010216 on minor 0
[drm] AGP 0.99 Aperture @ 0xd0000000 128MB
[drm] Initialized radeon 1.7.0 20020828 on minor 1
[drm] AGP 0.99 Aperture @ 0xd0000000 128MB
[drm] Initialized i810 1.2.1 20020211 on minor 2
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 00:1f.1
PCI: Found IRQ 11 for device 00:1f.1
PCI: Sharing IRQ 11 with 00:02.0
PCI: Sharing IRQ 11 with 01:00.0
ICH4: chipset revision 2
ICH4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
hdc: AOpen 12X DVD-ROM/ASH 01112001, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hdc: attached ide-cdrom driver.
hdc: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
raw1394: /dev/raw1394 device initialized
sbp2: $Rev: 1074 $ Ben Collins <bcollins at debian.org>
ALI 5455 + AC97 Audio, version 0.03-ac, 23:36:08 Mar 18 2004
Intel 810 + AC97 Audio, version 0.24, 23:36:11 Mar 18 2004
PCI: Found IRQ 10 for device 00:1f.5
PCI: Sharing IRQ 10 with 00:1f.3
i810: Intel ICH4 found at IO 0xe400 and 0xe000, MEM 0xde081000 and 0xde082000, IRQ 10
i810: Intel ICH4 mmio at 0xd00e5000 and 0xd00e7000
i810_audio: Primary codec has ID 2
i810_audio: Audio Controller supports 6 channels.
i810_audio: Defaulting to base 2 channel mode.
i810_audio: Resetting connection 0
i810_audio: Connection 0 with codec id 2
ac97_codec: AC97 Audio codec, id: ALG48 (Unknown)
i810_audio: only 48Khz playback available.
i810_audio: AC'97 codec 2 supports AMAP, total channels = 2
es1371: version v0.32 time 23:36:13 Mar 18 2004
Linux Kernel Card Services 3.1.22
  options:  [pci] [cardbus]
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
host/uhci.c: USB Universal Host Controller Interface driver v1.1
host/uhci.c: USB UHCI at I/O 0xd800, IRQ 11
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
host/uhci.c: USB UHCI at I/O 0xd000, IRQ 11
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
host/uhci.c: USB UHCI at I/O 0xd400, IRQ 9
usb.c: new USB bus registered, assigned bus number 3
hub.c: USB hub found
hub.c: 2 ports detected
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech at suse.cz>
hid-core.c: USB HID support drivers
usb.c: registered new driver audio
audio.c: v1.0.0:USB Audio Class driver
pegasus.c: v0.4.32 (2003/06/06):Pegasus/Pegasus II USB Ethernet driver
usb.c: registered new driver pegasus
rtl8150.c: rtl8150 based usb-ethernet driver v0.4.3 (2002/12/31)
usb.c: registered new driver rtl8150
catc.c: v2.8 CATC EL1210A NetMate USB Ethernet driver
usb.c: registered new driver catc
usb.c: registered new driver kaweth
usb.c: registered new driver CDCEther
bluetooth.c: USB Bluetooth support registered
usb.c: registered new driver bluetty
bluetooth.c: USB Bluetooth tty driver v0.13
usb.c: registered new driver serial
usbserial.c: USB Serial support registered for Generic
usbserial.c: USB Serial Driver core v1.4
usbserial.c: USB Serial support registered for PL-2303
pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.10
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
ds: no socket drivers loaded!
RAMDISK: Couldn't find valid RAM disk image starting at 0.

[[ This line was added by me to find out where in VM the kernel
   thinks the initrd resides ]].

RAMDISK: the ramdisk image starts at 0xC0800000 (-1065353216)

[[ Here is where I print out the first 512 bytes of the ramdisk
   (i.e. location 0xC0800000 -> 0xC08001FF).  The data in no way
   looks like data in the initrd image ]]

Freeing initrd memory: 1136k freed
FAT: bogus logical sector size 0
UMSDOS: msdos_read_super failed, mount aborted.
FAT: bogus logical sector size 0
FAT: bogus logical sector size 0
ufs was compiled with read-only support, can't be mounted as read-write
UDF-fs: No partition found (1)
sh-2021: reiserfs_read_super: can not find reiserfs on ramdisk(1,0)
XFS: bad magic number
XFS: SB validate failed
Kernel panic: VFS: Unable to mount root fs on 01:00
 

From ebiederman at lnxi.com  Tue Mar 23 18:02:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Mar 23 18:02:01 2004
Subject: unreliably booting off a BCM5701.
In-Reply-To: <20040322204314.GA11093@suse.de>
References: <20040322170110.GA6915@suse.de> <20040322174456.GA9378@suse.de>
	<m3lllslnbx.fsf@maxwell.lnxi.com> <20040322204314.GA11093@suse.de>
Message-ID: <m365cv16ki.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [040322 19:59]:
> > Stefan Reinauer <stepan at suse.de> writes:
> > > Also, I could not get beyound this point with a Linux 2.6.5rc1 kernel.
> > > Linux 2.4.x boots through to userland... It looks like a kernel issue,
> > > but could it come from mkelfImage?
> > 
> > Possibly.  Either that or you got hit with the changes to the
> > 2.6.x config option changes.  I have booted a 2.6 kernel.  So unless
> > it is a very recent change things should still work.
>  
> I definitely have booted 2.6 kernels up to 2.6.2 under LinuxBIOS as
> well. 

Ok that is peculiar.  2.6.5rc1 has some patches to head.S which possibly
accounts for it as soon as I have a moment I will check and see if
that is what breaks it.  From the looks the changes to head.S should
not break anything....
 
> > Have you tried memtest86?  I am quite curious to if your memory
> > is working solidly.  With all of your bootloaders going haywire
> > I really don't know what to think.
> 
> No memtest yet, but filo and etherboot, and linux kernel 2.4 - When they
> get loaded, they seem to work seamlessly...

So the etherboot and filo issues were resolved?

> > This might be a glitch in 5.3.recent as well.  I have not looked
> > in detail at what is going on there.  I can't think of anything
> > that would cause a failure like that.
> 
> 5.3.recent?

5.3.x is the development version, and there is some major development
going on there to implement pxe support so I don't know what is
going on.

Eric


From YhLu at tyan.com  Tue Mar 23 20:14:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Mar 23 20:14:00 2004
Subject: =?gb2312?B?tPC4tDogInVwIiwgImRvd24i?=
Message-ID: <3174569B9743D511922F00A0C94314230466D7BB@TYANWEB>

In the code

Link2 - Down
Link1 - Across
Link0 - up

YH.

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?22? 9:29
???: ron minnich
??: linuxbios at clustermatic.org
??: Re: "up", "down"

* ron minnich <rminnich at lanl.gov> [040322 18:21]:
> 
> which bus numbers do these correspond to again? I should know this but 
> don't.
  
It refers to the Hypertransport Links, Down (LDT0), Across (LDT1), UP
(LDT2). Is that what you mean?

Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Tue Mar 23 21:51:02 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Mar 23 21:51:02 2004
Subject: S4882 support
Message-ID: <3174569B9743D511922F00A0C94314230466D7DE@TYANWEB>

Eric,

The ht reset in auto.c seems not thoroughly.

And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can not
access 8111 yet).

Regards

YH

LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:33:50 PST 2004 starting...
setting up resource map....done.
04 nodes initialized.
ht reset -Ram1.00
X?m1.01
Ram1.02
Ram1.03
Ram2.00
Ram2.01
Ram2.02
Ram2.03
Ram3
Initializing memory:  done
Initializing memory:  done
Initializing memory:  done
Initializing memory:  done
Clearing LinuxBIOS memory:  done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:46:40 PST 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD 8111
Enumerating: Winbond w83627hf
Enumerating buses...PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
PCI: 00:1a.0 [1022/1100] enabled
PCI: 00:1a.1 [1022/1101] enabled
PCI: 00:1a.2 [1022/1102] enabled
PCI: 00:1a.3 [1022/1103] ops
PCI: 00:1a.3 [1022/1103] enabled
PCI: 00:1b.0 [1022/1100] enabled
PCI: 00:1b.1 [1022/1101] enabled
PCI: 00:1b.2 [1022/1102] enabled
PCI: 00:1b.3 [1022/1103] ops
PCI: 00:1b.3 [1022/1103] enabled
amdk8_scan_chains max: 0 starting...
Hyper transport scan link: 1 max: 1
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset needed

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: s4882_1.1.6_ht_reset_failed.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040323/f0537a25/attachment.txt>

From YhLu at tyan.com  Tue Mar 23 22:26:02 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Mar 23 22:26:02 2004
Subject: =?utf-8?B?562U5aSNOiBTNDg4MiBzdXBwb3J0?=
Message-ID: <3174569B9743D511922F00A0C94314230466D7F2@TYANWEB>

It seems the soft reset didn't rest the MB and ...

Ollie,

Can you check that in S2885? And I think if you changed the hard_reset and
soft_reset to bus 1, it may not rest the ht.

Regards

Yinghai Lu

-----????-----
???: YhLu 
????: 2004?3?23? 19:22
???: ebiederman at lnxi.com; Stefan Reinauer; ron minnich
??: linuxbios at clustermatic.org
??: S4882 support

Eric,

The ht reset in auto.c seems not thoroughly.

And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can not
access 8111 yet).

Regards

YH

LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:33:50 PST 2004 starting...
setting up resource map....done.
04 nodes initialized.
ht reset -Ram1.00
X?m1.01
Ram1.02
Ram1.03
Ram2.00
Ram2.01
Ram2.02
Ram2.03
Ram3
Initializing memory:  done
Initializing memory:  done
Initializing memory:  done
Initializing memory:  done
Clearing LinuxBIOS memory:  done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:46:40 PST 2004 booting...
Finding PCI configuration type.
PCI: Using configuration type 1
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8 Northbridge
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD K8
Enumerating: AMD 8111
Enumerating: Winbond w83627hf
Enumerating buses...PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
PCI: 00:1a.0 [1022/1100] enabled
PCI: 00:1a.1 [1022/1101] enabled
PCI: 00:1a.2 [1022/1102] enabled
PCI: 00:1a.3 [1022/1103] ops
PCI: 00:1a.3 [1022/1103] enabled
PCI: 00:1b.0 [1022/1100] enabled
PCI: 00:1b.1 [1022/1101] enabled
PCI: 00:1b.2 [1022/1102] enabled
PCI: 00:1b.3 [1022/1103] ops
PCI: 00:1b.3 [1022/1103] enabled
amdk8_scan_chains max: 0 starting...
Hyper transport scan link: 1 max: 1
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset needed



From ebiederman at lnxi.com  Wed Mar 24 02:09:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Mar 24 02:09:00 2004
Subject: S4882 support
In-Reply-To: <3174569B9743D511922F00A0C94314230466D7DE@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D7DE@TYANWEB>
Message-ID: <m3k71azo6f.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> The ht reset in auto.c seems not thoroughly.
> 
> And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can not
> access 8111 yet).

Correct.  The early hypertransport initialization code is not
complete in the 4P case.  That incompleteness triggers the later
fixups.

I could not test that case, and there were at least some small
difficulties in that it was not obvious how the 4P case should
be extended to work properly.

Why you are getting stuck in amdk8_scan_chains I do not currently
understand yet.  I suspect Stefan's suggestion of a delayed reset
is the appropriate course to implement.

Eric


From rminnich at lanl.gov  Wed Mar 24 09:15:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 24 09:15:01 2004
Subject: mkelfImage initrd help
In-Reply-To: <4060B2AC.3030402@bowery.com>
Message-ID: <Pine.LNX.4.44.0403240734410.18454-100000@maxroach.lanl.gov>

well your output is very puzzling. We do this all the time, although I 
have not yet tried 2.4.25. I think the last time I did this was 2.4.22

It's almost as though something in the kernel is trashing the ramdisk when 
it starts up. 

But you say it did work from cdrom, which makes this even weirder.

I hope it is not some random DMA from ethernet landing sometime after 
kernel starts, but it sounds too reproducible. 

I think you're stuck with some more etherboot debugging. Do you have to 
use net boot? 

ron



From don at bowery.com  Wed Mar 24 09:39:01 2004
From: don at bowery.com (Don Elwell)
Date: Wed Mar 24 09:39:01 2004
Subject: mkelfImage initrd help
In-Reply-To: <Pine.LNX.4.44.0403240734410.18454-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403240734410.18454-100000@maxroach.lanl.gov>
Message-ID: <4061A1EF.5000906@bowery.com>

ron minnich wrote:
> well your output is very puzzling. We do this all the time, although I 
> have not yet tried 2.4.25. I think the last time I did this was 2.4.22
> 

The exact same setup (identical initrd image) works perfectly with 
2.4.22 *and* 2.6.0-test3 kernels.  I'll be building and trying a plain 
(i.e. from www.kernel.org) 2.4.25 kernel this evening (the version I've 
been testing with is the -lck1 performance patches -- which themselves 
could be causing the problem).

> It's almost as though something in the kernel is trashing the ramdisk when 
> it starts up. 
> 
> But you say it did work from cdrom, which makes this even weirder.
> 

Yes, the errant kernel (2.4.25) will boot from CD-ROM using ISOLINUX 
(separate kernel/initrd images).  That identical image will not boot 
using Etherboot (single kernel/initrd image made with mkelfImage).  By 
simply replacing the kernel in the mkelfImage to either 2.4.22 or 
2.6.0-test3 the system boots normally.

> I hope it is not some random DMA from ethernet landing sometime after 
> kernel starts, but it sounds too reproducible. 
> 

I agree.  This happens exactly the same time, every time.  Coupled with 
the fact that the other kernels work, I think Etherboot and mkelfImage 
are doing what they are supposed to do.

> I think you're stuck with some more etherboot debugging. Do you have to 
> use net boot? 
> 

The systems we're building only have Ethernet/serial to the outside 
world (they do have a CF internal).  My thought was to have them net 
boot in their production test that (in addition to running production 
tests on the system) also puts the correct application image(s) on the 
CF.  Also, I didn't want the techs to have to take apart the units to 
re-image the CF.

But, PROGRESS!!!!!  I'm not married to the 2.4.25 kernel in any way.  I 
could just as easily use 2.4.22 (which we use in other systems now 
anyway).  (unfortunately :-) ) My curiosity has been piqued -- I gotta 
know whats causing this!

More to come.

-don



From stepan at suse.de  Wed Mar 24 10:11:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 10:11:00 2004
Subject: ??????: S4882 support
In-Reply-To: <3174569B9743D511922F00A0C94314230466D7F2@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D7F2@TYANWEB>
Message-ID: <20040324153532.GA4404@suse.de>

* YhLu <YhLu at tyan.com> [040324 04:57]:
> It seems the soft reset didn't rest the MB and ...
> 
> Ollie,
> 
> Can you check that in S2885? And I think if you changed the hard_reset and
> soft_reset to bus 1, it may not rest the ht.

I've changed the reset code today so that the same code is used on all
K8+AMD8111 systems

reset.c went to southbridge/amd/amd8111/amd8111_reset.c

In the config file, you can now specify the device doing the hard reset,
instead of copy+write the reset code for every new mainboard:

default HARD_RESET_BUS=1
default HARD_RESET_DEVICE=5
default HARD_RESET_FUNCTION=0

It would be a lot nicer to find the device dynamically. Maybe that can
get fixed together with dynamically creating pirq and the other tables
some day..

The Tyan boards currently assume the 8111 reset logic is available at
following positions on the PCI bus:

     s2850 1:2.0
     s2880 1:4.0
     s2881 1:4.0
     s2882 1:4.0
     s2885 3:4.0
     s4880 1:4.0

Yinghai, is this correct?

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From ollie at lanl.gov  Wed Mar 24 10:41:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Mar 24 10:41:01 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?= S4882 support
In-Reply-To: <3174569B9743D511922F00A0C94314230466D7F2@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D7F2@TYANWEB>
Message-ID: <1080144312.25319.110.camel@exponential.lanl.gov>

On Tue, 2004-03-23 at 20:57, YhLu wrote:
> It seems the soft reset didn't rest the MB and ...
> 
> Ollie,
> 
> Can you check that in S2885? And I think if you changed the hard_reset and
> soft_reset to bus 1, it may not rest the ht.
> 

What ?? I have to change it to bus 1 to make the reset work on
S2885.

Ollie

> Regards
> 
> Yinghai Lu
> 
> -----????-----
> ???: YhLu 
> ????: 2004?3?23? 19:22
> ???: ebiederman at lnxi.com; Stefan Reinauer; ron minnich
> ??: linuxbios at clustermatic.org
> ??: S4882 support
> 
> Eric,
> 
> The ht reset in auto.c seems not thoroughly.
> 
> And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can not
> access 8111 yet).
> 
> Regards
> 
> YH
> 
> LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:33:50 PST 2004 starting...
> setting up resource map....done.
> 04 nodes initialized.
> ht reset -Ram1.00
> X?m1.01
> Ram1.02
> Ram1.03
> Ram2.00
> Ram2.01
> Ram2.02
> Ram2.03
> Ram3
> Initializing memory:  done
> Initializing memory:  done
> Initializing memory:  done
> Initializing memory:  done
> Clearing LinuxBIOS memory:  done
> Ram4
> Copying LinuxBIOS to ram.
> Jumping to LinuxBIOS.
> LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:46:40 PST 2004 booting...
> Finding PCI configuration type.
> PCI: Using configuration type 1
> Enumerating: AMD K8 Northbridge
> Enumerating: AMD K8 Northbridge
> Enumerating: AMD K8 Northbridge
> Enumerating: AMD K8 Northbridge
> Enumerating: AMD K8
> Enumerating: AMD K8
> Enumerating: AMD K8
> Enumerating: AMD K8
> Enumerating: AMD 8111
> Enumerating: Winbond w83627hf
> Enumerating buses...PCI: pci_scan_bus for bus 0
> PCI: 00:18.0 [1022/1100] enabled
> PCI: 00:18.1 [1022/1101] enabled
> PCI: 00:18.2 [1022/1102] enabled
> PCI: 00:18.3 [1022/1103] ops
> PCI: 00:18.3 [1022/1103] enabled
> PCI: 00:19.0 [1022/1100] enabled
> PCI: 00:19.1 [1022/1101] enabled
> PCI: 00:19.2 [1022/1102] enabled
> PCI: 00:19.3 [1022/1103] ops
> PCI: 00:19.3 [1022/1103] enabled
> PCI: 00:1a.0 [1022/1100] enabled
> PCI: 00:1a.1 [1022/1101] enabled
> PCI: 00:1a.2 [1022/1102] enabled
> PCI: 00:1a.3 [1022/1103] ops
> PCI: 00:1a.3 [1022/1103] enabled
> PCI: 00:1b.0 [1022/1100] enabled
> PCI: 00:1b.1 [1022/1101] enabled
> PCI: 00:1b.2 [1022/1102] enabled
> PCI: 00:1b.3 [1022/1103] ops
> PCI: 00:1b.3 [1022/1103] enabled
> amdk8_scan_chains max: 0 starting...
> Hyper transport scan link: 1 max: 1
> PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
> PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
> HyperT reset needed
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From stepan at suse.de  Wed Mar 24 10:48:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 10:48:00 2004
Subject: unreliably booting off a BCM5701.
In-Reply-To: <m365cv16ki.fsf@maxwell.lnxi.com>
References: <20040322170110.GA6915@suse.de> <20040322174456.GA9378@suse.de> <m3lllslnbx.fsf@maxwell.lnxi.com> <20040322204314.GA11093@suse.de> <m365cv16ki.fsf@maxwell.lnxi.com>
Message-ID: <20040324161117.GA5137@suse.de>

* Eric W. Biederman <ebiederman at lnxi.com> [040324 00:34]:
> Ok that is peculiar.  2.6.5rc1 has some patches to head.S which possibly
> accounts for it as soon as I have a moment I will check and see if
> that is what breaks it.  From the looks the changes to head.S should
> not break anything....
 
Ok. I'll try to investigate this later, but apparently these changes
seem to influence the situation.
 
> > No memtest yet, but filo and etherboot, and linux kernel 2.4 - When they
> > get loaded, they seem to work seamlessly...
> 
> So the etherboot and filo issues were resolved?
 
They start fine. The issues I had are still there, though. I'll build a
memtest86 and do some testing...

> > 5.3.recent?
> 
> 5.3.x is the development version, and there is some major development
> going on there to implement pxe support so I don't know what is
> going on.

Ok, I'll try going back. Can you recommend a certain version?


   Stefan

  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From firstone5 at hotmail.com  Wed Mar 24 10:53:00 2004
From: firstone5 at hotmail.com (M. Renee Hopkins)
Date: Wed Mar 24 10:53:00 2004
Subject: EPIA-M
Message-ID: <BAY10-F17tzocTiczax0001013d@hotmail.com>

I've not seen much traffic on the EPIA-M lately.

Was this performance under linuxbios and XFree86 4.3 ever tracked down?

Via Bios:
(II) VIA(0): Benchmarking video copy. Less is better.
(--) VIA(0): Timed   libc YUV420 copy... 6317080. Throughput: 56.3 MiB/s.
(--) VIA(0): Timed kernel YUV420 copy... 4732303. Throughput: 75.2 MiB/s.
(--) VIA(0): Ditch    SSE YUV420 copy... Not supported by CPU.
(--) VIA(0): Timed    MMX YUV420 copy... 3321777. Throughput: 107.1 MiB/s.
(--) VIA(0): Timed 3DNow! YUV420 copy... 3219309. Throughput: 110.5 MiB/s.
(--) VIA(0): Ditch   MMX2 YUV420 copy... Not supported by CPU.
(--) VIA(0): Timed   Ezra YUV420 copy... 3143254. Throughput: 113.2 MiB/s.
(--) VIA(0): Using Ezra YUV42X copy for video.


Linux BIos:
(II) VIA(0): Benchmarking video copy. Less is better.
(--) VIA(0): Timed   libc YUV420 copy... 17020122. Throughput: 20.9 MiB/s.
(--) VIA(0): Timed kernel YUV420 copy... 9921195. Throughput: 35.9 MiB/s.
(--) VIA(0): Ditch    SSE YUV420 copy... Not supported by CPU.
(--) VIA(0): Timed    MMX YUV420 copy... 8576428. Throughput: 41.5 MiB/s.
(--) VIA(0): Timed 3DNow! YUV420 copy... 8576433. Throughput: 41.5 MiB/s.
(--) VIA(0): Ditch   MMX2 YUV420 copy... Not supported by CPU.
(--) VIA(0): Timed   Ezra YUV420 copy... 8577055. Throughput: 41.5 MiB/s.
(--) VIA(0): Using MMX YUV42X copy for video.

I will help where I can assist..  Seems AGP isn't the same?


M.R.

_________________________________________________________________
Check out MSN PC Safety & Security to help ensure your PC is protected and 
safe. http://specials.msn.com/msn/security.asp



From ollie at lanl.gov  Wed Mar 24 10:56:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Mar 24 10:56:01 2004
Subject: ??????: S4882 support
In-Reply-To: <20040324153532.GA4404@suse.de>
References: <3174569B9743D511922F00A0C94314230466D7F2@TYANWEB>
	 <20040324153532.GA4404@suse.de>
Message-ID: <1080145126.25319.123.camel@exponential.lanl.gov>

On Wed, 2004-03-24 at 08:35, Stefan Reinauer wrote:
> * YhLu <YhLu at tyan.com> [040324 04:57]:
> > It seems the soft reset didn't rest the MB and ...
> > 
> > Ollie,
> > 
> > Can you check that in S2885? And I think if you changed the hard_reset and
> > soft_reset to bus 1, it may not rest the ht.
> 
> I've changed the reset code today so that the same code is used on all
> K8+AMD8111 systems
> 
> reset.c went to southbridge/amd/amd8111/amd8111_reset.c
> 
> In the config file, you can now specify the device doing the hard reset,
> instead of copy+write the reset code for every new mainboard:
> 
> default HARD_RESET_BUS=1
> default HARD_RESET_DEVICE=5
> default HARD_RESET_FUNCTION=0
> 

These macros are K8 specific, should we add AMDK8 in front of it ?

> It would be a lot nicer to find the device dynamically. Maybe that can
> get fixed together with dynamically creating pirq and the other tables
> some day..
> 
> The Tyan boards currently assume the 8111 reset logic is available at
> following positions on the PCI bus:
> 
>      s2850 1:2.0
>      s2880 1:4.0
>      s2881 1:4.0
>      s2882 1:4.0
>      s2885 3:4.0
>      s4880 1:4.0
> 

How do you actually determine this ? And how is this been
programmed in LinuxBIOS ?

Ollie




From stepan at suse.de  Wed Mar 24 10:58:09 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 10:58:09 2004
Subject: S4882 support
In-Reply-To: <m3k71azo6f.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230466D7DE@TYANWEB> <m3k71azo6f.fsf@maxwell.lnxi.com>
Message-ID: <20040324161916.GB5137@suse.de>

* Eric W. Biederman <ebiederman at lnxi.com> [040324 08:42]:
> Correct.  The early hypertransport initialization code is not
> complete in the 4P case.  That incompleteness triggers the later
> fixups.
 
I assume you talk about the setup of the coherent devices.

> I could not test that case, and there were at least some small
> difficulties in that it was not obvious how the 4P case should
> be extended to work properly.

Can you go a bit into detail, please?
 
> Why you are getting stuck in amdk8_scan_chains I do not currently
> understand yet.  I suspect Stefan's suggestion of a delayed reset
> is the appropriate course to implement.

Do you have an example situation that would cause the need for a 
late reset? It would sound clean to only touch this part of the system
once and at one place. If this is possible, we safe looking at 50% of
the involved code in case something goes wrong..

Stefan
  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Wed Mar 24 11:02:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 11:02:00 2004
Subject: ??????: S4882 support
In-Reply-To: <1080145126.25319.123.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230466D7F2@TYANWEB> <20040324153532.GA4404@suse.de> <1080145126.25319.123.camel@exponential.lanl.gov>
Message-ID: <20040324162627.GC5137@suse.de>

* Li-Ta Lo <ollie at lanl.gov> [040324 17:18]:
> > In the config file, you can now specify the device doing the hard reset,
> > instead of copy+write the reset code for every new mainboard:
> > 
> > default HARD_RESET_BUS=1
> > default HARD_RESET_DEVICE=5
> > default HARD_RESET_FUNCTION=0
> 
> These macros are K8 specific, should we add AMDK8 in front of it ?
 
Sounds reasonable. If we can be sure there will not be other
platforms with wandering devices on the bus.

> > The Tyan boards currently assume the 8111 reset logic is available at
> > following positions on the PCI bus:
> > 
> >      s2850 1:2.0
> >      s2880 1:4.0
> >      s2881 1:4.0
> >      s2882 1:4.0
> >      s2885 3:4.0
> >      s4880 1:4.0
> 
> How do you actually determine this ? And how is this been
> programmed in LinuxBIOS ?

This was a hardcoded value in each occurence of reset.c:hard_reset().
The device location was put into the PCI_DEV( bus, dev, fn ) macro which
is defined in the same file.
The actual value was determined by looking at the debug output of each
of the ports. The actual bus/device/function number can change depending
on the order of the bus mapping, iirc. Changes to that part of the code
made it necessary to change all of those files.
If there is a small and elegant way of finding the ISA bridge: Advanced
Micro Devices [AMD] AMD-8111 LPC device on the fly, we could get rid of
the config macros all together. This would definitely be the best
solution, since it lowers efforts to port LinuxBIOS to a new
motherboard. 

    Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From rminnich at lanl.gov  Wed Mar 24 11:04:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 24 11:04:01 2004
Subject: ??????: S4882 support
In-Reply-To: <1080145126.25319.123.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403240927040.19002-100000@maxroach.lanl.gov>

On Wed, 24 Mar 2004, Li-Ta Lo wrote:

> These macros are K8 specific, should we add AMDK8 in front of it ?

rather than spend too much time perfecting the macros, let's put the 
effort into finding the southbridge dynamically. 

There's already some of that done in some of the ports.

ron



From rminnich at lanl.gov  Wed Mar 24 11:04:12 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 24 11:04:12 2004
Subject: EPIA-M
In-Reply-To: <BAY10-F17tzocTiczax0001013d@hotmail.com>
Message-ID: <Pine.LNX.4.44.0403240927530.19002-100000@maxroach.lanl.gov>

We at LANL are wrapping up the E325 and then hope to attack the -M

ron



From stepan at suse.de  Wed Mar 24 11:07:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 11:07:01 2004
Subject: EPIA-M
In-Reply-To: <BAY10-F17tzocTiczax0001013d@hotmail.com>
References: <BAY10-F17tzocTiczax0001013d@hotmail.com>
Message-ID: <20040324162753.GD5137@suse.de>

* M. Renee Hopkins <firstone5 at hotmail.com> [040324 17:17]:
> I've not seen much traffic on the EPIA-M lately.
> 
> Was this performance under linuxbios and XFree86 4.3 ever tracked down?
> 
> Via Bios:
> (--) VIA(0): Timed   libc YUV420 copy... 6317080. Throughput: 56.3 MiB/s.
> 
> Linux BIos:
> (--) VIA(0): Timed   libc YUV420 copy... 17020122. Throughput: 20.9 MiB/s.
> 
> I will help where I can assist..  Seems AGP isn't the same?

Either that, or MTRRs are not set up correctly. Can you check that?

   Stefan


-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Wed Mar 24 11:17:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 11:17:01 2004
Subject: coherent_ht_mainboard()
Message-ID: <20040324164105.GA5285@suse.de>

Yinghai,

tyan/*/hypertransport.c contain some fixed hypertransport register 
values poked into the AMD K8 northbridge. This code was earlier called
by coherent_ht.c:setup_coherent_ht_domain() but I removed the call some
time ago, since I could not see why it is still needed. Does this code
provide any crucial functionality that can't be realized in the dynamic
code of the current CVS tree?

If not, I suggest we drop this code. 

The same thing could btw work for the different versions of
resourcemap.c. The biggest reason for the split off here was that the
default resource map did always assume the AMD8111 southbridge on link0
which is not always true. This is fixed by now. 
The bus numbers should meanwhile be entered correctly by the generic
code.
So, we could reduce the amount of involved code a lot, flattening out
all the nasty exceptions we invented to bend the rules..

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From ollie at lanl.gov  Wed Mar 24 11:30:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Mar 24 11:30:01 2004
Subject: ??????: S4882 support
In-Reply-To: <20040324162627.GC5137@suse.de>
References: <3174569B9743D511922F00A0C94314230466D7F2@TYANWEB>
	 <20040324153532.GA4404@suse.de>
	 <1080145126.25319.123.camel@exponential.lanl.gov>
	 <20040324162627.GC5137@suse.de>
Message-ID: <1080147264.25319.147.camel@exponential.lanl.gov>

On Wed, 2004-03-24 at 09:26, Stefan Reinauer wrote:
> 
> This was a hardcoded value in each occurence of reset.c:hard_reset().
> The device location was put into the PCI_DEV( bus, dev, fn ) macro which
> is defined in the same file.
> The actual value was determined by looking at the debug output of each
> of the ports. The actual bus/device/function number can change depending
> on the order of the bus mapping, iirc. Changes to that part of the code
> made it necessary to change all of those files.
> If there is a small and elegant way of finding the ISA bridge: Advanced
> Micro Devices [AMD] AMD-8111 LPC device on the fly, we could get rid of
> the config macros all together. This would definitely be the best
> solution, since it lowers efforts to port LinuxBIOS to a new
> motherboard. 
> 

There was a function called coherent_ht_mainboard. Is it no longer used
?

Ollie




From ollie at lanl.gov  Wed Mar 24 11:33:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Mar 24 11:33:01 2004
Subject: coherent_ht_mainboard()
In-Reply-To: <20040324164105.GA5285@suse.de>
References: <20040324164105.GA5285@suse.de>
Message-ID: <1080147403.25319.149.camel@exponential.lanl.gov>

On Wed, 2004-03-24 at 09:41, Stefan Reinauer wrote:
> Yinghai,
> 
> tyan/*/hypertransport.c contain some fixed hypertransport register 
> values poked into the AMD K8 northbridge. This code was earlier called
> by coherent_ht.c:setup_coherent_ht_domain() but I removed the call some
> time ago, since I could not see why it is still needed. Does this code
> provide any crucial functionality that can't be realized in the dynamic
> code of the current CVS tree?
> 
> If not, I suggest we drop this code. 
> 
> The same thing could btw work for the different versions of
> resourcemap.c. The biggest reason for the split off here was that the
> default resource map did always assume the AMD8111 southbridge on link0
> which is not always true. This is fixed by now. 
> The bus numbers should meanwhile be entered correctly by the generic
> code.
> So, we could reduce the amount of involved code a lot, flattening out
> all the nasty exceptions we invented to bend the rules..
> 

Can you tell me in which file you did obth of these ?

Ollie

>   Stefan



From stepan at suse.de  Wed Mar 24 11:39:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 11:39:01 2004
Subject: ??????: S4882 support
In-Reply-To: <1080147264.25319.147.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230466D7F2@TYANWEB> <20040324153532.GA4404@suse.de> <1080145126.25319.123.camel@exponential.lanl.gov> <20040324162627.GC5137@suse.de> <1080147264.25319.147.camel@exponential.lanl.gov>
Message-ID: <20040324170127.GA5721@suse.de>

* Li-Ta Lo <ollie at lanl.gov> [040324 17:54]:
> There was a function called coherent_ht_mainboard. Is it no longer
> used?

Yes. It was never used by any port but the tyan boards, and the code did
some ht link setup. The functionality this code added (like optimizing
hypertransport link speed) is done by the generic k8 code since quite a
while. The functions are still there, tyan/*/hypertransport.c, but they
are no longer called.

Stefan
  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From YhLu at tyan.com  Wed Mar 24 12:04:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 12:04:01 2004
Subject: =?gb2312?B?tPC4tDogPz8/Pz8/OiBTNDg4MiBzdXBwb3J0?=
Message-ID: <3174569B9743D511922F00A0C94314230466D801@TYANWEB>

That's right.

YH

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?24? 7:36
???: YhLu
??: ebiederman at lnxi.com; ron minnich; linuxbios at clustermatic.org
??: Re: ??????: S4882 support

* YhLu <YhLu at tyan.com> [040324 04:57]:
> It seems the soft reset didn't rest the MB and ...
> 
> Ollie,
> 
> Can you check that in S2885? And I think if you changed the hard_reset and
> soft_reset to bus 1, it may not rest the ht.

I've changed the reset code today so that the same code is used on all
K8+AMD8111 systems

reset.c went to southbridge/amd/amd8111/amd8111_reset.c

In the config file, you can now specify the device doing the hard reset,
instead of copy+write the reset code for every new mainboard:

default HARD_RESET_BUS=1
default HARD_RESET_DEVICE=5
default HARD_RESET_FUNCTION=0

It would be a lot nicer to find the device dynamically. Maybe that can
get fixed together with dynamically creating pirq and the other tables
some day..

The Tyan boards currently assume the 8111 reset logic is available at
following positions on the PCI bus:

     s2850 1:2.0
     s2880 1:4.0
     s2881 1:4.0
     s2882 1:4.0
     s2885 3:4.0
     s4880 1:4.0

Yinghai, is this correct?

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From YhLu at tyan.com  Wed Mar 24 12:07:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 12:07:00 2004
Subject: =?utf-8?B?562U5aSNOiDnrZTlpI06IFM0ODgyIHN1cHBvcnQ=?=
Message-ID: <3174569B9743D511922F00A0C94314230466D803@TYANWEB>

 There is some dump_pci_devices in auto.c of s2885, you can enable that to
see if amd8111 LPC is 1:4.0

Regards

YH

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?24? 8:05
???: YhLu
??: ebiederman at lnxi.com; Stefan Reinauer; ron minnich; LinuxBIOS
??: Re: ??: S4882 support

On Tue, 2004-03-23 at 20:57, YhLu wrote:
> It seems the soft reset didn't rest the MB and ...
> 
> Ollie,
> 
> Can you check that in S2885? And I think if you changed the hard_reset and
> soft_reset to bus 1, it may not rest the ht.
> 

What ?? I have to change it to bus 1 to make the reset work on
S2885.

Ollie

> Regards
> 
> Yinghai Lu
> 
> -----????-----
> ???: YhLu 
> ????: 2004?3?23? 19:22
> ???: ebiederman at lnxi.com; Stefan Reinauer; ron minnich
> ??: linuxbios at clustermatic.org
> ??: S4882 support
> 
> Eric,
> 
> The ht reset in auto.c seems not thoroughly.
> 
> And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can
not
> access 8111 yet).
> 
> Regards
> 
> YH
> 
> LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:33:50 PST 2004 starting...
> setting up resource map....done.
> 04 nodes initialized.
> ht reset -Ram1.00
> X?m1.01
> Ram1.02
> Ram1.03
> Ram2.00
> Ram2.01
> Ram2.02
> Ram2.03
> Ram3
> Initializing memory:  done
> Initializing memory:  done
> Initializing memory:  done
> Initializing memory:  done
> Clearing LinuxBIOS memory:  done
> Ram4
> Copying LinuxBIOS to ram.
> Jumping to LinuxBIOS.
> LinuxBIOS-1.1.62.0_Normal Tue Mar 23 17:46:40 PST 2004 booting...
> Finding PCI configuration type.
> PCI: Using configuration type 1
> Enumerating: AMD K8 Northbridge
> Enumerating: AMD K8 Northbridge
> Enumerating: AMD K8 Northbridge
> Enumerating: AMD K8 Northbridge
> Enumerating: AMD K8
> Enumerating: AMD K8
> Enumerating: AMD K8
> Enumerating: AMD K8
> Enumerating: AMD 8111
> Enumerating: Winbond w83627hf
> Enumerating buses...PCI: pci_scan_bus for bus 0
> PCI: 00:18.0 [1022/1100] enabled
> PCI: 00:18.1 [1022/1101] enabled
> PCI: 00:18.2 [1022/1102] enabled
> PCI: 00:18.3 [1022/1103] ops
> PCI: 00:18.3 [1022/1103] enabled
> PCI: 00:19.0 [1022/1100] enabled
> PCI: 00:19.1 [1022/1101] enabled
> PCI: 00:19.2 [1022/1102] enabled
> PCI: 00:19.3 [1022/1103] ops
> PCI: 00:19.3 [1022/1103] enabled
> PCI: 00:1a.0 [1022/1100] enabled
> PCI: 00:1a.1 [1022/1101] enabled
> PCI: 00:1a.2 [1022/1102] enabled
> PCI: 00:1a.3 [1022/1103] ops
> PCI: 00:1a.3 [1022/1103] enabled
> PCI: 00:1b.0 [1022/1100] enabled
> PCI: 00:1b.1 [1022/1101] enabled
> PCI: 00:1b.2 [1022/1102] enabled
> PCI: 00:1b.3 [1022/1103] ops
> PCI: 00:1b.3 [1022/1103] enabled
> amdk8_scan_chains max: 0 starting...
> Hyper transport scan link: 1 max: 1
> PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
> PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
> HyperT reset needed
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 


From stepan at suse.de  Wed Mar 24 12:08:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 12:08:00 2004
Subject: dynamic hypertransport links
Message-ID: <20040324173151.GA6687@suse.de>

In the progress of getting hypertransport setup completely dynamic, I
made the following patch that completely gets rid of the CONNECTION
and link name macros in coherent_ht.c
(UP, ACROSS, DOWN and CONNECTION_0_1, CONNECTION_0_2, CONNECTION_1_3)
Therefore I added two simple helper functions that gain the needed
information from generate_row().
This patch probably raises the register pressure during ht setup, but
even on a 4p machine I could not see any problems with romcc. 
Dropping another couple of hardcodes seems like the right thing to
do[tm].

If nobody is opposing, I am going to check this into CVS.

  Stefan


-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development
-------------- next part --------------
Index: coherent_ht.c
===================================================================
RCS file: /cvsroot/freebios/freebios2/src/northbridge/amd/amdk8/coherent_ht.c,v
retrieving revision 1.23
diff -u -r1.23 coherent_ht.c
--- coherent_ht.c	12 Mar 2004 12:18:25 -0000	1.23
+++ coherent_ht.c	24 Mar 2004 17:15:55 -0000
@@ -20,33 +20,6 @@
 #include "arch/romcc_io.h"
 #include "amdk8.h"
 
-/*
- * Until we have a completely dynamic setup we want
- * to be able to map different cpu graphs.
- */
-
-#define UP	0x00
-#define ACROSS	0x20
-#define DOWN	0x40
-
-/* 
- * set some default values. These are used if they are not
- * differently defined in the motherboard's auto.c file.
- * See src/mainboard/amd/quartet/auto.c for an example.
- */
-
-#ifndef CONNECTION_0_1 
-#define CONNECTION_0_1 ACROSS
-#endif
-
-#ifndef CONNECTION_0_2 
-#define CONNECTION_0_2 UP
-#endif
-
-#ifndef CONNECTION_1_3 
-#define CONNECTION_1_3 UP
-#endif
-
 /* when generating a temporary row configuration we
  * don't want broadcast to be enabled for that node.
  */
@@ -68,6 +41,34 @@
 #define TRUE  (-1)
 #define FALSE (0)
 
+static u8 link_to_register(int ldt)
+{
+	/*
+	 * [ 0: 3] Request Route
+	 *     [0] Route to this node
+	 *     [1] Route to Link 0
+	 *     [2] Route to Link 1
+	 *     [3] Route to Link 2
+	 */
+
+	if (ldt&0x08) return 0x40;
+	if (ldt&0x04) return 0x20;
+	if (ldt&0x02) return 0x00;
+	
+	/* we should never get here */
+	print_debug("Unknown Link\n");
+	return 0;
+}
+
+static int link_connection(int src, int dest)
+{
+	/* we generate the needed link information from the rows
+	 * by taking the Request Route of the according row.
+	 */
+	
+	return generate_row(src, dest, CONFIG_MAX_CPUS) & 0x0f;
+}
+
 static void disable_probes(void)
 {
 	/* disable read/write/fill probes for uniprocessor setup
@@ -367,7 +368,7 @@
 	/* Setup and check a temporary connection to node 1 */
 	setup_temp_row(0, 1, result.cpus);
 	
-	if (!check_connection(0, 7, CONNECTION_0_1)) {
+	if (!check_connection(0, 7, link_to_register(link_connection(0,1)))) {
 		print_debug("No connection to Node 1.\r\n");
 		clear_temp_row(0);	/* delete temp connection */
 		setup_uniprocessor();	/* and get up working     */
@@ -376,8 +377,10 @@
 	}
 
 	/* We found 2 nodes so far */
-	result.needs_reset = 
-		optimize_connection(NODE_HT(0), 0x80 + CONNECTION_0_1, NODE_HT(7), 0x80 + CONNECTION_0_1);
+	result.needs_reset = optimize_connection(
+		NODE_HT(0), 0x80 + link_to_register(link_connection(0,1)),
+		NODE_HT(7), 0x80 + link_to_register(link_connection(1,0)) );
+		
 	setup_node(0, result.cpus);	/* Node 1 is there. Setup Node 0 correctly */
 	setup_remote_node(1, result.cpus);  /* Setup the routes on the remote node */
         rename_temp_node(1);    /* Rename Node 7 to Node 1  */
@@ -391,7 +394,7 @@
 	/* Setup and check temporary connection from Node 0 to Node 2 */
 	setup_temp_row(0,2, result.cpus);
 
-	if (!check_connection(0, 7, CONNECTION_0_2)) {
+	if (!check_connection(0, 7, link_to_register(link_connection(0,2))) ) {
 		print_debug("No connection to Node 2.\r\n");
 		clear_temp_row(0);	 /* delete temp connection */
 		result.cpus = 2;
@@ -405,7 +408,7 @@
 	setup_temp_row(0,1, result.cpus); /* temp. link between nodes 0 and 1 */
 	setup_temp_row(1,3, result.cpus); /* temp. link between nodes 1 and 3 */
 
-	if (!check_connection(1, 7, CONNECTION_1_3)) {
+	if (!check_connection(1, 7, link_to_register(link_connection(1,3)))) {
 		print_debug("No connection to Node 3.\r\n");
 		clear_temp_row(0);	 /* delete temp connection */
 		clear_temp_row(1);	 /* delete temp connection */

From YhLu at tyan.com  Wed Mar 24 12:08:59 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 12:08:59 2004
Subject: =?gb2312?B?tPC4tDogY29oZXJlbnRfaHRfbWFpbmJvYXJkKCk=?=
Message-ID: <3174569B9743D511922F00A0C94314230466D804@TYANWEB>

The dynamic code does not work on 4 way MB, I have found out why the s4882
can not soft_reset.

The HT-link between is not properly init properly.

If the dynamic code can init the coherent-ht properly, We can remove
hypertransport.c

Regards

YH

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?24? 8:41
???: YhLu
??: linuxbios at clustermatic.org
??: coherent_ht_mainboard()

Yinghai,

tyan/*/hypertransport.c contain some fixed hypertransport register 
values poked into the AMD K8 northbridge. This code was earlier called
by coherent_ht.c:setup_coherent_ht_domain() but I removed the call some
time ago, since I could not see why it is still needed. Does this code
provide any crucial functionality that can't be realized in the dynamic
code of the current CVS tree?

If not, I suggest we drop this code. 

The same thing could btw work for the different versions of
resourcemap.c. The biggest reason for the split off here was that the
default resource map did always assume the AMD8111 southbridge on link0
which is not always true. This is fixed by now. 
The bus numbers should meanwhile be entered correctly by the generic
code.
So, we could reduce the amount of involved code a lot, flattening out
all the nasty exceptions we invented to bend the rules..

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From rminnich at lanl.gov  Wed Mar 24 12:11:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 24 12:11:01 2004
Subject: dynamic hypertransport links
In-Reply-To: <20040324173151.GA6687@suse.de>
Message-ID: <Pine.LNX.4.44.0403241034310.19002-100000@maxroach.lanl.gov>

On Wed, 24 Mar 2004, Stefan Reinauer wrote:

> If nobody is opposing, I am going to check this into CVS.

I like it.

ron



From YhLu at tyan.com  Wed Mar 24 12:13:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 12:13:01 2004
Subject: S4882 support
Message-ID: <3174569B9743D511922F00A0C94314230466D807@TYANWEB>

Eric, 

After check 84/a4/c4, 88/a8/c8 of function 1 of K8 northbridge, the link
speed/width is not init properly.

Regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?23? 23:42
???: YhLu
??: Stefan Reinauer; ron minnich; linuxbios at clustermatic.org
??: Re: S4882 support

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> The ht reset in auto.c seems not thoroughly.
> 
> And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can
not
> access 8111 yet).

Correct.  The early hypertransport initialization code is not
complete in the 4P case.  That incompleteness triggers the later
fixups.

I could not test that case, and there were at least some small
difficulties in that it was not obvious how the 4P case should
be extended to work properly.

Why you are getting stuck in amdk8_scan_chains I do not currently
understand yet.  I suspect Stefan's suggestion of a delayed reset
is the appropriate course to implement.

Eric


From YhLu at tyan.com  Wed Mar 24 12:15:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 12:15:01 2004
Subject: =?gb2312?B?tPC4tDogZHluYW1pYyBoeXBlcnRyYW5zcG9ydCBsaW5rcw==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D808@TYANWEB>

Great, I will try it right now.

Anyway

Ldt0 = up
Ldt1 = across
Adt2 = down 

It that right?

Regards

YH.

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?24? 9:32
???: LinuxBIOS Experts
??: dynamic hypertransport links

In the progress of getting hypertransport setup completely dynamic, I
made the following patch that completely gets rid of the CONNECTION
and link name macros in coherent_ht.c
(UP, ACROSS, DOWN and CONNECTION_0_1, CONNECTION_0_2, CONNECTION_1_3)
Therefore I added two simple helper functions that gain the needed
information from generate_row().
This patch probably raises the register pressure during ht setup, but
even on a 4p machine I could not see any problems with romcc. 
Dropping another couple of hardcodes seems like the right thing to
do[tm].

If nobody is opposing, I am going to check this into CVS.

  Stefan


-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Wed Mar 24 12:15:15 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 12:15:15 2004
Subject: ????: coherent_ht_mainboard()
In-Reply-To: <3174569B9743D511922F00A0C94314230466D804@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D804@TYANWEB>
Message-ID: <20040324173659.GA6746@suse.de>

* YhLu <YhLu at tyan.com> [040324 18:39]:
> The dynamic code does not work on 4 way MB, I have found out why the s4882
> can not soft_reset.
> 
> The HT-link between is not properly init properly.

Which link is this? CPU0->AMD8111?
I seemed to have no problems on quartet with 1.1.5, which is 4 way as
well.
Have you been able to track the problem down to a certain function/flaw?

> If the dynamic code can init the coherent-ht properly, We can remove
> hypertransport.c

good.
  
  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From ollie at lanl.gov  Wed Mar 24 12:15:25 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Mar 24 12:15:25 2004
Subject: S4882 support
In-Reply-To: <3174569B9743D511922F00A0C94314230466D807@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D807@TYANWEB>
Message-ID: <1080149953.25319.151.camel@exponential.lanl.gov>

On Wed, 2004-03-24 at 10:43, YhLu wrote:
> Eric, 
> 
> After check 84/a4/c4, 88/a8/c8 of function 1 of K8 northbridge, the link
> speed/width is not init properly.
> 

Is it function 0 ?

Ollie

> Regards
> 
> YH
> 
> -----????-----
> ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
> ????: 2004?3?23? 23:42
> ???: YhLu
> ??: Stefan Reinauer; ron minnich; linuxbios at clustermatic.org
> ??: Re: S4882 support
> 
> YhLu <YhLu at tyan.com> writes:
> 
> > Eric,
> > 
> > The ht reset in auto.c seems not thoroughly.
> > 
> > And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can
> not
> > access 8111 yet).
> 
> Correct.  The early hypertransport initialization code is not
> complete in the 4P case.  That incompleteness triggers the later
> fixups.
> 
> I could not test that case, and there were at least some small
> difficulties in that it was not obvious how the 4P case should
> be extended to work properly.
> 
> Why you are getting stuck in amdk8_scan_chains I do not currently
> understand yet.  I suspect Stefan's suggestion of a delayed reset
> is the appropriate course to implement.
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From stepan at suse.de  Wed Mar 24 12:20:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 12:20:01 2004
Subject: S4882 support
In-Reply-To: <3174569B9743D511922F00A0C94314230466D807@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D807@TYANWEB>
Message-ID: <20040324174432.GA6840@suse.de>

* YhLu <YhLu at tyan.com> [040324 18:43]:
> After check 84/a4/c4, 88/a8/c8 of function 1 of K8 northbridge, the link
> speed/width is not init properly.

Between which devices?

It seems that the current HT code (before my dynamic changes) is doing a
wrong assumption when optimizing the connections, that is only right on
the HDAMA. I fixed this a while ago, but it seems, this drowned in the
last big merge of 1.1.6. 
The assumption is that CPU0 and CPU1 are interconnected using the same
link on both CPUs:
optimize_connection(NODE_HT(0), 0x80 + CONNECTION_0_1, NODE_HT(7), 0x80 + CONNECTION_0_1);
The second link specified in the function call has to be from CPU 1 to
0, not from 0 to 1 as the first link. This happens to not matter on
HDAMA, but basically on all other machines. My dynamic connections diff
should fix this (even though it is not optimizing link speed between the
other CPUs yet).

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Wed Mar 24 12:25:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 12:25:01 2004
Subject: ????: dynamic hypertransport links
In-Reply-To: <3174569B9743D511922F00A0C94314230466D808@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D808@TYANWEB>
Message-ID: <20040324174847.GA6878@suse.de>

* YhLu <YhLu at tyan.com> [040324 18:45]:
> Great, I will try it right now.
> 
> Anyway
> 
> Ldt0 = up
> Ldt1 = across
> Adt2 = down 
> 
> It that right?

That is at least the calling scheme I've been using when I wrote the
coherent hypertransport setup code originally. Looks right..

  Stefan

  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From YhLu at tyan.com  Wed Mar 24 12:25:13 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 12:25:13 2004
Subject: =?gb2312?B?tPC4tDogPz8/PzogY29oZXJlbnRfaHRfbWFpbmJvYXJkKCk=?=
Message-ID: <3174569B9743D511922F00A0C94314230466D80E@TYANWEB>

The CPU0->AMD8131->AMD8111 is right.

The link CPU0 to CPU1:  in CPU0 side(link0) is 16x600 and CPU1 side(link0)
is 16x800

All others is 8x200.

The coherent should be all 16x1000

I will try your patch and dig it out.

Regards

YH.

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?24? 9:37
???: YhLu
??: linuxbios at clustermatic.org
??: Re: ????: coherent_ht_mainboard()

* YhLu <YhLu at tyan.com> [040324 18:39]:
> The dynamic code does not work on 4 way MB, I have found out why the s4882
> can not soft_reset.
> 
> The HT-link between is not properly init properly.

Which link is this? CPU0->AMD8111?
I seemed to have no problems on quartet with 1.1.5, which is 4 way as
well.
Have you been able to track the problem down to a certain function/flaw?

> If the dynamic code can init the coherent-ht properly, We can remove
> hypertransport.c

good.
  
  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From YhLu at tyan.com  Wed Mar 24 12:25:24 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 12:25:24 2004
Subject: =?gb2312?B?tPC4tDogUzQ4ODIgc3VwcG9ydA==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D80F@TYANWEB>

Sorry it is function 0.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?24? 9:39
???: YhLu
??: ebiederman at lnxi.com; Stefan Reinauer; ron minnich; LinuxBIOS
??: re: S4882 support

On Wed, 2004-03-24 at 10:43, YhLu wrote:
> Eric, 
> 
> After check 84/a4/c4, 88/a8/c8 of function 1 of K8 northbridge, the link
> speed/width is not init properly.
> 

Is it function 0 ?

Ollie

> Regards
> 
> YH
> 
> -----????-----
> ???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
> ????: 2004?3?23? 23:42
> ???: YhLu
> ??: Stefan Reinauer; ron minnich; linuxbios at clustermatic.org
> ??: Re: S4882 support
> 
> YhLu <YhLu at tyan.com> writes:
> 
> > Eric,
> > 
> > The ht reset in auto.c seems not thoroughly.
> > 
> > And it will stuck at hard_reset in amdk8_scan_chains. ( at this time can
> not
> > access 8111 yet).
> 
> Correct.  The early hypertransport initialization code is not
> complete in the 4P case.  That incompleteness triggers the later
> fixups.
> 
> I could not test that case, and there were at least some small
> difficulties in that it was not obvious how the 4P case should
> be extended to work properly.
> 
> Why you are getting stuck in amdk8_scan_chains I do not currently
> understand yet.  I suspect Stefan's suggestion of a delayed reset
> is the appropriate course to implement.
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 


From YhLu at tyan.com  Wed Mar 24 12:59:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 12:59:01 2004
Subject: =?gb2312?B?tPC4tDogPz8/PzogZHluYW1pYyBoeXBlcnRyYW5zcG9ydCBsaW5r?=
	=?gb2312?B?cw==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D81F@TYANWEB>

The Patch remove the define CONNECTION...

But the link is still not initialized right.

Regards

Yinghai Lu

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?24? 9:49
???: YhLu
??: LinuxBIOS Experts
??: Re: ????: dynamic hypertransport links

* YhLu <YhLu at tyan.com> [040324 18:45]:
> Great, I will try it right now.
> 
> Anyway
> 
> Ldt0 = up
> Ldt1 = across
> Adt2 = down 
> 
> It that right?

That is at least the calling scheme I've been using when I wrote the
coherent hypertransport setup code originally. Looks right..

  Stefan

  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From ebiederman at lnxi.com  Wed Mar 24 13:05:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Mar 24 13:05:01 2004
Subject: S4882 support
In-Reply-To: <20040324161916.GB5137@suse.de>
References: <3174569B9743D511922F00A0C94314230466D7DE@TYANWEB>
	<m3k71azo6f.fsf@maxwell.lnxi.com> <20040324161916.GB5137@suse.de>
Message-ID: <m33c7yxf9m.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [040324 08:42]:
> > Correct.  The early hypertransport initialization code is not
> > complete in the 4P case.  That incompleteness triggers the later
> > fixups.
>  
> I assume you talk about the setup of the coherent devices.

Yes, I was.  Although it should only be incomplete incoherent 
HT that would cause this.

> > I could not test that case, and there were at least some small
> > difficulties in that it was not obvious how the 4P case should
> > be extended to work properly.
> 
> Can you go a bit into detail, please?

Mostly I could not clearly see which links I needed to call optimize_connection()
on.

> > Why you are getting stuck in amdk8_scan_chains I do not currently
> > understand yet.  I suspect Stefan's suggestion of a delayed reset
> > is the appropriate course to implement.
> 
> Do you have an example situation that would cause the need for a 
> late reset? It would sound clean to only touch this part of the system
> once and at one place. If this is possible, we safe looking at 50% of
> the involved code in case something goes wrong..

2 or more HT I/O chains that are not setup at boot time.

Eric


From YhLu at tyan.com  Wed Mar 24 13:07:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 13:07:00 2004
Subject: is_cpu_pre_c0()
Message-ID: <3174569B9743D511922F00A0C94314230466D825@TYANWEB>

Can we change is_cpu_pre_c0() to global macro define 

I think most K8 is C0 after.

And I can not include debug info  (MAX...._LOGLEVEL=8). The linuxbis image
is more than 65536.

Regards

YH


From ebiederman at lnxi.com  Wed Mar 24 13:09:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Mar 24 13:09:01 2004
Subject: dynamic hypertransport links
In-Reply-To: <20040324173151.GA6687@suse.de>
References: <20040324173151.GA6687@suse.de>
Message-ID: <m3oeqmulwq.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> In the progress of getting hypertransport setup completely dynamic, I
> made the following patch that completely gets rid of the CONNECTION
> and link name macros in coherent_ht.c
> (UP, ACROSS, DOWN and CONNECTION_0_1, CONNECTION_0_2, CONNECTION_1_3)
> Therefore I added two simple helper functions that gain the needed
> information from generate_row().
> This patch probably raises the register pressure during ht setup, but
> even on a 4p machine I could not see any problems with romcc. 
> Dropping another couple of hardcodes seems like the right thing to
> do[tm].
> 
> If nobody is opposing, I am going to check this into CVS.

If that works and compiles it should certainly make things much
less error prone.

Eric


From ebiederman at lnxi.com  Wed Mar 24 13:15:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Mar 24 13:15:01 2004
Subject: =?gb2312?b?tPC4tA==?=: coherent_ht_mainboard()
In-Reply-To: <3174569B9743D511922F00A0C94314230466D804@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D804@TYANWEB>
Message-ID: <m3k71aulmn.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> The dynamic code does not work on 4 way MB, I have found out why the s4882
> can not soft_reset.
> 
> The HT-link between is not properly init properly.
> 
> If the dynamic code can init the coherent-ht properly, We can remove
> hypertransport.c

hypertransport.c can become a noop I agree but there are systems like:
http://www.970eval.com/ where we will need it for the ppc.  And there
may be other even more interesting cases.

So I continue to see hypertansport.c as normative.  The rest of the
places as just optimizations.  Though I am completely in favor of
increasing the code sharing between hypertransport.c and
incoherent_ht.c

Eric



From stepan at suse.de  Wed Mar 24 13:22:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 13:22:01 2004
Subject: S4882 support
In-Reply-To: <m33c7yxf9m.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230466D7DE@TYANWEB> <m3k71azo6f.fsf@maxwell.lnxi.com> <20040324161916.GB5137@suse.de> <m33c7yxf9m.fsf@maxwell.lnxi.com>
Message-ID: <20040324184426.GA7064@suse.de>

* Eric W. Biederman <ebiederman at lnxi.com> [040324 19:37]:
> Mostly I could not clearly see which links I needed to call
> optimize_connection() on.
 
Ah. I think we can now safely get this information from generate_row.

> > Do you have an example situation that would cause the need for a 
> > late reset? It would sound clean to only touch this part of the system
> > once and at one place. If this is possible, we safe looking at 50% of
> > the involved code in case something goes wrong..
> 
> 2 or more HT I/O chains that are not setup at boot time.

Does this imply that incoherent ht setup has to be called every time a
new cpu is enabled, to see whether there are bridges connected to this
cpu?

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Wed Mar 24 13:24:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 13:24:01 2004
Subject: ????: coherent_ht_mainboard()
In-Reply-To: <m3k71aulmn.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230466D804@TYANWEB> <m3k71aulmn.fsf@maxwell.lnxi.com>
Message-ID: <20040324184721.GB7064@suse.de>

* Eric W. Biederman <ebiederman at lnxi.com> [040324 19:48]:
> hypertransport.c can become a noop I agree but there are systems like:
> http://www.970eval.com/ where we will need it for the ppc.  And there
> may be other even more interesting cases.
> 
> So I continue to see hypertansport.c as normative.  The rest of the
> places as just optimizations.  Though I am completely in favor of
> increasing the code sharing between hypertransport.c and
> incoherent_ht.c
  
I think you mean coherent_ht.c and incoherent_ht.c? hypertransport.c is
only available for tyan boards and contains the hardcodes for link setup
on those tyan boards. coherent_ht.c and incoherent_ht.c are both needed
and more than unlikely to go away, i agree.
Correct me if I misunderstood.

Stefan
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From YhLu at tyan.com  Wed Mar 24 13:28:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 13:28:01 2004
Subject: =?gb2312?B?tPC4tDogPz8/PzogY29oZXJlbnRfaHRfbWFpbmJvYXJkKCk=?=
Message-ID: <3174569B9743D511922F00A0C94314230466D827@TYANWEB>

The optimize_link make 
The link CPU0 to CPU1:  in CPU0 side(link0) is 16x800 and CPU1 side(link0)
is 16x800

but the scan_ht_chain change CPU0 side(link0) is 16x600

it must think it is connected to 8111 or something.

YH.

-----????-----
???: YhLu 
????: 2004?3?24? 9:56
???: Stefan Reinauer
??: linuxbios at clustermatic.org
??: ??: ????: coherent_ht_mainboard()

The CPU0->AMD8131->AMD8111 is right.

The link CPU0 to CPU1:  in CPU0 side(link0) is 16x600 and CPU1 side(link0)
is 16x800

All others is 8x200.

The coherent should be all 16x1000

I will try your patch and dig it out.

Regards

YH.

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?24? 9:37
???: YhLu
??: linuxbios at clustermatic.org
??: Re: ????: coherent_ht_mainboard()

* YhLu <YhLu at tyan.com> [040324 18:39]:
> The dynamic code does not work on 4 way MB, I have found out why the s4882
> can not soft_reset.
> 
> The HT-link between is not properly init properly.

Which link is this? CPU0->AMD8111?
I seemed to have no problems on quartet with 1.1.5, which is 4 way as
well.
Have you been able to track the problem down to a certain function/flaw?

> If the dynamic code can init the coherent-ht properly, We can remove
> hypertransport.c

good.
  
  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From ebiederman at lnxi.com  Wed Mar 24 13:34:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Mar 24 13:34:01 2004
Subject: ??????: S4882 support
In-Reply-To: <Pine.LNX.4.44.0403240927040.19002-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403240927040.19002-100000@maxroach.lanl.gov>
Message-ID: <m3ekriuksj.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Wed, 24 Mar 2004, Li-Ta Lo wrote:
> 
> > These macros are K8 specific, should we add AMDK8 in front of it ?
> 
> rather than spend too much time perfecting the macros, let's put the 
> effort into finding the southbridge dynamically. 
> 
> There's already some of that done in some of the ports.

There are 2 places we use the hard_reset code.

1) Right at the top of hardwaremain.c before enumerate_static_devices
   in case we get into LinuxBIOS for some odd reason.  Say the OS's wants
   to do a reboot.
2) In device/hypertransport.c where we to do something to get the HT settings
   on an I/O chain to go into effect.

The easiest thing to do is a global flag that says we need to reset
the system in hypertransport.c and then to put all of the reset code
after dev_enumerate.

There are still some details there to be worked out, but...

Eric


From ebiederman at lnxi.com  Wed Mar 24 13:39:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Mar 24 13:39:00 2004
Subject: is_cpu_pre_c0()
In-Reply-To: <3174569B9743D511922F00A0C94314230466D825@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D825@TYANWEB>
Message-ID: <m31xnit5yz.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Can we change is_cpu_pre_c0() to global macro define 
> 
> I think most K8 is C0 after.

B3 stepping CPUs shipped in production and Ron Minnich has a large
cluster of them.  Anything earlier than B3 we can safely ignore.

I guess I don't see a problem with that.

> And I can not include debug info  (MAX...._LOGLEVEL=8). The linuxbis image
> is more than 65536.

That is a major challenge.  I have a back burner project to make romcc not
inline all function calls.  But until I do that I don't know of a good
way to reduce the code size.

Eric


From ebiederman at lnxi.com  Wed Mar 24 13:45:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Mar 24 13:45:00 2004
Subject: ????: coherent_ht_mainboard()
In-Reply-To: <20040324184721.GB7064@suse.de>
References: <3174569B9743D511922F00A0C94314230466D804@TYANWEB>
	<m3k71aulmn.fsf@maxwell.lnxi.com> <20040324184721.GB7064@suse.de>
Message-ID: <m3wu5arr3z.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * Eric W. Biederman <ebiederman at lnxi.com> [040324 19:48]:
> > hypertransport.c can become a noop I agree but there are systems like:
> > http://www.970eval.com/ where we will need it for the ppc.  And there
> > may be other even more interesting cases.
> > 
> > So I continue to see hypertansport.c as normative.  The rest of the
> > places as just optimizations.  Though I am completely in favor of
> > increasing the code sharing between hypertransport.c and
> > incoherent_ht.c
>
>
> I think you mean coherent_ht.c and incoherent_ht.c? 

I mean devices/hypertransport.c and northbridge/amd/amdk8/incoherent_ht.c

> hypertransport.c is
> only available for tyan boards and contains the hardcodes for link setup
> on those tyan boards. 

mainbaord/tyan/*/hypertansport.c can go away yes.  Which may
have been the original suggestion.
 
devices/hypertransport.c remain and is normative.  
If incoherent_ht.c messes or is not general enough it catches
it.

> coherent_ht.c and incoherent_ht.c are both needed
> and more than unlikely to go away, i agree.
> Correct me if I misunderstood.

Hopefully I have.  Too many pieces not enough names :)

Eric


From ebiederman at lnxi.com  Wed Mar 24 13:47:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Mar 24 13:47:00 2004
Subject: =?gb2312?b?tPC4tA==?=: ????: coherent_ht_mainboard()
In-Reply-To: <3174569B9743D511922F00A0C94314230466D80E@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D80E@TYANWEB>
Message-ID: <m3u10err1q.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> The CPU0->AMD8131->AMD8111 is right.
> 
> The link CPU0 to CPU1:  in CPU0 side(link0) is 16x600 and CPU1 side(link0)
> is 16x800
> 
> All others is 8x200.
> 
> The coherent should be all 16x1000

Does AMD really support 1Ghz Operation between CPUs?  If so I am
fine with this.  Otherwise I have not seen any significant benchmarking
differences so I would mask out the 1Ghz capability...
 
Eric


From YhLu at tyan.com  Wed Mar 24 13:49:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 13:49:01 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogPz8/PzogY29oZXJlbnRfaHRfbWFpbmJvYXJk?=
	=?gb2312?B?KCk=?=
Message-ID: <3174569B9743D511922F00A0C94314230466D82D@TYANWEB>

In the normal BIOS, We are using 16x1000

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?24? 11:20
???: YhLu
??: Stefan Reinauer; linuxbios at clustermatic.org
??: Re: ??: ????: coherent_ht_mainboard()

YhLu <YhLu at tyan.com> writes:

> The CPU0->AMD8131->AMD8111 is right.
> 
> The link CPU0 to CPU1:  in CPU0 side(link0) is 16x600 and CPU1 side(link0)
> is 16x800
> 
> All others is 8x200.
> 
> The coherent should be all 16x1000

Does AMD really support 1Ghz Operation between CPUs?  If so I am
fine with this.  Otherwise I have not seen any significant benchmarking
differences so I would mask out the 1Ghz capability...
 
Eric


From ebiederman at lnxi.com  Wed Mar 24 13:55:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Mar 24 13:55:00 2004
Subject: =?gb2312?b?tPC4tA==?=: ????: coherent_ht_mainboard()
In-Reply-To: <3174569B9743D511922F00A0C94314230466D827@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D827@TYANWEB>
Message-ID: <m365cu6o59.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> The optimize_link make 
> The link CPU0 to CPU1:  in CPU0 side(link0) is 16x800 and CPU1 side(link0)
> is 16x800

I don't know if 1Ghz is actually supported between cpus.  AMD never
mentions it, at least I had not seen that it was supported when I
wrote that code.  So I erred on the side of caution and limited things
to what is documented as supported.
 
> but the scan_ht_chain change CPU0 side(link0) is 16x600

An 8131 does not operate reliably at over 600Mhz.  Read the errata.
The 8131 does advertise that it can go at 800Mhz though.

> it must think it is connected to 8111 or something.

I believe these cap come from ht_read_freq_cap.  And they
are explicitly set:

Here is the general version in devices/hypertransport.c.
The amdk8 versions are a little more abbreviated.

static unsigned ht_read_freq_cap(device_t dev, unsigned pos)
{
	/* Handle bugs in valid hypertransport frequency reporting */
	unsigned freq_cap;

	freq_cap = pci_read_config16(dev, pos);
	freq_cap &= ~(1 << HT_FREQ_VENDOR); /* Ignore Vendor HT frequencies */

	/* AMD 8131 Errata 48 */
	if ((dev->vendor == PCI_VENDOR_ID_AMD) &&
		(dev->device == PCI_DEVICE_ID_AMD_8131_PCIX)) {
		freq_cap &= ~(1 << HT_FREQ_800Mhz);
	}
	/* AMD 8151 Errata 23 */
	if ((dev->vendor == PCI_VENDOR_ID_AMD) &&
		(dev->device == PCI_DEVICE_ID_AMD_8151_SYSCTRL)) {
		freq_cap &= ~(1 << HT_FREQ_800Mhz);
	}
	/* AMD K8 Unsupported 1Ghz? */
	if ((dev->vendor == PCI_VENDOR_ID_AMD) && (dev->device == 0x1100)) {
		freq_cap &= ~(1 << HT_FREQ_1000Mhz);
	}
	return freq_cap;
}

I hope this helps,

Eric


From YhLu at tyan.com  Wed Mar 24 14:29:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 14:29:01 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogPz8/PzogY29oZXJlbnRfaHRfbWFpbmJvYXJk?=
	=?gb2312?B?KCk=?=
Message-ID: <3174569B9743D511922F00A0C94314230466D834@TYANWEB>

Eric,

CPU0 Link0 is connected to CPU1, and CPU0 Link1 is connected to amd8131.

Before        needs_reset |= ht_setup_chain(PCI_DEV(0, 0x18, 0), 0x80);

The link is 16x800,

After that it change to 16x600,

What's the 0x80 for? Do need to change that 0xa0, because CPU0 link1 is to
amd8131.

Regards

YH



-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?24? 11:28
???: YhLu
??: Stefan Reinauer; linuxbios at clustermatic.org
??: Re: ??: ????: coherent_ht_mainboard()

YhLu <YhLu at tyan.com> writes:

> The optimize_link make 
> The link CPU0 to CPU1:  in CPU0 side(link0) is 16x800 and CPU1 side(link0)
> is 16x800

I don't know if 1Ghz is actually supported between cpus.  AMD never
mentions it, at least I had not seen that it was supported when I
wrote that code.  So I erred on the side of caution and limited things
to what is documented as supported.
 
> but the scan_ht_chain change CPU0 side(link0) is 16x600

An 8131 does not operate reliably at over 600Mhz.  Read the errata.
The 8131 does advertise that it can go at 800Mhz though.

> it must think it is connected to 8111 or something.

I believe these cap come from ht_read_freq_cap.  And they
are explicitly set:

Here is the general version in devices/hypertransport.c.
The amdk8 versions are a little more abbreviated.

static unsigned ht_read_freq_cap(device_t dev, unsigned pos)
{
	/* Handle bugs in valid hypertransport frequency reporting */
	unsigned freq_cap;

	freq_cap = pci_read_config16(dev, pos);
	freq_cap &= ~(1 << HT_FREQ_VENDOR); /* Ignore Vendor HT frequencies
*/

	/* AMD 8131 Errata 48 */
	if ((dev->vendor == PCI_VENDOR_ID_AMD) &&
		(dev->device == PCI_DEVICE_ID_AMD_8131_PCIX)) {
		freq_cap &= ~(1 << HT_FREQ_800Mhz);
	}
	/* AMD 8151 Errata 23 */
	if ((dev->vendor == PCI_VENDOR_ID_AMD) &&
		(dev->device == PCI_DEVICE_ID_AMD_8151_SYSCTRL)) {
		freq_cap &= ~(1 << HT_FREQ_800Mhz);
	}
	/* AMD K8 Unsupported 1Ghz? */
	if ((dev->vendor == PCI_VENDOR_ID_AMD) && (dev->device == 0x1100)) {
		freq_cap &= ~(1 << HT_FREQ_1000Mhz);
	}
	return freq_cap;
}

I hope this helps,

Eric


From rminnich at lanl.gov  Wed Mar 24 14:44:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 24 14:44:01 2004
Subject: is_cpu_pre_c0()
In-Reply-To: <m31xnit5yz.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403241306370.19002-100000@maxroach.lanl.gov>

On 24 Mar 2004, Eric W. Biederman wrote:

> That is a major challenge.  I have a back burner project to make romcc
> not inline all function calls.  But until I do that I don't know of a
> good way to reduce the code size.


actually there is an easy way I tested way back that worked out ok. 

You put the linuxbios_c payload BEFORE the auto.c-generated code. That
really opens up the space. Requires some .lds hacking. I forget why I
never committed it -- might have been an issue with mapping the ROM space. 
It may have been because we did not have the new config tool and it was 
too much work.

ron



From ollie at lanl.gov  Wed Mar 24 15:13:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Mar 24 15:13:01 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= S4882 support
In-Reply-To: <3174569B9743D511922F00A0C94314230466D803@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D803@TYANWEB>
Message-ID: <1080160637.25319.165.camel@exponential.lanl.gov>

On Wed, 2004-03-24 at 10:36, YhLu wrote:
>  There is some dump_pci_devices in auto.c of s2885, you can enable that to
> see if amd8111 LPC is 1:4.0
> 
> Regards
> 

That why I don't understand of this magic. In the log, LPC was 0:4.0 and
than changed to 3:4.0 and it's never 1:4.0. But I have to change the 
reset code to 1:4.0.

Ollie


> YH
> 
> -----????-----
> ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????: 2004?3?24? 8:05
> ???: YhLu
> ??: ebiederman at lnxi.com; Stefan Reinauer; ron minnich; LinuxBIOS
> ??: Re: ??: S4882 support
> 
> On Tue, 2004-03-23 at 20:57, YhLu wrote:
> > It seems the soft reset didn't rest the MB and ...
> > 
> > Ollie,
> > 
> > Can you check that in S2885? And I think if you changed the hard_reset and
> > soft_reset to bus 1, it may not rest the ht.
> > 
> 
> What ?? I have to change it to bus 1 to make the reset work on
> S2885.
> 
> Ollie
> 




From YhLu at tyan.com  Wed Mar 24 15:48:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 15:48:01 2004
Subject: S4882 Support Done
Message-ID: <3174569B9743D511922F00A0C94314230466D840@TYANWEB>

Ron,

Please commit the s4882 support code.

1. Add S4882 support.
2. Modify auto.c for s2881, s2885, s4880.
3. Add some optimize_link calling in set_smp.

Regards

YH

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fb2_s4882_changes.diff.bz2
Type: application/octet-stream
Size: 16728 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040324/a7b6c98c/attachment.obj>

From stepan at suse.de  Wed Mar 24 16:01:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 16:01:01 2004
Subject: ??????: ??????: S4882 support
In-Reply-To: <1080160637.25319.165.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C94314230466D803@TYANWEB> <1080160637.25319.165.camel@exponential.lanl.gov>
Message-ID: <20040324212525.GA7112@suse.de>

* Li-Ta Lo <ollie at lanl.gov> [040324 21:37]:
> That why I don't understand of this magic. In the log, LPC was 0:4.0 and
> than changed to 3:4.0 and it's never 1:4.0. But I have to change the 
> reset code to 1:4.0.

Commercial bioses have it easy.. for some reason they always map that
device on 0:7.0. It looks less elegant, but it does a cheap job.

Stefan
  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Wed Mar 24 16:12:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Mar 24 16:12:01 2004
Subject: ????: ????: ????: coherent_ht_mainboard()
In-Reply-To: <3174569B9743D511922F00A0C94314230466D834@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D834@TYANWEB>
Message-ID: <20040324213606.GB7112@suse.de>

* YhLu <YhLu at tyan.com> [040324 21:00]:
> What's the 0x80 for? Do need to change that 0xa0, because CPU0 link1 is to
> amd8131.

This looks like another hard code. In a perfect world, we look at each
link of each CPU, check and remember what is connected to it, deciding
on the information we get from the northbridge, like whether the link is
coherent or non-coherent.
Currently we grab the information from the hypertransport graph that we
need for the next action, but we don't seem to be able to fully describe
the graph and optimally traverse it.

  Stefan
  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From YhLu at tyan.com  Wed Mar 24 16:23:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 16:23:01 2004
Subject: S4882 support
Message-ID: <3174569B9743D511922F00A0C94314230466D846@TYANWEB>

That is up to scan sequence. In S2885, CPU0 link0 is linked AMD8151, and
link2 is connected to ADM8131.

If scan from link 0, bus 1 will be used by AMD851 AGP device and bridge, and
bus 2 will be used by AGP adapter.

So amd8131/amd111 will start from bus 3. 

I will check that in S2885 if it is in 1:4.0

Regards

YH



-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?24? 13:25
???: Li-Ta Lo
??: YhLu; ebiederman at lnxi.com; ron minnich; LinuxBIOS
??: Re: ??????: ??????: S4882 support

* Li-Ta Lo <ollie at lanl.gov> [040324 21:37]:
> That why I don't understand of this magic. In the log, LPC was 0:4.0 and
> than changed to 3:4.0 and it's never 1:4.0. But I have to change the 
> reset code to 1:4.0.

Commercial bioses have it easy.. for some reason they always map that
device on 0:7.0. It looks less elegant, but it does a cheap job.

Stefan
  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From rminnich at lanl.gov  Wed Mar 24 16:25:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 24 16:25:01 2004
Subject: S4882 support
In-Reply-To: <3174569B9743D511922F00A0C94314230466D846@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403241448010.19002-100000@maxroach.lanl.gov>

On Wed, 24 Mar 2004, YhLu wrote:

> That is up to scan sequence. In S2885, CPU0 link0 is linked AMD8151, and
> link2 is connected to ADM8131.
> 
> If scan from link 0, bus 1 will be used by AMD851 AGP device and bridge, and
> bus 2 will be used by AGP adapter.
> 
> So amd8131/amd111 will start from bus 3. 
> 
> I will check that in S2885 if it is in 1:4.0

it's why we need the search for the 8111. Everytime the scan order 
changes, these bus numbers change. 

ron



From shawnp at RUSSOUND.COM  Wed Mar 24 16:38:00 2004
From: shawnp at RUSSOUND.COM (Shawn Perkin)
Date: Wed Mar 24 16:38:00 2004
Subject: No output on EPIA-M serial port
Message-ID: <397BE3254B845145BBD031B34F29B320011056C8@russ-dc2.russound.com>

Hello all,

 

I'm currently in the process of trying to get Linuxbios to work on my
Via EPIA-M with no success. I have successfully complied Etherboot 5.2.0
as my payload, and performed a successful build of Linuxbios. I burned
the image without any errors and rebooted the system. I then had
absolutely no output on either serial port, or local display. I
currently have 256 MB of ram in the unit, and have tried a build with
and without the extracted vgabios.bin. I have included my config file
for your review. Any help would be greatly appreciated.

 

Shawn

 

#
# LinuxBIOS config file for: VIA epia-m mini-itx
#

target /usr/local/build/epia-m

# via epia
mainboard via/epia-m

# Enable Serial Console for debugging
option SERIAL_CONSOLE=1
#option SERIAL_POST=1
option TTYS0_BAUD=115200
#option TTYS0_BAUD=57600
option HAVE_FRAMEBUFFER=1
option CONFIG_VGABIOS=1
option CONFIG_REALMODE_IDT=1
dir src/bioscall
option CONFIG_PCIBIOS=1
option VGABIOS_START=0xfffe0000
#addaction romimage dd if=../vgabios.bin of=romimage bs=65536 seek=2
conv=sync conv=notrunc
option CONFIG_EPIAMVERSIONSTRING="5.0.0E-" __DATE__ " " __TIME__
#target /ram/freebios/obj
#payload /code/bootfiles/etherboot/via6105m.ebi

option DEFAULT_CONSOLE_LOGLEVEL=9
option DEBUG=1

# Use 256KB Standard Flash as Normal BIOS 
option RAMTEST=1
option USE_GENERIC_ROM=1
option STD_FLASH=1
#option ZKERNEL_START=0xfffc0000
option ROM_SIZE=262144

# payload size = 192KB
option PAYLOAD_SIZE=196608

# use ELF Loader to load Etherboot
option USE_ELF_BOOT=1

# Use Etherboot as our payload 
payload /home/shawnp/bios/etherboot-5.2.0/src/bin/via-rhine.elf 
# payload /opt/cwlinux/memtest86/memtest
 

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

From ollie at lanl.gov  Wed Mar 24 16:44:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Mar 24 16:44:00 2004
Subject: S4882 support
In-Reply-To: <3174569B9743D511922F00A0C94314230466D846@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D846@TYANWEB>
Message-ID: <1080166055.25319.174.camel@exponential.lanl.gov>

On Wed, 2004-03-24 at 14:54, YhLu wrote:
> That is up to scan sequence. In S2885, CPU0 link0 is linked AMD8151, and
> link2 is connected to ADM8131.
> 
> If scan from link 0, bus 1 will be used by AMD851 AGP device and bridge, and
> bus 2 will be used by AGP adapter.
> 
> So amd8131/amd111 will start from bus 3. 
> 
> I will check that in S2885 if it is in 1:4.0
> 

And it is never bus 1, right ? Why I have to access it
on bus 1 ? Doesn't it go to the AGP bridge ?

Ollie



From gwatson at lanl.gov  Wed Mar 24 17:14:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Wed Mar 24 17:14:00 2004
Subject: No output on EPIA-M serial port
In-Reply-To: <397BE3254B845145BBD031B34F29B320011056C8@russ-dc2.russound.com>
References: <397BE3254B845145BBD031B34F29B320011056C8@russ-dc2.russound.com>
Message-ID: <F91B65BE-7DE3-11D8-BA3D-000393A47A5C@lanl.gov>

Does the EPIA-M have a 256KB flash or a 512KB flash? I just ran into 
this problem with the EPIA. If you flash the wrong size image then 
nothing works at all.

Greg

On 24/03/2004, at 3:02 PM, Shawn Perkin wrote:

> Hello all,
>
> ?
>
> I?m currently in the process of trying to get Linuxbios to work on my 
> Via EPIA-M with no success. I have successfully complied Etherboot 
> 5.2.0 as my payload, and performed a successful build of Linuxbios. I 
> burned the image without any errors and rebooted the system. I then 
> had absolutely no output on either serial port, or local display. I 
> currently have 256 MB of ram in the unit, and have tried a build with 
> and without the extracted vgabios.bin. I have included my config file 
> for your review. Any help would be greatly appreciated.
>
> ?
>
> Shawn
>
> ?
>
> #
>  # LinuxBIOS config file for: VIA epia-m mini-itx
>  #
>
>  target /usr/local/build/epia-m
>
>  # via epia
>  mainboard via/epia-m
>
>  # Enable Serial Console for debugging
>  option SERIAL_CONSOLE=1
>  #option SERIAL_POST=1
>  option TTYS0_BAUD=115200
>  #option TTYS0_BAUD=57600
>  option HAVE_FRAMEBUFFER=1
>  option CONFIG_VGABIOS=1
>  option CONFIG_REALMODE_IDT=1
>  dir src/bioscall
>  option CONFIG_PCIBIOS=1
>  option VGABIOS_START=0xfffe0000
>  #addaction romimage dd if=../vgabios.bin of=romimage bs=65536 seek=2 
> conv=sync conv=notrunc
>  option CONFIG_EPIAMVERSIONSTRING="5.0.0E-" __DATE__ " " __TIME__
>  #target /ram/freebios/obj
>  #payload /code/bootfiles/etherboot/via6105m.ebi
>
>  option DEFAULT_CONSOLE_LOGLEVEL=9
>  option DEBUG=1
>
>  # Use 256KB Standard Flash as Normal BIOS
>  option RAMTEST=1
>  option USE_GENERIC_ROM=1
>  option STD_FLASH=1
>  #option ZKERNEL_START=0xfffc0000
>  option ROM_SIZE=262144
>
>  # payload size = 192KB
>  option PAYLOAD_SIZE=196608
>
>  # use ELF Loader to load Etherboot
>  option USE_ELF_BOOT=1
>
>  # Use Etherboot as our payload
>  payload /home/shawnp/bios/etherboot-5.2.0/src/bin/via-rhine.elf
>  # payload /opt/cwlinux/memtest86/memtest
> ?



From YhLu at tyan.com  Wed Mar 24 18:19:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 24 18:19:00 2004
Subject: =?gb2312?B?tPC4tDogUzQ4ODIgc3VwcG9ydA==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D862@TYANWEB>

It is in 00:4.0

Even you are using 0x80, you got the same result, because auto.c only use
that optimize link speed/width, and 8131 and 8151 has the same speed/cap.

At this time, ht_setup_chain only can scan one ht-chain.

If want to optimize link to 8151, need to move code from northbridge.c to
init 0xe0.... to assign unitid to 8151.

Regards

YH.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?24? 14:08
???: YhLu
??: Stefan Reinauer; ebiederman at lnxi.com; ron minnich; LinuxBIOS
??: Re: S4882 support

On Wed, 2004-03-24 at 14:54, YhLu wrote:
> That is up to scan sequence. In S2885, CPU0 link0 is linked AMD8151, and
> link2 is connected to ADM8131.
> 
> If scan from link 0, bus 1 will be used by AMD851 AGP device and bridge,
and
> bus 2 will be used by AGP adapter.
> 
> So amd8131/amd111 will start from bus 3. 
> 
> I will check that in S2885 if it is in 1:4.0
> 

And it is never bus 1, right ? Why I have to access it
on bus 1 ? Doesn't it go to the AGP bridge ?

Ollie


From rminnich at lanl.gov  Wed Mar 24 21:17:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 24 21:17:01 2004
Subject: No output on EPIA-M serial port
In-Reply-To: <397BE3254B845145BBD031B34F29B320011056C8@russ-dc2.russound.com>
Message-ID: <Pine.LNX.4.44.0403241940370.23677-100000@maxroach.lanl.gov>

send me your linuxbios.rom and I'll take a quick look at it.

do you have a POST card?

ron



From joshua at joshuawise.com  Wed Mar 24 22:11:00 2004
From: joshua at joshuawise.com (Joshua Wise)
Date: Wed Mar 24 22:11:00 2004
Subject: EPIA "always-on" system
Message-ID: <200403242235.12364.joshua@joshuawise.com>

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

Hi all,

I am considering building a "backpack computer" that does MP3 playing, 
etcetera... I was planning on using the EPIA because LinuxBIOS supports it. 
Is the EPIA in a state right now where it would be usable for such activity?

Thanks,

joshua

- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAYlNvPn9tWOqA4LMRAi44AJ9yBjGNJXLfDOrOAZmQcdbGGOuwEgCdGwjG
Jskcoo0MCSpABsxHvgA9ArE=
=Xjf2
-----END PGP SIGNATURE-----


From rminnich at lanl.gov  Wed Mar 24 22:28:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 24 22:28:00 2004
Subject: EPIA "always-on" system
In-Reply-To: <200403242235.12364.joshua@joshuawise.com>
Message-ID: <Pine.LNX.4.44.0403242050580.24188-100000@maxroach.lanl.gov>

On Wed, 24 Mar 2004, Joshua Wise wrote:

> I am considering building a "backpack computer" that does MP3 playing,
> etcetera... I was planning on using the EPIA because LinuxBIOS supports
> it.  Is the EPIA in a state right now where it would be usable for such
> activity?

I believe so. Greg Watson just built linuxbios images today and they are 
working fine. If you need help just let us know. We can also just send you 
some 'epia+filo' images which load linux from an attached ext2 formatted 
CF.

ron



From gwatson at lanl.gov  Wed Mar 24 22:29:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Wed Mar 24 22:29:00 2004
Subject: EPIA "always-on" system
In-Reply-To: <200403242235.12364.joshua@joshuawise.com>
References: <200403242235.12364.joshua@joshuawise.com>
Message-ID: <E9CECA5A-7E0F-11D8-92F6-000393A47A5C@lanl.gov>

I'll have 15 or so EPIA's running LinuxBIOS at Clusterworld if you want 
to take a look :-)

Greg

On 24/03/2004, at 8:35 PM, Joshua Wise wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> I am considering building a "backpack computer" that does MP3 playing,
> etcetera... I was planning on using the EPIA because LinuxBIOS 
> supports it.
> Is the EPIA in a state right now where it would be usable for such 
> activity?
>
> Thanks,
>
> joshua
>
> - --
> Joshua Wise | www.joshuawise.com
> GPG Key     | 0xEA80E0B3
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
>
> iD8DBQFAYlNvPn9tWOqA4LMRAi44AJ9yBjGNJXLfDOrOAZmQcdbGGOuwEgCdGwjG
> Jskcoo0MCSpABsxHvgA9ArE=
> =Xjf2
> -----END PGP SIGNATURE-----
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From gwatson at lanl.gov  Wed Mar 24 22:32:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Wed Mar 24 22:32:00 2004
Subject: EPIA "always-on" system
In-Reply-To: <Pine.LNX.4.44.0403242050580.24188-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403242050580.24188-100000@maxroach.lanl.gov>
Message-ID: <5A355056-7E10-11D8-92F6-000393A47A5C@lanl.gov>

On 24/03/2004, at 8:51 PM, ron minnich wrote:

> On Wed, 24 Mar 2004, Joshua Wise wrote:
>
>> I am considering building a "backpack computer" that does MP3 playing,
>> etcetera... I was planning on using the EPIA because LinuxBIOS 
>> supports
>> it.  Is the EPIA in a state right now where it would be usable for 
>> such
>> activity?
>
> I believe so. Greg Watson just built linuxbios images today and they 
> are
> working fine. If you need help just let us know. We can also just send 
> you
> some 'epia+filo' images which load linux from an attached ext2 
> formatted
> CF.

Of course, this doesn't mean that I've in any way abandoned PPC for 
x86... :-)

Greg



From rminnich at lanl.gov  Wed Mar 24 22:32:12 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 24 22:32:12 2004
Subject: EPIA "always-on" system
In-Reply-To: <E9CECA5A-7E0F-11D8-92F6-000393A47A5C@lanl.gov>
Message-ID: <Pine.LNX.4.44.0403242055430.24188-100000@maxroach.lanl.gov>

On Wed, 24 Mar 2004, Greg Watson wrote:

> I'll have 15 or so EPIA's running LinuxBIOS at Clusterworld if you want 
> to take a look :-)

oh yeah, reference that, we're in a booth at clusterworld in san 
francisco. Stop by if you can!

it's the DOE booth, sandia+livermore+lanl. Should be good fun.

ron



From joshua at joshuawise.com  Wed Mar 24 22:36:01 2004
From: joshua at joshuawise.com (Joshua Wise)
Date: Wed Mar 24 22:36:01 2004
Subject: EPIA "always-on" system
In-Reply-To: <Pine.LNX.4.44.0403242055430.24188-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403242055430.24188-100000@maxroach.lanl.gov>
Message-ID: <200403242259.52731.joshua@joshuawise.com>

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

> oh yeah, reference that, we're in a booth at clusterworld in san
> francisco. Stop by if you can!
I'd love to go - a little bit far, though! I'm in Boston.

> ron
jwise

- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAYlk4Pn9tWOqA4LMRAiaaAKCGxoqgsOg3ApN4O3n6YZOIQJKo+ACff0s3
8POfn9QOmJpXkPGpLFnUOwg=
=e5Ib
-----END PGP SIGNATURE-----


From gwatson at lanl.gov  Wed Mar 24 22:36:13 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Wed Mar 24 22:36:13 2004
Subject: EPIA "always-on" system
In-Reply-To: <Pine.LNX.4.44.0403242055430.24188-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403242055430.24188-100000@maxroach.lanl.gov>
Message-ID: <E95528A4-7E10-11D8-92F6-000393A47A5C@lanl.gov>

San Jose, 6-8 April.

Greg

On 24/03/2004, at 8:56 PM, ron minnich wrote:

> On Wed, 24 Mar 2004, Greg Watson wrote:
>
>> I'll have 15 or so EPIA's running LinuxBIOS at Clusterworld if you 
>> want
>> to take a look :-)
>
> oh yeah, reference that, we're in a booth at clusterworld in san
> francisco. Stop by if you can!
>
> it's the DOE booth, sandia+livermore+lanl. Should be good fun.
>
> ron
>



From joshua at joshuawise.com  Wed Mar 24 22:38:01 2004
From: joshua at joshuawise.com (Joshua Wise)
Date: Wed Mar 24 22:38:01 2004
Subject: EPIA "always-on" system
In-Reply-To: <Pine.LNX.4.44.0403242050580.24188-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403242050580.24188-100000@maxroach.lanl.gov>
Message-ID: <200403242302.24573.joshua@joshuawise.com>

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

> > I am considering building a "backpack computer" that does MP3 playing,
> > etcetera... I was planning on using the EPIA because LinuxBIOS supports
> > it.  Is the EPIA in a state right now where it would be usable for such
> > activity?
>
> I believe so. Greg Watson just built linuxbios images today and they are
> working fine. If you need help just let us know. We can also just send you
> some 'epia+filo' images which load linux from an attached ext2 formatted
> CF.
Okay, cool. I will see if I can get my hands on one of these boards and see 
what I can do. What other hardware do I need other than the epia? (sockets, 
etcetera)

BTW, thanks for the quick response.. I'll not be around to read your response 
until later today, unfortunately - 11pm here.

> ron
joshua

- -- 
Joshua Wise | www.joshuawise.com
GPG Key     | 0xEA80E0B3
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAYlnPPn9tWOqA4LMRAtf5AJ9jeEHIPzCwhOLHMLc9pUoy5LtvxgCgr3sF
hRVbe6yL+ORJtKiRsdIjpyc=
=I0oc
-----END PGP SIGNATURE-----


From rminnich at lanl.gov  Wed Mar 24 22:42:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 24 22:42:01 2004
Subject: EPIA "always-on" system
In-Reply-To: <200403242302.24573.joshua@joshuawise.com>
Message-ID: <Pine.LNX.4.44.0403242105510.24188-100000@maxroach.lanl.gov>

On Wed, 24 Mar 2004, Joshua Wise wrote:

> Okay, cool. I will see if I can get my hands on one of these boards and see 
> what I can do. What other hardware do I need other than the epia? (sockets, 
> etcetera)

A board, a power supply, a magicram IDE-FLASH or IDE-CF adapter ... you 
don't need much.

ron



From bari at onelabs.com  Wed Mar 24 22:51:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Mar 24 22:51:01 2004
Subject: LinuxBIOS Featured on Slashdot Yet Again
Message-ID: <40625CBE.5060005@onelabs.com>

LinuxBIOS featured on Slashdot yet again this evening:

http://developers.slashdot.org/developers/04/03/24/2327229.shtml

-Bari




From YhLu at tyan.com  Thu Mar 25 01:33:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 01:33:01 2004
Subject: =?gb2312?B?tPC4tDogUzQ4ODIgU3VwcG9ydCBEb25l?=
Message-ID: <3174569B9743D511922F00A0C94314230466D892@TYANWEB>

Ron,

Please commit the s2885 support.

It make ht_reset in auto.c works with s2885.

Regards

YH

-----????-----
???: YhLu 
????: 2004?3?24? 13:19
???: ron minnich
??: Stefan Reinauer; ebiederman at lnxi.com; linuxbios at clustermatic.org
??: S4882 Support Done

Ron,

Please commit the s4882 support code.

1. Add S4882 support.
2. Modify auto.c for s2881, s2885, s4880.
3. Add some optimize_link calling in set_smp.

Regards

YH


-------------- next part --------------
A non-text attachment was scrubbed...
Name: fb2_s2885_multi_ht_chains_ht_reset.change.diff.bz2
Type: application/octet-stream
Size: 1951 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040325/0aad71ac/attachment.obj>

From YhLu at tyan.com  Thu Mar 25 01:43:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 01:43:00 2004
Subject: =?gb2312?B?tPC4tDogUzQ4ODIgc3VwcG9ydA==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D893@TYANWEB>

All 8131/8111 and 8151 are bus 0.

YH

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?24? 14:08
???: YhLu
??: Stefan Reinauer; ebiederman at lnxi.com; ron minnich; LinuxBIOS
??: Re: S4882 support

On Wed, 2004-03-24 at 14:54, YhLu wrote:
> That is up to scan sequence. In S2885, CPU0 link0 is linked AMD8151, and
> link2 is connected to ADM8131.
> 
> If scan from link 0, bus 1 will be used by AMD851 AGP device and bridge,
and
> bus 2 will be used by AGP adapter.
> 
> So amd8131/amd111 will start from bus 3. 
> 
> I will check that in S2885 if it is in 1:4.0
> 

And it is never bus 1, right ? Why I have to access it
on bus 1 ? Doesn't it go to the AGP bridge ?

Ollie


From stepan at suse.de  Thu Mar 25 04:26:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Mar 25 04:26:01 2004
Subject: S4882 Support Done
In-Reply-To: <3174569B9743D511922F00A0C94314230466D840@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D840@TYANWEB>
Message-ID: <20040325095031.GA9460@suse.de>

* YhLu <YhLu at tyan.com> [040324 22:19]:
> Please commit the s4882 support code.
> 
> 1. Add S4882 support.
> 2. Modify auto.c for s2881, s2885, s4880.
> 3. Add some optimize_link calling in set_smp.

it's committed, except two small things:

* src/devices/hypertransport.c:
  -               hard_reset();
  +// by LYH              hard_reset();

it'd be better to fix this issue so we don't walk into that code path
anymore at all.

* src/superio/winbond/w83627hf/superio.c

Why did this not have a sio_enable before? Is it really needed?


   Stefan
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Thu Mar 25 04:32:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Mar 25 04:32:01 2004
Subject: ????: S4882 Support Done
In-Reply-To: <3174569B9743D511922F00A0C94314230466D892@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D892@TYANWEB>
Message-ID: <20040325095601.GB9460@suse.de>

* YhLu <YhLu at tyan.com> [040325 08:03]:
> Please commit the s2885 support.
> 
> It make ht_reset in auto.c works with s2885.

Eric,

can you review this patch? It definitely won't break anything, but I
want to make sure it fits into src/northbridge/amd/amdk8/incoherent_ht.c
before committing this.

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From dwbird at nsictat.cscoms.com  Thu Mar 25 06:30:01 2004
From: dwbird at nsictat.cscoms.com (Dennis Bird)
Date: Thu Mar 25 06:30:01 2004
Subject: Tyan S2468 Dual AMD Athlon MP Board
Message-ID: <20040325115404.89BFD7FA7B@mailz2.loxinfo.co.th>

            Has LinuxBIOS been installed on the Tyan S2468 (Thunder K7X)
Mainboard?

 

            Dennis

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

From niki.waibel at newlogic.com  Thu Mar 25 07:12:01 2004
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Thu Mar 25 07:12:01 2004
Subject: No output on EPIA-M serial port
In-Reply-To: <397BE3254B845145BBD031B34F29B320011056C8@russ-dc2.russound.com>
Message-ID: <200403251236.i2PCaCUM023220@enterprise2.newlogic.at>

serial port speed was an issue months ago. dont know if that has been fixed.
try to lower the speed on the serial terminal (if you've configured 115200, try
57600)
niki

On 24-Mar-2004 Shawn Perkin wrote:
> Hello all,
> 
>  
> 
> I'm currently in the process of trying to get Linuxbios to work on my
> Via EPIA-M with no success. I have successfully complied Etherboot 5.2.0
> as my payload, and performed a successful build of Linuxbios. I burned
> the image without any errors and rebooted the system. I then had
> absolutely no output on either serial port, or local display. I
> currently have 256 MB of ram in the unit, and have tried a build with
> and without the extracted vgabios.bin. I have included my config file
> for your review. Any help would be greatly appreciated.
> 
>  
> 
> Shawn
> 
>  
> 
>#
># LinuxBIOS config file for: VIA epia-m mini-itx
>#
> 
> target /usr/local/build/epia-m
> 
># via epia
> mainboard via/epia-m
> 
># Enable Serial Console for debugging
> option SERIAL_CONSOLE=1
>#option SERIAL_POST=1
> option TTYS0_BAUD=115200
>#option TTYS0_BAUD=57600
> option HAVE_FRAMEBUFFER=1
> option CONFIG_VGABIOS=1
> option CONFIG_REALMODE_IDT=1
> dir src/bioscall
> option CONFIG_PCIBIOS=1
> option VGABIOS_START=0xfffe0000
>#addaction romimage dd if=../vgabios.bin of=romimage bs=65536 seek=2
> conv=sync conv=notrunc
> option CONFIG_EPIAMVERSIONSTRING="5.0.0E-" __DATE__ " " __TIME__
>#target /ram/freebios/obj
>#payload /code/bootfiles/etherboot/via6105m.ebi
> 
> option DEFAULT_CONSOLE_LOGLEVEL=9
> option DEBUG=1
> 
># Use 256KB Standard Flash as Normal BIOS 
> option RAMTEST=1
> option USE_GENERIC_ROM=1
> option STD_FLASH=1
>#option ZKERNEL_START=0xfffc0000
> option ROM_SIZE=262144
> 
># payload size = 192KB
> option PAYLOAD_SIZE=196608
> 
># use ELF Loader to load Etherboot
> option USE_ELF_BOOT=1
> 
># Use Etherboot as our payload 
> payload /home/shawnp/bios/etherboot-5.2.0/src/bin/via-rhine.elf 
># payload /opt/cwlinux/memtest86/memtest


From stepan at suse.de  Thu Mar 25 08:29:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Mar 25 08:29:00 2004
Subject: thinning out mainboard directories
Message-ID: <20040325135349.GA15010@suse.de>

Hi,

I'd like to continue thinning out the mainboard specific code
for the K8 mainboards, so it will be easier to keep all the mainboards
on the same level if the infrastructure code around it changes.
All code that is used by two or more motherboards should go to the
northbridge or southbridge code (or elsewhere)

* failover.c
  this seems to be the same on all K8 boards. It contains code that is
  specific to the amd 8111 south bridge. I suggest splitting this in 
  two pieces, one going to the cpu/k8 code, the other one going to the
  southbridge directory. Maybe this could even be used by x86 based 
  non-K8 boards?

* chip.h
  What exactly is this good for? It seems to be unused by all K8 boards.
  Do we need it? Should it be merged with mainboard.c?

mainboard.c and auto.c will probably always stay. (Can we rename this to
more speaking names, too? At least init.c or sth like that sounds a lot
more descriptive)

irq_tables.c and mptable.c will hopefully become autogenerated from
config some time, too.

This could reduce the amount of mainboard specific code to not more than 
four files, giving any hardware vendor a fair chance to jump on the
boat...

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From rminnich at lanl.gov  Thu Mar 25 10:04:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 25 10:04:01 2004
Subject: =?gb2312?B?tPC4tDogUzQ4ODIgU3VwcG9ydCBEb25l?=
In-Reply-To: <3174569B9743D511922F00A0C94314230466D892@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403250827120.28801-100000@maxroach.lanl.gov>

OK, Ollie and I are looking at your code and it will be comitted.

I think Ollie contacted you re a question he and I had.

ron



From rminnich at lanl.gov  Thu Mar 25 10:11:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 25 10:11:01 2004
Subject: S4882 Support Done
In-Reply-To: <20040325095031.GA9460@suse.de>
Message-ID: <Pine.LNX.4.44.0403250830570.28801-100000@maxroach.lanl.gov>

On Thu, 25 Mar 2004, Stefan Reinauer wrote:

> it's committed, except two small things:
> 
> * src/devices/hypertransport.c:
>   -               hard_reset();
>   +// by LYH              hard_reset();
> 
> it'd be better to fix this issue so we don't walk into that code path
> anymore at all.
> 

yes, this made us uncomfortable which is why we had not committed it yet. 
It's in the common code.

ron



From carl at youngbloods.org  Thu Mar 25 10:42:00 2004
From: carl at youngbloods.org (Carl Youngblood)
Date: Thu Mar 25 10:42:00 2004
Subject: Using LinuxBios to protect against DRM in PC hardware?
Message-ID: <56931.130.76.32.145.1080230805.squirrel@secure.pennytracker.net>

Pardon me if I am off-base here (I don't know much about LinuxBios), but
I've heard rumors/threats of new BIOSes that incorporate DRM into the BIOS
and won't allow non-approved OSes to run on them.  Could LinuxBios be a
way of protecting against this?

Thanks,
Carl Youngblood


From rminnich at lanl.gov  Thu Mar 25 11:02:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 25 11:02:00 2004
Subject: thinning out mainboard directories
In-Reply-To: <20040325135349.GA15010@suse.de>
Message-ID: <Pine.LNX.4.44.0403250925270.28801-100000@maxroach.lanl.gov>

On Thu, 25 Mar 2004, Stefan Reinauer wrote:

> * failover.c
>   this seems to be the same on all K8 boards. It contains code that is
>   specific to the amd 8111 south bridge. I suggest splitting this in 
>   two pieces, one going to the cpu/k8 code, the other one going to the
>   southbridge directory. Maybe this could even be used by x86 based 
>   non-K8 boards?

sounds good. 

> 
> * chip.h
>   What exactly is this good for? It seems to be unused by all K8 boards.
>   Do we need it? Should it be merged with mainboard.c?

the plan was to contain mainboard-specific stuff in here, generated by the
config tool, just as in all other devices. If we are not going to use it
it should go away. No one appears to be using it. 


> irq_tables.c and mptable.c will hopefully become autogenerated from
> config some time, too.

some day ...


I like it, reducing # files is good.

ron



From shawnp at RUSSOUND.COM  Thu Mar 25 11:21:01 2004
From: shawnp at RUSSOUND.COM (Shawn Perkin)
Date: Thu Mar 25 11:21:01 2004
Subject: Via EPIA-M serial output- problem fixed
Message-ID: <397BE3254B845145BBD031B34F29B32001105726@russ-dc2.russound.com>

Hello All,

 

I figured out why I had no output on the serial port of my Via EPIA-M.

 

I am embarrassed to admit this, but I was not using a null modem cable
between both PC's. I want to thank the folks that offered help; I and
may have a few more questions down the line. 

 

Once I get this project finished, I'm planning to put together a Web
site with FAQ and how-to documents for the Via EPIA-M motherboard. If
anyone would like to contribute information, tips, pitfalls, etc...
please email me at: shawn at interspeed.net or shawnp at russound.com.

 

Best regards,

Shawn

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

From rminnich at lanl.gov  Thu Mar 25 11:57:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 25 11:57:00 2004
Subject: Via EPIA-M serial output- problem fixed
In-Reply-To: <397BE3254B845145BBD031B34F29B32001105726@russ-dc2.russound.com>
Message-ID: <Pine.LNX.4.44.0403251020530.28801-100000@maxroach.lanl.gov>

On Thu, 25 Mar 2004, Shawn Perkin wrote:

> I am embarrassed to admit this, but I was not using a null modem cable
> between both PC's. I want to thank the folks that offered help; I and
> may have a few more questions down the line. 

Gee, I never did anything like this ... at least in the last 24 hours :-)

> Once I get this project finished, I'm planning to put together a Web
> site with FAQ and how-to documents for the Via EPIA-M motherboard. If
> anyone would like to contribute information, tips, pitfalls, etc...
> please email me at: shawn at interspeed.net or shawnp at russound.com.

THANKS!

ron



From YhLu at tyan.com  Thu Mar 25 12:17:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 12:17:01 2004
Subject: =?gb2312?B?tPC4tDogUzQ4ODIgU3VwcG9ydCBEb25l?=
Message-ID: <3174569B9743D511922F00A0C94314230466D8A2@TYANWEB>

Stefan thanks.

1. hard_reset, with my two patch, the s4880 and 2885 with deferent link to
amd8131 and more links to in coherent devices can make ht-reset works. You
can keep the hard-reset, but some time it cause trouble.
2. sio-enable, because the init is not called. Without the init_keyboard,
the keyboard will not work under kernel 2.6.3 or later.

Regards

YH

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?25? 1:51
???: YhLu
??: ron minnich; ebiederman at lnxi.com; linuxbios at clustermatic.org
??: Re: S4882 Support Done

* YhLu <YhLu at tyan.com> [040324 22:19]:
> Please commit the s4882 support code.
> 
> 1. Add S4882 support.
> 2. Modify auto.c for s2881, s2885, s4880.
> 3. Add some optimize_link calling in set_smp.

it's committed, except two small things:

* src/devices/hypertransport.c:
  -               hard_reset();
  +// by LYH              hard_reset();

it'd be better to fix this issue so we don't walk into that code path
anymore at all.

* src/superio/winbond/w83627hf/superio.c

Why did this not have a sio_enable before? Is it really needed?


   Stefan
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From rminnich at lanl.gov  Thu Mar 25 12:20:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Mar 25 12:20:00 2004
Subject: =?gb2312?B?tPC4tDogUzQ4ODIgU3VwcG9ydCBEb25l?=
In-Reply-To: <3174569B9743D511922F00A0C94314230466D8A2@TYANWEB>
Message-ID: <Pine.LNX.4.44.0403251042270.28801-100000@maxroach.lanl.gov>

On Thu, 25 Mar 2004, YhLu wrote:

> 2. sio-enable, because the init is not called. Without the init_keyboard,
> the keyboard will not work under kernel 2.6.3 or later.

Oops, just read the patch and I don't see any problem with it. 

Stefan, what was the concern?

Sorry, too much going on here.

ron



From YhLu at tyan.com  Thu Mar 25 12:20:13 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 12:20:13 2004
Subject: (no subject)
Message-ID: <3174569B9743D511922F00A0C94314230466D8A3@TYANWEB>

I add one function incoherent.c
static int ht_setup_chains(const struct ht_chain *ht_c, int ht_c_num);
 and it can only be called by multi-ht-chains init to handle multiple chains

YH
-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?3?25? 1:56
???: YhLu
??: ron minnich; ebiederman at lnxi.com; linuxbios at clustermatic.org
??: Re: ????: S4882 Support Done

* YhLu <YhLu at tyan.com> [040325 08:03]:
> Please commit the s2885 support.
> 
> It make ht_reset in auto.c works with s2885.

Eric,

can you review this patch? It definitely won't break anything, but I
want to make sure it fits into src/northbridge/amd/amdk8/incoherent_ht.c
before committing this.

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Thu Mar 25 12:23:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Mar 25 12:23:01 2004
Subject: ????: S4882 Support Done
In-Reply-To: <3174569B9743D511922F00A0C94314230466D8A2@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D8A2@TYANWEB>
Message-ID: <20040325174634.GB26443@suse.de>

* YhLu <YhLu at tyan.com> [040325 18:48]:
> 1. hard_reset, with my two patch, the s4880 and 2885 with deferent link to
> amd8131 and more links to in coherent devices can make ht-reset works. You
> can keep the hard-reset, but some time it cause trouble.

ok. we have to find a solution here..

> 2. sio-enable, because the init is not called. Without the init_keyboard,
> the keyboard will not work under kernel 2.6.3 or later.

Commited.

Stefan
  
-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From stepan at suse.de  Thu Mar 25 12:24:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Mar 25 12:24:01 2004
Subject: ????: S4882 Support Done
In-Reply-To: <Pine.LNX.4.44.0403251042270.28801-100000@maxroach.lanl.gov>
References: <3174569B9743D511922F00A0C94314230466D8A2@TYANWEB> <Pine.LNX.4.44.0403251042270.28801-100000@maxroach.lanl.gov>
Message-ID: <20040325174818.GC26443@suse.de>

* ron minnich <rminnich at lanl.gov> [040325 18:43]:
> Oops, just read the patch and I don't see any problem with it. 
> 
> Stefan, what was the concern?

I was just not sure what made the code necessary.. it's in now.

  Stefan

-- 
  Stefan Reinauer, SUSE LINUX AG
Head of Architecture Development


From YhLu at tyan.com  Thu Mar 25 12:27:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 12:27:00 2004
Subject: =?gb2312?B?tPC4tDogUzQ4ODIgU3VwcG9ydCBEb25l?=
Message-ID: <3174569B9743D511922F00A0C94314230466D8A6@TYANWEB>

Ron/Ollie,

Can you verify it on S2885? Because at this time only s2885 has two
incoherent links to AMD8151 and AMD8131 in CPU0.

Regards

YH

-----????-----
???: YhLu 
????: 2004?3?24? 23:04
???: YhLu; ron minnich
??: Stefan Reinauer; ebiederman at lnxi.com; linuxbios at clustermatic.org
??: ??: S4882 Support Done

Ron,

Please commit the s2885 support.

It make ht_reset in auto.c works with s2885.

Regards

YH

-----????-----
???: YhLu 
????: 2004?3?24? 13:19
???: ron minnich
??: Stefan Reinauer; ebiederman at lnxi.com; linuxbios at clustermatic.org
??: S4882 Support Done

Ron,

Please commit the s4882 support code.

1. Add S4882 support.
2. Modify auto.c for s2881, s2885, s4880.
3. Add some optimize_link calling in set_smp.

Regards

YH



From YhLu at tyan.com  Thu Mar 25 12:35:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 12:35:01 2004
Subject: S2885 support
Message-ID: <3174569B9743D511922F00A0C94314230466D8AA@TYANWEB>

Please refer to bootlog for s2885.

I have to comment out the optimized link in coherent_ht.c, and soft_reset to
get the pci_regs dump in auto.c stage.

You may find that the 0:5.0 and 0:6.0 are AMD8151 bridge and device.
And 0:1.0 ,0:1.1, 0:2.0, 0:2.1 are amd8131. 0:3.0 and 0:4.x are amd8111
Regards

YH.

-----????-----
???: YhLu 
????: 2004?3?25? 9:52
???: 'ron minnich'
??: 'Stefan Reinauer'; 'ebiederman at lnxi.com'; 'linuxbios at clustermatic.org'
??: ??: S4882 Support Done

Ron/Ollie,

Can you verify it on S2885? Because at this time only s2885 has two
incoherent links to AMD8151 and AMD8131 in CPU0.

Regards

YH

-----????-----
???: YhLu 
????: 2004?3?24? 23:04
???: YhLu; ron minnich
??: Stefan Reinauer; ebiederman at lnxi.com; linuxbios at clustermatic.org
??: ??: S4882 Support Done

Ron,

Please commit the s2885 support.

It make ht_reset in auto.c works with s2885.

Regards

YH

-----????-----
???: YhLu 
????: 2004?3?24? 13:19
???: ron minnich
??: Stefan Reinauer; ebiederman at lnxi.com; linuxbios at clustermatic.org
??: S4882 Support Done

Ron,

Please commit the s4882 support code.

1. Add S4882 support.
2. Modify auto.c for s2881, s2885, s4880.
3. Add some optimize_link calling in set_smp.

Regards

YH


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: s2885_before_ht_reset_all_regs_ok.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040325/0b91661e/attachment.txt>

From ollie at lanl.gov  Thu Mar 25 12:36:38 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 25 12:36:38 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?= S4882 Support Done
In-Reply-To: <3174569B9743D511922F00A0C94314230466D8A6@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D8A6@TYANWEB>
Message-ID: <1080237610.25319.176.camel@exponential.lanl.gov>

On Thu, 2004-03-25 at 10:58, YhLu wrote:
> Ron/Ollie,
> 
> Can you verify it on S2885? Because at this time only s2885 has two
> incoherent links to AMD8151 and AMD8131 in CPU0.
> 

It works on S2885. I will commit it soon.

Ollie




From YhLu at tyan.com  Thu Mar 25 16:56:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 16:56:00 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogUzQ4ODIgU3VwcG9ydCBEb25l?=
Message-ID: <3174569B9743D511922F00A0C94314230466D8DD@TYANWEB>

Please try this one. Remove the mindev in struct. And use next_unitid to
calculate the dev min and max.

Amd8151 is in dev 7 and 8. because Unit ID count for amd 8131 is 2 and amd
8111 is 4.

YH.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?25? 10:00
???: YhLu
??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
'linuxbios at clustermatic.org'
??: Re: ??: S4882 Support Done

On Thu, 2004-03-25 at 10:58, YhLu wrote:
> Ron/Ollie,
> 
> Can you verify it on S2885? Because at this time only s2885 has two
> incoherent links to AMD8151 and AMD8131 in CPU0.
> 

It works on S2885. I will commit it soon.

Ollie


-------------- next part --------------
A non-text attachment was scrubbed...
Name: incoherent_ht.c.diff
Type: application/octet-stream
Size: 4806 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040325/c7161eee/attachment.obj>

From ollie at lanl.gov  Thu Mar 25 17:54:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 25 17:54:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= S4882 Support Done
In-Reply-To: <3174569B9743D511922F00A0C94314230466D8DD@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D8DD@TYANWEB>
Message-ID: <1080256705.25319.180.camel@exponential.lanl.gov>

On Thu, 2004-03-25 at 15:27, YhLu wrote:
> Please try this one. Remove the mindev in struct. And use next_unitid to
> calculate the dev min and max.
> 
> Amd8151 is in dev 7 and 8. because Unit ID count for amd 8131 is 2 and amd
> 8111 is 4.
> 

BTW, is the device enumeration changed ? Linux kernel complains
about mptable/apic.

Ollie




From YhLu at tyan.com  Thu Mar 25 17:58:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 17:58:01 2004
Subject: S4882 Support Done
Message-ID: <3174569B9743D511922F00A0C94314230466D8F0@TYANWEB>

FYI

Please send out your bootlog.

YH
-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?25? 15:18
???: YhLu
??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
'linuxbios at clustermatic.org'
??: Re: ??: ??: S4882 Support Done

On Thu, 2004-03-25 at 15:27, YhLu wrote:
> Please try this one. Remove the mindev in struct. And use next_unitid to
> calculate the dev min and max.
> 
> Amd8151 is in dev 7 and 8. because Unit ID count for amd 8131 is 2 and amd
> 8111 is 4.
> 

BTW, is the device enumeration changed ? Linux kernel complains
about mptable/apic.

Ollie


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: s2885_before_ht_reset_all_regs_AGP78_ok.txt
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040325/ddaab47f/attachment.txt>

From ollie at lanl.gov  Thu Mar 25 18:04:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 25 18:04:01 2004
Subject: S4882 Support Done
In-Reply-To: <3174569B9743D511922F00A0C94314230466D8F0@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D8F0@TYANWEB>
Message-ID: <1080257295.25319.182.camel@exponential.lanl.gov>

On Thu, 2004-03-25 at 16:29, YhLu wrote:
> FYI
> 
> Please send out your bootlog.
> 

It said something like:

..TIMER: vector=0x31 pin1=2 pin2=0
testing the IO APIC.......................


An unexpected IO-APIC was found. If this kernel release is less than
three months old please report this to linux-smp at vger.kernel.org

An unexpected IO-APIC was found. If this kernel release is less than
three months old please report this to linux-smp at vger.kernel.org
.................................... done.


Is it normal ?

Ollie

> YH
> -----????-----
> ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????: 2004?3?25? 15:18
> ???: YhLu
> ??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
> 'linuxbios at clustermatic.org'
> ??: Re: ??: ??: S4882 Support Done
> 
> On Thu, 2004-03-25 at 15:27, YhLu wrote:
> > Please try this one. Remove the mindev in struct. And use next_unitid to
> > calculate the dev min and max.
> > 
> > Amd8151 is in dev 7 and 8. because Unit ID count for amd 8131 is 2 and amd
> > 8111 is 4.
> > 
> 
> BTW, is the device enumeration changed ? Linux kernel complains
> about mptable/apic.
> 
> Ollie
> 
> 



From YhLu at tyan.com  Thu Mar 25 18:06:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 18:06:01 2004
Subject: =?gb2312?B?tPC4tDogUzQ4ODIgU3VwcG9ydCBEb25l?=
Message-ID: <3174569B9743D511922F00A0C94314230466D8F5@TYANWEB>

What's your kernel version? I386 or x86_64?

YH

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?25? 15:28
???: YhLu
??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
'linuxbios at clustermatic.org'
??: Re: S4882 Support Done

On Thu, 2004-03-25 at 16:29, YhLu wrote:
> FYI
> 
> Please send out your bootlog.
> 

It said something like:

..TIMER: vector=0x31 pin1=2 pin2=0
testing the IO APIC.......................


An unexpected IO-APIC was found. If this kernel release is less than
three months old please report this to linux-smp at vger.kernel.org

An unexpected IO-APIC was found. If this kernel release is less than
three months old please report this to linux-smp at vger.kernel.org
.................................... done.


Is it normal ?

Ollie

> YH
> -----????-----
> ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????: 2004?3?25? 15:18
> ???: YhLu
> ??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
> 'linuxbios at clustermatic.org'
> ??: Re: ??: ??: S4882 Support Done
> 
> On Thu, 2004-03-25 at 15:27, YhLu wrote:
> > Please try this one. Remove the mindev in struct. And use next_unitid to
> > calculate the dev min and max.
> > 
> > Amd8151 is in dev 7 and 8. because Unit ID count for amd 8131 is 2 and
amd
> > 8111 is 4.
> > 
> 
> BTW, is the device enumeration changed ? Linux kernel complains
> about mptable/apic.
> 
> Ollie
> 
> 


From ollie at lanl.gov  Thu Mar 25 18:11:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 25 18:11:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?= S4882 Support Done
In-Reply-To: <3174569B9743D511922F00A0C94314230466D8F5@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D8F5@TYANWEB>
Message-ID: <1080257712.25319.184.camel@exponential.lanl.gov>

On Thu, 2004-03-25 at 16:37, YhLu wrote:
> What's your kernel version? I386 or x86_64?
> 

Found Linux version 2.4.24 (root at jotun.ccstar.lanl.gov) #9 SMP Mon Mar 1
10:12:11 MST 2004 bzImage.
Loading kernel... ok
Jumping to entry point...
Linux version 2.4.24 (root at jotun.ccstar.lanl.gov) (gcc version 3.3.2
20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)) #9 SMP Mon Mar 1
10:12:11 MST 2004

Ollie

> YH
> 
> -----????-----
> ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????: 2004?3?25? 15:28
> ???: YhLu
> ??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
> 'linuxbios at clustermatic.org'
> ??: Re: S4882 Support Done
> 
> On Thu, 2004-03-25 at 16:29, YhLu wrote:
> > FYI
> > 
> > Please send out your bootlog.
> > 
> 
> It said something like:
> 
> ..TIMER: vector=0x31 pin1=2 pin2=0
> testing the IO APIC.......................
> 
> 
> An unexpected IO-APIC was found. If this kernel release is less than
> three months old please report this to linux-smp at vger.kernel.org
> 
> An unexpected IO-APIC was found. If this kernel release is less than
> three months old please report this to linux-smp at vger.kernel.org
> .................................... done.
> 
> 
> Is it normal ?
> 
> Ollie
> 
> > YH
> > -----????-----
> > ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> > ????: 2004?3?25? 15:18
> > ???: YhLu
> > ??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
> > 'linuxbios at clustermatic.org'
> > ??: Re: ??: ??: S4882 Support Done
> > 
> > On Thu, 2004-03-25 at 15:27, YhLu wrote:
> > > Please try this one. Remove the mindev in struct. And use next_unitid to
> > > calculate the dev min and max.
> > > 
> > > Amd8151 is in dev 7 and 8. because Unit ID count for amd 8131 is 2 and
> amd
> > > 8111 is 4.
> > > 
> > 
> > BTW, is the device enumeration changed ? Linux kernel complains
> > about mptable/apic.
> > 
> > Ollie
> > 
> > 
> 



From ollie at lanl.gov  Thu Mar 25 18:13:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Mar 25 18:13:00 2004
Subject: Cache On and ECC clear
Message-ID: <1080257845.25319.187.camel@exponential.lanl.gov>

Eric,

I tried to call cache_on() first than the cpufixeup()
in cpu.c to fix the "slow ecc clear" problem. It still
works that way. Is there any reason we can't do this ?

Ollie




From YhLu at tyan.com  Thu Mar 25 18:27:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 18:27:00 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogUzQ4ODIgU3VwcG9ydCBEb25l?=
Message-ID: <3174569B9743D511922F00A0C94314230466D8FB@TYANWEB>

It's 32bit kernel.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?25? 15:35
???: YhLu
??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
'linuxbios at clustermatic.org'
??: Re: ??: S4882 Support Done

On Thu, 2004-03-25 at 16:37, YhLu wrote:
> What's your kernel version? I386 or x86_64?
> 

Found Linux version 2.4.24 (root at jotun.ccstar.lanl.gov) #9 SMP Mon Mar 1
10:12:11 MST 2004 bzImage.
Loading kernel... ok
Jumping to entry point...
Linux version 2.4.24 (root at jotun.ccstar.lanl.gov) (gcc version 3.3.2
20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)) #9 SMP Mon Mar 1
10:12:11 MST 2004

Ollie

> YH
> 
> -----????-----
> ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????: 2004?3?25? 15:28
> ???: YhLu
> ??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
> 'linuxbios at clustermatic.org'
> ??: Re: S4882 Support Done
> 
> On Thu, 2004-03-25 at 16:29, YhLu wrote:
> > FYI
> > 
> > Please send out your bootlog.
> > 
> 
> It said something like:
> 
> ..TIMER: vector=0x31 pin1=2 pin2=0
> testing the IO APIC.......................
> 
> 
> An unexpected IO-APIC was found. If this kernel release is less than
> three months old please report this to linux-smp at vger.kernel.org
> 
> An unexpected IO-APIC was found. If this kernel release is less than
> three months old please report this to linux-smp at vger.kernel.org
> .................................... done.
> 
> 
> Is it normal ?
> 
> Ollie
> 
> > YH
> > -----????-----
> > ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> > ????: 2004?3?25? 15:18
> > ???: YhLu
> > ??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
> > 'linuxbios at clustermatic.org'
> > ??: Re: ??: ??: S4882 Support Done
> > 
> > On Thu, 2004-03-25 at 15:27, YhLu wrote:
> > > Please try this one. Remove the mindev in struct. And use next_unitid
to
> > > calculate the dev min and max.
> > > 
> > > Amd8151 is in dev 7 and 8. because Unit ID count for amd 8131 is 2 and
> amd
> > > 8111 is 4.
> > > 
> > 
> > BTW, is the device enumeration changed ? Linux kernel complains
> > about mptable/apic.
> > 
> > Ollie
> > 
> > 
> 


From YhLu at tyan.com  Thu Mar 25 18:32:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 18:32:01 2004
Subject: =?gb2312?B?tPC4tDogtPC4tDogUzQ4ODIgU3VwcG9ydCBEb25l?=
Message-ID: <3174569B9743D511922F00A0C94314230466D8FC@TYANWEB>

2.6.4 32 bit don't have such warning.

-----????-----
???: YhLu 
????: 2004?3?25? 15:58
???: Li-Ta Lo
??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
'linuxbios at clustermatic.org'
??: ??: ??: S4882 Support Done

It's 32bit kernel.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?25? 15:35
???: YhLu
??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
'linuxbios at clustermatic.org'
??: Re: ??: S4882 Support Done

On Thu, 2004-03-25 at 16:37, YhLu wrote:
> What's your kernel version? I386 or x86_64?
> 

Found Linux version 2.4.24 (root at jotun.ccstar.lanl.gov) #9 SMP Mon Mar 1
10:12:11 MST 2004 bzImage.
Loading kernel... ok
Jumping to entry point...
Linux version 2.4.24 (root at jotun.ccstar.lanl.gov) (gcc version 3.3.2
20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)) #9 SMP Mon Mar 1
10:12:11 MST 2004

Ollie

> YH
> 
> -----????-----
> ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> ????: 2004?3?25? 15:28
> ???: YhLu
> ??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
> 'linuxbios at clustermatic.org'
> ??: Re: S4882 Support Done
> 
> On Thu, 2004-03-25 at 16:29, YhLu wrote:
> > FYI
> > 
> > Please send out your bootlog.
> > 
> 
> It said something like:
> 
> ..TIMER: vector=0x31 pin1=2 pin2=0
> testing the IO APIC.......................
> 
> 
> An unexpected IO-APIC was found. If this kernel release is less than
> three months old please report this to linux-smp at vger.kernel.org
> 
> An unexpected IO-APIC was found. If this kernel release is less than
> three months old please report this to linux-smp at vger.kernel.org
> .................................... done.
> 
> 
> Is it normal ?
> 
> Ollie
> 
> > YH
> > -----????-----
> > ???: Li-Ta Lo [mailto:ollie at lanl.gov] 
> > ????: 2004?3?25? 15:18
> > ???: YhLu
> > ??: 'ron minnich'; 'Stefan Reinauer'; 'ebiederman at lnxi.com';
> > 'linuxbios at clustermatic.org'
> > ??: Re: ??: ??: S4882 Support Done
> > 
> > On Thu, 2004-03-25 at 15:27, YhLu wrote:
> > > Please try this one. Remove the mindev in struct. And use next_unitid
to
> > > calculate the dev min and max.
> > > 
> > > Amd8151 is in dev 7 and 8. because Unit ID count for amd 8131 is 2 and
> amd
> > > 8111 is 4.
> > > 
> > 
> > BTW, is the device enumeration changed ? Linux kernel complains
> > about mptable/apic.
> > 
> > Ollie
> > 
> > 
> 
_______________________________________________
Linuxbios mailing list
Linuxbios at clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios


From YhLu at tyan.com  Thu Mar 25 19:30:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 19:30:01 2004
Subject: romcc -O and -O2
Message-ID: <3174569B9743D511922F00A0C94314230466D909@TYANWEB>

Eric,

What's the difference of -O and -O2? t seems -O2 can produce small code for
auto.c.

Regards

YH


From ebiederman at lnxi.com  Thu Mar 25 19:39:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Mar 25 19:39:00 2004
Subject: romcc -O and -O2
In-Reply-To: <3174569B9743D511922F00A0C94314230466D909@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D909@TYANWEB>
Message-ID: <m3hdwcif8f.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> What's the difference of -O and -O2? t seems -O2 can produce small code for
> auto.c.

The set of optimizations performed.  Essentially the difference
-O2 performs conditional constant propagation.  

Historically there have been some bugs with -02, but they should not apply
at this point.

Eric


From YhLu at tyan.com  Thu Mar 25 23:11:01 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Mar 25 23:11:01 2004
Subject: S2885 ht reset multi chain.
Message-ID: <3174569B9743D511922F00A0C94314230466D928@TYANWEB>

Stefan,

Please try this one. Remove the mindev in struct. And use next_unitid to
calculate the dev min and max.

Can you try that in AMD quartet to see if ht reset works.

You may need to add several lines in auto.c


        static const struct ht_chain ht_c[] = {
                {
                        .udev = PCI_DEV(0, 0x18, 0),
                        .upos = 0xc0,
                        .devreg = 0xe0,
                },
                {
                        .udev = PCI_DEV(0, 0x19, 0),
                        .upos = 0xa0,
                        .devreg = 0xe4,
                },
        };

	Change calling to ht_setup_chain to ht_setup_chains

        needs_reset |= ht_setup_chains(ht_c, sizeof(ht_c)/sizeof(ht_c[0]));

make sure resourcemap.c like this

        PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x04010207,
        PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000110,
        PCI_ADDR(0, 0x18, 1, 0xE8), 0x0000FC88, 0x00000000,
        PCI_ADDR(0, 0x18, 1, 0xEC), 0x0000FC88, 0x00000000,

The result would be
        PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x04010207,
        PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x06050117,

If you enable the print_pci_devices in auto.c, you may see
0:1.0
0:2.0
0:2.1
0:2.2
0:2.3
0:2.5
0:2.6
0:5.0
0:5.1
0:6.0
0:6.1
0:18:0
0:18:1
0:18:2
0:18:3
0:19:0
0:19:1
0:19:2
0:19:3
0:1a:0
0:1a:1
0:1a:2
0:1a:3
0:1b:0
0:1b:1
0:1b:2
0:1b:3

regards


YH


-------------- next part --------------
A non-text attachment was scrubbed...
Name: fb2_s2885_changes_multi_chain.diff.bz
Type: application/octet-stream
Size: 4512 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040325/8b224f1b/attachment.obj>

From ebiederman at lnxi.com  Fri Mar 26 02:33:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 26 02:33:00 2004
Subject: Cache On and ECC clear
In-Reply-To: <1080257845.25319.187.camel@exponential.lanl.gov>
References: <1080257845.25319.187.camel@exponential.lanl.gov>
Message-ID: <m34qsc58xh.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> Eric,
> 
> I tried to call cache_on() first than the cpufixeup()
> in cpu.c to fix the "slow ecc clear" problem. It still
> works that way. Is there any reason we can't do this ?

Hmm.  I don't see this.  I have the cache on and things
clear quite quickly.  I may have a slightly different calling
order then the standard tree.  

Ollie can you compare what is checked into the tree with 
the last release I did for Lightning?  It works there...

Eric


From johnl at blurbco.com  Fri Mar 26 11:10:01 2004
From: johnl at blurbco.com (John Laur)
Date: Fri Mar 26 11:10:01 2004
Subject: EPIA-M "Magic Potion"?
Message-ID: <009201c41350$83944420$e100a8c0@oogigmcxtaxx>

Greetings, everyone. I am fairly new to LinuxBIOS, having fooled with it
for only a couple of days. Needless to say, I've been learning a lot. I
have had a lot of success with this great project, but recently have
been meeting with some failures as well. I'm searching for the "Magic
Potion" of CVS checkout date, patches, and config file that makes it
work for me, even if only passably, until the v2 port can proceed and
the VGA issues can be re-addressed.

I am trying to use a VIA EPIA M-1000 (Ezra) board and I'm having limited
success that at this point, I cannot decide are problems with my
LinuxBIOS configuration/build or problems with the code I am using. I
was able to successfully build and run LinuxBIOS with the serial console
and using FILO or etherboot (via-rhine and ide-disk) payloads without. I
am building code from a current (Mar. 25, 2004) v1 cvs checkout.

1) The machine has 512MB SDRAM, but LinuxBIOS only sets up 128MB. Is
this a problem with my config file? I know that v1 has some limitations
with memory on this platform. Was there a time when this worked better
on epia-m?

2) I cannot for the life of me flash the BIOS under Linux. For now, I
have to reboot to a DOS floppy and flash the original BIOS, then reboot
again and flash the LinuxBIOS image (AWFLASH will for some reason not
flash a LinuxBIOS image over a LinuxBIOS image already on the flash
part) I have run 'setpci -s 0:11.0  40.b=54' as described in the docs
and on the mailing list, but flash_rom still detects no flash device.

3) Despite my sincerest efforts, VGA is doing nothing. I have extracted
the VGA bios from both /proc/kcore as described in the HOWTO and from a
ROM image using CBROM (padded to 64k).. neither of these work. The VGA
bios I'm trying is from the latest release of the BIOS from VIA.

I understand that some people are having success on epia-m/vga using a
checkout from last july and a patch from Dave Ashley.. I may have
mistakenly believed that all that made it into CVS, but if not, what is
the correct checkout date, and where can I find the patch?

Thanks in advance to the list for any assistance!

John Laur



From rminnich at lanl.gov  Fri Mar 26 11:29:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 26 11:29:00 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <009201c41350$83944420$e100a8c0@oogigmcxtaxx>
Message-ID: <Pine.LNX.4.44.0403260952130.6641-100000@maxroach.lanl.gov>

On Fri, 26 Mar 2004, John Laur wrote:

> 1) The machine has 512MB SDRAM, but LinuxBIOS only sets up 128MB. Is
> this a problem with my config file? I know that v1 has some limitations
> with memory on this platform. Was there a time when this worked better
> on epia-m?

It's a v1 limitation, which is why I want to start V2 next week.

> 2) I cannot for the life of me flash the BIOS under Linux. For now, I
> have to reboot to a DOS floppy and flash the original BIOS, then reboot
> again and flash the LinuxBIOS image (AWFLASH will for some reason not
> flash a LinuxBIOS image over a LinuxBIOS image already on the flash
> part) I have run 'setpci -s 0:11.0  40.b=54' as described in the docs
> and on the mailing list, but flash_rom still detects no flash device.

arg. flash_rom should have "just worked". My guess is we need southbridge 
docs for this thing as it is new hardware.

> 3) Despite my sincerest efforts, VGA is doing nothing. I have extracted
> the VGA bios from both /proc/kcore as described in the HOWTO and from a
> ROM image using CBROM (padded to 64k).. neither of these work. The VGA
> bios I'm trying is from the latest release of the BIOS from VIA.

let's do one thing at a time ... let's fix the first two things. Do we 
have chipset docs?

> I understand that some people are having success on epia-m/vga using a
> checkout from last july and a patch from Dave Ashley.. I may have
> mistakenly believed that all that made it into CVS, but if not, what is
> the correct checkout date, and where can I find the patch?

I have incorporated dave's patches, which is why it ought to work ...

ron



From ollie at lanl.gov  Fri Mar 26 11:31:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 26 11:31:01 2004
Subject: Cache On and ECC clear
In-Reply-To: <m34qsc58xh.fsf@maxwell.lnxi.com>
References: <1080257845.25319.187.camel@exponential.lanl.gov>
	 <m34qsc58xh.fsf@maxwell.lnxi.com>
Message-ID: <1080320127.25319.192.camel@exponential.lanl.gov>

On Fri, 2004-03-26 at 01:06, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > Eric,
> > 
> > I tried to call cache_on() first than the cpufixeup()
> > in cpu.c to fix the "slow ecc clear" problem. It still
> > works that way. Is there any reason we can't do this ?
> 
> Hmm.  I don't see this.  I have the cache on and things
> clear quite quickly.  I may have a slightly different calling
> order then the standard tree.  
> 
> Ollie can you compare what is checked into the tree with 
> the last release I did for Lightning?  It works there...
> 

In LNXI tree it's like:

        /* Turn on caching if we haven't already */
        cache_on(mem);
                                                                                
        display_cpuid();
        mtrr_check();
#if 1
        /* some cpus need a fixup done. This is the hook for doing that.
*/
        cpufixup(mem);
#endif

and in the CVS tree it's:

	/* some cpus need a fixup done. This is the hook for doing that. */
	cpufixup(mem);

	/* Turn on caching if we haven't already */
	cache_on(mem);

	display_cpuid();
	mtrr_check();

Ollie




From bari at onelabs.com  Fri Mar 26 12:02:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Mar 26 12:02:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <Pine.LNX.4.44.0403260952130.6641-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403260952130.6641-100000@maxroach.lanl.gov>
Message-ID: <406467BC.6030409@onelabs.com>

ron minnich wrote:

> let's do one thing at a time ... let's fix the first two things. Do we 
> have chipset docs?

The Epia-M and M11 use the Via VT8235 southbridge, which is in the V1 
source tree.

-Bari




From jbors at mail.ru  Fri Mar 26 12:15:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Fri Mar 26 12:15:01 2004
Subject: EPIA-M "Magic Potion"?
References: <Pine.LNX.4.44.0403260952130.6641-100000@maxroach.lanl.gov>
Message-ID: <014a01c41359$3dedaca0$0300a8c0@amr.corp.intel.com>

Ron,
I think the CVS is broken. 1 week ago I was trying to use it on my M-6000
and it failed. Let me take a diff between current CVS and what's working for
me( IDE+VGA+Splash ).
Dmitry/

PS: I've plans to visit clusterworld, will stop by if any...

----- Original Message ----- 
Subject: Re: EPIA-M "Magic Potion"?


>
> I have incorporated dave's patches, which is why it ought to work ...
>
> ron
>



From rminnich at lanl.gov  Fri Mar 26 12:23:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 26 12:23:00 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <014a01c41359$3dedaca0$0300a8c0@amr.corp.intel.com>
Message-ID: <Pine.LNX.4.44.0403261047010.6641-100000@maxroach.lanl.gov>

On Fri, 26 Mar 2004, Dmitry Borisov wrote:

> I think the CVS is broken. 1 week ago I was trying to use it on my M-6000
> and it failed. Let me take a diff between current CVS and what's working for
> me( IDE+VGA+Splash ).

thanks, hope to see you at clusterworld.

ron



From dwh at lanl.gov  Fri Mar 26 12:24:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Mar 26 12:24:00 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <009201c41350$83944420$e100a8c0@oogigmcxtaxx>
Message-ID: <Pine.LNX.4.44.0403261047220.19163-100000@ccs-mail.lanl.gov>

What is the model/part number on your flash? It *might* work with the code 
already in flash_and_burn, but we might need to add a device id or 
something.

On Fri, 26 Mar 2004, John Laur wrote:
> 2) I cannot for the life of me flash the BIOS under Linux. For now, I
> have to reboot to a DOS floppy and flash the original BIOS, then reboot
> again and flash the LinuxBIOS image (AWFLASH will for some reason not
> flash a LinuxBIOS image over a LinuxBIOS image already on the flash
> part) I have run 'setpci -s 0:11.0  40.b=54' as described in the docs
> and on the mailing list, but flash_rom still detects no flash device.



From YhLu at tyan.com  Fri Mar 26 12:38:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 26 12:38:01 2004
Subject: =?gb2312?B?tPC4tDogQ2FjaGUgT24gYW5kIEVDQyBjbGVhcg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466D949@TYANWEB>

After exchange cpufixup after cache_on, 

In s2885, it can clear the memory quite faster. 

YH.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?26? 8:55
???: Eric W. Biederman
??: LinuxBIOS
??: Re: Cache On and ECC clear

On Fri, 2004-03-26 at 01:06, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > Eric,
> > 
> > I tried to call cache_on() first than the cpufixeup()
> > in cpu.c to fix the "slow ecc clear" problem. It still
> > works that way. Is there any reason we can't do this ?
> 
> Hmm.  I don't see this.  I have the cache on and things
> clear quite quickly.  I may have a slightly different calling
> order then the standard tree.  
> 
> Ollie can you compare what is checked into the tree with 
> the last release I did for Lightning?  It works there...
> 

In LNXI tree it's like:

        /* Turn on caching if we haven't already */
        cache_on(mem);
 

        display_cpuid();
        mtrr_check();
#if 1
        /* some cpus need a fixup done. This is the hook for doing that.
*/
        cpufixup(mem);
#endif

and in the CVS tree it's:

	/* some cpus need a fixup done. This is the hook for doing that. */
	cpufixup(mem);

	/* Turn on caching if we haven't already */
	cache_on(mem);

	display_cpuid();
	mtrr_check();

Ollie


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


From johnl at blurbco.com  Fri Mar 26 13:01:01 2004
From: johnl at blurbco.com (John Laur)
Date: Fri Mar 26 13:01:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <Pine.LNX.4.44.0403261047220.19163-100000@ccs-mail.lanl.gov>
Message-ID: <009601c41360$004dbfa0$e100a8c0@oogigmcxtaxx>

> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Hendricks David W.
> Sent: Friday, March 26, 2004 11:49 AM
> To: John Laur
> Cc: linuxbios at clustermatic.org
> Subject: Re: EPIA-M "Magic Potion"?
> 
> What is the model/part number on your flash? It *might* work with the
code
> already in flash_and_burn, but we might need to add a device id or
> something.
> 

You will have to forgive me; I am still pretty green with this whole
thing. Which model/part number do you need exactly? I have included some
information here, but if you need to know something else, please just
let me know, and I'll be happy to provide it.

I am using an RD1-PL Bios Savior with the original BIOS chip in the
socket. Flash_rom recognizes neither the original BIOS nor the backup
flash part (I don't know exactly what chip the RD1-PL uses offhand.)

When the RD1 is switched to the ORG (original bios), AWFLASH.EXE reports
the following:

For VT8623-8235-CLE26I01C-00 DATE: 12/11/2003
Flash Type - SST 39SF020 /5V

The actual chip says on it:

SST
MPF
39SF020A
70-4C-NH
0219037-A

Here is the output of my lspci -vvn for the southbridge (00:11.0 ISA
bridge: VIA Technologies, Inc. VT8235 ISA Bridge):

00:11.0 Class 0601: 1106:3177
        Subsystem: 1106:aa01
        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-

Here is what flash_rom returns. As you can see it's probing for the
SST29SF020A, which is what I have, and failing:

m3:~/freebios/util/flash_and_burn# setpci -s 0:11.0  40.b=54

m3:~/freebios/util/flash_and_burn# ./flash_rom
Calibrating timer since microsleep sucks ... takes a second
Setting up microsecond timing loop
199M loops per second
OK, calibrated, now do the deed
Enabling flash write on VT8235...OK
Trying Am29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Trying At29C040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Trying Mx29f002, 256 KB
probe_29f002: id1 37, id2 0
Trying SST29EE020A, 256 KB
probe_jedec: id1 0x25, id2 0x0
Trying SST28SF040A, 512 KB
probe_28sf040: id1 0xff, id2 0xff
Trying SST39SF020A, 256 KB
probe_39sf020: id1 0x25, id2 0x0
Trying SST39VF020, 256 KB
probe_39sf020: id1 0x25, id2 0x0
Trying W29C011, 128 KB
probe_jedec: id1 0x68, id2 0x5b
Trying W29C020C, 256 KB
probe_jedec: id1 0x25, id2 0x0
Trying W49F002U, 256 KB
probe_49f002: id1 0x25, id2 0x0
Trying M29F400BT, 512 KB
probe_m29f400bt: id1 0xff, id2 0xff
Trying 82802ab, 512 KB
probe_82802ab: id1 0xff, id2 0xff
Trying 82802ac, 1024 KB
probe_82802ab: id1 0xff, id2 0xff
Trying MD-2802 (M-Systems DiskOnChip Millennium Module), 8 KB
probe_md2802:
probe_md2802: *******************************
probe_md2802: * THIS IS A PRE ALPHA VERSION *
probe_md2802: * IN THE DEVELOPEMENT *********
probe_md2802: * PROCESS RIGHT NOW. **********
probe_md2802: *******************************
probe_md2802: * IF YOU ARE NOT A DEVELOPER **
probe_md2802: * THEN DO NOT TRY TO READ OR **
probe_md2802: * WRITE TO THIS DEVICE ********
probe_md2802: *******************************
probe_md2802:
probe_md2802: switching off reset mode ...
probe_md2802: switching off reset mode ... done
probe_md2802:
probe_md2802: switching off write protection ...
probe_md2802: switching off write protection ... done
probe_md2802:
probe_md2802: IPL_0x0000: 0x41
probe_md2802: IPL_0x0001: 0x77
probe_md2802: IPL_0x0002: 0x61
probe_md2802: IPL_0x0003: 0x72
probe_md2802:
probe_md2802: ChipID: 0x0e
probe_md2802: DOCStatus: 0x17
probe_md2802: FloorSelect: 0x01
probe_md2802: CDSNControl: 0xeb
probe_md2802: CDSNDeviceSelect: 0x2c
probe_md2802: ECCConfiguration: 0xf6
probe_md2802: CDSNSlowIO: 0x2e
probe_md2802: ECCSyndrome0: 0x01
probe_md2802: ECCSyndrome1: 0x86
probe_md2802: ECCSyndrome2: 0xc4
probe_md2802: ECCSyndrome3: 0x8b
probe_md2802: ECCSyndrome4: 0x1e
probe_md2802: ECCSyndrome5: 0x1c
probe_md2802: AliasResolution: 0x83
probe_md2802: ConfigurationInput: 0xc3
probe_md2802: ReadPipelineInitialization: 0x02
probe_md2802: LastDataRead: 0x1e
probe_md2802:
probe_md2802: checking ECCConfiguration toggle bit
probe_md2802: 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
probe_md2802: toggle result: 5/5
EEPROM not found

Thank you, everyone for all the help. Hopefully, I can get this thing
figured out eventually.

John

> On Fri, 26 Mar 2004, John Laur wrote:
> > 2) I cannot for the life of me flash the BIOS under Linux. For now,
I
> > have to reboot to a DOS floppy and flash the original BIOS, then
reboot
> > again and flash the LinuxBIOS image (AWFLASH will for some reason
not
> > flash a LinuxBIOS image over a LinuxBIOS image already on the flash
> > part) I have run 'setpci -s 0:11.0  40.b=54' as described in the
docs
> > and on the mailing list, but flash_rom still detects no flash
device.
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From dwh at lanl.gov  Fri Mar 26 13:10:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Mar 26 13:10:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <009601c41360$004dbfa0$e100a8c0@oogigmcxtaxx>
Message-ID: <Pine.LNX.4.44.0403261132530.19163-100000@ccs-mail.lanl.gov>

I am having the same difficulty flashing the same part on a Tyan s2885 
board. I'll check to see that we're probing it correctly.

On Fri, 26 Mar 2004, John Laur wrote:

> > -----Original Message-----
> > From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> > admin at clustermatic.org] On Behalf Of Hendricks David W.
> > Sent: Friday, March 26, 2004 11:49 AM
> > To: John Laur
> > Cc: linuxbios at clustermatic.org
> > Subject: Re: EPIA-M "Magic Potion"?
> > 
> > What is the model/part number on your flash? It *might* work with the
> code
> > already in flash_and_burn, but we might need to add a device id or
> > something.
> > 
> 
> You will have to forgive me; I am still pretty green with this whole
> thing. Which model/part number do you need exactly? I have included some
> information here, but if you need to know something else, please just
> let me know, and I'll be happy to provide it.
> 
> I am using an RD1-PL Bios Savior with the original BIOS chip in the
> socket. Flash_rom recognizes neither the original BIOS nor the backup
> flash part (I don't know exactly what chip the RD1-PL uses offhand.)
> 
> When the RD1 is switched to the ORG (original bios), AWFLASH.EXE reports
> the following:
> 
> For VT8623-8235-CLE26I01C-00 DATE: 12/11/2003
> Flash Type - SST 39SF020 /5V
> 
> The actual chip says on it:
> 
> SST
> MPF
> 39SF020A
> 70-4C-NH
> 0219037-A
> 
> Here is the output of my lspci -vvn for the southbridge (00:11.0 ISA
> bridge: VIA Technologies, Inc. VT8235 ISA Bridge):
> 
> 00:11.0 Class 0601: 1106:3177
>         Subsystem: 1106:aa01
>         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-
> 
> Here is what flash_rom returns. As you can see it's probing for the
> SST29SF020A, which is what I have, and failing:
> 
> m3:~/freebios/util/flash_and_burn# setpci -s 0:11.0  40.b=54
> 
> m3:~/freebios/util/flash_and_burn# ./flash_rom
> Calibrating timer since microsleep sucks ... takes a second
> Setting up microsecond timing loop
> 199M loops per second
> OK, calibrated, now do the deed
> Enabling flash write on VT8235...OK
> Trying Am29F040B, 512 KB
> probe_29f040b: id1 0xff, id2 0xff
> Trying At29C040A, 512 KB
> probe_jedec: id1 0xff, id2 0xff
> Trying Mx29f002, 256 KB
> probe_29f002: id1 37, id2 0
> Trying SST29EE020A, 256 KB
> probe_jedec: id1 0x25, id2 0x0
> Trying SST28SF040A, 512 KB
> probe_28sf040: id1 0xff, id2 0xff
> Trying SST39SF020A, 256 KB
> probe_39sf020: id1 0x25, id2 0x0
> Trying SST39VF020, 256 KB
> probe_39sf020: id1 0x25, id2 0x0
> Trying W29C011, 128 KB
> probe_jedec: id1 0x68, id2 0x5b
> Trying W29C020C, 256 KB
> probe_jedec: id1 0x25, id2 0x0
> Trying W49F002U, 256 KB
> probe_49f002: id1 0x25, id2 0x0
> Trying M29F400BT, 512 KB
> probe_m29f400bt: id1 0xff, id2 0xff
> Trying 82802ab, 512 KB
> probe_82802ab: id1 0xff, id2 0xff
> Trying 82802ac, 1024 KB
> probe_82802ab: id1 0xff, id2 0xff
> Trying MD-2802 (M-Systems DiskOnChip Millennium Module), 8 KB
> probe_md2802:
> probe_md2802: *******************************
> probe_md2802: * THIS IS A PRE ALPHA VERSION *
> probe_md2802: * IN THE DEVELOPEMENT *********
> probe_md2802: * PROCESS RIGHT NOW. **********
> probe_md2802: *******************************
> probe_md2802: * IF YOU ARE NOT A DEVELOPER **
> probe_md2802: * THEN DO NOT TRY TO READ OR **
> probe_md2802: * WRITE TO THIS DEVICE ********
> probe_md2802: *******************************
> probe_md2802:
> probe_md2802: switching off reset mode ...
> probe_md2802: switching off reset mode ... done
> probe_md2802:
> probe_md2802: switching off write protection ...
> probe_md2802: switching off write protection ... done
> probe_md2802:
> probe_md2802: IPL_0x0000: 0x41
> probe_md2802: IPL_0x0001: 0x77
> probe_md2802: IPL_0x0002: 0x61
> probe_md2802: IPL_0x0003: 0x72
> probe_md2802:
> probe_md2802: ChipID: 0x0e
> probe_md2802: DOCStatus: 0x17
> probe_md2802: FloorSelect: 0x01
> probe_md2802: CDSNControl: 0xeb
> probe_md2802: CDSNDeviceSelect: 0x2c
> probe_md2802: ECCConfiguration: 0xf6
> probe_md2802: CDSNSlowIO: 0x2e
> probe_md2802: ECCSyndrome0: 0x01
> probe_md2802: ECCSyndrome1: 0x86
> probe_md2802: ECCSyndrome2: 0xc4
> probe_md2802: ECCSyndrome3: 0x8b
> probe_md2802: ECCSyndrome4: 0x1e
> probe_md2802: ECCSyndrome5: 0x1c
> probe_md2802: AliasResolution: 0x83
> probe_md2802: ConfigurationInput: 0xc3
> probe_md2802: ReadPipelineInitialization: 0x02
> probe_md2802: LastDataRead: 0x1e
> probe_md2802:
> probe_md2802: checking ECCConfiguration toggle bit
> probe_md2802: 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
> probe_md2802: toggle result: 5/5
> EEPROM not found
> 
> Thank you, everyone for all the help. Hopefully, I can get this thing
> figured out eventually.
> 
> John
> 
> > On Fri, 26 Mar 2004, John Laur wrote:
> > > 2) I cannot for the life of me flash the BIOS under Linux. For now,
> I
> > > have to reboot to a DOS floppy and flash the original BIOS, then
> reboot
> > > again and flash the LinuxBIOS image (AWFLASH will for some reason
> not
> > > flash a LinuxBIOS image over a LinuxBIOS image already on the flash
> > > part) I have run 'setpci -s 0:11.0  40.b=54' as described in the
> docs
> > > and on the mailing list, but flash_rom still detects no flash
> device.
> > 
> > _______________________________________________
> > 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 ollie at lanl.gov  Fri Mar 26 13:32:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 26 13:32:01 2004
Subject: S2885 ht reset multi chain.
In-Reply-To: <3174569B9743D511922F00A0C94314230466D928@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D928@TYANWEB>
Message-ID: <1080327404.25319.199.camel@exponential.lanl.gov>

On Thu, 2004-03-25 at 21:42, YhLu wrote:
> Stefan,
> 
> Please try this one. Remove the mindev in struct. And use next_unitid to
> calculate the dev min and max.
> 
> Can you try that in AMD quartet to see if ht reset works.

Can you do a CVS update and send me your patch again. Your incoherent.c 
and s2885_changes_mulit_ht conflict with other.

Ollie




From YhLu at tyan.com  Fri Mar 26 13:51:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Mar 26 13:51:01 2004
Subject: =?gb2312?B?tPC4tDogUzI4ODUgaHQgcmVzZXQgbXVsdGkgY2hhaW4u?=
Message-ID: <3174569B9743D511922F00A0C94314230466D969@TYANWEB>

Please find the change.diff.

Please still find the problem, please refer incoherent_ht.c and auto.c for
s2885

regards

YH
-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?26? 10:57
???: YhLu
??: 'Stefan Reinauer'; 'ron minnich'; 'ebiederman at lnxi.com';
'linuxbios at clustermatic.org'
??: Re: S2885 ht reset multi chain.

On Thu, 2004-03-25 at 21:42, YhLu wrote:
> Stefan,
> 
> Please try this one. Remove the mindev in struct. And use next_unitid to
> calculate the dev min and max.
> 
> Can you try that in AMD quartet to see if ht reset works.

Can you do a CVS update and send me your patch again. Your incoherent.c 
and s2885_changes_mulit_ht conflict with other.

Ollie


-------------- next part --------------
A non-text attachment was scrubbed...
Name: auto.c
Type: application/octet-stream
Size: 5662 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040326/804e0944/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: incoherent_ht.c
Type: application/octet-stream
Size: 11397 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040326/804e0944/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: change.diff
Type: application/octet-stream
Size: 22318 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040326/804e0944/attachment-0002.obj>

From dwh at lanl.gov  Fri Mar 26 13:56:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Mar 26 13:56:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <009601c41360$004dbfa0$e100a8c0@oogigmcxtaxx>
Message-ID: <Pine.LNX.4.44.0403261219320.19163-100000@ccs-mail.lanl.gov>

Oops, it's not LPC compatible :( Ollie says we need a really old mainboard 
to flash it.

Or perhaps MTD would work?

On Fri, 26 Mar 2004, John Laur wrote:

> > -----Original Message-----
> > From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> > admin at clustermatic.org] On Behalf Of Hendricks David W.
> > Sent: Friday, March 26, 2004 11:49 AM
> > To: John Laur
> > Cc: linuxbios at clustermatic.org
> > Subject: Re: EPIA-M "Magic Potion"?
> > 
> > What is the model/part number on your flash? It *might* work with the
> code
> > already in flash_and_burn, but we might need to add a device id or
> > something.
> > 
> 
> You will have to forgive me; I am still pretty green with this whole
> thing. Which model/part number do you need exactly? I have included some
> information here, but if you need to know something else, please just
> let me know, and I'll be happy to provide it.
> 
> I am using an RD1-PL Bios Savior with the original BIOS chip in the
> socket. Flash_rom recognizes neither the original BIOS nor the backup
> flash part (I don't know exactly what chip the RD1-PL uses offhand.)
> 
> When the RD1 is switched to the ORG (original bios), AWFLASH.EXE reports
> the following:
> 
> For VT8623-8235-CLE26I01C-00 DATE: 12/11/2003
> Flash Type - SST 39SF020 /5V
> 
> The actual chip says on it:
> 
> SST
> MPF
> 39SF020A
> 70-4C-NH
> 0219037-A
> 
> Here is the output of my lspci -vvn for the southbridge (00:11.0 ISA
> bridge: VIA Technologies, Inc. VT8235 ISA Bridge):
> 
> 00:11.0 Class 0601: 1106:3177
>         Subsystem: 1106:aa01
>         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-
> 
> Here is what flash_rom returns. As you can see it's probing for the
> SST29SF020A, which is what I have, and failing:
> 
> m3:~/freebios/util/flash_and_burn# setpci -s 0:11.0  40.b=54
> 
> m3:~/freebios/util/flash_and_burn# ./flash_rom
> Calibrating timer since microsleep sucks ... takes a second
> Setting up microsecond timing loop
> 199M loops per second
> OK, calibrated, now do the deed
> Enabling flash write on VT8235...OK
> Trying Am29F040B, 512 KB
> probe_29f040b: id1 0xff, id2 0xff
> Trying At29C040A, 512 KB
> probe_jedec: id1 0xff, id2 0xff
> Trying Mx29f002, 256 KB
> probe_29f002: id1 37, id2 0
> Trying SST29EE020A, 256 KB
> probe_jedec: id1 0x25, id2 0x0
> Trying SST28SF040A, 512 KB
> probe_28sf040: id1 0xff, id2 0xff
> Trying SST39SF020A, 256 KB
> probe_39sf020: id1 0x25, id2 0x0
> Trying SST39VF020, 256 KB
> probe_39sf020: id1 0x25, id2 0x0
> Trying W29C011, 128 KB
> probe_jedec: id1 0x68, id2 0x5b
> Trying W29C020C, 256 KB
> probe_jedec: id1 0x25, id2 0x0
> Trying W49F002U, 256 KB
> probe_49f002: id1 0x25, id2 0x0
> Trying M29F400BT, 512 KB
> probe_m29f400bt: id1 0xff, id2 0xff
> Trying 82802ab, 512 KB
> probe_82802ab: id1 0xff, id2 0xff
> Trying 82802ac, 1024 KB
> probe_82802ab: id1 0xff, id2 0xff
> Trying MD-2802 (M-Systems DiskOnChip Millennium Module), 8 KB
> probe_md2802:
> probe_md2802: *******************************
> probe_md2802: * THIS IS A PRE ALPHA VERSION *
> probe_md2802: * IN THE DEVELOPEMENT *********
> probe_md2802: * PROCESS RIGHT NOW. **********
> probe_md2802: *******************************
> probe_md2802: * IF YOU ARE NOT A DEVELOPER **
> probe_md2802: * THEN DO NOT TRY TO READ OR **
> probe_md2802: * WRITE TO THIS DEVICE ********
> probe_md2802: *******************************
> probe_md2802:
> probe_md2802: switching off reset mode ...
> probe_md2802: switching off reset mode ... done
> probe_md2802:
> probe_md2802: switching off write protection ...
> probe_md2802: switching off write protection ... done
> probe_md2802:
> probe_md2802: IPL_0x0000: 0x41
> probe_md2802: IPL_0x0001: 0x77
> probe_md2802: IPL_0x0002: 0x61
> probe_md2802: IPL_0x0003: 0x72
> probe_md2802:
> probe_md2802: ChipID: 0x0e
> probe_md2802: DOCStatus: 0x17
> probe_md2802: FloorSelect: 0x01
> probe_md2802: CDSNControl: 0xeb
> probe_md2802: CDSNDeviceSelect: 0x2c
> probe_md2802: ECCConfiguration: 0xf6
> probe_md2802: CDSNSlowIO: 0x2e
> probe_md2802: ECCSyndrome0: 0x01
> probe_md2802: ECCSyndrome1: 0x86
> probe_md2802: ECCSyndrome2: 0xc4
> probe_md2802: ECCSyndrome3: 0x8b
> probe_md2802: ECCSyndrome4: 0x1e
> probe_md2802: ECCSyndrome5: 0x1c
> probe_md2802: AliasResolution: 0x83
> probe_md2802: ConfigurationInput: 0xc3
> probe_md2802: ReadPipelineInitialization: 0x02
> probe_md2802: LastDataRead: 0x1e
> probe_md2802:
> probe_md2802: checking ECCConfiguration toggle bit
> probe_md2802: 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
> probe_md2802: toggle result: 5/5
> EEPROM not found
> 
> Thank you, everyone for all the help. Hopefully, I can get this thing
> figured out eventually.
> 
> John
> 
> > On Fri, 26 Mar 2004, John Laur wrote:
> > > 2) I cannot for the life of me flash the BIOS under Linux. For now,
> I
> > > have to reboot to a DOS floppy and flash the original BIOS, then
> reboot
> > > again and flash the LinuxBIOS image (AWFLASH will for some reason
> not
> > > flash a LinuxBIOS image over a LinuxBIOS image already on the flash
> > > part) I have run 'setpci -s 0:11.0  40.b=54' as described in the
> docs
> > > and on the mailing list, but flash_rom still detects no flash
> device.
> > 
> > _______________________________________________
> > 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 johnl at blurbco.com  Fri Mar 26 14:47:00 2004
From: johnl at blurbco.com (John Laur)
Date: Fri Mar 26 14:47:00 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <Pine.LNX.4.44.0403261219320.19163-100000@ccs-mail.lanl.gov>
Message-ID: <00a801c4136e$e8e8fcd0$e100a8c0@oogigmcxtaxx>

So, am I correct to assume that flashing the BIOS on my board is not (at
least) yet possible with flash_rom? I don't have the experience to mess
with MTD, really, so I'll just stick with flashing from DOS. Thanks for
your help on this.

John

> -----Original Message-----
> From: Hendricks David W. [mailto:dwh at lanl.gov]
> Sent: Friday, March 26, 2004 1:20 PM
> To: John Laur
> Cc: linuxbios at clustermatic.org
> Subject: RE: EPIA-M "Magic Potion"?
> 
> Oops, it's not LPC compatible :( Ollie says we need a really old
mainboard
> to flash it.
> 
> Or perhaps MTD would work?
> 
> On Fri, 26 Mar 2004, John Laur wrote:
> 
> > > -----Original Message-----
> > > From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> > > admin at clustermatic.org] On Behalf Of Hendricks David W.
> > > Sent: Friday, March 26, 2004 11:49 AM
> > > To: John Laur
> > > Cc: linuxbios at clustermatic.org
> > > Subject: Re: EPIA-M "Magic Potion"?
> > >
> > > What is the model/part number on your flash? It *might* work with
the
> > code
> > > already in flash_and_burn, but we might need to add a device id or
> > > something.
> > >
> >
> > You will have to forgive me; I am still pretty green with this whole
> > thing. Which model/part number do you need exactly? I have included
some
> > information here, but if you need to know something else, please
just
> > let me know, and I'll be happy to provide it.
> >
> > I am using an RD1-PL Bios Savior with the original BIOS chip in the
> > socket. Flash_rom recognizes neither the original BIOS nor the
backup
> > flash part (I don't know exactly what chip the RD1-PL uses offhand.)
> >
> > When the RD1 is switched to the ORG (original bios), AWFLASH.EXE
reports
> > the following:
> >
> > For VT8623-8235-CLE26I01C-00 DATE: 12/11/2003
> > Flash Type - SST 39SF020 /5V
> >
> > The actual chip says on it:
> >
> > SST
> > MPF
> > 39SF020A
> > 70-4C-NH
> > 0219037-A
> >
> > Here is the output of my lspci -vvn for the southbridge (00:11.0 ISA
> > bridge: VIA Technologies, Inc. VT8235 ISA Bridge):
> >
> > 00:11.0 Class 0601: 1106:3177
> >         Subsystem: 1106:aa01
> >         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-
> >
> > Here is what flash_rom returns. As you can see it's probing for the
> > SST29SF020A, which is what I have, and failing:
> >
> > m3:~/freebios/util/flash_and_burn# setpci -s 0:11.0  40.b=54
> >
> > m3:~/freebios/util/flash_and_burn# ./flash_rom
> > Calibrating timer since microsleep sucks ... takes a second
> > Setting up microsecond timing loop
> > 199M loops per second
> > OK, calibrated, now do the deed
> > Enabling flash write on VT8235...OK
> > Trying Am29F040B, 512 KB
> > probe_29f040b: id1 0xff, id2 0xff
> > Trying At29C040A, 512 KB
> > probe_jedec: id1 0xff, id2 0xff
> > Trying Mx29f002, 256 KB
> > probe_29f002: id1 37, id2 0
> > Trying SST29EE020A, 256 KB
> > probe_jedec: id1 0x25, id2 0x0
> > Trying SST28SF040A, 512 KB
> > probe_28sf040: id1 0xff, id2 0xff
> > Trying SST39SF020A, 256 KB
> > probe_39sf020: id1 0x25, id2 0x0
> > Trying SST39VF020, 256 KB
> > probe_39sf020: id1 0x25, id2 0x0
> > Trying W29C011, 128 KB
> > probe_jedec: id1 0x68, id2 0x5b
> > Trying W29C020C, 256 KB
> > probe_jedec: id1 0x25, id2 0x0
> > Trying W49F002U, 256 KB
> > probe_49f002: id1 0x25, id2 0x0
> > Trying M29F400BT, 512 KB
> > probe_m29f400bt: id1 0xff, id2 0xff
> > Trying 82802ab, 512 KB
> > probe_82802ab: id1 0xff, id2 0xff
> > Trying 82802ac, 1024 KB
> > probe_82802ab: id1 0xff, id2 0xff
> > Trying MD-2802 (M-Systems DiskOnChip Millennium Module), 8 KB
> > probe_md2802:
> > probe_md2802: *******************************
> > probe_md2802: * THIS IS A PRE ALPHA VERSION *
> > probe_md2802: * IN THE DEVELOPEMENT *********
> > probe_md2802: * PROCESS RIGHT NOW. **********
> > probe_md2802: *******************************
> > probe_md2802: * IF YOU ARE NOT A DEVELOPER **
> > probe_md2802: * THEN DO NOT TRY TO READ OR **
> > probe_md2802: * WRITE TO THIS DEVICE ********
> > probe_md2802: *******************************
> > probe_md2802:
> > probe_md2802: switching off reset mode ...
> > probe_md2802: switching off reset mode ... done
> > probe_md2802:
> > probe_md2802: switching off write protection ...
> > probe_md2802: switching off write protection ... done
> > probe_md2802:
> > probe_md2802: IPL_0x0000: 0x41
> > probe_md2802: IPL_0x0001: 0x77
> > probe_md2802: IPL_0x0002: 0x61
> > probe_md2802: IPL_0x0003: 0x72
> > probe_md2802:
> > probe_md2802: ChipID: 0x0e
> > probe_md2802: DOCStatus: 0x17
> > probe_md2802: FloorSelect: 0x01
> > probe_md2802: CDSNControl: 0xeb
> > probe_md2802: CDSNDeviceSelect: 0x2c
> > probe_md2802: ECCConfiguration: 0xf6
> > probe_md2802: CDSNSlowIO: 0x2e
> > probe_md2802: ECCSyndrome0: 0x01
> > probe_md2802: ECCSyndrome1: 0x86
> > probe_md2802: ECCSyndrome2: 0xc4
> > probe_md2802: ECCSyndrome3: 0x8b
> > probe_md2802: ECCSyndrome4: 0x1e
> > probe_md2802: ECCSyndrome5: 0x1c
> > probe_md2802: AliasResolution: 0x83
> > probe_md2802: ConfigurationInput: 0xc3
> > probe_md2802: ReadPipelineInitialization: 0x02
> > probe_md2802: LastDataRead: 0x1e
> > probe_md2802:
> > probe_md2802: checking ECCConfiguration toggle bit
> > probe_md2802: 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01 0x01
> > probe_md2802: toggle result: 5/5
> > EEPROM not found
> >
> > Thank you, everyone for all the help. Hopefully, I can get this
thing
> > figured out eventually.
> >
> > John
> >
> > > On Fri, 26 Mar 2004, John Laur wrote:
> > > > 2) I cannot for the life of me flash the BIOS under Linux. For
now,
> > I
> > > > have to reboot to a DOS floppy and flash the original BIOS, then
> > reboot
> > > > again and flash the LinuxBIOS image (AWFLASH will for some
reason
> > not
> > > > flash a LinuxBIOS image over a LinuxBIOS image already on the
flash
> > > > part) I have run 'setpci -s 0:11.0  40.b=54' as described in the
> > docs
> > > > and on the mailing list, but flash_rom still detects no flash
> > device.
> > >
> > > _______________________________________________
> > > 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 dwh at lanl.gov  Fri Mar 26 15:12:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Mar 26 15:12:00 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <00a801c4136e$e8e8fcd0$e100a8c0@oogigmcxtaxx>
Message-ID: <Pine.LNX.4.44.0403261333190.19163-100000@ccs-mail.lanl.gov>

Maybe just not on that specific motherboard. Someone probably had it 
working on another motherboard, otherwise there we wouldn't have it in 
the code.

If you have some extra cash, you can try ordering a different part like 
the SST49LF080A.

 On Fri, 26 Mar 2004, John Laur wrote:

> So, am I correct to assume that flashing the BIOS on my board is not (at
> least) yet possible with flash_rom? 



From rminnich at lanl.gov  Fri Mar 26 15:14:59 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 26 15:14:59 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <Pine.LNX.4.44.0403261219320.19163-100000@ccs-mail.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403261339280.6641-100000@maxroach.lanl.gov>

On Fri, 26 Mar 2004, Hendricks David W. wrote:

> Oops, it's not LPC compatible :( Ollie says we need a really old mainboard 
> to flash it.

david, bring up the geode cluster again and use that to flash.

ron



From dwh at lanl.gov  Fri Mar 26 15:34:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Mar 26 15:34:00 2004
Subject: Using LinuxBios to protect against DRM in PC hardware?
In-Reply-To: <56931.130.76.32.145.1080230805.squirrel@secure.pennytracker.net>
Message-ID: <Pine.LNX.4.44.0403261351240.19163-100000@ccs-mail.lanl.gov>

Sounds about right. Though I'm not aware of anything that could prevent 
a DRM implementation by someone else in LinuxBIOS except for the fact that 
it's GPL'd.

DRM would have to be done in the way that it might be used in the 
Linux kernel. 

On Thu, 25 Mar 2004, Carl Youngblood wrote:

> Pardon me if I am off-base here (I don't know much about LinuxBios), but
> I've heard rumors/threats of new BIOSes that incorporate DRM into the BIOS
> and won't allow non-approved OSes to run on them.  Could LinuxBios be a
> way of protecting against this?
> 
> Thanks,
> Carl Youngblood
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rminnich at lanl.gov  Fri Mar 26 15:45:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Mar 26 15:45:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <00a801c4136e$e8e8fcd0$e100a8c0@oogigmcxtaxx>
Message-ID: <Pine.LNX.4.44.0403261409290.6641-100000@maxroach.lanl.gov>

stick with DOS until we work this out.

ron



From Antony at Soft-Solutions.co.uk  Fri Mar 26 15:49:00 2004
From: Antony at Soft-Solutions.co.uk (Antony Stone)
Date: Fri Mar 26 15:49:00 2004
Subject: Using LinuxBios to protect against DRM in PC hardware?
In-Reply-To: <56931.130.76.32.145.1080230805.squirrel@secure.pennytracker.net>
References: <56931.130.76.32.145.1080230805.squirrel@secure.pennytracker.net>
Message-ID: <200403262113.33860.Antony@Soft-Solutions.co.uk>

On Thursday 25 March 2004 4:06 pm, Carl Youngblood wrote:

> Pardon me if I am off-base here (I don't know much about LinuxBios), but
> I've heard rumors/threats of new BIOSes that incorporate DRM into the BIOS
> and won't allow non-approved OSes to run on them.  Could LinuxBios be a
> way of protecting against this?

I'm not aware of DRM BIOSes which stop you running non-approved OSes; however 
if you do so, then you won't be able to run DRM-aware applications, because 
the chain of assurance from hardware (TPM) to BIOS to OS to Application is 
broken (and that's what DRM-aware applications look for before they'll let 
you play with copyright materials).

As far as I'm aware, all current DRM / TCPA / TCG implementations allow you to 
boot whatever you like, but if it's not a certified OS then DRM applications 
simply won't play ball.

Obviously if you start LinuxBIOS instead of the motherboard vendor-supplied 
BIOS, you simply ignore the existence of the TPM chip/s.

Regards,

Antony.

-- 
There's no such thing as bad weather - only the wrong clothes.

 - Billy Connolly

                                                     Please reply to the list;
                                                           please don't CC me.



From ollie at lanl.gov  Fri Mar 26 16:20:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 26 16:20:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?= S2885 ht reset multi chain.
In-Reply-To: <3174569B9743D511922F00A0C94314230466D969@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D969@TYANWEB>
Message-ID: <1080337451.25319.201.camel@exponential.lanl.gov>

On Fri, 2004-03-26 at 12:22, YhLu wrote:
> Please find the change.diff.
> 
> Please still find the problem, please refer incoherent_ht.c and auto.c for
> s2885
> 
> regards
> 

It works, I will commit it soon.

Ollie




From johnl at blurbco.com  Fri Mar 26 16:29:00 2004
From: johnl at blurbco.com (John Laur)
Date: Fri Mar 26 16:29:00 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <014a01c41359$3dedaca0$0300a8c0@amr.corp.intel.com>
Message-ID: <00a901c4137d$1afa2f60$e100a8c0@oogigmcxtaxx>

Ron, Dimitry,

Not to get too far ahead of myself here, but it seems CVS is probably
not completely broken. I am booting into LinuxBIOS fine, just there is
no PCI Bus #1 and no IRQ's are assigned to anything.

The reason VGA is not initializing is because for some reason LinuxBIOS
is not seeing PCI Bus #1 and thus can't locate an 0x0300 VGA class PCI
device when it goes to init the VGA BIOS; otherwise, I think it would
probably work fine. The IRQ problem is a more serious issue...

Since memory detection is waiting on the v2 port and we have the flash
problem at least identified, I'm going to poke at this VGA/PCI/IRQ thing
some more and see what I can see...

Any ideas?

John

> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Dmitry Borisov
> Sent: Friday, March 26, 2004 11:39 AM
> To: linuxbios at clustermatic.org
> Subject: Re: EPIA-M "Magic Potion"?
> 
> Ron,
> I think the CVS is broken. 1 week ago I was trying to use it on my
M-6000
> and it failed. Let me take a diff between current CVS and what's
working
> for
> me( IDE+VGA+Splash ).
> Dmitry/
> 
> PS: I've plans to visit clusterworld, will stop by if any...
> 
> ----- Original Message -----
> Subject: Re: EPIA-M "Magic Potion"?
> 
> 
> >
> > I have incorporated dave's patches, which is why it ought to work
...
> >
> > ron
> >
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From ollie at lanl.gov  Fri Mar 26 17:01:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 26 17:01:00 2004
Subject: Cache On and ECC clear
In-Reply-To: <m34qsc58xh.fsf@maxwell.lnxi.com>
References: <1080257845.25319.187.camel@exponential.lanl.gov>
	 <m34qsc58xh.fsf@maxwell.lnxi.com>
Message-ID: <1080339905.25319.204.camel@exponential.lanl.gov>

On Fri, 2004-03-26 at 01:06, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > Eric,
> > 
> > I tried to call cache_on() first than the cpufixeup()
> > in cpu.c to fix the "slow ecc clear" problem. It still
> > works that way. Is there any reason we can't do this ?
> 
> Hmm.  I don't see this.  I have the cache on and things
> clear quite quickly.  I may have a slightly different calling
> order then the standard tree.  
> 
> Ollie can you compare what is checked into the tree with 
> the last release I did for Lightning?  It works there...
> 

BTW, why are you using inline asm to clearing the memory ?
Isn't it just one line in C to clear the memory ? Why not use
string instruction instead of mov ?

Ollie

> Eric
> 



From ebiederman at lnxi.com  Fri Mar 26 19:13:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 26 19:13:01 2004
Subject: Cache On and ECC clear
In-Reply-To: <1080339905.25319.204.camel@exponential.lanl.gov>
References: <1080257845.25319.187.camel@exponential.lanl.gov>
	<m34qsc58xh.fsf@maxwell.lnxi.com>
	<1080339905.25319.204.camel@exponential.lanl.gov>
Message-ID: <m3brmjt8v4.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Fri, 2004-03-26 at 01:06, Eric W. Biederman wrote:
> > Li-Ta Lo <ollie at lanl.gov> writes:
> > 
> > > Eric,
> > > 
> > > I tried to call cache_on() first than the cpufixeup()
> > > in cpu.c to fix the "slow ecc clear" problem. It still
> > > works that way. Is there any reason we can't do this ?
> > 
> > Hmm.  I don't see this.  I have the cache on and things
> > clear quite quickly.  I may have a slightly different calling
> > order then the standard tree.  
> > 
> > Ollie can you compare what is checked into the tree with 
> > the last release I did for Lightning?  It works there...
> > 
> 
> BTW, why are you using inline asm to clearing the memory ?

Mostly it was just a copy from the romcc code.  And I have
a little distrust of compilers when I want a tight loop.

> Isn't it just one line in C to clear the memory ? Why not use
> string instruction instead of mov ?

A string mov instruction is slower.

Eric



From ollie at lanl.gov  Fri Mar 26 19:20:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Mar 26 19:20:00 2004
Subject: Cache On and ECC clear
In-Reply-To: <m3brmjt8v4.fsf@maxwell.lnxi.com>
References: <1080257845.25319.187.camel@exponential.lanl.gov>
	 <m34qsc58xh.fsf@maxwell.lnxi.com>
	 <1080339905.25319.204.camel@exponential.lanl.gov>
	 <m3brmjt8v4.fsf@maxwell.lnxi.com>
Message-ID: <1080348263.25319.210.camel@exponential.lanl.gov>

On Fri, 2004-03-26 at 17:46, Eric W. Biederman wrote:
> Li-Ta Lo <ollie at lanl.gov> writes:
> 
> > On Fri, 2004-03-26 at 01:06, Eric W. Biederman wrote:
> > > Li-Ta Lo <ollie at lanl.gov> writes:
> > > 
> > > > Eric,
> > > > 
> > > > I tried to call cache_on() first than the cpufixeup()
> > > > in cpu.c to fix the "slow ecc clear" problem. It still
> > > > works that way. Is there any reason we can't do this ?
> > > 
> > > Hmm.  I don't see this.  I have the cache on and things
> > > clear quite quickly.  I may have a slightly different calling
> > > order then the standard tree.  
> > > 
> > > Ollie can you compare what is checked into the tree with 
> > > the last release I did for Lightning?  It works there...
> > > 
> > 
> > BTW, why are you using inline asm to clearing the memory ?
> 
> Mostly it was just a copy from the romcc code.  And I have
> a little distrust of compilers when I want a tight loop.
> 
> > Isn't it just one line in C to clear the memory ? Why not use
> > string instruction instead of mov ?
> 
> A string mov instruction is slower.
> 

I just tried with a stosl version. It is not slower at all.
We are using stosl in the asm code to clear stack and bss,
why not use it here too.

Ollie




From ebiederman at lnxi.com  Fri Mar 26 19:42:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Mar 26 19:42:00 2004
Subject: Cache On and ECC clear
In-Reply-To: <1080348263.25319.210.camel@exponential.lanl.gov>
References: <1080257845.25319.187.camel@exponential.lanl.gov>
	<m34qsc58xh.fsf@maxwell.lnxi.com>
	<1080339905.25319.204.camel@exponential.lanl.gov>
	<m3brmjt8v4.fsf@maxwell.lnxi.com>
	<1080348263.25319.210.camel@exponential.lanl.gov>
Message-ID: <m3ptazozsk.fsf@maxwell.lnxi.com>

Li-Ta Lo <ollie at lanl.gov> writes:

> On Fri, 2004-03-26 at 17:46, Eric W. Biederman wrote:
> > Li-Ta Lo <ollie at lanl.gov> writes:
> > 
> > > Isn't it just one line in C to clear the memory ? Why not use
> > > string instruction instead of mov ?
> > 
> > A string mov instruction is slower.
> > 
> 
> I just tried with a stosl version. It is not slower at all.

Usually stosl is coded in microcode...  I much prefer to work
with real instructions.  Since memory bandwidth is the bottleneck
it should not much matter.  stosl actually runs faster with the cache
disabled (because it needs fewer instruction fetches) which is another
good reason not to use it.

stosl is also not conductive to breaking the loop up or doing
other odd things if something goes wrong.  A mov based loop
is more straight forward to modify if it comes to that.  

A slightly better question is why am I not using a loop using the
sse registers, which would probably be the ideal case.  I don't have
a good answer to that but I seem to recall some documented errata.
Plus we are memory bandwidth limited not instruction dispatch limited
so the exact loop does not matter a lot.

Given the memory bandwidth limitation it probably means we
would not see a performance penalty if coded the loop in C.
However this piece of code is the dominant speed factor when
booting so I don't want to take chances.

> We are using stosl in the asm code to clear stack and bss,
> why not use it here too.

20/30K versus gigabytes.  stack and bss clearing simply do not matter
speed wise.

Eric


From kevin at koconnor.net  Fri Mar 26 19:57:01 2004
From: kevin at koconnor.net (Kevin O'Connor)
Date: Fri Mar 26 19:57:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <009601c41360$004dbfa0$e100a8c0@oogigmcxtaxx>
References: <Pine.LNX.4.44.0403261047220.19163-100000@ccs-mail.lanl.gov> <009601c41360$004dbfa0$e100a8c0@oogigmcxtaxx>
Message-ID: <20040327012111.GA888@ohio.localdomain>

On Fri, Mar 26, 2004 at 12:27:31PM -0600, John Laur wrote:
> You will have to forgive me; I am still pretty green with this whole
> thing. Which model/part number do you need exactly? I have included some
> information here, but if you need to know something else, please just
> let me know, and I'll be happy to provide it.
> 
> I am using an RD1-PL Bios Savior with the original BIOS chip in the
> socket. Flash_rom recognizes neither the original BIOS nor the backup
> flash part (I don't know exactly what chip the RD1-PL uses offhand.)

The RD1-PL is working fine on my EPIA M9000:

[root at tiny bios]# ./flash_rom romimage
Calibrating timer since microsleep sucks ... takes a second
Setting up microsecond timing loop
184M loops per second
OK, calibrated, now do the deed
Enabling flash write on VT8235...tried to set 0x45 to 0x55 on VT8235 failed (WARNING ONLY)
Trying Am29F040B, 512 KB
probe_29f040b: id1 0x7f, id2 0x45
Trying At29C040A, 512 KB
probe_jedec: id1 0xbf, id2 0xb6
Trying Mx29f002, 256 KB
probe_29f002: id1 191, id2 182
Trying SST29EE020A, 256 KB
probe_jedec: id1 0xbf, id2 0xb6
Trying SST28SF040A, 512 KB
probe_28sf040: id1 0x7f, id2 0x45
Trying SST39SF020A, 256 KB
probe_39sf020: id1 0xbf, id2 0xb6
SST39SF020A found at physical address: 0xfffc0000
Part is SST39SF020A
Programming Page: 0063 at address: 0x0003f000

This is with the switch set to "RD1".

Couple of notes:

- don't run the setpci command that is in the epia-m readme.  It causes all
  sorts of errors (if you already ran it, reboot and run flash_rom
  directly.)

- My flash_rom was compiled back in November; it is possible flash_rom has
  regressed.  If you're still having problems I can email you my binary.

- I guess it is also possible that there are different RD1-PL models out
  there..

-Kevin


From johnl at blurbco.com  Fri Mar 26 22:45:01 2004
From: johnl at blurbco.com (John Laur)
Date: Fri Mar 26 22:45:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <20040327012111.GA888@ohio.localdomain>
Message-ID: <00ab01c413b1$909a31a0$e100a8c0@oogigmcxtaxx>

Holy crap! It works if you blatantly *DONT* follow the documentation
and/or the advice  of the developers! (Just kidding guys; you all rock
;) Seriously, though, the README under src/mainboard/via/epia-m/ ought
to at least note that the setpci command is not necessary on some
epia-m's...

Both the original BIOS flash part and the RD1 flash part are recognized.
The RD1-PL uses W9F002U and the original BIOS is SST39SF020A like yours.
Both flash fine with flash_rom.

Thank you very much for clueing me in. Flashing works perfectly! That
DOS crap was a pain in the ass; especially since I had to pop the top to
add a floppy drive externally...

John

> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Kevin O'Connor
> Sent: Friday, March 26, 2004 7:21 PM
> To: John Laur
> Cc: linuxbios at clustermatic.org
> Subject: Re: EPIA-M "Magic Potion"?
> 
> On Fri, Mar 26, 2004 at 12:27:31PM -0600, John Laur wrote:
> > You will have to forgive me; I am still pretty green with this whole
> > thing. Which model/part number do you need exactly? I have included
some
> > information here, but if you need to know something else, please
just
> > let me know, and I'll be happy to provide it.
> >
> > I am using an RD1-PL Bios Savior with the original BIOS chip in the
> > socket. Flash_rom recognizes neither the original BIOS nor the
backup
> > flash part (I don't know exactly what chip the RD1-PL uses offhand.)
> 
> The RD1-PL is working fine on my EPIA M9000:
> 
> [root at tiny bios]# ./flash_rom romimage
> Calibrating timer since microsleep sucks ... takes a second
> Setting up microsecond timing loop
> 184M loops per second
> OK, calibrated, now do the deed
> Enabling flash write on VT8235...tried to set 0x45 to 0x55 on VT8235
> failed (WARNING ONLY)
> Trying Am29F040B, 512 KB
> probe_29f040b: id1 0x7f, id2 0x45
> Trying At29C040A, 512 KB
> probe_jedec: id1 0xbf, id2 0xb6
> Trying Mx29f002, 256 KB
> probe_29f002: id1 191, id2 182
> Trying SST29EE020A, 256 KB
> probe_jedec: id1 0xbf, id2 0xb6
> Trying SST28SF040A, 512 KB
> probe_28sf040: id1 0x7f, id2 0x45
> Trying SST39SF020A, 256 KB
> probe_39sf020: id1 0xbf, id2 0xb6
> SST39SF020A found at physical address: 0xfffc0000
> Part is SST39SF020A
> Programming Page: 0063 at address: 0x0003f000
> 
> This is with the switch set to "RD1".
> 
> Couple of notes:
> 
> - don't run the setpci command that is in the epia-m readme.  It
causes
> all
>   sorts of errors (if you already ran it, reboot and run flash_rom
>   directly.)
> 
> - My flash_rom was compiled back in November; it is possible flash_rom
has
>   regressed.  If you're still having problems I can email you my
binary.
> 
> - I guess it is also possible that there are different RD1-PL models
out
>   there..
> 
> -Kevin
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From kevin at koconnor.net  Sat Mar 27 00:00:00 2004
From: kevin at koconnor.net (Kevin O'Connor)
Date: Sat Mar 27 00:00:00 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <00ab01c413b1$909a31a0$e100a8c0@oogigmcxtaxx>
References: <20040327012111.GA888@ohio.localdomain> <00ab01c413b1$909a31a0$e100a8c0@oogigmcxtaxx>
Message-ID: <20040327052408.GA1360@ohio.localdomain>

On Fri, Mar 26, 2004 at 10:11:22PM -0600, John Laur wrote:
> Both the original BIOS flash part and the RD1 flash part are recognized.
> The RD1-PL uses W9F002U and the original BIOS is SST39SF020A like yours.
> Both flash fine with flash_rom.

That's odd - both the original and the RD1 show up as SST39SF020A for me.
Maybe there are multiple RD1-PL models floating around out there.

In anycase, I'm glad it works for you.
-Kevin


From linuxbios at xdr.com  Sat Mar 27 23:30:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Sat Mar 27 23:30:00 2004
Subject: EPIA-M "Magic Potion"?
Message-ID: <200403280455.i2S4t2RI009530@xdr.com>

I really should check this list more often. However I've been really busy...

I think I gathered that the VGA isn't showing up in the lspci. I
looked at the latest CVS and found my earlysetup.inc isn't getting included
in the Config in src/mainboard/via/epia-m. Actually the earlysetup.inc isn't
even there.

Here's what I have. This can go after
mainboardinit southbridge/via/vt8235/setup_misc.inc
// enable VGA device
        movl    $CONFIG_ADDR(0, 0x00, 0xe1), %eax
        movb    $0xbd, %dl // enable vga with 8 megs
        PCI_WRITE_CONFIG_BYTE


// The stupid firewire device (undocumented) steps on IO 0+ on reset
        movl    $CONFIG_ADDR(0, 0x0d*8, 0x15), %eax
        movb    $0x1c, %dl
        PCI_WRITE_CONFIG_BYTE


Both of the above are *required*.

The following is optional but works well for me. Our application has a pci
card in the slot that can impose an interrupt even after a cpu reset, so
this can cause a lockup. I got around this by doing a single hard pci bus
reset. In order to know if I've already done the reset once, I store a flag
in the CMOS memory. I think this is a good idea but my choice of where in
the CMOS to store the flag is probably not kosher.

// use CMOS byte 0x0e as marker so we only reboot once
        movb    $0x0e, %al
        mov     $0x70, %dx
        outb    %al, %dx
        inc     %dx
        inb     %dx, %al
        cmpb    $0xda, %al
        je      1f

        movl    $0x100000, %ecx
0:
        movw    $0x70,%dx
        mov     $0x0e,%al
        outb    %al, %dx
        inc     %dx
        movb    $0xda, %al
        outb    %al, %dx
        inb     %dx, %al
        cmpb    $0xda, %al
        je      4f
        dec     %ecx
        jne     0b

4:

        CONSOLE_INFO_TX_CHAR($'R')
        CONSOLE_INFO_TX_CHAR($'B')
        CONSOLE_INFO_TX_CHAR($'!')
        movl    $CONFIG_ADDR(0, 0x88, 0x4f), %eax
        movb    $0x09, %dl
        PCI_WRITE_CONFIG_BYTE

2:
        jmp     2b

1:
        sub     %al,%al
        outb    %al, %dx
3:


Finally, I implemented the SMBUS io for being able to access the serial
eeprom on the DDR module. I had it print out the contents of the serial
eeprom on bootup. I had hoped Ron or Eric or cwlinux would run with this and
implement the auto ddr memory config but that didn't happen.

Anyway after the topmost fix the VGA will probably appear in lspci.

-Dave



From linuxbios at xdr.com  Sat Mar 27 23:36:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Sat Mar 27 23:36:01 2004
Subject: EPIA-M "Magic Potion"?
Message-ID: <200403280501.i2S51C9d009571@xdr.com>

Here is the flash utility I use without problems on every epia-m I've ever
run across:
#include <unistd.h>
#include <sys/io.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <signal.h>

/*
   VIA EPIA-M BIOS Flash utility written by Dave Ashley for NXTV Software.
   Written 20030418 by Dave Ashley.
   Use at your own risk, no warranties are implied or given.
   This code released under the terms of the GPL.

   Currently only supports the SST39SF020A
*/


#define MEMNAME "/dev/mem"

void outpci(int addr,unsigned char value)
{
unsigned long val,mask;
int shift;
        outl(0x80000000 | (17<<11) | (addr&0xfc),0xcf8);
        val=inl(0xcfc);
        shift=(addr&3)<<3;
        mask=0xff<<shift;
        outl((val&~mask) | (value<<shift),0xcfc);
}
unsigned char inpci(int addr)
{
        outl(0x80000000 | (17<<11) | (addr&0xfc),0xcf8);
        return 255 & (inl(0xcfc)>>((addr&3)<<3));
}

unsigned char vt8235[4]={0x06, 0x11, 0x77, 0x31};

int getromsize(unsigned char *id)
{
        if(id[0]==0xbf && id[1]==0xb6) return 0x40000;
        if(id[0]==0xc2 && id[1]==0xb0) return 0x40000;
        return -1;
}

#define MAXROMSIZE 0x200000
unsigned char *buffer;

int loadfile(char *name)
{
int filefd;
int filesize;
        filefd=open(name,O_RDONLY);
        if(filefd<0)
        {
                printf("Couldn't open file %s\n",name);
                return -1;
        }
        filesize=read(filefd,buffer,MAXROMSIZE);
        close(filefd);
        if(filesize<0)
        {
                printf("Error trying to read from file %s\n",name);
        }
        return filesize;
}

void readbios(char *name,volatile unsigned char *where,int len)
{
int filefd;
int filesize;

        filefd=open(name,O_WRONLY|O_TRUNC|O_CREAT,0644);
        if(filefd<0)
        {
                printf("Couldn't create file %s for writing\n",name);
                return;
        }
        filesize=write(filefd,(void *)where,len);
        close(filefd);
        if(filesize!=len)
        {
                printf("Error during write of %s file\n",name);
                return;
        }
        printf("BIOS contents saved to %s, $%x bytes\n",name,len);
}

int verifybios(char *name,volatile unsigned char *where,int len, int print)
{
int filelen;
int i;
int same=0;

        filelen=loadfile(name);
        for(i=0;i<filelen;++i)
                if(where[i]!=buffer[i]) break;
        if(i<filelen)
        {
                if(print)
                        printf("BIOS contents does not match file %s, from byte $%x\n",
                                name,i);
        } else
        {
                if(print)
                        printf("BIOS contents match file %s for all of its $%x bytes\n",
                                name,i);
                same=1;
        }
        return same;
}

void writebios(char *name,volatile unsigned char *where,int len,unsigned char *id)
{
int i;
int p1,p2;

        if(len!=loadfile(name))
        {
                printf("File size does not match expected ROM size\n");
                return;
        }
        if(0 && (id[0]!=0xbf || id[1]!=0xb6))
        {
                printf("Don't know how to write this kind of flash device\n");
                return;
        }

        printf("Erasing device\n");
        where[0x5555]=0xaa;
        where[0x2aaa]=0x55;
        where[0x5555]=0x80;
        where[0x5555]=0xaa;
        where[0x2aaa]=0x55;
        where[0x5555]=0x10;

        for(;;)
        {
                printf(".");fflush(stdout);
                usleep(250000);
                if(where[0]==where[0] && where[0]==where[0])
                        break;
        }
        printf("BIOS erased\n");

        printf("Writing to BIOS\n");
        p1=-1;
        for(i=0;i<len;++i)
        {
                p2=100*i/(len-1);
                if(p2!=p1)
                {
                        printf("\r%d%%",p1=p2);
                        fflush(stdout);
                }
                where[0x5555]=0xaa;
                where[0x2aaa]=0x55;
                where[0x5555]=0xa0;
                where[i]=buffer[i];
                while(where[0]!=where[0] || where[0]!=where[0]);
        }
        printf("\n");
}

void helptext(char *name)
{
        printf("USE: %s <options>\n",name);
        printf("  -v <filename>  = verify bios rom contents with file\n");
        printf("  -w <filename>  = write to bios rom contents from file\n");
        printf("  -r <filename>  = read from bios rom contents to file\n");
        printf("  -f             = force erase/write even if contents already match\n");
        exit(0);
}

int main(int argc,char **argv)
{
int i;
int fd;
volatile unsigned char *where;
unsigned long save;
int vals;
unsigned char save4d;
int powermanagement;
unsigned char id[4];
char *filename=0;
char action=0;
int romsize;
int force=0;
int same;

        vals=0;

        if(argc<2) helptext(argv[0]);
        for(i=1;i<argc;++i)
        {
                if(argv[i][0]!='-')
                        helptext(argv[0]);
                switch(argv[i][1])
                {
                case 'f':
                        force=1;
                        break;
                case 'v':
                case 'w':
                case 'r':
                        action=argv[i][1];
                        if(i+1<argc)
                                filename=argv[++i];
                        else helptext(argv[0]);
                        break;
                default:
                        helptext(argv[0]);
                }

        }

        buffer=malloc(MAXROMSIZE);
        if(!buffer)
        {
                printf("No memory available!\n");
                exit(-1);
        }

        iopl(3);

        for(i=0;i<4;++i)
                if(inpci(i)!=vt8235[i])
                {
                        printf("Could not find VT8235 Bus control and power management device\n");
                        exit(-1);
                }

        fd=open(MEMNAME,O_RDWR);

        where=mmap(0,0x40000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0xfffc0000);
        if(where==(void *)0xffffffff)
        {
                printf("Could not mmap\n");
                exit(-2);
        }

// Determine where power management registers have been located
        powermanagement=(inpci(0x88)&0x80) | (inpci(0x89)<<8);

        save4d=inb(powermanagement+0x4d);
        outb(save4d | 0x80,powermanagement+0x4d); // enable writes to bios

        save=inpci(0x40);
        outpci(0x40,0x10 | save);// enable writes to bios, GPO15 must go high

        where[0x5555]=0xaa; // get into flash ID mode
        where[0x2aaa]=0x55;
        where[0x5555]=0x90;

        for(i=0;i<4;++i) id[i]=where[i];

        where[0x5555]=0xaa;
        where[0x2aaa]=0x55;
        where[0x5555]=0xf0;

        for(i=0;i<4;++i)
                if(id[i]!=where[i]) break;
        if(i==4)
        {
                printf("Could not read BIOS flashrom ID.\n");
                goto biosdone;
        }
        printf("ID %02x %02x\n",id[0],id[1]);
        romsize=getromsize(id);
        if(romsize<0)
        {
                printf("Unknown rom type\n");
                goto biosdone;
        }
        printf("romsize=$%x bytes\n",romsize);
        if(action=='r')
                readbios(filename,where,romsize);
        if(action=='w')
        {
                if(!force)
                        same=verifybios(filename,where,romsize,0);
                else
                        same=0;
                if(!same)
                        writebios(filename,where,romsize,id);
        }
        if(action=='v' || action=='w')
                verifybios(filename,where,romsize,1);

biosdone:
        outpci(0x40,save);// disable writes to bios
        outb(save4d,powermanagement+0x4d); // restore write protect bit

        return 0;
}


From rminnich at lanl.gov  Sun Mar 28 10:15:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Mar 28 10:15:01 2004
Subject: Cache On and ECC clear
In-Reply-To: <m3brmjt8v4.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403280839520.12731-100000@maxroach.lanl.gov>

On 26 Mar 2004, Eric W. Biederman wrote:

> 
> Mostly it was just a copy from the romcc code.  And I have
> a little distrust of compilers when I want a tight loop.

for clarity and keep our other 3rd parties happy that's going to become C, 
hope nobody minds.

ron



From rminnich at lanl.gov  Sun Mar 28 10:21:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Mar 28 10:21:01 2004
Subject: Cache On and ECC clear
In-Reply-To: <1080348263.25319.210.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0403280845370.12731-100000@maxroach.lanl.gov>

On Fri, 26 Mar 2004, Li-Ta Lo wrote:

> 
> I just tried with a stosl version. It is not slower at all.
> We are using stosl in the asm code to clear stack and bss,
> why not use it here too.

Pure performance is not the only goal. Readability is. This code is in a C 
function, it is not essential that it be assembly, it should become C. 

ron



From rminnich at lanl.gov  Sun Mar 28 10:26:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Mar 28 10:26:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <00ab01c413b1$909a31a0$e100a8c0@oogigmcxtaxx>
Message-ID: <Pine.LNX.4.44.0403280849420.12731-100000@maxroach.lanl.gov>

On Fri, 26 Mar 2004, John Laur wrote:

> Holy crap! It works if you blatantly *DONT* follow the documentation
> and/or the advice of the developers! (Just kidding guys; you all rock ;)
> Seriously, though, the README under src/mainboard/via/epia-m/ ought to
> at least note that the setpci command is not necessary on some
> epia-m's...

Whoever wrote that needs to fix it, but if they don't step up I'll do it.

Sorry about that.

ron



From rminnich at lanl.gov  Sun Mar 28 10:26:12 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Mar 28 10:26:12 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <20040327052408.GA1360@ohio.localdomain>
Message-ID: <Pine.LNX.4.44.0403280850360.12731-100000@maxroach.lanl.gov>

On Sat, 27 Mar 2004, Kevin O'Connor wrote:

> That's odd - both the original and the RD1 show up as SST39SF020A for me.
> Maybe there are multiple RD1-PL models floating around out there.

sure. It's a standard pinout so they're going to plug in whatever is 
cheapest at the time. It's the PC world,

ron



From rminnich at lanl.gov  Sun Mar 28 10:33:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Mar 28 10:33:00 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <200403280455.i2S4t2RI009530@xdr.com>
Message-ID: <Pine.LNX.4.44.0403280857140.12731-100000@maxroach.lanl.gov>

dave, can you send me a diff -u and I'll apply that patch.

thanks

ron



From rminnich at lanl.gov  Sun Mar 28 13:17:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Mar 28 13:17:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <200403280455.i2S4t2RI009530@xdr.com>
Message-ID: <Pine.LNX.4.44.0403281141210.13511-100000@maxroach.lanl.gov>

sorry, Dave, I saw that last part of your note where I had not used your 
smbus stuff yet for V2. It's in the queue, hang in there, we had some K8 
stuff take longer than we hoped.

ron



From ebiederman at lnxi.com  Sun Mar 28 17:14:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Mar 28 17:14:00 2004
Subject: Cache On and ECC clear
In-Reply-To: <Pine.LNX.4.44.0403280839520.12731-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403280839520.12731-100000@maxroach.lanl.gov>
Message-ID: <m3r7vcio5b.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 26 Mar 2004, Eric W. Biederman wrote:
> 
> > 
> > Mostly it was just a copy from the romcc code.  And I have
> > a little distrust of compilers when I want a tight loop.
> 
> for clarity and keep our other 3rd parties happy that's going to become C, 
> hope nobody minds.

Fine, I think.  

But please break it out into it's own separate inline function.

It has two very strong requirements.
1) That we never trigger a hardware read on the addresses were are clearing
   before we have triggered a hardware write.  The fact I setup the area
   as uncached but write-combining ensures this.
2) That this code runs very fast.  It needs to be able to run at 6.4GB/s
   when you have dual channel PC3200 DDR installed.  This is one of the
   reasons we run it on a per cpu basis.  The loop can only run at 4.0GB/s
   from the other cpu.

When we don't need the fine grained control of assembly to meet these
requirements I don't have a problem with writing the code in C.  When
we do need the control we must be able to write it.

In part booting faster boots more correctly because the hardware
transitions from some half setup state to completely setup more
quickly.

Eric


From ebiederman at lnxi.com  Sun Mar 28 17:19:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Mar 28 17:19:01 2004
Subject: romcc -O and -O2
In-Reply-To: <m3hdwcif8f.fsf@maxwell.lnxi.com>
References: <3174569B9743D511922F00A0C94314230466D909@TYANWEB>
	<m3hdwcif8f.fsf@maxwell.lnxi.com>
Message-ID: <m3d66winxf.fsf@maxwell.lnxi.com>

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

> YhLu <YhLu at tyan.com> writes:
> 
> > Eric,
> > 
> > What's the difference of -O and -O2? t seems -O2 can produce small code for
> > auto.c.
> 
> The set of optimizations performed.  Essentially the difference
> -O2 performs conditional constant propagation.  
> 
> Historically there have been some bugs with -02, but they should not apply
> at this point.

Also it is worth nothing that all of my optimizations are either to reduce
register pressure or to reduce code size.  In general less code needs fewer
registers.  There is an exception in the case of function calls, to functions
that are called more than once, because you need to remember you
return address somewhere, and that takes a register.

Eric


From ebiederman at lnxi.com  Sun Mar 28 17:34:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Mar 28 17:34:01 2004
Subject: is_cpu_pre_c0()
In-Reply-To: <Pine.LNX.4.44.0403241306370.19002-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403241306370.19002-100000@maxroach.lanl.gov>
Message-ID: <m3vfkoefjc.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 24 Mar 2004, Eric W. Biederman wrote:
> 
> > That is a major challenge.  I have a back burner project to make romcc
> > not inline all function calls.  But until I do that I don't know of a
> > good way to reduce the code size.
> 
> 
> actually there is an easy way I tested way back that worked out ok. 
> 
> You put the linuxbios_c payload BEFORE the auto.c-generated code. That
> really opens up the space. Requires some .lds hacking. I forget why I
> never committed it -- might have been an issue with mapping the ROM space. 
> It may have been because we did not have the new config tool and it was 
> too much work.

There is an issue with mapping ROM space, which means at least the code
to open that up needs to be within 64K or so.

Beyond that there is the piece that with if LinuxBIOS gets to big we can't
stuff a kernel in there.  And until we have exhausted all of our options
to shrink it we should not give LinuxBIOS too much license to grow.

Size will always be an important consideration for LinuxBIOS.

Currently code generated by romcc is a factor of 3 larger than hand
generated assembly.  If can get a correct implementation that does
not inline everything we should see a significant reduction in code
size.

I have incorrect implementations that show a lot of promise.  Hopefully
I can find the time to build a correct version.

My rough numbers suggest that if we can keep LinuxBIOS to 64KB.  We can
squeeze a kernel in there with a 512KByte flash chip.  If we can't using
a kernel is pushed out farther in time.

Eric


From linuxbios at xdr.com  Sun Mar 28 19:30:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Sun Mar 28 19:30:00 2004
Subject: EPIA-M "Magic Potion"?
Message-ID: <200403290054.i2T0su8e013697@xdr.com>

Ron says:

>dave, can you send me a diff -u and I'll apply that patch.

Between what and what? Your source and my source have forked hopelessly
apart. A human has to step in and integrate the changes. I certainly don't
have time to do it. In fact I had thought when I passed my patch back to
this group July 2003 my version would have been integrated. If I send you
a patch now, maybe that will just gather dust again and we'll have to go
through this all again later.

Meanwhile I explained in the email what had to be patched and how, start
with that. This should get VGA working at least. Maybe that's all that's
left. Note I'm not actually building the latest cvs version of linuxbios,
I just looked at the files and saw the vga init code wasn't there.

-Dave


From don at bowery.com  Sun Mar 28 21:23:01 2004
From: don at bowery.com (Don Elwell)
Date: Sun Mar 28 21:23:01 2004
Subject: mkelfImage initrd help
In-Reply-To: <4061A1EF.5000906@bowery.com>
References: <Pine.LNX.4.44.0403240734410.18454-100000@maxroach.lanl.gov> <4061A1EF.5000906@bowery.com>
Message-ID: <40678D2F.2030908@bowery.com>

The saga continues:

I have more information on this problem.  A stock 2.4.25 kernel from 
www.kernel.org does not work.  A stock 2.4.24 kernel from www.kernel.org 
does work.  They were compiled with identical .config files (I'd be 
happy to send them along for anyone curious).

Here is where I'm at:

STD BIOS->Etherboot->Linux + Initrd (single kernel from mkelfImage) 
works great for all kernels I've tried except 2.4.25.  This includes 
2.4.21 and 2.4.22.  It also includes 2.6.0-test3.

STD BIOS->ISOLINUX->Linux + Initrd (separate files) works for all 
kernels, even 2.4.25.

I'm going to try to continue down this path of assuming its the 
difference between the two kernels.  Anyone care to venture a guess on 
where to start looking?

-don

Don Elwell wrote:

> 
> ron minnich wrote:
> 
>> well your output is very puzzling. We do this all the time, although I 
>> have not yet tried 2.4.25. I think the last time I did this was 2.4.22
>>
> 
> The exact same setup (identical initrd image) works perfectly with 
> 2.4.22 *and* 2.6.0-test3 kernels.  I'll be building and trying a plain 
> (i.e. from www.kernel.org) 2.4.25 kernel this evening (the version I've 
> been testing with is the -lck1 performance patches -- which themselves 
> could be causing the problem).
> 
>> It's almost as though something in the kernel is trashing the ramdisk 
>> when it starts up.
>> But you say it did work from cdrom, which makes this even weirder.
>>
> 
> Yes, the errant kernel (2.4.25) will boot from CD-ROM using ISOLINUX 
> (separate kernel/initrd images).  That identical image will not boot 
> using Etherboot (single kernel/initrd image made with mkelfImage).  By 
> simply replacing the kernel in the mkelfImage to either 2.4.22 or 
> 2.6.0-test3 the system boots normally.
> 
>> I hope it is not some random DMA from ethernet landing sometime after 
>> kernel starts, but it sounds too reproducible.
> 
> 
> I agree.  This happens exactly the same time, every time.  Coupled with 
> the fact that the other kernels work, I think Etherboot and mkelfImage 
> are doing what they are supposed to do.
> 
>> I think you're stuck with some more etherboot debugging. Do you have 
>> to use net boot?
> 
> 
> The systems we're building only have Ethernet/serial to the outside 
> world (they do have a CF internal).  My thought was to have them net 
> boot in their production test that (in addition to running production 
> tests on the system) also puts the correct application image(s) on the 
> CF.  Also, I didn't want the techs to have to take apart the units to 
> re-image the CF.
> 
> But, PROGRESS!!!!!  I'm not married to the 2.4.25 kernel in any way.  I 
> could just as easily use 2.4.22 (which we use in other systems now 
> anyway).  (unfortunately :-) ) My curiosity has been piqued -- I gotta 
> know whats causing this!
> 
> More to come.
> 
> -don
> 



From jbors at mail.ru  Sun Mar 28 21:35:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Sun Mar 28 21:35:01 2004
Subject: EPIA-M "Magic Potion"?
References: <00a901c4137d$1afa2f60$e100a8c0@oogigmcxtaxx>
Message-ID: <00cb01c41539$f98245c0$0300a8c0@amr.corp.intel.com>

Subject: RE: EPIA-M "Magic Potion"?


> Ron, Dimitry,
>
> Not to get too far ahead of myself here, but it seems CVS is probably
> not completely broken. I am booting into LinuxBIOS fine, just there is
> no PCI Bus #1 and no IRQ's are assigned to anything.
>
> The reason VGA is not initializing is because for some reason LinuxBIOS
> is not seeing PCI Bus #1 and thus can't locate an 0x0300 VGA class PCI
> device when it goes to init the VGA BIOS; otherwise, I think it would
> probably work fine. The IRQ problem is a more serious issue...
>
> Since memory detection is waiting on the v2 port and we have the flash
> problem at least identified, I'm going to poke at this VGA/PCI/IRQ thing
> some more and see what I can see...
>
> Any ideas?
>
> John

Guys,
Here is the patch to make EPIA-M work with splash and VGA. See attached
config for my settings...

Ron,
FYI:  I did some changes in hardwaremain.c to make sure splash is called
after VGA init and early enough to see the splash.
It may brake some other builds, unlikely though...

Enjoy,
Dmitry/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: epia-m-vga-splash.patch.gz
Type: application/octet-stream
Size: 10755 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040328/e19dccb4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.config
Type: application/octet-stream
Size: 1486 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040328/e19dccb4/attachment-0001.obj>

From johnl at blurbco.com  Sun Mar 28 23:00:01 2004
From: johnl at blurbco.com (John Laur)
Date: Sun Mar 28 23:00:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <200403290054.i2T0su8e013697@xdr.com>
Message-ID: <00b901c41546$1adcaba0$e100a8c0@oogigmcxtaxx>

Dave, Ron, Dmitry,

The patches Dave sent were great! The earlysetup.inc successfully gets
VGA going (the pci hard reset is not necessary in my configuration), and
the flash application helped me realize what a POS this winbond flash
chip in my RD1-PL is... The automatic verification in the tool is very
useful. Thank you, Dave.

I am happy to put together patches to current CVS providing I can get
something working well. Dmitry has just sent a patch for splash that
hopefully will help me set some things up so that I can hand over to
vesafb or viafb. Dmitry, did I see somewhere that you had a patch for
making viafb work correctly when compiled into the kernel? 2.6
vesafb+vm86d might also be a possibility to get framebuffer init that I
will investigate after exhausting alternatives. Anyway, if I can
consolidate all these patches, I'll make a unified one that can
hopefully fix CVS if that is OK with everybody.

Anyway, on to the last current problems:

Even though the sytem is more functional, I still can't do much;
however, because my PCI devices still do not seem to be getting assigned
IRQ's. Is there something I'm just missing here like a kernel patch, or
maybe there is still something else that is not in the current freebios
CVS?

Next, is there a way to hardcode the amount of ram in v1? I know
autodetection does not work, but even if I could just manually have the
machine set up the full 512MB that would help me a lot until the v2 port
progresses.

I will try working with Dmitry's changes that he has sent this evening
and post results soon. I'm hoping I'll find the IRQ problems..

Thanks again, everyone for all the help!

John 

> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Dave Ashley
> Sent: Sunday, March 28, 2004 6:55 PM
> To: linuxbios at clustermatic.org
> Subject: Re: EPIA-M "Magic Potion"?
> 
> Ron says:
> 
> >dave, can you send me a diff -u and I'll apply that patch.
> 
> Between what and what? Your source and my source have forked
hopelessly
> apart. A human has to step in and integrate the changes. I certainly
don't
> have time to do it. In fact I had thought when I passed my patch back
to
> this group July 2003 my version would have been integrated. If I send
you
> a patch now, maybe that will just gather dust again and we'll have to
go
> through this all again later.
> 
> Meanwhile I explained in the email what had to be patched and how,
start
> with that. This should get VGA working at least. Maybe that's all
that's
> left. Note I'm not actually building the latest cvs version of
linuxbios,
> I just looked at the files and saw the vga init code wasn't there.
> 
> -Dave
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From jbors at mail.ru  Sun Mar 28 23:29:00 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Sun Mar 28 23:29:00 2004
Subject: EPIA-M "Magic Potion"?
References: <00b901c41546$1adcaba0$e100a8c0@oogigmcxtaxx>
Message-ID: <012601c41549$e5778df0$0300a8c0@amr.corp.intel.com>

> vesafb or viafb. Dmitry, did I see somewhere that you had a patch for
> making viafb work correctly when compiled into the kernel? 2.6

Yes I have a patch for 2.4.23-epia1 that integrates viafb into kernel.
Should work with all kernels though.

> hopefully fix CVS if that is OK with everybody.

That would be cool.

> Even though the sytem is more functional, I still can't do much;
> however, because my PCI devices still do not seem to be getting assigned
> IRQ's. Is there something I'm just missing here like a kernel patch, or

I don't have external PCI devices, All built ins working properly( except
CLE266 which points to improper initialization ).

> Next, is there a way to hardcode the amount of ram in v1? I know
> autodetection does not work, but even if I could just manually have the
> machine set up the full 512MB that would help me a lot until the v2 port
> progresses.

I tried that but in fact ran into serious problems with DFB. Something went
wrong... So I stuck with 96M at this time...

Dmitry/



From rminnich at lanl.gov  Sun Mar 28 23:34:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Mar 28 23:34:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <200403290054.i2T0su8e013697@xdr.com>
Message-ID: <Pine.LNX.4.44.0403282157570.17726-100000@maxroach.lanl.gov>

On Sun, 28 Mar 2004, Dave Ashley wrote:

> Between what and what? Your source and my source have forked hopelessly
> apart. A human has to step in and integrate the changes. I certainly
> don't have time to do it. In fact I had thought when I passed my patch
> back to this group July 2003 my version would have been integrated. If I
> send you a patch now, maybe that will just gather dust again and we'll
> have to go through this all again later.

no, I committed that last patch, and I thought I had closed the loop, so 
I'm not sure why that part got missed.

OK, I'll just go with your last post.

ron



From rminnich at lanl.gov  Sun Mar 28 23:39:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Mar 28 23:39:00 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <00b901c41546$1adcaba0$e100a8c0@oogigmcxtaxx>
Message-ID: <Pine.LNX.4.44.0403282200000.17726-100000@maxroach.lanl.gov>

On Sun, 28 Mar 2004, John Laur wrote:

> I am happy to put together patches to current CVS providing I can get
> something working well.

Go for it. I thought I had managed to bring all Dave's stuff in but 
clearly that did not happen. 


> Even though the sytem is more functional, I still can't do much;
> however, because my PCI devices still do not seem to be getting assigned
> IRQ's. Is there something I'm just missing here like a kernel patch, or
> maybe there is still something else that is not in the current freebios
> CVS?


Let's get your first patch in, then look at IRQs.

ron



From rminnich at lanl.gov  Sun Mar 28 23:41:39 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Mar 28 23:41:39 2004
Subject: Cache On and ECC clear
In-Reply-To: <m3r7vcio5b.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0403282202210.17726-100000@maxroach.lanl.gov>

On 28 Mar 2004, Eric W. Biederman wrote:


> But please break it out into it's own separate inline function.
> 
> It has two very strong requirements.
> 1) That we never trigger a hardware read on the addresses were are clearing
>    before we have triggered a hardware write.  The fact I setup the area
>    as uncached but write-combining ensures this.
> 2) That this code runs very fast.  It needs to be able to run at 6.4GB/s
>    when you have dual channel PC3200 DDR installed.  This is one of the
>    reasons we run it on a per cpu basis.  The loop can only run at 4.0GB/s
>    from the other cpu.
> 

ok, if it stays assembly this explanation will be put in with it. 

ron



From johnl at blurbco.com  Mon Mar 29 01:15:01 2004
From: johnl at blurbco.com (John Laur)
Date: Mon Mar 29 01:15:01 2004
Subject: EPIA-M "Magic Potion"?
In-Reply-To: <012601c41549$e5778df0$0300a8c0@amr.corp.intel.com>
Message-ID: <00bd01c41559$07cc2af0$e100a8c0@oogigmcxtaxx>

Thank you, Dmitry. Your patches seem to fix a lot of my remaining
problems.

The kernel patch to make viafb work as compiled-in gets a framebuffer
going very soon after the kernel loads. I extended it a little bit to
allow for full selection of all module parameters from the kernel
commandline. I guess since it didn't work, nobody ever used the kernel
commandline params :) The vga stuff is now working perfectly except for
hardware-assisted.

The other thing that fixed a lot of issues is that I switched to an
earlier vga bios (extracted from bios v1.10F). I was trying to use the
latest one released with BIOS version 1.13 and it seems to not work
correctly. I'm going to try again now that I have some other stuff
working to verify that this is the case. Something bad running in the
1.13 vga bios I believe could have been the cause of my IRQ issues,
which are solved for the moment as well.

Whenever I can make the dust clear, I'll create a diff for CVS including
either amending the existing HOWTO with the information I have learned
or creating a new one especially for EPIA-M. I'll also include the viafb
patch from Dmitry + my extra changes in kernel-patches.

The final three non-memory related problems I'm looking at are:

1) trying to load the agpgart module hangs the system
2) applications hang when accessing the hardware clock
3) via_v4l_drv (hardware MPEG acceleration) wants to be loaded before
viafb in order to work unfortunately

Again, thanks everyone!

John

> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Dmitry Borisov
> Sent: Sunday, March 28, 2004 10:54 PM
> To: linuxbios at clustermatic.org
> Subject: Re: EPIA-M "Magic Potion"?
> 
> > vesafb or viafb. Dmitry, did I see somewhere that you had a patch
for
> > making viafb work correctly when compiled into the kernel? 2.6
> 
> Yes I have a patch for 2.4.23-epia1 that integrates viafb into kernel.
> Should work with all kernels though.
> 
> > hopefully fix CVS if that is OK with everybody.
> 
> That would be cool.
> 
> > Even though the sytem is more functional, I still can't do much;
> > however, because my PCI devices still do not seem to be getting
assigned
> > IRQ's. Is there something I'm just missing here like a kernel patch,
or
> 
> I don't have external PCI devices, All built ins working properly(
except
> CLE266 which points to improper initialization ).
> 
> > Next, is there a way to hardcode the amount of ram in v1? I know
> > autodetection does not work, but even if I could just manually have
the
> > machine set up the full 512MB that would help me a lot until the v2
port
> > progresses.
> 
> I tried that but in fact ran into serious problems with DFB. Something
> went
> wrong... So I stuck with 96M at this time...
> 
> Dmitry/
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From jbors at mail.ru  Mon Mar 29 01:34:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Mon Mar 29 01:34:01 2004
Subject: EPIA-M "Magic Potion"?
References: <00bd01c41559$07cc2af0$e100a8c0@oogigmcxtaxx>
Message-ID: <017401c4155b$48a6ba70$0300a8c0@amr.corp.intel.com>

Subject: RE: EPIA-M "Magic Potion"?


> Thank you, Dmitry. Your patches seem to fix a lot of my remaining
> problems.

Good.

> The kernel patch to make viafb work as compiled-in gets a framebuffer
> going very soon after the kernel loads. I extended it a little bit to
> allow for full selection of all module parameters from the kernel
> commandline. I guess since it didn't work, nobody ever used the kernel
> commandline params :) The vga stuff is now working perfectly except for
> hardware-assisted.

All params works in my case... But still I would be interested in your
changes...

> 3) via_v4l_drv (hardware MPEG acceleration) wants to be loaded before
> viafb in order to work unfortunately

I'm going to release MPEG-2 support builtin for ffmpeg/mplayer under DFB. No
need for X/v4l/etc.
It is working already, but still I want to scrub something. Will let you
know at earliest.

Dmitry/




From YhLu at tyan.com  Mon Mar 29 19:22:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Mar 29 19:22:00 2004
Subject: =?GB2312?B?tPC4tDogQ2FjaGUgT24gYW5kIEVDQyBjbGVhcg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466DA6D@TYANWEB>

Eric,

I verified the exchange the cpufixup after the cache_on...mtrr_check in cpu.
c for S2882.

Found one interesting thing
1. In fallback mode, it does not pause after "Clearing LinuxBIOS memory "
and "Copying LinuxBIOS to ram".
2. In normal node, it does pause after the "Clearing" and "Copying" ( 5s and
4s).

What could cause that?

Regards

YH
-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?3?28? 21:03
???: Eric W. Biederman
??: Li-Ta Lo; LinuxBIOS
??: Re: Cache On and ECC clear

On 28 Mar 2004, Eric W. Biederman wrote:


> But please break it out into it's own separate inline function.
> 
> It has two very strong requirements.
> 1) That we never trigger a hardware read on the addresses were are
clearing
>    before we have triggered a hardware write.  The fact I setup the area
>    as uncached but write-combining ensures this.
> 2) That this code runs very fast.  It needs to be able to run at 6.4GB/s
>    when you have dual channel PC3200 DDR installed.  This is one of the
>    reasons we run it on a per cpu basis.  The loop can only run at 4.0GB/s
>    from the other cpu.
> 

ok, if it stays assembly this explanation will be put in with it. 

ron

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


From ebiederman at lnxi.com  Mon Mar 29 19:43:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Mar 29 19:43:00 2004
Subject: =?gb2312?b?tPC4tA==?=: Cache On and ECC clear
In-Reply-To: <3174569B9743D511922F00A0C94314230466DA6D@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466DA6D@TYANWEB>
Message-ID: <m3ad1zuo8n.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I verified the exchange the cpufixup after the cache_on...mtrr_check in cpu.
> c for S2882.
> 
> Found one interesting thing
> 1. In fallback mode, it does not pause after "Clearing LinuxBIOS memory "
> and "Copying LinuxBIOS to ram".
> 2. In normal node, it does pause after the "Clearing" and "Copying" ( 5s and
> 4s).
> 
> What could cause that?

So we are talking about quantities all within the first 1MB of ram...

This sounds like something is goofy with the mtrrs.  At least that
is the usual suspect when something is running slowly.

Eric


From YhLu at tyan.com  Mon Mar 29 23:48:00 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Mar 29 23:48:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogQ2FjaGUgT24gYW5kIEVDQyBjbGVhcg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466DA9E@TYANWEB>

Eric,

It seems it's all right in mtrr setting. Except 0x201 and 0x203 setting in
earlymtrr.inc should set 0xff for msr.hi intead of 0xf

Before mtrr processing for clearing

Normal mode
0000=0x0000000000000006
0001=0x000000fffff00800
0002=0x00000000fffe8006
0003=0x000000fffffe8800

Fallback mode
0000=0x0000000000000006
0001=0x000000fffff00800
0002=0x00000000fffd0006
0003=0x000000fffffe8800

after mtrr processing for clearing,

Normal mode
0000=0x0000000000000001
0001=0x000000fffff00800
0002=0x00000000fffe8006
0003=0x000000fffffe8800

Fallback mode
0000=0x0000000000000001
0001=0x000000fffff00800
0002=0x00000000fffd0006
0003=0x000000fffffe8800

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?29? 17:18
???: YhLu
??: ron minnich; Li-Ta Lo; LinuxBIOS
??: Re: ??: Cache On and ECC clear

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I verified the exchange the cpufixup after the cache_on...mtrr_check in
cpu.
> c for S2882.
> 
> Found one interesting thing
> 1. In fallback mode, it does not pause after "Clearing LinuxBIOS memory "
> and "Copying LinuxBIOS to ram".
> 2. In normal node, it does pause after the "Clearing" and "Copying" ( 5s
and
> 4s).
> 
> What could cause that?

So we are talking about quantities all within the first 1MB of ram...

This sounds like something is goofy with the mtrrs.  At least that
is the usual suspect when something is running slowly.

Eric


From ebiederman at lnxi.com  Tue Mar 30 01:15:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Mar 30 01:15:01 2004
Subject: =?gb2312?b?tPC4tA==?=: =?gb2312?b?tPC4tA==?=: Cache On and ECC
  clear
In-Reply-To: <3174569B9743D511922F00A0C94314230466DA9E@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466DA9E@TYANWEB>
Message-ID: <m3ad1yu8vw.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> It seems it's all right in mtrr setting. Except 0x201 and 0x203 setting in
> earlymtrr.inc should set 0xff for msr.hi intead of 0xf
> 
> Before mtrr processing for clearing

Hmm.  Assuming 0000 == 0x200, 0001 == 0x201 etc.  So
you have to base and mask pairs.
 
> Normal mode
> 0000=0x0000000000000006
> 0001=0x000000fffff00800
> 0002=0x00000000fffe8006
  This is a base address 4GB - 96K
> 0003=0x000000fffffe8800 
  This is a size and it tries to be 96K.
  It is actually something like 32K.
 
> Fallback mode
> 0000=0x0000000000000006
> 0001=0x000000fffff00800
> 0002=0x00000000fffd0006 
  This is a base address 4GB - 160K
> 0003=0x000000fffffe8800 
  This is a size aand it tries to be 96K.
  It is actually something like 32K.

So somehow you got at non power of 2 size into XIP_ROM_SIZE.  So much less
of your code is cached than you would expect.  So instruction fetches take
a very long time.  And loops are slow.

The comments from my HDAMA Config.lb 
## XIP_ROM_SIZE must be a power of 2.
## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE

It looks like these needs to be enforced, somehow so build time mistakes
don't happen. Perhaps:
#if ((XIP_ROM_BASE % XIP_ROM_SIZE) != 0) || ((XIP_ROM_SIZE & (XIP_ROM_SIZE - 1)) != 0)
#error XIP_ROM_SIZE must be a power of 2 and XIP_ROM_BASE must be a multiple of it
#endif


Eric


From vberdin at eazix.com  Tue Mar 30 06:43:00 2004
From: vberdin at eazix.com (Vic Berdin)
Date: Tue Mar 30 06:43:00 2004
Subject: A bit OT: external equipment for writing...
Message-ID: <DDEILMFEIOAIPEHIAEPACEDACAAA.vberdin@eazix.com>

Hi,

This maybe the wrong list to post this but since you guys are into
the field of creating your own BIOSware, I would like to ask if 
anyone knows of a device or equipment (connected via stadard PC port) 
that may be used in order to write data into a BIOS chip?

I am currently scouring the net for any material (software/hardware)
that can aid me in safely replacing the BIOSware on an SST49LF008A
FWH that socketted on an AMD GX2-based target board.
The said board and SST chip is not (yet) supported (or listed) by 
this project.

However, our goal is to replace the existing BIOSware with Linux.


TIA - Vic



From Antony at Soft-Solutions.co.uk  Tue Mar 30 07:04:00 2004
From: Antony at Soft-Solutions.co.uk (Antony Stone)
Date: Tue Mar 30 07:04:00 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <DDEILMFEIOAIPEHIAEPACEDACAAA.vberdin@eazix.com>
References: <DDEILMFEIOAIPEHIAEPACEDACAAA.vberdin@eazix.com>
Message-ID: <200403301324.21387.Antony@Soft-Solutions.co.uk>

On Tuesday 30 March 2004 1:09 pm, Vic Berdin wrote:

> Hi,
>
> This maybe the wrong list to post this but since you guys are into
> the field of creating your own BIOSware, I would like to ask if
> anyone knows of a device or equipment (connected via stadard PC port)
> that may be used in order to write data into a BIOS chip?

BIOS chips are standard flash parts - a commercial flash programmer will do 
the job (but don't expect such a machine to be cheap).

Failing that, you could try using the DOS-based flash programming utility 
provided by the vendor of your motherboard?   That can write new BIOS images 
into the chip (in-place on the motherboard) - it's worth seeing if it'll 
write an arbitrary binary file for you.

Also, the MTD utilities may be able to help you out.

Regards,

Antony.

-- 
"Reports that say that something hasn't happened are always interesting to me, 
because as we know, there are known knowns; there are things we know we know. 
We also know there are known unknowns; that is to say we know there are some 
things we do not know. But there are also unknown unknowns - the ones we 
don't know we don't know."

 - Donald Rumsfeld, US Secretary of Defence

                                                     Please reply to the list;
                                                           please don't CC me.



From ian at abelon.com  Tue Mar 30 07:18:01 2004
From: ian at abelon.com (Ian Smith)
Date: Tue Mar 30 07:18:01 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <200403301324.21387.Antony@Soft-Solutions.co.uk>
References: <DDEILMFEIOAIPEHIAEPACEDACAAA.vberdin@eazix.com>
 <200403301324.21387.Antony@Soft-Solutions.co.uk>
Message-ID: <6.0.3.0.2.20040330133831.02d87178@mail.abelon.com>

At 13:25 30/03/2004, Antony Stone wrote:
>On Tuesday 30 March 2004 1:09 pm, Vic Berdin wrote:
>
> > Hi,
> >
> > This maybe the wrong list to post this but since you guys are into
> > the field of creating your own BIOSware, I would like to ask if
> > anyone knows of a device or equipment (connected via stadard PC port)
> > that may be used in order to write data into a BIOS chip?
>
>BIOS chips are standard flash parts - a commercial flash programmer will do
>the job (but don't expect such a machine to be cheap).

We use a Batronix USB programmer:

 >http://progshop.com/shop/programmer/usb-chip-programmer/index.shtml

List price is 289 USD (plus you'll need a PLCC adapter) which is quite a 
bit cheaper than a lot of the others on the market, and it will program a 
huge variety of different chips. It's pretty fast too (much faster than any 
serial/parallel port programmer)

Cheers

Ian 



From rminnich at lanl.gov  Tue Mar 30 09:06:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar 30 09:06:01 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <DDEILMFEIOAIPEHIAEPACEDACAAA.vberdin@eazix.com>
Message-ID: <Pine.LNX.4.44.0403300731280.31457-100000@maxroach.lanl.gov>

flash_rom should work fine, depending on chipset etc.

ron



From rsmith at bitworks.com  Tue Mar 30 11:16:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Mar 30 11:16:01 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <6.0.3.0.2.20040330133831.02d87178@mail.abelon.com>
References: <DDEILMFEIOAIPEHIAEPACEDACAAA.vberdin@eazix.com> <200403301324.21387.Antony@Soft-Solutions.co.uk> <6.0.3.0.2.20040330133831.02d87178@mail.abelon.com>
Message-ID: <4069A2FE.5020109@bitworks.com>

Ian Smith wrote:

> At 13:25 30/03/2004, Antony Stone wrote:
> 
>> the job (but don't expect such a machine to be cheap).
> 
> We use a Batronix USB programmer:
> 
>  >http://progshop.com/shop/programmer/usb-chip-programmer/index.shtml
> 
> List price is 289 USD (plus you'll need a PLCC adapter) which is quite a 
> bit cheaper than a lot of the others on the market, and it will program 
> a huge variety of different chips. It's pretty fast too (much faster 
> than any serial/parallel port programmer)

Wow. our experience with this device has been totally opposite. In my 
opinion it has about the worst programmer user interface I've ever used. 
  It won't install and run on 2 of our machines (an XP box and a win 98 
box) It dosen't do offsets.  Many of the dialog boxes pop up in German. 
  It does a bad job of figuring out when it can skip 0xff's in blank 
areas.  It wants to always read a part first before programming it.  And 
our Advin Pilot U40 which is a parallel port programmer is faster.

I could go on but I'll stop before I get worked up.

The hardware itself seems sound but the software blows hard.  So hard 
that I've seriously considered snooping the data stream and writeing a 
short sweet python cli utility for it.




From ian at abelon.com  Tue Mar 30 11:47:00 2004
From: ian at abelon.com (Ian Smith)
Date: Tue Mar 30 11:47:00 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <4069A2FE.5020109@bitworks.com>
References: <DDEILMFEIOAIPEHIAEPACEDACAAA.vberdin@eazix.com>
 <200403301324.21387.Antony@Soft-Solutions.co.uk>
 <6.0.3.0.2.20040330133831.02d87178@mail.abelon.com>
 <4069A2FE.5020109@bitworks.com>
Message-ID: <6.0.3.0.2.20040330180620.02c70710@mail.abelon.com>

At 17:40 30/03/2004, Richard Smith wrote:
>Ian Smith wrote:
>
>>At 13:25 30/03/2004, Antony Stone wrote:
>>
>>>the job (but don't expect such a machine to be cheap).
>>We use a Batronix USB programmer:
>>  >http://progshop.com/shop/programmer/usb-chip-programmer/index.shtml
>>List price is 289 USD (plus you'll need a PLCC adapter) which is quite a 
>>bit cheaper than a lot of the others on the market, and it will program a 
>>huge variety of different chips. It's pretty fast too (much faster than 
>>any serial/parallel port programmer)
>
>Wow. our experience with this device has been totally opposite. In my 
>opinion it has about the worst programmer user interface I've ever 
>used.  It won't install and run on 2 of our machines (an XP box and a win 
>98 box) It dosen't do offsets.  Many of the dialog boxes pop up in 
>German.  It does a bad job of figuring out when it can skip 0xff's in 
>blank areas.  It wants to always read a part first before programming 
>it.  And our Advin Pilot U40 which is a parallel port programmer is faster.
>
>I could go on but I'll stop before I get worked up.
>
>The hardware itself seems sound but the software blows hard.  So hard that 
>I've seriously considered snooping the data stream and writeing a short 
>sweet python cli utility for it.

Interesting!

Maybe we've just been lucky as I've only installed it on a Win2K box, and 
have only really used it for blowing BIOS proms. I've not seen the German 
dialog boxes either.

As for performance, it's well ahead of the Stag & Data IO programmers I've 
used in the past, but granted that isn't saying much.

Cheers

Ian 



From steve at nexpath.com  Tue Mar 30 12:16:01 2004
From: steve at nexpath.com (Steve Gehlbach)
Date: Tue Mar 30 12:16:01 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <6.0.3.0.2.20040330180620.02c70710@mail.abelon.com>
References: <DDEILMFEIOAIPEHIAEPACEDACAAA.vberdin@eazix.com> <200403301324.21387.Antony@Soft-Solutions.co.uk> <6.0.3.0.2.20040330133831.02d87178@mail.abelon.com> <4069A2FE.5020109@bitworks.com> <6.0.3.0.2.20040330180620.02c70710@mail.abelon.com>
Message-ID: <4069B3C5.9000008@nexpath.com>

Ian Smith wrote:

>>> We use a Batronix USB programmer:

The one I see mentioned the most, and the one I have, is from Needhams 
(www.needhams.com).  More money that what you are talking about, but I 
have never had a problem.  I heaved the DataIO into the dumpster, 
manuals, modules, everything.  The Needhams was less than a software 
upgrade on the DataIO.


From YhLu at tyan.com  Tue Mar 30 14:19:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Mar 30 14:19:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogtPC4tDogQ2FjaGUgT24gYW5kIEVDQyBjbGVh?=
	=?GB2312?B?cg==?=
Message-ID: <3174569B9743D511922F00A0C94314230466DAFB@TYANWEB>

Eric,

After change the FALLBACK_SIZE from 96k to 128k. it works. And 64k as
XIP_ROM_SIZE it works.

Regards

YH



-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?3?29? 22:50
???: YhLu
??: ron minnich; Li-Ta Lo; LinuxBIOS
??: Re: ??: ??: Cache On and ECC clear

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> It seems it's all right in mtrr setting. Except 0x201 and 0x203 setting in
> earlymtrr.inc should set 0xff for msr.hi intead of 0xf
> 
> Before mtrr processing for clearing

Hmm.  Assuming 0000 == 0x200, 0001 == 0x201 etc.  So
you have to base and mask pairs.
 
> Normal mode
> 0000=0x0000000000000006
> 0001=0x000000fffff00800
> 0002=0x00000000fffe8006
  This is a base address 4GB - 96K
> 0003=0x000000fffffe8800 
  This is a size and it tries to be 96K.
  It is actually something like 32K.
 
> Fallback mode
> 0000=0x0000000000000006
> 0001=0x000000fffff00800
> 0002=0x00000000fffd0006 
  This is a base address 4GB - 160K
> 0003=0x000000fffffe8800 
  This is a size aand it tries to be 96K.
  It is actually something like 32K.

So somehow you got at non power of 2 size into XIP_ROM_SIZE.  So much less
of your code is cached than you would expect.  So instruction fetches take
a very long time.  And loops are slow.

The comments from my HDAMA Config.lb 
## XIP_ROM_SIZE must be a power of 2.
## XIP_ROM_BASE must be a multiple of XIP_ROM_SIZE

It looks like these needs to be enforced, somehow so build time mistakes
don't happen. Perhaps:
#if ((XIP_ROM_BASE % XIP_ROM_SIZE) != 0) || ((XIP_ROM_SIZE & (XIP_ROM_SIZE -
1)) != 0)
#error XIP_ROM_SIZE must be a power of 2 and XIP_ROM_BASE must be a multiple
of it
#endif


Eric


From dwh at lanl.gov  Tue Mar 30 15:44:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Tue Mar 30 15:44:01 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <DDEILMFEIOAIPEHIAEPACEDACAAA.vberdin@eazix.com>
Message-ID: <Pine.LNX.4.44.0403301355310.15591-100000@ccs-mail.lanl.gov>

The 49LF008A was added to flash_rom just recently. You should be able to 
use any mainboard with the appropriate socket and one of these 
southbridges: SiS630, SiS5595, Intel E7500, VIA VT8231, VIA VT8235, AMD 
SC1100, AMD CS5530, AMD 8111.

The AMDSC1100 was the southbridge on some GX1 based boards we used here 
at the Lab a while back. I'm uncertain whether flash_rom will work with 
whatever is on your GX2 based board, but it might be worth a try. If it 
doesn't work, you can probably grab a cheap mainboard off pricewatch.com 
and use flash_rom anyway. Beats paying hundreds for specialized hardware 
plus some rediculous amount for an MS Windows license :)

On Tue, 30 Mar 2004, Vic Berdin wrote:

> Hi,
> 
> This maybe the wrong list to post this but since you guys are into
> the field of creating your own BIOSware, I would like to ask if 
> anyone knows of a device or equipment (connected via stadard PC port) 
> that may be used in order to write data into a BIOS chip?
> 
> I am currently scouring the net for any material (software/hardware)
> that can aid me in safely replacing the BIOSware on an SST49LF008A
> FWH that socketted on an AMD GX2-based target board.
> The said board and SST chip is not (yet) supported (or listed) by 
> this project.
> 
> However, our goal is to replace the existing BIOSware with Linux.
> 
> 
> TIA - Vic
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From hansolofalcon at worldnet.att.net  Tue Mar 30 19:04:00 2004
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Tue Mar 30 19:04:00 2004
Subject: CVS Management tools
Message-ID: <001201c416b7$5e387100$6401a8c0@who5>

Hello from Gregg C Levine
Is anyone using this one, from the KDE environment, CERVISIA?
Supposedly it will allow the user to do everything he normally does
with CVS, by hand. I discovered, that the Source Forge CVS does not
really appreciate the tool, despite the fact that the commands used,
are the same as those on other CVS storage sites that I've visited.
For example I was able to retrieve the ECOS sources from its CVS
storage, without much of a hassle, and that's the other one that I've
visited on a fairly regular basis.
Any suggestions would be greatly appreciated.
-------------------
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 vberdin at eazix.com  Tue Mar 30 20:20:01 2004
From: vberdin at eazix.com (Vic Berdin)
Date: Tue Mar 30 20:20:01 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <Pine.LNX.4.44.0403301355310.15591-100000@ccs-mail.lanl.gov>
Message-ID: <DDEILMFEIOAIPEHIAEPAMEDBCAAA.vberdin@eazix.com>

Hi,

> -----Original Message-----
> From: Hendricks David W. [mailto:dwh at lanl.gov]
> Sent: Wednesday, March 31, 2004 5:09 AM
> To: Vic Berdin
> Cc: Linuxbios at Clustermatic.Org
> Subject: Re: A bit OT: external equipment for writing...


> The 49LF008A was added to flash_rom just recently. You should be able to 
> use any mainboard with the appropriate socket and one of these 
> southbridges: SiS630, SiS5595, Intel E7500, VIA VT8231, VIA VT8235, AMD 
> SC1100, AMD CS5530, AMD 8111.

This is good news! My companion southbridge chip however is an AMDCS5535. 
Will this bring about problems? Anyways, I'll checkout the recent updates
from CVS and try to give this a shot. Any other info are very much welcome.

> The AMDSC1100 was the southbridge on some GX1 based boards we used here 
> at the Lab a while back. I'm uncertain whether flash_rom will work with 
> whatever is on your GX2 based board, but it might be worth a try. If it 
> doesn't work, you can probably grab a cheap mainboard off pricewatch.com 
> and use flash_rom anyway. Beats paying hundreds for specialized hardware 
> plus some rediculous amount for an MS Windows license :)

Best regards,
Vic



From rminnich at lanl.gov  Tue Mar 30 21:51:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Mar 30 21:51:00 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <DDEILMFEIOAIPEHIAEPAMEDBCAAA.vberdin@eazix.com>
Message-ID: <Pine.LNX.4.44.0403302016080.4450-100000@maxroach.lanl.gov>

On Wed, 31 Mar 2004, Vic Berdin wrote:

> This is good news! My companion southbridge chip however is an AMDCS5535. 

try it, I think it will also work.

ron



From vberdin at eazix.com  Tue Mar 30 22:50:00 2004
From: vberdin at eazix.com (Vic Berdin)
Date: Tue Mar 30 22:50:00 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <Pine.LNX.4.44.0403302016080.4450-100000@maxroach.lanl.gov>
Message-ID: <DDEILMFEIOAIPEHIAEPAMEDCCAAA.vberdin@eazix.com>

Hi Ron, everyone,

> -----Original Message-----
> From: ron minnich [mailto:rminnich at lanl.gov]
> Sent: Wednesday, March 31, 2004 11:16 AM
> To: Vic Berdin
> Cc: Hendricks David W.; Linuxbios at Clustermatic.Org
> Subject: RE: A bit OT: external equipment for writing...

> On Wed, 31 Mar 2004, Vic Berdin wrote:

>> This is good news! My companion southbridge chip however is an AMDCS5535.

> try it, I think it will also work.

I've also been going through the Sis630 online doc in order to
have an idea as to what I should do. Unfortunately, step 6
(replacing BIOS chip with a DOC), cannot be applied on my case.
My target board has no DOC support. Either (1) burn the kernel
image directly to the SST49LF008A chip that is socketted (not
soldered) on the target board, or (2) get an external device that
can write into an SST49LF008A.
In an attempt to do option (1), I downloaded driver codes for
49LF008 from SST:
http://www.sst.com/downloads/software_driver/SST49LF008A.txt,
and tried to make use of the "int Check_SST_49LF008A()" function.
Unfortunately, all I'm getting is a segfault. It seems that the
code is referring to an invalid address that should be specific
to my target SBC.
Anyways, if I may ask the list, has anyone tried the approach
to write directly into a BIOS chip using C when replacing the
BIOSware? If so, any hints/source codes/etc?

> ron

TIA - Vic



From svante.signell at telia.com  Wed Mar 31 02:40:00 2004
From: svante.signell at telia.com (Svante Signell)
Date: Wed Mar 31 02:40:00 2004
Subject: Can I execute a linuxbios image from linux?
Message-ID: <1080720298.18828.654.camel@em2.my.own.domain>

Hello,

I'm trying to upgrade the CPU on a 440BX dual board MSI-6210 from dual
Celerons (Mendocino) to a single Celeron2 (Tualatin) using a socket 370
to slot 1 adapter, SLOT-T from Upgradeware. On other 440BX based
motherboards, this works perfectly. Two computers I have upgraded are a
QDI BrillianX 1 based box and the Compaq 5670. The lates BIOS for the
6120 does not support Coppermine or Tualatin processors.

With the 6120, I get a successful boot too, but the effective speed is 7
MHz as compared to expected 1.3GHz (measured with lmbench). I have made
a small kernel module testing the level 2 cache activation code, without
any improvements. Also mtrr seems to be set up correctly. Now I would
like to execute a full linuxbios image after boot to linux, in order to
avoid the problem of re-flashing the BIOS. Is this possible?

The Upgradeware support pages mentions that the IO chips have to be of
correct type for a similar single CPU board, the MSI-6119 to uork with
the SLOT-T adapter. What function does the IO chip have, and how can in
be tested? 

Thanks,
Svante


From vberdin at eazix.com  Wed Mar 31 04:48:00 2004
From: vberdin at eazix.com (Vic Berdin)
Date: Wed Mar 31 04:48:00 2004
Subject: More n00by questions...
In-Reply-To: <20040330170001.9612.82293.Mailman@nwn.definitive.org>
Message-ID: <DDEILMFEIOAIPEHIAEPAOEDDCAAA.vberdin@eazix.com>

Hi everyone,

Which kernel patch should I apply having this hardware?

Processor & southbridge: AMDGX2 + CS5535
BIOS chip: SST49LF008A FWH
`lspci -n`:
	00:01.0 Class 0600: 100b:0028 (rev 21)
	00:01.1 Class 0300: 100b:0030
	00:0e.0 Class 0200: 10ec:8139 (rev 10)
	00:0f.0 Class 0601: 100b:002b (rev 13)
	00:0f.2 Class 0101: 100b:002d
	00:0f.3 Class 0401: 100b:002e
	00:0f.4 Class 0c03: 100b:002f (rev 06)
	00:0f.5 Class 0c03: 100b:002f (rev 06)

TIA - Vic



From rminnich at lanl.gov  Wed Mar 31 09:08:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 31 09:08:01 2004
Subject: A bit OT: external equipment for writing...
In-Reply-To: <DDEILMFEIOAIPEHIAEPAMEDCCAAA.vberdin@eazix.com>
Message-ID: <Pine.LNX.4.44.0403310732370.9002-100000@maxroach.lanl.gov>

On Wed, 31 Mar 2004, Vic Berdin wrote:

> In an attempt to do option (1), I downloaded driver codes for
> 49LF008 from SST:
> http://www.sst.com/downloads/software_driver/SST49LF008A.txt,
> and tried to make use of the "int Check_SST_49LF008A()" function.
> Unfortunately, all I'm getting is a segfault. It seems that the
> code is referring to an invalid address that should be specific
> to my target SBC.

I would guess that will never work, as the stuff usually is designed to 
run under DOS with no protections. 

> Anyways, if I may ask the list, has anyone tried the approach
> to write directly into a BIOS chip using C when replacing the
> BIOSware? If so, any hints/source codes/etc?

flash_rom

ron



From rminnich at lanl.gov  Wed Mar 31 09:14:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 31 09:14:01 2004
Subject: Can I execute a linuxbios image from linux?
In-Reply-To: <1080720298.18828.654.camel@em2.my.own.domain>
Message-ID: <Pine.LNX.4.44.0403310739070.9002-100000@maxroach.lanl.gov>

I'm not sure you're going to get much help here, as your question is kind 
of off topic for this list, but we'll see.

ron



From rminnich at lanl.gov  Wed Mar 31 09:15:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 31 09:15:00 2004
Subject: More n00by questions...
In-Reply-To: <DDEILMFEIOAIPEHIAEPAOEDDCAAA.vberdin@eazix.com>
Message-ID: <Pine.LNX.4.44.0403310739500.9002-100000@maxroach.lanl.gov>

On Wed, 31 Mar 2004, Vic Berdin wrote:

> Which kernel patch should I apply having this hardware?

none at all, to start. Did you actually get linuxbios to work on this?

ron



From gnandi at angstrom.com  Wed Mar 31 13:26:01 2004
From: gnandi at angstrom.com (gnandi at angstrom.com)
Date: Wed Mar 31 13:26:01 2004
Subject: trying to etherboot via linuxbios a tyan S2885 motherboard
Message-ID: <1080759032.406b12f8bad88@rand.angstrom.com>

 
Hi  
 
I am trying to boot linux using etherboot/linuxbios and  
get the following error (last few lines of the console dump): (see below) 
 
Any idea what could be going wrong ? The etherboot+linux image boots fine 
on a arima/hdama mother board. 
 
I am using one of the latest linuxbios source snapshots 
 
Regards, 
Gautam 
 
LinuxBIOS-1.1.62.0_Fallback Wed Mar 31 11:40:34 EST 2004 starting... 
setting up resource map....done. 
  
bla , bla ... 
 
Welcome to elfboot, the open sourced starter. 
January 2002, Eric Biederman. 
Version 1.3 
 
 
    23:stream_init() - rom_stream: 0xfffe0000 - 0xfffeffff 
Found ELF candiate at offset 0 
Loading Etherboot version: 5.2.4 
Dropping non PT_LOAD segment 
New segment addr 0x20000 size 0x37058 offset 0xb0 filesize 0x68a3 
(cleaned up) New segment addr 0x20000 size 0x37058 offset 0xb0 filesize 0x68a3 
Loading Segment: addr: 0x000000001ffb1f38 memsz: 0x0000000000019064 filesz: 
0x00 
000000000068a3 
Clearing Segment: addr: 0x000000001ffb87db memsz: 0x00000000000127c1 
Loading Segment: addr: 0x0000000000039064 memsz: 0x000000000001dff4 filesz: 
0x00 
00000000000000 
    39:stream_skip() - overflowed source buffer 
ERROR: Skip of 75713 bytes skiped 38573 bytes 
 


From svante.signell at telia.com  Wed Mar 31 14:05:00 2004
From: svante.signell at telia.com (Svante Signell)
Date: Wed Mar 31 14:05:00 2004
Subject: Can I execute a linuxbios image from linux?
In-Reply-To: <Pine.LNX.4.44.0403310739070.9002-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0403310739070.9002-100000@maxroach.lanl.gov>
Message-ID: <1080761416.18828.668.camel@em2.my.own.domain>

OK, maybe my question is OT, but not completely OT. Maybe I can try to
move the L440BX stuff from V1 to V2, and when it compiles get help from
the list after that?

Is there a way to try out a new BIOS without risking to end up with an
unbootable main-board, ethernet, serial port, some special card
connected to the south-bridge (PIIX4) e.g. a special PCI/ISA card, etc?
Other solutions including soldering, EEPROM programming devices, etc?

What is the function of th IO chip?
Thanks,
Svante

On Wed, 2004-03-31 at 16:39, ron minnich wrote:
> I'm not sure you're going to get much help here, as your question is kind 
> of off topic for this list, but we'll see.
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios


From ollie at lanl.gov  Wed Mar 31 17:12:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Mar 31 17:12:01 2004
Subject: S2885 ht reset multi chain.
In-Reply-To: <3174569B9743D511922F00A0C94314230466D928@TYANWEB>
References: <3174569B9743D511922F00A0C94314230466D928@TYANWEB>
Message-ID: <1080772623.2853.3.camel@exponential.lanl.gov>

On Thu, 2004-03-25 at 21:42, YhLu wrote:
> Stefan,
> 
> Please try this one. Remove the mindev in struct. And use next_unitid to
> calculate the dev min and max.
> 
> Can you try that in AMD quartet to see if ht reset works.
> 
> You may need to add several lines in auto.c
> 
> 
>         static const struct ht_chain ht_c[] = {
>                 {
>                         .udev = PCI_DEV(0, 0x18, 0),
>                         .upos = 0xc0,
>                         .devreg = 0xe0,
>                 },
>                 {
>                         .udev = PCI_DEV(0, 0x19, 0),
>                         .upos = 0xa0,
>                         .devreg = 0xe4,
>                 },
>         };
> 

Why don't you use LDT[-02] instead of register address like .upos ? It
is much easier to understand.

Ollie




From YhLu at tyan.com  Wed Mar 31 17:39:00 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Mar 31 17:39:00 2004
Subject: =?GB2312?B?tPC4tDogUzI4ODUgaHQgcmVzZXQgbXVsdGkgY2hhaW4u?=
Message-ID: <3174569B9743D511922F00A0C94314230466DBF4@TYANWEB>

You should ask Eric, because I just wrap the code to call scan_ht_chain
several times.

All the info should be removed and do it dynamically, but the problem the
code is in auto.c, and romcc would produce large code. Unless romcc can
produce the small code, I think we can let everything to be done
dynamically.

YH

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?3?31? 14:37
???: YhLu
??: 'ron minnich'; 'linuxbios at clustermatic.org'
??: Re: S2885 ht reset multi chain.

On Thu, 2004-03-25 at 21:42, YhLu wrote:
> Stefan,
> 
> Please try this one. Remove the mindev in struct. And use next_unitid to
> calculate the dev min and max.
> 
> Can you try that in AMD quartet to see if ht reset works.
> 
> You may need to add several lines in auto.c
> 
> 
>         static const struct ht_chain ht_c[] = {
>                 {
>                         .udev = PCI_DEV(0, 0x18, 0),
>                         .upos = 0xc0,
>                         .devreg = 0xe0,
>                 },
>                 {
>                         .udev = PCI_DEV(0, 0x19, 0),
>                         .upos = 0xa0,
>                         .devreg = 0xe4,
>                 },
>         };
> 

Why don't you use LDT[-02] instead of register address like .upos ? It
is much easier to understand.

Ollie



From aod at ponto-i.net  Wed Mar 31 18:38:01 2004
From: aod at ponto-i.net (Andre Dias)
Date: Wed Mar 31 18:38:01 2004
Subject: product using linuxbios
Message-ID: <1080777800.3108.12.camel@laptop>

We have launched a product using linuxbios here in Brasil, its a jukebox
for pubs, but we use ogg vorbis and we have developed the entire system
(including a hard disk distribution based in debian and one for the bios
based in busybox). I have been using sis730 motherboards, but they are
pretty scarce in the market right now. We use linuxbios for a faster
boot, for maintenance, in case there is a HD problem, to avoid CMOS
reset problems and because its cool ;)

Have a look at the machine:

http://www.digipop.com.br/produtos.htm

(website in portuguese).





From vberdin at eazix.com  Wed Mar 31 19:08:00 2004
From: vberdin at eazix.com (Vic Berdin)
Date: Wed Mar 31 19:08:00 2004
Subject: More n00by questions...
In-Reply-To: <Pine.LNX.4.44.0403310739500.9002-100000@maxroach.lanl.gov>
Message-ID: <DDEILMFEIOAIPEHIAEPACEDGCAAA.vberdin@eazix.com>

Hi Ron,

> -----Original Message-----
> From: ron minnich [mailto:rminnich at lanl.gov]
> Sent: Wednesday, March 31, 2004 10:40 PM
> To: Vic Berdin
> Cc: linuxbios at clustermatic.org
> Subject: Re: More n00by questions...
> 
> On Wed, 31 Mar 2004, Vic Berdin wrote:
> 
>> Which kernel patch should I apply having this hardware?
> 
> none at all, to start. 

strange, being guided by the Sis630 steps (step 2), the
doc mentions that one should patch the kernel tree (??).

> Did you actually get linuxbios to work on this?
> 

I haven't gotten anything working yet. I'm just refering
to the steps mentioned in Sis630 online doc. I'm also
integrating portions of info I get from "configmanual.ps"
To my understanding, I should patch the standard Kernel 
source tree first before I get to configure/build stuff 
mentioned on configmanual.ps file. Please point me to 
some other reference if I'm doing/understanding this
entirely wrong.

> ron

Thanks and best regards,

Vic



From kevin at koconnor.net  Wed Mar 31 19:21:01 2004
From: kevin at koconnor.net (Kevin O'Connor)
Date: Wed Mar 31 19:21:01 2004
Subject: Can I execute a linuxbios image from linux?
In-Reply-To: <1080761416.18828.668.camel@em2.my.own.domain>
References: <Pine.LNX.4.44.0403310739070.9002-100000@maxroach.lanl.gov> <1080761416.18828.668.camel@em2.my.own.domain>
Message-ID: <20040401004640.GA1768@ohio.localdomain>

On Wed, Mar 31, 2004 at 09:30:16PM +0200, Svante Signell wrote:
> Is there a way to try out a new BIOS without risking to end up with an
> unbootable main-board, ethernet, serial port, some special card
> connected to the south-bridge (PIIX4) e.g. a special PCI/ISA card, etc?
> Other solutions including soldering, EEPROM programming devices, etc?

A number of people are using the "BIOS Savior" product with success.  See:
http://www.ioss.com.tw/eg/rd1/index.html

Depending on which part you need, you can mail order it from mwave.com,
pcmods.com, or probably a bunch of other places.

-Kevin

-- 
 ---------------------------------------------------------------------
 | Kevin O'Connor                  "BTW, IMHO we need a FAQ for      |
 | kevin at koconnor.net               'IMHO', 'FAQ', 'BTW', etc. !"    |
 ---------------------------------------------------------------------


From rminnich at lanl.gov  Wed Mar 31 22:33:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Mar 31 22:33:00 2004
Subject: More n00by questions...
In-Reply-To: <DDEILMFEIOAIPEHIAEPACEDGCAAA.vberdin@eazix.com>
Message-ID: <Pine.LNX.4.44.0403312058050.14028-100000@maxroach.lanl.gov>

On Thu, 1 Apr 2004, Vic Berdin wrote:

> strange, being guided by the Sis630 steps (step 2), the
> doc mentions that one should patch the kernel tree (??).

I need to mark those files OBSOLETE


you're fine. Our docs really suck. I'm sorry.

ron



From vberdin at eazix.com  Wed Mar 31 23:25:01 2004
From: vberdin at eazix.com (Vic Berdin)
Date: Wed Mar 31 23:25:01 2004
Subject: More n00by questions...
In-Reply-To: <Pine.LNX.4.44.0403312058050.14028-100000@maxroach.lanl.gov>
Message-ID: <DDEILMFEIOAIPEHIAEPAEEDKCAAA.vberdin@eazix.com>

Hi Ron, everyone,

> -----Original Message-----
> From: ron minnich [mailto:rminnich at lanl.gov]
> Sent: Thursday, April 01, 2004 11:59 AM
> To: Vic Berdin
> Cc: linuxbios at clustermatic.org
> Subject: RE: More n00by questions...
> 
> On Thu, 1 Apr 2004, Vic Berdin wrote:
> 
>> strange, being guided by the Sis630 steps (step 2), the
>> doc mentions that one should patch the kernel tree (??).
> 
> I need to mark those files OBSOLETE
> 
> you're fine. Our docs really suck. I'm sorry.

Ok Ron, it's nice to know that I can still read :o). 
However, this doesn't answer as to where do I really 
go/start in using/implementing LinuxBIOS. I'm still trying
to read between the lines of whatever doc is available.
To everybody, please don't hesitate to e-mail n00bys like 
me for genric steps that I should follow in order to try out
this project.


Best regards,

Vic