Add regulator-boot-on to meson-sm1-odroid and -hc4 to fix power cycle during boot

[ean365]

Fix power cycle glitch to SD, USB, HDMI, and especially SATA during boot handoff from U-Boot to kernel. This was causing the HDDs to power cycle and do emergency head retract, etc., which is violent and will damage the HDDs over time.

The change to meson-sm1-odroid.dts is appropriate for all meson-sm1-odroid boards 5V regulator.
The changes to meson-sm1-odroid-hc4.dts is specific to the 12V SATA regulators on the Odroid HC4.
They are all tied to GPIOH_8 on the CPU, so all controlled from same pin, and should just never be turned off.

These changes were tested successfully on an Odroid HC4.

Note that this PR in conjunction with #9214 are both needed to save the HDDs from doing emergency head retracts during every boot, reboot, and shutdown. (Previously it was causing two emergency retracts each time.) I kept the PRs separate because technically they stand alone.

Summary by CodeRabbit

• System Configuration
  • Updated 12V power regulator configurations for Odroid SM1 devices, affecting system and SATA power rail behavior during boot.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds the regulator-boot-on property to three 12V power rail regulators in Odroid SM1 device tree source files. The property ensures these regulators are enabled during system boot across two DTS files.

Changes

Cohort / File(s)	Summary
Odroid SM1 Regulator Configuration arch/arm64/boot/dts/amlogic/meson-sm1-odroid-hc4.dts, arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi	Added regulator-boot-on property to p12v-0, p12v-1, and main_12v regulator nodes to enable boot-time activation of 12V power rails

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Suggested reviewers

• igorpecovnik
• rpardini
• pyavitz
• NicoD-SBC
• Tonymac32
• teknoid

Poem

🐰 Three rails now wake with morning's light,
Boot-on flags keep power tight,
The 12V hops with newfound might,
Odroid SM1 shines ever bright! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding regulator-boot-on property to device tree files to fix a power cycle issue during boot on Odroid SM1 boards.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[EvilOlaf]

Does this affect 6.19 only? 6.18 will stay here for a while too I guess since it is latest LTS kernel.

[rpardini]

Hmm. The HC4 DT has been stable for years.
I'd say send this to the (upstream, linux-amlogic) mailing list to get feedback from actual experts.
In general I don't think this makes sense, no matter how your heads retract -- the device tree describes the hardware, not the behavior.

[rpardini]

While you do your research upstream, it would be acceptable if you did an overlay or an extra DT. That way you can get your changes in, not affect other boards, and have it be optional.

[ean365]

In general I don't think this makes sense, no matter how your heads retract -- the device tree describes the hardware, not the behavior.

With all due respect, the device tree absolutely does define behavior. In this case, for instance, regulator-boot-on tells the kernel that it should assume that U-boot already turned it on and that the kernel should initialize it in that same state. Without this explicitly given, the regulator-fixed (fixed.c) code will first initialize it to default OFF before then turning it ON. This is poor behavior for this.

The HC4 DT has been stable for years.

Again, with respect, I don't agree. This is an issue, and it has either been an issue for years, or upstream behavior of the kernel "regulator-fixed" driver has changed since, and they since added the "regulator-boot-on" property to accommodate. Either way it is an appropriate fix.

This also affects other boards, so, no.

Yes, it affects the other meson-sm1-odroid boards. They all have 5V regulators controlled by the GPIOH_8 pin, and it is detrimental to cycle it during boot handoff from U-Boot to kernel. I am certain that it is appropriate for all of these boards, and it is in agreement with and complements the existing "regulator-always-on" properties.

If you are really worried about it, I can do a simple overlay, but I am certain that it makes more sense to update the dts files. I doubt anybody wants to deal with it upstream, though it belongs there -- and in any case Armbian is the best thing going for these older boards. Hardkernel has more or less moved on and is barely supporting them with linux updates.

Please reconsider. Or else, let me know, and I'll put in a PR with a simple overlay.

[ean365]

Does this affect 6.19 only? 6.18 will stay here for a while too I guess since it is latest LTS kernel.

It belongs in 6.18 as well.

[adeepn]

Hmm. The HC4 DT has been stable for years. I'd say send this to the (upstream, linux-amlogic) mailing list to get feedback from actual experts. In general I don't think this makes sense, no matter how your heads retract -- the device tree describes the hardware, not the behavior.

That makes sense. Looking at fixed.c:

	if (config->enabled_at_boot)
		gflags = GPIOD_OUT_HIGH;
	else
		gflags = GPIOD_OUT_LOW;

