Proper way to enable port access tracing with current xserver

[Alex Villací­s Lasso]

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?

 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?

-- 
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'