On 19/10/2013 05:44, Kyösti Mälkki wrote:
On 19.10.2013 01:40, John Lewis wrote:
Here's the dmesg output you asked for. Only two commands I'm currently running are "modprobe g_dbgp" and "screen /dev/ttyGS0". That timeout line was at 697 (have also git-pulled today). Increasing it made the output consistently miss off the loading segments messages and "Using LZMA".
What do you mean line 697? That endpoint timeout setting really should be on line 802. Double-check this.
Unfortunately the dmesg log was not annotated nor did you send the related coreboot console log file. I guess you rebooted the target chromebook several times during this log?
Let's reduce the number of unknowns and try to replicate the setup I have here as close as possible:
- Use your samsung/lumpy instead of google/butterfly for the
testing.
Use stty, cat and picocom as described on the wiki page.
Install archlinux-arm on the BBB. The one I use has kernel tagged
with version string 3.8.13-7-ARCH. With the patches for the gadget driver there is also a pre-built and patched g_dbgp module to be used with this kernel.
Kyösti
Yep, you're right it's at 802.
How was I to annotate it? You didn't ask for the coreboot console log. Quote "Is your logfile on ramfs or SD card? Send a log of commands you run on BeagleBone Black and also dmesg from the same sequence. Start with the loading of g_dbgp module."
Yes, I powered the board off and on a bunch of times. The console log was 64,000 lines long, from memory.
1. Okay, Lumpy it is.
2. picocom isn't included with the default BBB distro, and the EHCI gadget debug instructions don't specifying sticking Arch on the BBB.
3. I will try experimenting with the gadget on my Lumpy before I go wiping the BBB.
Thanks,
John.