Xbox Linux Kernel Patches Questions

Xbox Linux Kernel Patches Questions

[Michael Steil]

Hi!

I am Michael Steil from the Xbox Linux Project. As you might already 
know, we successfully run standard distributions on ("modded") 
Microsoft Xbox gaming consoles with only minimal kernel changes.

Our question is now what way our patches will have to be in order to 
have a chance for them to be accepted into the main kernel tree. I'll 
tell you a bit about our kernel changes first:

1) PCI chipset bugfix
The Xbox chipset has a PCI bug that makes the system hang when reading 
from 00:00.2 or 00:00.3 in the PCI configuration space. We have added a 
check that ignores these devices, embraced by #ifdef CONFIG_XBOX in 
drivers/pci/pci.c

2) System timer fix
The system timer runs about 6% faster than on a PC. We have added a 
#ifdef CONFIG_XBOX section to include/asm-i386/timex.h

3) Shutdown/Reboot
The Xbox doesn't support standardized APM to shut down and doesn't have 
a keyboard controller to reset the system. We have added code to shut 
down and reboot the Xbox in arch/i386/kernel/process.c.

4) No keyboard controller
There already seems to be a patch available that doesn't print 100 
warnings and allocate IRQ1 for the keyboard if there is no keyboard 
controller present and we add the command line parameter "kbd-reset". 
This patch is in 2.4.19-16mdk, but not in plain vanilla 2.4.19. Without 
this patch, we have an interrupt conflict on IRQ1.

There are some more drivers we're working on at the moment:

