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

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

[Hans de Goede]

Hi Karsten,

Thanks for testing this!

On 09/14/2014 05:43 PM, Karsten Merker wrote:
> Hello,
> 
> 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:
> 
> U-Boot 2014.10-rc2 (Sep 04 2014 - 07:32:33) Allwinner Technology
> 
> CPU:   Allwinner A20 (SUN7I)
> I2C:   ready
> DRAM:  2 GiB
> MMC:   SUNXI SD/MMC: 0
> In:    serial
> Out:   serial
> Err:   serial
> SCSI:  SUNXI SCSI INIT
> Target spinup took 0 ms.
> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: ncq stag pm led clo only pmp pio slum part ccc apst
> Net:   dwmac.1c50000
> 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 **
> 
> SCSI device 0:
>     Device 0: device type unknown
> ... is now current device
> Scanning scsi 0...
> ** Bad device size - scsi 0 **
> ** Bad device size - scsi 0 **
> ** Bad device size - scsi 0 **
> ** Bad device size - scsi 0 **
> ** Bad device size - scsi 0 **
> ** Bad device size - scsi 0 **
> [...]
> 
> The last block is the output of running ${scsi_boot}:
> 
> sun7i# printenv scsi_boot
> scsi_boot=if scsi dev ${devnum}; then setenv devtype scsi; run scan_dev_for_boot; fi
> 
> What appears to be missing here, is a previous 'scsi scan' command.
> When prepending it to ${scsi_boot}, everything works as expected:
> 
> sun7i# printenv scsi_boot
> scsi_boot=scsi scan; if scsi dev 0; then setenv devtype scsi; run scan_dev_for_boot; fi
> sun7i# run scsi_boot
> 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 20 ms (98.6 KiB/s)
> ## Executing script at 43100000
> 
> Could you add a 'scsi scan' command to the generic bootcmd
> handling infrastructure?

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 ?

Regards,

Hans

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

[Stephen Warren]

On 09/14/2014 12:00 PM, Hans de Goede wrote:
> Hi Karsten,
>
> Thanks for testing this!
>
> On 09/14/2014 05:43 PM, Karsten Merker wrote:
>> Hello,
>>
>> 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:
>>
>> U-Boot 2014.10-rc2 (Sep 04 2014 - 07:32:33) Allwinner Technology
>>
>> CPU:   Allwinner A20 (SUN7I)
>> I2C:   ready
>> DRAM:  2 GiB
>> MMC:   SUNXI SD/MMC: 0
>> In:    serial
>> Out:   serial
>> Err:   serial
>> SCSI:  SUNXI SCSI INIT
>> Target spinup took 0 ms.
>> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
>> flags: ncq stag pm led clo only pmp pio slum part ccc apst
>> Net:   dwmac.1c50000
>> 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 **
>>
>> SCSI device 0:
>>      Device 0: device type unknown
>> ... is now current device
>> Scanning scsi 0...
>> ** Bad device size - scsi 0 **
>> ** Bad device size - scsi 0 **
>> ** Bad device size - scsi 0 **
>> ** Bad device size - scsi 0 **
>> ** Bad device size - scsi 0 **
>> ** Bad device size - scsi 0 **
>> [...]
>>
>> The last block is the output of running ${scsi_boot}:
>>
>> sun7i# printenv scsi_boot
>> scsi_boot=if scsi dev ${devnum}; then setenv devtype scsi; run scan_dev_for_boot; fi
>>
>> What appears to be missing here, is a previous 'scsi scan' command.
>> When prepending it to ${scsi_boot}, everything works as expected:
>>
>> sun7i# printenv scsi_boot
>> scsi_boot=scsi scan; if scsi dev 0; then setenv devtype scsi; run scan_dev_for_boot; fi
>> sun7i# run scsi_boot
>> 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 20 ms (98.6 KiB/s)
>> ## Executing script at 43100000
>>
>> Could you add a 'scsi scan' command to the generic bootcmd
>> handling infrastructure?
>
> 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?

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

[Hans de Goede]

Hi,

On 09/15/2014 07:22 PM, Stephen Warren wrote:
> On 09/14/2014 12:00 PM, Hans de Goede wrote:
>> Hi Karsten,
>>
>> Thanks for testing this!
>>
>> On 09/14/2014 05:43 PM, Karsten Merker wrote:
>>> Hello,
>>>
>>> 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:
>>>
>>> U-Boot 2014.10-rc2 (Sep 04 2014 - 07:32:33) Allwinner Technology
>>>
>>> CPU:   Allwinner A20 (SUN7I)
>>> I2C:   ready
>>> DRAM:  2 GiB
>>> MMC:   SUNXI SD/MMC: 0
>>> In:    serial
>>> Out:   serial
>>> Err:   serial
>>> SCSI:  SUNXI SCSI INIT
>>> Target spinup took 0 ms.
>>> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
>>> flags: ncq stag pm led clo only pmp pio slum part ccc apst
>>> Net:   dwmac.1c50000
>>> 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 **
>>>
>>> SCSI device 0:
>>>      Device 0: device type unknown
>>> ... is now current device
>>> Scanning scsi 0...
>>> ** Bad device size - scsi 0 **
>>> ** Bad device size - scsi 0 **
>>> ** Bad device size - scsi 0 **
>>> ** Bad device size - scsi 0 **
>>> ** Bad device size - scsi 0 **
>>> ** Bad device size - scsi 0 **
>>> [...]
>>>
>>> The last block is the output of running ${scsi_boot}:
>>>
>>> sun7i# printenv scsi_boot
>>> scsi_boot=if scsi dev ${devnum}; then setenv devtype scsi; run scan_dev_for_boot; fi
>>>
>>> What appears to be missing here, is a previous 'scsi scan' command.
>>> When prepending it to ${scsi_boot}, everything works as expected:
>>>
>>> sun7i# printenv scsi_boot
>>> scsi_boot=scsi scan; if scsi dev 0; then setenv devtype scsi; run scan_dev_for_boot; fi
>>> sun7i# run scsi_boot
>>> 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 20 ms (98.6 KiB/s)
>>> ## Executing script at 43100000
>>>
>>> Could you add a 'scsi scan' command to the generic bootcmd
>>> handling infrastructure?
>>
>> 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 ?

Note I'm not sure my mail client will not mangle this when inlined like
this (normally I use git send-email for patches). So I've also attached
the patch.

Regards,

Hans

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

[Stephen Warren]

On 09/15/2014 11:59 AM, Hans de Goede wrote:
> Hi,
>
> On 09/15/2014 07:22 PM, Stephen Warren wrote:
>> On 09/14/2014 12:00 PM, Hans de Goede wrote:
>>> Hi Karsten,
>>>
>>> Thanks for testing this!
>>>
>>> On 09/14/2014 05:43 PM, Karsten Merker wrote:
>>>> Hello,
>>>>
>>>> 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:
>>>>
...
>>>> SCSI device 0:
>>>>       Device 0: device type unknown
>>>> ... is now current device
>>>> Scanning scsi 0...
>>>> ** Bad device size - scsi 0 **
...
>>>> Could you add a 'scsi scan' command to the generic bootcmd
>>>> handling infrastructure?
>>>
>>> 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 ?
>
> Note I'm not sure my mail client will not mangle this when inlined like
> this (normally I use git send-email for patches). So I've also attached
> the patch.
...
> Subject: [PATCH] config_distro_bootcmd: Run 'scsi scan' before trying scsi
>   disks
>
> Scsi disks need to be probed before we try to access them, otherwise all
> accesses fail with: ** Bad device size - scsi 0 **.

Yes, I think that looks right.

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

[Hans de Goede]

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