[PATCH 0/2] odroid-go-ultra: fix SD boot after a reboot from Linux

[PATCH 0/2] odroid-go-ultra: fix SD boot after a reboot from Linux

[Shigeaki Asai]

On the ODROID-GO Ultra, booting from the SD card fails after a reboot
from Linux. Linux sets vddio_c (the SD card vqmmc supply, RK818 LDO9)
to 3.0V, the value is kept across the warm reboot, and with U-Boot
running the card at 40 MHz, reads fail on some cards. The board then
stops at the U-Boot prompt. A cold boot is fine.

Patch 1 adds the missing RK818 LDO9 to the rk8xx regulator driver, and
patch 2 uses it to set vddio_c to 3.3V on the ODROID-GO Ultra.

Tested on an ODROID-GO Ultra with v2026.07 and a SanDisk Ultra A1 64GB
card: 9 reboots from Linux in a row, all booting from SD. The series
is rebased on current main and builds with
odroid-go-ultra_defconfig.

The patches were written with the help of Claude (claude-opus-5-5).

Shigeaki Asai (2):
  power: regulator: rk8xx: add RK818 LDO9 support
  arm: dts: meson-g12b-odroid-go-ultra-u-boot: set vddio_c to 3.3V

 .../meson-g12b-odroid-go-ultra-u-boot.dtsi    |  8 ++++
 drivers/power/regulator/rk8xx.c               | 46 +++++++++++++++----
 2 files changed, 44 insertions(+), 10 deletions(-)

-- 
2.43.0

Re: [PATCH 1/2] power: regulator: rk8xx: add RK818 LDO9 support

[Quentin Schulz]

Hi Shigeaki Asai,

On 10/10/26 3:32 AM, Shigeaki Asai wrote:
> The RK818 has nine LDOs, but rk818_ldo[] only describes eight, so
> LDO_REG9 indexes past the end of the table. Its voltage reads back as
> garbage and it cannot be enabled or set.
> 
> Unlike LDO1-8, LDO9 is switched from the DCDC enable and sleep
> registers (bit 5), and its voltage selector lives in
> BOOST_LDO9_ON_VSEL/SLP_VSEL with the usual 1.8-3.4V, 100mV range.
> 
> Add the table entry and handle LDO9 in the enable and suspend enable
> helpers.
> 
> This patch was written with the help of Claude (claude-opus-5-5).
> 
> Signed-off-by: Shigeaki Asai <y-asai.0816@docomonet.jp>
> ---
>   drivers/power/regulator/rk8xx.c | 46 ++++++++++++++++++++++++++-------
>   1 file changed, 36 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
> index 88453bb7bdb..cb402c96ec8 100644
> --- a/drivers/power/regulator/rk8xx.c
> +++ b/drivers/power/regulator/rk8xx.c
> @@ -60,6 +60,8 @@
>   #define RK818_BUCK4_VSEL_MASK		0x1f
>   #define RK818_LDO_VSEL_MASK		0x1f
>   #define RK818_LDO3_ON_VSEL_MASK	0xf
> +/* LDO9 is switched from REG_DCDC_EN and REG_SLEEP_SET_OFF1 */
> +#define RK818_LDO9_EN_MASK		BIT(5)
>   #define RK818_BOOST_ON_VSEL_MASK	0xe0
>   #define RK818_USB_ILIM_SEL_MASK		0x0f
>   #define RK818_USB_CHG_SD_VSEL_MASK	0x70
> @@ -297,6 +299,8 @@ static const struct rk8xx_reg_info rk818_ldo[] = {
>   	{  800000, 100000, REG_LDO6_ON_VSEL, REG_LDO6_SLP_VSEL, NA, RK818_LDO_VSEL_MASK, },
>   	{  800000, 100000, REG_LDO7_ON_VSEL, REG_LDO7_SLP_VSEL, NA, RK818_LDO_VSEL_MASK, },
>   	{ 1800000, 100000, REG_LDO8_ON_VSEL, REG_LDO8_SLP_VSEL, NA, RK818_LDO_VSEL_MASK, },
> +	{ 1800000, 100000, REG_BOOST_LDO9_ON_VSEL, REG_BOOST_LDO9_SLP_VSEL, NA,
> +	  RK818_LDO_VSEL_MASK, },

Please stay consistent with the rest of the file where we have 
everything on the same line.

>   };
>   #endif
>   
> @@ -695,8 +699,13 @@ static int _ldo_get_enable(struct udevice *pmic, int ldo)
>   		break;
>   	case RK808_ID:
>   	case RK818_ID:
> -		mask = 1 << ldo;
> -		ret = pmic_reg_read(pmic, REG_LDO_EN);
> +		if (priv->variant == RK818_ID && ldo == 8) {
> +			mask = RK818_LDO9_EN_MASK;
> +			ret = pmic_reg_read(pmic, REG_DCDC_EN);
> +		} else {
> +			mask = 1 << ldo;
> +			ret = pmic_reg_read(pmic, REG_LDO_EN);
> +		}

