Martin,
when I build s390x on s390 box, it fails without the
attached patch. Thought you might want to consder it.
If you support truly ancient compilers (2.7.2), it cannot
go in without some conditional compilation as sparc64 does.
Otherwise, it should be ok at least for 2.5.
Yours,
-- Pete
diff -urN -X dontdiff linux-2.4.20-2.1.14.s.1/arch/s390x/Makefile linux-2.4.20-2.1.14.s.2/arch/s390x/Makefile
--- linux-2.4.20-2.1.14.s.1/arch/s390x/Makefile 2002-08-02 20:39:43.000000000 -0400
+++ linux-2.4.20-2.1.14.s.2/arch/s390x/Makefile 2003-03-10 21:07:49.000000000 -0500
@@ -23,10 +23,11 @@
LINKFLAGS =-T $(TOPDIR)/arch/s390x/vmlinux.lds $(LDFLAGS)
endif
MODFLAGS += -fpic
+AFLAGS += -m64
CFLAGS_PIPE := -pipe
CFLAGS_NSR := -fno-strength-reduce
-CFLAGS := $(CFLAGS) $(CFLAGS_PIPE) $(CFLAGS_NSR)
+CFLAGS := $(CFLAGS) $(CFLAGS_PIPE) $(CFLAGS_NSR) -m64
HEAD := arch/s390x/kernel/head.o arch/s390x/kernel/init_task.o
diff -urN -X dontdiff linux-2.4.20-2.1.14.s.1/arch/s390x/vmlinux.lds linux-2.4.20-2.1.14.s.2/arch/s390x/vmlinux.lds
--- linux-2.4.20-2.1.14.s.1/arch/s390x/vmlinux.lds 2002-02-25 14:37:56.000000000 -0500
+++ linux-2.4.20-2.1.14.s.2/arch/s390x/vmlinux.lds 2003-03-10 21:07:49.000000000 -0500
@@ -1,8 +1,8 @@
-/* ld script to make s390 Linux kernel
+/* ld script to make s390x Linux kernel
* Written by Martin Schwidefsky ([email protected])
*/
OUTPUT_FORMAT("elf64-s390", "elf64-s390", "elf64-s390")
-OUTPUT_ARCH(s390)
+OUTPUT_ARCH(s390:64-bit)
ENTRY(_start)
SECTIONS
{
Hi Guys,
A long time ago I remember there was a guy working on a VESA FBconsole
driver for Linux. Then driver he was working on was structured as a user
land daemon that the kernel console driver would call back into once the
system was up, allowing the userland VESA driver to use the vm86()
service to change modes, program the palette and other useful things that
can't be done by the basic driver that uses a mode set previously by LILO
or GRUB.
My first question is, did this project ever get completed and included in
the Linux kernel at all? Does anyone have any reference to this project
that you can point me at?
My second question is, is it possible to execute vm86() services from
*within* the kernel as opposed to from user land? I got the impression at
the time that the userland daemon was used because vm86() could only be
called from userland code and could not be called from within the kernel
to execute real mode VESA BIOS services. Is that correct? If not, can
vm86() services now be called from other kernel modules inside the
kernel?
Feel free to email me directly with information if this is an FAQ to keep
traffic off the list.
Thanks!
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
I wrote:
> A long time ago I remember there was a guy working on a VESA
> FBconsole driver for Linux. Then driver he was working on was
> structured as a user land daemon that the kernel console driver
> would call back into once the system was up, allowing the userland
> VESA driver to use the vm86() service to change modes, program the
> palette and other useful things that can't be done by the basic
> driver that uses a mode set previously by LILO or GRUB.
No-one has responded to this email, so either no-one remembers this is
people think someone else responded to my email ;-)
Does anyone remember this project. I checked the Linux kernel and it
presently does not seem to have any support for this. Can anyone point me
at references that will help me figure out how the kernel can make
callbacks into a user land daemon?
> My second question is, is it possible to execute vm86() services
> from *within* the kernel as opposed to from user land? I got the
> impression at the time that the userland daemon was used because
> vm86() could only be called from userland code and could not be
> called from within the kernel to execute real mode VESA BIOS
> services. Is that correct? If not, can vm86() services now be
> called from other kernel modules inside the kernel?
I checked into this some more and it is clear that vm86() is only useable
from userland code on Linux. However recently the FreeBSD kernels were
modified to support vm86() from within the kernel, and in fact the latest
FreeBSD VESA console driver uses the vm86() services so that it can do
everything using the BIOS where necessary.
Is there any reason why the vm86() services in the Linux kernel cannot be
used by other kernel code? Has anyone made an attempt to update the
vm86() services to support this?
Thanks!
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
On Thu, Mar 13, 2003 at 01:31:01PM -0800, Kendall Bennett wrote:
> Kendall Bennett wrote:
>
> > A long time ago I remember there was a guy working on a VESA
> > FBconsole driver for Linux. Then driver he was working on was
> > structured as a user land daemon that the kernel console driver
> > would call back into once the system was up, allowing the userland
> > VESA driver to use the vm86() service to change modes, program the
> > palette and other useful things that can't be done by the basic
> > driver that uses a mode set previously by LILO or GRUB.
>
> No-one has responded to this email, so either no-one remembers this is
> people think someone else responded to my email ;-)
>
> Does anyone remember this project. I checked the Linux kernel and it
> presently does not seem to have any support for this. Can anyone point me
>
> at references that will help me figure out how the kernel can make
> callbacks into a user land daemon?
It was some guy from Finland and I'm under impression that this project
is dead, because BIOSes were proven to be completely unstable in Linux
environment. Try searching [email protected]
archives, maybe you'll find something.
> > My second question is, is it possible to execute vm86() services
> > from *within* the kernel as opposed to from user land? I got the
> > impression at the time that the userland daemon was used because
> > vm86() could only be called from userland code and could not be
> > called from within the kernel to execute real mode VESA BIOS
> > services. Is that correct? If not, can vm86() services now be
> > called from other kernel modules inside the kernel?
>
> I checked into this some more and it is clear that vm86() is only useable
>
> from userland code on Linux. However recently the FreeBSD kernels were
> modified to support vm86() from within the kernel, and in fact the latest
> FreeBSD VESA console driver uses the vm86() services so that it can do
> everything using the BIOS where necessary.
Maybe FreeBSD is too ia32 centric?
> Is there any reason why the vm86() services in the Linux kernel cannot be
> used by other kernel code? Has anyone made an attempt to update the
> vm86() services to support this?
Why you need it? To run some parts of VGA BIOS? Why you cannot run them
from userspace task? I think that it is much easier, especially now when
initramfs is here.
On ia32 people get binary drivers from vendors, and on non-ia32 VGA BIOS
is unusable without ia32 emulator (and no, I do not see any difference between
using binary-only driver for Linux and using binary-only BIOS).
Best regards,
Petr Vandrovec
[email protected]
"Kendall Bennett" <[email protected]> writes:
> No-one has responded to this email, so either no-one remembers this is
> people think someone else responded to my email ;-)
I remember, but havn't heard anything for a long time and don't know
the current status.
> at references that will help me figure out how the kernel can make
> callbacks into a user land daemon?
Look how /sbin/{hotplug|modprobe} is called if needed.
> Is there any reason why the vm86() services in the Linux kernel
> cannot be used by other kernel code?
Unlikely. To ugly to live with (says Linus, and lot of people agree),
and not really needed. Doing it in userspace also has the advantage
that you can play alot more tricks. XFree86 for example has a x86
emulator to execute vga bios code on !x86 platforms. _That_ you
really don't want to do in kernel mode ...
Gerd
--
/join #zonenkinder
Petr Vandrovec <[email protected]> wrote:
> It was some guy from Finland and I'm under impression that this
> project is dead, because BIOSes were proven to be completely
> unstable in Linux environment.
We have been using the VESA BIOS successfully in user land under Linux
for a long time now, and I would say that the BIOS'es are just as stable
under Linux as under any other platform (you just need to know how to
code around all the screwed up versions out there ;-).
> Try searching [email protected] archives,
> maybe you'll find something.
Ok, I will look. I tried searching the kernel lists but did not get
anywhere. Don't suppose you recall the name of this project?
> Maybe FreeBSD is too ia32 centric?
Perhaps, but vm86() but it's nature is ia32 specific anyway ;-)
> > Is there any reason why the vm86() services in the Linux kernel cannot be
> > used by other kernel code? Has anyone made an attempt to update the
> > vm86() services to support this?
>
> Why you need it? To run some parts of VGA BIOS? Why you cannot run
> them from userspace task? I think that it is much easier,
> especially now when initramfs is here.
The reason why it would nice is so that the VESA FBconsole driver (and in
fact all the FBconsole drivers that use the real mode BIOS to set an
initial display mode) can restore that mode correctly when an application
exists and restores the console. Right now it is up to the application
program to restore the console, as the kernel has absolutely no way to do
it. If that program has not way to restore it (old SVGALib code for
instance) or the application crashes, you are stuck with a black screen
if you are using a framebuffer console. If the kernel knew how to call
the BIOS to restore the mode, this problem could be completely eliminated
and services could be provided to properly restore the system state when
console graphics programs crash (or the X server for that matter if it
crashes and does not properly clean up).
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
> Gerd Knorr <[email protected]> wrote:
> > at references that will help me figure out how the kernel can make
> > callbacks into a user land daemon?
>
> Look how /sbin/{hotplug|modprobe} is called if needed.
Ok thanks.
> > Is there any reason why the vm86() services in the Linux kernel
> > cannot be used by other kernel code?
>
> Unlikely. To ugly to live with (says Linus, and lot of people
> agree), and not really needed.
Why is it ugly? IMHO it is very much needed, as it would provide a
mechanism for the kernel to be able to properly restore the screen if a
user land program goes astray.
> Doing it in userspace also has the advantage that you can play alot
> more tricks.
More tricks like what? All we need is the ability to call the BIOS and
have it execute the necessary real mode code, just like we do on ia32
machines in user land.
> XFree86 for example has a x86 emulator to execute vga bios code on
> !x86 platforms. _That_ you really don't want to do in kernel mode
> ...
Yes, I am aware of the x86 emulator - I revived the project a few years
back and Egbert Eich integrated it into XFree86 ;-)
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
Kendall Bennett wrote:
> Why is it ugly? IMHO it is very much needed, as it would provide a
> mechanism for the kernel to be able to properly restore the screen
> if a user land program goes astray.
First - the bios isn't always able to fix the screen - the program may
have programmed the video hardware in odd ways the bios don't know
about. Bioses aren't a magic fix.
Second, the proper way to do this is for the video driver to fix it up,
using more efficient code that runs under linux without special
consideration because it was written for that case.
> More tricks like what? All we need is the ability to call the BIOS and
> have it execute the necessary real mode code, just like we do on ia32
> machines in user land.
Ability to call the bios in real mode is no simple feat. And the bios
may screw up. That doesn't matter for a user program, it just crashes
and don't damage anything else. You don't want the kernel to crash -
ever. A broken bios is _no_ excuse here.
Bioses are generally too limited. They make a lot of stupid
assumptions, thinking it is ok to use legacy vga registers and things
like that. Consider a machine with two or more video cards. Linux
handles that fine, but a bios? Or really two bioses, one for each card?
Imagine a dual processor where one one processor executes one bios and
the other processor another bios , each trying to set up one card.
Somehow I think this won't work too well.
As for userspace tricks - userspace can do all sorts of nifty things
like actually open a file and read it. For example a file
with the latest list of bios oddities to work around.
Helge Hafting
On Thu, 13 Mar 2003, Kendall Bennett wrote:
> Petr Vandrovec <[email protected]> wrote:
> > Why you need it? To run some parts of VGA BIOS? Why you cannot run
> > them from userspace task? I think that it is much easier,
> > especially now when initramfs is here.
>
> The reason why it would nice is so that the VESA FBconsole driver (and in
> fact all the FBconsole drivers that use the real mode BIOS to set an
> initial display mode) can restore that mode correctly when an application
> exists and restores the console. Right now it is up to the application
> program to restore the console, as the kernel has absolutely no way to do
> it. If that program has not way to restore it (old SVGALib code for
> instance) or the application crashes, you are stuck with a black screen
> if you are using a framebuffer console. If the kernel knew how to call
> the BIOS to restore the mode, this problem could be completely eliminated
> and services could be provided to properly restore the system state when
> console graphics programs crash (or the X server for that matter if it
> crashes and does not properly clean up).
Assumed the BIOS can recover from whatever the application has done to the
graphics chipset...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Kendall Bennett wrote:
> The reason why it would nice is so that the VESA FBconsole driver (and in
> fact all the FBconsole drivers that use the real mode BIOS to set an
> initial display mode) can restore that mode correctly when an application
> exists and restores the console. Right now it is up to the application
> program to restore the console, as the kernel has absolutely no way to do
> it. If that program has not way to restore it (old SVGALib code for
> instance) or the application crashes, you are stuck with a black screen
> if you are using a framebuffer console. If the kernel knew how to call
> the BIOS to restore the mode, this problem could be completely eliminated
> and services could be provided to properly restore the system state
The bios isn't the way to go. Unless the bios coders puts an _ordinary_
linux kernel module in their eprom.
If the kernel knew how to restore the video state itself - that'd be
something. Go complain to those who keeps such knowledge secret.
And no, they won't risk their company on providing such information.
Setting the modes is such a tiny little piece of what a graphichs
card do. (Providing full information on how to program the
accelerator chips wouldn't kill them either...)
Helge Hafting
Helge Hafting <[email protected]> wrote:
> > Why is it ugly? IMHO it is very much needed, as it would provide a
> > mechanism for the kernel to be able to properly restore the screen
> > if a user land program goes astray.
>
> First - the bios isn't always able to fix the screen - the program may
> have programmed the video hardware in odd ways the bios don't know
> about. Bioses aren't a magic fix.
Exactly what facts do you base the above statement on? Have you seen this
in practice?
I can tell you from my own personal experience that the BIOS on the
graphics card can nearly always restore the screen no matter what state
you have put the graphics hardware into. I have done development in DOS
for years writing the UniVBE and SciTech Display Doctor products, and we
have always used the BIOS to restore the screen when one of our graphics
drivers crashed during development.
> Second, the proper way to do this is for the video driver to fix
> it up, using more efficient code that runs under linux without
> special consideration because it was written for that case.
Great, assuming you *have* a video driver for the card in question! There
are lots of cards that can run on the VESA fbconsole driver that uses a
mode set by the real mode boot loader and can never be changed once the
system is up and running. For those particular devices using the BIOS is
the *perfect* solution IMHO (if the driver was so easy to write it would
already exist).
> > More tricks like what? All we need is the ability to call the BIOS and
> > have it execute the necessary real mode code, just like we do on ia32
> > machines in user land.
>
> Ability to call the bios in real mode is no simple feat. And the
> bios may screw up. That doesn't matter for a user program, it just
> crashes and don't damage anything else. You don't want the kernel
> to crash - ever. A broken bios is _no_ excuse here.
We are talking about using the BIOS to do the most basic and simple thing
that it does - set a display mode. Sure BIOS'es are buggy, but even the
crappiest BIOS on the planet can properly set the display mode without
crashing! They have to, or their Windows 9x drivers would never have
worked.
Anyway this is a moot point because I do believe that if we implement the
VESAFBD style daemon that Aki was working on we can avoid the need for
the vm86() calls to be made from the kernel anyway, and have them run in
the protected space of a userland daemon. Then if the BIOS does crash
(unlikely IMHO), it won't crash the kernel.
> Bioses are generally too limited. They make a lot of stupid
> assumptions, thinking it is ok to use legacy vga registers and
> things like that. Consider a machine with two or more video cards.
> Linux handles that fine, but a bios? Or really two bioses, one for
> each card?
What about it? How do you think Linux brings up the secondary graphics
card for dual head operations? It uses the *BIOS*! I know that because I
resurrected the x86emu project that is used to warmboot the secondary
graphics cards. You can in fact do it on x86 Linux without needing the
BIOS emulator at all, just using the vm86() services and some nify copy
on write features of the Linux kenerl. As far as legacy I/O port access
goes, the BIOS will nearly always do that, but if you only run the BIOS
on one card at a time, this is no problem. The PCI spec allows you to
selectively enable and disable the I/O port access on any graphics card
on the bus as you see fit. So you simply disable the primary card, enable
the secondary card and let the BIOS have at it.
This does work, because it is how secondary controllers are done on Linux
today.
> Imagine a dual processor where one one processor executes one bios
> and the other processor another bios , each trying to set up one
> card. Somehow I think this won't work too well.
No, it wouldn't and you would need to ensure mutually exclusive access to
the graphics cards. Simple problem really and since XFree86 is not
threaded is not a problem in the existing code anyway, but if it is that
is pretty a simple multu-processor programming problem.
> As for userspace tricks - userspace can do all sorts of nifty
> things like actually open a file and read it. For example a file
> with the latest list of bios oddities to work around.
Definately. I have no argument there.
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
Geert Uytterhoeven <[email protected]> wrote:
> Assumed the BIOS can recover from whatever the application has done to the
> graphics chipset...
If the program just crashed (and did not lock the graphics card), the
BIOS can nearly always restore the screen properly. I know that from the
years of doing graphics development under DOS and always using the BIOS
to restore the screen when I screwed up and crashed my graphics programs
;-)
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
Kendall Bennett wrote:
> Helge Hafting <[email protected]> wrote:
>
>
>> > Why is it ugly? IMHO it is very much needed, as it would provide a
>> > mechanism for the kernel to be able to properly restore the screen
>> > if a user land program goes astray.
>>
>>First - the bios isn't always able to fix the screen - the program may
>>have programmed the video hardware in odd ways the bios don't know
>>about. Bioses aren't a magic fix.
>
>
> Exactly what facts do you base the above statement on? Have you seen this
> in practice?
>
I havent seen it, but the matrox fbdev can do things like turning the
legacy vga and/or bios off. (it makes sense on secondary cards)
There is the warning that such a card may need a power-off in
order to recover. I.e. ordinary reboot won't help.
> I can tell you from my own personal experience that the BIOS on the
> graphics card can nearly always restore the screen no matter what state
> you have put the graphics hardware into.
Great. It wasn't always so in the early 1990's. I once had a pc I had
to turn off whenever the os/2 video driver died. The pc would restart
using the reset button too, but the screen was black unless I powered
it off.
> Great, assuming you *have* a video driver for the card in question! There
> are lots of cards that can run on the VESA fbconsole driver that uses a
> mode set by the real mode boot loader and can never be changed once the
> system is up and running. For those particular devices using the BIOS is
> the *perfect* solution IMHO (if the driver was so easy to write it would
> already exist).
A driver supporting a modern video card may not be easy - supporting
mode changes _only_ (and use fbconsole for unaccelerated graphichs)
would likely be easy enough if stupid vendors didn't withold
information. I cannot imagine a trade secret in the mode change
programming.
>
> What about it? How do you think Linux brings up the secondary graphics
> card for dual head operations? It uses the *BIOS*!
I know. I tried, and it failed. :-/
> As far as legacy I/O port access
> goes, the BIOS will nearly always do that, but if you only run the BIOS
> on one card at a time, this is no problem. The PCI spec allows you to
> selectively enable and disable the I/O port access on any graphics card
> on the bus as you see fit. So you simply disable the primary card, enable
> the secondary card and let the BIOS have at it.
>
That works, but doing all that pci disabling looks like a silly
limitation to me. Of course it is necessary if no driver exists, but
then I wouldn't buy that card for a linux machine in the first place.
> No, it wouldn't and you would need to ensure mutually exclusive access to
> the graphics cards. Simple problem really and since XFree86 is not
> threaded is not a problem in the existing code anyway, but if it is that
> is pretty a simple multu-processor programming problem.
What I want is to run two xservers on different screens. Two processes
so they may run simultaneosly. And they shouldn't need to wait for each
other because the hardware itself don't need that.
Helge Hafting