[coreboot] HP Pavilion 14 Chromebook - AKA Butterfly

Kyösti Mälkki kyosti.malkki at gmail.com
Fri Oct 18 19:50:37 CEST 2013

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 

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!


More information about the coreboot mailing list