kernel does not boot if USB (OTG) port is connected to host

[h...@computer.org]

Is there a known patch to solve the problem that the kernel
does not boot if a BB (I have seen no difference between BB-C4
or BB-XM) is powered through the OTG USB port (and the host is
providing an ethernet gadget service)?

Or is it at least known where to search for the problem in the
sources?

I am using the BB-XM-Validation kernel (Linux version 2.6.32)
and the boot process dies with this output:

...

[ 11.769989] Switching to clocksource 32k_counter
[ 11.779846] musb_hdrc: version 6.0, musb-dma, otg (peripheral
+host), debug=0
[ 11.780151] musb_hdrc: USB OTG mode controller at fa0ab000 using
DMA, IRQ 92
[ 11.780181] musb_hdrc musb_hdrc: MUSB HDRC host driver
[ 11.780303] musb_hdrc musb_hdrc: new USB bus registered, assigned
bus number 1
[ 11.780456] usb usb1: New USB device found, idVendor=1d6b,
idProduct=0002
[ 11.780487] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 11.780517] usb usb1: Product: MUSB HDRC host driver
[ 11.780517] usb usb1: Manufacturer: Linux 2.6.32 musb-hcd
[ 11.780548] usb usb1: SerialNumber: musb_hdrc
[ 11.781219] hub 1-0:1.0: USB hub found
[ 11.781280] hub 1-0:1.0: 1 port detected
[ 11.782470] NET: Registered protocol family 2
[ 11.782684] IP route cache hash table entries: 4096 (order: 2,
16384 bytes)
[ 11.783233] TCP established hash table entries: 16384 (order: 5,
131072 bytes)
[ 11.783660] TCP bind hash table entries: 16384 (order: 4, 65536
bytes)
[ 11.783874] TCP: Hash tables configured (established 16384 bind
16384)
...
[ 12.211212] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 12.229644] serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a
ST16654
[ 12.247375] serial8250.1: ttyS1 at MMIO 0x4806c000 (irq = 73) is a
ST16654
[ 12.265045] serial8250.2: ttyS2 at MMIO 0x49020000 (irq = 74) is a
ST16654
[ 12.832153] console [ttyS2] enabled
[ 12.843078] brd: module loaded
[ 12.849731] loop: module loaded
[ 12.854095] omap2-nand driver initializing
[ 12.858551] NAND devic

note, the "e" of "device" is already missing...
Probably some more lines are lost in the buffer of the serial line
driver so I
would NOT assume a conflict between USB and the NAND device driver.

The kernel boots fine if powered by an external supply and USB is not
connected
or when using a USB power supply.

On another attempt I got this:

[ 14.268371] Unable to handle kernel NULL pointer dereference at
virtual address 00000014
[ 14.276519] pgd = c0004000
[ 14.279235] [00000014] *pgd=00000000
[ 14.282836] Internal error: Oops: 5 [#1] PREEMPT
[ 14.287475] last sysfs file:
[ 14.290435] Modules linked in:
[ 14.293518] CPU: 0 Not tainted (2.6.32 #48)
[ 14.298095] PC is at musb_interrupt+0x1450/0x157c
[ 14.302825] LR is at musb_interrupt+0x143c/0x157c
[ 14.307525] pc : [<c034e0cc>] lr : [<c034e0b8>] psr: 60000193
[ 14.307556] sp : df825868 ip : df825868 fp : df8258b4
[ 14.319091] r10: 00000001 r9 : 00000000 r8 : 00000000
[ 14.324340] r7 : 00000000 r6 : df81f108 r5 : 00000009 r4 :
00000000
[ 14.330871] r3 : 00000000 r2 : 00000000 r1 : 00000099 r0 :
df81f108
[ 14.337432] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 14.344879] Control: 10c5387d Table: 80004019 DAC: 00000017
[ 14.350646] Process swapper (pid: 1, stack limit = 0xdf8242f0)
[ 14.356506] Stack: (0xdf825868 to 0xdf826000)

The lines:

[ 14.298095] PC is at musb_interrupt+0x1450/0x157c
[ 14.302825] LR is at musb_interrupt+0x143c/0x157c

indicate that there is a problem with the musb interrupts.

Nikolaus

[Gyorgy Szekely]

Hi,
This is known issue, you can find quite a few threads discussing the
topic. A quick workaround is to have the gadget driver (g_ether or
g_cdc) compiled in.

Regards,
Gyorgy

> --
> You received this message because you are subscribed to the Google Groups "Beagle Board" group.
> To post to this group, send email to beagl...@googlegroups.com.
> To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
>
>

[h...@computer.org]

On 20 Sep., 09:51, Gyorgy Szekely <hodito...@gmail.com> wrote:
> Hi,
> This is known issue, you can find quite a few threads discussing the
> topic.

Yes, I remember that it was dicsussed but did not remember a
solution.

> A quick workaround is to have the gadget driver (g_ether or
> g_cdc) compiled in.

Ah,
that is the missing piece.
I will give it a try.

Thanks,
Nikolaus

[h...@computer.org]

I have tried, but it does not work. On the first boot attempt it still
crashes. On a second one
(pressing the Reset button) the kernel sometimes boots. But I can't
bring up the interface.

The /e/n/i that works fine when the OTG is plugged in after boot does
show this error:

Mounting local filesystems...done.
Activating swapfile swap...done.
Setting up networking....
Configuring network interfaces...[ 28.676452] g_ether: module is
already loaded
FATAL: Error inserting g_ether (/lib/modules/2.6.32/kernel/drivers/usb/
gadget/g_ether.ko): Invalid argument
Failed to bring up usb0.
done.
Setting console screen modes and fonts.

Best regards,
Nikolaus

[Richard Andrews]

On Mon, Sep 20, 2010 at 5:51 PM, Gyorgy Szekely <hodi...@gmail.com> wrote:
> Hi,
> This is known issue, you can find quite a few threads discussing the
> topic. A quick workaround is to have the gadget driver (g_ether or
> g_cdc) compiled in.

I'm pretty sure this doesn't work any more.

For me (Angstrom 2010.7), I have to wait until booting finishes,
modprobe g_ether via RS232 and then connect the OTG cable otherwise it
crashes.

[h...@computer.org]

It appears to be the same for me. Compiling g_ether into the kernel
does not work. I have to load the module after boot is complete.

With external power supply and a rule in /e/n/i to modprobe g_ether
automatically on plug-in (pre-up modprobe g_ether / post-down rmmod
g_ether)
works fine.

So we should collect information about the crash and try to work on a
fix.
To me the problem appears to be some initialization sequence issue,
i.e.
the driver starts some interrupts or whatever before some other
component
is completely initialized.


On 21 Sep., 02:30, Richard Andrews <bflatmaj...@gmail.com> wrote: