[coreboot] HP Pavilion 14 Chromebook - AKA Butterfly

[Kyösti Mälkki]

On 18.10.2013 22:03, John Lewis wrote:
> 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.

Find attached my grub.cfg with both serial and usb consoles, also 
enabling some debugging for USB storage there. You could possibly move 
set debug="usb" before the insmods, but you may need to revert it before 
using serial_usb0.

The easiest way is to use a desktop board booting to grub and have it 
provide grub shell over serial terminal. Those would be the first five 
lines. You can then copy-paste other commands while capturing all 
communication to logfile to check for any handshake with the BBB.

Kyösti
-------------- next part --------------
set timeout=5
set default=0

serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1
terminal_input --append  serial
terminal_output --append serial

insmod ehci
insmod usbserial_usbdebug
terminal_input --append serial_usb0
terminal_output --append serial_usb0

menuentry 'mini 3.0.8' {
	insmod usbms
	insmod part_msdos
	insmod ext2
	terminal_input --remove serial_usb0
	terminal_output --remove serial_usb0
	set debug="usb"
	linux (usb0,msdos1)/boot/vmlinuz
	initrd (usb0,msdos1)/boot/initrd.gz
}