the parameter controls the initial GPIO state, and if it is already enabled in U-Boot, its state will not change — unlike the case without the boot_on flag (where there would be a quick off-on flap).
If it is not enabled in U-Boot, it will still be enabled, but without any side effects.

[rpardini]

@ean365 you might be right -- I simply don't know enough -- but have seen these kinds of changes "pile up" on the Armbian side of things for years now. The best place to get feedback is on the mailing list. If you're correct, upstream will accept your changes, if not, good reasons and a fun discussion will emerge. With that, you can add a proper patch, with a lore link, that will make the whole thing clear to someone who looks at this in 5 years and wonders. It also benefits the whole community and not only Armbian.

That said, I've half a dozen HC4's running for a few years, and I've no indication of any retracting heads being a problem.

[pyavitz]

regulator-boot-on;

Its just a property that tells the operating system to automatically enable a specific power regulator when the system starts, even if the bootloader didn't turn it on.

Seems like a harmless addition to me. With that said, I don't see why the Odroid C4 would need this. Making it specific to the HC4 would make more sense.

With all that said; creating an overlay would achieve the same goal and not be so intrusive.

[rpardini]

@ean365 seems feedback from my more knowledgeable colleagues proves me wrong here. It is at worst harmless, and at best fixes an issue others might be having, no matter my own experience. Sorry for the initial reaction.

My proposal: make this into an "extra-DT" meson-sm1-odroid-hc4-boot-on-regs.dts (way less work than an overlay - see patch/kernel/archive/meson64-6.19/dt for a few examples). That way we can merge and do actual tests without affecting the default (a simple change in /boot/armbianEnv.txt). If results are positive & sent upstream (I really just would like the lore link, accepted or not...) then we can pick the patch version (also for 6.18).

I did some investigation and you could add these trailers:

Link: https://lore.kernel.org/r/20200506080702.6645-3-narmstrong@baylibre.com
Link: https://lore.kernel.org/r/20210607065435.577334-6-narmstrong@baylibre.com
Fixes: 164147f094ec5d0fc2c2098a888f4b50cf3096a7
Fixes: 326e57518b0dc8789d78e59563afbb3f4107e6e1

which, if accepted, would allow stable to backport it all the way back to 5.15.

[ean365]

