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! ~
"Kendall Bennett" <[email protected]> writes:
>
> So what do you guys think?
How big is the module with emulator etc.?
Normally putting such an emulator into kernel space doesn't
sound very attractive, but if it's small enough it can
be perhaps considered. Still it might be better to do it
in user space.
-Andi
Andi Kleen <[email protected]> wrote:
> "Kendall Bennett" <[email protected]> writes:
> >
> > So what do you guys think?
>
> How big is the module with emulator etc.?
About 150K compiled on x86 (before linking so that has symbol information
etc in it).
> Normally putting such an emulator into kernel space doesn't sound
> very attractive, but if it's small enough it can be perhaps
> considered. Still it might be better to do it in user space.
It is small, but for the purposes we need it for it wasn't possible to
put the code into user space. We thought about keeping it in user space
but unfortunately the code is needed when the framebuffer console driver
initialises which is very early in the boot sequence. So unless there is
a way to spawn a user mode process that early in the boot sequence (it
would have to come from the initrd image I expect) then the only option
is to compile it into the kernel.
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! ~
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
"Kendall Bennett" <[email protected]> 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;
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 -- [email protected]
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
Geert Uytterhoeven <[email protected]> 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;
On Iau, 2004-10-14 at 21:46, Kendall Bennett wrote:
> a way to spawn a user mode process that early in the boot sequence (it
> would have to come from the initrd image I expect) then the only option
> is to compile it into the kernel.
There is exactly that in 2.6 - the hotplug interfaces allow the kernel
to fire off userspace programs. Jon Smirl (who you should definitely
talk to about this stuff) has been hammering out a design for moving
almost all the mode switching into user space for kernel video.
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.
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
Alan Cox <[email protected]> writes:
> On Iau, 2004-10-14 at 21:46, Kendall Bennett wrote:
>> a way to spawn a user mode process that early in the boot sequence (it
>> would have to come from the initrd image I expect) then the only option
>> is to compile it into the kernel.
>
> There is exactly that in 2.6 - the hotplug interfaces allow the kernel
> to fire off userspace programs. Jon Smirl (who you should definitely
> talk to about this stuff) has been hammering out a design for moving
> almost all the mode switching into user space for kernel video.
The problem is that this would imply that the console would only
work after user space is running. Even with initrd that's quite late.
The only way I see to make that fly would be a very good early
console implementation, otherwise tracking down any problems will
be hell (how do you display "panic no rootfs found" without console?)
And writing a good early console implementation would have all the
same problems as the current one.
So I can see Kendall's point.
-Andi
On Gwe, 2004-10-15 at 15:22, Andi Kleen wrote:
> > There is exactly that in 2.6 - the hotplug interfaces allow the kernel
> > to fire off userspace programs. Jon Smirl (who you should definitely
> > talk to about this stuff) has been hammering out a design for moving
> > almost all the mode switching into user space for kernel video.
>
> The problem is that this would imply that the console would only
> work after user space is running. Even with initrd that's quite late.
It doesn't imply this at all. You set an initial mode with the BIOS
during boot up. When your initrd runs you gain the ability to flip mode
and do cool stuff - arguably it doesn't even need to be in initrd.
Andi Kleen <[email protected]> writes:
> The problem is that this would imply that the console would only
> work after user space is running. Even with initrd that's quite late.
klibc + initramfs + early userspace?
Gerd
--
return -ENOSIG;
Alan Cox <[email protected]> wrote:
> On Iau, 2004-10-14 at 21:46, Kendall Bennett wrote:
> > a way to spawn a user mode process that early in the boot sequence (it
> > would have to come from the initrd image I expect) then the only option
> > is to compile it into the kernel.
>
> There is exactly that in 2.6 - the hotplug interfaces allow the
> kernel to fire off userspace programs. Jon Smirl (who you should
> definitely talk to about this stuff) has been hammering out a
> design for moving almost all the mode switching into user space for
> kernel video.
That is awesome! I am all for moving this outside of the kernel, as it
would allow the use of ream vm86() services for VGA/VESA BIOS access on
x86 and the user of the emulator for non-x86 platforms.
The only catch would be making sure this stuff is available really early
in the boot sequence. As it stands right now the solution we have brings
up the video almost imediately after you see the 'uncompressing kernel
image' message on the serial port. The other solution of course is to get
this into the boot loader which is what the AmigaOne folks did for their
machines (U-Boot brings up the video). We are working with those guys to
update their BIOS emulator to the latest version as the one they have
doesn't work that reliably.
Anyway how do I find out more about this in 2.6?
Also I assume the code would need to end up in the initrg image, correct?
Can you point me at some resources to learn more about how to get custom
code into the initrd image?
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! ~
Alan Cox <[email protected]> wrote:
> On Gwe, 2004-10-15 at 15:22, Andi Kleen wrote:
> > > There is exactly that in 2.6 - the hotplug interfaces allow the kernel
> > > to fire off userspace programs. Jon Smirl (who you should definitely
> > > talk to about this stuff) has been hammering out a design for moving
> > > almost all the mode switching into user space for kernel video.
> >
> > The problem is that this would imply that the console would only
> > work after user space is running. Even with initrd that's quite late.
>
> It doesn't imply this at all. You set an initial mode with the BIOS
> during boot up. When your initrd runs you gain the ability to flip mode
> and do cool stuff - arguably it doesn't even need to be in initrd.
That works great on x86, but this solution was developed for PowerPC and
MIPS embedded systems development not x86 desktop systems. For those
platforms you either need a boot loader that can bring up the system into
graphics mode (possible with U-Boot) or to init the video right when the
framebuffer console driver is brought up.
>From the sound of it that might be too early to spawn a user mode
process?
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! ~
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);
"Antonino A. Daplas" <[email protected]> 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! ~
Gerd Knorr <[email protected]> wrote:
> "Kendall Bennett" <[email protected]> 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! ~
Helge Hafting <[email protected]> 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! ~
On Gwe, 2004-10-15 at 19:20, Kendall Bennett wrote:
> That works great on x86, but this solution was developed for PowerPC and
> MIPS embedded systems development not x86 desktop systems. For those
> platforms you either need a boot loader that can bring up the system into
> graphics mode (possible with U-Boot) or to init the video right when the
> framebuffer console driver is brought up.
Right there are certainly cases where you need to do stuff very early.
Even then you may benefit because you can keep the kernel side init
pretty basic and also marked "__init" so it is freed post boot.
> >From the sound of it that might be too early to spawn a user mode
> process?
Do the embedded folks want the kernel boot messages via the display or
are they happy with that via debug port/serial anyway. If so is it an
issue ? You can bring up the video at the point user space begins.
On Gwe, 2004-10-15 at 19:20, Kendall Bennett wrote:
> Also I assume the code would need to end up in the initrg image, correct?
> Can you point me at some resources to learn more about how to get custom
> code into the initrd image?
Just roll whatever you want into it. Its a file system that is your
initial root fs and is then swapped to appear under a file system it
mounts (and finally potentially is freed).
Something like the Red Hat "mkinitrd" ought to give you a good flavour
of what you can do with it.
On Fri, 15 Oct 2004 11:20:21 -0700, Kendall Bennett
<[email protected]> wrote:
> Alan Cox <[email protected]> wrote:
>
> > On Iau, 2004-10-14 at 21:46, Kendall Bennett wrote:
> > > a way to spawn a user mode process that early in the boot sequence (it
> > > would have to come from the initrd image I expect) then the only option
> > > is to compile it into the kernel.
> >
> > There is exactly that in 2.6 - the hotplug interfaces allow the
> > kernel to fire off userspace programs. Jon Smirl (who you should
> > definitely talk to about this stuff) has been hammering out a
> > design for moving almost all the mode switching into user space for
> > kernel video.
>
> That is awesome! I am all for moving this outside of the kernel, as it
> would allow the use of ream vm86() services for VGA/VESA BIOS access on
> x86 and the user of the emulator for non-x86 platforms.
>
> The only catch would be making sure this stuff is available really early
> in the boot sequence. As it stands right now the solution we have brings
> up the video almost imediately after you see the 'uncompressing kernel
> image' message on the serial port. The other solution of course is to get
> this into the boot loader which is what the AmigaOne folks did for their
> machines (U-Boot brings up the video). We are working with those guys to
> update their BIOS emulator to the latest version as the one they have
> doesn't work that reliably.
>
> Anyway how do I find out more about this in 2.6?
>
> Also I assume the code would need to end up in the initrg image, correct?
> Can you point me at some resources to learn more about how to get custom
> code into the initrd image?
The plan for this in 2.6 is to first write a VGA device driver. This
driver is responsible for identifying all of the VGA devices in a
system and ensuring only one of them gets enabled a time. I started
writing this but I haven't finished. This driver would be compiled
into the kernel. I can send source if you are interested.
I have added hooks to the PCI subsystem to record the boot video
device. If the VGA driver finds VGA devices other than the boot one it
will generate hotplug events on them. Initramfs should contain a reset
program for using X86 mode to reset these cards. To do this you need
two things from the kernel: 1) a way to make sure only a single VGA
device is active (VGA driver, allow you to disable the current VGA
device, reset the card, restore the active VGA device) and 2) a way to
get the ROM image. There is a patch in -mm that makes the ROMs visible
in sysfs that should be in the kernel shortly.
So, when you first boot you have two choices, 1) use a display the
boot ROM setup, such as VGAcon or PROMcon. or 2) have no display.
People want this both ways. VGAcon/PROMcon will let you get output
very early in the boot process.
Next the VGA driver will initialize. This will trigger user space
resets using the program on initramfs. Now it is possible to use all
of your displays. To control this from something like resume, the
driver sets a lock that is cleared by the reset app and the end of
reset. This will keep other processes out of the driver until reset is
finished.
Right now I am working on a merged fbdev/DRM that supports multi-head
adapters. It's turning out to be much more work than I though because
neither DRM or fbdev handle multihead at the device driver level. You
can get snapshots of the code at mesa3d.bkbits.net but it doesn't work
right yet. This driver is designed to run after the VGAdriver has
reset the hardware.
--
Jon Smirl
[email protected]
On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> Helge Hafting <[email protected]> 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
On Saturday 16 October 2004 02:36, Kendall Bennett wrote:
> Helge Hafting <[email protected]> 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
On Saturday 16 October 2004 02:36, Kendall Bennett wrote:
> "Antonino A. Daplas" <[email protected]> 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
Helge Hafting <[email protected]> wrote:
> On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> > Helge Hafting <[email protected]> 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! ~
Hi Jon,
> The plan for this in 2.6 is to first write a VGA device driver.
> This driver is responsible for identifying all of the VGA devices
> in a system and ensuring only one of them gets enabled a time. I
> started writing this but I haven't finished. This driver would be
> compiled into the kernel. I can send source if you are interested.
I am interested but I probably wouldn't have the time to look at it right
now.
> I have added hooks to the PCI subsystem to record the boot video
> device. If the VGA driver finds VGA devices other than the boot
> one it will generate hotplug events on them. Initramfs should
> contain a reset program for using X86 mode to reset these cards. To
> do this you need two things from the kernel: 1) a way to make sure
> only a single VGA device is active (VGA driver, allow you to
> disable the current VGA device, reset the card, restore the active
> VGA device) and 2) a way to get the ROM image. There is a patch in
> -mm that makes the ROMs visible in sysfs that should be in the
> kernel shortly.
>
> So, when you first boot you have two choices, 1) use a display the
> boot ROM setup, such as VGAcon or PROMcon. or 2) have no display.
> People want this both ways. VGAcon/PROMcon will let you get output
> very early in the boot process.
What about non-x86 platforms such as PowerPC and MIPS embedded devices
that want video (TiVo type platforms, media players etc). How would these
fit into the picture? Would this require the boot loader (ie: U-Boot or
whatever) to have the ability to POST the card?
Or perhaps the VideoBoot module would be a useful addition to the VGA
boot driver compiled into the kernel to bring up the video card into a
sane state on any system (even a dumb framebuffer linear mode) so a fully
accelerated console driver in user space can take over later on?
> Right now I am working on a merged fbdev/DRM that supports
> multi-head adapters. It's turning out to be much more work than I
> though because neither DRM or fbdev handle multihead at the device
> driver level. You can get snapshots of the code at
> mesa3d.bkbits.net but it doesn't work right yet. This driver is
> designed to run after the VGAdriver has reset the hardware.
Sounds interesting!
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! ~
Alan Cox <[email protected]> wrote:
> On Gwe, 2004-10-15 at 19:20, Kendall Bennett wrote:
> > That works great on x86, but this solution was developed for PowerPC and
> > MIPS embedded systems development not x86 desktop systems. For those
> > platforms you either need a boot loader that can bring up the system into
> > graphics mode (possible with U-Boot) or to init the video right when the
> > framebuffer console driver is brought up.
>
> Right there are certainly cases where you need to do stuff very
> early. Even then you may benefit because you can keep the kernel
> side init pretty basic and also marked "__init" so it is freed post
> boot.
Right. I haven't yet figured out how to mark the code as __init so it can
get tossed out, although if we use the VESA driver after the fact you
would want to keep it around in that case. But to just boot the card and
use say the Radeon FB driver it would be nice to toss out the code.
I should probably look into that.
> > >From the sound of it that might be too early to spawn a user mode
> > process?
>
> Do the embedded folks want the kernel boot messages via the
> display or are they happy with that via debug port/serial anyway.
> If so is it an issue ? You can bring up the video at the point user
> space begins.
Well in most cases I think what they really want is for the video to come
on as soon as possible (instantly would be best) after the power is
applied, but they probably want their own boot logo on the screen at that
point and not Linux kernel boot messages.
Also is it possible to run X on a machine that is running from a serial
console and have it start up on the graphics card at that point? I
thought about that option since then everything would be in user space,
but wasn't sure how that would work (plus there would be a long delay
between when the machine is powered on and something shows up on the
screen, which is generally not a good thing for consumer products).
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! ~
On Fri, 15 Oct 2004 15:22:51 -0700, Kendall Bennett
<[email protected]> wrote:
> What about non-x86 platforms such as PowerPC and MIPS embedded devices
> that want video (TiVo type platforms, media players etc). How would these
> fit into the picture? Would this require the boot loader (ie: U-Boot or
> whatever) to have the ability to POST the card?
There is the assumption that whatever BIOS the device has can get up a
very early console that can output critical error messages before the
kernel and early user space is loaded. For example the "I can't find
the kernel" or "initramfs is missing" error message. This also
assumes that the BIOS can post whatever display it is using.
I'm not trying to fix the problem of getting early boot messages out
of a Mac with an x86 card plugged into it. The card will work after
early user space initializes. The right way to fix that would be to
switch to something like LinuxBIOS and build the x86 emulator into it.
Also note that a lot of what you think are early boot messages are not
really being printed out during early boot. The kernel queues printks
until a console is running and then outputs them. An example of
queuing is the processor initialization messages for the first
processor. I believe there is a way to force messages like this to
print as they occur using the BIOS on x86.
> Or perhaps the VideoBoot module would be a useful addition to the VGA
> boot driver compiled into the kernel to bring up the video card into a
> sane state on any system (even a dumb framebuffer linear mode) so a fully
> accelerated console driver in user space can take over later on?
--
Jon Smirl
[email protected]
On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
<[email protected]> wrote:
> Yes, that is the downside to a userspace solution. How bad will that be?
> Note that Jon Smirl is proposing a temporary console driver for early
> boot messages until the primary console driver activates.
Does anyone know exactly how big the window is from when a compiled in
console activates until one that relies on initramfs loads? I don't
think it is very big given that a lot of the early printk's are queued
before they are displayed.
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
[email protected]
Jon Smirl <[email protected]> wrote:
> On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
> <[email protected]> wrote:
> > Yes, that is the downside to a userspace solution. How bad will that be?
> > Note that Jon Smirl is proposing a temporary console driver for early
> > boot messages until the primary console driver activates.
>
> Does anyone know exactly how big the window is from when a
> compiled in console activates until one that relies on initramfs
> loads? I don't think it is very big given that a lot of the early
> printk's are queued before they are displayed.
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! ~
On Fri, 15 Oct 2004 16:51:09 -0700, Kendall Bennett
<[email protected]> 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
[email protected]
On Gwe, 2004-10-15 at 23:27, Kendall Bennett wrote:
> Right. I haven't yet figured out how to mark the code as __init so it can
> get tossed out, although if we use the VESA driver after the fact you
> would want to keep it around in that case. But to just boot the card and
> use say the Radeon FB driver it would be nice to toss out the code.
Every function that starts __init, and every data object starting
__initdata gets magically blown away at the end of boot.
ie
int __init messy_horrible_boot_function(blah)
> Also is it possible to run X on a machine that is running from a serial
> console and have it start up on the graphics card at that point? I
Yes
On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
> Helge Hafting <[email protected]> wrote:
> > On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> > > Helge Hafting <[email protected]> wrote:
> > That's fine. What I meant, was please make it independent of the
> > VESA framebuffer driver, because one might want to use an
> > acellerated driver when one is available.
>
> Oh, it already is. The VESA driver is not actually done yet so the only
> drivers using VideoBoot right now are the accelerated ones ;-)
>
If these get in (emulator with/without the video boot), I'm willing to
modify the vesafb driver.
Tony
On Fri, Oct 15, 2004 at 05:37:09PM +0200, Gerd Knorr wrote:
> Andi Kleen <[email protected]> writes:
>
> > The problem is that this would imply that the console would only
> > work after user space is running. Even with initrd that's quite late.
>
> klibc + initramfs + early userspace?
That's still quite late in my book (by my perspective may be skewed
a bit from low level architecture hacking)
Ok I guess for debugging architectures it would work as long as you
have usable early console support everywhere that can be easily
enabled when anything goes wrong.
-Andi
On Fri, Oct 15, 2004 at 03:27:31PM -0700, Kendall Bennett wrote:
> Also is it possible to run X on a machine that is running from a serial
> console and have it start up on the graphics card at that point? I
> thought about that option since then everything would be in user space,
> but wasn't sure how that would work (plus there would be a long delay
> between when the machine is powered on and something shows up on the
> screen, which is generally not a good thing for consumer products).
I'm actually doing this in practice.
-- wli
On Saturday 16 October 2004 07:20, Jon Smirl wrote:
> On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
>
> <[email protected]> wrote:
> > Yes, that is the downside to a userspace solution. How bad will that be?
> > Note that Jon Smirl is proposing a temporary console driver for early
> > boot messages until the primary console driver activates.
>
> Does anyone know exactly how big the window is from when a compiled in
> console activates until one that relies on initramfs loads? I don't
> think it is very big given that a lot of the early printk's are queued
> before they are displayed.
There's a log of initialization that goes on between console_init() and
populate_rootfs(). However, console_init() will only initialize built-in
consoles (as pointed to by conswitchp) such as vgacon or dummycon.
However, the framebuffer system initialization does happen after
populate_rootfs().
So, at least in the framebuffer perspective, the emulator/video boot may be
loaded as part of initramfs.
Tony
On Sat, 16 Oct 2004 09:50:32 +0800, Antonino A. Daplas
<[email protected]> wrote:
> On Saturday 16 October 2004 07:20, Jon Smirl wrote:
> > On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
> >
> > <[email protected]> wrote:
> > > Yes, that is the downside to a userspace solution. How bad will that be?
> > > Note that Jon Smirl is proposing a temporary console driver for early
> > > boot messages until the primary console driver activates.
> >
> > Does anyone know exactly how big the window is from when a compiled in
> > console activates until one that relies on initramfs loads? I don't
> > think it is very big given that a lot of the early printk's are queued
> > before they are displayed.
>
> There's a log of initialization that goes on between console_init() and
> populate_rootfs(). However, console_init() will only initialize built-in
> consoles (as pointed to by conswitchp) such as vgacon or dummycon.
> However, the framebuffer system initialization does happen after
> populate_rootfs().
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
[email protected]
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.
On Sat, Oct 16, 2004 at 02:55:44AM +0200, Andi Kleen wrote:
> On Fri, Oct 15, 2004 at 05:37:09PM +0200, Gerd Knorr wrote:
> > Andi Kleen <[email protected]> writes:
> >
> > > The problem is that this would imply that the console would only
> > > work after user space is running. Even with initrd that's quite late.
> >
> > klibc + initramfs + early userspace?
>
> That's still quite late in my book (by my perspective may be skewed
> a bit from low level architecture hacking)
Framebuffer console _is_ quite late compared vgacon or even
early_printk, all the basic stuff is already up+running at that point.
I think initialization in early userspace can be done in a way that
it wouldn't delay the initial console display compared to todays vesafb
(or any other framebuffer). Of course you need some way to turn it off
and use vgacon instead ...
Gerd
--
return -ENOSIG;
> 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
[email protected]
hi :)
On Fri, Oct 15, 2004 at 03:13:13PM +0200, Gerd Knorr wrote:
> You have a application running which uses the framebuffer device, then
> suspend with that app running. You'll have to restore the state of
> the device _before_ restarting all the userspace proccesses, otherwise
> the app will not be very happy.
As long as the app only interfaces with the framebuffer device and not
directly with the hardware it won't notice.
The apps data will simply not show up on the screen until the
usermode helper finishes.
--
Martin Waitz
On Sun, Oct 17, 2004 at 02:07:28PM +0200, Martin Waitz wrote:
> hi :)
>
> On Fri, Oct 15, 2004 at 03:13:13PM +0200, Gerd Knorr wrote:
> > 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;
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
hi :)
On Fri, Oct 15, 2004 at 11:20:58AM -0700, Kendall Bennett wrote:
> Alan Cox <[email protected]> wrote:
> > It doesn't imply this at all. You set an initial mode with the BIOS
> > during boot up. When your initrd runs you gain the ability to flip mode
> > and do cool stuff - arguably it doesn't even need to be in initrd.
>
> That works great on x86, but this solution was developed for PowerPC and
> MIPS embedded systems development not x86 desktop systems. For those
> platforms you either need a boot loader that can bring up the system into
> graphics mode
not neccessarily.
If anything goes wrong before console is initialized, then that could
be displayed by the firmware.
Is there any arch which doesn't have some basic text-output
functunality in its firmware?
--
Martin Waitz
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;
Jon Smirl <[email protected]> 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! ~
Jon Smirl <[email protected]> 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! ~
Martin Waitz <[email protected]> wrote:
> On Fri, Oct 15, 2004 at 11:20:58AM -0700, Kendall Bennett wrote:
> > Alan Cox <[email protected]> wrote:
> > > It doesn't imply this at all. You set an initial mode with the BIOS
> > > during boot up. When your initrd runs you gain the ability to flip mode
> > > and do cool stuff - arguably it doesn't even need to be in initrd.
> >
> > That works great on x86, but this solution was developed for PowerPC and
> > MIPS embedded systems development not x86 desktop systems. For those
> > platforms you either need a boot loader that can bring up the system into
> > graphics mode
>
> not neccessarily.
>
> If anything goes wrong before console is initialized, then that
> could be displayed by the firmware. Is there any arch which doesn't
> have some basic text-output functunality in its firmware?
I am not sure what you mean by basic text output? If you mean to a
display, then yes, embedded boxes using U-Boot and OpenBIOS usually do
not have any text output. But if you mean serial output that is usually
the method of choice for the embedded machines that don't have support
for a physical display in the firmware.
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! ~
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
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
Richard Smith <[email protected]> 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! ~
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
Kendall Bennett wrote:
> Richard Smith <[email protected]> wrote:
>
> Good, so my assumption was incorrect which I am happy about. Since it
> makes the work we did more useful ;-)
>
> Anyway in your case do you need diagnostic messages just from the kernel
> or from the firmware as well?
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
On Mon, 18 Oct 2004 15:34:58 -0500, Richard Smith <[email protected]> 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
[email protected]
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
On Mon, 18 Oct 2004 17:34:45 -0500, Richard Smith <[email protected]> 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
[email protected]
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
Richard Smith <[email protected]> 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! ~
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
hoi :)
On Mon, Oct 18, 2004 at 12:43:41PM -0700, Kendall Bennett wrote:
> I am not sure what you mean by basic text output? If you mean to a
> display, then yes, embedded boxes using U-Boot and OpenBIOS usually do
> not have any text output. But if you mean serial output that is usually
> the method of choice for the embedded machines that don't have support
> for a physical display in the firmware.
I mean: text output on the preferred console.
Embedded devices have a serial console anyway and all other machines
have firmware support for drawing text.
That is: switching into graphics mode can be done by the firmware, bootloader,
or by userspace and doesn't have to be in the kernel.
--
Martin Waitz
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
Martin Waitz <[email protected]> wrote:
> On Mon, Oct 18, 2004 at 12:43:41PM -0700, Kendall Bennett wrote:
> > I am not sure what you mean by basic text output? If you mean to a
> > display, then yes, embedded boxes using U-Boot and OpenBIOS usually do
> > not have any text output. But if you mean serial output that is usually
> > the method of choice for the embedded machines that don't have support
> > for a physical display in the firmware.
>
> I mean: text output on the preferred console.
>
> Embedded devices have a serial console anyway and all other
> machines have firmware support for drawing text.
No, all other machines don't have firmware support for drawing text. That
is why we wrote this code in the first place.
> That is: switching into graphics mode can be done by the firmware,
> bootloader, or by userspace and doesn't have to be in the kernel.
U-Boot and OpenBIOS on the machines we are working with do not have any
support for initialising the video card. Both could be modified but at
present neither support this so the only way to bring up the video card
for framebuffer console support is in the kernel.
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! ~
Richard Smith <[email protected]> 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! ~
Hi!
> > What about non-x86 platforms such as PowerPC and MIPS embedded devices
> > that want video (TiVo type platforms, media players etc). How would these
> > fit into the picture? Would this require the boot loader (ie: U-Boot or
> > whatever) to have the ability to POST the card?
>
> There is the assumption that whatever BIOS the device has can get up a
> very early console that can output critical error messages before the
> kernel and early user space is loaded. For example the "I can't find
> the kernel" or "initramfs is missing" error message. This also
> assumes that the BIOS can post whatever display it is using.
>
> I'm not trying to fix the problem of getting early boot messages out
> of a Mac with an x86 card plugged into it. The card will work after
> early user space initializes. The right way to fix that would be to
> switch to something like LinuxBIOS and build the x86 emulator into
> it.
That still does not solve resume from suspend-to-RAM. We need to post
VGA there. We probably could do it late in userspace... but it makes
debugging resume pretty 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!
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!
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!
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!
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!
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!
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!
Pavel Machek <[email protected]> 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! ~
Paulo Marques <[email protected]> wrote:
> >>How big is the module with emulator etc.?
> >
> > About 150K compiled on x86 (before linking so that has symbol information
> > etc in it).
>
> I searched for the code in the scitech FTP server... If this code
> is similar to the one found under "../obsolete/.." then it seems
> that the code is somewhat optimized for speed, whereas for video
> initialization we probably could rework it to be optimized for
> code size.
No, the code is not under /obsolete/ but under /scitech/src/x86emu (well
at least the x86 emulator portion is). It is active code we are using as
well as sharing with the X.org server (time we did a sync actually ;-).
> If the complete interpreter could fit in 64k (or something like
> that) then the chances of it getting into the kernel would be
> probably higher and could solve a lot of problems.
Given the nature of the problems at the fact that most machines where a
real video card would be used have more than enough space to add 150K to
the kernel, making it smaller would be mostly an academic exercise IMHO.
For instance the embedded machines that usually run video normally have
at least 16M of memory, usually 32M or more. Mostly because once the
kernel is up they do a lot of stuff that needs a ton more memory than a
measly 150K, such as playing MPEG2 movies, playing MP3 files etc etc.
Although it would certainly be nice if it could be made smaller, I am not
sure how much smaller it could be trimmed down to since the code was
designed originally for functionality not necessarily speed. But you
never know - perhaps some clever rearrangement of the code could make it
smaller.
> This is a problem I find somewhat interesting, and would be
> willing to give it some of my spare time...
By all means feel free to look and see what you can do. If you do make it
smaller, I am sure the X.org folks would also be interested. We don't
have the latest version of the emulator code on our ftp site (we are
working on that) but the only difference between the code up there and
the new code is a few bugs that we have fixed. The structure and
functionality is identical.
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! ~
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!
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!
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!
It is hard to use native VGA for s3 debugging.
I don know if serial console or net console
can help s3 debugging.
Thanks
Luming
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of Pavel Machek
>Sent: 2004??10??20?? 5:09
>To: Jon Smirl
>Cc: Kendall Bennett; Alan Cox; Linux Kernel Mailing List; fbdev
>Subject: Re: Generic VESA framebuffer driver and Video card BOOT?
>
>Hi!
>
>> > What about non-x86 platforms such as PowerPC and MIPS
>embedded devices
>> > that want video (TiVo type platforms, media players etc).
>How would these
>> > fit into the picture? Would this require the boot loader
>(ie: U-Boot or
>> > whatever) to have the ability to POST the card?
>>
>> There is the assumption that whatever BIOS the device has
>can get up a
>> very early console that can output critical error messages before the
>> kernel and early user space is loaded. For example the "I can't find
>> the kernel" or "initramfs is missing" error message. This also
>> assumes that the BIOS can post whatever display it is using.
>>
>> I'm not trying to fix the problem of getting early boot messages out
>> of a Mac with an x86 card plugged into it. The card will work after
>> early user space initializes. The right way to fix that would be to
>> switch to something like LinuxBIOS and build the x86 emulator into
>> it.
>
>That still does not solve resume from suspend-to-RAM. We need to post
>VGA there. We probably could do it late in userspace... but it makes
>debugging resume pretty 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!
>-
>To unsubscribe from this list: send the line "unsubscribe
>linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
Pavel Machek <[email protected]> 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! ~
Pavel Machek <[email protected]> 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! ~
Hi!
> > > That works great on x86, but this solution was developed for PowerPC and
> > > MIPS embedded systems development not x86 desktop systems. For those
> > > platforms you either need a boot loader that can bring up the system into
> > > graphics mode (possible with U-Boot) or to init the video right when the
> > > framebuffer console driver is brought up.
> >
> > Right there are certainly cases where you need to do stuff very
> > early. Even then you may benefit because you can keep the kernel
> > side init pretty basic and also marked "__init" so it is freed post
> > boot.
>
> Right. I haven't yet figured out how to mark the code as __init so it can
> get tossed out, although if we use the VESA driver after the fact you
> would want to keep it around in that case. But to just boot the card and
> use say the Radeon FB driver it would be nice to toss out the code.
>
> I should probably look into that.
On any machine trying to do suspend-to-RAM, that POST code is likely
to be needed for suspend, too.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Kendall Bennett wrote:
> Andi Kleen <[email protected]> wrote:
>
>
>>"Kendall Bennett" <[email protected]> writes:
>>
>>>So what do you guys think?
>>
>>How big is the module with emulator etc.?
>
>
> About 150K compiled on x86 (before linking so that has symbol information
> etc in it).
I searched for the code in the scitech FTP server... If this code is
similar to the one found under "../obsolete/.." then it seems that the
code is somewhat optimized for speed, whereas for video initialization
we probably could rework it to be optimized for code size.
If the complete interpreter could fit in 64k (or something like that)
then the chances of it getting into the kernel would be probably higher
and could solve a lot of problems.
This is a problem I find somewhat interesting, and would be willing to
give it some of my spare time...
--
Paulo Marques - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
P.S. Aren't there other uses for a in-kernel x86 interpreter?
Pavel Machek <[email protected]> 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! ~
Pavel Machek <[email protected]> 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! ~
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
Antonino A. Daplas wrote:
> On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
>
>>Helge Hafting <[email protected]> wrote:
>>
>>>On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
>>>
>>>>Helge Hafting <[email protected]> wrote:
>>>
>>>That's fine. What I meant, was please make it independent of the
>>>VESA framebuffer driver, because one might want to use an
>>>acellerated driver when one is available.
>>
>>Oh, it already is. The VESA driver is not actually done yet so the only
>>drivers using VideoBoot right now are the accelerated ones ;-)
>>
>
>
> 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 - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
Paulo Marques <[email protected]> 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! ~
Kendall Bennett wrote:
> Paulo Marques <[email protected]> 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 - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
Paulo Marques <[email protected]> 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! ~