How to stagger drive spinup?

[Miles Raymond]

Now that I've finally gotten debian booting from an SD card, after a lot of searching and eventually:

1. curl http://neil.brown.name/gnubee/gnubee-6.1.1-gbpc2.bin -o /media/usb-fat/gnubee.bin

1a. (optionally) connect USB serial cable's gnd, tx to gnubee's rx, rx to gnubee's tx and watching with putty configured for COMx 57600/8/1/None/None

2. insert USB, connect 12V@10A power, flip the switch and watch the update flash over

3. remove USB, flip off, insert blank SD card, flip on

4. after boot, run 'config' to install debian to the SD card

My new issue is when I plug in all 6 drives, I get:

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)

Board: MediaTek APSoC DRAM: 512 MB

Config XHCI 40M PLL

MediaTek SPI flash driver, SPI clock: 45MHz

spi device id: 1 2 19 4d

find flash: S25FL256S

*** Warning - bad CRC, using default environment

============================================

MediaTek U-Boot Version: 5.0.1.0-6

--------------------------------------------

ASIC MT7621A DualCore (MAC to MT7530 Mode)

DRAM_CONF_FROM: Auto-Detection

DRAM_TYPE: DDR3

DRAM bus: 16 bit

Xtal Mode=3 OCP Ratio=1/3

Flash component: SPI Flash

Date:Aug  7 2017  Time:16:23:41

============================================

icache: sets:256, ways:4, linesz:32, total:32768

dcache: sets:256, ways:4, linesz:32, total:32768

 #### The CPU freq = 900 MHZ ####

 estimate memory size = 512 Mbytes

 Reset MT7530

set LAN/WAN WLLLL

(Re)start USB...

USB0:   mtk-xhci: init hccr be1c0000 and hcor be1c0020 hc_length 32

Register 300010f NbrPorts 3

Starting the controller

USB XHCI 0.96

scanning bus 0 for devices...

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)

Board: MediaTek APSoC DRAM: 512 MB

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)

Board: MediaTek APSoC DRAM: 512 MB

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)

Board: MediaTek APSoC DRAM: 512 MB

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)

Board: MediaTek APSoC DRAM: 512 MB

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)

Board: MediaTek APSoC DRAM: 512 MB

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)

Board: MediaTek APSoC DRAM: 512 MB

So after some more researching, according to https://superuser.com/questions/879374/hdd-power-up-in-standby-prevent-from-spinning-up I believe I have correctly set my disks to power up in standby (PUIS) by validating with:

root@gnubee:~# hdparm -I /dev/sd[a-d] | grep "Power-Up In Standby"

                Power-Up In Standby feature set

                Power-Up In Standby feature set

                Power-Up In Standby feature set

                Power-Up In Standby feature set

root@gnubee:~#

But it still won't boot if all disks are present! I only assume that it's the uboot attempting to spin up all drives. If I unplug 2, it will boot up, and then I can hotplug the two back in and everything works fine from there, but that's a lot of screws.

Is this a uboot problem or a kernel problem? How can I fix it?

[Jernej Jakob]

On Sun, 11 Jun 2023 20:07:19 -0700 (PDT)
Miles Raymond <reuk...@gmail.com> wrote:

>
> But it still won't boot if all disks are present! I only assume that it's
> the uboot attempting to spin up all drives. If I unplug 2, it will boot up,
> and then I can hotplug the two back in and everything works fine from
> there, but that's a lot of screws.
>
> Is this a uboot problem or a kernel problem? How can I fix it?

Do the drives start spinning immediately or do they spin up later in
kernel if you remove enough drives for it to not reset?
Since the reset happens in u-boot, it's not a kernel problem. Either
the drives don't respect the PUIS setting or they still draw enough
power even without the motor to overload the power supply. Check if
there's a bad contact on the power supply socket maybe causing a
voltage drop (if the connector is not the right dimensions or faulty).
Some drives also have a jumper to enable PUIS.

[Miles Raymond]

None of these Seagate drives have physical jumpers, and all use the openSeaChest command to set parameters:

2023-06-12 12:44:19 root@gnubee:~# openSeaChest_Configure -d all --puisFeature enable
==========================================================================================
 openSeaChest_Configure - openSeaChest drive utilities - NVMe Enabled
 Copyright (c) 2014-2023 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 openSeaChest_Configure Version: 2.3.1-4_1_1 MIPS
 Build Date: Mar 28 2023
 Today: Mon Jun 12 12:44:32 2023        User: root
