[coreboot] HP Pavilion 14 Chromebook - AKA Butterfly
jlewis at johnlewis.ie
Fri Oct 18 23:42:17 CEST 2013
On 18/10/2013 20:49, Kyösti Mälkki wrote:
> 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
>>>> 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
>>>> 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
>>> 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
>>> 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
>>> usbdebug without loading related modules in grub.cfg file. I have
>>> 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
>>> 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
>> the same firmware and see how consistent the output is, and maybe
>> 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.
> Find attached my grub.cfg with both serial and usb consoles, also
> enabling some debugging for USB storage there. You could possibly
> set debug="usb" before the insmods, but you may need to revert it
> 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
> lines. You can then copy-paste other commands while capturing all
> communication to logfile to check for any handshake with the BBB.
I'm unsure exactly what you mean. I thought that with the correct
grub.cfg the grub output would just continue where the BIOS debug output
finished i.e. going to the Beaglebone?
I have tried a grub.cfg with just the first 5 lines and with just the
usb relevant stuff, hoping I would get a grub prompt over the gadget
tty, but to no avail.
More information about the coreboot