This is not great, I would prefer to have some additional configuration 
in rk8xx_reg_info instead, but since we do it for many other cases 
already, nothing for you to do on this issue in this patch.

Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thanks!
Quentin

Re: [PATCH 1/2] power: regulator: rk8xx: add RK818 LDO9 support

[Asai, Shigeaki]

Hi Quentin,

Thank you for the review.

On 10/16/26, Quentin Schulz wrote:
> On 10/10/26 3:32 AM, Shigeaki Asai wrote:
>> +	{ 1800000, 100000, REG_BOOST_LDO9_ON_VSEL, REG_BOOST_LDO9_SLP_VSEL, NA,
>> +	  RK818_LDO_VSEL_MASK, },
>
> Please stay consistent with the rest of the file where we have
> everything on the same line.

OK, I will put it on one line in v2.

>> +		if (priv->variant == RK818_ID && ldo == 8) {
>> +			mask = RK818_LDO9_EN_MASK;
>> +			ret = pmic_reg_read(pmic, REG_DCDC_EN);
>> +		} else {
>> +			mask = 1 << ldo;
>> +			ret = pmic_reg_read(pmic, REG_LDO_EN);
>> +		}
>
> This is not great, I would prefer to have some additional configuration
> in rk8xx_reg_info instead, but since we do it for many other cases
> already, nothing for you to do on this issue in this patch.

I understand, thank you.

> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

Thank you. I will keep your Reviewed-by in v2.

I will drop patch 2/2 (see my reply there), so I plan to send v2 of
this patch alone, after waiting a few days for other comments.

Best regards,
Shigeaki Asai

(This reply was written with the help of Claude.)

Re: [PATCH 2/2] arm: dts: meson-g12b-odroid-go-ultra-u-boot: set vddio_c to 3.3V

[Quentin Schulz]

Hi Shigeaki Asai,

On 10/10/26 3:32 AM, Shigeaki Asai wrote:
> vddio_c (RK818 LDO9) is the vqmmc supply of the SD card. Linux picks
> 3.0V for it, the lowest value in the allowed 3.0V-3.3V range, and the
> value is kept across a warm reboot. U-Boot then finds the card at
> 3.0V: it initializes, but data reads at 40 MHz fail on some cards (a
> SanDisk Ultra A1 64GB here), so the kernel cannot be loaded and the
> board drops to the U-Boot prompt. A cold boot works since the PMIC
> starts from its 3.3V default.
> 
> Changing the kernel would not help the kernels already in use, so set
> vddio_c to 3.3V when U-Boot probes the regulator, which happens on
> every boot.
> 

I'll let Neil decide since he's the maintainer of that code, but I don't 
think this is necessarily correct? The spec specifically allows 
2.7-3.6V, c.f. https://www.sdcard.org/developers/sd-standard-overview/.

Moreover, RK3399 Puma has 1.8-3.0V only, and it's been working fine for 
years now (though I haven't checked with that SD card specifically).

What happens if you do NOT use the SD in U-Boot at all and boot straight 
to the Linux kernel, is it also broken in the Linux kernel then? If not, 
then your issue is probably not what your tool output and we may have an 
issue elsewhere (possibly in the MMC subsystem for example).

Cheers,
Quentin

Re: [PATCH 2/2] arm: dts: meson-g12b-odroid-go-ultra-u-boot: set vddio_c to 3.3V

[Asai, Shigeaki]

(Resending to the list only; my first reply was rejected by the list
server. Sorry for the duplicate.)

Hi Quentin,

Thank you for the review.

On 10/16/26, Quentin Schulz wrote:
> I'll let Neil decide since he's the maintainer of that code, but I don't
> think this is necessarily correct? The spec specifically allows
> 2.7-3.6V, c.f. https://www.sdcard.org/developers/sd-standard-overview/.
>
> Moreover, RK3399 Puma has 1.8-3.0V only, and it's been working fine for
> years now (though I haven't checked with that SD card specifically).
>
> What happens if you do NOT use the SD in U-Boot at all and boot straight
> to the Linux kernel, is it also broken in the Linux kernel then? If not,
> then your issue is probably not what your tool output and we may have an
> issue elsewhere (possibly in the MMC subsystem for example).

Linux is fine with this card at 3.0V. Linux itself sets vddio_c to
3.0V, and the system runs from the same card (SD high speed, 50MHz)
with no errors in dmesg.

Following your comments, I tested again without this patch, and I can
no longer reproduce the problem. I tried U-Boot 2025.07, 2026.07 and
2026.10, with and without patch 1/2, and three SD cards, including the
one in the commit message. In about 35 reboots from Linux, U-Boot always
read the card and booted the kernel. At the U-Boot prompt after a
reboot, vddio_c was 3.0V and the SD card ran at 40MHz, so the
conditions were the same as in my original report. I do not know what
was different when I saw the failure.

So I agree that 3.0V is probably not the cause, and I will drop this
patch. If I can reproduce the problem again, I will look at it again,
including the MMC side as you suggested.

Neil, sorry for the noise.

Best regards,
Shigeaki Asai

(This reply was written with the help of Claude.)