Generic VESA framebuffer driver and Video card BOOT?

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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.

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

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.

Quoted 77 lines · Kendall Bennett

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

Quoted 10 lines

-------------------------------------------------------
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 [email protected]
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Quoted 3 lines · Zachary Smith

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

Quoted 9 lines · Kendall Bennett

Quoted 3 lines · Zachary Smith

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 :)

Quoted 9 lines · Kendall Bennett

Quoted 3 lines · Zachary Smith

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.

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?

Quoted 7 lines · Kendall Bennett

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.

Quoted 1 line

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.

Quoted 4 lines · Antonino A. Daplas

Quoted 1 line

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).

Quoted 4 lines

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.

Quoted 2 lines

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?

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 3 lines · Antonino A. Daplas

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.

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.

Quoted 5 lines

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.

On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas

Quoted 3 lines · <[email protected]> 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.

Quoted 11 lines · Jon Smirl

On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas

Quoted 3 lines · <[email protected]> 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.

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().

Quoted 5 lines

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.

I would assume however a serial port console would be fine for embedded machines until the framebuffer driver could come up anyway.

Quoted 2 lines · Kendall Bennett

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 Smith <[email protected]> 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?

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).

Quoted 4 lines · Kendall Bennett

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.

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.

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

it, then it is the hardware manufacturer responsibility to acquire enough documentation from the graphics vendor so that a boot display can be implemented.

Quoted 3 lines · Jon Smirl

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.

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.

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 ;-)

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 ;-)

Quoted 4 lines · Kendall Bennett

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 3 lines

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.

Quoted 2 lines

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?

Quoted 4 lines

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.

Quoted 9 lines

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.

Quoted 10 lines

Quoted 9 lines

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.

Quoted 2 lines

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 ;-).

Quoted 5 lines

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.

Quoted 6 lines

Quoted 3 lines

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.

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.

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...

On Gwe, 2004-10-15 at 13:38, Geert Uytterhoeven wrote:

Quoted 2 lines

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.

Quoted 4 lines · Gerd Knorr

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.

hi :)

Quoted 4 lines · Gerd Knorr

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.

Quoted 6 lines · Martin Waitz

Quoted 4 lines · Gerd Knorr

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.

Quoted 2 lines

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.

Quoted 2 lines

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 ...

hi :)

Quoted 3 lines

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.

Quoted 6 lines · Martin Waitz

hi :)

Quoted 3 lines

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 ...

Quoted 2 lines

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.

Quoted 5 lines

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.

Am Montag, 18. Oktober 2004 22:21 schrieb Helge Hafting:

Quoted 7 lines

Quoted 5 lines

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?

Quoted 4 lines · Gerd Knorr

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...

Quoted 3 lines

Why not? Of course you won't get any output before the graphics card has been re-initialized to a sane and usable state...

True. I do it on my Dell 600m (Radeon 9000M) using usermodehelper and it works just fine. It works both with VGA and X. I need to split up the thaw_processes into two stages though. It may not work with fb as fb driver resumes earlier. I use the patch below for the kernel and a userlevel x86 emulator.

I have to say though, it will help if we have a such an emulator in the kernel.

Quoted 4 lines · Kendall Bennett

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 3 lines

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.

Hello All,

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.

Quoted 1 line · Kendall Bennett

Hello All,

[...]

Quoted 6 lines

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.

The BOOT stuff is very interesting. Currently, both my videocards (in the same pc) have nice hw-specific framebuffer drivers, but they require that the card is initialized by the bios first and this only ever happens to one of the cards. Xfree _can_ do the job, but way too late for setting up the framebuffer device.

Quoted 4 lines

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.

Having video BOOT would be great, and please make it independent of the framebuffer drivers.

I might want to try your vesa driver, but I might also want to use the hw-accelerated chip specific driver that happens to need an initialized video card.

Helge Hafting <[email protected]> wrote:

Quoted 2 lines

Having video BOOT would be great, and please make it independent of the framebuffer drivers.

Right now it is independent but I added a single line of code to the Radeon driver to init the card prior to initing the rest of the driver.

It can be done earlier than that inside fbmem.c, but I wasn't sure how to set up the code so it would only POST each card as it is needed as I don't want to bring up secondary controllers unless the user actually wants this.

How does the framebuffer console system handle secondary controllers right now? It seems from my look at the code that it only brings up the primary and not the secondary?

Quoted 2 lines · Kendall Bennett

Helge Hafting <[email protected]> wrote:

[...]

Quoted 3 lines

Quoted 2 lines

Having video BOOT would be great, and please make it independent of the framebuffer drivers.

Quoted 2 lines

Right now it is independent but I added a single line of code to the Radeon driver to init the card prior to initing the rest of the driver.

That's fine. What I meant, was please make it independent of the VESA framebuffer driver, because one might want to use an acellerated driver when one is available.

Quoted 4 lines

It can be done earlier than that inside fbmem.c, but I wasn't sure how to set up the code so it would only POST each card as it is needed as I don't want to bring up secondary controllers unless the user actually wants this.

Selecting which cards to "boot" can probably be done with a kernel parameter? The default could be to bring up all cards except the one the bios brought up already. Wanting to _not_ bring up some cards seems to be the unusual case to me.

Quoted 3 lines

How does the framebuffer console system handle secondary controllers right now? It seems from my look at the code that it only brings up the primary and not the secondary?

The stock 2.6.x fbcon only use one framebuffer console. I use the ruby patch which supports multiple consoles. The ruby patch for 2.6.7 support multiple fbcons so you can have several keyboards attached to separate framebuffers thus supporting several users. (VT1-VT16 is the first kbd on the first fbcon, VT17-VT32 is the second kbd on the second fbcon, and so on.)

The ruby patch for 2.6.8.1 is somewhat broken, and doesn't work with fbcon. It still support multiple keyboards and multiple framebuffers, so I can support several users with separate xservers but currently not gettys on separate fbcons.

Note that soft-booting the "extra" video card in order to support a framebuffer driver is nice even if it doesn't attach to the console, because there is other software that can utilize a framebuffer. X is the most well-known of them.

Quoted 5 lines · Helge Hafting

Quoted 1 line · Kendall Bennett

Helge Hafting <[email protected]> wrote:

That's fine. What I meant, was please make it independent of the VESA framebuffer driver, because one might want to use an acellerated driver when one is available.

Oh, it already is. The VESA driver is not actually done yet so the only drivers using VideoBoot right now are the accelerated ones ;-)

Quoted 10 lines · Kendall Bennett

Quoted 7 lines · Helge Hafting

Quoted 1 line · Kendall Bennett

Helge Hafting <[email protected]> wrote:

That's fine. What I meant, was please make it independent of the VESA framebuffer driver, because one might want to use an acellerated driver when one is available.

Quoted 3 lines

Oh, it already is. The VESA driver is not actually done yet so the only drivers using VideoBoot right now are the accelerated ones ;-)

If these get in (emulator with/without the video boot), I'm willing to modify the vesafb driver.

Well, I played with the emulator last night to see if I could reduce the code size, so that it would be easier to make it to the official kernel.

I only took ops.c and did some transformations, like using a single function to make several operations based on the opcode, instead of a separate function for each opcode, etc.[1]

This is the result. Before:

Size of stripped libx86emu.a: ~74kb
ops.c source code lines: 11682
ops.o .text size: 36136
ops.o .data: 1312

After:

Size of stripped libx86emu.a: ~57kb
ops.c source code lines: 5908
ops.o .text size: 19320
ops.o .data: 1280

If the same treatment is applied to ops2.c and prim_ops.c, I believe it would be possible to have a functional emulator for about 32kb of kernel code size, which seems pretty reasonable to me and could solve a lot of problems.

The decrease in source code size also helps maintenance, since there is not so much repeated code has it was before.

Of course, these changes are optimizing the emulator for code size, and not execution speed. I haven't done any benchmarks to see if there is a noticeable difference in speed.

Paulo Marques <[email protected]> wrote:
.....

Quoted 4 lines

If the same treatment is applied to ops2.c and prim_ops.c, I believe it would be possible to have a functional emulator for about 32kb of kernel code size, which seems pretty reasonable to me and could solve a lot of problems.

Wow, that is great!

Quoted 7 lines

The decrease in source code size also helps maintenance, since there is not so much repeated code has it was before.

Of course, these changes are optimizing the emulator for code size, and not execution speed. I haven't done any benchmarks to see if there is a noticeable difference in speed.

Did you get the latest code? I have been sick with the flu and I think I forgot to send you the latest code to play with. We should get you set up so you can merge your changes into our tree and then we can update the one in the X.org tree as well (Egbert Eich usually does that from our tree).

One other thing, is there a simple way to test the emulator? I've been careful with the changes I did not to change the resulting behaviour of the emulator, but I can not _absolutely_ sure that I didn't break anything. It would be very good to try the emulator in a controlled environment.

Quoted 1 line · Helge Hafting

On 14-10-2004 21:02:36, Kendall Bennett wrote:

How does the framebuffer console system handle secondary controllers right now? It seems from my look at the code that it only brings up the primary and not the secondary?

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.

Quoted 7 lines

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.

Quoted 2 lines

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.

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.

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

Quoted 7 lines

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)

What is this for?

Quoted 9 lines

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)

We have never needed to set up a private stack. What ASUS board was it that you had problems with and needed to do this for?

Quoted 10 lines

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

The call to 0xC000:0x0003 is the entry point to POST the card. However for PCI cards you need to make sure that AX is loaded with the bus, slot and function for the card that is being POST'ed. It will pass this value to the PCI BIOS Int 0x1A functions in order to find itself, so if this is not set many BIOS'es will not work.

Quoted 9 lines

Quoted 7 lines

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)

What is this for?

Debugging.

Quoted 10 lines

Quoted 9 lines

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)

Quoted 2 lines

We have never needed to set up a private stack. What ASUS board was it that you had problems with and needed to do this for?

This is running at system resume, so it is not normal boot. Some ASUS Athlon 900MHz machine needed this; I'm no longer using this one.

Quoted 11 lines

Quoted 10 lines

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

Quoted 5 lines

The call to 0xC000:0x0003 is the entry point to POST the card. However for PCI cards you need to make sure that AX is loaded with the bus, slot and function for the card that is being POST'ed. It will pass this value to the PCI BIOS Int 0x1A functions in order to find itself, so if this is not set many BIOS'es will not work.

Ok, this one is bad... ... In case of just one vga adapter, we should be able to store its parameters in some well-known place. For more than one adapter, we'll definitely need to run BIOS in emulator.

Quoted 17 lines

Quoted 11 lines

Quoted 10 lines

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

Quoted 5 lines

The call to 0xC000:0x0003 is the entry point to POST the card. However for PCI cards you need to make sure that AX is loaded with the bus, slot and function for the card that is being POST'ed. It will pass this value to the PCI BIOS Int 0x1A functions in order to find itself, so if this is not set many BIOS'es will not work.

Quoted 4 lines

Ok, this one is bad... ... In case of just one vga adapter, we should be able to store its parameters in some well-known place. For more than one adapter, we'll definitely need to run BIOS in emulator.

Yes. If you are running this in real mode you don't have any option but to use the BIOS emulator. If you are running in protected mode and using vm86() style service, the 0xC0000 memory is just memory and can be re- written. For instance on Linux you can map 0xC0000 into your process address space as copy on write, which then allows you to re-write the BIOS image for a secondary controller and then restore it when you are done.

One more question: Does 0xc0000 POST method work even on notebooks? On regular machines, PCI card must have normal bios and stuff is easy. On notebooks there was talk about "integrated bios" where it really has no video bios at all and system bios POSTs the card. Have you seen that?

Quoted 5 lines

One more question: Does 0xc0000 POST method work even on notebooks? On regular machines, PCI card must have normal bios and stuff is easy. On notebooks there was talk about "integrated bios" where it really has no video bios at all and system bios POSTs the card. Have you seen that?

We have never had a need to POST a notebook Video BIOS so I don't know what would happen. It is an interesting question, and if this is to be used for resume operations something that should be investigated.