On Fri, 15 Oct 2004 11:20:21 -0700, Kendall Bennett
[off-list ref] wrote:
Alan Cox [off-list ref] wrote:
quoted
On Iau, 2004-10-14 at 21:46, Kendall Bennett wrote:
quoted
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
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! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
On Fri, 15 Oct 2004 15:22:51 -0700, Kendall Bennett
[off-list ref] 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
Hi!
quoted
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!