Subject: Re: Xbox port
To: None <openbsd@softhome.net>
From: David Maxwell <david@vex.net>
List: netbsd-ports
Date: 03/19/2004 16:47:29
On Thu, 18 Mar 2004, openbsd@softhome.net wrote:
> David Maxwell writes:
> >The rule of thumb question is: "Can you build a kernel that will boot on
> >an XBOX and also on a non-XBOX i386?"
> >
> >If you can, without doing something really ugly, then XBOX is a kernel
> >config in arch i386.
> >
> >If you can't, then XBOX should be its own arch.
>
> 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...
> 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...
> >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.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?)
--
David Maxwell, david@vex.net|david@maxwell.net --> Unless you have a solution
when you tell them things like that, most people collapse into a gibbering,
unthinking mass. This is the same reason why you probably don't tell your
boss about everything you read on BugTraq! - Signal 11