[PATCH 2/2] ARM: stm32: Make PWR regulator driver available on STM32MP13xx
This patch makes STM32 PWR regulators available on stm32mp13xx. This requires TFA to clear RCC_SECCFGR, is disabled by default on stm32mp13xx and can only be enabled on board config level. Signed-off-by: Marek Vasut --- Cc: Patrice Chotard Cc: Patrick Delaunay Cc: Tom Rini Cc: u-b...@dh-electronics.com Cc: u-boot@lists.denx.de Cc: uboot-st...@st-md-mailman.stormreply.com --- arch/arm/mach-stm32mp/Kconfig | 17 + arch/arm/mach-stm32mp/Kconfig.15x | 16 2 files changed, 17 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig index b9af03d57e3..d5934a92771 100644 --- a/arch/arm/mach-stm32mp/Kconfig +++ b/arch/arm/mach-stm32mp/Kconfig @@ -155,4 +155,21 @@ source "arch/arm/mach-stm32mp/Kconfig.13x" source "arch/arm/mach-stm32mp/Kconfig.15x" source "arch/arm/mach-stm32mp/Kconfig.25x" source "arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig" + +config STM32MP15_PWR + bool "Enable driver for STM32MP15x PWR" + depends on DM_REGULATOR && DM_PMIC && (STM32MP13X || STM32MP15X) + default y if STM32MP15X + help + This config enables implementation of driver-model pmic and + regulator uclass features for access to STM32MP15x PWR. + +config SPL_STM32MP15_PWR + bool "Enable driver for STM32MP15x PWR in SPL" + depends on SPL && SPL_DM_REGULATOR && SPL_DM_PMIC && (STM32MP13X || STM32MP15X) + default y if STM32MP15X + help + This config enables implementation of driver-model pmic and + regulator uclass features for access to STM32MP15x PWR in SPL. + endif diff --git a/arch/arm/mach-stm32mp/Kconfig.15x b/arch/arm/mach-stm32mp/Kconfig.15x index 71c14eb4955..d99aa9fd694 100644 --- a/arch/arm/mach-stm32mp/Kconfig.15x +++ b/arch/arm/mach-stm32mp/Kconfig.15x @@ -77,22 +77,6 @@ config TARGET_ICORE_STM32MP1 endchoice -config STM32MP15_PWR - bool "Enable driver for STM32MP15x PWR" - depends on DM_REGULATOR && DM_PMIC - default y - help - This config enables implementation of driver-model pmic and - regulator uclass features for access to STM32MP15x PWR. - -config SPL_STM32MP15_PWR - bool "Enable driver for STM32MP15x PWR in SPL" - depends on SPL && SPL_DM_REGULATOR && SPL_DM_PMIC - default y - help - This config enables implementation of driver-model pmic and - regulator uclass features for access to STM32MP15x PWR in SPL. - config TEXT_BASE default 0xC010 -- 2.43.0
[PATCH 1/2] ARM: dts: stm32: add PWR regulators support on stm32mp131
This patch adds STM32 PWR regulators DT support on stm32mp131.
This requires TFA to clear RCC_SECCFGR, is disabled by default
and can only be enabled on board DT level.
Signed-off-by: Marek Vasut
---
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Tom Rini
Cc: u-b...@dh-electronics.com
Cc: u-boot@lists.denx.de
Cc: uboot-st...@st-md-mailman.stormreply.com
---
arch/arm/dts/stm32mp131.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
index 81d99a7582b..ad331b73d18 100644
--- a/arch/arm/dts/stm32mp131.dtsi
+++ b/arch/arm/dts/stm32mp131.dtsi
@@ -1092,6 +1092,30 @@
<_clk CK_SCMI_LSI>;
};
+ pwr_regulators: pwr@50001000 {
+ compatible = "st,stm32mp1,pwr-reg";
+ reg = <0x50001000 0x10>;
+ status = "disabled";
+
+ reg11: reg11 {
+ regulator-name = "reg11";
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <110>;
+ };
+
+ reg18: reg18 {
+ regulator-name = "reg18";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ usb33: usb33 {
+ regulator-name = "usb33";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+ };
+
exti: interrupt-controller@5000d000 {
compatible = "st,stm32mp13-exti", "syscon";
interrupt-controller;
--
2.43.0
[PATCH] ARM: stm32: Default dfu_alt_info for STM32MP13xx SPI NOR
Define dfu_alt_info with SPI NOR layout to make it easy to install or update bootloader in the SPI NOR using dfu-util. Use the following U-Boot commands to start DFU mode: " => sf probe && dfu 0 mtd " Use the following dfu-util invocation on Host PC to install binaries: " $ dfu-util -w -a 0 -D build/stm32mp1/release/tf-a-stm32mp135f-dhcor-dhsbc.stm32 $ dfu-util -w -a 1 -D build/stm32mp1/release/tf-a-stm32mp135f-dhcor-dhsbc.stm32 $ dfu-util -w -a 2 -D build/stm32mp1/release/fip.bin " Signed-off-by: Marek Vasut --- Cc: Patrice Chotard Cc: Patrick Delaunay Cc: Tom Rini Cc: u-b...@dh-electronics.com Cc: u-boot@lists.denx.de Cc: uboot-st...@st-md-mailman.stormreply.com --- include/configs/stm32mp13_common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/stm32mp13_common.h b/include/configs/stm32mp13_common.h index 5b0658ced92..d6e4f8fd915 100644 --- a/include/configs/stm32mp13_common.h +++ b/include/configs/stm32mp13_common.h @@ -63,6 +63,7 @@ "fi;\0" #define STM32MP_EXTRA \ + "dfu_alt_info=mtd nor0=fsbl1 raw 0x0 0x4;fsbl2 raw 0x4 0x4;uboot raw 0x8 0x16\0" \ "env_check=if env info -p -d -q; then env save; fi\0" \ "boot_net_usb_start=true\0" -- 2.43.0
[PATCH v3] arm: dts: armada-37xx: update devicetrees from linux
Update existing armada-37xx DTS files with those in linux
and add devicetree for ESPRESSObin Ultra device.
Signed-off-by: Benjamin Schneider
---
Changes in v3:
- fix U-Boot typo
- fix comment also missing from linux
Changes in v2:
- upstream is missing a patch for PCIe mem
arch/arm/dts/armada-3720-db.dts | 4 +-
.../arm/dts/armada-3720-espressobin-ultra.dts | 167 ++
arch/arm/dts/armada-3720-espressobin.dts | 2 +-
arch/arm/dts/armada-3720-espressobin.dtsi | 22 ++-
arch/arm/dts/armada-3720-turris-mox.dts | 131 --
arch/arm/dts/armada-3720-uDPU.dts | 8 +-
arch/arm/dts/armada-3720-uDPU.dtsi| 8 +-
arch/arm/dts/armada-372x.dtsi | 2 +-
arch/arm/dts/armada-37xx.dtsi | 34 +++-
9 files changed, 287 insertions(+), 91 deletions(-)
create mode 100644 arch/arm/dts/armada-3720-espressobin-ultra.dts
diff --git a/arch/arm/dts/armada-3720-db.dts b/arch/arm/dts/armada-3720-db.dts
index 1ee92406b7..717c896b81 100644
--- a/arch/arm/dts/armada-3720-db.dts
+++ b/arch/arm/dts/armada-3720-db.dts
@@ -18,7 +18,7 @@
/ {
model = "Marvell Armada 3720 Development Board DB-88F3720-DDR3";
- compatible = "marvell,armada-3720-db", "marvell,armada3720",
"marvell,armada3710";
+ compatible = "marvell,armada-3720-db", "marvell,armada3720",
"marvell,armada3700";
chosen {
stdout-path = "serial0:115200n8";
@@ -164,7 +164,7 @@
pinctrl-names = "default";
pinctrl-0 = <_quad_pins>;
- m25p80@0 {
+ flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <10800>;
diff --git a/arch/arm/dts/armada-3720-espressobin-ultra.dts
b/arch/arm/dts/armada-3720-espressobin-ultra.dts
new file mode 100644
index 00..870bb380a4
--- /dev/null
+++ b/arch/arm/dts/armada-3720-espressobin-ultra.dts
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree file for ESPRESSObin-Ultra board.
+ * Copyright (C) 2019 Globalscale technologies, Inc.
+ *
+ * Jason Hung
+ */
+
+/dts-v1/;
+
+#include "armada-3720-espressobin.dtsi"
+
+/ {
+ model = "Globalscale Marvell ESPRESSOBin Ultra Board";
+ compatible = "globalscale,espressobin-ultra", "globalscale,espressobin",
+"marvell,armada3720", "marvell,armada3700";
+
+ aliases {
+ /* ethernet1 is WAN port */
+ ethernet1 =
+ ethernet2 =
+ ethernet3 =
+ ethernet4 =
+ ethernet5 =
+ };
+
+ /delete-node/ regulator;
+
+ reg_usb3_vbus: usb3-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb3-vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ enable-active-high;
+ gpio = < 19 GPIO_ACTIVE_HIGH>;
+ };
+
+ usb3_phy: usb3-phy {
+ compatible = "usb-nop-xceiv";
+ vcc-supply = <_usb3_vbus>;
+ };
+
+ gpio-leds {
+ pinctrl-names = "default";
+ compatible = "gpio-leds";
+ /* No assigned functions to the LEDs by default */
+ led1 {
+ label = "ebin-ultra:blue:led1";
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ };
+ led2 {
+ label = "ebin-ultra:green:led2";
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ };
+ led3 {
+ label = "ebin-ultra:red:led3";
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ };
+ led4 {
+ label = "ebin-ultra:yellow:led4";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ /delete-property/ vqmmc-supply;
+ status = "disabled";
+};
+
+ {
+ flash@0 {
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "firmware";
+ reg = <0x0 0x3e>;
+ };
+ partition@3e {
+ label = "hw-info";
+ reg = <0x3e 0x1>;
+ read-only;
+ };
+ partition@3f {
+ label = "u-boot-env";
+ reg = <0x3f 0x1>;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ clock-frequency =
Re: [PATCH 1/3] boot: fdt: Change type of env_get_bootm_low() to phys_addr_t
On 3/17/24 6:18 PM, Heinrich Schuchardt wrote: [...] Shouldn't we convert to unsigned long long for printing. Printing phys_addr_t always confuses me. I was under the impression that turning the value into uintptr_t (platform pointer type represented as integer) and then actually using that as a pointer for printing should not suffer from any type width problems. Does it ? As you already remarked on LPAE this may happen. Though you may not be able load initrd outside the address range of void* the variables might exceed it. ACK, thanks for the confirmation.
Re: [PATCH 2/2] ARM: dts: renesas: Switch to using upstream DT on 64bit Renesas SoCs
On 3/18/24 5:14 PM, Adam Ford wrote: On Mon, Mar 18, 2024 at 10:00 AM Marek Vasut wrote: Enable OF_UPSTREAM to use upstream DT and add renesas/ prefix to the DEFAULT_DEVICE_TREE and OF_LIST. And thereby directly build DTB from dts/upstream/src/ including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory. The configuration update has been done using the following script: ``` sed -i '/^CONFIG_DEFAULT_DEVICE_TREE/ s@="@/@' `git grep -li renesas configs` sed -i '/^CONFIG_OF_LIST/ s@r8a@renesas/&@g' `git grep -li renesas configs` ``` There are SoCs which are not included in this patch. The 32bit SoCs require further infrastructure work. R8A779H0 is coming during the next upstream DT synchronization cycle as it is not included in current upstream DTs yet. Signed-off-by: Marek Vasut LTGM! Thanks for doing that. I was going to do that after the April release was done, but you beat me to it. Glad I could help. This will go into next release of course, i.e. 2024.07 .
Re: [PATCH 2/2] ARM: dts: renesas: Switch to using upstream DT on 64bit Renesas SoCs
On 3/18/24 7:15 PM, Paul Barker wrote: On 18/03/2024 14:59, Marek Vasut wrote: Enable OF_UPSTREAM to use upstream DT and add renesas/ prefix to the DEFAULT_DEVICE_TREE and OF_LIST. And thereby directly build DTB from dts/upstream/src/ including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory. The configuration update has been done using the following script: ``` sed -i '/^CONFIG_DEFAULT_DEVICE_TREE/ s@="@/@' `git grep -li renesas configs` sed -i '/^CONFIG_OF_LIST/ s@r8a@renesas/&@g' `git grep -li renesas configs` ``` There are SoCs which are not included in this patch. The 32bit SoCs require further infrastructure work. R8A779H0 is coming during the next upstream DT synchronization cycle as it is not included in current upstream DTs yet. Signed-off-by: Marek Vasut Reviewed-by: Paul Barker (for RZ/G2L only) Do we also plan to drop the corresponding .dts & .dtsi files from arch/arm/dts? Yes, once I'm done switching everything, I will drop them in bulk. -- Best regards, Marek Vasut
Re: [PATCH 1/2] clk: clk-imx8qxp: Add LPUART IPG entries
Hi Tom and Sean,
On Fri, Mar 8, 2024 at 5:13 PM Fabio Estevam wrote:
>
> Since commit cc7df0b9e8bc ("serial: lpuart: Enable IPG clock")
> the colibri-imx8qxp board no longer boots.
>
> The reason is that the imx8qxp clock driver does not handle the
> LPUART IPG clocks inside get_rate(), set_rate() and enable() functions.
>
> Fix the boot regression by adding the LPUART IPG entries.
>
> Fixes: cc7df0b9e8bc ("serial: lpuart: Enable IPG clock")
> Reported-by: Marcel Ziswiler
> Signed-off-by: Fabio Estevam
Please consider applying this series to 2024.04.
It fixes a boot regression on imx8qxp and imx8qm.
Thanks!
[PATCH] cmd: sysboot: null check filename
Currently if ${bootfile} is unset and sysboot is invoked with no
filename specified then U-Boot will crash will a null-pointer
dereference. Add the missing check and a matching error print.
Fixes: 993c912d304d ("cmd: sysboot: Create a sysboot command dedicated file")
Signed-off-by: Caleb Connolly
---
cmd/sysboot.c | 4
1 file changed, 4 insertions(+)
diff --git a/cmd/sysboot.c b/cmd/sysboot.c
index 63a7806debe4..d14c570d96ab 100644
--- a/cmd/sysboot.c
+++ b/cmd/sysboot.c
@@ -76,8 +76,12 @@ static int do_sysboot(struct cmd_tbl *cmdtp, int flag, int
argc,
}
if (argc < 6) {
filename = env_get("bootfile");
+ if (!filename) {
+ printf("Specify a filename or set the ${bootfile}
environment variable\n");
+ return 1;
+ }
} else {
filename = argv[5];
env_set("bootfile", filename);
}
--
2.44.0
Re: [PATCH v2 1/5] usb: dwc3-generic: implement Qualcomm wrapper
On 3/15/24 4:06 PM, Caleb Connolly wrote:
The Qualcomm specific dwc3 wrapper isn't hugely complicated, implemented
the missing initialisation for host and gadget mode.
Reviewed-by: Mattijs Korpershoek
Signed-off-by: Caleb Connolly
---
drivers/usb/dwc3/dwc3-generic.c | 81 -
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c
index a379a0002e77..5a355dd86c60 100644
--- a/drivers/usb/dwc3/dwc3-generic.c
+++ b/drivers/usb/dwc3/dwc3-generic.c
@@ -424,8 +424,79 @@ enum dwc3_omap_utmi_mode {
struct dwc3_glue_ops ti_ops = {
.glue_configure = dwc3_ti_glue_configure,
};
+/* USB QSCRATCH Hardware registers */
+#define QSCRATCH_HS_PHY_CTRL 0x10
+#define UTMI_OTG_VBUS_VALID BIT(20)
+#define SW_SESSVLD_SEL BIT(28)
+
+#define QSCRATCH_SS_PHY_CTRL 0x30
+#define LANE0_PWR_PRESENT BIT(24)
+
+#define QSCRATCH_GENERAL_CFG 0x08
Keep the list sorted, 0x08 goes above 0x10 ^ up there.
+#define PIPE_UTMI_CLK_SEL BIT(0)
+#define PIPE3_PHYSTATUS_SW BIT(3)
+#define PIPE_UTMI_CLK_DIS BIT(8)
+
+#define PWR_EVNT_IRQ_STAT_REG 0x58
+#define PWR_EVNT_LPM_IN_L2_MASK BIT(4)
+#define PWR_EVNT_LPM_OUT_L2_MASK BIT(5)
+
+#define SDM845_QSCRATCH_BASE_OFFSET 0xf8800
+#define SDM845_QSCRATCH_SIZE 0x400
+#define SDM845_DWC3_CORE_SIZE 0xcd00
The rest looks fine, with that fixed:
Reviewed-by: Marek Vasut
Thanks !
Re: imx7 issues with Secure and Non-Secure boot mode
On 3/7/24 10:26 AM, Emanuele Ghidoli wrote:
Hello,
I'm currently facing issues with our board, Colibri-imx7,
regarding its behavior in different boot modes:
- Secure Mode (bootm_boot_mode=sec in U-Boot):
When running Linux in secure mode, the idle time management does not function
properly. The following error message is displayed during boot:
"CPUidle arm: CPU 0 failed to init idle CPU ops".
- Non-Secure Mode (bootm_boot_mode=nonsec in U-Boot):
In non-secure mode, the caam_jr fails to initialize correctly,
preventing the utilization of the hardware random number generation.
The error message shown during boot is:
"caam_jr 30901000.jr: failed to flush job ring before reset".
I have conducted tests using both mainline and 6.1 stable versions,
with consistent results.
I have also reviewed the following threads for potential solutions:
- https://lore.kernel.org/u-boot/2536787.mZni4QDSI2@crypto/
-
https://lore.kernel.org/u-boot/CAByghJZn8d91uFr5JXSR=jXcfU4engZP_=buok7mnnjavei...@mail.gmail.com/
- https://lore.kernel.org/all/20220608170223.1536594-1-feste...@denx.de/T/
The first thread leave me thinking the only solution is to use OPTEE,
but the last email is without any answer.
So, I am considering the utilization of OPTEE, as it seems it might address
the issues discussed in the threads.
Could this configuration potentially resolve my current issues?
Your advice would be greatly appreciated.
Have a look at U-Boot
1f908b1898bd ("ARM: imx8m: Deduplicate CAAM init with arch_misc_init()
call")
Do you call this CAAM initialization on your machine ?
If not, try it, does it have any impact ?
Re: [PATCH 3/3] configs: imx93-phyboard-segin: Add fastboot support.
On 3/18/24 6:16 PM, Mathieu Othacehe wrote: Enable the `fastboot` command. Signed-off-by: Mathieu Othacehe Reviewed-by: Marek Vasut
Re: [PATCH 2/3] configs: imx93-phyboard-segin: Add USB support.
On 3/18/24 6:16 PM, Mathieu Othacehe wrote: Enable the `usb` command and some USB drivers. Signed-off-by: Mathieu Othacehe --- configs/imx93-phyboard-segin_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/configs/imx93-phyboard-segin_defconfig b/configs/imx93-phyboard-segin_defconfig index 24f9bd553aa..5acb987b817 100644 --- a/configs/imx93-phyboard-segin_defconfig +++ b/configs/imx93-phyboard-segin_defconfig @@ -23,6 +23,7 @@ CONFIG_SPL_STACK=0x20519dd0 CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x72 CONFIG_CMD_DEKBLOB=y +CONFIG_CMD_USB=y CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x8800 CONFIG_SYS_LOAD_ADDR=0x8040 CONFIG_SYS_MEMTEST_START=0x8000 @@ -132,6 +133,13 @@ CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_TMU=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_VENDOR_NUM=0x1fc9 +CONFIG_USB_GADGET_PRODUCT_NUM=0x0152 Shouldn't this by Phytec or similar USB IDs ?
Re: [PATCH 1/3] arm: dts: imx93-phyboard-segin: Add USB support.
On 3/18/24 6:16 PM, Mathieu Othacehe wrote:
Enable both usbotg1 and usbotg2 ports.
Drop fullstop from $subject end.
Signed-off-by: Mathieu Othacehe
---
arch/arm/dts/imx93-phyboard-segin.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/imx93-phyboard-segin.dts
b/arch/arm/dts/imx93-phyboard-segin.dts
index 85fb188b057..acf307a3192 100644
--- a/arch/arm/dts/imx93-phyboard-segin.dts
+++ b/arch/arm/dts/imx93-phyboard-segin.dts
@@ -40,6 +40,19 @@
status = "okay";
};
+/* USB */
+ {
+ disable-over-current;
Why is this needed ?
Re: [PATCH] starfive: visionfive2: switch to standard boot
On Thu, 2024-03-14 at 13:04, Nam Cao wrote: > On 13/Mar/2024 Milan P. Stanić wrote: > > On Wed, 2024-02-21 at 13:00, Nam Cao wrote: > > > Distro boot scripts are deprecated. Use standard boot instead. > > I had to enable 'CONFIG_CMD_SYSBOOT=y' in > > configs/starfive_visionfive2_defconfig because it doesn't boot without > > it. With this option it boots fine with this patch. > > You should not have to do that for it to work, otherwise this patch > introduced a bug. > > CONFIG_CMD_SYSBOOT adds the "sysboot" command, which is only used by > distroboot. So I suspect that you were actually still using distro boot, > because you didn't "update" your environment variable (that can be checked > with "printenv bootcmd"). For this patch to work, the environment variables > also need to be updated with: > env default > env save -a > > This makes me realize that the patch breaks boards if the users forget to > update the environment variables. I am not sure if this is considered a > bug. What do maintainers think? Rebuild it again and it worked out of the box. Tested-by: Milan P. Stanić
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
Hi Pierre, On Mon, Mar 18, 2024 at 4:59 PM Pierre-Clément Tosi wrote: > I notice that the mem_map in these logs have overlapping ranges, which results > in unnecessary work when creating the PTs. For this reason, it would make > sense > to prune it in arch/arm/mach-imx/imx8/cpu.c before calling dcache_enable(), > IMO. > On this point, you also have contiguous ranges with identical attributes > (mem_map[0] and mem_map[6]), which could be merged into a single entry. This > could result in more efficient MMU mappings if the mem_map entries can share a > block mapping. Also note that mem_map[4].size=0 so could be dropped. > > In any case, if we assume that overlapping mem_map entries are a valid input > to > the arch code (maybe not as it leads to potentially ambiguous behavior?), then > 41e2787f5ec4 had removed support for splitting existing block mappings. > > In your case, my assumption is that the function was then treating block > mappings in the range 0x1c00-0x8000 (which get mapped, at least > partially, by mem_map[0], mem_map[1], then mem_map[2]) as table mappings and > was > issuing read/write instructions in that range (accessing them as PTEs). As > those > seem to be device memory (I see they get mapped as MT_DEVICE_NGNRNE), these > accesses might explain the SError you were experiencing. > > Would you mind testing [1] and giving it "Tested-by:" if it addresses the > issue? Your patch fixed the boot regression. Thanks for your fix, appreciated it! I have replied with my Tested-by tag. Cheers, Fabio Estevam
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
Hi Fabio, On Mon, Mar 18, 2024 at 10:31:25AM -0300, Fabio Estevam wrote: > Please find the new logs here: > > https://pastebin.com/raw/qF3GbJry I notice that the mem_map in these logs have overlapping ranges, which results in unnecessary work when creating the PTs. For this reason, it would make sense to prune it in arch/arm/mach-imx/imx8/cpu.c before calling dcache_enable(), IMO. On this point, you also have contiguous ranges with identical attributes (mem_map[0] and mem_map[6]), which could be merged into a single entry. This could result in more efficient MMU mappings if the mem_map entries can share a block mapping. Also note that mem_map[4].size=0 so could be dropped. In any case, if we assume that overlapping mem_map entries are a valid input to the arch code (maybe not as it leads to potentially ambiguous behavior?), then 41e2787f5ec4 had removed support for splitting existing block mappings. In your case, my assumption is that the function was then treating block mappings in the range 0x1c00-0x8000 (which get mapped, at least partially, by mem_map[0], mem_map[1], then mem_map[2]) as table mappings and was issuing read/write instructions in that range (accessing them as PTEs). As those seem to be device memory (I see they get mapped as MT_DEVICE_NGNRNE), these accesses might explain the SError you were experiencing. Would you mind testing [1] and giving it "Tested-by:" if it addresses the issue? Thanks, [1]: https://lore.kernel.org/u-boot/43haokus4jdxguk4arig5tsqcgq2wbezwpbj7oti6pdkvrfual@wa7vz2iypcv5/ -- Pierre
Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks
Hi Pierre,
On Mon, Mar 18, 2024 at 4:35 PM Pierre-Clément Tosi wrote:
>
> The implementation of map_range() creates the requested mapping by
> walking the page tables, iterating over multiple PTEs and/or descending
> into existing table mappings as needed. When doing so, it assumes any
> pre-existing valid PTE to be a table mapping. This assumption is wrong
> if the platform code attempts to successively map two overlapping ranges
> where the latter intersects a block mapping created for the former.
>
> As a result, map_range() treats the existing block mapping as a table
> mapping and descends into it i.e. starts interpreting the
> previously-mapped range as an array of PTEs, writing to them and
> potentially even descending further (extra fun with MMIO ranges!).
>
> Instead, pass any valid non-table mapping to split_block(), which
> ensures that it actually was a block mapping (calls panic() otherwise)
> before splitting it.
>
> Fixes: 41e2787f5ec4 ("arm64: Reduce add_map() complexity")
> Signed-off-by: Pierre-Clément Tosi
This fixes the boot regression on colibri-imx8x.
Thanks a lot for your fix!
Tested-by: Fabio Estevam
[PATCH] arm64: Fix map_range() not splitting mapped blocks
The implementation of map_range() creates the requested mapping by
walking the page tables, iterating over multiple PTEs and/or descending
into existing table mappings as needed. When doing so, it assumes any
pre-existing valid PTE to be a table mapping. This assumption is wrong
if the platform code attempts to successively map two overlapping ranges
where the latter intersects a block mapping created for the former.
As a result, map_range() treats the existing block mapping as a table
mapping and descends into it i.e. starts interpreting the
previously-mapped range as an array of PTEs, writing to them and
potentially even descending further (extra fun with MMIO ranges!).
Instead, pass any valid non-table mapping to split_block(), which
ensures that it actually was a block mapping (calls panic() otherwise)
before splitting it.
Fixes: 41e2787f5ec4 ("arm64: Reduce add_map() complexity")
Signed-off-by: Pierre-Clément Tosi
---
arch/arm/cpu/armv8/cache_v8.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 697334086f..57d06f0575 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -326,6 +326,8 @@ static void map_range(u64 virt, u64 phys, u64 size, int
level,
/* Going one level down */
if (pte_type([i]) == PTE_TYPE_FAULT)
set_pte_table([i], create_table());
+ else if (pte_type([i]) != PTE_TYPE_TABLE)
+ split_block([i], level);
next_table = (u64 *)(table[i] & GENMASK_ULL(47, PAGE_SHIFT));
next_size = min(map_size - (virt & (map_size - 1)), size);
--
2.44.0.291.gc1ea87d7ee-goog
--
Pierre
Re: [PATCH 2/2] ARM: dts: renesas: Switch to using upstream DT on 64bit Renesas SoCs
On 18/03/2024 14:59, Marek Vasut wrote: > Enable OF_UPSTREAM to use upstream DT and add renesas/ prefix to the > DEFAULT_DEVICE_TREE and OF_LIST. And thereby directly build DTB from > dts/upstream/src/ including *-u-boot.dtsi files from arch/$(ARCH)/dts/ > directory. > > The configuration update has been done using the following script: > ``` > sed -i '/^CONFIG_DEFAULT_DEVICE_TREE/ s@="@/@' `git grep -li renesas > configs` > sed -i '/^CONFIG_OF_LIST/ s@r8a@renesas/&@g' `git grep -li renesas configs` > ``` > > There are SoCs which are not included in this patch. The 32bit SoCs > require further infrastructure work. R8A779H0 is coming during the > next upstream DT synchronization cycle as it is not included in > current upstream DTs yet. > > Signed-off-by: Marek Vasut Reviewed-by: Paul Barker (for RZ/G2L only) Do we also plan to drop the corresponding .dts & .dtsi files from arch/arm/dts? Thanks, -- Paul Barker OpenPGP_0x27F4B3459F002257.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH] doc: devicetree: Lets avoid short reference link names
On 02/03/2024 07:39, Paul Barker wrote: > On 01/03/2024 13:24, Sumit Garg wrote: >> Short reference link names like "dtspec", "dtrepo", "dttweaks" etc. >> interrupt the flow of the document text. Lets avoid them and instead >> expand in place for better readability. >> >> Suggested-by: Paul Barker >> Signed-off-by: Sumit Garg >> --- >> doc/develop/devicetree/control.rst | 24 >> 1 file changed, 12 insertions(+), 12 deletions(-) >> >> diff --git a/doc/develop/devicetree/control.rst >> b/doc/develop/devicetree/control.rst >> index c94d84192b71..4cc1457d4ea8 100644 >> --- a/doc/develop/devicetree/control.rst >> +++ b/doc/develop/devicetree/control.rst >> @@ -36,10 +36,10 @@ What is a Flattened Devicetree? >> --- >> >> An fdt can be specified in source format as a text file. To read about >> -the fdt syntax, take a look at the specification (dtspec_). >> +the fdt syntax, take a look at `the devicetree specification`_. >> >> -There is also a mailing list (dtlist_) for the compiler and associated >> -tools. >> +There is also a `devicetree compiler mailing list`_ for the compiler and >> +associated tools. >> >> In case you are wondering, OF stands for Open Firmware. This follows the >> convention used in Linux. >> @@ -89,7 +89,7 @@ Failing that, you could write one from scratch yourself! >> Resyncing with devicetree-rebasing >> -- >> >> -The devicetee-rebasing repository (dtrepo_) maintains a fork cum mirror >> copy of >> +The `devicetree-rebasing repository`_ maintains a fork cum mirror copy of >> devicetree files along with the bindings synced at every Linux kernel major >> release or intermediate release candidates. The U-Boot maintainers regularly >> sync the `dts/upstream/` subtree from the devicetree-rebasing repo whenever >> @@ -118,7 +118,7 @@ as `arch//dts/.dts`. To select that add `# >> CONFIG_OF_UPSTREAM is not >> set` and set `DEFAULT_DEVICE_TREE=` when prompted by Kconfig. >> >> This should include your CPU or SoC's devicetree file. On top of that any >> U-Boot >> -specific tweaks (see: dttweaks_) can be made for your board. >> +specific tweaks (see: :ref:`dttweaks`) can be made for your board. >> >> If `OF_EMBED` is selected by Kconfig, then it will be picked up and built >> into >> the U-Boot image (including u-boot.bin). This is suitable for debugging >> @@ -243,7 +243,7 @@ Dependencies >> >> The DT schema project must be installed in order to validate the DT schema >> binding documents and validate DTS files using the DT schema. For >> installation >> -instructions, refer to the DT schema project page (dtschema_). >> +instructions, refer to the `DT schema project page`_. >> >> Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be >> installed. Ensure they are in your PATH (~/.local/bin by default). >> @@ -333,10 +333,10 @@ used it before Linux (e.g. snow). The two projects >> developed in parallel >> and there are still some differences in the bindings for certain boards. >> While there has been discussion of having a separate repository for >> devicetree >> files, in practice the Linux kernel Git repository has become the place >> where >> -these are stored, with U-Boot taking copies via devicetree-rebasing repo >> -(see: dtrepo_) and adding tweaks with u-boot.dtsi files. >> +these are stored, with U-Boot taking copies via >> +`devicetree-rebasing repository`_ and adding tweaks with u-boot.dtsi files. >> >> -.. _dtspec: https://www.devicetree.org/specifications/ >> -.. _dtlist: https://www.spinics.net/lists/devicetree-compiler/ >> -.. _dtrepo: >> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git >> -.. _dtschema: https://github.com/devicetree-org/dt-schema/tree/main >> +.. _the devicetree specification: https://www.devicetree.org/specifications/ >> +.. _devicetree compiler mailing list: >> https://www.spinics.net/lists/devicetree-compiler/ >> +.. _devicetree-rebasing repository: >> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git >> +.. _DT schema project page: >> https://github.com/devicetree-org/dt-schema/tree/main > > Reviewed-by: Paul Barker > There are no comments from anyone else, but this hasn't hit the next branch yet so I'm sending a gentle ping. -- Paul Barker OpenPGP_0x27F4B3459F002257.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
[PATCH 2/3] configs: imx93-phyboard-segin: Add USB support.
Enable the `usb` command and some USB drivers. Signed-off-by: Mathieu Othacehe --- configs/imx93-phyboard-segin_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/configs/imx93-phyboard-segin_defconfig b/configs/imx93-phyboard-segin_defconfig index 24f9bd553aa..5acb987b817 100644 --- a/configs/imx93-phyboard-segin_defconfig +++ b/configs/imx93-phyboard-segin_defconfig @@ -23,6 +23,7 @@ CONFIG_SPL_STACK=0x20519dd0 CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x72 CONFIG_CMD_DEKBLOB=y +CONFIG_CMD_USB=y CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x8800 CONFIG_SYS_LOAD_ADDR=0x8040 CONFIG_SYS_MEMTEST_START=0x8000 @@ -132,6 +133,13 @@ CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_TMU=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_MANUFACTURER="FSL" +CONFIG_USB_GADGET_VENDOR_NUM=0x1fc9 +CONFIG_USB_GADGET_PRODUCT_NUM=0x0152 +CONFIG_CI_UDC=y CONFIG_ULP_WATCHDOG=y CONFIG_LZO=y CONFIG_BZIP2=y -- 2.41.0
[PATCH 0/3] imx93-phyboard-segin: Add USB support.
Hello, This series adds USB support to imx93-phyboard-segin, in the same way as it has been done for imx93_var_som here: https://lists.denx.de/pipermail/u-boot/2024-February/546301.html Thanks, Mathieu Mathieu Othacehe (3): arm: dts: imx93-phyboard-segin: Add USB support. configs: imx93-phyboard-segin: Add USB support. configs: imx93-phyboard-segin: Add fastboot support. arch/arm/dts/imx93-phyboard-segin.dts | 13 + configs/imx93-phyboard-segin_defconfig | 14 ++ 2 files changed, 27 insertions(+) -- 2.41.0
[PATCH 1/3] arm: dts: imx93-phyboard-segin: Add USB support.
Enable both usbotg1 and usbotg2 ports.
Signed-off-by: Mathieu Othacehe
---
arch/arm/dts/imx93-phyboard-segin.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/imx93-phyboard-segin.dts
b/arch/arm/dts/imx93-phyboard-segin.dts
index 85fb188b057..acf307a3192 100644
--- a/arch/arm/dts/imx93-phyboard-segin.dts
+++ b/arch/arm/dts/imx93-phyboard-segin.dts
@@ -40,6 +40,19 @@
status = "okay";
};
+/* USB */
+ {
+ disable-over-current;
+ dr_mode = "otg";
+ status = "okay";
+};
+
+ {
+ disable-over-current;
+ dr_mode = "host";
+ status = "okay";
+};
+
/* eMMC */
{
no-1-8-v;
--
2.41.0
[PATCH 3/3] configs: imx93-phyboard-segin: Add fastboot support.
Enable the `fastboot` command. Signed-off-by: Mathieu Othacehe --- configs/imx93-phyboard-segin_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/imx93-phyboard-segin_defconfig b/configs/imx93-phyboard-segin_defconfig index 5acb987b817..44ab6f7073b 100644 --- a/configs/imx93-phyboard-segin_defconfig +++ b/configs/imx93-phyboard-segin_defconfig @@ -94,6 +94,12 @@ CONFIG_SPL_CLK_IMX93=y CONFIG_CLK_IMX93=y CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y +CONFIG_USB_FUNCTION_FASTBOOT=y +CONFIG_FASTBOOT_BUF_ADDR=0x8280 +CONFIG_FASTBOOT_BUF_SIZE=0x2000 +CONFIG_FASTBOOT_FLASH=y +CONFIG_FASTBOOT_UUU_SUPPORT=y +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 CONFIG_GPIO_HOG=y CONFIG_IMX_RGPIO2P=y CONFIG_DM_I2C=y -- 2.41.0
Re: [PATCH 1/1] xilinx: zynq: add FDT_FIXUP_PARTITIONS support
On Mon, Mar 18, 2024 at 5:07 AM Michal Simek wrote:
>
>
>
> On 3/18/24 09:48, James Hilliard wrote:
> > On Mon, Mar 18, 2024 at 2:26 AM Michal Simek wrote:
> >>
> >>
> >>
> >> On 3/15/24 20:25, James Hilliard wrote:
> >>> There are situations where we may want to let U-Boot modify the FDT
> >>
> >> please use imperative mood.
> >>
> >>> nand partitions for the kernel, such as when supporting multiple
> >>> sizes of NAND chips.
> >>>
> >>> Lets also refactor xilinx common board support to have a
> >>> ft_common_board_setup which gets called by the ft_board_setup for each
> >>> specific board so that we can add non-common functionality to each
> >>> ft_board_setup like FDT_FIXUP_PARTITIONS as needed.
> >>>
> >>> This pattern is modeled after the one used by tdx-common.c.
> >>>
> >>> Signed-off-by: James Hilliard
> >>> ---
> >>>board/xilinx/common/board.c | 2 +-
> >>>board/xilinx/common/board.h | 2 ++
> >>>board/xilinx/mbv/board.c| 9 +
> >>>board/xilinx/versal-net/board.c | 7 +++
> >>>board/xilinx/versal/board.c | 7 +++
> >>>board/xilinx/zynq/board.c | 17 +
> >>>board/xilinx/zynqmp/zynqmp.c| 7 +++
> >>>board/xilinx/zynqmp_r5/board.c | 8
> >>>8 files changed, 58 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> >>> index 9641ed307b..629ba2b902 100644
> >>> --- a/board/xilinx/common/board.c
> >>> +++ b/board/xilinx/common/board.c
> >>> @@ -686,7 +686,7 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
> >>> total_size)
> >>>
> >>>#ifdef CONFIG_OF_BOARD_SETUP
> >>>#define MAX_RAND_SIZE 8
> >>> -int ft_board_setup(void *blob, struct bd_info *bd)
> >>> +int ft_common_board_setup(void *blob, struct bd_info *bd)
> >>>{
> >>>size_t n = MAX_RAND_SIZE;
> >>>struct udevice *dev;
> >>> diff --git a/board/xilinx/common/board.h b/board/xilinx/common/board.h
> >>> index 64d657673e..73f576952a 100644
> >>> --- a/board/xilinx/common/board.h
> >>> +++ b/board/xilinx/common/board.h
> >>> @@ -18,4 +18,6 @@ bool board_detection(void);
> >>>char *soc_name_decode(void);
> >>>
> >>>bool soc_detection(void);
> >>> +
> >>> +int ft_common_board_setup(void *blob, struct bd_info *bd);
> >>>#endif /* BOARD_XILINX_COMMON_BOARD_H */
> >>> diff --git a/board/xilinx/mbv/board.c b/board/xilinx/mbv/board.c
> >>> index ccf4395d6a..d8af1eaa90 100644
> >>> --- a/board/xilinx/mbv/board.c
> >>> +++ b/board/xilinx/mbv/board.c
> >>> @@ -5,7 +5,16 @@
> >>> * Michal Simek
> >>> */
> >>>
> >>> +#include "../common/board.h"
> >>> +
> >>>int board_init(void)
> >>>{
> >>>return 0;
> >>>}
> >>> +
> >>> +#ifdef CONFIG_OF_BOARD_SETUP
> >>> +int ft_board_setup(void *blob, struct bd_info *bd)
> >>> +{
> >>> + return ft_common_board_setup(blob, bd);
> >>> +}
> >>> +#endif
> >>
> >> Any reason not to put directly to board/xilinx/common/board.c?
> >> All xilinx boards are kept in sync from user perspective that's why generic
> >> pieces should be added to common location.
> >
> > I assumed the device tree node "arm,pl353-nand-r2p1" was specific to boards
> > using xilinx/zynq/board.c since it seemed only those were the only ones to
> > use
> > that node. Have any idea if that assumption is accurate?
>
> Configuration around xilinx boards are quite generic. Normally nand controller
> is by default connected on Zynq SOC. But because chips are highly configurable
> you can connect it also from Microblaze or Risc-V but
>
> I think you can simply do changes in common location and put there proper ifs
> and it should be fine.
> Also keep in mind that you should avoid using #ifdef as much as possible and
> use
> if (IS_ENABLED(...)) instead.
Is there a way to do that with the static const struct node_info nodes[] part?
>
> M
>
Re: [PATCH v2 3/4] boot: fdt: Drop lmb_alloc*() typecasts
Hi Marek,
Thank you for the patch.
On Mon, Mar 18, 2024 at 04:00:46PM +0100, Marek Vasut wrote:
> The lmb_alloc_base() returns phys_addr_t , map_sysmem() accepts
> phys_addr_t as first parameter. Declare 'addr' as phys_addr_t and
> get rid of the casts.
>
> Reported-by: Laurent Pinchart
> Signed-off-by: Marek Vasut
Reviewed-by: Laurent Pinchart
> ---
> Cc: Heinrich Schuchardt
> Cc: Kuninori Morimoto
> Cc: Laurent Pinchart
> Cc: Simon Glass
> Cc: Tom Rini
> ---
> V2: - Replace $addr with 'addr' to somehow delimit the variable name
> ---
> boot/image-fdt.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/boot/image-fdt.c b/boot/image-fdt.c
> index c2571b22244..c37442c9130 100644
> --- a/boot/image-fdt.c
> +++ b/boot/image-fdt.c
> @@ -162,6 +162,7 @@ int boot_relocate_fdt(struct lmb *lmb, char
> **of_flat_tree, ulong *of_size)
> void*of_start = NULL;
> phys_addr_t start, size, usable;
> char*fdt_high;
> + phys_addr_t addr;
> phys_addr_t low;
> phys_size_t mapsize;
> ulong of_len = 0;
> @@ -186,7 +187,6 @@ int boot_relocate_fdt(struct lmb *lmb, char
> **of_flat_tree, ulong *of_size)
> fdt_high = env_get("fdt_high");
> if (fdt_high) {
> ulong desired_addr = hextoul(fdt_high, NULL);
> - ulong addr;
>
> if (desired_addr == ~0UL) {
> /* All ones means use fdt in place */
> @@ -224,8 +224,8 @@ int boot_relocate_fdt(struct lmb *lmb, char
> **of_flat_tree, ulong *of_size)
>* At least part of this DRAM bank is usable, try
>* using it for LMB allocation.
>*/
> - of_start = map_sysmem((ulong)lmb_alloc_base(lmb,
> - of_len, 0x1000, usable), of_len);
> + addr = lmb_alloc_base(lmb, of_len, 0x1000, usable);
> + of_start = map_sysmem(addr, of_len);
> /* Allocation succeeded, use this block. */
> if (of_start != NULL)
> break;
--
Regards,
Laurent Pinchart
Re: [PATCH v2 2/4] boot: fdt: Clean up env_get_bootm_size()
Hi Marek,
Thank you for the patch.
On Mon, Mar 18, 2024 at 04:00:45PM +0100, Marek Vasut wrote:
> Clean up tmp variable use and type cast in env_get_bootm_size().
> No functional change.
The code change looks fine, but you may want to expand the commit
message to explain why this patch improves the code.
> Signed-off-by: Marek Vasut
> ---
> Cc: Heinrich Schuchardt
> Cc: Kuninori Morimoto
> Cc: Laurent Pinchart
> Cc: Simon Glass
> Cc: Tom Rini
> ---
> V2: - New patch
> ---
> boot/image-board.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/boot/image-board.c b/boot/image-board.c
> index 3263497a1d5..e3d63745299 100644
> --- a/boot/image-board.c
> +++ b/boot/image-board.c
> @@ -129,10 +129,8 @@ phys_size_t env_get_bootm_size(void)
> phys_addr_t start;
> char *s = env_get("bootm_size");
>
> - if (s) {
> - tmp = (phys_size_t)simple_strtoull(s, NULL, 16);
> - return tmp;
> - }
> + if (s)
> + return simple_strtoull(s, NULL, 16);
>
> start = gd->ram_base;
> size = gd->ram_size;
> @@ -142,7 +140,7 @@ phys_size_t env_get_bootm_size(void)
>
> s = env_get("bootm_low");
> if (s)
> - tmp = (phys_size_t)simple_strtoull(s, NULL, 16);
> + tmp = simple_strtoull(s, NULL, 16);
> else
> tmp = start;
>
Maybe you could even drop the tmp variable completely by writing this
if (s)
size -= simple_strtoull(s, NULL, 16) - start;
return size;
I've never liked variables named tmp :-)
--
Regards,
Laurent Pinchart
Re: [PATCH 2/2] ARM: dts: renesas: Switch to using upstream DT on 64bit Renesas SoCs
On Mon, Mar 18, 2024 at 10:00 AM Marek Vasut wrote: > > Enable OF_UPSTREAM to use upstream DT and add renesas/ prefix to the > DEFAULT_DEVICE_TREE and OF_LIST. And thereby directly build DTB from > dts/upstream/src/ including *-u-boot.dtsi files from arch/$(ARCH)/dts/ > directory. > > The configuration update has been done using the following script: > ``` > sed -i '/^CONFIG_DEFAULT_DEVICE_TREE/ s@="@/@' `git grep -li renesas > configs` > sed -i '/^CONFIG_OF_LIST/ s@r8a@renesas/&@g' `git grep -li renesas configs` > ``` > > There are SoCs which are not included in this patch. The 32bit SoCs > require further infrastructure work. R8A779H0 is coming during the > next upstream DT synchronization cycle as it is not included in > current upstream DTs yet. > > Signed-off-by: Marek Vasut LTGM! Thanks for doing that. I was going to do that after the April release was done, but you beat me to it. Reviewed-by: Adam Ford # Beacon boards > --- > Cc: Adam Ford > Cc: Biju Das > Cc: Lad Prabhakar > Cc: Paul Barker > Cc: Ralph Siemsen > Cc: Tom Rini > --- > arch/arm/mach-renesas/Kconfig | 1 + > configs/hihope_rzg2_defconfig | 4 ++-- > configs/r8a77970_eagle_defconfig | 2 +- > configs/r8a77970_v3msk_defconfig | 2 +- > configs/r8a77980_condor_defconfig | 2 +- > configs/r8a77980_v3hsk_defconfig | 2 +- > configs/r8a77990_ebisu_defconfig | 2 +- > configs/r8a77995_draak_defconfig | 2 +- > configs/r8a779a0_falcon_defconfig | 2 +- > configs/r8a779f0_spider_defconfig | 2 +- > configs/r8a779g0_whitehawk_defconfig | 2 +- > configs/r8a779h0_grayhawk_defconfig | 1 + > configs/rcar3_salvator-x_defconfig| 4 ++-- > configs/rcar3_ulcb_defconfig | 4 ++-- > configs/renesas_rzg2l_smarc_defconfig | 2 +- > configs/rzg2_beacon_defconfig | 4 ++-- > configs/silinux_ek874_defconfig | 2 +- > 17 files changed, 21 insertions(+), 19 deletions(-) > > diff --git a/arch/arm/mach-renesas/Kconfig b/arch/arm/mach-renesas/Kconfig > index 2ac867612bf..aeb55da609b 100644 > --- a/arch/arm/mach-renesas/Kconfig > +++ b/arch/arm/mach-renesas/Kconfig > @@ -14,6 +14,7 @@ config RCAR_64 > imply CMD_GPT > imply CMD_MMC_SWRITE if MMC > imply CMD_UUID > + imply OF_UPSTREAM > imply SUPPORT_EMMC_RPMB if MMC > > choice > diff --git a/configs/hihope_rzg2_defconfig b/configs/hihope_rzg2_defconfig > index 88c7ed1b98f..149ce0bac0d 100644 > --- a/configs/hihope_rzg2_defconfig > +++ b/configs/hihope_rzg2_defconfig > @@ -7,7 +7,7 @@ CONFIG_SYS_MALLOC_LEN=0x400 > CONFIG_ENV_SIZE=0x2 > CONFIG_ENV_OFFSET=0xFFFE > CONFIG_DM_GPIO=y > -CONFIG_DEFAULT_DEVICE_TREE="r8a774a1-hihope-rzg2m" > +CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a774a1-hihope-rzg2m" > CONFIG_RCAR_GEN3=y > CONFIG_TARGET_HIHOPE_RZG2=y > CONFIG_SYS_MONITOR_LEN=1048576 > @@ -40,7 +40,7 @@ CONFIG_CMD_EXT4_WRITE=y > CONFIG_CMD_FAT=y > CONFIG_CMD_FS_GENERIC=y > CONFIG_OF_CONTROL=y > -CONFIG_OF_LIST="r8a774a1-hihope-rzg2m r8a774b1-hihope-rzg2n > r8a774e1-hihope-rzg2h" > +CONFIG_OF_LIST="renesas/r8a774a1-hihope-rzg2m renesas/r8a774b1-hihope-rzg2n > renesas/r8a774e1-hihope-rzg2h" > CONFIG_MULTI_DTB_FIT_LZO=y > CONFIG_MULTI_DTB_FIT_USER_DEFINED_AREA=y > CONFIG_ENV_OVERWRITE=y > diff --git a/configs/r8a77970_eagle_defconfig > b/configs/r8a77970_eagle_defconfig > index a3f695e4238..fc39412f65c 100644 > --- a/configs/r8a77970_eagle_defconfig > +++ b/configs/r8a77970_eagle_defconfig > @@ -9,7 +9,7 @@ CONFIG_ENV_SIZE=0x4 > CONFIG_ENV_OFFSET=0x70 > CONFIG_ENV_SECT_SIZE=0x4 > CONFIG_DM_GPIO=y > -CONFIG_DEFAULT_DEVICE_TREE="r8a77970-eagle" > +CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a77970-eagle" > CONFIG_SPL_TEXT_BASE=0xe6318000 > CONFIG_RCAR_GEN3=y > CONFIG_TARGET_EAGLE=y > diff --git a/configs/r8a77970_v3msk_defconfig > b/configs/r8a77970_v3msk_defconfig > index 05c8d0e3868..bcd70b768ee 100644 > --- a/configs/r8a77970_v3msk_defconfig > +++ b/configs/r8a77970_v3msk_defconfig > @@ -9,7 +9,7 @@ CONFIG_ENV_SIZE=0x4 > CONFIG_ENV_OFFSET=0x70 > CONFIG_ENV_SECT_SIZE=0x4 > CONFIG_DM_GPIO=y > -CONFIG_DEFAULT_DEVICE_TREE="r8a77970-v3msk" > +CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a77970-v3msk" > CONFIG_SPL_TEXT_BASE=0xe6318000 > CONFIG_RCAR_GEN3=y > CONFIG_R8A77970=y > diff --git a/configs/r8a77980_condor_defconfig > b/configs/r8a77980_condor_defconfig > index 9e11c1b27ee..65eb563a712 100644 > --- a/configs/r8a77980_condor_defconfig > +++ b/configs/r8a77980_condor_defconfig > @@ -8,7 +8,7 @@ CONFIG_ENV_SIZE=0x4 > CONFIG_ENV_OFFSET=0x70 > CONFIG_ENV_SECT_SIZE=0x4 > CONFIG_DM_GPIO=y > -CONFIG_DEFAULT_DEVICE_TREE="r8a77980-condor" > +CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a77980-condor" > CONFIG_SPL_TEXT_BASE=0xe6318000 > CONFIG_RCAR_GEN3=y > CONFIG_TARGET_CONDOR=y > diff --git a/configs/r8a77980_v3hsk_defconfig > b/configs/r8a77980_v3hsk_defconfig > index f61574dd02d..38f9da445dd 100644 > ---
Re: imx7 issues with Secure and Non-Secure boot mode
On 07/03/2024 10:26, Emanuele Ghidoli wrote:
> Hello,
>
> I'm currently facing issues with our board, Colibri-imx7,
> regarding its behavior in different boot modes:
>
> - Secure Mode (bootm_boot_mode=sec in U-Boot):
> When running Linux in secure mode, the idle time management does not
> function
> properly. The following error message is displayed during boot:
> "CPUidle arm: CPU 0 failed to init idle CPU ops".
>
> - Non-Secure Mode (bootm_boot_mode=nonsec in U-Boot):
> In non-secure mode, the caam_jr fails to initialize correctly,
> preventing the utilization of the hardware random number generation.
> The error message shown during boot is:
> "caam_jr 30901000.jr: failed to flush job ring before reset".
>
> I have conducted tests using both mainline and 6.1 stable versions,
> with consistent results.
>
> I have also reviewed the following threads for potential solutions:
>
> - https://lore.kernel.org/u-boot/2536787.mZni4QDSI2@crypto/
> -
> https://lore.kernel.org/u-boot/CAByghJZn8d91uFr5JXSR=jXcfU4engZP_=buok7mnnjavei...@mail.gmail.com/
> - https://lore.kernel.org/all/20220608170223.1536594-1-feste...@denx.de/T/
>
> The first thread leave me thinking the only solution is to use OPTEE,
> but the last email is without any answer.
> So, I am considering the utilization of OPTEE, as it seems it might address
> the issues discussed in the threads.
> Could this configuration potentially resolve my current issues?
>
> Your advice would be greatly appreciated.
>
> Kind regards,
>
> Emanuele Ghidoli
Hello,
we are willing to use iMX7 without OP-TEE.
I saw that this patch was reverted, cause it is supposed that OPTEE is always
used on iMX7:
22191ac35344 ("drivers/crypto/fsl: assign job-rings to non-TrustZone")
What do you think if I propose a slightly different version where
I put the modifications conditionally under an U-Boot config?
Kind regards,
Emanuele
[PATCH v1 2/2] riscv: support extension probing using riscv, isa-extensions
From: Conor Dooley
A new property has been added, with an extensive rationale at [1], that
can be used in place of "riscv,isa" to indicate what extensions are
supported by a given platform that is a list of strings rather than a
single string. There are some differences between the new property,
"riscv,isa-extensions" and the incumbent "riscv,isa" - chief among them
for the sake of parsing being the list of strings, as opposed to a
string. Another advantage is strictly defined meanings for each string
in a dt-binding, rather than deriving meaning from RVI standards. This
will likely to some divergence over time, but U-Boot's current use of
extension detection is very limited - there are just four callsites of
supports_extension() in mainline U-Boot.
These checks are limited to two checks for FPU support and two checks
for "s" and "u". "s" and "u" are not supported by the new property, but
they were also not permitted in "riscv,isa". These checks are only
meaningful (or run) in M-Mode, in which case supports_extension() does
not parse the devicetree anyway.
Add support for the new property in U-Boot, prioritising it, before
falling back to the, now deprecated, "riscv,isa" property if it is not
present.
Signed-off-by: Conor Dooley
---
I moved the kernel devicetrees to use the new properties, I'd do the
same here, but I'd rather just move things to use dt-rebasing instead,
where possible.
---
arch/riscv/cpu/cpu.c | 56 +++-
1 file changed, 35 insertions(+), 21 deletions(-)
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index 99083e11df..affe70081b 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -38,9 +38,10 @@ static inline bool supports_extension(char ext)
#if CONFIG_IS_ENABLED(RISCV_MMODE)
return csr_read(CSR_MISA) & (1 << (ext - 'a'));
#elif CONFIG_CPU
+ char sext[2] = {ext};
struct udevice *dev;
const char *isa;
- int i;
+ int ret, i;
uclass_find_first_device(UCLASS_CPU, );
if (!dev) {
@@ -48,27 +49,40 @@ static inline bool supports_extension(char ext)
return false;
}
+ ret = dev_read_stringlist_search(dev, "riscv,isa-extensions", sext);
+ if (ret >= 0)
+ return true;
+
+ /*
+* Only if the property is not found (ENODATA) is the fallback to
+* riscv,isa used, otherwise the extension is not present in this
+* CPU.
+*/
+ if (ret != -ENODATA)
+ return false;
+
isa = dev_read_string(dev, "riscv,isa");
- if (isa) {
- /*
-* skip the first 4 characters (rv32|rv64)
-*/
- for (i = 4; i < sizeof(isa); i++) {
- switch (isa[i]) {
- case 's':
- case 'x':
- case 'z':
- case '_':
- case '\0':
- /*
-* Any of these characters mean the single
-* letter extensions have all been consumed.
-*/
- return false;
- default:
- if (isa[i] == ext)
- return true;
- }
+ if (!isa)
+ return false;
+
+ /*
+* Skip the first 4 characters (rv32|rv64).
+*/
+ for (i = 4; i < sizeof(isa); i++) {
+ switch (isa[i]) {
+ case 's':
+ case 'x':
+ case 'z':
+ case '_':
+ case '\0':
+ /*
+* Any of these characters mean the single
+* letter extensions have all been consumed.
+*/
+ return false;
+ default:
+ if (isa[i] == ext)
+ return true;
}
}
--
2.43.0
[PATCH v1 1/2] riscv: don't read riscv, isa in the riscv cpu's get_desc()
From: Conor Dooley
cpu_get_desc() for the RISC-V CPU currently reads "riscv,isa" to get
the description, but it is no longer a required property and cannot be
assummed to always be present, as the new "riscv,isa-extensions" and
"riscv,isa-base" properties may be present instead.
On RISC-V, cpu_get_desc() has two main uses - firstly providing an
informational name for the CPU for smbios or at boot with
DISPLAY_CPUINFO etc and secondly it forms the basis of ISA extension
detection in supports_extension() as it returns (a portion of) an ISA
string.
cpu_get_desc() returns a string, which aligned with "riscv,isa" but
the new property is a list of strings. Rather than add support for
the list of strings property, which would require creating an isa
string from "riscv,isa-extensions", modify the RISC-V CPU's
implementaion of cpu_get_desc() return the first compatible as the
cpu description instead. This may be fine for the informational cases,
but it would break extension dtection, given supports_extension()
expects cpu_get_desc() to return an ISA string.
Call dev_read_string() directly in supports_extension() to get the
contents of "riscv,isa" so that extension detection remains functional.
As a knock-on affect of this change, extension detection is no longer
broken for long ISA strings. Previously if the ISA string exceeded the
32 element array that supports_extension() passed to cpu_get_desc(),
it would return ENOSPC and no extensions would be detected.
This bug probably had no impact as U-Boot does not currently do anything
meaningful with the results of supports_extension() and most SoCs
supported by U-Boot don't have anywhere near that complex of an ISA
string. The QEMU virt machine's CPUs do however, so extension detection
doesn't work there.
Signed-off-by: Conor Dooley
---
I'm not really sure if I am happy with this patch - people could
definitely have got use out of the cpu info printout of the ISA string
before this patch - they'd have seen something like
CPU:rv64imafdc
at boot, but now they will see
CPU:sifive,u74
If it really is desired, cpu_get_desc() could be made to assemble
an isa string out of "riscv,isa-extensions", but I think it's always
gonna be a bit flawed, since that string can run to almost arbitrary
length now - one I saw for a CPU last week was 320 characters long
and these things are only going to grow.
---
arch/riscv/cpu/cpu.c| 12 +++-
drivers/cpu/riscv_cpu.c | 8
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index ecfefa1a02..99083e11df 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -39,7 +39,7 @@ static inline bool supports_extension(char ext)
return csr_read(CSR_MISA) & (1 << (ext - 'a'));
#elif CONFIG_CPU
struct udevice *dev;
- char desc[32];
+ const char *isa;
int i;
uclass_find_first_device(UCLASS_CPU, );
@@ -47,12 +47,14 @@ static inline bool supports_extension(char ext)
debug("unable to find the RISC-V cpu device\n");
return false;
}
- if (!cpu_get_desc(dev, desc, sizeof(desc))) {
+
+ isa = dev_read_string(dev, "riscv,isa");
+ if (isa) {
/*
* skip the first 4 characters (rv32|rv64)
*/
- for (i = 4; i < sizeof(desc); i++) {
- switch (desc[i]) {
+ for (i = 4; i < sizeof(isa); i++) {
+ switch (isa[i]) {
case 's':
case 'x':
case 'z':
@@ -64,7 +66,7 @@ static inline bool supports_extension(char ext)
*/
return false;
default:
- if (desc[i] == ext)
+ if (isa[i] == ext)
return true;
}
}
diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
index 5d1026b37d..9b1950efe0 100644
--- a/drivers/cpu/riscv_cpu.c
+++ b/drivers/cpu/riscv_cpu.c
@@ -21,13 +21,13 @@ DECLARE_GLOBAL_DATA_PTR;
static int riscv_cpu_get_desc(const struct udevice *dev, char *buf, int size)
{
- const char *isa;
+ const char *cpu;
- isa = dev_read_string(dev, "riscv,isa");
- if (size < (strlen(isa) + 1))
+ cpu = dev_read_string(dev, "compatible");
+ if (size < (strlen(cpu) + 1))
return -ENOSPC;
- strcpy(buf, isa);
+ strcpy(buf, cpu);
return 0;
}
--
2.43.0
[PATCH v1 0/2] Support new RISC-V ISA extension properties
From: Conor Dooley This would have just been a single patch (the second one), but as I reported a while back there's a problem with extension detection when the ISA string exceeds 32 characters: https://lore.kernel.org/u-boot/20240221-daycare-reliably-8ec86f95fe71@spud/ The first patch here fixes what I see as a bit of a misuse of cpu_get_desc() in supports_extension() as a preparatory patch for adding the new properties. Or more accurately, new property, as U-Boot barely makes use of extension detection as-is in s-mode and only one of the two new properties is even needed. Maybe it's not a misuse, but I left a comment under the --- line on that patch about the before/after for the RISC-V cpu's cpu_get_desc() and maybe my approach here would not be appreciated. Cheers, Conor. CC: Rick Chen CC: Leo CC: Tom Rini CC: Conor Dooley CC: Heinrich Schuchardt CC: u-boot@lists.denx.de (open list) Conor Dooley (2): riscv: don't read riscv,isa in the riscv cpu's get_desc() riscv: support extension probing using riscv,isa-extensions arch/riscv/cpu/cpu.c| 60 ++--- drivers/cpu/riscv_cpu.c | 8 +++--- 2 files changed, 42 insertions(+), 26 deletions(-) -- 2.43.0
[PATCH] Makefile: Add missing OF_UPSTREAM Makefile for 32bit ARM
Copy dts/upstream/src/arm64/Makefile into dts/upstream/src/arm/Makefile and create a commit. This makes 32bit ARM buildable with OF_UPSTREAM . Signed-off-by: Marek Vasut --- Cc: Adam Ford Cc: Biju Das Cc: Lad Prabhakar Cc: Paul Barker Cc: Ralph Siemsen Cc: Tom Rini --- dts/upstream/src/arm/Makefile | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 dts/upstream/src/arm/Makefile diff --git a/dts/upstream/src/arm/Makefile b/dts/upstream/src/arm/Makefile new file mode 100644 index 000..9a8f6aa3584 --- /dev/null +++ b/dts/upstream/src/arm/Makefile @@ -0,0 +1,14 @@ +# SPDX-License-Identifier: GPL-2.0+ + +include $(srctree)/scripts/Makefile.dts + +targets += $(dtb-y) + +# Add any required device tree compiler flags here +DTC_FLAGS += -a 0x8 + +PHONY += dtbs +dtbs: $(addprefix $(obj)/, $(dtb-y)) + @: + +clean-files := */*.dtb */*.dtbo -- 2.43.0
[PATCH v2 3/4] boot: fdt: Drop lmb_alloc*() typecasts
The lmb_alloc_base() returns phys_addr_t , map_sysmem() accepts
phys_addr_t as first parameter. Declare 'addr' as phys_addr_t and
get rid of the casts.
Reported-by: Laurent Pinchart
Signed-off-by: Marek Vasut
---
Cc: Heinrich Schuchardt
Cc: Kuninori Morimoto
Cc: Laurent Pinchart
Cc: Simon Glass
Cc: Tom Rini
---
V2: - Replace $addr with 'addr' to somehow delimit the variable name
---
boot/image-fdt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index c2571b22244..c37442c9130 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -162,6 +162,7 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree,
ulong *of_size)
void*of_start = NULL;
phys_addr_t start, size, usable;
char*fdt_high;
+ phys_addr_t addr;
phys_addr_t low;
phys_size_t mapsize;
ulong of_len = 0;
@@ -186,7 +187,6 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree,
ulong *of_size)
fdt_high = env_get("fdt_high");
if (fdt_high) {
ulong desired_addr = hextoul(fdt_high, NULL);
- ulong addr;
if (desired_addr == ~0UL) {
/* All ones means use fdt in place */
@@ -224,8 +224,8 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree,
ulong *of_size)
* At least part of this DRAM bank is usable, try
* using it for LMB allocation.
*/
- of_start = map_sysmem((ulong)lmb_alloc_base(lmb,
- of_len, 0x1000, usable), of_len);
+ addr = lmb_alloc_base(lmb, of_len, 0x1000, usable);
+ of_start = map_sysmem(addr, of_len);
/* Allocation succeeded, use this block. */
if (of_start != NULL)
break;
--
2.43.0
[PATCH v2 4/4] boot: fdt: Move usable variable below updated comment
Move the variable below comment which explains what the variable means. Update the comment. No functional change. Reviewed-by: Laurent Pinchart Suggested-by: Laurent Pinchart Signed-off-by: Marek Vasut --- Cc: Heinrich Schuchardt Cc: Kuninori Morimoto Cc: Laurent Pinchart Cc: Simon Glass Cc: Tom Rini --- V2: - Update the comment, s@the the@the@ and quote 'usable' - Add RB from Laurent --- boot/image-fdt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/boot/image-fdt.c b/boot/image-fdt.c index c37442c9130..2b92bdaff16 100644 --- a/boot/image-fdt.c +++ b/boot/image-fdt.c @@ -218,12 +218,12 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree, ulong *of_size) if (start + size < low) continue; - usable = min(start + size, low + mapsize); - /* * At least part of this DRAM bank is usable, try -* using it for LMB allocation. +* using the DRAM bank up to 'usable' address limit +* for LMB allocation. */ + usable = min(start + size, low + mapsize); addr = lmb_alloc_base(lmb, of_len, 0x1000, usable); of_start = map_sysmem(addr, of_len); /* Allocation succeeded, use this block. */ -- 2.43.0
[PATCH v2 2/4] boot: fdt: Clean up env_get_bootm_size()
Clean up tmp variable use and type cast in env_get_bootm_size().
No functional change.
Signed-off-by: Marek Vasut
---
Cc: Heinrich Schuchardt
Cc: Kuninori Morimoto
Cc: Laurent Pinchart
Cc: Simon Glass
Cc: Tom Rini
---
V2: - New patch
---
boot/image-board.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/boot/image-board.c b/boot/image-board.c
index 3263497a1d5..e3d63745299 100644
--- a/boot/image-board.c
+++ b/boot/image-board.c
@@ -129,10 +129,8 @@ phys_size_t env_get_bootm_size(void)
phys_addr_t start;
char *s = env_get("bootm_size");
- if (s) {
- tmp = (phys_size_t)simple_strtoull(s, NULL, 16);
- return tmp;
- }
+ if (s)
+ return simple_strtoull(s, NULL, 16);
start = gd->ram_base;
size = gd->ram_size;
@@ -142,7 +140,7 @@ phys_size_t env_get_bootm_size(void)
s = env_get("bootm_low");
if (s)
- tmp = (phys_size_t)simple_strtoull(s, NULL, 16);
+ tmp = simple_strtoull(s, NULL, 16);
else
tmp = start;
--
2.43.0
[PATCH v2 1/4] boot: fdt: Change type of env_get_bootm_low() to phys_addr_t
Change type of ulong env_get_bootm_low() to phys_addr_t env_get_bootm_low().
The PPC/LS systems already treat env_get_bootm_low() result as phys_addr_t,
while the function itself still returns ulong. This is potentially dangerous
on 64bit systems, where ulong might not be large enough to hold the content
of "bootm_low" environment variable. Fix it by using phys_addr_t, similar to
what env_get_bootm_size() does, which returns phys_size_t .
Reviewed-by: Laurent Pinchart
Reported-by: Laurent Pinchart
Signed-off-by: Marek Vasut
---
Cc: Heinrich Schuchardt
Cc: Kuninori Morimoto
Cc: Laurent Pinchart
Cc: Simon Glass
Cc: Tom Rini
---
V2: - Drop now unnecessary conversion in boot_start_lmb()
lmb_init_and_reserve_range()
- Drop tmp variable in env_get_bootm_low()
- Print initrd_high as u64/%llx
- Add RB from Laurent
---
boot/bootm.c | 4 ++--
boot/image-board.c | 14 ++
boot/image-fdt.c | 9 +
include/image.h| 2 +-
4 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index d071537d692..032f5a4a160 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -242,13 +242,13 @@ static int boot_get_kernel(const char *addr_fit, struct
bootm_headers *images,
#ifdef CONFIG_LMB
static void boot_start_lmb(struct bootm_headers *images)
{
- ulong mem_start;
+ phys_addr_t mem_start;
phys_size_t mem_size;
mem_start = env_get_bootm_low();
mem_size = env_get_bootm_size();
- lmb_init_and_reserve_range(>lmb, (phys_addr_t)mem_start,
+ lmb_init_and_reserve_range(>lmb, mem_start,
mem_size, NULL);
}
#else
diff --git a/boot/image-board.c b/boot/image-board.c
index 75f6906cd56..3263497a1d5 100644
--- a/boot/image-board.c
+++ b/boot/image-board.c
@@ -107,14 +107,12 @@ static int on_loadaddr(const char *name, const char
*value, enum env_op op,
}
U_BOOT_ENV_CALLBACK(loadaddr, on_loadaddr);
-ulong env_get_bootm_low(void)
+phys_addr_t env_get_bootm_low(void)
{
char *s = env_get("bootm_low");
- if (s) {
- ulong tmp = hextoul(s, NULL);
- return tmp;
- }
+ if (s)
+ return simple_strtoull(s, NULL, 16);
#if defined(CFG_SYS_SDRAM_BASE)
return CFG_SYS_SDRAM_BASE;
@@ -538,7 +536,7 @@ int boot_ramdisk_high(struct lmb *lmb, ulong rd_data, ulong
rd_len,
ulong *initrd_start, ulong *initrd_end)
{
char*s;
- ulong initrd_high;
+ phys_addr_t initrd_high;
int initrd_copy_to_ram = 1;
s = env_get("initrd_high");
@@ -553,8 +551,8 @@ int boot_ramdisk_high(struct lmb *lmb, ulong rd_data, ulong
rd_len,
initrd_high = env_get_bootm_mapsize() + env_get_bootm_low();
}
- debug("## initrd_high = 0x%08lx, copy_to_ram = %d\n",
- initrd_high, initrd_copy_to_ram);
+ debug("## initrd_high = 0x%llx, copy_to_ram = %d\n",
+ (u64)initrd_high, initrd_copy_to_ram);
if (rd_data) {
if (!initrd_copy_to_ram) { /* zero-copy ramdisk support */
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index 5e4aa9de0d2..c2571b22244 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -160,9 +160,10 @@ int boot_relocate_fdt(struct lmb *lmb, char
**of_flat_tree, ulong *of_size)
{
void*fdt_blob = *of_flat_tree;
void*of_start = NULL;
- u64 start, size, usable;
+ phys_addr_t start, size, usable;
char*fdt_high;
- ulong mapsize, low;
+ phys_addr_t low;
+ phys_size_t mapsize;
ulong of_len = 0;
int bank;
int err;
@@ -217,7 +218,7 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree,
ulong *of_size)
if (start + size < low)
continue;
- usable = min(start + size, (u64)(low + mapsize));
+ usable = min(start + size, low + mapsize);
/*
* At least part of this DRAM bank is usable, try
@@ -233,7 +234,7 @@ int boot_relocate_fdt(struct lmb *lmb, char **of_flat_tree,
ulong *of_size)
* Reduce the mapping size in the next bank
* by the size of attempt in current bank.
*/
- mapsize -= usable - max(start, (u64)low);
+ mapsize -= usable - max(start, low);
if (!mapsize)
break;
}
diff --git a/include/image.h b/include/image.h
index 21de70f0c9e..acffd17e0df 100644
--- a/include/image.h
+++ b/include/image.h
@@ -946,7 +946,7 @@ static inline void image_set_name(struct legacy_img_hdr
*hdr, const char *name)
int image_check_hcrc(const struct legacy_img_hdr *hdr);
int image_check_dcrc(const struct legacy_img_hdr *hdr);
[PATCH 2/2] ARM: dts: renesas: Switch to using upstream DT on 64bit Renesas SoCs
Enable OF_UPSTREAM to use upstream DT and add renesas/ prefix to the DEFAULT_DEVICE_TREE and OF_LIST. And thereby directly build DTB from dts/upstream/src/ including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory. The configuration update has been done using the following script: ``` sed -i '/^CONFIG_DEFAULT_DEVICE_TREE/ s@="@/@' `git grep -li renesas configs` sed -i '/^CONFIG_OF_LIST/ s@r8a@renesas/&@g' `git grep -li renesas configs` ``` There are SoCs which are not included in this patch. The 32bit SoCs require further infrastructure work. R8A779H0 is coming during the next upstream DT synchronization cycle as it is not included in current upstream DTs yet. Signed-off-by: Marek Vasut --- Cc: Adam Ford Cc: Biju Das Cc: Lad Prabhakar Cc: Paul Barker Cc: Ralph Siemsen Cc: Tom Rini --- arch/arm/mach-renesas/Kconfig | 1 + configs/hihope_rzg2_defconfig | 4 ++-- configs/r8a77970_eagle_defconfig | 2 +- configs/r8a77970_v3msk_defconfig | 2 +- configs/r8a77980_condor_defconfig | 2 +- configs/r8a77980_v3hsk_defconfig | 2 +- configs/r8a77990_ebisu_defconfig | 2 +- configs/r8a77995_draak_defconfig | 2 +- configs/r8a779a0_falcon_defconfig | 2 +- configs/r8a779f0_spider_defconfig | 2 +- configs/r8a779g0_whitehawk_defconfig | 2 +- configs/r8a779h0_grayhawk_defconfig | 1 + configs/rcar3_salvator-x_defconfig| 4 ++-- configs/rcar3_ulcb_defconfig | 4 ++-- configs/renesas_rzg2l_smarc_defconfig | 2 +- configs/rzg2_beacon_defconfig | 4 ++-- configs/silinux_ek874_defconfig | 2 +- 17 files changed, 21 insertions(+), 19 deletions(-) diff --git a/arch/arm/mach-renesas/Kconfig b/arch/arm/mach-renesas/Kconfig index 2ac867612bf..aeb55da609b 100644 --- a/arch/arm/mach-renesas/Kconfig +++ b/arch/arm/mach-renesas/Kconfig @@ -14,6 +14,7 @@ config RCAR_64 imply CMD_GPT imply CMD_MMC_SWRITE if MMC imply CMD_UUID + imply OF_UPSTREAM imply SUPPORT_EMMC_RPMB if MMC choice diff --git a/configs/hihope_rzg2_defconfig b/configs/hihope_rzg2_defconfig index 88c7ed1b98f..149ce0bac0d 100644 --- a/configs/hihope_rzg2_defconfig +++ b/configs/hihope_rzg2_defconfig @@ -7,7 +7,7 @@ CONFIG_SYS_MALLOC_LEN=0x400 CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0xFFFE CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="r8a774a1-hihope-rzg2m" +CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a774a1-hihope-rzg2m" CONFIG_RCAR_GEN3=y CONFIG_TARGET_HIHOPE_RZG2=y CONFIG_SYS_MONITOR_LEN=1048576 @@ -40,7 +40,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y -CONFIG_OF_LIST="r8a774a1-hihope-rzg2m r8a774b1-hihope-rzg2n r8a774e1-hihope-rzg2h" +CONFIG_OF_LIST="renesas/r8a774a1-hihope-rzg2m renesas/r8a774b1-hihope-rzg2n renesas/r8a774e1-hihope-rzg2h" CONFIG_MULTI_DTB_FIT_LZO=y CONFIG_MULTI_DTB_FIT_USER_DEFINED_AREA=y CONFIG_ENV_OVERWRITE=y diff --git a/configs/r8a77970_eagle_defconfig b/configs/r8a77970_eagle_defconfig index a3f695e4238..fc39412f65c 100644 --- a/configs/r8a77970_eagle_defconfig +++ b/configs/r8a77970_eagle_defconfig @@ -9,7 +9,7 @@ CONFIG_ENV_SIZE=0x4 CONFIG_ENV_OFFSET=0x70 CONFIG_ENV_SECT_SIZE=0x4 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="r8a77970-eagle" +CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a77970-eagle" CONFIG_SPL_TEXT_BASE=0xe6318000 CONFIG_RCAR_GEN3=y CONFIG_TARGET_EAGLE=y diff --git a/configs/r8a77970_v3msk_defconfig b/configs/r8a77970_v3msk_defconfig index 05c8d0e3868..bcd70b768ee 100644 --- a/configs/r8a77970_v3msk_defconfig +++ b/configs/r8a77970_v3msk_defconfig @@ -9,7 +9,7 @@ CONFIG_ENV_SIZE=0x4 CONFIG_ENV_OFFSET=0x70 CONFIG_ENV_SECT_SIZE=0x4 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="r8a77970-v3msk" +CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a77970-v3msk" CONFIG_SPL_TEXT_BASE=0xe6318000 CONFIG_RCAR_GEN3=y CONFIG_R8A77970=y diff --git a/configs/r8a77980_condor_defconfig b/configs/r8a77980_condor_defconfig index 9e11c1b27ee..65eb563a712 100644 --- a/configs/r8a77980_condor_defconfig +++ b/configs/r8a77980_condor_defconfig @@ -8,7 +8,7 @@ CONFIG_ENV_SIZE=0x4 CONFIG_ENV_OFFSET=0x70 CONFIG_ENV_SECT_SIZE=0x4 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="r8a77980-condor" +CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a77980-condor" CONFIG_SPL_TEXT_BASE=0xe6318000 CONFIG_RCAR_GEN3=y CONFIG_TARGET_CONDOR=y diff --git a/configs/r8a77980_v3hsk_defconfig b/configs/r8a77980_v3hsk_defconfig index f61574dd02d..38f9da445dd 100644 --- a/configs/r8a77980_v3hsk_defconfig +++ b/configs/r8a77980_v3hsk_defconfig @@ -8,7 +8,7 @@ CONFIG_ENV_SIZE=0x4 CONFIG_ENV_OFFSET=0x70 CONFIG_ENV_SECT_SIZE=0x4 CONFIG_DM_GPIO=y -CONFIG_DEFAULT_DEVICE_TREE="r8a77980-v3hsk" +CONFIG_DEFAULT_DEVICE_TREE="renesas/r8a77980-v3hsk" CONFIG_SPL_TEXT_BASE=0xe6318000 CONFIG_RCAR_GEN3=y CONFIG_R8A77980=y diff --git a/configs/r8a77990_ebisu_defconfig b/configs/r8a77990_ebisu_defconfig index fe4134226ac..f3cf2f8835d 100644 ---
[PATCH 1/2] ARM: dts: renesas: Replace R8A77950 with R8A77951
R-Car R8A77950 H3 ES1.* was only available to an internal development
group and needed a lot of quirks and workarounds. Public users only
have R-Car R8A77950 H3 ES2 and newer. Switch existing systems to use
R8A77951 device trees.
Signed-off-by: Marek Vasut
---
Cc: Adam Ford
Cc: Biju Das
Cc: Lad Prabhakar
Cc: Paul Barker
Cc: Ralph Siemsen
Cc: Tom Rini
---
arch/arm/dts/Makefile | 4 ++--
...ator-x-u-boot.dtsi => r8a77951-salvator-x-u-boot.dtsi} | 2 +-
.../dts/{r8a77950-u-boot.dtsi => r8a77951-u-boot.dtsi}| 6 --
...8a77950-ulcb-u-boot.dtsi => r8a77951-ulcb-u-boot.dtsi} | 2 +-
board/renesas/salvator-x/salvator-x.c | 2 +-
board/renesas/ulcb/ulcb.c | 2 +-
configs/rcar3_salvator-x_defconfig| 8
configs/rcar3_ulcb_defconfig | 8
8 files changed, 14 insertions(+), 20 deletions(-)
rename arch/arm/dts/{r8a77950-salvator-x-u-boot.dtsi =>
r8a77951-salvator-x-u-boot.dtsi} (96%)
rename arch/arm/dts/{r8a77950-u-boot.dtsi => r8a77951-u-boot.dtsi} (93%)
rename arch/arm/dts/{r8a77950-ulcb-u-boot.dtsi => r8a77951-ulcb-u-boot.dtsi}
(96%)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b6da94ab04b..a26cca88973 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1157,8 +1157,8 @@ dtb-$(CONFIG_RCAR_GEN3) += \
r8a774b1-hihope-rzg2n.dtb \
r8a774c0-ek874.dtb \
r8a774e1-hihope-rzg2h.dtb \
- r8a77950-ulcb.dtb \
- r8a77950-salvator-x.dtb \
+ r8a77951-ulcb.dtb \
+ r8a77951-salvator-x.dtb \
r8a77960-ulcb.dtb \
r8a77960-salvator-x.dtb \
r8a77965-ulcb.dtb \
diff --git a/arch/arm/dts/r8a77950-salvator-x-u-boot.dtsi
b/arch/arm/dts/r8a77951-salvator-x-u-boot.dtsi
similarity index 96%
rename from arch/arm/dts/r8a77950-salvator-x-u-boot.dtsi
rename to arch/arm/dts/r8a77951-salvator-x-u-boot.dtsi
index 23f12543746..744f4d9 100644
--- a/arch/arm/dts/r8a77950-salvator-x-u-boot.dtsi
+++ b/arch/arm/dts/r8a77951-salvator-x-u-boot.dtsi
@@ -5,7 +5,7 @@
* Copyright (C) 2018 Marek Vasut
*/
-#include "r8a77950-u-boot.dtsi"
+#include "r8a77951-u-boot.dtsi"
/ {
sysinfo {
diff --git a/arch/arm/dts/r8a77950-u-boot.dtsi
b/arch/arm/dts/r8a77951-u-boot.dtsi
similarity index 93%
rename from arch/arm/dts/r8a77950-u-boot.dtsi
rename to arch/arm/dts/r8a77951-u-boot.dtsi
index 92907ea09bf..4cbec591479 100644
--- a/arch/arm/dts/r8a77950-u-boot.dtsi
+++ b/arch/arm/dts/r8a77951-u-boot.dtsi
@@ -30,7 +30,6 @@
/delete-node/
/delete-node/
/delete-node/
-/delete-node/
/delete-node/
/delete-node/
/delete-node/
@@ -44,16 +43,13 @@
/delete-node/
/delete-node/
/delete-node/
-/delete-node/
/delete-node/
/delete-node/
/delete-node/
/delete-node/
/delete-node/
-/delete-node/
/delete-node/
/delete-node/
-/delete-node/
/delete-node/
/delete-node/
/delete-node/
@@ -72,10 +68,8 @@
/delete-node/
/delete-node/
/delete-node/
-/delete-node/
/delete-node/
/delete-node/
-/delete-node/
/ {
/delete-node/ cvbs-in;
diff --git a/arch/arm/dts/r8a77950-ulcb-u-boot.dtsi
b/arch/arm/dts/r8a77951-ulcb-u-boot.dtsi
similarity index 96%
rename from arch/arm/dts/r8a77950-ulcb-u-boot.dtsi
rename to arch/arm/dts/r8a77951-ulcb-u-boot.dtsi
index c65c2e6406d..305c4861520 100644
--- a/arch/arm/dts/r8a77950-ulcb-u-boot.dtsi
+++ b/arch/arm/dts/r8a77951-ulcb-u-boot.dtsi
@@ -5,7 +5,7 @@
* Copyright (C) 2018 Marek Vasut
*/
-#include "r8a77950-u-boot.dtsi"
+#include "r8a77951-u-boot.dtsi"
/ {
cpld {
diff --git a/board/renesas/salvator-x/salvator-x.c
b/board/renesas/salvator-x/salvator-x.c
index afb3b63582b..2c8860bcee4 100644
--- a/board/renesas/salvator-x/salvator-x.c
+++ b/board/renesas/salvator-x/salvator-x.c
@@ -79,7 +79,7 @@ int board_fit_config_name_match(const char *name)
u32 cpu_type = renesas_get_cpu_type();
if ((cpu_type == RENESAS_CPU_TYPE_R8A7795) &&
- !strcmp(name, "r8a77950-salvator-x"))
+ !strcmp(name, "r8a77951-salvator-x"))
return 0;
if ((cpu_type == RENESAS_CPU_TYPE_R8A7796) &&
diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c
index cda6976602d..64f01b123cb 100644
--- a/board/renesas/ulcb/ulcb.c
+++ b/board/renesas/ulcb/ulcb.c
@@ -70,7 +70,7 @@ int board_fit_config_name_match(const char *name)
u32 cpu_type = renesas_get_cpu_type();
if ((cpu_type == RENESAS_CPU_TYPE_R8A7795) &&
- !strcmp(name, "r8a77950-ulcb"))
+ !strcmp(name, "r8a77951-ulcb"))
return 0;
if ((cpu_type == RENESAS_CPU_TYPE_R8A7796) &&
diff --git a/configs/rcar3_salvator-x_defconfig
b/configs/rcar3_salvator-x_defconfig
index c76cbec76d4..22d649296e1 100644
--- a/configs/rcar3_salvator-x_defconfig
+++ b/configs/rcar3_salvator-x_defconfig
@@ -6,7 +6,7 @@ CONFIG_SYS_MALLOC_LEN=0x400
[PATCH v3] net: phy: Factor out PHY GPIO reset code
Pull the PHY GPIO reset code into separate function, since
this is and will be reused multiple times. Set up default
reset assert and deassert timing to generous 20ms and 1ms
for maximum compatibility in case those DT properties are
missing.
Reviewed-by: Ramon Fried
Signed-off-by: Marek Vasut
---
Cc: Joe Hershberger
Cc: Marek Vasut
Cc: Michal Simek
Cc: Nishanth Menon
Cc: Ramon Fried
---
V2: - Fix am335x_evm build with OF_REAL disabled
- Collect RB from Ramon
V3: - Drop stale conditional
---
drivers/net/phy/ethernet_id.c | 37 ---
drivers/net/phy/phy.c | 55 +++
include/phy.h | 9 ++
3 files changed, 69 insertions(+), 32 deletions(-)
diff --git a/drivers/net/phy/ethernet_id.c b/drivers/net/phy/ethernet_id.c
index 6cb1fd4453e..4dfdee60dcc 100644
--- a/drivers/net/phy/ethernet_id.c
+++ b/drivers/net/phy/ethernet_id.c
@@ -18,12 +18,11 @@ struct phy_device *phy_connect_phy_id(struct mii_dev *bus,
struct udevice *dev,
{
struct phy_device *phydev;
struct ofnode_phandle_args phandle_args;
- struct gpio_desc gpio;
const char *node_name;
struct udevice *pdev;
- ofnode node;
- u32 id, assert, deassert;
u16 vendor, device;
+ ofnode node;
+ u32 id;
int ret;
if (dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
@@ -41,35 +40,9 @@ struct phy_device *phy_connect_phy_id(struct mii_dev *bus,
struct udevice *dev,
return NULL;
}
- if (!IS_ENABLED(CONFIG_DM_ETH_PHY)) {
- ret = gpio_request_by_name_nodev(node, "reset-gpios", 0, ,
-GPIOD_IS_OUT |
GPIOD_ACTIVE_LOW);
- if (!ret) {
- assert = ofnode_read_u32_default(node,
-"reset-assert-us", 0);
- deassert = ofnode_read_u32_default(node,
- "reset-deassert-us",
- 0);
- ret = dm_gpio_set_value(, 1);
- if (ret) {
- dev_err(dev,
- "Failed assert gpio, err: %d\n", ret);
- return NULL;
- }
-
- udelay(assert);
-
- ret = dm_gpio_set_value(, 0);
- if (ret) {
- dev_err(dev,
- "Failed deassert gpio, err: %d\n",
- ret);
- return NULL;
- }
-
- udelay(deassert);
- }
- }
+ ret = phy_gpio_reset(dev);
+ if (ret)
+ return NULL;
if (phyaddr == -1)
phyaddr = ofnode_read_u32_default(phandle_args.node, "reg", -1);
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 63b3e46f101..a7a6fa66268 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -768,6 +770,59 @@ int miiphy_reset(const char *devname, unsigned char addr)
return phy_reset(phydev);
}
+#if CONFIG_IS_ENABLED(DM_GPIO) && CONFIG_IS_ENABLED(OF_REAL) && \
+!IS_ENABLED(CONFIG_DM_ETH_PHY)
+int phy_gpio_reset(struct udevice *dev)
+{
+ struct ofnode_phandle_args phandle_args;
+ struct gpio_desc gpio;
+ u32 assert, deassert;
+ ofnode node;
+ int ret;
+
+ ret = dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
+_args);
+ /* No PHY handle is OK */
+ if (ret)
+ return 0;
+
+ node = phandle_args.node;
+ if (!ofnode_valid(node))
+ return -EINVAL;
+
+ ret = gpio_request_by_name_nodev(node, "reset-gpios", 0, ,
+GPIOD_IS_OUT | GPIOD_ACTIVE_LOW);
+ /* No PHY reset GPIO is OK */
+ if (ret)
+ return 0;
+
+ assert = ofnode_read_u32_default(node, "reset-assert-us", 2);
+ deassert = ofnode_read_u32_default(node, "reset-deassert-us", 1000);
+ ret = dm_gpio_set_value(, 1);
+ if (ret) {
+ dev_err(dev, "Failed assert gpio, err: %d\n", ret);
+ return ret;
+ }
+
+ udelay(assert);
+
+ ret = dm_gpio_set_value(, 0);
+ if (ret) {
+ dev_err(dev, "Failed deassert gpio, err: %d\n", ret);
+ return ret;
+ }
+
+ udelay(deassert);
+
+ return 0;
+}
+#else
+int phy_gpio_reset(struct udevice *dev)
+{
+ return 0;
+}
+#endif
+
struct phy_device *phy_find_by_mask(struct mii_dev *bus, uint phy_mask)
{
/* Reset the bus */
Re: [PATCH v2 4/6] usb: Add environment based device blocklist
On 3/18/24 8:33 AM, Janne Grunau wrote:
+static int usb_blocklist_parse_error(const char *blocklist, size_t pos)
+{
+ printf("usb_blocklist parse error at char %zu in \"%s\"\n", pos,
+ blocklist);
+ return 0;
This could be static void without return 0 at the end.
the return is there to break out of the while loop on parsing errors in a
single statement. This probably won't be necessary after using strsep and
sscanf in the parsing function but see below.
Ahh, now I see it. But then, shouldn't this return -ENODEV here already ?
It returns 0 so that parsing errors in the blocklist do not result
in blocking every USB device. That looked to me like the
less bad error behavior to me.
In unix , 0 is considered success and non-zero failure .
How about this:
- Return -EINVAL here (parsing failed)
- Instead of 'return 1' in usb_device_is_blocked() return -ENODEV
- In usb_select_config(), check
if usb_device_is_blocked returned 0, no device blocked OK
if usb_device_is_blocked returned -ENODEV, device blocked,
return -ENODEV
if usb_device_is_blocked returned any other error, parsing error
return that error
What do you think ?
+}
+
+static int usb_device_is_blocked(u16 id_vendor, u16 id_product)
+{
+ ulong vid, pid;
+ char *end;
+ const char *block_str = env_get("usb_blocklist");
+ const char *cur = block_str;
+
+ /* parse "usb_blocklist" strictly */
+ while (cur && cur[0] != '\0') {
Have a look at strsep() , namely strsep(block_str, ","); This will split
the string up for you at "," delimiters.
Example is in drivers/dfu/dfu.c dfu_config_interfaces() .
strsep() is probably a good idea even if it alone won't make the code that much
simpler for strict parsing.
And then, on each token, you can try and run sscanf(token, "%04x:%04x",
vid, pid);, that will parse the token format for you. See e.g.
test/lib/sscanf.c for further examples.
That should simplify the parsing a lot.
It would but sscanf() is optional and is only selected by CONFIG_XEN so I
assumed there would be concerns over binary size increase if USB_HOST would
require sscanf.
Good point, lets postpone sscanf() . Also, looking at it, sscanf would
work for numbers, but not for the special characters. So ... do you want
to try tweaking this further with strsep() or shall we go with this
implementation ?
I started converting it to strsep. It makes the intent clearer but it doesn't
simplify the implementation much. strsep() has the disadvantage that
it can't work in place and needs to copy the string. If we go with strsep
I would look into parsing the list once at USB init time and use a list of
numeric vendor, product ID pairs at device probe time.
If have a slight preference for the current implementation (with ignore
or deny instead of blocklist) as long as the list remains short.
OK, we can always improve this later, I would also like this
functionality in soon-ish.
Re: [PATCH v2] cmd: nand: Add support to print the manufacturer, model and size
On 3/18/24 09:42, Mihai Sain wrote:
Add support to nand info for printing the manufacturer,model and size.
The manufacturer and model are printed only for ONFI flashes.
U-Boot> nand info
Device 0: nand0, sector size 256 KiB
Manufacturer MACRONIX
Model MX30LF4G28AD
Device size512 MiB
Page size 4096 b
OOB size 256 b
Erase size 262144 b
ecc strength 8 bits
ecc step size 512 b
subpagesize 4096 b
options 0x4200
bbt options 0x00028000
Signed-off-by: Mihai Sain
Changes in v2:
--
* use #ifdef directive for ONFI flashes.
* use unsigned int for chipsize.
---
cmd/nand.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/cmd/nand.c b/cmd/nand.c
index fe834c4ac5..5773246d64 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -418,6 +418,11 @@ static void nand_print_and_set_info(int idx)
printf("%dx ", chip->numchips);
printf("%s, sector size %u KiB\n",
mtd->name, mtd->erasesize >> 10);
+#ifdef CONFIG_SYS_NAND_ONFI_DETECTION
+ printf(" Manufacturer %s \n", chip->onfi_params.manufacturer);
+ printf(" Model %s \n", chip->onfi_params.model);
+#endif
+ printf(" Device size %8u MiB\n", (unsigned int)(chip->chipsize >>
20));
printf(" Page size %8d b\n", mtd->writesize);
printf(" OOB size %8d b\n", mtd->oobsize);
printf(" Erase size%8d b\n", mtd->erasesize);
Can you refactor the logic out of the end of nand_detect as a separate
function and use that instead? That will cover more cases (e.g. JEDEC).
--Sean
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
On Mon, Mar 18, 2024 at 10:31 AM Fabio Estevam wrote: > I tried dumping the page table entries, but could not notice anything > that looked suspicious. This looks suspicious: With 41e2787f5ec4 reverted: Checking if pte fits for virt=1c00 size=6400 blocksize=4000 Checking if pte fits for virt=1c00 size=6400 blocksize=20 Checking if pte fits for virt=1c20 size=63e0 blocksize=4000 Checking if pte fits for virt=1c20 size=63e0 blocksize=20 Checking if pte fits for virt=1c40 size=63c0 blocksize=4000 In U-Boot master: Checking if pte fits for virt=1c00 size=6400 blocksize=4000 Checking if pte fits for virt=1c00 size=2400 blocksize=20 Checking if pte fits for virt=1c20 size=23e0 blocksize=20 Checking if pte fits for virt=1c40 size=23c0 blocksize=20 The second entry has size=2400 instead of size=6400.
[PATCH v2] cmd: nand: Add support to print the manufacturer, model and size
Add support to nand info for printing the manufacturer,model and size.
The manufacturer and model are printed only for ONFI flashes.
U-Boot> nand info
Device 0: nand0, sector size 256 KiB
Manufacturer MACRONIX
Model MX30LF4G28AD
Device size512 MiB
Page size 4096 b
OOB size 256 b
Erase size 262144 b
ecc strength 8 bits
ecc step size 512 b
subpagesize 4096 b
options 0x4200
bbt options 0x00028000
Signed-off-by: Mihai Sain
Changes in v2:
--
* use #ifdef directive for ONFI flashes.
* use unsigned int for chipsize.
---
cmd/nand.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/cmd/nand.c b/cmd/nand.c
index fe834c4ac5..5773246d64 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -418,6 +418,11 @@ static void nand_print_and_set_info(int idx)
printf("%dx ", chip->numchips);
printf("%s, sector size %u KiB\n",
mtd->name, mtd->erasesize >> 10);
+#ifdef CONFIG_SYS_NAND_ONFI_DETECTION
+ printf(" Manufacturer %s \n", chip->onfi_params.manufacturer);
+ printf(" Model %s \n", chip->onfi_params.model);
+#endif
+ printf(" Device size %8u MiB\n", (unsigned int)(chip->chipsize >>
20));
printf(" Page size %8d b\n", mtd->writesize);
printf(" OOB size %8d b\n", mtd->oobsize);
printf(" Erase size%8d b\n", mtd->erasesize);
--
2.44.0
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
Hi Pierre, On Fri, Mar 15, 2024 at 12:13 PM Pierre-Clément Tosi wrote: > I had a quick look through your logs and notice that U-Boot master attempts to > map addresses in the high VA range e.g. > > Checking if pte fits for virt=e400 [...] > > while the logs that boot successfully only use the low VA range e.g. > > Checking if pte fits for virt=80193000 [...] > > Unless that has recently changed (since I last worked with U-Boot), U-Boot on > AArch64 only supports identity mappings and therefore was only taught how to > program TTBR0_ELx (i.e. is only able to map low virtual addresses). This means > that the code - with or without 41e2787f5ec4 - would be unable to map > addresses > such as 0xe400. Yes, I found it strange too. I may have done something wrong the last time I instrumented the code. I tried it again and no longer see these unexpected high virtual addresses. Please find the new logs here: https://pastebin.com/raw/qF3GbJry > Now, given that 41e2787f5ec4 only affects implementation details of add_map(), > I am surprised that reverting that commit changes the arguments received by > the > function such as virt. As a reminder, add_map() is exclusively used on > mem_map: > > for (i = 0; mem_map[i].size || mem_map[i].attrs; i++) > add_map(_map[i]); > > > > > That's the only issue preventing colibri-imx8x from booting mainline U-Boot. > > If I read the U-Boot configs right i.e. > > - configs/colibri-imx8x_defconfig: CONFIG_ARCH_IMX8=y > - arch/arm/mach-imx/imx8/Makefile: obj-y += cpu.o > - arch/arm/mach-imx/imx8/cpu.c: struct mm_region *mem_map = imx8_mem_map; Correct, these are the relevant files for the i.MXQ8XP. > There is a possibility that your mem_map is getting modified by MACH-specific > code. In particular, enable_caches() seems to dynamically get the MMU mappings > from some RPC mechanism (see get_owned_memreg() and sc_rm_get_memreg_info()). > > Could it be that whatever services those requests might be returning > unexpected > values? Instrumenting arch/arm/mach-imx/imx8/cpu.c and dumping mem_map (and > the RPC messages) with/without the patch would help clear this up. I tried dumping the page table entries, but could not notice anything that looked suspicious. Please let me know if you have any suggestions. Thanks
Re: [PATCH] cmd: nand: Add support to print the manufacturer, model and size
Hello Mihai,
adding the raw nand maintainers to Cc, maybe cmd/nand.c should be
added to MAINTAINERS file section raw nand? See my comments below.
Am Mon, Mar 18, 2024 at 02:26:47PM +0200 schrieb Mihai Sain:
> Add support to nand info for printing the manufacturer,model and size.
>
> U-Boot> nand info
>
> Device 0: nand0, sector size 256 KiB
> Manufacturer MACRONIX
> Model MX30LF4G28AD
> Device size512 MiB
> Page size 4096 b
> OOB size 256 b
> Erase size 262144 b
> ecc strength 8 bits
> ecc step size 512 b
> subpagesize 4096 b
> options 0x4200
> bbt options 0x00028000
Tested here:
Device 0: nand0, sector size 128 KiB
Manufacturer SPANSION
Model S34ML02G1
Device size256 MiB
Page size 2048 b
OOB size64 b
Erase size 131072 b
ecc strength 8 bits
ecc step size 512 b
subpagesize 2048 b
options 0x40004200
bbt options 0x00028000
> Signed-off-by: Mihai Sain
> ---
> cmd/nand.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/cmd/nand.c b/cmd/nand.c
> index fe834c4ac5..f5cfaab37c 100644
> --- a/cmd/nand.c
> +++ b/cmd/nand.c
> @@ -418,6 +418,9 @@ static void nand_print_and_set_info(int idx)
> printf("%dx ", chip->numchips);
> printf("%s, sector size %u KiB\n",
> mtd->name, mtd->erasesize >> 10);
> + printf(" Manufacturer %s \n", chip->onfi_params.manufacturer);
> + printf(" Model %s \n", chip->onfi_params.model);
This probably only works for ONFI flash and might fail otherwise. See
this code in nand_base.c:
https://elixir.bootlin.com/u-boot/v2024.01/source/drivers/mtd/nand/raw/nand_base.c#L4455
The manufacturer could always be printed from struct nand_chip
->manufacturer.desc.name here.
Don't know if the third fallback for model ("type->name") is somehow
accessible after nand_detect() but I would at least test on
chip->onfi_version or chip->jedec_version here, and maybe just drop
the model line if none is set.
> + printf(" Device size %8d MiB\n", (int)(chip->chipsize >> 20));
Fine.
Greets
Alex
> printf(" Page size %8d b\n", mtd->writesize);
> printf(" OOB size %8d b\n", mtd->oobsize);
> printf(" Erase size%8d b\n", mtd->erasesize);
> --
> 2.44.0
>
RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
Hi Alexander, > Maybe we should add an automatic fallback for timing mode in > nand-controller.c > As of now the driver is forcing tRC_min to 30ns (mode 3), which is not > reliable for sama7 nfc controller ☹ > > https://github.com/u-boot/u-boot/blob/master/drivers/mtd/nand/raw/nand_timings.c#L167 > The nand torture command helped me to manually force tRC_min to 35ns > (mode 2). This sounds like the same problem encountered in https://github.com/linux4sam/at91bootstrap/issues/174 and the fix proposed there works in Linux and U-Boot as well. I consider the original commit message of the patch attached to that ticket not easy to understand however, so I wrote what I think is the problem. Could you please test the patch attached to this mail which does the same thing and should apply to U-Boot cleanly? I tested that on sam9x60 and sama5, but have no other boards/socs to test with. If that works on sama7, I will propose it on U-Boot, too. (I hope it is okay to attach it as an attachment for now, it's not ready for submission anyways.) I tested your patch on sama7g54-curiosity board. I also reverted to (conf->timings.sdr.tRC_min < 3), to force mode 3 Indeed the decode command reports tighter timings. I tested using nand torture on 16MiB and 32MiB sizes. U-Boot> nand info Device 0: nand0, sector size 256 KiB Manufacturer MACRONIX Model MX30LF4G28AD Device size512 MiB Page size 4096 b OOB size 256 b Erase size 262144 b ecc strength 8 bits ecc step size 512 b subpagesize 4096 b options 0x40004200 bbt options 0x00028000 U-Boot> hsmc decode mck clock rate: 2 HSMC_SETUP3:0x0002 HSMC_PULSE3:0x07040703 HSMC_CYCLE3:0x00070007 HSMC_TIMINGS3: 0x880402f2 HSMC_MODE3: 0x001f0003 NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns) NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 ns) NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns) NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 (35 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE signal Read operation controlled by NRD signal U-Boot> nand torture 0x80 0x100 NAND torture: device 0 offset 0x80 size 0x100 (block size 0x4) Passed: 64, failed: 0 U-Boot> nand torture 0x80 0x200 NAND torture: device 0 offset 0x80 size 0x200 (block size 0x4) Passed: 128, failed: 0 Tested-by: Mihai Sain Best regards, Mihai Sain
Re: [PATCH 1/2] usb: udc: dwc3: Fold board dm_usb_gadget_handle_interrupts() into DWC3 gadget
On 17/03/2024 04:42, Marek Vasut wrote:
> The dm_usb_gadget_handle_interrupts() has no place in board code. Move
> this into DWC3 driver. The OMAP implementation is special, add new weak
> dwc3_uboot_interrupt_status() function to decide whether DWC3 interrupt
> handling should be called, and override it in OMAP DWC3 code, to repair
> the special OMAP interrupt handling code until OMAP gets switched over
> to DM UDC proper.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Caleb Connolly
> ---
> Cc: Angus Ainslie
> Cc: Caleb Connolly
> Cc: Eugen Hristev
> Cc: Igor Prusov
> Cc: Mattijs Korpershoek
> Cc: Nishanth Menon
> Cc: Patrice Chotard
> Cc: Simon Glass
> Cc: Stefan Bosch
> Cc: Svyatoslav Ryhel
> Cc: Tom Rini
> Cc: ker...@puri.sm
> ---
> board/purism/librem5/spl.c| 6 --
> board/samsung/common/exynos5-dt.c | 6 --
> board/st/stih410-b2260/board.c| 6 --
> board/ti/am43xx/board.c | 11 ---
> drivers/usb/dwc3/core.c | 25 +
> drivers/usb/dwc3/dwc3-omap.c | 4 ++--
> include/dwc3-omap-uboot.h | 1 -
> include/dwc3-uboot.h | 1 +
> 8 files changed, 24 insertions(+), 36 deletions(-)
>
> diff --git a/board/purism/librem5/spl.c b/board/purism/librem5/spl.c
> index 581f0929662..9aadc553302 100644
> --- a/board/purism/librem5/spl.c
> +++ b/board/purism/librem5/spl.c
> @@ -418,12 +418,6 @@ out:
> return rv;
> }
>
> -int dm_usb_gadget_handle_interrupts(struct udevice *dev)
> -{
> - dwc3_uboot_handle_interrupt(dev);
> - return 0;
> -}
> -
> static void dwc3_nxp_usb_phy_init(struct dwc3_device *dwc3)
> {
> u32 RegData;
> diff --git a/board/samsung/common/exynos5-dt.c
> b/board/samsung/common/exynos5-dt.c
> index 95cf6d2acc2..b3e87c93751 100644
> --- a/board/samsung/common/exynos5-dt.c
> +++ b/board/samsung/common/exynos5-dt.c
> @@ -122,12 +122,6 @@ static struct dwc3_device dwc3_device_data = {
> .index = 0,
> };
>
> -int dm_usb_gadget_handle_interrupts(struct udevice *dev)
> -{
> - dwc3_uboot_handle_interrupt(dev);
> - return 0;
> -}
> -
> int board_usb_init(int index, enum usb_init_type init)
> {
> struct exynos_usb3_phy *phy = (struct exynos_usb3_phy *)
> diff --git a/board/st/stih410-b2260/board.c b/board/st/stih410-b2260/board.c
> index e21cbc270e9..82817571ae3 100644
> --- a/board/st/stih410-b2260/board.c
> +++ b/board/st/stih410-b2260/board.c
> @@ -50,12 +50,6 @@ static struct dwc3_device dwc3_device_data = {
> .index = 0,
> };
>
> -int dm_usb_gadget_handle_interrupts(struct udevice *dev)
> -{
> - dwc3_uboot_handle_interrupt(dev);
> - return 0;
> -}
> -
> int board_usb_init(int index, enum usb_init_type init)
> {
> int node;
> diff --git a/board/ti/am43xx/board.c b/board/ti/am43xx/board.c
> index ea0d0b92088..a4679a2e294 100644
> --- a/board/ti/am43xx/board.c
> +++ b/board/ti/am43xx/board.c
> @@ -759,17 +759,6 @@ static struct ti_usb_phy_device usb_phy2_device = {
> .usb2_phy_power = (void *)USB2_PHY2_POWER,
> .index = 1,
> };
> -
> -int dm_usb_gadget_handle_interrupts(struct udevice *dev)
> -{
> - u32 status;
> -
> - status = dwc3_omap_uboot_interrupt_status(dev);
> - if (status)
> - dwc3_uboot_handle_interrupt(dev);
> -
> - return 0;
> -}
> #endif /* CONFIG_USB_DWC3 */
>
> #if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_OMAP)
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 4b4fcd8a22e..09737be9a9c 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -983,6 +983,11 @@ void dwc3_uboot_exit(int index)
> }
> }
>
> +MODULE_ALIAS("platform:dwc3");
> +MODULE_AUTHOR("Felipe Balbi ");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("DesignWare USB3 DRD Controller Driver");
> +
> /**
> * dwc3_uboot_handle_interrupt - handle dwc3 core interrupt
> * @dev: device of this controller
> @@ -1004,10 +1009,22 @@ void dwc3_uboot_handle_interrupt(struct udevice *dev)
> }
> }
>
> -MODULE_ALIAS("platform:dwc3");
> -MODULE_AUTHOR("Felipe Balbi ");
> -MODULE_LICENSE("GPL v2");
> -MODULE_DESCRIPTION("DesignWare USB3 DRD Controller Driver");
> +#if !CONFIG_IS_ENABLED(DM_USB_GADGET)
> +__weak int dwc3_uboot_interrupt_status(struct udevice *dev)
> +{
> + return 1;
> +}
> +
> +int dm_usb_gadget_handle_interrupts(struct udevice *dev)
> +{
> + if (!dwc3_uboot_interrupt_status(dev))
> + return 0;
> +
> + dwc3_uboot_handle_interrupt(dev);
> +
> + return 0;
> +}
> +#endif
>
> #if CONFIG_IS_ENABLED(PHY) && CONFIG_IS_ENABLED(DM_USB)
> int dwc3_setup_phy(struct udevice *dev, struct phy_bulk *phys)
> diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
> index 4fadb4a3e20..53c4d4826b4 100644
> --- a/drivers/usb/dwc3/dwc3-omap.c
> +++ b/drivers/usb/dwc3/dwc3-omap.c
> @@ -428,7 +428,7 @@ void dwc3_omap_uboot_exit(int index)
> }
>
> /**
> - *
Re: Pull Request: SoCFPGA changes for efi-2024-04-rc5
On Mon, Mar 18, 2024 at 07:17:24AM +, Chee, Tien Fong wrote: > Dear Tom, > > Please pull the SoCFPGA changes for master from u-boot-socfpga, thanks. > > Best regards, > Tien Fong > > The following changes since commit 86fd291a7990af84e96808f48eff2219dd4ef496: > > Merge tag 'efi-2024-04-rc5' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2024-03-13 20:39:46 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-socfpga.git > 386fca68960994ece0d9da8a69a14495b5f1aedf > > for you to fetch changes up to 386fca68960994ece0d9da8a69a14495b5f1aedf: > > arch: arm: Agilex5 enablement (2024-03-18 14:45:47 +0800) > > > Jit Loon Lim (1): > arch: arm: Agilex5 enablement > > Wan Yee Lau (1): > drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGA Please rebase this on top of the current next branch, and use a tag rather than commit hash for me to pull. A short summary of the changes, either in the tag or pull request email itself would be appreciated as well. Thanks. -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] Please pull u-boot-imx-next-20240317
On Sun, Mar 17, 2024 at 08:50:15PM -0300, Fabio Estevam wrote: > Hi Tom, > > Please pull this material for next from u-boot-imx, thank > > The following changes since commit 099c94b7613bb10d97936447f5136f3a36694325: > > Merge tag 'u-boot-rockchip-20240315' of > https://source.denx.de/u-boot/custodians/u-boot-rockchip into next > (2024-03-15 09:15:31 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-next-20240317 > > for you to fetch changes up to 86b79cf131b64eadae023a127921893d30503093: > > imx8m*_venice: move venice to OF_UPSTREAM (2024-03-17 18:39:54 -0300) > > u-boot-imx-next-20240317 Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] Please pull u-boot-imx-master-20240317
On Sun, Mar 17, 2024 at 08:34:20PM -0300, Fabio Estevam wrote: > Hi Tom, > > Please pull these fixes from u-boot-imx, thanks. > > The following changes since commit 86fd291a7990af84e96808f48eff2219dd4ef496: > > Merge tag 'efi-2024-04-rc5' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2024-03-13 20:39:46 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-master-20240317 > > for you to fetch changes up to e648c4a3455a4d1880efe121602ed90a0bc9b53f: > > arm: imx: imx8m: soc: Fix NPU/VPU fdt disable fixup (2024-03-17 18:00:04 > -0300) > > u-boot-imx-master-20240317 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] cmd: nand: Add support to print the manufacturer, model and size
Add support to nand info for printing the manufacturer,model and size.
U-Boot> nand info
Device 0: nand0, sector size 256 KiB
Manufacturer MACRONIX
Model MX30LF4G28AD
Device size512 MiB
Page size 4096 b
OOB size 256 b
Erase size 262144 b
ecc strength 8 bits
ecc step size 512 b
subpagesize 4096 b
options 0x4200
bbt options 0x00028000
Signed-off-by: Mihai Sain
---
cmd/nand.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/cmd/nand.c b/cmd/nand.c
index fe834c4ac5..f5cfaab37c 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -418,6 +418,9 @@ static void nand_print_and_set_info(int idx)
printf("%dx ", chip->numchips);
printf("%s, sector size %u KiB\n",
mtd->name, mtd->erasesize >> 10);
+ printf(" Manufacturer %s \n", chip->onfi_params.manufacturer);
+ printf(" Model %s \n", chip->onfi_params.model);
+ printf(" Device size %8d MiB\n", (int)(chip->chipsize >> 20));
printf(" Page size %8d b\n", mtd->writesize);
printf(" OOB size %8d b\n", mtd->oobsize);
printf(" Erase size%8d b\n", mtd->erasesize);
--
2.44.0
Re: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
Hello Mihai,
Am Mon, Mar 18, 2024 at 11:28:39AM + schrieb mihai.s...@microchip.com:
> Hi Alexander,
>
> I'm sorry for quoting because the email is sent from Outlook ☹
>
> > > U-Boot> nand info
> > >
> > > Device 0: nand0, sector size 256 KiB
> > > Manufacturer MACRONIX
> > > Model MX30LF4G28AD
> > > Device size512 MiB
> > > Page size 4096 b
> > > OOB size 256 b
> > > Erase size 262144 b
> > > ecc strength 8 bits
> > > ecc step size 512 b
> > > subpagesize 4096 b
> > > options 0x4200
> > > bbt options 0x00028000
> >
> > This seems to be the same NAND chip as on the sam9x60 curiosity, but your
> > output has three additional lines, see mine:
> > Do you have some additional patches printing manufacturer, model, and
> > device size? I can't see those lines printed in
> > nand_print_and_set_info() here.
> >
> > Yes. I have
> > + printf(" Manufacturer %s \n", chip->onfi_params.manufacturer);
> > + printf(" Model %s \n", chip->onfi_params.model);
> > + printf(" Device size %8d MiB\n", (int)(chip->chipsize >> 20));
>
> This is nice, and I think it would be valuable to have upstream.
> Maybe you could send a patch for that?
> Sure. I will send the patch !
>
> > > U-Boot> hsmc decode
> > >
> > > mck clock rate: 2
> > >
> > > HSMC_SETUP3:0x0001
> > > HSMC_PULSE3:0x07040804
> > > HSMC_CYCLE3:0x00070008
> > > HSMC_TIMINGS3: 0x880402f2
> > > HSMC_MODE3: 0x001f0003
> > > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35
> > > ns)
> > >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7
> > > (35 ns)
> > > NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40
> > > ns)
> > >NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8
> > > (40 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus
> > > Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE
> > > signal Read operation controlled by NRD signal
> >
> > This is also interesting. Given the mck clock rate is the same as on
> > sam9x60, I would have guessed the timings set by
> > atmel_smc_nand_prepare_smcconf() should give the same results, both for
> > ONFI timiming mode 3, which is the fastest mode the (H)SMC supports
> > according to comments in the driver. This is the output with the patch in
> > question applied on next for sam9x60:
> >
> > U-Boot> hsmc decode
> >
> > mck clock rate: 2
> >
> > SMC_SETUP3: 0x0002
> > SMC_PULSE3: 0x06030703
> > SMC_CYCLE3: 0x00060007
> > SMC_MODE3: 0x001f0003
> > NCS_RD: setup: 0 (0 ns), pulse: 6 (30 ns), hold: 0 (0 ns), cycle: 6 (30
> > ns)
> >NRD: setup: 0 (0 ns), pulse: 3 (15 ns), hold: 3 (15 ns), cycle: 6
> > (30 ns)
> > NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35
> > ns)
> >NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7
> > (35 ns)
> > Standard read is applied.
> > TDF optimization enabled
> > TDF cycles: 15 (75 ns)
> > Data Bus Width: 8-bit bus
> > NWAIT Mode: 0
> > Write operation controlled by NWE signal
> > Read operation controlled by NRD signal
> >
> > Notice the pulse times for read are one clock cycle smaller than in your
> > output, and the timings for write are also different. Do you have changes
> > for atmel_smc_nand_prepare_smcconf() applied which are not upstream yet?
> > Or is the HSMC on sama7g54 somehow different than on older SoCs?
> >
> > Yes. I force timing mode 2 in nand-controller.c:
> > + if (conf->timings.sdr.tRC_min < 30001) // force timing mode 2,
> > + 35ns for read/write cycle
> >
> > This will pass the nand torture test
> >
> > U-Boot> nand torture 0x80 0x100
> >
> > NAND torture: device 0 offset 0x80 size 0x100 (block size
> > 0x4)
> > Passed: 64, failed: 0
>
> Ah okay. I have another patch here for manually setting the ONFI timing mode
> from commandline. This is probably too late for some scenarios, but it
> helped me when testing. If you're interested I could send it to the public.
> Yes. I'm very interested !
Okay, I'll add it to v2 of the series then.
> Maybe we should add an automatic fallback for timing mode in
> nand-controller.c
> As of now the driver is forcing tRC_min to 30ns (mode 3), which is not
> reliable for sama7 nfc controller ☹
>
> https://github.com/u-boot/u-boot/blob/master/drivers/mtd/nand/raw/nand_timings.c#L167
> The nand torture command helped me to manually force tRC_min to 35ns
> (mode 2).
This sounds like the same problem encountered in
https://github.com/linux4sam/at91bootstrap/issues/174 and the fix
proposed there works in Linux and U-Boot as well. I consider the
original commit message of the patch attached to that ticket not easy
to understand however, so I wrote what I
RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
Hi Alexander,
I'm sorry for quoting because the email is sent from Outlook ☹
> > U-Boot> nand info
> >
> > Device 0: nand0, sector size 256 KiB
> > Manufacturer MACRONIX
> > Model MX30LF4G28AD
> > Device size512 MiB
> > Page size 4096 b
> > OOB size 256 b
> > Erase size 262144 b
> > ecc strength 8 bits
> > ecc step size 512 b
> > subpagesize 4096 b
> > options 0x4200
> > bbt options 0x00028000
>
> This seems to be the same NAND chip as on the sam9x60 curiosity, but your
> output has three additional lines, see mine:
> Do you have some additional patches printing manufacturer, model, and
> device size? I can't see those lines printed in
> nand_print_and_set_info() here.
>
> Yes. I have
> + printf(" Manufacturer %s \n", chip->onfi_params.manufacturer);
> + printf(" Model %s \n", chip->onfi_params.model);
> + printf(" Device size %8d MiB\n", (int)(chip->chipsize >> 20));
This is nice, and I think it would be valuable to have upstream.
Maybe you could send a patch for that?
Sure. I will send the patch !
> > U-Boot> hsmc decode
> >
> > mck clock rate: 2
> >
> > HSMC_SETUP3:0x0001
> > HSMC_PULSE3:0x07040804
> > HSMC_CYCLE3:0x00070008
> > HSMC_TIMINGS3: 0x880402f2
> > HSMC_MODE3: 0x001f0003
> > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
> >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7
> > (35 ns)
> > NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns)
> >NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8
> > (40 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus
> > Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE
> > signal Read operation controlled by NRD signal
>
> This is also interesting. Given the mck clock rate is the same as on
> sam9x60, I would have guessed the timings set by
> atmel_smc_nand_prepare_smcconf() should give the same results, both for ONFI
> timiming mode 3, which is the fastest mode the (H)SMC supports according to
> comments in the driver. This is the output with the patch in question
> applied on next for sam9x60:
>
> U-Boot> hsmc decode
>
> mck clock rate: 2
>
> SMC_SETUP3: 0x0002
> SMC_PULSE3: 0x06030703
> SMC_CYCLE3: 0x00060007
> SMC_MODE3: 0x001f0003
> NCS_RD: setup: 0 (0 ns), pulse: 6 (30 ns), hold: 0 (0 ns), cycle: 6 (30
> ns)
>NRD: setup: 0 (0 ns), pulse: 3 (15 ns), hold: 3 (15 ns), cycle: 6 (30
> ns)
> NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35
> ns)
>NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 (35
> ns)
> Standard read is applied.
> TDF optimization enabled
> TDF cycles: 15 (75 ns)
> Data Bus Width: 8-bit bus
> NWAIT Mode: 0
> Write operation controlled by NWE signal
> Read operation controlled by NRD signal
>
> Notice the pulse times for read are one clock cycle smaller than in your
> output, and the timings for write are also different. Do you have changes
> for atmel_smc_nand_prepare_smcconf() applied which are not upstream yet? Or
> is the HSMC on sama7g54 somehow different than on older SoCs?
>
> Yes. I force timing mode 2 in nand-controller.c:
> + if (conf->timings.sdr.tRC_min < 30001) // force timing mode 2,
> + 35ns for read/write cycle
>
> This will pass the nand torture test
>
> U-Boot> nand torture 0x80 0x100
>
> NAND torture: device 0 offset 0x80 size 0x100 (block size
> 0x4)
> Passed: 64, failed: 0
Ah okay. I have another patch here for manually setting the ONFI timing mode
from commandline. This is probably too late for some scenarios, but it helped
me when testing. If you're interested I could send it to the public.
Yes. I'm very interested !
Maybe we should add an automatic fallback for timing mode in
nand-controller.c
As of now the driver is forcing tRC_min to 30ns (mode 3), which is not
reliable for sama7 nfc controller ☹
https://github.com/u-boot/u-boot/blob/master/drivers/mtd/nand/raw/nand_timings.c#L167
The nand torture command helped me to manually force tRC_min to 35ns
(mode 2).
Thanks.
Greets
Alex
>
> Note: I'm currently testing a patch changing the computation of the read
> pulse cycles based on a patch for at91bootstrap [1], but that is not applied
> here for the output quoted above.
>
> Greets
> Alex
>
> [1]
> https://github.com/linux4sam/at91bootstrap/issues/174#issuecomment-197
> 0698527
>
> >
> > Best regards,
> > Mihai Sain
Re: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
Hello Mihai,
Am Mon, Mar 18, 2024 at 09:07:09AM + schrieb mihai.s...@microchip.com:
> > U-Boot> nand info
> >
> > Device 0: nand0, sector size 256 KiB
> > Manufacturer MACRONIX
> > Model MX30LF4G28AD
> > Device size512 MiB
> > Page size 4096 b
> > OOB size 256 b
> > Erase size 262144 b
> > ecc strength 8 bits
> > ecc step size 512 b
> > subpagesize 4096 b
> > options 0x4200
> > bbt options 0x00028000
>
> This seems to be the same NAND chip as on the sam9x60 curiosity, but your
> output has three additional lines, see mine:
> Do you have some additional patches printing manufacturer, model, and device
> size? I can't see those lines printed in
> nand_print_and_set_info() here.
>
> Yes. I have
> + printf(" Manufacturer %s \n", chip->onfi_params.manufacturer);
> + printf(" Model %s \n", chip->onfi_params.model);
> + printf(" Device size %8d MiB\n", (int)(chip->chipsize >> 20));
This is nice, and I think it would be valuable to have upstream.
Maybe you could send a patch for that?
> > U-Boot> hsmc decode
> >
> > mck clock rate: 2
> >
> > HSMC_SETUP3:0x0001
> > HSMC_PULSE3:0x07040804
> > HSMC_CYCLE3:0x00070008
> > HSMC_TIMINGS3: 0x880402f2
> > HSMC_MODE3: 0x001f0003
> > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
> >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7
> > (35 ns)
> > NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns)
> >NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8
> > (40 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus
> > Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE
> > signal Read operation controlled by NRD signal
>
> This is also interesting. Given the mck clock rate is the same as on
> sam9x60, I would have guessed the timings set by
> atmel_smc_nand_prepare_smcconf() should give the same results, both for ONFI
> timiming mode 3, which is the fastest mode the (H)SMC supports according to
> comments in the driver. This is the output with the patch in question
> applied on next for sam9x60:
>
> U-Boot> hsmc decode
>
> mck clock rate: 2
>
> SMC_SETUP3: 0x0002
> SMC_PULSE3: 0x06030703
> SMC_CYCLE3: 0x00060007
> SMC_MODE3: 0x001f0003
> NCS_RD: setup: 0 (0 ns), pulse: 6 (30 ns), hold: 0 (0 ns), cycle: 6 (30
> ns)
>NRD: setup: 0 (0 ns), pulse: 3 (15 ns), hold: 3 (15 ns), cycle: 6 (30
> ns)
> NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35
> ns)
>NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 (35
> ns)
> Standard read is applied.
> TDF optimization enabled
> TDF cycles: 15 (75 ns)
> Data Bus Width: 8-bit bus
> NWAIT Mode: 0
> Write operation controlled by NWE signal
> Read operation controlled by NRD signal
>
> Notice the pulse times for read are one clock cycle smaller than in your
> output, and the timings for write are also different. Do you have changes
> for atmel_smc_nand_prepare_smcconf() applied which are not upstream yet? Or
> is the HSMC on sama7g54 somehow different than on older SoCs?
>
> Yes. I force timing mode 2 in nand-controller.c:
> + if (conf->timings.sdr.tRC_min < 30001) // force timing mode 2, 35ns for
> read/write cycle
>
> This will pass the nand torture test
>
> U-Boot> nand torture 0x80 0x100
>
> NAND torture: device 0 offset 0x80 size 0x100 (block size 0x4)
> Passed: 64, failed: 0
Ah okay. I have another patch here for manually setting the ONFI
timing mode from commandline. This is probably too late for some
scenarios, but it helped me when testing. If you're interested I
could send it to the public.
Greets
Alex
>
> Note: I'm currently testing a patch changing the computation of the read
> pulse cycles based on a patch for at91bootstrap [1], but that is not applied
> here for the output quoted above.
>
> Greets
> Alex
>
> [1]
> https://github.com/linux4sam/at91bootstrap/issues/174#issuecomment-1970698527
>
> >
> > Best regards,
> > Mihai Sain
RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
> The command is very useful. > I would like to have also the ONFI timing mode printed for nand-flash > As far as I can see the actually set mode is not stored anywhere. One could print it after it was successfully set, but that would be in nand base, not in the atmel driver. OK. Understood. Thanks. > Also I recommend to print the master clock in MHz, and to print the master > clock name/label from ccf driver: > https://github.com/u-boot/u-boot/blob/master/drivers/clk/at91/sama7g5. > c#L410 Should be possible. I could do this and send a v2? Yes Please Also please note that older SAM9/SAMA5 series have no ccf drivers ☹ Only SAM9X6+ and SAMA7 series have ccf Thanks. Greets Alex > > Tested-by: Mihai Sain > > Best regards, > Mihai Sain
Re: [PATCH 1/1] xilinx: zynq: add FDT_FIXUP_PARTITIONS support
On 3/18/24 09:48, James Hilliard wrote:
On Mon, Mar 18, 2024 at 2:26 AM Michal Simek wrote:
On 3/15/24 20:25, James Hilliard wrote:
There are situations where we may want to let U-Boot modify the FDT
please use imperative mood.
nand partitions for the kernel, such as when supporting multiple
sizes of NAND chips.
Lets also refactor xilinx common board support to have a
ft_common_board_setup which gets called by the ft_board_setup for each
specific board so that we can add non-common functionality to each
ft_board_setup like FDT_FIXUP_PARTITIONS as needed.
This pattern is modeled after the one used by tdx-common.c.
Signed-off-by: James Hilliard
---
board/xilinx/common/board.c | 2 +-
board/xilinx/common/board.h | 2 ++
board/xilinx/mbv/board.c| 9 +
board/xilinx/versal-net/board.c | 7 +++
board/xilinx/versal/board.c | 7 +++
board/xilinx/zynq/board.c | 17 +
board/xilinx/zynqmp/zynqmp.c| 7 +++
board/xilinx/zynqmp_r5/board.c | 8
8 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 9641ed307b..629ba2b902 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -686,7 +686,7 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
#ifdef CONFIG_OF_BOARD_SETUP
#define MAX_RAND_SIZE 8
-int ft_board_setup(void *blob, struct bd_info *bd)
+int ft_common_board_setup(void *blob, struct bd_info *bd)
{
size_t n = MAX_RAND_SIZE;
struct udevice *dev;
diff --git a/board/xilinx/common/board.h b/board/xilinx/common/board.h
index 64d657673e..73f576952a 100644
--- a/board/xilinx/common/board.h
+++ b/board/xilinx/common/board.h
@@ -18,4 +18,6 @@ bool board_detection(void);
char *soc_name_decode(void);
bool soc_detection(void);
+
+int ft_common_board_setup(void *blob, struct bd_info *bd);
#endif /* BOARD_XILINX_COMMON_BOARD_H */
diff --git a/board/xilinx/mbv/board.c b/board/xilinx/mbv/board.c
index ccf4395d6a..d8af1eaa90 100644
--- a/board/xilinx/mbv/board.c
+++ b/board/xilinx/mbv/board.c
@@ -5,7 +5,16 @@
* Michal Simek
*/
+#include "../common/board.h"
+
int board_init(void)
{
return 0;
}
+
+#ifdef CONFIG_OF_BOARD_SETUP
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ return ft_common_board_setup(blob, bd);
+}
+#endif
Any reason not to put directly to board/xilinx/common/board.c?
All xilinx boards are kept in sync from user perspective that's why generic
pieces should be added to common location.
I assumed the device tree node "arm,pl353-nand-r2p1" was specific to boards
using xilinx/zynq/board.c since it seemed only those were the only ones to use
that node. Have any idea if that assumption is accurate?
Configuration around xilinx boards are quite generic. Normally nand controller
is by default connected on Zynq SOC. But because chips are highly configurable
you can connect it also from Microblaze or Risc-V but
I think you can simply do changes in common location and put there proper ifs
and it should be fine.
Also keep in mind that you should avoid using #ifdef as much as possible and use
if (IS_ENABLED(...)) instead.
M
Re: [PATCH 1/1] xilinx: zynq: add FDT_FIXUP_PARTITIONS support
On Mon, Mar 18, 2024 at 2:26 AM Michal Simek wrote:
>
>
>
> On 3/15/24 20:25, James Hilliard wrote:
> > There are situations where we may want to let U-Boot modify the FDT
>
> please use imperative mood.
>
> > nand partitions for the kernel, such as when supporting multiple
> > sizes of NAND chips.
> >
> > Lets also refactor xilinx common board support to have a
> > ft_common_board_setup which gets called by the ft_board_setup for each
> > specific board so that we can add non-common functionality to each
> > ft_board_setup like FDT_FIXUP_PARTITIONS as needed.
> >
> > This pattern is modeled after the one used by tdx-common.c.
> >
> > Signed-off-by: James Hilliard
> > ---
> > board/xilinx/common/board.c | 2 +-
> > board/xilinx/common/board.h | 2 ++
> > board/xilinx/mbv/board.c| 9 +
> > board/xilinx/versal-net/board.c | 7 +++
> > board/xilinx/versal/board.c | 7 +++
> > board/xilinx/zynq/board.c | 17 +
> > board/xilinx/zynqmp/zynqmp.c| 7 +++
> > board/xilinx/zynqmp_r5/board.c | 8
> > 8 files changed, 58 insertions(+), 1 deletion(-)
> >
> > diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
> > index 9641ed307b..629ba2b902 100644
> > --- a/board/xilinx/common/board.c
> > +++ b/board/xilinx/common/board.c
> > @@ -686,7 +686,7 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
> > total_size)
> >
> > #ifdef CONFIG_OF_BOARD_SETUP
> > #define MAX_RAND_SIZE 8
> > -int ft_board_setup(void *blob, struct bd_info *bd)
> > +int ft_common_board_setup(void *blob, struct bd_info *bd)
> > {
> > size_t n = MAX_RAND_SIZE;
> > struct udevice *dev;
> > diff --git a/board/xilinx/common/board.h b/board/xilinx/common/board.h
> > index 64d657673e..73f576952a 100644
> > --- a/board/xilinx/common/board.h
> > +++ b/board/xilinx/common/board.h
> > @@ -18,4 +18,6 @@ bool board_detection(void);
> > char *soc_name_decode(void);
> >
> > bool soc_detection(void);
> > +
> > +int ft_common_board_setup(void *blob, struct bd_info *bd);
> > #endif /* BOARD_XILINX_COMMON_BOARD_H */
> > diff --git a/board/xilinx/mbv/board.c b/board/xilinx/mbv/board.c
> > index ccf4395d6a..d8af1eaa90 100644
> > --- a/board/xilinx/mbv/board.c
> > +++ b/board/xilinx/mbv/board.c
> > @@ -5,7 +5,16 @@
> >* Michal Simek
> >*/
> >
> > +#include "../common/board.h"
> > +
> > int board_init(void)
> > {
> > return 0;
> > }
> > +
> > +#ifdef CONFIG_OF_BOARD_SETUP
> > +int ft_board_setup(void *blob, struct bd_info *bd)
> > +{
> > + return ft_common_board_setup(blob, bd);
> > +}
> > +#endif
>
> Any reason not to put directly to board/xilinx/common/board.c?
> All xilinx boards are kept in sync from user perspective that's why generic
> pieces should be added to common location.
I assumed the device tree node "arm,pl353-nand-r2p1" was specific to boards
using xilinx/zynq/board.c since it seemed only those were the only ones to use
that node. Have any idea if that assumption is accurate?
>
>
> > diff --git a/board/xilinx/versal-net/board.c
> > b/board/xilinx/versal-net/board.c
> > index 990ca1650a..bd674e6739 100644
> > --- a/board/xilinx/versal-net/board.c
> > +++ b/board/xilinx/versal-net/board.c
> > @@ -371,3 +371,10 @@ int dram_init(void)
> > void reset_cpu(void)
> > {
> > }
> > +
> > +#ifdef CONFIG_OF_BOARD_SETUP
> > +int ft_board_setup(void *blob, struct bd_info *bd)
> > +{
> > + return ft_common_board_setup(blob, bd);
> > +}
> > +#endif
> > diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
> > index 8c2e614ad8..944ef2d822 100644
> > --- a/board/xilinx/versal/board.c
> > +++ b/board/xilinx/versal/board.c
> > @@ -320,3 +320,10 @@ enum env_location env_get_location(enum env_operation
> > op, int prio)
> > return ENVL_NOWHERE;
> > }
> > }
> > +
> > +#ifdef CONFIG_OF_BOARD_SETUP
> > +int ft_board_setup(void *blob, struct bd_info *bd)
> > +{
> > + return ft_common_board_setup(blob, bd);
> > +}
> > +#endif
> > diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
> > index 6c36591001..1ca1984c49 100644
> > --- a/board/xilinx/zynq/board.c
> > +++ b/board/xilinx/zynq/board.c
> > @@ -13,10 +13,12 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -201,3 +203,18 @@ void set_dfu_alt_info(char *interface, char *devstr)
> > puts("DFU alt info setting: done\n");
> > }
> > #endif
> > +
> > +#ifdef CONFIG_OF_BOARD_SETUP
> > +int ft_board_setup(void *blob, struct bd_info *bd)
> > +{
> > +#ifdef CONFIG_FDT_FIXUP_PARTITIONS
> > + static const struct node_info nodes[] = {
> > + { "arm,pl353-nand-r2p1", MTD_DEV_TYPE_NAND, },
>
> Very likely also depends on CONFIG_NAND_ZYNQ. It means pretty much you can
> move
> this code directly to common/board.c because only Zynq uses this
[PATCH 1/1] .mailmap entry for Masahisa Kojima
The Linaro mail address is not valid anymore. Cc: kojima.masah...@socionext.com Signed-off-by: Heinrich Schuchardt --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index d1f08f3eca8..59f84711000 100644 --- a/.mailmap +++ b/.mailmap @@ -57,6 +57,7 @@ John Linn Jyotheeswar Reddy Mutthareddyvari Jyotheeswar Reddy Mutthareddyvari Kalyani Akula +Masahisa Kojima Love Kumar Lukasz Majewski Marek Behún -- 2.43.0
Re: [PATCH v2 2/2] rockchip: rock-pi-4-rk3399: enable booting from SPI flash
Hi Christopher,
On 2024-03-15 13:01, Christopher Obbard wrote:
> Some variants of the ROCK Pi 4 series have an SPI flash chip populated
> which can be booted from. This patch enables support in U-Boot for
> building the image for the SPI flash, support for booting U-Boot from the
> SPI flash chip and support in U-Boot for accessing the SPI flash using
> `sf` commands.
>
> Not all variants (e.g. ROCK Pi 4B, ROCK 4 Model C Plus, ROCK 4SE) come
> populated with an SPI flash chip, but have the footprint on the board so
> a user could solder their own to the board. With this patchset applied,
> these board variants without an SPI flash chip still boot from MMC.
>
> I have enabled support for both Winbond and XTX SPI flash devices since
> different hardware variants have different devices populated:
>
> - `rockpi4_v13_sch_20181112.pdf` contains a Winbond part `W25Q64FWZPIG`
> - `rockpi4_v14_sch_20210114.pdf` contains an XTX part `XT25F32BWOIGT`
>
> The ROCK Pi 4 I have is marked as "ROCK PI 4 v1.48" and contains an SPI
> flash chip from XTX:
>
> => sf probe
> SF: Detected xt25f32 with page size 256 Bytes, erase size 4 KiB, total 4
> MiB
>
> In the interest of supporting all board variants and not regressing
> existing users who boot from MMC, I have enabled support for booting from
> both SPI flash chip variants in the defconfig and left the environment
> storage location as MMC to not break existing users who have the
> environment stored on MMC.
>
> Signed-off-by: Christopher Obbard
With a small nit below this is:
Reviewed-by: Jonas Karlman
>
> ---
>
> Changes in v2:
> - Rebase on top of rockchip/for-next.
> - Sync configuration changes with savedefconfig.
> - Remove GigaDevice SPI flash chip support (suggested by Kever Y).
> - Re-enable CONFIG_SPL_FIT_SIGNATURE=y (fixed in rockchip/for-next, solves
> multiple problems mentioned in v1. Thanks Jonas!).
> - Remove spl-boot-order from rk3399-rock-pi-4a-u-boot.dtsi (suggested by
> Jonas K).
> - Enable CONFIG_SPI_FLASH_SFDP_SUPPORT=y (suggested by Jonas K).
>
> arch/arm/dts/rk3399-rock-pi-4a-u-boot.dtsi | 7 +++
> configs/rock-pi-4-rk3399_defconfig | 17 ++---
> 2 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/dts/rk3399-rock-pi-4a-u-boot.dtsi
> b/arch/arm/dts/rk3399-rock-pi-4a-u-boot.dtsi
> index 85ee5770add..38385621deb 100644
> --- a/arch/arm/dts/rk3399-rock-pi-4a-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rock-pi-4a-u-boot.dtsi
> @@ -4,3 +4,10 @@
> */
>
> #include "rk3399-rock-pi-4-u-boot.dtsi"
> +
> + {
> + flash@0 {
> + bootph-pre-ram;
> + bootph-some-ram;
> + };
> +};
> diff --git a/configs/rock-pi-4-rk3399_defconfig
> b/configs/rock-pi-4-rk3399_defconfig
> index bca44beca12..315b8b853fc 100644
> --- a/configs/rock-pi-4-rk3399_defconfig
> +++ b/configs/rock-pi-4-rk3399_defconfig
> @@ -3,25 +3,30 @@ CONFIG_SKIP_LOWLEVEL_INIT=y
> CONFIG_COUNTER_FREQUENCY=2400
> CONFIG_ARCH_ROCKCHIP=y
> CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SF_DEFAULT_SPEED=1000
> CONFIG_ENV_OFFSET=0x3F8000
> CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock-pi-4a"
> CONFIG_OF_LIBFDT_OVERLAY=y
> CONFIG_DM_RESET=y
> CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPI_IMAGE=y
> CONFIG_TARGET_ROCKPI4_RK3399=y
> CONFIG_DEBUG_UART_BASE=0xFF1A
> CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_SPL_SPI_FLASH_SUPPORT=y
> +CONFIG_SPL_SPI=y
> CONFIG_SYS_LOAD_ADDR=0x800800
> CONFIG_PCI=y
> CONFIG_DEBUG_UART=y
> # CONFIG_ANDROID_BOOT_IMAGE is not set
> CONFIG_SPL_FIT_SIGNATURE=y
> -CONFIG_LEGACY_IMAGE_FORMAT=y
This may stop scripts from working.
I am getting very close to send out a big rk3399 DT sync and update
series [1] on top of your series. That series will move to imply
LEGACY_IMAGE_FORMAT in Kconfig file, so this does not matter that much.
Please let me know if you will revert this line or if I should send out
my series on top of this patch as-is :-)
[1] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3399-2024.07-wip
Regards,
Jonas
> CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock-pi-4a.dtb"
> CONFIG_DISPLAY_BOARDINFO_LATE=y
> -CONFIG_SPL_MAX_SIZE=0x2e000
> +CONFIG_SPL_MAX_SIZE=0x4
> CONFIG_SPL_PAD_TO=0x7f8000
> # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> +CONFIG_SPL_SPI_LOAD=y
> +CONFIG_SYS_SPI_U_BOOT_OFFS=0xE
> CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
> CONFIG_TPL=y
> CONFIG_CMD_BOOTZ=y
> @@ -40,14 +45,20 @@ CONFIG_SPL_OF_CONTROL=y
> CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> CONFIG_ENV_IS_IN_MMC=y
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
> CONFIG_DFU_MMC=y
> CONFIG_ROCKCHIP_GPIO=y
> CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_ROCKCHIP_IODOMAIN=y
> CONFIG_MMC_DW=y
> CONFIG_MMC_DW_ROCKCHIP=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_SDMA=y
> CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_SF_DEFAULT_BUS=1
> +CONFIG_SPI_FLASH_SFDP_SUPPORT=y
>
Re: [PATCH v2 1/2] arm: rockchip: sync ROCK Pi 4A DTS from Linux
On 2024-03-15 13:01, Christopher Obbard wrote:
> To prepare for ROCK Pi 4A SPI flash support, sync the DTS from Linux which
> includes an SPI flash node.
>
> Kernel tag: v6.6-rc1
> Kernel commits:
> - eddf73029770 ("arm64: dts: rockchip: Enable internal SPI flash for ROCK \
> Pi 4A/B/C")
>
> Reviewed-by: Kever Yang
> Signed-off-by: Christopher Obbard
Reviewed-by: Jonas Karlman
Regards,
Jonas
> ---
>
> Changes in v2:
> - Collect Reviewed-by tag from Kever Y.
>
> arch/arm/dts/rk3399-rock-pi-4a.dts | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-rock-pi-4a.dts
> b/arch/arm/dts/rk3399-rock-pi-4a.dts
> index 931334aa3d6..d5df8939a65 100644
> --- a/arch/arm/dts/rk3399-rock-pi-4a.dts
> +++ b/arch/arm/dts/rk3399-rock-pi-4a.dts
> @@ -12,3 +12,13 @@
> model = "Radxa ROCK Pi 4A";
> compatible = "radxa,rockpi4a", "radxa,rockpi4", "rockchip,rk3399";
> };
> +
> + {
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <1000>;
> + };
> +};
Re: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
Hello Mihai, Am Mon, Mar 18, 2024 at 09:15:29AM + schrieb mihai.s...@microchip.com: > > Hi Alexander, > > > > I tested your work on sama7g54-curiosity board: > > > > U-Boot> nand info > > > > Device 0: nand0, sector size 256 KiB > > Manufacturer MACRONIX > > Model MX30LF4G28AD > > Device size512 MiB > > Page size 4096 b > > OOB size 256 b > > Erase size 262144 b > > ecc strength 8 bits > > ecc step size 512 b > > subpagesize 4096 b > > options 0x4200 > > bbt options 0x00028000 > > > > U-Boot> hsmc decode > > > > mck clock rate: 2 > > > > HSMC_SETUP3:0x0001 > > HSMC_PULSE3:0x07040804 > > HSMC_CYCLE3:0x00070008 > > HSMC_TIMINGS3: 0x880402f2 > > HSMC_MODE3: 0x001f0003 > > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns) > >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 > > (35 ns) > > NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns) > >NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8 > > (40 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus > > Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE > > signal Read operation controlled by NRD signal > > > > Best regards, > > Mihai Sain > > Hello Mihai, > > If you have any suggestions for improvement, changes, or you are happy with > this command, is it useful ? > You can provide your Tested-by then if you consider this is useful > > Eugen > > -- > > Hello Eugen, > > Yes. > The command is very useful. > I would like to have also the ONFI timing mode printed for nand-flash As far as I can see the actually set mode is not stored anywhere. One could print it after it was successfully set, but that would be in nand base, not in the atmel driver. > Also I recommend to print the master clock in MHz, and to print the master > clock name/label from ccf driver: > https://github.com/u-boot/u-boot/blob/master/drivers/clk/at91/sama7g5.c#L410 Should be possible. I could do this and send a v2? Greets Alex > > Tested-by: Mihai Sain > > Best regards, > Mihai Sain
Re: [RFC PATCH 0/3] mtd: nand: raw: atmel: Using dm driver for older sam9 SoCs
On 3/11/24 17:23, Alexander Dahl wrote: > Hello raw NAND fans, > Hello Alexander, Thank you for your efforts > today I thought it would be interesting to have all that automatic NAND > flash timings setting usable with an old board featuring a at91sam9g20 > SoC, which would pave the way to get rid of the old atmel raw nand > driver eventually. My "let's try this quickly" ended up in "damn this > took hours and now I'm stuck". > > Those older SoCs have no hardware ecc engine like the sama5d2 or sam9x60 > have, which the Linux driver can work with. (The U-Boot driver was > ported from Linux back then.) > > The problem is NAND flash detection fails because the atmel nand > controller drivers fails on probing. In fact > `atmel_nand_controller_init()` tries to set the pointer `nc->pmecc` by > calling `devm_atmel_pmecc_get()`. That one probably gets a > -EPROBE_DEFER returned by `atmel_pmecc_get_by_node()` and then > `atmel_nand_controller_init()` returns -EPROBE_DEFER too and probing the > driver fails. I suspect it should work fine if `nc->pmecc` would be > NULL, but I have no idea what would be the right place to implement > this. I also suspect that -EPROBE_DEFER contradicts the U-Boot driver > model somehow? The raw/atmel/nand-controller driver was adapted (quite > a bit) to work with U-Boot, but maybe some aspects of U-Boot driver > model where not considered correctly? I added Simon, to give us a hint on how to approach this. How I see it, is that the probing of the NAND should pause, and then the DM should look for the dependency, and probe it. if that dependency fails, then NAND probe fails. But returning DEFER would not be good since I do not believe there is another probe attempt unless manually done so (and it would be weird to get some error on first probe and success on the next, at least in u-boot state of mind) Maybe Simon can give us some ideas > > The attached patches are what I have so far, marked them as RFC because > my actual goal of using the new dm based driver for the old SoC was not > completed. Patches look good, but I am not sure whether they bring any additional value as you claim it's not working. Maybe they could be picked up and worked more to get it into the state you want ? >From my knowledge, investing effort into these old SoCs is not a priority for >the at91 people. Eugen > > Greets > Alex > > P.S.: Patch stack based on next. > > Alexander Dahl (3): > ARM: dts: at91sam9260: Add modern NAND controller nodes > memory: atmel-ebi: Add compatible for older 9260 cores > mtd: nand: raw: atmel: Remove redundant PMECC probe > > arch/arm/dts/at91sam9260.dtsi| 47 > drivers/memory/atmel_ebi.c | 1 + > drivers/mtd/nand/raw/atmel/nand-controller.c | 7 --- > drivers/mtd/nand/raw/atmel/pmecc.c | 1 + > 4 files changed, 49 insertions(+), 7 deletions(-) > > > base-commit: beedf675b36841ce1e09157a87a6505317e6
[RESEND PATCH v3 4/5] power: regulator: tps65941: use function callbacks for conversion ops
Use function callbacks for volt2val, val2volt and slewrate lookups.
This makes it easier to add support for TPS65224 PMIC regulators.
Signed-off-by: Bhargav Raviprakash
---
drivers/power/regulator/tps65941_regulator.c | 61 +++-
1 file changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/power/regulator/tps65941_regulator.c
b/drivers/power/regulator/tps65941_regulator.c
index cf54e30df5..d879c2301b 100644
--- a/drivers/power/regulator/tps65941_regulator.c
+++ b/drivers/power/regulator/tps65941_regulator.c
@@ -35,6 +35,17 @@
#define TPS65941_LDO_ID_3 3
#define TPS65941_LDO_ID_4 4
+#define TPS65941_BUCK_CONV_OPS_IDX 0
+#define TPS65941_LDO_CONV_OPS_IDX 0
+
+struct tps65941_reg_conv_ops {
+ int volt_mask;
+ int (*volt2val)(int idx, int uV);
+ int (*val2volt)(int idx, int volt);
+ int slew_mask;
+ int (*lookup_slew)(int id);
+};
+
static const char tps65941_buck_ctrl[TPS65941_BUCK_NUM] = {0x4, 0x6, 0x8, 0xA,
0xC};
static const char tps65941_buck_vout[TPS65941_BUCK_NUM] = {0xE, 0x10, 0x12,
@@ -79,7 +90,7 @@ static int tps65941_buck_enable(struct udevice *dev, int op,
bool *enable)
return 0;
}
-static int tps65941_buck_volt2val(int uV)
+static int tps65941_buck_volt2val(__maybe_unused int idx, int uV)
{
if (uV > TPS65941_BUCK_VOLT_MAX)
return -EINVAL;
@@ -95,7 +106,7 @@ static int tps65941_buck_volt2val(int uV)
return -EINVAL;
}
-static int tps65941_buck_val2volt(int val)
+static int tps65941_buck_val2volt(__maybe_unused int idx, int val)
{
if (val > TPS65941_BUCK_VOLT_MAX_HEX)
return -EINVAL;
@@ -135,12 +146,25 @@ int tps65941_lookup_slew(int id)
}
}
+static const struct tps65941_reg_conv_ops buck_conv_ops[] = {
+ [TPS65941_BUCK_CONV_OPS_IDX] = {
+ .volt_mask = TPS65941_BUCK_VOLT_MASK,
+ .volt2val = tps65941_buck_volt2val,
+ .val2volt = tps65941_buck_val2volt,
+ .slew_mask = TP65941_BUCK_CONF_SLEW_MASK,
+ .lookup_slew = tps65941_lookup_slew,
+ },
+};
+
static int tps65941_buck_val(struct udevice *dev, int op, int *uV)
{
unsigned int hex, adr;
- int ret, delta, uwait, slew;
+ int ret, delta, uwait, slew, idx;
struct dm_regulator_uclass_plat *uc_pdata;
+ const struct tps65941_reg_conv_ops *conv_ops;
+ idx = dev->driver_data;
+ conv_ops = _conv_ops[TPS65941_BUCK_CONV_OPS_IDX];
uc_pdata = dev_get_uclass_plat(dev);
if (op == PMIC_OP_GET)
@@ -152,8 +176,8 @@ static int tps65941_buck_val(struct udevice *dev, int op,
int *uV)
if (ret < 0)
return ret;
- ret &= TPS65941_BUCK_VOLT_MASK;
- ret = tps65941_buck_val2volt(ret);
+ ret &= conv_ops->volt_mask;
+ ret = conv_ops->val2volt(idx, ret);
if (ret < 0)
return ret;
@@ -175,14 +199,14 @@ static int tps65941_buck_val(struct udevice *dev, int op,
int *uV)
if (slew < 0)
return ret;
- slew &= TP65941_BUCK_CONF_SLEW_MASK;
- slew = tps65941_lookup_slew(slew);
+ slew &= conv_ops->slew_mask;
+ slew = conv_ops->lookup_slew(slew);
if (slew <= 0)
return ret;
uwait = delta / slew;
- hex = tps65941_buck_volt2val(*uV);
+ hex = conv_ops->volt2val(idx, *uV);
if (hex < 0)
return hex;
@@ -231,7 +255,7 @@ static int tps65941_ldo_enable(struct udevice *dev, int op,
bool *enable)
return 0;
}
-static int tps65941_ldo_val2volt(int val)
+static int tps65941_ldo_val2volt(__maybe_unused int idx, int val)
{
if (val > TPS65941_LDO_VOLT_MAX_HEX || val < TPS65941_LDO_VOLT_MIN_HEX)
return -EINVAL;
@@ -241,12 +265,23 @@ static int tps65941_ldo_val2volt(int val)
return -EINVAL;
}
+static const struct tps65941_reg_conv_ops ldo_conv_ops[] = {
+ [TPS65941_LDO_CONV_OPS_IDX] = {
+ .volt_mask = TPS65941_LDO_VOLT_MASK,
+ .volt2val = tps65941_buck_volt2val,
+ .val2volt = tps65941_ldo_val2volt,
+ },
+};
+
static int tps65941_ldo_val(struct udevice *dev, int op, int *uV)
{
unsigned int hex, adr;
- int ret;
+ int ret, idx;
struct dm_regulator_uclass_plat *uc_pdata;
+ const struct tps65941_reg_conv_ops *conv_ops;
+ idx = dev->driver_data;
+ conv_ops = _conv_ops[TPS65941_LDO_CONV_OPS_IDX];
uc_pdata = dev_get_uclass_plat(dev);
if (op == PMIC_OP_GET)
@@ -258,8 +293,8 @@ static int tps65941_ldo_val(struct udevice *dev, int op,
int *uV)
if (ret < 0)
return ret;
- ret &= TPS65941_LDO_VOLT_MASK;
- ret = tps65941_ldo_val2volt(ret);
+ ret &= conv_ops->volt_mask;
+ ret = conv_ops->val2volt(idx, ret);
if (ret <
[RESEND PATCH v3 5/5] power: regulator: tps65941: Add TPS65224 PMIC regulator support
Reuse TPS65941 regulator driver to adds support for
TPS65224 PMIC's regulators. 4 BUCKs and 3 LDOs, where
BUCK1 and BUCK2 can be configured in dual phase mode.
Signed-off-by: Bhargav Raviprakash
---
drivers/power/regulator/tps65941_regulator.c | 283 ++-
1 file changed, 270 insertions(+), 13 deletions(-)
diff --git a/drivers/power/regulator/tps65941_regulator.c
b/drivers/power/regulator/tps65941_regulator.c
index d879c2301b..b1b9462fd3 100644
--- a/drivers/power/regulator/tps65941_regulator.c
+++ b/drivers/power/regulator/tps65941_regulator.c
@@ -37,6 +37,8 @@
#define TPS65941_BUCK_CONV_OPS_IDX 0
#define TPS65941_LDO_CONV_OPS_IDX 0
+#define TPS65224_LDO_CONV_OPS_IDX 1
+#define TPS65224_BUCK_CONV_OPS_IDX 1
struct tps65941_reg_conv_ops {
int volt_mask;
@@ -55,6 +57,11 @@ static const char tps65941_ldo_ctrl[TPS65941_BUCK_NUM] =
{0x1D, 0x1E, 0x1F,
static const char tps65941_ldo_vout[TPS65941_BUCK_NUM] = {0x23, 0x24, 0x25,
0x26};
+static inline int tps65941_get_chip_id(struct udevice *dev)
+{
+ return dev->parent->driver_data;
+}
+
static int tps65941_buck_enable(struct udevice *dev, int op, bool *enable)
{
int ret;
@@ -146,6 +153,112 @@ int tps65941_lookup_slew(int id)
}
}
+static int tps65224_buck_volt2val(int idx, int uV)
+{
+ /* This functions maps a value which is in micro Volts to the VSET
value.
+* The mapping is as per the datasheet of TPS65224.
+*/
+
+ if (uV > TPS65224_BUCK_VOLT_MAX)
+ return -EINVAL;
+
+ if (idx > 0) {
+ /* Buck2, Buck3 and Buck4 of TPS65224 has a different schema in
+* converting b/w micro_volt and VSET hex values
+*
+* VSET value starts from 0x00 for 0.5V, and for every increment
+* in VSET value the output voltage increases by 25mV. This is
upto
+* 1.15V where VSET is 0x1A.
+*
+* For 0x1B the output voltage is 1.2V, and for every increment
of
+* VSET the output voltage increases by 50mV upto the max
voltage of
+* 3.3V
+*
+* | Voltage Ranges | VSET Ranges | Voltage Step |
+* +-+--+--+
+* | 0.5V to 1.50V | 0x00 to 0x1A | 25mV|
+* | 1.2V to 3.3V| 0x1B to 0x45 | 50mV|
+*/
+ if (uV >= 120)
+ return (uV - 120) / 5 + 0x1B;
+ else if (uV >= 50)
+ return (uV - 50) / 25000;
+ else
+ return -EINVAL;
+ }
+
+ /* Buck1 and Buck12(dual phase) has a different mapping b/w output
+* voltage and VSET value.
+*
+* | Voltage Ranges | VSET Ranges | Voltage Step |
+* +-+--+--+
+* | 0.5V to 0.58V | 0xA to 0xE | 20mV|
+* | 0.6V to 1.095V | 0xF to 0x72 | 5mV |
+* | 1.1V to 1.65V | 0x73 to 0xAA | 10mV|
+* | 1.6V to 3.3V| 0xAB to 0xFD | 20mV|
+*
+*/
+ if (uV >= 166)
+ return (uV - 166) / 2 + 0xAB;
+ else if (uV >= 110)
+ return (uV - 110) / 1 + 0x73;
+ else if (uV >= 60)
+ return (uV - 60) / 5000 + 0x0F;
+ else if (uV >= 50)
+ return (uV - 50) / 2 + 0x0A;
+ else
+ return -EINVAL;
+}
+
+static int tps65224_buck_val2volt(int idx, int val)
+{
+ /* This function does the opposite to the tps65224_buck_volt2val
function
+* described above.
+* This maps the VSET value to micro volts. Please refer to the ranges
+* mentioned the comments of tps65224_buck_volt2val.
+*/
+
+ if (idx > 0) {
+ if (val > TPS65224_BUCK234_VOLT_MAX_HEX)
+ return -EINVAL;
+ else if (val >= 0x1B)
+ return 120 + (val - 0x1B) * 5;
+ else if (val >= 0x00)
+ return 50 + (val - 0x00) * 25000;
+ else
+ return -EINVAL;
+ }
+
+ if (val > TPS65224_BUCK1_VOLT_MAX_HEX)
+ return -EINVAL;
+ else if (val >= 0xAB)
+ return 166 + (val - 0xAB) * 2;
+ else if (val >= 0x73)
+ return 110 + (val - 0x73) * 1;
+ else if (val >= 0xF)
+ return 60 + (val - 0xF) * 5000;
+ else if (val >= 0xA)
+ return 50 + (val - 0xA) * 2;
+ else
+ return -EINVAL;
+}
+
+int tps65224_lookup_slew(int id)
+{
+ switch (id) {
+ case 0:
+ return 1;
+ case 1:
+
[RESEND PATCH v3 3/5] power: regulator: tps65941: Added macros for BUCK ID
Adds macros for buck and ldo ids and switched to using switch
case instead of if else in probe functions. Helps in adding
support for TPS65224 PMIC.
Signed-off-by: Bhargav Raviprakash
Reviewed-by: Dhruva Gole
---
drivers/power/regulator/tps65941_regulator.c | 54 +++-
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/drivers/power/regulator/tps65941_regulator.c
b/drivers/power/regulator/tps65941_regulator.c
index b041126775..cf54e30df5 100644
--- a/drivers/power/regulator/tps65941_regulator.c
+++ b/drivers/power/regulator/tps65941_regulator.c
@@ -16,6 +16,25 @@
#include
#include
+/* Single Phase Buck IDs */
+#define TPS65941_BUCK_ID_11
+#define TPS65941_BUCK_ID_22
+#define TPS65941_BUCK_ID_33
+#define TPS65941_BUCK_ID_44
+#define TPS65941_BUCK_ID_55
+
+/* Multi Phase Buck IDs */
+#define TPS65941_BUCK_ID_12 12
+#define TPS65941_BUCK_ID_34 34
+#define TPS65941_BUCK_ID_123123
+#define TPS65941_BUCK_ID_1234 1234
+
+/* LDO IDs */
+#define TPS65941_LDO_ID_1 1
+#define TPS65941_LDO_ID_2 2
+#define TPS65941_LDO_ID_3 3
+#define TPS65941_LDO_ID_4 4
+
static const char tps65941_buck_ctrl[TPS65941_BUCK_NUM] = {0x4, 0x6, 0x8, 0xA,
0xC};
static const char tps65941_buck_vout[TPS65941_BUCK_NUM] = {0xE, 0x10, 0x12,
@@ -270,10 +289,15 @@ static int tps65941_ldo_probe(struct udevice *dev)
uc_pdata->type = REGULATOR_TYPE_LDO;
idx = dev->driver_data;
- if (idx == 1 || idx == 2 || idx == 3 || idx == 4) {
+ switch (idx) {
+ case TPS65941_LDO_ID_1:
+ case TPS65941_LDO_ID_2:
+ case TPS65941_LDO_ID_3:
+ case TPS65941_LDO_ID_4:
debug("Single phase regulator\n");
- } else {
- printf("Wrong ID for regulator\n");
+ break;
+ default:
+ pr_err("Wrong ID for regulator\n");
return -EINVAL;
}
@@ -292,18 +316,24 @@ static int tps65941_buck_probe(struct udevice *dev)
uc_pdata->type = REGULATOR_TYPE_BUCK;
idx = dev->driver_data;
- if (idx == 1 || idx == 2 || idx == 3 || idx == 4 || idx == 5) {
+ switch (idx) {
+ case TPS65941_BUCK_ID_1:
+ case TPS65941_BUCK_ID_2:
+ case TPS65941_BUCK_ID_3:
+ case TPS65941_BUCK_ID_4:
+ case TPS65941_BUCK_ID_5:
debug("Single phase regulator\n");
- } else if (idx == 12) {
+ break;
+ case TPS65941_BUCK_ID_12:
+ case TPS65941_BUCK_ID_123:
+ case TPS65941_BUCK_ID_1234:
idx = 1;
- } else if (idx == 34) {
+ break;
+ case TPS65941_BUCK_ID_34:
idx = 3;
- } else if (idx == 123) {
- idx = 1;
- } else if (idx == 1234) {
- idx = 1;
- } else {
- printf("Wrong ID for regulator\n");
+ break;
+ default:
+ pr_err("Wrong ID for regulator\n");
return -EINVAL;
}
--
2.25.1
[RESEND PATCH v3 2/5] power: pmic: tps65941: Add TI TPS65224 PMIC
Adds compatible and data field values of TPS65224 driver in
TPS65941 PMIC driver.
Signed-off-by: Bhargav Raviprakash
Reviewed-by: Dhruva Gole
---
drivers/power/pmic/tps65941.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/pmic/tps65941.c b/drivers/power/pmic/tps65941.c
index 727b42747a..ef63eb733a 100644
--- a/drivers/power/pmic/tps65941.c
+++ b/drivers/power/pmic/tps65941.c
@@ -75,6 +75,7 @@ static const struct udevice_id tps65941_ids[] = {
{ .compatible = "ti,tps659412", .data = TPS659411 },
{ .compatible = "ti,tps659413", .data = TPS659413 },
{ .compatible = "ti,lp876441", .data = LP876441 },
+ { .compatible = "ti,tps65224", .data = TPS65224 },
{ }
};
--
2.25.1
[RESEND PATCH v3 1/5] power: tps65941: Add macros of TPS65224 PMIC
Re-use the TPS65941 PMIC driver for TPS65224 PMIC. Add additional macros of TPS65224 to aid in the driver re-use. Signed-off-by: Bhargav Raviprakash Reviewed-by: Dhruva Gole --- include/power/tps65941.h | 30 ++ 1 file changed, 30 insertions(+) diff --git a/include/power/tps65941.h b/include/power/tps65941.h index a2bc6814ba..cec85333f0 100644 --- a/include/power/tps65941.h +++ b/include/power/tps65941.h @@ -3,11 +3,14 @@ #define TPS659413 0x2 #define TPS659414 0x3 #define LP876441 0x4 +#define TPS65224 0x5 /* I2C device address for pmic tps65941 */ #define TPS65941_I2C_ADDR (0x12 >> 1) #define TPS65941_LDO_NUM 4 #define TPS65941_BUCK_NUM 5 +#define TPS65224_LDO_NUM 3 +#define TPS65224_BUCK_NUM 4 /* Drivers name */ #define TPS65941_LDO_DRIVER"tps65941_ldo" @@ -25,3 +28,30 @@ #define TPS65941_LDO_MODE_MASK 0x1 #define TPS65941_LDO_BYPASS_EN 0x80 #define TP65941_BUCK_CONF_SLEW_MASK0x7 + +#define TPS65224_BUCK_VOLT_MAX 330 +#define TPS65224_BUCK1_VOLT_MAX_HEX 0xFD +#define TPS65224_BUCK234_VOLT_MAX_HEX0x45 + +#define TPS65224_BUCK_CONF_SLEW_MASK 0x3 +#define TPS65224_LDO_VOLT_MASK(0x3F << 1) + +#define TPS65224_LDO1_VOLT_MIN_HEX 0x0C +#define TPS65224_LDO23_VOLT_MIN_HEX 0x00 +#define TPS65224_LDO1_VOLT_MAX_HEX 0x36 +#define TPS65224_LDO23_VOLT_MAX_HEX 0x38 + +#define TPS65224_LDO1_VOLT_MAX330 +#define TPS65224_LDO23_VOLT_MAX 340 +#define TPS65224_LDO1_VOLT_MIN120 +#define TPS65224_LDO23_VOLT_MIN60 + +#define TPS65224_LDO_STEP 5 + +#define TPS65224_LDO_BYP_CONFIG 7 + +#define TPS65224_LDO1_VOLT_BYP_MIN220 +#define TPS65224_LDO1_VOLT_BYP_MAX360 + +#define TPS65224_LDO23_VOLT_BYP_MIN 150 +#define TPS65224_LDO23_VOLT_BYP_MAX 550 -- 2.25.1
[RESEND PATCH v3 0/5] Add support for TI TPS65224 PMIC
TPS65224 is a Power Management IC which provides regulators and others features like GPIOs, RTC, watchdog, ADC, ESMs (Error Signal Monitor), and PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC can communicate through the I2C. Data Sheet for TPS65224: https://www.ti.com/product/TPS65224-Q1 Reusing the TPS65941 PMIC driver to add support for TPS65224 PMIC in U-boot. This includes driver for PMIC and regulator. The driver was tested on Ti's custom AM62P EVM using U-boot's pmic list, regulator list, regulator status and regulator value commands. Since, support for Ti's AM62P is absent in u-boot next, the patches were applied on ti-u-boot ti-u-boot-2023.04-next and tested. Changelog v2 -> v3: - use pr_err instead of printf - comments added in ldo conversion functions Bhargav Raviprakash (5): power: tps65941: Add macros of TPS65224 PMIC power: pmic: tps65941: Add TI TPS65224 PMIC power: regulator: tps65941: Added macros for BUCK ID power: regulator: tps65941: use function callbacks for conversion ops power: regulator: tps65941: Add TPS65224 PMIC regulator support drivers/power/pmic/tps65941.c| 1 + drivers/power/regulator/tps65941_regulator.c | 384 +-- include/power/tps65941.h | 30 ++ 3 files changed, 384 insertions(+), 31 deletions(-) base-commit: 4b151562bb8e54160adedbc6a1c0c749c00a2f84 -- 2.25.1
Re: Add support for TI TPS65224 PMIC
Hello, On Mon, 18 Mar 2024 14:59:54 +0530, Bhargav wrote: > > TPS65224 is a Power Management IC which provides regulators and others > features like GPIOs, RTC, watchdog, ADC, ESMs (Error Signal Monitor), > and PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC > can communicate through the I2C. > > Data Sheet for TPS65224: https://www.ti.com/product/TPS65224-Q1 > > Reusing the TPS65941 PMIC driver to add support for TPS65224 PMIC > in U-boot. This includes driver for PMIC and regulator. > > The driver was tested on Ti's custom AM62P EVM using U-boot's > pmic list, regulator list, regulator status and regulator value commands. > Since, support for Ti's AM62P is absent in u-boot next, the patches > were applied on ti-u-boot ti-u-boot-2023.04-next and tested. > > Changelog v2 -> v3: > - use pr_err instead of printf > - comments added in ldo conversion functions > Please ignore this patch set. I sent old patches again by mistake. I will be re-sending the v3 patch with updated changes. Regards, Bhargav
[PATCH v3 5/5] power: regulator: tps65941: Add TPS65224 PMIC regulator support
Reuse TPS65941 regulator driver to adds support for
TPS65224 PMIC's regulators. 4 BUCKs and 3 LDOs, where
BUCK1 and BUCK2 can be configured in dual phase mode.
Signed-off-by: Bhargav Raviprakash
---
drivers/power/regulator/tps65941_regulator.c | 280 ++-
1 file changed, 267 insertions(+), 13 deletions(-)
diff --git a/drivers/power/regulator/tps65941_regulator.c
b/drivers/power/regulator/tps65941_regulator.c
index d879c2301b..826bc0c63e 100644
--- a/drivers/power/regulator/tps65941_regulator.c
+++ b/drivers/power/regulator/tps65941_regulator.c
@@ -37,6 +37,8 @@
#define TPS65941_BUCK_CONV_OPS_IDX 0
#define TPS65941_LDO_CONV_OPS_IDX 0
+#define TPS65224_LDO_CONV_OPS_IDX 1
+#define TPS65224_BUCK_CONV_OPS_IDX 1
struct tps65941_reg_conv_ops {
int volt_mask;
@@ -55,6 +57,11 @@ static const char tps65941_ldo_ctrl[TPS65941_BUCK_NUM] =
{0x1D, 0x1E, 0x1F,
static const char tps65941_ldo_vout[TPS65941_BUCK_NUM] = {0x23, 0x24, 0x25,
0x26};
+static inline int tps65941_get_chip_id(struct udevice *dev)
+{
+ return dev->parent->driver_data;
+}
+
static int tps65941_buck_enable(struct udevice *dev, int op, bool *enable)
{
int ret;
@@ -146,6 +153,112 @@ int tps65941_lookup_slew(int id)
}
}
+static int tps65224_buck_volt2val(int idx, int uV)
+{
+ /* This functions maps a value which is in micro Volts to the VSET
value.
+* The mapping is as per the datasheet of TPS65224.
+*/
+
+ if (uV > TPS65224_BUCK_VOLT_MAX)
+ return -EINVAL;
+
+ if (idx > 0) {
+ /* Buck2, Buck3 and Buck4 of TPS65224 has a different schema in
+* converting b/w micro_volt and VSET hex values
+*
+* VSET value starts from 0x00 for 0.5V, and for every increment
+* in VSET value the output voltage increases by 25mV. This is
upto
+* 1.15V where VSET is 0x1A.
+*
+* For 0x1B the output voltage is 1.2V, and for every increment
of
+* VSET the output voltage increases by 50mV upto the max
voltage of
+* 3.3V
+*
+* | Voltage Ranges | VSET Ranges | Voltage Step |
+* +-+--+--+
+* | 0.5V to 1.50V | 0x00 to 0x1A | 25mV|
+* | 1.2V to 3.3V| 0x1B to 0x45 | 50mV|
+*/
+ if (uV >= 120)
+ return (uV - 120) / 5 + 0x1B;
+ else if (uV >= 50)
+ return (uV - 50) / 25000;
+ else
+ return -EINVAL;
+ }
+
+ /* Buck1 and Buck12(dual phase) has a different mapping b/w output
+* voltage and VSET value.
+*
+* | Voltage Ranges | VSET Ranges | Voltage Step |
+* +-+--+--+
+* | 0.5V to 0.58V | 0xA to 0xE | 20mV|
+* | 0.6V to 1.095V | 0xF to 0x72 | 5mV |
+* | 1.1V to 1.65V | 0x73 to 0xAA | 10mV|
+* | 1.6V to 3.3V| 0xAB to 0xFD | 20mV|
+*
+*/
+ if (uV >= 166)
+ return (uV - 166) / 2 + 0xAB;
+ else if (uV >= 110)
+ return (uV - 110) / 1 + 0x73;
+ else if (uV >= 60)
+ return (uV - 60) / 5000 + 0x0F;
+ else if (uV >= 50)
+ return (uV - 50) / 2 + 0x0A;
+ else
+ return -EINVAL;
+}
+
+static int tps65224_buck_val2volt(int idx, int val)
+{
+ /* This function does the opposite to the tps65224_buck_volt2val
function
+* described above.
+* This maps the VSET value to micro volts. Please refer to the ranges
+* mentioned the comments of tps65224_buck_volt2val.
+*/
+
+ if (idx > 0) {
+ if (val > TPS65224_BUCK234_VOLT_MAX_HEX)
+ return -EINVAL;
+ else if (val >= 0x1B)
+ return 120 + (val - 0x1B) * 5;
+ else if (val >= 0x00)
+ return 50 + (val - 0x00) * 25000;
+ else
+ return -EINVAL;
+ }
+
+ if (val > TPS65224_BUCK1_VOLT_MAX_HEX)
+ return -EINVAL;
+ else if (val >= 0xAB)
+ return 166 + (val - 0xAB) * 2;
+ else if (val >= 0x73)
+ return 110 + (val - 0x73) * 1;
+ else if (val >= 0xF)
+ return 60 + (val - 0xF) * 5000;
+ else if (val >= 0xA)
+ return 50 + (val - 0xA) * 2;
+ else
+ return -EINVAL;
+}
+
+int tps65224_lookup_slew(int id)
+{
+ switch (id) {
+ case 0:
+ return 1;
+ case 1:
+
[PATCH v3 4/5] power: regulator: tps65941: use function callbacks for conversion ops
Use function callbacks for volt2val, val2volt and slewrate lookups.
This makes it easier to add support for TPS65224 PMIC regulators.
Signed-off-by: Bhargav Raviprakash
---
drivers/power/regulator/tps65941_regulator.c | 61 +++-
1 file changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/power/regulator/tps65941_regulator.c
b/drivers/power/regulator/tps65941_regulator.c
index cf54e30df5..d879c2301b 100644
--- a/drivers/power/regulator/tps65941_regulator.c
+++ b/drivers/power/regulator/tps65941_regulator.c
@@ -35,6 +35,17 @@
#define TPS65941_LDO_ID_3 3
#define TPS65941_LDO_ID_4 4
+#define TPS65941_BUCK_CONV_OPS_IDX 0
+#define TPS65941_LDO_CONV_OPS_IDX 0
+
+struct tps65941_reg_conv_ops {
+ int volt_mask;
+ int (*volt2val)(int idx, int uV);
+ int (*val2volt)(int idx, int volt);
+ int slew_mask;
+ int (*lookup_slew)(int id);
+};
+
static const char tps65941_buck_ctrl[TPS65941_BUCK_NUM] = {0x4, 0x6, 0x8, 0xA,
0xC};
static const char tps65941_buck_vout[TPS65941_BUCK_NUM] = {0xE, 0x10, 0x12,
@@ -79,7 +90,7 @@ static int tps65941_buck_enable(struct udevice *dev, int op,
bool *enable)
return 0;
}
-static int tps65941_buck_volt2val(int uV)
+static int tps65941_buck_volt2val(__maybe_unused int idx, int uV)
{
if (uV > TPS65941_BUCK_VOLT_MAX)
return -EINVAL;
@@ -95,7 +106,7 @@ static int tps65941_buck_volt2val(int uV)
return -EINVAL;
}
-static int tps65941_buck_val2volt(int val)
+static int tps65941_buck_val2volt(__maybe_unused int idx, int val)
{
if (val > TPS65941_BUCK_VOLT_MAX_HEX)
return -EINVAL;
@@ -135,12 +146,25 @@ int tps65941_lookup_slew(int id)
}
}
+static const struct tps65941_reg_conv_ops buck_conv_ops[] = {
+ [TPS65941_BUCK_CONV_OPS_IDX] = {
+ .volt_mask = TPS65941_BUCK_VOLT_MASK,
+ .volt2val = tps65941_buck_volt2val,
+ .val2volt = tps65941_buck_val2volt,
+ .slew_mask = TP65941_BUCK_CONF_SLEW_MASK,
+ .lookup_slew = tps65941_lookup_slew,
+ },
+};
+
static int tps65941_buck_val(struct udevice *dev, int op, int *uV)
{
unsigned int hex, adr;
- int ret, delta, uwait, slew;
+ int ret, delta, uwait, slew, idx;
struct dm_regulator_uclass_plat *uc_pdata;
+ const struct tps65941_reg_conv_ops *conv_ops;
+ idx = dev->driver_data;
+ conv_ops = _conv_ops[TPS65941_BUCK_CONV_OPS_IDX];
uc_pdata = dev_get_uclass_plat(dev);
if (op == PMIC_OP_GET)
@@ -152,8 +176,8 @@ static int tps65941_buck_val(struct udevice *dev, int op,
int *uV)
if (ret < 0)
return ret;
- ret &= TPS65941_BUCK_VOLT_MASK;
- ret = tps65941_buck_val2volt(ret);
+ ret &= conv_ops->volt_mask;
+ ret = conv_ops->val2volt(idx, ret);
if (ret < 0)
return ret;
@@ -175,14 +199,14 @@ static int tps65941_buck_val(struct udevice *dev, int op,
int *uV)
if (slew < 0)
return ret;
- slew &= TP65941_BUCK_CONF_SLEW_MASK;
- slew = tps65941_lookup_slew(slew);
+ slew &= conv_ops->slew_mask;
+ slew = conv_ops->lookup_slew(slew);
if (slew <= 0)
return ret;
uwait = delta / slew;
- hex = tps65941_buck_volt2val(*uV);
+ hex = conv_ops->volt2val(idx, *uV);
if (hex < 0)
return hex;
@@ -231,7 +255,7 @@ static int tps65941_ldo_enable(struct udevice *dev, int op,
bool *enable)
return 0;
}
-static int tps65941_ldo_val2volt(int val)
+static int tps65941_ldo_val2volt(__maybe_unused int idx, int val)
{
if (val > TPS65941_LDO_VOLT_MAX_HEX || val < TPS65941_LDO_VOLT_MIN_HEX)
return -EINVAL;
@@ -241,12 +265,23 @@ static int tps65941_ldo_val2volt(int val)
return -EINVAL;
}
+static const struct tps65941_reg_conv_ops ldo_conv_ops[] = {
+ [TPS65941_LDO_CONV_OPS_IDX] = {
+ .volt_mask = TPS65941_LDO_VOLT_MASK,
+ .volt2val = tps65941_buck_volt2val,
+ .val2volt = tps65941_ldo_val2volt,
+ },
+};
+
static int tps65941_ldo_val(struct udevice *dev, int op, int *uV)
{
unsigned int hex, adr;
- int ret;
+ int ret, idx;
struct dm_regulator_uclass_plat *uc_pdata;
+ const struct tps65941_reg_conv_ops *conv_ops;
+ idx = dev->driver_data;
+ conv_ops = _conv_ops[TPS65941_LDO_CONV_OPS_IDX];
uc_pdata = dev_get_uclass_plat(dev);
if (op == PMIC_OP_GET)
@@ -258,8 +293,8 @@ static int tps65941_ldo_val(struct udevice *dev, int op,
int *uV)
if (ret < 0)
return ret;
- ret &= TPS65941_LDO_VOLT_MASK;
- ret = tps65941_ldo_val2volt(ret);
+ ret &= conv_ops->volt_mask;
+ ret = conv_ops->val2volt(idx, ret);
if (ret <
[PATCH v3 2/5] power: pmic: tps65941: Add TI TPS65224 PMIC
Adds compatible and data field values of TPS65224 driver in
TPS65941 PMIC driver.
Signed-off-by: Bhargav Raviprakash
---
drivers/power/pmic/tps65941.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/pmic/tps65941.c b/drivers/power/pmic/tps65941.c
index 727b42747a..ef63eb733a 100644
--- a/drivers/power/pmic/tps65941.c
+++ b/drivers/power/pmic/tps65941.c
@@ -75,6 +75,7 @@ static const struct udevice_id tps65941_ids[] = {
{ .compatible = "ti,tps659412", .data = TPS659411 },
{ .compatible = "ti,tps659413", .data = TPS659413 },
{ .compatible = "ti,lp876441", .data = LP876441 },
+ { .compatible = "ti,tps65224", .data = TPS65224 },
{ }
};
--
2.25.1
[PATCH v3 1/5] power: tps65941: Add macros of TPS65224 PMIC
Re-use the TPS65941 PMIC driver for TPS65224 PMIC. Add additional macros of TPS65224 to aid in the driver re-use. Signed-off-by: Bhargav Raviprakash --- include/power/tps65941.h | 30 ++ 1 file changed, 30 insertions(+) diff --git a/include/power/tps65941.h b/include/power/tps65941.h index a2bc6814ba..cec85333f0 100644 --- a/include/power/tps65941.h +++ b/include/power/tps65941.h @@ -3,11 +3,14 @@ #define TPS659413 0x2 #define TPS659414 0x3 #define LP876441 0x4 +#define TPS65224 0x5 /* I2C device address for pmic tps65941 */ #define TPS65941_I2C_ADDR (0x12 >> 1) #define TPS65941_LDO_NUM 4 #define TPS65941_BUCK_NUM 5 +#define TPS65224_LDO_NUM 3 +#define TPS65224_BUCK_NUM 4 /* Drivers name */ #define TPS65941_LDO_DRIVER"tps65941_ldo" @@ -25,3 +28,30 @@ #define TPS65941_LDO_MODE_MASK 0x1 #define TPS65941_LDO_BYPASS_EN 0x80 #define TP65941_BUCK_CONF_SLEW_MASK0x7 + +#define TPS65224_BUCK_VOLT_MAX 330 +#define TPS65224_BUCK1_VOLT_MAX_HEX 0xFD +#define TPS65224_BUCK234_VOLT_MAX_HEX0x45 + +#define TPS65224_BUCK_CONF_SLEW_MASK 0x3 +#define TPS65224_LDO_VOLT_MASK(0x3F << 1) + +#define TPS65224_LDO1_VOLT_MIN_HEX 0x0C +#define TPS65224_LDO23_VOLT_MIN_HEX 0x00 +#define TPS65224_LDO1_VOLT_MAX_HEX 0x36 +#define TPS65224_LDO23_VOLT_MAX_HEX 0x38 + +#define TPS65224_LDO1_VOLT_MAX330 +#define TPS65224_LDO23_VOLT_MAX 340 +#define TPS65224_LDO1_VOLT_MIN120 +#define TPS65224_LDO23_VOLT_MIN60 + +#define TPS65224_LDO_STEP 5 + +#define TPS65224_LDO_BYP_CONFIG 7 + +#define TPS65224_LDO1_VOLT_BYP_MIN220 +#define TPS65224_LDO1_VOLT_BYP_MAX360 + +#define TPS65224_LDO23_VOLT_BYP_MIN 150 +#define TPS65224_LDO23_VOLT_BYP_MAX 550 -- 2.25.1
[PATCH v3 3/5] power: regulator: tps65941: Added macros for BUCK ID
Adds macros for buck and ldo ids and switched to using switch
case instead of if else in probe functions. Helps in adding
support for TPS65224 PMIC.
Signed-off-by: Bhargav Raviprakash
---
drivers/power/regulator/tps65941_regulator.c | 54 +++-
1 file changed, 42 insertions(+), 12 deletions(-)
diff --git a/drivers/power/regulator/tps65941_regulator.c
b/drivers/power/regulator/tps65941_regulator.c
index b041126775..cf54e30df5 100644
--- a/drivers/power/regulator/tps65941_regulator.c
+++ b/drivers/power/regulator/tps65941_regulator.c
@@ -16,6 +16,25 @@
#include
#include
+/* Single Phase Buck IDs */
+#define TPS65941_BUCK_ID_11
+#define TPS65941_BUCK_ID_22
+#define TPS65941_BUCK_ID_33
+#define TPS65941_BUCK_ID_44
+#define TPS65941_BUCK_ID_55
+
+/* Multi Phase Buck IDs */
+#define TPS65941_BUCK_ID_12 12
+#define TPS65941_BUCK_ID_34 34
+#define TPS65941_BUCK_ID_123123
+#define TPS65941_BUCK_ID_1234 1234
+
+/* LDO IDs */
+#define TPS65941_LDO_ID_1 1
+#define TPS65941_LDO_ID_2 2
+#define TPS65941_LDO_ID_3 3
+#define TPS65941_LDO_ID_4 4
+
static const char tps65941_buck_ctrl[TPS65941_BUCK_NUM] = {0x4, 0x6, 0x8, 0xA,
0xC};
static const char tps65941_buck_vout[TPS65941_BUCK_NUM] = {0xE, 0x10, 0x12,
@@ -270,10 +289,15 @@ static int tps65941_ldo_probe(struct udevice *dev)
uc_pdata->type = REGULATOR_TYPE_LDO;
idx = dev->driver_data;
- if (idx == 1 || idx == 2 || idx == 3 || idx == 4) {
+ switch (idx) {
+ case TPS65941_LDO_ID_1:
+ case TPS65941_LDO_ID_2:
+ case TPS65941_LDO_ID_3:
+ case TPS65941_LDO_ID_4:
debug("Single phase regulator\n");
- } else {
- printf("Wrong ID for regulator\n");
+ break;
+ default:
+ pr_err("Wrong ID for regulator\n");
return -EINVAL;
}
@@ -292,18 +316,24 @@ static int tps65941_buck_probe(struct udevice *dev)
uc_pdata->type = REGULATOR_TYPE_BUCK;
idx = dev->driver_data;
- if (idx == 1 || idx == 2 || idx == 3 || idx == 4 || idx == 5) {
+ switch (idx) {
+ case TPS65941_BUCK_ID_1:
+ case TPS65941_BUCK_ID_2:
+ case TPS65941_BUCK_ID_3:
+ case TPS65941_BUCK_ID_4:
+ case TPS65941_BUCK_ID_5:
debug("Single phase regulator\n");
- } else if (idx == 12) {
+ break;
+ case TPS65941_BUCK_ID_12:
+ case TPS65941_BUCK_ID_123:
+ case TPS65941_BUCK_ID_1234:
idx = 1;
- } else if (idx == 34) {
+ break;
+ case TPS65941_BUCK_ID_34:
idx = 3;
- } else if (idx == 123) {
- idx = 1;
- } else if (idx == 1234) {
- idx = 1;
- } else {
- printf("Wrong ID for regulator\n");
+ break;
+ default:
+ pr_err("Wrong ID for regulator\n");
return -EINVAL;
}
--
2.25.1
[PATCH v3 0/5] Add support for TI TPS65224 PMIC
TPS65224 is a Power Management IC which provides regulators and others features like GPIOs, RTC, watchdog, ADC, ESMs (Error Signal Monitor), and PFSM (Pre-configurable Finite State Machine). The SoC and the PMIC can communicate through the I2C. Data Sheet for TPS65224: https://www.ti.com/product/TPS65224-Q1 Reusing the TPS65941 PMIC driver to add support for TPS65224 PMIC in U-boot. This includes driver for PMIC and regulator. The driver was tested on Ti's custom AM62P EVM using U-boot's pmic list, regulator list, regulator status and regulator value commands. Since, support for Ti's AM62P is absent in u-boot next, the patches were applied on ti-u-boot ti-u-boot-2023.04-next and tested. Changelog v2 -> v3: - use pr_err instead of printf - comments added in ldo conversion functions Bhargav Raviprakash (5): power: tps65941: Add macros of TPS65224 PMIC power: pmic: tps65941: Add TI TPS65224 PMIC power: regulator: tps65941: Added macros for BUCK ID power: regulator: tps65941: use function callbacks for conversion ops power: regulator: tps65941: Add TPS65224 PMIC regulator support drivers/power/pmic/tps65941.c| 1 + drivers/power/regulator/tps65941_regulator.c | 381 +-- include/power/tps65941.h | 30 ++ 3 files changed, 381 insertions(+), 31 deletions(-) base-commit: 4b151562bb8e54160adedbc6a1c0c749c00a2f84 -- 2.25.1
RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
> Hi Alexander, > > I tested your work on sama7g54-curiosity board: > > U-Boot> nand info > > Device 0: nand0, sector size 256 KiB > Manufacturer MACRONIX > Model MX30LF4G28AD > Device size512 MiB > Page size 4096 b > OOB size 256 b > Erase size 262144 b > ecc strength 8 bits > ecc step size 512 b > subpagesize 4096 b > options 0x4200 > bbt options 0x00028000 > > U-Boot> hsmc decode > > mck clock rate: 2 > > HSMC_SETUP3:0x0001 > HSMC_PULSE3:0x07040804 > HSMC_CYCLE3:0x00070008 > HSMC_TIMINGS3: 0x880402f2 > HSMC_MODE3: 0x001f0003 > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns) >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 > (35 ns) > NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns) >NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8 > (40 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus > Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE > signal Read operation controlled by NRD signal > > Best regards, > Mihai Sain Hello Mihai, If you have any suggestions for improvement, changes, or you are happy with this command, is it useful ? You can provide your Tested-by then if you consider this is useful Eugen -- Hello Eugen, Yes. The command is very useful. I would like to have also the ONFI timing mode printed for nand-flash Also I recommend to print the master clock in MHz, and to print the master clock name/label from ccf driver: https://github.com/u-boot/u-boot/blob/master/drivers/clk/at91/sama7g5.c#L410 Tested-by: Mihai Sain Best regards, Mihai Sain
Re: [PATCH] arm: mach-k3: Fix config check for FS_LOADER
On 3/14/24 8:03 PM, MD Danish Anwar wrote: > load_firmware() API calls fs-loader APIs and checks for CONFIG_FS_LOADER > before calling those APIs. The if check only checks for CONFIG_FS_LOADER > but not for CONFIG_SPL_FS_LOADER. > > When CONFIG_FS_LOADER is enabled, load_firmware() API calls fs-loader APIs > but this is done at SPL stage and at this time FS_LOADER is not built yet > as a result we see below build error. > > AR spl/boot/built-in.o > LD spl/u-boot-spl > arm-none-linux-gnueabihf-ld.bfd: arch/arm/mach-k3/common.o: in function > `load_firmware': > /home/danish/workspace/u-boot/arch/arm/mach-k3/common.c:184: undefined > reference to `get_fs_loader' > arm-none-linux-gnueabihf-ld.bfd: > /home/danish/workspace/u-boot/arch/arm/mach-k3/common.c:185: undefined > reference to `request_firmware_into_buf' > make[2]: *** [/home/danish/workspace/u-boot/scripts/Makefile.spl:527: > spl/u-boot-spl] Error 1 > make[1]: *** [/home/danish/workspace/u-boot/Makefile:2055: > spl/u-boot-spl] Error 2 > make[1]: Leaving directory '/home/danish/uboot_images/am64x/r5' > make: *** [Makefile:177: sub-make] Error 2 > > Fix this by modifying the if check to CONFIG_IS_ENABLED(FS_LOADER) instead > of IS_ENABLED(CONFIG_FS_LOADER) as the former will check for the > appropriate config option (CONFIG_SPL_FS_LOADER / CONFIG_FS_LOADER) based > on the build stage. > > Signed-off-by: MD Danish Anwar > --- > arch/arm/mach-k3/r5/common.c | 2 +- > arch/arm/mach-omap2/boot-common.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c > index 7309573a3f..c02f8d3309 100644 > --- a/arch/arm/mach-k3/r5/common.c > +++ b/arch/arm/mach-k3/r5/common.c > @@ -70,7 +70,7 @@ int load_firmware(char *name_fw, char *name_loadaddr, u32 > *loadaddr) > char *name = NULL; > int size = 0; > > - if (!IS_ENABLED(CONFIG_FS_LOADER)) > + if (!CONFIG_IS_ENABLED(FS_LOADER)) > return 0; > > *loadaddr = 0; > diff --git a/arch/arm/mach-omap2/boot-common.c > b/arch/arm/mach-omap2/boot-common.c > index 57917da25c..aa0ab13d5f 100644 > --- a/arch/arm/mach-omap2/boot-common.c > +++ b/arch/arm/mach-omap2/boot-common.c > @@ -190,7 +190,7 @@ int load_firmware(char *name_fw, u32 *loadaddr) > struct udevice *fsdev; > int size = 0; > > - if (!IS_ENABLED(CONFIG_FS_LOADER)) > + if (!CONFIG_IS_ENABLED(FS_LOADER)) > return 0; > > if (!*loadaddr) Acked-by: Ravi Gunasekaran -- Regards, Ravi
RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
> U-Boot> nand info
>
> Device 0: nand0, sector size 256 KiB
> Manufacturer MACRONIX
> Model MX30LF4G28AD
> Device size512 MiB
> Page size 4096 b
> OOB size 256 b
> Erase size 262144 b
> ecc strength 8 bits
> ecc step size 512 b
> subpagesize 4096 b
> options 0x4200
> bbt options 0x00028000
This seems to be the same NAND chip as on the sam9x60 curiosity, but your
output has three additional lines, see mine:
Do you have some additional patches printing manufacturer, model, and device
size? I can't see those lines printed in
nand_print_and_set_info() here.
Yes. I have
+ printf(" Manufacturer %s \n", chip->onfi_params.manufacturer);
+ printf(" Model %s \n", chip->onfi_params.model);
+ printf(" Device size %8d MiB\n", (int)(chip->chipsize >> 20));
> U-Boot> hsmc decode
>
> mck clock rate: 2
>
> HSMC_SETUP3:0x0001
> HSMC_PULSE3:0x07040804
> HSMC_CYCLE3:0x00070008
> HSMC_TIMINGS3: 0x880402f2
> HSMC_MODE3: 0x001f0003
> NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
>NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7
> (35 ns)
> NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns)
>NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8
> (40 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus
> Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE
> signal Read operation controlled by NRD signal
This is also interesting. Given the mck clock rate is the same as on sam9x60,
I would have guessed the timings set by
atmel_smc_nand_prepare_smcconf() should give the same results, both for ONFI
timiming mode 3, which is the fastest mode the (H)SMC supports according to
comments in the driver. This is the output with the patch in question applied
on next for sam9x60:
U-Boot> hsmc decode
mck clock rate: 2
SMC_SETUP3: 0x0002
SMC_PULSE3: 0x06030703
SMC_CYCLE3: 0x00060007
SMC_MODE3: 0x001f0003
NCS_RD: setup: 0 (0 ns), pulse: 6 (30 ns), hold: 0 (0 ns), cycle: 6 (30 ns)
NRD: setup: 0 (0 ns), pulse: 3 (15 ns), hold: 3 (15 ns), cycle: 6 (30 ns)
NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns)
NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 (35
ns)
Standard read is applied.
TDF optimization enabled
TDF cycles: 15 (75 ns)
Data Bus Width: 8-bit bus
NWAIT Mode: 0
Write operation controlled by NWE signal
Read operation controlled by NRD signal
Notice the pulse times for read are one clock cycle smaller than in your
output, and the timings for write are also different. Do you have changes for
atmel_smc_nand_prepare_smcconf() applied which are not upstream yet? Or is the
HSMC on sama7g54 somehow different than on older SoCs?
Yes. I force timing mode 2 in nand-controller.c:
+ if (conf->timings.sdr.tRC_min < 30001) // force timing mode 2, 35ns for
read/write cycle
This will pass the nand torture test
U-Boot> nand torture 0x80 0x100
NAND torture: device 0 offset 0x80 size 0x100 (block size 0x4)
Passed: 64, failed: 0
Note: I'm currently testing a patch changing the computation of the read pulse
cycles based on a patch for at91bootstrap [1], but that is not applied here for
the output quoted above.
Greets
Alex
[1]
https://github.com/linux4sam/at91bootstrap/issues/174#issuecomment-1970698527
>
> Best regards,
> Mihai Sain
Re: [PATCH 3/3] configs: amlogic: set board family to avoid random MAC on WeTek Hub/Play2
Hi, On 16/03/2024 14:54, Christian Hewitt wrote: Add CONFIG_SYS_BOARD="p200" to the Hub/Play2 board configs to ensure the factory programmed MAC is correctly read from efuse. Signed-off-by: Christian Hewitt --- configs/wetek-hub_defconfig | 1 + configs/wetek-play2_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/wetek-hub_defconfig b/configs/wetek-hub_defconfig index fd92b041e73..413bbfe9ab7 100644 --- a/configs/wetek-hub_defconfig +++ b/configs/wetek-hub_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_MESON=y +CONFIG_SYS_BOARD="p200" CONFIG_TEXT_BASE=0x0100 CONFIG_NR_DRAM_BANKS=1 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/wetek-play2_defconfig b/configs/wetek-play2_defconfig index b887419a6ba..dd98929444c 100644 --- a/configs/wetek-play2_defconfig +++ b/configs/wetek-play2_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_MESON=y +CONFIG_SYS_BOARD="p200" CONFIG_TEXT_BASE=0x0100 CONFIG_NR_DRAM_BANKS=1 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_SYS_BOARD="p200" is already the default value for MESON_GXBB, see arch/arm/mach-meson/Kconfig Neil
Re: [PATCH 2/3] ARM: board: meson: update efuse MAC reading code
Hi,
On 16/03/2024 14:54, Christian Hewitt wrote:
Current code used for reading the factory programmed MAC from efuse on
p200 boards does not appear to work resulting in a random MAC being
generated. Update the p200 board data reusing the function from the VIM3
source.
I'm pretty sure this code works on the Odroid-C2, but hardkernel had a custom
way to store the mac address so perhaps you should move this code to an
odroid-c2
board file first ?
Or try both methods ? if first method doesn't give a valid mac address
try the ASCII format.
Neil
Signed-off-by: Christian Hewitt
---
board/amlogic/p200/p200.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/board/amlogic/p200/p200.c b/board/amlogic/p200/p200.c
index 7c432f9d281..fb07eefa532 100644
--- a/board/amlogic/p200/p200.c
+++ b/board/amlogic/p200/p200.c
@@ -14,29 +14,36 @@
#include
#include
-#define EFUSE_SN_OFFSET 20
-#define EFUSE_SN_SIZE 16
-#define EFUSE_MAC_OFFSET 52
-#define EFUSE_MAC_SIZE 6
+#define EFUSE_MAC_OFFSET 0
+#define EFUSE_MAC_SIZE 12
+#define MAC_ADDR_LEN 6
int misc_init_r(void)
{
- u8 mac_addr[EFUSE_MAC_SIZE];
- char serial[EFUSE_SN_SIZE];
+ u8 mac_addr[MAC_ADDR_LEN];
+ char efuse_mac_addr[EFUSE_MAC_SIZE], tmp[3];
ssize_t len;
if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
len = meson_sm_read_efuse(EFUSE_MAC_OFFSET,
- mac_addr, EFUSE_MAC_SIZE);
- if (len == EFUSE_MAC_SIZE && is_valid_ethaddr(mac_addr))
+ efuse_mac_addr, EFUSE_MAC_SIZE);
+ if (len != EFUSE_MAC_SIZE)
+ return 0;
+
+ /* MAC is stored in ASCII format, 1bytes = 2characters */
+ for (int i = 0; i < 6; i++) {
+ tmp[0] = efuse_mac_addr[i * 2];
+ tmp[1] = efuse_mac_addr[i * 2 + 1];
+ tmp[2] = '\0';
+ mac_addr[i] = simple_strtoul(tmp, NULL, 16);
+ }
+
+ if (is_valid_ethaddr(mac_addr))
eth_env_set_enetaddr("ethaddr", mac_addr);
- }
+ else
+ meson_generate_serial_ethaddr();
- if (!env_get("serial#")) {
- len = meson_sm_read_efuse(EFUSE_SN_OFFSET, serial,
- EFUSE_SN_SIZE);
- if (len == EFUSE_SN_SIZE)
- env_set("serial#", serial);
+ eth_env_get_enetaddr("ethaddr", mac_addr);
}
return 0;
Re: [PATCH v2] net: phy: Factor out PHY GPIO reset code
On 3/17/24 04:11, Marek Vasut wrote:
Pull the PHY GPIO reset code into separate function, since
this is and will be reused multiple times. Set up default
reset assert and deassert timing to generous 20ms and 1ms
for maximum compatibility in case those DT properties are
missing.
Reviewed-by: Ramon Fried
Signed-off-by: Marek Vasut
---
Cc: Joe Hershberger
Cc: Michal Simek
Cc: Nishanth Menon
Cc: Ramon Fried
---
V2: - Fix am335x_evm build with OF_REAL disabled
- Collect RB from Ramon
---
drivers/net/phy/ethernet_id.c | 37 +++---
drivers/net/phy/phy.c | 58 +++
include/phy.h | 9 ++
3 files changed, 72 insertions(+), 32 deletions(-)
diff --git a/drivers/net/phy/ethernet_id.c b/drivers/net/phy/ethernet_id.c
index 6cb1fd4453e..4dfdee60dcc 100644
--- a/drivers/net/phy/ethernet_id.c
+++ b/drivers/net/phy/ethernet_id.c
@@ -18,12 +18,11 @@ struct phy_device *phy_connect_phy_id(struct mii_dev *bus,
struct udevice *dev,
{
struct phy_device *phydev;
struct ofnode_phandle_args phandle_args;
- struct gpio_desc gpio;
const char *node_name;
struct udevice *pdev;
- ofnode node;
- u32 id, assert, deassert;
u16 vendor, device;
+ ofnode node;
+ u32 id;
int ret;
if (dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
@@ -41,35 +40,9 @@ struct phy_device *phy_connect_phy_id(struct mii_dev *bus,
struct udevice *dev,
return NULL;
}
- if (!IS_ENABLED(CONFIG_DM_ETH_PHY)) {
- ret = gpio_request_by_name_nodev(node, "reset-gpios", 0, ,
-GPIOD_IS_OUT |
GPIOD_ACTIVE_LOW);
- if (!ret) {
- assert = ofnode_read_u32_default(node,
-"reset-assert-us", 0);
- deassert = ofnode_read_u32_default(node,
- "reset-deassert-us",
- 0);
- ret = dm_gpio_set_value(, 1);
- if (ret) {
- dev_err(dev,
- "Failed assert gpio, err: %d\n", ret);
- return NULL;
- }
-
- udelay(assert);
-
- ret = dm_gpio_set_value(, 0);
- if (ret) {
- dev_err(dev,
- "Failed deassert gpio, err: %d\n",
- ret);
- return NULL;
- }
-
- udelay(deassert);
- }
- }
+ ret = phy_gpio_reset(dev);
+ if (ret)
+ return NULL;
if (phyaddr == -1)
phyaddr = ofnode_read_u32_default(phandle_args.node, "reg", -1);
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 63b3e46f101..9ceb7d7c6a1 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -768,6 +770,62 @@ int miiphy_reset(const char *devname, unsigned char addr)
return phy_reset(phydev);
}
+#if CONFIG_IS_ENABLED(DM_GPIO) && CONFIG_IS_ENABLED(OF_REAL) && \
+!IS_ENABLED(CONFIG_DM_ETH_PHY)
+int phy_gpio_reset(struct udevice *dev)
+{
+ struct ofnode_phandle_args phandle_args;
+ struct gpio_desc gpio;
+ u32 assert, deassert;
+ ofnode node;
+ int ret;
+
+ if (IS_ENABLED(CONFIG_DM_ETH_PHY))
+ return 0;
Trying to wrap my head around this condition. Above you have
!IS_ENABLED(CONFIG_DM_ETH_PHY) and here IS_ENABLED(CONFIG_DM_ETH_PHY).
Thanks,
Michal
Re: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
Hello Mihai, Am Mon, Mar 18, 2024 at 08:09:00AM + schrieb mihai.s...@microchip.com: > On 3/7/24 11:10, Alexander Dahl wrote: > > For now adds one new command 'hsmc' with a single subcommand 'decode' > > to read and display the content of the registers of the Static Memory > > Controllers (SMC/HSMC) found in different at91 SoCs. Needed to get a > > better picture on what raw nand core and atmel nand controller driver > > try to set as timings based on ONFI parameters of the connected NAND > > chip. > > > > Tested on SAMA5D2 and SAM9X60 based boards. Example output: > > > > U-Boot> hsmc decode > > > > mck clock rate: 2 > > > > SMC_SETUP3: 0x0002 > > SMC_PULSE3: 0x07040703 > > SMC_CYCLE3: 0x00070007 > > SMC_MODE3: 0x001f0003 > > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 > > ns) > >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 > > (35 ns) > > NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 > > ns) > >NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 > > (35 ns) > > Standard read is applied. > > TDF optimization enabled > > TDF cycles: 15 (75 ns) > > Data Bus Width: 8-bit bus > > NWAIT Mode: 0 > > Write operation controlled by NWE signal > > Read operation controlled by NRD signal > > Adding Mihai as he is usually very interested in such debug information and > methods. > > - > > Hi Alexander, > > I tested your work on sama7g54-curiosity board: nice, thanks for that. > U-Boot> nand info > > Device 0: nand0, sector size 256 KiB > Manufacturer MACRONIX > Model MX30LF4G28AD > Device size512 MiB > Page size 4096 b > OOB size 256 b > Erase size 262144 b > ecc strength 8 bits > ecc step size 512 b > subpagesize 4096 b > options 0x4200 > bbt options 0x00028000 This seems to be the same NAND chip as on the sam9x60 curiosity, but your output has three additional lines, see mine: U-Boot> nand info Device 0: nand0, sector size 256 KiB Page size 4096 b OOB size 256 b Erase size 262144 b ecc strength 8 bits ecc step size 512 b subpagesize 4096 b options 0x40004200 bbt options 0x00028000 Do you have some additional patches printing manufacturer, model, and device size? I can't see those lines printed in nand_print_and_set_info() here. > U-Boot> hsmc decode > > mck clock rate: 2 > > HSMC_SETUP3:0x0001 > HSMC_PULSE3:0x07040804 > HSMC_CYCLE3:0x00070008 > HSMC_TIMINGS3: 0x880402f2 > HSMC_MODE3: 0x001f0003 > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns) >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 ns) > NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns) >NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8 (40 ns) > TDF optimization enabled > TDF cycles: 15 (75 ns) > Data Bus Width: 8-bit bus > NWAIT Mode: 0 > Write operation controlled by NWE signal > Read operation controlled by NRD signal This is also interesting. Given the mck clock rate is the same as on sam9x60, I would have guessed the timings set by atmel_smc_nand_prepare_smcconf() should give the same results, both for ONFI timiming mode 3, which is the fastest mode the (H)SMC supports according to comments in the driver. This is the output with the patch in question applied on next for sam9x60: U-Boot> hsmc decode mck clock rate: 2 SMC_SETUP3: 0x0002 SMC_PULSE3: 0x06030703 SMC_CYCLE3: 0x00060007 SMC_MODE3: 0x001f0003 NCS_RD: setup: 0 (0 ns), pulse: 6 (30 ns), hold: 0 (0 ns), cycle: 6 (30 ns) NRD: setup: 0 (0 ns), pulse: 3 (15 ns), hold: 3 (15 ns), cycle: 6 (30 ns) NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns) NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 (35 ns) Standard read is applied. TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE signal Read operation controlled by NRD signal Notice the pulse times for read are one clock cycle smaller than in your output, and the timings for write are also different. Do you have changes for atmel_smc_nand_prepare_smcconf() applied which are not upstream yet? Or is the HSMC on sama7g54 somehow different than on older SoCs? Note: I'm currently testing a patch changing the computation of the read pulse cycles based on a patch for at91bootstrap [1], but that is not applied here for the output quoted above. Greets Alex [1]
Re: [PATCH 1/3] ARM: dts: fix Ethernet on WeTek Hub/Play2
On 16/03/2024 14:54, Christian Hewitt wrote:
Placing the snps,reset content needed for Ethernet to probe in a common
uboot.dtsi results in the content not being used and broken Ethernet. Fix
this by creating two board specific dtsi files with the right content.
Fixes: 67d5128df950 ("ARM: dts: add support for WeTek Hub and WeTek Play2")
Signed-off-by: Christian Hewitt
---
...u-boot.dtsi => meson-gxbb-wetek-hub-u-boot.dtsi} | 0
arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi | 13 +
2 files changed, 13 insertions(+)
rename arch/arm/dts/{meson-gxbb-wetek-u-boot.dtsi =>
meson-gxbb-wetek-hub-u-boot.dtsi} (100%)
create mode 100644 arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi
diff --git a/arch/arm/dts/meson-gxbb-wetek-u-boot.dtsi
b/arch/arm/dts/meson-gxbb-wetek-hub-u-boot.dtsi
similarity index 100%
rename from arch/arm/dts/meson-gxbb-wetek-u-boot.dtsi
rename to arch/arm/dts/meson-gxbb-wetek-hub-u-boot.dtsi
diff --git a/arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi
b/arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi
new file mode 100644
index 000..3743053eb9c
--- /dev/null
+++ b/arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong
+ */
+
+#include "meson-gx-u-boot.dtsi"
+
+ {
+ snps,reset-gpio = < GPIOZ_14 0>;
+ snps,reset-delays-us = <0 1 100>;
+ snps,reset-active-low;
+};
Reviewed-by: Neil Armstrong
Re: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
On 3/18/24 10:09, mihai.s...@microchip.com wrote: > On 3/7/24 11:10, Alexander Dahl wrote: >> For now adds one new command 'hsmc' with a single subcommand 'decode' >> to read and display the content of the registers of the Static Memory >> Controllers (SMC/HSMC) found in different at91 SoCs. Needed to get a >> better picture on what raw nand core and atmel nand controller driver >> try to set as timings based on ONFI parameters of the connected NAND >> chip. >> >> Tested on SAMA5D2 and SAM9X60 based boards. Example output: >> >> U-Boot> hsmc decode >> >> mck clock rate: 2 >> >> SMC_SETUP3: 0x0002 >> SMC_PULSE3: 0x07040703 >> SMC_CYCLE3: 0x00070007 >> SMC_MODE3: 0x001f0003 >> NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 >> ns) >>NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 >> ns) >> NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 >> ns) >>NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 >> (35 ns) >> Standard read is applied. >> TDF optimization enabled >> TDF cycles: 15 (75 ns) >> Data Bus Width: 8-bit bus >> NWAIT Mode: 0 >> Write operation controlled by NWE signal >> Read operation controlled by NRD signal > > Adding Mihai as he is usually very interested in such debug information and > methods. > > - > > Hi Alexander, > > I tested your work on sama7g54-curiosity board: > > U-Boot> nand info > > Device 0: nand0, sector size 256 KiB > Manufacturer MACRONIX > Model MX30LF4G28AD > Device size512 MiB > Page size 4096 b > OOB size 256 b > Erase size 262144 b > ecc strength 8 bits > ecc step size 512 b > subpagesize 4096 b > options 0x4200 > bbt options 0x00028000 > > U-Boot> hsmc decode > > mck clock rate: 2 > > HSMC_SETUP3:0x0001 > HSMC_PULSE3:0x07040804 > HSMC_CYCLE3:0x00070008 > HSMC_TIMINGS3: 0x880402f2 > HSMC_MODE3: 0x001f0003 > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns) >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 ns) > NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns) >NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8 (40 ns) > TDF optimization enabled > TDF cycles: 15 (75 ns) > Data Bus Width: 8-bit bus > NWAIT Mode: 0 > Write operation controlled by NWE signal > Read operation controlled by NRD signal > > Best regards, > Mihai Sain Hello Mihai, If you have any suggestions for improvement, changes, or you are happy with this command, is it useful ? You can provide your Tested-by then if you consider this is useful Eugen
Re: [PATCH 1/1] xilinx: zynq: add FDT_FIXUP_PARTITIONS support
On 3/15/24 20:25, James Hilliard wrote:
There are situations where we may want to let U-Boot modify the FDT
please use imperative mood.
nand partitions for the kernel, such as when supporting multiple
sizes of NAND chips.
Lets also refactor xilinx common board support to have a
ft_common_board_setup which gets called by the ft_board_setup for each
specific board so that we can add non-common functionality to each
ft_board_setup like FDT_FIXUP_PARTITIONS as needed.
This pattern is modeled after the one used by tdx-common.c.
Signed-off-by: James Hilliard
---
board/xilinx/common/board.c | 2 +-
board/xilinx/common/board.h | 2 ++
board/xilinx/mbv/board.c| 9 +
board/xilinx/versal-net/board.c | 7 +++
board/xilinx/versal/board.c | 7 +++
board/xilinx/zynq/board.c | 17 +
board/xilinx/zynqmp/zynqmp.c| 7 +++
board/xilinx/zynqmp_r5/board.c | 8
8 files changed, 58 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 9641ed307b..629ba2b902 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -686,7 +686,7 @@ phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
#ifdef CONFIG_OF_BOARD_SETUP
#define MAX_RAND_SIZE 8
-int ft_board_setup(void *blob, struct bd_info *bd)
+int ft_common_board_setup(void *blob, struct bd_info *bd)
{
size_t n = MAX_RAND_SIZE;
struct udevice *dev;
diff --git a/board/xilinx/common/board.h b/board/xilinx/common/board.h
index 64d657673e..73f576952a 100644
--- a/board/xilinx/common/board.h
+++ b/board/xilinx/common/board.h
@@ -18,4 +18,6 @@ bool board_detection(void);
char *soc_name_decode(void);
bool soc_detection(void);
+
+int ft_common_board_setup(void *blob, struct bd_info *bd);
#endif /* BOARD_XILINX_COMMON_BOARD_H */
diff --git a/board/xilinx/mbv/board.c b/board/xilinx/mbv/board.c
index ccf4395d6a..d8af1eaa90 100644
--- a/board/xilinx/mbv/board.c
+++ b/board/xilinx/mbv/board.c
@@ -5,7 +5,16 @@
* Michal Simek
*/
+#include "../common/board.h"
+
int board_init(void)
{
return 0;
}
+
+#ifdef CONFIG_OF_BOARD_SETUP
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ return ft_common_board_setup(blob, bd);
+}
+#endif
Any reason not to put directly to board/xilinx/common/board.c?
All xilinx boards are kept in sync from user perspective that's why generic
pieces should be added to common location.
diff --git a/board/xilinx/versal-net/board.c b/board/xilinx/versal-net/board.c
index 990ca1650a..bd674e6739 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -371,3 +371,10 @@ int dram_init(void)
void reset_cpu(void)
{
}
+
+#ifdef CONFIG_OF_BOARD_SETUP
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ return ft_common_board_setup(blob, bd);
+}
+#endif
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index 8c2e614ad8..944ef2d822 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -320,3 +320,10 @@ enum env_location env_get_location(enum env_operation op,
int prio)
return ENVL_NOWHERE;
}
}
+
+#ifdef CONFIG_OF_BOARD_SETUP
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ return ft_common_board_setup(blob, bd);
+}
+#endif
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 6c36591001..1ca1984c49 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -13,10 +13,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -201,3 +203,18 @@ void set_dfu_alt_info(char *interface, char *devstr)
puts("DFU alt info setting: done\n");
}
#endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_FDT_FIXUP_PARTITIONS
+ static const struct node_info nodes[] = {
+ { "arm,pl353-nand-r2p1", MTD_DEV_TYPE_NAND, },
Very likely also depends on CONFIG_NAND_ZYNQ. It means pretty much you can move
this code directly to common/board.c because only Zynq uses this symbol.
Thanks,
Michal
RE: [PATCH 4/4] mtd: nand: raw: atmel: Introduce optional debug commands
On 3/7/24 11:10, Alexander Dahl wrote: > For now adds one new command 'hsmc' with a single subcommand 'decode' > to read and display the content of the registers of the Static Memory > Controllers (SMC/HSMC) found in different at91 SoCs. Needed to get a > better picture on what raw nand core and atmel nand controller driver > try to set as timings based on ONFI parameters of the connected NAND > chip. > > Tested on SAMA5D2 and SAM9X60 based boards. Example output: > > U-Boot> hsmc decode > > mck clock rate: 2 > > SMC_SETUP3: 0x0002 > SMC_PULSE3: 0x07040703 > SMC_CYCLE3: 0x00070007 > SMC_MODE3: 0x001f0003 > NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 > ns) >NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 > ns) > NCS_WR: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 > ns) >NWE: setup: 2 (10 ns), pulse: 3 (15 ns), hold: 2 (10 ns), cycle: 7 (35 > ns) > Standard read is applied. > TDF optimization enabled > TDF cycles: 15 (75 ns) > Data Bus Width: 8-bit bus > NWAIT Mode: 0 > Write operation controlled by NWE signal > Read operation controlled by NRD signal Adding Mihai as he is usually very interested in such debug information and methods. - Hi Alexander, I tested your work on sama7g54-curiosity board: U-Boot> nand info Device 0: nand0, sector size 256 KiB Manufacturer MACRONIX Model MX30LF4G28AD Device size512 MiB Page size 4096 b OOB size 256 b Erase size 262144 b ecc strength 8 bits ecc step size 512 b subpagesize 4096 b options 0x4200 bbt options 0x00028000 U-Boot> hsmc decode mck clock rate: 2 HSMC_SETUP3:0x0001 HSMC_PULSE3:0x07040804 HSMC_CYCLE3:0x00070008 HSMC_TIMINGS3: 0x880402f2 HSMC_MODE3: 0x001f0003 NCS_RD: setup: 0 (0 ns), pulse: 7 (35 ns), hold: 0 (0 ns), cycle: 7 (35 ns) NRD: setup: 0 (0 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 7 (35 ns) NCS_WR: setup: 0 (0 ns), pulse: 8 (40 ns), hold: 0 (0 ns), cycle: 8 (40 ns) NWE: setup: 1 (5 ns), pulse: 4 (20 ns), hold: 3 (15 ns), cycle: 8 (40 ns) TDF optimization enabled TDF cycles: 15 (75 ns) Data Bus Width: 8-bit bus NWAIT Mode: 0 Write operation controlled by NWE signal Read operation controlled by NRD signal Best regards, Mihai Sain
Re: [PATCH v2 4/6] usb: Add environment based device blocklist
Hej, On Sun, Mar 17, 2024, at 22:39, E Shattow wrote: > Should be usb_denylist, since "block devices" is ambiguous meaning if > it is a list of data chunks (blocks) or if it blocks (deny). There is > no question what a denylist is. I briefly thought of that concluded that the spelling "blocklist" removed the ambiguity. I not sure about "denylist". It sounds weird to me in the context of probing USB devices. I'd rather use "ignorelist" as alternative. Janne
Re: [PATCH v2 4/6] usb: Add environment based device blocklist
On Mon, Mar 18, 2024, at 06:06, Marek Vasut wrote:
> On 3/17/24 7:15 PM, Janne Grunau wrote:
>> Hej,
>
> Hi,
>
>> On Sun, Mar 17, 2024, at 17:18, Marek Vasut wrote:
>>> On 3/17/24 12:07 PM, Janne Grunau via B4 Relay wrote:
From: Janne Grunau
Add the environment variable "usb_blocklist" to prevent USB devices
listed in it from being used. This allows to ignore devices which
trigger bugs in u-boot's USB stack or are undesirable for other reasons.
Devices emulating keyboards are one example. U-boot currently supports
only one USB keyboard device. Most commonly, people run into this with
Yubikeys, so let's ignore those in the default environment.
Based on previous USB keyboard specific patches for the same purpose.
Link:
https://lore.kernel.org/u-boot/7ab604fb-0fec-4f5e-8708-7a3a7e2cb...@denx.de/
Signed-off-by: Janne Grunau
---
common/usb.c | 56
+++
doc/usage/environment.rst | 12 ++
include/env_default.h | 11 ++
3 files changed, 79 insertions(+)
diff --git a/common/usb.c b/common/usb.c
index 836506dcd9..73af5be066 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -1084,6 +1084,57 @@ static int usb_prepare_device(struct usb_device
*dev, int addr, bool do_read,
return 0;
}
+static int usb_blocklist_parse_error(const char *blocklist, size_t pos)
+{
+ printf("usb_blocklist parse error at char %zu in \"%s\"\n", pos,
+ blocklist);
+ return 0;
>>>
>>> This could be static void without return 0 at the end.
>>
>> the return is there to break out of the while loop on parsing errors in a
>> single statement. This probably won't be necessary after using strsep and
>> sscanf in the parsing function but see below.
>
> Ahh, now I see it. But then, shouldn't this return -ENODEV here already ?
It returns 0 so that parsing errors in the blocklist do not result
in blocking every USB device. That looked to me like the
less bad error behavior to me.
+}
+
+static int usb_device_is_blocked(u16 id_vendor, u16 id_product)
+{
+ ulong vid, pid;
+ char *end;
+ const char *block_str = env_get("usb_blocklist");
+ const char *cur = block_str;
+
+ /* parse "usb_blocklist" strictly */
+ while (cur && cur[0] != '\0') {
>>>
>>> Have a look at strsep() , namely strsep(block_str, ","); This will split
>>> the string up for you at "," delimiters.
>>>
>>> Example is in drivers/dfu/dfu.c dfu_config_interfaces() .
>>
>> strsep() is probably a good idea even if it alone won't make the code that
>> much simpler for strict parsing.
>>
>>> And then, on each token, you can try and run sscanf(token, "%04x:%04x",
>>> vid, pid);, that will parse the token format for you. See e.g.
>>> test/lib/sscanf.c for further examples.
>>>
>>> That should simplify the parsing a lot.
>>
>> It would but sscanf() is optional and is only selected by CONFIG_XEN so I
>> assumed there would be concerns over binary size increase if USB_HOST would
>> require sscanf.
>
> Good point, lets postpone sscanf() . Also, looking at it, sscanf would
> work for numbers, but not for the special characters. So ... do you want
> to try tweaking this further with strsep() or shall we go with this
> implementation ?
I started converting it to strsep. It makes the intent clearer but it doesn't
simplify the implementation much. strsep() has the disadvantage that
it can't work in place and needs to copy the string. If we go with strsep
I would look into parsing the list once at USB init time and use a list of
numeric vendor, product ID pairs at device probe time.
If have a slight preference for the current implementation (with ignore
or deny instead of blocklist) as long as the list remains short.
Janne
Pull Request: SoCFPGA changes for efi-2024-04-rc5
Dear Tom, Please pull the SoCFPGA changes for master from u-boot-socfpga, thanks. Best regards, Tien Fong The following changes since commit 86fd291a7990af84e96808f48eff2219dd4ef496: Merge tag 'efi-2024-04-rc5' of https://source.denx.de/u-boot/custodians/u-boot-efi (2024-03-13 20:39:46 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-socfpga.git 386fca68960994ece0d9da8a69a14495b5f1aedf for you to fetch changes up to 386fca68960994ece0d9da8a69a14495b5f1aedf: arch: arm: Agilex5 enablement (2024-03-18 14:45:47 +0800) Jit Loon Lim (1): arch: arm: Agilex5 enablement Wan Yee Lau (1): drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGA arch/arm/Kconfig | 6 +- arch/arm/dts/Makefile | 1 + arch/arm/dts/socfpga_agilex5-u-boot.dtsi | 71 +++ arch/arm/dts/socfpga_agilex5.dtsi | 575 +++ arch/arm/dts/socfpga_agilex5_socdk-u-boot.dtsi | 124 +++ arch/arm/dts/socfpga_agilex5_socdk.dts | 163 +++ arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi | 38 ++-- arch/arm/mach-socfpga/Kconfig | 19 +- arch/arm/mach-socfpga/Makefile | 14 +- arch/arm/mach-socfpga/board.c | 56 - arch/arm/mach-socfpga/clock_manager_agilex5.c | 89 arch/arm/mach-socfpga/include/mach/base_addr_soc64.h | 38 +++- arch/arm/mach-socfpga/include/mach/clock_manager.h | 4 +- arch/arm/mach-socfpga/include/mach/clock_manager_agilex5.h | 12 ++ arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 25 ++- arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 1 + arch/arm/mach-socfpga/mmu-arm64_s10.c | 59 +- arch/arm/mach-socfpga/wrap_handoff_soc64.c | 1 - board/intel/agilex5-socdk/MAINTAINERS | 8 + configs/socfpga_agilex5_defconfig | 116 +++ doc/device-tree-bindings/misc/socfpga_dtreg.txt| 80 +++ drivers/clk/altera/Makefile| 1 + drivers/clk/altera/clk-agilex5.c | 745 ++ drivers/clk/altera/clk-agilex5.h | 284 + drivers/misc/Kconfig | 7 + drivers/misc/Makefile | 1 + drivers/misc/socfpga_dtreg.c | 115 +++ include/configs/socfpga_agilex5_socdk.h| 12 ++ include/configs/socfpga_soc64_common.h | 143 - include/dt-bindings/clock/agilex5-clock.h | 71 +++ include/dt-bindings/reset/altr,rst-mgr-agx5.h | 80 +++ 31 files changed, 2922 insertions(+), 37 deletions(-) create mode 100644 arch/arm/dts/socfpga_agilex5-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_agilex5.dtsi create mode 100644 arch/arm/dts/socfpga_agilex5_socdk-u-boot.dtsi create mode 100644 arch/arm/dts/socfpga_agilex5_socdk.dts create mode 100644 arch/arm/mach-socfpga/clock_manager_agilex5.c create mode 100644 arch/arm/mach-socfpga/include/mach/clock_manager_agilex5.h create mode 100644 board/intel/agilex5-socdk/MAINTAINERS create mode 100644 configs/socfpga_agilex5_defconfig create mode 100644 doc/device-tree-bindings/misc/socfpga_dtreg.txt create mode 100644 drivers/clk/altera/clk-agilex5.c create mode 100644 drivers/clk/altera/clk-agilex5.h create mode 100644 drivers/misc/socfpga_dtreg.c create mode 100644 include/configs/socfpga_agilex5_socdk.h create mode 100644 include/dt-bindings/clock/agilex5-clock.h create mode 100644 include/dt-bindings/reset/altr,rst-mgr-agx5.h
