[coreboot] [SeaBIOS] usb boot issue

Marshall Buschman mbuschman at lucidmachines.com
Sun Aug 21 03:33:37 CEST 2011


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<marcj303 at gmail.com>  wrote:
>>> On Wed, Aug 3, 2011 at 5:22 PM, Kevin O'Connor<kevin at 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<scott at 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<scott at notabs.org>
>>      Acked-by: Marshall Buschman<mbuschman at lucidmachines.com>
>>      Reviewed-on: http://review.coreboot.org/44
>>      Tested-by: build bot (Jenkins)
>>      Reviewed-by: Cristian 
>> Măgherușan-Stanciu<cristi.magherusan at 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
> SeaBIOS at 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













More information about the coreboot mailing list