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...
http://www.cs.pitt.edu/~nib1/dmesg-linux.txt 

Then pcils
http://www.cs.pitt.edu/~nib1/pci.txt 

Finally pcils "verbose"
http://www.cs.pitt.edu/~nib1/pci-verbose.txt 

And this is the dmesg from my NetBSD i386 machine running
kernel+ramdisk+pci_patch with all the PCI verbose enabled in the kernel.
http://www.cs.pitt.edu/~nib1/dmesg.txt 


Hope this helps,
Nicolas.