Re: [PATCH v2 2/3] rockchip: rk356x: update the dwc3_device register offset
hi,
could you tell me current status of this patch?
--
FUKAUMI Naoki
On 2/26/23 22:22, Manoj Sai wrote:
update the dwc3_device register offset in board_usb_init()
for rk3568 platforms.
Signed-off-by: Manoj Sai
Reviewed-by: Jagan Teki
---
Changes for v2:-
- None
---
arch/arm/mach-rockchip/board.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
index f1f70c81d0..c7729c966a 100644
--- a/arch/arm/mach-rockchip/board.c
+++ b/arch/arm/mach-rockchip/board.c
@@ -300,6 +300,9 @@ int usb_gadget_handle_interrupts(int index)
int board_usb_init(int index, enum usb_init_type init)
{
+ if (IS_ENABLED(CONFIG_ROCKCHIP_RK3568))
+ dwc3_device_data.base = 0xfcc0;
+
return dwc3_uboot_init(_device_data);
}
#endif /* CONFIG_USB_DWC3_GADGET */
Re: [PATCH] i2c: rockchip: De-initialize the bus after start bit failure
Hello Jirman, On 25.05.23 14:18, Ondřej Jirman wrote: > From: Ondrej Jirman > > Failure can happen when i2c is used without initializing pinctrl properly, > which U-Boot happily allows in SPL. Without this fix, further I2C access would > fail, even after proper pinctrl initialization. > > Signed-off-by: Ondrej Jirman > Cc: Heiko Schocher > --- > drivers/i2c/rk_i2c.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) Reviewed-by: Heiko Schocher @kever: Patch is delegated to you on patchwork, for me it is fine, if you pick it up. If you do not plan to pick it up, please delegate it to me. Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH v2 1/2] rockchip: rk3568: Add support for FriendlyARM NanoPi R5S
Hi Jonas,
On Mon, May 29, 2023 at 11:45 PM Jonas Karlman wrote:
>
> Hi,
>
> On 2023-05-29 06:59, Tianling Shen wrote:
> > FriendlyElec Nanopi R5S is an open-sourced mini IoT gateway device.
> >
> > Board Specifications
> > - Rockchip RK3568
> > - 2 or 4GB LPDDR4X
> > - 8GB or 16GB eMMC, SD card slot
> > - GbE LAN (Native)
> > - 2x 2.5G LAN (PCIe)
> > - M.2 Connector
> > - HDMI 2.0, MIPI DSI/CSI
> > - 2xUSB 3.0 Host
> > - USB Type C PD, 5V/9V/12V
> > - GPIO: 12-pin 0.5mm FPC connector
> >
> > The device tree is taken from kernel v6.4-rc1.
> >
> > Signed-off-by: Tianling Shen
> > ---
> >
> > No changes in v2.
> >
> > ---
> > arch/arm/dts/Makefile | 1 +
> > arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 33 ++
> > arch/arm/dts/rk3568-nanopi-r5s.dts | 136 +
> > arch/arm/dts/rk3568-nanopi-r5s.dtsi| 590 +
> > board/rockchip/evb_rk3568/MAINTAINERS | 8 +
> > configs/nanopi-r5s-rk3568_defconfig| 90
> > 6 files changed, 858 insertions(+)
> > create mode 100644 arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
> > create mode 100644 arch/arm/dts/rk3568-nanopi-r5s.dts
> > create mode 100644 arch/arm/dts/rk3568-nanopi-r5s.dtsi
> > create mode 100644 configs/nanopi-r5s-rk3568_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 480269fa60..e2eda3ffcb 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -169,6 +169,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
> > rk3566-anbernic-rgxx3.dtb \
> > rk3566-radxa-cm3-io.dtb \
> > rk3568-evb.dtb \
> > + rk3568-nanopi-r5s.dtb \
> > rk3568-rock-3a.dtb
> >
> > dtb-$(CONFIG_ROCKCHIP_RK3588) += \
> > diff --git a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
> > b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
> > new file mode 100644
> > index 00..b37ad1e72d
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
> > @@ -0,0 +1,33 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +/*
> > + * Copyright (c) 2022 FriendlyElec Computer Tech. Co., Ltd.
> > + * (http://www.friendlyelec.com)
> > + *
> > + * Copyright (c) 2023 Tianling Shen
> > + */
> > +
> > +#include "rk356x-u-boot.dtsi"
> > +
> > +/ {
> > + chosen {
> > + stdout-path =
> > + u-boot,spl-boot-order = "same-as-spl", ,
> > + };
> > +};
> > +
> > + {
> > + cap-mmc-highspeed;
> > + mmc-hs200-1_8v;
> > +};
>
> Because this is a rk3568 you can probably also add:
>
> mmc-ddr-1_8v;
> mmc-hs400-1_8v;
> mmc-hs400-enhanced-strobe;
>
> and a pinctrl with emmc_datastrobe according to schematic:
>
> pinctrl-0 = <_bus8 _clk _cmd _datastrobe>;
>
> > +
> > + {
> > + bus-width = <4>;
> > + bootph-pre-ram;
> > + u-boot,spl-fifo-mode;
> > +};
>
> The sdmmc0 node is not needed:
> - bus-width is set in linux dts
> - bootph-pre-ram is set in rk356x-u-boot.dtsi
> - u-boot,spl-fifo-mode is not needed on rk356x
>
> > +
> > + {
> > + clock-frequency = <2400>;
> > + bootph-pre-ram;
>
> Recommended to be bootph-all, in case TPL support gets added in future.
>
Thank you so much for all of these explanations and suggestions!
I will test them later today and send v3.
Thanks,
Tianling.
> > + status = "okay";
> > +};
>
> [snip]
>
> > diff --git a/board/rockchip/evb_rk3568/MAINTAINERS
> > b/board/rockchip/evb_rk3568/MAINTAINERS
> > index 6b2e7c7575..9222682461 100644
> > --- a/board/rockchip/evb_rk3568/MAINTAINERS
> > +++ b/board/rockchip/evb_rk3568/MAINTAINERS
> > @@ -7,6 +7,14 @@ F: configs/evb-rk3568_defconfig
> > F: arch/arm/dts/rk3568-evb-boot.dtsi
> > F: arch/arm/dts/rk3568-evb.dts
> >
> > +NANOPI-R5S
> > +M: Tianling Shen
> > +S: Maintained
> > +F: configs/nanopi-r5s-rk3568_defconfig
> > +F: arch/arm/dts/rk3568-nanopi-r5s.dts
> > +F: arch/arm/dts/rk3568-nanopi-r5s.dtsi
> > +F: arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
> > +
> > RADXA-CM3
> > M: Jagan Teki
> > S: Maintained
> > diff --git a/configs/nanopi-r5s-rk3568_defconfig
> > b/configs/nanopi-r5s-rk3568_defconfig
> > new file mode 100644
> > index 00..041fa6d84f
> > --- /dev/null
> > +++ b/configs/nanopi-r5s-rk3568_defconfig
> > @@ -0,0 +1,90 @@
> > +CONFIG_ARM=y
> > +CONFIG_SKIP_LOWLEVEL_INIT=y
> > +CONFIG_COUNTER_FREQUENCY=2400
> > +CONFIG_ARCH_ROCKCHIP=y
> > +CONFIG_TEXT_BASE=0x00a0
> > +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> > +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> > +CONFIG_NR_DRAM_BANKS=2
> > +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> > +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
> > +CONFIG_DEFAULT_DEVICE_TREE="rk3568-nanopi-r5s"
> > +CONFIG_ROCKCHIP_RK3568=y
> > +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
> > +CONFIG_SPL_SERIAL=y
> > +CONFIG_SPL_STACK_R_ADDR=0x60
> > +CONFIG_TARGET_EVB_RK3568=y
> > +CONFIG_SPL_STACK=0x40
> > +CONFIG_DEBUG_UART_BASE=0xFE66
> > +CONFIG_DEBUG_UART_CLOCK=2400
> > +CONFIG_SYS_LOAD_ADDR=0xc00800
> > +CONFIG_DEBUG_UART=y
[PATCH v1 3/3] drivers: rtc: add pcf2131 rtc driver
Adding support for pcf2131 RTC chip.
The pcf2131 is similar to the pcf2127. The driver support rtc register
read/write by using rtc cmd and rtc date set/get by using date cmd.
Signed-off-by: Joy Zou
---
drivers/rtc/Kconfig | 10 +++
drivers/rtc/Makefile | 1 +
drivers/rtc/pcf2131.c | 189 ++
3 files changed, 200 insertions(+)
create mode 100644 drivers/rtc/pcf2131.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 23173139e0..507dc6cbcb 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -64,6 +64,16 @@ config RTC_PCF2127
has a selectable I2C-bus or SPI-bus, a backup battery switch-over
circuit, a
programmable watchdog function, a timestamp function, and many other
features.
+config RTC_PCF2131
+ bool "Enable PCF2131 driver"
+ depends on DM_RTC
+ help
+ The PCF2131 is a CMOS Real Time Clock (RTC) and calendar with an
integrated
+ Temperature Compensated Crystal (Xtal) Oscillator (TCXO) and a 32.768
kHz quartz
+ crystal optimized for very high accuracy and very low power
consumption. The PCF2127
+ has a selectable I2C-bus or SPI-bus, a backup battery switch-over
circuit, a
+ programmable watchdog function, a timestamp function, and many other
features.
+
config RTC_DS1307
bool "Enable DS1307 driver"
depends on DM_RTC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 308fab8da9..722f2be98f 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_RTC_MV) += mvrtc.o
obj-$(CONFIG_RTC_MXS) += mxsrtc.o
obj-$(CONFIG_RTC_PCF8563) += pcf8563.o
obj-$(CONFIG_RTC_PCF2127) += pcf2127.o
+obj-$(CONFIG_RTC_PCF2131) += pcf2131.o
obj-$(CONFIG_RTC_PL031) += pl031.o
obj-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
obj-$(CONFIG_RTC_RV3028) += rv3028.o
diff --git a/drivers/rtc/pcf2131.c b/drivers/rtc/pcf2131.c
new file mode 100644
index 00..8b9c17a2c8
--- /dev/null
+++ b/drivers/rtc/pcf2131.c
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * The NXP PCF2131 RTC uboot driver.
+ * Copyright 2023 NXP
+ * Date & Time support for PCF2131 RTC
+ */
+
+/* #define DEBUG */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PCF2131_REG_CTRL1 0x00
+#define PCF2131_BIT_CTRL1_STOP BIT(5)
+#define PCF2131_BIT_CTRL1_100TH_S_DIS BIT(4)
+#define PCF2131_REG_CTRL2 0x01
+#define PCF2131_REG_CTRL3 0x02
+#define PCF2131_REG_SR_RESET0x05
+#define PCF2131_SR_VAL_Clr_Pres 0xa4
+#define PCF2131_REG_SC 0x07
+#define PCF2131_REG_MN 0x08
+#define PCF2131_REG_HR 0x09
+#define PCF2131_REG_DM 0x0a
+#define PCF2131_REG_DW 0x0b
+#define PCF2131_REG_MO 0x0c
+#define PCF2131_REG_YR 0x0d
+
+static int pcf2131_rtc_read(struct udevice *dev, uint offset, u8 *buffer, uint
len)
+{
+ struct dm_i2c_chip *chip = dev_get_parent_plat(dev);
+ struct i2c_msg msg;
+ int ret;
+
+ /* Set the address of the start register to be read */
+ ret = dm_i2c_write(dev, offset, NULL, 0);
+ if (ret < 0)
+ return ret;
+
+ /* Read register's data */
+ msg.addr = chip->chip_addr;
+ msg.flags |= I2C_M_RD;
+ msg.len = len;
+ msg.buf = buffer;
+
+ return dm_i2c_xfer(dev, , 1);
+}
+
+static int pcf2131_rtc_lock(struct udevice *dev)
+{
+ int ret = 0;
+ uchar buf[6] = { PCF2131_REG_CTRL1 };
+
+ ret = pcf2131_rtc_read(dev, PCF2131_REG_CTRL1, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+
+ buf[PCF2131_REG_CTRL1] |= PCF2131_BIT_CTRL1_STOP;
+ ret = dm_i2c_write(dev, PCF2131_REG_CTRL1, [PCF2131_REG_CTRL1], 1);
+ if (ret < 0)
+ return ret;
+
+ buf[PCF2131_REG_SR_RESET] = PCF2131_SR_VAL_Clr_Pres;
+ ret = dm_i2c_write(dev, PCF2131_REG_SR_RESET,
[PCF2131_REG_SR_RESET], 1);
+ return ret;
+}
+
+static int pcf2131_rtc_unlock(struct udevice *dev)
+{
+ int ret = 0;
+ uchar buf[6] = { PCF2131_REG_CTRL1 };
+
+ ret = pcf2131_rtc_read(dev, PCF2131_REG_CTRL1, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+
+ buf[PCF2131_REG_CTRL1] &= ~PCF2131_BIT_CTRL1_STOP;
+ ret = dm_i2c_write(dev, PCF2131_REG_CTRL1, [PCF2131_REG_CTRL1], 1);
+ return ret;
+}
+
+static int pcf2131_rtc_write(struct udevice *dev, uint offset,
+const u8 *buffer, uint len)
+{
+ int ret = 0;
+
+ ret = pcf2131_rtc_lock(dev);
+ if (ret < 0)
+ return ret;
+
+ ret = dm_i2c_write(dev, offset, buffer, len);
+ if (ret < 0)
+ return ret;
+
+ ret = pcf2131_rtc_unlock(dev);
+ return ret;
+}
+
+static int pcf2131_rtc_set(struct udevice *dev, const struct rtc_time *tm)
+{
[PATCH v1 2/3] imx: imx93_evk: add rtc pcf2131
support rtc pcf2131 for imx93.
Signed-off-by: Joy Zou
---
arch/arm/dts/imx93-11x11-evk-u-boot.dtsi | 8
arch/arm/dts/imx93-11x11-evk.dts | 25
arch/arm/dts/imx93.dtsi | 2 +-
3 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
b/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
index 89e64344c6..4165a9b6b1 100644
--- a/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
@@ -113,6 +113,10 @@
bootph-pre-ram;
};
+ {
+ u-boot,dm-spl;
+};
+
&{/soc@0/bus@4400/i2c@4435/pmic@25} {
bootph-pre-ram;
};
@@ -125,6 +129,10 @@
bootph-pre-ram;
};
+_lpi2c3 {
+ u-boot,dm-spl;
+};
+
{
phy-reset-gpios = < 16 GPIO_ACTIVE_LOW>;
phy-reset-duration = <15>;
diff --git a/arch/arm/dts/imx93-11x11-evk.dts b/arch/arm/dts/imx93-11x11-evk.dts
index b3a5a3d71e..421041757e 100644
--- a/arch/arm/dts/imx93-11x11-evk.dts
+++ b/arch/arm/dts/imx93-11x11-evk.dts
@@ -244,6 +244,24 @@
};
};
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <40>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_lpi2c3>;
+ pinctrl-1 = <_lpi2c3>;
+ status = "okay";
+
+ pcf2131: rtc@53 {
+ compatible = "nxp,pcf2131";
+ reg = <0x53>;
+ interrupt-parent = <>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ status = "okay";
+ };
+};
+
{ /* console */
pinctrl-names = "default";
pinctrl-0 = <_uart1>;
@@ -461,6 +479,13 @@
>;
};
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__LPI2C3_SDA
0x4b9e
+ MX93_PAD_GPIO_IO29__LPI2C3_SCL
0x4b9e
+ >;
+ };
+
pinctrl_pcal6524: pcal6524grp {
fsl,pins = <
MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
diff --git a/arch/arm/dts/imx93.dtsi b/arch/arm/dts/imx93.dtsi
index 28026ccecc..ac4b81c02f 100644
--- a/arch/arm/dts/imx93.dtsi
+++ b/arch/arm/dts/imx93.dtsi
@@ -319,7 +319,7 @@
reg = <0x4253 0x1>;
interrupts = ;
clocks = < IMX93_CLK_LPI2C3_GATE>,
-< IMX93_CLK_LPI2C3_GATE>;
+< IMX93_CLK_BUS_WAKEUP>;
clock-names = "per", "ipg";
status = "disabled";
};
--
2.37.1
[PATCH v1 1/3] configs: Enable RTC pcf2131 support
Enable CONFIG_RTC_PCF2131 configs to support pcf2131. Disable CONFIG_RTC_EMULATION configs. The default rtc0 change into pcf2131. Signed-off-by: Joy Zou --- configs/imx93_11x11_evk_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/imx93_11x11_evk_defconfig b/configs/imx93_11x11_evk_defconfig index 4f8777161e..ccb6999369 100644 --- a/configs/imx93_11x11_evk_defconfig +++ b/configs/imx93_11x11_evk_defconfig @@ -13,6 +13,7 @@ CONFIG_DEFAULT_DEVICE_TREE="imx93-11x11-evk" CONFIG_SPL_TEXT_BASE=0x2049A000 CONFIG_TARGET_IMX93_11X11_EVK=y CONFIG_SYS_PROMPT="u-boot=> " +CONFIG_RTC_PCF2131=y CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y CONFIG_SPL_STACK=0x2051ddd0 @@ -107,7 +108,6 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_DM_RTC=y -CONFIG_RTC_EMULATION=y CONFIG_DM_SERIAL=y CONFIG_FSL_LPUART=y CONFIG_ULP_WATCHDOG=y -- 2.37.1
[PATCH v1 0/3] Add pcf2131 rtc support
The patchset supports pcf2131 rtc. For the details, please check the patch commit log. Joy Zou (3): configs: Enable RTC pcf2131 support imx: imx93_evk: add rtc pcf2131 drivers: rtc: add pcf2131 rtc driver arch/arm/dts/imx93-11x11-evk-u-boot.dtsi | 8 + arch/arm/dts/imx93-11x11-evk.dts | 25 +++ arch/arm/dts/imx93.dtsi | 2 +- configs/imx93_11x11_evk_defconfig| 2 +- drivers/rtc/Kconfig | 10 ++ drivers/rtc/Makefile | 1 + drivers/rtc/pcf2131.c| 189 +++ 7 files changed, 235 insertions(+), 2 deletions(-) create mode 100644 drivers/rtc/pcf2131.c -- 2.37.1
Re: [RFC PATCH 10/17] clk: sunxi: Add support for the D1 CCU
Hey again Andre, On 5/26/23 20:15, Sam Edwards wrote: My "no success" is Linux stalling indefinitely at: [ 0.123090] smp: Bringing up secondary CPUs ... OK, correction: my "no success" was Linux being unable to access the GIC, so boot was getting stuck. This was because it was running in nonsec mode and the GIC wasn't getting the interrupts moved over into group1. The root cause of THAT was that the T113's CBAR's PERIPHBASE is still 0x01C8, where the GIC used to be on the older ARM sunxis. Allwinner never updated their ARM cores when they moved the GIC to 0x0302! Guess we need a `#define CFG_ARM_GIC_BASE_ADDRESS 0x0302`. Where do you recommend I put that? :) I also think sunxi/psci.c:psci_arch_init needs some cleanup: - It sets GICC_PMR to 0xFF, which should probably be removed because that was already done by `_nonsec_init` - It tries to clear the NS bit of SCR to enter secure mode, but the NS bit is just enabled later in `_secure_monitor`. So that should also be removed because it has no effect. So, I'll have a few PSCI patches for you soon -- once I rest up from all of that GIC debugging, that is! Cheers, Sam
Re: [PATCH v6 0/8] FMP versioning support
On Sun, 28 May 2023 at 17:54, Heinrich Schuchardt wrote: > > On 5/19/23 12:32, Masahisa Kojima wrote: > > Firmware version management is not implemented in the current > > FMP implementation. This series aims to add the versioning support > > in FMP. > > > > Currently, there is no way to know the current running firmware > > version through the EFI interface. FMP->GetImageInfo() returns > > always 0 for the version number. So a user can not know that > > expected firmware is running after the capsule update. > > > > EDK II reference implementation utilizes the FMP Payload Header > > inserted right before the capsule payload. > > U-Boot also follows the EDK II implementation. > > With this series applied, version number can be specified > > in the capsule file generation with mkeficapsule tool, then > > user can know the running firmware version through > > FMP->GetImageInfo() and ESRT. > > > > There is a design consideration for lowest supported version. > > If the backing storage is a file we can't trust > > any of that information since anyone can tamper with the file, > > although the variables are defined as RO. > > With that, we store the lowest supported version in the device tree. > > We can trust the information from dtb as long as the former > > stage boot loader verifies the image containing the dtb. > > The firmware version can not be stored in device tree because > > not all the capsule files do not have a device tree. > > > > Note that this series does not mandate the FMP Payload Header, > > compatible with boards that are already using the existing > > U-Boot FMP implementation. > > If no FMP Payload Header is found in the capsule file, fw_version, > > lowest supported version, last attempt version and last attempt > > status is set to 0 and this is the same behavior as existing FMP > > implementation. > > > > Major Changes in v6: > > - change the location of fw_version and lowest supported version > >- fw_version is stored in FMP Payload Header in the capsule file > >- lowest_supported_version is stored in the device tree > > > > Major Changes in v5: > > - major design changes, versioning is implemented with > >device tree instead of EFI variable > > > > Major Changes in v4: > > - add python-based test > > > > Major Changes in v3: > > - exclude CONFIG_FWU_MULT > > > > Masahisa Kojima (8): > >efi_loader: add the number of image entries in efi_capsule_update_info > >efi_loader: store firmware version into FmpState variable > >efi_loader: versioning support in GetImageInfo > >efi_loader: get lowest supported version from device tree > >efi_loader: check lowest supported version > >mkeficapsule: add FMP Payload Header > >doc: uefi: add firmware versioning documentation > >doc: uefi: add anti-rollback documentation > > > > arch/arm/mach-rockchip/board.c| 4 +- > > .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 2 +- > > .../imx8mm-cl-iot-gate/imx8mm-cl-iot-gate.c | 2 +- > > board/emulation/qemu-arm/qemu-arm.c | 2 +- > > board/kontron/pitx_imx8m/pitx_imx8m.c | 2 +- > > board/kontron/sl-mx8mm/sl-mx8mm.c | 2 +- > > board/kontron/sl28/sl28.c | 2 +- > > board/rockchip/evb_rk3399/evb-rk3399.c| 2 +- > > board/sandbox/sandbox.c | 2 +- > > board/socionext/developerbox/developerbox.c | 2 +- > > board/st/stm32mp1/stm32mp1.c | 2 +- > > board/xilinx/common/board.c | 2 +- > > doc/develop/uefi/uefi.rst | 61 > > .../firmware/firmware-version.txt | 22 ++ > > doc/mkeficapsule.1| 10 + > > include/efi_loader.h | 3 +- > > lib/efi_loader/efi_firmware.c | 273 -- > > lib/fwu_updates/fwu.c | 2 +- > > tools/eficapsule.h| 30 ++ > > tools/mkeficapsule.c | 37 ++- > > 20 files changed, 421 insertions(+), 43 deletions(-) > > create mode 100644 doc/device-tree-bindings/firmware/firmware-version.txt > > > > Why are there no changes in directory test/ ? > Could you add a test for the rollback protection? Yes, I will include the test in the next version. Thanks, Masahisa Kojima > > Best regards > > Heinrich
Re: [PATCH v6 2/8] efi_loader: store firmware version into FmpState variable
Hi Heinrich,
On Sun, 28 May 2023 at 17:39, Heinrich Schuchardt wrote:
>
> On 5/19/23 12:32, Masahisa Kojima wrote:
> > Firmware version management is not implemented in the current
> > FMP protocol.
> > EDK II reference implementation capsule generation script inserts
> > the FMP Payload Header right before the payload, FMP Payload Header
> > contains the firmware version and lowest supported version.
> >
> > This commit utilizes the FMP Payload Header, reads the header and
> > stores the firmware version into "FmpState" EFI non-volatile variable.
> > indicates the image index, since FMP protocol handles multiple
> > image indexes.
> > Note that lowest supported version included in the FMP Payload Header
> > is not used. If the platform uses file-based EFI variable storage,
> > it can be tampered. The file-based EFI variable storage is not the
> > right place to store the lowest supported version for anti-rollback
> > protection.
> >
> > This change is compatible with the existing FMP implementation.
> > This change does not mandate the FMP Payload Header.
> > If no FMP Payload Header is found in the capsule file, fw_version,
> > lowest supported version, last attempt version and last attempt
> > status is 0 and this is the same behavior as existing FMP
> > implementation.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > Changed in v6:
> > - only store the fw_version in the FmpState EFI variable
> >
> > Changes in v4:
> > - move lines that are the same in both branches out of the if statement
> > - s/EDK2/EDK II/
> > - create print result function
> > - set last_attempt_version when capsule authentication failed
> > - use log_err() instead of printf()
> >
> > Changes in v3:
> > - exclude CONFIG_FWU_MULTI_BANK_UPDATE case
> > - set image_type_id as a vendor field of FmpState variable
> > - set READ_ONLY flag for FmpState variable
> > - add error code for FIT image case
> >
> > Changes in v2:
> > - modify indent
> >
> > lib/efi_loader/efi_firmware.c | 161 ++
> > 1 file changed, 146 insertions(+), 15 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
> > index cc650e1443..fc085e3c08 100644
> > --- a/lib/efi_loader/efi_firmware.c
> > +++ b/lib/efi_loader/efi_firmware.c
> > @@ -10,6 +10,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -36,11 +37,52 @@ struct fmp_payload_header {
> > u32 lowest_supported_version;
> > };
> >
> > +/**
> > + * struct fmp_state - fmp firmware update state
> > + *
> > + * This structure describes the state of the firmware update
> > + * through FMP protocol.
> > + *
> > + * @fw_version: Firmware versions used
> > + * @lowest_supported_version:Lowest supported version
> > + * @last_attempt_version:Last attempt version
> > + * @last_attempt_status: Last attempt status
> > + */
> > +struct fmp_state {
> > + u32 fw_version;
> > + u32 lowest_supported_version; /* not used */
> > + u32 last_attempt_version; /* not used */
> > + u32 last_attempt_status; /* not used */
> > +};
> > +
> > __weak void set_dfu_alt_info(char *interface, char *devstr)
> > {
> > env_set("dfu_alt_info", update_info.dfu_string);
> > }
> >
> > +/**
> > + * efi_firmware_get_image_type_id - get image_type_id
> > + * @image_index: image index
> > + *
> > + * Return the image_type_id identified by the image index.
> > + *
> > + * Return: pointer to the image_type_id, NULL if image_index is
> > invalid
> > + */
> > +static
> > +efi_guid_t *efi_firmware_get_image_type_id(u8 image_index)
> > +{
> > + int i;
> > + struct efi_fw_image *fw_array;
> > +
> > + fw_array = update_info.images;
> > + for (i = 0; i < update_info.num_images; i++) {
> > + if (fw_array[i].image_index == image_index)
> > + return _array[i].image_type_id;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > /* Place holder; not supported */
> > static
> > efi_status_t EFIAPI efi_firmware_get_image_unsupported(
> > @@ -194,8 +236,6 @@ efi_status_t efi_firmware_capsule_authenticate(const
> > void **p_image,
> > {
> > const void *image = *p_image;
> > efi_uintn_t image_size = *p_image_size;
> > - u32 fmp_hdr_signature;
> > - struct fmp_payload_header *header;
> > void *capsule_payload;
> > efi_status_t status;
> > efi_uintn_t capsule_payload_size;
> > @@ -222,24 +262,107 @@ efi_status_t efi_firmware_capsule_authenticate(const
> > void **p_image,
> > debug("Updating capsule without authenticating.\n");
> > }
> >
> > - fmp_hdr_signature = FMP_PAYLOAD_HDR_SIGNATURE;
> > - header = (void *)image;
> > + *p_image = image;
> > + *p_image_size = image_size;
> > + return EFI_SUCCESS;
> > +}
> > +
> > +/**
> > + * efi_firmware_set_fmp_state_var - set FmpState
Re: eMMC errors on RK3588 (rock5b)
Hi again, On 2023-05-29 17:27, Jonas Karlman wrote: > Hi Eugen, > > On 2023-05-25 11:23, Eugen Hristev wrote: >> Hi Jonas, >> >> I tried some basic eMMC read/write commands, and in my setup with >> rock5b, it fails at single/multiple block read/write , even if >> sometimes, the initial read works fine. >> >> Here is some log : >> >> => mmc read 0x5000 64 1 > [snip] >> MMC read: dev # 0, block # 100, count 1 ... >> 1 blocks read: OK >> => mmc write 0x5000 64 1 >> MMC write: dev # 0, block # 100, count 1 ... > [snip] >> 0 blocks written: ERROR >> => mmc write 0x5000 64 5 >> MMC write: dev # 0, block # 100, count 5 ... > [snip] >> 0 blocks written: ERROR >> => mmc read 0x5000 64 5 >> MMC read: dev # 0, block # 100, count 5 ... > [snip] >> 0 blocks read: ERROR >> => mmc read 0x5000 64 1 > [snip] >> MMC read: dev # 0, block # 100, count 1 ... >> 0 blocks read: ERROR >> => >> >> So now after this attempt, there is a timeout when reading too. >> >> Can you try to reproduce this on your setup as well ? > > I was able to reproduce similar issue on rk356x, did not test on rk3588 > yet. Also going to try similar write commands on the rk3399 (arasan) > compatible of the rk sdhci driver, guess both rk35xx (dwc) compatible is > affected. I tested on rk3399 and there was no problem loading u-boot-rockchip.bin from SD-card and writing it to eMMC using the following commands: Load u-boot-rockchip.bin to @512 MiB DRAM from SD-card: => load mmc 1:1 2000 u-boot-rockchip.bin 9264128 bytes read in 402 ms (22 MiB/s) Select eMMC device: => mmc dev 0 switch to partitions #0, OK mmc0(part 0) is current device Erase 12 MiB starting from sector 64: => mmc erase 40 6000 MMC erase: dev # 0, block # 64, count 24576 ... 24576 blocks erased: OK Write 12 MiB from @512 MiB DRAM to sector 64: => mmc write 2000 40 6000 MMC write: dev # 0, block # 64, count 24576 ... 24576 blocks written: OK So something in controller or driver cause write issues on rk35xx. > > Something odd that I noticed was that write sometime reported OK when > a read command for same blocks was issued, e.g. something similar worked > in some of my testing: > > Select eMMC device to reset state: > => mmc dev 0 > > Read 256KiB (TPL+SPL) from sector 64 to @512 MiB DRAM: > => mmc read 2000 40 200 > > Erase 256KiB from sector 64: > => mmc erase 40 200 > > Write 256KiB (TPL+SPL) from @512 MiB DRAM to sector 64: > => mmc write 2000 40 200 Count param was in bytes in my prior mail, corrected to block count above. Regards, Jonas > > After something fails the use of "mmc dev 0" could be used to reset into > a working read state. Some retry/reset handling may be needed in driver > to fully support write commands. > > A quick peek at vendor u-boot: rk u-boot include some form of retry > logic for write and hardkernel u-boot implement some sort of sw reset. > > Regards, > Jonas > >> >> P.S. booting from eMMC works fine. When I am trying this, I am booting >> from the eMMC. >> >> Thanks ! >
[tom.r...@gmail.com: Fwd: New Defects reported by Coverity Scan for Das U-Boot]
Here's the latest report.
-- Forwarded message -
From:
Date: Mon, May 29, 2023, 11:10 AM
Subject: New Defects reported by Coverity Scan for Das U-Boot
To:
Hi,
Please find the latest report on new defect(s) introduced to Das U-Boot
found with Coverity Scan.
2 new defect(s) introduced to Das U-Boot found with Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)
** CID 461871: Null pointer dereferences (NULL_RETURNS)
/tools/renesas_spkgimage.c: 56 in spkgimage_parse_config_line()
*** CID 461871: Null pointer dereferences (NULL_RETURNS)
/tools/renesas_spkgimage.c: 56 in spkgimage_parse_config_line()
50 char *saveptr;
51 char *delim = "\t ";
52 char *name = strtok_r(line, delim, );
53 char *val_str = strtok_r(NULL, delim, );
54 int value = atoi(val_str);
55
>>> CID 461871: Null pointer dereferences (NULL_RETURNS)
>>> Dereferencing a pointer that might be "NULL" "name" when calling
"strcmp". [Note: The source code implementation of the function has been
overridden by a builtin model.]
56 if (!strcmp("VERSION", name)) {
57 conf.version = check_range(name, value, 1, 15);
58 } else if (!strcmp("NAND_ECC_ENABLE", name)) {
59 conf.ecc_enable = check_range(name, value, 0, 1);
60 } else if (!strcmp("NAND_ECC_BLOCK_SIZE", name)) {
61 conf.ecc_block_size = check_range(name, value, 0, 2);
** CID 461870: Resource leaks (RESOURCE_LEAK)
/tools/renesas_spkgimage.c: 106 in spkgimage_parse_config_file()
*** CID 461870: Resource leaks (RESOURCE_LEAK)
/tools/renesas_spkgimage.c: 106 in spkgimage_parse_config_file()
100
101 /* Strip any trailing newline */
102 line[strcspn(line, "\n")] = 0;
103
104 /* Parse the line */
105 if (spkgimage_parse_config_line(line, line_num))
>>> CID 461870: Resource leaks (RESOURCE_LEAK)
>>> Variable "fcfg" going out of scope leaks the storage it points to.
106 return -EINVAL;
107 }
108
109 fclose(fcfg);
110
111 /* Avoid divide-by-zero later on */
--
Tom
signature.asc
Description: PGP signature
[PATCH] arm64: imx: imx8mp-beacon: Enable LTO
With LTO enabled, SPL shrinks about 10K and U-Boot shrinks about 30K. Signed-off-by: Adam Ford diff --git a/configs/imx8mp_beacon_defconfig b/configs/imx8mp_beacon_defconfig index e8ddd537c0..86d0de3a30 100644 --- a/configs/imx8mp_beacon_defconfig +++ b/configs/imx8mp_beacon_defconfig @@ -34,6 +34,7 @@ CONFIG_ARMV8_EA_EL3_FIRST=y CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x4800 CONFIG_SYS_LOAD_ADDR=0x4048 CONFIG_SYS_MONITOR_LEN=524288 +CONFIG_LTO=y # CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_FIT=y CONFIG_FIT_EXTERNAL_OFFSET=0x3000 -- 2.39.2
Re: [PATCH 3/3] arm: dts: imx8mp: Sync with Linux 6.3
On Wed, May 24, 2023 at 9:02 PM Fabio Estevam wrote:
>
> Hi Tim,
>
> On Fri, May 19, 2023 at 8:00 PM Tim Harvey wrote:
>
> > Fabio,
+ Marek
I am adding Marek since he did the HSIO power domain driver.
> >
> > There's more to be done here also. With this patch, and with the
> > spba-bus added to u-boot.dtsi, if you try to enable usb (usb start)
> > you get:
> > starting USB...
> > Bus usb@3820:
> > Enable clock-controller@3038 failed
> > probe failed, error -2
> > No working controllers found
>
> Does this help?
A bit. I finally got some time to try to troubleshoot USB on my 8MP.
>
> --- a/drivers/clk/imx/clk-imx8mp.c
> +++ b/drivers/clk/imx/clk-imx8mp.c
> @@ -337,8 +337,8 @@ static int imx8mp_clk_probe(struct udevice *dev)
> clk_dm(IMX8MP_CLK_UART2_ROOT, imx_clk_gate4("uart2_root_clk",
> "uart2", base + 0x44a0, 0));
> clk_dm(IMX8MP_CLK_UART3_ROOT, imx_clk_gate4("uart3_root_clk",
> "uart3", base + 0x44b0, 0));
> clk_dm(IMX8MP_CLK_UART4_ROOT, imx_clk_gate4("uart4_root_clk",
> "uart4", base + 0x44c0, 0));
> - clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk",
> "usb_core_ref", base + 0x44d0, 0));
> - clk_dm(IMX8MP_CLK_USB_PHY_ROOT,
IMX8MP_CLK_USB_PHY_ROOT is also referenced in the device tree, so I
don't think we can delete it. I had keep IMX8MP_CLK_USB_ROOT, and
IMX8MP_CLK_USB_PHY_ROOT while also adding IMX8MP_CLK_USB_SUSP.
> imx_clk_gate4("usb_phy_root_clk", "usb_phy_ref", base + 0x44f0, 0));
> + clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk",
> "hsio_axi", base + 0x44d0, 0));
> + clk_dm(IMX8MP_CLK_USB_SUSP, imx_clk_gate4("usb_suspend_clk",
> "osc_32k", base + 0x44d0, 0));
> clk_dm(IMX8MP_CLK_USDHC1_ROOT,
> imx_clk_gate4("usdhc1_root_clk", "usdhc1", base + 0x4510, 0));
> clk_dm(IMX8MP_CLK_USDHC2_ROOT,
> imx_clk_gate4("usdhc2_root_clk", "usdhc2", base + 0x4520, 0));
> clk_dm(IMX8MP_CLK_WDOG1_ROOT, imx_clk_gate4("wdog1_root_clk",
> "wdog", base + 0x4530, 0));
At this point, the missing clock errors go away, but it hangs. I
updated my 8MP USB clocks based on the latest Linux kernel so my
clocks looks like:
clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate2("usb_root_clk", "hsio_axi",
base + 0x44d0, 0));
clk_dm(IMX8MP_CLK_USB_SUSP, imx_clk_gate2("usb_suspend_clk",
"clock-osc-24m", base + 0x44d0, 0));
clk_dm(IMX8MP_CLK_USB_PHY_ROOT, imx_clk_gate4("usb_phy_root_clk",
"usb_phy_ref", base + 0x44f0, 0));
The linux kernel uses gate2 for USB_ROOT and USB_SUSP while gate4 is
used for IMX8MP_CLK_USB_PHY_ROOT. I didn't verify this against the
reference manual.
With some debugging enabled, it looks to me like it might be
power-domain related, but I am not 100% certain.
When I start the USB, it appears to go through some clocks, and start
one power domain, but I think we have a power-domain chain where one
power domain starts another. I saw a patch on another thread for
enabling parent power-domains, but it didn't seem to help me.
u-boot=> usb start
starting USB...
Bus usb@3820: ofnode_read_prop: maximum-speed:
ofnode_read_prop: dr_mode: host
dev_power_domain_on usb@32f10108
ofnode_read_prop: assigned-clock-rates:
Looking for clock-controller@3038
Looking for clock-controller@3038
- result for clock-controller@3038: clock-controller@3038 (ret=0)
- result for clock-controller@3038: clock-controller@3038 (ret=0)
Looking for clock-controller@3038
Looking for clock-controller@3038
- result for clock-controller@3038: clock-controller@3038 (ret=0)
- result for clock-controller@3038: clock-controller@3038 (ret=0)
ofnode_read_prop: dr_mode: host
I added some debug code to the imx8mp_hsiomix_on in HSIOmix power
domain driver, and it doesn't appear to be getting called, yet
dev_power_domain_on usb@32f10108 should be invoking it.
I am not positive it's a power domain issue, that's my first guess.
Tim - have you had any success?
adam
Re: [PATCH v2 2/2] rockchip: rk3568: Add support for FriendlyARM NanoPi R5C
Hi, On 2023-05-29 06:59, Tianling Shen wrote: > FriendlyARM NanoPi R5C is an open-sourced mini IoT gateway device. > > Specification: > - Rockchip RK3568 > - 1/4GB LPDDR4X RAM > - 8/32GB eMMC > - SD card slot > - M.2 Connector > - 2x USB 3.0 Port > - 2x 2500 Base-T (PCIe, r8125) > - HDMI 2.0 > - MIPI DSI/CSI > - USB Type C 5V > > The device tree is taken from kernel v6.4-rc1. > > Signed-off-by: Tianling Shen > --- > > Changes in v2: add dtb to Makefile > > --- > arch/arm/dts/Makefile | 1 + > arch/arm/dts/rk3568-nanopi-r5c-u-boot.dtsi | 3 + > arch/arm/dts/rk3568-nanopi-r5c.dts | 112 + > board/rockchip/evb_rk3568/MAINTAINERS | 7 ++ > configs/nanopi-r5c-rk3568_defconfig| 90 + > 5 files changed, 213 insertions(+) > create mode 100644 arch/arm/dts/rk3568-nanopi-r5c-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3568-nanopi-r5c.dts > create mode 100644 configs/nanopi-r5c-rk3568_defconfig > [snip] Recommend similar changes to defconfig as for r5s. Regards, Jonas
Re: [PATCH v2 1/2] rockchip: rk3568: Add support for FriendlyARM NanoPi R5S
Hi,
On 2023-05-29 06:59, Tianling Shen wrote:
> FriendlyElec Nanopi R5S is an open-sourced mini IoT gateway device.
>
> Board Specifications
> - Rockchip RK3568
> - 2 or 4GB LPDDR4X
> - 8GB or 16GB eMMC, SD card slot
> - GbE LAN (Native)
> - 2x 2.5G LAN (PCIe)
> - M.2 Connector
> - HDMI 2.0, MIPI DSI/CSI
> - 2xUSB 3.0 Host
> - USB Type C PD, 5V/9V/12V
> - GPIO: 12-pin 0.5mm FPC connector
>
> The device tree is taken from kernel v6.4-rc1.
>
> Signed-off-by: Tianling Shen
> ---
>
> No changes in v2.
>
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 33 ++
> arch/arm/dts/rk3568-nanopi-r5s.dts | 136 +
> arch/arm/dts/rk3568-nanopi-r5s.dtsi| 590 +
> board/rockchip/evb_rk3568/MAINTAINERS | 8 +
> configs/nanopi-r5s-rk3568_defconfig| 90
> 6 files changed, 858 insertions(+)
> create mode 100644 arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3568-nanopi-r5s.dts
> create mode 100644 arch/arm/dts/rk3568-nanopi-r5s.dtsi
> create mode 100644 configs/nanopi-r5s-rk3568_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 480269fa60..e2eda3ffcb 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -169,6 +169,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
> rk3566-anbernic-rgxx3.dtb \
> rk3566-radxa-cm3-io.dtb \
> rk3568-evb.dtb \
> + rk3568-nanopi-r5s.dtb \
> rk3568-rock-3a.dtb
>
> dtb-$(CONFIG_ROCKCHIP_RK3588) += \
> diff --git a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
> b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
> new file mode 100644
> index 00..b37ad1e72d
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/*
> + * Copyright (c) 2022 FriendlyElec Computer Tech. Co., Ltd.
> + * (http://www.friendlyelec.com)
> + *
> + * Copyright (c) 2023 Tianling Shen
> + */
> +
> +#include "rk356x-u-boot.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path =
> + u-boot,spl-boot-order = "same-as-spl", ,
> + };
> +};
> +
> + {
> + cap-mmc-highspeed;
> + mmc-hs200-1_8v;
> +};
Because this is a rk3568 you can probably also add:
mmc-ddr-1_8v;
mmc-hs400-1_8v;
mmc-hs400-enhanced-strobe;
and a pinctrl with emmc_datastrobe according to schematic:
pinctrl-0 = <_bus8 _clk _cmd _datastrobe>;
> +
> + {
> + bus-width = <4>;
> + bootph-pre-ram;
> + u-boot,spl-fifo-mode;
> +};
The sdmmc0 node is not needed:
- bus-width is set in linux dts
- bootph-pre-ram is set in rk356x-u-boot.dtsi
- u-boot,spl-fifo-mode is not needed on rk356x
> +
> + {
> + clock-frequency = <2400>;
> + bootph-pre-ram;
Recommended to be bootph-all, in case TPL support gets added in future.
> + status = "okay";
> +};
[snip]
> diff --git a/board/rockchip/evb_rk3568/MAINTAINERS
> b/board/rockchip/evb_rk3568/MAINTAINERS
> index 6b2e7c7575..9222682461 100644
> --- a/board/rockchip/evb_rk3568/MAINTAINERS
> +++ b/board/rockchip/evb_rk3568/MAINTAINERS
> @@ -7,6 +7,14 @@ F: configs/evb-rk3568_defconfig
> F: arch/arm/dts/rk3568-evb-boot.dtsi
> F: arch/arm/dts/rk3568-evb.dts
>
> +NANOPI-R5S
> +M: Tianling Shen
> +S: Maintained
> +F: configs/nanopi-r5s-rk3568_defconfig
> +F: arch/arm/dts/rk3568-nanopi-r5s.dts
> +F: arch/arm/dts/rk3568-nanopi-r5s.dtsi
> +F: arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
> +
> RADXA-CM3
> M: Jagan Teki
> S: Maintained
> diff --git a/configs/nanopi-r5s-rk3568_defconfig
> b/configs/nanopi-r5s-rk3568_defconfig
> new file mode 100644
> index 00..041fa6d84f
> --- /dev/null
> +++ b/configs/nanopi-r5s-rk3568_defconfig
> @@ -0,0 +1,90 @@
> +CONFIG_ARM=y
> +CONFIG_SKIP_LOWLEVEL_INIT=y
> +CONFIG_COUNTER_FREQUENCY=2400
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_TEXT_BASE=0x00a0
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_NR_DRAM_BANKS=2
> +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
> +CONFIG_DEFAULT_DEVICE_TREE="rk3568-nanopi-r5s"
> +CONFIG_ROCKCHIP_RK3568=y
> +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
> +CONFIG_SPL_SERIAL=y
> +CONFIG_SPL_STACK_R_ADDR=0x60
> +CONFIG_TARGET_EVB_RK3568=y
> +CONFIG_SPL_STACK=0x40
> +CONFIG_DEBUG_UART_BASE=0xFE66
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_SYS_LOAD_ADDR=0xc00800
> +CONFIG_DEBUG_UART=y
> +CONFIG_FIT=y
> +CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_LOAD_FIT=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-nanopi-r5s.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_MAX_SIZE=0x4
> +CONFIG_SPL_PAD_TO=0x7f8000
> +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> +CONFIG_SPL_BSS_START_ADDR=0x400
> +CONFIG_SPL_BSS_MAX_SIZE=0x4000
> +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> +# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> +CONFIG_SPL_STACK_R=y
>
Re: eMMC errors on RK3588 (rock5b)
Hi Eugen, On 2023-05-25 11:23, Eugen Hristev wrote: > Hi Jonas, > > I tried some basic eMMC read/write commands, and in my setup with > rock5b, it fails at single/multiple block read/write , even if > sometimes, the initial read works fine. > > Here is some log : > > => mmc read 0x5000 64 1 [snip] > MMC read: dev # 0, block # 100, count 1 ... > 1 blocks read: OK > => mmc write 0x5000 64 1 > MMC write: dev # 0, block # 100, count 1 ... [snip] > 0 blocks written: ERROR > => mmc write 0x5000 64 5 > MMC write: dev # 0, block # 100, count 5 ... [snip] > 0 blocks written: ERROR > => mmc read 0x5000 64 5 > MMC read: dev # 0, block # 100, count 5 ... [snip] > 0 blocks read: ERROR > => mmc read 0x5000 64 1 [snip] > MMC read: dev # 0, block # 100, count 1 ... > 0 blocks read: ERROR > => > > So now after this attempt, there is a timeout when reading too. > > Can you try to reproduce this on your setup as well ? I was able to reproduce similar issue on rk356x, did not test on rk3588 yet. Also going to try similar write commands on the rk3399 (arasan) compatible of the rk sdhci driver, guess both rk35xx (dwc) compatible is affected. Something odd that I noticed was that write sometime reported OK when a read command for same blocks was issued, e.g. something similar worked in some of my testing: Select eMMC device to reset state: => mmc dev 0 Read 256KiB (TPL+SPL) from sector 64 to @512 MiB DRAM: => mmc read 2000 40 4 Erase 256KiB from sector 64: => mmc erase 40 4 Write 256KiB (TPL+SPL) from @512 MiB DRAM to sector 64: => mmc write 2000 40 4 After something fails the use of "mmc dev 0" could be used to reset into a working read state. Some retry/reset handling may be needed in driver to fully support write commands. A quick peek at vendor u-boot: rk u-boot include some form of retry logic for write and hardkernel u-boot implement some sort of sw reset. Regards, Jonas > > P.S. booting from eMMC works fine. When I am trying this, I am booting > from the eMMC. > > Thanks !
[ANN] U-Boot v2023.07-rc3 released
Hey all, Well, this is shaping up to be one of the releases where I do a bad job at following the -rc schedule, sorry. That said, we're well in to the stability period now, so I'm hoping for pull requests versus the next branch at this point and only regression fixes versus master. In terms of a changelog, git log --merges v2023.07-rc2..v2023.07-rc3 contains what I've pulled but as always, better PR messages and tags will provide better results here. Continuing on schedule now and that means the rest of the rcs every other Monday, and with final release on July 3rd, 2023. Thanks all! -- Tom signature.asc Description: PGP signature
[PATCH] spl: Kconfig: fix trivial typo Suppport
s/Suppport/Support Signed-off-by: Eugen Hristev --- common/spl/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 2c042ad30668..c66b38ee676d 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -1373,7 +1373,7 @@ config SYS_USB_FAT_BOOT_PARTITION Partition on the USB storage device to load U-Boot from config SPL_USB_GADGET - bool "Suppport USB Gadget drivers" + bool "Support USB Gadget drivers" help Enable USB Gadget API which allows to enable USB device functions in SPL. -- 2.34.1
Re: [PATCH v6 2/3] Boot var automatic management for removable medias
Hi Heinrich,
On Sat, 27 May 2023 at 17:54, Heinrich Schuchardt wrote:
>
> On 5/26/23 23:36, Raymond Mao wrote:
> > Changes for complying to EFI spec §3.5.1.1
> > 'Removable Media Boot Behavior'.
> > Boot variables can be automatically generated during a removable
> > media is probed. At the same time, unused boot variables will be
> > detected and removed.
> >
> > Signed-off-by: Raymond Mao
> > ---
[]
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index d2256713a8..ca5f07f2ec 100644
> > --- a/lib/efi_loader/efi_disk.c
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -687,6 +687,13 @@ int efi_disk_probe(void *ctx, struct event *event)
> > return -1;
> > }
> >
> > + /* only do the boot option management when UEFI sub-system is
> > initialized */
> > + if (efi_obj_list_initialized == EFI_SUCCESS) {
> > + ret = efi_bootmgr_update_media_device_boot_option();
> > + if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
>
> efi_bootmgr_update_media_device_boot_option() returns EFI_SUCCESS if
> calloc fails(). It fails with EFI_NOT_FOUND if there is no handle with a
> simple file protocol.
>
> Why would we return 0 here if we are out of memory?
> It would be preferable to let
> efi_bootmgr_update_media_device_boot_option() return EFI_SUCCESS if
> there is no partition with a file system.
>
It is an original bug of the function
'eficonfig_generate_media_device_boot_option()'.
I can add the fix to return EFI_OUT_OF_RESOURCES with this patch.
Also, I can add below lines at the end of the function to return EFI_SUCCESS for
EFI_NOT_FOUND if you agree.
---
if (ret == EFI_NOT_FOUND)
return EFI_SUCCESS;
return ret;
---
Thanks and regards.
Raymond
[PATCH v2 6/6] corstone1000: add nvmxip, fwu-mdata and gpt options
Enable the newest features: nvmxip, fwu-metadata and
gpt. Commands to print the partition info, gpt info
and fwu metadata will be available.
Adjust also env boot script the address of the
bootbank with the new gpt layout, and also remove
the not needed kernel address bank0 and bank1
and retrieve function that would test the bank flag
before and now we are getting the info from the fwu
metadata.
Signed-off-by: Rui Miguel Silva
---
board/armltd/corstone1000/corstone1000.c | 1 +
board/armltd/corstone1000/corstone1000.env | 10 +-
configs/corstone1000_defconfig | 13 -
3 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/board/armltd/corstone1000/corstone1000.c
b/board/armltd/corstone1000/corstone1000.c
index a4567449f1be..01c80aaf9d77 100644
--- a/board/armltd/corstone1000/corstone1000.c
+++ b/board/armltd/corstone1000/corstone1000.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/board/armltd/corstone1000/corstone1000.env
b/board/armltd/corstone1000/corstone1000.env
index b24ff07fc6bd..ee318b1b1c30 100644
--- a/board/armltd/corstone1000/corstone1000.env
+++ b/board/armltd/corstone1000/corstone1000.env
@@ -1,13 +1,5 @@
/* SPDX-License-Identifier: GPL-2.0+ */
usb_pgood_delay=250
-boot_bank_flag=0x08002000
-kernel_addr_bank_0=0x083EE000
-kernel_addr_bank_1=0x0936E000
-retrieve_kernel_load_addr=
- if itest.l *${boot_bank_flag} == 0; then
- setenv kernel_addr $kernel_addr_bank_0;
- else
- setenv kernel_addr $kernel_addr_bank_1;
- fi;
+boot_bank_flag=0x08005006
kernel_addr_r=0x8820
diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig
index 5be5335bdfc1..a8a79fd10568 100644
--- a/configs/corstone1000_defconfig
+++ b/configs/corstone1000_defconfig
@@ -15,7 +15,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTDELAY=3
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="console=ttyAMA0 loglevel=9 ip=dhcp earlyprintk"
-CONFIG_BOOTCOMMAND="run retrieve_kernel_load_addr; echo Loading kernel from
$kernel_addr to memory ... ; loadm $kernel_addr $kernel_addr_r 0xc0; usb
start; usb reset; run distro_bootcmd; bootefi $kernel_addr_r $fdtcontroladdr;"
+CONFIG_BOOTCOMMAND="echo Loading kernel from $kernel_addr to memory ... ;
loadm $kernel_addr $kernel_addr_r 0xc0; usb start; usb reset; run
distro_bootcmd; bootefi $kernel_addr_r $fdtcontroladdr;"
CONFIG_CONSOLE_RECORD=y
CONFIG_LOGLEVEL=7
# CONFIG_DISPLAY_CPUINFO is not set
@@ -24,11 +24,16 @@ CONFIG_BOARD_LATE_INIT=y
CONFIG_SYS_MAXARGS=64
CONFIG_SYS_CBSIZE=512
# CONFIG_CMD_CONSOLE is not set
+CONFIG_CMD_FWU_METADATA=y
CONFIG_CMD_BOOTZ=y
CONFIG_SYS_BOOTM_LEN=0x80
# CONFIG_CMD_XIMG is not set
+CONFIG_CMD_NVMXIP=y
+CONFIG_CMD_GPT=y
+# CONFIG_RANDOM_UUID is not set
CONFIG_CMD_LOADM=y
# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
CONFIG_CMD_USB=y
# CONFIG_CMD_SETEXPR is not set
# CONFIG_CMD_NFS is not set
@@ -40,6 +45,8 @@ CONFIG_OF_CONTROL=y
CONFIG_VERSION_VARIABLE=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_REGMAP=y
+CONFIG_FWU_MDATA=y
+CONFIG_FWU_MDATA_GPT_BLK=y
CONFIG_MISC=y
# CONFIG_MMC is not set
CONFIG_NVMXIP_QSPI=y
@@ -51,6 +58,10 @@ CONFIG_RAM=y
CONFIG_DM_RTC=y
CONFIG_RTC_EMULATION=y
CONFIG_DM_SERIAL=y
+CONFIG_SYSRESET=y
CONFIG_USB=y
CONFIG_USB_ISP1760=y
+CONFIG_EFI_CAPSULE_ON_DISK=y
+CONFIG_EFI_IGNORE_OSINDICATIONS=y
+CONFIG_FWU_MULTI_BANK_UPDATE=y
CONFIG_ERRNO_STR=y
--
2.40.1
[PATCH v2 5/6] corstone1000: set kernel_addr based on boot_idx
We need to distinguish between boot banks and from which
partition to load the kernel+initramfs to memory.
For that, fetch the boot index, fetch the correspondent
partition, calculate the correct kernel address and
then set the env variable kernel_addr with that value.
Signed-off-by: Rui Miguel Silva
---
board/armltd/corstone1000/corstone1000.c | 56 +++-
configs/corstone1000_defconfig | 1 +
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/board/armltd/corstone1000/corstone1000.c
b/board/armltd/corstone1000/corstone1000.c
index 1bead7a0a8b4..a4567449f1be 100644
--- a/board/armltd/corstone1000/corstone1000.c
+++ b/board/armltd/corstone1000/corstone1000.c
@@ -5,16 +5,24 @@
* Rui Miguel Silva
*/
+#include
#include
#include
#include
#include
-#include
#include
+#include
+#include
#include
#include
#include
+#define CORSTONE1000_KERNEL_PARTS 2
+#define CORSTONE1000_KERNEL_PRIMARY "kernel_primary"
+#define CORSTONE1000_KERNEL_SECONDARY "kernel_secondary"
+
+static int corstone1000_boot_idx;
+
static struct mm_region corstone1000_mem_map[] = {
{
/* CVM */
@@ -103,6 +111,52 @@ void fwu_plat_get_bootidx(uint *boot_idx)
*boot_idx = CONFIG_FWU_NUM_BANKS;
log_err("corstone1000: failed to read active index\n");
}
+}
+
+int board_late_init(void)
+{
+ struct disk_partition part_info;
+ struct udevice *dev, *bdev;
+ struct nvmxip_plat *plat;
+ struct blk_desc *desc;
+ int ret;
+
+ ret = uclass_first_device_err(UCLASS_NVMXIP, );
+ if (ret < 0) {
+ log_err("Cannot find kernel device\n");
+ return ret;
+ }
+
+ plat = dev_get_plat(dev);
+ device_find_first_child(dev, );
+ desc = dev_get_uclass_plat(bdev);
+ ret = fwu_get_active_index(_boot_idx);
+ if (ret < 0) {
+ log_err("corstone1000: failed to read boot index\n");
+ return ret;
+ }
+
+ if (!corstone1000_boot_idx)
+ ret = part_get_info_by_name(desc, CORSTONE1000_KERNEL_PRIMARY,
+ _info);
+ else
+ ret = part_get_info_by_name(desc, CORSTONE1000_KERNEL_SECONDARY,
+ _info);
+
+ if (ret < 0) {
+ log_err("failed to fetch kernel partition index: %d\n",
+ corstone1000_boot_idx);
+ return ret;
+ }
+
+ ret = 0;
+
+ ret |= env_set_hex("kernel_addr", plat->phys_base +
+ (part_info.start * part_info.blksz));
+ ret |= env_set_hex("kernel_size", part_info.size * part_info.blksz);
+
+ if (ret < 0)
+ log_err("failed to setup kernel addr and size\n");
return ret;
}
diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig
index 2d391048cd67..5be5335bdfc1 100644
--- a/configs/corstone1000_defconfig
+++ b/configs/corstone1000_defconfig
@@ -20,6 +20,7 @@ CONFIG_CONSOLE_RECORD=y
CONFIG_LOGLEVEL=7
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SYS_MAXARGS=64
CONFIG_SYS_CBSIZE=512
# CONFIG_CMD_CONSOLE is not set
--
2.40.1
[PATCH v2 4/6] corstone1000: add boot index
it is expected that the firmware that runs before
u-boot somehow provide the information of the bank
for now we will fetch the info from the metadata
since the Secure enclave is the one responsible for
this information.
Signed-off-by: Rui Miguel Silva
---
board/armltd/corstone1000/corstone1000.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/board/armltd/corstone1000/corstone1000.c
b/board/armltd/corstone1000/corstone1000.c
index 6ec8e6144fb4..1bead7a0a8b4 100644
--- a/board/armltd/corstone1000/corstone1000.c
+++ b/board/armltd/corstone1000/corstone1000.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -87,6 +89,20 @@ int dram_init_banksize(void)
return 0;
}
-void reset_cpu(void)
+void fwu_plat_get_bootidx(uint *boot_idx)
{
+ int ret;
+
+ /*
+* in our platform, the Secure Enclave is the one who controls
+* all the boot tries and status, so, every time we get here
+* we know that the we are booting from the active index
+*/
+ ret = fwu_get_active_index(boot_idx);
+ if (ret < 0) {
+ *boot_idx = CONFIG_FWU_NUM_BANKS;
+ log_err("corstone1000: failed to read active index\n");
+ }
+
+ return ret;
}
--
2.40.1
[PATCH v2 3/6] corstone1000: add fwu-metadata store info
Add fwu-mdata node and handle for the reference
nvmxip-qspi.
Signed-off-by: Rui Miguel Silva
---
arch/arm/dts/corstone1000.dtsi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/corstone1000.dtsi b/arch/arm/dts/corstone1000.dtsi
index 533dfdf8e1ca..1e0ec075e4cd 100644
--- a/arch/arm/dts/corstone1000.dtsi
+++ b/arch/arm/dts/corstone1000.dtsi
@@ -38,7 +38,7 @@
reg = <0x8820 0x77e0>;
};
- nvmxip-qspi@0800 {
+ nvmxip: nvmxip-qspi@0800 {
compatible = "nvmxip,qspi";
reg = <0x0800 0x200>;
lba_shift = <9>;
@@ -106,6 +106,11 @@
method = "smc";
};
+ fwu-mdata {
+ compatible = "u-boot,fwu-mdata-gpt";
+ fwu-mdata-store = <>;
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
--
2.40.1
[PATCH v2 2/6] nvmxip: move header to include
Move header to include to allow external code
to get the internal bdev structures to access
block device operations.
as at it, just add the UCLASS_NVMXIP string
so we get the correct output in partitions
listing.
Signed-off-by: Rui Miguel Silva
---
{drivers/mtd/nvmxip => include}/nvmxip.h | 0
test/dm/nvmxip.c | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename {drivers/mtd/nvmxip => include}/nvmxip.h (100%)
diff --git a/drivers/mtd/nvmxip/nvmxip.h b/include/nvmxip.h
similarity index 100%
rename from drivers/mtd/nvmxip/nvmxip.h
rename to include/nvmxip.h
diff --git a/test/dm/nvmxip.c b/test/dm/nvmxip.c
index e934748eb5d2..89bf481f6161 100644
--- a/test/dm/nvmxip.c
+++ b/test/dm/nvmxip.c
@@ -17,7 +17,7 @@
#include
#include
#include
-#include "../../drivers/mtd/nvmxip/nvmxip.h"
+#include
/* NVMXIP devices described in the device tree */
#define SANDBOX_NVMXIP_DEVICES 2
--
2.40.1
[PATCH v2 1/6] fwu_metadata: make sure structures are packed
The fwu metadata in the metadata partitions
should/are packed to guarantee that the info is
correct in all platforms. Also the size of them
are used to calculate the crc32 and that is important
to get it right.
Signed-off-by: Rui Miguel Silva
Reviewed-by: Ilias Apalodimas
---
include/fwu_mdata.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
index 8fda4f4ac225..c61221a91735 100644
--- a/include/fwu_mdata.h
+++ b/include/fwu_mdata.h
@@ -22,7 +22,7 @@ struct fwu_image_bank_info {
efi_guid_t image_uuid;
uint32_t accepted;
uint32_t reserved;
-};
+} __packed;
/**
* struct fwu_image_entry - information for a particular type of image
@@ -38,7 +38,7 @@ struct fwu_image_entry {
efi_guid_t image_type_uuid;
efi_guid_t location_uuid;
struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
-};
+} __packed;
/**
* struct fwu_mdata - FWU metadata structure for multi-bank updates
@@ -62,6 +62,6 @@ struct fwu_mdata {
uint32_t previous_active_index;
struct fwu_image_entry img_entry[CONFIG_FWU_NUM_IMAGES_PER_BANK];
-};
+} __packed;
#endif /* _FWU_MDATA_H_ */
--
2.40.1
[PATCH v2 0/6] corstone1000: fwu metadata and GPT
Now that the nvmxip block driver is merged we can add on top
of it the platform code to use GPT and FWU metadata in the
Corstone1000.
But first, push 2 fixes that are needed to make all this work:
- move nvmxip header to include
- setup fwu metadata structures as packed (we have a 32bit
writer - Secure enclave Cortex-M0 and a 64bit reader host
Cortex-A35)
Cheers,
Rui
v1 [0]-> v2:
Ilias:
- add Reviewed-by tag in patch 1/6
Heinrich:
- fix test include nvmxip header after the move to include/
in patch 2/6
[0]:
https://lore.kernel.org/u-boot/20230502131200.2551513-1-rui.si...@linaro.org/
Rui Miguel Silva (6):
fwu_metadata: make sure structures are packed
nvmxip: move header to include
corstone1000: add fwu-metadata store info
corstone1000: add boot index
corstone1000: set kernel_addr based on boot_idx
corstone1000: add nvmxip, fwu-mdata and gpt options
arch/arm/dts/corstone1000.dtsi | 7 ++-
board/armltd/corstone1000/corstone1000.c | 73 +-
board/armltd/corstone1000/corstone1000.env | 10 +--
configs/corstone1000_defconfig | 14 -
include/fwu_mdata.h| 6 +-
{drivers/mtd/nvmxip => include}/nvmxip.h | 0
test/dm/nvmxip.c | 2 +-
7 files changed, 96 insertions(+), 16 deletions(-)
rename {drivers/mtd/nvmxip => include}/nvmxip.h (100%)
--
2.40.1
[PATCH] drivers: spi: omap3_spi: Initialize mode for all channels
At first SPI transfers, multiple chip selects can be
enabled simultaneously. This is due to chip select
polarity, which is not properly initialized for all
channels. This patch fixes the issue.
Signed-off-by: Julien Panis
---
Using TI OMAP3 McSPI driver, multiple chip selects
can be enabled simultaneously during SPI transfers.
This patch fixes the issue.
---
drivers/spi/omap3_spi.c | 20 ++--
include/omap3_spi.h | 4 +++-
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 1cbb5d46fd60..ff7b55f8707e 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -347,20 +347,28 @@ static void _omap3_spi_set_wordlen(struct omap3_spi_priv
*priv)
omap3_spi_write_chconf(priv, confr);
}
-static void spi_reset(struct mcspi *regs)
+static void spi_reset(struct omap3_spi_priv *priv)
{
unsigned int tmp;
- writel(OMAP3_MCSPI_SYSCONFIG_SOFTRESET, >sysconfig);
+ writel(OMAP3_MCSPI_SYSCONFIG_SOFTRESET, >regs->sysconfig);
do {
- tmp = readl(>sysstatus);
+ tmp = readl(>regs->sysstatus);
} while (!(tmp & OMAP3_MCSPI_SYSSTATUS_RESETDONE));
writel(OMAP3_MCSPI_SYSCONFIG_AUTOIDLE |
OMAP3_MCSPI_SYSCONFIG_ENAWAKEUP |
- OMAP3_MCSPI_SYSCONFIG_SMARTIDLE, >sysconfig);
+ OMAP3_MCSPI_SYSCONFIG_SMARTIDLE, >regs->sysconfig);
- writel(OMAP3_MCSPI_WAKEUPENABLE_WKEN, >wakeupenable);
+ writel(OMAP3_MCSPI_WAKEUPENABLE_WKEN, >regs->wakeupenable);
+
+ /*
+* Set the same default mode for each channel, especially CS polarity
+* which must be common for all SPI slaves before any transfer.
+*/
+ for (priv->cs = 0 ; priv->cs < OMAP4_MCSPI_CHAN_NB ; priv->cs++)
+ _omap3_spi_set_mode(priv);
+ priv->cs = 0;
}
static void _omap3_spi_claim_bus(struct omap3_spi_priv *priv)
@@ -430,7 +438,7 @@ static int omap3_spi_probe(struct udevice *dev)
priv->pin_dir = plat->pin_dir;
priv->wordlen = SPI_DEFAULT_WORDLEN;
- spi_reset(priv->regs);
+ spi_reset(priv);
return 0;
}
diff --git a/include/omap3_spi.h b/include/omap3_spi.h
index cae37705830a..5381431d4389 100644
--- a/include/omap3_spi.h
+++ b/include/omap3_spi.h
@@ -46,6 +46,8 @@
#define OMAP4_MCSPI_REG_OFFSET 0x100
+#define OMAP4_MCSPI_CHAN_NB4
+
/* OMAP3 McSPI registers */
struct mcspi_channel {
unsigned int chconf;/* 0x2C, 0x40, 0x54, 0x68 */
@@ -64,7 +66,7 @@ struct mcspi {
unsigned int wakeupenable; /* 0x20 */
unsigned int syst; /* 0x24 */
unsigned int modulctrl; /* 0x28 */
- struct mcspi_channel channel[4];
+ struct mcspi_channel channel[OMAP4_MCSPI_CHAN_NB];
/* channel0: 0x2C - 0x3C, bus 0 & 1 & 2 & 3 */
/* channel1: 0x40 - 0x50, bus 0 & 1 */
/* channel2: 0x54 - 0x64, bus 0 & 1 */
---
base-commit: f1d33a44ca04fdca241c1d89fd79e2e56c930c7e
change-id: 20230526-omap3-spi-cs-fix-948591265425
Best regards,
--
Julien Panis
Re: [PATCH 1/6] fwu_metadata: make sure structures are packed
Ilias Apalodimas writes:
> Hi,
>
> On Mon, 29 May 2023 at 16:12, Rui Miguel Silva wrote:
>>
>> Hi Heinrich,
>> thanks for the review,
>> Heinrich Schuchardt writes:
>>
>> > On 5/3/23 10:06, Ilias Apalodimas wrote:
>> >> On Tue, 2 May 2023 at 16:12, Rui Miguel Silva
>> >> wrote:
>> >>
>> >> Hi Rui,
>> >>>
>> >>> The fwu metadata in the metadata partitions
>> >>> should/are packed to guarantee that the info is
>> >>> correct in all platforms. Also the size of them
>> >>> are used to calculate the crc32 and that is important
>> >>> to get it right.
>> >>>
>> >>> Signed-off-by: Rui Miguel Silva
>> >>> ---
>> >>> include/fwu_mdata.h | 6 +++---
>> >>> 1 file changed, 3 insertions(+), 3 deletions(-)
>> >>>
>> >>> diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
>> >>> index 8fda4f4ac225..c61221a91735 100644
>> >>> --- a/include/fwu_mdata.h
>> >>> +++ b/include/fwu_mdata.h
>> >>> @@ -22,7 +22,7 @@ struct fwu_image_bank_info {
>> >>> efi_guid_t image_uuid;
>> >>> uint32_t accepted;
>> >>> uint32_t reserved;
>> >>> -};
>> >>> +} __packed;
>> >
>> > This structure is naturally packed. Why should adding a __packed
>> > attribute make a difference?
>>
>> Agree.
>>
>> >
>> >>>
>> >>> /**
>> >>>* struct fwu_image_entry - information for a particular type of image
>> >>> @@ -38,7 +38,7 @@ struct fwu_image_entry {
>> >>> efi_guid_t image_type_uuid;
>> >>> efi_guid_t location_uuid;
>> >>> struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
>> >>> -};
>> >>> +} __packed;
>> >
>> > ditto
>>
>> Agree.
>>
>> >
>> >>>
>> >>> /**
>> >>>* struct fwu_mdata - FWU metadata structure for multi-bank updates
>> >>> @@ -62,6 +62,6 @@ struct fwu_mdata {
>> >>> uint32_t previous_active_index;
>> >>>
>> >>> struct fwu_image_entry
>> >>> img_entry[CONFIG_FWU_NUM_IMAGES_PER_BANK];
>> >>> -};
>> >>> +} __packed;
>> >
>> > Depending on the alignment of efi_guid_t __packed might make a
>> > difference here. But as efi_guid_t is defined as 4 aligned I can't see
>> > an impact here either.
>>
>> but efi_guid_t is defined as 8 aligned, right?
>
> No, we have it as 4byte aligned,
Sorry, was looking at an relative old branch. (only with this:
1dd705cf99 efi: use 32-bit alignment for efi_guid_t in v2023.04 it
changed to 4 aligned)
and, please note, that there is a definition of efi_guid_t
as aligned 8 in eficapsule tool:
https://elixir.bootlin.com/u-boot/latest/source/tools/eficapsule.h#L27
>
>> Even though, I think that this type of data written to disk/flash
>> without guaranteeing (trusting natural picketing) packed and endianness
>> is never a good idea.
>
> I think we should overall define these as packed regardless. The spec
> might change at some point and add a few fields ane even though it
> doesn't explicitly requires packing it only mentions offsets. This is
> going to make a difference in code generation, but it's in a path
> noone cares about speed.
Agree. Thanks for the feedback.
Cheers,
Rui
>
> Thanks
> /Ilias
>
>>
>> Cheers,
>>Rui
>>
>> >
>> > Best regards
>> >
>> > Heinrich
>> >
>> >>>
>> >>> #endif /* _FWU_MDATA_H_ */
>> >>> --
>> >>> 2.40.0
>> >>>
>> >>
>> >> Yep, that's a good catch. The spec defines 'just' the offsets and not
>> >> the C representation, so those should be indeed packed.
>> >>
>> >> Reviewed-by: Ilias Apalodimas
Re: [PATCH 1/6] fwu_metadata: make sure structures are packed
Hi,
On Mon, 29 May 2023 at 16:12, Rui Miguel Silva wrote:
>
> Hi Heinrich,
> thanks for the review,
> Heinrich Schuchardt writes:
>
> > On 5/3/23 10:06, Ilias Apalodimas wrote:
> >> On Tue, 2 May 2023 at 16:12, Rui Miguel Silva wrote:
> >>
> >> Hi Rui,
> >>>
> >>> The fwu metadata in the metadata partitions
> >>> should/are packed to guarantee that the info is
> >>> correct in all platforms. Also the size of them
> >>> are used to calculate the crc32 and that is important
> >>> to get it right.
> >>>
> >>> Signed-off-by: Rui Miguel Silva
> >>> ---
> >>> include/fwu_mdata.h | 6 +++---
> >>> 1 file changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
> >>> index 8fda4f4ac225..c61221a91735 100644
> >>> --- a/include/fwu_mdata.h
> >>> +++ b/include/fwu_mdata.h
> >>> @@ -22,7 +22,7 @@ struct fwu_image_bank_info {
> >>> efi_guid_t image_uuid;
> >>> uint32_t accepted;
> >>> uint32_t reserved;
> >>> -};
> >>> +} __packed;
> >
> > This structure is naturally packed. Why should adding a __packed
> > attribute make a difference?
>
> Agree.
>
> >
> >>>
> >>> /**
> >>>* struct fwu_image_entry - information for a particular type of image
> >>> @@ -38,7 +38,7 @@ struct fwu_image_entry {
> >>> efi_guid_t image_type_uuid;
> >>> efi_guid_t location_uuid;
> >>> struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
> >>> -};
> >>> +} __packed;
> >
> > ditto
>
> Agree.
>
> >
> >>>
> >>> /**
> >>>* struct fwu_mdata - FWU metadata structure for multi-bank updates
> >>> @@ -62,6 +62,6 @@ struct fwu_mdata {
> >>> uint32_t previous_active_index;
> >>>
> >>> struct fwu_image_entry img_entry[CONFIG_FWU_NUM_IMAGES_PER_BANK];
> >>> -};
> >>> +} __packed;
> >
> > Depending on the alignment of efi_guid_t __packed might make a
> > difference here. But as efi_guid_t is defined as 4 aligned I can't see
> > an impact here either.
>
> but efi_guid_t is defined as 8 aligned, right?
No, we have it as 4byte aligned,
> Even though, I think that this type of data written to disk/flash
> without guaranteeing (trusting natural picketing) packed and endianness
> is never a good idea.
I think we should overall define these as packed regardless. The spec
might change at some point and add a few fields ane even though it
doesn't explicitly requires packing it only mentions offsets. This is
going to make a difference in code generation, but it's in a path
noone cares about speed.
Thanks
/Ilias
>
> Cheers,
>Rui
>
> >
> > Best regards
> >
> > Heinrich
> >
> >>>
> >>> #endif /* _FWU_MDATA_H_ */
> >>> --
> >>> 2.40.0
> >>>
> >>
> >> Yep, that's a good catch. The spec defines 'just' the offsets and not
> >> the C representation, so those should be indeed packed.
> >>
> >> Reviewed-by: Ilias Apalodimas
Re: [PATCH 2/6] nvmxip: move header to include
Hi Heinrich,
Thanks for the review.
Heinrich Schuchardt writes:
> On 5/2/23 15:11, Rui Miguel Silva wrote:
>> Move header to include to allow external code
>> to get the internal bdev structures to access
>> block device operations.
>>
>> as at it, just add the UCLASS_NVMXIP string
>> so we get the correct output in partitions
>> listing.
>>
>> Signed-off-by: Rui Miguel Silva
>> ---
>> {drivers/mtd/nvmxip => include}/nvmxip.h | 0
>> 1 file changed, 0 insertions(+), 0 deletions(-)
>> rename {drivers/mtd/nvmxip => include}/nvmxip.h (100%)
>>
>> diff --git a/drivers/mtd/nvmxip/nvmxip.h b/include/nvmxip.h
>> similarity index 100%
>> rename from drivers/mtd/nvmxip/nvmxip.h
>> rename to include/nvmxip.h
>
> We expect the code to compile after each single patch. Otherwise
> bisecting will not work.
>
> You cannot move an include without adjusting all references, e.g.
> test/dm/nvmxip.c:20:#include "../../drivers/mtd/nvmxip/nvmxip.h"
Hrrr, thanks for noticing this. I will fix it in v2.
Cheers,
Rui
>
> Best regards
>
> Heinrich
Re: [PATCH 1/6] fwu_metadata: make sure structures are packed
Hi Heinrich,
thanks for the review,
Heinrich Schuchardt writes:
> On 5/3/23 10:06, Ilias Apalodimas wrote:
>> On Tue, 2 May 2023 at 16:12, Rui Miguel Silva wrote:
>>
>> Hi Rui,
>>>
>>> The fwu metadata in the metadata partitions
>>> should/are packed to guarantee that the info is
>>> correct in all platforms. Also the size of them
>>> are used to calculate the crc32 and that is important
>>> to get it right.
>>>
>>> Signed-off-by: Rui Miguel Silva
>>> ---
>>> include/fwu_mdata.h | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
>>> index 8fda4f4ac225..c61221a91735 100644
>>> --- a/include/fwu_mdata.h
>>> +++ b/include/fwu_mdata.h
>>> @@ -22,7 +22,7 @@ struct fwu_image_bank_info {
>>> efi_guid_t image_uuid;
>>> uint32_t accepted;
>>> uint32_t reserved;
>>> -};
>>> +} __packed;
>
> This structure is naturally packed. Why should adding a __packed
> attribute make a difference?
Agree.
>
>>>
>>> /**
>>>* struct fwu_image_entry - information for a particular type of image
>>> @@ -38,7 +38,7 @@ struct fwu_image_entry {
>>> efi_guid_t image_type_uuid;
>>> efi_guid_t location_uuid;
>>> struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
>>> -};
>>> +} __packed;
>
> ditto
Agree.
>
>>>
>>> /**
>>>* struct fwu_mdata - FWU metadata structure for multi-bank updates
>>> @@ -62,6 +62,6 @@ struct fwu_mdata {
>>> uint32_t previous_active_index;
>>>
>>> struct fwu_image_entry img_entry[CONFIG_FWU_NUM_IMAGES_PER_BANK];
>>> -};
>>> +} __packed;
>
> Depending on the alignment of efi_guid_t __packed might make a
> difference here. But as efi_guid_t is defined as 4 aligned I can't see
> an impact here either.
but efi_guid_t is defined as 8 aligned, right?
Even though, I think that this type of data written to disk/flash
without guaranteeing (trusting natural picketing) packed and endianness
is never a good idea.
Cheers,
Rui
>
> Best regards
>
> Heinrich
>
>>>
>>> #endif /* _FWU_MDATA_H_ */
>>> --
>>> 2.40.0
>>>
>>
>> Yep, that's a good catch. The spec defines 'just' the offsets and not
>> the C representation, so those should be indeed packed.
>>
>> Reviewed-by: Ilias Apalodimas
Re: [PATCH] i2c: rockchip: De-initialize the bus after start bit failure
On 2023/5/25 20:18, Ondřej Jirman wrote:
From: Ondrej Jirman
Failure can happen when i2c is used without initializing pinctrl properly,
which U-Boot happily allows in SPL. Without this fix, further I2C access would
fail, even after proper pinctrl initialization.
Signed-off-by: Ondrej Jirman
Cc: Heiko Schocher
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/i2c/rk_i2c.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/rk_i2c.c b/drivers/i2c/rk_i2c.c
index f8fac45b6ca0..9927af94a80b 100644
--- a/drivers/i2c/rk_i2c.c
+++ b/drivers/i2c/rk_i2c.c
@@ -342,7 +342,7 @@ static int rockchip_i2c_xfer(struct udevice *bus, struct
i2c_msg *msg,
int nmsgs)
{
struct rk_i2c *i2c = dev_get_priv(bus);
- int ret;
+ int ret = 0;
debug("i2c_xfer: %d messages\n", nmsgs);
for (; nmsgs > 0; nmsgs--, msg++) {
@@ -356,14 +356,15 @@ static int rockchip_i2c_xfer(struct udevice *bus, struct
i2c_msg *msg,
}
if (ret) {
debug("i2c_write: error sending\n");
- return -EREMOTEIO;
+ ret = -EREMOTEIO;
+ break;
}
}
rk_i2c_send_stop_bit(i2c);
rk_i2c_disable(i2c);
- return 0;
+ return ret;
}
int rockchip_i2c_set_bus_speed(struct udevice *bus, unsigned int speed)
[PATCH 3/4] ARM: dts: rockchip: rk3588-rock-5b-u-boot: add USB3 support
Enable the USB3.0 host node, and gadget node.
The gadget is available through the USB type C connector on the board.
The connector is tied to a Fairchild fusb302b device, which currently
does not have a driver in U-boot, but the node is here for correct
description of the board + Linux future compatibility.
It will be easier to move the node as-is when it will be available
in the DT from Linux
Signed-off-by: Eugen Hristev
---
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 197
1 file changed, 197 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 1cd8a57a6fa6..5a3292699640 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
/ {
aliases {
@@ -18,6 +19,25 @@
u-boot,spl-boot-order = "same-as-spl", ,
};
+ vcc12v_dcin: vcc12v-dcin-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc12v_dcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+
+ vcc5v0_usbdcin: vcc5v0-usbdcin {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_usbdcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_dcin>;
+ };
+
vcc5v0_host: vcc5v0-host-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_host";
@@ -29,6 +49,28 @@
pinctrl-0 = <_host_en>;
vin-supply = <_sys>;
};
+
+ vcc5v0_usb: vcc5v0-usb {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_usb";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_usbdcin>;
+ };
+
+ vbus5v0_typec: vbus5v0-typec {
+ compatible = "regulator-fixed";
+ regulator-name = "vbus5v0_typec";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ enable-active-high;
+ gpio = < RK_PB6 GPIO_ACTIVE_HIGH>;
+ vin-supply = <_usb>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pwren>;
+ };
};
_ps {
@@ -85,6 +127,16 @@
rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO _pull_none>;
};
};
+
+ usb-typec {
+ usbc0_int: usbc0-int {
+ rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO _pull_up>;
+ };
+
+ typec5v_pwren: typec5v-pwren {
+ rockchip,pins = <2 RK_PB6 RK_FUNC_GPIO _pull_none>;
+ };
+ };
};
_pull_none {
@@ -168,6 +220,15 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+_otg {
+ rockchip,typec-vbus-det;
+ status = "okay";
+};
+
{
resets = < SRST_OTGPHY_U2_0>, < SRST_P_USB2PHY_U2_0_GRF0>;
reset-names = "phy", "apb";
@@ -209,3 +270,139 @@
status = "okay";
};
+_phy0 {
+ orientation-switch;
+ svid = <0xff01>;
+ sbu1-dc-gpios = < RK_PA6 GPIO_ACTIVE_HIGH>;
+ sbu2-dc-gpios = < RK_PA7 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ usbdp_phy0_orientation_switch: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_orien_sw>;
+ };
+
+ usbdp_phy0_dp_altmode_mux: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <_altmode_mux>;
+ };
+ };
+};
+
+_phy0_u3 {
+ status = "okay";
+};
+
+_0 {
+ status = "okay";
+};
+
+_dwc3_0 {
+ dr_mode = "otg";
+ usb-role-switch;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ dwc3_0_role_switch: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <_role_sw>;
+ };
+ };
+};
+
+_phy1 {
+ rockchip,dp-lane-mux = <2 3>;
+ status = "okay";
+};
+
+_phy1_u3 {
+ status = "okay";
+};
+
+_1 {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_otg {
+ status = "okay";
+};
+
+ {
+ pinctrl-0 = <_xfer>;
+ status = "okay";
+
+ usbc0: fusb302@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <>;
+
[PATCH 2/4] ARM: dts: rockchip: rk3588: add support for USB 3.0 devices
From: Joseph Chen
Add support for the USB 3.0 devices in rk3588:
- USB DRD(dual role device) 3.0 #0 as usbdrd3_0 which is available in
rk3588s
- USB DRD(dual role device) 3.0 #1 as usbdrd3_1 which is available in
rk3588 only
- USB DP PHY (combo USB3.0 and DisplayPort Alt Mode ) #0 phy interface
as usbdp_phy0
- USB DP PHY (combo USB3.0 and DisplayPort Alt Mode ) #1 phy interface
as usbdp_phy1
- USB 2.0 phy #2 , the USB 3.0 device can work with this phy in USB 2.0
mode
- associated GRFs (general register files) for the devices.
Signed-off-by: Joseph Chen
[eugen.hris...@collabora.com: move nodes to right place, adapt from latest
linux kernel]
Signed-off-by: Eugen Hristev
---
arch/arm/dts/rk3588-u-boot.dtsi | 93 +++
arch/arm/dts/rk3588s-u-boot.dtsi | 105 +++
2 files changed, 198 insertions(+)
diff --git a/arch/arm/dts/rk3588-u-boot.dtsi b/arch/arm/dts/rk3588-u-boot.dtsi
index 4c8ac804d615..68b419f3abd5 100644
--- a/arch/arm/dts/rk3588-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-u-boot.dtsi
@@ -5,3 +5,96 @@
#include "rockchip-u-boot.dtsi"
#include "rk3588s-u-boot.dtsi"
+
+/ {
+ usbdrd3_1: usbdrd3_1 {
+ compatible = "rockchip,rk3588-dwc3", "rockchip,rk3399-dwc3";
+ clocks = < REF_CLK_USB3OTG1>, < SUSPEND_CLK_USB3OTG1>,
+< ACLK_USB3OTG1>;
+ clock-names = "ref", "suspend", "bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ usbdrd_dwc3_1: usb@fc40 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfc40 0x0 0x40>;
+ interrupts = ;
+ power-domains = < RK3588_PD_USB>;
+ resets = < SRST_A_USB3OTG1>;
+ reset-names = "usb3-otg";
+ dr_mode = "host";
+ phys = <_otg>, <_phy1_u3>;
+ phy-names = "usb2-phy", "usb3-phy";
+ phy_type = "utmi_wide";
+ snps,dis_enblslpm_quirk;
+ snps,dis-u2-freeclk-exists-quirk;
+ snps,dis-del-phy-power-chg-quirk;
+ snps,dis-tx-ipgap-linecheck-quirk;
+ };
+ };
+
+ usbdpphy1_grf: syscon@fd5cc000 {
+ compatible = "rockchip,rk3588-usbdpphy-grf", "syscon";
+ reg = <0x0 0xfd5cc000 0x0 0x4000>;
+ };
+
+ usb2phy1_grf: syscon@fd5d4000 {
+ compatible = "rockchip,rk3588-usb2phy-grf", "syscon",
+"simple-mfd";
+ reg = <0x0 0xfd5d4000 0x0 0x4000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ u2phy1: usb2-phy@4000 {
+ compatible = "rockchip,rk3588-usb2phy";
+ reg = <0x4000 0x10>;
+ interrupts = ;
+ resets = < SRST_OTGPHY_U3_1>, <
SRST_P_USB2PHY_U3_1_GRF0>;
+ reset-names = "phy", "apb";
+ clocks = < CLK_USB2PHY_HDPTXRXPHY_REF>;
+ clock-names = "phyclk";
+ clock-output-names = "usb480m_phy1";
+ #clock-cells = <0>;
+ rockchip,usbctrl-grf = <_grf>;
+ status = "disabled";
+
+ u2phy1_otg: otg-port {
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+ };
+ };
+
+ usbdp_phy1: phy@fed9 {
+ compatible = "rockchip,rk3588-usbdp-phy";
+ reg = <0x0 0xfed9 0x0 0x1>;
+ rockchip,u2phy-grf = <_grf>;
+ rockchip,usb-grf = <_grf>;
+ rockchip,usbdpphy-grf = <_grf>;
+ rockchip,vo-grf = <_grf>;
+ clocks = < CLK_USBDPPHY_MIPIDCPPHY_REF>,
+< CLK_USBDP_PHY1_IMMORTAL>,
+< PCLK_USBDPPHY1>,
+<>;
+ clock-names = "refclk", "immortal", "pclk", "utmi";
+ resets = < SRST_USBDP_COMBO_PHY1_INIT>,
+< SRST_USBDP_COMBO_PHY1_CMN>,
+< SRST_USBDP_COMBO_PHY1_LANE>,
+< SRST_USBDP_COMBO_PHY1_PCS>,
+< SRST_P_USBDPPHY1>;
+ reset-names = "init", "cmn", "lane", "pcs_apb", "pma_apb";
+ status = "disabled";
+
+ usbdp_phy1_dp: dp-port {
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ usbdp_phy1_u3: usb3-port {
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi
[PATCH 4/4] configs: rock5b-rk3588: enable USB 3.0 controller, command, gadget
Enable configuration for USB 3.0 controller, the commands required, and the gadget drivers. Signed-off-by: Eugen Hristev --- configs/rock5b-rk3588_defconfig | 14 ++ 1 file changed, 14 insertions(+) diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig index a4a3c0afd178..3f28a68f0c94 100644 --- a/configs/rock5b-rk3588_defconfig +++ b/configs/rock5b-rk3588_defconfig @@ -47,9 +47,11 @@ CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 CONFIG_SPL_ATF=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y +CONFIG_CMD_ROCKUSB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_REGULATOR=y # CONFIG_SPL_DOS_PARTITION is not set @@ -59,6 +61,7 @@ CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigne CONFIG_SPL_REGMAP=y CONFIG_SPL_SYSCON=y CONFIG_SPL_CLK=y +# CONFIG_USB_FUNCTION_FASTBOOT is not set CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y @@ -76,6 +79,7 @@ CONFIG_GMAC_ROCKCHIP=y CONFIG_PCIE_DW_ROCKCHIP=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y +CONFIG_PHY_ROCKCHIP_USBDP=y CONFIG_SPL_PINCTRL=y CONFIG_REGULATOR_PWM=y CONFIG_PWM_ROCKCHIP=y @@ -86,10 +90,16 @@ CONFIG_SYS_NS16550_MEM32=y CONFIG_ROCKCHIP_SFC=y CONFIG_SYSRESET=y CONFIG_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_USB_XHCI_HCD=y +# CONFIG_USB_XHCI_DWC3_OF_SIMPLE is not set CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_GENERIC=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_GENERIC=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y +CONFIG_SPL_USB_DWC3_GENERIC=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_ASIX=y CONFIG_USB_ETHER_ASIX88179=y @@ -98,4 +108,8 @@ CONFIG_USB_ETHER_LAN78XX=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_PRODUCT_NUM=0x350b +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_USB_FUNCTION_ROCKUSB=y CONFIG_ERRNO_STR=y -- 2.34.1
[PATCH 1/4] phy: rockchip: add usbdp combo phy driver
From: Frank Wang
This adds a new USBDP combo PHY with Samsung IP block driver.
The PHY is a combo between USB 3.0 and DisplayPort alt mode.
Signed-off-by: Frank Wang
[eugen.hris...@collabora.com: ported to 2023.07, clean-up]
Signed-off-by: Eugen Hristev
---
drivers/phy/rockchip/Kconfig | 7 +
drivers/phy/rockchip/Makefile | 1 +
drivers/phy/rockchip/phy-rockchip-usbdp.c | 880 ++
include/linux/usb/phy-rockchip-usbdp.h| 70 ++
4 files changed, 958 insertions(+)
create mode 100644 drivers/phy/rockchip/phy-rockchip-usbdp.c
create mode 100644 include/linux/usb/phy-rockchip-usbdp.h
diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index f87ca8c31060..0247d93ab401 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -41,6 +41,13 @@ config PHY_ROCKCHIP_SNPS_PCIE3
It could support PCIe Gen3 single root complex, and could
also be able splited into multiple combinations of lanes.
+config PHY_ROCKCHIP_USBDP
+ tristate "Rockchip USBDP COMBO PHY Driver"
+ depends on ARCH_ROCKCHIP
+ select PHY
+ help
+ Enable this to support the Rockchip USB3.0/DP
+ combo PHY with Samsung IP block.
config PHY_ROCKCHIP_TYPEC
bool "Rockchip TYPEC PHY Driver"
diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile
index 25a803a8a86f..7fdbd107976d 100644
--- a/drivers/phy/rockchip/Makefile
+++ b/drivers/phy/rockchip/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_PHY_ROCKCHIP_PCIE) += phy-rockchip-pcie.o
obj-$(CONFIG_PHY_ROCKCHIP_SNPS_PCIE3) += phy-rockchip-snps-pcie3.o
obj-$(CONFIG_PHY_ROCKCHIP_TYPEC) += phy-rockchip-typec.o
obj-$(CONFIG_PHY_ROCKCHIP_INNO_DSIDPHY)+= phy-rockchip-inno-dsidphy.o
+obj-$(CONFIG_PHY_ROCKCHIP_USBDP) += phy-rockchip-usbdp.o
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c
b/drivers/phy/rockchip/phy-rockchip-usbdp.c
new file mode 100644
index ..baf92529348c
--- /dev/null
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -0,0 +1,880 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Rockchip USBDP Combo PHY with Samsung IP block driver
+ *
+ * Copyright (C) 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define BIT_WRITEABLE_SHIFT16
+
+enum {
+ UDPHY_MODE_NONE = 0,
+ UDPHY_MODE_USB = BIT(0),
+ UDPHY_MODE_DP = BIT(1),
+ UDPHY_MODE_DP_USB = BIT(1) | BIT(0),
+};
+
+struct udphy_grf_reg {
+ unsigned intoffset;
+ unsigned intbitend;
+ unsigned intbitstart;
+ unsigned intdisable;
+ unsigned intenable;
+};
+
+/**
+ * struct reg_sequence - An individual write from a sequence of writes.
+ *
+ * @reg: Register address.
+ * @def: Register value.
+ * @delay_us: Delay to be applied after the register write in microseconds
+ *
+ * Register/value pairs for sequences of writes with an optional delay in
+ * microseconds to be applied after each write.
+ */
+struct reg_sequence {
+ unsigned int reg;
+ unsigned int def;
+ unsigned int delay_us;
+};
+
+struct udphy_grf_cfg {
+ /* u2phy-grf */
+ struct udphy_grf_regbvalid_phy_con;
+ struct udphy_grf_regbvalid_grf_con;
+
+ /* usb-grf */
+ struct udphy_grf_regusb3otg0_cfg;
+ struct udphy_grf_regusb3otg1_cfg;
+
+ /* usbdpphy-grf */
+ struct udphy_grf_reglow_pwrn;
+ struct udphy_grf_regrx_lfps;
+};
+
+struct rockchip_udphy;
+
+struct rockchip_udphy_cfg {
+ /* resets to be requested */
+ const char * const *rst_list;
+ int num_rsts;
+
+ struct udphy_grf_cfg grfcfg;
+ int (*combophy_init)(struct rockchip_udphy *udphy);
+};
+
+struct rockchip_udphy {
+ struct udevice *dev;
+ struct regmap *pma_regmap;
+ struct regmap *u2phygrf;
+ struct regmap *udphygrf;
+ struct regmap *usbgrf;
+ struct regmap *vogrf;
+
+ /* clocks and rests */
+ struct reset_ctl *rsts;
+
+ /* PHY status management */
+ bool flip;
+ bool mode_change;
+ u8 mode;
+ u8 status;
+
+ /* utilized for USB */
+ bool hs; /* flag for high-speed */
+
+ /* utilized for DP */
+ struct gpio_desc *sbu1_dc_gpio;
+ struct gpio_desc *sbu2_dc_gpio;
+ u32 lane_mux_sel[4];
+ u32 dp_lane_sel[4];
+ u32 dp_aux_dout_sel;
+ u32 dp_aux_din_sel;
+ int id;
+
+ /* PHY const config */
+ const struct rockchip_udphy_cfg *cfgs;
+};
+
+static const struct reg_sequence rk3588_udphy_24m_refclk_cfg[] = {
+ {0x0090, 0x68}, {0x0094, 0x68},
+ {0x0128, 0x24}, {0x012c, 0x44},
+ {0x0130, 0x3f}, {0x0134, 0x44},
+ {0x015c, 0xa9}, {0x0160,
[PATCH 0/4] rockchip: rk3588: add USB 3.0 support
This series adds preliminary support for USB 3.0 using the Dual Role Devices DRD based on DWC3 controller One controller is in host mode : 1 Hub (5 Gb/s, 0mA) | U-Boot XHCI Host Controller | +-2 Mass Storage (480 Mb/s, 100mA) TDK LoR TF10 C900587416E2C552 The other is in gadget mode, and to test it out, I enabled rockusb Currently it works to remotely reboot the board e.g. : $ sudo rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x350b,LocationID=601Maskrom $ sudo rkdeveloptool rd Reset Device OK. => rockusb 0 mmc 0 dwc3-generic-peripheral usb@fc00: request edf44580 was not queued to ep1in-bulk rockkusb set reboot flag: 0 resetting ... For a typeC to typeC gadget connection, it only works in one orientation. To get orientation flipping support, another patch series is required, for the fairchild fusb driver and type C stack. Current patch series also adds the USB-DP combo phy driver. The DWC3 controllers each have two PHYs, one for USB 2.0 (the inno2 usb2 phy) and the usbdp for USB 3.0 . Eugen Hristev (2): ARM: dts: rockchip: rk3588-rock-5b-u-boot: add USB3 support configs: rock5b-rk3588: enable USB 3.0 controller, command, gadget Frank Wang (1): phy: rockchip: add usbdp combo phy driver Joseph Chen (1): ARM: dts: rockchip: rk3588: add support for USB 3.0 devices arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 197 + arch/arm/dts/rk3588-u-boot.dtsi | 93 +++ arch/arm/dts/rk3588s-u-boot.dtsi | 105 +++ configs/rock5b-rk3588_defconfig | 14 + drivers/phy/rockchip/Kconfig | 7 + drivers/phy/rockchip/Makefile | 1 + drivers/phy/rockchip/phy-rockchip-usbdp.c | 880 ++ include/linux/usb/phy-rockchip-usbdp.h| 70 ++ 8 files changed, 1367 insertions(+) create mode 100644 drivers/phy/rockchip/phy-rockchip-usbdp.c create mode 100644 include/linux/usb/phy-rockchip-usbdp.h -- 2.34.1
Re: [PATCH] video: rockchip: Add support for RK3399 to dw-mipi-dsi bridge
On 2023/5/25 20:29, Ondřej Jirman wrote:
From: Ondrej Jirman
This just needs some extra clocks enabled, and different registers
configured. Copied from Linux, just like the original submitter
of this driver did for rk3568.
Tested on Pinephone Pro.
Signed-off-by: Ondrej Jirman
Cc: Anatolij Gustschin
Cc: Simon Glass
Cc: Philipp Tomsich
Cc: Kever Yang
Cc: Chris Morgan
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 99 +++
1 file changed, 99 insertions(+)
diff --git a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
index 1bb1c7c67d07..9ec3a48bf2a5 100644
--- a/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
+++ b/drivers/video/rockchip/dw_mipi_dsi_rockchip.c
@@ -134,6 +134,32 @@
#define HS_RX_CONTROL_OF_LANE_2 0x84
#define HS_RX_CONTROL_OF_LANE_3 0x94
+#define DW_MIPI_NEEDS_PHY_CFG_CLK BIT(0)
+#define DW_MIPI_NEEDS_GRF_CLK BIT(1)
+
+#define RK3399_GRF_SOC_CON20 0x6250
+#define RK3399_DSI0_LCDC_SEL BIT(0)
+#define RK3399_DSI1_LCDC_SEL BIT(4)
+
+#define RK3399_GRF_SOC_CON22 0x6258
+#define RK3399_DSI0_TURNREQUEST(0xf << 12)
+#define RK3399_DSI0_TURNDISABLE(0xf << 8)
+#define RK3399_DSI0_FORCETXSTOPMODE(0xf << 4)
+#define RK3399_DSI0_FORCERXMODE(0xf << 0)
+
+#define RK3399_GRF_SOC_CON23 0x625c
+#define RK3399_DSI1_TURNDISABLE(0xf << 12)
+#define RK3399_DSI1_FORCETXSTOPMODE(0xf << 8)
+#define RK3399_DSI1_FORCERXMODE(0xf << 4)
+#define RK3399_DSI1_ENABLE (0xf << 0)
+
+#define RK3399_GRF_SOC_CON24 0x6260
+#define RK3399_TXRX_MASTERSLAVEZ BIT(7)
+#define RK3399_TXRX_ENABLECLK BIT(6)
+#define RK3399_TXRX_BASEDIRBIT(5)
+#define RK3399_TXRX_SRC_SEL_ISP0 BIT(4)
+#define RK3399_TXRX_TURNREQUESTGENMASK(3, 0)
+
#define RK3568_GRF_VO_CON20x0368
#define RK3568_DSI0_SKEWCALHS (0x1f << 11)
#define RK3568_DSI0_FORCETXSTOPMODE (0xf << 4)
@@ -209,6 +235,8 @@ struct dw_rockchip_dsi_priv {
struct clk *pclk;
struct clk *ref;
+ struct clk *grf_clk;
+ struct clk *phy_cfg_clk;
struct reset_ctl *rst;
unsigned int lane_mbps; /* per lane */
u16 input_div;
@@ -844,6 +872,28 @@ static int dw_mipi_dsi_rockchip_probe(struct udevice *dev)
}
}
+ if (cdata->flags & DW_MIPI_NEEDS_PHY_CFG_CLK) {
+ priv->phy_cfg_clk = devm_clk_get(dev, "phy_cfg");
+ if (IS_ERR(priv->phy_cfg_clk)) {
+ ret = PTR_ERR(priv->phy_cfg_clk);
+ dev_err(dev, "phy_cfg_clk clock get error %d\n", ret);
+ return ret;
+ }
+
+ clk_enable(priv->phy_cfg_clk);
+ }
+
+ if (cdata->flags & DW_MIPI_NEEDS_GRF_CLK) {
+ priv->grf_clk = devm_clk_get(dev, "grf");
+ if (IS_ERR(priv->grf_clk)) {
+ ret = PTR_ERR(priv->grf_clk);
+ dev_err(dev, "grf_clk clock get error %d\n", ret);
+ return ret;
+ }
+
+ clk_enable(priv->grf_clk);
+ }
+
priv->rst = devm_reset_control_get_by_index(device->dev, 0);
if (IS_ERR(priv->rst)) {
ret = PTR_ERR(priv->rst);
@@ -864,6 +914,52 @@ struct video_bridge_ops dw_mipi_dsi_rockchip_ops = {
.set_backlight = dw_mipi_dsi_rockchip_set_bl,
};
+static const struct rockchip_dw_dsi_chip_data rk3399_chip_data[] = {
+ {
+ .reg = 0xff96,
+ .lcdsel_grf_reg = RK3399_GRF_SOC_CON20,
+ .lcdsel_big = HIWORD_UPDATE(0, RK3399_DSI0_LCDC_SEL),
+ .lcdsel_lit = HIWORD_UPDATE(RK3399_DSI0_LCDC_SEL,
+ RK3399_DSI0_LCDC_SEL),
+
+ .lanecfg1_grf_reg = RK3399_GRF_SOC_CON22,
+ .lanecfg1 = HIWORD_UPDATE(0, RK3399_DSI0_TURNREQUEST |
+RK3399_DSI0_TURNDISABLE |
+RK3399_DSI0_FORCETXSTOPMODE |
+RK3399_DSI0_FORCERXMODE),
+
+ .flags = DW_MIPI_NEEDS_PHY_CFG_CLK | DW_MIPI_NEEDS_GRF_CLK,
+ .max_data_lanes = 4,
+ },
+ {
+ .reg = 0xff968000,
+ .lcdsel_grf_reg = RK3399_GRF_SOC_CON20,
+ .lcdsel_big = HIWORD_UPDATE(0, RK3399_DSI1_LCDC_SEL),
+ .lcdsel_lit = HIWORD_UPDATE(RK3399_DSI1_LCDC_SEL,
+ RK3399_DSI1_LCDC_SEL),
+
+ .lanecfg1_grf_reg = RK3399_GRF_SOC_CON23,
+ .lanecfg1 = HIWORD_UPDATE(0, RK3399_DSI1_TURNDISABLE |
+
Re: [PATCH v2 2/2] rockchip: rk3568: Add support for FriendlyARM NanoPi R5C
On 2023/5/29 12:59, Tianling Shen wrote:
FriendlyARM NanoPi R5C is an open-sourced mini IoT gateway device.
Specification:
- Rockchip RK3568
- 1/4GB LPDDR4X RAM
- 8/32GB eMMC
- SD card slot
- M.2 Connector
- 2x USB 3.0 Port
- 2x 2500 Base-T (PCIe, r8125)
- HDMI 2.0
- MIPI DSI/CSI
- USB Type C 5V
The device tree is taken from kernel v6.4-rc1.
Signed-off-by: Tianling Shen
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Changes in v2: add dtb to Makefile
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3568-nanopi-r5c-u-boot.dtsi | 3 +
arch/arm/dts/rk3568-nanopi-r5c.dts | 112 +
board/rockchip/evb_rk3568/MAINTAINERS | 7 ++
configs/nanopi-r5c-rk3568_defconfig| 90 +
5 files changed, 213 insertions(+)
create mode 100644 arch/arm/dts/rk3568-nanopi-r5c-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-nanopi-r5c.dts
create mode 100644 configs/nanopi-r5c-rk3568_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e2eda3ffcb..507bfb512a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -169,6 +169,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-anbernic-rgxx3.dtb \
rk3566-radxa-cm3-io.dtb \
rk3568-evb.dtb \
+ rk3568-nanopi-r5c.dtb \
rk3568-nanopi-r5s.dtb \
rk3568-rock-3a.dtb
diff --git a/arch/arm/dts/rk3568-nanopi-r5c-u-boot.dtsi b/arch/arm/dts/rk3568-nanopi-r5c-u-boot.dtsi
new file mode 100644
index 00..fe5bc6af47
--- /dev/null
+++ b/arch/arm/dts/rk3568-nanopi-r5c-u-boot.dtsi
@@ -0,0 +1,3 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rk3568-nanopi-r5s-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3568-nanopi-r5c.dts
b/arch/arm/dts/rk3568-nanopi-r5c.dts
new file mode 100644
index 00..f70ca9f047
--- /dev/null
+++ b/arch/arm/dts/rk3568-nanopi-r5c.dts
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2022 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyelec.com)
+ *
+ * Copyright (c) 2023 Tianling Shen
+ */
+
+/dts-v1/;
+#include "rk3568-nanopi-r5s.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPi R5C";
+ compatible = "friendlyarm,nanopi-r5c", "rockchip,rk3568";
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <_button_pin>;
+
+ button-reset {
+ debounce-interval = <50>;
+ gpios = < RK_PB7 GPIO_ACTIVE_LOW>;
+ label = "reset";
+ linux,code = ;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_led_pin>, <_led_pin>, <_led_pin>,
<_led_pin>;
+
+ led-lan {
+ color = ;
+ function = LED_FUNCTION_LAN;
+ gpios = < RK_PA3 GPIO_ACTIVE_HIGH>;
+ };
+
+ power_led: led-power {
+ color = ;
+ function = LED_FUNCTION_POWER;
+ linux,default-trigger = "heartbeat";
+ gpios = < RK_PA2 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-wan {
+ color = ;
+ function = LED_FUNCTION_WAN;
+ gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-wlan {
+ color = ;
+ function = LED_FUNCTION_WLAN;
+ gpios = < RK_PA5 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_reset_pin>;
+ reset-gpios = < RK_PC1 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+};
+
+ {
+ num-lanes = <1>;
+ reset-gpios = < RK_PA0 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <_pcie>;
+ status = "okay";
+};
+
+ {
+ num-lanes = <1>;
+ reset-gpios = < RK_PB6 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <_pcie>;
+ status = "okay";
+};
+
+ {
+ gpio-leds {
+ lan_led_pin: lan-led-pin {
+ rockchip,pins = <3 RK_PA3 RK_FUNC_GPIO _pull_none>;
+ };
+
+ power_led_pin: power-led-pin {
+ rockchip,pins = <3 RK_PA2 RK_FUNC_GPIO _pull_none>;
+ };
+
+ wan_led_pin: wan-led-pin {
+ rockchip,pins = <3 RK_PA4 RK_FUNC_GPIO _pull_none>;
+ };
+
+ wlan_led_pin: wlan-led-pin {
+ rockchip,pins = <3 RK_PA5 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ pcie {
+ pcie20_reset_pin: pcie20-reset-pin {
+ rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO _pull_up>;
+ };
+ };
+
+ rockchip-key {
+
Re: [PATCH v2 1/2] rockchip: rk3568: Add support for FriendlyARM NanoPi R5S
On 2023/5/29 12:59, Tianling Shen wrote:
FriendlyElec Nanopi R5S is an open-sourced mini IoT gateway device.
Board Specifications
- Rockchip RK3568
- 2 or 4GB LPDDR4X
- 8GB or 16GB eMMC, SD card slot
- GbE LAN (Native)
- 2x 2.5G LAN (PCIe)
- M.2 Connector
- HDMI 2.0, MIPI DSI/CSI
- 2xUSB 3.0 Host
- USB Type C PD, 5V/9V/12V
- GPIO: 12-pin 0.5mm FPC connector
The device tree is taken from kernel v6.4-rc1.
Signed-off-by: Tianling Shen
Reviewed-by: Kever Yang
Thanks,
- Kever
---
No changes in v2.
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi | 33 ++
arch/arm/dts/rk3568-nanopi-r5s.dts | 136 +
arch/arm/dts/rk3568-nanopi-r5s.dtsi| 590 +
board/rockchip/evb_rk3568/MAINTAINERS | 8 +
configs/nanopi-r5s-rk3568_defconfig| 90
6 files changed, 858 insertions(+)
create mode 100644 arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-nanopi-r5s.dts
create mode 100644 arch/arm/dts/rk3568-nanopi-r5s.dtsi
create mode 100644 configs/nanopi-r5s-rk3568_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa60..e2eda3ffcb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -169,6 +169,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-anbernic-rgxx3.dtb \
rk3566-radxa-cm3-io.dtb \
rk3568-evb.dtb \
+ rk3568-nanopi-r5s.dtb \
rk3568-rock-3a.dtb
dtb-$(CONFIG_ROCKCHIP_RK3588) += \
diff --git a/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
new file mode 100644
index 00..b37ad1e72d
--- /dev/null
+++ b/arch/arm/dts/rk3568-nanopi-r5s-u-boot.dtsi
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2022 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyelec.com)
+ *
+ * Copyright (c) 2023 Tianling Shen
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
+
+ {
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+};
+
+ {
+ bus-width = <4>;
+ bootph-pre-ram;
+ u-boot,spl-fifo-mode;
+};
+
+ {
+ clock-frequency = <2400>;
+ bootph-pre-ram;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3568-nanopi-r5s.dts
b/arch/arm/dts/rk3568-nanopi-r5s.dts
new file mode 100644
index 00..b6ad8328c7
--- /dev/null
+++ b/arch/arm/dts/rk3568-nanopi-r5s.dts
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) 2022 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyelec.com)
+ *
+ * Copyright (c) 2023 Tianling Shen
+ */
+
+/dts-v1/;
+#include "rk3568-nanopi-r5s.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPi R5S";
+ compatible = "friendlyarm,nanopi-r5s", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 =
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_led_pin>, <_led_pin>, <_led_pin>,
<_led_pin>;
+
+ led-lan1 {
+ color = ;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <1>;
+ gpios = < RK_PD6 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-lan2 {
+ color = ;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <2>;
+ gpios = < RK_PD7 GPIO_ACTIVE_HIGH>;
+ };
+
+ power_led: led-power {
+ color = ;
+ function = LED_FUNCTION_POWER;
+ linux,default-trigger = "heartbeat";
+ gpios = < RK_PD2 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-wan {
+ color = ;
+ function = LED_FUNCTION_WAN;
+ gpios = < RK_PC1 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ {
+ assigned-clocks = < SCLK_GMAC0_RX_TX>, < SCLK_GMAC0>;
+ assigned-clock-parents = < SCLK_GMAC0_RGMII_SPEED>, <
CLK_MAC0_2TOP>;
+ assigned-clock-rates = <0>, <12500>;
+ clock_in_out = "output";
+ phy-handle = <_phy0>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <_miim
+_tx_bus2
+_rx_bus2
+_rgmii_clk
+_rgmii_bus>;
+ snps,reset-gpio = < RK_PC5 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ /* Reset time is 15ms, 50ms for rtl8211f */
+ snps,reset-delays-us = <0 15000 5>;
+ tx_delay = <0x3c>;
+ rx_delay = <0x2f>;
+ status = "okay";
+};
+
+ {
+ rgmii_phy0: ethernet-phy@1 {
+ compatible =
Re: [PATCH] ARM: dts: rockchip: rk3588: sync with Linux
On 2023/5/29 15:34, Eugen Hristev wrote:
Sync the devicetree with linux-next tag: next-20230525
Signed-off-by: Eugen Hristev
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3588-rock-5b.dts | 152
arch/arm/dts/rk3588.dtsi | 68 +
arch/arm/dts/rk3588s-u-boot.dtsi | 12 --
arch/arm/dts/rk3588s.dtsi| 234 ++-
4 files changed, 449 insertions(+), 17 deletions(-)
diff --git a/arch/arm/dts/rk3588-rock-5b.dts b/arch/arm/dts/rk3588-rock-5b.dts
index 95805cb0adfa..3e4aee8f70c1 100644
--- a/arch/arm/dts/rk3588-rock-5b.dts
+++ b/arch/arm/dts/rk3588-rock-5b.dts
@@ -2,6 +2,7 @@
/dts-v1/;
+#include
#include "rk3588.dtsi"
/ {
@@ -17,6 +18,31 @@
stdout-path = "serial2:150n8";
};
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 95 145 195 255>;
+ fan-supply = <_sys>;
+ pwms = < 0 5 0>;
+ #cooling-cells = <2>;
+ };
+
+ sound {
+ compatible = "audio-graph-card";
+ label = "Analog";
+
+ widgets = "Microphone", "Mic Jack",
+ "Headphone", "Headphones";
+
+ routing = "MIC2", "Mic Jack",
+ "Headphones", "HPOL",
+ "Headphones", "HPOR";
+
+ dais = <_8ch_p0>;
+ hp-det-gpio = < RK_PD5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_detect>;
+ };
+
vcc5v0_sys: vcc5v0-sys-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_sys";
@@ -27,6 +53,132 @@
};
};
+_b0 {
+ cpu-supply = <_cpu_big0_s0>;
+};
+
+_b1 {
+ cpu-supply = <_cpu_big0_s0>;
+};
+
+_b2 {
+ cpu-supply = <_cpu_big1_s0>;
+};
+
+_b3 {
+ cpu-supply = <_cpu_big1_s0>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_xfer>;
+ status = "okay";
+
+ vdd_cpu_big0_s0: regulator@42 {
+ compatible = "rockchip,rk8602";
+ reg = <0x42>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu_big0_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <55>;
+ regulator-max-microvolt = <105>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_big1_s0: regulator@43 {
+ compatible = "rockchip,rk8603", "rockchip,rk8602";
+ reg = <0x43>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu_big1_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <55>;
+ regulator-max-microvolt = <105>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ hym8563: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-output-names = "hym8563";
+ pinctrl-names = "default";
+ pinctrl-0 = <_int>;
+ interrupt-parent = <>;
+ interrupts = ;
+ wakeup-source;
+ };
+};
+
+ {
+ status = "okay";
+
+ es8316: audio-codec@11 {
+ compatible = "everest,es8316";
+ reg = <0x11>;
+ clocks = < I2S0_8CH_MCLKOUT>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+
+ port {
+ es8316_p0_0: endpoint {
+ remote-endpoint = <_8ch_p0_0>;
+ };
+ };
+ };
+};
+
+_8ch {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lrck
+_mclk
+_sclk
+_sdi0
+_sdo0>;
+ status = "okay";
+
+ i2s0_8ch_p0: port {
+ i2s0_8ch_p0_0: endpoint {
+ dai-format = "i2s";
+ mclk-fs = <256>;
+ remote-endpoint = <_p0_0>;
+ };
+ };
+};
+
+ {
+ hym8563 {
+ hym8563_int: hym8563-int {
+ rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ sound {
+ hp_detect: hp-detect {
+ rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
+
+ {
+ status =
Re: [PATCH] pinephone-pro: Fix I/O port voltage (GPIO3D4A is 1.8V)
Hi Ondrej, Thanks for your patch. On 2023/5/25 21:27, Ondřej Jirman wrote: From: Ondrej Jirman This fixes access to camera sensor over I2C during probe time in the kernel. (Kernel will fix I/0 port voltage by itself, but the timing depends on probe order of the drivers, so the fix can come after the camera sensor driver already failed to probe.) Signed-off-by: Ondrej Jirman Cc: Kever Yang Reviewed-by: Kever Yang Thanks, - Kever --- board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c index eb639cd0d070..b6ccbb9c1c4b 100644 --- a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c +++ b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c @@ -15,7 +15,8 @@ #include #include -#define GRF_IO_VSEL_BT565_SHIFT 0 +#define GRF_IO_VSEL_BT565_GPIO2AB 1 +#define GRF_IO_VSEL_AUDIO_GPIO3D4A 2 #define PMUGRF_CON0_VSEL_SHIFT 8 #ifndef CONFIG_SPL_BUILD @@ -48,7 +49,8 @@ static void setup_iodomain(void) syscon_get_first_range(ROCKCHIP_SYSCON_PMUGRF); /* BT565 is in 1.8v domain */ - rk_setreg(>io_vsel, 1 << GRF_IO_VSEL_BT565_SHIFT); + rk_setreg(>io_vsel, + GRF_IO_VSEL_BT565_GPIO2AB | GRF_IO_VSEL_AUDIO_GPIO3D4A); /* Set GPIO1 1.8v/3.0v source select to PMU1830_VOL */ rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
Re: [PATCH 2/6] nvmxip: move header to include
On 5/2/23 15:11, Rui Miguel Silva wrote:
Move header to include to allow external code
to get the internal bdev structures to access
block device operations.
as at it, just add the UCLASS_NVMXIP string
so we get the correct output in partitions
listing.
Signed-off-by: Rui Miguel Silva
---
{drivers/mtd/nvmxip => include}/nvmxip.h | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename {drivers/mtd/nvmxip => include}/nvmxip.h (100%)
diff --git a/drivers/mtd/nvmxip/nvmxip.h b/include/nvmxip.h
similarity index 100%
rename from drivers/mtd/nvmxip/nvmxip.h
rename to include/nvmxip.h
We expect the code to compile after each single patch. Otherwise
bisecting will not work.
You cannot move an include without adjusting all references, e.g.
test/dm/nvmxip.c:20:#include "../../drivers/mtd/nvmxip/nvmxip.h"
Best regards
Heinrich
Re: [RESEND PATCH v1 2/4] riscv: dts: t-head: Add basic device tree for Sipeed Lichee PI 4A board
Hi Guo: On 16:22 Mon 29 May , Guo Ren wrote: > On Mon, May 29, 2023 at 3:54 PM Yixun Lan wrote: > > > > Hi Guo: > > > > On 14:50 Mon 29 May , Guo Ren wrote: > > > On Mon, May 29, 2023 at 11:01 AM Yixun Lan wrote: > > > > > > > > Hi Guo: > > > > > > > > see my comment below. > > > > > > > > On 09:19 Mon 29 May , Guo Ren wrote: > > > > > On Sat, May 27, 2023 at 5:17 PM Yixun Lan wrote: > > > > > > > > > > > > Hi Guo: > > > > > > > > > > > > On 09:43 Sat 27 May , Guo Ren wrote: > > > > > > > Sorry, why we need dts here? If we put dts here, we could delete > > > > > > > the > > > > > > > one in Linux. > > > > > > No, I think it's more than a historical reason for why we have two > > > > > > dts > > > > > > both in u-boot and kernel. And this dts here is merely used by > > > > > > u-boot, > > > > > > it could be a simplified version comparing to kernel's dts. > > > > > > > > > > > > > > > > > > > > We shouldn't put it with two places, that would be bad for > > > > > > > maintanice. > > > > > > I can totally understand your concern, in fact, we are trying to > > > > > > keep them sync, > > > > > > so I will probably wait the dts of kernel settle down, before take > > > > > > action here. > > > > > > so, please conside this patch as RFC, and may change in next > > > > > > revisions.. > > > > > Thx for clarification. But I still concern the necessary of the patch, > > > > > could you move this from this series first, because we've argument on > > > > > it. Your other patches looks good, I'm looking forward your next v2. > > > > > > > > > > But for this one, let's talk it after kernel side merged. > > > > I'd like to include dts in the first series, otherwise it won't be a > > > > complete > > > > working series, e.g. - not only it's unable to build, also can't do > > > > run-time test > > > I couldn't make sense how it block your build, The build operation is > > > controlled by you Makefile modification. right? > > > > > you mostly right, but in patch "[ 3/4 ] configs: th1520_lpi4a_defconfig: Add > > initial config", we will enable device tree, and require > > CONFIG_DEFAULT_DEVICE_TREE="th1520-lichee-pi-4a.dtb" to be provided, > > also since UART's base register is parsed from dts (run time), so I see no > > reason > > why the dts patch should be separated > Oh, I see; u-boot needs a seperate dtb to boot indepedent. Maybe, we > just keep a minimum dts here, then we needn't syncronize with the > kernel side. > yes, that's the plan, we will keep necessary dts here, and try to keep it sync with kernel when needed.. > > > > > diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile > > > index 79a58694f5..72fd815a40 100644 > > > --- a/arch/riscv/dts/Makefile > > > +++ b/arch/riscv/dts/Makefile > > > @@ -9,6 +9,7 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += > > > hifive-unmatched-a00.dtb > > > dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb > > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += > > > jh7110-starfive-visionfive-2-v1.3b.dtb > > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += > > > jh7110-starfive-visionfive-2-v1.2a.dtb > > > +dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb > > > include $(srctree)/scripts/Makefile.dts > > > > > > > > > > > I'm totally fine with kernel dts merged first, then submit this later, > > > > so no push.. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, May 26, 2023 at 8:41 PM Yixun Lan wrote: > > > > > > > > > > > > > > > > Only add basic support for CPU, PLIC UART and Timer. > > > > > > > > > > > > > > > > Reviewed-by: Wei Fu > > > > > > > > Signed-off-by: Yixun Lan > > > > > > > > --- > > > > > > > > arch/riscv/dts/Makefile | 1 + > > > > > > > > arch/riscv/dts/th1520-lichee-module-4a.dtsi | 34 ++ > > > > > > > > arch/riscv/dts/th1520-lichee-pi-4a.dts | 32 ++ > > > > > > > > arch/riscv/dts/th1520.dtsi | 435 > > > > > > > > > > > > > > > > 4 files changed, 502 insertions(+) > > > > > > > > create mode 100644 arch/riscv/dts/th1520-lichee-module-4a.dtsi > > > > > > > > create mode 100644 arch/riscv/dts/th1520-lichee-pi-4a.dts > > > > > > > > create mode 100644 arch/riscv/dts/th1520.dtsi > > > > > > > > > > > > > > > > diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile > > > > > > > > index 79a58694f5..72fd815a40 100644 > > > > > > > > --- a/arch/riscv/dts/Makefile > > > > > > > > +++ b/arch/riscv/dts/Makefile > > > > > > > > @@ -9,6 +9,7 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += > > > > > > > > hifive-unmatched-a00.dtb > > > > > > > > dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb > > > > > > > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += > > > > > > > > jh7110-starfive-visionfive-2-v1.3b.dtb > > > > > > > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += > > > > > > > > jh7110-starfive-visionfive-2-v1.2a.dtb > > > > > > > > +dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb > > > > > > > >
Re: [PATCH 1/6] fwu_metadata: make sure structures are packed
On 5/3/23 10:06, Ilias Apalodimas wrote:
On Tue, 2 May 2023 at 16:12, Rui Miguel Silva wrote:
Hi Rui,
The fwu metadata in the metadata partitions
should/are packed to guarantee that the info is
correct in all platforms. Also the size of them
are used to calculate the crc32 and that is important
to get it right.
Signed-off-by: Rui Miguel Silva
---
include/fwu_mdata.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/fwu_mdata.h b/include/fwu_mdata.h
index 8fda4f4ac225..c61221a91735 100644
--- a/include/fwu_mdata.h
+++ b/include/fwu_mdata.h
@@ -22,7 +22,7 @@ struct fwu_image_bank_info {
efi_guid_t image_uuid;
uint32_t accepted;
uint32_t reserved;
-};
+} __packed;
This structure is naturally packed. Why should adding a __packed
attribute make a difference?
/**
* struct fwu_image_entry - information for a particular type of image
@@ -38,7 +38,7 @@ struct fwu_image_entry {
efi_guid_t image_type_uuid;
efi_guid_t location_uuid;
struct fwu_image_bank_info img_bank_info[CONFIG_FWU_NUM_BANKS];
-};
+} __packed;
ditto
/**
* struct fwu_mdata - FWU metadata structure for multi-bank updates
@@ -62,6 +62,6 @@ struct fwu_mdata {
uint32_t previous_active_index;
struct fwu_image_entry img_entry[CONFIG_FWU_NUM_IMAGES_PER_BANK];
-};
+} __packed;
Depending on the alignment of efi_guid_t __packed might make a
difference here. But as efi_guid_t is defined as 4 aligned I can't see
an impact here either.
Best regards
Heinrich
#endif /* _FWU_MDATA_H_ */
--
2.40.0
Yep, that's a good catch. The spec defines 'just' the offsets and not
the C representation, so those should be indeed packed.
Reviewed-by: Ilias Apalodimas
Re: [PATCH 0/6] corstone1000: fwu metadata and GPT
Hi,
Rui Miguel Silva writes:
> Hi,
> Rui Miguel Silva writes:
>> Now that the nvmxip block driver is merged we can add on top
>> of it the platform code to use GPT and FWU metadata in the
>> Corstone1000.
>>
>> But first, push 2 fixes that are needed to make all this work:
>> - move nvmxip header to include
>> - setup fwu metadata structures as packed (we have a 32bit
>>writer - Secure enclave Cortex-M0 and a 64bit reader host
>>Cortex-A35)
>
> Gentle ping.
>
> Cheers,
>Rui
It would be great to have some feedback on this ones.
Many thanks.
Cheers,
Rui
>>
>> Cheers,
>> Rui
>>
>> Rui Miguel Silva (6):
>> fwu_metadata: make sure structures are packed
>> nvmxip: move header to include
>> corstone1000: add fwu-metadata store info
>> corstone1000: add boot index
>> corstone1000: set kernel_addr based on boot_idx
>> corstone1000: add nvmxip, fwu-mdata and gpt options
>>
>> arch/arm/dts/corstone1000.dtsi | 7 ++-
>> board/armltd/corstone1000/corstone1000.c | 73 +-
>> board/armltd/corstone1000/corstone1000.env | 10 +--
>> configs/corstone1000_defconfig | 14 -
>> include/fwu_mdata.h| 6 +-
>> {drivers/mtd/nvmxip => include}/nvmxip.h | 0
>> 6 files changed, 95 insertions(+), 15 deletions(-)
>> rename {drivers/mtd/nvmxip => include}/nvmxip.h (100%)
>>
>> --
>> 2.40.0
Re: [RESEND PATCH v1 2/4] riscv: dts: t-head: Add basic device tree for Sipeed Lichee PI 4A board
On Mon, May 29, 2023 at 3:54 PM Yixun Lan wrote: > > Hi Guo: > > On 14:50 Mon 29 May , Guo Ren wrote: > > On Mon, May 29, 2023 at 11:01 AM Yixun Lan wrote: > > > > > > Hi Guo: > > > > > > see my comment below. > > > > > > On 09:19 Mon 29 May , Guo Ren wrote: > > > > On Sat, May 27, 2023 at 5:17 PM Yixun Lan wrote: > > > > > > > > > > Hi Guo: > > > > > > > > > > On 09:43 Sat 27 May , Guo Ren wrote: > > > > > > Sorry, why we need dts here? If we put dts here, we could delete the > > > > > > one in Linux. > > > > > No, I think it's more than a historical reason for why we have two dts > > > > > both in u-boot and kernel. And this dts here is merely used by u-boot, > > > > > it could be a simplified version comparing to kernel's dts. > > > > > > > > > > > > > > > > > We shouldn't put it with two places, that would be bad for > > > > > > maintanice. > > > > > I can totally understand your concern, in fact, we are trying to keep > > > > > them sync, > > > > > so I will probably wait the dts of kernel settle down, before take > > > > > action here. > > > > > so, please conside this patch as RFC, and may change in next > > > > > revisions.. > > > > Thx for clarification. But I still concern the necessary of the patch, > > > > could you move this from this series first, because we've argument on > > > > it. Your other patches looks good, I'm looking forward your next v2. > > > > > > > > But for this one, let's talk it after kernel side merged. > > > I'd like to include dts in the first series, otherwise it won't be a > > > complete > > > working series, e.g. - not only it's unable to build, also can't do > > > run-time test > > I couldn't make sense how it block your build, The build operation is > > controlled by you Makefile modification. right? > > > you mostly right, but in patch "[ 3/4 ] configs: th1520_lpi4a_defconfig: Add > initial config", we will enable device tree, and require > CONFIG_DEFAULT_DEVICE_TREE="th1520-lichee-pi-4a.dtb" to be provided, > also since UART's base register is parsed from dts (run time), so I see no > reason > why the dts patch should be separated Oh, I see; u-boot needs a seperate dtb to boot indepedent. Maybe, we just keep a minimum dts here, then we needn't syncronize with the kernel side. > > > diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile > > index 79a58694f5..72fd815a40 100644 > > --- a/arch/riscv/dts/Makefile > > +++ b/arch/riscv/dts/Makefile > > @@ -9,6 +9,7 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += > > hifive-unmatched-a00.dtb > > dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += > > jh7110-starfive-visionfive-2-v1.3b.dtb > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += > > jh7110-starfive-visionfive-2-v1.2a.dtb > > +dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb > > include $(srctree)/scripts/Makefile.dts > > > > > > > > I'm totally fine with kernel dts merged first, then submit this later, so > > > no push.. > > > > > > > > > > > > > > > > > > > > > > > > On Fri, May 26, 2023 at 8:41 PM Yixun Lan wrote: > > > > > > > > > > > > > > Only add basic support for CPU, PLIC UART and Timer. > > > > > > > > > > > > > > Reviewed-by: Wei Fu > > > > > > > Signed-off-by: Yixun Lan > > > > > > > --- > > > > > > > arch/riscv/dts/Makefile | 1 + > > > > > > > arch/riscv/dts/th1520-lichee-module-4a.dtsi | 34 ++ > > > > > > > arch/riscv/dts/th1520-lichee-pi-4a.dts | 32 ++ > > > > > > > arch/riscv/dts/th1520.dtsi | 435 > > > > > > > > > > > > > > 4 files changed, 502 insertions(+) > > > > > > > create mode 100644 arch/riscv/dts/th1520-lichee-module-4a.dtsi > > > > > > > create mode 100644 arch/riscv/dts/th1520-lichee-pi-4a.dts > > > > > > > create mode 100644 arch/riscv/dts/th1520.dtsi > > > > > > > > > > > > > > diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile > > > > > > > index 79a58694f5..72fd815a40 100644 > > > > > > > --- a/arch/riscv/dts/Makefile > > > > > > > +++ b/arch/riscv/dts/Makefile > > > > > > > @@ -9,6 +9,7 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += > > > > > > > hifive-unmatched-a00.dtb > > > > > > > dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb > > > > > > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += > > > > > > > jh7110-starfive-visionfive-2-v1.3b.dtb > > > > > > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += > > > > > > > jh7110-starfive-visionfive-2-v1.2a.dtb > > > > > > > +dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb > > > > > > > include $(srctree)/scripts/Makefile.dts > > > > > > > > > > > > > > targets += $(dtb-y) > > > > > > > diff --git a/arch/riscv/dts/th1520-lichee-module-4a.dtsi > > > > > > > b/arch/riscv/dts/th1520-lichee-module-4a.dtsi > > > > > > > new file mode 100644 > > > > > > > index 00..dc00e3dfa0 > > > > > > > --- /dev/null > > > > > > > +++ b/arch/riscv/dts/th1520-lichee-module-4a.dtsi > > > > > > > @@
Re: [RESEND PATCH v1 2/4] riscv: dts: t-head: Add basic device tree for Sipeed Lichee PI 4A board
Hi Guo:
On 14:50 Mon 29 May , Guo Ren wrote:
> On Mon, May 29, 2023 at 11:01 AM Yixun Lan wrote:
> >
> > Hi Guo:
> >
> > see my comment below.
> >
> > On 09:19 Mon 29 May , Guo Ren wrote:
> > > On Sat, May 27, 2023 at 5:17 PM Yixun Lan wrote:
> > > >
> > > > Hi Guo:
> > > >
> > > > On 09:43 Sat 27 May , Guo Ren wrote:
> > > > > Sorry, why we need dts here? If we put dts here, we could delete the
> > > > > one in Linux.
> > > > No, I think it's more than a historical reason for why we have two dts
> > > > both in u-boot and kernel. And this dts here is merely used by u-boot,
> > > > it could be a simplified version comparing to kernel's dts.
> > > >
> > > > >
> > > > > We shouldn't put it with two places, that would be bad for maintanice.
> > > > I can totally understand your concern, in fact, we are trying to keep
> > > > them sync,
> > > > so I will probably wait the dts of kernel settle down, before take
> > > > action here.
> > > > so, please conside this patch as RFC, and may change in next revisions..
> > > Thx for clarification. But I still concern the necessary of the patch,
> > > could you move this from this series first, because we've argument on
> > > it. Your other patches looks good, I'm looking forward your next v2.
> > >
> > > But for this one, let's talk it after kernel side merged.
> > I'd like to include dts in the first series, otherwise it won't be a
> > complete
> > working series, e.g. - not only it's unable to build, also can't do
> > run-time test
> I couldn't make sense how it block your build, The build operation is
> controlled by you Makefile modification. right?
>
you mostly right, but in patch "[ 3/4 ] configs: th1520_lpi4a_defconfig: Add
initial config", we will enable device tree, and require
CONFIG_DEFAULT_DEVICE_TREE="th1520-lichee-pi-4a.dtb" to be provided,
also since UART's base register is parsed from dts (run time), so I see no
reason
why the dts patch should be separated
> diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> index 79a58694f5..72fd815a40 100644
> --- a/arch/riscv/dts/Makefile
> +++ b/arch/riscv/dts/Makefile
> @@ -9,6 +9,7 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) +=
> hifive-unmatched-a00.dtb
> dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
> dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) +=
> jh7110-starfive-visionfive-2-v1.3b.dtb
> dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) +=
> jh7110-starfive-visionfive-2-v1.2a.dtb
> +dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb
> include $(srctree)/scripts/Makefile.dts
>
> >
> > I'm totally fine with kernel dts merged first, then submit this later, so
> > no push..
> >
> > >
> > > >
> > > > >
> > > > > On Fri, May 26, 2023 at 8:41 PM Yixun Lan wrote:
> > > > > >
> > > > > > Only add basic support for CPU, PLIC UART and Timer.
> > > > > >
> > > > > > Reviewed-by: Wei Fu
> > > > > > Signed-off-by: Yixun Lan
> > > > > > ---
> > > > > > arch/riscv/dts/Makefile | 1 +
> > > > > > arch/riscv/dts/th1520-lichee-module-4a.dtsi | 34 ++
> > > > > > arch/riscv/dts/th1520-lichee-pi-4a.dts | 32 ++
> > > > > > arch/riscv/dts/th1520.dtsi | 435
> > > > > >
> > > > > > 4 files changed, 502 insertions(+)
> > > > > > create mode 100644 arch/riscv/dts/th1520-lichee-module-4a.dtsi
> > > > > > create mode 100644 arch/riscv/dts/th1520-lichee-pi-4a.dts
> > > > > > create mode 100644 arch/riscv/dts/th1520.dtsi
> > > > > >
> > > > > > diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> > > > > > index 79a58694f5..72fd815a40 100644
> > > > > > --- a/arch/riscv/dts/Makefile
> > > > > > +++ b/arch/riscv/dts/Makefile
> > > > > > @@ -9,6 +9,7 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) +=
> > > > > > hifive-unmatched-a00.dtb
> > > > > > dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
> > > > > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) +=
> > > > > > jh7110-starfive-visionfive-2-v1.3b.dtb
> > > > > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) +=
> > > > > > jh7110-starfive-visionfive-2-v1.2a.dtb
> > > > > > +dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb
> > > > > > include $(srctree)/scripts/Makefile.dts
> > > > > >
> > > > > > targets += $(dtb-y)
> > > > > > diff --git a/arch/riscv/dts/th1520-lichee-module-4a.dtsi
> > > > > > b/arch/riscv/dts/th1520-lichee-module-4a.dtsi
> > > > > > new file mode 100644
> > > > > > index 00..dc00e3dfa0
> > > > > > --- /dev/null
> > > > > > +++ b/arch/riscv/dts/th1520-lichee-module-4a.dtsi
> > > > > > @@ -0,0 +1,34 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > > +/*
> > > > > > + * Copyright (C) 2023 Jisheng Zhang
> > > > > > + */
> > > > > > +
> > > > > > +/dts-v1/;
> > > > > > +
> > > > > > +#include "th1520.dtsi"
> > > > > > +
> > > > > > +/ {
> > > > > > + model = "Sipeed Lichee Module 4A";
> > > > > > + compatible = "sipeed,lichee-module-4a", "thead,th1520";
> > > > > > +
> > > > > > +
[PATCH] ARM: dts: rockchip: rk3588: sync with Linux
Sync the devicetree with linux-next tag: next-20230525
Signed-off-by: Eugen Hristev
---
arch/arm/dts/rk3588-rock-5b.dts | 152
arch/arm/dts/rk3588.dtsi | 68 +
arch/arm/dts/rk3588s-u-boot.dtsi | 12 --
arch/arm/dts/rk3588s.dtsi| 234 ++-
4 files changed, 449 insertions(+), 17 deletions(-)
diff --git a/arch/arm/dts/rk3588-rock-5b.dts b/arch/arm/dts/rk3588-rock-5b.dts
index 95805cb0adfa..3e4aee8f70c1 100644
--- a/arch/arm/dts/rk3588-rock-5b.dts
+++ b/arch/arm/dts/rk3588-rock-5b.dts
@@ -2,6 +2,7 @@
/dts-v1/;
+#include
#include "rk3588.dtsi"
/ {
@@ -17,6 +18,31 @@
stdout-path = "serial2:150n8";
};
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 95 145 195 255>;
+ fan-supply = <_sys>;
+ pwms = < 0 5 0>;
+ #cooling-cells = <2>;
+ };
+
+ sound {
+ compatible = "audio-graph-card";
+ label = "Analog";
+
+ widgets = "Microphone", "Mic Jack",
+ "Headphone", "Headphones";
+
+ routing = "MIC2", "Mic Jack",
+ "Headphones", "HPOL",
+ "Headphones", "HPOR";
+
+ dais = <_8ch_p0>;
+ hp-det-gpio = < RK_PD5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_detect>;
+ };
+
vcc5v0_sys: vcc5v0-sys-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_sys";
@@ -27,6 +53,132 @@
};
};
+_b0 {
+ cpu-supply = <_cpu_big0_s0>;
+};
+
+_b1 {
+ cpu-supply = <_cpu_big0_s0>;
+};
+
+_b2 {
+ cpu-supply = <_cpu_big1_s0>;
+};
+
+_b3 {
+ cpu-supply = <_cpu_big1_s0>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_xfer>;
+ status = "okay";
+
+ vdd_cpu_big0_s0: regulator@42 {
+ compatible = "rockchip,rk8602";
+ reg = <0x42>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu_big0_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <55>;
+ regulator-max-microvolt = <105>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_big1_s0: regulator@43 {
+ compatible = "rockchip,rk8603", "rockchip,rk8602";
+ reg = <0x43>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu_big1_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <55>;
+ regulator-max-microvolt = <105>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ hym8563: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-output-names = "hym8563";
+ pinctrl-names = "default";
+ pinctrl-0 = <_int>;
+ interrupt-parent = <>;
+ interrupts = ;
+ wakeup-source;
+ };
+};
+
+ {
+ status = "okay";
+
+ es8316: audio-codec@11 {
+ compatible = "everest,es8316";
+ reg = <0x11>;
+ clocks = < I2S0_8CH_MCLKOUT>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+
+ port {
+ es8316_p0_0: endpoint {
+ remote-endpoint = <_8ch_p0_0>;
+ };
+ };
+ };
+};
+
+_8ch {
+ pinctrl-names = "default";
+ pinctrl-0 = <_lrck
+_mclk
+_sclk
+_sdi0
+_sdo0>;
+ status = "okay";
+
+ i2s0_8ch_p0: port {
+ i2s0_8ch_p0_0: endpoint {
+ dai-format = "i2s";
+ mclk-fs = <256>;
+ remote-endpoint = <_p0_0>;
+ };
+ };
+};
+
+ {
+ hym8563 {
+ hym8563_int: hym8563-int {
+ rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+
+ sound {
+ hp_detect: hp-detect {
+ rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
{
bus-width = <8>;
no-sdio;
diff --git a/arch/arm/dts/rk3588.dtsi
Re: [RESEND PATCH v1 2/4] riscv: dts: t-head: Add basic device tree for Sipeed Lichee PI 4A board
On Mon, May 29, 2023 at 11:01 AM Yixun Lan wrote:
>
> Hi Guo:
>
> see my comment below.
>
> On 09:19 Mon 29 May , Guo Ren wrote:
> > On Sat, May 27, 2023 at 5:17 PM Yixun Lan wrote:
> > >
> > > Hi Guo:
> > >
> > > On 09:43 Sat 27 May , Guo Ren wrote:
> > > > Sorry, why we need dts here? If we put dts here, we could delete the
> > > > one in Linux.
> > > No, I think it's more than a historical reason for why we have two dts
> > > both in u-boot and kernel. And this dts here is merely used by u-boot,
> > > it could be a simplified version comparing to kernel's dts.
> > >
> > > >
> > > > We shouldn't put it with two places, that would be bad for maintanice.
> > > I can totally understand your concern, in fact, we are trying to keep
> > > them sync,
> > > so I will probably wait the dts of kernel settle down, before take action
> > > here.
> > > so, please conside this patch as RFC, and may change in next revisions..
> > Thx for clarification. But I still concern the necessary of the patch,
> > could you move this from this series first, because we've argument on
> > it. Your other patches looks good, I'm looking forward your next v2.
> >
> > But for this one, let's talk it after kernel side merged.
> I'd like to include dts in the first series, otherwise it won't be a complete
> working series, e.g. - not only it's unable to build, also can't do run-time
> test
I couldn't make sense how it block your build, The build operation is
controlled by you Makefile modification. right?
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 79a58694f5..72fd815a40 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) +=
hifive-unmatched-a00.dtb
dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) +=
jh7110-starfive-visionfive-2-v1.3b.dtb
dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) +=
jh7110-starfive-visionfive-2-v1.2a.dtb
+dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb
include $(srctree)/scripts/Makefile.dts
>
> I'm totally fine with kernel dts merged first, then submit this later, so no
> push..
>
> >
> > >
> > > >
> > > > On Fri, May 26, 2023 at 8:41 PM Yixun Lan wrote:
> > > > >
> > > > > Only add basic support for CPU, PLIC UART and Timer.
> > > > >
> > > > > Reviewed-by: Wei Fu
> > > > > Signed-off-by: Yixun Lan
> > > > > ---
> > > > > arch/riscv/dts/Makefile | 1 +
> > > > > arch/riscv/dts/th1520-lichee-module-4a.dtsi | 34 ++
> > > > > arch/riscv/dts/th1520-lichee-pi-4a.dts | 32 ++
> > > > > arch/riscv/dts/th1520.dtsi | 435
> > > > >
> > > > > 4 files changed, 502 insertions(+)
> > > > > create mode 100644 arch/riscv/dts/th1520-lichee-module-4a.dtsi
> > > > > create mode 100644 arch/riscv/dts/th1520-lichee-pi-4a.dts
> > > > > create mode 100644 arch/riscv/dts/th1520.dtsi
> > > > >
> > > > > diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> > > > > index 79a58694f5..72fd815a40 100644
> > > > > --- a/arch/riscv/dts/Makefile
> > > > > +++ b/arch/riscv/dts/Makefile
> > > > > @@ -9,6 +9,7 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) +=
> > > > > hifive-unmatched-a00.dtb
> > > > > dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
> > > > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) +=
> > > > > jh7110-starfive-visionfive-2-v1.3b.dtb
> > > > > dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) +=
> > > > > jh7110-starfive-visionfive-2-v1.2a.dtb
> > > > > +dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb
> > > > > include $(srctree)/scripts/Makefile.dts
> > > > >
> > > > > targets += $(dtb-y)
> > > > > diff --git a/arch/riscv/dts/th1520-lichee-module-4a.dtsi
> > > > > b/arch/riscv/dts/th1520-lichee-module-4a.dtsi
> > > > > new file mode 100644
> > > > > index 00..dc00e3dfa0
> > > > > --- /dev/null
> > > > > +++ b/arch/riscv/dts/th1520-lichee-module-4a.dtsi
> > > > > @@ -0,0 +1,34 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > +/*
> > > > > + * Copyright (C) 2023 Jisheng Zhang
> > > > > + */
> > > > > +
> > > > > +/dts-v1/;
> > > > > +
> > > > > +#include "th1520.dtsi"
> > > > > +
> > > > > +/ {
> > > > > + model = "Sipeed Lichee Module 4A";
> > > > > + compatible = "sipeed,lichee-module-4a", "thead,th1520";
> > > > > +
> > > > > + memory@0 {
> > > > > + device_type = "memory";
> > > > > + reg = <0x0 0x 0x2 0x>;
> > > > > + };
> > > > > +};
> > > > > +
> > > > > + {
> > > > > + clock-frequency = <2400>;
> > > > > +};
> > > > > +
> > > > > +_32k {
> > > > > + clock-frequency = <32768>;
> > > > > +};
> > > > > +
> > > > > +_clk {
> > > > > + clock-frequency = <6250>;
> > > > > +};
> > > > > +
> > > > > +_sclk {
> > > > > + clock-frequency = <1>;
> > > > > +};
> > > > > diff --git a/arch/riscv/dts/th1520-lichee-pi-4a.dts
> > > > >
