[coreboot] HP Pavilion 14 Chromebook - AKA Butterfly

[John Lewis]

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.