* [PATCH 0/2] Attempt to enable MMC on SpacemiT K1 boards
@ 2025-12-15 10:10 Michael Opdenacker
2025-12-15 10:10 ` [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 Michael Opdenacker
2025-12-15 10:10 ` [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and " Michael Opdenacker
0 siblings, 2 replies; 22+ messages in thread
From: Michael Opdenacker @ 2025-12-15 10:10 UTC (permalink / raw)
To: Yixun Lan
Cc: Dan Carpenter, Binbin Zhou, linux-riscv, spacemit,
Michael Opdenacker
The following commits are trying to enable MMC support on the OrangePi RV2
and BananaPi F3 boards.
This is partially supported. On both boards, partitions are
recognized and a filesystem can be read until a certain point.
However, after attempting to read a partition via dd to /dev/null,
this error is shown:
[ 503.868650] Disabling IRQ #21
IRQ #21 was indeed the IRQ for mmc (from /proc/interrupts):
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
21: 390 0 0 0 0 0 0 0 SiFive PLIC 99 Edge mmc1
This "Disabling IRQ" message comes from kernel/irq/spurious.c,
meaning that the IRQ was spurious, i.e. not handled by the driver.
This is confirmed by the number of interrupts:
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
21: 100391 0 0 0 0 0 0 0 SiFive PLIC 99 Edge mmc1
What could be wrong? Are the pin configurations correct?
My understanding of MMC/SD and of the K1 SoC is very limited.
Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
---
Michael Opdenacker (2):
riscv: dts: spacemit: Add i2c buses on OrangePi RV2
riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 12 ++
arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 176 +++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi | 13 ++
arch/riscv/boot/dts/spacemit/k1.dtsi | 10 ++
4 files changed, 211 insertions(+)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251215-k1-boards-add-mmc-843c7d9e5822
Best regards,
--
Michael Opdenacker <michael.opdenacker@rootcommit.com>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-15 10:10 [PATCH 0/2] Attempt to enable MMC on SpacemiT K1 boards Michael Opdenacker @ 2025-12-15 10:10 ` Michael Opdenacker 2025-12-15 12:58 ` Yao Zi ` (2 more replies) 2025-12-15 10:10 ` [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and " Michael Opdenacker 1 sibling, 3 replies; 22+ messages in thread From: Michael Opdenacker @ 2025-12-15 10:10 UTC (permalink / raw) To: Yixun Lan Cc: Dan Carpenter, Binbin Zhou, linux-riscv, spacemit, Michael Opdenacker The OrangePi RV2 board exposes i2c2 and i2c8 buses from the Spacemit K1 SoC. This declares devices present on such buses, in particular the at24 eeprom to store MAC addresses and the regulators attached to the PMIC on i2c8. Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com> --- arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 166 +++++++++++++++++++++++ 1 file changed, 166 insertions(+) diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts index 41dc8e35e6eb..b9b760d7c398 100644 --- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts +++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts @@ -17,6 +17,8 @@ aliases { serial0 = &uart0; ethernet0 = ð0; ethernet1 = ð1; + i2c2 = &i2c2; + i2c8 = &i2c8; }; chosen { @@ -33,6 +35,25 @@ led1 { default-state = "on"; }; }; + + reg_dc_in: dc-in-12v { + compatible = "regulator-fixed"; + regulator-name = "dc_in_12v"; + regulator-min-microvolt = <12000000>; + regulator-max-microvolt = <12000000>; + regulator-boot-on; + regulator-always-on; + }; + + reg_vcc_4v: vcc-4v { + compatible = "regulator-fixed"; + regulator-name = "vcc_4v"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <4000000>; + regulator-boot-on; + regulator-always-on; + vin-supply = <®_dc_in>; + }; }; ð0 { @@ -81,6 +102,151 @@ rgmii1: phy@1 { }; }; +&i2c2 { + pinctrl-0 = <&i2c2_0_cfg>; + pinctrl-names = "default"; + status = "okay"; + + eeprom@50 { + compatible = "atmel,24c02"; + reg = <0x50>; + vcc-supply = <&buck3_1v8>; /* EEPROM_VCC1V8 */ + pagesize = <16>; + read-only; + size = <256>; + + nvmem-layout { + compatible = "onie,tlv-layout"; + + mac-address { + #nvmem-cell-cells = <1>; + }; + + num-macs { + }; + + serial-number { + }; + }; + }; +}; + +&i2c8 { + pinctrl-0 = <&i2c8_cfg>; + pinctrl-names = "default"; + status = "okay"; + + pmic@41 { + compatible = "spacemit,p1"; + reg = <0x41>; + interrupts = <64>; + vin-supply = <®_vcc_4v>; + + regulators { + buck1 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3450000>; + regulator-ramp-delay = <5000>; + regulator-always-on; + }; + + buck2 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3450000>; + regulator-ramp-delay = <5000>; + regulator-always-on; + }; + + buck3_1v8: buck3 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1800000>; + regulator-ramp-delay = <5000>; + regulator-always-on; + }; + + buck4 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3300000>; + regulator-ramp-delay = <5000>; + regulator-always-on; + }; + + buck5 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3450000>; + regulator-ramp-delay = <5000>; + regulator-always-on; + }; + + buck6 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3450000>; + regulator-ramp-delay = <5000>; + regulator-always-on; + }; + + aldo1 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + regulator-boot-on; + }; + + aldo2 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + }; + + aldo3 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + }; + + aldo4 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + }; + + dldo1 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + regulator-boot-on; + }; + + dldo2 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + }; + + dldo3 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + }; + + dldo4 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + regulator-always-on; + }; + + dldo5 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + }; + + dldo6 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + regulator-always-on; + }; + + dldo7 { + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <3400000>; + }; + }; + }; +}; + &pdma { status = "okay"; }; -- 2.43.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-15 10:10 ` [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 Michael Opdenacker @ 2025-12-15 12:58 ` Yao Zi 2025-12-15 15:00 ` Michael Opdenacker 2025-12-16 8:58 ` Javier Martinez Canillas 2025-12-24 14:00 ` Chukun Pan 2 siblings, 1 reply; 22+ messages in thread From: Yao Zi @ 2025-12-15 12:58 UTC (permalink / raw) To: Michael Opdenacker, Yixun Lan Cc: Dan Carpenter, Binbin Zhou, linux-riscv, spacemit On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote: > The OrangePi RV2 board exposes i2c2 and i2c8 buses > from the Spacemit K1 SoC. > > This declares devices present on such buses, in particular > the at24 eeprom to store MAC addresses and the regulators > attached to the PMIC on i2c8. This series is named as "Attempt to enable MMC on SpacemiT K1 boards", what's the relationship between MMC and PMIC/I2C bus? You didn't make use of any regulators in the second patch, either (which seems wrong to me). vmmc-supply specifies the card's power supply. And if you want to enable SDR modes which mandate 1.8v IO level, vqmmc-supply is also necessary for switching between 1.8v and 3.3v. Regards, Yao Zi _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-15 12:58 ` Yao Zi @ 2025-12-15 15:00 ` Michael Opdenacker 2025-12-16 5:37 ` Yao Zi 0 siblings, 1 reply; 22+ messages in thread From: Michael Opdenacker @ 2025-12-15 15:00 UTC (permalink / raw) To: Yao Zi, Yixun Lan Cc: michael.opdenacker, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit Hi Yao Thanks for your helpful questions! On 12/15/25 13:58, Yao Zi wrote: > On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote: >> The OrangePi RV2 board exposes i2c2 and i2c8 buses >> from the Spacemit K1 SoC. >> >> This declares devices present on such buses, in particular >> the at24 eeprom to store MAC addresses and the regulators >> attached to the PMIC on i2c8. > This series is named as "Attempt to enable MMC on SpacemiT K1 boards", > what's the relationship between MMC and PMIC/I2C bus? You didn't make > use of any regulators in the second patch, either (which seems wrong to > me). I expected that declaring the regulators under the PMIC on i2c8 was enough to enable them, but I'm happy to be corrected. > > vmmc-supply specifies the card's power supply. And if you want to enable > SDR modes which mandate 1.8v IO level, vqmmc-supply is also necessary > for switching between 1.8v and 3.3v. I was thinking to get started without the SDR modes first, to make sure basic operation works first. Would that work? Would you have board examples to recommend, with an MMC controller operating in a way similar to the one on SpacemiT K1? Thanks again Michael. -- Michael Opdenacker Root Commit Yocto Project and OpenEmbedded Training course - Learn by doing: https://rootcommit.com/training/yocto/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-15 15:00 ` Michael Opdenacker @ 2025-12-16 5:37 ` Yao Zi 2025-12-16 21:05 ` Michael Opdenacker 0 siblings, 1 reply; 22+ messages in thread From: Yao Zi @ 2025-12-16 5:37 UTC (permalink / raw) To: Michael Opdenacker, Yixun Lan Cc: Dan Carpenter, Binbin Zhou, linux-riscv, spacemit On Mon, Dec 15, 2025 at 03:00:52PM +0000, Michael Opdenacker wrote: > Hi Yao > > Thanks for your helpful questions! > > On 12/15/25 13:58, Yao Zi wrote: > > On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote: > > > The OrangePi RV2 board exposes i2c2 and i2c8 buses > > > from the Spacemit K1 SoC. > > > > > > This declares devices present on such buses, in particular > > > the at24 eeprom to store MAC addresses and the regulators > > > attached to the PMIC on i2c8. > > This series is named as "Attempt to enable MMC on SpacemiT K1 boards", > > what's the relationship between MMC and PMIC/I2C bus? You didn't make > > use of any regulators in the second patch, either (which seems wrong to > > me). > > I expected that declaring the regulators under the PMIC on i2c8 was enough > to enable them, but I'm happy to be corrected. Declaring them doesn't mean enable them. Regulator subsystem maintains a enable reference count, and when it downcounts to zero, the regulator gets disabled. If no driver acquires one regulator, it gets disabled after 30s since the regulator subsystem is initialized, see regulator_init_complete() and regulator_init_complete_work_function. On BPI F3, SD is supplied by buck4 of the PMIC. It's marked as regulator-always-on, so wouldn't be disabled and then cause issues for the SD card, but this doesn't mean it's okay to omit the correct regulator supplier of SD. > > > > vmmc-supply specifies the card's power supply. And if you want to enable > > SDR modes which mandate 1.8v IO level, vqmmc-supply is also necessary > > for switching between 1.8v and 3.3v. > > > I was thinking to get started without the SDR modes first, to make sure > basic operation works first. Would that work? Yes. FYI, for SDR104 mode, you may need to implement some tuning logic[1] as indicated by vendor driver, /* * Tuning is required for SDR50/SDR104, HS200/HS400 cards and * if clock frequency is greater than 100MHz in these modes. */ Though in mainline the eMMC on BPI-F3 already makes use of HS400 mode without tuning. No idea what happened here, or it just happens to work well. Also, the pin controller on K1 SoC seems to have some undocumented registers to select the IO voltage of SD pins, which should be adjusted when switching IO voltage[2]. I think these pins should be implemented in the pinctrl driver, then you could create two pinctrl states, one for 1.8v operation, one for 3.3v, and switch between them through pinctrl_lookup_state() when changing IO voltage. The last thing to mention is that the three MMC controllers on K1 aren't same, The one used for eMMC is the only one that has a phy (both SD and SDIO controllers are marked as SDHCI_QUIRK2_BROKEN_PHY_MODULE[3]), thus have different reset and tuning logics. You probably need to create new compatibles for the SD and SDIO controllers instead of re-using spacemit,k1-sdhci, and write correct sdhci_spacemit_reset() for controllers without phy. This is probably necessary even if you don't implement SDR modes. > Would you have board examples to recommend, with an MMC controller operating > in a way similar to the one on SpacemiT K1? All sd/emmc controllers work similarly... you may want to take a look at mmc-controller-common.yaml for common properties. > Thanks again > Michael. That's it! I've struggled for hours with the MMC driver, and these are all strange points which I've figured out. Hope it's helpful, and feel free to ask me if I am not clear. Regards, Yao Zi [1]: https://gitee.com/spacemit-buildroot/linux-6.6/blob/k1-bl-v2.2.y/drivers/mmc/host/sdhci-of-k1x.c#L1203 [2]: https://gitee.com/spacemit-buildroot/linux-6.6/blob/k1-bl-v2.2.y/drivers/mmc/host/sdhci-of-k1x.c#L923 [3]: https://gitee.com/spacemit-buildroot/linux-6.6/blob/k1-bl-v2.2.y/arch/riscv/boot/dts/spacemit/k1-x_deb1.dts#L670 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-16 5:37 ` Yao Zi @ 2025-12-16 21:05 ` Michael Opdenacker 2025-12-17 15:26 ` Iker Pedrosa 0 siblings, 1 reply; 22+ messages in thread From: Michael Opdenacker @ 2025-12-16 21:05 UTC (permalink / raw) To: Yao Zi, Yixun Lan Cc: michael.opdenacker, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit Hi Yao Thanks a lot for your help and tips, much appreciated! On 12/16/25 06:37, Yao Zi wrote: > On Mon, Dec 15, 2025 at 03:00:52PM +0000, Michael Opdenacker wrote: >> Hi Yao >> >> Thanks for your helpful questions! >> >> On 12/15/25 13:58, Yao Zi wrote: >>> On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote: >>>> The OrangePi RV2 board exposes i2c2 and i2c8 buses >>>> from the Spacemit K1 SoC. >>>> >>>> This declares devices present on such buses, in particular >>>> the at24 eeprom to store MAC addresses and the regulators >>>> attached to the PMIC on i2c8. >>> This series is named as "Attempt to enable MMC on SpacemiT K1 boards", >>> what's the relationship between MMC and PMIC/I2C bus? You didn't make >>> use of any regulators in the second patch, either (which seems wrong to >>> me). >> I expected that declaring the regulators under the PMIC on i2c8 was enough >> to enable them, but I'm happy to be corrected. > Declaring them doesn't mean enable them. Regulator subsystem maintains a > enable reference count, and when it downcounts to zero, the regulator > gets disabled. > > If no driver acquires one regulator, it gets disabled after 30s since > the regulator subsystem is initialized, see regulator_init_complete() > and regulator_init_complete_work_function. > > On BPI F3, SD is supplied by buck4 of the PMIC. It's marked as > regulator-always-on, so wouldn't be disabled and then cause issues for > the SD card, but this doesn't mean it's okay to omit the correct > regulator supplier of SD. Good to know! Surprisingly, when I add this to the "sdhci0" node: vmmc-supply = <&buck4_3v3>; (after creating the label, of course), the device and its partition no longer show up in /proc/partitions! I was hopeful because read-only mode already seems to work, but maybe indeed things are more complicated. > >>> vmmc-supply specifies the card's power supply. And if you want to enable >>> SDR modes which mandate 1.8v IO level, vqmmc-supply is also necessary >>> for switching between 1.8v and 3.3v. >> >> I was thinking to get started without the SDR modes first, to make sure >> basic operation works first. Would that work? > Yes. > > FYI, for SDR104 mode, you may need to implement some tuning logic[1] as > indicated by vendor driver, > > /* > * Tuning is required for SDR50/SDR104, HS200/HS400 cards and > * if clock frequency is greater than 100MHz in these modes. > */ > > Though in mainline the eMMC on BPI-F3 already makes use of HS400 mode > without tuning. No idea what happened here, or it just happens to work > well. > > Also, the pin controller on K1 SoC seems to have some undocumented > registers to select the IO voltage of SD pins, which should be adjusted > when switching IO voltage[2]. > > I think these pins should be implemented in the pinctrl driver, then you > could create two pinctrl states, one for 1.8v operation, one for 3.3v, > and switch between them through pinctrl_lookup_state() when changing IO > voltage. > > The last thing to mention is that the three MMC controllers on K1 aren't > same, The one used for eMMC is the only one that has a phy (both SD and > SDIO controllers are marked as SDHCI_QUIRK2_BROKEN_PHY_MODULE[3]), thus > have different reset and tuning logics. Wow, that's surprising. https://developer.spacemit.com/documentation?token=WZNvwFDkYinYx0k9jzPcMK5WnIe#12.5-sd%2Femmc doesn't seem to mention this (though I didn't check very carefully yet). > > You probably need to create new compatibles for the SD and SDIO > controllers instead of re-using spacemit,k1-sdhci, and write correct > sdhci_spacemit_reset() for controllers without phy. This is probably > necessary even if you don't implement SDR modes. > >> Would you have board examples to recommend, with an MMC controller operating >> in a way similar to the one on SpacemiT K1? > All sd/emmc controllers work similarly... you may want to take a look at > mmc-controller-common.yaml for common properties. Right, I'm already using it :) I'll be patient and try to progress step by step. My time is quite limited these days, so everyone is welcome to try and make this work. Thanks again for everything Cheers Michael. -- Michael Opdenacker Root Commit Yocto Project and OpenEmbedded Training course - Learn by doing: https://rootcommit.com/training/yocto/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-16 21:05 ` Michael Opdenacker @ 2025-12-17 15:26 ` Iker Pedrosa 2025-12-17 16:27 ` Michael Opdenacker 2025-12-17 20:25 ` Javier Martinez Canillas 0 siblings, 2 replies; 22+ messages in thread From: Iker Pedrosa @ 2025-12-17 15:26 UTC (permalink / raw) To: Michael Opdenacker Cc: Yao Zi, Yixun Lan, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit Hi Michael, Based on the discussion and Javier's feedback, to make the SD card work properly, we need to patch the driver to implement the following: Define a separate compatible string: the eMMC slot has a PHY, while SD/SDIO slots do not. We need to differentiate them to apply the correct reset logic (skipping PHY init for SD). Extend the pinctrl driver: support is needed for switching the SD voltage pins from 3.3V to 1.8V. Add tuning logic: this is required at least for SDR modes. If you don't mind, I'll start working on point #1. Feel free to choose any other task. I'll post a patch once I have it working. El mar, 16 dic 2025 a las 22:30, Michael Opdenacker (<michael.opdenacker@rootcommit.com>) escribió: > > Hi Yao > > Thanks a lot for your help and tips, much appreciated! > > On 12/16/25 06:37, Yao Zi wrote: > > On Mon, Dec 15, 2025 at 03:00:52PM +0000, Michael Opdenacker wrote: > >> Hi Yao > >> > >> Thanks for your helpful questions! > >> > >> On 12/15/25 13:58, Yao Zi wrote: > >>> On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote: > >>>> The OrangePi RV2 board exposes i2c2 and i2c8 buses > >>>> from the Spacemit K1 SoC. > >>>> > >>>> This declares devices present on such buses, in particular > >>>> the at24 eeprom to store MAC addresses and the regulators > >>>> attached to the PMIC on i2c8. > >>> This series is named as "Attempt to enable MMC on SpacemiT K1 boards", > >>> what's the relationship between MMC and PMIC/I2C bus? You didn't make > >>> use of any regulators in the second patch, either (which seems wrong to > >>> me). > >> I expected that declaring the regulators under the PMIC on i2c8 was enough > >> to enable them, but I'm happy to be corrected. > > Declaring them doesn't mean enable them. Regulator subsystem maintains a > > enable reference count, and when it downcounts to zero, the regulator > > gets disabled. > > > > If no driver acquires one regulator, it gets disabled after 30s since > > the regulator subsystem is initialized, see regulator_init_complete() > > and regulator_init_complete_work_function. > > > > On BPI F3, SD is supplied by buck4 of the PMIC. It's marked as > > regulator-always-on, so wouldn't be disabled and then cause issues for > > the SD card, but this doesn't mean it's okay to omit the correct > > regulator supplier of SD. > > Good to know! > Surprisingly, when I add this to the "sdhci0" node: > > vmmc-supply = <&buck4_3v3>; > > (after creating the label, of course), the device and its partition no > longer show up in /proc/partitions! > > I was hopeful because read-only mode already seems to work, but maybe > indeed things are more complicated. > > > >>> vmmc-supply specifies the card's power supply. And if you want to enable > >>> SDR modes which mandate 1.8v IO level, vqmmc-supply is also necessary > >>> for switching between 1.8v and 3.3v. > >> > >> I was thinking to get started without the SDR modes first, to make sure > >> basic operation works first. Would that work? > > Yes. > > > > FYI, for SDR104 mode, you may need to implement some tuning logic[1] as > > indicated by vendor driver, > > > > /* > > * Tuning is required for SDR50/SDR104, HS200/HS400 cards and > > * if clock frequency is greater than 100MHz in these modes. > > */ > > > > Though in mainline the eMMC on BPI-F3 already makes use of HS400 mode > > without tuning. No idea what happened here, or it just happens to work > > well. > > > > Also, the pin controller on K1 SoC seems to have some undocumented > > registers to select the IO voltage of SD pins, which should be adjusted > > when switching IO voltage[2]. > > > > I think these pins should be implemented in the pinctrl driver, then you > > could create two pinctrl states, one for 1.8v operation, one for 3.3v, > > and switch between them through pinctrl_lookup_state() when changing IO > > voltage. > > > > The last thing to mention is that the three MMC controllers on K1 aren't > > same, The one used for eMMC is the only one that has a phy (both SD and > > SDIO controllers are marked as SDHCI_QUIRK2_BROKEN_PHY_MODULE[3]), thus > > have different reset and tuning logics. > > Wow, that's surprising. > https://developer.spacemit.com/documentation?token=WZNvwFDkYinYx0k9jzPcMK5WnIe#12.5-sd%2Femmc > doesn't seem to mention this (though I didn't check very carefully yet). > > > > You probably need to create new compatibles for the SD and SDIO > > controllers instead of re-using spacemit,k1-sdhci, and write correct > > sdhci_spacemit_reset() for controllers without phy. This is probably > > necessary even if you don't implement SDR modes. > > > >> Would you have board examples to recommend, with an MMC controller operating > >> in a way similar to the one on SpacemiT K1? > > All sd/emmc controllers work similarly... you may want to take a look at > > mmc-controller-common.yaml for common properties. > > Right, I'm already using it :) > > I'll be patient and try to progress step by step. My time is quite > limited these days, so everyone is welcome to try and make this work. > Thanks again for everything > Cheers > Michael. > > -- > Michael Opdenacker > Root Commit > Yocto Project and OpenEmbedded Training course - Learn by doing: > https://rootcommit.com/training/yocto/ > > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-17 15:26 ` Iker Pedrosa @ 2025-12-17 16:27 ` Michael Opdenacker 2025-12-17 22:10 ` Johannes Erdfelt 2025-12-17 20:25 ` Javier Martinez Canillas 1 sibling, 1 reply; 22+ messages in thread From: Michael Opdenacker @ 2025-12-17 16:27 UTC (permalink / raw) To: Iker Pedrosa Cc: michael.opdenacker, Yao Zi, Yixun Lan, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit Hi Iker On 12/17/25 16:26, Iker Pedrosa wrote: > Hi Michael, > > Based on the discussion and Javier's feedback, to make the SD card > work properly, we need to patch the driver to implement the following: > > Define a separate compatible string: the eMMC slot has a PHY, while > SD/SDIO slots do not. We need to differentiate them to apply the > correct reset logic (skipping PHY init for SD). > Extend the pinctrl driver: support is needed for switching the SD > voltage pins from 3.3V to 1.8V. > Add tuning logic: this is required at least for SDR modes. > > If you don't mind, I'll start working on point #1. Feel free to choose > any other task. > > I'll post a patch once I have it working. Wow, that would be awesome indeed, all the more as my time is quite limited. Please do! I'll have a look at other aspects if I can, like USB and PCI Express. Note that I have an eMMC module if you have code to test, and I have the BananaPI F3 too which also has eMMC. Happy to work together :) Cheers Michael. -- Michael Opdenacker Root Commit Yocto Project and OpenEmbedded Training course - Learn by doing: https://rootcommit.com/training/yocto/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-17 16:27 ` Michael Opdenacker @ 2025-12-17 22:10 ` Johannes Erdfelt 2025-12-18 5:19 ` Michael Opdenacker 0 siblings, 1 reply; 22+ messages in thread From: Johannes Erdfelt @ 2025-12-17 22:10 UTC (permalink / raw) To: Michael Opdenacker Cc: Iker Pedrosa, Yao Zi, Yixun Lan, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit On Wed, Dec 17, 2025, Michael Opdenacker <michael.opdenacker@rootcommit.com> wrote: > Wow, that would be awesome indeed, all the more as my time is quite limited. > Please do! > I'll have a look at other aspects if I can, like USB and PCI Express. If it helps, I have PCIe working on my RV2 board. I based it on the BPI F3 patches but RV2 also requires enabling 3.3v for the M.2 slot. I haven't ever submitted a DT patch before, but I'd be willing to clean up my patch. JE _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-17 22:10 ` Johannes Erdfelt @ 2025-12-18 5:19 ` Michael Opdenacker 2025-12-18 5:25 ` Michael Opdenacker 0 siblings, 1 reply; 22+ messages in thread From: Michael Opdenacker @ 2025-12-18 5:19 UTC (permalink / raw) To: Johannes Erdfelt Cc: michael.opdenacker, Iker Pedrosa, Yao Zi, Yixun Lan, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit Hi Johannes On 12/17/25 23:10, Johannes Erdfelt wrote: > On Wed, Dec 17, 2025, Michael Opdenacker <michael.opdenacker@rootcommit.com> wrote: >> Wow, that would be awesome indeed, all the more as my time is quite limited. >> Please do! >> I'll have a look at other aspects if I can, like USB and PCI Express. > If it helps, I have PCIe working on my RV2 board. I based it on the BPI > F3 patches but RV2 also requires enabling 3.3v for the M.2 slot. > Great, please share... I needed this too on Orange Pi R2S to enable the two 2.5 Gb Ethernet links :) > > I haven't ever submitted a DT patch before, but I'd be willing to clean > up my patch. Sharing is always a great opportunity to learn. Here are my raw notes about the topic: * Most importantly, run scripts/checkpatch.pl on your patches before sending them * Very important too, run "make dtbs" and then "make dtbs_check" to validate your changes See https://static.sched.com/hosted_files/ossjapan2025/59/Status of DTS Validation in Linux Kernel - Krzysztof Kozlowski%2C Qualcomm - OSSJ 2025.pdf <https://static.sched.com/hosted_files/ossjapan2025/59/Status%20of%20DTS%20Validation%20in%20Linux%20Kernel%20-%20Krzysztof%20Kozlowski%2C%20Qualcomm%20-%20OSSJ%202025.pdf> for reasons why. * You won't be embarrassed if you already passed these first two checks ;) * Follow the DTS coding style: https://docs.kernel.org/devicetree/bindings/dts-coding-style.html - Nodes on any bus should be in ascending address order - If no address, order alphanumerically by node name - "status" right before child nodes - properties of the same type (like aliases) in "natural" order (1, 3, 12...) * Don't enable features as static (default y) in Kconfig, unless you have a very strong reason. Otherwise, it makes the kernel bigger for everyone else. * When you submit first DTS support for one board, submit the DTS in one commit. https://lore.kernel.org/all/20251010-confider-raven-0ad7a810e5de@spud/ * If someone replies "2 < v" to you, it means "Please send v2" * In commit messages, don't comment on where the DT is coming from (device tree is similar to...) * References should be like this, followed by a blank line before "Signed-off-by" [1] https://tinker-board.asus.com/series/tinker-board-3.html [2] https://tinker-board.asus.com/series/tinker-board-3s.html * Keep track of Reviewed-by and Tested-by tags (using b4 to manage your branch and submissions will help tremendously) https://b4.docs.kernel.org/en/latest/ * Explain WHY you're doing something in a commit message (Krzysztof Kozlowski) * If anything is wrong or can be improved, we (the Linux kernel community) will be delighted to guide you, so that we end up with some code that's easy for others to maintain and expand. * Special gratitude to Krzysztof Kozlowski for always being there to help on DT patches :) I'm also available to test your patches, as I have Banana Pi F3, Orange Pi RV2 and R2S. I hope you can do this in the next days, because there's a great window in the next days for contribution, when work slows down during the holidays :) Thanks in advance Cheers Michael. -- Michael Opdenacker Root Commit Yocto Project and OpenEmbedded Training course - Learn by doing: https://rootcommit.com/training/yocto/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-18 5:19 ` Michael Opdenacker @ 2025-12-18 5:25 ` Michael Opdenacker 2025-12-18 9:49 ` Iker Pedrosa 0 siblings, 1 reply; 22+ messages in thread From: Michael Opdenacker @ 2025-12-18 5:25 UTC (permalink / raw) To: Johannes Erdfelt Cc: michael.opdenacker, Iker Pedrosa, Yao Zi, Yixun Lan, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit On 12/18/25 06:19, Michael Opdenacker wrote: > > * You won't be embarrassed if you already passed these first two > checks ;) > * I'm the one getting embarrassed 😅. Copying and pasting from Joplin notes into Thunderbird really made my reply ugly... This made me forget a quite important rule: send the patches to yourself first: b4 send --reflect Michael. -- Michael Opdenacker Root Commit Yocto Project and OpenEmbedded Training course - Learn by doing: https://rootcommit.com/training/yocto/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-18 5:25 ` Michael Opdenacker @ 2025-12-18 9:49 ` Iker Pedrosa 2025-12-19 11:29 ` Yixun Lan 0 siblings, 1 reply; 22+ messages in thread From: Iker Pedrosa @ 2025-12-18 9:49 UTC (permalink / raw) To: Michael Opdenacker Cc: Johannes Erdfelt, Yao Zi, Yixun Lan, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit Hi Michael, Yao, Javier, Johannes, Thanks everyone for the great discussion and the guidance. First of all, I’d like to clarify a point regarding my previous email to avoid any confusion: the detailed technical breakdown and pointers were provided by Yao here in the thread. My mention of Javier was regarding a separate offline conversation we had earlier. Both contributions have been essential to understanding why the SD card is currently failing. Given that we are all a bit tight on time, I think it would be best to split the work into separate tasks so we can make progress in parallel. Based on the feedback, here is the roadmap: 1. Define a separate compatible string: the eMMC slot has a PHY, while SD/SDIO slots do not. We need to differentiate them to apply the correct reset logic (skipping PHY init for SD). 2. Extend the pinctrl driver: support is needed for switching the SD voltage pins from 3.3V to 1.8V. 3. Add tuning logic: this is required at least for SDR modes. Since I’ll be focusing on the driver/reset logic (1), is there anyone else willing to pick up the pinctrl (2) or the tuning (3)? Looking forward to working together on this. El jue, 18 dic 2025 a las 6:25, Michael Opdenacker (<michael.opdenacker@rootcommit.com>) escribió: > > > On 12/18/25 06:19, Michael Opdenacker wrote: > > > > * You won't be embarrassed if you already passed these first two > > checks ;) > > * > > I'm the one getting embarrassed 😅. Copying and pasting from Joplin > notes into Thunderbird really made my reply ugly... > > This made me forget a quite important rule: send the patches to yourself > first: > b4 send --reflect > > Michael. > > -- > Michael Opdenacker > Root Commit > Yocto Project and OpenEmbedded Training course - Learn by doing: > https://rootcommit.com/training/yocto/ > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-18 9:49 ` Iker Pedrosa @ 2025-12-19 11:29 ` Yixun Lan 2025-12-20 2:22 ` Yao Zi 0 siblings, 1 reply; 22+ messages in thread From: Yixun Lan @ 2025-12-19 11:29 UTC (permalink / raw) To: Iker Pedrosa Cc: Michael Opdenacker, Johannes Erdfelt, Yao Zi, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit Hi Iker, thanks for pushing this, I have few comments On 10:49 Thu 18 Dec , Iker Pedrosa wrote: > Hi Michael, Yao, Javier, Johannes, > > Thanks everyone for the great discussion and the guidance. > > First of all, I’d like to clarify a point regarding my previous email > to avoid any confusion: the detailed technical breakdown and pointers > were provided by Yao here in the thread. My mention of Javier was > regarding a separate offline conversation we had earlier. Both > contributions have been essential to understanding why the SD card is > currently failing. > > Given that we are all a bit tight on time, I think it would be best to > split the work into separate tasks so we can make progress in > parallel. Based on the feedback, here is the roadmap: > > 1. Define a separate compatible string: the eMMC slot has a PHY, while > SD/SDIO slots do not. We need to differentiate them to apply the > correct reset logic (skipping PHY init for SD). I agree, separate compatibles sounds more feasibile, vendor reuse macro of MMC_CAP2_NO_{SD,SDIO,MMC} to differentiate the controller which is kind of unmaintainable > 2. Extend the pinctrl driver: support is needed for switching the SD > voltage pins from 3.3V to 1.8V. we probably could leave pinctrl for now or take a look at it later when really necessary, the default pin settings should work for most cases, besides, vendor is also starting to drop two pinctrl state implementation (the normal vs fast ..) for 3.3v to 1.8v switch, there is one MMC1_IO_REG to control it, and we do need to implement a _voltage_switch() function and it's in another aib io space.. > 3. Add tuning logic: this is required at least for SDR modes. > right, especially for high speed clock > Since I’ll be focusing on the driver/reset logic (1), is there anyone the reset logic is also needed for K3 SoC, so I'd like to get it added early, I could get a patch for it during the weekend if you don't mind, or can leave it to you if you will do it shortly.. > else willing to pick up the pinctrl (2) or the tuning (3)? > I do want to work on SD/SDIO support, but for now I need to push clock/pinctrl for K3 SoC first, then will have time to take a look > Looking forward to working together on this. > great! -- Yixun Lan (dlan) _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-19 11:29 ` Yixun Lan @ 2025-12-20 2:22 ` Yao Zi 0 siblings, 0 replies; 22+ messages in thread From: Yao Zi @ 2025-12-20 2:22 UTC (permalink / raw) To: Yixun Lan, Iker Pedrosa Cc: Michael Opdenacker, Johannes Erdfelt, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit On Fri, Dec 19, 2025 at 07:29:24PM +0800, Yixun Lan wrote: > Hi Iker, > > thanks for pushing this, I have few comments > > On 10:49 Thu 18 Dec , Iker Pedrosa wrote: > > Hi Michael, Yao, Javier, Johannes, > > > > Thanks everyone for the great discussion and the guidance. ... > > 2. Extend the pinctrl driver: support is needed for switching the SD > > voltage pins from 3.3V to 1.8V. > we probably could leave pinctrl for now or take a look at it later when > really necessary, the default pin settings should work for most cases, > besides, vendor is also starting to drop two pinctrl state implementation > (the normal vs fast ..) > > for 3.3v to 1.8v switch, there is one MMC1_IO_REG to control it, and > we do need to implement a _voltage_switch() function > and it's in another aib io space.. Note the MMC1_IO_REG (0xd401_e81c) stays right in the Pad Configuration region (0xd401_e000, length 0xc00) as stated in the address mapping of TRM. So it's not another io space, it's right the pin controller. This makes me believe it's an undocumented pinctrl register, in which case it's pretty natural to implement the switch logic through pinctrl interface. Seems I forgot to mention one thing: there are mysterious "asfar" and "assar" registers in APBC region which are written 0xbaba and 0xeb10 during voltage switch process. I've looked through the TRM and found they aren't documented, either. But handling of them should be easy, since the whole APBC region is registered as a syscon, though it will still be helpful to know their effects... Regards, Yao Zi _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-17 15:26 ` Iker Pedrosa 2025-12-17 16:27 ` Michael Opdenacker @ 2025-12-17 20:25 ` Javier Martinez Canillas 1 sibling, 0 replies; 22+ messages in thread From: Javier Martinez Canillas @ 2025-12-17 20:25 UTC (permalink / raw) To: Iker Pedrosa, Michael Opdenacker Cc: Yao Zi, Yixun Lan, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit Iker Pedrosa <ikerpedrosam@gmail.com> writes: Hello Iker, > Hi Michael, > > Based on the discussion and Javier's feedback, to make the SD card > work properly, we need to patch the driver to implement the following: > Just one correction: it was Yao who gave that feedback, not me. > Define a separate compatible string: the eMMC slot has a PHY, while > SD/SDIO slots do not. We need to differentiate them to apply the > correct reset logic (skipping PHY init for SD). > Extend the pinctrl driver: support is needed for switching the SD > voltage pins from 3.3V to 1.8V. > Add tuning logic: this is required at least for SDR modes. > I think you are correct with all of these. > If you don't mind, I'll start working on point #1. Feel free to choose > any other task. > > I'll post a patch once I have it working. > As Micheal said, that would be great. Please let me know if I can help in any way since I also have a board to test (Milk-V Jupiter with a MMC slot). -- Best regards, Javier Martinez Canillas Core Platforms Red Hat _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-15 10:10 ` [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 Michael Opdenacker 2025-12-15 12:58 ` Yao Zi @ 2025-12-16 8:58 ` Javier Martinez Canillas 2025-12-24 14:00 ` Chukun Pan 2 siblings, 0 replies; 22+ messages in thread From: Javier Martinez Canillas @ 2025-12-16 8:58 UTC (permalink / raw) To: Michael Opdenacker, Yixun Lan Cc: Dan Carpenter, Binbin Zhou, linux-riscv, spacemit, Michael Opdenacker Michael Opdenacker <michael.opdenacker@rootcommit.com> writes: Hello Michael, > The OrangePi RV2 board exposes i2c2 and i2c8 buses > from the Spacemit K1 SoC. > > This declares devices present on such buses, in particular > the at24 eeprom to store MAC addresses and the regulators > attached to the PMIC on i2c8. > As Yao explained, there is still work needed to make the MMC work on K1 based boards. I also tried the same on my Milk-V Jupiter and found issues. I believe though that this patch has merits on its own and could land regardless of the MMC support. That's why I also posted a similar change for the Milk-V Jupiter board: https://lore.kernel.org/lkml/20251206134532.1741648-1-javierm@redhat.com/ My changes are identical to the Banana Pi BPI-F3 and I see yours too, so it seems all these boards are based on a K1 SoC reference design. > Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com> > --- > arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 166 +++++++++++++++++++++++ > 1 file changed, 166 insertions(+) > Personally, I would split the changes in separate patches as I did on my series. But I guess it is also OK to have it as a single patch as you did: Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 2025-12-15 10:10 ` [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 Michael Opdenacker 2025-12-15 12:58 ` Yao Zi 2025-12-16 8:58 ` Javier Martinez Canillas @ 2025-12-24 14:00 ` Chukun Pan 2 siblings, 0 replies; 22+ messages in thread From: Chukun Pan @ 2025-12-24 14:00 UTC (permalink / raw) To: michael.opdenacker; +Cc: dan.carpenter, dlan, linux-riscv, spacemit, Chukun Pan Hi, > + reg_dc_in: dc-in-12v { > + compatible = "regulator-fixed"; > + regulator-name = "dc_in_12v"; > + regulator-min-microvolt = <12000000>; > + regulator-max-microvolt = <12000000>; > + regulator-boot-on; > + regulator-always-on; > + }; This does not match the schematic. (vcc_5v0 instead of dc-in-12v) https://drive.google.com/drive/folders/1pcI_U0C3VJKTCg8A1zj08CwNbohnONSR > + > + reg_vcc_4v: vcc-4v { > + compatible = "regulator-fixed"; > + regulator-name = "vcc_4v"; > + regulator-min-microvolt = <4000000>; > + regulator-max-microvolt = <4000000>; > + regulator-boot-on; > + regulator-always-on; > + vin-supply = <®_dc_in>; > + }; It is also missing the regulator prefix. So it should look like this: ``` vcc_5v0: regulator-vcc-5v0 { compatible = "regulator-fixed"; regulator-name = "vcc_5v0"; regulator-always-on; regulator-boot-on; regulator-min-microvolt = <5000000>; regulator-max-microvolt = <5000000>; }; vcc4v0: regulator-vcc4v0 { compatible = "regulator-fixed"; regulator-name = "vcc4v0"; regulator-always-on; regulator-boot-on; regulator-min-microvolt = <4000000>; regulator-max-microvolt = <4000000>; vin-supply = <&vcc_5v0>; }; ``` > +&i2c2 { > + pinctrl-0 = <&i2c2_0_cfg>; > + pinctrl-names = "default"; > + status = "okay"; > + > + eeprom@50 { > + compatible = "atmel,24c02"; > + reg = <0x50>; > + vcc-supply = <&buck3_1v8>; /* EEPROM_VCC1V8 */ vcc-supply should be placed after size. > + pagesize = <16>; > + read-only; > + size = <256>; > + > + nvmem-layout { > + compatible = "onie,tlv-layout"; > + > + mac-address { > + #nvmem-cell-cells = <1>; > + }; > + > + num-macs { > + }; > + > + serial-number { > + }; From vendor uboot: => tlv_eeprom TLV: 0 [ 6.991] TlvInfo Header: [ 6.992] Id String: TlvInfo [ 6.995] Version: 1 [ 6.997] Total Length: 38 [ 7.000] TLV Name Code Len Value [ 7.004] -------------------- ---- --- ----- [ 7.009] Base MAC Address 0x24 6 xxxxx [ 7.014] MAC Addresses 0x2A 2 2 [ 7.018] Unknown 0x41 1 0x01 [ 7.022] Product Name 0x21 15 x1_orangepi-rv2 [ 7.027] CRC-32 0xFE 4 0x... [ 7.031] Checksum is valid. There is no serial-number (0x23) in the EEPROM. Does "product-name" need to be described here? > + }; > + }; Thanks, Chukun _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2 2025-12-15 10:10 [PATCH 0/2] Attempt to enable MMC on SpacemiT K1 boards Michael Opdenacker 2025-12-15 10:10 ` [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 Michael Opdenacker @ 2025-12-15 10:10 ` Michael Opdenacker 2025-12-15 12:46 ` Yao Zi 2025-12-24 15:00 ` Chukun Pan 1 sibling, 2 replies; 22+ messages in thread From: Michael Opdenacker @ 2025-12-15 10:10 UTC (permalink / raw) To: Yixun Lan Cc: Dan Carpenter, Binbin Zhou, linux-riscv, spacemit, Michael Opdenacker This introduces a new sdhci0 node and enables it for the BananaPI F3 and OrangePi RV2 boards. Note that card detect is marked as broken in the driver (SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk), therefore removing the card while the system is running won't have any effect. Signed-off-by: Michael Opdenacker <michael.opdenacker@rootcommit.com> --- arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 12 ++++++++++++ arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts | 10 ++++++++++ arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi | 13 +++++++++++++ arch/riscv/boot/dts/spacemit/k1.dtsi | 10 ++++++++++ 4 files changed, 45 insertions(+) diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts index 02f218a16318..1ff758115496 100644 --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts @@ -16,6 +16,8 @@ aliases { serial0 = &uart0; i2c2 = &i2c2; i2c8 = &i2c8; + mmc0 = &emmc; + mmc1 = &sdhci0; }; chosen { @@ -264,6 +266,16 @@ dldo7 { }; }; +&sdhci0 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_cfg>; + bus-width = <4>; + cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>; + cd-inverted; + no-sdio; + status = "okay"; +}; + &uart0 { pinctrl-names = "default"; pinctrl-0 = <&uart0_2_cfg>; diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts index b9b760d7c398..7204f419c856 100644 --- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts +++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts @@ -247,6 +247,16 @@ dldo7 { }; }; +&sdhci0 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc1_cfg>; + bus-width = <4>; + cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>; + cd-inverted; + no-sdio; + status = "okay"; +}; + &pdma { status = "okay"; }; diff --git a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi index e922e05ff856..87e84a880fbc 100644 --- a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi +++ b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi @@ -537,4 +537,17 @@ pwm14-1-pins { drive-strength = <32>; }; }; + + mmc1_cfg: mmc1-cfg { + mmc1-pins { + pinmux = <K1_PADCONF(92, 0)>, /* mmc1_d3 */ + <K1_PADCONF(91, 0)>, /* mmc1_d2 */ + <K1_PADCONF(90, 0)>, /* mmc1_d1 */ + <K1_PADCONF(89, 0)>, /* mmc1_d0 */ + <K1_PADCONF(113, 0)>, /* mmc1_cmd */ + <K1_PADCONF(114, 0)>; /* mmc1_clk */ + bias-pull-up = <1>; + drive-strength = <21>; + }; + }; }; diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi index 7818ca4979b6..a5b7d7c8c066 100644 --- a/arch/riscv/boot/dts/spacemit/k1.dtsi +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi @@ -987,6 +987,16 @@ emmc: mmc@d4281000 { interrupts = <101>; status = "disabled"; }; + + sdhci0: mmc@d4280000 { + compatible = "spacemit,k1-sdhci"; + reg = <0x0 0xd4280000 0x0 0x200>; + clocks = <&syscon_apmu CLK_SDH_AXI>, + <&syscon_apmu CLK_SDH0>; + clock-names = "core", "io"; + interrupts = <99>; + status = "disabled"; + }; }; }; }; -- 2.43.0 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2 2025-12-15 10:10 ` [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and " Michael Opdenacker @ 2025-12-15 12:46 ` Yao Zi 2025-12-15 13:58 ` Michael Opdenacker 2025-12-24 15:00 ` Chukun Pan 1 sibling, 1 reply; 22+ messages in thread From: Yao Zi @ 2025-12-15 12:46 UTC (permalink / raw) To: Michael Opdenacker, Yixun Lan Cc: Dan Carpenter, Binbin Zhou, linux-riscv, spacemit On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote: > This introduces a new sdhci0 node and enables it > for the BananaPI F3 and OrangePi RV2 boards. > > Note that card detect is marked as broken in the driver > (SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk), therefore removing the card > while the system is running won't have any effect. This description looks suspicious: SDHCI_QUIRK_BROKEN_CARD_DETECTION doesn't break hotplug. It only informs sdhci core to actively poll for card status, instead of relying on interrupts for status change. ... > diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi > index 7818ca4979b6..a5b7d7c8c066 100644 > --- a/arch/riscv/boot/dts/spacemit/k1.dtsi > +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi > @@ -987,6 +987,16 @@ emmc: mmc@d4281000 { > interrupts = <101>; > status = "disabled"; > }; > + > + sdhci0: mmc@d4280000 { > + compatible = "spacemit,k1-sdhci"; > + reg = <0x0 0xd4280000 0x0 0x200>; > + clocks = <&syscon_apmu CLK_SDH_AXI>, > + <&syscon_apmu CLK_SDH0>; > + clock-names = "core", "io"; > + interrupts = <99>; > + status = "disabled"; > + }; This node should be probably put before the emmc node, since it comes with lower address. Regards, Yao Zi _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2 2025-12-15 12:46 ` Yao Zi @ 2025-12-15 13:58 ` Michael Opdenacker 0 siblings, 0 replies; 22+ messages in thread From: Michael Opdenacker @ 2025-12-15 13:58 UTC (permalink / raw) To: Yao Zi Cc: michael.opdenacker, Dan Carpenter, Binbin Zhou, linux-riscv, spacemit, Yixun Lan Hi Yao Thanks a lot for the review! On 12/15/25 13:46, Yao Zi wrote: > On Mon, Dec 15, 2025 at 10:10:14AM +0000, Michael Opdenacker wrote: >> This introduces a new sdhci0 node and enables it >> for the BananaPI F3 and OrangePi RV2 boards. >> >> Note that card detect is marked as broken in the driver >> (SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk), therefore removing the card >> while the system is running won't have any effect. > This description looks suspicious: SDHCI_QUIRK_BROKEN_CARD_DETECTION > doesn't break hotplug. It only informs sdhci core to actively poll for > card status, instead of relying on interrupts for status change. I must have misinterpreted the code. I modified the description to just mention that card detection currently doesn't work with these changes. > > ... > >> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi >> index 7818ca4979b6..a5b7d7c8c066 100644 >> --- a/arch/riscv/boot/dts/spacemit/k1.dtsi >> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi >> @@ -987,6 +987,16 @@ emmc: mmc@d4281000 { >> interrupts = <101>; >> status = "disabled"; >> }; >> + >> + sdhci0: mmc@d4280000 { >> + compatible = "spacemit,k1-sdhci"; >> + reg = <0x0 0xd4280000 0x0 0x200>; >> + clocks = <&syscon_apmu CLK_SDH_AXI>, >> + <&syscon_apmu CLK_SDH0>; >> + clock-names = "core", "io"; >> + interrupts = <99>; >> + status = "disabled"; >> + }; > This node should be probably put before the emmc node, since it comes > with lower address. Oops, correct in my branch. Thanks! Cheers Michael. -- Michael Opdenacker Root Commit Yocto Project and OpenEmbedded Training course - Learn by doing: https://rootcommit.com/training/yocto/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2 2025-12-15 10:10 ` [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and " Michael Opdenacker 2025-12-15 12:46 ` Yao Zi @ 2025-12-24 15:00 ` Chukun Pan 2025-12-29 10:14 ` Javier Martinez Canillas 1 sibling, 1 reply; 22+ messages in thread From: Chukun Pan @ 2025-12-24 15:00 UTC (permalink / raw) To: michael.opdenacker; +Cc: dan.carpenter, dlan, linux-riscv, spacemit, Chukun Pan Hi, > +&sdhci0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&mmc1_cfg>; It would be better to arrange them in alphabetical order. (Place pinctrl below no-sdio) > + bus-width = <4>; > + cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>; It seems that "cap-sd-highspeed" is missing? > + cd-inverted; > + no-sdio; > + status = "okay"; > +}; > + sdhci0: mmc@d4280000 { An immature idea. Would naming nodes this way be better? sdmmc: mmc@d4280000 sdio: mmc@d4280800 emmc: mmc@d4281000 This seems to fit the description here better: https://bianbu-linux.spacemit.com/en/device/peripheral_driver/SDHC/#dts-configuration Thanks, Chukun _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and OrangePi RV2 2025-12-24 15:00 ` Chukun Pan @ 2025-12-29 10:14 ` Javier Martinez Canillas 0 siblings, 0 replies; 22+ messages in thread From: Javier Martinez Canillas @ 2025-12-29 10:14 UTC (permalink / raw) To: Chukun Pan, michael.opdenacker Cc: dan.carpenter, dlan, linux-riscv, spacemit, Chukun Pan Chukun Pan <amadeus@jmu.edu.cn> writes: > Hi, > >> +&sdhci0 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&mmc1_cfg>; > > It would be better to arrange them in alphabetical order. > (Place pinctrl below no-sdio) > >> + bus-width = <4>; >> + cd-gpios = <&gpio K1_GPIO(80) GPIO_ACTIVE_HIGH>; > > It seems that "cap-sd-highspeed" is missing? > >> + cd-inverted; >> + no-sdio; >> + status = "okay"; >> +}; > >> + sdhci0: mmc@d4280000 { > > An immature idea. Would naming nodes this way be better? > > sdmmc: mmc@d4280000 > sdio: mmc@d4280800 > emmc: mmc@d4281000 > > This seems to fit the description here better: > https://bianbu-linux.spacemit.com/en/device/peripheral_driver/SDHC/#dts-configuration > I initially thought something similar but it's not accurate. Because as explained in the doc that you referred: * slot1 supports SD/SDIO (1/4 bit) * slot2 supports SDIO/eMMC (1/4 bit) * slot3 supports only eMMC (1/4/8 bit) Which means that only slot3 is limited to eMMC. So even when a typical configuration is what you mentioned (and what I saw in most of the existing designs), slots 1 and 2 won't always be SD and SDIO. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2025-12-29 10:14 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-12-15 10:10 [PATCH 0/2] Attempt to enable MMC on SpacemiT K1 boards Michael Opdenacker 2025-12-15 10:10 ` [PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2 Michael Opdenacker 2025-12-15 12:58 ` Yao Zi 2025-12-15 15:00 ` Michael Opdenacker 2025-12-16 5:37 ` Yao Zi 2025-12-16 21:05 ` Michael Opdenacker 2025-12-17 15:26 ` Iker Pedrosa 2025-12-17 16:27 ` Michael Opdenacker 2025-12-17 22:10 ` Johannes Erdfelt 2025-12-18 5:19 ` Michael Opdenacker 2025-12-18 5:25 ` Michael Opdenacker 2025-12-18 9:49 ` Iker Pedrosa 2025-12-19 11:29 ` Yixun Lan 2025-12-20 2:22 ` Yao Zi 2025-12-17 20:25 ` Javier Martinez Canillas 2025-12-16 8:58 ` Javier Martinez Canillas 2025-12-24 14:00 ` Chukun Pan 2025-12-15 10:10 ` [PATCH 2/2] riscv: dts: spacemit: Add MMC support on BPI-F3 and " Michael Opdenacker 2025-12-15 12:46 ` Yao Zi 2025-12-15 13:58 ` Michael Opdenacker 2025-12-24 15:00 ` Chukun Pan 2025-12-29 10:14 ` Javier Martinez Canillas
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox