From: Alexander G. <ag...@su...> - 2010-04-19 04:07:43
|
Howdy, After spending several hours trying to merge the gc-linux master branch into my KVM branch, I finally got a kernel that boots and runs seemingly well. Unfortunately, I can not use my USB keyboard. Is there any know bugs when using the IOS USB support? I certainly remember that the keyboard did work with one random older binary blob kernel I got from somewhere on the wii - and that was 100% running on IOS. I've also stumbled over the SI keyboard. How exactly does that work? Alex |
From: Albert H. <alb...@ya...> - 2010-04-19 06:34:18
|
> Howdy, Hi, >After spending several hours trying to merge the gc-linux master > branch into my KVM branch, I finally got a kernel that boots and runs seemingly > well. Unfortunately, I can not use my USB keyboard. > >Is there any know > bugs when using the IOS USB support? I certainly remember that the keyboard did > work with one random older binary blob kernel I got from somewhere on the wii - > and that was 100% running on IOS. > Running under IOS has a few limitations regarding USB hubs (hot plug of devices into hubs doesn't work) and configuration descriptor parsing. Also, the USB stack is limited in this case to USB 1.x mode. Other than that I'm not aware of any other bugs for the IOS-based kernel USB support. I'd make sure that your specific USB keyboard support is enabled on your kernel configuration. The default configuration does not enable all possible USB HID devices. >I've also stumbled over the SI > keyboard. How exactly does that > work? That's a driver for a special keyboard (and some adapter clones) designed to play Phantasy Star Online. The keyboard (or the keyboard adapter) plugs directly on a gamepad controller port. Cheers, Albert PS: Note that IOS-based kernels are now deprecated. "Active" development is currently only done on MINI-based kernels. |
From: Alexander G. <ag...@su...> - 2010-04-19 11:49:21
|
On 19.04.2010, at 08:34, Albert Herranz wrote: >> Howdy, > > Hi, > >> After spending several hours trying to merge the gc-linux master >> branch into my KVM branch, I finally got a kernel that boots and runs seemingly >> well. Unfortunately, I can not use my USB keyboard. >> >> Is there any know >> bugs when using the IOS USB support? I certainly remember that the keyboard did >> work with one random older binary blob kernel I got from somewhere on the wii - >> and that was 100% running on IOS. >> > > Running under IOS has a few limitations regarding USB hubs (hot plug of devices into hubs doesn't work) and configuration descriptor parsing. Also, the USB stack is limited in this case to USB 1.x mode. > Other than that I'm not aware of any other bugs for the IOS-based kernel USB support. > > I'd make sure that your specific USB keyboard support is enabled on your kernel configuration. > The default configuration does not enable all possible USB HID devices. It's just a generic HID device. Just to be sure I went to the list of all USB HID devices and activated everything - no luck. I wonder what's going wrong there. The enumeration does work, the device gets detected and even added as a HID device to the system. Just pressing keys doesn't help. Weird. > >> I've also stumbled over the SI >> keyboard. How exactly does that >> work? > > > That's a driver for a special keyboard (and some adapter clones) designed to play Phantasy Star Online. > The keyboard (or the keyboard adapter) plugs directly on a gamepad controller port. Oh, nice. Maybe I'll just get one of those and not care about that USB keyboard. > > Cheers, > Albert > > PS: Note that IOS-based kernels are now deprecated. "Active" development is currently only done on MINI-based kernels. I'm pretty sure the Arm-hack doesn't work on my Wii, so I'm out of luck there. Why exactly is that a requirement anyways? IIRC there's a way to give full access to all device's MMIO regions to the PPC. Alex |
From: Albert H. <alb...@ya...> - 2010-04-19 12:49:37
|
Hi, >It's > just a generic HID device. Just to be sure I went to the list of all USB HID > devices and activated everything - no luck. I wonder what's going wrong there. > The enumeration does work, the device gets detected and even added as a HID > device to the system. Just pressing keys doesn't help. Weird. Yeah, weird. Maybe we can find something if you post the dmesg output of the relevant USB-related messages when plugging the keyboard on a gc-linux kernel and the same for a "normal" linux kernel where the device works. >Oh, nice. Maybe I'll just get one of those and > not care about that USB keyboard. It may be simpler to switch to another USB keyboard if that _really_ doesn't work. All keyboards I have tested so far do work... >I'm > pretty sure the Arm-hack doesn't work on my Wii, so I'm out of luck > there. AFAIK, you can always run MINI via BootMii as IOS as opposed to BootMii as Boot2. >Why exactly is that a requirement anyways? IIRC there's a way to > give full access to all device's MMIO regions to the > PPC. When I refer to a MINI-based kernel, I'm actually talking about a kernel handling all devices in the PPC side, directly accessing registers via MMIO. The MINI IPC mechanism is not used anymore since the AHBPROT register was discovered, but we keep the MINI-kernel name to avoid even more naming confussion/mess. (In any case, the kernel is booted by MINI in the MINI-based kernel). Cheers, Albert |
From: Alexander G. <ag...@su...> - 2010-04-19 13:20:23
|
On 19.04.2010, at 14:49, Albert Herranz wrote: > Hi, > >> It's >> just a generic HID device. Just to be sure I went to the list of all USB HID >> devices and activated everything - no luck. I wonder what's going wrong there. >> The enumeration does work, the device gets detected and even added as a HID >> device to the system. Just pressing keys doesn't help. Weird. > > > Yeah, weird. > Maybe we can find something if you post the dmesg output of the relevant USB-related messages when plugging the keyboard on a gc-linux kernel and the same for a "normal" linux kernel where the device works. Yikes. Call me stupid. The battery was depleted :). > >> Oh, nice. Maybe I'll just get one of those and >> not care about that USB keyboard. > > > It may be simpler to switch to another USB keyboard if that _really_ doesn't work. > All keyboards I have tested so far do work... Too late - I'll need one for the GC anyways. > >> I'm >> pretty sure the Arm-hack doesn't work on my Wii, so I'm out of luck >> there. > > > AFAIK, you can always run MINI via BootMii as IOS as opposed to BootMii as Boot2. Hrm, alright. I'll give that a try. > >> Why exactly is that a requirement anyways? IIRC there's a way to >> give full access to all device's MMIO regions to the >> PPC. > > When I refer to a MINI-based kernel, I'm actually talking about a kernel handling all devices in the PPC side, directly accessing registers via MMIO. > The MINI IPC mechanism is not used anymore since the AHBPROT register was discovered, but we keep the MINI-kernel name to avoid even more naming confussion/mess. (In any case, the kernel is booted by MINI in the MINI-based kernel). Does that register have to be flipped from the Arm side or can the PPC side do it? If it's available on the PPC, why not put the flipping in the early boot code and not require mini at all? Alex |
From: Albert H. <alb...@ya...> - 2010-04-19 13:29:25
|
Hi, >Does that > register have to be flipped from the Arm side or can the PPC side do it? If it's > available on the PPC, why not put the flipping in the early boot code and not > require mini at > all? As you guessed, that register needs to be set from the ARM side. Cheers, Albert |
From: Alexander G. <ag...@su...> - 2010-04-19 14:52:00
|
On 19.04.2010, at 15:29, Albert Herranz wrote: > Hi, > >> Does that >> register have to be flipped from the Arm side or can the PPC side do it? If it's >> available on the PPC, why not put the flipping in the early boot code and not >> require mini at >> all? > > As you guessed, that register needs to be set from the ARM side. I see. That explains why. So the next thing I stumbled over is ehci support. As I said earlier I merged your gc-linux changes into kvm.git which is pretty close to tip. Apparently I'm getting a DSI in the interrupt handling code now. Basically there are two questions arising from this: 1) Is there an easy way to debug such things? I'm having a hard time reading from a TV screen, the contents scroll out, copy&paste doesn't work, etc. Netconsole isn't an option I guess because wifi doesn't play well with it. So what is left to get dumps? 2) Would you mind rebasing your master to something more current :-). Alex |
From: Albert H. <alb...@ya...> - 2010-04-19 19:35:17
|
>So the next thing I > stumbled over is ehci support. As I said earlier I merged your gc-linux changes > into kvm.git which is pretty close to tip. Apparently I'm getting a DSI in the > interrupt handling code now. > Obviously your fault :-P >Basically there are two questions arising > from this: > >1) Is there an easy way to debug such things? I'm having a > hard time reading from a TV screen, the contents scroll out, copy&paste > doesn't work, etc. Netconsole isn't an option I guess because wifi doesn't play > well with it. So what is left to get dumps? > The easiest way to debug stuff is to use an "usbgecko". It's an adapter that plugs into a memory card slot of the gamecube/wii on one side and a USB port on your PC on the other side. It provides a USB serial connection on the PC and a simple SPI interface on the gamecube/wii which allows to send/receive data to the PC. >2) Would you mind rebasing > your master to something more current > :-). I decided to mainline code instead of continuing development out of tree. See www.gc-linux.org/wiki/Mainline_Kernel for a current status of what's already in. But, as mainlining is taking more time than I expected (for example, I'm stuck waiting for some USB and swiotlb core changes that the EHCI driver patches for mainline depends on) I may eventually integrate as-is the old MIKE series into a mainline-based branch. While doing that, I'll get rid of all IOS-based support which I don't plan to support on the mainline kernel. Cheers, Albert |
From: Alexander G. <ag...@su...> - 2010-04-19 21:53:39
|
On 19.04.2010, at 21:35, Albert Herranz wrote: >> So the next thing I >> stumbled over is ehci support. As I said earlier I merged your gc-linux changes >> into kvm.git which is pretty close to tip. Apparently I'm getting a DSI in the >> interrupt handling code now. >> > > Obviously your fault :-P Obviously :). I'd actually guess at interface changes between 2.6.32 and 2.6.34. > >> Basically there are two questions arising >> from this: >> >> 1) Is there an easy way to debug such things? I'm having a >> hard time reading from a TV screen, the contents scroll out, copy&paste >> doesn't work, etc. Netconsole isn't an option I guess because wifi doesn't play >> well with it. So what is left to get dumps? >> > > The easiest way to debug stuff is to use an "usbgecko". > It's an adapter that plugs into a memory card slot of the gamecube/wii on one side and a USB port on your PC on the other side. It provides a USB serial connection on the PC and a simple SPI interface on the gamecube/wii which allows to send/receive data to the PC. Phew - sounds like me "need to buy" list is getting bigger and bigger :). > >> 2) Would you mind rebasing >> your master to something more current >> :-). > > > I decided to mainline code instead of continuing development out of tree. > See www.gc-linux.org/wiki/Mainline_Kernel for a current status of what's already in. Yeah, but that feature set is certainly not enough to actually do something with the Wii :-). > But, as mainlining is taking more time than I expected (for example, I'm stuck waiting for some USB and swiotlb core changes that the EHCI driver patches for mainline depends on) I may eventually integrate as-is the old MIKE series into a mainline-based branch. While doing that, I'll get rid of all IOS-based support which I don't plan to support on the mainline kernel. Makes sense. I was merely stating that I'd love to have your "master" tree be synced to what's upstream now. There are a lot of conflicts between your tree that actually has all the drivers and tip. Btw - I have more odd USB results: I figured I'd move my root fs from the SD card to a USB drive to speed up things a bit. Hence the try with EHCI. So I went back to OHCI and can't seem to get any USB HDs working as is. As soon as the partition table should be read out I run into a timeout and the HCI driver just sends a reset after n seconds. The fun thing is that as soon as I also plug in my USB keyboard, everything works fine in OHCI mode. I can use the hard drive just fine. This is all on the MINI based system. Can you reproduce this on your system too? Alex |
From: Albert H. <alb...@ya...> - 2010-04-21 20:50:27
|
>Btw - I have more odd USB results: > >I figured I'd move my > root fs from the SD card to a USB drive to speed up things a bit. Hence the try > with EHCI. So I went back to OHCI and can't seem to get any USB HDs working as > is. As soon as the partition table should be read out I run into a timeout and > the HCI driver just sends a reset after n seconds. > >The fun thing is that > as soon as I also plug in my USB keyboard, everything works fine in OHCI mode. I > can use the hard drive just fine. This is all on the MINI based > system. > >Can you reproduce this on your system > too? I haven't tried that exact scenario. But I can tell you that the OHCI controllers in the Wii are buggy. The first symptom you see when you use the pristine OHCI support in Linux is that the controller completes the first control transfer but "ignores" all transfers after that one. I implemented the mother of all ugliest workarounds (attempting a dummy TD transfer to a control ED after each transfer) and that seemed to keep the controller happy and working, but I've received reports on the irc channel that still there are problems (like disconnection of mass storage devices after hours of operation). I haven't yet managed to figure out what's the real cause of the OHCI issues. Something fishy is going on with the OHCI hardware. On the other hand EHCI is fine. Cheers, Albert |
From: Alexander G. <ag...@su...> - 2010-04-21 20:57:03
|
On 21.04.2010, at 22:50, Albert Herranz wrote: >> Btw - I have more odd USB results: >> >> I figured I'd move my >> root fs from the SD card to a USB drive to speed up things a bit. Hence the try >> with EHCI. So I went back to OHCI and can't seem to get any USB HDs working as >> is. As soon as the partition table should be read out I run into a timeout and >> the HCI driver just sends a reset after n seconds. >> >> The fun thing is that >> as soon as I also plug in my USB keyboard, everything works fine in OHCI mode. I >> can use the hard drive just fine. This is all on the MINI based >> system. >> >> Can you reproduce this on your system >> too? > > > I haven't tried that exact scenario. > > But I can tell you that the OHCI controllers in the Wii are buggy. The first symptom you see when you use the pristine OHCI support in Linux is that the controller completes the first control transfer but "ignores" all transfers after that one. > I implemented the mother of all ugliest workarounds (attempting a dummy TD transfer to a control ED after each transfer) and that seemed to keep the controller happy and working, but I've received reports on the irc channel that still there are problems (like disconnection of mass storage devices after hours of operation). > > I haven't yet managed to figure out what's the real cause of the OHCI issues. Something fishy is going on with the OHCI hardware. > On the other hand EHCI is fine. So I guess I should just use EHCI then. Would you mind to take a few minutes to get your master branch rebased against the current tip? :-) KVM works just fine on the Wii btw - I booted a VM perfectly fine. The major issue was swapping being seriously slow though, as the swap was on OHCI. Alex |
From: Albert H. <alb...@ya...> - 2010-04-21 21:26:43
|
> Would you mind > to take a few minutes to get your master branch rebased against the current tip? > :-) The MIKE series and mainline both now include gamecube and wii support, but they are now different code bases (mainline uses a different device tree and includes all changes resulting from the mainline review process of the merged parts). Instead of simply rebasing, my plan is to add back all non-IOS driver stuff to a mainline-based branch as I said. I just need to get back to development and have a name for the new branch series :) > KVM works just fine on the Wii btw - I booted a VM perfectly fine. > The major issue was swapping being seriously slow though, as the swap was on > OHCI. Nice :) Cheers, Albert |
From: Alexander G. <ag...@su...> - 2010-04-21 21:36:16
|
On 21.04.2010, at 23:26, Albert Herranz wrote: >> Would you mind >> to take a few minutes to get your master branch rebased against the current tip? >> :-) > > > The MIKE series and mainline both now include gamecube and wii support, but they are now different code bases (mainline uses a different device tree and includes all changes resulting from the mainline review process of the merged parts). > Instead of simply rebasing, my plan is to add back all non-IOS driver stuff to a mainline-based branch as I said. > > I just need to get back to development and have a name for the new branch series :) Yes, please! That would be awesome. Any idea on how long it'd take you to do that? Anything I can do to help? Alex |
From: Albert H. <alb...@ya...> - 2010-04-22 15:38:24
|
>> I just need to get back to >> development and have a name for the new branch series :) > > Yes, please! > That would be awesome. Any idea on how long it'd take you to do that? Anything I > can do to > help? I probably will give it a go during the weekend. If you have a list of drivers that you'd like to have ready first, just tell. Thanks, Albert |
From: Alexander G. <ag...@su...> - 2010-04-22 15:43:33
|
Albert Herranz wrote: >>> I just need to get back to >>> development and have a name for the new branch series :) >>> >> Yes, please! >> That would be awesome. Any idea on how long it'd take you to do that? Anything I >> can do to >> help? >> > > I probably will give it a go during the weekend. > If you have a list of drivers that you'd like to have ready first, just tell. > Oh thanks a lot! I'm mostly interested in EHCI, wifi and the frame buffer. But then again I'll be leaving for 2 weeks of vacation on Saturday, so it's not really urgent anymore :). I'll get back to things after that hopefully. Thanks again, Alex |