Generic VESA framebuffer driver and Video card BOOT?

Generic VESA framebuffer driver and Video card BOOT?

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Antonino A. Daplas]

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Gerd Knorr]

"Kendall Bennett" <KendallB@scitechsoft.com> writes:

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Geert Uytterhoeven]

On Fri, 15 Oct 2004, Gerd Knorr wrote:
> 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Alan Cox]

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.

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Gerd Knorr]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Fri, 15 Oct 2004, Gerd Knorr wrote:
> > 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;

Re: Generic VESA framebuffer driver and Video card BOOT?

[Helge Hafting]

On 14-10-2004 21:02:36, Kendall Bennett wrote:
> 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.

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.

> 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Venkatesh Pallipadi]

On Fri, Oct 15, 2004 at 02:38:01PM +0200, Geert Uytterhoeven wrote:
> On Fri, 15 Oct 2004, Gerd Knorr wrote:
> > 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...
> 

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.

Thanks,
Venki


--- linux-2.6.9-rc2/kernel/power/main.c.org	2004-09-12 18:23:00.671546520 -0700
+++ linux-2.6.9-rc2/kernel/power/main.c	2004-09-12 18:22:27.548581976 -0700
@@ -106,12 +106,28 @@ static int suspend_enter(u32 state)
  *	console that we've allocated.
  */
 
+int vgapost_usermode(void)
+{
+	char	*argv[3] = {NULL, NULL, NULL};
+	char	*envp[3] = {NULL, NULL, NULL};
+
+	argv[0] = "/root/emu/video_post";
+
+	/* minimal command environment */
+	envp[0] = "HOME=/";
+	envp[1] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
+        
+	return call_usermodehelper(argv[0], argv, envp, 1);
+}
+
 static void suspend_finish(u32 state)
 {
 	int retval;
 	device_resume();
 	if (pm_ops && pm_ops->finish)
 		pm_ops->finish(state);
+	thaw_processes_kernel();
+	retval = vgapost_usermode();
 	thaw_processes();
 
 	pm_restore_console();
--- linux-2.6.9-rc2/kernel/power/process.c.org	2004-09-12 18:21:48.266553752 -0700
+++ linux-2.6.9-rc2/kernel/power/process.c	2004-09-12 18:22:06.851728376 -0700
@@ -97,6 +97,29 @@ int freeze_processes(void)
 	return 0;
 }
 
+void thaw_processes_kernel(void)
+{
+	struct task_struct *g, *p;
+
+	printk( "Restarting kernel tasks..." );
+	read_lock(&tasklist_lock);
+	do_each_thread(g, p) {
+		if (!freezeable(p))
+			continue;
+		if (p->parent->pid != 1)
+			continue;
+		if (p->flags & PF_FROZEN) {
+			p->flags &= ~PF_FROZEN;
+			wake_up_process(p);
+		} else
+			printk(KERN_INFO " Strange, %s not stopped\n", p->comm );
+	} while_each_thread(g, p);
+
+	read_unlock(&tasklist_lock);
+	schedule();
+	printk( " done\n" );
+}
+
 void thaw_processes(void)
 {
 	struct task_struct *g, *p;
@@ -106,6 +129,8 @@ void thaw_processes(void)
 	do_each_thread(g, p) {
 		if (!freezeable(p))
 			continue;
+		if (p->parent->pid == 1)
+			continue;
 		if (p->flags & PF_FROZEN) {
 			p->flags &= ~PF_FROZEN;
 			wake_up_process(p);

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

"Antonino A. Daplas" <adaplas@hotpop.com> wrote:

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

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Gerd Knorr <kraxel@bytesex.org> wrote:

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

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Helge Hafting <helgehaf@aitel.hist.no> wrote:

> On 14-10-2004 21:02:36, Kendall Bennett wrote:
> > 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.
> 
> 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. 

Exactly.

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

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?

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

Yep, you could use either. In fact you could even use the VGA text 
console driver on PowerPC and MIPS platforms provided the kernel 
correctly sets up the proper VGA resource mappings (which many embedded 
kernels do not do).

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Helge Hafting]

On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> Helge Hafting <helgehaf@aitel.hist.no> wrote:
> 
[...]
> > 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. 

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.

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

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

Helge Hafting

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Antonino A. Daplas]

On Saturday 16 October 2004 02:36, Kendall Bennett wrote:
> "Antonino A. Daplas" <adaplas@hotpop.com> wrote:
> > > 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).
>
> > 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. 

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

