Author: quozl
Date: Sat May 10 05:44:05 2014
New Revision: 3726
URL: http://tracker.coreboot.org/trac/openfirmware/changeset/3726
Log:
scsidisk - retry TEST UNIT READY once
Some USB flash drives violate section 3.4 of the USB Mass Storage
Specification For Bootability 1.0, October 25, 2004, by responding to
TEST UNIT READY with CHECK CONDITION status with a sense key of NOT
READY, and an additional sense code of MEDIUM NOT PRESENT.
Section 3.4 says "If the Device cannot become operational or in a
state such that a Host Computer action is required to make the Device
ready, the Device returns CHECK CONDITION status with a sense key of
NOT READY."
So the device either cannot become operational, or requires action of
the host.
However, a second TEST UNIT READY is successful, without any other
action of the host other than trying again.
READ CAPACITY and READ commands also fail if they are done first,
before the device admits to being ready.
Section 3.4 also says "Devices are expected to respond promptly to
indicate the current status of the Device."
Section 6.1 of the USB Mass Storage Class - Compliance Test
Specification 0.9a, June 30, 2006, says "Issue a Test Unit Ready
command. Repeat until the device indicates a ready state."
Modified:
dev/usb2/device/storage/scsidisk.fth
Modified: dev/usb2/device/storage/scsidisk.fth
==============================================================================
--- dev/usb2/device/storage/scsidisk.fth Tue Apr 29 23:06:32 2014 (r3725)
+++ dev/usb2/device/storage/scsidisk.fth Sat May 10 05:44:05 2014 (r3726)
@@ -43,6 +43,14 @@
" "(00 00 00 00 00 00)" drop no-data-command 0=
;
+\ Some devices require a second TEST UNIT READY, despite returning
+\ CHECK CONDITION, with sense NOT READY and MEDIUM NOT PRESENT.
+
+: retry-unit-ready? ( -- ready? )
+ unit-ready? ?dup if exit then
+ unit-ready?
+;
+
\ Ensures that the disk is spinning, but doesn't wait forever
create sstart-cmd h# 1b c, 0 c, 0 c, 0 c, 1 c, 0 c,
@@ -206,7 +214,7 @@
\ up to 30 secs to spin up.
d# 45 d# 1000 * set-timeout
- unit-ready? 0= if false exit then
+ retry-unit-ready? 0= if false exit then
\ It might be a good idea to do an inquiry here to determine the
\ device configuration, checking the result to see if the device
Author: quozl
Date: Thu Mar 20 05:06:05 2014
New Revision: 3718
URL: http://tracker.coreboot.org/trac/openfirmware/changeset/3718
Log:
core - use initial values from a current instance package if there is one, fixes clearing of display on subsequent select, caused by my-termemu not persisting, fixes OLPC #12765, thanks to Mitch Bradley.
Modified:
ofw/core/ofwcore.fth
Modified: ofw/core/ofwcore.fth
==============================================================================
--- ofw/core/ofwcore.fth Wed Mar 19 22:20:04 2014 (r3717)
+++ ofw/core/ofwcore.fth Thu Mar 20 05:06:05 2014 (r3718)
@@ -992,16 +992,16 @@
\ resource). If we ever need to make this ROMable, we can implement copy-on-
\ write for initial values.
-: >initial-value ( pfa -- adr )
- @
+: initial-values' ( -- adr )
my-self if \ Use current instance's package if there is a current instance
my-voc (push-package) initial-values (pop-package)
else \ Otherwise use the active package
initial-values
then
- +
;
+: >initial-value ( pfa -- adr ) @ initial-values' + ;
+
3 actions
action: >initial-value @ ;
action: >initial-value ! ;
@@ -1055,7 +1055,7 @@
;
\ Returns the address of the initial value of the named instance data.
-: (initial-addr) ( adr -- adr' ) my-self - initial-values + ;
+: (initial-addr) ( adr -- adr' ) my-self - initial-values' + ;
: initial-addr \ name ( -- addr )
[compile] addr
state @ if compile (initial-addr) else (initial-addr) then