Subject: Re: Xbox port
To: David Maxwell <>
From: None <>
List: netbsd-ports
Date: 03/21/2004 15:39:32
David Maxwell writes: 

>> The kernel works fine in general. But the Xbox needs a couple of hacks. One
>> of them is in the PCI bus. You need to avoid probbing 0:0:1 and 0:0:2, if
>> you don't, it crashes.
> Think modularly...  Why does that cause a crash? Is it something about
> the PCI HBA or Bridge? Is it a model that could have a quirk entry to
> avoid those probes? 
> If the problem is in the bridge, then the bridge driver should get the
> special case, not the whole architecture...

It is a problem in the MCPX, which is the Media and Communications Processor
for the Xbox. I do agree with what you say. But right now I am more focussed
on getting something to "work". Once I get a kernel that boots, I can seek
for the problem in a better way. I did a patch for pciconf.c that seems to
work. Check the links at the end of this email. 

>> Then the other one is a hack on the eject button for
>> the DVD drive. It reboots the Xbox if you don't apply it. 
> Likewise, That sounds like something specific to the DVD drive as wired
> into the XBOX. Then the hack can be included if that device ID is
> found...

True. But this is one of the last things I will be working on. Since it
only crashes the Xbox when you push the eject button. So far, the kernel
will still boot. My priority now is the bootloader. 

>> >Either way, you probably don't actually need (or want) #ifdef XBOX
>> >anywhere. 
>> Then how would you do it? Just create a new arch for it? If I have to
>> modify /sys/dev/pci/pciconf.c, is there a way to create changes just for
>> the Xbox and not for everything else? I thought the way to do it was to
>> create an option in the kernel config. Because just with that I can do all
>> the modifications that I need for the Xbox using #ifdef. 
> #ifdef should be a last resort that comes long after modular changes.
> Someone reading pciconf.c from an i386 perspective shouldn't need to
> skip over speacial cases for one single piece of hardware - unless it's
> clearly part of the infrastructure to check the hardware ID, and turn on
> some workaround functionality. 
> Charles Hannum has also shown that in many cases, 'quirk' workaround
> functionality was not actually required, and the driver itself was
> provoking the bad behaviour through subtle mis-applications of the
> interface specifications.

I do agree with what you say. But it is easier to debug the hardware from
the hardware itself. By this, I mean that it will be easier to do this
once after the kernel on the Xbox is working. 

> (i.e. Are you _really sure_ that probing 0:0:[12] crashes the XBOX under
> every circumstance, and not just in the state the device happens to be
> in at that point in the current version of the driver?)

I am _really sure_ that probing 0:0:[12] crashes the Xbox under every
circumstance. It is a flaw in the MCPX, as I mentioned before. I created
some output from Linux so that you can check the PCI status. 

First, the dmesg... 

Then pcils 

Finally pcils "verbose" 

And this is the dmesg from my NetBSD i386 machine running
kernel+ramdisk+pci_patch with all the PCI verbose enabled in the kernel. 

Hope this helps,