[maemo-developers] N800 in USB Host mode not detecting any devices (powered or not)

[From: Sean Cross]

On Aug 4, 2007, at 12:23 PM, Rodrigo Vivi wrote:

> On 8/3/07, Sean Cross <smcross at ucsd.edu> wrote:
>>
>> On Aug 3, 2007, at 2:06 PM, Michael Lapinski wrote:
>>> In summary the older patches give some error and dont see the hub  
>>> and
>>> the newer patches dont appear to work at all. Anyone have any  
>>> idea or
>>> suggestions? Have we missed some sort of a step in the procedure?
>>
>> I've been curious about the USB Host Mode patches myself, and have
>> been trying to get them to work for the past week.
>
> me too.
>
>> I'm running bora
>> 3.2, and I haven't heard of any reports of anyone getting it working
>> with this version yet.
>>
>> Whether I use the kernel-source-rx-34_2.6.18-osso40.diff (bora 3.1)
>> or kernel-source-rx-34_2.6.18-osso52.diff (bora 5.2) patches, I can't
>> get /sys/devices/platform/musb_hdrc/mode to report anything other
>> than b_idle.  /proc/driver/musb_hdrc also perpetually reports
>> "Peripheral" mode.  Furthermore, with these patches, the N800 no
>> longer acts as a peripheral device.  If I cat /sys/devices/platform/
>> musb_hdrc/looptest, the "mode" suddenly becomes a_wait_vrise, and
>> won't change without a reboot.
>>
>> However, I have just discovered that things suddenly start to work if
>> the N800 is connected to a desktop machine via USB when it starts
>> up.  Under these circumstances, it does respond to switching modes, I
>> can mount USB devices, I can e.g. cat /dev/input/event5 when I plug
>> in a mouse, and keyboards work.
>
> you are using the patched kernel now, aren't you?
>
> I'm using this patched kernel and I've just tried to start with N800
> connected to a desktop, but I couldn't change the state from b_idle to
> host.
> I've noticed an init error message on the looptest:
>
> cat /sys/devices/platform/musb_hdrc/looptest
> init error
>
> do you have any idea what can it be?

It /looks/ as though there are three things that can cause an "init  
error" message, though I'm not sure the first would ever cause  
anything other than a panic.  Can someone who has more kernel-hacking  
experience comment on whether this code (from tusb6010_test.c:90)  
will cause Bad Things to happen if the_musb is, in fact, NULL?


static int tusb_do_test(void)
{
         void __iomem    *base = the_musb->ctrl_base;
         void __iomem    *musb_base = the_musb->pRegs;
...
         if (the_musb == NULL)
                 return TUSB_TEST_INIT_ERROR;



The other two causes of an "init error" are logged to dmesg with an  
error level of 2.  A few months ago, Marcell Lengyel mentioned the  
following with respect to increasing debug verbosity:

 >         Could you please increase the musb driver debug level by  
doing:
 >
 >        # echo 8 > /proc/sysrq-trigger
 >        # echo D3 > /proc/driver/musb_hdrc

You should execute these commands, then try the loopback test again  
to see if any errors appear.  The two possible error causes are "ID  
down before VBUS is on", or "line(s) up after VBUS is on".  If  
neither of these shows up, then it probably is the first case, and  
the chip isn't initializing properly.

Unfortunately, I don't know much [anything] about the chip, so I  
don't know how much help I'd be in troubleshooting.  You could try a  
"make clean && make n800_defconfig && make zImage" to ensure USB is  
enabled in the config file.  I believe patch 0006 of the USB patches  
enables USB Host Mode by default in the n800_defconfig file.

Sean Cross