On 19.04.2010, at 14:49, Albert Herranz wrote:
>> 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.
>> pretty sure the Arm-hack doesn't work on my Wii, so I'm out of luck
> 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
> 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?