Hello again coreboot folks,
I am trying to get the subject working with coreboot, and I can't seem to get any display, either with SeaBIOS or Grub2 payloads (although Grub2 does switch backlight on). I have output from USB debug, but the only obvious problem is not being able to write the MRC cache (which also happens on Lumpy and doesn't stop it from booting). Additionally there isn't any debug output from the payloads. How do I enable same, and have you any other thoughts as to how to move things forward? Please see attached.
Kind Regards,
John.
On 17.10.2013 19:45, John Lewis wrote:
Hello again coreboot folks,
I am trying to get the subject working with coreboot, and I can't seem to get any display, either with SeaBIOS or Grub2 payloads (although Grub2 does switch backlight on). I have output from USB debug, but the only obvious problem is not being able to write the MRC cache (which also happens on Lumpy and doesn't stop it from booting). Additionally there isn't any debug output from the payloads. How do I enable same, and have you any other thoughts as to how to move things forward? Please see attached.
Kind Regards,
John.
Hi
That log was with SeaBIOS? With it one usually executes video bios late. With Grub2 video bios is usually executed early, before payload.
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.
Grub2 console over Net20DC has been demonstrated, it may require some tweaks to USB IDs/descriptors to make it work with BeagleBone Black.
Kyösti
On 17/10/2013 19:49, Kyösti Mälkki wrote:
On 17.10.2013 19:45, John Lewis wrote:
Hello again coreboot folks, I am trying to get the subject working with coreboot, and I can't seem to get any display, either with SeaBIOS or Grub2 payloads (although Grub2 does switch backlight on). I have output from USB debug, but the only obvious problem is not being able to write the MRC cache (which also happens on Lumpy and doesn't stop it from booting). Additionally there isn't any debug output from the payloads. How do I enable same, and have you any other thoughts as to how to move things forward? Please see attached. Kind Regards, John.
Hi
That log was with SeaBIOS? With it one usually executes video bios late. With Grub2 video bios is usually executed early, before payload.
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.
Grub2 console over Net20DC has been demonstrated, it may require some tweaks to USB IDs/descriptors to make it work with BeagleBone Black.
Kyösti
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Hi Kyösti,
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?
John.
On 17.10.2013 23:39, John Lewis wrote:
On 17/10/2013 19:49, Kyösti Mälkki wrote:
<clip>
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
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.
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
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.
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
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 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
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.
John.
On 19.10.2013 00:42, John Lewis wrote: <clip>
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
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.
John.
This was a proposal for a setup for a mainboard with old-style serial port so you could debug why console using the gadget driver does not come up.
For further discussion on this particular topic, better address the GRUB mailing lists.
Kyöst
On 19/10/2013 05:06, Kyösti Mälkki wrote:
On 19.10.2013 00:42, John Lewis wrote:
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
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. John.
This was a proposal for a setup for a mainboard with old-style serial port so you could debug why console using the gadget driver does not come up.
For further discussion on this particular topic, better address the GRUB mailing lists.
Kyöst
Ah, I see what you mean now. No, sorry, don't have anything with a serial port.
John.
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 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
Here's the dmesg output you asked for. Only two commands I'm currently running are "modprobe g_dbgp" and "screen /dev/ttyGS0". That timeout line was at 697 (have also git-pulled today). Increasing it made the output consistently miss off the loading segments messages and "Using LZMA".
On 19.10.2013 01:40, John Lewis wrote:
<clip>
Here's the dmesg output you asked for. Only two commands I'm currently running are "modprobe g_dbgp" and "screen /dev/ttyGS0". That timeout line was at 697 (have also git-pulled today). Increasing it made the output consistently miss off the loading segments messages and "Using LZMA".
What do you mean line 697? That endpoint timeout setting really should be on line 802. Double-check this.
Unfortunately the dmesg log was not annotated nor did you send the related coreboot console log file. I guess you rebooted the target chromebook several times during this log?
Let's reduce the number of unknowns and try to replicate the setup I have here as close as possible:
1. Use your samsung/lumpy instead of google/butterfly for the testing.
2. Use stty, cat and picocom as described on the wiki page.
3. Install archlinux-arm on the BBB. The one I use has kernel tagged with version string 3.8.13-7-ARCH. With the patches for the gadget driver there is also a pre-built and patched g_dbgp module to be used with this kernel.
Kyösti
On 19/10/2013 05:44, Kyösti Mälkki wrote:
On 19.10.2013 01:40, John Lewis wrote:
Here's the dmesg output you asked for. Only two commands I'm currently running are "modprobe g_dbgp" and "screen /dev/ttyGS0". That timeout line was at 697 (have also git-pulled today). Increasing it made the output consistently miss off the loading segments messages and "Using LZMA".
What do you mean line 697? That endpoint timeout setting really should be on line 802. Double-check this.
Unfortunately the dmesg log was not annotated nor did you send the related coreboot console log file. I guess you rebooted the target chromebook several times during this log?
Let's reduce the number of unknowns and try to replicate the setup I have here as close as possible:
- Use your samsung/lumpy instead of google/butterfly for the
testing.
Use stty, cat and picocom as described on the wiki page.
Install archlinux-arm on the BBB. The one I use has kernel tagged
with version string 3.8.13-7-ARCH. With the patches for the gadget driver there is also a pre-built and patched g_dbgp module to be used with this kernel.
Kyösti
Yep, you're right it's at 802.
How was I to annotate it? You didn't ask for the coreboot console log. Quote "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."
Yes, I powered the board off and on a bunch of times. The console log was 64,000 lines long, from memory.
1. Okay, Lumpy it is.
2. picocom isn't included with the default BBB distro, and the EHCI gadget debug instructions don't specifying sticking Arch on the BBB.
3. I will try experimenting with the gadget on my Lumpy before I go wiping the BBB.
Thanks,
John.
<clip>
Let's reduce the number of unknowns and try to replicate the setup I have here as close as possible:
- Use your samsung/lumpy instead of google/butterfly for the
testing.
Use stty, cat and picocom as described on the wiki page.
Install archlinux-arm on the BBB. The one I use has kernel tagged
with version string 3.8.13-7-ARCH. With the patches for the gadget driver there is also a pre-built and patched g_dbgp module to be used with this kernel.
Kyösti
Hi Kyösti,
Trying to load ehci then usbserial_usbdebug module in Grub on Lumpy gives "error: no transfer descriptors available for EHCI transfer".
I've got a more verbose log for Butterfly, and it looks to me as though it's having trouble with graphics, as well as not actually loading the payload (possibly intertwined?). Help!
CBFS: Looking for 'pci8086,0106.rom' starting from 0x600000. CBFS: - load entry 0x600000 file name (16 bytes)... CBFS: (unmatched file @0x600000: cmos_layout.bin) CBFS: - load entry 0x6004c0 file name (32 bytes)... CBFS: Found file (offset=0x6004f8, len=65536). In CBFS, ROM address for PCI: 00:02.0 = ffe004f8 PCI expansion ROM, signature 0xaa55, INIT size 0x10000, data ptr 0x0040 PCI ROM image, vendor ID 8086, device ID 0106, PCI ROM image, Class Code 030000, Code Type 00 Copying VGA ROM Image from ffe004f8 to 0xc0000, 0x10000 bytes Real mode stub @00000600: 867 bytes Calling Option ROM... int15_handler: INT15 function 1000! Unknown INT15 function 1000! ... Option ROM returned. VBE: Getting information about VESA mode 4117 VBE: resolution: 1024x768@16 VBE: framebuffer: d0000000 VBE: Setting VESA mode 4117 int15_handler: INT15 function e873! Unknown INT15 function e873! VGA Option ROM has been loaded GT Power Management Init (post VBIOS)
See attached.
John.
On 21.10.2013 15:02, John Lewis wrote:
<clip>
Let's reduce the number of unknowns and try to replicate the setup I have here as close as possible:
Use your samsung/lumpy instead of google/butterfly for the testing.
Use stty, cat and picocom as described on the wiki page.
Install archlinux-arm on the BBB. The one I use has kernel tagged
with version string 3.8.13-7-ARCH. With the patches for the gadget driver there is also a pre-built and patched g_dbgp module to be used with this kernel.
Kyösti
Hi Kyösti,
Trying to load ehci then usbserial_usbdebug module in Grub on Lumpy gives "error: no transfer descriptors available for EHCI transfer".
I've got a more verbose log for Butterfly, and it looks to me as though it's having trouble with graphics, as well as not actually loading the payload (possibly intertwined?). Help!
Hi
Did you get a complete usbdebug log with lumpy? Including the loading of payload?
Kyösti
On 21/10/2013 19:52, Kyösti Mälkki wrote:
On 21.10.2013 15:02, John Lewis wrote:
Let's reduce the number of unknowns and try to replicate the setup I have here as close as possible: 1. Use your samsung/lumpy instead of google/butterfly for the testing. 2. Use stty, cat and picocom as described on the wiki page. 3. Install archlinux-arm on the BBB. The one I use has kernel tagged with version string 3.8.13-7-ARCH. With the patches for the gadget driver there is also a pre-built and patched g_dbgp module to be used with this kernel. Kyösti
Hi Kyösti, Trying to load ehci then usbserial_usbdebug module in Grub on Lumpy gives "error: no transfer descriptors available for EHCI transfer". I've got a more verbose log for Butterfly, and it looks to me as though it's having trouble with graphics, as well as not actually loading the payload (possibly intertwined?). Help!
Hi
Did you get a complete usbdebug log with lumpy? Including the loading of payload?
Kyösti
Yes, see attached. There are some lines after "Using LZMA".
John.
On 21/10/2013 19:52, Kyösti Mälkki wrote:
On 21.10.2013 15:02, John Lewis wrote:
Let's reduce the number of unknowns and try to replicate the setup I have here as close as possible: 1. Use your samsung/lumpy instead of google/butterfly for the testing. 2. Use stty, cat and picocom as described on the wiki page. 3. Install archlinux-arm on the BBB. The one I use has kernel tagged with version string 3.8.13-7-ARCH. With the patches for the gadget driver there is also a pre-built and patched g_dbgp module to be used with this kernel. Kyösti
Hi Kyösti, Trying to load ehci then usbserial_usbdebug module in Grub on Lumpy gives "error: no transfer descriptors available for EHCI transfer". I've got a more verbose log for Butterfly, and it looks to me as though it's having trouble with graphics, as well as not actually loading the payload (possibly intertwined?). Help!
Hi
Did you get a complete usbdebug log with lumpy? Including the loading of payload?
Kyösti
Hi Kyösti,
During my experiments and edge cases yesterday I discovered that Butterfly will boot from a Parrot build. All that needs to be done is to change the vendor and model strings in menuconfig.
I've a vague notion that someone mentioned to me that Parrot and Butterfly are pretty much identical, and that the Butterfly code is old, smelly, and probably doesn't work. I've also an idea that was Stefan. I could equally have made all that up, but thank you Stefan if not, and I apologise for forgetting your advice!
Cheers,
John.
On 17/10/2013 19:49, Kyösti Mälkki wrote:
On 17.10.2013 19:45, John Lewis wrote:
Hello again coreboot folks, I am trying to get the subject working with coreboot, and I can't seem to get any display, either with SeaBIOS or Grub2 payloads (although Grub2 does switch backlight on). I have output from USB debug, but the only obvious problem is not being able to write the MRC cache (which also happens on Lumpy and doesn't stop it from booting). Additionally there isn't any debug output from the payloads. How do I enable same, and have you any other thoughts as to how to move things forward? Please see attached. Kind Regards, John.
Hi
That log was with SeaBIOS? With it one usually executes video bios late. With Grub2 video bios is usually executed early, before payload.
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.
Grub2 console over Net20DC has been demonstrated, it may require some tweaks to USB IDs/descriptors to make it work with BeagleBone Black.
Kyösti
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
From the log I just sent it looks as though the missing INT15 function is probably the biggest problem?
-
John Lewis -
Kyösti Mälkki