ATI rage xl.init

[YhLu]

Stefan,

I move the kernel patch that init rage xl for fb into LinuxBIOS. You can
disable the patch in Kernel and still can use rage xl for fb.

Regards

YH

YhLu  writes:
> Stefan,
>
> I move the kernel patch that init rage xl for fb into LinuxBIOS. You can
> disable the patch in Kernel and still can use rage xl for fb.

Cool.  I have been meaning to try that for a long time I just have
not been able to find the time.

Unless we see some serious problems this looks like a good model for
how to handle onboard graphics chips.

Eric

[Gregg C Levine]

Hello from Gregg C Levine
It happens that I can use the frame buffer functions on my ATI Rage
128 without much of a hassle. In fact that's the native mode of the
video card. (And this is on a native BIOS, not the subject of the
group.)

Without breaking your NDA, could you enlighten the group regarding how
you are going about the enabling of this ATI card? And where did you
find the details for the frame buffer modes for this ATI video card?
Were they provided that way? If so, then I don't need to know.  
-------------------
Gregg C Levine [e-mail]
------------------------------------------------------------
"The Force will be with you...Always." Obi-Wan Kenobi
"Use the Force, Luke."  Obi-Wan Kenobi
> -----Original Message-----
> From: [e-mail] [mailto:linuxbios-
> [e-mail]] On Behalf Of Eric W. Biederman
> Sent: Monday, April 12, 2004 8:29 PM
> To: YhLu
> Cc: ron minnich; Stefan Reinauer; Takeshi Sone;

[e-mail]
> Subject: Re: ATI rage xl.init
>
> YhLu  writes:
> > Stefan,
> >
> > I move the kernel patch that init rage xl for fb into LinuxBIOS.

You can
> > disable the patch in Kernel and still can use rage xl for fb.
>
> Cool.  I have been meaning to try that for a long time I just have
> not been able to find the time.
>
> Unless we see some serious problems this looks like a good model for
> how to handle onboard graphics chips.
>
> Eric
> _______________________________________________
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

[ron minnich]

On 12 Apr 2004, Eric W. Biederman wrote:
> Unless we see some serious problems this looks like a good model for
> how to handle onboard graphics chips.

I agree I like this too, however, it still does not solve things like the 
nvidia cards.

ron

[Stefan Reinauer]

* YhLu  [040412 23:23]:
> I move the kernel patch that init rage xl for fb into LinuxBIOS. You can
> disable the patch in Kernel and still can use rage xl for fb.

wonderful! I've commited this to the V2 CVS and moved the Trident
Blade3d driver there as well. I changed the directory layout a little
bit to suit northbridge/southbridge/mainboard by using
driver/vendor/device as the path to the device init code.

What is the right way of getting this code into a LinuxBIOS build?
Should there be some "driver" directive like there's "northbridge" and
"southbridge"? Or is there some better idea?

If we can now get hands on loading firmware into the LSI1020/1030, we'd
be prepared for a lot of nice opteron servers and possibly many others.

Stefan

Stefan Reinauer  writes:
> YhLu  [040412 23:23]:
> > I move the kernel patch that init rage xl for fb into LinuxBIOS. You can
> > disable the patch in Kernel and still can use rage xl for fb.
>
> wonderful! I've commited this to the V2 CVS and moved the Trident
> Blade3d driver there as well. I changed the directory layout a little
> bit to suit northbridge/southbridge/mainboard by using
> driver/vendor/device as the path to the device init code.
>
> What is the right way of getting this code into a LinuxBIOS build?
> Should there be some "driver" directive like there's "northbridge" and
> "southbridge"? Or is there some better idea?

Use the dir command.  northbridge/southbridge/etc are just specializations
of it.
> If we can now get hands on loading firmware into the LSI1020/1030, we'd
> be prepared for a lot of nice opteron servers and possibly many others.

The Linux driver does not load the firmware?  Or do we need SCSI support?

Eric

[Stefan Reinauer]

* Eric W. Biederman  [040413 14:40]:
> > What is the right way of getting this code into a LinuxBIOS build?
> > Should there be some "driver" directive like there's "northbridge" and
> > "southbridge"? Or is there some better idea?
> Use the dir command.  northbridge/southbridge/etc are just specializations
> of it.

Ah, right!
> > If we can now get hands on loading firmware into the LSI1020/1030, we'd
> > be prepared for a lot of nice opteron servers and possibly many others.
>
> The Linux driver does not load the firmware?  Or do we need SCSI support?

