On 18/10/2013 18:50, Kyösti Mälkki wrote:
On 18.10.2013 18:03, John Lewis wrote:
On 18/10/2013 15:43, Kyösti Mälkki wrote:
On 17.10.2013 23:39, John Lewis wrote:
On 17/10/2013 19:49, Kyösti Mälkki wrote:
Your log indicates it did not even reach payload. Try to add some debugging printk's in smbios_write_tables() to trace where it might halt. Unfortunately you cannot yet use GDB over usbdebug.
I'm unsure, so I've done another. This one is Grub2 LZMA compressed, and it gets a bit further. Also more warning messages and errors. Guess there's no point adding printk's to smbios_write_tables() as it gets past that on this one?
Hi John It is not clear to me if you previously had a working Butterfly built from coreboot git and it is now broken with a recent master. Does it fail in a consistent fashion? Log terminates exactly at the same point if you try a few cold boots? You will not benefit from CBMEM console and timestamps until you can reach OS and I honestly hope those are not affecting your boots. I think you already disabled console for the last log. What local changes have you made, log has -dirty tag in version string? Kyösti
Hi Kyösti, No, it's never worked, but I've only had the Chromebook a week. Where it terminates seems to depend on whether I redirect cat to a file or not. If I don't redirect I get further messages than you can see in the file I attached about "loading segments" and finally "Using LZMA". CBMEM console is disabled, but early pre-RAM console is enabled, yes. I've tried removing "select CHROMEOS" from the board's Kconfig, but it doesn't even build (tried from clean), and I just add it back again. Only other change I ever make is the default hard-coded menu key in SeaBIOS. John.
Ok, modified Kconfig file explains the -dirty flag.
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.
Maybe, if there is high latency on USB device port on BBB, usbdebug hits one of the timeouts. You can try to increase that in lib/usbdebug.c, line 802: info->ep_pipe[i].timeout = 1000;
This was slow enough for average 9600bps and there isn't really a complete recovery mechanism implemented. Even if usbdebug times out, the boot will continue, but somewhat slower and without output on usbdebug console.
You will not get any SeaBIOS interaction over usbdebug, not implemented.
You will not get any GRUB interaction over usbdebug without loading related modules in grub.cfg file. I have not used it with the debug gadget driver at all, only with the DIY dongle. Making BBB work here would make a nice contribution so I hope you are willing to spend some time on it!
Kyösti
It's on the BBB's filesystem, whatever that is. Okay, but beyond loading the module, setting up the tty, and running the cat command there isn't much - I even renamed the one gadget module which was getting loaded ahead of g_dbgp.ko, because I thought rmmod -f might make the USB subsystem act strangely.
I will run a bunch of boots with the same firmware and see how consistent the output is, and maybe try adjusting the timeout then.
Do you happen to know if loading usbserial_usbdebug.mod in the grub config will pull in all necessary modules? I don't mind spending as long as it takes, just remember I don't know C, and I haven't programmed in earnest since circa 1996. :)
John.