Re: Generic VESA framebuffer driver and Video card BOOT?

Re: Generic VESA framebuffer driver and Video card BOOT?

[Andi Kleen]

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Andi Kleen <ak@muc.de> wrote:

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Alan Cox]

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.

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Alan Cox <alan@lxorguk.ukuu.org.uk> 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! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Alan Cox]

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.

Re: Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Fri, 15 Oct 2004 11:20:21 -0700, Kendall Bennett
<kendallb@scitechsoft.com> wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> 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
jonsmirl@gmail.com

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

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!

Re: Generic VESA framebuffer driver and Video card BOOT?

[Paulo Marques]

Kendall Bennett wrote:
> Andi Kleen <ak@muc.de> wrote:
> 
> 
>>"Kendall Bennett" <KendallB@scitechsoft.com> 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 -  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?

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Paulo Marques <pmarques@grupopie.com> 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! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

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!

RE: Generic VESA framebuffer driver and Video card BOOT?

[Yu, Luming]

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: linux-kernel-owner@vger.kernel.org 
>[mailto:linux-kernel-owner@vger.kernel.org] 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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> I am writing this email to guage the interest in having code contributed 
> to the main stream Linux kernel that would support the user of a generic, 
> full featured VESA framebuffer driver that works on any CPU architecture 
> along with a generic Video card BOOT or POST mechanism.

BTW, does this look like right way to POST VGA BIOS from real mode? It
is what we currently use... and it works on some machines...

        movw    $0xb800, %ax
        movw    %ax,%fs
        movw    $0x0e00 + 'L', %fs:(0x10)

        cli
        cld

        # setup data segment
        movw    %cs, %ax
        movw    %ax, %ds                                        # Make ds:0 point to wakeup_start
        movw    %ax, %ss
        mov     $(wakeup_stack - wakeup_code), %sp              # Private stack is needed for ASUS board
        movw    $0x0e00 + 'S', %fs:(0x12)

        pushl   $0                                              # Kill any dangerous flags
        popfl

        movl    real_magic - wakeup_code, %eax
        cmpl    $0x12345678, %eax
        jne     bogus_real_magic

        testl   $1, video_flags - wakeup_code
        jz      1f
        lcall   $0xc000,$3
        movw    %cs, %ax
        movw    %ax, %ds                                        # Bios might have played with that
        movw    %ax, %ss
1:

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> I am writing this email to guage the interest in having code contributed 
> to the main stream Linux kernel that would support the user of a generic, 
> full featured VESA framebuffer driver that works on any CPU architecture 
> along with a generic Video card BOOT or POST mechanism.

This is pretty much neccessary for suspend-to-RAM, and there's a *lot*
of interest in that.

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Martin Waitz <tali@admingilde.org> 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! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Martin Waitz]

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

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

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Martin Waitz <tali@admingilde.org> wrote:

> On Fri, Oct 15, 2004 at 11:20:58AM -0700, Kendall Bennett wrote:
> > Alan Cox <alan@lxorguk.ukuu.org.uk> 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! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Martin Waitz]

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

hi :)

On Fri, Oct 15, 2004 at 11:20:58AM -0700, Kendall Bennett wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> 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

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

> What this means is that it should be possible to build a new version of
> the VESA framebuffer console driver for the Linux kernel that will have
> these important features:
> 
> 1. Be able to switch display modes on the fly, supporting all modes
> enumerated by the Video BIOS.
> 
> 2. Be able to support refresh rate control on graphics cards that support
> the VBE 3.0 services.

How is this going to work if there are multiple graphics cards
installed? Each card will want to install it's own VBE extension
interrupt.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Generic VESA framebuffer driver and Video card BOOT?

[Gerd Knorr]

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 <ak@muc.de> 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;

Re: Generic VESA framebuffer driver and Video card BOOT?

[William Lee Irwin III]

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Andi Kleen]

On Fri, Oct 15, 2004 at 05:37:09PM +0200, Gerd Knorr wrote:
> Andi Kleen <ak@muc.de> 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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Alan Cox]

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Alan Cox <alan@lxorguk.ukuu.org.uk> 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! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

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

> On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> > Helge Hafting <helgehaf@aitel.hist.no> wrote:
> > 
> [...]
> > > Having video BOOT would be great, and please make it independent of
> > > the framebuffer drivers.  
> > 
> > Right now it is independent but I added a single line of code to the 
> > Radeon driver to init the card prior to initing the rest of the driver. 
> 
> That's fine.  What I meant, was please make it independent of the
> VESA framebuffer driver, because one might want to use an
> acellerated driver when one is available. 

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

> > It can be done earlier than that inside fbmem.c, but I wasn't sure how to 
> > set up the code so it would only POST each card as it is needed as I 
> > don't want to bring up secondary controllers unless the user actually 
> > wants this.
> 
> Selecting which cards to "boot" can probably be done with a kernel
> parameter?  The default could be to bring up all cards except the
> one the bios brought up already.  Wanting to _not_ bring up some
> cards seems to be the unusual case to me. 

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

> > How does the framebuffer console system handle secondary controllers 
> > right now? It seems from my look at the code that it only brings up the 
> > primary and not the secondary?
> 
> The stock 2.6.x fbcon only use one framebuffer console.  I use the
> ruby patch which supports multiple consoles.  The ruby patch for
> 2.6.7 support multiple fbcons so you can have several keyboards
> attached to separate framebuffers thus supporting several users.
> (VT1-VT16 is the first kbd on the first fbcon, VT17-VT32 is the
> second kbd on the second fbcon, and so on.) 
> 
> The ruby patch for 2.6.8.1 is somewhat broken, and doesn't work
> with fbcon. It still support multiple keyboards and multiple
> framebuffers, so I can support several users with separate xservers
> but currently not gettys on separate fbcons. 

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

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

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

Regards,

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

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Helge Hafting]

On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> Helge Hafting <helgehaf@aitel.hist.no> wrote:
> 
[...]
> > Having video BOOT would be great, and please make it independent of
> > the framebuffer drivers.  
> 
> Right now it is independent but I added a single line of code to the 
> Radeon driver to init the card prior to initing the rest of the driver. 

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

> It can be done earlier than that inside fbmem.c, but I wasn't sure how to 
> set up the code so it would only POST each card as it is needed as I 
> don't want to bring up secondary controllers unless the user actually 
> wants this.
> 
Selecting which cards to "boot" can probably be done with a
kernel parameter?  The default could be to bring up all cards
except the one the bios brought up already.  Wanting to _not_
bring up some cards seems to be the unusual case to me.

> How does the framebuffer console system handle secondary controllers 
> right now? It seems from my look at the code that it only brings up the 
> primary and not the secondary?
> 
The stock 2.6.x fbcon only use one framebuffer console.  I use the ruby
patch which supports multiple consoles.  The ruby patch for
2.6.7 support multiple fbcons so you can have several keyboards
attached to separate framebuffers thus supporting several users.
(VT1-VT16 is the first kbd on the first fbcon,
VT17-VT32 is the second kbd on the second fbcon, and so on.)

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

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

Helge Hafting

Re: Generic VESA framebuffer driver and Video card BOOT?

[Alan Cox]

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.

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

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

> On 14-10-2004 21:02:36, Kendall Bennett wrote:
> > Hello All,
> [...]
> > So what we would like to find out is how much interest there might be
> > in
> > both an updated VESA framebuffer console driver as well as the code
> > for
> > the Video card BOOT process being contributed to the maintstream
> > kernel.
> 
> The BOOT stuff is very interesting.  Currently, both my videocards
> (in the same pc) have nice hw-specific framebuffer drivers, but
> they require that the card is initialized by the bios first and
> this only ever happens to one of the cards.  Xfree _can_ do the
> job, but way too late for setting up the framebuffer device. 

Exactly.

> > If there is interest, we would start out by first contributing the
> > core
> > emulator and Video BOOT code, and then work on building a better VESA
> > framebuffer console driver.
> 
> Having video BOOT would be great, and please make it independent of
> the framebuffer drivers.  

