From adam at megacz.com  Fri Jan  2 06:08:01 2004
From: adam at megacz.com (Adam Megacz)
Date: Fri Jan  2 06:08:01 2004
Subject: ide emulation based on network block device for arbitrary OSes?
In-Reply-To: ron minnich's message of "Wed, 31 Dec 2003 10:21:02 -0700 (MST)"
References: <Pine.LNX.4.44.0312311020490.26852-100000@maxroach.lanl.gov>
Message-ID: <E1AcNIb-0007Ny-00@megacz.com>

I'd like to run Win2k server on a diskless box.  I (unfortunately)
need to have a Win2k server box around for testing an app that we
develop on Linux but need to (occasionally) deploy on Windows.  It's
headless, so I just RDP in when I need to test stuff out.

I guess I'm interested in the diskless aspect not to save the cost of
a hard drive, but just because I like having all my hard disks in one
machine.  All my linux boxen boot off the network and mount their root
partition off of a (very, very fast) RAID-5 array.  So they all get
four-spindle speed instead of single-spindle speed.

  - a


ron minnich <rminnich at lanl.gov> writes:
> On Mon, 29 Dec 2003, Adam Megacz wrote:
> 
> > 
> > I've heard that you can use LinuxBIOS to bootload other operating
> > systems (like Windows, etc).  Is it possible for LinuxBIOS to boot the
> > device and install a block of code in memory that handles BIOS disk
> > requests using some sort of network block device protocol?
> 
> ouch. What is the motivation?
> 
> thanks
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
"If Darl McBride [the CEO of SCO, who claims the GPL 'destroys
 intellectual property'] was in charge, he'd probably make marriage
 unconstitutional too, since clearly it de-emphasizes the commercial
 nature of normal human interaction, and probably is a major
 impediment to the commercial growth of prostitution"

                                             -- Linus Torvalds


From justin at street-vision.com  Fri Jan  2 08:14:00 2004
From: justin at street-vision.com (Justin Cormack)
Date: Fri Jan  2 08:14:00 2004
Subject: ide emulation based on network block device for arbitrary OSes?
In-Reply-To: <E1AcNIb-0007Ny-00@megacz.com>
References: <Pine.LNX.4.44.0312311020490.26852-100000@maxroach.lanl.gov> 
	<E1AcNIb-0007Ny-00@megacz.com>
Message-ID: <1073049615.1350.16.camel@lotte.street-vision.com>

I think you will find that Win2k server doesnt use BIOS disk requests,
accesses the hardware directly. Why not run it on VMware on a diskless
Linux box?

Justin



On Fri, 2004-01-02 at 11:17, Adam Megacz wrote:
> 
> I'd like to run Win2k server on a diskless box.  I (unfortunately)
> need to have a Win2k server box around for testing an app that we
> develop on Linux but need to (occasionally) deploy on Windows.  It's
> headless, so I just RDP in when I need to test stuff out.
> 
> I guess I'm interested in the diskless aspect not to save the cost of
> a hard drive, but just because I like having all my hard disks in one
> machine.  All my linux boxen boot off the network and mount their root
> partition off of a (very, very fast) RAID-5 array.  So they all get
> four-spindle speed instead of single-spindle speed.
> 
>   - a
> 
> 
> ron minnich <rminnich at lanl.gov> writes:
> > On Mon, 29 Dec 2003, Adam Megacz wrote:
> > 
> > > 
> > > I've heard that you can use LinuxBIOS to bootload other operating
> > > systems (like Windows, etc).  Is it possible for LinuxBIOS to boot the
> > > device and install a block of code in memory that handles BIOS disk
> > > requests using some sort of network block device protocol?
> > 
> > ouch. What is the motivation?
> > 
> > thanks
> > 
> > ron
> > 
> > _______________________________________________
> > Linuxbios mailing list
> > Linuxbios at clustermatic.org
> > http://www.clustermatic.org/mailman/listinfo/linuxbios
> > 
> 
> -- 
> "If Darl McBride [the CEO of SCO, who claims the GPL 'destroys
>  intellectual property'] was in charge, he'd probably make marriage
>  unconstitutional too, since clearly it de-emphasizes the commercial
>  nature of normal human interaction, and probably is a major
>  impediment to the commercial growth of prostitution"
> 
>                                              -- Linus Torvalds
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios




From adam at megacz.com  Fri Jan  2 15:03:00 2004
From: adam at megacz.com (Adam Megacz)
Date: Fri Jan  2 15:03:00 2004
Subject: ide emulation based on network block device for arbitrary OSes?
In-Reply-To: Justin Cormack's message of "02 Jan 2004 13:20:14 +0000"
References: <Pine.LNX.4.44.0312311020490.26852-100000@maxroach.lanl.gov> <E1AcNIb-0007Ny-00@megacz.com> <1073049615.1350.16.camel@lotte.street-vision.com>
Message-ID: <E1AcVe5-0008CS-00@megacz.com>

Justin Cormack <justin at street-vision.com> writes:
> I think you will find that Win2k server doesnt use BIOS disk requests,
> accesses the hardware directly.

Bleh.

> Why not run it on VMware on a diskless Linux box?

Their kernel modules have caused me no end of pain... main gripes being:

  a) System instability resulting from said modules.

  b) Their sinister "you must pay us more money every time Linus
     releases a new kernel" policy (when a new kernel comes out they
     only update the kernel modules for the newest vmware).  I don't
     object to buying a new vmware when I want to run a new *guest*
     OS, but I figure that if I've paid them for the software, I
     should be able to continue using it for the same task forever
     even when I upgrade my host OS.

If they ever release a version that doesn't require kernel modules,
I'll be the first in line with a fistfull of cash... their product is
otherwise fantastic.

  - a


From ebiederman at lnxi.com  Sun Jan  4 02:44:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Jan  4 02:44:01 2004
Subject: Tiny linux
In-Reply-To: <3FE72505.1090804@bitworks.com>
References: <Pine.LNX.4.44.0312182236530.15968-100000@maxroach.lanl.gov>
	<m3k74tuz8m.fsf@maxwell.lnxi.com> <1072049521.4876.63.camel@eddie>
	<3FE72505.1090804@bitworks.com>
Message-ID: <m34qvcqh5e.fsf@maxwell.lnxi.com>

Richard Smith <rsmith at bitworks.com> writes:

> Has anyone tried this to see how small it compiles down to? 

I just looked.  With everything turned off I have built a
220K kernel. 371K uncompressed but that doesn't count.

It looks like there is light at the end of the tunnel.

Eric


From pmacv at telefonica.net  Sun Jan  4 03:02:00 2004
From: pmacv at telefonica.net (Pedro M.)
Date: Sun Jan  4 03:02:00 2004
Subject: Booting USB keydrive from BIOS
Message-ID: <004401c3d29a$03230890$6369cb51@usuario>

 I tried to boot JetFlash ( http://www.transcendusa.com )  with Flonix ( http://www.wikipedia.org/wiki/flonix ), but something is wrong, because I only can boot it using a floppy. 

I  have USB boot support in the BIOS. 

What can I do to boot the keydrive (http://www.wikipedia.org/wiki/keydrive ) with Flonix ???? 

Thanks in advance. 

( I think sell bootable USB keydrives with Flonix pre-installed would be a great idea....). 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040104/87cc4d78/attachment.html>

From pmacv at telefonica.net  Sun Jan  4 03:53:01 2004
From: pmacv at telefonica.net (Pedro M.)
Date: Sun Jan  4 03:53:01 2004
Subject: Booting USB keydrive from BIOS
References: <200401040833.i048Xx532134@singularity.tronunltd.com>
Message-ID: <002001c3d2a1$2e72a9e0$6369cb51@usuario>

Yes, for sure, step by step.

Now I try to write
http://linuxdocs.tuxfamily.org/flonix/wakka.php?wiki=BootUtility and find
alternative solution...

Regards.
----- Original Message ----- 
From: "Ian Latter" <Ian.Latter at mq.edu.au>
To: "Pedro M." <pmacv at telefonica.net>
Cc: <linuxbios at clustermatic.org>
Sent: Sunday, January 04, 2004 9:33 AM
Subject: Re:Booting USB keydrive from BIOS


>
> Hello Pedro,
>
>   Have you followed their documentation?
>
http://linuxdocs.tuxfamily.org/flonix/doc/wakka.php?wiki=EnUsbEditionInstall
>
>   I've not seen Flonix before, but this looks pretty straight
> forward.  Actually, last week I finished making a USB bootable
> version of CHAOS for the wrist watch that they show in the
> devices section on that site.  I haven't tested it yet, but the
> procedure I ended up with was very similar to what they seem
> to have listed on that page.

> >  I tried to boot JetFlash ( http://www.transcendusa.com )  with
Flonix....



From pmacv at telefonica.net  Sun Jan  4 05:06:01 2004
From: pmacv at telefonica.net (Pedro M.)
Date: Sun Jan  4 05:06:01 2004
Subject: Booting USB keydrive from BIOS
References: <200401040904.i04942O32226@singularity.tronunltd.com>
Message-ID: <000c01c3d2ab$41324540$6369cb51@usuario>


----- Original Message ----- 
From: "Ian Latter" <Ian.Latter at mq.edu.au>
To: "Pedro M." <pmacv at telefonica.net>
Cc: <linuxbios at clustermatic.org>
Sent: Sunday, January 04, 2004 10:04 AM
Subject: Re: Re:Booting USB keydrive from BIOS


> Ok, then I guess maybe my question should be; You said your
> PC BIOS supported USB booting, but is your USB key able to
> be booted?
>
I am not sure about it... I bought this modell  (JetFlash usb 2.0 128 Mb--->
Part #: TS128MJF2L

) because I saw : Window, Machintosh, Linux; boot up function--- can make
JetFlash Bootable device

"JetFlash can also be setup to be used as MS-DOS Boot Disk with the software
included in the package"

"JetFlash boot function requires Windows operating system, software
installation and your motherboard need to support USB ZIP, USB-FDD or
USB-HDD (in Windows XP only USB ZIP). Refer to your motherboard manual. Boot
function only allow JetFlash to run MS-DOS programs, however, this does not
make JetFlash as Rescue Disk or put Windows Startup files into JetFlash"
http://www.transcendusa.com/FlashCard/docs/256MJF2L.pdf

http://www.transcendusa.com/FlashCard/docs/TS4GJF2C-EN.pdf


  Are
> you confident you have a bootable USB key?
>
> Further more, under the BIOS' I have access too with USB boot
> capability, they tend to have differing types - such as;
>
>   USB-FDD
>   USB-HDD
>   USB-ZIP
>
> I'm not sure if the syslinux version is going to be USB-FDD or
> USB-HDD

For Flonix is USB-FDD ( although sometimes , USB-HDD works, but not for me
using Windows XP to prepare the booting files in the keydrive).


Regards.

P.D. : Has anyone obtained a good booting using Flonix with a keydrive ??.
Can specify the trademark and modell of the keydrive ??.



From rminnich at lanl.gov  Sun Jan  4 10:37:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sun Jan  4 10:37:01 2004
Subject: Tiny linux
In-Reply-To: <m34qvcqh5e.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0401040843400.11163-100000@maxroach.lanl.gov>

On 4 Jan 2004, Eric W. Biederman wrote:

> I just looked.  With everything turned off I have built a
> 220K kernel. 371K uncompressed but that doesn't count.

this is 2.6 or ...

ron



From ebiederman at lnxi.com  Sun Jan  4 10:44:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Jan  4 10:44:00 2004
Subject: Tiny linux
In-Reply-To: <Pine.LNX.4.44.0401040843400.11163-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401040843400.11163-100000@maxroach.lanl.gov>
Message-ID: <m3k747n1s4.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 4 Jan 2004, Eric W. Biederman wrote:
> 
> > I just looked.  With everything turned off I have built a
> > 220K kernel. 371K uncompressed but that doesn't count.
> 
> this is 2.6 or ...

2.6.1-rc1-tiny1

Adding in 
- printk
- serial console support
- networking support ( Not IP networking)
- an eepro100 driver

takes it up to about 306K compressed.
With IPv4 support compiled it goes to about 396K compressed.

So the patches for 2.6 exist to make it usable.  And there
is still room for improvement.

Eric


From ebiederman at lnxi.com  Sun Jan  4 19:15:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Jan  4 19:15:01 2004
Subject: Tiny linux
In-Reply-To: <m3k747n1s4.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0401040843400.11163-100000@maxroach.lanl.gov>
	<m3k747n1s4.fsf@maxwell.lnxi.com>
Message-ID: <m3ekufjkzt.fsf@maxwell.lnxi.com>

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

> ron minnich <rminnich at lanl.gov> writes:
> 
> > On 4 Jan 2004, Eric W. Biederman wrote:
> > 
> > > I just looked.  With everything turned off I have built a
> > > 220K kernel. 371K uncompressed but that doesn't count.
> > 
> > this is 2.6 or ...
> 
> 2.6.1-rc1-tiny1
> 
> Adding in 
> - printk
> - serial console support
> - networking support ( Not IP networking)
> - an eepro100 driver
> 
> takes it up to about 306K compressed.
> With IPv4 support compiled it goes to about 396K compressed.
> 
> So the patches for 2.6 exist to make it usable.  And there
> is still room for improvement.

Playing a little more in the nothing selected case I get the kernel to
191K if I compile out support for block devices.  After writing
the patch that allows that.

Eric


From adam at megacz.com  Sun Jan  4 23:11:01 2004
From: adam at megacz.com (Adam Megacz)
Date: Sun Jan  4 23:11:01 2004
Subject: Tiny linux
In-Reply-To: ebiederman@lnxi.com's message of "04 Jan 2004 00:58:37 -0700"
References: <Pine.LNX.4.44.0312182236530.15968-100000@maxroach.lanl.gov> <m3k74tuz8m.fsf@maxwell.lnxi.com> <1072049521.4876.63.camel@eddie> <3FE72505.1090804@bitworks.com> <m34qvcqh5e.fsf@maxwell.lnxi.com>
Message-ID: <E1AdME9-0004E4-00@megacz.com>

BTW, if you want super tiny kernels, check out Microsoft's
(unpatented, surprisingly well documented) LZX compression format.
It's specifically designed to compress x86 machine code, so it beats
out all the general-purpose compression algorithms if the payload is a
binary.  I think libmspack has an LGPL'ed LZX compressor/decompressor.

  - a


ebiederman at lnxi.com (Eric W. Biederman) writes:
> Richard Smith <rsmith at bitworks.com> writes:
> 
> > Has anyone tried this to see how small it compiles down to? 
> 
> I just looked.  With everything turned off I have built a
> 220K kernel. 371K uncompressed but that doesn't count.
> 
> It looks like there is light at the end of the tunnel.
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
"If Darl McBride [the CEO of SCO, who claims the GPL 'destroys
 intellectual property'] was in charge, he'd probably make marriage
 unconstitutional too, since clearly it de-emphasizes the commercial
 nature of normal human interaction, and probably is a major
 impediment to the commercial growth of prostitution"

                                             -- Linus Torvalds


From ebiederman at lnxi.com  Sun Jan  4 23:34:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Jan  4 23:34:00 2004
Subject: Tiny linux
In-Reply-To: <E1AdME9-0004E4-00@megacz.com>
References: <Pine.LNX.4.44.0312182236530.15968-100000@maxroach.lanl.gov>
	<m3k74tuz8m.fsf@maxwell.lnxi.com> <1072049521.4876.63.camel@eddie>
	<3FE72505.1090804@bitworks.com> <m34qvcqh5e.fsf@maxwell.lnxi.com>
	<E1AdME9-0004E4-00@megacz.com>
Message-ID: <m3hdzbvw3y.fsf@maxwell.lnxi.com>

Adam Megacz <adam at megacz.com> writes:

> BTW, if you want super tiny kernels, check out Microsoft's
> (unpatented, surprisingly well documented) LZX compression format.
> It's specifically designed to compress x86 machine code, so it beats
> out all the general-purpose compression algorithms if the payload is a
> binary.  I think libmspack has an LGPL'ed LZX compressor/decompressor.

It looks like it is present in libmspack.  What kind of compression
ration do you get with LZX?  Unless it is noticeably greater than 2:1
the major gains are not to be had with compression.  Currently I use a
stripped down version of UPX when I really want a small self
extracting binary.  The nrv2b algorithm has an absolutely tiny 100
byte or so decompressor.

For the kernel the decompressor is 8K.  Which is significant but it is
again not a major bottle neck.

The target is to see how useful a linux kernel that we can put into
384K.  For use as a boot loader by LinuxBIOS.

Eric


From ebiederman at lnxi.com  Sun Jan  4 23:50:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Jan  4 23:50:00 2004
Subject: Source code control
Message-ID: <m3ptdz6l4r.fsf@maxwell.lnxi.com>

This is just a heads up.  I have been doing some investigation
into distributed version control systems.  arch looks like it
usable and getting more usable.


From adam at megacz.com  Mon Jan  5 00:19:01 2004
From: adam at megacz.com (Adam Megacz)
Date: Mon Jan  5 00:19:01 2004
Subject: Source code control
In-Reply-To: ebiederman@lnxi.com's message of "04 Jan 2004 22:05:08 -0700"
References: <m3ptdz6l4r.fsf@maxwell.lnxi.com>
Message-ID: <E1AdNIb-0005VV-00@megacz.com>

You really should check out darcs.  I did an extensive arch/darcs
comparison, and the XWT project (xwt.org) is going with the latter.
Vastly simpler than either bk or arch but with all the same features.

  - a


ebiederman at lnxi.com (Eric W. Biederman) writes:
> This is just a heads up.  I have been doing some investigation
> into distributed version control systems.  arch looks like it
> usable and getting more usable.
> 
> >From the design standpoint I don't see any big issues and
> it appears to be the equal of bk etc.  I think I see some
> was to make it simpler and more powerful but that is not needed to
> make a good revision control system.
> 
> I need to do a little more testing to see what arch is actually like
> to use.  Before I seriously start advocating anything but I'm not
> expecting any weird issues to crop up.  Except possibly for some
> issues running under cygwin, for the platform challenged.
> 
> Once my evaluation is finished I plan on pushing the projects I work
> on in that direction.  So this is something to think about.
> 
> Eric
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 

-- 
"If Darl McBride [the CEO of SCO, who claims the GPL 'destroys
 intellectual property'] was in charge, he'd probably make marriage
 unconstitutional too, since clearly it de-emphasizes the commercial
 nature of normal human interaction, and probably is a major
 impediment to the commercial growth of prostitution"

                                             -- Linus Torvalds


From rminnich at lanl.gov  Mon Jan  5 04:36:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan  5 04:36:01 2004
Subject: Source code control
In-Reply-To: <m3ptdz6l4r.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0401050233480.17858-100000@maxroach.lanl.gov>

one thing I don't much like are packages that require users to get a bunch 
of software and load it before they can get the package. I like to 
minimize barriers to entry, and we probably have all seen situations where 
to get package Y, you need to get package X, which doesn't work on your 
system Z due to conflicts with language/compiler A, B, and C. 

darcs requires people to get a Haskell and build it. Not so sure I like 
this.

arch is a single C program but if we are really proposing changes I'd 
rather not end up with maintaining an RCS as part of the project, so I 
think the changes should go back into arch if they're really needed. 

In the end, what does arch do better than bitkeeper? I'd like to 
understand that. bk is used for the Linux kernel itself, as well as the 
infiniband source tree, which indicates to me that it is fairly robust. bk 
has the same problem as darcs and arch, however: users will need to get 
these and get them working before they can get etherboot/linuxbios. The 
infiniband project fixed this by exporting to sourceforge. But sourceforge 
was failing again for me today, so depending on that seems a mistake. 

The 'arch' web pages have a few 'we need help' items, which leaves me
somewhat concerned.

Is the motivation here perceived problems with CVS (not hard to imagine) 
or with sourceforge (also not hard to imagine).

ron



From rminnich at lanl.gov  Mon Jan  5 04:54:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan  5 04:54:00 2004
Subject: current set of projects on bitkeeper
Message-ID: <Pine.LNX.4.44.0401050300570.18067-100000@maxroach.lanl.gov>

It's pretty impressive: http://www.bkbits.net/

ron



From ebiederman at lnxi.com  Mon Jan  5 08:04:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jan  5 08:04:00 2004
Subject: Source code control
In-Reply-To: <E1AdNIb-0005VV-00@megacz.com>
References: <m3ptdz6l4r.fsf@maxwell.lnxi.com> <E1AdNIb-0005VV-00@megacz.com>
Message-ID: <m31xqer0rv.fsf@maxwell.lnxi.com>

Adam Megacz <adam at megacz.com> writes:

> You really should check out darcs.  I did an extensive arch/darcs
> comparison, and the XWT project (xwt.org) is going with the latter.
> Vastly simpler than either bk or arch but with all the same features.

I looked on the core mailing list and saw a version control discussion
but did not see your comparison.

As for features at least as of tla 1.1 I do not believe this to
be the case.  Feel free to prove me wrong.

It was mentioned in some of your discussion that darcs uses
reverse format patches.  I am leary of that because it was
exactly that ``optimization'' in RCS which made CVS suck at branches.

For myself I am branch happy.  And I don't think I like the idea of
having to create another copy of a repository to have a branch.  Besides
which darcs does not appear to have the merging capabilities that are
present in arch.  

I will keep darcs in mind.  It always interesting to see another version
control system.


Eric


From ebiederman at lnxi.com  Mon Jan  5 09:00:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jan  5 09:00:00 2004
Subject: Source code control
In-Reply-To: <Pine.LNX.4.44.0401050233480.17858-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401050233480.17858-100000@maxroach.lanl.gov>
Message-ID: <m3r7yeo520.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> one thing I don't much like are packages that require users to get a bunch 
> of software and load it before they can get the package. I like to 
> minimize barriers to entry, and we probably have all seen situations where 
> to get package Y, you need to get package X, which doesn't work on your 
> system Z due to conflicts with language/compiler A, B, and C. 
> 
> darcs requires people to get a Haskell and build it. Not so sure I like 
> this.
> 
> arch is a single C program but if we are really proposing changes I'd 
> rather not end up with maintaining an RCS as part of the project, so I 
> think the changes should go back into arch if they're really needed. 

Agreed.  Arch is at the maturity level now that it should be usable.
But at the same time I expect a few tweaks along the edges would be
nice.  Have you seen me work on a project make changes and not push
it back to the original developers?  And a big part of what
a distributed version control system does it that it makes this
easier.
 
> In the end, what does arch do better than bitkeeper? 

- Merging, arch has several methods.
- Branches, with arch you don't need multiple copies of your archive.
- The License.  The free Bk license requires at least your change
  history to be released, which for early development can trivially
  violate NDAs, which is a big concern on the LinuxBIOS side.
  The free Bk license forbids working on competitors to bk.
- Distribution.  All you have to do to export an arch repository for
  all the world to see is to point an ftp or http server at it's
  directory.
- Renames.  Since arch does not revision control the files individual
  but a change at a time you don't get into awkward situations with
  the SCCS version control file named differently than the file itself.

> I'd like to 
> understand that. bk is used for the Linux kernel itself, as well as the 
> infiniband source tree, which indicates to me that it is fairly robust. bk 
> has the same problem as darcs and arch, however: users will need to get 
> these and get them working before they can get etherboot/linuxbios.

Partly that is what releases are for, and we need to make those on the
LinuxBIOS side.  The only arch dependencies are diff, patch, tar, and
C.  And there should be prebuilt packages along shortly.

As for the Linux kernel half the developers don't use bk for
lots of things including at the moment Andrew Morton the 2.6
maintainer.  Getting arch to the point where the majority
of the kernel developers can use it productively is likely
what will require the most development effort at this point.

But it is possible at this point with almost no knowledge of arch
to take a raw repository to extract your changes with patch and tar.

> The 
> infiniband project fixed this by exporting to sourceforge. But sourceforge 
> was failing again for me today, so depending on that seems a
> mistake. 

Yay they responded to my complaints. :)  

Also there is also a different level of care you need to give to an
open source tool and a tool with a more restrictive license.  With a
more restrictive license, some people will never use the tool.  With
an open source tool the only concern is the tool painful to setup.

> The 'arch' web pages have a few 'we need help' items, which leaves me
> somewhat concerned.

arch is maturing quickly and has an active developer community.  With
tla 1.1 out arch does not appear to be lacking anything significant.  
The core looks fairly solid but arch is not so old there still won't
be itches to scratch.

I am in the middle of a fairly in depth technical review.  And I am
going to make darn certain there we need missing before I seriously
suggest switching over.  I have what two sets of criteria I am using
to evaluate arch, immediate needs, and expected long term needs.  So
far I have seen nothing in the immediate needs category missing.  For
the long term needs I have seen a few possibilities.

The best analogy I can think of is cluster applications like mpi.  It
is trivial to scale to 20 or 30 nodes.  Getting an implementation that
works and scales to the 1000s of nodes is a bit more work, even when
there is a good design that support it.  There are always issues at
the large scale you can't see at the small scale.

Arch is that way right now.  The design looks good. It runs fine on
small projects but it has not been pushed to the large scales yet.

> Is the motivation here perceived problems with CVS (not hard to imagine) 
> or with sourceforge (also not hard to imagine).

CVS, sourceforge, and the fact that there are currently at least
4 repositories for the freebios2 tree alone.  And for LinuxBIOS that
inherently makes sense.  With a distributed source code control system
we can continue working the way we are working now and have the tools
to merge the repositories.

Basically with a distributed version control system everybody and
their brother can have commit access.  They just can't commit to
the official branch.  

On the etherboot side the only real problem I have is by checking
in the repository multiple times getting code from one repository
to another is a pain.  As evidenced by the fact that EFI support
still has not made it into the 5.2 and 5.3 branches yet...

Eric


From ebiederman at lnxi.com  Mon Jan  5 09:10:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jan  5 09:10:01 2004
Subject: current set of projects on bitkeeper
In-Reply-To: <Pine.LNX.4.44.0401050300570.18067-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401050300570.18067-100000@maxroach.lanl.gov>
Message-ID: <m3n092o4lv.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> It's pretty impressive: http://www.bkbits.net/

And it looks like a few of them are actually used.  And one or two
of them aren't even related to the Linux kernel.  The arch registry:

http://gnuarch.org/bin/view/Main/ArchiveRegistry 
is almost as long.

Eric


From rminnich at lanl.gov  Mon Jan  5 10:23:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan  5 10:23:01 2004
Subject: Source code control
In-Reply-To: <m3r7yeo520.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0401050829530.20462-100000@maxroach.lanl.gov>

Eric, I just realized that since you contributed to 'arch' you are locked 
out of using bk!

OK, your point it well taken!

ron



From linuxbios at xdr.com  Mon Jan  5 12:36:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Mon Jan  5 12:36:01 2004
Subject: EPIA-M fix for real time clock operation
Message-ID: <200401051743.i05HhTB5006883@xdr.com>

In V1 the epia-m real time clock was stopped, the file to change to fix this
is src/southbridge/via/vt8235/setup_misc.inc

	movl	$CONFIG_ADDR(0, 0x88, 0x4e), %eax
	movb	$0x1a, %dl
	PCI_WRITE_CONFIG_BYTE

The value used to be 1b, this evidently freezes the clock.
Changing to 1a allows normal operation. The low 3 bits are not documented.

-Dave


From linuxbios at xdr.com  Mon Jan  5 14:30:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Mon Jan  5 14:30:00 2004
Subject: Linuxbios -> etherboot 5.0.10, is CONSOLE_DUAL possible?
Message-ID: <200401051936.i05JapWP007247@xdr.com>

I'm using etherboot 5.0.10 on the epia-m, but I have -DLINUXBIOS defined
in etherboot's config, not -DPCBIOS. I want some debug messages to come out
on the console, but these need -DPCBIOS to be defined. If I define -DPCBIOS
alongside -DLINUXBIOS, I get link errors. Anyone have any ideas?

Strictly speaking this is an etherboot issue, not a linuxbios issue. Sorry :^)

-Dave


From bos at serpentine.com  Mon Jan  5 15:32:00 2004
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Mon Jan  5 15:32:00 2004
Subject: Source code control
In-Reply-To: <m3r7yeo520.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0401050233480.17858-100000@maxroach.lanl.gov>
	 <m3r7yeo520.fsf@maxwell.lnxi.com>
Message-ID: <1073335141.15302.25.camel@serpentine.pathscale.com>

Not to bang the BK drum, but I'd hate to see the arguments for or
against it misrepresented.

On Mon, 2004-01-05 at 06:15, Eric W. Biederman wrote:

> > In the end, what does arch do better than bitkeeper? 
> 
> - Merging, arch has several methods.

BK's merging support is, for what it's worth, by far the best I have
seen.  It does most merges automatically that tools like CVS just dump
you into vi for.

> - Branches, with arch you don't need multiple copies of your archive.

BK has pretty cheap branching support.  It uses a tree of hardlinks if
that's what you want, so you just end up paying in inodes.

> - Distribution.  All you have to do to export an arch repository for
>   all the world to see is to point an ftp or http server at it's
>   directory.

BK has a built-in server that provides the same facilities.

> - Renames.  Since arch does not revision control the files individual
>   but a change at a time you don't get into awkward situations with
>   the SCCS version control file named differently than the file itself.

BK supports renames and metadata changes (file modes, mostly) perfectly
well.

BK is pretty slow on a large tree.  However, it's several thousand (!)
times faster than arch in most cases, which is by design just abominably
slow at even the most trivial of common operations.

> As for the Linux kernel half the developers don't use bk for
> lots of things including at the moment Andrew Morton the 2.6
> maintainer.

One solid reason for this is that BK doesn't have good GNU patch
handling support.  You can import a GNU patch into BK, no problem, but
it's a huge PITA to then manage successors to that patch as their
maintainer issues them.  You're basically left in manual merge hell.

Andrew wrote his own set of scripts, which have since taken on a life of
their own, to handle a pile of patches against a tarball.  This works
better than BK for a loosely-coupled world in which everyone flings GNU
patches around.  If you have a tighter world in which 90% of people deal
in terms of BK patches, BK is a lot easier to work with than the patch
scripts.

On the other hand, there's a lot to be said for open source software in
this realm.  Larry is perfectly happy to tell paying customers to fuck
off (and in approximately that language, too, as Ron can probably
attest) if he doesn't want to implement a feature they're requesting. 
The flip side is that arch is about a decade away from being as
performant and mature as BK is today.

	<b



From ebiederman at lnxi.com  Mon Jan  5 16:22:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jan  5 16:22:00 2004
Subject: Linuxbios -> etherboot 5.0.10, is CONSOLE_DUAL possible?
In-Reply-To: <200401051936.i05JapWP007247@xdr.com>
References: <200401051936.i05JapWP007247@xdr.com>
Message-ID: <m3smiu3x06.fsf@maxwell.lnxi.com>

Dave Ashley <linuxbios at xdr.com> writes:

> I'm using etherboot 5.0.10 on the epia-m, but I have -DLINUXBIOS defined
> in etherboot's config, not -DPCBIOS. I want some debug messages to come out
> on the console, but these need -DPCBIOS to be defined. If I define -DPCBIOS
> alongside -DLINUXBIOS, I get link errors. Anyone have any ideas?

You want some debug messages to be printed with x86 bios calls?

In 5.2 there is CONSOLE_DIRECT_VGA that prints directly to a screen,
and I think that is what you want.

> Strictly speaking this is an etherboot issue, not a linuxbios issue. Sorry :^)

So ask on the etherboot list then...

Eric


From ebiederman at lnxi.com  Mon Jan  5 17:10:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jan  5 17:10:01 2004
Subject: Source code control
In-Reply-To: <1073335141.15302.25.camel@serpentine.pathscale.com>
References: <Pine.LNX.4.44.0401050233480.17858-100000@maxroach.lanl.gov>
	<m3r7yeo520.fsf@maxwell.lnxi.com>
	<1073335141.15302.25.camel@serpentine.pathscale.com>
Message-ID: <m3oeti3urj.fsf@maxwell.lnxi.com>

"Bryan O'Sullivan" <bos at serpentine.com> writes:

> Not to bang the BK drum, but I'd hate to see the arguments for or
> against it misrepresented.

I agree that the way I stated the differences BK didn't sound too good.

> On Mon, 2004-01-05 at 06:15, Eric W. Biederman wrote:
> > - Distribution.  All you have to do to export an arch repository for
> >   all the world to see is to point an ftp or http server at it's
> >   directory.
> 
> BK has a built-in server that provides the same facilities.

Nice but not quite as convenient, as needing no special server.
Sort of the plain text versus the binary file argument, until it is a
performance bottleneck the extra convenience has a lot of nice
secondary side effects. 

> BK is pretty slow on a large tree.  However, it's several thousand (!)
> times faster than arch in most cases, which is by design just abominably
> slow at even the most trivial of common operations.

That arch is slow is something I will look into.  Although it should
be able to trivially be beat sourceforges anonymous CVS servers...

> On the other hand, there's a lot to be said for open source software in
> this realm.  
Right.

> The flip side is that arch is about a decade away from being as
> performant and mature as BK is today.

If the performance is not good enough to be usable we won't go there.
And if it is usable but annoying it can be fixed.

Eric


From linuxbios at xdr.com  Mon Jan  5 17:39:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Mon Jan  5 17:39:01 2004
Subject: Etherboot 5.2.2 ebi images?
Message-ID: <200401052246.i05MkXlQ007732@xdr.com>

How do I make ebi images for linuxbios in the newer etherboot?
I get make: *** No rule to make target `bin/via6105m.ebi'.  Stop.

which worked before in 5.0.10...

-Dave


From ebiederman at lnxi.com  Mon Jan  5 17:58:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jan  5 17:58:00 2004
Subject: Etherboot 5.2.2 ebi images?
In-Reply-To: <200401052246.i05MkXlQ007732@xdr.com>
References: <200401052246.i05MkXlQ007732@xdr.com>
Message-ID: <m3llom0zff.fsf@maxwell.lnxi.com>

Dave Ashley <linuxbios at xdr.com> writes:

> How do I make ebi images for linuxbios in the newer etherboot?
> I get make: *** No rule to make target `bin/via6105m.ebi'.  Stop.

make bin/via-rhine.elf or make bin/via-rhine.zelf is what you want.

> which worked before in 5.0.10...

Things were cleaned up a little bit in 5.2.  

Eric


From linuxbios at xdr.com  Mon Jan  5 19:01:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Mon Jan  5 19:01:00 2004
Subject: EPIA-M AC97 link problem, 20% of boxes
Message-ID: <200401060008.i0608jEo008099@xdr.com>

We're into production, and we've found 20% of our boxes based on the
epia-m 6000 + linuxbios have a problem with the AC97 codec, the codec
reports busy all the time, or never reports a ready status. If I switch
back to award bios the codec works fine. This is related to device
11.5 of the VT8235. It seems as though 80% of the boxes have no problem,
but 20% always have the problem under linuxbios.

I'll need to dig into this and work out a solution, which of course I'll
share. I'm wondering if anyone has any suggestions as to what to try.

Thanks--
Dave


From stepan at suse.de  Mon Jan  5 20:11:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Mon Jan  5 20:11:00 2004
Subject: Source code control
In-Reply-To: <m3oeti3urj.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0401050233480.17858-100000@maxroach.lanl.gov> <m3r7yeo520.fsf@maxwell.lnxi.com> <1073335141.15302.25.camel@serpentine.pathscale.com> <m3oeti3urj.fsf@maxwell.lnxi.com>
Message-ID: <20040106011835.GA32623@suse.de>

* Eric W. Biederman <ebiederman at lnxi.com> [040105 23:17]:
> > BK is pretty slow on a large tree.  However, it's several thousand (!)
> > times faster than arch in most cases, which is by design just abominably
> > slow at even the most trivial of common operations.
> 
> That arch is slow is something I will look into.  Although it should
> be able to trivially be beat sourceforges anonymous CVS servers...
 
This is something that has pretty much changed when arch was rewritten
from being a big huge mess of shell scripts to one single binary called
tla. The former was pretty unusable, the later works not (noticably) slower
than bk.

> > The flip side is that arch is about a decade away from being as
> > performant and mature as BK is today.
> 
> If the performance is not good enough to be usable we won't go there.
> And if it is usable but annoying it can be fixed.

bk has some nice gui tools that I really miss from tla. Last time I
checked tlator, it was really more a try than a program...
On the other hand that is just my i-need-colors-to-go-away-from-cvs
attitude...

For the merge facilities, I don't think this project has had, or will have,
big problems with merging different trees together. And no versioning
system can make up to the caution it takes to see the conceptional
problems that might hide behind a merge conflict.

  Stefan

-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From rminnich at lanl.gov  Mon Jan  5 20:51:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan  5 20:51:01 2004
Subject: [Etherboot-developers] Re: Source code control
In-Reply-To: <1073335141.15302.25.camel@serpentine.pathscale.com>
Message-ID: <Pine.LNX.4.44.0401051857200.24395-100000@maxroach.lanl.gov>

I am reforwarding this as it got dropped by a bunch of 'naughty language' 
filters ...

ron


On Mon, 5 Jan 2004, Bryan O'Sullivan wrote:

> Not to bang the BK drum, but I'd hate to see the arguments for or
> against it misrepresented.
> 
> On Mon, 2004-01-05 at 06:15, Eric W. Biederman wrote:
> 
> > > In the end, what does arch do better than bitkeeper? 
> > 
> > - Merging, arch has several methods.
> 
> BK's merging support is, for what it's worth, by far the best I have
> seen.  It does most merges automatically that tools like CVS just dump
> you into vi for.
> 
> > - Branches, with arch you don't need multiple copies of your archive.
> 
> BK has pretty cheap branching support.  It uses a tree of hardlinks if
> that's what you want, so you just end up paying in inodes.
> 
> > - Distribution.  All you have to do to export an arch repository for
> >   all the world to see is to point an ftp or http server at it's
> >   directory.
> 
> BK has a built-in server that provides the same facilities.
> 
> > - Renames.  Since arch does not revision control the files individual
> >   but a change at a time you don't get into awkward situations with
> >   the SCCS version control file named differently than the file itself.
> 
> BK supports renames and metadata changes (file modes, mostly) perfectly
> well.
> 
> BK is pretty slow on a large tree.  However, it's several thousand (!)
> times faster than arch in most cases, which is by design just abominably
> slow at even the most trivial of common operations.
> 
> > As for the Linux kernel half the developers don't use bk for
> > lots of things including at the moment Andrew Morton the 2.6
> > maintainer.
> 
> One solid reason for this is that BK doesn't have good GNU patch
> handling support.  You can import a GNU patch into BK, no problem, but
> it's a huge PITA to then manage successors to that patch as their
> maintainer issues them.  You're basically left in manual merge hell.
> 
> Andrew wrote his own set of scripts, which have since taken on a life of
> their own, to handle a pile of patches against a tarball.  This works
> better than BK for a loosely-coupled world in which everyone flings GNU
> patches around.  If you have a tighter world in which 90% of people deal
> in terms of BK patches, BK is a lot easier to work with than the patch
> scripts.
> 
> On the other hand, there's a lot to be said for open source software in
> this realm.  Larry is perfectly happy to tell paying customers to f@@@
> off (and in approximately that language, too, as Ron can probably
> attest) if he doesn't want to implement a feature they're requesting. 
> The flip side is that arch is about a decade away from being as
> performant and mature as BK is today.
> 
> 	<b
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Etherboot-developers mailing list
> Etherboot-developers at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> 



From linuxbios at xdr.com  Mon Jan  5 21:49:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Mon Jan  5 21:49:00 2004
Subject: EPIA-M AC97 link problem, 20% of boxes
Message-ID: <200401060256.i062uhEr009325@xdr.com>

I worked out a fix. The VT8235 11.6 register 0x41 can be used to
reset the AC97 link, when I reset then unreset the thing starts working
again. I'll have more details tomorrow.

-Dave


From rminnich at lanl.gov  Mon Jan  5 22:10:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan  5 22:10:01 2004
Subject: EPIA-M AC97 link problem, 20% of boxes [PMX:#]
In-Reply-To: <200401060256.i062uhEr009325@xdr.com>
Message-ID: <Pine.LNX.4.44.0401052016300.24906-100000@maxroach.lanl.gov>

On Mon, 5 Jan 2004, Dave Ashley wrote:

> I worked out a fix. The VT8235 11.6 register 0x41 can be used to
> reset the AC97 link, when I reset then unreset the thing starts working
> again. I'll have more details tomorrow.

Thanks. I'll betcha the standard bios does this workaround too.

You have an earlier fix you submitted, can you send them both to me when 
you're sure they're good?

thanks again

ron



From adam at megacz.com  Tue Jan  6 02:46:01 2004
From: adam at megacz.com (Adam Megacz)
Date: Tue Jan  6 02:46:01 2004
Subject: Tiny linux
In-Reply-To: ebiederman@lnxi.com's message of "04 Jan 2004 21:48:49 -0700"
References: <Pine.LNX.4.44.0312182236530.15968-100000@maxroach.lanl.gov> <m3k74tuz8m.fsf@maxwell.lnxi.com> <1072049521.4876.63.camel@eddie> <3FE72505.1090804@bitworks.com> <m34qvcqh5e.fsf@maxwell.lnxi.com> <E1AdME9-0004E4-00@megacz.com> <m3hdzbvw3y.fsf@maxwell.lnxi.com>
Message-ID: <E1Adm4X-0000mG-00@megacz.com>

ebiederman at lnxi.com (Eric W. Biederman) writes:
> extracting binary.  The nrv2b algorithm has an absolutely tiny 100
> byte or so decompressor.

Wow, that's impressive.  In the face of such a tiny decompressor LZX
might not be worth it; I'm sure the size of the decompression code
wasn't on anybody's mind when the algorithm was designed.

  - a



From adam at megacz.com  Tue Jan  6 02:49:00 2004
From: adam at megacz.com (Adam Megacz)
Date: Tue Jan  6 02:49:00 2004
Subject: Source code control
In-Reply-To: ron minnich's message of "Mon, 5 Jan 2004 02:43:23 -0700 (MST)"
References: <Pine.LNX.4.44.0401050233480.17858-100000@maxroach.lanl.gov>
Message-ID: <E1Adm7E-0000nC-00@megacz.com>

ron minnich <rminnich at lanl.gov> writes:
> darcs requires people to get a Haskell and build it. Not so sure I like 
> this.

We solved this problem by distributing statically linked binaries.
Not ideal, but generally workable.  Feel free to use them:

  http://dist.xwt.org/darcs/

> In the end, what does arch do better than bitkeeper?

I think for many people (including me), BitMover's recent shenanigans
are more of a factor than the technical merits of their code.  But I
really don't want to start that argument here.  I do not claim that
darcs (or arch) has any features that BK lacks, except perhaps
simplicity.

  - a



From adam at megacz.com  Tue Jan  6 02:56:01 2004
From: adam at megacz.com (Adam Megacz)
Date: Tue Jan  6 02:56:01 2004
Subject: Source code control
In-Reply-To: ebiederman@lnxi.com's message of "05 Jan 2004 06:19:16 -0700"
References: <m3ptdz6l4r.fsf@maxwell.lnxi.com> <E1AdNIb-0005VV-00@megacz.com> <m31xqer0rv.fsf@maxwell.lnxi.com>
Message-ID: <E1AdmE6-0000py-00@megacz.com>

ebiederman at lnxi.com (Eric W. Biederman) writes:
> As for features at least as of tla 1.1 I do not believe this to
> be the case.  Feel free to prove me wrong.

Which features do you find present in tla that you do not see in darcs?


> It was mentioned in some of your discussion that darcs uses reverse
> format patches.  I am leary of that because it was exactly that
> ``optimization'' in RCS which made CVS suck at branches.

Well, I certainly agree that RCS/CVS is awful, and I'm sure that its
patch format plays some part in this, but I do not see how that
extrapolates to darcs.  Have you read the Theory Of Patches?


> For myself I am branch happy.

Me too!  I love branches.  The hard part is getting people who don't
normally use them to start using them.  When they can think of each
branch as a separate checkout/repo[*] I find that novices pick up the
concept of branching almost instantly.

[*] There is no difference between a darcs workspace and repository;
    every workspace is implicitly a fully-functional repository from
    which you can take checkouts; in fact, this is exactly how you
    make a branch.

> And I don't think I like the idea of having to create another copy
> of a repository to have a branch.

Why?  Hardlinks eliminate the space concerns in most cases, and in the
rest, well, disk is cheap, and human time sure isn't ;)

  - a


From ebiederman at lnxi.com  Tue Jan  6 07:16:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jan  6 07:16:01 2004
Subject: Source code control
In-Reply-To: <E1AdmE6-0000py-00@megacz.com>
References: <m3ptdz6l4r.fsf@maxwell.lnxi.com> <E1AdNIb-0005VV-00@megacz.com>
	<m31xqer0rv.fsf@maxwell.lnxi.com> <E1AdmE6-0000py-00@megacz.com>
Message-ID: <m38ykll103.fsf@maxwell.lnxi.com>

Adam Megacz <adam at megacz.com> writes:

> ebiederman at lnxi.com (Eric W. Biederman) writes:
> > As for features at least as of tla 1.1 I do not believe this to
> > be the case.  Feel free to prove me wrong.
> 
> Which features do you find present in tla that you do not see in darcs?

- Written in C, so it is more hackable, and it has more hackers.
- The ability to sign repositories (admittedly still beta but the subject
  did not even come up on the darcs list).

There are a bunch of other places that are pluses and minuses but...

I guess the really big difference between darcs and arch are global
identifiers.  arch has them darcs doesn't.  This simplifies darcs
quite a bit, but my gut feel is that some of the more interesting
solutions involve global identifiers. 

Eric


From atila at unizar.es  Tue Jan  6 08:17:01 2004
From: atila at unizar.es (atila at unizar.es)
Date: Tue Jan  6 08:17:01 2004
Subject: Source code control
Message-ID: <1073395067.3ffab57bcfe73@webmail.unizar.es>

Nobody talked about subversion in this thread, and I'm not sure why... 

I haven't used it, only considered it for future projects after reading the 
docs. But the concept was to make a cvs replacement, with its advantages and 
without its hassles/disadvantages. Last time I checked, the apache project was 
seriously considering moving to subversion, so it can't be that bad. Oh, and the 
license is Apache/BSD, just for comparison with the bk/arch crossfire... ;-)

I also found a brief comparison of version control systems, for the 
decisionmakers:

http://better-scm.berlios.de/comparison/comparison.html

Fernando



From linuxbios at xdr.com  Tue Jan  6 10:50:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Tue Jan  6 10:50:01 2004
Subject: EPIA-M AC97 link problem, 20% of boxes
Message-ID: <200401061557.i06Fv9t3012922@xdr.com>

Here is the complete fix. Put this code at the bottom of
src/southbridge/via/vt8235/setup_misc.inc
// reset AC97 link
	movl	$CONFIG_ADDR(0, 0x88 + 5, 0x41), %eax
	movb	$0x80, %dl
	PCI_WRITE_CONFIG_BYTE

	DELAY($0x5000)

	movl	$CONFIG_ADDR(0, 0x88 + 5, 0x41), %eax
	movb	$0xcc, %dl
	PCI_WRITE_CONFIG_BYTE


The DELAY($0x5000) is arbitrary, I just grabbed that from the raminit code.
I was shooting for 1/100th of a second, I don't really know what I got. All
this does is force the reset line on the ACLink interface, then remove it.
This fixes the problem. The problem was for 20% of our epia-m boxes running
linuxbios the ac97 link would be reporting busy all the time (never ready),
and the ALSA driver would throw up its hands and audio out wouldn't work.

This is the same file to modify for the previous fix recently posted. The
previous fix is to enable the real time clock of the VT8235, near the top
of this file make it so the entry looks like this:
	movl	$CONFIG_ADDR(0, 0x88, 0x4e), %eax
	movb	$0x1a, %dl
	PCI_WRITE_CONFIG_BYTE

The $0x1a value used to be $0x1b, which for some reason freezes the real time
clock. This can easily be tested with "hwclock --show". Before this
modification that command will just freeze, but you can control-C out of it.
After the mod it works as expected.

-Dave



From bos at serpentine.com  Tue Jan  6 11:53:00 2004
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue Jan  6 11:53:00 2004
Subject: Source code control
In-Reply-To: <1073395067.3ffab57bcfe73@webmail.unizar.es>
References: <1073395067.3ffab57bcfe73@webmail.unizar.es>
Message-ID: <1073408416.15302.61.camel@serpentine.pathscale.com>

On Tue, 2004-01-06 at 05:17, atila at unizar.es wrote:
> Nobody talked about subversion in this thread, and I'm not sure why... 

I get the impression that people would like to move to a fully
distributed revision control system, which svn isn't.  It's also
appallingly complex for the job it does.

	<b



From ebiederman at lnxi.com  Tue Jan  6 11:56:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jan  6 11:56:00 2004
Subject: Source code control
In-Reply-To: <1073395067.3ffab57bcfe73@webmail.unizar.es>
References: <1073395067.3ffab57bcfe73@webmail.unizar.es>
Message-ID: <m3oethqaak.fsf@maxwell.lnxi.com>

atila at unizar.es writes:

> Nobody talked about subversion in this thread, and I'm not sure why... 

It's not distributed.  Multiple repositories are hard.
LinuxBIOS development is inherently distributed, and needs
multiple repositories.

> http://better-scm.berlios.de/comparison/comparison.html

Thanks it is an interesting comparison.

Eric


From ebiederman at lnxi.com  Tue Jan  6 12:50:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jan  6 12:50:01 2004
Subject: [Etherboot-developers] Source code control
In-Reply-To: <000801c3d3f3$bf8bf500$3402a8c0@ipc>
References: <000801c3d3f3$bf8bf500$3402a8c0@ipc>
Message-ID: <m3d69xvu22.fsf@maxwell.lnxi.com>

"Timothy Legge" <tlegge at rogers.com> writes:

> > Once my evaluation is finished I plan on pushing the projects I work
> > on in that direction.  So this is something to think about.
> > 
> 
> Does arch have anything like webcvs?  I tend to use that quite a bit
> when I don't want to be bothered with vi.

I have not seen a webcvs equivalent.  However you can get mirror the
repository local so it isn't needed as much.

This is one of those areas where since arch is immature it doesn't 
have a tool set as rich as cvs does today.
 
> My needs are fairly simple as long as arch does what cvs does, it should
> meet them.  I assume it runs on the command line...

Yes arch runs on the command line.  Although if arch did exactly
what CVS does there would be no point in using it.

Eric



From ebiederman at lnxi.com  Tue Jan  6 13:11:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jan  6 13:11:01 2004
Subject: [Etherboot-developers] Source code control
In-Reply-To: <m3d69xvu22.fsf@maxwell.lnxi.com>
References: <000801c3d3f3$bf8bf500$3402a8c0@ipc>
	<m3d69xvu22.fsf@maxwell.lnxi.com>
Message-ID: <m3znd19bzp.fsf@maxwell.lnxi.com>

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

> "Timothy Legge" <tlegge at rogers.com> writes:
> 
> > > Once my evaluation is finished I plan on pushing the projects I work
> > > on in that direction.  So this is something to think about.
> > > 
> > 
> > Does arch have anything like webcvs?  I tend to use that quite a bit
> > when I don't want to be bothered with vi.
> 
> I have not seen a webcvs equivalent.  However you can get mirror the
> repository local so it isn't needed as much.
> 
> This is one of those areas where since arch is immature it doesn't 
> have a tool set as rich as cvs does today.

Looking a little further there is a ViewArch that seems to fill
that niche.

Eric


From linuxbios at xdr.com  Tue Jan  6 13:13:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Tue Jan  6 13:13:00 2004
Subject: Source code control
Message-ID: <200401061820.i06IKtJ0013670@xdr.com>

The only problems I have with CVS are:
1) Doesn't deal with symlinks
2) Your source tree is littered with CVS directories
3) Versioning is on a file basis, not a tree basis
4) Dealing with binaries seems complicated

I was watching the subversion project since I saw a posting about it on
slashdot, and the two things that were interesting about it were
1) Will eventually handle symlinks
2) The whole tree is versioned, not individual files

I've kept checking back in on subversion but they're not at 1.00 yet and
it seems like for the longest time the symlink handling never got implemented.
I don't know for sure if it is working now even. It seemed like subversion
was moving forward with glacial speeds, so I figured it was a dead project.

-Dave



From linuxbios at xdr.com  Tue Jan  6 14:24:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Tue Jan  6 14:24:00 2004
Subject: Trouble with etherboot-5.2.2
Message-ID: <200401061931.i06JVDej013883@xdr.com>

I'm trying to use my bastardized epia-m tree with etherboot-5.2.2 using
the bin/via-rhine.elf image in place of my 5.0.10 bin32/via6105m.ebi image
that has been working fine.

I get this with linuxbios + 5.0.10:
Found ELF candiate at offset 0                                                  
New segment addr 0x94000 size 0x6f68 offset 0x60 filesize 0x3460                
(cleaned up) New segment addr 0x94000 size 0x6f68 offset 0x60 filesize 0x3460   
Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000006f68 filesz: 0x00
Clearing Segment: addr: 0x0000000000097460 memsz: 0x0000000000003b08            
Jumping to boot code at 0x94000                                                 
ROM segment 0x0001 length 0x0000 reloc 0x9400                                   
Etherboot 5.0.10 (GPL) ELF for [VIA 86C100]                                     
... everything proceeds normally

I get this with linuxbios + 5.2.2:
Found ELF candiate at offset 0                                                  
Loading Etherboot version: 5.2.2                                                
Dropping non PT_LOAD segment                                                    
New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc                
(cleaned up) New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc   
Loading Segment: addr: 0x0000000005f81028 memsz: 0x000000000000efc0 filesz: 0x0c
Clearing Segment: addr: 0x0000000005f86ae4 memsz: 0x0000000000009504            
Jumping to boot code at 0x20000                                                 
ROM segment 0x0001 length 0x0000 reloc 0x00020000                               

These addr: values for Loading + Clearing Segment seem way off. I looked into
linuxbios src/lib/elfboot.c and there is only one line difference between my
version and the latest off cvs:
	head->phdr_next = head->phdr_prev = head;
at line 369 or 370. I added that but no difference.

This question is probably directed at Eric again: What should I try?
My config for etherboot 5.2.2 is pretty much stock, except I added this line:
CFLAGS += -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 -DCONSPEED=115200

I also tried taking out -DRELOCATE
but that made no difference.

Thanks!
Dave


From ebiederman at lnxi.com  Tue Jan  6 15:16:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jan  6 15:16:01 2004
Subject: Trouble with etherboot-5.2.2
In-Reply-To: <200401061931.i06JVDej013883@xdr.com>
References: <200401061931.i06JVDej013883@xdr.com>
Message-ID: <m3ad504yjb.fsf@maxwell.lnxi.com>

Dave Ashley <linuxbios at xdr.com> writes:

> I'm trying to use my bastardized epia-m tree with etherboot-5.2.2 using
> the bin/via-rhine.elf image in place of my 5.0.10 bin32/via6105m.ebi image
> that has been working fine.
> 
> I get this with linuxbios + 5.0.10:
> Found ELF candiate at offset 0
> 
> New segment addr 0x94000 size 0x6f68 offset 0x60 filesize 0x3460
> (cleaned up) New segment addr 0x94000 size 0x6f68 offset 0x60 filesize 0x3460
> Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000006f68 filesz: 0x00
> Clearing Segment: addr: 0x0000000000097460 memsz: 0x0000000000003b08
> Jumping to boot code at 0x94000
> ROM segment 0x0001 length 0x0000 reloc 0x9400
> Etherboot 5.0.10 (GPL) ELF for [VIA 86C100]

> ... everything proceeds normally
> 
> I get this with linuxbios + 5.2.2:
> Found ELF candiate at offset 0
> Loading Etherboot version: 5.2.2
> Dropping non PT_LOAD segment
> New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc
> (cleaned up) New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc
> Loading Segment: addr: 0x0000000005f81028 memsz: 0x000000000000efc0 filesz: 0x0c
> Clearing Segment: addr: 0x0000000005f86ae4 memsz: 0x0000000000009504
> Jumping to boot code at 0x20000
> ROM segment 0x0001 length 0x0000 reloc 0x00020000
> 
> 
> These addr: values for Loading + Clearing Segment seem way off. 

Agreed.  What does readelf -e say they are in the file?

> I also tried taking out -DRELOCATE
> but that made no difference.

Right you need to get etherboot loaded properly before that
matters.

Eric


From linuxbios at xdr.com  Tue Jan  6 15:36:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Tue Jan  6 15:36:01 2004
Subject: Trouble with etherboot-5.2.2
Message-ID: <200401062043.i06Kht3O014189@xdr.com>

Eric wrote:

>Agreed.  What does readelf -e say they are in the file?

Here it is:
dave% readelf -e bin/via-rhine.elf 
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Intel 80386
  Version:                           0x1
  Entry point address:               0x20000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         2
  Size of section headers:           0 (bytes)
  Number of section headers:         0
  Section header string table index: 0

There are no sections in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  NOTE           0x000074 0x00000074 0x00000074 0x0003c 0x0003c RWE 0
  LOAD           0x0000b0 0x00020000 0x00020000 0x05abc 0x0efc0 RWE 0

-Dave


From ebiederman at lnxi.com  Tue Jan  6 15:57:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jan  6 15:57:01 2004
Subject: Trouble with etherboot-5.2.2
In-Reply-To: <200401062043.i06Kht3O014189@xdr.com>
References: <200401062043.i06Kht3O014189@xdr.com>
Message-ID: <m3fzeshjqe.fsf@maxwell.lnxi.com>

Dave Ashley <linuxbios at xdr.com> writes:

> Eric wrote:
> 
> >Agreed.  What does readelf -e say they are in the file?
> 
> Here it is:
> dave% readelf -e bin/via-rhine.elf 
> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
>   Class:                             ELF32
>   Data:                              2's complement, little endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              EXEC (Executable file)
>   Machine:                           Intel 80386
>   Version:                           0x1
>   Entry point address:               0x20000
>   Start of program headers:          52 (bytes into file)
>   Start of section headers:          0 (bytes into file)
>   Flags:                             0x0
>   Size of this header:               52 (bytes)
>   Size of program headers:           32 (bytes)
>   Number of program headers:         2
>   Size of section headers:           0 (bytes)
>   Number of section headers:         0
>   Section header string table index: 0
> 
> There are no sections in this file.
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   NOTE           0x000074 0x00000074 0x00000074 0x0003c 0x0003c RWE 0
>   LOAD           0x0000b0 0x00020000 0x00020000 0x05abc 0x0efc0 RWE 0

So we now know which segments you have and for certain their
values.

> I get this with linuxbios + 5.2.2:
> Found ELF candiate at offset 0
> 
> Loading Etherboot version: 5.2.2
> Dropping non PT_LOAD segment  
This is dropping the note segment.

> New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc
> (cleaned up) New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc

The segment is initially read from the rom fine.
 
> Loading Segment: addr: 0x0000000005f81028 memsz: 0x000000000000efc0 filesz: 0x0c
> Clearing Segment: addr: 0x0000000005f86ae4 memsz: 0x0000000000009504

The segment has been corrupted in processing.  So somewhere
between the call to build_elf_segment_list and load_elf_segment
the list has gotten corrupted.

My hunch it is just a coincidence that a new etherboot triggered this
problem.

> Jumping to boot code at 0x20000
> ROM segment 0x0001 length 0x0000 reloc 0x00020000

Take a look at the values in the segment list in elfboot.c and see
if you can track down how it is getting corrupted.  My hunch says it is
most likely a mis setup of your DRAM controller.

Eric


From linuxbios at xdr.com  Tue Jan  6 16:42:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Tue Jan  6 16:42:00 2004
Subject: Trouble with etherboot-5.2.2
Message-ID: <200401062149.i06LnmXa014480@xdr.com>

Eric wrote:

>Take a look at the values in the segment list in elfboot.c and see
>if you can track down how it is getting corrupted.  My hunch says it is
>most likely a mis setup of your DRAM controller.

I've tracked the problem to the function get_bounce_buffer in
src/lib/elfboot.c, it is returning 5f646e8 for some reason. I added
some printk's to that function and get this:

zzz mem_entries = 3, lb_size=9b918
zzz 1: mstart=6a8, msize=9f958, mend=a0000, tbuffer=46e8
zzz 2: mstart=100000, msize=5f00000, mend=6000000, tbuffer=5f646e8


Here is the debug output. I also changed printk_spew to printk_debug:

Found ELF candiate at offset 0
header_offset is 0
Try to load at offset 0x0
zzz mem_entries = 3, lb_size=9b918
zzz 1: mstart=6a8, msize=9f958, mend=a0000, tbuffer=46e8
zzz 2: mstart=100000, msize=5f00000, mend=6000000, tbuffer=5f646e8
n_type: 00000001 n_name(8): ELFBoot  n_desc(10): Etherboot 
n_type: 00000002 n_name(8): ELFBoot  n_desc(6): 5.2.2 
Loading Etherboot version: 5.2.2
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc
(cleaned up) New segment addr 0x20000 size 0xefc0 offset 0xb0 filesize 0x5abc
lb: [0x0000000000004000, 0x0000000000051c8c)
segment: [0x0000000000020000, 0x0000000000025abc, 0x000000000002efc0)
 buffer=5f646e8, seg->s_addr=20000, lb_start=4000
 bounce: [0x0000000005f806e8, 0x0000000005f861a4, 0x0000000005f8f6a8)
Loading Segment: addr: 0x0000000005f806e8 memsz: 0x000000000000efc0 filesz: 0x0c
[ 0x0000000005f806e8, 0000000005f861a4, 0x0000000005f8f6a8) <- 00000000000000b0
Clearing Segment: addr: 0x0000000005f861a4 memsz: 0x0000000000009504
Loaded segments
verified segments
closed down stream
Jumping to boot code at 0x20000
ROM segment 0x0004 length 0x0000 reloc 0x00020000


Here is the same debug output but with the 5.0.10 etherboot payload:
Found ELF candiate at offset 0
header_offset is 0
Try to load at offset 0x0
zzz mem_entries = 3, lb_size=9b918
zzz 1: mstart=6a8, msize=9f958, mend=a0000, tbuffer=46e8
zzz 2: mstart=100000, msize=5f00000, mend=6000000, tbuffer=5f646e8
New segment addr 0x94000 size 0x6f68 offset 0x60 filesize 0x3460
(cleaned up) New segment addr 0x94000 size 0x6f68 offset 0x60 filesize 0x3460
lb: [0x0000000000004000, 0x0000000000051c8c)
Loading Segment: addr: 0x0000000000094000 memsz: 0x0000000000006f68 filesz: 0x00
[ 0x0000000000094000, 0000000000097460, 0x000000000009af68) <- 0000000000000060
Clearing Segment: addr: 0x0000000000097460 memsz: 0x0000000000003b08
Loaded segments
verified segments
closed down stream
Jumping to boot code at 0x94000
ROM segment 0x0004 length 0x0000 reloc 0x9400
Etherboot 5.0.10 (GPL) ELF for [VIA 86C100]



The 5.2.2 elf file exercises more of the elfboot.c. The bounce buffer should
be in valid memory, there is 128M total minus 32M for video, which now that
I think about it is way more than we need. So 0x6000000 total memory.

I'll keep digging...

-Dave



From ebiederman at lnxi.com  Tue Jan  6 17:18:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jan  6 17:18:00 2004
Subject: Trouble with etherboot-5.2.2
In-Reply-To: <200401062149.i06LnmXa014480@xdr.com>
References: <200401062149.i06LnmXa014480@xdr.com>
Message-ID: <m3fzesu33g.fsf@maxwell.lnxi.com>

Dave Ashley <linuxbios at xdr.com> writes:

> Eric wrote:
> 
> >Take a look at the values in the segment list in elfboot.c and see
> >if you can track down how it is getting corrupted.  My hunch says it is
> >most likely a mis setup of your DRAM controller.
> 
> I've tracked the problem to the function get_bounce_buffer in
> src/lib/elfboot.c, it is returning 5f646e8 for some reason. I added
> some printk's to that function and get this:
> 
> zzz mem_entries = 3, lb_size=9b918
> zzz 1: mstart=6a8, msize=9f958, mend=a0000, tbuffer=46e8
> zzz 2: mstart=100000, msize=5f00000, mend=6000000, tbuffer=5f646e8

Duh. Etherboot is wanting the same addresses that linuxBIOS is using,
so I allocate a bounce buffer at the top of memory.  

> The 5.2.2 elf file exercises more of the elfboot.c. The bounce buffer should
> be in valid memory, there is 128M total minus 32M for video, which now that
> I think about it is way more than we need. So 0x6000000 total memory.

On my box that address does not trigger the bounce buffer code.  But
I know I tested it ages ago when I added it.

So either there is a bug in the bounce buffer code, or
in the hand off to etherboot.

Easy things to try.
1) load the new etherboot with the old etherboot, over the network.
   That should confirm that the code actually works.
2) Play with RELOCADDR in etherboot so we don't trigger the bounce
   buffer case.

Eric


From adam at megacz.com  Wed Jan  7 01:50:01 2004
From: adam at megacz.com (Adam Megacz)
Date: Wed Jan  7 01:50:01 2004
Subject: Source code control
In-Reply-To: ebiederman@lnxi.com's message of "06 Jan 2004 10:03:31 -0700"
References: <1073395067.3ffab57bcfe73@webmail.unizar.es> <m3oethqaak.fsf@maxwell.lnxi.com>
Message-ID: <E1Ae7fX-0003oF-00@megacz.com>

ebiederman at lnxi.com (Eric W. Biederman) writes:
> > Nobody talked about subversion in this thread, and I'm not sure why... 

> It's not distributed.  Multiple repositories are hard.
> LinuxBIOS development is inherently distributed, and needs
> multiple repositories.

It also depends on a ton of other software being installed to make it
work (Apache, WebDAV, etc), or at least it did last time I evaluated
it.  The beauty of next-gen systems like arch and darcs is that any
http server, ftp server, or ssh-able machine can be a repo.

  - a


From mort1arn at online.no  Wed Jan  7 04:42:00 2004
From: mort1arn at online.no (Morten Arnesen)
Date: Wed Jan  7 04:42:00 2004
Subject: support for msi mb's?
Message-ID: <3FFBD612.2090407@online.no>

i couldn't figure out whether there are support for msi mobos, could 
anyone of u tell me so?

i'm very interesting in using linuxbios if it's possible on my 
msi-kt7-pro2 ver 1 this is a motherboard with an amibios on.
-- 
Morten Arnesen, Dyrkorn 6250 Stordal tlf: +47 7027 7036, fax: +47 70 27 
82 77
for ? svare p? mail, fjern det ?penbare i mailadressen. (gjelder news)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



From linuxbios at xdr.com  Wed Jan  7 10:05:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Wed Jan  7 10:05:01 2004
Subject: Trouble with etherboot-5.2.2
Message-ID: <200401071512.i07FCO06017416@xdr.com>

Eric wrote:

>Easy things to try.
>1) load the new etherboot with the old etherboot, over the network.
>   That should confirm that the code actually works.
>2) Play with RELOCADDR in etherboot so we don't trigger the bounce
>   buffer case.

I tried #2 first, I put RELOCADDR=0x80000 and that didn't trigger the bounce
code but it still locked up. Then I tried #1 where I serve the via-rhine.elf
file from 5.2.2 to etherboot 5.0.10. I get this:
Searching for server (BOOTP)...
.Me: 172.30.6.71, Server: 172.30.6.100, Gateway 172.30.6.254
Loading 172.30.6.100:via_rhine_elf ...(ELF)... ................done
rhine disable
ROM segment 0x0001 length 0x0000 reloc 0x00020000

This is a lot easier to experiment with since I don't have to burn bootroms.
I'll keep working on it. All I'm trying to get is some sign of life from
etherboot 5.2.2 that it loaded correctly.

Thanks--
Dave


From linuxbios at xdr.com  Wed Jan  7 10:19:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Wed Jan  7 10:19:01 2004
Subject: Trouble with etherboot-5.2.2
Message-ID: <200401071526.i07FQZ3Q017458@xdr.com>

I wrote:

>...
>rhine disable
>ROM segment 0x0001 length 0x0000 reloc 0x00020000

Ok, this message "ROM segment..." is coming from the new etherboot 5.2.2,
so it looks like linuxbios is out of the picture. I'll start going on a
printf fest and see where it is failing in etherboot.

Eric: Thanks for the idea of doing it this way, it speeds up development a
lot, having last known good load the new etherboot. Now the cycle is
compile, copy file, reset machine, see what I got, instead of
compile, copyfile to box, enter box, flash bootrom, reboot, see what I got,
   switch to safe bootrom, reboot.

-Dave


From rminnich at lanl.gov  Wed Jan  7 10:49:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan  7 10:49:00 2004
Subject: support for msi mb's?
In-Reply-To: <3FFBD612.2090407@online.no>
Message-ID: <Pine.LNX.4.44.0401070856090.8646-100000@maxroach.lanl.gov>

what is the chipset? 

BTW, your message was rejected as spam by several filters ...

ron



From linuxbios at xdr.com  Wed Jan  7 11:02:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Wed Jan  7 11:02:01 2004
Subject: Trouble with etherboot-5.2.2 [resolution]
Message-ID: <200401071610.i07GA70k017560@xdr.com>

The problem turned out to be I didn't build etherboot 5.2.2 properly, in
addition to editing the src/Config file I had to edit
arch/i386/Config and switch to the CFLAGS+= relating to linuxbios.
In etherboot 5.0.10 the only config file (that I know of) is the src/Config
one.

I did try reading the docs, but there was very little mention of linuxbios
in the etherboot docs. This whole thing could have been avoided if
etherboot had a top level README.Linuxbios or something like that.

The whole point of this exercise was to be able to get etherboot to output
to the vga even without a normal pc bios. I tried the CONSOLE_DIRECT_VGA
option Eric mentioned, and it works as needed.

There is still an issue with my epia-m vga init code that doesn't set the
sync for composite/svideo properly. That means in order to view the output
of etherboot you've got to plug in a vga monitor, which we want to avoid.
The epia-m vga init code sometimes detects that a monitor is plugged into
composite/svideo and automatically switches to the appropriate sync, but this
appears somewhat random.

-Dave


From rminnich at lanl.gov  Wed Jan  7 11:07:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan  7 11:07:00 2004
Subject: Trouble with etherboot-5.2.2 [resolution] [PMX:#]
In-Reply-To: <200401071610.i07GA70k017560@xdr.com>
Message-ID: <Pine.LNX.4.44.0401070913130.8646-100000@maxroach.lanl.gov>

Dave, could you send me those two config files? I can try to write the 
top-level doco if you want.

ron



From linuxbios at xdr.com  Wed Jan  7 12:28:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Wed Jan  7 12:28:00 2004
Subject: Trouble with etherboot-5.2.2
Message-ID: <200401071735.i07HZNte017804@xdr.com>

Ron wrote:

>Dave, could you send me those two config files? I can try to write the
>top-level doco if you want.

Here is a diff of the 2 config files I changed. My changes are pretty
trivial, and the comments in the Config files explain everything.

-Dave


diff -Nur etherboot-5.2.2/src/Config /ram/etherboot-5.2.2/src/Config
--- etherboot-5.2.2/src/Config  2003-10-04 18:00:54.000000000 -0700
+++ /ram/etherboot-5.2.2/src/Config     2004-01-07 07:55:33.000000000 -0800
@@ -241,7 +241,7 @@
 CFLAGS+=       -DCONFIG_PCI -DCONFIG_ISA
 
 # For prompting and default on timeout
-CFLAGS+=       -DASK_BOOT=3 -DBOOT_FIRST=BOOT_NIC
+CFLAGS+=       -DASK_BOOT=0 -DBOOT_FIRST=BOOT_NIC
 # If you would like to attempt to boot from other devices as well as the network.
 # CFLAGS+=     -DBOOT_SECOND=BOOT_FLOPPY
 # CFLAGS+=     -DBOOT_THIRD=BOOT_DISK
@@ -275,7 +275,7 @@
 
 # Limit the delay on packet loss/congestion to a more bearable value. See
 # description above.  If unset, do not limit the delay between resend.
-CFLAGS+=       -DBACKOFF_LIMIT=7 -DCONGESTED
+CFLAGS+=       -DBACKOFF_LIMIT=2 -DCONGESTED
 
 # More optional features
 # CFLAGS+=     -DCAN_BOOT_DISK -DTRY_FLOPPY_FIRST=4
@@ -283,9 +283,13 @@
 # For a serial console, which can run in parallel with FIRMWARE console
 # CFLAGS+=     -DCONSOLE_DUAL -DCOMCONSOLE=0x3F8 -DCONSPEED=9600
 
+CFLAGS += -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 -DCONSPEED=115200
+
+CFLAGS+= -DCONSOLE_DIRECT_VGA
+
 # Enable tagged image, generic ELF, Multiboot ELF
 # or FreeBSD ELF/a.out boot image support
-CFLAGS+=       -DTAGGED_IMAGE -DELF_IMAGE
+CFLAGS+=       -DELF_IMAGE
 # CFLAGS+=     -DAOUT_IMAGE -DIMAGE_MULTIBOOT -DIMAGE_FREEBSD
 # CFLAGS+=     -DAOUT_IMAGE -DAOUT_LYNX_KDI
 
diff -Nur etherboot-5.2.2/src/arch/i386/Config /ram/etherboot-5.2.2/src/arch/i386/Config
--- etherboot-5.2.2/src/arch/i386/Config        2003-08-01 20:00:16.000000000 -0700
+++ /ram/etherboot-5.2.2/src/arch/i386/Config   2004-01-07 07:35:19.000000000 -0800
@@ -79,13 +79,13 @@
 # @/OptionDescription@
 
 # BIOS select don't change unless you know what you are doing
-CFLAGS+=       -DPCBIOS
+#CFLAGS+=      -DPCBIOS
 
 # Compile in k8/hammer support
 #CFLAGS+= -DCONFIG_X86_64
 
 # Options to make a version of Etherboot that will work under linuxBIOS.
-#CFLAGS+= -DLINUXBIOS -DCONFIG_TSC_CURRTICKS  -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE 
+CFLAGS+= -DLINUXBIOS -DCONFIG_TSC_CURRTICKS  -DCONSOLE_SERIAL -DCOMCONSOLE=0x3f8 -DCOMPRESERVE -DCONFIG_PCI_DIRECT -DELF_IMAGE 
 
 # These options affect the loader that is prepended to the Etherboot image
 LCONFIG+=      -DMOVEROM


From ebiederman at lnxi.com  Thu Jan  8 05:08:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan  8 05:08:00 2004
Subject: Parallel port - LinuxBIOS
In-Reply-To: <Sea1-F1095k1Ed28kIN00001e39@hotmail.com>
References: <Sea1-F1095k1Ed28kIN00001e39@hotmail.com>
Message-ID: <m3y8sieofj.fsf@maxwell.lnxi.com>

"wora list" <kojinx at hotmail.com> writes:

> Hello everybody,
> 
>         I have a problem with linuxBIOS for using parallel port in bios. My
> project doesnot want to boot Linux but want to use mainboard to control
> something by Serial,Parallel port or USB , PS/2 later
> But now i have a problem for parallel port (My motherboard is EPIA mini-ITX) via
> 
> 8231 is SIO controller , i want to send data directly from bios to led
> board. But i don't know howto wirte some code for do this ,and  i can't find
> address 0x378 for parallel port ... If your have some suggession ,please reply
> me.

Pleas ask on the LinuxBIOS list.
 
>        I added this code but nothing happen
>               http://www.mikrosol.de/southbridge.diff
>               http://www.mikrosol.de/setup_serial.diff
> 
>                                                                       Thank you.
> 
> 
>                                                                        Best
> regards,
> 
>                                                                        Kojinx
> (LinuxBIOS user)

Eric


From s4310376 at hotmail.com  Thu Jan  8 11:38:00 2004
From: s4310376 at hotmail.com (worachet lirtsuttikul)
Date: Thu Jan  8 11:38:00 2004
Subject: Epia mini-itx parallel port
Message-ID: <BAY7-F101GMKRw3nWGb00017cdf@hotmail.com>

Hi , ALL

      How can i enable or set address to use parallel port in bios. I wanna 
send some data to show in LED (or 7-segment display) from BIOS when computer 
booting up. Please suggest me. Thank a lot.
                                                                             
                        Best Regard,
                                                                             
                           Kojinx

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus



From rminnich at lanl.gov  Thu Jan  8 12:06:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan  8 12:06:00 2004
Subject: Epia mini-itx parallel port
In-Reply-To: <BAY7-F101GMKRw3nWGb00017cdf@hotmail.com>
Message-ID: <Pine.LNX.4.44.0401081013520.22691-100000@maxroach.lanl.gov>

On Thu, 8 Jan 2004, worachet lirtsuttikul wrote:

>       How can i enable or set address to use parallel port in bios. I wanna 
> send some data to show in LED (or 7-segment display) from BIOS when computer 
> booting up. Please suggest me. Thank a lot.

do you mean from linuxbios?

ron



From rminnich at lanl.gov  Thu Jan  8 12:15:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan  8 12:15:00 2004
Subject: K8 northbridge f1 behaviour.
Message-ID: <Pine.LNX.4.44.0401081014280.22691-100000@maxroach.lanl.gov>

(note: c0.b means byte at register c0, and c0.l means 32-bits at c0. this 
is the 'setpci' command nomenclature)

I'm seeing something on Function 1 on K8 that I don't understand. 

Consider config. register c0.b. That register, if set to 0x33, enables ISA
and legacy VGA ports to the link defined in register c4.l (i.e. dest
node/dest link). In the case of the s2885, and a vga card in the pci33
slot, the pair c0.l and c4.l set up legacy vga to go to HT link #2, and
c0.b is set to 0x33.

What I don't understand is this: if, after booting, I use setpci to set
c0.b to 0, the system as a whole continues to work fine. If I set c0.l AND
c4.l to 0, then the system works. I would expect the system to die as I/O 
no longer would be routed to HT link #2. 

What am I missing? This is a system booted nosmp, so all I/O should be 
going through cpu 0 and 0:18.1 settings should control I/O. Is there some 
'magic' to make these settings really set into the chip? 

I've run into this as we are trying to get vga to work under linuxbios
using the emulation code (freebios/util/vgabios/testbios). We have
actually got this code close to working on the normal bios, and have even
made an nvidia card come up correctly in the agp slot, but we can't get
vga enables set up so that I/O to the legacy VGA ports works under
linuxbios.

Any hints would be gratefully accepted!

thanks

ron



From linuxbios at xdr.com  Thu Jan  8 12:39:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Thu Jan  8 12:39:01 2004
Subject: epia-m parallel port
Message-ID: <200401081746.i08HkVE6022609@xdr.com>

This may not answer the question (epia mini-itx parallel port) but it might
work anyway. In linuxbios V1 in the file
src/superio/via/vt1211/setup_serial.inc
you can add these lines to enable the parallel port. It defaults to 0x378
and IRQ 5 and DMA 2.
	/* Select parallel port */
	OUTPNPADDR($7)
	OUTPNPDATA($1)
	/* set the enable in reg. 0x30 to 00, SPP , 01 = ECP, 02 = EPP */
	OUTPNPADDR($0x30)
	OUTPNPDATA($0)

Put this before this line:
	/* turn off PnP */
	OUTPNPADDR($0xaa)

I just tried this on epia-m and it worked for me, I could see the parallel
port IO register space. YMMV.

-Dave


From rminnich at lanl.gov  Thu Jan  8 12:53:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan  8 12:53:00 2004
Subject: epia-m parallel port [PMX:#]
In-Reply-To: <200401081746.i08HkVE6022609@xdr.com>
Message-ID: <Pine.LNX.4.44.0401081100480.22691-100000@maxroach.lanl.gov>

Dave, can you send me the file with all your good fixes in it :-)

ron



From linuxbios at xdr.com  Thu Jan  8 12:59:00 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Thu Jan  8 12:59:00 2004
Subject: epia-m parallel port
Message-ID: <200401081807.i08I7LIV022718@xdr.com>

Ron wrote:
>Dave, can you send me the file with all your good fixes in it :-)

My linuxbios V1 src/superio/via/vt1211/setup_serial.inc is
this:
#define OUTIT(val, port) movb val, %al; \
	outb %al, port

#define OUTPNPADDR(val) OUTIT(val, $0x2e); OUTIT(val, $0xeb)
#define OUTPNPDATA(val) OUTIT(val, $0x2f); OUTIT(val, $0xeb)

/* to do: move this to a common include file! */
#define WRITESIOBYTE(register, value) movw register, %dx ;\
	movb	value, %al ;\
	outb	%al, %dx;\
	outb	%al, $0xeb;\
	outb	%al, $0xeb

#define WRITESIOWORD(register, value) movw register, %dx ;\
	movw	value, %ax ;\
	outw	%ax, %dx;\
	outb	%al, $0xeb;\
	outb	%al, $0xeb

enable_serial:
	/* turn on PnP */
	OUTPNPADDR($0x87)
	OUTPNPADDR($0x87)

	/* Allow serial port 2 (ldn 3) pins to come out */
	OUTPNPADDR($0x27)
	OUTPNPDATA($00)

	/* select com1 */
	OUTPNPADDR($7)
	OUTPNPDATA($3)
	/* set the enable in reg. 0x30 */
	OUTPNPADDR($0x30)
	OUTPNPDATA($0x1)

	/* Serial Port 1 Base Address (FEh) */
	OUTPNPADDR($0x60)
	OUTPNPDATA($0xfe)
	/* Serial Port 1 IRQ (04h) */
	OUTPNPADDR($0x70)
	OUTPNPDATA($0x4)
	/* Serial Port 1 Control */
	OUTPNPADDR($0xf0)
	OUTPNPDATA($0x2)

	/* select com2 */
	OUTPNPADDR($7)
	OUTPNPDATA($2)
	/* set the enable in reg. 0x30 */
	OUTPNPADDR($0x30)
	OUTPNPDATA($0x1)

	/* Serial Port 2 Base Address (BEh) */
	OUTPNPADDR($0x60)
	OUTPNPDATA($0xbe)
	/* Serial Port 2 IRQ (03h) */
	OUTPNPADDR($0x70)
	OUTPNPDATA($0x3)
	/* Serial Port 2 Control */
	OUTPNPADDR($0xf0)
	OUTPNPDATA($0x2)

	/* Select parallel port */
	OUTPNPADDR($7)
	OUTPNPDATA($1)
	/* set the enable in reg. 0x30 to 00, SPP , 01 = ECP, 02 = EPP */
	OUTPNPADDR($0x30)
	OUTPNPDATA($0)

	/* turn off PnP */
	OUTPNPADDR($0xaa)

	/* all done that nonsense -- from here on it's standard pc80 */
	/* Enable DLAB to set baud rate. */
	WRITESIOBYTE($0x3fb, $0x80)
	/* Set Buad Rate Divisor = 1==> 115 kb */
	WRITESIOWORD($0x3f8, $0x1)
	/* now set no parity, one stop, 8 bits, disable DLAB */
	WRITESIOBYTE($0x3fb, $0x3)
	/* now turn on RTS, DTR */
	WRITESIOBYTE($0x3fc, $0x3)
	/* Enable interrupts */
	WRITESIOBYTE($0x3f9, $0xf)

	/* should be done. Dump a char for fun. */
	WRITESIOBYTE($0x3f8, $0x30)

	/* Enable DLAB to set baud rate. */
	WRITESIOBYTE($0x2fb, $0x80)
	/* Set Buad Rate Divisor = 1==> 115 kb */
	WRITESIOWORD($0x2f8, $0x1)
	/* now set no parity, one stop, 8 bits, disable DLAB */
	WRITESIOBYTE($0x2fb, $0x3)
	/* now turn on RTS, DTR */
	WRITESIOBYTE($0x2fc, $0x3)
	/* Enable interrupts */
	WRITESIOBYTE($0x2f9, $0xf)

	/* should be done. Dump a char for fun. */
	WRITESIOBYTE($0x2f8, $0x31)


From pmacv at telefonica.net  Thu Jan  8 14:30:00 2004
From: pmacv at telefonica.net (Pedro M.)
Date: Thu Jan  8 14:30:00 2004
Subject: Interesting links
Message-ID: <002301c3d61e$dfad8600$6369cb51@usuario>

You can see http://www.superant.com/cgi-bin/slencyclopedia.pl?USB and the same in http://www.wlug.org.nz/USB

Very interesting links like :

*http://linuxkey.biz/
*http://linuxmobile.sourceforge.net/
and
* http://linuxdocs.tuxfamily.org/flonix/index.php

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040108/8dcd8144/attachment.html>

From stepan at suse.de  Thu Jan  8 16:40:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Jan  8 16:40:01 2004
Subject: K8 northbridge f1 behaviour.
In-Reply-To: <Pine.LNX.4.44.0401081014280.22691-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401081014280.22691-100000@maxroach.lanl.gov>
Message-ID: <20040108214752.GB27199@suse.de>

* ron minnich <rminnich at lanl.gov> [040108 18:22]:
> What I don't understand is this: if, after booting, I use setpci to set
> c0.b to 0, the system as a whole continues to work fine. If I set c0.l AND
> c4.l to 0, then the system works. I would expect the system to die as I/O 
> no longer would be routed to HT link #2. 
> 
> What am I missing? This is a system booted nosmp, so all I/O should be 
> going through cpu 0 and 0:18.1 settings should control I/O. Is there some 
> 'magic' to make these settings really set into the chip? 
 
Do these registers maybe want an LDTSTOP_L or a reset asserted to become
significant? 

Are you sure your other operations do access the VGA ports at all and
don't operate on the graphics device directly?

> I've run into this as we are trying to get vga to work under linuxbios
> using the emulation code (freebios/util/vgabios/testbios). We have
> actually got this code close to working on the normal bios, and have even
> made an nvidia card come up correctly in the agp slot, but we can't get
> vga enables set up so that I/O to the legacy VGA ports works under
> linuxbios.
 
I got an S2880 up with VGA by using the ATI biosless patch for 2.4.x
done by some SGI guy. That is not really flexible, but it helped me to
see light for the first time in LinuxBIOS

Stefan

  
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From rminnich at lanl.gov  Thu Jan  8 17:03:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan  8 17:03:01 2004
Subject: K8 northbridge f1 behaviour.
In-Reply-To: <20040108214752.GB27199@suse.de>
Message-ID: <Pine.LNX.4.44.0401081505470.22691-100000@maxroach.lanl.gov>

On Thu, 8 Jan 2004, Stefan Reinauer wrote:

> Do these registers maybe want an LDTSTOP_L or a reset asserted to become
> significant? 

ouch. maybe.

> Are you sure your other operations do access the VGA ports at all and
> don't operate on the graphics device directly?

These are operations that access 0x3cc and other legacy vga stuff, and 
they're not getting to vga ...

> I got an S2880 up with VGA by using the ATI biosless patch for 2.4.x
> done by some SGI guy. That is not really flexible, but it helped me to
> see light for the first time in LinuxBIOS

The right solution. We're doing the wrong solution (running the VGA bios) 
because VGA people won't let us do the right solution.

ron



From YhLu at tyan.com  Thu Jan  8 17:24:00 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Jan  8 17:24:00 2004
Subject: =?GB2312?B?tPC4tDogSzggbm9ydGhicmlkZ2UgZjEgYmVoYXZpb3VyLg==?=
Message-ID: <3174569B9743D511922F00A0C943142303D8E6A6@TYANWEB>

Ron,

You need to set the REG in some special position. Because ht_scanbus, may
reset some regs according to it's scan result.

I think the best to use VGA is
1. LinuxBIOS init critical regs to make sure VGA can be used in Linux
kernel.
2. Linux Kernel does the special work to make use some acceleration function
works.
3. Let X Server no changes.

Regards

YH.

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?1?8? 14:11
???: Stefan Reinauer
??: linuxbios at clustermatic.org
??: Re: K8 northbridge f1 behaviour.

On Thu, 8 Jan 2004, Stefan Reinauer wrote:

> Do these registers maybe want an LDTSTOP_L or a reset asserted to become
> significant? 

ouch. maybe.

> Are you sure your other operations do access the VGA ports at all and
> don't operate on the graphics device directly?

These are operations that access 0x3cc and other legacy vga stuff, and 
they're not getting to vga ...

> I got an S2880 up with VGA by using the ATI biosless patch for 2.4.x
> done by some SGI guy. That is not really flexible, but it helped me to
> see light for the first time in LinuxBIOS

The right solution. We're doing the wrong solution (running the VGA bios) 
because VGA people won't let us do the right solution.

ron

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


From stepan at suse.de  Thu Jan  8 18:00:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Jan  8 18:00:01 2004
Subject: K8 northbridge f1 behaviour.
In-Reply-To: <Pine.LNX.4.44.0401081505470.22691-100000@maxroach.lanl.gov>
References: <20040108214752.GB27199@suse.de> <Pine.LNX.4.44.0401081505470.22691-100000@maxroach.lanl.gov>
Message-ID: <20040108230733.GA20971@suse.de>

* ron minnich <rminnich at lanl.gov> [040108 23:11]:

> > I got an S2880 up with VGA by using the ATI biosless patch for 2.4.x
> > done by some SGI guy. That is not really flexible, but it helped me to
> > see light for the first time in LinuxBIOS
> 
> The right solution. We're doing the wrong solution (running the VGA bios) 
> because VGA people won't let us do the right solution.

What VGA device are you using? The 2880 has the ATI Rage XL chip which
seems to be used in quite some AMD64 implementations.
I used this patch:
http://ftp.fi.muni.cz/pub/linux/sgi/people/ppopov/aty_nobiosinit.patch

Best regards,
  Stefan Reinauer
  
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From stepan at suse.de  Thu Jan  8 18:04:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Jan  8 18:04:01 2004
Subject: K8 northbridge f1 behaviour.
In-Reply-To: <Pine.LNX.4.44.0401081505470.22691-100000@maxroach.lanl.gov>
References: <20040108214752.GB27199@suse.de> <Pine.LNX.4.44.0401081505470.22691-100000@maxroach.lanl.gov>
Message-ID: <20040108231226.GB20971@suse.de>

* ron minnich <rminnich at lanl.gov> [040108 23:11]:
> > I got an S2880 up with VGA by using the ATI biosless patch for 2.4.x
> > done by some SGI guy. That is not really flexible, but it helped me to
> > see light for the first time in LinuxBIOS
> 
> The right solution. We're doing the wrong solution (running the VGA bios) 
> because VGA people won't let us do the right solution.

The right solution is actually to use FCode for device initialization.
;-) You don't really want another layer of graphics drivers next to
fbdev, X11, directfb, ggi/kgi, svgalib, and what they are called (even
though non really copes with the layer we are talking about)

As soon as I get a working Open Firmware PCI driver done for OpenBIOS, 
this is the way to go (at least for the few devices with FCode that 
don't do the Apple fake thingie)

  Stefan


From rminnich at lanl.gov  Thu Jan  8 18:31:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan  8 18:31:01 2004
Subject: K8 northbridge f1 behaviour.
In-Reply-To: <20040108230733.GA20971@suse.de>
Message-ID: <Pine.LNX.4.44.0401081638100.22691-100000@maxroach.lanl.gov>

On Fri, 9 Jan 2004, Stefan Reinauer wrote:

> What VGA device are you using? The 2880 has the ATI Rage XL chip which
> seems to be used in quite some AMD64 implementations.
> I used this patch:
> http://ftp.fi.muni.cz/pub/linux/sgi/people/ppopov/aty_nobiosinit.patch

many types, unfortunately.

ron



From ollie at lanl.gov  Thu Jan  8 18:32:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Jan  8 18:32:00 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?= K8 northbridge f1 behaviour.
In-Reply-To: <3174569B9743D511922F00A0C943142303D8E6A6@TYANWEB>
References: <3174569B9743D511922F00A0C943142303D8E6A6@TYANWEB>
Message-ID: <1073605168.13170.59.camel@exponential.lanl.gov>

On Thu, 2004-01-08 at 15:43, YhLu wrote:
> Ron,
> 
> You need to set the REG in some special position. Because ht_scanbus, may
> reset some regs according to it's scan result.
> 
> I think the best to use VGA is
> 1. LinuxBIOS init critical regs to make sure VGA can be used in Linux
> kernel.
> 2. Linux Kernel does the special work to make use some acceleration function
> works.
> 3. Let X Server no changes.
> 

YhLu,

We found that under normal bios, the AMD8151 is not present. Is there 
any bits to hide it ?

We have tried everything to forward VGAIO behind 8111 and 8151
bridges but fail. Do you know anything about it ?

Ollie




From rminnich at lanl.gov  Thu Jan  8 18:37:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan  8 18:37:01 2004
Subject: K8 northbridge f1 behaviour.
In-Reply-To: <20040108231226.GB20971@suse.de>
Message-ID: <Pine.LNX.4.44.0401081643570.22691-100000@maxroach.lanl.gov>

On Fri, 9 Jan 2004, Stefan Reinauer wrote:

> The right solution is actually to use FCode for device initialization.

it's right, but nobody puts fcode in their VGA bios AFAIK (or am I wrong).

Plus that FCode will probably want to get to 0x3cc :-(

ron



From ebiederman at lnxi.com  Thu Jan  8 23:42:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan  8 23:42:00 2004
Subject: K8 northbridge f1 behaviour.
In-Reply-To: <Pine.LNX.4.44.0401081014280.22691-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401081014280.22691-100000@maxroach.lanl.gov>
Message-ID: <m3wu81n2se.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> (note: c0.b means byte at register c0, and c0.l means 32-bits at c0. this 
> is the 'setpci' command nomenclature)
> 
> I'm seeing something on Function 1 on K8 that I don't understand. 
> 
> Consider config. register c0.b. That register, if set to 0x33, enables ISA
> and legacy VGA ports to the link defined in register c4.l (i.e. dest
> node/dest link). In the case of the s2885, and a vga card in the pci33
> slot, the pair c0.l and c4.l set up legacy vga to go to HT link #2, and
> c0.b is set to 0x33.
> 
> What I don't understand is this: if, after booting, I use setpci to set
> c0.b to 0, the system as a whole continues to work fine. If I set c0.l AND
> c4.l to 0, then the system works. I would expect the system to die as I/O 
> no longer would be routed to HT link #2. 
> 
> What am I missing? This is a system booted nosmp, so all I/O should be 
> going through cpu 0 and 0:18.1 settings should control I/O. Is there some 
> 'magic' to make these settings really set into the chip? 

For this kind of setting I don't think there is.
But you can't not route traffic on the Opteron.  If traffic is not
routed it goes out the default link.  Which is why my broken HT routing
and setup code worked for so long.
 
> I've run into this as we are trying to get vga to work under linuxbios
> using the emulation code (freebios/util/vgabios/testbios). We have
> actually got this code close to working on the normal bios, and have even
> made an nvidia card come up correctly in the agp slot, but we can't get
> vga enables set up so that I/O to the legacy VGA ports works under
> linuxbios.
> 
> Any hints would be gratefully accepted!

The generic code should already handle this properly. With some small
exceptions of non standard registers.

Eric


From ebiederman at lnxi.com  Thu Jan  8 23:52:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan  8 23:52:01 2004
Subject: ç­å¤: K8 northbridge f1 behaviour.
In-Reply-To: <1073605168.13170.59.camel@exponential.lanl.gov>
References: <3174569B9743D511922F00A0C943142303D8E6A6@TYANWEB>
	<1073605168.13170.59.camel@exponential.lanl.gov>
Message-ID: <m3r7y9n2c7.fsf@maxwell.lnxi.com>

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

> On Thu, 2004-01-08 at 15:43, YhLu wrote:
> > Ron,
> > 
> > You need to set the REG in some special position. Because ht_scanbus, may
> > reset some regs according to it's scan result.

I know the existing code when it was back in the freebios codebase and PCI
only handled this correctly, so it should be just a matter of a little bit
of debugging to get this to happen automatically if it does not already.

> > I think the best to use VGA is
> > 1. LinuxBIOS init critical regs to make sure VGA can be used in Linux
> > kernel.
> > 2. Linux Kernel does the special work to make use some acceleration function
> > works.
> > 3. Let X Server no changes.
> > 
> 
> YhLu,
> 
> We found that under normal bios, the AMD8151 is not present. Is there 
> any bits to hide it ?

Hmm.  This may because of how things are laid out.  
I wonder if there are driver issues when you put the 8151 on something
besides bus 0.

> We have tried everything to forward VGAIO behind 8111 and 8151
> bridges but fail. Do you know anything about it ?

That is very weird.  Besides the card not working what test
are you using to be certain you have failed?  Are you failing
to read/write an I/O register.

It occurs to me LinuxBIOS might be different enough in pci layout to
confuse the option ROM on your card.

Plus I think there are some special bits of AGP initialization that
we might not be doing.

Eric


From YhLu at tyan.com  Thu Jan  8 23:53:21 2004
From: YhLu at tyan.com (YhLu)
Date: Thu Jan  8 23:53:21 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogSzggbm9ydGhicmlkZ2UgZjEgYmVoYXZpb3Vy?=
	=?GB2312?B?Lg==?=
Message-ID: <3174569B9743D511922F00A0C943142303D8E715@TYANWEB>

Ollie,

Should only forward to 8151 only. For the AGP is on 8151.


>We found that under normal bios, the AMD8151 is not present. Is there 
>any bits to hide it ?

The under normal bios, you need to use the most update kernel or may be 2.4.
22 to see the 8151.


Regards

YH.

-----????-----
???: Li-Ta Lo [mailto:ollie at lanl.gov] 
????: 2004?1?8? 15:39
???: YhLu
??: ron minnich; Stefan Reinauer; linuxbios at clustermatic.org
??: Re: ??: K8 northbridge f1 behaviour.

On Thu, 2004-01-08 at 15:43, YhLu wrote:
> Ron,
> 
> You need to set the REG in some special position. Because ht_scanbus, may
> reset some regs according to it's scan result.
> 
> I think the best to use VGA is
> 1. LinuxBIOS init critical regs to make sure VGA can be used in Linux
> kernel.
> 2. Linux Kernel does the special work to make use some acceleration
function
> works.
> 3. Let X Server no changes.
> 

YhLu,

We found that under normal bios, the AMD8151 is not present. Is there 
any bits to hide it ?

We have tried everything to forward VGAIO behind 8111 and 8151
bridges but fail. Do you know anything about it ?

Ollie



From ebiederman at lnxi.com  Fri Jan  9 01:09:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Jan  9 01:09:00 2004
Subject: K8 northbridge f1 behaviour.
In-Reply-To: <Pine.LNX.4.44.0401081638100.22691-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401081638100.22691-100000@maxroach.lanl.gov>
Message-ID: <m3ad4xk5n5.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Fri, 9 Jan 2004, Stefan Reinauer wrote:
> 
> > What VGA device are you using? The 2880 has the ATI Rage XL chip which
> > seems to be used in quite some AMD64 implementations.
> > I used this patch:
> > http://ftp.fi.muni.cz/pub/linux/sgi/people/ppopov/aty_nobiosinit.patch
> 
> many types, unfortunately.

Just to clear up the conversation.  There are two distinct problems,
with two separate solutions.

1) Onboard video.   
   - We should be able to do this open source and very early.
     As generally these are not high end chips.

2) Video Card.
   - This will require running a PC Option ROM.


From stepan at suse.de  Fri Jan  9 05:48:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Fri Jan  9 05:48:01 2004
Subject: ????: ????: K8 northbridge f1 behaviour.
In-Reply-To: <3174569B9743D511922F00A0C943142303D8E715@TYANWEB>
References: <3174569B9743D511922F00A0C943142303D8E715@TYANWEB>
Message-ID: <20040109105624.GA9710@suse.de>

* YhLu <YhLu at tyan.com> [040109 06:12]:
> >We found that under normal bios, the AMD8151 is not present. Is there 
> >any bits to hide it ?
> 
> The under normal bios, you need to use the most update kernel or may be 2.4.
> 22 to see the 8151.
 
It's probably sitting on a peer bus? Maybe it needs an entry in the pirq
table, like bus one did? (just guessing)

  Stefan


From rminnich at lanl.gov  Fri Jan  9 10:15:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan  9 10:15:01 2004
Subject: K8 northbridge f1 behaviour.
In-Reply-To: <m3wu81n2se.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0401090821360.599-100000@maxroach.lanl.gov>

On 8 Jan 2004, Eric W. Biederman wrote:

> The generic code should already handle this properly. With some small
> exceptions of non standard registers.

the generic code works wonderfully well but does not set the vga enable 
bit. The fix is trivial but as a quick test I just hardwired the 0xc0 
register in the setup code and ... still no vga i/o happening to the vga 
card. Boy, this is driving me nuts :-)

ron



From rminnich at lanl.gov  Fri Jan  9 10:20:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan  9 10:20:00 2004
Subject: =?ISO-8859-1?Q?Re=3A_=E7=AD=E5=A4=3A_K8_northbridge_f1_behaviou?=
 =?ISO-8859-1?Q?r=2E?=
In-Reply-To: <m3r7y9n2c7.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0401090823030.599-100000@maxroach.lanl.gov>

On 8 Jan 2004, Eric W. Biederman wrote:

> That is very weird.  Besides the card not working what test
> are you using to be certain you have failed?  Are you failing
> to read/write an I/O register.

on "normal" bios, i/o to 0x3cc produces data. On linuxbios, i/o to 0x3cc 
always comes back as 0xff. 

Here is my understanding of the tyan s2885 layout: cpu0, link2, goes to 
the 8131, which has a tunnel to 8111, which drives pci. 

Under our linuxbios + hack, c0.b is 0x33. c4.l is set for link2. So VGA 
i/o should in  my view go out link2. 

the 8111 is the pci connection. register 3e.b in 8111 is set to 0xf, which 
should pass vga i/o to the pci bus. 

the vga card, using Ollie's 'userio' program, does not respond to byte 
accesses to 0x3cc or 0x3d4. Under normal bios, all these register settings 
are the same and ... the card responds. 

> It occurs to me LinuxBIOS might be different enough in pci layout to
> confuse the option ROM on your card.

no, I don't think that's it.

> Plus I think there are some special bits of AGP initialization that
> we might not be doing.

even on pci it won't work.

ron



From rminnich at lanl.gov  Fri Jan  9 10:21:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan  9 10:21:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogSzggbm9ydGhicmlkZ2UgZjEgYmVoYXZpb3Vy?=
 =?GB2312?B?Lg==?=
In-Reply-To: <3174569B9743D511922F00A0C943142303D8E715@TYANWEB>
Message-ID: <Pine.LNX.4.44.0401090828390.599-100000@maxroach.lanl.gov>

On Thu, 8 Jan 2004, YhLu wrote:

> >We found that under normal bios, the AMD8151 is not present. Is there 
> >any bits to hide it ?
> 
> The under normal bios, you need to use the most update kernel or may be 2.4.
> 22 to see the 8151.

this is 2.4.23. The 8151 is totally invisible, under normal bios, and 
totally visible, under linuxbios. Some trick in the hardware?

ron



From rminnich at lanl.gov  Fri Jan  9 10:23:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan  9 10:23:01 2004
Subject: K8 northbridge f1 behaviour.
In-Reply-To: <m3ad4xk5n5.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0401090830240.599-100000@maxroach.lanl.gov>

On 8 Jan 2004, Eric W. Biederman wrote:

> 
> 2) Video Card.
>    - This will require running a PC Option ROM.

and this is the one we're working on. 

ron



From rminnich at lanl.gov  Fri Jan  9 10:24:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan  9 10:24:00 2004
Subject: ????: ????: K8 northbridge f1 behaviour.
In-Reply-To: <20040109105624.GA9710@suse.de>
Message-ID: <Pine.LNX.4.44.0401090830580.599-100000@maxroach.lanl.gov>

On Fri, 9 Jan 2004, Stefan Reinauer wrote:

> * YhLu <YhLu at tyan.com> [040109 06:12]:
> > >We found that under normal bios, the AMD8151 is not present. Is there 
> > >any bits to hide it ?
> > 
> > The under normal bios, you need to use the most update kernel or may be 2.4.
> > 22 to see the 8151.
>  
> It's probably sitting on a peer bus? Maybe it needs an entry in the pirq
> table, like bus one did? (just guessing)

it's weirder than that. The AGP video card is visible but the bridge to it 
(8151) is not. So the card works, is accessible, but the bridge is 
invisible (in normal bios).

ron



From ollie at lanl.gov  Fri Jan  9 10:30:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Fri Jan  9 10:30:01 2004
Subject: =?UTF-8?Q?=E7=AD=94=E5=A4=8D=3A?=
	=?UTF-8?Q?_=E7=AD=94=E5=A4=8D=3A?= K8 northbridge f1 behaviour.
In-Reply-To: <3174569B9743D511922F00A0C943142303D8E715@TYANWEB>
References: <3174569B9743D511922F00A0C943142303D8E715@TYANWEB>
Message-ID: <1073662652.13170.63.camel@exponential.lanl.gov>

On Thu, 2004-01-08 at 22:12, YhLu wrote:
> Ollie,
> 
> Should only forward to 8151 only. For the AGP is on 8151.
> 
> 
> >We found that under normal bios, the AMD8151 is not present. Is there 
> >any bits to hide it ?
> 
> The under normal bios, you need to use the most update kernel or may be 2.4.
> 22 to see the 8151.
> 
> 

We used the same 2.4.23 kernel under normal and linuxbios. The 8151 is
not present with lspci when booted with normal bios.

What exactly is the peer bus stuff?

Ollie




From niki.waibel at newlogic.com  Fri Jan  9 11:57:00 2004
From: niki.waibel at newlogic.com (Niki Waibel)
Date: Fri Jan  9 11:57:00 2004
Subject: help me ...
In-Reply-To: <BAY2-F171jS5wF9hRcA00004a05@hotmail.com>
Message-ID: <200401091705.i09H5QUM001477@enterprise2.newlogic.at>

On 06-Jan-2004 Devi Priya wrote:
> Hi.
> Thanks.
> I want to have linuxbios, linux os and filesystem in my diskonchip 
> millennium.

EXACTLY what i would like to have as well.

> Mine is sc1200.

ok. i have an epia-m board.

> If I use linuxbios to which physical address 
> should the DOCM be mapped?

that depends how you want to boot the pc / the board.
and how you connect the DOC chip.
how is your doc connected right now?
has your DOC DIL pins? (mine has -- have attached a pic of it)

here are 3 hardware configs i know:
BTW: if anything below is wrong then pls correct me!
A)
you can replace the bios (software) in the bords bios chip.
you can reprogramm it with some linux tools and store linuxbios
in it. (have you already done that?)
that way the system boots with linuxbios.
that's very fast (< 3sec) -- at the end you have to load the linux
kernel. there are several ways to do that.
the standard way seems to be etherboot.
i could not get that working.
i use filo (http://te.to/~ts1/filo/).
that little thing can load the kernel from a disk with and
without a filesystem / with and without partitions / with and
without offset (of a disk or partition).
with filo you can also specify kernel parameters (root disk).
the root disk needs to have a filesystem.

afaik you can use filo to load the kernel from character
devices (DoC millennium). that is at least what the filo
developer sayed.

what i do currently, is, replacing the boards bios by linuxbios.
linuxbios is configured to use filo (as i sayed).
filo also resides in the bios chip.
filo loads the linux kernel from an ide disk (a compact flash card in my case).
the kernel loads its root disk (parameter from filo which is programmed in the
bios chip (with linuxbios)) from another part of the disk.
the root disk contains the linuxsystem i put together:
uclibc, busybox, tinylogin, openssl, zlib, openssh, iptables, freeswan. 

B)
my plan was to replace the bios chip compleately to have
no ide disk (no compactflash card). only this DoC millennium.
everything (as you've sayed:
> I want to have linuxbios, linux os and filesystem in my diskonchip 
> millennium.
) in the doc mill.
but somehow i could not use the flash memory in the DoC millenniums.
the chip itself was working (so all address mapping was ok), but i
could not access the 8MByte flash memory. i got a 2nd DoC Mill,
-> no success, same problem. so i bet it has sthg to to with the
bios socket/electrical problem...
ah -- my DoC mill is a DIP chip ... as you can see in the image.
my bios socket is a PLCC socket (epia-m). so i had to buy a
converter. -> pins have a 1 to 1 mapping!
that way i could plug the DoC directly into the bios socket.
i bet it should work that way, and it WILL work one day.

if done this way 3 another problem appear:
1) the DoC mill flash memory cannot be accessed directly.
the 8MByte flash does not fit into the 8KByte address space
of the DoC. but the DoC can map a 512 byte page into that
8KByte address space. --- after some initialisation of
registers in the DoC mill.
2) the memory of the board (epia-m in my case, sc1200 in your
case) has to be initialised as well to put the 512byte peaces
of the DoC into some large chunk of the boards memory.
3) you have to do 1) and 2) within 512byte (... or maybe 1024byte,
but i could never figure out that). that piece of code is usually
called IPL (initial probram loader). the reason for that is, that
when a PC boots it executes code in the BIOS -- the address
pins of the bios socket will be active. i know nothing
about the real mapping ... and i dont care. the DoC mill will
do a reset on power on. AND!!! it will map the first flash page
on TOP and on BOTTOM of its 8KByte address space!!! automatically.
but only the FIRST page (512byte). that is the reason why you
have to do 1) and 2) within 512bytes. the PC board will execute
its code from at that 512bytes.

C)
there are boards around in which you can plug the DoC chip in addition
to the bios. and afaik there are also PCI boards in which you can 
plug a DoC mill.

if you use the regular bios it checks some addresses
for "bios extentions". such sockets or pci boards map the DoC
millennium into such an address space.
afaik the DoC mill is shipped with such a bios extention program.
that code can install a filesystem and an additional "emulated"
drive (dont know the details). if there is no other disk in the
system it looks as you have a drive (windows/dos would call it C:)
plugged to your computer and it boot from that drive.

also grub seems to be able to act as such a loader (with patches?).

but, C) was not the way i wanted to go, and so i dont know much details.

> Is it that no filesystem is necessary with 
> linuxbios?

not for linuxbios.
the pc's bios does not have a filesystem either.
it is just some code which inits memory and other
pc components (serial port, pci bus, usb, ethernet, ...)
and does some checks on the hardware.

but after that you want to load an os.
and the os usually wants a root disk.
with a filesystem.

hope this helps, niki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x.jpg
Type: application/octet-stream
Size: 3393 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040109/d8eb213d/attachment.obj>

From rminnich at lanl.gov  Fri Jan  9 12:24:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan  9 12:24:01 2004
Subject: help me ...
In-Reply-To: <200401091705.i09H5QUM001477@enterprise2.newlogic.at>
Message-ID: <Pine.LNX.4.44.0401091030340.599-100000@maxroach.lanl.gov>

we did use the technoland sbc 710 with both a flash and a millenium, see 
http://www.linuxbios.org/developer/portguides/sbc710/index.html

for a writeup on that.

ron



From YhLu at tyan.com  Fri Jan  9 16:51:00 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jan  9 16:51:00 2004
Subject: =?GB2312?B?tPC4tDogtPC4tDogtPC4tDogSzggbm9ydGhicmlkZ2UgZjEgYmVo?=
	=?GB2312?B?YXZpb3VyLg==?=
Message-ID: <3174569B9743D511922F00A0C943142303D8E77E@TYANWEB>

I used 2.4.22 and CPU type is AMD64.

Actually I used Redhat 9 for AMD64 beta, and then compile the 2.4.22 in 64
bit mode. After that I can see the 8151.

YH

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?1?9? 7:29
???: YhLu
??: Li-Ta Lo; Stefan Reinauer; linuxbios at clustermatic.org
??: Re: ??: ??: K8 northbridge f1 behaviour.

On Thu, 8 Jan 2004, YhLu wrote:

> >We found that under normal bios, the AMD8151 is not present. Is there 
> >any bits to hide it ?
> 
> The under normal bios, you need to use the most update kernel or may be 2.
4.
> 22 to see the 8151.

this is 2.4.23. The 8151 is totally invisible, under normal bios, and 
totally visible, under linuxbios. Some trick in the hardware?

ron


From rminnich at lanl.gov  Fri Jan  9 17:27:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan  9 17:27:01 2004
Subject: Tyan S2885 + K8 + Nvidia GEForce FX 5600 + testbios: WORKS!
Message-ID: <Pine.LNX.4.44.0401091531090.599-100000@maxroach.lanl.gov>

We just brought up an AGP card using the freebios/util/vgabios/testbios 
code! It's an Nvidia and it works fine. 

I think the emulator path is going to work for linuxbios. There are still 
some sharp corners to round off but this is really exciting. This is as 
far as we have ever come with VGA support that will work safely and across 
all architectures. 

I will be putting a fix into the linuxbios resource code to deal with the
problems we encountered. It is a trivial fix. It is amazing how well the
resource setup code in V2 is working, however; bridges and things just
tend to get set up correctly. 

Anyway, just thought you'd all want to know.

ron



From YhLu at tyan.com  Fri Jan  9 17:31:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jan  9 17:31:01 2004
Subject: =?GB2312?B?tPC4tDogPz8/PzogPz8/PzogSzggbm9ydGhicmlkZ2UgZjEgYmVo?=
	=?GB2312?B?YXZpb3VyLg==?=
Message-ID: <3174569B9743D511922F00A0C943142303D8E78A@TYANWEB>

Ron,

It seems the s2885 code in CVS tree is out of date, please check code in my
tree.

The 8151 is in bus 1, and the AGP is in BUS2,
The 8131/8111 is in bus3

Regards

YH.

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?1?9? 7:32
???: Stefan Reinauer
??: YhLu; Li-Ta Lo; linuxbios at clustermatic.org
??: Re: ????: ????: K8 northbridge f1 behaviour.

On Fri, 9 Jan 2004, Stefan Reinauer wrote:

> * YhLu <YhLu at tyan.com> [040109 06:12]:
> > >We found that under normal bios, the AMD8151 is not present. Is there 
> > >any bits to hide it ?
> > 
> > The under normal bios, you need to use the most update kernel or may be
2.4.
> > 22 to see the 8151.
>  
> It's probably sitting on a peer bus? Maybe it needs an entry in the pirq
> table, like bus one did? (just guessing)

it's weirder than that. The AGP video card is visible but the bridge to it 
(8151) is not. So the card works, is accessible, but the bridge is 
invisible (in normal bios).

ron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: s2885.tar.bz2
Type: application/octet-stream
Size: 12561 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040109/a0d9dd68/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: S2885_1.1.5_normal_scan_clear_e0_before_scan_hard_reset_OK.zip
Type: application/octet-stream
Size: 9504 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040109/a0d9dd68/attachment-0001.obj>

From YhLu at tyan.com  Fri Jan  9 17:39:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jan  9 17:39:01 2004
Subject: =?GB2312?B?tPC4tDogVHlhbiBTMjg4NSArIEs4ICsgTnZpZGlhIEdFRm9yY2Ug?=
	=?GB2312?B?RlggNTYwMCArIHRlc3RiaW9zOiBXT1JLUyE=?=
Message-ID: <3174569B9743D511922F00A0C943142303D8E78B@TYANWEB>

Great, I would have a try.

So the vgabios will be in the tree. How about the util/testbios?

YH.

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?1?9? 14:35
???: linuxbios at clustermatic.org
??: Tyan S2885 + K8 + Nvidia GEForce FX 5600 + testbios: WORKS!


We just brought up an AGP card using the freebios/util/vgabios/testbios 
code! It's an Nvidia and it works fine. 

I think the emulator path is going to work for linuxbios. There are still 
some sharp corners to round off but this is really exciting. This is as 
far as we have ever come with VGA support that will work safely and across 
all architectures. 

I will be putting a fix into the linuxbios resource code to deal with the
problems we encountered. It is a trivial fix. It is amazing how well the
resource setup code in V2 is working, however; bridges and things just
tend to get set up correctly. 

Anyway, just thought you'd all want to know.

ron

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


From rminnich at lanl.gov  Fri Jan  9 17:43:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan  9 17:43:00 2004
Subject: =?GB2312?B?tPC4tDogPz8/PzogPz8/PzogSzggbm9ydGhicmlkZ2UgZjEgYmVo?=
 =?GB2312?B?YXZpb3VyLg==?=
In-Reply-To: <3174569B9743D511922F00A0C943142303D8E78A@TYANWEB>
Message-ID: <Pine.LNX.4.44.0401091550310.599-100000@maxroach.lanl.gov>

On Fri, 9 Jan 2004, YhLu wrote:

> It seems the s2885 code in CVS tree is out of date, please check code in my
> tree.
> 
> The 8151 is in bus 1, and the AGP is in BUS2,
> The 8131/8111 is in bus3
> 

weird, we are using your tree, or I though we were. 

ron



From rminnich at lanl.gov  Fri Jan  9 17:44:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan  9 17:44:01 2004
Subject: =?GB2312?B?tPC4tDogVHlhbiBTMjg4NSArIEs4ICsgTnZpZGlhIEdFRm9yY2Ug?=
 =?GB2312?B?RlggNTYwMCArIHRlc3RiaW9zOiBXT1JLUyE=?=
In-Reply-To: <3174569B9743D511922F00A0C943142303D8E78B@TYANWEB>
Message-ID: <Pine.LNX.4.44.0401091551310.599-100000@maxroach.lanl.gov>

On Fri, 9 Jan 2004, YhLu wrote:

> So the vgabios will be in the tree. How about the util/testbios?

it's going to move into the freebios2 tree as well.

ron



From stuge-linuxbios at cdy.org  Fri Jan  9 20:15:01 2004
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri Jan  9 20:15:01 2004
Subject: =?iso-8859-1?B?563lpA==?=
	=?iso-8859-1?Q?=3A?= K8 northbridge f1 behaviour.
In-Reply-To: <Pine.LNX.4.44.0401090823030.599-100000@maxroach.lanl.gov>
References: <m3r7y9n2c7.fsf@maxwell.lnxi.com> <Pine.LNX.4.44.0401090823030.599-100000@maxroach.lanl.gov>
Message-ID: <20040110012323.GD30556@foo.birdnet.se>

On Fri, Jan 09, 2004 at 08:27:55AM -0700, ron minnich wrote:

[..]

> the 8111 is the pci connection. register 3e.b in 8111 is set to 0xf, which 
> should pass vga i/o to the pci bus. 
> 
> the vga card, using Ollie's 'userio' program, does not respond to byte 
> accesses to 0x3cc or 0x3d4. Under normal bios, all these register settings 
> are the same and ... the card responds. 

It seems you've solved this now, according to the later success report.
Excellent news indeed! :)

I would've suggested a modified POST card or logic analyzer to see if the
writes made it to the bus. This is somewhat more of a LAN approach to
diagnostics, but might have helped anyway. LAN bridges also tend to just
make packets disappear mysteriously.

What was the problem, anyway?


//Peter


From rminnich at lanl.gov  Fri Jan  9 23:30:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan  9 23:30:01 2004
Subject: =?iso-8859-1?B?563lpA==?= =?iso-8859-1?Q?=3A?= K8 northbridge
 f1 behaviour.
In-Reply-To: <20040110012323.GD30556@foo.birdnet.se>
Message-ID: <Pine.LNX.4.44.0401092135410.6160-100000@maxroach.lanl.gov>

On Sat, 10 Jan 2004, Peter Stuge wrote:

> I would've suggested a modified POST card or logic analyzer to see if the
> writes made it to the bus. This is somewhat more of a LAN approach to
> diagnostics, but might have helped anyway. LAN bridges also tend to just
> make packets disappear mysteriously.

I finally found my VMETRO and put it in the slot and we were able to work 
it all out. 
> 
> What was the problem, anyway?

- incorrect setting of the pci i/o registers in the k8 northbridge (fix in 
	the works)
- the stupid vga cards don't respond to I/O in the legacy range until you 
	do a Magic Write to a Magic Place with Magic Data. The emulator 
	helped us figure this out since we can watch I/O 

But we're really a lot closer than we ever have been.

ron



From Phreak_show at gmx.de  Sat Jan 10 06:59:00 2004
From: Phreak_show at gmx.de (Stefan)
Date: Sat Jan 10 06:59:00 2004
Subject: GA-7DXR
In-Reply-To: <20040107.164252.-506793.0.tocats@juno.com>
References: <20040107.164252.-506793.0.tocats@juno.com>
Message-ID: <3FFFEB44.8010706@gmx.de>

HI Thomas,

I'm sorry, but I didn't manage to run LinuxBIOS on it, because the whole 
board crashed during a benchmark!

Thomas M Spear wrote:

>Hi -
>
>I found your msgs from last summer in the LinuxBios archive.  I have an
>almost identical board (seems like only the south bridge is different)
>that I want to use with LinuxBios.  Did you ever get your GA-7DXR working
>with LinuxBios?  If so would you please send me the files/scripts you
>used to create the ROM image.  Any info you can provide will be
>appreciated.
>
>Thanx.
>
>________________________________________________________________
>The best thing to hit the internet in years - Juno SpeedBand!
>Surf the web up to FIVE TIMES FASTER!
>Only $14.95/ month - visit www.juno.com to sign up today!
>
>
>  
>




From miernik at ctnet.pl  Sat Jan 10 07:18:00 2004
From: miernik at ctnet.pl (Miernik)
Date: Sat Jan 10 07:18:00 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
Message-ID: <20040110122559.GA19323@tarnica.ctnet.pl>

Maybe this will be a candidate for LinuxBIOS laptop:
http://www.linuxcertified.com/linux-laptop-lc2430.html

This laptop is probably produced by a Linux company (LC stands for 
Linux Certified I presume), so they might be interested in 
cooperation. It has been recently Debian certified.

The chipsets are:
http://www.linuxcertified.com/specs_lc2430.html
Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge

There are some datasheets for this here:
http://developer.intel.com/design/chipsets/845/

lspci optput is here:
http://www.linuxcertified.com/test-reports/lc2430-report/debian-info.epl.html

There has been one post on the LinuxBIOS list, from someone who says 
that he has done some Intel 845 work:
http://www.clustermatic.org/pipermail/linuxbios/2002-September/000239.html

-- 
JabberID:miernik at amessage.info



From pmacv at telefonica.net  Sat Jan 10 08:58:00 2004
From: pmacv at telefonica.net (Pedro M.)
Date: Sat Jan 10 08:58:00 2004
Subject: Wiki
Message-ID: <00db01c3d782$d8fee690$6369cb51@usuario>

I suggest create a Linux Bios Wiki ( like http://wikipedia.org ).

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

From stepan at suse.de  Sat Jan 10 14:53:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Sat Jan 10 14:53:01 2004
Subject: Wiki
In-Reply-To: <00db01c3d782$d8fee690$6369cb51@usuario>
References: <00db01c3d782$d8fee690$6369cb51@usuario>
Message-ID: <20040110200053.GA20257@suse.de>

* Pedro M. <pmacv at telefonica.net> [040110 15:05]:
> I suggest create a Linux Bios Wiki ( like http://wikipedia.org ).

I've set one up at http://www.openbios.org/linuxbioswiki/
(and another one http://www.openbios.org/openbioswiki/)

Feel free to fill it with contents ;-)
Please report problems or ideas to me...

If someone creates a dns entry for wiki.linuxbios.org or similar, 
I can give it an own virtual host on the machine..

  Stefan Reinauer
 
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From don at bowery.com  Sat Jan 10 18:16:00 2004
From: don at bowery.com (Don Elwell)
Date: Sat Jan 10 18:16:00 2004
Subject: Intel 845G/GL/GV... support
Message-ID: <4000887F.5010901@bowery.com>

Hello,

I saw a thread a couple of weeks ago regarding LinuxBIOS support for the 
Intel 845G/GL chipset.  I've noticed a bit of work in the freebios CVS 
tree done for the southbridge (ICH4 -- src/southbridge/intel/82801db/*) 
but none for the northbridge (82845G/GL/GV).  My question is who owns/is 
responsible for this port/code?  I'd like to contact them directly to 
see if I can help.

-don




From ted at php.net  Sat Jan 10 19:15:01 2004
From: ted at php.net (Ted Rolle)
Date: Sat Jan 10 19:15:01 2004
Subject: Configure script missing on linuxbios.org
Message-ID: <Pine.BSO.4.56.0401101821550.14120@maurizio.lytehouse.net>

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

I get this message when configuring a K7SEM config file:

The requested URL /cgi-bin/linuxbios/config.cgi was not found on this
server.

Ted
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (OpenBSD)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQFAAJedNVEzkt/Z5uIRAhLBAJ9AHwiy7a+u3gUWcj2fwy4rA8VbzgCfRL9e
8GGpfv/yCd1DoKNkDMsJ9f0=
=F4Ah
-----END PGP SIGNATURE-----


From admin at movingideasanimation.com  Sun Jan 11 00:37:01 2004
From: admin at movingideasanimation.com (Dylan D)
Date: Sun Jan 11 00:37:01 2004
Subject: DirectFB Minit-itx?
Message-ID: <019a01c3d806$2602b1a0$152ca8c0@dylan>

Hello, Im interested in a M1000 with the CLE266 tv-encoder(mpeg2)/Matrox G550 chipset for a PVR type applications id like to use Linuxbios to boot the system quicker, As well as boot directly into Tv-output through DirectFB.
DirectFB has support for calling Tv-output once booted, but I'd like to activate it during boot can this be done with linuxbios ?



Dylan D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040111/3adcf236/attachment.html>

From joshua at joshuawise.com  Sun Jan 11 02:29:01 2004
From: joshua at joshuawise.com (Joshua Wise)
Date: Sun Jan 11 02:29:01 2004
Subject: DirectFB Minit-itx?
In-Reply-To: <019a01c3d806$2602b1a0$152ca8c0@dylan>
References: <019a01c3d806$2602b1a0$152ca8c0@dylan>
Message-ID: <200401110238.54666.joshua@joshuawise.com>

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

On Sunday 11 January 2004 12:45 am, Dylan D wrote:
> Hello, Im interested in a M1000 with the CLE266 tv-encoder(mpeg2)/Matrox
> G550 chipset for a PVR type applications id like to use Linuxbios to boot
> the system quicker, As well as boot directly into Tv-output through
> DirectFB. DirectFB has support for calling Tv-output once booted, but I'd
> like to activate it during boot can this be done with linuxbios ?
At present, LinuxBIOS does very little VGA support of its own - certainly not 
advanced features like TV Out.

You could write the support to it if you wish, though, but I assume that would 
take quite a bit of code to initialize the card.

joshua

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

iD8DBQFAAP2OPn9tWOqA4LMRAuh2AKC0SjPWl0yQoyNdAm3OENbY6JwHuACgmRqr
1tHKA0QnkGJJUar8zzN1r4Y=
=9m7b
-----END PGP SIGNATURE-----



From jbors at mail.ru  Sun Jan 11 03:34:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Sun Jan 11 03:34:01 2004
Subject: DirectFB Minit-itx?
References: <019a01c3d806$2602b1a0$152ca8c0@dylan>
Message-ID: <046d01c3d81e$ca32a100$0300a8c0@amr.corp.intel.com>

Dylan,
What I noticed is that if you use legacy BIOS it may take little longer to boot( 5-7 secs more ), but it does your initialization cleaner and all of the devices works properly under Linux.
Anyways you can definitely get epia2 kernel which uses vgafb and pass TVon=1 at the boot time to turn on the video output.
http://www.courville.org/phpwiki/index.php/CLE266%20MPEG%20decoding
viafb works well when used as a module. For kernel non module build you may need additional patch. I have it if you wish.
Just out of curiosity. What encoder you're talking here ? Is it built in to EPIA board ? Can you send a link ?
Bors/
  ----- Original Message ----- 
  From: Dylan D 
  To: LinuxBIOS 
  Sent: Saturday, January 10, 2004 9:45 PM
  Subject: DirectFB Minit-itx?


  Hello, Im interested in a M1000 with the CLE266 tv-encoder(mpeg2)/Matrox G550 chipset for a PVR type applications id like to use Linuxbios to boot the system quicker, As well as boot directly into Tv-output through DirectFB.
  DirectFB has support for calling Tv-output once booted, but I'd like to activate it during boot can this be done with linuxbios ?



  Dylan D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040111/79eb3852/attachment.html>

From m.j.harvey at ucl.ac.uk  Sun Jan 11 08:58:00 2004
From: m.j.harvey at ucl.ac.uk (Matt Harvey)
Date: Sun Jan 11 08:58:00 2004
Subject: DIMM relocation on Tyan S2885
Message-ID: <1073829958.25376.715.camel@ohm.chem.ucl.ac.uk>

Hello,

I have an Opteron machine based on the Tyan K8W S2885 mainboard which is
equipped with 8GB of RAM (8x1GB DIMM). The BIOS is mapping  the PCI/AGP
devices into the address space immediately below 4GB and so
consequently, I am losing access to nearly an entire 1GB of RAM. I've
spoken to Tyan about this and they acknowledged that it it is principle
possible for the BIOS to remap the DIMM presently located at 3GB to 9GB
but that they have no intention of including this option in their BIOS
as it "penalizes 32-bit OS's that cannot use more than 4GB." 

So the question to the panel is: Will LinuxBIOS solve this problem for
me? The task this machine was purchased for really does require as much
RAM as possible.

Thanks in advance,

Matt Harvey

-- 
Matt Harvey                        E-mail: M.J.Harvey at ucl.ac.uk
RealityGrid Computing Officer      Tel:    +44 (0) 20 7679 5300
Centre for Computational Science   Mobile: +44 (0) 7947 735 036
Department of Chemistry
University College
University of London



From ebiederman at lnxi.com  Sun Jan 11 19:45:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Sun Jan 11 19:45:00 2004
Subject: DIMM relocation on Tyan S2885
In-Reply-To: <1073829958.25376.715.camel@ohm.chem.ucl.ac.uk>
References: <1073829958.25376.715.camel@ohm.chem.ucl.ac.uk>
Message-ID: <m3oetaj8b9.fsf@maxwell.lnxi.com>

Matt Harvey <m.j.harvey at ucl.ac.uk> writes:

> Hello,
> 
> I have an Opteron machine based on the Tyan K8W S2885 mainboard which is
> equipped with 8GB of RAM (8x1GB DIMM). The BIOS is mapping  the PCI/AGP
> devices into the address space immediately below 4GB and so
> consequently, I am losing access to nearly an entire 1GB of RAM. I've
> spoken to Tyan about this and they acknowledged that it it is principle
> possible for the BIOS to remap the DIMM presently located at 3GB to 9GB
> but that they have no intention of including this option in their BIOS
> as it "penalizes 32-bit OS's that cannot use more than 4GB." 
> 
> So the question to the panel is: Will LinuxBIOS solve this problem for
> me?  The task this machine was purchased for really does require as much
> RAM as possible.

At the present moment that is not implemented by LinuxBIOS.  It is
something I would like to work on, but it has not been a priority yet.
I think I could do it a day or two a week with testing etc.

There are a couple of ways LinuxBIOS could solve this problem.

1) You have the code so you can implement that, so you are not helpless.
2) You can wait until I get around to implementing for other reasons.
3) You can pay one of the vendors doing LinuxBIOS to fix it for you.
   <plug> Linux Networx </plug>

Eric


From rminnich at lanl.gov  Mon Jan 12 00:20:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 12 00:20:00 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <20040110122559.GA19323@tarnica.ctnet.pl>
Message-ID: <Pine.LNX.4.44.0401112227250.7765-100000@maxroach.lanl.gov>

On Sat, 10 Jan 2004, Miernik wrote:

> Maybe this will be a candidate for LinuxBIOS laptop:

I like it. I sure would like to find a company that want to work on this 
problem with us as partners. 

For anyone reading this list, our Big Goal this year is to get more 
companies involved in shipping systems running linuxbios out of the box. 
Laptops included. 

ron



From rminnich at lanl.gov  Mon Jan 12 00:21:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 12 00:21:00 2004
Subject: Wiki
In-Reply-To: <00db01c3d782$d8fee690$6369cb51@usuario>
Message-ID: <Pine.LNX.4.44.0401112228580.7765-100000@maxroach.lanl.gov>

On Sat, 10 Jan 2004, Pedro M. wrote:

> I suggest create a Linux Bios Wiki ( like http://wikipedia.org ).

we've thought about it, but it's a headache to do these things sometimes 
due to Wiki Vandals.

ron



From rminnich at lanl.gov  Mon Jan 12 00:28:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 12 00:28:01 2004
Subject: Wiki
In-Reply-To: <20040110200053.GA20257@suse.de>
Message-ID: <Pine.LNX.4.44.0401112236130.7765-100000@maxroach.lanl.gov>

On Sat, 10 Jan 2004, Stefan Reinauer wrote:

> If someone creates a dns entry for wiki.linuxbios.org or similar, 
> I can give it an own virtual host on the machine..

ok, we'll try to do that this week.

ron



From rminnich at lanl.gov  Mon Jan 12 00:30:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 12 00:30:00 2004
Subject: Intel 845G/GL/GV... support
In-Reply-To: <4000887F.5010901@bowery.com>
Message-ID: <Pine.LNX.4.44.0401112238360.7765-100000@maxroach.lanl.gov>

On Sat, 10 Jan 2004, Don Elwell wrote:

> I saw a thread a couple of weeks ago regarding LinuxBIOS support for the 
> Intel 845G/GL chipset.  I've noticed a bit of work in the freebios CVS 
> tree done for the southbridge (ICH4 -- src/southbridge/intel/82801db/*) 
> but none for the northbridge (82845G/GL/GV).  My question is who owns/is 
> responsible for this port/code?  I'd like to contact them directly to 
> see if I can help.

I think you just took ownership, but if you're going to do it, then work 
in freebios2 and do your code in C, not asm.

ron



From rminnich at lanl.gov  Mon Jan 12 00:31:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 12 00:31:01 2004
Subject: Configure script missing on linuxbios.org
In-Reply-To: <Pine.BSO.4.56.0401101821550.14120@maurizio.lytehouse.net>
Message-ID: <Pine.LNX.4.44.0401112239230.7765-100000@maxroach.lanl.gov>

On Sat, 10 Jan 2004, Ted Rolle wrote:

> The requested URL /cgi-bin/linuxbios/config.cgi was not found on this
> server.

sorry. I have to take that thing down, usage was almost zero and it did 
not help people as much as we hoped.

ron



From rminnich at lanl.gov  Mon Jan 12 00:34:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 12 00:34:01 2004
Subject: DIMM relocation on Tyan S2885
In-Reply-To: <1073829958.25376.715.camel@ohm.chem.ucl.ac.uk>
Message-ID: <Pine.LNX.4.44.0401112241450.7765-100000@maxroach.lanl.gov>

On Sun, 11 Jan 2004, Matt Harvey wrote:

> So the question to the panel is: Will LinuxBIOS solve this problem for
> me? The task this machine was purchased for really does require as much
> RAM as possible.

well, I think we can solve it for you. I have one of these boards, if you 
want to do the homework on how to do it I'll try to do it.

ron



From ebiederman at lnxi.com  Mon Jan 12 01:13:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jan 12 01:13:00 2004
Subject: DIMM relocation on Tyan S2885
In-Reply-To: <Pine.LNX.4.44.0401112241450.7765-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401112241450.7765-100000@maxroach.lanl.gov>
Message-ID: <m31xq5sn35.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Sun, 11 Jan 2004, Matt Harvey wrote:
> 
> > So the question to the panel is: Will LinuxBIOS solve this problem for
> > me? The task this machine was purchased for really does require as much
> > RAM as possible.
> 
> well, I think we can solve it for you. I have one of these boards, if you 
> want to do the homework on how to do it I'll try to do it.

There are a couple of ways to implement this.  If you have less than
4GB in one of the cpus you can put that cpu below 4G and the rest about.

Alternatively you can not enable dimm row interleaving, and create
a hole in a single cpus memory map, but putting the base address for
all but the first dimm rom about 4GB.  This looses a little performance
though.

And on the extreme side I think it would be possible to place all
of memory about 4GB and to use the GART to get a little of it to
appear below 4GB.  If this works there are still some very interesting
issues that crop up when the OS takes over the GART, and reprograms
it.

Eric


From prl at peterlister.co.uk  Mon Jan 12 05:20:00 2004
From: prl at peterlister.co.uk (Peter Lister)
Date: Mon Jan 12 05:20:00 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <Pine.LNX.4.44.0401112227250.7765-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401112227250.7765-100000@maxroach.lanl.gov>
Message-ID: <1073903293.4909.14777.camel@eddie>

On Mon, 2004-01-12 at 05:28, ron minnich wrote:#

> I like it. I sure would like to find a company that want to work on this 
> problem with us as partners. 
> 
> For anyone reading this list, our Big Goal this year is to get more 
> companies involved in shipping systems running linuxbios out of the box. 
> Laptops included.

Now that Linux (or BSD) friendly hardware is starting to appear, how far
are we from getting a fully open BIOS which, instead of being designed
for Windows and tolerant of Linux, is designed for Linux (and other open
source) and tolerant of Windows? 

Is anything being done with Adam + Adam's ADLO?

The latest news from the Etherboot front is a full on effort to add a
PXE environment to make replacement for the buggy proprietary NIC roms.
This is a big step towards open source something that hardware vendors
can use.





From dave at undone.org.uk  Mon Jan 12 09:22:01 2004
From: dave at undone.org.uk (Dave Reader)
Date: Mon Jan 12 09:22:01 2004
Subject: V2 EPIA compilation problem
Message-ID: <Pine.LNX.4.21.0401121430120.3861-100000@kinda.undone.org.uk>


Hi,

Having built V1 for epia, I wanted to try V2.

I'm hitting the following problem with romcc segfaulting when trying to
build.

The buildhost is Debian Stable on a P4 machine. I have upgraded binutils
to 2.14.90 & gcc to 3.3 in case the problem lie there, but i still have
this problem.

I've seperated out the gcc options show below for readability.

What am I doing wrong?

Thanks,
d.


dave at dr:~/LinuxBIOS/freebios2/targets/via/epia/epia$ make
if (cd normal; \
        make linuxbios.rom)\
then true; else exit 1; fi;
make[1]: Entering directory
`/home/dave/LinuxBIOS/freebios2/targets/via/epia/epia/normal'
cp /home/dave/LinuxBIOS/freebios2/src/arch/i386/config/crt0.base crt0.S
gcc-3.3 -no-gcc -x assembler-with-cpp 
 -DASSEMBLY -E
 -I/home/dave/LinuxBIOS/freebios2/src 
 -D__ROMCC__=0 
 -D__ROMCC_MINOR__=37
 -I/home/dave/LinuxBIOS/freebios2/src/include
 -I/home/dave/LinuxBIOS/freebios2/src/arch/i386/include
 -I/usr/lib/gcc-lib/i486-linux/3.3.3/include -DARCH='i386' -Di586='1'
 -Di686='1' 
 -DCPU_FIXUP='1' 
 -DCROSS_COMPILE 
 -DCC='gcc-3.3' 
 -DHOSTCC='gcc'
 -DOBJCOPY='objcopy' 
 -DLINUXBIOS_VERSION='1.1.5'
 -DLINUXBIOS_EXTRA_VERSION='.0Normal' 
 -DLINUXBIOS_BUILD='Mon Jan 12 14:23:13 GMT 2004'
 -DLINUXBIOS_COMPILE_TIME='14:23:13'
 -DLINUXBIOS_COMPILE_BY='dave' 
 -DLINUXBIOS_COMPILE_HOST='dr'
 -DLINUXBIOS_COMPILE_DOMAIN 
 -DLINUXBIOS_COMPILER='gcc version 3.3.3 20031206 (prerelease) (Debian SSP - skx at debian.org)'
 -DLINUXBIOS_LINKER='GNU ld version 2.14.90.0.7 20031029 Debian GNU/Linux'
 -DLINUXBIOS_ASSEMBLER='GNU assembler version 2.14.90.0.7 (i386-linux) using BFD version 2.14.90.0.7 20031029 Debian GNU/Linux'
 -DCONFIG_CHIP_CONFIGURE='1' 
 -DCONFIG_USE_INIT='0'
 -DHAVE_FALLBACK_BOOT='1'
 -DUSE_FALLBACK_IMAGE='0' 
 -DFALLBACK_SIZE='0x20000' 
 -DROM_SIZE='0x40000'
 -DROM_IMAGE_SIZE='0x10000' 
 -DROM_SECTION_SIZE='0x20000'
 -DROM_SECTION_OFFSET='0x20000' 
 -DPAYLOAD_SIZE='0x10000'
 -D_ROMBASE='0xffff0000' 
 -D_RESET='0xffff0000'
 -D_EXCEPTION_VECTORS='0xffff0100' 
 -DSTACK_SIZE='0x2000'
 -DHEAP_SIZE='0x4000' 
 -D_RAMBASE='0x4000' 
 -DXIP_ROM_BASE='0xffff0000'
 -DXIP_ROM_SIZE='0x10000' 
 -DCONFIG_COMPRESS='1' 
 -DCONFIG_UNCOMPRESSED='0'
 -DHAVE_OPTION_TABLE='1' 
 -DUSE_OPTION_TABLE='0'
 -DCRT0='/home/dave/LinuxBIOS/freebios2/src/arch/i386/config/crt0.base'
 -DDEBUG='1' 
 -DCONFIG_CONSOLE_VGA='0' 
 -DCONFIG_CONSOLE_LOGBUF='0'
 -DCONFIG_CONSOLE_SROM='0' 
 -DCONFIG_CONSOLE_SERIAL8250='1'
 -DDEFAULT_CONSOLE_LOGLEVEL='7' 
 -DMAXIMUM_CONSOLE_LOGLEVEL='7'
 -DTTYS0_BASE='0x3f8' 
 -DTTYS0_BAUD='19200' 
 -DTTYS0_LCS='0x3'
 -DMAINBOARD='/home/dave/LinuxBIOS/freebios2/src/mainboard/via/epia'
 -DMAINBOARD_PART_NUMBER='epia' 
 -DMAINBOARD_VENDOR='via'
 -DCONFIG_KEYBOARD='1' 
 -DCONFIG_LEGACY_VGABIOS='0' 
 -DCONFIG_SMP='0'
 -DCONFIG_MAX_CPUS='1' 
 -DCONFIG_MAX_PHYSICAL_CPUS='1'
 -DCONFIG_LOGICAL_CPUS='0' 
 -DHAVE_MP_TABLE='0' 
 -DCONFIG_IDE_STREAM='0'
 -DCONFIG_ROM_STREAM='1' 
 -DCONFIG_ROM_STREAM_START='0xfffe0000'
 -DHAVE_PIRQ_TABLE='1' 
 -DIRQ_SLOT_COUNT='5' 
 -DIDE_BOOT_DRIVE='0'
 -DIDE_OFFSET='0' 
 -DHAVE_HARD_RESET='1' 
 -DMAX_REBOOT_CNT='3'
 -DINTEL_PPRO_MTRR='1' 
 -DCONFIG_UDELAY_TSC='0' 
 -DFAKE_SPDROM='0'
/home/dave/LinuxBIOS/freebios2/src/mainboard/via/epia/auto.c > ./auto.E
gcc -g -Os -Wall -DVERSION='"0.37"' -DRELEASE_DATE='"21 October 2003"'
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c -o romcc
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:20: warning: #warning
"FIXME boundary cases with small types in larger registers"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:21: warning: #warning
"FIXME give clear error messages about unused variables"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:22: warning: #warning
"FIXME properly handle multi dimensional arrays"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:208: warning: #warning
"FIXME this assumes 32bit x86 is the destination"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:3679: warning: #warning
"FIXME multiple #elif and #else in an #if do not work properly"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:3782: warning: #warning
"FIXME macros with arguments not supported"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:3992: warning: #warning
"FIXME do not hardcode the include paths"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:4741: warning: #warning
"FIXME can I just cast all operands like this?"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:5018: warning: #warning
"CHECK_ME is this the right place to transform arrays to pointers?"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:7947: warning: #warning
"Extend relational exprs to work on more than arithmetic types"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:7990: warning: #warning
"Extend equality exprs to work on more than arithmetic types"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:8444: warning: #warning
"FIXME implement a more general excess branch elimination"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:9177: warning: #warning
"FIXME implement bitfields to reduce register usage"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:9639: warning: #warning
"FIXME more consistent initializer handling (where should eval_const_expr
go?"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:12902: warning: #warning
"FIXME is this O(N^2) algorithm bad?"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:13931: warning: #warning
"FIXME should this be a merge instead of a splice?"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:14481: warning: #warning
"WISHLIST visit just those blocks that need it *"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:14534: warning: #warning
"WISHLIST recalculate all affected instructions colors"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:14672: warning: #warning
"FIXME ignore cases that cannot be fixed (a definition followed by a use)"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:14708: warning: #warning
"FIXME should I call find_constrained_def here only if no previous
constrained def was found?"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:14752: warning: #warning
"WISHLIST implement live range splitting..."
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:15948: warning: #warning
"FIXME see if simplify does anything bad"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:16005: warning: #warning
"FIXME constant propogate through expressions with multiple left hand
sides"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:16069: warning: #warning
"FIXME do I need to do something here?"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:16605: warning: #warning
"WISHLIST implement single use constants (least possible register
pressure)"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:16606: warning: #warning
"WISHLIST implement induction variable elimination"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:16789: warning: #warning
"WISHLIST figure out how to use pinsrw and pextrw to better use extended
regs"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:17339: warning: #warning
"FIXME force types smaller (if legal) before I get here"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:19154: warning: #warning
"FIXME I have observed instructions between the test and branch
instructions"
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c: In function
`mask_uint':
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:4115: warning: left
shift count >= width of type
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c: At top level:
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:4126: warning: `short_type'
defined but not used
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:4138: warning: `void_func_type'
defined but not used
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:5829: warning: `bit_count'
defined but not used
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:6058: warning: `check_lhs'
defined but not used
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:9525: warning: `isdecl_specifier'
defined but not used
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:12775: warning: `unin_triple'
defined but not used
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:12784: warning: `unout_triple'
defined but not used
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:13828: warning: `different_colored'
defined but not used
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:14196: warning: `verify_graph_ins'
defined but not used
/home/dave/LinuxBIOS/freebios2/util/romcc/romcc.c:19443: warning: `print_tokens'
defined but not used
./romcc   -O -mcpu=c3 ./auto.E 
make[1]: *** [auto.inc] Segmentation fault
make[1]: *** Deleting file `auto.inc'
make[1]: Leaving directory
`/home/dave/LinuxBIOS/freebios2/targets/via/epia/epia/normal'
make: *** [normal-rom] Error 1
dave at dr:~/LinuxBIOS/freebios2/targets/via/epia/epia$ 





From rminnich at lanl.gov  Mon Jan 12 10:22:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 12 10:22:00 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <1073903293.4909.14777.camel@eddie>
Message-ID: <Pine.LNX.4.44.0401120829270.12252-100000@maxroach.lanl.gov>

On 12 Jan 2004, Peter Lister wrote:

> Now that Linux (or BSD) friendly hardware is starting to appear, how far
> are we from getting a fully open BIOS which, instead of being designed
> for Windows and tolerant of Linux, is designed for Linux (and other open
> source) and tolerant of Windows? 

not too far. Problem is getting company's interest up. We need more 
companies like Linux NetworX, Linux Labs, Tyan and so on out there. 

> Is anything being done with Adam + Adam's ADLO?

not sure.




From rsmith at bitworks.com  Mon Jan 12 13:09:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Mon Jan 12 13:09:01 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401091551310.599-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401091551310.599-100000@maxroach.lanl.gov>
Message-ID: <4002E491.80509@bitworks.com>

ron minnich wrote:

> On Fri, 9 Jan 2004, YhLu wrote:
>  
>>So the vgabios will be in the tree. How about the util/testbios?
> 
> it's going to move into the freebios2 tree as well.
> 

At the end of this week and next I'm going to start work on bringing up 
our new system that has ATI video chips.  The ADLO solution that worked 
for the Assiliant 68030's hangs on with the ATI bios.

So it looks like a good time to stop using ADLO and move to vgabios and 
see if I can make it work.  Currently I don't have the liberty of moving 
to freebios2 tree as I'd have to rewrite all the memory init stuff.

Can some kind soul give me or point me to info on what the current 
status is and what I going to need to do to get it all up?

-- 
Richard A. Smith
rsmith at bitworks.com




From rminnich at lanl.gov  Mon Jan 12 13:13:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 12 13:13:01 2004
Subject: vgabios use howto.
In-Reply-To: <4002E491.80509@bitworks.com>
Message-ID: <Pine.LNX.4.44.0401121120150.12252-100000@maxroach.lanl.gov>

On Mon, 12 Jan 2004, Richard Smith wrote:

> Can some kind soul give me or point me to info on what the current 
> status is and what I going to need to do to get it all up?

vgabios/testbios is currently a linux program, not built into linuxbios at
all.  That's the emulator. We want to make it a linuxbios device soon.

The vgabios support code will run a vgabios directly. It is built into 
linuxbios. 

Which one did you want?

ron



From YhLu at tyan.com  Mon Jan 12 13:40:01 2004
From: YhLu at tyan.com (YhLu)
Date: Mon Jan 12 13:40:01 2004
Subject: =?gb2312?B?tPC4tDogRElNTSByZWxvY2F0aW9uIG9uIFR5YW4gUzI4ODU=?=
Message-ID: <3174569B9743D511922F00A0C943142303D8E84B@TYANWEB>

After ron solve the VGA support on LinuxBIOS and We must make sure the
performance meet some degree, We can talk about remapping the AGP ram in to
some other range.

Regards

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?1?11? 21:42
???: Matt Harvey
??: linuxbios at clustermatic.org
??: Re: DIMM relocation on Tyan S2885

On Sun, 11 Jan 2004, Matt Harvey wrote:

> So the question to the panel is: Will LinuxBIOS solve this problem for
> me? The task this machine was purchased for really does require as much
> RAM as possible.

well, I think we can solve it for you. I have one of these boards, if you 
want to do the homework on how to do it I'll try to do it.

ron

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


From rsmith at bitworks.com  Mon Jan 12 14:21:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Mon Jan 12 14:21:01 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401121120150.12252-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401121120150.12252-100000@maxroach.lanl.gov>
Message-ID: <4002F596.3010708@bitworks.com>

ron minnich wrote:

> On Mon, 12 Jan 2004, Richard Smith wrote:
> 
> 
>>Can some kind soul give me or point me to info on what the current 
>>status is and what I going to need to do to get it all up?
> 
> 
> vgabios/testbios is currently a linux program, not built into linuxbios at
> all.  That's the emulator. We want to make it a linuxbios device soon.
> 
> The vgabios support code will run a vgabios directly. It is built into 
> linuxbios. 
> 
> Which one did you want?

I (and my customer) want to see the screen light up at boot so I guess I 
need the direct vgabios support.  I seem to remember trying to use it 
about 6 months ago but I never could get it to compile and since ADLO 
worked I didn't continue that path.  I'm using a 440BX chipset.

Does success under the emulator indicate the level of success for the 
direct support or are they totally different?  Will it be of use to boot 
the board up headless and run the emulator to see what happens?

-- 
Richard A. Smith
rsmith at bitworks.com




From rminnich at lanl.gov  Mon Jan 12 15:10:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 12 15:10:00 2004
Subject: vgabios use howto.
In-Reply-To: <4002F596.3010708@bitworks.com>
Message-ID: <Pine.LNX.4.44.0401121257270.1348-100000@maxroach.lanl.gov>

On Mon, 12 Jan 2004, Richard Smith wrote:

> I (and my customer) want to see the screen light up at boot so I guess I 
> need the direct vgabios support.  

well, maybe. I am also working to move the emulator to become a linuxbios 
component. For many reasons, this is much safer than just running the BIOS 
directly. 

But you do what that screen on boot so we will start pushing that harder. 

I could use your help on this, since we do get some problems with some 
cards. 

>Will it be of use to boot
> the board up headless and run the emulator to see what happens?

That would be the right way to start. 

I think in the long term the emulator is the way to go, and possibly in 
the short term too.

ron



From rsmith at bitworks.com  Mon Jan 12 15:39:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Mon Jan 12 15:39:01 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401121257270.1348-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401121257270.1348-100000@maxroach.lanl.gov>
Message-ID: <400307D6.1070307@bitworks.com>

ron minnich wrote:

> On Mon, 12 Jan 2004, Richard Smith wrote:

> component. For many reasons, this is much safer than just running the BIOS 
> directly. 
> 
> But you do what that screen on boot so we will start pushing that harder. 

Yeah.  This system is going to boot from a compact flash thats 
replaceable so if it gets hosed and won't boot then I need some sort of 
info on the screen to indicate failue rather than haveing to have a tech 
sent out to the site to connect up a serial console to determine the issue.

> I could use your help on this, since we do get some problems with some 
> cards. 
> 
> 
>>Will it be of use to boot
>>the board up headless and run the emulator to see what happens?
> 
> That would be the right way to start. 

Ok.  Is that in the stock freebios module or a seperate module?  Have 
you tested it compiling against uclibc?  I guess I can compile static to 
start with if I need to.

> I think in the long term the emulator is the way to go, and possibly in 
> the short term too.

How much work do you see coming to add the emulator into LB?

-- 
Richard A. Smith
rsmith at bitworks.com




From rminnich at lanl.gov  Mon Jan 12 16:01:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 12 16:01:01 2004
Subject: vgabios use howto.
In-Reply-To: <400307D6.1070307@bitworks.com>
Message-ID: <Pine.LNX.4.44.0401121408440.1348-100000@maxroach.lanl.gov>

On Mon, 12 Jan 2004, Richard Smith wrote:

> Yeah.  This system is going to boot from a compact flash thats 
> replaceable so if it gets hosed and won't boot then I need some sort of 
> info on the screen to indicate failue rather than haveing to have a tech 
> sent out to the site to connect up a serial console to determine the issue.

it's amazing how often this issue comes up. VGA is "special".

> Ok.  Is that in the stock freebios module or a seperate module?  Have 
> you tested it compiling against uclibc?  I guess I can compile static to 
> start with if I need to.

yes, the stock one in the freebios 1 tree.

> How much work do you see coming to add the emulator into LB?

not a lot. We'll see as we proceed. 

Your expertise would be invaluable in making sure it's working correctly, 
however.

ron



From rsmith at bitworks.com  Mon Jan 12 16:50:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Mon Jan 12 16:50:01 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401121408440.1348-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401121408440.1348-100000@maxroach.lanl.gov>
Message-ID: <40031878.20306@bitworks.com>

ron minnich wrote:

> 
>>How much work do you see coming to add the emulator into LB?
> 
> not a lot. We'll see as we proceed. 
> 
> Your expertise would be invaluable in making sure it's working correctly, 
> however.

Cool thanks.   BTW. I read your article in Linux Journal.  Good Job.  I 
also now a have a face to go with the name.

-- 
Richard A. Smith
rsmith at bitworks.com




From dwh at lanl.gov  Mon Jan 12 16:56:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Jan 12 16:56:00 2004
Subject: vgabios use howto.
In-Reply-To: <40031878.20306@bitworks.com>
Message-ID: <Pine.LNX.4.44.0401121503060.19779-100000@ccs-mail.lanl.gov>

Oh, that's nothing. check out the pics on the LinuxBIOS page: 
http://www.linuxbios.org/misc/index.html

On Mon, 12 Jan 2004, Richard Smith wrote:
> I also now a have a face to go with the name.
> 
> 



From ted at php.net  Mon Jan 12 17:21:01 2004
From: ted at php.net (Ted Rolle)
Date: Mon Jan 12 17:21:01 2004
Subject: Source for linux-2.4.7 SiS patch
Message-ID: <Pine.BSO.4.56.0401121628340.29935@maurizio.lytehouse.net>

Can someone tell me the location of the SiS patch for linux 2.4.7?
Or, if a later version of Linux is available, the patch to that one.

Ted


From dwh at lanl.gov  Mon Jan 12 17:40:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Jan 12 17:40:01 2004
Subject: Source for linux-2.4.7 SiS patch
In-Reply-To: <Pine.BSO.4.56.0401121628340.29935@maurizio.lytehouse.net>
Message-ID: <Pine.LNX.4.44.0401121546320.19779-100000@ccs-mail.lanl.gov>

Specifically, which patch are you looking for? Also, can you run lspci and 
copy+paste the output?

On Mon, 12 Jan 2004, Ted Rolle wrote:

> Can someone tell me the location of the SiS patch for linux 2.4.7?
> Or, if a later version of Linux is available, the patch to that one.
> 
> Ted
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From ted at php.net  Mon Jan 12 17:58:01 2004
From: ted at php.net (Ted Rolle)
Date: Mon Jan 12 17:58:01 2004
Subject: SiS Patch
Message-ID: <Pine.BSO.4.56.0401121659510.2946@maurizio.lytehouse.net>

The patch is linux-2.4.7-sis.patch from the K7SEM HOWTO.

I have a K7SEM board.

Here is the output from lspci:
root at marvel / # lspci
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
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.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:01.4 Multimedia audio controller: Silicon Integrated Systems [SiS] SiS
PCI Audio Accelerator (rev 02)
00:02.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual
PCI-to-PCI bridge (AGP)
00:09.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev
08)
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS630
GUI Accelerator+3D (rev 31)
r

Thanks for the quick reply!

Ted


From ollie at lanl.gov  Mon Jan 12 18:11:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Mon Jan 12 18:11:00 2004
Subject: SiS Patch
In-Reply-To: <Pine.BSO.4.56.0401121659510.2946@maurizio.lytehouse.net>
References: <Pine.BSO.4.56.0401121659510.2946@maurizio.lytehouse.net>
Message-ID: <1073949565.13170.82.camel@exponential.lanl.gov>

On Mon, 2004-01-12 at 16:08, Ted Rolle wrote:
> The patch is linux-2.4.7-sis.patch from the K7SEM HOWTO.
> 
> I have a K7SEM board.
> 

What exactly do you want to do ? 
The linux-2.4.7-sis.patch is in the freebios1 tree.

Ollie




From dwh at lanl.gov  Mon Jan 12 18:14:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Jan 12 18:14:00 2004
Subject: SiS Patch
In-Reply-To: <Pine.BSO.4.56.0401121659510.2946@maurizio.lytehouse.net>
Message-ID: <Pine.LNX.4.44.0401121620380.19779-100000@ccs-mail.lanl.gov>

The patches can be found here:
http://cvs.sourceforge.net/viewcvs.py/freebios/freebios/src/kernel_patches/

It appears that the patches work up to kernel version 2.4.19. You should 
also be aware that this mainboard is not (yet) supported under freebios2. 
Ollie's the expert on SiS (Check out your kernel's SiS drivers to see 
why). I'll let him answer any further inquiries :)

On Mon, 12 Jan 2004, Ted Rolle wrote:

> The patch is linux-2.4.7-sis.patch from the K7SEM HOWTO.
> 
> I have a K7SEM board.
> 
> Here is the output from lspci:
> root at marvel / # lspci
> 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02)
> 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.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:01.4 Multimedia audio controller: Silicon Integrated Systems [SiS] SiS
> PCI Audio Accelerator (rev 02)
> 00:02.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual
> PCI-to-PCI bridge (AGP)
> 00:09.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev
> 08)
> 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS630
> GUI Accelerator+3D (rev 31)
> r
> 
> Thanks for the quick reply!
> 
> Ted
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From ted at php.net  Mon Jan 12 18:16:01 2004
From: ted at php.net (Ted Rolle)
Date: Mon Jan 12 18:16:01 2004
Subject: SiS Patch
In-Reply-To: <1073949565.13170.82.camel@exponential.lanl.gov>
References: <Pine.BSO.4.56.0401121659510.2946@maurizio.lytehouse.net>
 <1073949565.13170.82.camel@exponential.lanl.gov>
Message-ID: <Pine.BSO.4.56.0401121724390.1237@maurizio.lytehouse.net>

<blush> I thought it was on the Web</blush>
I found it -- right where you said it was.

Ted

>
> What exactly do you want to do ?
> The linux-2.4.7-sis.patch is in the freebios1 tree.
>
> Ollie
>


From hansolofalcon at worldnet.att.net  Mon Jan 12 18:24:00 2004
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Mon Jan 12 18:24:00 2004
Subject: vgabios use howto.
In-Reply-To: <40031878.20306@bitworks.com>
Message-ID: <001b01c3d964$738a3420$6401a8c0@who5>

Hello (again) from Gregg C Levine
Funny you should mention that Linux Journal article, Richard. So have
I. Nice article Ron. It is indeed a Good Job.

Now as to the subject, is this in reference to the VGA BIOS item
that's tucked into the regular Free BIOS tree? Or is it in version 2
of same?

Now the fun question: Anyone besides myself, going to be attending
Linux World Conference and Expo, here in NYC, this month?
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Richard Smith
> Sent: Monday, January 12, 2004 4:58 PM
> To: rminnich at lanl.gov
> Cc: YhLu; linuxbios at clustermatic.org
> Subject: Re: vgabios use howto.
> 
> ron minnich wrote:
> 
> >
> >>How much work do you see coming to add the emulator into LB?
> >
> > not a lot. We'll see as we proceed.
> >
> > Your expertise would be invaluable in making sure it's working
correctly,
> > however.
> 
> Cool thanks.   BTW. I read your article in Linux Journal.  Good Job.
I
> also now a have a face to go with the name.
> 
> --
> Richard A. Smith
> rsmith at bitworks.com
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From ebiederman at lnxi.com  Mon Jan 12 18:40:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Mon Jan 12 18:40:01 2004
Subject: vgabios use howto.
In-Reply-To: <4002F596.3010708@bitworks.com>
References: <Pine.LNX.4.44.0401121120150.12252-100000@maxroach.lanl.gov>
	<4002F596.3010708@bitworks.com>
Message-ID: <m3isjg20dr.fsf@maxwell.lnxi.com>

Richard Smith <rsmith at bitworks.com> writes:

> ron minnich wrote:
> 
> > On Mon, 12 Jan 2004, Richard Smith wrote:
> >
> >> Can some kind soul give me or point me to info on what the current status is
> >> and what I going to need to do to get it all up?
> > vgabios/testbios is currently a linux program, not built into linuxbios at
> > all.  That's the emulator. We want to make it a linuxbios device soon.
> > The vgabios support code will run a vgabios directly. It is built into
> > linuxbios. Which one did you want?
> 
> I (and my customer) want to see the screen light up at boot so I guess I need
> the direct vgabios support.  I seem to remember trying to use it about 6 months
> ago but I never could get it to compile and since ADLO worked I didn't continue
> that path.  I'm using a 440BX chipset.
> 
> Does success under the emulator indicate the level of success for the direct
> support or are they totally different?  Will it be of use to boot the board up
> headless and run the emulator to see what happens?

There are some ATI framebuffer drivers that think they know how to initialize
a card from one of those.

It may be worth trying the emulator.  If we have open source code that can init
your video chip there are a lot of interesting things that can be done.

Eric


From rsmith at bitworks.com  Mon Jan 12 19:34:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Mon Jan 12 19:34:00 2004
Subject: vgabios use howto.
In-Reply-To: <m3isjg20dr.fsf@maxwell.lnxi.com>
References: <Pine.LNX.4.44.0401121120150.12252-100000@maxroach.lanl.gov>	<4002F596.3010708@bitworks.com> <m3isjg20dr.fsf@maxwell.lnxi.com>
Message-ID: <40033F04.8010405@bitworks.com>

Eric W. Biederman wrote:

>>Does success under the emulator indicate the level of success for the direct
>>support or are they totally different?  Will it be of use to boot the board up
>>headless and run the emulator to see what happens?
> 
> There are some ATI framebuffer drivers that think they know how to initialize
> a card from one of those.

The chips are the Rage Mobility M1.  Suposedly a mach64 core with extra 
TFT and LVDS drivers added.  Target is for laptops.  Its pretty new so I 
don't know if any of the fbdevs would support it.  If is really is a 
mach64 with a facelift then the atyfb might be able to make it work. 
Thats easy enough to test.

> It may be worth trying the emulator.  If we have open source code that can init
> your video chip there are a lot of interesting things that can be done.

I have to be careful here.  To get the datasheet on this chip we had to 
enter into NDA's with ATI which also provided us access to the register 
level docs.  So as a Bitworks employee I'm tainted.

If I can I'd like to just stick with running (or emulating) the provided 
bios image as that should keep any possiblity of someone crying foul. 
Otherwise I'll have to go seek permission from ATI's legal machine.

-- 
Richard A. Smith
rsmith at bitworks.com




From stepan at suse.de  Tue Jan 13 11:17:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Jan 13 11:17:00 2004
Subject: Solo fails - once again..
Message-ID: <20040113162549.GA6530@suse.de>

Note, it says it's doing interleaving. Funny enough, it also interleaves
with one DIMM module.

Stefan

LinuxBIOS-1.1.5.0-Fallback Di Jan 13 17:12:12 CET 2004 starting...              
setting up resource map....                                                     
 AMD8111 southbridge is connected to HT link 00000000                           
setting up resource map....                                                     
done.                                                                           
Enabling routing table for node 00000000 done.                                  
Enabling UP settings                                                            
Disabling read/write/fill probes for UP... done.                                
coherent_ht_finalize                                                            
done                                                                            
SMBus controller enabled                                                        
Ram1.00                                                                         
setting up CPU00 northbridge registers                                          
done.                                                                           
Ram2.00                                                                         
133Mhz                                                                          
Interleaved                                                                     
RAM: 0x00080000 KB                                                              
Ram3                                                                            
Initializing memory:  done                                                      
Ram4                                                                            
Copying LinuxBIOS to ram.                                                       
Jumping to LinuxBIOS.

Best regards,
  Stefan Reinauer
  
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From ebiederman at lnxi.com  Tue Jan 13 14:22:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jan 13 14:22:01 2004
Subject: Solo fails - once again..
In-Reply-To: <20040113162549.GA6530@suse.de>
References: <20040113162549.GA6530@suse.de>
Message-ID: <m3brp7fxwn.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> Note, it says it's doing interleaving. Funny enough, it also interleaves
> with one DIMM module.

If it is a double sided module this is quite possible.  It is
interleaving the chip selects.

If it did not do this in it's last incarnation this certainly
looks like an update may have broken something.

If my solo had not died I would test this.

Eric


From rsmith at bitworks.com  Tue Jan 13 15:57:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jan 13 15:57:00 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401121408440.1348-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401121408440.1348-100000@maxroach.lanl.gov>
Message-ID: <40045D77.7010407@bitworks.com>

How do I tell it what pci device to use.  I get an error trying to open 
/proc/bus/pci/00/1f.7

lspci shows my video devices at 00:12.0 and 00:14.0 with 12 being the 
device that has its IO region enabled at 1000


-- 
Richard A. Smith
rsmith at bitworks.com




From rminnich at lanl.gov  Tue Jan 13 16:01:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jan 13 16:01:01 2004
Subject: vgabios use howto.
In-Reply-To: <40045D77.7010407@bitworks.com>
Message-ID: <Pine.LNX.4.44.0401131408200.10693-100000@maxroach.lanl.gov>

On Tue, 13 Jan 2004, Richard Smith wrote:

> 
> How do I tell it what pci device to use.  I get an error trying to open 
> /proc/bus/pci/00/1f.7

what does lspci show?


> lspci shows my video devices at 00:12.0 and 00:14.0 with 12 being the 
> device that has its IO region enabled at 1000

for the -d option to the tool you have to give the busdevfn as one number, 
e.g. 2:0.0 needs to be 0x200

ron



From rsmith at bitworks.com  Tue Jan 13 16:12:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jan 13 16:12:00 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401131408200.10693-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401131408200.10693-100000@maxroach.lanl.gov>
Message-ID: <400460E6.6040208@bitworks.com>

ron minnich wrote:

> On Tue, 13 Jan 2004, Richard Smith wrote:
> 
> 
>>How do I tell it what pci device to use.  I get an error trying to open 
>>/proc/bus/pci/00/1f.7
> 
> 
> what does lspci show?
> 

gpatlas:~# lspci -v
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge 
(AGP
disabled) (rev 03)
         Subsystem: Intel Corp.: Unknown device 0000
         Flags: bus master, medium devsel, latency 64
         Memory at e0000000 (32-bit, prefetchable) [size=256M]

00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
         Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 
(prog-if 8
0 [Master])
         Flags: medium devsel
         I/O ports at 1820 [size=16]

00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 
(prog-if
00 [UHCI])
         Flags: bus master, medium devsel, latency 64, IRQ 9
         I/O ports at 1800 [size=32]

00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
         Flags: medium devsel, IRQ 9

00:12.0 VGA compatible controller: ATI Technologies Inc Rage Mobility 
P/M (rev
  64) (prog-if 00 [VGA])
         Flags: stepping, medium devsel
         Memory at f0000000 (32-bit, non-prefetchable) [size=16M]
         I/O ports at 1000 [size=256]
         Memory at f2000000 (32-bit, non-prefetchable) [size=4K]
         Expansion ROM at <unassigned> [disabled] [size=128K]
         Capabilities: [5c] Power Management version 1

00:14.0 VGA compatible controller: ATI Technologies Inc Rage Mobility 
P/M (rev
  64) (prog-if 00 [VGA])
         Flags: stepping, medium devsel
         Memory at f1000000 (32-bit, non-prefetchable) [disabled] [size=16M]
         I/O ports at 1400 [disabled] [size=256]
         Memory at f2001000 (32-bit, non-prefetchable) [disabled] [size=4K]
         Expansion ROM at <unassigned> [disabled] [size=128K]
         Capabilities: [5c] Power Management version 1

> for the -d option to the tool you have to give the busdevfn as one number, 
> e.g. 2:0.0 needs to be 0x200

I always get this wrong..  00:12.0 would be what?

-- 
Richard A. Smith
rsmith at bitworks.com




From rminnich at lanl.gov  Tue Jan 13 16:21:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jan 13 16:21:01 2004
Subject: vgabios use howto.
In-Reply-To: <400460E6.6040208@bitworks.com>
Message-ID: <Pine.LNX.4.44.0401131428390.10693-100000@maxroach.lanl.gov>

On Tue, 13 Jan 2004, Richard Smith wrote:

> I always get this wrong..  00:12.0 would be what?

12 << 3 or 0x90

so testbios -d 0x90

ron



From rsmith at bitworks.com  Tue Jan 13 16:38:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jan 13 16:38:01 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401131428390.10693-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401131428390.10693-100000@maxroach.lanl.gov>
Message-ID: <40046718.6020601@bitworks.com>

ron minnich wrote:

> 
> so testbios -d 0x90
> 

Ok.. BTW the -d option dosen't show up in the useage info..

So now I have:

gpatlas:~# ./testbios -d 0x90 -s 65536 video.bios-ATI-M1.bin
running file video.bios-ATI-M1.bin
No base specified. defaulting to 0xc0000
No initial code segment specified. defaulting to 0xc000
No initial instruction pointer specified. defaulting to 0x0003
eax=0x9 ecx=0x4c52 eflags=0x44
eax=0x9 ecx=0x1001 eflags=0x44
eax=0x8 ecx=0xef87 eflags=0x2
eax=0xb eflags=0x86
eax=0xa ecx=0xf2000000 eflags=0x86

int15 encountered.
         EAX=64004e08  EBX=00000805  ECX=00008000  EDX=000010e0
         ESP=0000ffe4  EBP=00000000  ESI=0000bf2f  EDI=0000019e
         DS=0000  ES=a000  SS=0030  CS=c000  EIP=0000e90c
         NV UP EI PL ZR NA PE NC

int15 encountered.
         EAX=00004e08  EBX=00001006  ECX=00000000  EDX=00001088
         ESP=0000ffe2  EBP=00000000  ESI=0000bf2f  EDI=000001a2
         DS=0000  ES=a000  SS=0030  CS=c000  EIP=0000ec67
         NV UP EI PL ZR NA PE NC

int15 encountered.
         EAX=00004e08  EBX=00000100  ECX=00000001  EDX=00001088
         ESP=0000ffe2  EBP=00000000  ESI=0000bf2f  EDI=000001a2
         DS=0000  ES=a000  SS=0030  CS=c000  EIP=0000e9fd
         NV UP EI PL ZR NA PE NC

int15 encountered.
         EAX=00004e08  EBX=00001502  ECX=00000000  EDX=00001088
         ESP=0000ffe2  EBP=00000000  ESI=0000bf2f  EDI=000001a2
         DS=c000  ES=a000  SS=0030  CS=c000  EIP=0000eba1
         NV UP EI PL ZR NA PE NC

int15 encountered.
         EAX=00004e08  EBX=00000f01  ECX=00000000  EDX=0000108a
         ESP=0000ffe2  EBP=00000000  ESI=0000bf2f  EDI=000001a2
         DS=c000  ES=a000  SS=0030  CS=c000  EIP=0000ebe7
         NV UP EI PL NZ NA PO NC
int6d: Write String in Teletype Mode - Function not implemented.
         EAX=00001301  EBX=00000007  ECX=0000002a  EDX=00000000
         ESP=0000ffe4  EBP=00000083  ESI=0000ffda  EDI=0000ffd0
         DS=0000  ES=c000  SS=0030  CS=c000  EIP=00000331
         NV UP EI PL ZR NA PE NC
halt_sys: file ops.c, line 9836
halted


-- 
Richard A. Smith
rsmith at bitworks.com




From rminnich at lanl.gov  Tue Jan 13 16:48:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jan 13 16:48:01 2004
Subject: vgabios use howto.
In-Reply-To: <40046718.6020601@bitworks.com>
Message-ID: <Pine.LNX.4.44.0401131456260.10693-100000@maxroach.lanl.gov>

run with -t also and you'll get instruction traces. 

Don't post traces to the list, as we don't want to start posting 
disassembled bios code to the list.

ron



From rsmith at bitworks.com  Tue Jan 13 17:11:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jan 13 17:11:00 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401131456260.10693-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401131456260.10693-100000@maxroach.lanl.gov>
Message-ID: <40046F19.7080708@bitworks.com>

ron minnich wrote:

> run with -t also and you'll get instruction traces. 
> 
> Don't post traces to the list, as we don't want to start posting 
> disassembled bios code to the list.

Agreed.  Way to long anyway.

So now what?  Since it was getting to a write string int call I would 
guess that the video init stuff would have already been run but I don't 
get any indication that VSYNC has been enabled.  I haven't verified yet 
directly by checking the vsync pin on our header yet but my monitor 
never comes out of powersave.

The emulator lets the actual writes to the hardware occur dosen't it?

-- 
Richard A. Smith
rsmith at bitworks.com




From rminnich at lanl.gov  Tue Jan 13 17:13:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jan 13 17:13:00 2004
Subject: vgabios use howto.
In-Reply-To: <40046F19.7080708@bitworks.com>
Message-ID: <Pine.LNX.4.44.0401131521220.10693-100000@maxroach.lanl.gov>

On Tue, 13 Jan 2004, Richard Smith wrote:

> So now what?  Since it was getting to a write string int call I would 
> guess that the video init stuff would have already been run but I don't 
> get any indication that VSYNC has been enabled.  I haven't verified yet 
> directly by checking the vsync pin on our header yet but my monitor 
> never comes out of powersave.

blast. It's working on nvidia and an S3 card here. 

> The emulator lets the actual writes to the hardware occur dosen't it?
yes.


You need more tracing now.

ron



From ollie at lanl.gov  Tue Jan 13 17:39:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Tue Jan 13 17:39:00 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401131521220.10693-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401131521220.10693-100000@maxroach.lanl.gov>
Message-ID: <1074034070.13170.90.camel@exponential.lanl.gov>

On Tue, 2004-01-13 at 15:21, ron minnich wrote:
> On Tue, 13 Jan 2004, Richard Smith wrote:
> 
> > So now what?  Since it was getting to a write string int call I would 
> > guess that the video init stuff would have already been run but I don't 
> > get any indication that VSYNC has been enabled.  I haven't verified yet 
> > directly by checking the vsync pin on our header yet but my monitor 
> > never comes out of powersave.
> 
> blast. It's working on nvidia and an S3 card here. 
> 
> > The emulator lets the actual writes to the hardware occur dosen't it?
> yes.
> 
> 

Ron,

what paltform does he use ? Does it have the same problem to
forward I/O and mem to the card ?

Ollie




From rsmith at bitworks.com  Tue Jan 13 17:39:08 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jan 13 17:39:08 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401131521220.10693-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401131521220.10693-100000@maxroach.lanl.gov>
Message-ID: <40047599.9030107@bitworks.com>

ron minnich wrote:

> On Tue, 13 Jan 2004, Richard Smith wrote:

>>So now what?  Since it was getting to a write string int call I would 
>>guess that the video init stuff would have already been run but I don't 
>>get any indication that VSYNC has been enabled.  I haven't verified yet 
>>directly by checking the vsync pin on our header yet but my monitor 
>>never comes out of powersave.
> 
> blast. It's working on nvidia and an S3 card here. 

All's not lost yet.  ATI provided me with a huge wad of code and images 
so it entirely possible that I'm not even running the correct image. 
Let me play with it some and report back.

-- 
Richard A. Smith
rsmith at bitworks.com




From rminnich at lanl.gov  Tue Jan 13 17:40:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jan 13 17:40:01 2004
Subject: vgabios use howto.
In-Reply-To: <1074034070.13170.90.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0401131548220.10693-100000@maxroach.lanl.gov>

On Tue, 13 Jan 2004, Li-Ta Lo wrote:

> what paltform does he use ? Does it have the same problem to
> forward I/O and mem to the card ?

I think it's the 845, so should be ok.

ron



From rsmith at bitworks.com  Tue Jan 13 17:48:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Tue Jan 13 17:48:00 2004
Subject: vgabios use howto.
In-Reply-To: <Pine.LNX.4.44.0401131548220.10693-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401131548220.10693-100000@maxroach.lanl.gov>
Message-ID: <40047777.1000707@bitworks.com>

ron minnich wrote:

> On Tue, 13 Jan 2004, Li-Ta Lo wrote:
> 
> 
>>what paltform does he use ? Does it have the same problem to
>>forward I/O and mem to the card ?
> 
> I think it's the 845, so should be ok.

440BX.  Our previous BIOS from Assiliant worked so I think the IO range 
is ok.

-- 
Richard A. Smith
rsmith at bitworks.com




From rsmith at bitworks.com  Wed Jan 14 10:40:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Wed Jan 14 10:40:01 2004
Subject: Int 15 AX=b808
In-Reply-To: <Pine.LNX.4.44.0401131548220.10693-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401131548220.10693-100000@maxroach.lanl.gov>
Message-ID: <400564BE.10700@bitworks.com>

Anyone have a clue what Int 15 AX=b808 does?  It's not in Ralph's list 
and none of the emulator code supports it.

My video bios is calling it so Im trying to determine if I can blow it 
off or if I actually have to make it work.

-- 
Richard A. Smith
rsmith at bitworks.com




From rminnich at lanl.gov  Wed Jan 14 11:17:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 14 11:17:01 2004
Subject: For VGA ...
Message-ID: <Pine.LNX.4.44.0401140920320.18892-100000@maxroach.lanl.gov>

VGA is "special". 

This code: 
src/devices/device.c:static void allocate_vga_resource(void)

is great. 

This loop:
         while(bus) {
                bus->bridge_ctrl |= PCI_BRIDGE_CTL_VGA;
                bus = (bus == bus->dev->bus)? 0 : bus->dev->bus;
        } 

is close, but as noted it is somewhat pci-centric. It works darned well 
though: it sets up most bridges just fine. 

But VGA is just so darned "SPECIAL". 

I am thinking of adding a new device_operation just for good old vga. 

	void (*endable_vga)(dev, vga_dev)

The loop changes to this: 

        while(bus) {
		if (bus->dev->ops && bus->dev->ops->enable_vga)
			bus->dev->ops->enable_vga(bus->dev, vga);
		else
	                bus->bridge_ctrl |= PCI_BRIDGE_CTL_VGA;
                bus = (bus == bus->dev->bus)? 0 : bus->dev->bus;
        } 


I think this is all we need. Most of the devices would have this empty, 
but the amdk8 would have an entry so it could: 
- set the VGA_EN bit in the correct PCI I/O register
- set up an MMIO pair for the a0000-affff range

I realize this is a special case, but all of vga is a special case, and 
VGA is *very* *important* to the embedded space. Our goal is to have a VGA 
filo or etherboot prompt. 

comments? Absent serious objections I want to put this in today.

ron



From hansolofalcon at worldnet.att.net  Wed Jan 14 11:29:01 2004
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Wed Jan 14 11:29:01 2004
Subject: Int 15 AX=b808
In-Reply-To: <400564BE.10700@bitworks.com>
Message-ID: <000001c3dabc$e1636440$6401a8c0@who5>

Hello (again) from Gregg C Levine
Richard, according to a guide book for programming for the Evil
Empire, that BIOS call, INT 15H AH=88H, which does mean AX=88H, since
your using the high order byte for that call, does this, Get Extended
Block Size. Upon return from the interrupt the AX register will
contain the number of 1K blocks. 

The book itself claims to be "The Programmers PC Sourcebook", but
since its published by those guys, that's why I gave that
introduction. In short, yes you do need to make it work. I don't know
why yours is calling it, and the emulator does not. Is this on the
native BIOS? I should think so. And is this for the video BIOS that
lives on the card, or as a part of the VGA setup, as a whole? And I
don't know why his interrupt list doesn't have it, its supposed to be
extremely extensive.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Richard Smith
> Sent: Wednesday, January 14, 2004 10:48 AM
> To: linuxbios at clustermatic.org
> Subject: Int 15 AX=b808
> 
> Anyone have a clue what Int 15 AX=b808 does?  It's not in Ralph's
list
> and none of the emulator code supports it.
> 
> My video bios is calling it so Im trying to determine if I can blow
it
> off or if I actually have to make it work.
> 
> --
> Richard A. Smith
> rsmith at bitworks.com
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios



From rminnich at lanl.gov  Wed Jan 14 11:32:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 14 11:32:01 2004
Subject: that last code I sent 
Message-ID: <Pine.LNX.4.44.0401140936250.18892-100000@maxroach.lanl.gov>

still is not quite right. 

It can be simpler I just realized. 

I can look at the bridge_ctl and if vga is set, I should be able to figure 
out that it needs to be set in amdk8. Off to look some more. 

ron



From bari at onelabs.com  Wed Jan 14 13:14:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Jan 14 13:14:00 2004
Subject: [Fwd: [Beowulf] linuxbios]
Message-ID: <40058924.9020600@onelabs.com>

Just forwarding this since there wasn't much of a response from the 
beowulf list.

-------- Original Message --------
Subject: [Beowulf] linuxbios
Date: Sun, 11 Jan 2004 18:45:17 -0800 (PST)
From: Andrew Latham <lathama at yahoo.com>
Reply-To: lathama at lathama.com
To: beowulf <beowulf at beowulf.org>

Just got my "Linux Journal" and was reading about the linuxbios.
It mentioned tyan (My fav.)
I searched tyan.com and found nothing related.
(just thought about googling tyan.com)
Any Tyan MB Linux BIOS users out there?

What are the success stories out there. I am starting to play and am already
downloading some stuff I just wondered what the group thinks about this.




http://www.clustermatic.org/
http://www.linuxbios.org

=====
/---------------------------------------------------------------------------------------------------\
Andrew Latham -LathamA - Penguin Loving, Moralist Agnostic.

What Is an agnostic? -  An agnostic thinks it impossible to know the truth
in matters such as, a god or the future with which religions are concerned
with. Or, if not impossible, at least impossible at the present time.

LathamA.com - (lay-th-ham-eh) - lathama at lathama.com - lathama at yahoo.com
\---------------------------------------------------------------------------------------------------/
_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit 
http://www.beowulf.org/mailman/listinfo/beowulf







From dwh at lanl.gov  Wed Jan 14 13:26:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Wed Jan 14 13:26:00 2004
Subject: [Fwd: [Beowulf] linuxbios]
In-Reply-To: <40058924.9020600@onelabs.com>
Message-ID: <Pine.LNX.4.44.0401141129000.16919-100000@ccs-mail.lanl.gov>

If you want to order a Tyan board with LinuxBIOS pre-loaded, you might 
need to go through some special ordering process... try asking Charlie 
Ding (cding at tyan.com).

Currently we're working on the S2885. VGA works to an extent now, we can 
use the testbios utility to init the VGA BIOS on a GeForce FX and X will 
run with the "nv" driver. The binary driver will load and X will start, 
but the screen goes corrupt. So long as it's not a driver issue, this 
might be fixed in the near future. Getting the CLI should be  first, and 
that will be nice since Ollie just got keyboard input working.

On Wed, 14 Jan 2004, Bari Ari wrote:

> Just forwarding this since there wasn't much of a response from the 
> beowulf list.
> 
> -------- Original Message --------
> Subject: [Beowulf] linuxbios
> Date: Sun, 11 Jan 2004 18:45:17 -0800 (PST)
> From: Andrew Latham <lathama at yahoo.com>
> Reply-To: lathama at lathama.com
> To: beowulf <beowulf at beowulf.org>
> 
> Just got my "Linux Journal" and was reading about the linuxbios.
> It mentioned tyan (My fav.)
> I searched tyan.com and found nothing related.
> (just thought about googling tyan.com)
> Any Tyan MB Linux BIOS users out there?
> 
> What are the success stories out there. I am starting to play and am already
> downloading some stuff I just wondered what the group thinks about this.
> 
> 
> 
> 
> http://www.clustermatic.org/
> http://www.linuxbios.org
> 
> =====
> /---------------------------------------------------------------------------------------------------\
> Andrew Latham -LathamA - Penguin Loving, Moralist Agnostic.
> 
> What Is an agnostic? -  An agnostic thinks it impossible to know the truth
> in matters such as, a god or the future with which religions are concerned
> with. Or, if not impossible, at least impossible at the present time.
> 
> LathamA.com - (lay-th-ham-eh) - lathama at lathama.com - lathama at yahoo.com
> \---------------------------------------------------------------------------------------------------/
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit 
> http://www.beowulf.org/mailman/listinfo/beowulf
> 
> 
> 
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From bari at onelabs.com  Wed Jan 14 13:28:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Jan 14 13:28:01 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <20040110122559.GA19323@tarnica.ctnet.pl>
References: <20040110122559.GA19323@tarnica.ctnet.pl>
Message-ID: <40058C8B.20300@onelabs.com>

Miernik wrote:

> Maybe this will be a candidate for LinuxBIOS laptop:
> http://www.linuxcertified.com/linux-laptop-lc2430.html
> 
> This laptop is probably produced by a Linux company (LC stands for 
> Linux Certified I presume), so they might be interested in 
> cooperation. It has been recently Debian certified.
> 
Cooperation would be nice... but they may not even know some of the 
details needed to get all the features working with LinuxBIOS.

Laptops typically use a micro with lots of I/O to perform keyboard scan 
along with power management, battery charging, flashing the BIOS etc.
Getting the specs. to make these features work is a problem since most 
laptop vendors don't design their own motherboards.

-Bari




From rminnich at lanl.gov  Wed Jan 14 13:34:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 14 13:34:00 2004
Subject: Int 15 AX=b808
In-Reply-To: <000001c3dabc$e1636440$6401a8c0@who5>
Message-ID: <Pine.LNX.4.44.0401141142270.18892-100000@maxroach.lanl.gov>

interesting, as I thought I had put the 'free memory' interrupt in there. 

We'll try to look some more later today. 

Thanks Gregg.

ron



From hansolofalcon at worldnet.att.net  Wed Jan 14 13:37:00 2004
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Wed Jan 14 13:37:00 2004
Subject: Int 15 AX=b808
In-Reply-To: <Pine.LNX.4.44.0401141142270.18892-100000@maxroach.lanl.gov>
Message-ID: <000001c3dace$cbce02e0$6401a8c0@who5>

Hello (again) from Gregg C Levine
Your quite welcome. Although I am curious as to how that problem
materialized, with what Richard is doing, within the scope of his NDA.
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: ron minnich [mailto:rminnich at lanl.gov]
> Sent: Wednesday, January 14, 2004 1:43 PM
> To: Gregg C Levine
> Cc: rsmith at bitworks.com; linuxbios at clustermatic.org
> Subject: RE: Int 15 AX=b808
> 
> interesting, as I thought I had put the 'free memory' interrupt in
there.
> 
> We'll try to look some more later today.
> 
> Thanks Gregg.
> 
> ron



From rminnich at lanl.gov  Wed Jan 14 13:45:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 14 13:45:01 2004
Subject: [Fwd: [Beowulf] linuxbios]
In-Reply-To: <40058924.9020600@onelabs.com>
Message-ID: <Pine.LNX.4.44.0401141153020.18892-100000@maxroach.lanl.gov>

On Wed, 14 Jan 2004, Bari Ari wrote:

> What are the success stories out there. I am starting to play and am already
> downloading some stuff I just wondered what the group thinks about this.

well there is the largest K8 cluster in the world, here at LANL, 1408 
nodes. Built by linuxbios, arima mobo, linuxbios support from linux 
networx. 

Tyan will sell you K8 mobos with linuxbios on them. Hopefully the tyan
people reading this will get in touch with you.

There are a few other companies that will do K8 mobos with linuxbios but 
nothing public yet.

ron



From rminnich at lanl.gov  Wed Jan 14 13:46:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 14 13:46:00 2004
Subject: [Fwd: [Beowulf] linuxbios]
In-Reply-To: <Pine.LNX.4.44.0401141129000.16919-100000@ccs-mail.lanl.gov>
Message-ID: <Pine.LNX.4.44.0401141154440.18892-100000@maxroach.lanl.gov>

On Wed, 14 Jan 2004, Hendricks David W. wrote:

> Currently we're working on the S2885. VGA works to an extent now, we can 
> use the testbios utility to init the VGA BIOS on a GeForce FX and X will 
> run with the "nv" driver. The binary driver will load and X will start, 
> but the screen goes corrupt. So long as it's not a driver issue, this 
> might be fixed in the near future. Getting the CLI should be  first, and 
> that will be nice since Ollie just got keyboard input working.

it's no big deal, we may have all vga fixed this afternoon. 

ron



From YhLu at tyan.com  Wed Jan 14 14:05:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jan 14 14:05:01 2004
Subject: =?gb2312?B?tPC4tDogW0Z3ZDogW0Jlb3d1bGZdIGxpbnV4Ymlvc10=?=
Message-ID: <3174569B9743D511922F00A0C943142303D8E9AD@TYANWEB>

Lathama,

I will let Charlie to contact you to see if We can help.

Regards

Yinghai Lu

-----????-----
???: ron minnich [mailto:rminnich at lanl.gov] 
????: 2004?1?14? 10:54
???: Bari Ari
??: linuxbios at clustermatic.org; lathama at lathama.com
??: Re: [Fwd: [Beowulf] linuxbios]

On Wed, 14 Jan 2004, Bari Ari wrote:

> What are the success stories out there. I am starting to play and am
already
> downloading some stuff I just wondered what the group thinks about this.

well there is the largest K8 cluster in the world, here at LANL, 1408 
nodes. Built by linuxbios, arima mobo, linuxbios support from linux 
networx. 

Tyan will sell you K8 mobos with linuxbios on them. Hopefully the tyan
people reading this will get in touch with you.

There are a few other companies that will do K8 mobos with linuxbios but 
nothing public yet.

ron

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


From ebiederman at lnxi.com  Wed Jan 14 14:51:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jan 14 14:51:01 2004
Subject: that last code I sent
In-Reply-To: <Pine.LNX.4.44.0401140936250.18892-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401140936250.18892-100000@maxroach.lanl.gov>
Message-ID: <m3oet6uwog.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> still is not quite right. 
> 
> It can be simpler I just realized. 
> 
> I can look at the bridge_ctl and if vga is set, I should be able to figure 
> out that it needs to be set in amdk8. Off to look some more. 

Right that is why I did it that way.  

Eric


From YhLu at tyan.com  Wed Jan 14 18:56:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jan 14 18:56:01 2004
Subject: SuperIO w83627hf. support.
Message-ID: <3174569B9743D511922F00A0C943142303D8E9F5@TYANWEB>

Eric or Ron or Stefan,,

I want to who's dev src/superio/NSC/pc87360.

I have tried to copy and modify for winbond/w83627hf to make FDC and
Keyboard to work. Some resource can not be set to the several reg.

I add several line in s2282/Config.lb
                superio winbond/w83627hf link 1
                        pnp 2e.0
                        pnp 2e.1
                        pnp 2e.2
                        pnp 2e.3
                        pnp 2e.5
                        pnp 2e.6
                        pnp 2e.7
                        pnp 2e.8
                        pnp 2e.9
                        pnp 2e.a
                        pnp 2e.b
                        register "com1" = "{1, 0, 0x3f8, 4}"
                        register "lpt" = "{1}"
                end

Can you tell why call it 2e...

Regards

YH.

the result will be

Allocating resources...
PCI: 04:01.0 missing read_resources
PCI: 04:01.0 missing read_resources
PCI: 04:01.0 missing read_resources
PCI: 01:04.5 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 01:04.5 missing read_resources
PCI: 01:04.6 missing read_resources
ASSIGN RESOURCES, bus 0
PCI: 01:04.5 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 00:18.0 c0 <- [0x00001000 - 0x00003fff] node 0 link 0 io
PCI: 01:04.5 missing read_resources
PCI: 01:04.6 missing read_resources
PCI: 00:18.0 b8 <- [0xfd000000 - 0xfe2fffff] node 0 link 0 mem
ASSIGN RESOURCES, bus 1
PCI: 01:01.0 1c <- [0x00001000 - 0x00001fff] bus 2 io
PCI: 01:01.0 24 <- [0xfe200000 - 0xfe1fffff] bus 2 prefmem
PCI: 01:01.0 20 <- [0xfe100000 - 0xfe1fffff] bus 2 mem
ASSIGN RESOURCES, bus 2
PCI: 02:06.0 10 <- [0x00001000 - 0x000010ff] io
PCI: 02:06.0 14 <- [0xfe140000 - 0xfe141fff] mem
PCI: 02:06.0 1c <- [0x00001400 - 0x000014ff] io
PCI: 02:06.1 10 <- [0x00001800 - 0x000018ff] io
PCI: 02:06.1 14 <- [0xfe142000 - 0xfe143fff] mem
PCI: 02:06.1 1c <- [0x00001c00 - 0x00001cff] io
PCI: 02:09.0 10 <- [0xfe100000 - 0xfe10ffff] mem
PCI: 02:09.0 18 <- [0xfe110000 - 0xfe11ffff] mem
PCI: 02:09.1 10 <- [0xfe120000 - 0xfe12ffff] mem
PCI: 02:09.1 18 <- [0xfe130000 - 0xfe13ffff] mem
ASSIGNED RESOURCES, bus 2
PCI: 01:01.1 10 <- [0xfe200000 - 0xfe200fff] mem
PCI: 01:02.0 1c <- [0x00003000 - 0x00002fff] bus 3 io
PCI: 01:02.0 24 <- [0xfe200000 - 0xfe1fffff] bus 3 prefmem
PCI: 01:02.0 20 <- [0xfe200000 - 0xfe1fffff] bus 3 mem
PCI: 01:02.1 10 <- [0xfe201000 - 0xfe201fff] mem
PCI: 04:01.0 missing read_resources
PCI: 01:03.0 1c <- [0x00002000 - 0x00002fff] bus 4 io
PCI: 04:01.0 missing read_resources
PCI: 01:03.0 24 <- [0xfe200000 - 0xfe1fffff] bus 4 prefmem
PCI: 04:01.0 missing read_resources
PCI: 01:03.0 20 <- [0xfd000000 - 0xfeffffff] bus 4 mem
ASSIGN RESOURCES, bus 4
PCI: 04:00.0 10 <- [0xfe020000 - 0xfe020fff] mem
PCI: 04:00.1 10 <- [0xfe021000 - 0xfe021fff] mem
PCI: 04:00.2 10 <- [0xfe025000 - 0xfe0250ff] mem
PCI: 04:00.2 14 <- [0xfe026000 - 0xfe02601f] mem
PCI: 04:01.0 missing set_resources
PCI: 04:05.0 10 <- [0x00002450 - 0x00002457] io
PCI: 04:05.0 14 <- [0x00002470 - 0x00002473] io
PCI: 04:05.0 18 <- [0x00002460 - 0x00002467] io
PCI: 04:05.0 1c <- [0x00002480 - 0x00002483] io
PCI: 04:05.0 20 <- [0x00002440 - 0x0000244f] io
PCI: 04:05.0 24 <- [0xfe024000 - 0xfe0243ff] mem
PCI: 04:06.0 10 <- [0xfd000000 - 0xfdffffff] mem
PCI: 04:06.0 14 <- [0x00002000 - 0x000020ff] io
PCI: 04:06.0 18 <- [0xfe022000 - 0xfe022fff] mem
PCI: 04:08.0 10 <- [0xfe023000 - 0xfe023fff] mem
PCI: 04:08.0 14 <- [0x00002400 - 0x0000243f] io
PCI: 04:08.0 18 <- [0xfe000000 - 0xfe01ffff] 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.0 60 <- [0x00003030 - 0x00003037 io
ERROR: PNP: 002e.0 70 not allocated
ERROR: PNP: 002e.0 74 not allocated
PNP: 002e.1 60 <- [0x00003040 - 0x00003047 io
ERROR: PNP: 002e.1 70 not allocated
ERROR: PNP: 002e.1 74 not allocated
PNP: 002e.2 60 <- [0x000003f8 - 0x000003f7 io
PNP: 002e.2 70 <- [0x00000004 - 0x00000003 irq
PNP: 002e.3 60 <- [0x00003050 - 0x00003057 io
ERROR: PNP: 002e.3 70 not allocated
PNP: 002e.5 60 <- [0x00000060 - 0x0000005f io
PNP: 002e.5 62 <- [0x00000064 - 0x00000063 io
PNP: 002e.5 70 <- [0x00000001 - 0x00000000 irq
PNP: 002e.5 72 <- [0x0000000c - 0x0000000b irq
PNP: 002e.6 60 <- [0x00003060 - 0x00003067 io
ERROR: PNP: 002e.6 70 not allocated
PNP: 002e.7 60 <- [0x00003090 - 0x00003090 io
PNP: 002e.7 62 <- [0x00003080 - 0x00003081 io
ERROR: PNP: 002e.7 70 not allocated
ERROR: PNP: 002e.a 70 not allocated
PNP: 002e.b 60 <- [0x00003070 - 0x00003077 io
ERROR: PNP: 002e.b 70 not allocated
ASSIGNED RESOURCES, bus 0
PCI: 01:04.1 20 <- [0x00003020 - 0x0000302f] io
PCI: 01:04.2 10 <- [0x00003000 - 0x0000301f] io
PCI: 01:04.5 missing set_resources
PCI: 01:04.6 missing set_resources
ASSIGNED RESOURCES, bus 1
ASSIGNED RESOURCES, bus 0
Allocating VGA resource

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

From prl at peterlister.co.uk  Wed Jan 14 19:18:01 2004
From: prl at peterlister.co.uk (Peter Lister)
Date: Wed Jan 14 19:18:01 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <40058C8B.20300@onelabs.com>
References: <20040110122559.GA19323@tarnica.ctnet.pl>
	 <40058C8B.20300@onelabs.com>
Message-ID: <1074126440.5466.602.camel@eddie>

On Wed, 2004-01-14 at 18:38, Bari Ari wrote:

> Cooperation would be nice... but they may not even know some of the 
> details needed to get all the features working with LinuxBIOS.

Yes, but presumably a supplier who might handle a reasonable number of
units is likelier to get a hearing from the upstream vendor than the
average end user, especially if there is no intervening retail vendor
who understands nothing but M$.

Just out of interest, my laptop is a Clevo SiS unbranded, no Windows
job. Winmodem doesn't work, as one might expect, and the sound card
needs Linux ACPI support turned on, but other than that it's fine.

Oh, and the VGA text mode is badly aligned when the framebuffer is
working. But that's liveable with. Nothing else wrong, though.

lspci attached. What are the chances??

-------------- next part --------------
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 650 Host (rev 01)
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual PCI-to-PCI bridge (AGP)
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 25)
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE]
00:02.6 Modem: Silicon Integrated Systems [SiS] Intel 537 [56k Winmodem] (rev a0)
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] SiS7012 PCI Audio Accelerator (rev a0)
00:03.0 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 0f)
00:03.1 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 0f)
00:03.2 USB Controller: Silicon Integrated Systems [SiS] SiS7002 USB 2.0
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)
00:0c.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller
01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS650/651/M650/740 PCI/AGP VGA Display Adapter
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 650 Host (rev 01)
	Subsystem: CLEVO/KAPOK Computer: Unknown device 2263
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 64
	Region 0: Memory at e8000000 (32-bit, non-prefetchable) [size=64M]
	Capabilities: <available only to root>

00:01.0 PCI bridge: Silicon Integrated Systems [SiS] SiS 530 Virtual PCI-to-PCI bridge (AGP) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 99
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=68
	I/O behind bridge: 00009000-00009fff
	Memory behind bridge: ec100000-ec1fffff
	Prefetchable memory behind bridge: f0000000-f7ffffff
	BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-

00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 25)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (prog-if 80 [Master])
	Subsystem: CLEVO/KAPOK Computer: Unknown device 2263
	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: 128
	Interrupt: pin ? routed to IRQ 5
	Region 4: I/O ports at 1000 [size=16]

00:02.6 Modem: Silicon Integrated Systems [SiS] Intel 537 [56k Winmodem] (rev a0) (prog-if 00 [Generic])
	Subsystem: CLEVO/KAPOK Computer: Unknown device 4201
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin C routed to IRQ 5
	Region 0: I/O ports at 1400 [size=256]
	Region 1: I/O ports at 1080 [size=128]
	Capabilities: <available only to root>

00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] SiS7012 PCI Audio Accelerator (rev a0)
	Subsystem: CLEVO/KAPOK Computer: Unknown device 2263
	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: 173 (13000ns min, 2750ns max)
	Interrupt: pin C routed to IRQ 5
	Region 0: I/O ports at 1c00 [size=256]
	Region 1: I/O ports at 1800 [size=128]
	Capabilities: <available only to root>

00:03.0 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 0f) (prog-if 10 [OHCI])
	Subsystem: CLEVO/KAPOK Computer: Unknown device 2263
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+
	Latency: 64 (20000ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at ec000000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <available only to root>

00:03.1 USB Controller: Silicon Integrated Systems [SiS] SiS7001 USB Controller (rev 0f) (prog-if 10 [OHCI])
	Subsystem: CLEVO/KAPOK Computer: Unknown device 2263
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR+
	Latency: 64 (20000ns max)
	Interrupt: pin B routed to IRQ 10
	Region 0: Memory at ec001000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <available only to root>

00:03.2 USB Controller: Silicon Integrated Systems [SiS] SiS7002 USB 2.0 (prog-if 20 [EHCI])
	Subsystem: CLEVO/KAPOK Computer: Unknown device 2263
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (20000ns max)
	Interrupt: pin D routed to IRQ 10
	Region 0: Memory at ec002000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <available only to root>

00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
	Subsystem: CLEVO/KAPOK Computer: Unknown device 2263
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (8000ns min, 16000ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 2000 [size=256]
	Region 1: Memory at ec003000 (32-bit, non-prefetchable) [size=256]
	Capabilities: <available only to root>

00:0b.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
	Subsystem: CLEVO/KAPOK Computer: Unknown device 2263
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (500ns min, 1000ns max), cache line size 04
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at ec003800 (32-bit, non-prefetchable) [size=2K]
	Region 1: Memory at ec004000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: <available only to root>

00:0c.0 CardBus bridge: ENE Technology Inc CB1410 Cardbus Controller
	Subsystem: CLEVO/KAPOK Computer: Unknown device 2263
	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: 168, cache line size 20
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at 1e000000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
	Memory window 0: 1e400000-1e7ff000 (prefetchable)
	Memory window 1: 1e800000-1ebff000
	I/O window 0: 00004000-000040ff
	I/O window 1: 00004400-000044ff
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] SiS650/651/M650/740 PCI/AGP VGA Display Adapter (prog-if 00 [VGA])
	Subsystem: CLEVO/KAPOK Computer: Unknown device 2263
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 5
	BIST result: 00
	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
	Region 1: Memory at ec100000 (32-bit, non-prefetchable) [size=128K]
	Region 2: I/O ports at 9000 [size=128]
	Capabilities: <available only to root>


From ebiederman at lnxi.com  Wed Jan 14 19:40:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jan 14 19:40:01 2004
Subject: SuperIO w83627hf. support.
In-Reply-To: <3174569B9743D511922F00A0C943142303D8E9F5@TYANWEB>
References: <3174569B9743D511922F00A0C943142303D8E9F5@TYANWEB>
Message-ID: <m3hdyyghmw.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric or Ron or Stefan,,
> 
> I want to who's dev src/superio/NSC/pc87360.
> 
> I have tried to copy and modify for winbond/w83627hf to make FDC and
> Keyboard to work. Some resource can not be set to the several reg.

The only piece I am seeing, is that the irq resources that are not
hard coded are not being allocated automatically.  

The basic problem is that we don't have an irq allocator in LinuxBIOS,
We also could use a legacy address allocator as well to automatically
put these things at their legacy addresses if possible.

My latest build (still needs to be merged) I just turned off all of
the devices I didn't care about which made the irq assignment problems
go away.  It is a bad long term solution but it is ok in the short
term. 

> Can you tell why call it 2e...

Because that is the base configuration port.   Figuring out
what kind of paths to use for devices like this is a bit of
a challenge.  

I forget but I think there was a considerable about of infrastructure
in the super.c file you copied that probably should be moved to
a generic file some place.

Eric


From YhLu at tyan.com  Wed Jan 14 19:56:01 2004
From: YhLu at tyan.com (YhLu)
Date: Wed Jan 14 19:56:01 2004
Subject: =?gb2312?B?tPC4tDogU3VwZXJJTyB3ODM2MjdoZi4gc3VwcG9ydC4=?=
Message-ID: <3174569B9743D511922F00A0C943142303D8EA00@TYANWEB>

Yes, may only sio_enable() and struct pnp_dev_info[] and enumerate should be
specific.

YH.

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?1?14? 16:50
???: YhLu
??: ron minnich; linuxbios at clustermatic.org
??: Re: SuperIO w83627hf. support.

YhLu <YhLu at tyan.com> writes:

> Eric or Ron or Stefan,,
> 
> I want to who's dev src/superio/NSC/pc87360.
> 
> I have tried to copy and modify for winbond/w83627hf to make FDC and
> Keyboard to work. Some resource can not be set to the several reg.

The only piece I am seeing, is that the irq resources that are not
hard coded are not being allocated automatically.  

The basic problem is that we don't have an irq allocator in LinuxBIOS,
We also could use a legacy address allocator as well to automatically
put these things at their legacy addresses if possible.

My latest build (still needs to be merged) I just turned off all of
the devices I didn't care about which made the irq assignment problems
go away.  It is a bad long term solution but it is ok in the short
term. 

> Can you tell why call it 2e...

Because that is the base configuration port.   Figuring out
what kind of paths to use for devices like this is a bit of
a challenge.  

I forget but I think there was a considerable about of infrastructure
in the super.c file you copied that probably should be moved to
a generic file some place.

Eric


From bari at onelabs.com  Wed Jan 14 23:10:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Jan 14 23:10:01 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <1074126440.5466.602.camel@eddie>
References: <20040110122559.GA19323@tarnica.ctnet.pl>	 <40058C8B.20300@onelabs.com> <1074126440.5466.602.camel@eddie>
Message-ID: <400613E0.7090408@onelabs.com>

Peter Lister wrote:

> Yes, but presumably a supplier who might handle a reasonable number of
> units is likelier to get a hearing from the upstream vendor than the
> average end user, especially if there is no intervening retail vendor
> who understands nothing but M$.
> 
> Just out of interest, my laptop is a Clevo SiS unbranded, no Windows
> job. Winmodem doesn't work, as one might expect, and the sound card
> needs Linux ACPI support turned on, but other than that it's fine.
> 
> Oh, and the VGA text mode is badly aligned when the framebuffer is
> working. But that's liveable with. Nothing else wrong, though.
> 
> lspci attached. What are the chances??

The SiS 650 chipset was never supported by LinuxBIOS. SiS also dropped 
interest in LinuxBIOS last year.

A laptop that uses any of the currently supported chipsets or any 
chipsets by Intel or AMD won't be a problem (since they openly post docs 
for their chipsets) to support under LinuxBIOS except for the issues 
with the keyboard scan micros that are also used for power management, 
battery charging, BIOS Flashing etc. Laptops typically use I/O on these 
micros to control writes to the flash. You may need to know the "magic 
code" or at least the register locations in the micro to turn on BIOS 
Flash write enables.

We did some work before on creating open firmware for these devices.

Some examples of cpu based super i/o's:

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

Some descriptions of the closed source firmware and how they use these 
micros:

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

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

-Bari




From rminnich at lanl.gov  Wed Jan 14 23:15:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 14 23:15:01 2004
Subject: SuperIO w83627hf. support.
In-Reply-To: <3174569B9743D511922F00A0C943142303D8E9F5@TYANWEB>
Message-ID: <Pine.LNX.4.44.0401142123450.23744-100000@maxroach.lanl.gov>

On Wed, 14 Jan 2004, YhLu wrote:

> 
> I add several line in s2282/Config.lb
>                 superio winbond/w83627hf link 1
>                         pnp 2e.0

2e means the pnp address is 2e

This also lists all the devices on the superio.

The rest I will have to look at.

ron



From rminnich at lanl.gov  Wed Jan 14 23:16:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 14 23:16:01 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <1074126440.5466.602.camel@eddie>
Message-ID: <Pine.LNX.4.44.0401142125290.23744-100000@maxroach.lanl.gov>

how easy/hard is it to get the flash part?

ron



From rminnich at lanl.gov  Wed Jan 14 23:18:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 14 23:18:01 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <400613E0.7090408@onelabs.com>
Message-ID: <Pine.LNX.4.44.0401142126370.23744-100000@maxroach.lanl.gov>

On Wed, 14 Jan 2004, Bari Ari wrote:

> The SiS 650 chipset was never supported by LinuxBIOS. SiS also dropped 
> interest in LinuxBIOS last year.

:=(

But, Ollie works here now ... :=)

ron



From rminnich at lanl.gov  Wed Jan 14 23:49:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 14 23:49:00 2004
Subject: legacy vga ... what do you think?
Message-ID: <Pine.LNX.4.44.0401142144190.25611-100000@maxroach.lanl.gov>

The issue is that at the amdk8 northbridge, we need to know bus/dev/fn for
the hardware so we can set up the VGA_EN bit in the right PCIIO pair as
well as an MMIO entry for it. It's not enough to just set a bit in the 
bridge on the K8 -- you have to set up routing to the right Hypertransport 
bus. You have to know where the device is.

By far the easiest way to do this is to add a simple structure member to
the bus structure:
	struct device *vgadev;

so we have:
struct bus {
        device_t        dev;            /* This bridge device */
        device_t        children;       /* devices behind this bridge */
	unsigned        bridge_ctrl;    /* Bridge control register */
	/* NEW */
	struct device 	*vgadev;	/* if bridge_ctl has 
					 * PCI_CB_BRIDGE_CTL_VGA set, 
					 * this contains pointer to 
					 * the device.
					 */
	/* END NEW */
        unsigned char   link;           /* The index of this link */
        unsigned char   secondary;      /* secondary bus number */
        unsigned char   subordinate;    /* max subordinate bus number */
        unsigned char   cap;            /* PCi capability offset */
};

Setting vgadev is then trivial in the allocate_vga_resource since in that
function you already have a pointer to the vga device; or just set the
pointer. Either way, when you are at a bridge and know that the bridge has
vga on the bus somewhere, you can easily get the info you need to set up
the bridge if it is a complex bridge like the K8.

        while(bus) {
                bus->bridge_ctrl |= PCI_BRIDGE_CTL_VGA;
		/* NEW */
		bus->vgadev = vga;
		/* END NEW */
                bus = (bus == bus->dev->bus)? 0 : bus->dev->bus;
        }


Unless there is a huge problem with this I will try to get it done 
tomorrow. It's a new structure member and one line of code and we're on 
the air.

It is not totally general but ... VGA is "special". As in, really ugly.

ron






From ebiederman at lnxi.com  Thu Jan 15 01:05:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 15 01:05:01 2004
Subject: legacy vga ... what do you think?
In-Reply-To: <Pine.LNX.4.44.0401142144190.25611-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401142144190.25611-100000@maxroach.lanl.gov>
Message-ID: <m3ptdlenzj.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> The issue is that at the amdk8 northbridge, we need to know bus/dev/fn for
> the hardware so we can set up the VGA_EN bit in the right PCIIO pair as
> well as an MMIO entry for it.

Huh?  There is a fairly definitive association between resources and
non-coherent hypertransport chains.  What do you need the device for?

> It's not enough to just set a bit in the 
> bridge on the K8 -- you have to set up routing to the right Hypertransport 
> bus. 

Right and we know that bus is the bus we set the VGA_EN bit for.

> You have to know where the device is.

Yes but you should not need to know which device it is.

> By far the easiest way to do this is to add a simple structure member to
> the bus structure:
> 	struct device *vgadev;

Huh?


> so we have:
> struct bus {
>         device_t        dev;            /* This bridge device */
>         device_t        children;       /* devices behind this bridge */
> 	unsigned        bridge_ctrl;    /* Bridge control register */
> 	/* NEW */
> 	struct device 	*vgadev;	/* if bridge_ctl has 
> 					 * PCI_CB_BRIDGE_CTL_VGA set, 
> 					 * this contains pointer to 
> 					 * the device.
> 					 */
> 	/* END NEW */
>         unsigned char   link;           /* The index of this link */
>         unsigned char   secondary;      /* secondary bus number */
>         unsigned char   subordinate;    /* max subordinate bus number */
>         unsigned char   cap;            /* PCi capability offset */
> };
> 
> Setting vgadev is then trivial in the allocate_vga_resource since in that
> function you already have a pointer to the vga device; or just set the
> pointer. Either way, when you are at a bridge and know that the bridge has
> vga on the bus somewhere, you can easily get the info you need to set up
> the bridge if it is a complex bridge like the K8.

Yes the simple enough it just appears to be unnecessary.
 
>         while(bus) {
>                 bus->bridge_ctrl |= PCI_BRIDGE_CTL_VGA;
> 		/* NEW */
> 		bus->vgadev = vga;
> 		/* END NEW */
>                 bus = (bus == bus->dev->bus)? 0 : bus->dev->bus;
>         }
> 
> 
> Unless there is a huge problem with this I will try to get it done 
> tomorrow. It's a new structure member and one line of code and we're on 
> the air.
> 
> It is not totally general but ... VGA is "special". As in, really ugly.

Yes, the vga routing at least needs a special case.  It is a common
case so there is no problem with that.  The idea is to have a model
that we progressively refine into what we need.

What I don't see is what you need vgadev for.  The only case I can
think of is short cutting to the emulator.  In that case one global
would be fine.

Looking at the code though there is a bug.  When it finds a device
to give the legacy vga resources to it does not allocate any MMIO
resources.  For bridges this is a normal resource so this looks
a real bug in the generic code.  If that is why you need
the vgadev,  let's fix the generic code to handle that part properly. 

Eric


From rsmith at bitworks.com  Thu Jan 15 02:37:01 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Thu Jan 15 02:37:01 2004
Subject: ATI M1 progress.
In-Reply-To: <Pine.LNX.4.44.0401142144190.25611-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401142144190.25611-100000@maxroach.lanl.gov>
Message-ID: <40064511.9000907@bitworks.com>

I made a little progress today.

I learned how to build a copy of my vgabios and build a new image rather 
than use the one that came pre-built with the kit.

I've found a configuration that under both ADLO and direct IDT will 
actually enable a VSYNC.  No video output yet but at least its a start. 
    I almost didn't catch it.  It appears to be hung but after about 15 
seconds or so something times out and the familiar *foush* of the 
monitor kicking out of powersave can be heard.  Elfboot then runs and 
boots up my system.

The vgabios emulator still chokes on the image though.  The unsuported 
write string call somehow causes the bios to execute a halt.  Is there a 
way I can set up a breakpoint and then drop to single stepping?



-- 
Richard A. Smith
rsmith at bitworks.com




From mayuresh.bakshi at nevisnetworks.com  Thu Jan 15 03:06:01 2004
From: mayuresh.bakshi at nevisnetworks.com (Mayuresh Bakshi)
Date: Thu Jan 15 03:06:01 2004
Subject: Support for Athlon 64 and nVIDIA nforce3
Message-ID: <36993D449C7FA647BF43568E0793AB3E32B035@nevis_pune_xchg.pune.nevisnetworks.com>

Hi,

We've a custom board with AMD Athlon 64 processor
and nVIDIA nforce3 as south bridge. Does linuxBIOS
have support for these chipsets. 

Thanks,

-Mayuresh



From stepan at suse.de  Thu Jan 15 03:32:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Jan 15 03:32:00 2004
Subject: Support for Athlon 64 and nVIDIA nforce3
In-Reply-To: <36993D449C7FA647BF43568E0793AB3E32B035@nevis_pune_xchg.pune.nevisnetworks.com>
References: <36993D449C7FA647BF43568E0793AB3E32B035@nevis_pune_xchg.pune.nevisnetworks.com>
Message-ID: <20040115084056.GB19418@suse.de>

* Mayuresh Bakshi <mayuresh.bakshi at nevisnetworks.com> [040115 09:15]:
> 
> Hi,
> 
> We've a custom board with AMD Athlon 64 processor
> and nVIDIA nforce3 as south bridge. Does linuxBIOS
> have support for these chipsets. 

nvidia nforce3 is not supported. AFAIK nvidia has been kind of
restrictive wrt releasing any of their specs. Only AMD released
the complete range to their specifications and data sheets for
AMD64 chipsets.

Best regards,
  Stefan Reinauer
  
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From ebiederman at lnxi.com  Thu Jan 15 04:13:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 15 04:13:01 2004
Subject: Support for Athlon 64 and nVIDIA nforce3
In-Reply-To: <20040115084056.GB19418@suse.de>
References: <36993D449C7FA647BF43568E0793AB3E32B035@nevis_pune_xchg.pune.nevisnetworks.com>
	<20040115084056.GB19418@suse.de>
Message-ID: <m3brp5woor.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * Mayuresh Bakshi <mayuresh.bakshi at nevisnetworks.com> [040115 09:15]:
> > 
> > Hi,
> > 
> > We've a custom board with AMD Athlon 64 processor
> > and nVIDIA nforce3 as south bridge. Does linuxBIOS
> > have support for these chipsets. 
> 
> nvidia nforce3 is not supported. AFAIK nvidia has been kind of
> restrictive wrt releasing any of their specs. Only AMD released
> the complete range to their specifications and data sheets for
> AMD64 chipsets.

The memory controller setup is part of processor.  So with
the documentation as it now stands there is a slim possibility
of getting it up and going.  The hard part is supported.

If you are building a board with the nforce3 you probably have
enough traction that you have a reasonable chance of
getting the needed docs.  It is worth asking anyway :)

Eric


From bari at onelabs.com  Thu Jan 15 04:36:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Thu Jan 15 04:36:01 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <1074126440.5466.602.camel@eddie>
References: <20040110122559.GA19323@tarnica.ctnet.pl>	 <40058C8B.20300@onelabs.com> <1074126440.5466.602.camel@eddie>
Message-ID: <40062B87.3030502@onelabs.com>


Peter Lister wrote:

> Just out of interest, my laptop is a Clevo SiS unbranded, no Windows
> job. Winmodem doesn't work, as one might expect, 

Have you looked at  http://linmodems.org/  for Linux support for the 
Winmodem?

-Bari




From peter.fox at aeroflex.com  Thu Jan 15 06:54:00 2004
From: peter.fox at aeroflex.com (Peter Fox)
Date: Thu Jan 15 06:54:00 2004
Subject: Bit banging SPD code
Message-ID: <NEBBJLECKKOPJEEKNGJOGEFEEDAA.peter.fox@aeroflex.com>

I would like to make the STPC elite ram initialisation use SPD info.

I notice that all the existing SDRAM initialisation that uses
SPD seems to use some kind of SPD controller. Is this true ?

The STPC elite only provides a bit banging SPD interface, has
anyone implemented smbus_read_byte etc with a bit banging interface ?

-- 
Peter Fox <peter.fox at aeroflex.com>     Aeroflex Test Solutions
Principal Design Engineer                            Stevenage
Any opinions expressed above are      http://www.aeroflex.com/
not necessarily those of Aeroflex.   Tel: + 44 (0) 1438 742200


From rminnich at lanl.gov  Thu Jan 15 10:12:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 15 10:12:00 2004
Subject: legacy vga ... what do you think?
In-Reply-To: <m3ptdlenzj.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0401150818500.29900-100000@maxroach.lanl.gov>

On 14 Jan 2004, Eric W. Biederman wrote:

> Yes but you should not need to know which device it is.

> Looking at the code though there is a bug.  When it finds a device
> to give the legacy vga resources to it does not allocate any MMIO
> resources.  For bridges this is a normal resource so this looks
> a real bug in the generic code.  If that is why you need
> the vgadev,  let's fix the generic code to handle that part properly. 

yes, that's the bug. I waffled between a generic fix and the simple fix I 
outlined, but if you want the generic fix we can look at that too.

ron



From rminnich at lanl.gov  Thu Jan 15 10:19:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 15 10:19:00 2004
Subject: ATI M1 progress.
In-Reply-To: <40064511.9000907@bitworks.com>
Message-ID: <Pine.LNX.4.44.0401150827320.29900-100000@maxroach.lanl.gov>

On Thu, 15 Jan 2004, Richard Smith wrote:

> The vgabios emulator still chokes on the image though.  The unsuported 
> write string call somehow causes the bios to execute a halt.  Is there a 
> way I can set up a breakpoint and then drop to single stepping?

weird. I am not sure what is going on unless the emulator is returning in 
some incorrect way from that unsupported call.

ron



From ebiederman at lnxi.com  Thu Jan 15 10:41:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 15 10:41:00 2004
Subject: legacy vga ... what do you think?
In-Reply-To: <Pine.LNX.4.44.0401150818500.29900-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401150818500.29900-100000@maxroach.lanl.gov>
Message-ID: <m3fzehgqgw.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 14 Jan 2004, Eric W. Biederman wrote:
> 
> > Yes but you should not need to know which device it is.
> 
> > Looking at the code though there is a bug.  When it finds a device
> > to give the legacy vga resources to it does not allocate any MMIO
> > resources.  For bridges this is a normal resource so this looks
> > a real bug in the generic code.  If that is why you need
> > the vgadev,  let's fix the generic code to handle that part properly. 
> 
> yes, that's the bug. I waffled between a generic fix and the simple fix I 
> outlined, but if you want the generic fix we can look at that too.

Please.  Mostly it requires finding the vga card first and giving it
the appropriate resource, in a format the resource allocator can
understand.

This is a subset of a more general case that working on the superio code
made me realize needs to be done.  Ultimately we need to make a scan
of devices with known programming interfaces and to assign them legacy
resources.  serial ports, parallel ports, ide, etc.  But vga is a
good first small step.

Eric


From dwh at lanl.gov  Thu Jan 15 11:28:00 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Jan 15 11:28:00 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <40062B87.3030502@onelabs.com>
Message-ID: <Pine.LNX.4.44.0401150935440.30809-100000@ccs-mail.lanl.gov>

IIRC, SuSE also offers pretty extensive winmodem support in their 
distributions.

On Wed, 14 Jan 2004, Bari Ari wrote:

> 
> 
> Peter Lister wrote:
> 
> > Just out of interest, my laptop is a Clevo SiS unbranded, no Windows
> > job. Winmodem doesn't work, as one might expect, 
> 
> Have you looked at  http://linmodems.org/  for Linux support for the 
> Winmodem?
> 
> -Bari
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From ollie at lanl.gov  Thu Jan 15 13:14:00 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Jan 15 13:14:00 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <Pine.LNX.4.44.0401142126370.23744-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401142126370.23744-100000@maxroach.lanl.gov>
Message-ID: <1074191014.13170.142.camel@exponential.lanl.gov>

On Wed, 2004-01-14 at 21:27, ron minnich wrote:
> On Wed, 14 Jan 2004, Bari Ari wrote:
> 
> > The SiS 650 chipset was never supported by LinuxBIOS. SiS also dropped 
> > interest in LinuxBIOS last year.
> 
> :=(
> 
> But, Ollie works here now ... :=)
> 

But the problem is I can't do anything without the 
register spec acquired leaglly.

Ollie
 



From dwh at lanl.gov  Thu Jan 15 13:19:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Jan 15 13:19:01 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <1074191014.13170.142.camel@exponential.lanl.gov>
Message-ID: <Pine.LNX.4.44.0401151128050.30765-100000@ccs-mail.lanl.gov>

Surely there must be someone at SiS you can blackmail into giving you the 
spec sheet "legally."

On Thu, 15 Jan 2004, Li-Ta Lo wrote:

> On Wed, 2004-01-14 at 21:27, ron minnich wrote:
> > On Wed, 14 Jan 2004, Bari Ari wrote:
> > 
> > > The SiS 650 chipset was never supported by LinuxBIOS. SiS also dropped 
> > > interest in LinuxBIOS last year.
> > 
> > :=(
> > 
> > But, Ollie works here now ... :=)
> > 
> 
> But the problem is I can't do anything without the 
> register spec acquired leaglly.
> 
> Ollie
>  
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From dwh at lanl.gov  Thu Jan 15 13:37:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Thu Jan 15 13:37:01 2004
Subject: VGA console on S2885 with fbdev
Message-ID: <Pine.LNX.4.44.0401151135340.30765-100000@ccs-mail.lanl.gov>

If you need a VGA console for an S2885, fbdev seems to work pretty well, 
at least with the GeForce 2 MX we've tested it with. Just rip your video 
BIOS (dd if=/dev/mem of=vgabios.bin count=1536 skip=128), run testbios -s 
65336 vgabios.bin, and modprobe your fbdev driver. Only obvious issue we 
noticed was when quitting X the cursor became grossly out of proportion. 
It's really kind of funny (Assuming you have no real work to get done).

Kind of a quick workaround, but if you're desperate for a local 
console fbdev seems to be a good temporary solution.



From uszaty at tempest.com.pl  Thu Jan 15 14:16:01 2004
From: uszaty at tempest.com.pl (=?iso-8859-2?Q?Maciej_Olesi=F1ski?=)
Date: Thu Jan 15 14:16:01 2004
Subject: New LinuxBIOS user needs urgent help!
Message-ID: <002b01c3db9e$c4ad18e0$2402a8c0@suo>

Hello!

When I first encountered LinuxBIOS project at the beginning of december, I was amazed at what it can do (for example I would like to build my OWN mini router DoC distro). So the next day I found M-Sys distributor in Poland and ordered two MD2802-D08 units, because I had two spare mobo's with BX chipset. After 4 (!!!) weeks of waiting I finally got my DoCs and began my story with LinuxBIOS begun. First thaing that was wrong, was that docipl file was missing, but I tried not to bother about that. It took me a few days before I read on the linuxbios newsgroup that BX is not supported in the way I would like it to be. I also learned that SiS got very good support (now I know it HAD, but hasn't any more), so I tried to buy used SiS 630/635/730/735 chipset based mainboard, because I saw they all got ipl.S file in their folders. After one week I finally found nice board based on SiS 735 (Ellitegroup's K7S5A) and I bought it. I patched kernel for use with SiS and tried to build rom images for my new SiS. Then something terrible happened! I got error during compilation of docipl file, saying that .org instruction is moving backwards! Once again I looked up newsgroup and read that SiS 735 with DoC is _NOT_ supported. That's why I got a few questions:

1. Which *NEW* mainboard can I buy if I want to install LinuxBIOS with DoC Millenium support on it?

2. How mature is freebios2 project?

3. Does IPL code for SiS 735 initialize only DDR SDRAM (no standard SDRAM) or both? (I got normal SDRAM in my mobo)

4. If I get it right SiS 735 cannot boot off MD2802-D08 because it's IPL code is too big?

5. Any idea why my flash writer does not work on mobo ECS K7S5A, based on SiS 735 with IT8705F superio (which is 100% compatible with SiS 950)? I use "flash_on" utility for SiS and if I'm right it should work on this nb/sb/sio configuration, but "flash_rom" says "no EEPROM".

Thanks for any help,
Uszaty
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040115/6061a7fa/attachment.html>

From ollie at lanl.gov  Thu Jan 15 14:45:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Jan 15 14:45:01 2004
Subject: VGA console on S2885 with fbdev
In-Reply-To: <Pine.LNX.4.44.0401151135340.30765-100000@ccs-mail.lanl.gov>
References: <Pine.LNX.4.44.0401151135340.30765-100000@ccs-mail.lanl.gov>
Message-ID: <1074196450.13170.147.camel@exponential.lanl.gov>

On Thu, 2004-01-15 at 11:46, Hendricks David W. wrote:
> If you need a VGA console for an S2885, fbdev seems to work pretty well, 
> at least with the GeForce 2 MX we've tested it with. Just rip your video 
> BIOS (dd if=/dev/mem of=vgabios.bin count=1536 skip=128), run testbios -s 

it should be "dd if=/dev/mem of=vgabios.bin skip=1536 count=128"

You have to do this with booting by normal bios too.

> 65336 vgabios.bin, and modprobe your fbdev driver. Only obvious issue we 
> noticed was when quitting X the cursor became grossly out of proportion. 
> It's really kind of funny (Assuming you have no real work to get done).
> 
> Kind of a quick workaround, but if you're desperate for a local 
> console fbdev seems to be a good temporary solution.


I think the problem is the vgabios only do the half
of the job. It only init the device but does not set
it to any specific video mode. Under normal bios,
the system call the vga bios to set the mode. But we
do not do this in linuxbios.

Ollie




From rminnich at lanl.gov  Thu Jan 15 17:50:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 15 17:50:00 2004
Subject: legacy vga ... what do you think?
In-Reply-To: <m3fzehgqgw.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0401151558330.31203-100000@maxroach.lanl.gov>

On 15 Jan 2004, Eric W. Biederman wrote:

> ron minnich <rminnich at lanl.gov> writes:
> 
> > On 14 Jan 2004, Eric W. Biederman wrote:
> > 
> > > Yes but you should not need to know which device it is.
> > 
> > > Looking at the code though there is a bug.  When it finds a device
> > > to give the legacy vga resources to it does not allocate any MMIO
> > > resources.  For bridges this is a normal resource so this looks
> > > a real bug in the generic code.  If that is why you need
> > > the vgadev,  let's fix the generic code to handle that part properly. 
> > 
> > yes, that's the bug. I waffled between a generic fix and the simple fix I 
> > outlined, but if you want the generic fix we can look at that too.
> 
> Please.  Mostly it requires finding the vga card first and giving it
> the appropriate resource, in a format the resource allocator can
> understand.
> 
> This is a subset of a more general case that working on the superio code
> made me realize needs to be done.  Ultimately we need to make a scan
> of devices with known programming interfaces and to assign them legacy
> resources.  serial ports, parallel ports, ide, etc.  But vga is a
> good first small step.

The second problem is that the PCIO is not correctly set up for legacy vga 
either. OK, we'll look.

ron



From prl at peterlister.co.uk  Thu Jan 15 19:37:00 2004
From: prl at peterlister.co.uk (Peter Lister)
Date: Thu Jan 15 19:37:00 2004
Subject: LC2430 - laptop candidate for LinuxBIOS (Intel 845G)?
In-Reply-To: <40062B87.3030502@onelabs.com>
References: <20040110122559.GA19323@tarnica.ctnet.pl>
	 <40058C8B.20300@onelabs.com> <1074126440.5466.602.camel@eddie>
	 <40062B87.3030502@onelabs.com>
Message-ID: <1074213976.5464.1319.camel@eddie>

On Thu, 2004-01-15 at 05:56, Bari Ari wrote:

> Have you looked at  http://linmodems.org/  for Linux support for the 
> Winmodem?

Yes - can't see any support for the SiS

I have a pcmcia modem which works, and don't dial up much anyway, so I
didn't expect it to work and don't really care.





From YhLu at tyan.com  Fri Jan 16 00:45:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jan 16 00:45:01 2004
Subject: Two console in com1 and com2 in 
Message-ID: <3174569B9743D511922F00A0C943142303D8EA8F@TYANWEB>

Eric,

I wonder if it is possible to have two consoles and one is in com1 and the
other is in com2, and maybe in different baud rate.

I mean in LinuxBIOS should be OK if I add another uart8250_console2.c. but
how about Etherboot, Does it support that? Or just can only use one port?

Regards

Yinghai Lu




From ebiederman at lnxi.com  Fri Jan 16 01:00:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Jan 16 01:00:00 2004
Subject: Two console in com1 and com2 in
In-Reply-To: <3174569B9743D511922F00A0C943142303D8EA8F@TYANWEB>
References: <3174569B9743D511922F00A0C943142303D8EA8F@TYANWEB>
Message-ID: <m3oet4xw2w.fsf@maxwell.lnxi.com>

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I wonder if it is possible to have two consoles and one is in com1 and the
> other is in com2, and maybe in different baud rate.
> 
> I mean in LinuxBIOS should be OK if I add another uart8250_console2.c. but
> how about Etherboot, Does it support that? Or just can only use one port?

Etherboot would need similar modifications but it can support two
consoles as well.  What would be the gain in having two serial consoles?

Eric


From YhLu at tyan.com  Fri Jan 16 12:16:01 2004
From: YhLu at tyan.com (YhLu)
Date: Fri Jan 16 12:16:01 2004
Subject: =?gb2312?B?tPC4tDogVHdvIGNvbnNvbGUgaW4gY29tMSBhbmQgY29tMiBpbg==?=
Message-ID: <3174569B9743D511922F00A0C943142303D8EA97@TYANWEB>

Thanks,

Current our Server Management Daughter card (SMDC or IPMI card) is using
COM2 on MB to do Console redirection via LAN. So If using LinuxBIOS, I also
hope the user use COM1 for on site Console using if he he wants.

Regards

YH

-----????-----
???: ebiederman at lnxi.com [mailto:ebiederman at lnxi.com] 
????: 2004?1?15? 22:11
???: YhLu
??: ron minnich; linuxbios at clustermatic.org
??: Re: Two console in com1 and com2 in

YhLu <YhLu at tyan.com> writes:

> Eric,
> 
> I wonder if it is possible to have two consoles and one is in com1 and the
> other is in com2, and maybe in different baud rate.
> 
> I mean in LinuxBIOS should be OK if I add another uart8250_console2.c. but
> how about Etherboot, Does it support that? Or just can only use one port?

Etherboot would need similar modifications but it can support two
consoles as well.  What would be the gain in having two serial consoles?

Eric


From JJia at Fortinet.com  Mon Jan 19 12:46:01 2004
From: JJia at Fortinet.com (Jia Jianwei)
Date: Mon Jan 19 12:46:01 2004
Subject: 82845GV DDR SDRAM initialization
Message-ID: <002701c3deb5$8244ce20$3a4610ac@JiaJianwei>

     I'm now working on linux bios with 82845gv/82801db chipset. When I initialize DDR RAM, It's always hangs. When I enable NOP command and issue a memory read instruction, It hangs.  Anyone can tell me if I missed something? Any advice would be appreciated.

Best Regards,
Jianwei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040119/4a170348/attachment.html>

From rminnich at lanl.gov  Mon Jan 19 16:45:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 19 16:45:01 2004
Subject: 82845GV DDR SDRAM initialization
In-Reply-To: <002701c3deb5$8244ce20$3a4610ac@JiaJianwei>
Message-ID: <Pine.LNX.4.44.0401191454470.15205-100000@maxroach.lanl.gov>

On Mon, 19 Jan 2004, Jia Jianwei wrote:

>      I'm now working on linux bios with 82845gv/82801db chipset. When I
> initialize DDR RAM, It's always hangs. When I enable NOP command and
> issue a memory read instruction, It hangs.  Anyone can tell me if I
> missed something? Any advice would be appreciated.

This is always the hard part. Unfortunately, you are going to have to 
debug and debug until you get it.

Are you using V1 or V2?

ron



From JJia at Fortinet.com  Mon Jan 19 17:13:01 2004
From: JJia at Fortinet.com (Jia Jianwei)
Date: Mon Jan 19 17:13:01 2004
Subject: 82845GV DDR SDRAM initialization
References: <Pine.LNX.4.44.0401191454470.15205-100000@maxroach.lanl.gov>
Message-ID: <003b01c3deda$e24511c0$3a4610ac@JiaJianwei>

Thank you very much!
I'm using V1 and have changed a lot to fit our own need.

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 1:55 PM
Subject: Re: 82845GV DDR SDRAM initialization


> On Mon, 19 Jan 2004, Jia Jianwei wrote:
> 
> >      I'm now working on linux bios with 82845gv/82801db chipset. When I
> > initialize DDR RAM, It's always hangs. When I enable NOP command and
> > issue a memory read instruction, It hangs.  Anyone can tell me if I
> > missed something? Any advice would be appreciated.
> 
> This is always the hard part. Unfortunately, you are going to have to 
> debug and debug until you get it.
> 
> Are you using V1 or V2?
> 
> ron


From rminnich at lanl.gov  Mon Jan 19 17:20:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Mon Jan 19 17:20:01 2004
Subject: 82845GV DDR SDRAM initialization
In-Reply-To: <003b01c3deda$e24511c0$3a4610ac@JiaJianwei>
Message-ID: <Pine.LNX.4.44.0401191529120.15205-100000@maxroach.lanl.gov>

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 JJia at Fortinet.com  Mon Jan 19 18:33:01 2004
From: JJia at Fortinet.com (Jia Jianwei)
Date: Mon Jan 19 18:33:01 2004
Subject: 82845GV DDR SDRAM initialization
References: <Pine.LNX.4.44.0401191529120.15205-100000@maxroach.lanl.gov>
Message-ID: <004701c3dee6$0e3451a0$3a4610ac@JiaJianwei>

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 pmacv at telefonica.net  Mon Jan 19 19:02:00 2004
From: pmacv at telefonica.net (Pedro M.)
Date: Mon Jan 19 19:02:00 2004
Subject: Article
Message-ID: <003f01c3def2$a3de4290$6369cb51@usuario>

I send an interesting article about BIOS and videocard.

Suggestions wellcome ( use the wiki-edit ).

http://wiki.debian.net/index.cgi?XFreeCommon

Regards.


From stepan at suse.de  Tue Jan 20 07:47:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Jan 20 07:47:00 2004
Subject: IRQ-Tables once again
Message-ID: <20040120125744.GA5495@suse.de>

Hi,

I'm trying to factor the IRQ Table generation a bit, since the
current way to write an IRQ Table plain sucks. This means

* gather all information before actually generating the table
* gather information in a readable and adjustable way.

I juggled with the Arima Hdama irq table, since this one seems to 
work. (See attachment)

Currently I have a couple of defines that are hardcoded into the file.
This should maybe be moved to the motherboard configuration files. 
(At least I would move them and the IRQ_SLOT_COUNT together)

#define IRQ_ROUTER_BUS          1
#define IRQ_ROUTER_DEVFN        PCI_DEVFN(4,3)
#define IRQ_ROUTER_VENDOR       0x1022
#define IRQ_ROUTER_DEVICE       0x746b
#define AVAILABLE_IRQS          0xdef8

Then I substituted the longish irq table entries with a macro
IRQ_SLOT which takes the following arguments:
 * slot number
 * bus,dev,fn
 * 4* irq link line id

Example:
/* PCI Slot 1 */
IRQ_SLOT (1, 3,1,0, 2,3,4,1 ),
/* Let Linux know about bus 1 */
IRQ_SLOT (0, 1,4,3, 0,0,0,0 ),

If there are no objections, I am going to make this change in the code.
Who else is having IRQ Table trouble here?

  Stefan

-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development
-------------- next part --------------
#include <arch/pirq_routing.h>
#include <device/pci.h>

#define IRQ_ROUTER_BUS		1
#define IRQ_ROUTER_DEVFN	PCI_DEVFN(4,3)
#define IRQ_ROUTER_VENDOR	0x1022
#define IRQ_ROUTER_DEVICE	0x746b

#define AVAILABLE_IRQS 0xdef8
#define IRQ_SLOT(slot, bus, dev, fn, linka, linkb, linkc, linkd) \
	{ bus, (dev<<3)|fn, {{ linka, AVAILABLE_IRQS}, { linkb, AVAILABLE_IRQS}, \
	{linkc, AVAILABLE_IRQS}, {linkd, AVAILABLE_IRQS}}, slot, 0}

/*  Each IRQ_SLOT entry consists of:
 *  bus, devfn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu  
 */

const struct irq_routing_table intel_irq_routing_table = {
	PIRQ_SIGNATURE,		/* u32 signature */
	PIRQ_VERSION,		/* u16 version   */
	32+16*IRQ_SLOT_COUNT,	/* there can be total IRQ_SLOT_COUNT 
				 * devices on the bus */
	IRQ_ROUTER_BUS,		/* Where the interrupt router lies (bus) */
	IRQ_ROUTER_DEVFN,	/* Where the interrupt router lies (dev) */
	0x00,			/* IRQs devoted exclusively to PCI usage */
	IRQ_ROUTER_VENDOR,	/* Vendor */
	IRQ_ROUTER_DEVICE,	/* Device */
	0x00,			/* Crap (miniport) */
	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },	/* u8 rfu[11] */
	0x00,			/*  u8 checksum , mod 256 checksum must give
				 *  zero, will be corrected later 
				 */
	{

		/* slot(0=onboard), devfn, irqlinks (line id, 0=not routed) */

		/* PCI Slot 1-6 */
		IRQ_SLOT (1, 3,1,0, 2,3,4,1 ),
		IRQ_SLOT (2, 3,2,0, 3,4,1,2 ),
		IRQ_SLOT (3, 2,1,0, 2,3,4,1 ),
		IRQ_SLOT (4, 2,2,0, 3,4,1,2 ),
		IRQ_SLOT (5, 4,5,0, 2,3,4,1 ),
		IRQ_SLOT (6, 4,4,0, 1,2,3,4 ),

		/* Onboard NICs */
		IRQ_SLOT (0, 2,3,0, 4,0,0,0 ),
		IRQ_SLOT (0, 2,4,0, 4,0,0,0 ),

		/* Let Linux know about bus 1 */
		IRQ_SLOT (0, 1,4,3, 0,0,0,0 ),
	}
};

From rminnich at lanl.gov  Tue Jan 20 10:49:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jan 20 10:49:01 2004
Subject: IRQ-Tables once again
In-Reply-To: <20040120125744.GA5495@suse.de>
Message-ID: <Pine.LNX.4.44.0401200858570.23794-100000@maxroach.lanl.gov>

On Tue, 20 Jan 2004, Stefan Reinauer wrote:

> If there are no objections, I am going to make this change in the code.
> Who else is having IRQ Table trouble here?

looks fine. 

Everyone is always having trouble. It may be best if we spend future
effort on generating IRQ tables from MP tables, if that is possible.

ron



From stepan at suse.de  Tue Jan 20 11:03:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Jan 20 11:03:00 2004
Subject: IRQ-Tables once again
In-Reply-To: <20040120125744.GA5495@suse.de>
References: <20040120125744.GA5495@suse.de>
Message-ID: <20040120161214.GA31789@suse.de>

* Stefan Reinauer <stepan at suse.de> [040120 13:57]:
> I'm trying to factor the IRQ Table generation a bit, since the
> current way to write an IRQ Table plain sucks. This means
> 
> * gather all information before actually generating the table
> * gather information in a readable and adjustable way.
> 
> I juggled with the Arima Hdama irq table, since this one seems to 
> work. (See attachment)

On my Solo I still don't get further. 
The pci cards irqs get routed fine to the interrupt pins, but those
don't get any irq numbers. 

Also, if I disable the amd8111 builtin ethernet card, the system hangs.

Best regards,
  Stefan Reinauer
  
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From stepan at suse.de  Tue Jan 20 12:50:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Tue Jan 20 12:50:00 2004
Subject: IRQ-Tables once again
In-Reply-To: <Pine.LNX.4.44.0401200858570.23794-100000@maxroach.lanl.gov>
References: <20040120125744.GA5495@suse.de> <Pine.LNX.4.44.0401200858570.23794-100000@maxroach.lanl.gov>
Message-ID: <20040120180028.GA30841@suse.de>

* ron minnich <rminnich at lanl.gov> [040120 16:59]:
> looks fine. 
> 
> Everyone is always having trouble. It may be best if we spend future
> effort on generating IRQ tables from MP tables, if that is possible.

I am not sure if our current mp tables know enough of the hardware to
do so. Interrupts are often hardwired so there has to be knowledge in
LinuxBIOS on which slot gets which interrupt. 

The configuration files should contain this knowledge. 

  < Bridges > -- 1:n -- < slots > -- 1:n(m:n?) -- < irqs >

Reading the Linux kernel sources it seems that Linux _does_ expect the
devices to have interrupts assigned already, which obviously LinuxBIOS
does not do. This has to be "fixed" if LinuxBIOS shall be open to
anybody not patching special kernels that do the right thing.

Is there any way to generate a decent mptable? The result from the
mptable utility in the freebios 1 tree seems not to do it's best on
AMD systems.

If we provide tables at all, can we maybe drop the irq table and only
use the mptable?

Best regards,
  Stefan Reinauer
  
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From YhLu at tyan.com  Tue Jan 20 15:26:00 2004
From: YhLu at tyan.com (YhLu)
Date: Tue Jan 20 15:26:00 2004
Subject: =?gb2312?B?tPC4tDogSVJRLVRhYmxlcyBvbmNlIGFnYWlu?=
Message-ID: <3174569B9743D511922F00A0C943142303D8EBF3@TYANWEB>

Good, it's more readble.

-----????-----
???: Stefan Reinauer [mailto:stepan at suse.de] 
????: 2004?1?20? 4:58
???: linuxbios at clustermatic.org
??: IRQ-Tables once again

Hi,

I'm trying to factor the IRQ Table generation a bit, since the
current way to write an IRQ Table plain sucks. This means

* gather all information before actually generating the table
* gather information in a readable and adjustable way.

I juggled with the Arima Hdama irq table, since this one seems to 
work. (See attachment)

Currently I have a couple of defines that are hardcoded into the file.
This should maybe be moved to the motherboard configuration files. 
(At least I would move them and the IRQ_SLOT_COUNT together)

#define IRQ_ROUTER_BUS          1
#define IRQ_ROUTER_DEVFN        PCI_DEVFN(4,3)
#define IRQ_ROUTER_VENDOR       0x1022
#define IRQ_ROUTER_DEVICE       0x746b
#define AVAILABLE_IRQS          0xdef8

Then I substituted the longish irq table entries with a macro
IRQ_SLOT which takes the following arguments:
 * slot number
 * bus,dev,fn
 * 4* irq link line id

Example:
/* PCI Slot 1 */
IRQ_SLOT (1, 3,1,0, 2,3,4,1 ),
/* Let Linux know about bus 1 */
IRQ_SLOT (0, 1,4,3, 0,0,0,0 ),

If there are no objections, I am going to make this change in the code.
Who else is having IRQ Table trouble here?

  Stefan

-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From rminnich at lanl.gov  Wed Jan 21 01:25:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 21 01:25:01 2004
Subject: IRQ-Tables once again
In-Reply-To: <20040120180028.GA30841@suse.de>
Message-ID: <Pine.LNX.4.44.0401202334050.29507-100000@maxroach.lanl.gov>

On Tue, 20 Jan 2004, Stefan Reinauer wrote:

> Reading the Linux kernel sources it seems that Linux _does_ expect the
> devices to have interrupts assigned already, which obviously LinuxBIOS
> does not do. This has to be "fixed" if LinuxBIOS shall be open to
> anybody not patching special kernels that do the right thing.

no. In 2.4, in the right circumstances, the kernel can assign interrupts 
just fine. 

> If we provide tables at all, can we maybe drop the irq table and only
> use the mptable?

no, sadly the kernel needs an irq table for pci bus scanning.

ron



From P.W.deBruin at ewi.tudelft.nl  Wed Jan 21 04:40:00 2004
From: P.W.deBruin at ewi.tudelft.nl (Paul de Bruin)
Date: Wed Jan 21 04:40:00 2004
Subject: EPIA V-series tv out questions
Message-ID: <20040121095055.GA1463@dutids.twi.tudelft.nl>

Hi all,

I am working on a project involving an epia-v box (the 533MHz, fanless
ones).  For our application it is important that the tv out is disabled
during the booting sequence and enabled at a later point. Unfortunately,
the machine's bios does not have an option to disable tv out.

Enter LinuxBios. A bios saviour is on order, and in the mean time I am
hoping that someone here can point me in the right direction or has
experience with the following:

1. If the original vgabios is not included with linuxbios, is it
   possible to initialise the graphics card and tv out after booting
   using tridentfb/epiafb and the tvtool from
   http://epiafb.sourceforge.net ?

2. If the original vgabios is included, will it automatically enable
   tv out at boot time?

3. With the vgabios, is it possible to use vesafb?

4. Does anyone have experience with "tweaking" the vgabios, for example 
   to disable the automatic tv detection?

Any help and/or info is greatly appreciated,
Regards,
Paul

-- 
 --------------------------------------------------------------- 
| ir. P.W. de Bruin, Delft University of Technology             |
| Faculty of Information Technology and Systems                 |
| http://visualisation.tudelft.nl/~paul         PGP-ID:CD36D25B |
 ---------------------------------------------------------------


From stepan at suse.de  Thu Jan 22 05:56:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Jan 22 05:56:01 2004
Subject: IRQ-Tables once again
In-Reply-To: <Pine.LNX.4.44.0401202334050.29507-100000@maxroach.lanl.gov>
References: <20040120180028.GA30841@suse.de> <Pine.LNX.4.44.0401202334050.29507-100000@maxroach.lanl.gov>
Message-ID: <20040122110619.GA18350@suse.de>

* ron minnich <rminnich at lanl.gov> [040121 07:35]:
> > If we provide tables at all, can we maybe drop the irq table and only
> > use the mptable?
> 
> no, sadly the kernel needs an irq table for pci bus scanning.

good. things seem to work now. Except that the secondary bus of the 
8151 gets set to 0, where it seems that in our case this should be 2
(the AGP device is visible on bus 2) Don't think this matters though

  Stefan

-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From armijn at uulug.nl  Thu Jan 22 08:40:00 2004
From: armijn at uulug.nl (Armijn Hemel)
Date: Thu Jan 22 08:40:00 2004
Subject: LinuxBIOS questions
Message-ID: <20040122135107.GE32520@uulug.nl>

hello all,

for the Dutch Linux Magazine (http://www.linuxmag.nl/) I'm writing an
article about open source hardware and LinuxBIOS is one of the projects
I will mention. I have a question which does not seem to be answered
in the FAQ.

Do I really need to remove the normal BIOS from a machine, insert a ZIF
socket, etc.? I read an article (British Linux Magazine) which suggests
that you always have to, but when I read the LinuxBIOS pages I start
to wonder...

If it's not the case, any chance that LinuxBIOS will work for a Dell
Optiplex GX1 system (Intel 440BX PIIX4e chipset)? I already took a look
and you can't remove the BIOS, which I'd like to have replaced, because
it freaks me out and has wasted hours of precious time.

armijn

-- 
 ---------------------------------------------------------------------------
  armijn at uulug.nl | http://www.uulug.nl/ | UULug: Utrecht Linux Users Group
 ---------------------------------------------------------------------------


From ollie at lanl.gov  Thu Jan 22 11:12:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Thu Jan 22 11:12:01 2004
Subject: IRQ-Tables once again
In-Reply-To: <20040122110619.GA18350@suse.de>
References: <20040120180028.GA30841@suse.de>
	 <Pine.LNX.4.44.0401202334050.29507-100000@maxroach.lanl.gov>
	 <20040122110619.GA18350@suse.de>
Message-ID: <1074788577.6434.35.camel@exponential.lanl.gov>

On Thu, 2004-01-22 at 04:06, Stefan Reinauer wrote:
> * ron minnich <rminnich at lanl.gov> [040121 07:35]:
> > > If we provide tables at all, can we maybe drop the irq table and only
> > > use the mptable?
> > 
> > no, sadly the kernel needs an irq table for pci bus scanning.
> 
> good. things seem to work now. Except that the secondary bus of the 
> 8151 gets set to 0, where it seems that in our case this should be 2
> (the AGP device is visible on bus 2) Don't think this matters though
> 
>   Stefan

Did you just dump the IRQ table from normal BIOS and put it in
LinuxBIOS ?

That is the same problem we found here. The normal BIOS tries to make
the secondary bus of 8151 as bus 0. It also tries to hide the bridge
from IRQ and/or MP table.

The way we are configuring the PCI system is too different from
what normal BIOS does on K8 systems. We can't just dump the table
from BIOS and expect it to work anymore.

Ollie 




From rminnich at lanl.gov  Thu Jan 22 11:20:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 22 11:20:01 2004
Subject: LinuxBIOS questions
In-Reply-To: <20040122135107.GE32520@uulug.nl>
Message-ID: <Pine.LNX.4.44.0401220926340.10597-100000@maxroach.lanl.gov>

On Thu, 22 Jan 2004, Armijn Hemel wrote:

> for the Dutch Linux Magazine (http://www.linuxmag.nl/) I'm writing an
> article about open source hardware and LinuxBIOS is one of the projects
> I will mention. I have a question which does not seem to be answered
> in the FAQ.

no, we reprogram machines all the time without yanking the flash or 
inserting ZIF. We just reprogrammed linuxbios on a 1024-node cluster, 
for example, and we did not yank any parts. BUT, you'd better have a 
working linuxbios for that system! You have to test it on a development 
system. 

> Do I really need to remove the normal BIOS from a machine, insert a ZIF
> socket, etc.? 

No, but the FLASH process will replace that BIOS with linuxbios. 


Sorry about your Dell, but Dell has been very unwilling to help, so I 
don't think it will work.

ron



From andy.pearce at austrocontrol.at  Thu Jan 22 11:23:01 2004
From: andy.pearce at austrocontrol.at (Andy Pearce)
Date: Thu Jan 22 11:23:01 2004
Subject: Replacement for console level access on ALPHAs
Message-ID: <OGEMKDIFPJHJACJMGAPBKEMNCGAA.andy.pearce@austrocontrol.at>

We currently run a set of systems that operator on DEC Alpha machines, these
provide
a console level access which we use to configure a machine remotely via the
console
port. Plans are afoot to migrate the systems running on the Alphas to PC (HP
xw4100 machines),
we will still however have the requirement to access and manage the machines
when the
main OS is down, select which kernel versions should be run etc.

Based on what I have read about Linux Bios it seems it would be perfect for
this task.

Does anyone have any idea of the likelihood of the HP xw4100s motherboard
being able to
support LinuxBios.

Many thanks

Andy Pearce


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

From rsmith at bitworks.com  Thu Jan 22 11:27:00 2004
From: rsmith at bitworks.com (Richard Smith)
Date: Thu Jan 22 11:27:00 2004
Subject: LinuxBIOS questions
In-Reply-To: <20040122135107.GE32520@uulug.nl>
References: <20040122135107.GE32520@uulug.nl>
Message-ID: <400FFC40.3040100@bitworks.com>

Armijn Hemel wrote:

> Do I really need to remove the normal BIOS from a machine, insert a
> ZIF socket, etc.? I read an article (British Linux Magazine) which
> suggests that you always have to, but when I read the LinuxBIOS pages
> I start to wonder...

> If it's not the case, any chance that LinuxBIOS will work for a Dell 
> Optiplex GX1 system (Intel 440BX PIIX4e chipset)? I already took a
> look and you can't remove the BIOS, which I'd like to have replaced,
> because it freaks me out and has wasted hours of precious time.

Since your chips are soldered to the pcb things are going to be a little 
more difficult.  As if you flash in something that dosen't work then 
your board is toast.  Do you know if your stock bios has a "recovery" 
method?  If it does then you can use that to flash in a new copy of the 
bios if you get something that dosen't boot.

The 440BX is pretty much fully supported.  The freebios (as opposed to 
the new freebios2) tree will set up and enable everything except the 
power management system.  Unless this is a laptop you shouldn't need the 
power managment stuff.

This assumes that Dell does not do something special to enable the SPD 
signals to the RAM.  Setup is not fully automatic though and parts of 
the code will have to be customized to your system.

Usually the only way to really find this stuff out is to boot LinuxBIOS 
and see what happens.  Thus the danger of winding up with a paper weight.

You need to know things such as how your PCI IRQs are routed, and other 
stuff.  I tried to keep all the custom options of our board specific to 
the "bitworks/IMS" config but I would not be suprised if there was 
something lurking in the main tree that only worked on an IMS system.  I 
added lots of code.

-- 
Richard A. Smith
rsmith at bitworks.com




From rminnich at lanl.gov  Thu Jan 22 11:48:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 22 11:48:00 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <OGEMKDIFPJHJACJMGAPBKEMNCGAA.andy.pearce@austrocontrol.at>
Message-ID: <Pine.LNX.4.44.0401220957400.10597-100000@maxroach.lanl.gov>

crack open those HP machines, and see if they are a supported mobo. My 
guess is they are serverworks chipset, which means no good thing, as 
serverworks absolutely refuses to help with linuxbios. 

Or send an lspci and we can see.

ron



From stepan at suse.de  Thu Jan 22 14:21:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Jan 22 14:21:00 2004
Subject: IRQ-Tables once again
In-Reply-To: <1074788577.6434.35.camel@exponential.lanl.gov>
References: <20040120180028.GA30841@suse.de> <Pine.LNX.4.44.0401202334050.29507-100000@maxroach.lanl.gov> <20040122110619.GA18350@suse.de> <1074788577.6434.35.camel@exponential.lanl.gov>
Message-ID: <20040122192636.GA1631@suse.de>

* Li-Ta Lo <ollie at lanl.gov> [040122 17:22]:
> > good. things seem to work now. Except that the secondary bus of the 
> > 8151 gets set to 0, where it seems that in our case this should be 2
> > (the AGP device is visible on bus 2) Don't think this matters though
 
> Did you just dump the IRQ table from normal BIOS and put it in
> LinuxBIOS ?

> That is the same problem we found here. The normal BIOS tries to make
> the secondary bus of 8151 as bus 0. It also tries to hide the bridge
> from IRQ and/or MP table.

My assumption that the secondary bus is 0 on the 8151 comes from reading
the SECONDARY_BUS register while creating the mptable. 

This happens before the irq table is used for the first time.

Some  pirq tables I've looked at showed the complete device tree of 
the machine, including the 2 cpus and all the bridges. We could probably
generate a lot of this information automatically already.
For getting the slots described right we need an additional slot
command/tag in the config mechanism. 
Then we could just walk over all north/southbridges and generate both
an irq table and an mptable from the device tree.

Stefan  

-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From ebiederman at lnxi.com  Thu Jan 22 14:50:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 22 14:50:00 2004
Subject: IRQ-Tables once again
In-Reply-To: <20040122192636.GA1631@suse.de>
References: <20040120180028.GA30841@suse.de>
	<Pine.LNX.4.44.0401202334050.29507-100000@maxroach.lanl.gov>
	<20040122110619.GA18350@suse.de>
	<1074788577.6434.35.camel@exponential.lanl.gov>
	<20040122192636.GA1631@suse.de>
Message-ID: <m3smi721lz.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> * Li-Ta Lo <ollie at lanl.gov> [040122 17:22]:
> > > good. things seem to work now. Except that the secondary bus of the 
> > > 8151 gets set to 0, where it seems that in our case this should be 2
> > > (the AGP device is visible on bus 2) Don't think this matters though
>  
> > Did you just dump the IRQ table from normal BIOS and put it in
> > LinuxBIOS ?
> 
> > That is the same problem we found here. The normal BIOS tries to make
> > the secondary bus of 8151 as bus 0. It also tries to hide the bridge
> > from IRQ and/or MP table.
> 
> My assumption that the secondary bus is 0 on the 8151 comes from reading
> the SECONDARY_BUS register while creating the mptable. 

Hmm.  That sounds like a bug.
 
> This happens before the irq table is used for the first time.
> 
> Some  pirq tables I've looked at showed the complete device tree of 
> the machine, including the 2 cpus and all the bridges. We could probably
> generate a lot of this information automatically already.
> For getting the slots described right we need an additional slot
> command/tag in the config mechanism. 
> Then we could just walk over all north/southbridges and generate both
> an irq table and an mptable from the device tree.

That is one of my informal requirements for a stable freebios 2.0 release.
To be able to generate the mptable and irq tables from the device tree.

Eric


From ebiederman at lnxi.com  Thu Jan 22 14:53:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 22 14:53:00 2004
Subject: IRQ-Tables once again
In-Reply-To: <20040120125744.GA5495@suse.de>
References: <20040120125744.GA5495@suse.de>
Message-ID: <m3oesv21ht.fsf@maxwell.lnxi.com>

Stefan Reinauer <stepan at suse.de> writes:

> Hi,
> 
> I'm trying to factor the IRQ Table generation a bit, since the
> current way to write an IRQ Table plain sucks. This means
> 
> * gather all information before actually generating the table
> * gather information in a readable and adjustable way.
> 
> I juggled with the Arima Hdama irq table, since this one seems to 
> work. (See attachment)
> 
> Currently I have a couple of defines that are hardcoded into the file.
> This should maybe be moved to the motherboard configuration files. 
> (At least I would move them and the IRQ_SLOT_COUNT together)
> 
> #define IRQ_ROUTER_BUS          1
> #define IRQ_ROUTER_DEVFN        PCI_DEVFN(4,3)
> #define IRQ_ROUTER_VENDOR       0x1022
> #define IRQ_ROUTER_DEVICE       0x746b
> #define AVAILABLE_IRQS          0xdef8
> 
> Then I substituted the longish irq table entries with a macro
> IRQ_SLOT which takes the following arguments:
>  * slot number
>  * bus,dev,fn
>  * 4* irq link line id
> 
> Example:
> /* PCI Slot 1 */
> IRQ_SLOT (1, 3,1,0, 2,3,4,1 ),
> /* Let Linux know about bus 1 */
> IRQ_SLOT (0, 1,4,3, 0,0,0,0 ),
> 
> If there are no objections, I am going to make this change in the code.
> Who else is having IRQ Table trouble here?

Sounds like a good small step.  I object only on the grounds
it does not go far enough.  We should go at least as far as
we have with mptable generation, so we can be isolated from
bus renumbering.  And preferably we should go all of the way
to generating it from the device tree.

Eric


From ebiederman at lnxi.com  Thu Jan 22 14:56:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 22 14:56:00 2004
Subject: IRQ-Tables once again
In-Reply-To: <Pine.LNX.4.44.0401202334050.29507-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401202334050.29507-100000@maxroach.lanl.gov>
Message-ID: <m3isj321as.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On Tue, 20 Jan 2004, Stefan Reinauer wrote:
> 
> > Reading the Linux kernel sources it seems that Linux _does_ expect the
> > devices to have interrupts assigned already, which obviously LinuxBIOS
> > does not do. This has to be "fixed" if LinuxBIOS shall be open to
> > anybody not patching special kernels that do the right thing.
> 
> no. In 2.4, in the right circumstances, the kernel can assign interrupts 
> just fine. 

However the statement is still true that it is desirable that we
assign irqs to support non linux operating systems.

We should have enough information to do so when we can generate
the irq tables from the device tree.
 
> > If we provide tables at all, can we maybe drop the irq table and only
> > use the mptable?
> 
> no, sadly the kernel needs an irq table for pci bus scanning.

In particular when the kernel does not see a pci-pci bridge
going to a pci bus, it will not scan it unless it sees it in pirq
table.  This is only true of the i386 kernel.  The x86-64 kernel uses
different logic to accomplish the same thing.

Regardless if we can our house it order it will be easy to provide
kernels with what they need.

Eric


From rminnich at lanl.gov  Thu Jan 22 15:01:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 22 15:01:01 2004
Subject: IRQ-Tables once again
In-Reply-To: <m3isj321as.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0401221311190.10597-100000@maxroach.lanl.gov>

On 22 Jan 2004, Eric W. Biederman wrote:

> > no. In 2.4, in the right circumstances, the kernel can assign interrupts 
> > just fine. 
> 
> However the statement is still true that it is desirable that we
> assign irqs to support non linux operating systems.
> 

yes, that is why we've started plugging support in: we needed it for EPIA
for Plan 9 ...

ron



From ebiederman at lnxi.com  Thu Jan 22 15:10:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 22 15:10:01 2004
Subject: LinuxBIOS questions
In-Reply-To: <20040122135107.GE32520@uulug.nl>
References: <20040122135107.GE32520@uulug.nl>
Message-ID: <m3d69b20nj.fsf@maxwell.lnxi.com>

Armijn Hemel <armijn at uulug.nl> writes:

> hello all,
> 
> for the Dutch Linux Magazine (http://www.linuxmag.nl/) I'm writing an
> article about open source hardware and LinuxBIOS is one of the projects
> I will mention. I have a question which does not seem to be answered
> in the FAQ.
> 
> Do I really need to remove the normal BIOS from a machine, insert a ZIF
> socket, etc.? I read an article (British Linux Magazine) which suggests
> that you always have to, but when I read the LinuxBIOS pages I start
> to wonder...
> 
> If it's not the case, any chance that LinuxBIOS will work for a Dell
> Optiplex GX1 system (Intel 440BX PIIX4e chipset)? I already took a look
> and you can't remove the BIOS, which I'd like to have replaced, because
> it freaks me out and has wasted hours of precious time.

There are two important cases.
1) Development machines.
2) Production machines.

On production machines you can have things soldered on with no
problem.

On a development machine you want some insurance against misflashing
the BIOS.

There is some safety with linuxbios on development machines as it is
typically configured to have two copies of the firmware on the ROM
chip.

As for getting a socket on a board without one for people who
have the skill removing a rom chip and soldering in a socket is
fairly doable.

The minimum requirements for developing LinuxBIOS are:
1) a method for recovering from a bad flash (usually a socketed rom chip)
2) a serial console.
3) Documentation...
4) Time

With all of those you can probably do a complete LinuxBIOS port.

Eric


From ebiederman at lnxi.com  Thu Jan 22 15:14:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 22 15:14:00 2004
Subject: IRQ-Tables once again
In-Reply-To: <Pine.LNX.4.44.0401221311190.10597-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401221311190.10597-100000@maxroach.lanl.gov>
Message-ID: <m33ca7zq3o.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 22 Jan 2004, Eric W. Biederman wrote:
> 
> > > no. In 2.4, in the right circumstances, the kernel can assign interrupts 
> > > just fine. 
> > 
> > However the statement is still true that it is desirable that we
> > assign irqs to support non linux operating systems.
> > 
> 
> yes, that is why we've started plugging support in: we needed it for EPIA
> for Plan 9 ...

And to be very clear the reason it is needed for the EPIA
is that VIA is slightly out of spec.  VIA chipsets instead
of just providing a scratch irq register, actually interpret
the value of that register for irq routing.

So while a general purpose solution should work in the EPIA case
the via chipsets may still require special casing.  Although
hopefully we can abstract an irq router well enough we won't
have to worry about it.

Eric


From ebiederman at lnxi.com  Thu Jan 22 15:18:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 22 15:18:00 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <Pine.LNX.4.44.0401220957400.10597-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401220957400.10597-100000@maxroach.lanl.gov>
Message-ID: <m3y8rzybdm.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> crack open those HP machines, and see if they are a supported mobo. My 
> guess is they are serverworks chipset, which means no good thing, as 
> serverworks absolutely refuses to help with linuxbios. 

I would not say that serverworks is a lost cause.  But it
is quite true that no one has yet succeeded in getting
traction while working with them.

> Or send an lspci and we can see.

Given the number of heatsinks on important boards lspci
tends to be a better way of recognizing high level chips.

Eric


From rminnich at lanl.gov  Thu Jan 22 15:58:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 22 15:58:00 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <m3y8rzybdm.fsf@maxwell.lnxi.com>
Message-ID: <Pine.LNX.4.44.0401221407390.10597-100000@maxroach.lanl.gov>

On 22 Jan 2004, Eric W. Biederman wrote:

> I would not say that serverworks is a lost cause.  But it
> is quite true that no one has yet succeeded in getting
> traction while working with them.

yes, but having had an nda for a year with them (2000-2001), and having
had 0 help from them in that time, I am not hopeful.

ron



From ebiederman at lnxi.com  Thu Jan 22 18:27:00 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 22 18:27:00 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <Pine.LNX.4.44.0401221407390.10597-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401221407390.10597-100000@maxroach.lanl.gov>
Message-ID: <m34qund038.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 22 Jan 2004, Eric W. Biederman wrote:
> 
> > I would not say that serverworks is a lost cause.  But it
> > is quite true that no one has yet succeeded in getting
> > traction while working with them.
> 
> yes, but having had an nda for a year with them (2000-2001), and having
> had 0 help from them in that time, I am not hopeful.

I have seen a little more than that.  Not quite enough to do a port
yet but I have seen documentation.

Eric


From ebiederman at lnxi.com  Thu Jan 22 18:29:58 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 22 18:29:58 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <Pine.LNX.4.44.0401221407390.10597-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401221407390.10597-100000@maxroach.lanl.gov>
Message-ID: <m34qund038.fsf@maxwell.lnxi.com>

ron minnich <rminnich at lanl.gov> writes:

> On 22 Jan 2004, Eric W. Biederman wrote:
> 
> > I would not say that serverworks is a lost cause.  But it
> > is quite true that no one has yet succeeded in getting
> > traction while working with them.
> 
> yes, but having had an nda for a year with them (2000-2001), and having
> had 0 help from them in that time, I am not hopeful.

I have seen a little more than that.  Not quite enough to do a port
yet but I have seen documentation.

Eric


From ebiederman at lnxi.com  Thu Jan 22 18:36:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Thu Jan 22 18:36:01 2004
Subject: Bit banging SPD code
In-Reply-To: <NEBBJLECKKOPJEEKNGJOGEFEEDAA.peter.fox@aeroflex.com>
References: <NEBBJLECKKOPJEEKNGJOGEFEEDAA.peter.fox@aeroflex.com>
Message-ID: <m3zncfbl4q.fsf@maxwell.lnxi.com>

"Peter Fox" <peter.fox at aeroflex.com> writes:

> I would like to make the STPC elite ram initialisation use SPD info.
> 
> I notice that all the existing SDRAM initialisation that uses
> SPD seems to use some kind of SPD controller. Is this true ?

Yes.
 
> The STPC elite only provides a bit banging SPD interface, has
> anyone implemented smbus_read_byte etc with a bit banging interface ?

Not for LinuxBIOS so it looks like you have some work ahead of you.
On the plus side a bit banging interface since you get more control
provides the opportunity for more robust error handling.

Eric


From peter.fox at aeroflex.com  Fri Jan 23 04:27:01 2004
From: peter.fox at aeroflex.com (Peter Fox)
Date: Fri Jan 23 04:27:01 2004
Subject: A new timer.c for FILO
In-Reply-To: <NHBBJNOBEJCDFKDDBLLMCEAKCIAA.peter.fox@aeroflex.com>
Message-ID: <NHBBJNOBEJCDFKDDBLLMEEJKCIAA.peter.fox@aeroflex.com>

There was a bug where the timer gate wasn't turned on if only
currticks was called.

-- 
Peter Fox <peter.fox at aeroflex.com>     Aeroflex Test Solutions
Principal Design Engineer                            Stevenage
Any opinions expressed above are      http://www.aeroflex.com/
not necessarily those of Aeroflex.   Tel: + 44 (0) 1438 742200

  -----Original Message-----
  From: linuxbios-admin at clustermatic.org
  [mailto:linuxbios-admin at clustermatic.org]On Behalf Of Peter Fox
  Sent: 10 November 2003 15:30
  To: Takeshi Sone
  Cc: Linuxbios
  Subject: RE: How to use Filo as a payload ?
  
  
  That's it.
  
  I hacked together a new timer.c based on freebios/src/pc80/udelay_timer2.c
  
  You may want to offer it as an alternative, but then again, maybe not.
  
  I can now boot linux using filo !
  
  Thanks for all your help.
  
  -- 
  Peter Fox <peter.fox at aeroflex.com>     Aeroflex Test Solutions
  Principal Design Engineer                            Stevenage
  Any opinions expressed above are      http://www.aeroflex.com/
  not necessarily those of Aeroflex.   Tel: + 44 (0) 1438 742200
  
    -----Original Message-----
    From: Takeshi Sone [mailto:ts1 at tsn.or.jp]
    Sent: 10 November 2003 13:00
    To: Peter Fox
    Cc: Linuxbios
    Subject: Re: How to use Filo as a payload ?
    
    
    On Mon, Nov 10, 2003 at 12:45:27PM -0000, Peter Fox wrote:
    > I don't think so. It is the 486 core in an stpc elite.
    > It just claims Industry standard 486 compatibility.
    > 
    > In their published instruction set summary, which
    > appears to be in alphabetical order, there is
    > RCR, then REP INS.
    
    Maybe RDTSC causes invalid opcode exception, and since there is no
    exception handler, the CPU resets.
    
    filo/i386/timer.c must be re-written to support pre-Pentium CPUs.
    -- 
    Takeshi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timer.c
Type: application/octet-stream
Size: 1409 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040123/f71196c4/attachment.obj>

From andy.pearce at austrocontrol.at  Fri Jan 23 10:20:01 2004
From: andy.pearce at austrocontrol.at (Andy Pearce)
Date: Fri Jan 23 10:20:01 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <Pine.LNX.4.44.0401221407390.10597-100000@maxroach.lanl.gov>
Message-ID: <OGEMKDIFPJHJACJMGAPBGENECGAA.andy.pearce@austrocontrol.at>

Here is the lspci listing for the HP machine, so are we talking hopeful or
no hope ?

Thanks

Andy

======================================================================
# lspci -xxv
00:00.0 Host bridge: Intel Corp.: Unknown device 2578 (rev 02)
Subsystem: Hewlett-Packard Company: Unknown device 12bf
Flags: bus master, fast devsel, latency 0
Memory at e8000000 (32-bit, prefetchable) [size=128M]
Capabilities: [e4] #09 [2106]
Capabilities: [a0] AGP version 3.0
00: 86 80 78 25 06 01 90 20 02 00 00 06 00 00 00 00
10: 08 00 00 e8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
30: 00 00 00 00 e4 00 00 00 00 00 00 00 00 00 00 00
00:01.0 PCI bridge: Intel Corp.: Unknown device 2579 (rev 02) (prog-if
00 [Normal decode])
Flags: bus master, 66Mhz, fast devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
Memory behind bridge: f9000000-fa1fffff
Prefetchable memory behind bridge: f0000000-f81fffff
00: 86 80 79 25 07 01 a0 00 02 00 04 06 00 40 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 20 f0 00 a0 22
20: 00 f9 10 fa 00 f0 10 f8 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00
00:1d.0 USB Controller: Intel Corp. 82801EB USB (Hub #1) (rev 02)
(prog-if 00 [UHCI])
Subsystem: Hewlett-Packard Company: Unknown device 12bf
Flags: bus master, medium devsel, latency 0, IRQ 10
I/O ports at 2440 [size=32]
00: 86 80 d2 24 05 00 80 02 02 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 41 24 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
00:1d.1 USB Controller: Intel Corp. 82801EB USB (Hub #2) (rev 02)
(prog-if 00 [UHCI])
Subsystem: Hewlett-Packard Company: Unknown device 12bf
Flags: bus master, medium devsel, latency 0, IRQ 5
I/O ports at 2460 [size=32]
00: 86 80 d4 24 05 00 80 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 61 24 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
30: 00 00 00 00 00 00 00 00 00 00 00 00 05 02 00 00
00:1d.2 USB Controller: Intel Corp. 82801EB USB (Hub #3) (rev 02)
(prog-if 00 [UHCI])
Subsystem: Hewlett-Packard Company: Unknown device 12bf
Flags: bus master, medium devsel, latency 0, IRQ 10
I/O ports at 2480 [size=32]
00: 86 80 d7 24 05 00 80 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 24 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 03 00 00
00:1d.7 USB Controller: Intel Corp. 82801EB USB EHCI Controller (rev 02)
(prog-if 20 [EHCI])
Subsystem: Hewlett-Packard Company: Unknown device 12bf
Flags: bus master, medium devsel, latency 0, IRQ 11
Memory at f8500000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] #0a [20a0]
00: 86 80 dd 24 06 01 90 02 02 20 03 0c 00 00 00 00
10: 00 00 50 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 04 00 00
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev c2)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=05, subordinate=05, sec-latency=64
I/O behind bridge: 00001000-00001fff
Memory behind bridge: f8200000-f84fffff
00: 86 80 4e 24 07 01 80 00 c2 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 05 05 40 10 10 80 22
20: 20 f8 40 f8 f0 ff 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 00
00:1f.0 ISA bridge: Intel Corp. 82801EB ISA Bridge (LPC) (rev 02)
Flags: bus master, medium devsel, latency 0
00: 86 80 d0 24 0f 01 80 02 02 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:1f.1 IDE interface: Intel Corp. 82801EB ICH5 IDE (rev 02) (prog-if 8a
[Master SecP PriP])
Subsystem: Hewlett-Packard Company: Unknown device 12bf
Flags: bus master, medium devsel, latency 0, IRQ 10
I/O ports at <ignored>
I/O ports at <ignored>
I/O ports at <ignored>
I/O ports at <ignored>
I/O ports at 24c0 [size=16]
Memory at 20000000 (32-bit, non-prefetchable) [size=1K]
00: 86 80 db 24 07 00 88 02 02 8a 01 01 00 00 00 00
10: e1 24 00 00 01 28 00 00 e9 24 00 00 05 28 00 00
20: c1 24 00 00 00 00 00 20 00 00 00 00 3c 10 bf 12
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
00:1f.2 IDE interface: Intel Corp.: Unknown device 24d1 (rev 02)
(prog-if 8f [Master SecP SecO PriP PriO])
Subsystem: Hewlett-Packard Company: Unknown device 12bf
Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 10
I/O ports at 24f0 [size=8]
I/O ports at 2808 [size=4]
I/O ports at 24f8 [size=8]
I/O ports at 280c [size=4]
I/O ports at 24d0 [size=16]
00: 86 80 d1 24 05 00 a0 02 02 8f 01 01 00 00 00 00
10: f1 24 00 00 09 28 00 00 f9 24 00 00 0d 28 00 00
20: d1 24 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
00:1f.5 Multimedia audio controller: Intel Corp. 82801EB AC'97 Audio
(rev 02)
Subsystem: Hewlett-Packard Company: Unknown device 12bf
Flags: bus master, medium devsel, latency 0, IRQ 5
I/O ports at 2000 [size=256]
I/O ports at 2400 [size=64]
Memory at f8500400 (32-bit, non-prefetchable) [size=512]
Memory at f8500600 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
00: 86 80 d5 24 07 00 90 02 02 00 01 04 00 00 00 00
10: 01 20 00 00 01 24 00 00 00 04 50 f8 00 06 50 f8
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
30: 00 00 00 00 50 00 00 00 00 00 00 00 05 02 00 00
01:00.0 VGA compatible controller: nVidia Corporation NV18GL [Quadro4
380 XGL] (rev a2) (prog-if 00 [VGA])
Subsystem: nVidia Corporation: Unknown device 0169
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 10
Memory at f9000000 (32-bit, non-prefetchable) [size=16M]
Memory at f0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Capabilities: [44] AGP version 3.0
00: de 10 8b 01 07 00 b0 02 a2 00 00 03 00 40 00 00
10: 00 00 00 f9 08 00 00 f0 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 69 01
30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 05 01
05:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5782
Gigabit Ethernet (rev 03)
Subsystem: Hewlett-Packard Company: Unknown device 12bf
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 5
Memory at f8420000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] Message Signalled Interrupts: 64bit+
Queue=0/3 Enable-
00: e4 14 96 16 06 01 b0 02 03 00 00 02 10 40 00 00
10: 04 00 42 f8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 07 00 00 00 3c 10 bf 12
30: 00 00 00 00 48 00 00 00 00 00 00 00 05 01 40 00
05:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 0c)
Subsystem: Intel Corp. EtherExpress PRO/100 S Desktop Adapter
Flags: bus master, medium devsel, latency 66, IRQ 10
Memory at f8430000 (32-bit, non-prefetchable) [size=4K]
I/O ports at 1000 [size=64]
Memory at f8400000 (32-bit, non-prefetchable) [size=128K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
00: 86 80 29 12 07 01 90 02 0c 00 00 02 10 42 00 00
10: 00 00 43 f8 01 10 00 00 00 00 40 f8 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 40 00
30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 08 38

> -----Original Message-----
> From: ron minnich [mailto:rminnich at lanl.gov]
> Sent: Thursday, January 22, 2004 10:09 PM
> To: Eric W. Biederman
> Cc: Andy Pearce; linuxbios at clustermatic.org
> Subject: Re: Replacement for console level access on ALPHAs
>
>
> On 22 Jan 2004, Eric W. Biederman wrote:
>
> > I would not say that serverworks is a lost cause.  But it
> > is quite true that no one has yet succeeded in getting
> > traction while working with them.
>
> yes, but having had an nda for a year with them (2000-2001), and having
> had 0 help from them in that time, I am not hopeful.
>
> ron
>
>



From ebiederman at lnxi.com  Fri Jan 23 15:09:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Fri Jan 23 15:09:01 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <OGEMKDIFPJHJACJMGAPBGENECGAA.andy.pearce@austrocontrol.at>
References: <OGEMKDIFPJHJACJMGAPBGENECGAA.andy.pearce@austrocontrol.at>
Message-ID: <m3k73i8lfy.fsf@maxwell.lnxi.com>

Andy Pearce <andy.pearce at austrocontrol.at> writes:

> Here is the lspci listing for the HP machine, so are we talking hopeful or
> no hope ?

Well it is some intel chipset so there is a possibility of things working.

Eric


From dwh at lanl.gov  Fri Jan 23 16:23:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Fri Jan 23 16:23:01 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <OGEMKDIFPJHJACJMGAPBGENECGAA.andy.pearce@austrocontrol.at>
Message-ID: <Pine.LNX.4.44.0401231424490.17522-100000@ccs-mail.lanl.gov>

It looks to be a newer version of the chipset on the Supermicro P4DP6 or 
P4DPR or something (I hate Supermicro's naming conventions) using the 
82801DB (ICH4) and 82801CA (ICH3). As I recall, Eric Beiderman had at 
least one of those working. Dig around in the freebios (Not freebios2) 
tree. 

Is there a huge difference between the 82801CA/DB/EB? At first glance, I 
see DDR400, AGP8X, and SATA. 

On Fri, 23 Jan 2004, Andy Pearce wrote:

> Here is the lspci listing for the HP machine, so are we talking hopeful or
> no hope ?
> 
> Thanks
> 
> Andy
> 
> ======================================================================
> # lspci -xxv
> 00:00.0 Host bridge: Intel Corp.: Unknown device 2578 (rev 02)
> Subsystem: Hewlett-Packard Company: Unknown device 12bf
> Flags: bus master, fast devsel, latency 0
> Memory at e8000000 (32-bit, prefetchable) [size=128M]
> Capabilities: [e4] #09 [2106]
> Capabilities: [a0] AGP version 3.0
> 00: 86 80 78 25 06 01 90 20 02 00 00 06 00 00 00 00
> 10: 08 00 00 e8 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
> 30: 00 00 00 00 e4 00 00 00 00 00 00 00 00 00 00 00
> 00:01.0 PCI bridge: Intel Corp.: Unknown device 2579 (rev 02) (prog-if
> 00 [Normal decode])
> Flags: bus master, 66Mhz, fast devsel, latency 64
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
> Memory behind bridge: f9000000-fa1fffff
> Prefetchable memory behind bridge: f0000000-f81fffff
> 00: 86 80 79 25 07 01 a0 00 02 00 04 06 00 40 01 00
> 10: 00 00 00 00 00 00 00 00 00 01 01 20 f0 00 a0 22
> 20: 00 f9 10 fa 00 f0 10 f8 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00
> 00:1d.0 USB Controller: Intel Corp. 82801EB USB (Hub #1) (rev 02)
> (prog-if 00 [UHCI])
> Subsystem: Hewlett-Packard Company: Unknown device 12bf
> Flags: bus master, medium devsel, latency 0, IRQ 10
> I/O ports at 2440 [size=32]
> 00: 86 80 d2 24 05 00 80 02 02 00 03 0c 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 41 24 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
> 00:1d.1 USB Controller: Intel Corp. 82801EB USB (Hub #2) (rev 02)
> (prog-if 00 [UHCI])
> Subsystem: Hewlett-Packard Company: Unknown device 12bf
> Flags: bus master, medium devsel, latency 0, IRQ 5
> I/O ports at 2460 [size=32]
> 00: 86 80 d4 24 05 00 80 02 02 00 03 0c 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 61 24 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 05 02 00 00
> 00:1d.2 USB Controller: Intel Corp. 82801EB USB (Hub #3) (rev 02)
> (prog-if 00 [UHCI])
> Subsystem: Hewlett-Packard Company: Unknown device 12bf
> Flags: bus master, medium devsel, latency 0, IRQ 10
> I/O ports at 2480 [size=32]
> 00: 86 80 d7 24 05 00 80 02 02 00 03 0c 00 00 00 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 81 24 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 03 00 00
> 00:1d.7 USB Controller: Intel Corp. 82801EB USB EHCI Controller (rev 02)
> (prog-if 20 [EHCI])
> Subsystem: Hewlett-Packard Company: Unknown device 12bf
> Flags: bus master, medium devsel, latency 0, IRQ 11
> Memory at f8500000 (32-bit, non-prefetchable) [size=1K]
> Capabilities: [50] Power Management version 2
> Capabilities: [58] #0a [20a0]
> 00: 86 80 dd 24 06 01 90 02 02 20 03 0c 00 00 00 00
> 10: 00 00 50 f8 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
> 30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 04 00 00
> 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB PCI Bridge (rev c2)
> (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=00, secondary=05, subordinate=05, sec-latency=64
> I/O behind bridge: 00001000-00001fff
> Memory behind bridge: f8200000-f84fffff
> 00: 86 80 4e 24 07 01 80 00 c2 00 04 06 00 00 01 00
> 10: 00 00 00 00 00 00 00 00 00 05 05 40 10 10 80 22
> 20: 20 f8 40 f8 f0 ff 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 00
> 00:1f.0 ISA bridge: Intel Corp. 82801EB ISA Bridge (LPC) (rev 02)
> Flags: bus master, medium devsel, latency 0
> 00: 86 80 d0 24 0f 01 80 02 02 00 01 06 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00:1f.1 IDE interface: Intel Corp. 82801EB ICH5 IDE (rev 02) (prog-if 8a
> [Master SecP PriP])
> Subsystem: Hewlett-Packard Company: Unknown device 12bf
> Flags: bus master, medium devsel, latency 0, IRQ 10
> I/O ports at <ignored>
> I/O ports at <ignored>
> I/O ports at <ignored>
> I/O ports at <ignored>
> I/O ports at 24c0 [size=16]
> Memory at 20000000 (32-bit, non-prefetchable) [size=1K]
> 00: 86 80 db 24 07 00 88 02 02 8a 01 01 00 00 00 00
> 10: e1 24 00 00 01 28 00 00 e9 24 00 00 05 28 00 00
> 20: c1 24 00 00 00 00 00 20 00 00 00 00 3c 10 bf 12
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
> 00:1f.2 IDE interface: Intel Corp.: Unknown device 24d1 (rev 02)
> (prog-if 8f [Master SecP SecO PriP PriO])
> Subsystem: Hewlett-Packard Company: Unknown device 12bf
> Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 10
> I/O ports at 24f0 [size=8]
> I/O ports at 2808 [size=4]
> I/O ports at 24f8 [size=8]
> I/O ports at 280c [size=4]
> I/O ports at 24d0 [size=16]
> 00: 86 80 d1 24 05 00 a0 02 02 8f 01 01 00 00 00 00
> 10: f1 24 00 00 09 28 00 00 f9 24 00 00 0d 28 00 00
> 20: d1 24 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
> 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00
> 00:1f.5 Multimedia audio controller: Intel Corp. 82801EB AC'97 Audio
> (rev 02)
> Subsystem: Hewlett-Packard Company: Unknown device 12bf
> Flags: bus master, medium devsel, latency 0, IRQ 5
> I/O ports at 2000 [size=256]
> I/O ports at 2400 [size=64]
> Memory at f8500400 (32-bit, non-prefetchable) [size=512]
> Memory at f8500600 (32-bit, non-prefetchable) [size=256]
> Capabilities: [50] Power Management version 2
> 00: 86 80 d5 24 07 00 90 02 02 00 01 04 00 00 00 00
> 10: 01 20 00 00 01 24 00 00 00 04 50 f8 00 06 50 f8
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 bf 12
> 30: 00 00 00 00 50 00 00 00 00 00 00 00 05 02 00 00
> 01:00.0 VGA compatible controller: nVidia Corporation NV18GL [Quadro4
> 380 XGL] (rev a2) (prog-if 00 [VGA])
> Subsystem: nVidia Corporation: Unknown device 0169
> Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 10
> Memory at f9000000 (32-bit, non-prefetchable) [size=16M]
> Memory at f0000000 (32-bit, prefetchable) [size=128M]
> Expansion ROM at <unassigned> [disabled] [size=128K]
> Capabilities: [60] Power Management version 2
> Capabilities: [44] AGP version 3.0
> 00: de 10 8b 01 07 00 b0 02 a2 00 00 03 00 40 00 00
> 10: 00 00 00 f9 08 00 00 f0 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 de 10 69 01
> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0a 01 05 01
> 05:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5782
> Gigabit Ethernet (rev 03)
> Subsystem: Hewlett-Packard Company: Unknown device 12bf
> Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 5
> Memory at f8420000 (64-bit, non-prefetchable) [size=64K]
> Capabilities: [48] Power Management version 2
> Capabilities: [50] Vital Product Data
> Capabilities: [58] Message Signalled Interrupts: 64bit+
> Queue=0/3 Enable-
> 00: e4 14 96 16 06 01 b0 02 03 00 00 02 10 40 00 00
> 10: 04 00 42 f8 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 07 00 00 00 3c 10 bf 12
> 30: 00 00 00 00 48 00 00 00 00 00 00 00 05 01 40 00
> 05:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
> (rev 0c)
> Subsystem: Intel Corp. EtherExpress PRO/100 S Desktop Adapter
> Flags: bus master, medium devsel, latency 66, IRQ 10
> Memory at f8430000 (32-bit, non-prefetchable) [size=4K]
> I/O ports at 1000 [size=64]
> Memory at f8400000 (32-bit, non-prefetchable) [size=128K]
> Expansion ROM at <unassigned> [disabled] [size=64K]
> Capabilities: [dc] Power Management version 2
> 00: 86 80 29 12 07 01 90 02 0c 00 00 02 10 42 00 00
> 10: 00 00 43 f8 01 10 00 00 00 00 40 f8 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 40 00
> 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 08 38
> 
> > -----Original Message-----
> > From: ron minnich [mailto:rminnich at lanl.gov]
> > Sent: Thursday, January 22, 2004 10:09 PM
> > To: Eric W. Biederman
> > Cc: Andy Pearce; linuxbios at clustermatic.org
> > Subject: Re: Replacement for console level access on ALPHAs
> >
> >
> > On 22 Jan 2004, Eric W. Biederman wrote:
> >
> > > I would not say that serverworks is a lost cause.  But it
> > > is quite true that no one has yet succeeded in getting
> > > traction while working with them.
> >
> > yes, but having had an nda for a year with them (2000-2001), and having
> > had 0 help from them in that time, I am not hopeful.
> >
> > ron
> >
> >
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rminnich at lanl.gov  Sat Jan 24 00:16:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sat Jan 24 00:16:01 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <OGEMKDIFPJHJACJMGAPBGENECGAA.andy.pearce@austrocontrol.at>
Message-ID: <Pine.LNX.4.44.0401232225240.24673-100000@maxroach.lanl.gov>

On Fri, 23 Jan 2004, Andy Pearce wrote:

> Here is the lspci listing for the HP machine, so are we talking hopeful or
> no hope ?

I see an ICH 5, and the numbers are so new I will take a guess: this will 
be a new port. 

If you want, see if you can find out what the chipset is -- note that 
lspci did not know, so it is really new. I don't have time to look it up 
at present.

ron



From bari at onelabs.com  Sat Jan 24 11:37:00 2004
From: bari at onelabs.com (Bari Ari)
Date: Sat Jan 24 11:37:00 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <Pine.LNX.4.44.0401232225240.24673-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401232225240.24673-100000@maxroach.lanl.gov>
Message-ID: <4012A1EE.2090900@onelabs.com>

ron minnich wrote:

> On Fri, 23 Jan 2004, Andy Pearce wrote:
> 
> 
>>Here is the lspci listing for the HP machine, so are we talking hopeful or
>>no hope ?
> 
> 
> I see an ICH 5, and the numbers are so new I will take a guess: this will 
> be a new port. 
> 
# lspci -xxv
00:00.0 Host bridge: Intel Corp.: Unknown device 2578 (rev 02)
Subsystem: Hewlett-Packard Company: Unknown device 12bf

2578 = Intel 875P

http://developer.intel.com/design/chipsets/datashts/252525.htm

-Bari






From rminnich at lanl.gov  Sat Jan 24 14:09:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sat Jan 24 14:09:00 2004
Subject: Replacement for console level access on ALPHAs
In-Reply-To: <4012A1EE.2090900@onelabs.com>
Message-ID: <Pine.LNX.4.44.0401241218500.30200-100000@maxroach.lanl.gov>

On Sat, 24 Jan 2004, Bari Ari wrote:

> # lspci -xxv
> 00:00.0 Host bridge: Intel Corp.: Unknown device 2578 (rev 02)
> Subsystem: Hewlett-Packard Company: Unknown device 12bf
> 
> 2578 = Intel 875P
> 
> http://developer.intel.com/design/chipsets/datashts/252525.htm


oh! Then it's possible. Sorry for my pessimism -- I was just at a
vendor/DOE meeting where the subject of Intel came up, and their new "we
don't tell anyone anything about E7xxx chips" policy was a matter of some
long discussions. It leaves many of us unsure as to what to think.

ron



From r3pek at r3pek.homelinux.org  Sat Jan 24 15:25:01 2004
From: r3pek at r3pek.homelinux.org (Carlos Silva)
Date: Sat Jan 24 15:25:01 2004
Subject: ASUS A7N8X
Message-ID: <3321.193.126.185.164.1074976568.squirrel@webmail.r3pek.homelinux.org>

Hi, i've just found the LinuxBIOS project and waht it does. i'ts really
nice. i was going to download it when i remebered to check if my MOBO was
supported. guess what? it's not! i tried the link "Help me!" but it looks
like the submit button link is broken, so here i am posting to the
mailling list.

here's my lspci:

00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?)
(rev a2)
00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev a2)
00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev a2)
00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev a2)
00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev a2)
00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev a2)
00:01.0 ISA bridge: nVidia Corporation nForce2 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation nForce2 SMBus (MCP) (rev a2)
00:02.0 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:02.1 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3)
00:04.0 Ethernet controller: nVidia Corporation nForce2 Ethernet
Controller (rev a1)
00:08.0 PCI bridge: nVidia Corporation nForce2 External PCI Bridge (rev a3)
00:09.0 IDE interface: nVidia Corporation nForce2 IDE (rev a2)
00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev a2)
01:06.0 Multimedia video controller: Brooktree Corporation Bt878 Video
Capture (rev 11)
01:06.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture
(rev 11)
01:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
01:08.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
01:08.1 Input device controller: Creative Labs SB Audigy MIDI/Game port
(rev 03)
01:08.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port
03:00.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX
5200] (rev a1)

if you need something more... just mail to me or to the mailing list.

Keep up the good work,
Carlos Silva


From rminnich at lanl.gov  Sat Jan 24 15:55:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sat Jan 24 15:55:00 2004
Subject: ASUS A7N8X
In-Reply-To: <3321.193.126.185.164.1074976568.squirrel@webmail.r3pek.homelinux.org>
Message-ID: <Pine.LNX.4.44.0401241405380.30911-100000@maxroach.lanl.gov>

unfortunately, nvidia is not interested in helping with linuxbios, so I am 
afraid your board is not supported.

ron




From armijn at uulug.nl  Mon Jan 26 17:07:00 2004
From: armijn at uulug.nl (Armijn Hemel)
Date: Mon Jan 26 17:07:00 2004
Subject: LinuxBIOS questions
In-Reply-To: <Pine.LNX.4.44.0401220926340.10597-100000@maxroach.lanl.gov>
References: <20040122135107.GE32520@uulug.nl> <Pine.LNX.4.44.0401220926340.10597-100000@maxroach.lanl.gov>
Message-ID: <20040126221731.GD25064@uulug.nl>

On Thu, Jan 22, 2004 at 09:30:19AM -0700, ron minnich wrote:

> > for the Dutch Linux Magazine (http://www.linuxmag.nl/) I'm writing an
> > article about open source hardware and LinuxBIOS is one of the projects
> > I will mention. I have a question which does not seem to be answered
> > in the FAQ.

[cut]

> > Do I really need to remove the normal BIOS from a machine, insert a ZIF
> > socket, etc.? 
> 
> No, but the FLASH process will replace that BIOS with linuxbios. 

Ah cool. There are some things that are not really clear to me. Can
other operating systems ('doze, FreeBSD) be booted with the LinuxBIOS?
I read something about SEBOS on the project page, but not about
LinuxBIOS being able to do it. So can it? A simple `yes' or `no' will be
sufficient :)

thanks,

armijn

-- 
 ---------------------------------------------------------------------------
  armijn at uulug.nl | http://www.uulug.nl/ | UULug: Utrecht Linux Users Group
 ---------------------------------------------------------------------------


From dwh at lanl.gov  Mon Jan 26 17:36:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Jan 26 17:36:01 2004
Subject: LinuxBIOS questions
In-Reply-To: <20040126221731.GD25064@uulug.nl>
Message-ID: <Pine.LNX.4.44.0401261543580.544-100000@ccs-mail.lanl.gov>

Yes. IIRC, FreeBSD and Plan9 can be booted. Adam Sulmicki's ADLO (Adhesive 
loader) has been used to boot Windows 2000, but I'm not sure if anyone's 
gotten it to work with Windows XP as of yet.

On Mon, 26 Jan 2004, Armijn Hemel wrote:

> On Thu, Jan 22, 2004 at 09:30:19AM -0700, ron minnich wrote:
> 
> > > for the Dutch Linux Magazine (http://www.linuxmag.nl/) I'm writing an
> > > article about open source hardware and LinuxBIOS is one of the projects
> > > I will mention. I have a question which does not seem to be answered
> > > in the FAQ.
> 
> [cut]
> 
> > > Do I really need to remove the normal BIOS from a machine, insert a ZIF
> > > socket, etc.? 
> > 
> > No, but the FLASH process will replace that BIOS with linuxbios. 
> 
> Ah cool. There are some things that are not really clear to me. Can
> other operating systems ('doze, FreeBSD) be booted with the LinuxBIOS?
> I read something about SEBOS on the project page, but not about
> LinuxBIOS being able to do it. So can it? A simple `yes' or `no' will be
> sufficient :)
> 
> thanks,
> 
> armijn
> 
> 



From john at szakmeister.net  Mon Jan 26 19:05:01 2004
From: john at szakmeister.net (John Szakmeister)
Date: Mon Jan 26 19:05:01 2004
Subject: Couple of questions...
Message-ID: <200401261904.06824.john@szakmeister.net>

Is there directions on how to build LinuxBIOS somewhere?  I haven't seen much 
in the way of documentation, but I'd like to give it a whirl.

Also, I'm not sure my motherboard is supported.  I have an ASUS A7M266-D (it's 
a dual proc AMD motherboard).  Here is the 'lspci' output:

00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System 
Controller (rev 11)
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP 
Bridge
00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 04)
00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 
04)
00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 03)
00:09.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller 
(Link)
00:10.0 PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI (rev 04)
01:05.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 
400] (rev a1)
02:04.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
02:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 
[FasterNet] (rev 22)
02:06.0 USB Controller: NEC Corporation USB (rev 41)
02:06.1 USB Controller: NEC Corporation USB (rev 41)
02:06.2 USB Controller: NEC Corporation USB 2.0 (rev 02)

BTW, read the recent article in Linux Journal... this is really cool stuff.

-John



From dwh at lanl.gov  Mon Jan 26 20:05:01 2004
From: dwh at lanl.gov (Hendricks David W.)
Date: Mon Jan 26 20:05:01 2004
Subject: Couple of questions...
In-Reply-To: <200401261904.06824.john@szakmeister.net>
Message-ID: <Pine.LNX.4.44.0401261758070.544-100000@ccs-mail.lanl.gov>

Hmm, I think Ron might have gotten LinuxBIOS to work on a Tyan Thunder K7 
(Dual Athlon/Palomino, AMD 760MP chipset). The Tyan board used a Viper 
Plus southbridge instead of an Opus, but the northbridge appears to be the 
same. I'm not sure what the exact status is on that chipset, however.

On Mon, 26 Jan 2004, John Szakmeister wrote:

> Is there directions on how to build LinuxBIOS somewhere?  I haven't seen much 
> in the way of documentation, but I'd like to give it a whirl.
> 
> Also, I'm not sure my motherboard is supported.  I have an ASUS A7M266-D (it's 
> a dual proc AMD motherboard).  Here is the 'lspci' output:
> 
> 00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] System 
> Controller (rev 11)
> 00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 MP [IGD4-2P] AGP 
> Bridge
> 00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ISA (rev 04)
> 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-768 [Opus] IDE (rev 
> 04)
> 00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] ACPI (rev 03)
> 00:09.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller 
> (Link)
> 00:10.0 PCI bridge: Advanced Micro Devices [AMD] AMD-768 [Opus] PCI (rev 04)
> 01:05.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 
> 400] (rev a1)
> 02:04.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
> 02:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 
> [FasterNet] (rev 22)
> 02:06.0 USB Controller: NEC Corporation USB (rev 41)
> 02:06.1 USB Controller: NEC Corporation USB (rev 41)
> 02:06.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
> 
> BTW, read the recent article in Linux Journal... this is really cool stuff.
> 
> -John
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 



From rminnich at lanl.gov  Tue Jan 27 02:22:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jan 27 02:22:00 2004
Subject: Couple of questions...
In-Reply-To: <200401261904.06824.john@szakmeister.net>
Message-ID: <Pine.LNX.4.44.0401270032140.1989-100000@maxroach.lanl.gov>

all those chipsets are supported. The issue is asus habit of putting smbus 
in an odd place, which can cause trouble on bringup. 

But you could try tyan/guiness bios build and see if it works.

ron



From john at szakmeister.net  Tue Jan 27 05:23:00 2004
From: john at szakmeister.net (John Szakmeister)
Date: Tue Jan 27 05:23:00 2004
Subject: Couple of questions...
In-Reply-To: <Pine.LNX.4.44.0401270032140.1989-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401270032140.1989-100000@maxroach.lanl.gov>
Message-ID: <200401270521.56777.john@szakmeister.net>

On Tuesday 27 January 2004 02:33, ron minnich wrote:
> all those chipsets are supported. The issue is asus habit of putting smbus
> in an odd place, which can cause trouble on bringup.
>
> But you could try tyan/guiness bios build and see if it works.

How do I go about doing that?  Is there documentation somewhere?  And which 
version should I use freebios/ or freebios2/?



From ebiederman at lnxi.com  Tue Jan 27 06:13:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Tue Jan 27 06:13:01 2004
Subject: Link/Links field in struct device
In-Reply-To: <1075148356.22746.2.camel@exponential.lanl.gov>
References: <1075148356.22746.2.camel@exponential.lanl.gov>
Message-ID: <m31xplr5r0.fsf@maxwell.lnxi.com>

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

> Eric,
> 
> What does the link field in the device struct used for ? Does
> it has anything to do with the hypertransport links ? 

Yes, and no. 

In the device tree each device has several links coming off of it.  One
for each function.    So below mc0 has 6 logical links:
	pci 0:18.0
	pci 0:18.0
	pci 0:18.0
	pci 0:18.1
	pci 0:18.2
	pci 0:18.3

You can only hang devices off of the first 3 which are the hypertransport
links, in this case.  Hanging devices off the rest is not physically possible.
I do abuse HT chains a little bit an consider all of their members hanging
off the start of the chain instead of hanging off of each other.  But that
seems to model the reality fairly well.


> Is there a way to travel the HT links like the PCI bus in LinuxBIOS ?

Yes.  A HT chain is treated as a bus.  And we rebuild the chains during
enumeration.


> 
> Ollie

northbridge amd/amdk8 "mc0"
	pci 0:18.0
	pci 0:18.0
	pci 0:18.0
	pci 0:18.1
	pci 0:18.2
	pci 0:18.3
	southbridge amd/amd8131 "amd8131" link 0
	end
	southbridge amd/amd8111 "amd8111" link 0
	end
end



From rminnich at lanl.gov  Tue Jan 27 11:10:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Tue Jan 27 11:10:01 2004
Subject: Couple of questions...
In-Reply-To: <200401270521.56777.john@szakmeister.net>
Message-ID: <Pine.LNX.4.44.0401270921130.5606-100000@maxroach.lanl.gov>

On Tue, 27 Jan 2004, John Szakmeister wrote:

> On Tuesday 27 January 2004 02:33, ron minnich wrote:
> > all those chipsets are supported. The issue is asus habit of putting smbus
> > in an odd place, which can cause trouble on bringup.
> >
> > But you could try tyan/guiness bios build and see if it works.
> 
> How do I go about doing that?  Is there documentation somewhere?  And which 
> version should I use freebios/ or freebios2/?

use freebios, not freebios2. 

See the HOWTOs for some examples.

ron



From ssingh at totalise.co.uk  Tue Jan 27 11:59:00 2004
From: ssingh at totalise.co.uk (Surjan Singh)
Date: Tue Jan 27 11:59:00 2004
Subject: EPIA + SST39SF020A
Message-ID: <1075223370.4456.7.camel@tank>

Hello all,


Just wanted to highlight a website I found that actually sells the same
BIOS chips that are used in the bog standard EPIA board
(http://www.viavpsd.com/product/epia_mini_itx_spec.jsp?motherboardId=21).

Try this: http://progshop.com/shop/eproms/index.shtml#39SF

I had to enable cross-site cookies to actually place an order, but I
changed it back straight after.

I've had all sorts of problems with BIOS Savior and other chips that
were supposed to be a drop-in replacement.

Surj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040127/8f625bba/attachment.html>

From don at bowery.com  Tue Jan 27 21:42:01 2004
From: don at bowery.com (Don Elwell)
Date: Tue Jan 27 21:42:01 2004
Subject: LPC Rom Programmer/Emulator Recommendations
Message-ID: <40172339.7070904@bowery.com>

All,

I just discovered that my good old BP-1200 Universal Device Programmer 
isn't quite so universal -- it won't program LPC based firmware BIOS 
flash devices.

Anyone got any sort of recommendations on an LPC flash compatible 
programmer?  One that runs under Linux perhaps?  Better yet, what about 
an LPC flash ROM emulator?

-don





From steve at nexpath.com  Wed Jan 28 10:59:01 2004
From: steve at nexpath.com (Steve Gehlbach)
Date: Wed Jan 28 10:59:01 2004
Subject: LPC Rom Programmer/Emulator Recommendations
In-Reply-To: <40172339.7070904@bowery.com>
References: <40172339.7070904@bowery.com>
Message-ID: <4017E182.3030101@nexpath.com>

> Anyone got any sort of recommendations on an LPC flash compatible 
> programmer?  One that runs under Linux perhaps?  Better yet, what about 
> an LPC flash ROM emulator?

Needhams works for me (www.needhams.com) as a good reasonably priced 
professional programmer.

You might look at CheapLPC for an LPC emulator build it yourself: 
http://warmcat.com/milksop/

-Steve



From mf-lucas at csu.edu  Wed Jan 28 11:38:00 2004
From: mf-lucas at csu.edu (Matthew Lucas)
Date: Wed Jan 28 11:38:00 2004
Subject: question re: epox 8rda+
Message-ID: <001001c3e5bf$2e81d240$2c1510ac@CSU003789>

Dear LinuxBios group,

I've been lurking on the list for about two weeks.

After checking the product listings on the website, I have not found a
listing for the mother board I use.

Has anyone successfully installed a linux bios on an Epox 8rda+ Ultra 400
nforce2?  It uses the Phoenix Awardbios v6.0.

Thanks for any info,

Matthew Lucas
Chicago, IL



From gwatson at lanl.gov  Wed Jan 28 11:52:00 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Wed Jan 28 11:52:00 2004
Subject: Updated PPC support
Message-ID: <p0602041bbc3d9abe66f4@[10.0.1.2]>

For those interested in PPC issues,  I have updated support for the 
Motorola Sandpoint (G4 processor) in the V2 tree. Over the next few 
days I will tidy up a few remaining things, but as of now I have the 
Sandpoint booting a 2.4.24-pre2 kernel.

Regards,

Greg


From nathanael at gnat.ca  Wed Jan 28 11:52:11 2004
From: nathanael at gnat.ca (Nathanael Noblet)
Date: Wed Jan 28 11:52:11 2004
Subject: question re: epox 8rda+
In-Reply-To: <001001c3e5bf$2e81d240$2c1510ac@CSU003789>
Message-ID: <F842D037-51B3-11D8-B811-0003931B4D6A@gnat.ca>

On Wednesday, January 28, 2004, at 09:52 AM, Matthew Lucas wrote:

> Dear LinuxBios group,
>
> I've been lurking on the list for about two weeks.
>
> After checking the product listings on the website, I have not found a
> listing for the mother board I use.
>
> Has anyone successfully installed a linux bios on an Epox 8rda+ Ultra 
> 400
> nforce2?  It uses the Phoenix Awardbios v6.0.

If by nforce2 you mean the Nvidia Nforce2 chipset, It is unfortunately 
not supported as of yet.
-- 
Nathanael D. Noblet
Gnat Solutions
4604 Monterey Ave NW
Calgary, AB T3B 5K4

T/F 403.288.5360

http://www.gnat.ca/



From ollie at lanl.gov  Wed Jan 28 12:13:01 2004
From: ollie at lanl.gov (Li-Ta Lo)
Date: Wed Jan 28 12:13:01 2004
Subject: Updated PPC support
In-Reply-To: <p0602041bbc3d9abe66f4@[10.0.1.2]>
References: <p0602041bbc3d9abe66f4@[10.0.1.2]>
Message-ID: <1075310721.6358.6.camel@exponential.lanl.gov>

On Wed, 2004-01-28 at 10:03, Greg Watson wrote:
> For those interested in PPC issues,  I have updated support for the 
> Motorola Sandpoint (G4 processor) in the V2 tree. Over the next few 
> days I will tidy up a few remaining things, but as of now I have the 
> Sandpoint booting a 2.4.24-pre2 kernel.
> 
> Regards,
> 

What have you done ? You said you can't boot it
yesterday.

Ollie




From stepan at suse.de  Wed Jan 28 12:15:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Jan 28 12:15:01 2004
Subject: ACPI Support
Message-ID: <20040128172710.GB3519@suse.de>

Hi,

I've implemented initial code for ACPI support in LinuxBIOS. It can be
enabled by the option HAVE_ACPI_TABLES. 

Currently there is only support for HPET tables, which are needed to
tell the Linux kernel where the HPET timers on AMD64 systems can be
found.

The code is generated at the same place as the other tables (MP/PIRQ) -
in src/arch/i386/boot/tables.c. The ACPI code itself can be found at
src/arch/i386/boot/acpi.c

The code is far from being a generic ACPI implementation, but it can be
enhanced to whatever is needed.

Questions and comments are welcome.

Best regards,
  Stefan Reinauer
  
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From gwatson at lanl.gov  Wed Jan 28 12:33:01 2004
From: gwatson at lanl.gov (Greg Watson)
Date: Wed Jan 28 12:33:01 2004
Subject: Updated PPC support
In-Reply-To: <1075310721.6358.6.camel@exponential.lanl.gov>
References: <p0602041bbc3d9abe66f4@[10.0.1.2]>
 <1075310721.6358.6.camel@exponential.lanl.gov>
Message-ID: <p0602041dbc3da3bb8241@[10.0.1.2]>

At 10:25 AM -0700 1/28/04, Li-Ta Lo wrote:
>On Wed, 2004-01-28 at 10:03, Greg Watson wrote:
>>  For those interested in PPC issues,  I have updated support for the
>>  Motorola Sandpoint (G4 processor) in the V2 tree. Over the next few
>>  days I will tidy up a few remaining things, but as of now I have the
>>  Sandpoint booting a 2.4.24-pre2 kernel.
>>
>>  Regards,
>>
>
>What have you done ? You said you can't boot it
>yesterday.
>
>Ollie

A lot can happen in a day...

I've actually had LinuxBIOS loading a kernel for a while, but I was 
trying to get a kernel that would work on the Sandpoint.

The main problem was that the startup code was running out of stack 
space while trying to decompress the kernel (inflate returns 
FFFFFFFD!). Since the stack size is hardcoded in some assembly, it 
took a while to work out this was the problem.

The next thing was that LinuxBIOS was not initializing the superio 
properly, so even though the kernel re-does this initialization, it 
was happening too late and causing all kinds of screwy behavior. I'm 
fixing this now.

Greg


From bari at onelabs.com  Wed Jan 28 12:38:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Wed Jan 28 12:38:01 2004
Subject: question re: epox 8rda+
In-Reply-To: <001001c3e5bf$2e81d240$2c1510ac@CSU003789>
References: <001001c3e5bf$2e81d240$2c1510ac@CSU003789>
Message-ID: <4017F685.1090907@onelabs.com>

Matthew Lucas wrote:
> Dear LinuxBios group,
> 
> I've been lurking on the list for about two weeks.
> 
> After checking the product listings on the website, I have not found a
> listing for the mother board I use.
> 
> Has anyone successfully installed a linux bios on an Epox 8rda+ Ultra 400
> nforce2?  It uses the Phoenix Awardbios v6.0.
> 
> 
You can check the lspci for the board... but nforce2 = nvidia = not 
supported. Nvidia hasn't supported LinuxBIOS.

-Bari




From stepan at suse.de  Wed Jan 28 13:34:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Wed Jan 28 13:34:01 2004
Subject: old config method
Message-ID: <20040128182855.GC3519@suse.de>

Hi,

I've dropped the configuration files of the old configuration method
today to keep the LinuxBIOS 2 codebase as clean as possible. 

Since all ports use the new configuration method now, these files were
obsolete and only there for reference.

Best regards,
  Stefan Reinauer
  
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From jbors at mail.ru  Wed Jan 28 22:55:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Wed Jan 28 22:55:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
Message-ID: <027801c3e61d$66a2a100$0300a8c0@amr.corp.intel.com>

Hi,
I have taken freebios from CVS and applied the patch from here
http://www.clustermatic.org/pipermail/linuxbios/2003-July/004046.html to enable VGA. It works perfect. Exactly what I need.
The major problem with such a build is that directfb( it uses HW accelaration extensively ) works 2 times slower. Even though it still uses it as without acceleration it runs 10 times slower...
I'm wondering what could cause such a slow performance ? Does anyone have any suggestions ?
( It seems all other pure memory/disk programs are not affected )
Dmitry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040128/c8b03a33/attachment.html>

From ebiederman at lnxi.com  Wed Jan 28 23:04:01 2004
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: Wed Jan 28 23:04:01 2004
Subject: FYI: An interesting note about intels x86-64 plans
Message-ID: <m34qufl74k.fsf@maxwell.lnxi.com>

http://www.reuters.com/newsArticle.jhtml?type=technologyNews&storyID=4233918

Eric



From rminnich at lanl.gov  Wed Jan 28 23:21:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Wed Jan 28 23:21:00 2004
Subject: EPIA-M HW graphics slow under linuxbios
In-Reply-To: <027801c3e61d$66a2a100$0300a8c0@amr.corp.intel.com>
Message-ID: <Pine.LNX.4.44.0401282132100.19499-100000@maxroach.lanl.gov>

well we obviously have more to do here. Somebody want to do some register 
dumps and see what it could be? I have no EPIA-M.

Work on bios emulation continues ...

ron



From stepan at suse.de  Thu Jan 29 05:10:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Jan 29 05:10:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
In-Reply-To: <027801c3e61d$66a2a100$0300a8c0@amr.corp.intel.com>
References: <027801c3e61d$66a2a100$0300a8c0@amr.corp.intel.com>
Message-ID: <20040129102220.GB13187@suse.de>

* Dmitry Borisov <jbors at mail.ru> [040129 05:07]:
> Hi, I have taken freebios from CVS and applied the patch from here
> http://www.clustermatic.org/pipermail/linuxbios/2003-July/004046.html
> to enable VGA. It works perfect. Exactly what I need.  The major
> problem with such a build is that directfb( it uses HW accelaration
> extensively ) works 2 times slower. Even though it still uses it as
> without acceleration it runs 10 times slower...  I'm wondering what
> could cause such a slow performance ? Does anyone have any suggestions
> ?  ( It seems all other pure memory/disk programs are not affected )
> Dmitry/

Just guessing ...
Maybe an MTRR entry is missing? Does the epia connect it's graphics with
an (AGP) bridge? Maybe the bridge is not at full speed?

  Stefan
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From pmacv at telefonica.net  Thu Jan 29 11:16:00 2004
From: pmacv at telefonica.net (Pedro M.)
Date: Thu Jan 29 11:16:00 2004
Subject: Interesting HOWTO
Message-ID: <401942C5.4080901@telefonica.net>

I have seen an interesting HOWTO about BIOS and Booting .

http://www.freewebs.com/tsj/bootingUSB_ldp_v0.1.htm

Regards.



From stepan at suse.de  Thu Jan 29 11:30:01 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Jan 29 11:30:01 2004
Subject: Interesting HOWTO
In-Reply-To: <401942C5.4080901@telefonica.net>
References: <401942C5.4080901@telefonica.net>
Message-ID: <20040129163820.GA31181@suse.de>

* Pedro M. <pmacv at telefonica.net> [040129 18:28]:
> http://www.freewebs.com/tsj/bootingUSB_ldp_v0.1.htm

Unfortunately this won't work unless we have some stripped down USB
stack or get the kernel into flash...

Best regards,
  Stefan Reinauer
  
-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From pmacv at telefonica.net  Thu Jan 29 12:06:00 2004
From: pmacv at telefonica.net (Pedro M.)
Date: Thu Jan 29 12:06:00 2004
Subject: Interesting HOWTO
In-Reply-To: <20040129163820.GA31181@suse.de>
References: <401942C5.4080901@telefonica.net> <20040129163820.GA31181@suse.de>
Message-ID: <40194E81.7050907@telefonica.net>

Stefan Reinauer wrote:
> * Pedro M. <pmacv at telefonica.net> [040129 18:28]:
> 
>>http://www.freewebs.com/tsj/bootingUSB_ldp_v0.1.htm
> 
> 
> Unfortunately this won't work unless we have some stripped down USB
> stack or get the kernel into flash...
> 
> Best regards,
>   Stefan Reinauer
>   
I send you interesting links ;)

http://www.wlug.org.nz/KeyDrive

http://d-i.pascal.at/

and http://www.wlug.org.nz/LinuxDistribution (removable media ).

Regards.



From stepan at suse.de  Thu Jan 29 12:26:00 2004
From: stepan at suse.de (Stefan Reinauer)
Date: Thu Jan 29 12:26:00 2004
Subject: Interesting HOWTO
In-Reply-To: <40194E81.7050907@telefonica.net>
References: <401942C5.4080901@telefonica.net> <20040129163820.GA31181@suse.de> <40194E81.7050907@telefonica.net>
Message-ID: <20040129173806.GA14412@suse.de>

* Pedro M. <pmacv at telefonica.net> [040129 19:18]:
> http://www.wlug.org.nz/KeyDrive
 
cite:
------------------ 8< ---------------------------------------------
You can even boot from one, if your BIOS knows how to talk to them.
------------------ 8< ---------------------------------------------

LinuxBIOS can't :-(

  Stefan

-- 
     Stefan Reinauer, SUSE LINUX AG
Teamleader Architecture Development


From pmacv at telefonica.net  Thu Jan 29 12:55:00 2004
From: pmacv at telefonica.net (Pedro M.)
Date: Thu Jan 29 12:55:00 2004
Subject: Interesting HOWTO
In-Reply-To: <20040129163820.GA31181@suse.de>
References: <401942C5.4080901@telefonica.net> <20040129163820.GA31181@suse.de>
Message-ID: <40195A03.4000106@telefonica.net>

Stefan Reinauer wrote:
> * Pedro M. <pmacv at telefonica.net> [040129 18:28]:
> 
>>http://www.freewebs.com/tsj/bootingUSB_ldp_v0.1.htm
> 
> 
> Unfortunately this won't work unless we have some stripped down USB
> stack or get the kernel into flash...
> 
> Best regards,
>   Stefan Reinauer
>   
Antoher BIOS can. And to promote Linux ( http://flonix.tuxfamily.org ) 
is fundamental.

What can we do ?.

Regards.



From jbors at mail.ru  Thu Jan 29 15:25:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Thu Jan 29 15:25:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
References: <027801c3e61d$66a2a100$0300a8c0@amr.corp.intel.com> <20040129102220.GB13187@suse.de>
Message-ID: <012801c3e6a7$aa47b960$0300a8c0@amr.corp.intel.com>

How to verify what you're saying about AGP bridge ?
Are ther any utilities or something ? 
Let me know if I can do some research and where to look.
Thanks,
Dmitry/

----- Original Message ----- 
From: "Stefan Reinauer" <stepan at suse.de>
To: "Dmitry Borisov" <jbors at mail.ru>
Cc: <linuxbios at clustermatic.org>
Sent: Thursday, January 29, 2004 2:22 AM
Subject: Re: EPIA-M HW graphics slow under linuxbios


> * Dmitry Borisov <jbors at mail.ru> [040129 05:07]:
> > Hi, I have taken freebios from CVS and applied the patch from here
> > http://www.clustermatic.org/pipermail/linuxbios/2003-July/004046.html
> > to enable VGA. It works perfect. Exactly what I need.  The major
> > problem with such a build is that directfb( it uses HW accelaration
> > extensively ) works 2 times slower. Even though it still uses it as
> > without acceleration it runs 10 times slower...  I'm wondering what
> > could cause such a slow performance ? Does anyone have any suggestions
> > ?  ( It seems all other pure memory/disk programs are not affected )
> > Dmitry/
> 
> Just guessing ...
> Maybe an MTRR entry is missing? Does the epia connect it's graphics with
> an (AGP) bridge? Maybe the bridge is not at full speed?
> 
>   Stefan
> -- 
>      Stefan Reinauer, SUSE LINUX AG
> Teamleader Architecture Development
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 


From jbors at mail.ru  Thu Jan 29 15:44:00 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Thu Jan 29 15:44:00 2004
Subject: EPIA-M HW graphics slow under linuxbios
References: <Pine.LNX.4.44.0401282132100.19499-100000@maxroach.lanl.gov>
Message-ID: <014c01c3e6aa$5b977ff0$0300a8c0@amr.corp.intel.com>

Do you have a script I can run ?
Dmitry/

----- Original Message ----- 
From: "ron minnich" <rminnich at lanl.gov>
To: "Dmitry Borisov" <jbors at mail.ru>
Cc: <linuxbios at clustermatic.org>
Sent: Wednesday, January 28, 2004 8:32 PM
Subject: Re: EPIA-M HW graphics slow under linuxbios


> well we obviously have more to do here. Somebody want to do some register
> dumps and see what it could be? I have no EPIA-M.
>
> Work on bios emulation continues ...
>
> ron
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From linuxbios at xdr.com  Thu Jan 29 16:27:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Thu Jan 29 16:27:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
Message-ID: <200401292139.i0TLdV6O022790@xdr.com>

That old patch:
http://www.clustermatic.org/pipermail/linuxbios/2003-July/004046.html
was the first one I put up, there have been a lot of fixes since then.

Go to this site:
http://www.xdr.com/dash/linuxbios/
get this patch:
http://www.xdr.com/dash/linuxbios/freebios-nxtv-patch-20030705.gz

That is more complete.

The slow video rendering might be related to the int21 handlers in
mainboard.c. I found performance wasn't as good as under award bios until I
fixed that. It looks like the patch you applied doesn't even handle the
bios callbacks the VGA bios is expecting.

-Dave


From jbors at mail.ru  Thu Jan 29 16:46:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Thu Jan 29 16:46:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
References: <200401292139.i0TLdV6O022790@xdr.com>
Message-ID: <001f01c3e6b2$fa3b8e00$0300a8c0@amr.corp.intel.com>

Dave,
I've tried that patch as well.
It does not applicable against the current version of freebios from CVS. It
rejects 75% of the changes.
Even though it was rejected, I've tried to burn the bios and it hangs...
Another thing: I was forced to comment out setup_misc.inc in your Config
file as this file does not exists in CVS tree.
Can you put your recent changes in a tarball instead of diff ?
Thanks,
Dmitry/

----- Original Message ----- 
From: "Dave Ashley" <linuxbios at xdr.com>
To: <linuxbios at clustermatic.org>
Sent: Thursday, January 29, 2004 1:39 PM
Subject: Re: EPIA-M HW graphics slow under linuxbios


> That old patch:
> http://www.clustermatic.org/pipermail/linuxbios/2003-July/004046.html
> was the first one I put up, there have been a lot of fixes since then.
>
> Go to this site:
> http://www.xdr.com/dash/linuxbios/
> get this patch:
> http://www.xdr.com/dash/linuxbios/freebios-nxtv-patch-20030705.gz
>
> That is more complete.
>
> The slow video rendering might be related to the int21 handlers in
> mainboard.c. I found performance wasn't as good as under award bios until
I
> fixed that. It looks like the patch you applied doesn't even handle the
> bios callbacks the VGA bios is expecting.
>
> -Dave
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From linuxbios at xdr.com  Thu Jan 29 17:57:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Thu Jan 29 17:57:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
Message-ID: <200401292309.i0TN9XGi023155@xdr.com>

>Can you put your recent changes in a tarball instead of diff ?

The way to use the patch is to cvs co the freebios tree, then update it
to 2003/7/5, then apply the patch.

Freebios has evolved since I made all these changes. All I can say is
my freebios fork works perfectly fine for me :^). Whenever Ron asked for
patches or whatever I provided them, but they never got integrated I guess.
I don't have cvs write permissions nor would I have time to clean up my
patch anyway or bring it back into sync...Especially since freebios2 is
the way to go anyway in the future.

Ron always says he doesn't have an epia-m yet to work with, but when I
offer to send one he doesn't take me up on it :^).

I think my epia-m support is further along than the epia support anyway.
Last I checked epia didn't have a good composite/svideo video encoder,
there were awful color bands. I don't know why more people aren't demanding
the epia-m and giving up on epia. Oh well.

-Dave



From jbors at mail.ru  Thu Jan 29 18:28:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Thu Jan 29 18:28:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
References: <200401292309.i0TN9XGi023155@xdr.com>
Message-ID: <00d001c3e6c1$43b1aca0$0300a8c0@amr.corp.intel.com>

Dave,
I did what you said. The patch was applied correctly. I built the romimage
and burnt it the same way I did it before and it did turn the VGA on, true,
but never ran linux, just infinite loop inside linuxbios...
Here are the last messages I've got before it went to the restart.
--------------------------------------------------------------------
...
Copying IRQ routing tables to 0xf0000...done.
Verifing priq routing tables copy at 0xf0000...failed
Wrote linuxbios table at: 00000500 - 00000650  checksum 9ac4

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 0x24130 offset 0xa0 filesize 0xa168
(cleaned up) New segment addr 0x100000 size 0x24130 offset 0xa0 filesize
0xa168
New segment addr 0x124140 size 0x48 offset 0xa220 filesize 0x48
(cleaned up) New segment addr 0x124140 size 0x48 offset 0xa220 filesize 0x48
Dropping non PT_LOAD segment
Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000024130 filesz:
0x000000000000a168
Clearing Segment: addr: 0x000000000010a168 memsz: 0x0000000000019fc8
Loading Segment: addr: 0x0000000000124140 memsz: 0x0000000000000048 filesz:
0x000000000000
Jumping to boot code at 0x106710
0

LinuxBIOS-1.0.0 Thu Jan 29 15:29:50 PST 2004 starting...
RB!0
....
--------------------------------------------------------------------

Any ideas ?
Dmitry/
.
----- Original Message ----- 
From: "Dave Ashley" <linuxbios at xdr.com>
To: <linuxbios at clustermatic.org>
Sent: Thursday, January 29, 2004 3:09 PM
Subject: Re: EPIA-M HW graphics slow under linuxbios


> >Can you put your recent changes in a tarball instead of diff ?
>
> The way to use the patch is to cvs co the freebios tree, then update it
> to 2003/7/5, then apply the patch.
>
> Freebios has evolved since I made all these changes. All I can say is
> my freebios fork works perfectly fine for me :^). Whenever Ron asked for
> patches or whatever I provided them, but they never got integrated I
guess.
> I don't have cvs write permissions nor would I have time to clean up my
> patch anyway or bring it back into sync...Especially since freebios2 is
> the way to go anyway in the future.
>
> Ron always says he doesn't have an epia-m yet to work with, but when I
> offer to send one he doesn't take me up on it :^).
>
> I think my epia-m support is further along than the epia support anyway.
> Last I checked epia didn't have a good composite/svideo video encoder,
> there were awful color bands. I don't know why more people aren't
demanding
> the epia-m and giving up on epia. Oh well.
>
> -Dave
>
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From linuxbios at xdr.com  Thu Jan 29 19:03:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Thu Jan 29 19:03:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
Message-ID: <200401300015.i0U0Fjuw023315@xdr.com>

>I did what you said...
>...
>Jumping to boot code at 0x106710
>0

I think this is a divide by zero error when it tries to jump into the
etherboot payload. Etherboot has a bug which I've mentioned before. It
tries to use some timer machinery before it has been initialized.
Edit src/timer.c of etherboot, in the function currticks you want:
diff -Nur etherboot-5.0.10/src/timer.c etherboot-5.0.10-new/src/timer.c
--- etherboot-5.0.10/src/timer.c	Sat Mar 22 11:52:25 2003
+++ etherboot-5.0.10-new/src/timer.c	Wed Jul 16 09:45:46 2003
@@ -138,6 +138,8 @@
 {
 	unsigned long clocks_high, clocks_low;
 	unsigned long currticks;
+
+setup_timers();
 	/* Read the Time Stamp Counter */
 	rdtsc(clocks_low, clocks_high);


BTW if this fixed your problem I'm a miracle worker.

-Dave


From pyro at linuxlabs.com  Thu Jan 29 19:06:01 2004
From: pyro at linuxlabs.com (Steven James)
Date: Thu Jan 29 19:06:01 2004
Subject: Interesting HOWTO
In-Reply-To: <20040129173806.GA14412@suse.de>
References: <401942C5.4080901@telefonica.net> <20040129163820.GA31181@suse.de>
 <40194E81.7050907@telefonica.net> <20040129173806.GA14412@suse.de>
Message-ID: <Pine.LNX.4.58.0401291621200.6724@ucontrol.mobiledns.com>

Greetings,

I just checked in a polling USB stack (FINALLY!) in
freebios/util/baremetal/usb

So far, it only supports uhci, but successfully enumerates the bus and
loads an ELF image from some USB drives (It loads from the ones I have
anyway).

G'day,
sjames


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


On Thu, 29 Jan 2004, Stefan Reinauer wrote:

> * Pedro M. <pmacv at telefonica.net> [040129 19:18]:
> > http://www.wlug.org.nz/KeyDrive
>
> cite:
> ------------------ 8< ---------------------------------------------
> You can even boot from one, if your BIOS knows how to talk to them.
> ------------------ 8< ---------------------------------------------
>
> LinuxBIOS can't :-(
>
>   Stefan
>
> --
>      Stefan Reinauer, SUSE LINUX AG
> Teamleader Architecture Development
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>


From jbors at mail.ru  Thu Jan 29 19:32:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Thu Jan 29 19:32:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
References: <200401300015.i0U0Fjuw023315@xdr.com>
Message-ID: <011a01c3e6ca$2470cb60$0300a8c0@amr.corp.intel.com>

Hmm,
I don't have etherboot. I use filo-0.4.1. I wasn't able to use etherboot
correctly with my system( IDE flash drives ), so I switched to filo...
Dmitry/

----- Original Message ----- 
From: "Dave Ashley" <linuxbios at xdr.com>
To: <linuxbios at clustermatic.org>
Sent: Thursday, January 29, 2004 4:15 PM
Subject: Re: EPIA-M HW graphics slow under linuxbios


> >I did what you said...
> >...
> >Jumping to boot code at 0x106710
> >0
>
> I think this is a divide by zero error when it tries to jump into the
> etherboot payload. Etherboot has a bug which I've mentioned before. It
> tries to use some timer machinery before it has been initialized.
> Edit src/timer.c of etherboot, in the function currticks you want:
> diff -Nur etherboot-5.0.10/src/timer.c etherboot-5.0.10-new/src/timer.c
> --- etherboot-5.0.10/src/timer.c Sat Mar 22 11:52:25 2003
> +++ etherboot-5.0.10-new/src/timer.c Wed Jul 16 09:45:46 2003
> @@ -138,6 +138,8 @@
>  {
>   unsigned long clocks_high, clocks_low;
>   unsigned long currticks;
> +
> +setup_timers();
>   /* Read the Time Stamp Counter */
>   rdtsc(clocks_low, clocks_high);
>
>
> BTW if this fixed your problem I'm a miracle worker.
>
> -Dave
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>



From linuxbios at xdr.com  Thu Jan 29 19:58:01 2004
From: linuxbios at xdr.com (Dave Ashley)
Date: Thu Jan 29 19:58:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
Message-ID: <200401300110.i0U1ALXS023449@xdr.com>

>I don't have etherboot. I use filo-0.4.1.

Doh! I guess I'm not so great afterall...

I don't really have any suggestions. The important thing I was trying
to get working for you was the int21 bios calls. The VGA bios will do
various callbacks to query how much video memory has been allocated,
what the clock rates are, etc. My patch traps those and provides acceptable
answers. After doing that I saw a performance improvement. If you could
integrate those int handlers you'll get the same benefit.

Another alternative is to debug the existing problem. You can't always get
everything you want without effort :^).

Really someone in the core linuxbios group needs to adopt my patch and
integrate it into linuxbios, after "blessing" it and making sure everything
is ok. I did all the really hard work, someone just has to make it so it is
fit for mass consumption. I'll be around for answering questions.

-Dave


From hansolofalcon at worldnet.att.net  Thu Jan 29 20:14:01 2004
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Thu Jan 29 20:14:01 2004
Subject: Interesting HOWTO
In-Reply-To: <Pine.LNX.4.58.0401291621200.6724@ucontrol.mobiledns.com>
Message-ID: <000501c3e6d0$16dbde80$6401a8c0@who5>

Hello (again) from Gregg C Levine
Great news!
Now the next great question. For which mother boards have you tested
this? Or one anyway. And of course which USB drives have you tested?

I remember this issue first coming up, when our friends at M-SYS,
launched their Disk-On-Key project. One of us, mentioned the device,
and posted a link for the thing.

Now the next big question, have you had a chance to create a HOWTO for
using your baremetal boot loader?
-------------------
Gregg C Levine hansolofalcon at worldnet.att.net
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."? Obi-Wan Kenobi
(This company dedicates this E-Mail to General Obi-Wan Kenobi )
(This company dedicates this E-Mail to Master Yoda )



> -----Original Message-----
> From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> admin at clustermatic.org] On Behalf Of Steven James
> Sent: Thursday, January 29, 2004 11:25 AM
> To: Stefan Reinauer
> Cc: Pedro M.; linuxbios at clustermatic.org
> Subject: Re: Interesting HOWTO
> 
> Greetings,
> 
> I just checked in a polling USB stack (FINALLY!) in
> freebios/util/baremetal/usb
> 
> So far, it only supports uhci, but successfully enumerates the bus
and
> loads an ELF image from some USB drives (It loads from the ones I
have
> anyway).
> 
> G'day,
> sjames
> 
> 
> -------------------------steven james, director of research, linux
labs
> ... ........ ..... ....                    230 peachtree st nw ste
2701
> the original linux labs                             atlanta.ga.us
30303
>       -since 1995
http://www.linuxlabs.com
>                                    office 404.577.7747 fax
404.577.7743
>
----------------------------------------------------------------------
-
> 
> 
> On Thu, 29 Jan 2004, Stefan Reinauer wrote:
> 
> > * Pedro M. <pmacv at telefonica.net> [040129 19:18]:
> > > http://www.wlug.org.nz/KeyDrive
> >
> > cite:
> > ------------------ 8<
---------------------------------------------
> > You can even boot from one, if your BIOS knows how to talk to
them.
> > ------------------ 8<
---------------------------------------------
> >
> > LinuxBIOS can't :-(
> >
> >   Stefan
> >
> > --
> >      Stefan Reinauer, SUSE LINUX AG
> > Teamleader Architecture Development
> > _______________________________________________
> > 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 pyro at linuxlabs.com  Thu Jan 29 21:27:01 2004
From: pyro at linuxlabs.com (Steven James)
Date: Thu Jan 29 21:27:01 2004
Subject: Interesting HOWTO
In-Reply-To: <000501c3e6d0$16dbde80$6401a8c0@who5>
References: <000501c3e6d0$16dbde80$6401a8c0@who5>
Message-ID: <Pine.LNX.4.58.0401291822410.6724@ucontrol.mobiledns.com>

Greetings,

I suppose I really should write up a howto for that.

So far, It has been tested on a few i7501 boards (Supermicro x5dpr, Intel
Clearwater, Tyan Tiger-7501).

The drive was a TrekStore Thumbdrive. It's SCSI over bulk transfer.

Also worked connected through the hub in an iMac keyboard.

To test it, in brief,

Go to baremetal/lib
make
cd ../usb
make

This will produce an ELF image suitable for LinuxBIOS (or bootselect).

The usb loader will attempt to load a kernel from the first partition on
the drive that has the boot flag set. The image should be written to the
raw partition (using dd or similar).

G'day,
sjames

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


On Thu, 29 Jan 2004, Gregg C Levine wrote:

> Hello (again) from Gregg C Levine
> Great news!
> Now the next great question. For which mother boards have you tested
> this? Or one anyway. And of course which USB drives have you tested?
>
> I remember this issue first coming up, when our friends at M-SYS,
> launched their Disk-On-Key project. One of us, mentioned the device,
> and posted a link for the thing.
>
> Now the next big question, have you had a chance to create a HOWTO for
> using your baremetal boot loader?
> -------------------
> Gregg C Levine hansolofalcon at worldnet.att.net
> ------------------------------------------------------------
> "The Force will be with you...Always." Obi-Wan Kenobi
> "Use the Force, Luke."? Obi-Wan Kenobi
> (This company dedicates this E-Mail to General Obi-Wan Kenobi )
> (This company dedicates this E-Mail to Master Yoda )
>
>
>
> > -----Original Message-----
> > From: linuxbios-admin at clustermatic.org [mailto:linuxbios-
> > admin at clustermatic.org] On Behalf Of Steven James
> > Sent: Thursday, January 29, 2004 11:25 AM
> > To: Stefan Reinauer
> > Cc: Pedro M.; linuxbios at clustermatic.org
> > Subject: Re: Interesting HOWTO
> >
> > Greetings,
> >
> > I just checked in a polling USB stack (FINALLY!) in
> > freebios/util/baremetal/usb
> >
> > So far, it only supports uhci, but successfully enumerates the bus
> and
> > loads an ELF image from some USB drives (It loads from the ones I
> have
> > anyway).
> >
> > G'day,
> > sjames
> >
> >
> > -------------------------steven james, director of research, linux
> labs
> > ... ........ ..... ....                    230 peachtree st nw ste
> 2701
> > the original linux labs                             atlanta.ga.us
> 30303
> >       -since 1995
> http://www.linuxlabs.com
> >                                    office 404.577.7747 fax
> 404.577.7743
> >
> ----------------------------------------------------------------------
> -
> >
> >
> > On Thu, 29 Jan 2004, Stefan Reinauer wrote:
> >
> > > * Pedro M. <pmacv at telefonica.net> [040129 19:18]:
> > > > http://www.wlug.org.nz/KeyDrive
> > >
> > > cite:
> > > ------------------ 8<
> ---------------------------------------------
> > > You can even boot from one, if your BIOS knows how to talk to
> them.
> > > ------------------ 8<
> ---------------------------------------------
> > >
> > > LinuxBIOS can't :-(
> > >
> > >   Stefan
> > >
> > > --
> > >      Stefan Reinauer, SUSE LINUX AG
> > > Teamleader Architecture Development
> > > _______________________________________________
> > > 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 rminnich at lanl.gov  Thu Jan 29 21:36:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 29 21:36:00 2004
Subject: Interesting HOWTO
In-Reply-To: <40195A03.4000106@telefonica.net>
Message-ID: <Pine.LNX.4.44.0401291947500.28001-100000@maxroach.lanl.gov>

well, if we can configure hypertransport we can probably configure usb :-)

ron



From rminnich at lanl.gov  Thu Jan 29 21:40:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 29 21:40:00 2004
Subject: EPIA-M HW graphics slow under linuxbios
In-Reply-To: <014c01c3e6aa$5b977ff0$0300a8c0@amr.corp.intel.com>
Message-ID: <Pine.LNX.4.44.0401291952210.28001-100000@maxroach.lanl.gov>

On Thu, 29 Jan 2004, Dmitry Borisov wrote:

> Do you have a script I can run ?

just lspci -xxx in linuxbios and standard bios.

ron



From rminnich at lanl.gov  Thu Jan 29 21:43:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 29 21:43:00 2004
Subject: EPIA-M HW graphics slow under linuxbios
In-Reply-To: <001f01c3e6b2$fa3b8e00$0300a8c0@amr.corp.intel.com>
Message-ID: <Pine.LNX.4.44.0401291954380.28001-100000@maxroach.lanl.gov>

I think I have failed to get Dave's stuff in, my fault. 

I'll try again.

ron



From rminnich at lanl.gov  Thu Jan 29 21:45:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 29 21:45:01 2004
Subject: EPIA-M HW graphics slow under linuxbios [PMX:#]
In-Reply-To: <200401292309.i0TN9XGi023155@xdr.com>
Message-ID: <Pine.LNX.4.44.0401291956370.28001-100000@maxroach.lanl.gov>

On Thu, 29 Jan 2004, Dave Ashley wrote:

> Freebios has evolved since I made all these changes. All I can say is
> my freebios fork works perfectly fine for me :^). Whenever Ron asked for
> patches or whatever I provided them, but they never got integrated I guess.

Ron screwed up.

> Ron always says he doesn't have an epia-m yet to work with, but when I
> offer to send one he doesn't take me up on it :^).

send it.


ron



From rminnich at lanl.gov  Thu Jan 29 21:50:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Thu Jan 29 21:50:01 2004
Subject: EPIA-M HW graphics slow under linuxbios [PMX:#]
In-Reply-To: <200401300110.i0U1ALXS023449@xdr.com>
Message-ID: <Pine.LNX.4.44.0401292001460.28001-100000@maxroach.lanl.gov>

Dave, I will try to get your patch in next week. Sorry I keep dropping the 
ball.

ron



From jbors at mail.ru  Thu Jan 29 22:57:00 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Thu Jan 29 22:57:00 2004
Subject: EPIA-M HW graphics slow under linuxbios
References: <200401300110.i0U1ALXS023449@xdr.com>
Message-ID: <016d01c3e6e6$cc570f30$0300a8c0@amr.corp.intel.com>

Yeah, I know...
Some things that may help though.
I have put some print statements into src/lib/elfboot.c into
get_bounce_buffer():
Here is the response from original bios:
---------------------------------
Try to load at offset 0x0
mem_entries=3 buffer=0
i= 0 buffer=0 &buffer=1244c
i= 1 buffer=0 &buffer=1244c
map_type=1 mstart=6c4 msize=653628 buffer=0 mend=a0000 tbuffer=35e8
i= 2 buffer=35e8 &buffer=1244c
map_type=1 mstart=100000 msize=99614720 buffer=35e8 mend=6000000
tbuffer=5f635e8

---------------------------------
And here is the version I've got from your patch:
---------------------------------
Try to load at offset 0x0
mem_entries=2 buffer=0
i= 0 buffer=0 &buffer=124ac
i= 1 buffer=0 &buffer=124ac
map_type=1 mstart=6b0 msize=-1712 buffer=0 mend=0 tbuffer=fff63528

---------------------------------
Take a look at the tbuffer. Address is incorrect.
Some memory allocation issue which makes impossible to get correct address
for the filo elf image.
I give up for now.
Dmitry/

----- Original Message ----- 
From: "Dave Ashley" <linuxbios at xdr.com>
To: <linuxbios at clustermatic.org>
Sent: Thursday, January 29, 2004 5:10 PM
Subject: Re: EPIA-M HW graphics slow under linuxbios


>
> Another alternative is to debug the existing problem. You can't always get
> everything you want without effort :^).
>



From jbors at mail.ru  Thu Jan 29 23:30:01 2004
From: jbors at mail.ru (Dmitry Borisov)
Date: Thu Jan 29 23:30:01 2004
Subject: EPIA-M HW graphics slow under linuxbios
References: <Pine.LNX.4.44.0401291952210.28001-100000@maxroach.lanl.gov>
Message-ID: <019501c3e6eb$85fc3fb0$0300a8c0@amr.corp.intel.com>

Here we go...
Dmitry/

----- Original Message ----- 
From: "ron minnich" <rminnich at lanl.gov>
To: "Dmitry Borisov" <jbors at mail.ru>
Cc: <linuxbios at clustermatic.org>
Sent: Thursday, January 29, 2004 6:52 PM
Subject: Re: EPIA-M HW graphics slow under linuxbios


> On Thu, 29 Jan 2004, Dmitry Borisov wrote:
> 
> > Do you have a script I can run ?
> 
> just lspci -xxx in linuxbios and standard bios.
> 
> ron
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: orig_bios.regs
Type: application/octet-stream
Size: 1800 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040129/3b39e4eb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: free_bios.regs
Type: application/octet-stream
Size: 1800 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20040129/3b39e4eb/attachment-0001.obj>

From stuge-linuxbios at cdy.org  Fri Jan 30 00:22:01 2004
From: stuge-linuxbios at cdy.org (Peter Stuge)
Date: Fri Jan 30 00:22:01 2004
Subject: EPIA + SST39SF020A
In-Reply-To: <1075223370.4456.7.camel@tank>
References: <1075223370.4456.7.camel@tank>
Message-ID: <20040130053412.GI26532@foo.birdnet.se>

On Tue, Jan 27, 2004 at 05:10:21PM +0000, Surjan Singh wrote:
> Just wanted to highlight a website I found that actually sells the same
> BIOS chips that are used in the bog standard EPIA board

I'd just order them from Memec, a global SST sales agent.
(I believe Unique Memec is the right place.)


//Peter


From rminnich at lanl.gov  Fri Jan 30 18:53:00 2004
From: rminnich at lanl.gov (ron minnich)
Date: Fri Jan 30 18:53:00 2004
Subject: AGP 3.0 bus analyzer
Message-ID: <Pine.LNX.4.44.0401301704560.3908-100000@maxroach.lanl.gov>

I'm looking for an AGP 3.0 interposer bus analyzer along the lines of what 
vmetro supplies. If anyone knows of such a thing, let me know. This AGP 
debug is a real pain without an analyzer. We're losing lots of time 
because it is hard to tell what signals are making it to AGP and what are 
not.

thanks

ron



From prl at peterlister.co.uk  Fri Jan 30 19:13:01 2004
From: prl at peterlister.co.uk (Peter Lister)
Date: Fri Jan 30 19:13:01 2004
Subject: Interesting HOWTO
In-Reply-To: <Pine.LNX.4.58.0401291621200.6724@ucontrol.mobiledns.com>
References: <401942C5.4080901@telefonica.net>
	 <20040129163820.GA31181@suse.de> <40194E81.7050907@telefonica.net>
	 <20040129173806.GA14412@suse.de>
	 <Pine.LNX.4.58.0401291621200.6724@ucontrol.mobiledns.com>
Message-ID: <1075508708.6342.761.camel@eddie>

On Thu, 2004-01-29 at 16:24, Steven James wrote:

> So far, it only supports uhci, but successfully enumerates the bus and
> loads an ELF image from some USB drives (It loads from the ones I have
> anyway).

Congratulations. This is very valuable work. I'll have a look when I can
get SF to let me cvs update...

But my immediate comment is that this code should be available to
Etherboot, FILO and anything else which needs to pull an image from a
USB device without the help of a legacy BIOS.




From steve at nexpath.com  Fri Jan 30 20:14:01 2004
From: steve at nexpath.com (Steve Gehlbach)
Date: Fri Jan 30 20:14:01 2004
Subject: Interesting HOWTO
In-Reply-To: <1075508708.6342.761.camel@eddie>
References: <401942C5.4080901@telefonica.net>	 <20040129163820.GA31181@suse.de> <40194E81.7050907@telefonica.net>	 <20040129173806.GA14412@suse.de>	 <Pine.LNX.4.58.0401291621200.6724@ucontrol.mobiledns.com> <1075508708.6342.761.camel@eddie>
Message-ID: <401B0681.5020805@nexpath.com>

Peter Lister wrote:


> But my immediate comment is that this code should be available to
> Etherboot, FILO and anything else which needs to pull an image from a
> USB device without the help of a legacy BIOS.
> 

Love to see this in FILO.

/sg



From bari at onelabs.com  Fri Jan 30 20:16:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Fri Jan 30 20:16:01 2004
Subject: AGP 3.0 bus analyzer
In-Reply-To: <Pine.LNX.4.44.0401301704560.3908-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401301704560.3908-100000@maxroach.lanl.gov>
Message-ID: <401B0531.5090100@onelabs.com>

ron minnich wrote:

> I'm looking for an AGP 3.0 interposer bus analyzer along the lines of what 
> vmetro supplies. If anyone knows of such a thing, let me know. This AGP 
> debug is a real pain without an analyzer. We're losing lots of time 
> because it is hard to tell what signals are making it to AGP and what are 
> not.

These are the two biggies:

http://www.futureplus.com/products/agp/fs2229_summary.html

http://www.tektronix.com/Measurement/cgi-bin/framed.pl?Document=/Measurement/logic_analyzers/bus_support/TMS809/&FrameSet=logic_analyzers

-Bari




From rminnich at lanl.gov  Sat Jan 31 00:07:01 2004
From: rminnich at lanl.gov (ron minnich)
Date: Sat Jan 31 00:07:01 2004
Subject: AGP 3.0 bus analyzer
In-Reply-To: <401B0531.5090100@onelabs.com>
Message-ID: <Pine.LNX.4.44.0401302218390.5887-100000@maxroach.lanl.gov>

As I read the manual for these two products it looks like I need to buy an 
external logic analyzer. Anybody seen a standalone card similar to the 
vmetro PCI analyzer?

ron



From pyro at linuxlabs.com  Sat Jan 31 10:43:01 2004
From: pyro at linuxlabs.com (Steven James)
Date: Sat Jan 31 10:43:01 2004
Subject: Interesting HOWTO
In-Reply-To: <1075508708.6342.761.camel@eddie>
References: <401942C5.4080901@telefonica.net>  <20040129163820.GA31181@suse.de>
 <40194E81.7050907@telefonica.net>  <20040129173806.GA14412@suse.de> 
 <Pine.LNX.4.58.0401291621200.6724@ucontrol.mobiledns.com>
 <1075508708.6342.761.camel@eddie>
Message-ID: <Pine.LNX.4.58.0401310745380.6724@ucontrol.mobiledns.com>

Greetings,

I agree. The loader I wrote is really just a quick and dirty way to
exercize the code for testing.

It souuldn't be too painful to link it in to other loaders and call the
ll_read_block function.

block_fill_inbuf.c best demonstrates the interface to the USB stack.
init_bytes() shows getting the bus enumerated and finding an appropriate
boot device and usb_read() shows grabbing the blocks.

Really, it's just a matter of calling usb_poll(0 in a loop until you see a
device you want or it quits finding new devices. usb_poll just checks all
known hubs for connect events and enumerates the device that was
connected. It returns 1 if it processed an event, 0 for no events and -1
for an error (retryable).

G'day,
sjames


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


On Sat, 31 Jan 2004, Peter Lister wrote:

> On Thu, 2004-01-29 at 16:24, Steven James wrote:
>
> > So far, it only supports uhci, but successfully enumerates the bus and
> > loads an ELF image from some USB drives (It loads from the ones I have
> > anyway).
>
> Congratulations. This is very valuable work. I'll have a look when I can
> get SF to let me cvs update...
>
> But my immediate comment is that this code should be available to
> Etherboot, FILO and anything else which needs to pull an image from a
> USB device without the help of a legacy BIOS.
>
>


From bari at onelabs.com  Sat Jan 31 12:07:01 2004
From: bari at onelabs.com (Bari Ari)
Date: Sat Jan 31 12:07:01 2004
Subject: AGP 3.0 bus analyzer
In-Reply-To: <Pine.LNX.4.44.0401302218390.5887-100000@maxroach.lanl.gov>
References: <Pine.LNX.4.44.0401302218390.5887-100000@maxroach.lanl.gov>
Message-ID: <401BE3EA.5020105@onelabs.com>

ron minnich wrote:

> As I read the manual for these two products it looks like I need to buy an 
> external logic analyzer. Anybody seen a standalone card similar to the 
> vmetro PCI analyzer?

I'd be surprised if someone makes a standalone card. There's just not a 
large enough market for it. There are only a few graphics companies vs. 
several that work with expansion buses like PCI.

Look at renting since you're probably not going to need the AGP 3.0 
analyzer long term.

http://www.twinhunter.com/Products/AGP/AGP%20Extender.html

and similar cards can be used along with a logic analyzer to look at bus 
activity since you're just interested in finding out if you're getting 
activity on the bus.

-Bari




From prl at peterlister.co.uk  Sat Jan 31 19:59:01 2004
From: prl at peterlister.co.uk (Peter Lister)
Date: Sat Jan 31 19:59:01 2004
Subject: Interesting HOWTO
In-Reply-To: <Pine.LNX.4.58.0401310745380.6724@ucontrol.mobiledns.com>
References: <401942C5.4080901@telefonica.net>
	 <20040129163820.GA31181@suse.de> <40194E81.7050907@telefonica.net>
	 <20040129173806.GA14412@suse.de>
	 <Pine.LNX.4.58.0401291621200.6724@ucontrol.mobiledns.com>
	 <1075508708.6342.761.camel@eddie>
	 <Pine.LNX.4.58.0401310745380.6724@ucontrol.mobiledns.com>
Message-ID: <1075597890.6342.1022.camel@eddie>

On Sat, 2004-01-31 at 08:02, Steven James wrote:

> It souuldn't be too painful to link it in to other loaders and call the
> ll_read_block function.
> 
> block_fill_inbuf.c best demonstrates the interface to the USB stack.
> init_bytes() shows getting the bus enumerated and finding an appropriate
> boot device and usb_read() shows grabbing the blocks.
> 
> Really, it's just a matter of calling usb_poll(0 in a loop until you see a
> device you want or it quits finding new devices. usb_poll just checks all
> known hubs for connect events and enumerates the device that was
> connected. It returns 1 if it processed an event, 0 for no events and -1
> for an error (retryable).

The Etherboot guys are champing at the bit for USB, and anything which
advances the work is very useful. I'm sure that with this and the Linux
usb ethernet dongle source, there'll be something soon.

Dumb question - how much work is it to add OHCI?




From prl at peterlister.co.uk  Sat Jan 31 20:24:00 2004
From: prl at peterlister.co.uk (Peter Lister)
Date: Sat Jan 31 20:24:00 2004
Subject: Interesting HOWTO
In-Reply-To: <1075597890.6342.1022.camel@eddie>
References: <401942C5.4080901@telefonica.net>
	 <20040129163820.GA31181@suse.de> <40194E81.7050907@telefonica.net>
	 <20040129173806.GA14412@suse.de>
	 <Pine.LNX.4.58.0401291621200.6724@ucontrol.mobiledns.com>
	 <1075508708.6342.761.camel@eddie>
	 <Pine.LNX.4.58.0401310745380.6724@ucontrol.mobiledns.com>
	 <1075597890.6342.1022.camel@eddie>
Message-ID: <1075599407.6342.1028.camel@eddie>

On Sun, 2004-02-01 at 01:11, Peter Lister wrote:

> Dumb question - how much work is it to add OHCI?

Duh, sorry, meant EHCI. The USB 2.0 one.




From pyro at linuxlabs.com  Sat Jan 31 21:42:01 2004
From: pyro at linuxlabs.com (Steven James)
Date: Sat Jan 31 21:42:01 2004
Subject: Interesting HOWTO
In-Reply-To: <1075597890.6342.1022.camel@eddie>
References: <401942C5.4080901@telefonica.net>  <20040129163820.GA31181@suse.de>
 <40194E81.7050907@telefonica.net>  <20040129173806.GA14412@suse.de> 
 <Pine.LNX.4.58.0401291621200.6724@ucontrol.mobiledns.com> 
 <1075508708.6342.761.camel@eddie>  <Pine.LNX.4.58.0401310745380.6724@ucontrol.mobiledns.com>
 <1075597890.6342.1022.camel@eddie>
Message-ID: <Pine.LNX.4.58.0401311858220.6724@ucontrol.mobiledns.com>

Greetings,

It would be handy to be able to rescue a machine with a USB NIC.

I'm not sure what it'll take for OHCI yet, but my new hardware has it, so
I'll fine out soon enough.

IIRC, OHCI does more in hardware, so it may actually be easier than uhci.

G'day,
sjames

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


On Sun, 1 Feb 2004, Peter Lister wrote:

> On Sat, 2004-01-31 at 08:02, Steven James wrote:
>
> > It souuldn't be too painful to link it in to other loaders and call the
> > ll_read_block function.
> >
> > block_fill_inbuf.c best demonstrates the interface to the USB stack.
> > init_bytes() shows getting the bus enumerated and finding an appropriate
> > boot device and usb_read() shows grabbing the blocks.
> >
> > Really, it's just a matter of calling usb_poll(0 in a loop until you see a
> > device you want or it quits finding new devices. usb_poll just checks all
> > known hubs for connect events and enumerates the device that was
> > connected. It returns 1 if it processed an event, 0 for no events and -1
> > for an error (retryable).
>
> The Etherboot guys are champing at the bit for USB, and anything which
> advances the work is very useful. I'm sure that with this and the Linux
> usb ethernet dongle source, there'll be something soon.
>
> Dumb question - how much work is it to add OHCI?
>
>


From pyro at linuxlabs.com  Sat Jan 31 21:58:00 2004
From: pyro at linuxlabs.com (Steven James)
Date: Sat Jan 31 21:58:00 2004
Subject: Interesting HOWTO
In-Reply-To: <1075599407.6342.1028.camel@eddie>
References: <401942C5.4080901@telefonica.net>  <20040129163820.GA31181@suse.de>
 <40194E81.7050907@telefonica.net>  <20040129173806.GA14412@suse.de> 
 <Pine.LNX.4.58.0401291621200.6724@ucontrol.mobiledns.com> 
 <1075508708.6342.761.camel@eddie>  <Pine.LNX.4.58.0401310745380.6724@ucontrol.mobiledns.com>
  <1075597890.6342.1022.camel@eddie> <1075599407.6342.1028.camel@eddie>
Message-ID: <Pine.LNX.4.58.0401311901290.6724@ucontrol.mobiledns.com>

Greetings,

I just got EHCI also :-)

I'm not sure it's all that necessary to support EHCI in firmware since any
USB 2.0 device is required to fall back if necessary. EHCI devices are
required to include a UHCI or OHCI companion device to handle 1.1 devices.
There's a bitmask to select which controls each port.

The USB boot over 1.1 only takes a second or 2 for a Linux kernel.
Given all that, the best bet is probably just set the ports to the
companion controller and support OHCI and UHCI.

G'day,
sjames

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


On Sun, 1 Feb 2004, Peter Lister wrote:

> On Sun, 2004-02-01 at 01:11, Peter Lister wrote:
>
> > Dumb question - how much work is it to add OHCI?
>
> Duh, sorry, meant EHCI. The USB 2.0 one.
>
>