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:
1. Use your samsung/lumpy instead of google/butterfly for the
testing.
2. Use stty, cat and picocom as described on the wiki page.
3. 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.
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