http://dev.gentoo.org/~spock/projects/vesafb-tng/

Tony

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Antonino A. Daplas]

On Saturday 16 October 2004 02:36, Kendall Bennett wrote:
> Helge Hafting <helgehaf@aitel.hist.no> wrote:
> > 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?

By default, the first driver to initialize is used by the fb console.   If
there are more than 1 fb driver, one can either use:

- con2fbmap
- the "fbcon=map:abcd" kernel boot option

Of course, the secondary card must be POSTed.

Tony

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Helge Hafting <helgehaf@aitel.hist.no> wrote:

> On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> > Helge Hafting <helgehaf@aitel.hist.no> wrote:
> > 
> [...]
> > > 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. 
> 
> 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 ;-)

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

Not really. In many cases there may be a secondary controller on the 
system that is not wanted, such as when the user has an i915G or other 
chipset with integrated video but has plugged a different video card into 
the system. The integrated video can still be active so trying to bring 
it up may be problematic unless it is really wanted.

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

Cool. So this stuff is not yet in the official kernel trees. Is that 
going to happen or is the project to move the video out of the kernel 
going to happen first?

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

Yes, but if you don't need a framebuffer console on the card then X or 
whatever can bring up the secondary controller from user space once the 
kernel has booted.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
<adaplas@hotpop.com> 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Jon Smirl <jonsmirl@gmail.com> wrote:

> On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
> <adaplas@hotpop.com> 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. 

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Fri, 15 Oct 2004 16:51:09 -0700, Kendall Bennett
<kendallb@scitechsoft.com> 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

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Antonino A. Daplas]

On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
> Helge Hafting <helgehaf@aitel.hist.no> wrote:
> > On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> > > Helge Hafting <helgehaf@aitel.hist.no> 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 ;-)
>

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

Tony

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Antonino A. Daplas]

On Saturday 16 October 2004 07:20, Jon Smirl wrote:
> On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
>
> <adaplas@hotpop.com> 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().  

So, at least in the framebuffer perspective, the emulator/video boot may be
loaded as part of initramfs.

Tony

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Sat, 16 Oct 2004 09:50:32 +0800, Antonino A. Daplas
<adaplas@hotpop.com> wrote:
> On Saturday 16 October 2004 07:20, Jon Smirl wrote:
> > On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
> >
> > <adaplas@hotpop.com> 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().

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Nigel Cunningham]

Hi.

On Sat, 2004-10-16 at 04:29, Venkatesh Pallipadi 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...
> > 
> 
> 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.

Just a quick question: is this the right way to distinguish kernel
threads? I've been checking if the process has an mm context (if p->mm).

> +		if (p->parent->pid != 1)
> +			continue;

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.

Re: Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

> 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Gerd Knorr]

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Gerd Knorr]

On Mon, Oct 18, 2004 at 01:39:29PM +0200, Martin Waitz wrote:
> hi :)
> 
> > 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;

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Jon Smirl <jonsmirl@gmail.com> wrote:

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

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Jon Smirl <jonsmirl@gmail.com> wrote:

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Helge Hafting]

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Oliver Neukum]

Am Montag, 18. Oktober 2004 22:21 schrieb Helge Hafting:
> > 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Richard Smith <rsmith@bitworks.com> wrote:

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

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

Kendall Bennett wrote:

> Richard Smith <rsmith@bitworks.com> 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Mon, 18 Oct 2004 15:34:58 -0500, Richard Smith <rsmith@bitworks.com> wrote:
> 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.

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Mon, 18 Oct 2004 17:34:45 -0500, Richard Smith <rsmith@bitworks.com> 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Richard Smith <rsmith@bitworks.com> wrote:

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

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

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 

Check out linux-tiny (http://www.selenic.com/tiny-about/)

> 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Mon, Oct 18, 2004 at 10:42:04PM +0200, Oliver Neukum wrote:
> Am Montag, 18. Oktober 2004 22:21 schrieb Helge Hafting:
> > > 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Richard Smith <rsmith@bitworks.com> wrote:

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

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.

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

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!

Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

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!

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

On Pá 15-10-04 13:45:10, Alan Cox wrote:
> On Gwe, 2004-10-15 at 13:38, Geert Uytterhoeven wrote:
     ~~~-
	  eh? :-)

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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

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

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

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

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

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

