I've just built Angstrom from org.openembedded.dev after a recent git
pull and this kernel has multiple problems for me.
I hope this is the right forum.
Here's what I now see:
* Always get kernel oops or panic when connecting USB OTG after boot
(or during boot).
* Cannot boot with USB OTG connected
* If ever the kernel boots with USB OTG connected, it is unusable
(g_ether does not create an interface at the host PC).
X-loader is 1.4.4ss (via USER button) and 1.4.2 in NAND (which no longer works).
Is there a branch or recipe I can use with openembedded to build
something with a recent (ie. 2.6.34 or 2.6.35-rc) kernel that is known
to work?
The 2.6.32 kernel is the only known working recent kernel that supports the beagleboard features (usb, dsp, video, sgx, etc).
I just tried OTG and it seems to detects my mouse just fine (rev B6, C3, C4 and xM).
Is there a branch or recipe I can use with openembedded to build
something with a recent (ie. 2.6.34 or 2.6.35-rc) kernel that is known
to work?
The 2.6.32 kernel is the only known working recent kernel that supports the beagleboard features (usb, dsp, video, sgx, etc).
I don't need half of these, only USB networking and sound. So far all
my builds have managed to have one working or the other.
I was under the impression from recent discussions on this list that
2.6.35-rc in linus' tree has beagleboard support in the vanilla
kernel.
I just tried OTG and it seems to detects my mouse just fine (rev B6, C3, C4 and xM).
Sounds like you're testing host mode. To me OTG means the beagleboard
is the gadget, ie. USB cable to a host PC - and in my case usb0
networking via g_ether.
Is there a branch or recipe I can use with openembedded to build
something with a recent (ie. 2.6.34 or 2.6.35-rc) kernel that is known
to work?
The 2.6.32 kernel is the only known working recent kernel that supports the beagleboard features (usb, dsp, video, sgx, etc).
I don't need half of these, only USB networking and sound. So far all
my builds have managed to have one working or the other.
I was under the impression from recent discussions on this list that
2.6.35-rc in linus' tree has beagleboard support in the vanilla
kernel.
Since i said it, i better chime in and clarify.. 
The 2.6.35-rc mainline has all the basic support the average person
would require. It's when you start requiring dsp (well dspbridge is
in staging for 2.6.36), sgx, or zippy support you'll need external
patches. Also the 2.6.32 in angstrom is well tested and patched
beyond the original 2.6.32 for good TI support..
OK thanks for clarifying. This sounds like it's probably enough for me
at this stage.
There's a particular patch I'm looking for which adds audio capture
gain controls to twl4030.c. The patched 2.6.32 on org.openembedded.dev
for Angstrom 2010.7 seems to have the code I'm looking for but for me
that kernel is broken. The patch is also on 2.6.35.
Where can I learn to build a beagleboard image (at least kernel uImage
+ modules) for a kernel of my choice?
That's Nokia dspbridge, not TI dspridge. The de-camelcasing changed the api of course....
At least dsplink has active support for community usage, there's multiple people improving OE and hence angstrom support for it.
regards,
Koen
Getting back to my problem. Does beagleboard work as a USB gadget for
you on .dev?
Getting back to my problem. Does beagleboard work as a USB gadget for
you on .dev?
It does, I do:
root@beagleboard.local: ~ #usb-gadget networking
# plug in cable
And on the beagle and the host usb0 appears.
I did however notice that plugging a device cable with no module loaded will cause a lockup, so if you want to use it as usb device you have a few options:
1) edit /etc/default/usb-gadget to say "networking" or an other function you want to use and plug in the cable after boot
2) rebuild kernel with your favorite gadget built-in
3) fix role switching patch
3) would be the preferred option, but I don't know of anyone brave enough to attempt that, getting the patch written took some arm-twisting already. If you don't mind plugging cables, try 1), otherwise try 2).
regards,
Koen
Hmmm. OK.
Given that USB OTG cable is the power source for my project this might
be a major issue for me.
I'll see if this config allows the device to boot with the USB
conneted to the host. Sounds fragile.
For usb powered operation you'll need to turn on cpuidle as well. If you build it with OE you'll get 2 uimages, one without cpuidle and one with:
koen@dominion:/OE/angstrom-dev/deploy/glibc$ ls images/beagleboard/ | grep uImage-2
uImage-2.6.32-r83+gitra6bad4464f985fdd3bed72e1b82dcbfc004d7869-beagleboard.bin
uImage-2.6.32-r83+gitra6bad4464f985fdd3bed72e1b82dcbfc004d7869-beagleboard.multi-config-cpuidle.bin
regards,
Koen
Thanks for telling me about that. I noticed it appeared in the last week or so.
It also bears the name multi-config. What is that part of the name about?
Getting back to my problem. Does beagleboard work as a USB gadget for
you on .dev?
It does, I do:
root@beagleboard.local: ~ #usb-gadget networking
# plug in cable
And on the beagle and the host usb0 appears.
This does NOT work for me (rev C4). The kernel throws an oops and
panics on a NULL pointer (virtual address varies).
How can I get the same version of kernel code you have?
Here's the oops output I get. Where should I send it?
...
[ 38.842346] Bluetooth: RFCOMM TTY layer initialized
[ 38.847442] Bluetooth: RFCOMM socket layer initialized
[ 38.852630] Bluetooth: RFCOMM ver 1.11
[ 43.606048] NET: Registered protocol family 10
.-------.
> .-.
> >-----.-----.-----.| | .----..-----.-----.
> > __ | ---'| '--.| .-'| | |
> > > > >--- || --'| | | ' | | | |
'---'---'--'--'--. |-----''----''--' '-----'-'-'-'
-' |
'---'
The Angstrom Distribution beagleboard ttyS2
Angstrom 2010.7-test-20100626 beagleboard ttyS2
beagleboard login: root
root@beagleboard:~# usb-gadget networking
root@beagleboard:~# lsmod
Module Size Used by
ipv6 249063 8
rfcomm 33488 0
hidp 11193 0
l2cap 30104 4 rfcomm,hidp
bluetooth 49221 3 rfcomm,hidp,l2cap
rfkill 14838 1 bluetooth
rtc_twl 4451 0
rtc_core 12535 1 rtc_twl
mailbox_mach 4183 0
mailbox 3593 1 mailbox_mach
root@beagleboard:~# [ 95.086273] Unable to handle kernel NULL
pointer dereference at virtual address 00000014
[ 95.103057] pgd = c0004000
[ 95.110046] [00000014] *pgd=00000000
[ 95.117950] Internal error: Oops: 17 [#1] PREEMPT
[ 95.127044] last sysfs file: /sys/kernel/uevent_seqnum
[ 95.136657] Modules linked in: ipv6 rfcomm hidp l2cap bluetooth
rfkill rtc_twl rtc_core mailbox_mach mailbox
[ 95.156127] CPU: 0 Not tainted (2.6.32 #2)
[ 95.165252] PC is at musb_interrupt+0x9f8/0xbb8
[ 95.174377] LR is at musb_interrupt+0x9e4/0xbb8
[ 95.183288] pc : [<c033c634>] lr : [<c033c620>] psr: 60000193
[ 95.183319] sp : c061fee0 ip : c061ff18 fp : 000000f0
[ 95.203704] r10: 00000000 r9 : 00000099 r8 : 00000009
[ 95.213317] r7 : 00000000 r6 : cf82f108 r5 : 00000001 r4 : 00000000
[ 95.224273] r3 : 00000000 r2 : 00000000 r1 : fa0ab000 r0 : cf82f108
[ 95.235321] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 95.252166] Control: 10c5387d Table: 8fb5c019 DAC: 00000017
[ 95.262847] Process swapper (pid: 0, stack limit = 0xc061e2f0)
[ 95.273651] Stack: (0xc061fee0 to 0xc0620000)
[ 95.283050] fee0: 00000000 ffff92cb 00000000 00773594 c061e000
cf82f108 60000113 cf8a0940
[ 95.301544] ff00: c061e000 0000005c 00000000 00000000 c0665a00
c033c858 c061ff48 cf8a0940
[ 95.320861] ff20: c06330a0 c00a306c 00000000 cf8a0940 c06330a0
0000005c 00000002 00000001
[ 95.340728] ff40: c061e000 0000001f 00000000 c00a5164 0000005c
00000000 c0621e84 c003b074
[ 95.361083] ff60: 00000001 ffffffff fa200000 c003bb44 00000000
80000013 80000013 00000000
[ 95.381561] ff80: c061e000 c0621fe0 c0621e84 c0669a0c 8002eefc
411fc083 0000001f 00000000
[ 95.402496] ffa0: c0631090 c061ffbc c004b93c c004c194 60000013
ffffffff 00000000 c003cfa4
[ 95.423980] ffc0: 00000000 c06b0ae0 c06699d0 c0031010 c0621e78
c0008984 c0008498 00000000
[ 95.445617] ffe0: 00000000 c0031010 10c53c7d c0669a60 c0031414
80008034 00000000 00000000
[ 95.467559] [<c033c634>] (musb_interrupt+0x9f8/0xbb8) from
[<c033c858>] (generic_interrupt+0x64/0x98)
[ 95.491333] [<c033c858>] (generic_interrupt+0x64/0x98) from
[<c00a306c>] (handle_IRQ_event+0xac/0x1ec)
[ 95.515563] [<c00a306c>] (handle_IRQ_event+0xac/0x1ec) from
[<c00a5164>] (handle_level_irq+0xbc/0x148)
[ 95.540374] [<c00a5164>] (handle_level_irq+0xbc/0x148) from
[<c003b074>] (asm_do_IRQ+0x74/0x98)
[ 95.564819] [<c003b074>] (asm_do_IRQ+0x74/0x98) from [<c003bb44>]
(__irq_svc+0x44/0xa8)
[ 95.588775] Exception stack(0xc061ff70 to 0xc061ffb8)
[ 95.601898] ff60: 00000000
80000013 80000013 00000000
[ 95.626037] ff80: c061e000 c0621fe0 c0621e84 c0669a0c 8002eefc
411fc083 0000001f 00000000
[ 95.650054] ffa0: c0631090 c061ffbc c004b93c c004c194 60000013 ffffffff
[ 95.664703] [<c003bb44>] (__irq_svc+0x44/0xa8) from [<c004c194>]
(omap3_pm_idle+0x4c/0x50)
[ 95.688720] [<c004c194>] (omap3_pm_idle+0x4c/0x50) from [<00000000>] (0x0)
[ 95.703613] Code: e3530003 13a02000 05963078 05933018 (05d33014)
[ 95.717742] ---[ end trace 6cb1213fe192ee8d ]---
[ 95.730224] Kernel panic - not syncing: Fatal exception in interrupt
Thanks for telling me about that. I noticed it appeared in the last week or so.
It also bears the name multi-config. What is that part of the name about?
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/multi-kernel.inc
That doesn't show any gadged loaded (g_*), did dmesg have any clues why it failed?
As for having the same code, I build all my rootfses with narcissus.
regards,
Koen
That doesn't show any gadged loaded (g_*), did dmesg have any clues why it failed?
How do I get dmesg out of a dead kernel?
As for having the same code, I build all my rootfses with narcissus.
... and kernels?
Can I replicate the OE recipe version Narcissus uses?
I rebooted and forced modprobe g_ether after usb-gadget networking. It
does not oops under that condition.
But alsamixer still shows no capture gain control.
*sigh*
That doesn't show any gadged loaded (g_*), did dmesg have any clues why it failed?
How do I get dmesg out of a dead kernel?
As for having the same code, I build all my rootfses with narcissus.
... and kernels?
The kernel is in /boot of the rootfs
Can I replicate the OE recipe version Narcissus uses?
Go to the angstrom website, reads the article below the intro, that shows how to setup OE. This is exactly what the autobuilders use that upload to the feeds.
Now I'm confused. The patched kernel source in OE does not seem to
match the behaviour I observe. The ALSA controls have the wrong names.
I've verified he uImage.bin has the same MD5 sum of the output from OE.
I must be misunderstanding something fairly fundamental.
How can I stop the object files from being deleted in the OE build process?
Is there a way to rebuild just the uImage? I just tries bitbake -c
virtual/kernel and it throws an error. Pretty sure this used to work.
bitbake virtual/kernel -c compile -f