Thanks @rpardini, @adeepn, @EvilOlaf, and @pyavitz (and the rest) for your support, not only for Armbian, but also for giving me benefit of the doubt and taking a second look at this PR (and #9214). It's very much appreciated. I'll elevate upstream to linux-amlogic and hope it gets some good attention and discussion. In the meantime, I'll try to follow up on your interim suggestions to have it supported (optionally) in Armbian.

@rpardini, these HC4s are pretty nice for a cheap but capable NAS. If you are running HDDs (spinners, not SSDs) in yours, it is quite possible that you are actually having similar issues and just haven't noticed -- especially if you typically leave them running 24/7/365 and rarely reboot. Try the following on one of your HC4s that has spinning drives and 6.x kernel to confirm (forgive me if you already know all this, but good for others reading the thread)...

1. Install smartmontools.
2. Check SMART status on one or all of the HDDs in the unit: smartctl /dev/sda -x | egrep "Power|Pwr"
   Sample output:

   9 Power_On_Hours          -O--CK   050   050   000    -    36548
 12 Power_Cycle_Count       -O--CK   100   100   000    -    111
192 Power-Off_Retract_Count -O--CK   200   200   000    -    77
Power Cycle Min/Max Temperature:     30/31 Celsius

3. Note the Power_Cycle_Count and especially the Power_Off_Retract_Count at the end of the respective lines. The Power_Off_Retract_Count counts the number of times the HDD has retracted its heads in an emergency because they weren't parked when power was turned off or cycled. (Ideally this number should be zero, or a small number equal to the number of times the power grid went down to your house during a lightning storm, black-out or brown-out.)
4. Shutdown or reboot the HC4, then check SMART status again as above. If the Power_Off_Retract_Count increments, then you are also having a problem and slowly degrading your HDDs. In fact with the HC4, at least with mine, if you don't have both the fixes in this PR and the fix in Add HDD park at shutdown for Odroid HC4 #9214, it will increment by two every time you shutdown and/or reboot -- not good!!!!

@pyavitz, the boot behavior of the GPIOH_8 regulator control pin that this PR attempts to "fix", controls power to the SD Card, USB port, and HDMI on all sm1-odroid boards (at least), C4 included -- and on the HC4, it also controls power to the SATA ports. People may not be "seeing" issues (other than on an HC4 with sensitive HDDs spinning) when power glitches every shutdown/boot, but those are all boot devices (except maybe the HDMI), and glitching their power can not be good nor intentional, especially during the boot process or truly any time -- not harmless unless regulator-boot-on is added. (For what it's worth, I'm an experienced Electrical Engineer and design things like these SBCs and other electronics for a living.)

Thanks again, all. I'll see what I can do. @rpardini, I'll be curious to know if you (or others) confirm the issue on your HC4s...

[rpardini]

Nice, thanks.

• I've one accessible right now (but not reboot-able) that has a large total uptime (multiple years) with very few reboots. It has a very large number of Power-Off_Retract_Count. It is actually exactly the same number as Load_Cycle_Count.

# smartctl /dev/sda -x | egrep -e "Power" -e Load_Cycle_Count
  9 Power_On_Hours          -O--C-   090   090   000    -    72937
 12 Power_Cycle_Count       -O--CK   100   100   000    -    158
192 Power-Off_Retract_Count -O--CK   062   062   000    -    46209
193 Load_Cycle_Count        -O--C-   062   062   000    -    46209

Being a helium, low-power drive, it spins down (remember IntelliPark?). In this context Power-Off_Retract_Count means "number of times the heads are retracted from the platters", safe or not.

• I've access to a remote one which has a regular, non helium disk, and has Power-Off_Retract_Count low and consistent with the number of times it's (solar) power failed.

• I'll de-comission an HC4 that's running on SSDs soon and do more testing if I can find an extra HDD.

[ean365]

Hmmm. That's strange. See the wikipedia article on SMART and read the description for Power Loss Protection Countwhich they point out is the same as Power-Off_Retract_Count. Sounds like your particular drive manufacturer is treating it completely differently than the standard, especially since your Power_Cycle_Count is relatively small -- that number of emergency head retracts is HUGE, if real? Nonetheless, I'm still betting that you and possibly a lot of HC4 owners with HDDs might have been "suffering in silence" for a long time. I'll be interested to know what you find as you dig further with your spare HC4.

[rpardini]

• it's a helium low-power IntelliPark disk.
• 192 is a vendor specific counter, thus can mean anything
• 2nd machine has completely normal, low, consistent-with-actual-power-failures numbers (while having much higher rate of reboots, just out of kernel upgrading) thus not sensitive to the regulator issue.

I don't mean this changes anything about boot-on, just that each disk might behave very differently - yours might be extra-sensitive to the regulator, others not.

[ean365]

Hmmm. That's strange. See the wikipedia article on SMART and read the description for Power Loss Protection Countwhich they point out is the same as Power-Off_Retract_Count. Sounds like your particular drive manufacturer is treating it completely differently than the standard, especially since your Power_Cycle_Count is relatively small -- that number of emergency head retracts is HUGE, if real? Nonetheless, I'm still betting that you and possibly a lot of HC4 owners with HDDs might have been "suffering in silence" for a long time. I'll be interested to know what you find as you dig further with your spare HC4.

Actually, see the description for 1920 xC0 Power-Off_Retract_Count. That's the one being reported (left column of the smartctl output).

[ean365]

• it's a helium low-power IntelliPark disk.

  • 192 is a vendor specific counter, thus can mean anything

  • 2nd machine has completely normal, low, consistent-with-actual-power-failures numbers (while having much higher rate of reboots, just out of kernel upgrading) thus not sensitive to the regulator issue.

I don't mean this changes anything about boot-on, just that each disk might behave very differently - yours might be extra-sensitive to the regulator, others not.

Agreed. Though, one way or the other, HDDs were meant to be placed in standby (heads parked) prior to power down. The heads "float" on a razor-thin cushion of air (or helium) while the disk platters are spinning. They must be retracted before the platters slow down, or the heads will potentially "crash" into the platter and damage it all. So, when power is removed suddenly, without warning, there is no more power to nicely retract the heads. Instead, the drive has a capacitor that it keeps charged up for just such an emergency, and it has to very rapidly yank the heads off the platters and up onto the "parking deck" before that capacitor runs out of energy. This is typically a lot more "violent" then a normal head retract/park, which is why it's frowned upon, and should be avoided if possible, if you want maximum life and reliability out of an HDD.

[ean365]

BTW, one other smartctl property to check is 174 Unexpect_Power_Loss_Ct, (or Unexpected_Pwr_Loss_Cnt, or something like that -- it will be number 174, if your HDD supports it.