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=8cc96848f0a467922820895b6b2363b0... 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