* x86 - Realmode BIOS and Code calling module
@ 2004-08-12 9:36 Jakub Vana
2004-08-12 11:56 ` Alan Cox
` (3 more replies)
0 siblings, 4 replies; 13+ messages in thread
From: Jakub Vana @ 2004-08-12 9:36 UTC (permalink / raw)
To: linux-kernel
Hello,
I have written Linux Kernel module that allows you to call BIOS interupts, Far services or your own code. It's working on x86 machines with PAE or not PAE enabled(up to 4GB or up to 64GB). It's tested on 2.4.26 and 2.6.7 kernel on P4 machine. I think there is not problem to work on others. Now, I'm preparing DOCs and Demos.
I wrote the module especialy for changing the VESAFB videomode, but It is usable anywhere the BIOS is neaded.
I'm writing you to know this code exists and to ask you for help to add this code to official Kernel distribution.
Thank you
Jakub Vana
--------------------
Připravte se! Je tu škola. Navštivte včas Palác Flóra. Od 20.srpna do 5.září probíhá v Paláci Flóra speciální trh školních potřeb. http://user.centrum.cz/redir.php?url=http://www.palacflora.com
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: x86 - Realmode BIOS and Code calling module
2004-08-12 9:36 x86 - Realmode BIOS and Code calling module Jakub Vana
@ 2004-08-12 11:56 ` Alan Cox
2004-09-06 15:27 ` Jozef Vesely
2004-08-12 12:39 ` Grzegorz Kulewski
` (2 subsequent siblings)
3 siblings, 1 reply; 13+ messages in thread
From: Alan Cox @ 2004-08-12 11:56 UTC (permalink / raw)
To: Jakub Vana; +Cc: Linux Kernel Mailing List
On Iau, 2004-08-12 at 10:36, Jakub Vana wrote:
> Hello,
>
> I have written Linux Kernel module that allows you to call BIOS
> interupts, Far services or your own code.
Why is this better than LRMI in user mode. To do BIOS calls safely
you need to be very careful about things like PCI locking, I/O
emulation and the ROM scribbling in strange places. LRMI can handle this
in user space as does x86emu in Xorg.
All you should thus need is an ioctl in vesafb to tell it you've
changed the display properties and here is the new layout to use.
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: x86 - Realmode BIOS and Code calling module
2004-08-12 11:56 ` Alan Cox
@ 2004-09-06 15:27 ` Jozef Vesely
2004-09-06 17:03 ` Alan Cox
0 siblings, 1 reply; 13+ messages in thread
From: Jozef Vesely @ 2004-09-06 15:27 UTC (permalink / raw)
To: Alan Cox; +Cc: Jakub Vana, Linux Kernel Mailing List
On Thu, 12 Aug 2004, Alan Cox wrote:
> On Iau, 2004-08-12 at 10:36, Jakub Vana wrote:
> > Hello,
> >
> > I have written Linux Kernel module that allows you to call BIOS
> > interupts, Far services or your own code.
>
> Why is this better than LRMI in user mode. To do BIOS calls safely
> you need to be very careful about things like PCI locking, I/O
> emulation and the ROM scribbling in strange places. LRMI can handle this
> in user space as does x86emu in Xorg.
>
In-kernel BIOS calls are useful:
I (and many others) have experienced problems with resuming from ACPI S3
state. Some graphic cards need to have their state saved before suspend
and restored after resume, otherwise the screen stays blank. VESA BIOS
call 0x4f04, does exactly that.
Yes it can be done from userspace, but at the time devices are woken up,
userspace processes are still sleeping. And if something goes wrong with
device wakeup (not uncommon thing with ACPI :-) ), you end up with a
backtrace on a blank screen :-(. (Modern laptops do not have serial port
to hook up terminal to.)
to Jakub:
You promised to put that code somewhere on the net, could
you please send me an URL.
Thank you
Jozef Vesely
vesely@gjh.sk
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: x86 - Realmode BIOS and Code calling module
2004-09-06 15:27 ` Jozef Vesely
@ 2004-09-06 17:03 ` Alan Cox
0 siblings, 0 replies; 13+ messages in thread
From: Alan Cox @ 2004-09-06 17:03 UTC (permalink / raw)
To: Jozef Vesely; +Cc: Jakub Vana, Linux Kernel Mailing List
On Llu, 2004-09-06 at 16:27, Jozef Vesely wrote:
> In-kernel BIOS calls are useful:
> I (and many others) have experienced problems with resuming from ACPI S3
> state. Some graphic cards need to have their state saved before suspend
> and restored after resume, otherwise the screen stays blank. VESA BIOS
> call 0x4f04, does exactly that.
As I understand it VESA 0x4F04 is for saving/restoring mode state, not
restoring the video card from poweroff. Correct me if I'm wrong here.
Secondly if you wanted to do this cleanly you could still do the save
from vm86 in user space and the restore on the 16bit return path having
checked a save was made and that the video bios hasn't gone for a walk.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: x86 - Realmode BIOS and Code calling module
2004-08-12 9:36 x86 - Realmode BIOS and Code calling module Jakub Vana
2004-08-12 11:56 ` Alan Cox
@ 2004-08-12 12:39 ` Grzegorz Kulewski
2004-08-12 12:50 ` Vojtech Pavlik
2004-08-16 7:49 ` Pavel Machek
3 siblings, 0 replies; 13+ messages in thread
From: Grzegorz Kulewski @ 2004-08-12 12:39 UTC (permalink / raw)
To: Jakub Vana; +Cc: linux-kernel
On Thu, 12 Aug 2004, Jakub Vana wrote:
> Hello,
>
> I have written Linux Kernel module that allows you to call BIOS interupts, Far services or your own code. It's working on x86 machines with PAE or not PAE enabled(up to 4GB or up to 64GB). It's tested on 2.4.26 and 2.6.7 kernel on P4 machine. I think there is not problem to work on others. Now, I'm preparing DOCs and Demos.
>
> I wrote the module especialy for changing the VESAFB videomode, but It is usable anywhere the BIOS is neaded.
>
> I'm writing you to know this code exists and to ask you for help to add this code to official Kernel distribution.
Did you saw vesafb-tng at http://dev.gentoo.org/~spock/?
Thanks,
Grzegorz Kulewski
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: x86 - Realmode BIOS and Code calling module
2004-08-12 9:36 x86 - Realmode BIOS and Code calling module Jakub Vana
2004-08-12 11:56 ` Alan Cox
2004-08-12 12:39 ` Grzegorz Kulewski
@ 2004-08-12 12:50 ` Vojtech Pavlik
2004-08-16 7:49 ` Pavel Machek
3 siblings, 0 replies; 13+ messages in thread
From: Vojtech Pavlik @ 2004-08-12 12:50 UTC (permalink / raw)
To: Jakub Vana; +Cc: linux-kernel
On Thu, Aug 12, 2004 at 11:36:40AM +0200, Jakub Vana wrote:
> Hello,
>
> I have written Linux Kernel module that allows you to call BIOS interupts, Far services or your own code. It's working on x86 machines with PAE or not PAE enabled(up to 4GB or up to 64GB). It's tested on 2.4.26 and 2.6.7 kernel on P4 machine. I think there is not problem to work on others. Now, I'm preparing DOCs and Demos.
>
> I wrote the module especialy for changing the VESAFB videomode, but It is usable anywhere the BIOS is neaded.
>
> I'm writing you to know this code exists and to ask you for help to add this code to official Kernel distribution.
Can't this be done from userspace without kernel support? I think X
already does exactly that to initialize secondary VGA cards, and to set
videomodes on intel VGA's.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: x86 - Realmode BIOS and Code calling module
2004-08-12 9:36 x86 - Realmode BIOS and Code calling module Jakub Vana
` (2 preceding siblings ...)
2004-08-12 12:50 ` Vojtech Pavlik
@ 2004-08-16 7:49 ` Pavel Machek
3 siblings, 0 replies; 13+ messages in thread
From: Pavel Machek @ 2004-08-16 7:49 UTC (permalink / raw)
To: Jakub Vana; +Cc: linux-kernel
Hi!
> I have written Linux Kernel module that allows you to call BIOS
> interupts, Far services or your own code. It's working on x86
> machines with PAE or not PAE enabled(up to 4GB or up to 64GB). It's
> tested on 2.4.26 and 2.6.7 kernel on P4 machine. I think there is
> not problem to work on others. Now, I'm preparing DOCs and Demos.
How is it better from code Ole Rohne has?
> I wrote the module especialy for changing the VESAFB videomode, but It is usable anywhere the BIOS is neaded.
>
> I'm writing you to know this code exists and to ask you for help to add this code to official Kernel distribution.
Hmm, perhaps you should add at least pointer to the code there.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: x86 - Realmode BIOS and Code calling module
@ 2004-08-12 13:38 Jakub Vana
2004-08-12 20:30 ` Alan Cox
2004-08-13 7:44 ` Vojtech Pavlik
0 siblings, 2 replies; 13+ messages in thread
From: Jakub Vana @ 2004-08-12 13:38 UTC (permalink / raw)
To: alan, gugux; +Cc: linux-kernel
______________________________________________________________
> Od: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Komu: Jakub Vana <gugux@centrum.cz>
> CC: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Datum: Thu, 12 Aug 2004 12:56:43 +0100
> Předmět: Re: x86 - Realmode BIOS and Code calling module
>
> On Iau, 2004-08-12 at 10:36, Jakub Vana wrote:
> > Hello,
> >
> > I have written Linux Kernel module that allows you to call BIOS
> > interupts, Far services or your own code.
>
> Why is this better than LRMI in user mode.
I was now looking on LRMI. It must be a nice code, but It is still only V86 emulation. I have listen that some BIOSes use something called Unreal mode, that is realmode with segment registers used like in protected mode. There is only one way, how to set this segregs - switch to prot. mode, but if the BIOS try to switch when is running in V86 CPU generates #GP (Global Protection fault). Not if it is running in real Real Mode.
> To do BIOS calls safely
> you need to be very careful about things like PCI locking, I/O
> emulation and the ROM scribbling
I'm not sure abou this, but I think there is not problem in calling BIOS, here is problem in BIOS handling with this features and so It's the problem of programmer that calls the BIOS to safely work and synchronize his hardware in kernel with BIOS. Other hardware (that is not pawn by BIOS) can't make problems.
>in strange places. LRMI can handle this
> in user space as does x86emu in Xorg.
>
> All you should thus need is an ioctl in vesafb to tell it you've
> changed the display properties and here is the new layout to use.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--------------------
Připravte se! Je tu škola. Navštivte včas Palác Flóra. Od 20.srpna do 5.září probíhá v Paláci Flóra speciální trh školních potřeb. http://user.centrum.cz/redir.php?url=http://www.palacflora.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: x86 - Realmode BIOS and Code calling module
2004-08-12 13:38 Jakub Vana
@ 2004-08-12 20:30 ` Alan Cox
2004-08-13 7:44 ` Vojtech Pavlik
1 sibling, 0 replies; 13+ messages in thread
From: Alan Cox @ 2004-08-12 20:30 UTC (permalink / raw)
To: Jakub Vana; +Cc: Linux Kernel Mailing List
On Iau, 2004-08-12 at 14:38, Jakub Vana wrote:
> > Why is this better than LRMI in user mode.
>
> I was now looking on LRMI. It must be a nice code, but It is still only
> V86 emulation. I have listen that some BIOSes use something called
> Unreal mode, that is realmode with segment registers used like in
> protected mode. There is only one way, how to set this segregs -
> switch to prot. mode, but if the BIOS try to switch when is running
> in V86 CPU generates #GP (Global Protection fault). Not if it is
> running in real Real Mode.
I've yet to meet a video bios that does this. I don't think the X folks
have either, but you could run it past Egbert to make sure. The
"unreal" mode is normally only in existance during early boot.
>
> > To do BIOS calls safely
> > you need to be very careful about things like PCI locking, I/O
> > emulation and the ROM scribbling
>
> I'm not sure abou this, but I think there is not problem in calling
> BIOS, here is problem in BIOS handling with this features and so
> It's the problem of programmer that calls the BIOS to safely work
> and synchronize his hardware in kernel with BIOS. Other hardware
> (that is not pawn by BIOS) can't make problems.
One example is PCI configuration accesses which must be co-ordinated
with the kernel, and through the kernel PCI interfaces.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: x86 - Realmode BIOS and Code calling module
2004-08-12 13:38 Jakub Vana
2004-08-12 20:30 ` Alan Cox
@ 2004-08-13 7:44 ` Vojtech Pavlik
1 sibling, 0 replies; 13+ messages in thread
From: Vojtech Pavlik @ 2004-08-13 7:44 UTC (permalink / raw)
To: Jakub Vana; +Cc: alan, linux-kernel
On Thu, Aug 12, 2004 at 03:38:45PM +0200, Jakub Vana wrote:
> > Why is this better than LRMI in user mode.
>
> I was now looking on LRMI. It must be a nice code, but It is still
> only V86 emulation. I have listen that some BIOSes use something
> called Unreal mode, that is realmode with segment registers used like
> in protected mode. There is only one way, how to set this segregs -
> switch to prot. mode, but if the BIOS try to switch when is running in
> V86 CPU generates #GP (Global Protection fault). Not if it is running
> in real Real Mode.
Well, if it's running an emulated CPU (x86emu), there are no problems
with that. Even the unreal mode could be emulated, although I have yet
to see a BIOS which uses that to handle an INT call.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: x86 - Realmode BIOS and Code calling module
@ 2004-08-13 14:36 Jakub Vana
2004-08-13 21:54 ` Alan Cox
0 siblings, 1 reply; 13+ messages in thread
From: Jakub Vana @ 2004-08-13 14:36 UTC (permalink / raw)
To: vojtech, gugux; +Cc: alan, linux-kernel
______________________________________________________________
> Od: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Komu: Jakub Vana <gugux@centrum.cz>
> CC: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Datum: Thu, 12 Aug 2004 21:30:54 +0100
> Předmět: Re: x86 - Realmode BIOS and Code calling module
>
> On Iau, 2004-08-12 at 14:38, Jakub Vana wrote:
> > > Why is this better than LRMI in user mode.
> >
> > I was now looking on LRMI. It must be a nice code, but It is still only
> > V86 emulation. I have listen that some BIOSes use something called
> > Unreal mode, that is realmode with segment registers used like in
> > protected mode. There is only one way, how to set this segregs -
> > switch to prot. mode, but if the BIOS try to switch when is running
> > in V86 CPU generates #GP (Global Protection fault). Not if it is
> > running in real Real Mode.
>
> I've yet to meet a video bios that does this. I don't think the X folks
> have either, but you could run it past Egbert to make sure. The
> "unreal" mode is normally only in existance during early boot.
I got knowledge (or how is it well English?) that for video is it unusable, but I thing there are many other problems which can be solved by this module. Maybe it is not neaded for common hardware but there can be special hardware for special usage with drivers in it's BIOSes and there can by problems to write Linux Kernel driver for low documentation or a little money. It doesn't pay off to write all the driver for one or sixteen pieces of HW.
It is better to be it module in kernel so the driver(that uses BIOS) can be in kernel too and can provide standard services.
> > > To do BIOS calls safely
> > > you need to be very careful about things like PCI locking, I/O
> > > emulation and the ROM scribbling
> >
> > I'm not sure abou this, but I think there is not problem in calling
> > BIOS, here is problem in BIOS handling with this features and so
> > It's the problem of programmer that calls the BIOS to safely work
> > and synchronize his hardware in kernel with BIOS. Other hardware
> > (that is not pawn by BIOS) can't make problems.
>
> One example is PCI configuration accesses which must be co-ordinated
> with the kernel, and through the kernel PCI interfaces.
>
But when running in LRMI there are same problems, aren't ?
______________________________________________________________
> Od: Vojtech Pavlik <vojtech@suse.cz>
> Komu: Jakub Vana <gugux@centrum.cz>
> CC: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org
> Datum: Fri, 13 Aug 2004 09:44:57 +0200
> Předmět: Re: x86 - Realmode BIOS and Code calling module
>
> On Thu, Aug 12, 2004 at 03:38:45PM +0200, Jakub Vana wrote:
>
> > > Why is this better than LRMI in user mode.
> >
> > I was now looking on LRMI. It must be a nice code, but It is still
> > only V86 emulation. I have listen that some BIOSes use something
> > called Unreal mode, that is realmode with segment registers used like
> > in protected mode. There is only one way, how to set this segregs -
> > switch to prot. mode, but if the BIOS try to switch when is running in
> > V86 CPU generates #GP (Global Protection fault). Not if it is running
> > in real Real Mode.
>
> Well, if it's running an emulated CPU (x86emu), there are no problems
> with that. Even the unreal mode could be emulated, although I have yet
> to see a BIOS which uses that to handle an INT call.
When I tried to write my own kernel I hadn't time to write disk I/O so I temporarily used the DOS that I was writing it on. I used to call it as V86 task. It worked well on my one computer, but on other it failed by #GP. Because the DOS is all realmode (I used pure DOS - not smartdrv) It must be the BIOS that make the kernel failed. I'm almost sure it was because using protected mode(maybe like unreal mode), but It's not important what was the instruction. Important is that the instruction used to generate #GP. I know that this is not operation that can be module used for, but it shows that problem can be here.
> --
> Vojtech Pavlik
> SuSE Labs, SuSE CR
>
Jakub Vana
--------------------
Připravte se! Je tu škola. Navštivte včas Palác Flóra. Od 20.srpna do 5.září probíhá v Paláci Flóra speciální trh školních potřeb. http://user.centrum.cz/redir.php?url=http://www.palacflora.com
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: x86 - Realmode BIOS and Code calling module
@ 2004-08-14 20:10 Jakub Vana
0 siblings, 0 replies; 13+ messages in thread
From: Jakub Vana @ 2004-08-14 20:10 UTC (permalink / raw)
To: alan, gugux; +Cc: vojtech, linux-kernel
______________________________________________________________
> Od: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Komu: Jakub Vana <gugux@centrum.cz>
> CC: vojtech@suse.cz, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Datum: Fri, 13 Aug 2004 22:54:24 +0100
> Předmět: Re: x86 - Realmode BIOS and Code calling module
>
> On Gwe, 2004-08-13 at 15:36, Jakub Vana wrote:
> > But when running in LRMI there are same problems, aren't ?
>
> vm86 mode running in user space faults I/O port accesses if you wish so
> you can decode them and re-run them through the kernel PCI layer as for
> example Xorg does.
>
> Alan
I understand. I see that this code is not neaded for majority of Linux users so I will not annoy you. But I'll upload it somewhere on net in hope that there can be found some minority users that
will see it useful maybe for it's easy usage.
To Alan & Vojtech:
It was nice to meat you. And I hope to see your's mails again in future when I'll work on my next Kernel projects.
To Alan:
Let me congratulate to your saint's day if you celebrate it today like in my country.
Jakub
--------------------
Připravte se! Je tu škola. Navštivte včas Palác Flóra. Od 20.srpna do 5.září probíhá v Paláci Flóra speciální trh školních potřeb. http://user.centrum.cz/redir.php?url=http://www.palacflora.com
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2004-09-06 18:05 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-12 9:36 x86 - Realmode BIOS and Code calling module Jakub Vana
2004-08-12 11:56 ` Alan Cox
2004-09-06 15:27 ` Jozef Vesely
2004-09-06 17:03 ` Alan Cox
2004-08-12 12:39 ` Grzegorz Kulewski
2004-08-12 12:50 ` Vojtech Pavlik
2004-08-16 7:49 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2004-08-12 13:38 Jakub Vana
2004-08-12 20:30 ` Alan Cox
2004-08-13 7:44 ` Vojtech Pavlik
2004-08-13 14:36 Jakub Vana
2004-08-13 21:54 ` Alan Cox
2004-08-14 20:10 Jakub Vana
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox