Hi Kevin,
It took a bit longer but now i have your vga patches/updates working on
Geode GX2.(i had to solve a bug in my VSA first)
Not all of your patches did apply cleanly.
I made this patchset to test the code on GX2 and it works.:)
Signed-off-by: Nils Jacobs <njacobs8 at adsltotaal.nl>
Thanks, Nils.
On Wed, Jan 04, 2012 at 05:19:59PM +0000, Julian Pidancet wrote:
> On Sat, Nov 5, 2011 at 2:43 AM, Julian Pidancet
> <julian.pidancet(a)gmail.com> wrote:
> > When running on Xen, use Xen debug io port as debug output instead
> > of Bochs one.
I'm leery of having multiple "magic" debug ports. Is it possible for
Xen to pick up port 0x0402 (or use the qemu style -device
isa-debugcon,iobase=0x402 command line option)?
-Kevin
Hi Fred,
On Mon, Jan 02, 2012 at 10:16:56AM +0100, Fred . wrote:
> Yes.
> Immediately/initially misc minor cleanup such as copyediting,
> capitalization, punctation, etc.
I'm not really interested in these types of changes. The wiki lacks
content; it doesn't lack for style of other's content.
> Then add content;
> * List of standards supported
> * List of features supported
> * Links to PDF standard specifications for developers
FYI - there is a page at: http://seabios.org/Developer_links
> * Link to Wikipedia article, link to project page on coreboot site
> * List of acronyms
> * FAQ
> * Readme, documentation
If you wish to add content, then send your articles to the list, and
if they make sense I'll push them to the wiki. To be clear, though,
I'm not interested in quick changes or high level thoughts - to really
contribute requires research, attention to detail, and work. If
you're willing to commit to working on the project then I'd be glad
for the assistance.
-Kevin
Hi,
There were a number of requests about support of 64bit PCI BAR allocations.
Also we have observed the issue on guests with older linux version
(2.6.18): if we
have a 64bit BAR allocated within first 4GB, the OS may hang during
start process.
(I guess it is an OS bug, but we need to take care of this).
This patch addresses these two issues and allows 64bit BARs to be
allocated in ranges
above 4GB.
Patch consists of three parts:
1. Add new range above 4GB in _CRS table to let Windows 2008 work
properly. Thanks
a lot to Michael S. Triskin for this brilliant idea.
2. Added new PCI_REGION_TYPE_PREFMEM_64 region type in pciinit and changed
types of variables.
3. Take care about PCI devices with 64bit BARs on secondary buses.
Patches have been tested on several configurations which includes linux
2.6.18 - 3.0 &
windows 2008. Everything works quite well.
On Tue, Jan 03, 2012 at 12:42:10PM +0000, Julian Pidancet wrote:
> On Wed, Dec 21, 2011 at 5:39 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > I'm not sure which scheme makes the most sense. I could see using the
> > "cirrus" scheme - each hardware type defines its own "handle_10" and
> > "vga_post" in a file dedicated to that hardware, which then check for
> > hardware specific functions and call "library" code for the standard
> > stuff. However, I'm not sure how much code duplication there would be
> > for things like the VBE calls which seem to contain a mix of standard
> > info and hardware specific info.
> >
>
> Happy new year,
Happy new year!
> I havn't studied the cirrus code yet, but the part which implements
> the VBE interface should be quite simillar from one driver to another,
> so I don't think it is necessary to let every hardware type redefine
> its own int10 handler, at least for the vesa part.
Yes - I looked at this closer last week and I agree. The VBE
interface is too complex to implement multiple times. (For example,
full VBE support has five entry points.)
I think the main code could call out to hardware specific code where
needed. The last patch series I sent starts this idea. The idea is
to have the main code in vgaentry.S, vgabios.c, vgafb.c, and vbe.c,
while the rest of the code is driver specific (with the "standard" vga
interface - stdvga.c and vgatables.c - used by the other drivers as
needed).
I think after reworking it, the hardware specific drivers will only
need to provide X_init(), X_set_mode(), X_save/restore_state(), and
X_mode_info() functions. The mode stuff can be further refactored -
right now the cirrus, bochs, and stdvga stuff all have similar mode
tables - the main code can reuse those tables if the common
information (memmodel, width, height, depth, cwidth, cheight, segment)
is stored in the same format across drivers.
-Kevin
On Sat, Dec 17, 2011 at 04:44:52PM +0000, Julian Pidancet wrote:
> Also, I implemented this vbe driver skeleton with an interface which
> could be as generic as possible to allow to implement several
> different drivers. But I am actually wondering now what would be the
> best way for several drivers to share the same interface in terms of
> code.
That is an interesting issue. The current lgpl seems to use two
schemes - the bochs vbe interface is inline with the standard vga
interface and uses "#ifdef VBE" guards - the cirrus interface takes
the int10 vector, checks for the calls it needs to handle and then
calls the standard vga interface for the rest.
A couple of years back, a geode interface was written for seabios -
see the thread at (look for the code in attachments):
http://www.coreboot.org/pipermail/coreboot/2009-August/051624.html
I'm don't recall why the above didn't get merged. The Geode interface
only needed to override the legacy timing parameter table and be
called during init.
I'm not sure which scheme makes the most sense. I could see using the
"cirrus" scheme - each hardware type defines its own "handle_10" and
"vga_post" in a file dedicated to that hardware, which then check for
hardware specific functions and call "library" code for the standard
stuff. However, I'm not sure how much code duplication there would be
for things like the VBE calls which seem to contain a mix of standard
info and hardware specific info.
-Kevin
Fred . wrote:
> I would like to request a wiki account so that I can contribute to
> the website.
Cool! Do you already have some specific things in mind to improve?
//Peter
