"Cross" compilation for s390x

"Cross" compilation for s390x

[Pete Zaitcev]

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 (schwidefsky@de.ibm.com)
  */
 OUTPUT_FORMAT("elf64-s390", "elf64-s390", "elf64-s390")
-OUTPUT_ARCH(s390)
+OUTPUT_ARCH(s390:64-bit)
 ENTRY(_start)
 SECTIONS
 {

VESA FBconsole driver?

[Kendall Bennett]

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! ~

Re: VESA FBconsole driver?

[Kendall Bennett]

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! ~

Re: VESA FBconsole driver?

[Petr Vandrovec]

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 linux-fbdev-devel@lists.sourceforge.net 
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
						vandrove@vc.cvut.cz

Re: VESA FBconsole driver?

[Kendall Bennett]

Petr Vandrovec <vandrove@vc.cvut.cz> 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 linux-fbdev-devel@lists.sourceforge.net 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! ~

Re: VESA FBconsole driver?

[Geert Uytterhoeven]

On Thu, 13 Mar 2003, Kendall Bennett wrote:
> Petr Vandrovec <vandrove@vc.cvut.cz> 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 -- geert@linux-m68k.org

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

Re: VESA FBconsole driver?

[Kendall Bennett]

Geert Uytterhoeven <geert@linux-m68k.org> 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! ~

Re: VESA FBconsole driver?

[Helge Hafting]

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

Re: VESA FBconsole driver?

[Gerd Knorr]

"Kendall Bennett" <KendallB@scitechsoft.com> 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

Re: VESA FBconsole driver?

[Kendall Bennett]

> Gerd Knorr <kraxel@bytesex.org> 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! ~

Re: VESA FBconsole driver?

[Helge Hafting]

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

Re: VESA FBconsole driver?

[Kendall Bennett]

Helge Hafting <helgehaf@aitel.hist.no> 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! ~

Re: VESA FBconsole driver?

[Helge Hafting]

Kendall Bennett wrote:
> Helge Hafting <helgehaf@aitel.hist.no> 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