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 Jones<marcj...@gmail.com> wrote:
On Wed, Aug 3, 2011 at 5:22 PM, Kevin O'Connor<ke...@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?
-Kevin
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 Duplichan<sc...@notabs.org>
Date: Sat Jun 18 10:46:45 2011 -0500
ASRock E350M1: Configure SB800 GPP ports to support onboard pcie
nic
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<sc...@notabs.org>
Acked-by: Marshall Buschman<mbusch...@lucidmachines.com>
Reviewed-on: http://review.coreboot.org/44
Tested-by: build bot (Jenkins)
Reviewed-by: Cristian
Măgherușan-Stanciu<cristi.magheru...@gmail.com>
I'll see if I can figure out why it breaks stuff.
Marshall,
Can you try before and after this change?
Marc
Understood. I'll roll that back and see if I can still reproduce the
USB error.
-Marshall
_______________________________________________
SeaBIOS mailing list
seab...@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
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
