From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Tue, 16 Sep 2014 09:36:19 +0200 Subject: [U-Boot] Generic bootcmd handling: Missing 'scsi scan' In-Reply-To: <20140916060700.GA5908@excalibur.cnev.de> References: <20140914154357.GD4641@excalibur.cnev.de> <5415D7D4.2050508@redhat.com> <54172053.8070309@wwwdotorg.org> <541728ED.503@redhat.com> <20140916060700.GA5908@excalibur.cnev.de> Message-ID: <5417E873.9070602@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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