* [U-Boot] Generic bootcmd handling: Missing 'scsi scan'
[not found] <20140914154357.GD4641@excalibur.cnev.de>
@ 2014-09-14 18:00 ` Hans de Goede
2014-09-15 17:22 ` Stephen Warren
0 siblings, 1 reply; 5+ messages in thread
From: Hans de Goede @ 2014-09-14 18:00 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] Generic bootcmd handling: Missing 'scsi scan'
2014-09-14 18:00 ` [U-Boot] Generic bootcmd handling: Missing 'scsi scan' Hans de Goede
@ 2014-09-15 17:22 ` Stephen Warren
2014-09-15 17:59 ` Hans de Goede
0 siblings, 1 reply; 5+ messages in thread
From: Stephen Warren @ 2014-09-15 17:22 UTC (permalink / raw)
To: u-boot
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?
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] Generic bootcmd handling: Missing 'scsi scan'
2014-09-15 17:22 ` Stephen Warren
@ 2014-09-15 17:59 ` Hans de Goede
2014-09-15 18:11 ` Stephen Warren
[not found] ` <20140916060700.GA5908@excalibur.cnev.de>
0 siblings, 2 replies; 5+ messages in thread
From: Hans de Goede @ 2014-09-15 17:59 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] Generic bootcmd handling: Missing 'scsi scan'
2014-09-15 17:59 ` Hans de Goede
@ 2014-09-15 18:11 ` Stephen Warren
[not found] ` <20140916060700.GA5908@excalibur.cnev.de>
1 sibling, 0 replies; 5+ messages in thread
From: Stephen Warren @ 2014-09-15 18:11 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [U-Boot] Generic bootcmd handling: Missing 'scsi scan'
[not found] ` <20140916060700.GA5908@excalibur.cnev.de>
@ 2014-09-16 7:36 ` Hans de Goede
0 siblings, 0 replies; 5+ messages in thread
From: Hans de Goede @ 2014-09-16 7:36 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-09-16 7:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20140914154357.GD4641@excalibur.cnev.de>
2014-09-14 18:00 ` [U-Boot] Generic bootcmd handling: Missing 'scsi scan' Hans de Goede
2014-09-15 17:22 ` Stephen Warren
2014-09-15 17:59 ` Hans de Goede
2014-09-15 18:11 ` Stephen Warren
[not found] ` <20140916060700.GA5908@excalibur.cnev.de>
2014-09-16 7:36 ` Hans de Goede
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.