Right now it is independent but I added a single line of code to the 
Radeon driver to init the card prior to initing the rest of the driver. 
It can be done earlier than that inside fbmem.c, but I wasn't sure how to 
set up the code so it would only POST each card as it is needed as I 
don't want to bring up secondary controllers unless the user actually 
wants this.

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

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

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

Regards,

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

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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Alan Cox <alan@lxorguk.ukuu.org.uk> 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! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Gerd Knorr]

Andi Kleen <ak@muc.de> 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;

Re: Generic VESA framebuffer driver and Video card BOOT?

[Alan Cox]

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.

Re: Generic VESA framebuffer driver and Video card BOOT?

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> 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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Helge Hafting]

On 14-10-2004 21:02:36, Kendall Bennett wrote:
> Hello All,
[...]
> So what we would like to find out is how much interest there might be
> in
> both an updated VESA framebuffer console driver as well as the code
> for
> the Video card BOOT process being contributed to the maintstream
> kernel.

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

> If there is interest, we would start out by first contributing the
> core
> emulator and Video BOOT code, and then work on building a better VESA
> framebuffer console driver.

Having video BOOT would be great, and please make it independent
of the framebuffer drivers.  I might want to try your vesa driver,
but I might also want to use the hw-accelerated chip specific driver
that happens to need an initialized video card.

Helge Hafting

Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Hello All,

I am writing this email to guage the interest in having code contributed 
to the main stream Linux kernel that would support the user of a generic, 
full featured VESA framebuffer driver that works on any CPU architecture 
along with a generic Video card BOOT or POST mechanism.

We have been working on a project under contract to ATI that involves 
porting a version of our SNAPBoot BIOS emulator solution to the PowerPC 
Linux kernel. The SNAPBoot code supports initialising a graphics card 
using an x86 BIOS image on any platform (currently tesed on x86, x86-64 
and PowerPC). Initially SNAPBoot was developed to work across multiple 
operating systems and CPU architectures from user space, but the desire 
to use it to initialise the graphics card on embedded PowerPC kernels 
prompted us to port a version of it for use within the Linux kernel. The 
version we have ported for use in the kernel can be used to initialise 
the graphics card for use with any accelerated framebuffer console 
driver, such as the radeonfb driver which we are currently using it with.

Note that the SNAPBoot code uses the x86emu BIOS emulator project as the 
core CPU emulation technology, and project we have been actively involved 
with for many years since the licensing on the project was changed to 
MIT/BSD style licensing and incorporated into the XFree86 project. We 
have built code on top of x86emu to provide generic support for 
initialising graphics cards on multiple platforms as well as supporting 
initialisation of modern NonVGA graphics cards (like the ATI Radeon 
family) without needing access to real VGA resources such as VGA I/O 
ports and physical memory at 0xA0000-0xBFFFF.

More importantly we have used SNAPBoot to port our generic VESA SNAP 
display driver to work on multiple operating systems and platforms, 
including both x86-64 and PowerPC platforms. Using this driver you can 
use any graphics card in the machine and it will support all the features 
provided by the graphics cards VESA BIOS, including support for refresh 
rate control on cards that support VBE 3.0 services. We have been 
actively testing both the SNAPBoot capability and the BIOS emulator on 
many platforms and graphics cards, and the latest version work flawlessly 
on just about every graphics card we have tested.

What this means is that it should be possible to build a new version of 
the VESA framebuffer console driver for the Linux kernel that will have 
these important features:

1. Be able to switch display modes on the fly, supporting all modes 
enumerated by the Video BIOS.

2. Be able to support refresh rate control on graphics cards that support 
the VBE 3.0 services.

3. Be able to support 8-bit and 32-bit display modes on any graphics card 
on big endian machines (16-bit is not possible unless software rendering 
code is written to enable endian swapping in software, which may be 
possible).

So what we would like to find out is how much interest there might be in 
both an updated VESA framebuffer console driver as well as the code for 
the Video card BOOT process being contributed to the maintstream kernel. 
If there is interest, we would start out by first contributing the core 
emulator and Video BOOT code, and then work on building a better VESA 
framebuffer console driver. 

So what do you guys think? 

Regards,

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

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