On 08/04/2011 09:56 PM, Marshall Buschman wrote:
On 8/4/2011 6:45 PM, Marc Jones wrote:
On Thu, Aug 4, 2011 at 4:07 PM, Marc Jonesmarcj303@gmail.com wrote:
On Wed, Aug 3, 2011 at 5:22 PM, Kevin O'Connorkevin@koconnor.net wrote:
On Wed, Aug 03, 2011 at 02:47:19PM -0600, Marc Jones wrote:
I'm having a problem with booting a usb flash key that worked previously in version 0.6.2. The USB device is identified but then gets a read error when booting from it. This is the Persimmon, sb800 platform. Any thoughts on what might have changed to cause this?
Could it be just a sporatic failure? The only real USB changes since v0.6.2 were book keeping changes for 'struct pcidevice' - I don't think they would cause drive read errors. Can you post the log?
This is the error I am getting:
enter handle_13: a=00204280 b=00002400 c=0000000a d=00000080 ds=0000 es=07c0 ss=0000 si=00007ba2 di=00002000 bp=000007be sp=00007ba2 cs=07c0 ip=0147 f=0202 disk_op d=0x0000d5e0 lba=2097280 buf=0x0000a000 count=1 cmd=2 ehci_send_bulk qh=0x0009ff00 dir=0 data=0x0009fad8 size=31 ehci_send_bulk qh=0x0009ff80 dir=128 data=0x0000a000 size=512 ehci_send_bulk qh=0x0009ff80 dir=128 data=0x0009faf7 size=13 enter handle_13: a=00204281 b=00002400 c=00000000 d=00000780 ds=0000 es=07e0 ss=0000 si=00007ba2 di=00002000 bp=000007be sp=00007ba2 cs=07c0 ip=0147 f=0206 disk_op d=0x0000d5e0 lba=2097281 buf=0x0000a200 count=1 cmd=2 ehci_send_bulk qh=0x0009ff00 dir=0 data=0x0009fad8 size=31 WARNING - Timeout at ehci_wait_td:570! ehci_send_bulk failed USB transmission failed invalid extended_access:143: a=00204281 b=00002400 c=00000000 d=00000780 ds=0000 es=07e0 ss=0000 si=00007ba2 di=00002000 bp=000007be sp=00007ba2 cs=07c0 ip=0147 f=0206
I now suspect that this is a coreboot problem. The old working seabios with current coreboot fails as well.
I bisected it to this change in coreboot: 8fed77ae4c46122859d0718678e54546e126d4bc is the first bad commit commit 8fed77ae4c46122859d0718678e54546e126d4bc Author: Scott Duplichanscott@notabs.org Date: Sat Jun 18 10:46:45 2011 -0500
ASRock E350M1: Configure SB800 GPP ports to support onboard pcie
Scott Duplichan's patch from the mailing list: sb800 cimx wrapper: Run the complete sb800 cimx
sbBeforePciInit() function once, after determining device 0x15 function enables.
1) Update the asrock e350m1 devicetree.cb to match the hardware. 2) Change the way the sb800 cimx wrapper code works. The original cimx code calls sb800 cimx function sbBeforePciInit() once. When ported to coreboot, the gpp component of this function was called once for each gpp port, as the gpp port's enable/disable state became known. A 05/15/2011 change makes the early gpp code run only once, triggered by processing the 4th gpp port. This method is not general enough because the 4th gpp port is not enabled on all boards. With the current change, the early gpp code runs when the first gpp port is processed. If any gpp ports are enabled, the first must be enabled. Tested with Win7 and linux on asrock e350m1. This change will also affect amd inagua, and has not been tested on that board. Change-Id: I93d44c216bfcab3c3a8fbb79d23dab43a65850e6 Signed-off-by: Scott Duplichan<firstname.lastname@example.org> Acked-by: Marshall Buschman<email@example.com> Reviewed-on: http://review.coreboot.org/44 Tested-by: build bot (Jenkins) Reviewed-by: Cristian
I'll see if I can figure out why it breaks stuff.
Marshall, Can you try before and after this change?
Understood. I'll roll that back and see if I can still reproduce the USB error. -Marshall
SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Wow! I'm sorry this has taken so long. I can confirm this on my E350M1: USB flash drives (tested with my Motorola Droid X and an actual USB flash drive) break after applying coreboot 8fed77ae4c4612.
full dmesg output (Linux 3.0.1, Gentoo): Coreboot master: http://www.lucidmachines.com/coreboot/broken-copy.gz Coreboot 47b3fb403d5b7f7fc: http://www.lucidmachines.com/coreboot/working-copy.gz Coreboot 8fed77ae4c4612: http://www.lucidmachines.com/coreboot/broken-copy-after.gz
I tested this by mounting my phone and doing a cp -R of the folder which contains all of my media files to /var on the E350M1. I would guess that whatever failure we have here is random - I've seen it fail after copying as little as 6.3MB and as much as ~500MB.
Please let me know if I can assist further.
For what it's worth: I was able to observe this behavior in Linux 2.6.39 as well.
Thank you! -Marshall