==========================================================================================

/dev/sda - ST2000NE0025-2FL101 - ZDS01LXR - EN02 - ATA
PUIS feature successfully enabled!

/dev/sdb - ST2000VN000-1HJ164 - Z5209KFN - SC60 - ATA
PUIS feature successfully enabled!

/dev/sdc - ST2000VN000-1HJ164 - Z5209VV6 - SC60 - ATA
PUIS feature successfully enabled!

/dev/sdd - ST2000VN000-1HJ164 - Z5209KQ0 - SC60 - ATA
PUIS feature successfully enabled!

/dev/sde - ST2000VN000-1HJ164 - Z5209KPM - SC60 - ATA
PUIS feature successfully enabled!

/dev/sdf - ST2000VN000-1HJ164 - Z5209128 - SC60 - ATA
PUIS feature successfully enabled!

2023-06-12 12:44:32 root@gnubee:~#

As far as I can tell, they all start spinning up around the time the scanning bus 0 for devices...  shows up on the screen, and get interrupted (system power reset?) and try again, over and over.

After comparison to a 'normal' boot and this, I believe you are right that this is a uboot problem, as this should be the beginning of the check for firmware on USB. A normal boot would finish that before showing a menu and booting the kernel:

Starting the controller

USB XHCI 0.96

scanning bus 0 for devices... 2 USB Device(s) found

       scanning bus for storage devices... 0 Storage Device(s) found

 No USB Storage found. Upgrade FW failed!

Please choose the operation:

   1: Load system code to SDRAM via TFTP.

   2: Load system code then write to Flash via TFTP.

   3: Boot system code via Flash (default).

   4: Enter boot command line interface.

   5: Load system code then write to Flash via USB Storage.

   6: Load system code then write to Flash via Httpd.

   9: Load U-Boot code then write to Flash via TFTP.                                                                                                                                                                                       0

3: System Boot system code via Flash.

## Checking image at bc050000 ...

   Image Name:   MIPS libreCMC Linux-4.4.87

   Image Type:   MIPS Linux Kernel Image (lzma compressed)

   Data Size:    1531539 Bytes =  1.5 MB

   Load Address: 80001000

   Entry Point:  80001000

   Verifying Checksum ... OK

   Uncompressing Kernel Image ... OK

No initrd

## Transferring control to Linux (at address 80001000) ...

## Giving linux memsize in MB, 512

Starting kernel ...

I wouldn't think that the SATA ports are included in the uboot scan for storage devices. Are they connected internally on the USB bus?

[Jernej Jakob]

This doesn't happen with my WD20EARS and EARX drives. They stay spun
down until the kernel starts probing SATA devices. I have a 2.5" SSD
in slot 1 with the boot partition. Then four WD20EAR* drives in slots
2-5, slot 6 empty. Maybe in my case it finds the boot partition on SATA
and stops probing the remaining drives?
I don't know anything about how u-boot works in this particular case or
why there are two separate u-boots.

On Mon, 12 Jun 2023 08:53:38 -0700 (PDT)

[Miles Raymond]

I'm only using these Seagate drives because they were free. I'd much prefer WD Greens for larger storage and lower power consumption, which I may do much later on. Interesting that your WD20EARS and EARX drives work as intended with PUIS in the GnuBee. Do they need jumpers for PUIS?

It seems like the only purpose of the

U-Boot 1.1.3 (Aug  7 2017 - 16:23:41)

is to find the flash chip (SPI in GnuBee) and load the next uboot from it?

MediaTek U-Boot Version: 5.0.1.0-6

Maybe the 1.1.3 uboot is somehow included within the SoC hard coded as first execution point? I'd be interested to know if the your kernel in SPI starts spinning up the drives before it starts loading the rest of OS from SATA1's SSD, or if it's intelligent enough to say 'found a root volume and not caring about the rest of the SATA ports for now'. I think you'd need to watch UART closely, or maybe even video record it to replay analyze the moment at which the HDDs start to spin up. It'd be nice to slow the CPU down somewhat for a single boot to catch these timings easier. I saw there was reference to overclocking the CPU up to 1.4GHz - is there a way to dynamically control this or is a set speed compiled into the firmware?