Proper way to enable port access tracing with current xserver

[Alex Deucher]

On Fri, Jan 16, 2009 at 11:40 AM, Alex Villací­s Lasso
<a_villacis at palosanto.com> wrote:
> Alex Deucher escribió:
>> On Thu, Jan 15, 2009 at 4:53 PM, Alex Villací­s Lasso
>> <a_villacis at palosanto.com> wrote:
>>
>>> Alex Deucher escribió:
>>>
>>>> On Thu, Jan 15, 2009 at 3:10 PM, Alex Villací­s Lasso
>>>> <a_villacis at palosanto.com> 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