[coreboot] HP Pavilion 14 Chromebook - AKA Butterfly
jlewis at johnlewis.ie
Fri Oct 18 21:03:49 CEST 2013
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
>>> master. Does it fail in a consistent fashion? Log terminates
>>> 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
>>> disabled console for the last log. What local changes have you
>>> 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
>> a file or not. If I don't redirect I get further messages than you
>> see in the file I attached about "loading segments" and finally
>> LZMA". CBMEM console is disabled, but early pre-RAM console is
>> 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
>> 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
> BeagleBone Black and also dmesg from the same sequence. Start with
> loading of g_dbgp module.
> Maybe, if there is high latency on USB device port on BBB, usbdebug
> 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,
> boot will continue, but somewhat slower and without output on
> You will not get any SeaBIOS interaction over usbdebug, not
> 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
> time on it!
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. :)
More information about the coreboot