The Linux driver does not load the firmware at the moment. The Linux
driver just bails out without being able to load anything from disk.
Otoh, it's kind of crucial to boot off SCSI drives in future. Since the
LSI10[2|3]0 is pretty wide spread among opteron systems, it would give
us a pretty good start.

Stefan

[ron minnich]

On 13 Apr 2004, Eric W. Biederman wrote:
> The Linux driver does not load the firmware?  Or do we need SCSI support?

You're going to love this one Eric :-)

I might just need it for Plan 9 :-)

So, much as I always disliked the idea of loading SCSI firmware, I might 
want it now :-(

ron

[Stefan Reinauer]

* ron minnich  [040413 16:06]:
> I might just need it for Plan 9 :-)
>
> So, much as I always disliked the idea of loading SCSI firmware, I might 
> want it now :-(

SCSI firmware imho really belongs on the SCSI controller you put in. At
least as long as we don't live in a world of perfect, intelligent and 
self-initializing hardware, this is the way of smallest trouble if we
don't want to lock potential customers/users away. For onboard hardware
this means we want a minimal set of drivers in LinuxBIOS, unfortunately.

Stefan

Stefan Reinauer  writes:
> ron minnich  [040413 16:06]:
> > I might just need it for Plan 9 :-)
> >
> > So, much as I always disliked the idea of loading SCSI firmware, I might 
> > want it now :-(
>
> SCSI firmware imho really belongs on the SCSI controller you put in. At
> least as long as we don't live in a world of perfect, intelligent and 
> self-initializing hardware, this is the way of smallest trouble if we
> don't want to lock potential customers/users away. For onboard hardware
> this means we want a minimal set of drivers in LinuxBIOS, unfortunately.

If we can do it, I don't see a problem putting the code somewhere
in the motherboard BIOS.  Basically the LinuxBIOS mandate is to make
the hardware functional.

One thing to watch is that a LinuxBIOS driver is not really a driver
more of an initializer.

However there is no point in doing work that can be done elsewhere,
like probing a scsi or ide chain for devices.

Eric

[ron minnich]

On Tue, 13 Apr 2004, Stefan Reinauer wrote:
> What is the right way of getting this code into a LinuxBIOS build?
> Should there be some "driver" directive like there's "northbridge" and
> "southbridge"? Or is there some better idea?

Driver  sounds ok to me. This would get the driver into the static device 
tree. The convention could be that drivers are called with the same passes 
that any other static device is called with.

I think the structure of V2 would support this just fine.

ron

[ron minnich]

On Tue, 13 Apr 2004, ron minnich wrote:
> Driver  sounds ok to me. This would get the driver into the static device 
> tree. The convention could be that drivers are called with the same passes 
> that any other static device is called with.

It's true that 'dir' would work. The other commands are all for the most 
part handly aliases for 'dir'.

So if people want to just go with 'dir', fine, if we want another noise 
word, 'device' is fine too. One thing, the new noise word 'device' does 
give us the future ability to do special things for devices if we need to.

ron

[Stefan Reinauer]

* ron minnich  [040413 16:10]:
> It's true that 'dir' would work. The other commands are all for the most 
> part handly aliases for 'dir'.
>
> So if people want to just go with 'dir', fine, if we want another noise 
> word, 'device' is fine too. One thing, the new noise word 'device' does 
> give us the future ability to do special things for devices if we need to.

I've adapted the newisys khepri build to use the trident blade 3d code
in drivers/.

What boards use an onboard Rage XL?
 * Tyan S2880?
 * Arima HDAM*
 * AMD Quartet

any more?

Stefan

[ron minnich]

On Tue, 13 Apr 2004, Stefan Reinauer wrote:
> What boards use an onboard Rage XL?
> Tyan S2880?
> Arima HDAM*
> AMD Quartet

ibm e325

ron

Stefan Reinauer  writes:
> ron minnich  [040413 16:10]:
> > It's true that 'dir' would work. The other commands are all for the most 
> > part handly aliases for 'dir'.
> >
> > So if people want to just go with 'dir', fine, if we want another noise 
> > word, 'device' is fine too. One thing, the new noise word 'device' does 
> > give us the future ability to do special things for devices if we need to.
>
> I've adapted the newisys khepri build to use the trident blade 3d code
> in drivers/.
>
> What boards use an onboard Rage XL?
> Tyan S2880?
> Arima HDAM*
> AMD Quartet
>
> any more?

Probably not in the freebios2 tree..

Pretty much every server board I have touched in the last
3 years has one.  If I have some spare time that will be a good
excuse to do some forward ports.

Eric