The rest of the code you have above seems superfluous to me as we have 
never needed to do that. Then again we boot the card using the BIOS 
emulator, which is different because it runs within a protected machine 
state.

Have you taken a look at the X.org code? They have code in there to POST 
the video card also (either using vm86() or the BIOS emulator).

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

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

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

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.

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

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.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

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

Ok ;-)

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

Ok. For the BIOS emulator the code always has it's own local stack anyway 
so I assume the problme you had may have been that the BIOS on the board 
was using too much stack space, so setting up a local stack that is big 
enough is probably a good idea.

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

But you will also need to make sure you can hook the Int 0x1A interrupt 
to hide any other graphics cards on the bus as some BIOS'es are pretty 
stupid and will find the first card on the bus that matches their 
Vendor/Device ID's. So if you have two of the same card, it will find th 
wrong 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! ~

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

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

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> > > >         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.
> > 
> > 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?
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

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

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

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

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

Kendall Bennett wrote:

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

With all the video chips I've worked with the mfg gives me a binary 
formatted up as an option ROM and I'm responsible for getting it called.

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

What I've seen is that they simply place a copy of the video bios at the 
shadowed legacy vbios range usually 0xc0000 but it can be anywhere in 
the 0xc0000-0x0e0000 range.  Or physically locate the vbios in the 
onboard ROM such that it will show up in that range.

Then when the system bios goes through its scan of the legacy ranges 
looking for option roms it hits the video bios and runs it.

-- 
Richard A. Smith

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Paulo Marques]

Antonino A. Daplas wrote:
> On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
> 
>>Helge Hafting <helgehaf@aitel.hist.no> wrote:
>>
>>>On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
>>>
>>>>Helge Hafting <helgehaf@aitel.hist.no> 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 ;-)
>>
> 
> 
> 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.






[1] The worst offenders were actually constructions like:

FETCH_DECODE_MODRM(mod, rh, rl);
switch (mod) {
   case 0:
       ...<some code>
       addr = decode_rm00_address(rl);
       ...<some more code>
       break;
   case 1:
       ...<exactly the same code as above>
       addr = decode_rm01_address(rl);
       ...<exactly the same code as above>
       break;
   case 2:
       ...<exactly the same code as above>
       addr = decode_rm10_address(rl);
       ...<exactly the same code as above>
       break;
    case 3:
       <diferent code to handle register-register ops>
       break;
   }

This could be easily changed to:

FETCH_DECODE_MODRM(mod, rh, rl);
if (mod < 3) {
       ...<some code>
       addr = decode_rmXX_address(mod, rl);
       ...<some more code>
   } else {
       <diferent code to handle register-register ops>
   }

simply by making a new decode_rmXX_address function that handles the mod 
parameter. There were more than 20 of these, and some of them were 
pretty big.

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Paulo Marques <pmarques@grupopie.com> wrote:

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

Wow, that is great!

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

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Paulo Marques]

Kendall Bennett wrote:
> Paulo Marques <pmarques@grupopie.com> wrote:
> .....
>>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!

Thanks :)

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

No, I didn't get the latest source (you did disapear for a while :) ).

I started to work on the old source because:

  A - I really wanted to know if this could be done and what kind of 
improvements could be expected, even if the actual changes were thrown 
away in the end

  B - you said that only small bug fixes were made since this version, 
so I probably could diff the source I started from against the latest 
and do the same fixes to my latest source.

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.

Anyway, I think I'll have some more time tonight, so probably tomorrow 
I'll have more information about the final code size.

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Paulo Marques <pmarques@grupopie.com> wrote:

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

Unfortunately the test code I wrote years ago is only for Open Watcom and 
uses inline assembler. It hasn't been used for some time and I am not 
sure if it works properly or not (I don't think it does right now). Plus 
we recently found out that it doesn't test everything, just the 
implementation of prim_ops.c.

The only real way to test the emulator is to use it to emulate some code. 
We don't have any code we use on a regular basis to test it, but perhaps 
we should think about building a test suite for it. Usually we test it on 
Video BIOS ROM's, but that is painful because you have to switch video 
cards all the time.

XFree86 and X.org do use the same code so it could be tested there, but 
once again it is only used for Video BIOS ROM stuff. 

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