1) FATX driver
The Xbox uses a derivative of the MS-DOS FAT filesystem, but it's a lot 
simplified and completely legacy-free. Though, the file allocation 
table structure and the basic ideas of directory entries remain the 
same. We have done small changes to fs/fat/* and added a directory 
fs/fatx.

2) Xpad & remote control drivers
The Xpad (Xbox gamepad) driver module is already available in your 
latest development kernel, we can soon add additional or updated 
drivers for Xbox-specific (USB) hardware.

So these are our questions now:

Do we have a chance for our kernel fixes for the Xbox to be included 
into the standard kernel? All our changes are tiny and #ifdef 
CONFIG_XBOX and change nothing on a i386 PC or on any other 
architecture.

Would it be better to have a runtime check at kernel initialization to 
detect the Xbox and put all Xbox specific code between if (xbox) {}?

Can our FATX driver be accepted into the main kernel? It has been 
impossible to implement FATX on top of FAT without making the FATX code 
a bit more general. We hope that it wasn't too many changes there. By 
the way, FATX doesn't only make sense on the Xbox, it's a multi-purpose 
filesystem that might also be used for other applications, because of 
it's simplicity and its small kernel footprint. (Please note that our 
FATX code is still in beta).

Can our additional drivers be added to the standard kernel once they 
are finished?

Our project website is at http://xbox-linux.sourceforge.net/, we have 
our kernel changes in the CVS if you want to have a look at it. I 
didn't want to send a patch in this mail already, because we might have 
to discuss what way to do our patches first (especially on #ifdef 
CONFIG_XBOX vs. if (xbox) {}).

Thanks a lot for your time.

   Michael

Re: Xbox Linux Kernel Patches Questions

[Greg KH]

On Thu, Oct 10, 2002 at 10:13:56PM +0200, Michael Steil wrote:
> 
> 2) Xpad & remote control drivers
> The Xpad (Xbox gamepad) driver module is already available in your 
> latest development kernel, we can soon add additional or updated 
> drivers for Xbox-specific (USB) hardware.

I'll gladly look over any USB drivers or changes.  Feel free to send
them to the linux-usb-devel list when you feel they are ready to be
added to the tree.

thanks,

greg k-h

Re: Xbox Linux Kernel Patches Questions

[Alan Cox]

> The Xbox chipset has a PCI bug that makes the system hang when reading 
> from 00:00.2 or 00:00.3 in the PCI configuration space. We have added a 
> check that ignores these devices, embraced by #ifdef CONFIG_XBOX in 
> drivers/pci/pci.c

Can you tell the xbox by the subsystem id on the root bridges ?

> 2) System timer fix
> The system timer runs about 6% faster than on a PC. We have added a 
> #ifdef CONFIG_XBOX section to include/asm-i386/timex.h

It isnt actually alone in that - 2.5 probably makes that pretty easy to
accomodate. We have subtrees for x86 variants as a patch set now and used
for the voyager platform. The newer IBM and certain other vendor "big x86"
boxes are pretty weird probably weirder than X-box 8)

> 3) Shutdown/Reboot
> The Xbox doesn't support standardized APM to shut down and doesn't have 
> a keyboard controller to reset the system. We have added code to shut 
> down and reboot the Xbox in arch/i386/kernel/process.c.

Ok. Thats true of some embedded x86 too

> 4) No keyboard controller
> There already seems to be a patch available that doesn't print 100 
> warnings and allocate IRQ1 for the keyboard if there is no keyboard 
> controller present and we add the command line parameter "kbd-reset". 
> This patch is in 2.4.19-16mdk, but not in plain vanilla 2.4.19. Without 
> this patch, we have an interrupt conflict on IRQ1.

The latest code has a kbd_present function. That lets you add the logic
you need.

> Do we have a chance for our kernel fixes for the Xbox to be included 
> into the standard kernel? All our changes are tiny and #ifdef 
> CONFIG_XBOX and change nothing on a i386 PC or on any other 
> architecture.

Probably. I suspect the primary questions are political/lawyer ones rather than
technical ones. Things like the IDE drive password are touchy obviously
but that can be done from an initrd loaded with the kernel I guess.

> Would it be better to have a runtime check at kernel initialization to 
> detect the Xbox and put all Xbox specific code between if (xbox) {}?

IMHO yes. 

> the way, FATX doesn't only make sense on the Xbox, it's a multi-purpose 
> filesystem that might also be used for other applications, because of 
> it's simplicity and its small kernel footprint. (Please note that our 
> FATX code is still in beta).
> 
> Can our additional drivers be added to the standard kernel once they 
> are finished?

Yes - you should probably aim at 2.5 for merging rather than 2.4 however, 
especially for things like the FATX file system work.

Re: Xbox Linux Kernel Patches Questions

[Michael Steil]

> Can you tell the xbox by the subsystem id on the root bridges ?

Yes, these are unique.

>> Do we have a chance for our kernel fixes for the Xbox to be included
>> into the standard kernel? All our changes are tiny and #ifdef
>> CONFIG_XBOX and change nothing on a i386 PC or on any other
>> architecture.
>
> Probably. I suspect the primary questions are political/lawyer ones 
> rather than
> technical ones. Things like the IDE drive password are touchy obviously
> but that can be done from an initrd loaded with the kernel I guess.

Yes, we have already moved the IDE unlock code into the bootloader and 
it won't be needed in the kernel for most systems, so it won't have to 
be included into the main kernel. All other changes shouldn't be 
(politically/legally) problematic in any way.

>> Would it be better to have a runtime check at kernel initialization to
>> detect the Xbox and put all Xbox specific code between if (xbox) {}?
>
> IMHO yes.

So all all Xbox specific code would look like this:
#ifdef CONFIG_XBOX_SUPPORT
if (xbox) {
	...
}
#endif

Where would we put out Xbox detection code? If it detects the Xbox as 
described above, CONFIG_XBOX_SUPPORT will depend on CONFIG_PCI.

   Michael

Re: Xbox Linux Kernel Patches Questions

[Alan Cox]

On Thu, 2002-10-10 at 22:35, Michael Steil wrote:
> > Can you tell the xbox by the subsystem id on the root bridges ?
> 
> Yes, these are unique.

> Where would we put out Xbox detection code? If it detects the Xbox as 
> described above, CONFIG_XBOX_SUPPORT will depend on CONFIG_PCI.

Which seems fair enough. ISA bus X-box systems are suprisingly rare