On Fri, Jan 16, 2009 at 11:40 AM, Alex Villacís Lasso <[email protected]> wrote: > Alex Deucher escribió: >> On Thu, Jan 15, 2009 at 4:53 PM, Alex Villacís Lasso >> <[email protected]> wrote: >> >>> Alex Deucher escribió: >>> >>>> On Thu, Jan 15, 2009 at 3:10 PM, Alex Villacís Lasso >>>> <[email protected]> wrote: >>>> >>>> >>>>> I am trying to enable I/O port tracing on current xserver head in my home >>>>> machine (Linux 2.6.28 on x86 Pentium 4 32-bits, ProSavageDDR-K as primary >>>>> card, Oak OTI64111 as secondary card) in order to learn about the register >>>>> initialization for the video BIOS of both the Savage and the Oak chipsets: >>>>> >>>>> * For savage, I want to eventually see the POST port accesses as they >>>>> occur >>>>> in VESA, so that the current driver can do the same port enabling on the >>>>> case of a savage as secondary card. Currently, the xorg driver can >>>>> initialize a secondary savage without BIOS (but see below for caveat), but >>>>> the colors are washed out and horrible artifacts appear on any attempt to >>>>> accelerate operations. Same issue happens with the savagefb kernel >>>>> framebuffer driver. >>>>> * For oak, I want to peek at the register initialization for mode >>>>> switching >>>>> in VESA, in order to have better understanding towards writing a driver >>>>> for >>>>> the chipset. >>>>> >>>>> >>>> http://people.freedesktop.org/~airlied/xresprobe-mjg59-0.4.21.tar.gz >>>> >>>> This will dump io accesses when you execute bios code using the >>>> included x86 emulator. >>>> >>>> Alex >>>> >>>> >>>> >>> From a quick skim over the contents of the file, I see an x86emu >>> directory. I think I have seen a directory with that name in the xserver >>> sources. Is it safe to switch to x86emu on an x86 32-bits in the xserver >>> source? Or do I have to keep in mind some special consideration? >>> >> >> We already do. the xserver uses x86emu by default now for x86. >> >> Alex >> >> > That is a bit weird. I had to explicitly enable x86emu with a configure > switch before I could get an actual port trace. Maybe I should force > vm86 back home and see what happens. Why was this change made? I would > think only non-PC architectures and x86_64 would need this. Why also on > i386?
http://lists.freedesktop.org/archives/xorg-commit/2008-December/019092.html > > From what I glean from the traces, it seems that using VESA to start up > the primary Savage chipset works correctly. However, when trying to > initialize the Oak chipset as secondary (just that one, without > reference to the primary Savage chipset), it ends up in a loop of > in(3da) = ff and hangs. Interestingly, I saw no hint that the Savage > chipset was ever moved out of the legacy VGA mapping in order to > initialize the Oak chipset via POST. Which ties back to my previous > question: what measures (if any) are supposed to be taken by the xserver > in order to hand over the legacy VGA ports to a secondary chipset that > needs access to them for POST, when run with a different chipset as > primary? As in, Savage is mapped to legacy VGA, I want to POST the Oak > chipset, which needs a mapping to the VGA ports too, so what should the > xserver do? The bridge chipset needs to route vga to the proper card. Pre-1.5 xservers used to handle this. libpciaccess does not yet AFAIK. Alex _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
