Hello All,
I am writing this email to guage the interest in having code contributed
to the main stream Linux kernel that would support the user of a generic,
full featured VESA framebuffer driver that works on any CPU architecture
along with a generic Video card BOOT or POST mechanism.
We have been working on a project under contract to ATI that involves
porting a version of our SNAPBoot BIOS emulator solution to the PowerPC
Linux kernel. The SNAPBoot code supports initialising a graphics card
using an x86 BIOS image on any platform (currently tesed on x86, x86-64
and PowerPC). Initially SNAPBoot was developed to work across multiple
operating systems and CPU architectures from user space, but the desire
to use it to initialise the graphics card on embedded PowerPC kernels
prompted us to port a version of it for use within the Linux kernel. The
version we have ported for use in the kernel can be used to initialise
the graphics card for use with any accelerated framebuffer console
driver, such as the radeonfb driver which we are currently using it with.
Note that the SNAPBoot code uses the x86emu BIOS emulator project as the
core CPU emulation technology, and project we have been actively involved
with for many years since the licensing on the project was changed to
MIT/BSD style licensing and incorporated into the XFree86 project. We
have built code on top of x86emu to provide generic support for
initialising graphics cards on multiple platforms as well as supporting
initialisation of modern NonVGA graphics cards (like the ATI Radeon
family) without needing access to real VGA resources such as VGA I/O
ports and physical memory at 0xA0000-0xBFFFF.
More importantly we have used SNAPBoot to port our generic VESA SNAP
display driver to work on multiple operating systems and platforms,
including both x86-64 and PowerPC platforms. Using this driver you can
use any graphics card in the machine and it will support all the features
provided by the graphics cards VESA BIOS, including support for refresh
rate control on cards that support VBE 3.0 services. We have been
actively testing both the SNAPBoot capability and the BIOS emulator on
many platforms and graphics cards, and the latest version work flawlessly
on just about every graphics card we have tested.
What this means is that it should be possible to build a new version of
the VESA framebuffer console driver for the Linux kernel that will have
these important features:
1. Be able to switch display modes on the fly, supporting all modes
enumerated by the Video BIOS.
2. Be able to support refresh rate control on graphics cards that support
the VBE 3.0 services.
3. Be able to support 8-bit and 32-bit display modes on any graphics card
on big endian machines (16-bit is not possible unless software rendering
code is written to enable endian swapping in software, which may be
possible).
So what we would like to find out is how much interest there might be in
both an updated VESA framebuffer console driver as well as the code for
the Video card BOOT process being contributed to the maintstream kernel.
If there is interest, we would start out by first contributing the core
emulator and Video BOOT code, and then work on building a better VESA
framebuffer console driver.
So what do you guys think?
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! ~
From: Zachary Smith <hidden> Date: 2004-10-14 19:55:34
This is a problem of the videocard manufacturers' making which,
in the spirit of good engineering, they should fix before requiring
a downstream kludge.
Specifically, ATI, rather than advocate x86 emulation in order
to use their BIOS on non-x86 machines, should put a pseudocode BIOS
(something like java bytecode) in the ROM instead, including
an interpreter of course, perhaps gutting the x86 BIOS calls to use the
pseudocode routines so there is only one version to maintain.
And provide an entrypoint for non-x86 CPUs.
Zack
Kendall Bennett wrote:
Hello All,
I am writing this email to guage the interest in having code contributed
to the main stream Linux kernel that would support the user of a generic,
full featured VESA framebuffer driver that works on any CPU architecture
along with a generic Video card BOOT or POST mechanism.
We have been working on a project under contract to ATI that involves
porting a version of our SNAPBoot BIOS emulator solution to the PowerPC
Linux kernel. The SNAPBoot code supports initialising a graphics card
using an x86 BIOS image on any platform (currently tesed on x86, x86-64
and PowerPC). Initially SNAPBoot was developed to work across multiple
operating systems and CPU architectures from user space, but the desire
to use it to initialise the graphics card on embedded PowerPC kernels
prompted us to port a version of it for use within the Linux kernel. The
version we have ported for use in the kernel can be used to initialise
the graphics card for use with any accelerated framebuffer console
driver, such as the radeonfb driver which we are currently using it with.
Note that the SNAPBoot code uses the x86emu BIOS emulator project as the
core CPU emulation technology, and project we have been actively involved
with for many years since the licensing on the project was changed to
MIT/BSD style licensing and incorporated into the XFree86 project. We
have built code on top of x86emu to provide generic support for
initialising graphics cards on multiple platforms as well as supporting
initialisation of modern NonVGA graphics cards (like the ATI Radeon
family) without needing access to real VGA resources such as VGA I/O
ports and physical memory at 0xA0000-0xBFFFF.
More importantly we have used SNAPBoot to port our generic VESA SNAP
display driver to work on multiple operating systems and platforms,
including both x86-64 and PowerPC platforms. Using this driver you can
use any graphics card in the machine and it will support all the features
provided by the graphics cards VESA BIOS, including support for refresh
rate control on cards that support VBE 3.0 services. We have been
actively testing both the SNAPBoot capability and the BIOS emulator on
many platforms and graphics cards, and the latest version work flawlessly
on just about every graphics card we have tested.
What this means is that it should be possible to build a new version of
the VESA framebuffer console driver for the Linux kernel that will have
these important features:
1. Be able to switch display modes on the fly, supporting all modes
enumerated by the Video BIOS.
2. Be able to support refresh rate control on graphics cards that support
the VBE 3.0 services.
3. Be able to support 8-bit and 32-bit display modes on any graphics card
on big endian machines (16-bit is not possible unless software rendering
code is written to enable endian swapping in software, which may be
possible).
So what we would like to find out is how much interest there might be in
both an updated VESA framebuffer console driver as well as the code for
the Video card BOOT process being contributed to the maintstream kernel.
If there is interest, we would start out by first contributing the core
emulator and Video BOOT code, and then work on building a better VESA
framebuffer console driver.
So what do you guys think?
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! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Ian Romanick <hidden> Date: 2004-10-15 23:36:55
Zachary Smith wrote:
This is a problem of the videocard manufacturers' making which,
in the spirit of good engineering, they should fix before requiring
a downstream kludge.
Specifically, ATI, rather than advocate x86 emulation in order
to use their BIOS on non-x86 machines, should put a pseudocode BIOS
(something like java bytecode) in the ROM instead, including
an interpreter of course, perhaps gutting the x86 BIOS calls to use the
pseudocode routines so there is only one version to maintain.
And provide an entrypoint for non-x86 CPUs.
Isn't that basically what OpenFirmware is? I think part of the issue is
the x86 compiled BIOS is smaller than the OF BIOS, so they use smaller
(i.e., cheaper) flash on the card. That has prevented people from
re-flashing PC cards with OF images from Mac cards.
I think Digital had the right idea from the beginning: put the x86 BIOS
emulator in the system firmware and be done with it.
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Zachary Smith <hidden> Date: 2004-10-14 20:44:31
The problem of x86-only BIOSes is one of the videocard manufacturers'
own making which, in the spirit of good engineering, they should fix
before requiring a downstream kludge.
It's strange that they seem to want to sell these cards for use in
non-x86 machines yet they won't pay to have people write BIOSes
for PPC or other CPUs, or even provide a pseudocode solution.
Zack
Kendall Bennett wrote:
Hello All,
I am writing this email to guage the interest in having code contributed
to the main stream Linux kernel that would support the user of a generic,
full featured VESA framebuffer driver that works on any CPU architecture
along with a generic Video card BOOT or POST mechanism.
We have been working on a project under contract to ATI that involves
porting a version of our SNAPBoot BIOS emulator solution to the PowerPC
Linux kernel. The SNAPBoot code supports initialising a graphics card
using an x86 BIOS image on any platform (currently tesed on x86, x86-64
and PowerPC). Initially SNAPBoot was developed to work across multiple
operating systems and CPU architectures from user space, but the desire
to use it to initialise the graphics card on embedded PowerPC kernels
prompted us to port a version of it for use within the Linux kernel. The
version we have ported for use in the kernel can be used to initialise
the graphics card for use with any accelerated framebuffer console
driver, such as the radeonfb driver which we are currently using it with.
Note that the SNAPBoot code uses the x86emu BIOS emulator project as the
core CPU emulation technology, and project we have been actively involved
with for many years since the licensing on the project was changed to
MIT/BSD style licensing and incorporated into the XFree86 project. We
have built code on top of x86emu to provide generic support for
initialising graphics cards on multiple platforms as well as supporting
initialisation of modern NonVGA graphics cards (like the ATI Radeon
family) without needing access to real VGA resources such as VGA I/O
ports and physical memory at 0xA0000-0xBFFFF.
More importantly we have used SNAPBoot to port our generic VESA SNAP
display driver to work on multiple operating systems and platforms,
including both x86-64 and PowerPC platforms. Using this driver you can
use any graphics card in the machine and it will support all the features
provided by the graphics cards VESA BIOS, including support for refresh
rate control on cards that support VBE 3.0 services. We have been
actively testing both the SNAPBoot capability and the BIOS emulator on
many platforms and graphics cards, and the latest version work flawlessly
on just about every graphics card we have tested.
What this means is that it should be possible to build a new version of
the VESA framebuffer console driver for the Linux kernel that will have
these important features:
1. Be able to switch display modes on the fly, supporting all modes
enumerated by the Video BIOS.
2. Be able to support refresh rate control on graphics cards that support
the VBE 3.0 services.
3. Be able to support 8-bit and 32-bit display modes on any graphics card
on big endian machines (16-bit is not possible unless software rendering
code is written to enable endian swapping in software, which may be
possible).
So what we would like to find out is how much interest there might be in
both an updated VESA framebuffer console driver as well as the code for
the Video card BOOT process being contributed to the maintstream kernel.
If there is interest, we would start out by first contributing the core
emulator and Video BOOT code, and then work on building a better VESA
framebuffer console driver.
So what do you guys think?
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! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
The problem of x86-only BIOSes is one of the videocard
manufacturers' own making which, in the spirit of good engineering,
they should fix before requiring a downstream kludge.
It's strange that they seem to want to sell these cards for use in
non-x86 machines yet they won't pay to have people write BIOSes for
PPC or other CPUs, or even provide a pseudocode solution.
Interesting perspective. Given that you find this such a 'downstream
kludge', perhaps you would like to explain exactly what PPC BIOS
specification the manufacturers should be using instead?
Given that there isn't one, this is an option that works today. The only
other option is Open Firmware and manufacturers such as ATI *do* support
Open Firmware for Macintosh machines. The problem of course is that Open
Firmware is not exactly open, and there are no Linux implementations of
an Open Firmware exection environment that could be used. If there was,
this project would not exist.
Lastly perhaps it would be worth while thinking about this project a
little differently. Forgetting the fact that the BIOS image is x86, why
not think about the x86 BIOS image as being a set of 'generic'
instructions or p-code that can be excuted on any platform provided you
have the correct runtime interpreter. That is basically what the x86 BIOS
emulator solution does - it turns the x86 BIOS image into something that
can be interpreted on any platform.
Now if you think about it that way, perhaps you will realise that it
really isn't any different from Open Firmware! Any cross platform
'firmware' solution is developed such that the code in the firmware is
not processor specific but rather a 'p-code' that is interpreted on the
target processor platform.
So now if you ignore the fact that the 'firmware' runs natively in 16-bit
x86 environments, maybe this solution won't seem so dirty after all?
Regards,
Kendall Bennett wrote:
quoted
Hello All,
I am writing this email to guage the interest in having code contributed
to the main stream Linux kernel that would support the user of a generic,
full featured VESA framebuffer driver that works on any CPU architecture
along with a generic Video card BOOT or POST mechanism.
We have been working on a project under contract to ATI that involves
porting a version of our SNAPBoot BIOS emulator solution to the PowerPC
Linux kernel. The SNAPBoot code supports initialising a graphics card
using an x86 BIOS image on any platform (currently tesed on x86, x86-64
and PowerPC). Initially SNAPBoot was developed to work across multiple
operating systems and CPU architectures from user space, but the desire
to use it to initialise the graphics card on embedded PowerPC kernels
prompted us to port a version of it for use within the Linux kernel. The
version we have ported for use in the kernel can be used to initialise
the graphics card for use with any accelerated framebuffer console
driver, such as the radeonfb driver which we are currently using it with.
Note that the SNAPBoot code uses the x86emu BIOS emulator project as the
core CPU emulation technology, and project we have been actively involved
with for many years since the licensing on the project was changed to
MIT/BSD style licensing and incorporated into the XFree86 project. We
have built code on top of x86emu to provide generic support for
initialising graphics cards on multiple platforms as well as supporting
initialisation of modern NonVGA graphics cards (like the ATI Radeon
family) without needing access to real VGA resources such as VGA I/O
ports and physical memory at 0xA0000-0xBFFFF.
More importantly we have used SNAPBoot to port our generic VESA SNAP
display driver to work on multiple operating systems and platforms,
including both x86-64 and PowerPC platforms. Using this driver you can
use any graphics card in the machine and it will support all the features
provided by the graphics cards VESA BIOS, including support for refresh
rate control on cards that support VBE 3.0 services. We have been
actively testing both the SNAPBoot capability and the BIOS emulator on
many platforms and graphics cards, and the latest version work flawlessly
on just about every graphics card we have tested.
What this means is that it should be possible to build a new version of
the VESA framebuffer console driver for the Linux kernel that will have
these important features:
1. Be able to switch display modes on the fly, supporting all modes
enumerated by the Video BIOS.
2. Be able to support refresh rate control on graphics cards that support
the VBE 3.0 services.
3. Be able to support 8-bit and 32-bit display modes on any graphics card
on big endian machines (16-bit is not possible unless software rendering
code is written to enable endian swapping in software, which may be
possible).
So what we would like to find out is how much interest there might be in
both an updated VESA framebuffer console driver as well as the code for
the Video card BOOT process being contributed to the maintstream kernel.
If there is interest, we would start out by first contributing the core
emulator and Video BOOT code, and then work on building a better VESA
framebuffer console driver.
So what do you guys think?
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! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Zachary Smith <hidden> Date: 2004-10-15 18:51:32
Kendall Bennett wrote:
Zachary Smith [off-list ref] wrote:
quoted
The problem of x86-only BIOSes is one of the videocard
manufacturers' own making which, in the spirit of good engineering,
they should fix before requiring a downstream kludge.
> Forgetting the fact that the BIOS image is x86, why
> not think about the x86 BIOS image as being a set of 'generic'
> instructions or p-code
Yes, this idea occurred to me after I posted my response.
But if you're going to add x86 emulation to the non-x86 kernels
perhaps it would be nice if you could find a way to permit
users to run x86 applications as well seamlessly.
Although that would introduce a tradeoff: kernel code should be
small which is bound to be slow in the case of an emulator,
which is OK for running BIOS code, but a user running apps
probably prefer optimized code which may be bigger.
On the other hand, a person running a free emulator doesn't
really have the option of great speed :)
Cheers,
Zack
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
The problem of x86-only BIOSes is one of the videocard
manufacturers' own making which, in the spirit of good engineering,
they should fix before requiring a downstream kludge.
quoted
Forgetting the fact that the BIOS image is x86, why
not think about the x86 BIOS image as being a set of 'generic'
instructions or p-code
Yes, this idea occurred to me after I posted my response.
But if you're going to add x86 emulation to the non-x86 kernels
perhaps it would be nice if you could find a way to permit
users to run x86 applications as well seamlessly.
Ugh... There's a big difference between a 16-bit 8086 emulator to run BIOS code
and a full-fletched 32-bit 80386 (or higher) emulator...
Although that would introduce a tradeoff: kernel code should be
small which is bound to be slow in the case of an emulator,
which is OK for running BIOS code, but a user running apps
probably prefer optimized code which may be bigger.
We already have qemu.
On the other hand, a person running a free emulator doesn't
really have the option of great speed :)
Really? We already have qemu.
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
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
The problem of x86-only BIOSes is one of the videocard
manufacturers' own making which, in the spirit of good engineering,
they should fix before requiring a downstream kludge.
> Forgetting the fact that the BIOS image is x86, why
> not think about the x86 BIOS image as being a set of 'generic'
> instructions or p-code
Yes, this idea occurred to me after I posted my response.
But if you're going to add x86 emulation to the non-x86 kernels
perhaps it would be nice if you could find a way to permit users to
run x86 applications as well seamlessly.
Well there is a big difference between a simple CPU emulator and a full
fledged machine emulation environment. Although if you only plan to run
Linux user space programs that might be easier to handle because you just
need to handle the system calls. But you would still need x86 shared
libraries and such which at the end of the day doesn't make much sense
(too much bloat).
Also the emulator only emulates real mode code at present. It had full
support for 32-bit instructions and could probably be tweaked to run user
space 32-bit code, but it has never been tested.
Although that would introduce a tradeoff: kernel code should be
small which is bound to be slow in the case of an emulator, which
is OK for running BIOS code, but a user running apps probably
prefer optimized code which may be bigger.
Probably. Although we have been very surprised at just how well the
PowerPC compiled version of the emulator runs BIOS code. It seems the
PowerPC compilers can optimise the code a lot better than x86 compilers.
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! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Antonino A. Daplas <hidden> Date: 2004-10-15 00:30:33
On Friday 15 October 2004 03:02, Kendall Bennett wrote:
So what we would like to find out is how much interest there might be in
both an updated VESA framebuffer console driver as well as the code for
the Video card BOOT process being contributed to the maintstream kernel.
If there is interest, we would start out by first contributing the core
emulator and Video BOOT code, and then work on building a better VESA
framebuffer console driver.
So what do you guys think?
I'm for it, if you can get the code in the kernel. If not, what are the
arguments against doing this in userspace?
If you remember about 2 years ago, there was a thread which you started
about vesafbd. From that, I've worked on vm86d which is a generic approach
to running BIOS code in user space. I stopped development on this though,
but it should be easy to revive. There is also vesafb-tng. I think it runs
BIOS code in kernel space.
The video BOOT code is also nice, especially for non-primary graphics cards.
Tony
On Friday 15 October 2004 03:02, Kendall Bennett wrote:
quoted
So what we would like to find out is how much interest there might be in
both an updated VESA framebuffer console driver as well as the code for
the Video card BOOT process being contributed to the maintstream kernel.
If there is interest, we would start out by first contributing the core
emulator and Video BOOT code, and then work on building a better VESA
framebuffer console driver.
So what do you guys think?
I'm for it, if you can get the code in the kernel. If not, what
are the arguments against doing this in userspace?
At least for the 2.4 kernels it is not possible to run code from user
space early enough in the boot sequence to bring up the video card when
the framebuffer console driver starts. Alan Cox said there is work under
way for 2.6 that might allow this, but it would have to be done very
early in the boot sequence.
Remember this project is for non-x86 platforms such as PowerPC and MIPS
embedded machines where there is no way to set a graphics mode using the
BIOS before the kernel starts loading (well, you can do something using U-
Boot but a lot of projects don't always use U-Boot).
If you remember about 2 years ago, there was a thread which you
started about vesafbd. From that, I've worked on vm86d which is a
generic approach to running BIOS code in user space. I stopped
development on this though, but it should be easy to revive.
Yes, I am aware of this project. It is a great project for x86 platforms,
but falls short for non-x86 due to the inability to set a basic display
mode prior to user space access becoming available.
There is also vesafb-tng. I think it runs BIOS code in kernel
space.
I am not familiar with that. Can you point me to a URL?
The video BOOT code is also nice, especially for non-primary
graphics cards.
Yep.
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! ~
From: Antonino A. Daplas <hidden> Date: 2004-10-15 21:53:49
On Saturday 16 October 2004 02:36, Kendall Bennett wrote:
"Antonino A. Daplas" [off-list ref] wrote:
quoted
quoted
So what do you guys think?
I'm for it, if you can get the code in the kernel. If not, what
are the arguments against doing this in userspace?
At least for the 2.4 kernels it is not possible to run code from user
space early enough in the boot sequence to bring up the video card when
the framebuffer console driver starts. Alan Cox said there is work under
way for 2.6 that might allow this, but it would have to be done very
early in the boot sequence.
For 2.6, the framebuffer console can activate as early or as late as one
wants because fbcon will wait until a framebuffer driver becomes active. In
contrast, in 2.4, at least one fb driver needs to be active for the
framebuffer console to become active.
Remember this project is for non-x86 platforms such as PowerPC and MIPS
embedded machines where there is no way to set a graphics mode using the
BIOS before the kernel starts loading (well, you can do something using U-
Boot but a lot of projects don't always use U-Boot).
quoted
If you remember about 2 years ago, there was a thread which you
started about vesafbd. From that, I've worked on vm86d which is a
generic approach to running BIOS code in user space. I stopped
development on this though, but it should be easy to revive.
Yes, I am aware of this project. It is a great project for x86 platforms,
but falls short for non-x86 due to the inability to set a basic display
mode prior to user space access becoming available.
Yes, that is the downside to a userspace solution. How bad will that be?
Note that Jon Smirl is proposing a temporary console driver for early
boot messages until the primary console driver activates.
quoted
There is also vesafb-tng. I think it runs BIOS code in kernel
space.
I am not familiar with that. Can you point me to a URL?
From: Jon Smirl <hidden> Date: 2004-10-15 23:20:06
On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
[off-list ref] wrote:
Yes, that is the downside to a userspace solution. How bad will that be?
Note that Jon Smirl is proposing a temporary console driver for early
boot messages until the primary console driver activates.
Does anyone know exactly how big the window is from when a compiled in
console activates until one that relies on initramfs loads? I don't
think it is very big given that a lot of the early printk's are queued
before they are displayed.
Other than embedded systems, are there machines that have no BIOS/PROM
display at all and rely entirely on a bootable kernel for display? If
so, how do machines like this put up a message that they can't find
the kernel? How do you get hardware diagnostic messages from them?
In the case of something like a Mac you would want to keep the display
blank until the early user space code initializes the display in
graphics mode. Only if you get a fatal error before this would you
dump the info using the Open Firmware display. Same strategy would
apply to x86.
--
Jon Smirl
jonsmirl@gmail.com
On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
Yes, that is the downside to a userspace solution. How bad will that be?
Note that Jon Smirl is proposing a temporary console driver for early
boot messages until the primary console driver activates.
Does anyone know exactly how big the window is from when a
compiled in console activates until one that relies on initramfs
loads? I don't think it is very big given that a lot of the early
printk's are queued before they are displayed.
I have not used initramfs at all (I am not sure I know what it is
actually) so I don't know. I know there is quite a long period of time on
most machines from when the kernel starts booting and when the real file
system based init process takes over.
Other than embedded systems, are there machines that have no
BIOS/PROM display at all and rely entirely on a bootable kernel
for display? If so, how do machines like this put up a message that
they can't find the kernel? How do you get hardware diagnostic
messages from them?
I am pretty sure most embedded systems use some kind of boot firmware to
bring up the box. Something like Open BIOS from IBM or U-Boot. U-Boot can
be set up to POST the card using the BIOS emulator but Open BIOS cannot.
If you don't POST the card in the boot loader, usually they display
diagnostics on the serial port until the console comes up (ie: I see the
'uncompress linux...' message on the serial port and then the framebuffer
console comes up and the messages switch over to it.
In the case of something like a Mac you would want to keep the
display blank until the early user space code initializes the
display in graphics mode. Only if you get a fatal error before this
would you dump the info using the Open Firmware display. Same
strategy would apply to x86.
True. On the Mac they use the speakers so the user knows that the machine
is booting. Almost immediately after hitting the power you will hear a
calming sound coming from the speaker, and it might be another 5 seconds
or so before the actual video comes up.
If they didn't do that they would no doubt have lots of users turning the
machine off again before it had a chance to bring up the video!
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! ~
From: Jon Smirl <hidden> Date: 2004-10-15 23:58:11
On Fri, 15 Oct 2004 16:51:09 -0700, Kendall Bennett
[off-list ref] wrote:
I have not used initramfs at all (I am not sure I know what it is
actually) so I don't know. I know there is quite a long period of time on
most machines from when the kernel starts booting and when the real file
system based init process takes over.
initramfs/initrd comes up very early in the boot process. For example
it holds your supplemental device drivers and initial /dev.
/dev/console is opened from this /dev so it much be up before the
console is. This is much earlier than normal user space starts.
I believe the current Fedora 3 uses udev from initramfs, but I haven't
tried it yet.
--
Jon Smirl
jonsmirl@gmail.com
From: Pavel Machek <hidden> Date: 2004-10-19 21:21:02
Hi!
quoted
In the case of something like a Mac you would want to keep the
display blank until the early user space code initializes the
display in graphics mode. Only if you get a fatal error before this
would you dump the info using the Open Firmware display. Same
strategy would apply to x86.
True. On the Mac they use the speakers so the user knows that the machine
is booting. Almost immediately after hitting the power you will hear a
calming sound coming from the speaker, and it might be another 5 seconds
or so before the actual video comes up.
Heh, I'm trying to do the some in i386 resume case... If you can call
square waves at 600Hz "calming sound" :-). Having video early would
certainly be more welcome.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
From: Antonino A. Daplas <hidden> Date: 2004-10-16 01:50:33
On Saturday 16 October 2004 07:20, Jon Smirl wrote:
On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
Yes, that is the downside to a userspace solution. How bad will that be?
Note that Jon Smirl is proposing a temporary console driver for early
boot messages until the primary console driver activates.
Does anyone know exactly how big the window is from when a compiled in
console activates until one that relies on initramfs loads? I don't
think it is very big given that a lot of the early printk's are queued
before they are displayed.
There's a log of initialization that goes on between console_init() and
populate_rootfs(). However, console_init() will only initialize built-in
consoles (as pointed to by conswitchp) such as vgacon or dummycon.
However, the framebuffer system initialization does happen after
populate_rootfs().
So, at least in the framebuffer perspective, the emulator/video boot may be
loaded as part of initramfs.
Tony
From: Jon Smirl <hidden> Date: 2004-10-16 02:03:16
On Sat, 16 Oct 2004 09:50:32 +0800, Antonino A. Daplas
[off-list ref] wrote:
On Saturday 16 October 2004 07:20, Jon Smirl wrote:
quoted
On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
[off-list ref] wrote:
quoted
Yes, that is the downside to a userspace solution. How bad will that be?
Note that Jon Smirl is proposing a temporary console driver for early
boot messages until the primary console driver activates.
Does anyone know exactly how big the window is from when a compiled in
console activates until one that relies on initramfs loads? I don't
think it is very big given that a lot of the early printk's are queued
before they are displayed.
There's a log of initialization that goes on between console_init() and
populate_rootfs(). However, console_init() will only initialize built-in
consoles (as pointed to by conswitchp) such as vgacon or dummycon.
However, the framebuffer system initialization does happen after
populate_rootfs().
We already have vgacon, promcon, sticon, mgacon, newportcon. What
platforms (other than embedded) are not covered by these?
The idea is to use one of these as a temporary console and not print
anything on it except KERN_ERR level messages. Of course if you are a
kernel developer you can change this. A working system would non have
KERN_ERR messages during this phase and the screen would remain blank.
Messages at levels other than KERN_ERR would be queued until
populate_rootfs()/early user space time where they would then get
displayed on the fbcon. fbcon will be a full console with mode setting
capability and other fancy features. It would immediately go into
graphics mode.
--
Jon Smirl
jonsmirl@gmail.com
There's a log of initialization that goes on between console_init() and
populate_rootfs(). However, console_init() will only initialize built-in
consoles (as pointed to by conswitchp) such as vgacon or dummycon.
However, the framebuffer system initialization does happen after
populate_rootfs().
We already have vgacon, promcon, sticon, mgacon, newportcon. What
platforms (other than embedded) are not covered by these?
Many embedded platforms do not map VGA resources in, so it is not
possible to get VGACon to work on those machines unless the kernel/boot
loader is modified to properly map VGA resources (which should be
possible).
Then there are Macintosh machines that also do not map VGA resources. I
am not sure if it is possible to map them on Macintosh machines or not.
I would assume however a serial port console would be fine for embedded
machines until the framebuffer driver could come up anyway.
The idea is to use one of these as a temporary console and not
print anything on it except KERN_ERR level messages. Of course if
you are a kernel developer you can change this. A working system
would non have KERN_ERR messages during this phase and the screen
would remain blank.
Messages at levels other than KERN_ERR would be queued until
populate_rootfs()/early user space time where they would then get
displayed on the fbcon. fbcon will be a full console with mode
setting capability and other fancy features. It would immediately
go into graphics mode.
As long as this process happens quickly and the machine boots into
graphics mode within 1-2 seconds from poweron, that would probably be OK.
If it starts taking too long for the system to get into graphics mode to
display something the user can easily think something is wrong and the
machine is not working.
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! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Richard Smith <hidden> Date: 2004-10-18 20:40:21
Kendall Bennett wrote:
I would assume however a serial port console would be fine for embedded
machines until the framebuffer driver could come up anyway.
This would be an incorrect assumption. Speaking as a developer of one
said embedded system I must have video at boot and be able to dump
critical kernel messages to the screen.
In the field, hooking up a serial cable to see why the unit doesn't boot
requires the dispatch of a tech who would have open up the unit to get
to the serial port. This costs the end client lots of $$. They don't
like that.
By having video on boot the support person can tell the end user to look
at the screen and read back any messages and then make the determination
if a tech dispatch is needed.
And its common practice to only have as many serial ports as the system
needs during runtime. During development you can dual purpose them but
in the final system their may not be a serial port free (or even
installed) to get that console info from.
--
Richard A. Smith
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
I would assume however a serial port console would be fine for embedded
machines until the framebuffer driver could come up anyway.
This would be an incorrect assumption. Speaking as a developer of
one said embedded system I must have video at boot and be able to
dump critical kernel messages to the screen.
In the field, hooking up a serial cable to see why the unit
doesn't boot requires the dispatch of a tech who would have open
up the unit to get to the serial port. This costs the end client
lots of $$. They don't like that.
By having video on boot the support person can tell the end user
to look at the screen and read back any messages and then make the
determination if a tech dispatch is needed.
And its common practice to only have as many serial ports as the
system needs during runtime. During development you can dual
purpose them but in the final system their may not be a serial
port free (or even installed) to get that console info from.
Good, so my assumption was incorrect which I am happy about. Since it
makes the work we did more useful ;-)
Anyway in your case do you need diagnostic messages just from the kernel
or from the firmware as well? To get it in the firmware the video boot
code would need to be ported there (U-Boot has a version of it already,
but it is the only firmware I am aware of that supports this).
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! ~
From: Richard Smith <hidden> Date: 2004-10-18 21:07:18
Kendall Bennett wrote:
Richard Smith [off-list ref] wrote:
Good, so my assumption was incorrect which I am happy about. Since it
makes the work we did more useful ;-)
Anyway in your case do you need diagnostic messages just from the kernel
or from the firmware as well?
Firmware messages are the most critical since none of the app code is
running yet and can't self-heal or cry for help.
Some units boot off of a compact flash. Try as we might to make these
babies robust they do fail. So in that case the boot message from the
firmware needs to be displayed. In other cases the system net boots
which increases the firmware error message level by about a factor of 10.
> To get it in the firmware the video boot
> code would need to be ported there (U-Boot has a version of it already,
> but it is the only firmware I am aware of that supports this).
LinuxBIOS has some suport for this. Not by emulation though. It uses
the bios from the BOCHS project as a payload. Some glue drops the
system back into real mode and runs the BOCHS bios which scans the
legacy regions for ROM expansion modules. So as long as I copy my video
bios up int 0x0C0000 prior to this I get video. Otherwise I have to
wait until X comes up and soft-boots the display device.
--
Richard A. Smith
From: Jon Smirl <hidden> Date: 2004-10-18 21:19:28
On Mon, 18 Oct 2004 15:34:58 -0500, Richard Smith [off-list ref] wrote:
Kendall Bennett wrote:
quoted
I would assume however a serial port console would be fine for embedded
machines until the framebuffer driver could come up anyway.
This would be an incorrect assumption. Speaking as a developer of one
said embedded system I must have video at boot and be able to dump
critical kernel messages to the screen.
I don't see it as the kernel's responsibility to compensate for lack
of something in an embedded system's BIOS. Embedded programmers are
free to go in and add basic display code to their arch specific
directories for printing out this class of messages. Better yet would
be to fix the embedded ROM to support basic display.
What I don't want to do is get a graphics driver system capable of
supporting multi-head console and openGL running before the kernel
initializes. I'm also trying to move big chunks of the display system
(vm86 reset and EDID) out of the kernel and into user space in order
to reduce the size of the graphic drivers. Moving this code means that
the full display system can not initialize until at least early user
space is running.
Every system has to be able to somehow indicate that it can find/load the
kernel image or that the image is corrupt or that hardware diagnostics failed.
Displaying this info is the responsibility of the BIOS.
--
Jon Smirl
jonsmirl@gmail.com
From: Richard Smith <hidden> Date: 2004-10-18 22:34:53
Jon Smirl wrote:
Every system has to be able to somehow indicate that it can find/load the
kernel image or that the image is corrupt or that hardware diagnostics failed.
Displaying this info is the responsibility of the BIOS.
Jon, I agree with you 100%. I was merely responding to a statement I
saw as false.
If we could get the video chip manufacturers to provide me with all the
necessary documentation we embedded folk would be happy to do exactly as
you say. We could code up a nice robust boot time init procedure to
serve our purposes. OF would be great if all the mfgs would support it.
Its a sad fact though that we are (x86 anyway) dependant on some
amazingly fragile, stupid, usually binary only, legacy bloated, and
quite often buggy, 16-bit realmode video init code that should have been
put to pasture many years ago.
LinuxBIOS has been trying to come up with a solution to the video BOOT
problems for good while now. Emulation seems to be the only thing that
really has a chance of working.
I don't currently (see next paragraph) need the kernel to try and do all
that stuff for me since I need it prior to when the kernel loads. But
what I would like is to be able to use/build on kernel framework without
having to completely re-invent the wheel.
A long term goal of LinuxBIOS however is to use Linux _AS_ the bios
which kind of nullifies your BIOS responsibility statement. Some of the
LANL clusters are doing this right now. The only reason we aren't doing
it 100% of the time is that a lot of motherboards don't have a big
enough flash. Yet. But with projects like linux-tiny and larger flashes
headed our way those days are numbered.
Linux far exceeds the hardware support level and flexablity of any bios
and already does 90% of the job a bios does anyway. In most cases better
than the bios ever could. Linux booting Linux is the ultimate
bios/bootloader.
--
Richard A. Smith
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Jon Smirl <hidden> Date: 2004-10-18 23:28:50
On Mon, 18 Oct 2004 17:34:45 -0500, Richard Smith [off-list ref] wrote:
A long term goal of LinuxBIOS however is to use Linux _AS_ the bios
which kind of nullifies your BIOS responsibility statement. Some of the
LANL clusters are doing this right now. The only reason we aren't doing
it 100% of the time is that a lot of motherboards don't have a big
enough flash. Yet. But with projects like linux-tiny and larger flashes
headed our way those days are numbered.
Linux far exceeds the hardware support level and flexablity of any bios
and already does 90% of the job a bios does anyway. In most cases better
than the bios ever could. Linux booting Linux is the ultimate
bios/bootloader.
LinuxBIOS can do things the real kernel probably shouldn't be doing.
For example on an x86 it can find the expansion ROMs and post all of
the video cards. On non-x86 it can embed emu86 and run the ROMs that
way. And for a few cards that we have the docs on it can directly
initialize them. These options should be selected when LinuxBIOS is
built for the hardware.
But getting Int10 video up and running does not mean that the kernel
framebuffer/DRM subsystem has to be up and running. Int10 or Open
Firmware text output should be used for these critical messages before
the kernel video system is loaded. As far as I know every video card
has some sort of ROM on it to support BIOS level display. If someone
is going to embed a graphics chip without a ROM and run LinuxBIOS on
it, then it is the hardware manufacturer responsibility to acquire
enough documentation from the graphics vendor so that a boot display
can be implemented.
To achieve pure graphical boot, don't print out anything except
KERN_ERR level messages to the Int10 display. Queue all non-KERN_ERR
until the framebuffer loads and then dump them if you want.
--
Jon Smirl
jonsmirl@gmail.com
From: Richard Smith <hidden> Date: 2004-10-19 00:18:22
Jon Smirl wrote:
LinuxBIOS can do things the real kernel probably shouldn't be doing.
For example on an x86 it can find the expansion ROMs and post all of
> the video cards. On non-x86 it can embed emu86 and run the ROMs that
> way. And for a few cards that we have the docs on it can directly
> initialize them. These options should be selected when LinuxBIOS is
> built for the hardware.
Well we see it the other way around. We want to do a little as possible
and let Linux handle as much as possible. Otherwise your bios turns
into a mini-OS. The path is littered with dead projects that went that
route. Keeping current with driver support kills them.
But getting Int10 video up and running does not mean that the kernel
framebuffer/DRM subsystem has to be up and running. Int10 or Open
Agreed.
it, then it is the hardware manufacturer responsibility to acquire
enough documentation from the graphics vendor so that a boot display
can be implemented.
If only it were that easy. *grin*
Ok well I really don't want to start a off-topic argument here so I'll
shut up after this. Especially since I'm not really argueing anything
that hasn't already be thrashed over many times.
I and many others would like to see a unified int10 solution that could
be used by as many projects that need it rather than the fragmented
setup we have now. The kernel proper may or may not be one of those.
--
Richard A. Smith
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
Every system has to be able to somehow indicate that it can find/load the
kernel image or that the image is corrupt or that hardware diagnostics failed.
Displaying this info is the responsibility of the BIOS.
Jon, I agree with you 100%. I was merely responding to a
statement I saw as false.
If we could get the video chip manufacturers to provide me with
all the necessary documentation we embedded folk would be happy to
do exactly as you say. We could code up a nice robust boot time
init procedure to serve our purposes. OF would be great if all
the mfgs would support it.
Well being able to use this BIOS emulator logic to bring up the primary
video card in the firmware should solve this problem, right? Just ignore
the fact that the BIOS image we are using happens to be x86 code, and
think about is as a set of instructions that we execute using an
interpreter (ie: the same as Open Firmware really).
Its a sad fact though that we are (x86 anyway) dependant on some
amazingly fragile, stupid, usually binary only, legacy bloated, and
quite often buggy, 16-bit realmode video init code that should have
been put to pasture many years ago.
Actually there is nothing wrong with the x86 BIOS from the perspective of
functionality and useability (or bloat for that matter). It contains all
the functionality we need and armed with something like the x86 emulator
we can use it for what we need on any platform.
Open Firmware may be a 'nicer' solution, but I guarantee that if the
vendors started supporting that it would be just a bug ridden as any 16-
bit real mode BIOS code. For the Video BIOS the code always works for
what it is tested for. Some vendors spend more time testing the VBE BIOS
side of things fully (if they are smart they have licensed our VBETest
tools for this purpose). Unfortunatley some vendors do not test this
stuff thoroughly and it has problems. But the same testing issues would
exist whether the firmware was written as a 16-bit x86 blob or as an Open
Firmware blob.
LinuxBIOS has been trying to come up with a solution to the video
BOOT problems for good while now. Emulation seems to be the only
thing that really has a chance of working.
IMHO that is the best solution to the problem because it will be using
code that has been heavily tested by the vendor. The one thing x86 Video
BIOS'es can do reliably is POST the graphics card ;-)
I don't currently (see next paragraph) need the kernel to try and
do all that stuff for me since I need it prior to when the kernel
loads. But what I would like is to be able to use/build on kernel
framework without having to completely re-invent the wheel.
Assuming you put the video init code into the firmware, then yes, the
kernel does not need it. However part of the project to put this into the
kernel involves building a better VESA framebuffer console driver, and to
do that we either need vm86() services from kernel land (frowned upon by
the kernel community and inherently x86 centric) or support for x86
emulation.
If you want to try and build a better standard than the x86 VESA VBE
BIOS, be my guest. I lobbied for years on the VESA Software Standards
Committee to build the next generation firmware that would be cross
platform, but nobody was interested. In fact the SSC eventually closed
due to lack of interest so we took all our technology and turned it into
SciTech SNAP.
I see Intel is trying to do something similar with EFI, but when will
that actually be here?
So for now we have the x86 BIOS and it works today. We should use it.
Linux far exceeds the hardware support level and flexablity of any
bios and already does 90% of the job a bios does anyway. In most
cases better than the bios ever could. Linux booting Linux is the
ultimate bios/bootloader.
That would be nice if you could trim it down ;-) Would certainly save a
lot of code bloat. But if you do that, then you would need this code in
the kernel since now it would be the boot loader as well ;-)
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! ~
From: Richard Smith <hidden> Date: 2004-10-19 01:39:36
Kendall Bennett wrote:
Actually there is nothing wrong with the x86 BIOS from the perspective of
functionality and useability (or bloat for that matter). It contains all
the functionality we need and armed with something like the x86 emulator
we can use it for what we need on any platform.
IMHO that is the best solution to the problem because it will be using
code that has been heavily tested by the vendor. The one thing x86 Video
BIOS'es can do reliably is POST the graphics card ;-)
I'm just going to take your word on this since you have messed with far
more video bioses than I. I've just got a few too many scars over the
years from trying to make the whole BIOS sub-system robust enough for
embedded standards.
That would be nice if you could trim it down ;-) Would certainly save a
lot of code bloat. But if you do that, then you would need this code in
the kernel since now it would be the boot loader as well ;-)
Exactly. Which is why I like your project and I think its a good thing.
The only reason I have to carry around the legacy BIOS baggage is
for video.
How big is your in-kernel implementation?
--
Richard A. Smith
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
Actually there is nothing wrong with the x86 BIOS from the perspective of
functionality and useability (or bloat for that matter). It contains all
the functionality we need and armed with something like the x86 emulator
we can use it for what we need on any platform.
quoted
IMHO that is the best solution to the problem because it will be using
code that has been heavily tested by the vendor. The one thing x86 Video
BIOS'es can do reliably is POST the graphics card ;-)
I'm just going to take your word on this since you have messed
with far more video bioses than I. I've just got a few too many
scars over the years from trying to make the whole BIOS sub-system
robust enough for embedded standards.
Most BIOS'es are relatively good, but there are some terrible ones. We
have one a lot of work over the years making our VESA VBE drivers work
well with all the BIOS'es out there, working around the issues in the
broken ones. I plan to use that same module for the kernel VESA driver
when I get around to re-writing it.
quoted
lot of code bloat. But if you do that, then you would need this code in
the kernel since now it would be the boot loader as well ;-)
Exactly. Which is why I like your project and I think its a good
thing. The only reason I have to carry around the legacy BIOS
baggage is for video.
Yep.
How big is your in-kernel implementation?
Right now the compiled x86 code is about 100K in size. PowerPC code
appears to be about twice that size and x86-64 is about 130K I think. I
have no idea how big an Open Firmware interpreter would be for comparison
purposes because I have never seen an Open Source implementation of one.
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! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Pavel Machek <hidden> Date: 2004-10-19 22:18:57
Hi!
quoted
Its a sad fact though that we are (x86 anyway) dependant on some
amazingly fragile, stupid, usually binary only, legacy bloated, and
quite often buggy, 16-bit realmode video init code that should have
been put to pasture many years ago.
Actually there is nothing wrong with the x86 BIOS from the perspective of
functionality and useability (or bloat for that matter). It contains all
the functionality we need and armed with something like the x86 emulator
we can use it for what we need on any platform.
Open Firmware may be a 'nicer' solution, but I guarantee that if the
vendors started supporting that it would be just a bug ridden as any 16-
bit real mode BIOS code. For the Video BIOS the code always works for
what it is tested for. Some vendors spend more time testing the VBE BIOS
side of things fully (if they are smart they have licensed our VBETest
tools for this purpose). Unfortunatley some vendors do not test this
stuff thoroughly and it has problems. But the same testing issues would
exist whether the firmware was written as a 16-bit x86 blob or as an Open
Firmware blob.
Actually that 16-bit x86 blob can access any PC hardware, and that's
where the stuff gets hard.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Open Firmware may be a 'nicer' solution, but I guarantee that if the
vendors started supporting that it would be just a bug ridden as any 16-
bit real mode BIOS code. For the Video BIOS the code always works for
what it is tested for. Some vendors spend more time testing the VBE BIOS
side of things fully (if they are smart they have licensed our VBETest
tools for this purpose). Unfortunatley some vendors do not test this
stuff thoroughly and it has problems. But the same testing issues would
exist whether the firmware was written as a 16-bit x86 blob or as an Open
Firmware blob.
Actually that 16-bit x86 blob can access any PC hardware, and that's
where the stuff gets hard.
Yes, but there is only a very small set of PC hardware features you need
to implement, and most BIOS'es only look at those things for timing
purposes. Unfortunately there is no standard for how BIOS'es do internal
timing and delay loops, so we emulate them all (8253 timers, speaker
ports and CMOS time/date support ;-).
When we come across a new card that doesn't work we figure out why and
make new additions to the video boot code. However at this point we think
we have covered just about every card out there, as I don't think there
are any cards in our labs that don't work at present. If there are,
fixing them is just a matter of spending the time to debug it.
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! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Pavel Machek <hidden> Date: 2004-10-20 19:13:18
Hi!
quoted
quoted
Open Firmware may be a 'nicer' solution, but I guarantee that if the
vendors started supporting that it would be just a bug ridden as any 16-
bit real mode BIOS code. For the Video BIOS the code always works for
what it is tested for. Some vendors spend more time testing the VBE BIOS
side of things fully (if they are smart they have licensed our VBETest
tools for this purpose). Unfortunatley some vendors do not test this
stuff thoroughly and it has problems. But the same testing issues would
exist whether the firmware was written as a 16-bit x86 blob or as an Open
Firmware blob.
Actually that 16-bit x86 blob can access any PC hardware, and that's
where the stuff gets hard.
Yes, but there is only a very small set of PC hardware features you need
to implement, and most BIOS'es only look at those things for timing
purposes. Unfortunately there is no standard for how BIOS'es do internal
timing and delay loops, so we emulate them all (8253 timers, speaker
ports and CMOS time/date support ;-).
Hmm, that does not seem that bad. Did you need to emulate interrupt
controller, too? That one seemed most scary to me.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Yes, but there is only a very small set of PC hardware features you need
to implement, and most BIOS'es only look at those things for timing
purposes. Unfortunately there is no standard for how BIOS'es do internal
timing and delay loops, so we emulate them all (8253 timers, speaker
ports and CMOS time/date support ;-).
Hmm, that does not seem that bad. Did you need to emulate interrupt
controller, too? That one seemed most scary to me.
No. Only software interrupts. The BIOS never deals with hardware
interrupts since there is no standard, reliable way to hook them from
real mode so it never uses them ;-)
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! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Pavel Machek <hidden> Date: 2004-10-19 21:51:45
Hi!
quoted
quoted
I would assume however a serial port console would be fine for embedded
machines until the framebuffer driver could come up anyway.
This would be an incorrect assumption. Speaking as a developer of one
said embedded system I must have video at boot and be able to dump
critical kernel messages to the screen.
I don't see it as the kernel's responsibility to compensate for lack
of something in an embedded system's BIOS. Embedded programmers are
free to go in and add basic display code to their arch specific
directories for printing out this class of messages. Better yet would
be to fix the embedded ROM to support basic display.
Unfortunately, this is not only problem of embedded bootup but also of
resume (from suspend-to-RAM) on plain i386 notebook near you...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Note that the SNAPBoot code uses the x86emu BIOS emulator project as the
core CPU emulation technology, and project we have been actively involved
with for many years since the licensing on the project was changed to
MIT/BSD style licensing and incorporated into the XFree86 project.
So what we would like to find out is how much interest there might be in
both an updated VESA framebuffer console driver as well as the code for
the Video card BOOT process being contributed to the maintstream kernel.
It certainly would be nice to have that. Not nessesarely in the
kernel through, people tend not to like such complex stuff like cpu
emulation in the kernel for good reasons. The kernel can run
userspace apps (modprobe, hotplug), that mechanism could be used to
invoke a userspace tool which does the boot / mode switching. Having
it in userspace likely also makes it easier to share code with X11.
Have you talked to the powermanagement guys btw.? One of the major
issues with suspend-to-ram is to get the graphics card back online,
and SNAPBoot might help to fix this too. I'm not sure a userspace
solution would work for *that* through.
Gerd
--
return -ENOSIG;
Have you talked to the powermanagement guys btw.? One of the major
issues with suspend-to-ram is to get the graphics card back online,
and SNAPBoot might help to fix this too. I'm not sure a userspace
solution would work for *that* through.
Why not? Of course you won't get any output before the graphics card has been
re-initialized to a sane and usable state...
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
Have you talked to the powermanagement guys btw.? One of the major
issues with suspend-to-ram is to get the graphics card back online,
and SNAPBoot might help to fix this too. I'm not sure a userspace
solution would work for *that* through.
Why not? Of course you won't get any output before the graphics card has been
re-initialized to a sane and usable state...
You have a application running which uses the framebuffer device, then
suspend with that app running. You'll have to restore the state of
the device _before_ restarting all the userspace proccesses, otherwise
the app will not be very happy. I'm not sure if the kernel can run a
userspace helper in that situation (i.e. before waking all the
processes).
Gerd
--
return -ENOSIG;
From: Martin Waitz <hidden> Date: 2004-10-17 12:08:18
hi :)
On Fri, Oct 15, 2004 at 03:13:13PM +0200, Gerd Knorr wrote:
You have a application running which uses the framebuffer device, then
suspend with that app running. You'll have to restore the state of
the device _before_ restarting all the userspace proccesses, otherwise
the app will not be very happy.
As long as the app only interfaces with the framebuffer device and not
directly with the hardware it won't notice.
The apps data will simply not show up on the screen until the
usermode helper finishes.
--
Martin Waitz
On Sun, Oct 17, 2004 at 02:07:28PM +0200, Martin Waitz wrote:
hi :)
On Fri, Oct 15, 2004 at 03:13:13PM +0200, Gerd Knorr wrote:
quoted
You have a application running which uses the framebuffer device, then
suspend with that app running. You'll have to restore the state of
the device _before_ restarting all the userspace proccesses, otherwise
the app will not be very happy.
As long as the app only interfaces with the framebuffer device and not
directly with the hardware it won't notice.
Well, mmap("/dev/fb") will just map the gfx cards memory into
the applications address space, so they _will_ interface with
the hardware.
The apps data will simply not show up on the screen until the
usermode helper finishes.
Whenever writing to the gfx memory before finishing the initialization
is harmless or not probably depends on the hardware, I'd better not
count on it ...
Gerd
--
return -ENOSIG;
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Martin Waitz <hidden> Date: 2004-10-18 11:40:35
hi :)
On Mon, Oct 18, 2004 at 10:36:32AM +0200, Gerd Knorr wrote:
On Sun, Oct 17, 2004 at 02:07:28PM +0200, Martin Waitz wrote:
quoted
On Fri, Oct 15, 2004 at 03:13:13PM +0200, Gerd Knorr wrote:
quoted
You have a application running which uses the framebuffer device, then
suspend with that app running. You'll have to restore the state of
the device _before_ restarting all the userspace proccesses, otherwise
the app will not be very happy.
As long as the app only interfaces with the framebuffer device and not
directly with the hardware it won't notice.
Well, mmap("/dev/fb") will just map the gfx cards memory into
the applications address space, so they _will_ interface with
the hardware.
but still through a driver which can take care of this access.
quoted
The apps data will simply not show up on the screen until the
usermode helper finishes.
Whenever writing to the gfx memory before finishing the initialization
is harmless or not probably depends on the hardware, I'd better not
count on it ...
when the application tries to access the framebuffer memory then
the driver is asked to map the corresponding page.
If the hardware does not cope with framebuffer access while it
is not correctly initialized, then the driver can defer those
mappings until the userspace helper is run.
--
Martin Waitz
On Mon, Oct 18, 2004 at 01:39:29PM +0200, Martin Waitz wrote:
hi :)
quoted
Whenever writing to the gfx memory before finishing the initialization
is harmless or not probably depends on the hardware, I'd better not
count on it ...
when the application tries to access the framebuffer memory then
the driver is asked to map the corresponding page.
On first access only, and even that only if the driver doesn't map the
pages at mmap() time already. Not a single fb driver seems to map the
pages lazy today, grepping in drivers/video for nopage handles shows
nothing. I'm not sure you can actually do that for iomem mappings.
Gerd
--
return -ENOSIG;
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
On Mon, Oct 18, 2004 at 02:10:33PM +0200, Gerd Knorr wrote:
On Mon, Oct 18, 2004 at 01:39:29PM +0200, Martin Waitz wrote:
quoted
hi :)
quoted
Whenever writing to the gfx memory before finishing the initialization
is harmless or not probably depends on the hardware, I'd better not
count on it ...
when the application tries to access the framebuffer memory then
the driver is asked to map the corresponding page.
On first access only, and even that only if the driver doesn't map the
pages at mmap() time already. Not a single fb driver seems to map the
pages lazy today, grepping in drivers/video for nopage handles shows
nothing. I'm not sure you can actually do that for iomem mappings.
Isn't it possible for the driver to unmap the mapping when
suspending? Then you're guaranteed to get that first access.
This can be simplified to a all-or-nothing approach, it is not
necessary to fault the pages in individually.
Helge Hafting
From: Oliver Neukum <oliver@neukum.org> Date: 2004-10-18 20:49:35
Am Montag, 18. Oktober 2004 22:21 schrieb Helge Hafting:
quoted
On first access only, and even that only if the driver doesn't map the
pages at mmap() time already. Not a single fb driver seems to map the
pages lazy today, grepping in drivers/video for nopage handles shows
nothing. I'm not sure you can actually do that for iomem mappings.
Isn't it possible for the driver to unmap the mapping when
suspending? Then you're guaranteed to get that first access.
But what would you do then? Block everything that is using a terminal?
Regards
Oliver
From: Martin Waitz <hidden> Date: 2004-10-19 17:05:45
On Mon, Oct 18, 2004 at 10:42:04PM +0200, Oliver Neukum wrote:
Am Montag, 18. Oktober 2004 22:21 schrieb Helge Hafting:
quoted
quoted
On first access only, and even that only if the driver doesn't map the
pages at mmap() time already. ?Not a single fb driver seems to map the
pages lazy today, grepping in drivers/video for nopage handles shows
nothing. ?I'm not sure you can actually do that for iomem mappings.
Isn't it possible for the driver to unmap the mapping when
suspending? ?Then you're guaranteed to get that first access.
But what would you do then? Block everything that is using a terminal?
yes
but that wouldn't last long if you run the userspace helper as soon
as you are finished resuming.
One 'only' needs a method to give feedback while loading the image...
I guess we have to rely on the firmware here.
(Eighter it already sets an useable mode or provides a function that
can display test)
--
Martin Waitz
On Gwe, 2004-10-15 at 13:38, Geert Uytterhoeven wrote:
Why not? Of course you won't get any output before the graphics card has been
re-initialized to a sane and usable state...
That will depend on the system. The AMD64 boxes I have all allow the
bios to post the video card on S3 resume.
For a lot of other stuff we can run the bios directly on the resume path
without emulation (or for intel call the video restore bios
int). For the rest this could be a useful weapon.
From: Pavel Machek <hidden> Date: 2004-10-19 21:59:39
Hi!
On Pá 15-10-04 13:45:10, Alan Cox wrote:
On Gwe, 2004-10-15 at 13:38, Geert Uytterhoeven wrote:
~~~-
eh? :-)
quoted
Why not? Of course you won't get any output before the graphics card has been
re-initialized to a sane and usable state...
That will depend on the system. The AMD64 boxes I have all allow the
bios to post the video card on S3 resume.
Do you have Arima a.k.a. eMachines notebook near you? That's the one I
can't get to work...
For a lot of other stuff we can run the bios directly on the resume path
without emulation (or for intel call the video restore bios
int). For the rest this could be a useful weapon.
What's the video restore bios int?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Note that the SNAPBoot code uses the x86emu BIOS emulator project as the
core CPU emulation technology, and project we have been actively involved
with for many years since the licensing on the project was changed to
MIT/BSD style licensing and incorporated into the XFree86 project.
quoted
So what we would like to find out is how much interest there might be in
both an updated VESA framebuffer console driver as well as the code for
the Video card BOOT process being contributed to the maintstream kernel.
It certainly would be nice to have that. Not nessesarely in the
kernel through, people tend not to like such complex stuff like
cpu emulation in the kernel for good reasons.
Well think about it as an x86 p-code interpreter then ;-) Kind of like a
forth interpreter for Open Firmware but we use an x86 image instead.
The kernel can run userspace apps (modprobe, hotplug), that
mechanism could be used to invoke a userspace tool which does the
boot / mode switching. Having it in userspace likely also makes it
easier to share code with X11.
I agree entirely, provided we can find a way to get this to run really
early in the boot sequence. We need this for non-x86 embedded machines
such as PowerPC and MIPS, not for x86 platforms where the BIOS can be
called from the boot loader easily.
Have you talked to the powermanagement guys btw.? One of the
major issues with suspend-to-ram is to get the graphics card back
online, and SNAPBoot might help to fix this too. I'm not sure a
userspace solution would work for *that* through.
That is a good point. Another good reason to have the code in 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! ~
From: Jon Smirl <hidden> Date: 2004-10-16 17:44:25
What this means is that it should be possible to build a new version of
the VESA framebuffer console driver for the Linux kernel that will have
these important features:
1. Be able to switch display modes on the fly, supporting all modes
enumerated by the Video BIOS.
2. Be able to support refresh rate control on graphics cards that support
the VBE 3.0 services.
How is this going to work if there are multiple graphics cards
installed? Each card will want to install it's own VBE extension
interrupt.
--
Jon Smirl
jonsmirl@gmail.com
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
What this means is that it should be possible to build a new version of
the VESA framebuffer console driver for the Linux kernel that will have
these important features:
1. Be able to switch display modes on the fly, supporting all modes
enumerated by the Video BIOS.
2. Be able to support refresh rate control on graphics cards that support
the VBE 3.0 services.
How is this going to work if there are multiple graphics cards
installed? Each card will want to install it's own VBE extension
interrupt.
Yep. The code I have ported to the Linux kernel right now does not
support multiple consoles because porting that code would be a lot more
work (I would prefer to keep it in userland if possible since it already
works there).
Anyway the way the system works for multiple controllers is that there is
a separate BIOS image and separate machine state maintained for each
graphics card. So you can run the VBE driver on the primary, secondary
and ternary drivers if you want. We do it all the time with SNAP just for
fun and giggles ;-)
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! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
From: Pavel Machek <hidden> Date: 2004-10-19 21:30:56
Hi!
I am writing this email to guage the interest in having code contributed
to the main stream Linux kernel that would support the user of a generic,
full featured VESA framebuffer driver that works on any CPU architecture
along with a generic Video card BOOT or POST mechanism.
This is pretty much neccessary for suspend-to-RAM, and there's a *lot*
of interest in that.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
From: Pavel Machek <hidden> Date: 2004-10-19 21:36:23
Hi!
I am writing this email to guage the interest in having code contributed
to the main stream Linux kernel that would support the user of a generic,
full featured VESA framebuffer driver that works on any CPU architecture
along with a generic Video card BOOT or POST mechanism.
BTW, does this look like right way to POST VGA BIOS from real mode? It
is what we currently use... and it works on some machines...
movw $0xb800, %ax
movw %ax,%fs
movw $0x0e00 + 'L', %fs:(0x10)
cli
cld
# setup data segment
movw %cs, %ax
movw %ax, %ds # Make ds:0 point to wakeup_start
movw %ax, %ss
mov $(wakeup_stack - wakeup_code), %sp # Private stack is needed for ASUS board
movw $0x0e00 + 'S', %fs:(0x12)
pushl $0 # Kill any dangerous flags
popfl
movl real_magic - wakeup_code, %eax
cmpl $0x12345678, %eax
jne bogus_real_magic
testl $1, video_flags - wakeup_code
jz 1f
lcall $0xc000,$3
movw %cs, %ax
movw %ax, %ds # Bios might have played with that
movw %ax, %ss
1:
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!