[U-Boot] Generic bootcmd handling: Missing 'scsi scan'

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 09/16/2014 08:07 AM, Karsten Merker wrote:
> On Mon, Sep 15, 2014 at 07:59:09PM +0200, Hans de Goede wrote:
>> On 09/15/2014 07:22 PM, Stephen Warren wrote:
>>> On 09/14/2014 12:00 PM, Hans de Goede wrote:
>>>> On 09/14/2014 05:43 PM, Karsten Merker wrote:
> 
>>>>> I am currently testing the new bootcmd handling introduced at
>>>>> http://git.denx.de/?p=u-boot.git;a=commit;h=8cc96848f0a467922820895b6b2363b0c64163b5
>>>>> on a sunxi-based system running u-boot v2014.10-rc2.
>>>>>
>>>>> When installing to MMC, everything works as expected; the
>>>>> boot.scr on the first MMC partition is found and executed.
>>>>>
>>>>> When installing to a SATA disk, the following happens:
> [snip]
>>>>> SCSI device 0:
>>>>>      Device 0: device type unknown
>>>>> ... is now current device
>>>>> Scanning scsi 0...
>>>>> ** Bad device size - scsi 0 **
> [snip]
>>>>> What appears to be missing here, is a previous 'scsi scan' command.
>>>>> When prepending it to ${scsi_boot}, everything works as expected:
> [snip]
>>>> A good question, I wonder if this is something which would be considered
>>>> SoC specific, or if all SoCs need this though?
>>>>
>>>> Stephen (added to the To) what is your take on this ?
>>>
>>> Hmmm. 'mmc_dev' detects the media each time it's executed. However, I
>>> suppose that's appropriate because each MMC controller is connected 1:1
>>> with a device.  Such automatic scanning might not be a good idea for
>>> larger buses where scanning could take a long time.  Perhaps you can
>>> copy the style of $usb_boot, and prefix a "run $scsi_init" onto the
>>> front of it in the same way?
>>
>> So perhaps something like the patch below ?
>>
>> Karsten, can you give this a try ?
> 
> Thanks a lot, your patch works:
> 
> [...]
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0...
> ** No partition table - mmc 0 **
> ** No partition table - mmc 0 **
> ** No partition table - mmc 0 **
> ** No partition table - mmc 0 **
> ** No partition table - mmc 0 **
> ** No partition table - mmc 0 **
> scanning bus for devices...
>   Device 0: (0:0) Vendor: ATA Prod.: HGST HTS541010A9 Rev: JA0O
>             Type: Hard Disk
>             Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
> Found 1 device(s).
> 
> SCSI device 0:
>     Device 0: (0:0) Vendor: ATA Prod.: HGST HTS541010A9 Rev: JA0O
>             Type: Hard Disk
>             Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
> ... is now current device
> Scanning scsi 0...
> Found U-Boot script /boot.scr
> 2033 bytes read in 27 ms (73.2 KiB/s)
> ## Executing script at 43100000
> [...]
> 
> While testing it, I have found another issue, though. It looks
> like there could be some race condition / timing issue when
> reading the type and capacity information from the SATA disk.
> 
> When stopping the autoboot countdown timer and then manually
> running scsi_boot after some seconds, the output always looks
> like above.  When letting the autoboot happen without manual
> intervention, sometimes the output looks like this:
> 
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0...
> ** No partition table - mmc 0 **
> ** No partition table - mmc 0 **
> ** No partition table - mmc 0 **
> ** No partition table - mmc 0 **
> ** No partition table - mmc 0 **
> ** No partition table - mmc 0 **
> scanning bus for devices...
>   Device 0: (0:0) Vendor: ATA Prod.: ?? Rev: ???p
>             Type: Hard Disk
>             Capacity: not available
> Found 1 device(s).
> 
> SCSI device 0:
>     Device 0: (0:0) Vendor: ATA Prod.: ?? Rev: ???p
>             Type: Hard Disk
>             Capacity: not available
> ... is now current device
> Scanning scsi 0...
> Found U-Boot script /boot.scr
> 2033 bytes read in 27 ms (73.2 KiB/s)
> ## Executing script at 43100000
> 
> i.e. the disk properties are not read properly.

Hmm, that is unfortunate, but otherwise the boot does
continue normally ? This looks like a bug in the harddisk
to me TBH. We do wait for the sata link to become ready,
once it is ready I would expect simple identify commands
to just work and not need some additional delay.

> The same happens
> when doing a reboot from Linux.  I get the impression that the
> harddisk is not always fully ready when it is queried.  From the
> sounds the disk makes, it also appears that the SATA power is
> turned off and on several times during a (re-)boot.  It
> looks/sounds like during the boot process the following happens:
> 
> - power on the device
> - u-boot initializes
> - the disk spins up
> - u-boot queries the disk, sometimes the disk has not reached
>   its full revolution speed at that point (the "whining" sound
>   still gets higher after the query from u-boot)
> - u-boot starts the kernel

So far so good ...

> - the kernel disables the SATA power and immediately afterwards
>   enables it again, often resulting in the harddisk making a
>   hard "klack" (headload?) sound

That should not be happening, do you have the ahci_sunxi module
build into the kernel ? I guess the kernel may do this if it
is a module. We may need some dts changes here to mark the powersupply
in question as always-on.

Can you try building a new dtb for your cubietruck using this patch:

--- a/arch/arm/boot/dts/sunxi-common-regulators.dtsi
+++ b/arch/arm/boot/dts/sunxi-common-regulators.dtsi
@@ -44,6 +44,8 @@
                regulator-name = "ahci-5v";
                regulator-min-microvolt = <5000000>;
                regulator-max-microvolt = <5000000>;
+         /* Stop rapid off/on on (re)boot, use spindown to save power */
+         regulator-always-on;
                enable-active-high;
                gpio = <&pio 1 8 0>;
                status = "disabled";

And see if that helps, it would also be good to try with ahci_sunxi
buildin that may actually be the preferable solution. Either way
this is not a u-boot problem.

> - upon reboot either the kernel or u-boot disables the SATA
>   power, the disk starts spinning down
> - u-boot enables the SATA power and the disk immediately
>   spins up again, often resulting in another hard "klack"
>   sound, and the whole process starts from the beginning

Not sure if that can be avoided even with regulator-always-on;
on reboot we let the watchdog do a full system reset, I don't
know what this does to the gpio-s of the SoC.

> This is on a Cubietruck, which has a GPIO-controlled SATA power
> supply, so this behaviour might not show up on other devices.

Ack.

Regards,

Hans