Re: [PATCH v2 2/3] include: configs: j721s2_evm: Change to using .env
Hi Neha,
Thanks for the patch.
On 15/03/23 10:57, Neha Malcom Francis wrote:
Move to using .env file for setting up environment variables for J721S2.
Signed-off-by: Neha Malcom Francis
Reviewed-by: Tom Rini
---
Changes in v2:
- Added CONFIG_CMD_REMOTEPROC guard to including k3_rproc.env
- Retained Reviewed-by tag
board/ti/j721s2/Kconfig | 6 ++
board/ti/j721s2/j721s2.env | 56 +
include/configs/j721s2_evm.h | 118 +--
3 files changed, 63 insertions(+), 117 deletions(-)
create mode 100644 board/ti/j721s2/j721s2.env
diff --git a/board/ti/j721s2/Kconfig b/board/ti/j721s2/Kconfig
index 6141798333..70972d1227 100644
--- a/board/ti/j721s2/Kconfig
+++ b/board/ti/j721s2/Kconfig
@@ -40,6 +40,9 @@ config SYS_VENDOR
config SYS_CONFIG_NAME
default "j721s2_evm"
+config ENV_SOURCE_FILE
+ default "j721s2"
+
source "board/ti/common/Kconfig"
endif
@@ -55,6 +58,9 @@ config SYS_VENDOR
config SYS_CONFIG_NAME
default "j721s2_evm"
+config ENV_SOURCE_FILE
+ default "j721s2"
+
source "board/ti/common/Kconfig"
endif
diff --git a/board/ti/j721s2/j721s2.env b/board/ti/j721s2/j721s2.env
new file mode 100644
index 00..2152f8849f
--- /dev/null
+++ b/board/ti/j721s2/j721s2.env
@@ -0,0 +1,56 @@
+#include
+#include
+#include
+#include
+
+#if CONFIG_CMD_REMOTEPROC
+#include
+#endif
+
+default_device_tree=k3-j721s2-common-proc-board.dtb
+findfdt=
+ setenv name_fdt ${default_device_tree};
+ if test $board_name = j721s2; then \
+ setenv name_fdt k3-j721s2-common-proc-board.dtb; fi;
+ if test $board_name = am68-sk; then
+ setenv name_fdt k3-am68-sk-base-board.dtb; fi;
+ setenv fdtfile ${name_fdt}
+name_kern=Image
+console=ttyS2,115200n8
+args_all=setenv optargs earlycon=ns16550a,mmio32,0x0288
+ ${mtdparts}
+run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
+
+boot=mmc
+mmcdev=1
+bootpart=1:2
+bootdir=/boot
+#if CONFIG_SYS_K3_SPL_ATF
+#if CONFIG_TARGET_J721S2_R5_EVM
+addr_mcur5f0_0load=0x8900
+name_mcur5f0_0fw=/lib/firmware/j7-mcu-r5f0_0-fw
+#endif
+#endif
+rd_spec=-
+init_mmc=run args_all args_mmc
+get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
+get_overlay_mmc=
+ fdt address ${fdtaddr};
+ fdt resize 0x10;
+ for overlay in $name_overlays;
+ do;
+ load mmc ${bootpart} ${dtboaddr} ${bootdir}/${overlay} &&
+ fdt apply ${dtboaddr};
+ done;
+partitions=uuid_disk=${uuid_gpt_disk};
+ name=rootfs,start=0,size=-,uuid=${uuid_gpt_rootfs}
+get_kern_mmc=load mmc ${bootpart} ${loadaddr}
+ ${bootdir}/${name_kern}
+get_fit_mmc=load mmc ${bootpart} ${addr_fit}
+ ${bootdir}/${name_fit}
+partitions=uuid_disk=${uuid_gpt_disk};
+ name=rootfs,start=0,size=-,uuid=${uuid_gpt_rootfs}
+
+rproc_fw_binaries= 2 /lib/firmware/j721s2-main-r5f0_0-fw 3
/lib/firmware/j721s2-main-r5f0_1-fw 4 /lib/firmware/j721s2-main-r5f1_0-fw 5
/lib/firmware/j721s2-main-r5f1_1-fw 6 /lib/firmware/j721s2-c71_0-fw 7
/lib/firmware/j721s2-c71_1-fw
+
+
You have two extra lines at the end of the file.
diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h
index bfada9eebc..2fa93b7961 100644
--- a/include/configs/j721s2_evm.h
+++ b/include/configs/j721s2_evm.h
@@ -11,10 +11,6 @@
#include
#include
-#include
-#include
-#include
-#include
/* DDR Configuration */
#define CFG_SYS_SDRAM_BASE1 0x88000
@@ -27,120 +23,8 @@
#define CFG_SYS_UBOOT_BASE0x5008
#endif
-/* U-Boot general configuration */
-#define EXTRA_ENV_J721S2_BOARD_SETTINGS
\
- "default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
- "findfdt="\
- "setenv name_fdt ${default_device_tree};" \
- "if test $board_name = j721s2; then " \
- "setenv name_fdt k3-j721s2-common-proc-board.dtb; fi;" \
- "if test $board_name = am68-sk; then "\
- "setenv name_fdt k3-am68-sk-base-board.dtb; fi;"\
- "setenv fdtfile ${name_fdt}\0"\
- "name_kern=Image\0" \
- "console=ttyS2,115200n8\0"\
- "args_all=setenv optargs earlycon=ns16550a,mmio32,0x0288 "\
- "${mtdparts}\0" \
- "run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}\0"
-
-#define PARTS_DEFAULT \
- /* Linux partitions */ \
- "uuid_disk=${uuid_gpt_disk};" \
- "name=rootfs,start=0,size=-,uuid=${uuid_gpt_rootfs}\0"
-
-#ifdef CONFIG_SYS_K3_SPL_ATF
-#if defined(CONFIG_TARGET_J721S2_R5_EVM)
-#define
Re: [PATCH 2/3] rockchip: Disable DISTRO_DEFAULTS for rockpro64
Hi, On Thu, 16 Mar 2023 at 12:17, Tom Rini wrote: > > On Thu, Mar 16, 2023 at 11:01:01AM +, Peter Robinson wrote: > > On Wed, Feb 22, 2023 at 7:17 PM Tom Rini wrote: > > > > > > On Wed, Feb 22, 2023 at 12:03:58PM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Wed, 22 Feb 2023 at 12:01, Tom Rini wrote: > > > > > > > > > > On Wed, Feb 22, 2023 at 11:58:37AM -0700, Simon Glass wrote: > > > > > > Hi, > > > > > > > > > > > > On Wed, 22 Feb 2023 at 11:56, Jonas Karlman wrote: > > > > > > > > > > > > > > On 2023-02-22 19:24, Tom Rini wrote: > > > > > > > > On Wed, Feb 22, 2023 at 10:19:03AM -0800, Vagrant Cascadian > > > > > > > > wrote: > > > > > > > >> On 2023-02-21, Vagrant Cascadian wrote: > > > > > > > >>> On 2023-02-21, Simon Glass wrote: > > > > > > > This board has moved to standard boot but the old > > > > > > > 'distro_bootcmd' > > > > > > > command is still active. Disable DISTRO_DEFAULTS to fix this. > > > > > > > >>> > > > > > > > >>> Works for booting rockpro64-rk3399, thanks! > > > > > > > >> > > > > > > > >> I can also confirm that applying a very similar patch for > > > > > > > >> pinebook-pro-rk3399 works booting with bootstd. > > > > > > > >> > > > > > > > >> Seems worth adding if there is a v2 of the patch series. > > > > > > > >> > > > > > > > >> Alternately, rather than doing this on a board-by-board basis, > > > > > > > >> is there > > > > > > > >> some way to disable CONFIG_DISTRO_DEFAULTS when a board is > > > > > > > >> using > > > > > > > >> BOOTSTD? > > > > > > > > > > > > > > > > I think that's possibly a bit dangerous? DISTRO_DEFAULTS and > > > > > > > > BOOTSTD_DEFAULTS need to be reconciled to a single new symbol, > > > > > > > > and the > > > > > > > > DISTRO_DEFAULTS method of select not imply for most things is > > > > > > > > also I > > > > > > > > suspect the right path. > > > > > > > > > > > > > > > > > > > > > > Another option would be to set BOOTSTD_BOOTCOMMAND=y, this is the > > > > > > > main > > > > > > > issue with rk3399 at the moment, distro_bootcmd got removed from > > > > > > > env, > > > > > > > yet bootcmd is still "run distro_bootcmd" due to > > > > > > > DISTRO_DEFAULTS=y. > > > > > > > > > > > > > > > > > > > > > config BOOTCOMMAND > > > > > > > default "bootflow scan -lb" if BOOTSTD_BOOTCOMMAND && > > > > > > > CMD_BOOTFLOW_FULL > > > > > > > default "bootflow scan" if BOOTSTD_BOOTCOMMAND && > > > > > > > !CMD_BOOTFLOW_FULL > > > > > > > default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && > > > > > > > DISTRO_DEFAULTS > > > > > > > > > > > > > > config BOOTSTD_BOOTCOMMAND > > > > > > > default y if !DISTRO_DEFAULTS > > > > > > > > > > > > That seems reasonable to me, along with a 'depends on BOOTSTD' > > > > > > > > > > > > At present DISTRO_DEFAULTS is both enabled in defconfig files (about > > > > > > 350) and Kconfig (another 300). For rockchip it is the latter. > > > > > > > > > > > > It doesn't really make sense to use DISTRO_DEFAULTS when using > > > > > > BOOTSTD_DEFAULTS. One is 'run distro_bootcmd' and the other is > > > > > > 'bootflow scan', possibly with -lb flags. But we really don't want > > > > > > people flipping back and forward. > > > > > > > > > > It doesn't make linguistic sense to have "distro defaults" and > > > > > "bootstd > > > > > defaults" enabled. It makes compute sense to have these two symbols > > > > > combined as they're nearly identical and have a similar conceptual > > > > > need > > > > > (make sure we have things like bootz/booti/ext4/etc support). > > > > > > > > Oh, so you are talking about DISTRO_DEFAULTS, not the actual command? > > > > In that case I can do a patch to make them both use a common symbol to > > > > bring in most stuff, although bootstd does not need hush and a few > > > > other things that are needed by distro_bootcmd. > > > > > > > > Let me know if that makes sense. > > > > > > Yeah, the Kconfig symbols DISTRO_DEFAULTS and BOOTSTD_DEFAULTS need to > > > be reconciled and combined. This is separate from setting bootcmd to > > > "run distro_bootcmd", which should be separate, and yes, not be the > > > chosen symbol when we have bootstd enabled. > > > > What came out of this decision, the first other rk3399 device I tried, > > the rock960, is also broken booting. We really can't have devices > > randomly broken all the time and I don't have the time or the devices > > to go through and test everything. We should really be getting better > > at these mass changes, it doesn't lead to a great user experience! > > Part of the problem is that Rockchip had a few issues at the end of the > last cycle and then the start of this one. Another issue is that I don't > have a Rockchip platform in my CI loop, but I'm hoping to fix that in > the next week or so. Is top of tree working on your platforms or no? > They should be, at this point. This series hopes to resolve the issues:
Re: [PATCH v2 6/8] boot: Create a common BOOT_DEFAULTS for distro and bootstd
Hi Tom, On Thu, 2 Mar 2023 at 08:14, Tom Rini wrote: > > On Wed, Mar 01, 2023 at 08:39:27PM -0700, Simon Glass wrote: > > > These two features use a lot of common options. Move them into a common > > CONFIG to reduce duplication. > > > > Resync defconfigs since this makes a lot of changes. > > > > Signed-off-by: Simon Glass > [snip] > > diff --git a/boot/Kconfig b/boot/Kconfig > > index da18d4738a7..7f7ec208a54 100644 > > --- a/boot/Kconfig > > +++ b/boot/Kconfig > > @@ -350,6 +350,35 @@ config PXE_UTILS > > help > > Utilities for parsing PXE file formats. > > > > +config BOOT_DEFAULTS > > + bool # Common defaults for standard boot and distroboot > > + imply USE_BOOTCOMMAND > > + # Bring in some defaults which are generally needed. Boards can drop > > + # these as needed to save code space. Bootstd does not generally > > require > > + # the commands themselves to be enabled, but this is how some of the > > + # functionality is controlled at present > > + select CMD_ENV_EXISTS > > + imply CMD_EXT2 > > + imply CMD_EXT4 > > + imply CMD_FAT > > + imply CMD_FS_GENERIC > > + imply CMD_PART if PARTITIONS > > + imply CMD_DHCP if NET > > + imply CMD_MII if NET > > + imply CMD_PING if NET > > + imply CMD_PXE if NET > > + imply USB_STORAGE > > + imply SUPPORT_RAW_INITRD > > + imply ENV_VARS_UBOOT_CONFIG > > + imply EFI_PARTITION > > + imply ISO_PARTITION > > + select CMD_BOOTI if ARM64 > > + select CMD_BOOTZ if ARM && !ARM64 > > + help > > + These are not required but are commonly needed to support a good > > + selection of booting methods. Enable this to improve the capability > > + of U-Boot to boot various images. > > We want the more heavy-handed select rather than imply here, as this is > part of making sure people do end up with a set of default that will > work and not unexpectedly fail to boot off-the-shelf things. > But then boards cannot override it. This is a 'default' option that intends to bring in things that make it easier for the user to get right. But we do need to allow for people to use standard boot in more constrained ways. Did we ever figure out if we can detect inconsistencies when we try to select something that has an unsatisfied dependency? Regards, Simon
RE: [PATCH 1/3] dm: adc: add iMX93 ADC support
> -Original Message-
> From: Luca Ellero
> Sent: 2023年3月15日 21:36
> To: u-boot@lists.denx.de; sba...@denx.de; feste...@gmail.com; dl-uboot-imx
> ; luca.ell...@brickedbrain.com; Ye Li ;
> Peng Fan ; Bough Chen
> Cc: Luca Ellero
> Subject: [PATCH 1/3] dm: adc: add iMX93 ADC support
>
> This commit adds driver for iMX93 ADC.
>
> The driver is implemented using driver model and provides ADC uclass's methods
> for ADC single channel operations:
> - adc_start_channel()
> - adc_channel_data()
> - adc_stop()
>
> ADC features:
> - channels: 4
> - resolution: 12-bit
>
> Signed-off-by: Luca Ellero
> ---
> drivers/adc/Kconfig | 8 ++
> drivers/adc/Makefile| 1 +
> drivers/adc/imx93-adc.c | 286
>
> 3 files changed, 295 insertions(+)
> create mode 100644 drivers/adc/imx93-adc.c
>
> diff --git a/drivers/adc/Kconfig b/drivers/adc/Kconfig index
> e719c38bb3..4336732dee 100644
> --- a/drivers/adc/Kconfig
> +++ b/drivers/adc/Kconfig
> @@ -63,3 +63,11 @@ config STM32_ADC
> - core driver to deal with common resources
> - child driver to deal with individual ADC resources (declare ADC
> device and associated channels, start/stop conversions)
> +
> +config ADC_IMX93
> + bool "Enable NXP IMX93 ADC driver"
> + help
> + This enables basic driver for NXP IMX93 ADC.
> + It provides:
> + - 4 analog input channels
> + - 12-bit resolution
> diff --git a/drivers/adc/Makefile b/drivers/adc/Makefile index
> c1387f3a34..5336c82097 100644
> --- a/drivers/adc/Makefile
> +++ b/drivers/adc/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_ADC_SANDBOX) += sandbox.o
> obj-$(CONFIG_SARADC_ROCKCHIP) += rockchip-saradc.o
> obj-$(CONFIG_SARADC_MESON) += meson-saradc.o
> obj-$(CONFIG_STM32_ADC) += stm32-adc.o stm32-adc-core.o
> +obj-$(CONFIG_ADC_IMX93) += imx93-adc.o
> diff --git a/drivers/adc/imx93-adc.c b/drivers/adc/imx93-adc.c new file mode
> 100644 index 00..b3bbea6c4e
> --- /dev/null
> +++ b/drivers/adc/imx93-adc.c
> @@ -0,0 +1,286 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 ASEM Srl
> + * Author: Luca Ellero
> + *
> + * Originally based on NXP linux-imx kernel v5.15
> +drivers/iio/adc/imx93_adc.c */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define IMX93_ADC_MCR0x00
> +#define IMX93_ADC_MSR0x04
> +#define IMX93_ADC_ISR0x10
> +#define IMX93_ADC_IMR0x20
> +#define IMX93_ADC_CIMR0 0x24
> +#define IMX93_ADC_CTR0 0x94
> +#define IMX93_ADC_NCMR0 0xA4
> +#define IMX93_ADC_PCDR0 0x100
> +#define IMX93_ADC_PCDR1 0x104
> +#define IMX93_ADC_PCDR2 0x108
> +#define IMX93_ADC_PCDR3 0x10c
> +#define IMX93_ADC_PCDR4 0x110
> +#define IMX93_ADC_PCDR5 0x114
> +#define IMX93_ADC_PCDR6 0x118
> +#define IMX93_ADC_PCDR7 0x11c
> +#define IMX93_ADC_CALSTAT0x39C
> +
> +#define IMX93_ADC_MCR_MODE_MASK BIT(29)
> +#define IMX93_ADC_MCR_NSTART_MASKBIT(24)
> +#define IMX93_ADC_MCR_CALSTART_MASK BIT(14)
> +#define IMX93_ADC_MCR_ADCLKSE_MASK BIT(8)
> +#define IMX93_ADC_MCR_PWDN_MASK BIT(0)
> +
> +#define IMX93_ADC_MSR_CALFAIL_MASK BIT(30)
> +#define IMX93_ADC_MSR_CALBUSY_MASK BIT(29)
> +#define IMX93_ADC_MSR_ADCSTATUS_MASK GENMASK(2, 0)
> +
> +#define IMX93_ADC_ISR_EOC_MASK BIT(1)
> +
> +#define IMX93_ADC_IMR_EOC_MASK BIT(1)
> +#define IMX93_ADC_IMR_ECH_MASK BIT(0)
> +
> +#define IMX93_ADC_PCDR_CDATA_MASKGENMASK(11, 0)
> +
> +#define IDLE 0
> +#define POWER_DOWN 1
> +#define WAIT_STATE 2
> +#define BUSY_IN_CALIBRATION 3
> +#define SAMPLE 4
> +#define CONVERSION 6
> +
> +#define IMX93_ADC_MAX_CHANNEL3
> +#define IMX93_ADC_DAT_MASK 0xfff
> +#define IMX93_ADC_TIMEOUT10
> +
> +struct imx93_adc_priv {
> + int active_channel;
> + void __iomem *regs;
> +};
> +
> +static int imx93_adc_power_down(struct imx93_adc_priv *adc) {
> + u32 mcr, msr;
> + int ret;
> +
> + mcr = readl(adc->regs + IMX93_ADC_MCR);
> + mcr |= FIELD_PREP(IMX93_ADC_MCR_PWDN_MASK, 1);
> + writel(mcr, adc->regs + IMX93_ADC_MCR);
> +
> + ret = readl_poll_timeout(adc->regs + IMX93_ADC_MSR, msr,
> + ((msr & IMX93_ADC_MSR_ADCSTATUS_MASK) == POWER_DOWN),
> 50);
> + if (ret == -ETIMEDOUT)
> + pr_warn("ADC not in power down mode, current MSR: %x\n", msr);
> +
> + return ret;
> +}
> +
> +static int imx93_adc_config_ad_clk(struct imx93_adc_priv *adc) {
> + u32
[PATCH v1 2/5] net: dwc_eth_qos: Add StarFive ethernet driver glue layer
The StarFive ETHQOS hardware has its own clock and reset,so add a
corresponding glue driver to configure them.
Signed-off-by: Yanhong Wang
---
drivers/net/Kconfig| 7 +
drivers/net/Makefile | 1 +
drivers/net/dwc_eth_qos.c | 6 +
drivers/net/dwc_eth_qos.h | 2 +
drivers/net/dwc_eth_qos_starfive.c | 306 +
5 files changed, 322 insertions(+)
create mode 100644 drivers/net/dwc_eth_qos_starfive.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ceadee98a1..161289d00f 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -249,6 +249,13 @@ config DWC_ETH_QOS_QCOM
The Synopsys Designware Ethernet QOS IP block with specific
configuration used in Qcom QCS404 SoC.
+config DWC_ETH_QOS_STARFIVE
+ bool "Synopsys DWC Ethernet QOS device support for STARFIVE"
+ depends on DWC_ETH_QOS
+ help
+ The Synopsys Designware Ethernet QOS IP block with specific
+ configuration used in STARFIVE JH7110 soc.
+
config E1000
bool "Intel PRO/1000 Gigabit Ethernet support"
depends on PCI
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 75daa5e694..69af678757 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_DSA_SANDBOX) += dsa_sandbox.o
obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
+obj-$(CONFIG_DWC_ETH_QOS_STARFIVE) += dwc_eth_qos_starfive.o
obj-$(CONFIG_E1000) += e1000.o
obj-$(CONFIG_E1000_SPI) += e1000_spi.o
obj-$(CONFIG_EEPRO100) += eepro100.o
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 112deb546d..9aecd56e73 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1718,6 +1718,12 @@ static const struct udevice_id eqos_ids[] = {
.data = (ulong)_qcom_config
},
#endif
+#if IS_ENABLED(CONFIG_DWC_ETH_QOS_STARFIVE)
+ {
+ .compatible = "starfive,jh7110-dwmac",
+ .data = (ulong)_jh7110_config
+ },
+#endif
{ }
};
diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h
index fddbe9336c..20450497a9 100644
--- a/drivers/net/dwc_eth_qos.h
+++ b/drivers/net/dwc_eth_qos.h
@@ -279,6 +279,7 @@ struct eqos_priv {
bool clk_ck_enabled;
unsigned int tx_fifo_sz, rx_fifo_sz;
u32 reset_delays[3];
+ struct reset_ctl reset_ahb;
};
void eqos_inval_desc_generic(void *desc);
@@ -289,3 +290,4 @@ int eqos_null_ops(struct udevice *dev);
extern struct eqos_config eqos_imx_config;
extern struct eqos_config eqos_qcom_config;
+extern struct eqos_config eqos_jh7110_config;
diff --git a/drivers/net/dwc_eth_qos_starfive.c
b/drivers/net/dwc_eth_qos_starfive.c
new file mode 100644
index 00..eeb45981bd
--- /dev/null
+++ b/drivers/net/dwc_eth_qos_starfive.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 StarFive Technology Co., Ltd.
+ * Author: Yanhong Wang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dwc_eth_qos.h"
+
+#define STARFIVE_DWMAC_PHY_INFT_RGMII 0x1
+#define STARFIVE_DWMAC_PHY_INFT_RMII 0x4
+#define STARFIVE_DWMAC_PHY_INFT_FIELD 0x7U
+
+static int eqos_interface_init_jh7110(struct udevice *dev,
+ phy_interface_t interface_type)
+{
+ struct regmap *regmap;
+ struct ofnode_phandle_args args;
+ unsigned int mode;
+ int ret;
+
+ switch (interface_type) {
+ case PHY_INTERFACE_MODE_RMII:
+ mode = STARFIVE_DWMAC_PHY_INFT_RMII;
+ break;
+
+ case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ mode = STARFIVE_DWMAC_PHY_INFT_RGMII;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ ret = dev_read_phandle_with_args(dev, "starfive,syscon", NULL,
+2, 0, );
+ if (ret)
+ return ret;
+
+ if (args.args_count != 2)
+ return -EINVAL;
+
+ regmap = syscon_regmap_lookup_by_phandle(dev, "starfive,syscon");
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
+ pr_err("Failed to get regmap: %d\n", ret);
+ return ret;
+ }
+
+ return regmap_update_bits(regmap, args.args[0],
+ STARFIVE_DWMAC_PHY_INFT_FIELD << args.args[1],
+ mode << args.args[1]);
+}
+
+static int eqos_set_tx_clk_speed_jh7110(struct udevice *dev)
+{
+ struct eqos_priv *eqos = dev_get_priv(dev);
+ struct clk *pclk, *c;
+ ulong rate;
+ int ret;
+
+ /* Generally, the rgmii_tx clock is provided by the internal clock,
+* which needs to match the corresponding clock frequency
[PATCH v1 1/5] net: phy: Add driver for Motorcomm yt8531 gigabit ethernet phy
Add a driver for the motorcomm yt8531 gigabit ethernet phy. We have verified the driver on StarFive VisionFive2 board. Signed-off-by: Yanhong Wang --- drivers/net/phy/Kconfig | 6 + drivers/net/phy/Makefile| 1 + drivers/net/phy/motorcomm.c | 409 drivers/net/phy/phy.c | 4 +- include/phy.h | 1 + 5 files changed, 420 insertions(+), 1 deletion(-) create mode 100644 drivers/net/phy/motorcomm.c diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 5eaff053a0..aba718566a 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -212,6 +212,12 @@ config PHY_MICREL_KSZ8XXX endif # PHY_MICREL +config PHY_MOTORCOMM + tristate "Motorcomm PHYs" + help + Enables support for Motorcomm network PHYs. + Currently supports the YT8531 Gigabit Ethernet PHYs. + config PHY_MSCC bool "Microsemi Corp Ethernet PHYs support" diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile index d38e99e717..e9523fed2e 100644 --- a/drivers/net/phy/Makefile +++ b/drivers/net/phy/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_PHY_MARVELL) += marvell.o obj-$(CONFIG_PHY_MICREL_KSZ8XXX) += micrel_ksz8xxx.o obj-$(CONFIG_PHY_MICREL_KSZ90X1) += micrel_ksz90x1.o obj-$(CONFIG_PHY_MESON_GXL) += meson-gxl.o +obj-$(CONFIG_PHY_MOTORCOMM) += motorcomm.o obj-$(CONFIG_PHY_NATSEMI) += natsemi.o obj-$(CONFIG_PHY_NXP_C45_TJA11XX) += nxp-c45-tja11xx.o obj-$(CONFIG_PHY_NXP_TJA11XX) += nxp-tja11xx.o diff --git a/drivers/net/phy/motorcomm.c b/drivers/net/phy/motorcomm.c new file mode 100644 index 00..c7e44cfb63 --- /dev/null +++ b/drivers/net/phy/motorcomm.c @@ -0,0 +1,409 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Motorcomm 8531 PHY driver. + * + * Copyright (C) 2023 StarFive Technology Co., Ltd. + */ + +#include +#include +#include +#include + +#define PHY_ID_YT8531 0x4f51e91b +#define PHY_ID_MASKGENMASK(31, 0) + +/* Extended Register's Address Offset Register */ +#define YTPHY_PAGE_SELECT 0x1E + +/* Extended Register's Data Register */ +#define YTPHY_PAGE_DATA0x1F + +#define YTPHY_SYNCE_CFG_REG0xA012 + +#define YTPHY_DTS_OUTPUT_CLK_DIS 0 +#define YTPHY_DTS_OUTPUT_CLK_25M 2500 +#define YTPHY_DTS_OUTPUT_CLK_125M 12500 + +#define YT8531_SCR_SYNCE_ENABLEBIT(6) +/* 1b0 output 25m clock *default* + * 1b1 output 125m clock + */ +#define YT8531_SCR_CLK_FRE_SEL_125MBIT(4) +#define YT8531_SCR_CLK_SRC_MASKGENMASK(3, 1) +#define YT8531_SCR_CLK_SRC_PLL_125M0 +#define YT8531_SCR_CLK_SRC_UTP_RX 1 +#define YT8531_SCR_CLK_SRC_SDS_RX 2 +#define YT8531_SCR_CLK_SRC_CLOCK_FROM_DIGITAL 3 +#define YT8531_SCR_CLK_SRC_REF_25M 4 +#define YT8531_SCR_CLK_SRC_SSC_25M 5 + +/* 1b0 use original tx_clk_rgmii *default* + * 1b1 use inverted tx_clk_rgmii. + */ +#define YT8531_RC1R_TX_CLK_SEL_INVERTEDBIT(14) +#define YT8531_RC1R_RX_DELAY_MASK GENMASK(13, 10) +#define YT8531_RC1R_FE_TX_DELAY_MASK GENMASK(7, 4) +#define YT8531_RC1R_GE_TX_DELAY_MASK GENMASK(3, 0) +#define YT8531_RC1R_RGMII_0_000_NS 0 +#define YT8531_RC1R_RGMII_0_150_NS 1 +#define YT8531_RC1R_RGMII_0_300_NS 2 +#define YT8531_RC1R_RGMII_0_450_NS 3 +#define YT8531_RC1R_RGMII_0_600_NS 4 +#define YT8531_RC1R_RGMII_0_750_NS 5 +#define YT8531_RC1R_RGMII_0_900_NS 6 +#define YT8531_RC1R_RGMII_1_050_NS 7 +#define YT8531_RC1R_RGMII_1_200_NS 8 +#define YT8531_RC1R_RGMII_1_350_NS 9 +#define YT8531_RC1R_RGMII_1_500_NS 10 +#define YT8531_RC1R_RGMII_1_650_NS 11 +#define YT8531_RC1R_RGMII_1_800_NS 12 +#define YT8531_RC1R_RGMII_1_950_NS 13 +#define YT8531_RC1R_RGMII_2_100_NS 14 +#define YT8531_RC1R_RGMII_2_250_NS 15 + +/* Phy gmii clock gating Register */ +#define YT8531_CLOCK_GATING_REG0xC +#define YT8531_CGR_RX_CLK_EN BIT(12) + +/* Specific Status Register */ +#define YTPHY_SPECIFIC_STATUS_REG 0x11 +#define YTPHY_DUPLEX_MASK BIT(13) +#define YTPHY_DUPLEX_SHIFT 13 +#define YTPHY_SPEED_MODE_MASK GENMASK(15, 14) +#define YTPHY_SPEED_MODE_SHIFT 14 + +#define YT8531_EXTREG_SLEEP_CONTROL1_REG 0x27 +#define YT8531_ESC1R_SLEEP_SW BIT(15) +#define YT8531_ESC1R_PLLON_SLP BIT(14) + +#define YT8531_RGMII_CONFIG1_REG 0xA003 + +#define YT8531_CHIP_CONFIG_REG 0xA001 +#define YT8531_CCR_SW_RST BIT(15) +/* 1b0 disable 1.9ns rxc clock delay *default* + * 1b1 enable 1.9ns rxc clock
[PATCH v1 5/5] configs: starfive: Enable ethernet configuration for StarFive VisionFive 2
Enable DWC_ETH_QOS and PHY_MOTORCOMM configuration to support ethernet function for StarFive VisionFive 2 board. Signed-off-by: Yanhong Wang --- configs/starfive_visionfive2_defconfig | 13 + 1 file changed, 13 insertions(+) diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index 550d0ff3ab..18f0d8fd27 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -52,6 +52,9 @@ CONFIG_SYS_BOOTM_LEN=0x400 CONFIG_CMD_MEMINFO=y CONFIG_CMD_TFTPPUT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_REGMAP=y +CONFIG_SYSCON=y CONFIG_SPL_CLK_COMPOSITE_CCF=y CONFIG_CLK_COMPOSITE_CCF=y CONFIG_SPL_CLK_JH7110=y @@ -65,6 +68,15 @@ CONFIG_SPI_FLASH_EON=y CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_SPI_FLASH_ISSI=y CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_PHY_MOTORCOMM=y +# CONFIG_PHY_MSCC is not set +CONFIG_DM_MDIO=y +CONFIG_DM_ETH_PHY=y +CONFIG_DWC_ETH_QOS=y +CONFIG_DWC_ETH_QOS_STARFIVE=y +CONFIG_RGMII=y +# CONFIG_MII is not set +CONFIG_RMII=y CONFIG_PINCTRL=y CONFIG_PINCONF=y CONFIG_SPL_PINCTRL=y @@ -72,6 +84,7 @@ CONFIG_SPL_PINCONF=y CONFIG_SPL_PINCTRL_STARFIVE=y CONFIG_SPL_PINCTRL_STARFIVE_JH7110=y CONFIG_PINCTRL_STARFIVE=y +# CONFIG_POWER is not set # CONFIG_RAM_SIFIVE is not set CONFIG_SYS_NS16550=y CONFIG_CADENCE_QSPI=y -- 2.17.1
[PATCH v1 0/5] Add Ethernet driver for StarFive JH7110 SoC
This series adds ethernet support for the StarFive JH7110 RISC-V SoC. The series includes PHY and MAC drivers. The PHY model is YT8531 (from Motorcomm Inc), and the MAC version is dwmac-5.20 (from Synopsys DesignWare). The implementation of the phy driver is ported from linux, but it has been adjusted for the u-boot framework. The PHY and MAC driver has been tested on the StarFive VisionFive 2 1.2A and 1.3B boards and works normally. For more information and support,you can visit RVspace wiki[1]. This patchset should be applied after the patchset [2]. [1] https://wiki.rvspace.org/ [2] https://patchwork.ozlabs.org/project/uboot/cover/20230316025332.3297-1-yanhong.w...@starfivetech.com/ Yanhong Wang (5): net: phy: Add driver for Motorcomm yt8531 gigabit ethernet phy net: dwc_eth_qos: Add StarFive ethernet driver glue layer riscv: dts: jh7110: Add ethernet device tree nodes riscv: dts: starfive: Add phy clock delay configuration for StarFive VisionFive2 board configs: starfive: Enable ethernet configuration for StarFive VisionFive 2 .../jh7110-starfive-visionfive-2-v1.2a.dts| 13 + .../jh7110-starfive-visionfive-2-v1.3b.dts| 27 ++ .../dts/jh7110-starfive-visionfive-2.dtsi | 34 ++ arch/riscv/dts/jh7110.dtsi| 69 +++ configs/starfive_visionfive2_defconfig| 13 + drivers/net/Kconfig | 7 + drivers/net/Makefile | 1 + drivers/net/dwc_eth_qos.c | 6 + drivers/net/dwc_eth_qos.h | 2 + drivers/net/dwc_eth_qos_starfive.c| 306 + drivers/net/phy/Kconfig | 6 + drivers/net/phy/Makefile | 1 + drivers/net/phy/motorcomm.c | 409 ++ drivers/net/phy/phy.c | 4 +- include/phy.h | 1 + 15 files changed, 898 insertions(+), 1 deletion(-) create mode 100644 drivers/net/dwc_eth_qos_starfive.c create mode 100644 drivers/net/phy/motorcomm.c base-commit: 3ad7642443aee9369726844ffcfe5b9ae68c259e -- 2.17.1
[PATCH v1 4/5] riscv: dts: starfive: Add phy clock delay configuration for StarFive VisionFive2 board
The StarFive VisionFive2 board include 1.2A and 1.3B version.
v1.3B uses motorcomm YT8531(rgmii-id phy) x2, phy clock need delay and
inverse configurations.
v1.2A gmac0 uses motorcomm YT8531(rgmii-id) PHY, and needs phy clock
delay configurations.
v1.2A gmac1 uses motorcomm YT8512(rmii) PHY, and needs to switch rx and
tx to external clock sources.
Signed-off-by: Yanhong Wang
---
.../jh7110-starfive-visionfive-2-v1.2a.dts| 13 +++
.../jh7110-starfive-visionfive-2-v1.3b.dts| 27 +++
.../dts/jh7110-starfive-visionfive-2.dtsi | 34 +++
3 files changed, 74 insertions(+)
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2-v1.2a.dts
b/arch/riscv/dts/jh7110-starfive-visionfive-2-v1.2a.dts
index b9d26d7af7..918e77220a 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2-v1.2a.dts
+++ b/arch/riscv/dts/jh7110-starfive-visionfive-2-v1.2a.dts
@@ -10,3 +10,16 @@
model = "StarFive VisionFive 2 v1.2A";
compatible = "starfive,visionfive-2-v1.2a", "starfive,jh7110";
};
+
+ {
+ phy-mode = "rmii";
+ assigned-clocks = < JH7110_SYSCLK_GMAC1_TX>,
+ < JH7110_SYSCLK_GMAC1_RX>;
+ assigned-clock-parents = < JH7110_SYSCLK_GMAC1_RMII_RTX>,
+< JH7110_SYSCLK_GMAC1_RMII_RTX>;
+};
+
+ {
+ rx-internal-delay-ps = <1900>;
+ tx-internal-delay-ps = <1350>;
+};
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2-v1.3b.dts
b/arch/riscv/dts/jh7110-starfive-visionfive-2-v1.3b.dts
index 3b3b3453a1..0fcd6ab80f 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2-v1.3b.dts
+++ b/arch/riscv/dts/jh7110-starfive-visionfive-2-v1.3b.dts
@@ -10,3 +10,30 @@
model = "StarFive VisionFive 2 v1.3B";
compatible = "starfive,visionfive-2-v1.3b", "starfive,jh7110";
};
+
+ {
+ starfive,tx-use-rgmii-clk;
+ assigned-clocks = < JH7110_AONCLK_GMAC0_TX>;
+ assigned-clock-parents = < JH7110_AONCLK_GMAC0_RMII_RTX>;
+};
+
+ {
+ starfive,tx-use-rgmii-clk;
+ assigned-clocks = < JH7110_SYSCLK_GMAC1_TX>;
+ assigned-clock-parents = < JH7110_SYSCLK_GMAC1_RMII_RTX>;
+};
+
+ {
+ motorcomm,tx-clk-adj-enabled;
+ motorcomm,tx-clk-100-inverted;
+ motorcomm,tx-clk-1000-inverted;
+ rx-internal-delay-ps = <1900>;
+ tx-internal-delay-ps = <1500>;
+};
+
+ {
+ motorcomm,tx-clk-adj-enabled;
+ motorcomm,tx-clk-100-inverted;
+ rx-internal-delay-ps = <0>;
+ tx-internal-delay-ps = <0>;
+};
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
index c6b6dfa940..3c1148ae2d 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi
@@ -17,6 +17,8 @@
i2c2 =
i2c5 =
i2c6 =
+ ethernet0 =
+ ethernet1 =
};
chosen {
@@ -317,3 +319,35 @@
assigned-clock-parents = <>;
assigned-clock-rates = <0>;
};
+
+ {
+ phy-handle = <>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+};
+
+ {
+ phy-handle = <>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+
+ phy1: ethernet-phy@1 {
+ reg = <0>;
+ };
+ };
+};
--
2.17.1
[PATCH v1 3/5] riscv: dts: jh7110: Add ethernet device tree nodes
Add ethernet device tree node to support StarFive ethernet driver for
the JH7110 RISC-V SoC.
Signed-off-by: Yanhong Wang
---
arch/riscv/dts/jh7110.dtsi | 69 ++
1 file changed, 69 insertions(+)
diff --git a/arch/riscv/dts/jh7110.dtsi b/arch/riscv/dts/jh7110.dtsi
index d3e9f92987..67267d9024 100644
--- a/arch/riscv/dts/jh7110.dtsi
+++ b/arch/riscv/dts/jh7110.dtsi
@@ -244,6 +244,13 @@
#clock-cells = <0>;
};
+ stmmac_axi_setup: stmmac-axi-config {
+ snps,lpi_en;
+ snps,wr_osr_lmt = <4>;
+ snps,rd_osr_lmt = <4>;
+ snps,blen = <256 128 64 32 0 0 0>;
+ };
+
soc {
compatible = "simple-bus";
interrupt-parent = <>;
@@ -548,6 +555,68 @@
status = "disabled";
};
+ gmac0: ethernet@1603 {
+ compatible = "starfive,jh7110-dwmac", "snps,dwmac-5.20";
+ reg = <0x0 0x1603 0x0 0x1>;
+ clocks = < JH7110_AONCLK_GMAC0_AXI>,
+< JH7110_AONCLK_GMAC0_AHB>,
+< JH7110_SYSCLK_GMAC0_PTP>,
+< JH7110_AONCLK_GMAC0_TX_INV>,
+< JH7110_SYSCLK_GMAC0_GTXC>;
+ clock-names = "stmmaceth", "pclk", "ptp_ref",
+ "tx", "gtx";
+ resets = < JH7110_AONRST_GMAC0_AXI>,
+< JH7110_AONRST_GMAC0_AHB>;
+ reset-names = "stmmaceth", "ahb";
+ interrupts = <7>, <6>, <5>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ snps,multicast-filter-bins = <64>;
+ snps,perfect-filter-entries = <8>;
+ rx-fifo-depth = <2048>;
+ tx-fifo-depth = <2048>;
+ snps,fixed-burst;
+ snps,no-pbl-x8;
+ snps,force_thresh_dma_mode;
+ snps,axi-config = <_axi_setup>;
+ snps,tso;
+ snps,en-tx-lpi-clockgating;
+ snps,txpbl = <16>;
+ snps,rxpbl = <16>;
+ starfive,syscon = <_syscon 0xc 0x12>;
+ status = "disabled";
+ };
+
+ gmac1: ethernet@1604 {
+ compatible = "starfive,jh7110-dwmac", "snps,dwmac-5.20";
+ reg = <0x0 0x1604 0x0 0x1>;
+ clocks = < JH7110_SYSCLK_GMAC1_AXI>,
+< JH7110_SYSCLK_GMAC1_AHB>,
+< JH7110_SYSCLK_GMAC1_PTP>,
+< JH7110_SYSCLK_GMAC1_TX_INV>,
+< JH7110_SYSCLK_GMAC1_GTXC>;
+ clock-names = "stmmaceth", "pclk", "ptp_ref",
+ "tx", "gtx";
+ resets = < JH7110_SYSRST_GMAC1_AXI>,
+< JH7110_SYSRST_GMAC1_AHB>;
+ reset-names = "stmmaceth", "ahb";
+ interrupts = <78>, <77>, <76>;
+ interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
+ snps,multicast-filter-bins = <64>;
+ snps,perfect-filter-entries = <8>;
+ rx-fifo-depth = <2048>;
+ tx-fifo-depth = <2048>;
+ snps,fixed-burst;
+ snps,no-pbl-x8;
+ snps,force_thresh_dma_mode;
+ snps,axi-config = <_axi_setup>;
+ snps,tso;
+ snps,en-tx-lpi-clockgating;
+ snps,txpbl = <16>;
+ snps,rxpbl = <16>;
+ starfive,syscon = <_syscon 0x90 0x2>;
+ status = "disabled";
+ };
+
aoncrg: clock-controller@1700 {
compatible = "starfive,jh7110-aoncrg";
reg = <0x0 0x1700 0x0 0x1>;
--
2.17.1
Re: i.MX8MP SPL failures due to memory corruption/overflow?
On 3/15/23 15:12, Frieder Schrempf wrote: Hi, Hi, I'm trying to bring up a new board based on the i.MX8MP and I have an issue I'm hoping someone can help solving. I'm seeing failures in the early SPL code, usually in the DDR initialization. Often they look like: U-Boot SPL 2023.04-rc3 (Mar 07 2023 - 14:32:34 +) Training FAILED Failed to initialize DDR RAM! ### ERROR ### Please RESET the board ### But sometimes ddr_init() doesn't even return an error and only the get_ram_size() afterwards which tries to allocate the memory fails. The strange thing is that the issues appear or disappear deterministically on the binary level. This means I sometimes get a U-Boot binary which runs just fine in 100% of cases. Then I change for example one of the following: * Adding a single printf() somewhere in the boards spl.c * Using the same binary but booting from SD card instead of USB loader * Using the same source but switching from the OS cross compiler to the one from Yocto/OE And afterwards I get 100% failure rate with an error as described above. My suspicion is that there is some memory corruption/conflict. My SPL is quite large and I wonder if it exceeds some limit. SPL is loaded to 0x92 and CONFIG_SPL_STACK is set to 0x96, which leaves 256 KiB in between for the SPL. But all i.MX8MP boards seem to set CONFIG_SPL_MAX_SIZE=0x26000 (152 KiB) for some reason. My u-boot-spl-ddr.bin currently has around 193 KiB but I don't get any warning about exceeding the SPL_MAX_SIZE. My questions: * Why is CONFIG_SPL_MAX_SIZE set to 152 KiB? * Why is there no warning in my case? * Any other ideas or pointers? Does it help if you enable CONFIG_LTO=y ?
[PATCH 2/2] drivers: rtc: add max313xx series rtc driver
Adding support for Analog Devices MAX313XX series RTCs.
This is ported from the Linux driver and adapted for use in u-boot.
Notable differences are
- handling of tm_year and tm_mon differ
- clock source support is omitted
- hwmon support for the MAX31328 and MAX31343 is omitted
- rtc_ops->reset is added
Signed-off-by: Chris Packham
---
drivers/rtc/Kconfig| 8 +
drivers/rtc/Makefile | 1 +
drivers/rtc/max313xx.c | 442 +
3 files changed, 451 insertions(+)
create mode 100644 drivers/rtc/max313xx.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 35b6ed4d7c72..49c260b5b190 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -134,6 +134,14 @@ config RTC_ISL1208
This driver supports reading and writing the RTC/calendar and detects
total power failures.
+config RTC_MAX313XX
+ bool "Analog Devices MAX313XX RTC driver"
+ depends on DM_RTC
+ depends on DM_I2C
+ help
+ If you say yes here you will get support for the
+ Analog Devices MAX313XX series RTC family.
+
config RTC_PCF8563
tristate "Philips PCF8563"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 447551e15aa2..adfa23f66702 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_RTC_HT1380) += ht1380.o
obj-$(CONFIG_SANDBOX) += i2c_rtc_emul.o
obj-$(CONFIG_RTC_ISL1208) += isl1208.o
obj-$(CONFIG_RTC_M41T62) += m41t62.o
+obj-$(CONFIG_RTC_MAX313XX) += max313xx.o
obj-$(CONFIG_RTC_MC13XXX) += mc13xxx-rtc.o
obj-$(CONFIG_RTC_MC146818) += mc146818.o
obj-$(CONFIG_MCFRTC) += mcfrtc.o
diff --git a/drivers/rtc/max313xx.c b/drivers/rtc/max313xx.c
new file mode 100644
index ..1aa430d121ee
--- /dev/null
+++ b/drivers/rtc/max313xx.c
@@ -0,0 +1,442 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Analog Devices MAX313XX series I2C RTC driver
+ *
+ * Copyright 2022 Analog Devices Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* common registers */
+#define MAX313XX_INT_ALARM1BIT(0)
+#define MAX313XX_INT_ALARM2BIT(1)
+#define MAX313XX_HRS_F_12_24 BIT(6)
+#define MAX313XX_HRS_F_AM_PM BIT(5)
+#define MAX313XX_MONTH_CENTURY BIT(7)
+
+#define MAX313XX_TMR_CFG_ENABLEBIT(4)
+#define MAX313XX_TMR_CFG_FREQ_MASK GENMASK(1, 0)
+#define MAX313XX_TMR_CFG_FREQ_16HZ 0x03
+
+#define MAX313XX_REG_MINUTE0x01
+#define MAX313XX_REG_HOUR 0x02
+
+#define MAX313XX_TIME_SIZE 0x07
+
+/* device specific registers */
+#define MAX3134X_CFG2_REG 0x01
+#define MAX3134X_CFG2_SET_RTC BIT(1)
+
+#define MAX31341_TRICKLE_RES_MASK GENMASK(1, 0)
+#define MAX31341_TRICKLE_DIODE_EN BIT(2)
+#define MAX31341_TRICKLE_ENABLE_BITBIT(3)
+#define MAX31341_POWER_MGMT_REG0x56
+#define MAX31341_POWER_MGMT_TRICKLE_BITBIT(0)
+
+#define MAX3133X_TRICKLE_RES_MASK GENMASK(2, 1)
+#define MAX3133X_TRICKLE_DIODE_EN BIT(3)
+#define MAX3133X_TRICKLE_ENABLE_BITBIT(0)
+
+#define MAX31329_TRICKLE_ENABLE_BITBIT(7)
+#define MAX31343_TRICKLE_ENABLE_MASK GENMASK(7, 4)
+#define MAX31343_TRICKLE_ENABLE_CODE 5
+#define MAX31329_43_TRICKLE_RES_MASK GENMASK(1, 0)
+#define MAX31329_43_TRICKLE_DIODE_EN BIT(2)
+
+#define MAX31329_CONFIG2_REG 0x04
+#define MAX31329_CONFIG2_CLKIN_EN BIT(2)
+#define MAX31329_CONFIG2_CLKIN_FREQGENMASK(1, 0)
+
+#define MAX31341_42_CONFIG1_REG0x00
+#define MAX31341_42_CONFIG1_CLKIN_EN BIT(7)
+#define MAX31341_42_CONFIG1_CLKIN_FREQ GENMASK(5, 4)
+#define MAX31341_42_CONFIG1_OSC_DISABLEBIT(3)
+#define MAX31341_42_CONFIG1_SWRST BIT(0)
+
+enum max313xx_ids {
+ ID_MAX31328,
+ ID_MAX31329,
+ ID_MAX31331,
+ ID_MAX31334,
+ ID_MAX31341,
+ ID_MAX31342,
+ ID_MAX31343,
+ MAX313XX_ID_NR
+};
+
+struct chip_desc {
+ struct clkout_cfg *clkout;
+ const char *clkout_name;
+ u8 sec_reg;
+ u8 alarm1_sec_reg;
+
+ u8 int_en_reg;
+ u8 int_status_reg;
+
+ u8 ram_reg;
+ u8 ram_size;
+
+ u8 temp_reg;
+
+ u8 trickle_reg;
+
+ u8 rst_reg;
+ u8 rst_bit;
+};
+
+struct max313xx {
+ enum max313xx_ids id;
+ const struct chip_desc *chip;
+};
+
+static const struct chip_desc chip[MAX313XX_ID_NR] = {
+ [ID_MAX31328] = {
+ .int_en_reg = 0x0E,
+ .int_status_reg = 0x0F,
+ .sec_reg = 0x00,
+ .alarm1_sec_reg = 0x07,
+ },
+ [ID_MAX31329] = {
+ .int_en_reg = 0x01,
+ .int_status_reg = 0x00,
+ .sec_reg = 0x06,
+ .alarm1_sec_reg = 0x0D,
+ .ram_reg = 0x22,
+ .ram_size = 64,
+ .trickle_reg = 0x19,
+ .rst_reg = 0x02,
+
[PATCH 1/2] include: kernel.h: port find_closest() from Linux
The find_closest() macro can be used to find an element in a sorted
array that is closest to an input value.
Signed-off-by: Chris Packham
---
include/linux/kernel.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3e71d61074b6..5cd6c9dc8219 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -284,4 +284,28 @@
offsetof(struct structure, member) == (offset), \
"`struct " #structure "` offset for `" #member "` is not " #offset)
+#define __find_closest(x, a, as, op) \
+({ \
+ typeof(as) __fc_i, __fc_as = (as) - 1; \
+ typeof(x) __fc_x = (x); \
+ typeof(*a) const *__fc_a = (a); \
+ for (__fc_i = 0; __fc_i < __fc_as; __fc_i++) { \
+ if (__fc_x op DIV_ROUND_CLOSEST(__fc_a[__fc_i] +\
+ __fc_a[__fc_i + 1], 2)) \
+ break; \
+ } \
+ (__fc_i); \
+})
+
+/**
+ * find_closest - locate the closest element in a sorted array
+ * @x: The reference value.
+ * @a: The array in which to look for the closest element. Must be sorted
+ * in ascending order.
+ * @as: Size of 'a'.
+ *
+ * Returns the index of the element closest to 'x'.
+ */
+#define find_closest(x, a, as) __find_closest(x, a, as, <=)
+
#endif
--
2.40.0
[PATCH 0/2] max313xx RTC driver
This series is based on the in-flight linux patch that is adding support for this family of RTCs to linux[1]. The u-boot driver is a bit different due to some of the differences between Linux and u-boot and I've dropped the support for hwmon and clock source functions. Where possible I've tried to keep things such that the U-Boot and Linux versions can be compared and kept in sync. [1] - https://lore.kernel.org/all/20221108122254.1185-2-ibrahim.ti...@analog.com/ Chris Packham (2): include: kernel.h: port find_closest() from Linux drivers: rtc: add max313xx series rtc driver drivers/rtc/Kconfig| 8 + drivers/rtc/Makefile | 1 + drivers/rtc/max313xx.c | 442 + include/linux/kernel.h | 24 +++ 4 files changed, 475 insertions(+) create mode 100644 drivers/rtc/max313xx.c -- 2.40.0
Re: [PATCH v2 5/5] test_vboot.py: include test of fdt_add_pubkey tool
Hi Ivan,
On Thu, 16 Mar 2023 at 08:45, Ivan Mikhaylov wrote:
>
> On Thu, 2023-03-16 at 07:59 -0600, Simon Glass wrote:
> > Hi Ivan,
> >
> > On Wed, 15 Mar 2023 at 19:17, Ivan Mikhaylov
> > wrote:
> > >
> > > On Fri, 2023-03-10 at 17:46 -0800, Simon Glass wrote:
> > > > Hi Ivan,
> > > >
> > > > On Tue, 7 Mar 2023 at 14:13, Ivan Mikhaylov
> > > > wrote:
> > > > >
> > > > > From: Roman Kopytin
> > > > >
> > > > > Signed-off-by: Roman Kopytin
> > > > > Cc: Rasmus Villemoes
> > > > > ---
> > > > > test/py/tests/test_vboot.py | 8
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/test/py/tests/test_vboot.py
> > > > > b/test/py/tests/test_vboot.py
> > > > > index e3e7ca4b21..956b8fcd43 100644
> > > > > --- a/test/py/tests/test_vboot.py
> > > > > +++ b/test/py/tests/test_vboot.py
> > > > > @@ -313,6 +313,13 @@ def test_vboot(u_boot_console, name,
> > > > > sha_algo,
> > > > > padding, sign_options, required,
> > > > >
> > > > > util.run_and_log(cons, [fit_check_sign, '-f', fit, '-
> > > > > k',
> > > > > dtb])
> > > > >
> > > > > +# Create a fresh .dtb without the public keys
> > > > > +dtc('sandbox-u-boot.dts')
> > > > > +# Then add the dev key via the fdt_add_pubkey tool
> > > > > +util.run_and_log(cons, [fdt_add_pubkey, '-a',
> > > > > '%s,rsa2048'
> > > > > % sha_algo,
> > > > > +'-k', tmpdir, '-n', 'dev', '-
> > > > > r',
> > > > > 'conf', dtb])
> > > > > +util.run_and_log(cons, [fit_check_sign, '-f', fit, '-
> > > > > k',
> > > > > dtb])
> > > > > +
> > > > > if full_test:
> > > > > # Make sure that U-Boot checks that the config is
> > > > > in
> > > > > the list of
> > > > > # hashed nodes. If it isn't, a security bypass is
> > > > > possible.
> > > > > @@ -500,6 +507,7 @@ def test_vboot(u_boot_console, name,
> > > > > sha_algo,
> > > > > padding, sign_options, required,
> > > > > mkimage = cons.config.build_dir + '/tools/mkimage'
> > > > > binman = cons.config.source_dir + '/tools/binman/binman'
> > > > > fit_check_sign = cons.config.build_dir +
> > > > > '/tools/fit_check_sign'
> > > > > +fdt_add_pubkey = cons.config.build_dir +
> > > > > '/tools/fdt_add_pubkey'
> > > > > dtc_args = '-I dts -O dtb -i %s' % tmpdir
> > > > > dtb = '%ssandbox-u-boot.dtb' % tmpdir
> > > > > sig_node = '/configurations/conf-1/signature'
> > > > > --
> > > > > 2.39.1
> > > > >
> > > >
> > > > Unfortunately this test fails on sandbox:
> > > >
> > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/591975
> > > >
> > > > I think it would be better to put it in its own test (perhaps in
> > > > the
> > > > same file) so we are not doing it on every test run. Also you
> > > > could
> > > > check (in a very basic way) that it adds the key correctly since
> > > > we
> > > > don't really need another test of the logic of doing that. We are
> > > > just
> > > > checking that your tool calls that logic correctly.
> > > >
> > > > I'll drop this one when applying, for now. Please take a look.
> > > >
> > > > Regards,
> > > > Simon
> > >
> > > Simon, does it look ok? Test for test_vboot is passed fine.
> >
> > Please see my message before:
> >
> > > Unfortunately this test fails on sandbox:
> > >
> > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/591975
> > >
> > > I think it would be better to put it in its own test (perhaps in
> > > the
> > > same file) so we are not doing it on every test run. Also you could
> > > check (in a very basic way) that it adds the key correctly since we
> > > don't really need another test of the logic of doing that. We are
> > > just
> > > checking that your tool calls that logic correctly.
> > >
> > > I'll drop this one when applying, for now. Please take a look.
> >
> > I have not applied this patch due to the problem.
> >
> > Regards,
> > Simon
> >
>
> Simon, but I've changed the test and put it in previous note, maybe you
> didn't notice, I did what you asked:
> - made own test "test_fdt_add_pubkey"
> - simple check that with clear dtb you can add keys with fdt_add_pubkey
> and check with fit_check_sign with signed fit.
>
> I've checked that change with sandbox and it passes test_vboot well.
>
> Need I re-submit that patch or whole series?
OK, great. Yes please send that patch by itself (rebased to
u-boot-dm/next) so it is picked up by patchwork. You'll find the rest
of your patches in dm/next but they have not made it upstream yet.
Regards,
Simon
>
> Thanks.
>
> >
> >
> > >
> > > Thanks.
> > >
> > > From 5484d525d4950b064adf1204f5bf055229c942ac Mon Sep 17 00:00:00
> > > 2001
> > > From: Roman Kopytin
> > > Date: Thu, 11 Nov 2021 11:15:12 +0300
> > > Subject: [PATCH v3] test_vboot.py: include test of fdt_add_pubkey
> > > tool
> > >
> > > Signed-off-by: Roman Kopytin
> > > Signed-off-by: Ivan Mikhaylov
> > > Cc: Rasmus Villemoes
> > > ---
> > > test/py/tests/test_vboot.py | 33
Re: [GIT PULL] xilinx patches for v2023.07-rc1
On Wed, Mar 15, 2023 at 02:07:30PM +0100, Michal Simek wrote: > Hi Tom, > > please pull these patches to your next branch. CI loop doesn't report any > issue. > > Thanks, > Michal > > The following changes since commit 70ed05ce6c051e55e126e67e72ab20409134c953: > > Merge tag 'next-20230307' of > https://source.denx.de/u-boot/custodians/u-boot-video into next (2023-03-07 > 12:54:01 -0500) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2023.07-rc1 > > for you to fetch changes up to 7ac50f88f8a9374e5cb4bc2a88c002d02ef3c570: > > microblaze: drop remnants of manual reloc (2023-03-13 11:46:17 +0100) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] please pull fsl-qoriq-next for next
On Tue, Mar 14, 2023 at 10:16:22AM +, Peng Fan wrote: > Hi Tom, > > Please pull fsl-qoriq-next-2023-3-14 for next > CI: > https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq/-/pipelines/15599 Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Revert 9f62a472dfb2 ("video: Remove duplicate cursor-positioning function")
On Wed, Mar 15, 2023 at 10:23:34AM -0600, Simon Glass wrote: > On Wed, 15 Mar 2023 at 10:01, Tom Rini wrote: > > > > This reverts commit 9f62a472dfb26ec14408a27938ddd2a2579d. > > > > The changes here aren't quite right, and on platforms such as Raspberry > > Pi where we can have both serial and video output, the change above > > causes output to change. This can be seen as the hush tests we have now > > fail. > > > > Signed-off-by: Tom Rini > > --- > > Cc: Simon Glass > > > > Some other issues in my lab meant I thought I had tested this platform > > when I took the PR in originally, but hadn't. So I'd like to grab this > > ASAP. > > --- > > drivers/video/vidconsole-uclass.c | 44 --- > > 1 file changed, 34 insertions(+), 10 deletions(-) > > > > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-dm/next
On Sun, Mar 12, 2023 at 09:10:19PM -0600, Simon Glass wrote: > Hi Tom, > > This is for the -next branch > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/15568 > > The following changes since commit bcf343146ff365a88481b9a80920ed146c6dee5b: > > Merge tag 'dm-next-9mar23' of > https://source.denx.de/u-boot/custodians/u-boot-dm into next > (2023-03-09 11:22:50 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-next-12mar23 > > for you to fetch changes up to 7bb28330f7b4d20bcf844ec306dcfbb41296cfa8: > > buildman: Fix CROSS_COMPILE output for sandbox (2023-03-12 11:37:34 -0600) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] board_r: Relocate OF_EMBED if NEEDS_MANUAL_RELOC only
On Thu, Mar 16, 2023 at 12:54:10AM +0530, Ajay Kaher wrote: > > On Fri, Sep 09, 2022 at 09:16:18PM +0100, Pierre-Clément Tosi wrote: > > > >> When the embedded device tree is pointed to by the __dtb_dt_*begin > >> symbols, it seems to be covered by the early relocation code and doesn't > >> need to be manually patched. > >> > >> Cc: Simon Glass > >> Signed-off-by: Pierre-Clément Tosi > > > > Applied to u-boot/master, thanks! > > Getting following error on Rpi3 board and fail to boot with u-boot upstream > commit 76f921eb95d5b814f973a263187db509d6f03903: Please give https://patchwork.ozlabs.org/project/uboot/patch/20230228155605.1209559-1-pbrobin...@gmail.com/ a try and see if things act as you expect, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: kirkwood: pogo v4: Use a more common format for stdout-path
On Wednesday 15 March 2023 16:11:27 Tony Dinh wrote:
> Hi Pali,
>
> On Wed, Mar 15, 2023 at 2:58 PM Pali Rohár wrote:
> >
> > On Wednesday 15 March 2023 14:56:52 Tony Dinh wrote:
> > > The mainline Pogo V4 DTS uses a stdout-path format that is not
> > > recognizable by u-boot. Change it to a commonly used format.
> >
> > Cannot we teach u-boot to understand also currently used format?
>
> I assume it is good to document the fact that perhaps using
> dm-pre-reloc tag (and later boot-phase tag) will overcome many odd
> properties format in Linux DTS. We said dm-pre-reloc is a workaround,
> but IMHO the tags are really good for u-boot, since u-boot is a
> multi-phase boot loader. If a device like UART is needed in a certain
> phase, we should say so.
>
> Also at the moment, modifying the serial-uclass.c is something more
> than I can chew. If I must do it myself, it will be a while. If
> anybody wants to give it a try, please do so.
Simon could help there?
> Thanks,
> Tony
>
> > > Note that this patch removes the previous workaround for this board
> > > as discussed here:
> > > https://lists.denx.de/pipermail/u-boot/2023-February/508936.html
> > >
> > > Signed-off-by: Tony Dinh
> > > ---
> > >
> > > arch/arm/dts/kirkwood-pogoplug-series-4-u-boot.dtsi | 9 ++---
> > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4-u-boot.dtsi
> > > b/arch/arm/dts/kirkwood-pogoplug-series-4-u-boot.dtsi
> > > index f9e127234c..9bb97c6b6b 100644
> > > --- a/arch/arm/dts/kirkwood-pogoplug-series-4-u-boot.dtsi
> > > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4-u-boot.dtsi
> > > @@ -1,7 +1,10 @@
> > > // SPDX-License-Identifier: GPL-2.0+
> > > /*
> > > * Copyright (C) 2023 Tony Dinh
> > > - */
> > > - {
> > > - u-boot,dm-pre-reloc;
> > > +*/
> > > +
> > > +/ {
> > > + chosen {
> > > + stdout-path =
> > > + };
> > > };
> > > --
> > > 2.30.2
> > >
Re: [PATCH v3 0/5] improve 'read' command, add 'write' command
On Thu, Mar 16, 2023 at 02:24:05PM +0100, Rasmus Villemoes wrote: > On 02/03/2023 09.12, Rasmus Villemoes wrote: > > The first patch simplies do_read somewhat by making use of an existing > > helper instead of parsing the dev_part string manually. As a bonus > > (and my actual motivation), it now understands dev#partname syntax - > > hard-coded partition numbers are so last decade. > > > > I also need the symmetrical operation, being able to write to a named > > raw partition, and fortunately it doesn't require that many lines of > > code to implement that. > > > > There's a very minor change in the error reporting due to using > > cmdtp->name to generate the new messages, but I don't think "Error > > reading blocks" offers much that "read error" doesn't. > > > > New in v2: the last three patches add documentation, ensure CMD_WRITE > > is set for sandbox and adds some basic test cases for the various ways > > of accessing the partitions (by number, name, or as raw offset within > > the whole disk). > > > > v3: Add Simon's R-b to patches 2, 4, 5, fixup whitespace in patch 5. > > Can this series be picked up for -next, please? Yes. Getting out of a backlog now due to some lab issues. -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] rockchip: Disable DISTRO_DEFAULTS for rockpro64
On Thu, Mar 16, 2023 at 11:01:01AM +, Peter Robinson wrote: > On Wed, Feb 22, 2023 at 7:17 PM Tom Rini wrote: > > > > On Wed, Feb 22, 2023 at 12:03:58PM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 22 Feb 2023 at 12:01, Tom Rini wrote: > > > > > > > > On Wed, Feb 22, 2023 at 11:58:37AM -0700, Simon Glass wrote: > > > > > Hi, > > > > > > > > > > On Wed, 22 Feb 2023 at 11:56, Jonas Karlman wrote: > > > > > > > > > > > > On 2023-02-22 19:24, Tom Rini wrote: > > > > > > > On Wed, Feb 22, 2023 at 10:19:03AM -0800, Vagrant Cascadian wrote: > > > > > > >> On 2023-02-21, Vagrant Cascadian wrote: > > > > > > >>> On 2023-02-21, Simon Glass wrote: > > > > > > This board has moved to standard boot but the old > > > > > > 'distro_bootcmd' > > > > > > command is still active. Disable DISTRO_DEFAULTS to fix this. > > > > > > >>> > > > > > > >>> Works for booting rockpro64-rk3399, thanks! > > > > > > >> > > > > > > >> I can also confirm that applying a very similar patch for > > > > > > >> pinebook-pro-rk3399 works booting with bootstd. > > > > > > >> > > > > > > >> Seems worth adding if there is a v2 of the patch series. > > > > > > >> > > > > > > >> Alternately, rather than doing this on a board-by-board basis, > > > > > > >> is there > > > > > > >> some way to disable CONFIG_DISTRO_DEFAULTS when a board is using > > > > > > >> BOOTSTD? > > > > > > > > > > > > > > I think that's possibly a bit dangerous? DISTRO_DEFAULTS and > > > > > > > BOOTSTD_DEFAULTS need to be reconciled to a single new symbol, > > > > > > > and the > > > > > > > DISTRO_DEFAULTS method of select not imply for most things is > > > > > > > also I > > > > > > > suspect the right path. > > > > > > > > > > > > > > > > > > > Another option would be to set BOOTSTD_BOOTCOMMAND=y, this is the > > > > > > main > > > > > > issue with rk3399 at the moment, distro_bootcmd got removed from > > > > > > env, > > > > > > yet bootcmd is still "run distro_bootcmd" due to DISTRO_DEFAULTS=y. > > > > > > > > > > > > > > > > > > config BOOTCOMMAND > > > > > > default "bootflow scan -lb" if BOOTSTD_BOOTCOMMAND && > > > > > > CMD_BOOTFLOW_FULL > > > > > > default "bootflow scan" if BOOTSTD_BOOTCOMMAND && > > > > > > !CMD_BOOTFLOW_FULL > > > > > > default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && > > > > > > DISTRO_DEFAULTS > > > > > > > > > > > > config BOOTSTD_BOOTCOMMAND > > > > > > default y if !DISTRO_DEFAULTS > > > > > > > > > > That seems reasonable to me, along with a 'depends on BOOTSTD' > > > > > > > > > > At present DISTRO_DEFAULTS is both enabled in defconfig files (about > > > > > 350) and Kconfig (another 300). For rockchip it is the latter. > > > > > > > > > > It doesn't really make sense to use DISTRO_DEFAULTS when using > > > > > BOOTSTD_DEFAULTS. One is 'run distro_bootcmd' and the other is > > > > > 'bootflow scan', possibly with -lb flags. But we really don't want > > > > > people flipping back and forward. > > > > > > > > It doesn't make linguistic sense to have "distro defaults" and "bootstd > > > > defaults" enabled. It makes compute sense to have these two symbols > > > > combined as they're nearly identical and have a similar conceptual need > > > > (make sure we have things like bootz/booti/ext4/etc support). > > > > > > Oh, so you are talking about DISTRO_DEFAULTS, not the actual command? > > > In that case I can do a patch to make them both use a common symbol to > > > bring in most stuff, although bootstd does not need hush and a few > > > other things that are needed by distro_bootcmd. > > > > > > Let me know if that makes sense. > > > > Yeah, the Kconfig symbols DISTRO_DEFAULTS and BOOTSTD_DEFAULTS need to > > be reconciled and combined. This is separate from setting bootcmd to > > "run distro_bootcmd", which should be separate, and yes, not be the > > chosen symbol when we have bootstd enabled. > > What came out of this decision, the first other rk3399 device I tried, > the rock960, is also broken booting. We really can't have devices > randomly broken all the time and I don't have the time or the devices > to go through and test everything. We should really be getting better > at these mass changes, it doesn't lead to a great user experience! Part of the problem is that Rockchip had a few issues at the end of the last cycle and then the start of this one. Another issue is that I don't have a Rockchip platform in my CI loop, but I'm hoping to fix that in the next week or so. Is top of tree working on your platforms or no? They should be, at this point. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 3/4] Kconfig: j721e: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region
On Wed, Mar 15, 2023 at 12:18:54PM +0530, Manorit Chawdhry wrote:
> On 14:01-20230306, Tom Rini wrote:
> > On Mon, Mar 06, 2023 at 11:12:53AM +0530, Manorit Chawdhry wrote:
> > > In non-combined boot flow for K3, all the firewalls are locked by default
> > > until sysfw comes up. Rom configures some of the firewall for its usage
> > > along with the SRAM for R5 but the PSRAM region is still locked.
> > >
> > > The K3 MCU Scratchpad for j721e was set to a PSRAM region triggering the
> > > firewall exception before sysfw came up. The exception started happening
> > > after adding multi dtb support that accesses the scratchpad for reading
> > > EEPROM contents.
> > >
> > > The commit changes R5 MCU scratchpad for j721e to an SRAM region.
> > >
> > > Old Map:
> > > ┌─┐ 0x41c0
> > > │ SPL │
> > > ├─┤ 0x41c4 (approx)
> > > │STACK│
> > > ├─┤ 0x41c85b20
> > > │ Global data │
> > > │ sizeof(struct global_data) = 0xd8 │
> > > ├─┤ gd->malloc_base = 0x41c85bfc
> > > │HEAP │
> > > │ CONFIG_SYS_MALLOC_F_LEN = 0x7 │
> > > ├─┤ CONFIG_SPL_BSS_START_ADDR
> > > │ SPL BSS │ (0x41cf5bfc)
> > > │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
> > > └─┘
> > > CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
> > > (0x41cffbfc)
> > >
> > > New Map:
> > > ┌─┐ 0x41c0
> > > │ SPL │
> > > ├─┤ 0x41c4 (approx)
> > > │EMPTY│
> > > ├─┤ 0x41c81920
> > > │STACK│
> > > │ SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000 │
> > > ├─┤ 0x41c85920
> > > │ Global data │
> > > │ sizeof(struct global_data) = 0xd8 │
> > > ├─┤ gd->malloc_base = 0x41c859f0
> > > │HEAP │
> > > │ CONFIG_SYS_MALLOC_F_LEN = 0x7 │
> > > ├─┤ CONFIG_SPL_BSS_START_ADDR
> > > │ SPL BSS │ (0x41cf59f0)
> > > │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
> > > ├─┤ 0x41cff9fc
> > > │ NEW MCU SCRATCHPAD │
> > > │ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │
> > > └─┘
> > > CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
> > > (0x41cffbfc)
> > >
> > > Fixes: ab977c8b91b4 ("configs: j721s2_evm_r5: Enable support for building
> > > multiple dtbs into FIT")
> > >
> > > Signed-off-by: Manorit Chawdhry
> > > [n-fran...@ti.com: SRAM allocation addressing diagram]
> > > Signed-off-by: Neha Francis
> > > Reviewed-by: Tom Rini
> > > Reviewed-by: Kamlesh Gurudasani
> > > ---
> > > arch/arm/mach-k3/Kconfig | 3 ++-
> > > configs/j721e_evm_r5_defconfig | 10 --
> > > doc/board/ti/j721e_evm.rst | 27 +++
> >
> > OK, but now this just renders differently poorly. Please see the
> > list-table directive as used for example in doc/board/apple/m1.rst and
> > it would be good to get other ascii tables updated to produce nice
> > output as well.
> >
>
> Hi Tom,
>
> I've updated this table in v5, we can look at updating other tables
> later.
Sounds good, thanks.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 1/3] include: environment: ti: Use .env for environment variables
On Wed, Mar 15, 2023 at 10:57:43AM +0530, Neha Malcom Francis wrote: > Add K3 common environment variables to .env. We retain the old-style C > environment .h files to maintain compatibility with other K3 boards that > have not moved to using .env yet. > > Signed-off-by: Neha Malcom Francis Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: kirkwood: pogo v4: Use a more common format for stdout-path
On Wed, Mar 15, 2023 at 04:11:27PM -0700, Tony Dinh wrote: > Hi Pali, > > On Wed, Mar 15, 2023 at 2:58 PM Pali Rohár wrote: > > > > On Wednesday 15 March 2023 14:56:52 Tony Dinh wrote: > > > The mainline Pogo V4 DTS uses a stdout-path format that is not > > > recognizable by u-boot. Change it to a commonly used format. > > > > Cannot we teach u-boot to understand also currently used format? > > I assume it is good to document the fact that perhaps using > dm-pre-reloc tag (and later boot-phase tag) will overcome many odd > properties format in Linux DTS. We said dm-pre-reloc is a workaround, > but IMHO the tags are really good for u-boot, since u-boot is a > multi-phase boot loader. If a device like UART is needed in a certain > phase, we should say so. > > Also at the moment, modifying the serial-uclass.c is something more > than I can chew. If I must do it myself, it will be a while. If > anybody wants to give it a try, please do so. Note that the boot phase tags are now upstream, so those dts changes can also go upstream now. -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/2] add support for hs bootflows on am62 devices
On Thu, Mar 16, 2023 at 04:05:06PM +0530, Kamlesh Gurudasani wrote: > Bryan Brattlof writes: > > > Hi Kamlesh! > > > > On March 2, 2023 thus sayeth kaml...@ti.com: > >> From: Kamlesh Gurudasani > >> > >> Add support for high security bootflow on am62 devices. > >> > >> On HS devices, ROM and TIFS will protect the RAM regions with > >> firewalls. This means the wakeup domain's SPL will need to move the > >> stack and heap to HSM RAM to ensure it stays within its allotted > >> memory regions. > >> > >> Kamlesh Gurudasani (2): > >> arm: mach-k3: am62: move scratch board area to HSM RAM > >> configs: am62: move stack and heap to HSM RAM > >> > >> arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +-- > >> configs/am62x_evm_r5_defconfig| 16 +++- > >> 2 files changed, 12 insertions(+), 7 deletions(-) > > > > Thanks for getting this fixed! Does TIFS drop the On Chip SRAM firewall > > completely once it's started? or only for the r5? > > > > Reviewed-by: Bryan Brattlof > > > > ~Bryan > Hi Tom, > > Could you please review and merge this patches as these are bug fixes to > get HS devices working. Is this a regression fix vs v2023.01 or new feature support? Thanks. -- Tom signature.asc Description: PGP signature
[PATCH] board: rockchip: add Anbernic RGXX3 Series Devices
From: Chris Morgan
The Anbernic RGxx3 is a "pseudo-device" that encompasses the following
devices:
- Anbernic RG353M
- Anbernic RG353P
- Anbernic RG353V
- Anbernic RG353VS
- Anbernic RG503
The rk3566-anbernic-rgxx3.dtsi is synced with upstream Linux, but
rk3566-anbernic-rgxx3.dts is a U-Boot specific devicetree that
is used for all RGxx3 devices.
Via the board.c file, the bootloader automatically sets the correct
fdtfile, board, and board_name environment variables so that the
correct devicetree can be passed to Linux. It is also possible to
simply hard-code a single devicetree in the boot.scr file and use
that to load Linux as well.
The common specifications for each device are:
- Rockchip RK3566 SoC
- 2 external SDMMC slots
- 1 USB-C host port, 1 USB-C peripheral port
- 1 mini-HDMI output
- MIPI-DSI based display panel
- ADC controlled joysticks with a GPIO mux
- GPIO buttons
- A PWM controlled vibrator
- An ADC controlled button
All of the common features are defined in the devicetree synced from
upstream Linux.
TODO: DSI panel auto-detection for the RG353 devices (requires porting
of DSI controller driver and DSI-DPHY driver to send DSI commands to
the panel).
Signed-off-by: Chris Morgan
---
arch/arm/dts/Makefile | 1 +
.../arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi | 85 ++
arch/arm/dts/rk3566-anbernic-rgxx3.dts| 18 +
arch/arm/dts/rk3566-anbernic-rgxx3.dtsi | 786 ++
arch/arm/mach-rockchip/rk3568/Kconfig | 14 +
board/anbernic/rgxx3_rk3566/Kconfig | 15 +
board/anbernic/rgxx3_rk3566/MAINTAINERS | 6 +
board/anbernic/rgxx3_rk3566/Makefile | 6 +
board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c| 203 +
configs/anbernic-rgxx3_defconfig | 78 ++
doc/board/anbernic/index.rst | 9 +
doc/board/anbernic/rgxx3.rst | 47 ++
doc/board/index.rst | 1 +
doc/board/rockchip/rockchip.rst | 3 +
include/configs/anbernic-rgxx3-rk3566.h | 12 +
15 files changed, 1284 insertions(+)
create mode 100644 arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3566-anbernic-rgxx3.dts
create mode 100644 arch/arm/dts/rk3566-anbernic-rgxx3.dtsi
create mode 100644 board/anbernic/rgxx3_rk3566/Kconfig
create mode 100644 board/anbernic/rgxx3_rk3566/MAINTAINERS
create mode 100644 board/anbernic/rgxx3_rk3566/Makefile
create mode 100644 board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
create mode 100644 configs/anbernic-rgxx3_defconfig
create mode 100644 doc/board/anbernic/index.rst
create mode 100644 doc/board/anbernic/rgxx3.rst
create mode 100644 include/configs/anbernic-rgxx3-rk3566.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index c160e884bf..74dd55f700 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -165,6 +165,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399pro-rock-pi-n10.dtb
dtb-$(CONFIG_ROCKCHIP_RK3568) += \
+ rk3566-anbernic-rgxx3.dtb \
rk3568-evb.dtb \
rk3566-radxa-cm3-io.dtb \
rk3568-rock-3a.dtb
diff --git a/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
b/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
new file mode 100644
index 00..2ae8186228
--- /dev/null
+++ b/arch/arm/dts/rk3566-anbernic-rgxx3-u-boot.dtsi
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+
+ rng: rng@fe388000 {
+ compatible = "rockchip,cryptov2-rng";
+ reg = <0x0 0xfe388000 0x0 0x2000>;
+ status = "okay";
+ };
+};
+
+ {
+ assigned-clocks =
+ < CLK_RTC_32K>,
+ < PLL_PPLL>,
+ < PCLK_PMU>, < PLL_CPLL>,
+ < PLL_GPLL>,
+ < ACLK_BUS>, < PCLK_BUS>,
+ < ACLK_TOP_HIGH>, < ACLK_TOP_LOW>,
+ < HCLK_TOP>, < PCLK_TOP>,
+ < ACLK_PERIMID>, < HCLK_PERIMID>,
+ < CPLL_500M>, < CPLL_333M>,
+ < CPLL_250M>, < CPLL_125M>,
+ < CPLL_100M>, < CPLL_62P5M>,
+ < CPLL_50M>, < CPLL_25M>;
+ assigned-clock-rates =
+ <32768>,
+ <2>,
+ <1>, <10>,
+ <118800>,
+ <15000>, <1>,
+ <5>, <4>,
+ <15000>, <1>,
+ <3>, <15000>,
+ <5>, <3>,
+ <25000>, <12500>,
+ <1>, <6250>,
+ <5000>,
[QUESTION] Device tree for gmii-to-rgmii phy driver
Hi Siva Durga Prasad Paladugu,
we want to add rgmii-id support to the gmiitorgmii phy driver. How does
the correct device tree for the gmiitorgmii looks like? The converter
sits between the MAC and the external PHY (MAC <==> GMII2RGMII <==>
RGMII_PHY) which would mean that the phy-handle of the MAC should point
to the GMII2RGMII and the GMII2RGMII to RGMII_PHY:
{
phy-handle = <>;
phy-mode = "gmii";
mdio {
ethphy0: ethernet-phy@1 {
};
gmiitorgmii0: gmiitorgmii@8 {
compatible = "xlnx,gmii-to-rgmii-1.0";
phy-handle = <>;
phy-mode = "rgmii-id";
};
};
};
This device tree snippet does not work in the kernel. The kernel
gmii2rgmii driver does not use a phy driver as base and manipulates the
functions of the external phy object instead. It requires the following
device tree snippet:
{
phy-handle = <>;
phy-mode = "rgmii-id";
mdio {
ethphy0: ethernet-phy@1 {
};
gmiitorgmii0: gmiitorgmii@8 {
compatible = "xlnx,gmii-to-rgmii-1.0";
phy-handle = <>;
phy-mode = "rgmii-id";
};
};
};
This does not work in u-boot because the phy framework ignores the
phy-handle of the MAC for the gmii2rgmii but the gmii2rgmii driver
itself checks the phy-mode of the MAC.
What is the correct device tree and thereby proper implementation?
Regards
Stefan
[PATCH v1 6/6] rockchip: configs: mk808: enable usb support
Enable usb support in the mk808_defconfig. Signed-off-by: Johan Jonker --- configs/mk808_defconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/configs/mk808_defconfig b/configs/mk808_defconfig index 548df9c5..3e9bdb14 100644 --- a/configs/mk808_defconfig +++ b/configs/mk808_defconfig @@ -53,6 +53,9 @@ CONFIG_SYS_PBSIZE=276 # CONFIG_BOOTM_VXWORKS is not set CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +CONFIG_CMD_ROCKUSB=y +CONFIG_CMD_USB_MASS_STORAGE=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y @@ -78,6 +81,7 @@ CONFIG_TPL_SYSCON=y CONFIG_CLK=y CONFIG_SPL_CLK=y CONFIG_TPL_CLK=y +CONFIG_FASTBOOT_BUF_ADDR=0x8000 CONFIG_ROCKCHIP_GPIO=y # CONFIG_SPL_DM_I2C is not set CONFIG_LED=y @@ -106,6 +110,12 @@ CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_TPL_TIMER=y CONFIG_DESIGNWARE_APB_TIMER=y +CONFIG_USB=y +CONFIG_USB_DWC2=y +CONFIG_ROCKCHIP_USB2_PHY=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_FUNCTION_ROCKUSB=y CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y # CONFIG_TPL_OF_LIBFDT is not set -- 2.20.1
[PATCH v1 5/6] rockchip: configs: mk808: change CONFIG_TPL_TEXT_BASE
Currently the Rockchip rk3066a u-boot-tpl.bin file needs to add the characters "RK30", while the other SoCs replace the first 4 bytes. Bring this in line with the rest by lowering CONFIG_TPL_TEXT_BASE and update rockchip.rst instructions. Signed-off-by: Johan Jonker Reviewed-by: Simon Glass --- configs/mk808_defconfig | 2 +- doc/board/rockchip/rockchip.rst | 7 +++ 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/configs/mk808_defconfig b/configs/mk808_defconfig index c080706d..548df9c5 100644 --- a/configs/mk808_defconfig +++ b/configs/mk808_defconfig @@ -18,7 +18,7 @@ CONFIG_SPL_TEXT_BASE=0x6000 CONFIG_DM_RESET=y CONFIG_ROCKCHIP_RK3066=y # CONFIG_ROCKCHIP_STIMER is not set -CONFIG_TPL_TEXT_BASE=0x10080C04 +CONFIG_TPL_TEXT_BASE=0x10080C00 CONFIG_TPL_STACK=0x1008 CONFIG_TARGET_MK808=y CONFIG_SPL_STACK_R_ADDR=0x7000 diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index b5563b8f..7d903946 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -380,9 +380,8 @@ Program with commands in a bash script ./flash.sh: #!/bin/sh -printf "RK30" > tplspl.bin -dd if=u-boot-tpl.bin >> tplspl.bin -truncate -s %2048 tplspl.bin +printf "RK30" | dd conv=notrunc bs=4 count=1 of=u-boot-tpl.bin +truncate -s %2048 u-boot-tpl.bin truncate -s %2048 u-boot-spl.bin ../tools/boot_merger --verbose config-flash.ini ../tools/upgrade_tool ul ./RK30xxLoader_uboot.bin @@ -406,7 +405,7 @@ config-flash.ini: NUM=2 LOADER1=FlashData LOADER2=FlashBoot -FlashData=tplspl.bin +FlashData=u-boot-tpl.bin FlashBoot=u-boot-spl.bin [OUTPUT] PATH=RK30xxLoader_uboot.bin -- 2.20.1
[PATCH v1 4/6] arm: dts: rockchip: sync rk3066/rk3188 DT files from linux-next v6.2-rc4
Sync rk3066/rk3188 DT files from Linux.
This is the state as of linux-next v6.2-rc4.
New nfc node for MK808 rk3066a.
CRU nodes now have a clock property.
To prefend dtoc errors a fixed clock must also be
included for tpl/spl in the rk3xxx-u-boot.dtsi file.
Signed-off-by: Johan Jonker
---
arch/arm/dts/rk3066a-mk808.dts| 27 ++-
arch/arm/dts/rk3066a.dtsi | 3 ++-
arch/arm/dts/rk3188-radxarock.dts | 24 +---
arch/arm/dts/rk3188.dtsi | 27 ---
arch/arm/dts/rk3xxx-u-boot.dtsi | 4
arch/arm/dts/rk3xxx.dtsi | 9 +++--
6 files changed, 68 insertions(+), 26 deletions(-)
diff --git a/arch/arm/dts/rk3066a-mk808.dts b/arch/arm/dts/rk3066a-mk808.dts
index 667d57a4..06790f05 100644
--- a/arch/arm/dts/rk3066a-mk808.dts
+++ b/arch/arm/dts/rk3066a-mk808.dts
@@ -32,7 +32,7 @@
keyup-threshold-microvolt = <250>;
poll-interval = <100>;
- recovery {
+ button-recovery {
label = "recovery";
linux,code = ;
press-threshold-microvolt = <0>;
@@ -157,7 +157,32 @@
pinctrl-0 = <_clk _cmd _bus4>;
pinctrl-names = "default";
vmmc-supply = <_wifi>;
+ #address-cells = <1>;
+ #size-cells = <0>;
status = "okay";
+
+ brcmf: wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ };
+};
+
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ nand@0 {
+ reg = <0>;
+ label = "rk-nand";
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-ecc-step-size = <1024>;
+ nand-ecc-strength = <40>;
+ nand-is-boot-medium;
+ rockchip,boot-blks = <8>;
+ rockchip,boot-ecc-strength = <24>;
+ };
};
{
diff --git a/arch/arm/dts/rk3066a.dtsi b/arch/arm/dts/rk3066a.dtsi
index c25b9695..de9915d9 100644
--- a/arch/arm/dts/rk3066a.dtsi
+++ b/arch/arm/dts/rk3066a.dtsi
@@ -202,8 +202,9 @@
cru: clock-controller@2000 {
compatible = "rockchip,rk3066a-cru";
reg = <0x2000 0x1000>;
+ clocks = <>;
+ clock-names = "xin24m";
rockchip,grf = <>;
-
#clock-cells = <1>;
#reset-cells = <1>;
assigned-clocks = < PLL_CPLL>, < PLL_GPLL>,
diff --git a/arch/arm/dts/rk3188-radxarock.dts
b/arch/arm/dts/rk3188-radxarock.dts
index e7138a4a..118deacd 100644
--- a/arch/arm/dts/rk3188-radxarock.dts
+++ b/arch/arm/dts/rk3188-radxarock.dts
@@ -6,7 +6,6 @@
/dts-v1/;
#include
#include "rk3188.dtsi"
-#include "rk3188-radxarock-u-boot.dtsi"
/ {
model = "Radxa Rock";
@@ -25,7 +24,7 @@
compatible = "gpio-keys";
autorepeat;
- power {
+ key-power {
gpios = < RK_PA4 GPIO_ACTIVE_LOW>;
linux,code = ;
label = "GPIO Key Power";
@@ -72,7 +71,7 @@
#sound-dai-cells = <0>;
};
- ir_recv: gpio-ir-receiver {
+ ir_recv: ir-receiver {
compatible = "gpio-ir-receiver";
gpios = < RK_PB2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
@@ -127,18 +126,21 @@
};
{
- status = "okay";
-
+ phy = <>;
+ phy-supply = <_rmii>;
pinctrl-names = "default";
pinctrl-0 = <_xfer>, <_mdio>, <_int>;
+ status = "okay";
- phy = <>;
- phy-supply = <_rmii>;
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
- phy0: ethernet-phy@0 {
- reg = <0>;
- interrupt-parent = <>;
- interrupts = ;
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
};
diff --git a/arch/arm/dts/rk3188.dtsi b/arch/arm/dts/rk3188.dtsi
index 9a80f83a..44b54af0 100644
--- a/arch/arm/dts/rk3188.dtsi
+++ b/arch/arm/dts/rk3188.dtsi
@@ -54,7 +54,7 @@
};
};
- cpu0_opp_table: opp_table0 {
+ cpu0_opp_table: opp-table-0 {
compatible = "operating-points-v2";
opp-shared;
@@ -195,8 +195,9 @@
cru: clock-controller@2000 {
compatible = "rockchip,rk3188-cru";
reg = <0x2000 0x1000>;
+ clocks = <>;
+ clock-names = "xin24m";
rockchip,grf = <>;
-
#clock-cells = <1>;
#reset-cells = <1>;
};
@@ -223,7 +224,7 @@
#size-cells = <1>;
ranges;
- gpio0: gpio0@2000a000 {
+ gpio0: gpio@2000a000 {
[PATCH v1 3/6] arm: dts: rockchip: rk3188-u-boot: add gpio-ranges
The gpio node names are made generic, but without
gpio bank ID. Add gpio-ranges to rk3188-u-boot.dtsi
for now till a better method is found.
Signed-off-by: Johan Jonker
---
arch/arm/dts/rk3188-u-boot.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/rk3188-u-boot.dtsi b/arch/arm/dts/rk3188-u-boot.dtsi
index 735776c1..176f9e65 100644
--- a/arch/arm/dts/rk3188-u-boot.dtsi
+++ b/arch/arm/dts/rk3188-u-boot.dtsi
@@ -12,6 +12,19 @@
{
compatible = "rockchip,gpio-bank";
+ gpio-ranges = < 0 0 32>;
+};
+
+ {
+ gpio-ranges = < 0 32 32>;
+};
+
+ {
+ gpio-ranges = < 0 64 32>;
+};
+
+ {
+ gpio-ranges = < 0 96 32>;
};
{
--
2.20.1
[PATCH v1 2/6] arm: dts: rockchip: rk3066a-u-boot: add gpio-ranges
The gpio node names are made generic, but without
gpio bank ID. Add gpio-ranges to rk3066a-u-boot.dtsi
for now till a better method is found.
Signed-off-by: Johan Jonker
---
arch/arm/dts/rk3066a-u-boot.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/dts/rk3066a-u-boot.dtsi b/arch/arm/dts/rk3066a-u-boot.dtsi
index bc6e609d..8d4e1ad2 100644
--- a/arch/arm/dts/rk3066a-u-boot.dtsi
+++ b/arch/arm/dts/rk3066a-u-boot.dtsi
@@ -2,3 +2,28 @@
#include "rockchip-u-boot.dtsi"
#include "rk3xxx-u-boot.dtsi"
+
+ {
+ gpio-ranges = < 0 0 32>;
+};
+
+ {
+ gpio-ranges = < 0 32 32>;
+};
+
+ {
+ gpio-ranges = < 0 64 32>;
+};
+
+ {
+ gpio-ranges = < 0 96 32>;
+};
+
+ {
+ gpio-ranges = < 0 128 32>;
+};
+
+ {
+ gpio-ranges = < 0 192 32>;
+};
+
--
2.20.1
[PATCH v1 1/6] rockchip: gpio: rk_gpio: use ROCKCHIP_GPIOS_PER_BANK as divider
The current divider to calculate the bank ID can change.
Use a constant ROCKCHIP_GPIOS_PER_BANK as fixed divider.
Signed-off-by: Johan Jonker
---
drivers/gpio/rk_gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/rk_gpio.c b/drivers/gpio/rk_gpio.c
index f7ad4d68..0a2acf18 100644
--- a/drivers/gpio/rk_gpio.c
+++ b/drivers/gpio/rk_gpio.c
@@ -160,7 +160,7 @@ static int rockchip_gpio_probe(struct udevice *dev)
0, );
if (!ret || ret != -ENOENT) {
uc_priv->gpio_count = args.args[2];
- priv->bank = args.args[1] / args.args[2];
+ priv->bank = args.args[1] / ROCKCHIP_GPIOS_PER_BANK;
} else {
uc_priv->gpio_count = ROCKCHIP_GPIOS_PER_BANK;
end = strrchr(dev->name, '@');
--
2.20.1
[PATCH] fdt: Make fdt addr -q quieter
From: Peter Hoyes
64597346 "fdt: Add -q option to fdt addr for distro_bootcmd" introduced
the -q option for fdt addr, which sets the current working fdt address
without printing any output.
baf41410 "fdt: Show a message when the working FDT changes" made the
utility function set_working_fdt_addr (in cmd/fdt.c) output a message
on each invocation, even if called via fdt addr -q, in which case its
output is now slightly noisier.
To fix this, move the printf outside of set_working_fdt_addr to three
call sites:
* bootm_find_images (the use case for which the additional output was
added in baf41410).
* fdt addr, but only if the 'quiet' argument is not set.
* fdt move.
This also has the advantage of printing the specified address instead of
the translated address when using the sandbox.
Remove assertions from the fdt addr test case when:
* Calling set_working_fdt_addr directly.
* Calling fdt addr with the -q argument.
Signed-off-by: Peter Hoyes
---
boot/bootm.c | 5 -
cmd/fdt.c | 13 +
test/cmd/fdt.c | 6 --
3 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 2eec60ec7b..be5e29088d 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -313,8 +313,11 @@ int bootm_find_images(int flag, int argc, char *const
argv[], ulong start,
return 1;
}
- if (IS_ENABLED(CONFIG_CMD_FDT))
+ if (IS_ENABLED(CONFIG_CMD_FDT)) {
+ printf("Working FDT set to %lx\n", (ulong)images.ft_addr);
set_working_fdt_addr(map_to_sysmem(images.ft_addr));
+ }
+
#endif
#if CONFIG_IS_ENABLED(FIT)
diff --git a/cmd/fdt.c b/cmd/fdt.c
index f38fe909c3..39f94759d9 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -40,7 +40,6 @@ void set_working_fdt_addr(ulong addr)
{
void *buf;
- printf("Working FDT set to %lx\n", addr);
buf = map_sysmem(addr, 0);
working_fdt = buf;
env_set_hex("fdtaddr", addr);
@@ -192,10 +191,13 @@ static int do_fdt(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
if ((quiet && fdt_check_header(blob)) ||
(!quiet && !fdt_valid()))
return 1;
- if (control)
+ if (control) {
gd->fdt_blob = blob;
- else
+ } else {
+ if (!quiet)
+ printf("Working FDT set to %lx\n", addr);
set_working_fdt_addr(addr);
+ }
if (argc >= 2) {
int len;
@@ -223,6 +225,7 @@ static int do_fdt(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
* Move the working_fdt
*/
} else if (strncmp(argv[1], "mo", 2) == 0) {
+ unsigned long addr;
struct fdt_header *newaddr;
int len;
int err;
@@ -237,7 +240,8 @@ static int do_fdt(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
if (!fdt_valid(_fdt))
return 1;
- newaddr = map_sysmem(hextoul(argv[3], NULL), 0);
+ addr = hextoul(argv[3], NULL);
+ newaddr = map_sysmem(addr, 0);
/*
* If the user specifies a length, use that. Otherwise use the
@@ -264,6 +268,7 @@ static int do_fdt(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
fdt_strerror(err));
return 1;
}
+ printf("Working FDT set to %lx\n", addr);
set_working_fdt_addr(map_to_sysmem(newaddr));
return CMD_RET_SUCCESS;
diff --git a/test/cmd/fdt.c b/test/cmd/fdt.c
index cdbaf8c425..d2839d6dee 100644
--- a/test/cmd/fdt.c
+++ b/test/cmd/fdt.c
@@ -151,7 +151,6 @@ static int fdt_test_addr(struct unit_test_state *uts)
/* The working fdt is not set, so this should fail */
set_working_fdt_addr(0);
- ut_assert_nextline("Working FDT set to 0");
ut_asserteq(CMD_RET_FAILURE, run_command("fdt addr", 0));
ut_assert_nextline("libfdt fdt_check_header(): FDT_ERR_BADMAGIC");
ut_assertok(ut_check_console_end(uts));
@@ -160,20 +159,17 @@ static int fdt_test_addr(struct unit_test_state *uts)
ut_assertok(make_test_fdt(uts, fdt, sizeof(fdt)));
addr = map_to_sysmem(fdt);
set_working_fdt_addr(addr);
- ut_assert_nextline("Working FDT set to %lx", addr);
ut_assertok(run_command("fdt addr", 0));
ut_assert_nextline("Working fdt: %08lx", (ulong)map_to_sysmem(fdt));
ut_assertok(ut_check_console_end(uts));
/* Set the working FDT */
set_working_fdt_addr(0);
- ut_assert_nextline("Working FDT set to 0");
ut_assertok(run_commandf("fdt addr %08x", addr));
ut_assert_nextline("Working FDT set to %lx", addr);
ut_asserteq(addr,
Re: Please pull u-boot-dm/next
On Thu, Mar 16, 2023 at 10:56:17AM -0400, Tom Rini wrote: > On Thu, Mar 16, 2023 at 07:58:33AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 15 Mar 2023 at 08:49, Tom Rini wrote: > > > > > > On Tue, Mar 14, 2023 at 04:07:57PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Mon, 13 Mar 2023 at 13:36, Tom Rini wrote: > > > > > > > > > > On Sun, Mar 12, 2023 at 09:10:19PM -0600, Simon Glass wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > This is for the -next branch > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/15568 > > > > > > > > > > > > The following changes since commit > > > > > > bcf343146ff365a88481b9a80920ed146c6dee5b: > > > > > > > > > > > > Merge tag 'dm-next-9mar23' of > > > > > > https://source.denx.de/u-boot/custodians/u-boot-dm into next > > > > > > (2023-03-09 11:22:50 -0500) > > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > git://git.denx.de/u-boot-dm.git tags/dm-next-12mar23 > > > > > > > > > > > > for you to fetch changes up to > > > > > > 7bb28330f7b4d20bcf844ec306dcfbb41296cfa8: > > > > > > > > > > > > buildman: Fix CROSS_COMPILE output for sandbox (2023-03-12 > > > > > > 11:37:34 -0600) > > > > > > > > > > > > > > > > There's something, or somethings, broken here now. Take a look at: > > > > > https://source.denx.de/u-boot/u-boot/-/jobs/593223#L904 > > > > > where now there's a bunch of warnings but we don't fail the build (nor > > > > > > > > That seems to have been going for a while. See: > > > > > > > > https://source.denx.de/u-boot/u-boot/-/jobs/593528 > > > > > > I don't see it there, no. The problem, to be clear, is warnings in C NOT > > > leading to CI failing. > > > > OK that's fine, but what does it have to do with this pull request? > > I don't know when this regression happened, only that I saw it, and the > warnings at the same time. So I'm seeing now (after sorting out some > failing lab equipment) if the "C warnings cause CI to fail" changes are > in master, or next, or neither. Alright, so, there was something very odd with what got triggered before, as I cannot make CI pass when it should fail with a simple #warning. I'll review this PR fully now. -- Tom signature.asc Description: PGP signature
Re: EXTERNAL - [PATCH] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.
Am 16.03.2023 um 11:33 hat Frieder Schrempf geschrieben:
> On 10.03.23 14:50, Sebastian Andrzej Siewior wrote:
> > From: Manuel Traut
> >
> > The board is similar to Kontron's N801x design. It lacks external eMMC
> > support and only supports only 1GiB of main memory.
>
> Good to see some custom boards being upstreamed!
>
> It would be worth mentioning here that it is based on the "Kontron SL
> i.MX8M Mini" SoM, which is the proper name of the product nowadays.
>
> What do you mean by "it lacks external eMMC support"?
> There is an eMMC on the SoM, so the hardware does support it.
It is using the SoM and has an eMMC. There are two variants.
Snowflake_v2 has an external SDCard Interface. LEIG is the same,
but without display and without external SDCard Interface.
> >
> > [ bigeasy: porting and a bit of cleanup ]
> >
> > Signed-off-by: Manuel Traut
> > Signed-off-by: Sebastian Andrzej Siewior
> > ---
> > arch/arm/dts/Makefile |1 +
> > .../dts/imx8mm-mt-snowflake-v2-u-boot.dtsi| 116 ++
> > arch/arm/dts/imx8mm-mt-snowflake-v2.dts | 186 ++
> > arch/arm/mach-imx/imx8m/Kconfig |8 +
> > board/mt/snowflake_v2/Kconfig | 18 +
> > board/mt/snowflake_v2/MAINTAINERS |7 +
> > board/mt/snowflake_v2/Makefile|9 +
> > board/mt/snowflake_v2/imximage.cfg|8 +
> > board/mt/snowflake_v2/lpddr4_timing.c | 1844 +
> > board/mt/snowflake_v2/snowflake_v2.c | 32 +
> > board/mt/snowflake_v2/snowflake_v2.env| 33 +
> > board/mt/snowflake_v2/spl.c | 167 ++
> > configs/snowflake_v2_emmcboot_defconfig | 134 ++
> > include/configs/snowflake_v2.h| 54 +
> > 14 files changed, 2617 insertions(+)
> > create mode 100644 arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
> > create mode 100644 arch/arm/dts/imx8mm-mt-snowflake-v2.dts
> > create mode 100644 board/mt/snowflake_v2/Kconfig
> > create mode 100644 board/mt/snowflake_v2/MAINTAINERS
> > create mode 100644 board/mt/snowflake_v2/Makefile
> > create mode 100644 board/mt/snowflake_v2/imximage.cfg
> > create mode 100644 board/mt/snowflake_v2/lpddr4_timing.c
> > create mode 100644 board/mt/snowflake_v2/snowflake_v2.c
> > create mode 100644 board/mt/snowflake_v2/snowflake_v2.env
> > create mode 100644 board/mt/snowflake_v2/spl.c
> > create mode 100644 configs/snowflake_v2_emmcboot_defconfig
> > create mode 100644 include/configs/snowflake_v2.h
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 7a577deb5023d..ba0786064847e 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -964,6 +964,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
> > imx8mm-icore-mx8mm-edimm2.2.dtb \
> > imx8mm-kontron-bl.dtb \
> > imx8mm-kontron-bl-osm-s.dtb \
> > + imx8mm-mt-snowflake-v2.dtb \
> > imx8mm-mx8menlo.dtb \
> > imx8mm-phg.dtb \
> > imx8mm-venice.dtb \
> > diff --git a/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
> > b/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
> > new file mode 100644
> > index 0..d6476db292b79
> > --- /dev/null
> > +++ b/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
> > @@ -0,0 +1,116 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 Mettler Toledo GmbH
> > + */
> > +
> > +/ {
> > +
> > + aliases {
> > + usbgadget0 =
> > + };
> > +
> > + usbg1: usbg1 {
> > + u-boot,dm-spl;
> > + compatible = "fsl,imx27-usb-gadget";
> > + dr_mode = "peripheral";
> > + chipidea,usb = <>;
> > + status = "okay";
> > + };
> > +
> > + firmware {
> > + optee {
> > + compatible = "linaro,optee-tz";
> > + method = "smc";
> > + };
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > + u-boot,dm-spl;
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + status = "okay";
> > + u-boot,dm-spl;
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > +_ecspi1 {
> > + u-boot,dm-spl;
> > +};
> > +
> > +_i2c1 {
> > + u-boot,dm-spl;
> > +};
> > +
> > +_pmic {
> > + u-boot,dm-spl;
> > +};
> > +
> > +_uart3 {
> > + u-boot,dm-spl;
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > +_usdhc1 {
> > + u-boot,dm-spl;
> > +};
> > +
> > +_usdhc1_100mhz {
> > + u-boot,dm-spl;
> > +};
> > +
> > +_usdhc1_200mhz {
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > +};
> > +
> > +&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > +};
> > +
> > + {
> > + u-boot,dm-spl;
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > +
Re: Please pull u-boot-dm/next
On Thu, Mar 16, 2023 at 07:58:33AM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 15 Mar 2023 at 08:49, Tom Rini wrote: > > > > On Tue, Mar 14, 2023 at 04:07:57PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 13 Mar 2023 at 13:36, Tom Rini wrote: > > > > > > > > On Sun, Mar 12, 2023 at 09:10:19PM -0600, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > This is for the -next branch > > > > > > > > > > > > > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/15568 > > > > > > > > > > The following changes since commit > > > > > bcf343146ff365a88481b9a80920ed146c6dee5b: > > > > > > > > > > Merge tag 'dm-next-9mar23' of > > > > > https://source.denx.de/u-boot/custodians/u-boot-dm into next > > > > > (2023-03-09 11:22:50 -0500) > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > git://git.denx.de/u-boot-dm.git tags/dm-next-12mar23 > > > > > > > > > > for you to fetch changes up to > > > > > 7bb28330f7b4d20bcf844ec306dcfbb41296cfa8: > > > > > > > > > > buildman: Fix CROSS_COMPILE output for sandbox (2023-03-12 11:37:34 > > > > > -0600) > > > > > > > > > > > > > There's something, or somethings, broken here now. Take a look at: > > > > https://source.denx.de/u-boot/u-boot/-/jobs/593223#L904 > > > > where now there's a bunch of warnings but we don't fail the build (nor > > > > > > That seems to have been going for a while. See: > > > > > > https://source.denx.de/u-boot/u-boot/-/jobs/593528 > > > > I don't see it there, no. The problem, to be clear, is warnings in C NOT > > leading to CI failing. > > OK that's fine, but what does it have to do with this pull request? I don't know when this regression happened, only that I saw it, and the warnings at the same time. So I'm seeing now (after sorting out some failing lab equipment) if the "C warnings cause CI to fail" changes are in master, or next, or neither. -- Tom signature.asc Description: PGP signature
Re: mkimage for Windows?
On Wed, Mar 15, 2023 at 01:56:25PM -0600, Simon Glass wrote: > Hi, > > Does anyone know how to build mkimage (or other tools) on a Windows > host, or at least with a Windows target? Other than the Azure tools-only test? I think that builds mkimage. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 5/5] test_vboot.py: include test of fdt_add_pubkey tool
On Thu, 2023-03-16 at 07:59 -0600, Simon Glass wrote:
> Hi Ivan,
>
> On Wed, 15 Mar 2023 at 19:17, Ivan Mikhaylov
> wrote:
> >
> > On Fri, 2023-03-10 at 17:46 -0800, Simon Glass wrote:
> > > Hi Ivan,
> > >
> > > On Tue, 7 Mar 2023 at 14:13, Ivan Mikhaylov
> > > wrote:
> > > >
> > > > From: Roman Kopytin
> > > >
> > > > Signed-off-by: Roman Kopytin
> > > > Cc: Rasmus Villemoes
> > > > ---
> > > > test/py/tests/test_vboot.py | 8
> > > > 1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/test/py/tests/test_vboot.py
> > > > b/test/py/tests/test_vboot.py
> > > > index e3e7ca4b21..956b8fcd43 100644
> > > > --- a/test/py/tests/test_vboot.py
> > > > +++ b/test/py/tests/test_vboot.py
> > > > @@ -313,6 +313,13 @@ def test_vboot(u_boot_console, name,
> > > > sha_algo,
> > > > padding, sign_options, required,
> > > >
> > > > util.run_and_log(cons, [fit_check_sign, '-f', fit, '-
> > > > k',
> > > > dtb])
> > > >
> > > > + # Create a fresh .dtb without the public keys
> > > > + dtc('sandbox-u-boot.dts')
> > > > + # Then add the dev key via the fdt_add_pubkey tool
> > > > + util.run_and_log(cons, [fdt_add_pubkey, '-a',
> > > > '%s,rsa2048'
> > > > % sha_algo,
> > > > + '-k', tmpdir, '-n', 'dev', '-
> > > > r',
> > > > 'conf', dtb])
> > > > + util.run_and_log(cons, [fit_check_sign, '-f', fit, '-
> > > > k',
> > > > dtb])
> > > > +
> > > > if full_test:
> > > > # Make sure that U-Boot checks that the config is
> > > > in
> > > > the list of
> > > > # hashed nodes. If it isn't, a security bypass is
> > > > possible.
> > > > @@ -500,6 +507,7 @@ def test_vboot(u_boot_console, name,
> > > > sha_algo,
> > > > padding, sign_options, required,
> > > > mkimage = cons.config.build_dir + '/tools/mkimage'
> > > > binman = cons.config.source_dir + '/tools/binman/binman'
> > > > fit_check_sign = cons.config.build_dir +
> > > > '/tools/fit_check_sign'
> > > > + fdt_add_pubkey = cons.config.build_dir +
> > > > '/tools/fdt_add_pubkey'
> > > > dtc_args = '-I dts -O dtb -i %s' % tmpdir
> > > > dtb = '%ssandbox-u-boot.dtb' % tmpdir
> > > > sig_node = '/configurations/conf-1/signature'
> > > > --
> > > > 2.39.1
> > > >
> > >
> > > Unfortunately this test fails on sandbox:
> > >
> > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/591975
> > >
> > > I think it would be better to put it in its own test (perhaps in
> > > the
> > > same file) so we are not doing it on every test run. Also you
> > > could
> > > check (in a very basic way) that it adds the key correctly since
> > > we
> > > don't really need another test of the logic of doing that. We are
> > > just
> > > checking that your tool calls that logic correctly.
> > >
> > > I'll drop this one when applying, for now. Please take a look.
> > >
> > > Regards,
> > > Simon
> >
> > Simon, does it look ok? Test for test_vboot is passed fine.
>
> Please see my message before:
>
> > Unfortunately this test fails on sandbox:
> >
> > https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/591975
> >
> > I think it would be better to put it in its own test (perhaps in
> > the
> > same file) so we are not doing it on every test run. Also you could
> > check (in a very basic way) that it adds the key correctly since we
> > don't really need another test of the logic of doing that. We are
> > just
> > checking that your tool calls that logic correctly.
> >
> > I'll drop this one when applying, for now. Please take a look.
>
> I have not applied this patch due to the problem.
>
> Regards,
> Simon
>
Simon, but I've changed the test and put it in previous note, maybe you
didn't notice, I did what you asked:
- made own test "test_fdt_add_pubkey"
- simple check that with clear dtb you can add keys with fdt_add_pubkey
and check with fit_check_sign with signed fit.
I've checked that change with sandbox and it passes test_vboot well.
Need I re-submit that patch or whole series?
Thanks.
>
>
> >
> > Thanks.
> >
> > From 5484d525d4950b064adf1204f5bf055229c942ac Mon Sep 17 00:00:00
> > 2001
> > From: Roman Kopytin
> > Date: Thu, 11 Nov 2021 11:15:12 +0300
> > Subject: [PATCH v3] test_vboot.py: include test of fdt_add_pubkey
> > tool
> >
> > Signed-off-by: Roman Kopytin
> > Signed-off-by: Ivan Mikhaylov
> > Cc: Rasmus Villemoes
> > ---
> > test/py/tests/test_vboot.py | 33 +
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/test/py/tests/test_vboot.py
> > b/test/py/tests/test_vboot.py
> > index e3e7ca4b21..5ae622fe21 100644
> > --- a/test/py/tests/test_vboot.py
> > +++ b/test/py/tests/test_vboot.py
> > @@ -491,6 +491,37 @@ def test_vboot(u_boot_console, name, sha_algo,
> > padding, sign_options, required,
> > # Check that the boot fails if the global signature is not
> > provided
> > run_bootm(sha_algo, 'global image signature',
Re: [PATCH v2 5/5] test_vboot.py: include test of fdt_add_pubkey tool
Hi Ivan,
On Wed, 15 Mar 2023 at 19:17, Ivan Mikhaylov wrote:
>
> On Fri, 2023-03-10 at 17:46 -0800, Simon Glass wrote:
> > Hi Ivan,
> >
> > On Tue, 7 Mar 2023 at 14:13, Ivan Mikhaylov
> > wrote:
> > >
> > > From: Roman Kopytin
> > >
> > > Signed-off-by: Roman Kopytin
> > > Cc: Rasmus Villemoes
> > > ---
> > > test/py/tests/test_vboot.py | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/test/py/tests/test_vboot.py
> > > b/test/py/tests/test_vboot.py
> > > index e3e7ca4b21..956b8fcd43 100644
> > > --- a/test/py/tests/test_vboot.py
> > > +++ b/test/py/tests/test_vboot.py
> > > @@ -313,6 +313,13 @@ def test_vboot(u_boot_console, name, sha_algo,
> > > padding, sign_options, required,
> > >
> > > util.run_and_log(cons, [fit_check_sign, '-f', fit, '-k',
> > > dtb])
> > >
> > > +# Create a fresh .dtb without the public keys
> > > +dtc('sandbox-u-boot.dts')
> > > +# Then add the dev key via the fdt_add_pubkey tool
> > > +util.run_and_log(cons, [fdt_add_pubkey, '-a', '%s,rsa2048'
> > > % sha_algo,
> > > +'-k', tmpdir, '-n', 'dev', '-r',
> > > 'conf', dtb])
> > > +util.run_and_log(cons, [fit_check_sign, '-f', fit, '-k',
> > > dtb])
> > > +
> > > if full_test:
> > > # Make sure that U-Boot checks that the config is in
> > > the list of
> > > # hashed nodes. If it isn't, a security bypass is
> > > possible.
> > > @@ -500,6 +507,7 @@ def test_vboot(u_boot_console, name, sha_algo,
> > > padding, sign_options, required,
> > > mkimage = cons.config.build_dir + '/tools/mkimage'
> > > binman = cons.config.source_dir + '/tools/binman/binman'
> > > fit_check_sign = cons.config.build_dir +
> > > '/tools/fit_check_sign'
> > > +fdt_add_pubkey = cons.config.build_dir +
> > > '/tools/fdt_add_pubkey'
> > > dtc_args = '-I dts -O dtb -i %s' % tmpdir
> > > dtb = '%ssandbox-u-boot.dtb' % tmpdir
> > > sig_node = '/configurations/conf-1/signature'
> > > --
> > > 2.39.1
> > >
> >
> > Unfortunately this test fails on sandbox:
> >
> > https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/591975
> >
> > I think it would be better to put it in its own test (perhaps in the
> > same file) so we are not doing it on every test run. Also you could
> > check (in a very basic way) that it adds the key correctly since we
> > don't really need another test of the logic of doing that. We are
> > just
> > checking that your tool calls that logic correctly.
> >
> > I'll drop this one when applying, for now. Please take a look.
> >
> > Regards,
> > Simon
>
> Simon, does it look ok? Test for test_vboot is passed fine.
Please see my message before:
> Unfortunately this test fails on sandbox:
>
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/jobs/591975
>
> I think it would be better to put it in its own test (perhaps in the
> same file) so we are not doing it on every test run. Also you could
> check (in a very basic way) that it adds the key correctly since we
> don't really need another test of the logic of doing that. We are just
> checking that your tool calls that logic correctly.
>
> I'll drop this one when applying, for now. Please take a look.
I have not applied this patch due to the problem.
Regards,
Simon
>
> Thanks.
>
> From 5484d525d4950b064adf1204f5bf055229c942ac Mon Sep 17 00:00:00 2001
> From: Roman Kopytin
> Date: Thu, 11 Nov 2021 11:15:12 +0300
> Subject: [PATCH v3] test_vboot.py: include test of fdt_add_pubkey tool
>
> Signed-off-by: Roman Kopytin
> Signed-off-by: Ivan Mikhaylov
> Cc: Rasmus Villemoes
> ---
> test/py/tests/test_vboot.py | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py
> index e3e7ca4b21..5ae622fe21 100644
> --- a/test/py/tests/test_vboot.py
> +++ b/test/py/tests/test_vboot.py
> @@ -491,6 +491,37 @@ def test_vboot(u_boot_console, name, sha_algo,
> padding, sign_options, required,
> # Check that the boot fails if the global signature is not
> provided
> run_bootm(sha_algo, 'global image signature', 'signature is
> mandatory', False)
>
> +def test_fdt_add_pubkey(sha_algo, padding, sign_options):
> +"""Test fdt_add_pubkey utility with given hash algorithm and
> padding.
> +
> +This function tests if fdt_add_pubkey utility may add public
> keys into dtb.
> +
> +Args:
> +sha_algo: Either 'sha1' or 'sha256', to select the
> algorithm to use
> +padding: Either '' or '-pss', to select the padding to use
> for the
> +rsa signature algorithm.
> +sign_options: Options to mkimage when signing a fit image.
> +"""
> +
> +# Create a fresh .dtb without the public keys
> +dtc('sandbox-u-boot.dts')
> +make_fit('sign-configs-%s%s.its' % (sha_algo, padding))
> +
> +# Sign images with our dev keys
> +
Re: Please pull u-boot-dm/next
Hi Tom, On Wed, 15 Mar 2023 at 08:49, Tom Rini wrote: > > On Tue, Mar 14, 2023 at 04:07:57PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 13 Mar 2023 at 13:36, Tom Rini wrote: > > > > > > On Sun, Mar 12, 2023 at 09:10:19PM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > This is for the -next branch > > > > > > > > > > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/15568 > > > > > > > > The following changes since commit > > > > bcf343146ff365a88481b9a80920ed146c6dee5b: > > > > > > > > Merge tag 'dm-next-9mar23' of > > > > https://source.denx.de/u-boot/custodians/u-boot-dm into next > > > > (2023-03-09 11:22:50 -0500) > > > > > > > > are available in the Git repository at: > > > > > > > > git://git.denx.de/u-boot-dm.git tags/dm-next-12mar23 > > > > > > > > for you to fetch changes up to 7bb28330f7b4d20bcf844ec306dcfbb41296cfa8: > > > > > > > > buildman: Fix CROSS_COMPILE output for sandbox (2023-03-12 11:37:34 > > > > -0600) > > > > > > > > > > There's something, or somethings, broken here now. Take a look at: > > > https://source.denx.de/u-boot/u-boot/-/jobs/593223#L904 > > > where now there's a bunch of warnings but we don't fail the build (nor > > > > That seems to have been going for a while. See: > > > > https://source.denx.de/u-boot/u-boot/-/jobs/593528 > > I don't see it there, no. The problem, to be clear, is warnings in C NOT > leading to CI failing. OK that's fine, but what does it have to do with this pull request? I can take a look at the problem, but it does not seem related. Regards, Simon
[PATCH] regulator: implement basic reference counter
Some devices share a regulator supply, when the first one will request
regulator disable, the second device will have it's supply cut off before
graciously shutting down. Hence there will be timeouts and other failed
operations.
Implement a reference counter mechanism similar with what is done in
Linux, to keep track of enable and disable requests, and only disable the
regulator when the last of the consumers has requested shutdown.
Signed-off-by: Eugen Hristev
---
drivers/power/regulator/regulator_common.c | 22 ++
drivers/power/regulator/regulator_common.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/power/regulator/regulator_common.c
b/drivers/power/regulator/regulator_common.c
index 93d8196b381e..edda25336176 100644
--- a/drivers/power/regulator/regulator_common.c
+++ b/drivers/power/regulator/regulator_common.c
@@ -73,6 +73,23 @@ int regulator_common_set_enable(const struct udevice *dev,
return 0;
}
+ /* If previously enabled, increase count */
+ if (enable && dev_pdata->enable_count > 0) {
+ dev_pdata->enable_count++;
+ return 0;
+ }
+
+ if (!enable) {
+ if (dev_pdata->enable_count > 1) {
+ /* If enabled multiple times, decrease count */
+ dev_pdata->enable_count--;
+ return 0;
+ } else if (!dev_pdata->enable_count) {
+ /* If already disabled, do nothing */
+ return 0;
+ }
+ }
+
ret = dm_gpio_set_value(_pdata->gpio, enable);
if (ret) {
pr_err("Can't set regulator : %s gpio to: %d\n", dev->name,
@@ -87,5 +104,10 @@ int regulator_common_set_enable(const struct udevice *dev,
if (!enable && dev_pdata->off_on_delay_us)
udelay(dev_pdata->off_on_delay_us);
+ if (enable)
+ dev_pdata->enable_count++;
+ else
+ dev_pdata->enable_count--;
+
return 0;
}
diff --git a/drivers/power/regulator/regulator_common.h
b/drivers/power/regulator/regulator_common.h
index c10492f01675..8167bc866261 100644
--- a/drivers/power/regulator/regulator_common.h
+++ b/drivers/power/regulator/regulator_common.h
@@ -13,6 +13,7 @@ struct regulator_common_plat {
struct gpio_desc gpio; /* GPIO for regulator enable control */
unsigned int startup_delay_us;
unsigned int off_on_delay_us;
+ unsigned int enable_count;
};
int regulator_common_of_to_plat(struct udevice *dev,
--
2.34.1
Re: [PATCH 0/9] binman: Show missing blob message when building U-Boot
Hi Jonas, On Thu, 16 Mar 2023 at 01:45, Jonas Karlman wrote: > > Hi Simon, > On 2023-03-10 21:49, Simon Glass wrote: > > Hi Jonas, > > > > On Sun, 19 Feb 2023 at 14:02, Jonas Karlman wrote: > >> > >> binman currently support showing a helpful missing blob message, but > >> only when the --allow-missing flag is used. > >> > >> This changes so that binman is invoked with the --allow-missing flag > >> and the helpful message can be shown by default when building U-Boot. > >> > >> Using the following: > >> > >> make rockpro64-rk3399_defconfig > >> make CROSS_COMPILE="aarch64-linux-gnu-" > >> > >> Before this series a build fails with: > >> > >> binman: Filename 'atf-bl31' not found in input path (...) > >> > >> After this series a build fails with: > >> > >> Image 'simple-bin' is missing external blobs and is non-functional: > >> atf-bl31 > >> > >> /binman/simple-bin/fit/images/@atf-SEQ/atf-bl31 (atf-bl31): > >> See the documentation for your board. You may need to build ARM > >> Trusted > >> Firmware and build with BL31=/path/to/bl31.bin > >> > >> Image 'simple-bin' is missing external blobs but is still functional: > >> tee-os > >> > >> /binman/simple-bin/fit/images/@tee-SEQ/tee-os (tee-os): > >> See the documentation for your board. You may need to build Open > >> Portable > >> Trusted Execution Environment (OP-TEE) with TEE=/path/to/tee.bin > >> > >> Some images are invalid > >> > >> Builds will continue to fail when there is missing blobs, and the use of > >> BINMAN_ALLOW_MISSING=1 now only enables the --ignore-missing flag. > >> > >> This series also fixes a few minor issues that prevented some missing > >> and optional blobs to be detected for fit and mkimage entries. > >> > >> Patch 1-3 contains spelling fixes and code cleanup for related parts. > >> Patch 4-6 improve missing/optional detection for fit and mkimage entries. > >> Patch 7-8 improve the missing blob warning message output. > >> Patch 9 finally update Makefile to always pass the --allow-missing flag. > >> > >> The series is based on top of [1], and is the follow-up series meant to > >> address the issue with missing blob message for mkimage entries. > >> > >> [1] > >> https://patchwork.ozlabs.org/project/uboot/cover/20230219150629.4012377-1-jo...@kwiboo.se/ > >> > >> Jonas Karlman (9): > >> binman: Remove redundant SetAllowFakeBlob from blob-ext entry > >> binman: Fix spelling of nodes in code comments > >> binman: Use correct argument name in docstrings > >> binman: Override CheckOptional in fit entry > >> binman: Implement missing check functions in mkimage entry > >> binman: Mark mkimage entry missing when its subnodes is missing > >> binman: Fix blank line usage for invalid images warning text > >> binman: Show filename in missing blob help message > >> Makefile: Show binman missing blob message > >> > >> Makefile | 2 +- > >> tools/binman/control.py | 24 ++--- > >> tools/binman/entry.py | 2 +- > >> tools/binman/etype/blob.py| 2 +- > >> tools/binman/etype/blob_ext.py| 8 --- > >> tools/binman/etype/fit.py | 9 +++- > >> tools/binman/etype/mkimage.py | 54 ++- > >> tools/binman/etype/section.py | 6 +-- > >> tools/binman/ftest.py | 9 > >> tools/binman/state.py | 2 +- > >> .../test/278_mkimage_missing_multiple.dts | 19 +++ > >> 11 files changed, 111 insertions(+), 26 deletions(-) > >> create mode 100644 tools/binman/test/278_mkimage_missing_multiple.dts > >> > >> -- > >> 2.39.2 > >> > > > > I applied what I could of this to -next > > > > Could you please take another look and see if we can get the rest in? > > Sure, I will take a look at a v2 (with more tests) in next few days. > > Still unclear what to do about "Makefile: Show binman missing blob > message" at [2]. Should I re-send it as-is, change it or just drop it? > > [2] > https://patchwork.ozlabs.org/project/uboot/patch/20230219220158.4160763-10-jo...@kwiboo.se/#3063614 I'd say resend since it seems right to me. I'll probably need to talk to Tom about it. Regards, SImon
Re: [PATCH v3 0/5] improve 'read' command, add 'write' command
On 02/03/2023 09.12, Rasmus Villemoes wrote: > The first patch simplies do_read somewhat by making use of an existing > helper instead of parsing the dev_part string manually. As a bonus > (and my actual motivation), it now understands dev#partname syntax - > hard-coded partition numbers are so last decade. > > I also need the symmetrical operation, being able to write to a named > raw partition, and fortunately it doesn't require that many lines of > code to implement that. > > There's a very minor change in the error reporting due to using > cmdtp->name to generate the new messages, but I don't think "Error > reading blocks" offers much that "read error" doesn't. > > New in v2: the last three patches add documentation, ensure CMD_WRITE > is set for sandbox and adds some basic test cases for the various ways > of accessing the partitions (by number, name, or as raw offset within > the whole disk). > > v3: Add Simon's R-b to patches 2, 4, 5, fixup whitespace in patch 5. Can this series be picked up for -next, please? Rasmus
[PATCH] pinctrl: fix pinctrl_gpio_get_pinctrl_and_offset for gpio-ranges array
From: Quanyang Wang
Sometimes a multi-element array is used for "gpio-ranges" property in
dts file:
qe_pio_e: gpio-controller@1460 {
..
gpio-ranges = < 0 20 10>, < 10 50 20>;
..
};
But the function pinctrl_gpio_get_pinctrl_and_offset can't handle this
case because the "index" argument passed to dev_read_phandle_with_args
is fixed to be "0". Use a loop to traverse the array to fix it.
Signed-off-by: Quanyang Wang
---
drivers/pinctrl/pinctrl-uclass.c | 47
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-uclass.c b/drivers/pinctrl/pinctrl-uclass.c
index 8837726cc1..73dd7b1038 100644
--- a/drivers/pinctrl/pinctrl-uclass.c
+++ b/drivers/pinctrl/pinctrl-uclass.c
@@ -169,34 +169,33 @@ pinctrl_gpio_get_pinctrl_and_offset(struct udevice *dev,
unsigned offset,
{
struct ofnode_phandle_args args;
unsigned gpio_offset, pfc_base, pfc_pins;
- int ret;
+ int ret = 0;
+ int i = 0;
- ret = dev_read_phandle_with_args(dev, "gpio-ranges", NULL, 3,
-0, );
- if (ret) {
- dev_dbg(dev, "%s: dev_read_phandle_with_args: err=%d\n",
- __func__, ret);
- return ret;
- }
+ while (ret == 0) {
+ ret = dev_read_phandle_with_args(dev, "gpio-ranges", NULL, 3,
+i++, );
+ if (ret) {
+ dev_dbg(dev, "%s: dev_read_phandle_with_args: err=%d\n",
+ __func__, ret);
+ return ret;
+ }
- ret = uclass_get_device_by_ofnode(UCLASS_PINCTRL,
- args.node, pctldev);
- if (ret) {
- dev_dbg(dev,
- "%s: uclass_get_device_by_of_offset failed: err=%d\n",
- __func__, ret);
- return ret;
- }
+ ret = uclass_get_device_by_ofnode(UCLASS_PINCTRL,
+ args.node, pctldev);
+ if (ret) {
+ dev_dbg(dev,
+ "%s: uclass_get_device_by_of_offset failed:
err=%d\n",
+ __func__, ret);
+ return ret;
+ }
- gpio_offset = args.args[0];
- pfc_base = args.args[1];
- pfc_pins = args.args[2];
+ gpio_offset = args.args[0];
+ pfc_base = args.args[1];
+ pfc_pins = args.args[2];
- if (offset < gpio_offset || offset > gpio_offset + pfc_pins) {
- dev_dbg(dev,
- "%s: GPIO can not be mapped to pincontrol pin\n",
- __func__);
- return -EINVAL;
+ if (offset >= gpio_offset && offset <= gpio_offset + pfc_pins)
+ break;
}
offset -= gpio_offset;
--
2.36.1
Re: [PATCH] board_r: Relocate OF_EMBED if NEEDS_MANUAL_RELOC only
> On 16-Mar-2023, at 1:12 AM, Simon Glass wrote: > > !! External Email > > Hi Ajay, > > On Wed, 15 Mar 2023 at 13:24, Ajay Kaher wrote: >> >>> On Fri, Sep 09, 2022 at 09:16:18PM +0100, Pierre-Clément Tosi wrote: >>> When the embedded device tree is pointed to by the __dtb_dt_*begin symbols, it seems to be covered by the early relocation code and doesn't need to be manually patched. Cc: Simon Glass Signed-off-by: Pierre-Clément Tosi >>> >>> Applied to u-boot/master, thanks! >> >> Getting following error on Rpi3 board and fail to boot with u-boot upstream >> commit 76f921eb95d5b814f973a263187db509d6f03903: >> >> ERROR: invalid device tree >> EFI LOAD FAILED: continuing... >> >> As per bdinfo: >> fdt_blob= 0x000f4b00 >> >> Would like to understand the reasoning of this upstream commit >> 76f921eb95d5b814f973a263187db509d6f03903 and looking for proper fix for Rpi3. >> >> -Ajay > > Did you bisect to that patch? Yes, between v2022.07 and v2022.10. > > The proper fix would be to get away from OF_EMBED which is not allowed > in production boards. Can you post the full console log so I can see > what happens before the error? Here are the logs: U-Boot 2022.10 (Mar 15 2023 - 07:10:46 +) DRAM: 948 MiB RPI 3 Model B (0xa02082) Core: 66 devices, 14 uclasses, devicetree: embed MMC: mmc@7e202000: 0, mmc@7e30: 1 Loading Environment from FAT... OK In:serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... Bus usb@7e98: USB DWC2 scanning bus usb@7e98 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Saving Environment to FAT... OK switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Card did not respond to voltage select! : -110 No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image 1146880 bytes read in 50 ms (21.9 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC ERROR: invalid device tree EFI LOAD FAILED: continuing... Card did not respond to voltage select! : -110 Device 0: unknown device Waiting for Ethernet connection... unable to connect. missing environment variable: pxeuuid Retrieving file: pxelinux.cfg/01-b8-27-eb-4d-9e-e9 Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/ Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/000 Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/00 Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/0 Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/ Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/000 Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/00 Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/0 Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/default-arm-bcm283x Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/default-arm Waiting for Ethernet connection... unable to connect. Retrieving file: pxelinux.cfg/default Waiting for Ethernet connection... unable to connect. Config file not found Waiting for Ethernet connection... unable to connect. Waiting for Ethernet connection... unable to connect. U-Boot> > The commit does not look correct to me. This is nothing to do with the > horrible NEEDS_MANUAL_RELOC which is only needed on m68k I think now. > It is because we have moved the executable containing the DT. The DT > in the old position may be overwritten by loading something. Seems like your observations are correct and may be need to revert 76f921eb95d5b814f973a263187db509d6f03903. And handle m68k case separately. Thanks Simon for your response. - Ajay
Re: [PATCH 2/3] rockchip: Disable DISTRO_DEFAULTS for rockpro64
On Wed, Feb 22, 2023 at 7:17 PM Tom Rini wrote: > > On Wed, Feb 22, 2023 at 12:03:58PM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 22 Feb 2023 at 12:01, Tom Rini wrote: > > > > > > On Wed, Feb 22, 2023 at 11:58:37AM -0700, Simon Glass wrote: > > > > Hi, > > > > > > > > On Wed, 22 Feb 2023 at 11:56, Jonas Karlman wrote: > > > > > > > > > > On 2023-02-22 19:24, Tom Rini wrote: > > > > > > On Wed, Feb 22, 2023 at 10:19:03AM -0800, Vagrant Cascadian wrote: > > > > > >> On 2023-02-21, Vagrant Cascadian wrote: > > > > > >>> On 2023-02-21, Simon Glass wrote: > > > > > This board has moved to standard boot but the old > > > > > 'distro_bootcmd' > > > > > command is still active. Disable DISTRO_DEFAULTS to fix this. > > > > > >>> > > > > > >>> Works for booting rockpro64-rk3399, thanks! > > > > > >> > > > > > >> I can also confirm that applying a very similar patch for > > > > > >> pinebook-pro-rk3399 works booting with bootstd. > > > > > >> > > > > > >> Seems worth adding if there is a v2 of the patch series. > > > > > >> > > > > > >> Alternately, rather than doing this on a board-by-board basis, is > > > > > >> there > > > > > >> some way to disable CONFIG_DISTRO_DEFAULTS when a board is using > > > > > >> BOOTSTD? > > > > > > > > > > > > I think that's possibly a bit dangerous? DISTRO_DEFAULTS and > > > > > > BOOTSTD_DEFAULTS need to be reconciled to a single new symbol, and > > > > > > the > > > > > > DISTRO_DEFAULTS method of select not imply for most things is also I > > > > > > suspect the right path. > > > > > > > > > > > > > > > > Another option would be to set BOOTSTD_BOOTCOMMAND=y, this is the main > > > > > issue with rk3399 at the moment, distro_bootcmd got removed from env, > > > > > yet bootcmd is still "run distro_bootcmd" due to DISTRO_DEFAULTS=y. > > > > > > > > > > > > > > > config BOOTCOMMAND > > > > > default "bootflow scan -lb" if BOOTSTD_BOOTCOMMAND && > > > > > CMD_BOOTFLOW_FULL > > > > > default "bootflow scan" if BOOTSTD_BOOTCOMMAND && > > > > > !CMD_BOOTFLOW_FULL > > > > > default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && > > > > > DISTRO_DEFAULTS > > > > > > > > > > config BOOTSTD_BOOTCOMMAND > > > > > default y if !DISTRO_DEFAULTS > > > > > > > > That seems reasonable to me, along with a 'depends on BOOTSTD' > > > > > > > > At present DISTRO_DEFAULTS is both enabled in defconfig files (about > > > > 350) and Kconfig (another 300). For rockchip it is the latter. > > > > > > > > It doesn't really make sense to use DISTRO_DEFAULTS when using > > > > BOOTSTD_DEFAULTS. One is 'run distro_bootcmd' and the other is > > > > 'bootflow scan', possibly with -lb flags. But we really don't want > > > > people flipping back and forward. > > > > > > It doesn't make linguistic sense to have "distro defaults" and "bootstd > > > defaults" enabled. It makes compute sense to have these two symbols > > > combined as they're nearly identical and have a similar conceptual need > > > (make sure we have things like bootz/booti/ext4/etc support). > > > > Oh, so you are talking about DISTRO_DEFAULTS, not the actual command? > > In that case I can do a patch to make them both use a common symbol to > > bring in most stuff, although bootstd does not need hush and a few > > other things that are needed by distro_bootcmd. > > > > Let me know if that makes sense. > > Yeah, the Kconfig symbols DISTRO_DEFAULTS and BOOTSTD_DEFAULTS need to > be reconciled and combined. This is separate from setting bootcmd to > "run distro_bootcmd", which should be separate, and yes, not be the > chosen symbol when we have bootstd enabled. What came out of this decision, the first other rk3399 device I tried, the rock960, is also broken booting. We really can't have devices randomly broken all the time and I don't have the time or the devices to go through and test everything. We should really be getting better at these mass changes, it doesn't lead to a great user experience! Peter
Re: [PATCH] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.
On 16.03.23 11:33, Frieder Schrempf wrote: > On 10.03.23 14:50, Sebastian Andrzej Siewior wrote: >> From: Manuel Traut >> >> The board is similar to Kontron's N801x design. It lacks external eMMC >> support and only supports only 1GiB of main memory. > > Good to see some custom boards being upstreamed! > > It would be worth mentioning here that it is based on the "Kontron SL > i.MX8M Mini" SoM, which is the proper name of the product nowadays. > > What do you mean by "it lacks external eMMC support"? > There is an eMMC on the SoM, so the hardware does support it. Or did I misunderstand the snowflake hardware and it actually doesn't have the SoM onboard but is designed like the SoM?
Re: [PATCH 0/2] add support for hs bootflows on am62 devices
Bryan Brattlof writes: > Hi Kamlesh! > > On March 2, 2023 thus sayeth kaml...@ti.com: >> From: Kamlesh Gurudasani >> >> Add support for high security bootflow on am62 devices. >> >> On HS devices, ROM and TIFS will protect the RAM regions with >> firewalls. This means the wakeup domain's SPL will need to move the >> stack and heap to HSM RAM to ensure it stays within its allotted >> memory regions. >> >> Kamlesh Gurudasani (2): >> arm: mach-k3: am62: move scratch board area to HSM RAM >> configs: am62: move stack and heap to HSM RAM >> >> arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +-- >> configs/am62x_evm_r5_defconfig| 16 +++- >> 2 files changed, 12 insertions(+), 7 deletions(-) > > Thanks for getting this fixed! Does TIFS drop the On Chip SRAM firewall > completely once it's started? or only for the r5? > > Reviewed-by: Bryan Brattlof > > ~Bryan Hi Tom, Could you please review and merge this patches as these are bug fixes to get HS devices working. Thanks. ~Kamlesh
Re: [PATCH] imx: imx8mm: Add suppoer for Mettler-Toledo snowflake board.
On 10.03.23 14:50, Sebastian Andrzej Siewior wrote:
> From: Manuel Traut
>
> The board is similar to Kontron's N801x design. It lacks external eMMC
> support and only supports only 1GiB of main memory.
Good to see some custom boards being upstreamed!
It would be worth mentioning here that it is based on the "Kontron SL
i.MX8M Mini" SoM, which is the proper name of the product nowadays.
What do you mean by "it lacks external eMMC support"?
There is an eMMC on the SoM, so the hardware does support it.
>
> [ bigeasy: porting and a bit of cleanup ]
>
> Signed-off-by: Manuel Traut
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> arch/arm/dts/Makefile |1 +
> .../dts/imx8mm-mt-snowflake-v2-u-boot.dtsi| 116 ++
> arch/arm/dts/imx8mm-mt-snowflake-v2.dts | 186 ++
> arch/arm/mach-imx/imx8m/Kconfig |8 +
> board/mt/snowflake_v2/Kconfig | 18 +
> board/mt/snowflake_v2/MAINTAINERS |7 +
> board/mt/snowflake_v2/Makefile|9 +
> board/mt/snowflake_v2/imximage.cfg|8 +
> board/mt/snowflake_v2/lpddr4_timing.c | 1844 +
> board/mt/snowflake_v2/snowflake_v2.c | 32 +
> board/mt/snowflake_v2/snowflake_v2.env| 33 +
> board/mt/snowflake_v2/spl.c | 167 ++
> configs/snowflake_v2_emmcboot_defconfig | 134 ++
> include/configs/snowflake_v2.h| 54 +
> 14 files changed, 2617 insertions(+)
> create mode 100644 arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx8mm-mt-snowflake-v2.dts
> create mode 100644 board/mt/snowflake_v2/Kconfig
> create mode 100644 board/mt/snowflake_v2/MAINTAINERS
> create mode 100644 board/mt/snowflake_v2/Makefile
> create mode 100644 board/mt/snowflake_v2/imximage.cfg
> create mode 100644 board/mt/snowflake_v2/lpddr4_timing.c
> create mode 100644 board/mt/snowflake_v2/snowflake_v2.c
> create mode 100644 board/mt/snowflake_v2/snowflake_v2.env
> create mode 100644 board/mt/snowflake_v2/spl.c
> create mode 100644 configs/snowflake_v2_emmcboot_defconfig
> create mode 100644 include/configs/snowflake_v2.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 7a577deb5023d..ba0786064847e 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -964,6 +964,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
> imx8mm-icore-mx8mm-edimm2.2.dtb \
> imx8mm-kontron-bl.dtb \
> imx8mm-kontron-bl-osm-s.dtb \
> + imx8mm-mt-snowflake-v2.dtb \
> imx8mm-mx8menlo.dtb \
> imx8mm-phg.dtb \
> imx8mm-venice.dtb \
> diff --git a/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
> b/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
> new file mode 100644
> index 0..d6476db292b79
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
> @@ -0,0 +1,116 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Mettler Toledo GmbH
> + */
> +
> +/ {
> +
> + aliases {
> + usbgadget0 =
> + };
> +
> + usbg1: usbg1 {
> + u-boot,dm-spl;
> + compatible = "fsl,imx27-usb-gadget";
> + dr_mode = "peripheral";
> + chipidea,usb = <>;
> + status = "okay";
> + };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + status = "okay";
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +_ecspi1 {
> + u-boot,dm-spl;
> +};
> +
> +_i2c1 {
> + u-boot,dm-spl;
> +};
> +
> +_pmic {
> + u-boot,dm-spl;
> +};
> +
> +_uart3 {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +_usdhc1 {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc1_100mhz {
> + u-boot,dm-spl;
> +};
> +
> +_usdhc1_200mhz {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +&{/soc@0/bus@3080/i2c@30a2/pmic@25/regulators} {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +_wdog {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/imx8mm-mt-snowflake-v2.dts
> b/arch/arm/dts/imx8mm-mt-snowflake-v2.dts
> new file mode 100644
> index 0..49761b22afcf0
> --- /dev/null
> +++ b/arch/arm/dts/imx8mm-mt-snowflake-v2.dts
> @@ -0,0 +1,186 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Mettler Toledo GmbH
> + */
> +
> +/dts-v1/;
> +
> +#include
Re: i.MX8MP SPL failures due to memory corruption/overflow?
Hi Emanuele,
On 15.03.23 22:25, Emanuele Ghidoli wrote:
> [Sie erhalten nicht häufig E-Mails von ghidoliemanu...@gmail.com.
> Weitere Informationen, warum dies wichtig ist, finden Sie unter
> https://aka.ms/LearnAboutSenderIdentification ]
>
> On 15/03/2023 16:24, Frieder Schrempf wrote:
>> On 15.03.23 15:42, Frieder Schrempf wrote:
>>> On 15.03.23 15:17, Michael Nazzareno Trimarchi wrote:
Hi
On Wed, Mar 15, 2023 at 3:13 PM Frieder Schrempf
wrote:
>
> Hi,
>
> I'm trying to bring up a new board based on the i.MX8MP and I have an
> issue I'm hoping someone can help solving.
>
> I'm seeing failures in the early SPL code, usually in the DDR
> initialization. Often they look like:
>
> U-Boot SPL 2023.04-rc3 (Mar 07 2023 - 14:32:34 +)
> Training FAILED
> Failed to initialize DDR RAM!
> ### ERROR ### Please RESET the board ###
>
> But sometimes ddr_init() doesn't even return an error and only the
> get_ram_size() afterwards which tries to allocate the memory fails.
>
In my experience you don't have space inside the cpu internal
memory. It means
that you overlap some stack with the code. Change the printf means
move a bit. So you have
problem but depends what you are going to destroy
>>>
>>> Thanks for your reply. That's exactly what I'm thinking, too.
>>>
> The strange thing is that the issues appear or disappear
> deterministically on the binary level. This means I sometimes get a
> U-Boot binary which runs just fine in 100% of cases. Then I change for
> example one of the following:
>
> * Adding a single printf() somewhere in the boards spl.c
> * Using the same binary but booting from SD card instead of USB loader
> * Using the same source but switching from the OS cross compiler to
> the
> one from Yocto/OE
>
> And afterwards I get 100% failure rate with an error as described
> above.
>
> My suspicion is that there is some memory corruption/conflict. My
> SPL is
> quite large and I wonder if it exceeds some limit.
>
> SPL is loaded to 0x92 and CONFIG_SPL_STACK is set to 0x96,
> which
> leaves 256 KiB in between for the SPL. But all i.MX8MP boards seem to
> set CONFIG_SPL_MAX_SIZE=0x26000 (152 KiB) for some reason. My
> u-boot-spl-ddr.bin currently has around 193 KiB but I don't get any
> warning about exceeding the SPL_MAX_SIZE.
>
> My questions:
>
> * Why is CONFIG_SPL_MAX_SIZE set to 152 KiB?
>>>
>>> I guess the remainder between the SPL code and the SPL stack is for the
>>> DDR firmware. Which explains why I get failures with SPL exceeding 152
>>> KiB size.
>>
>> Still, it doesn't really make sense to me at the moment as the
>> u-boot-spl-ddr.bin already contains the DDR firmware it should be fine
>> to exceed the 152 KiB size. My u-boot-spl.bin (without DDR firmware) is
>> only 135 KiB.
>>
>> Sorry for spamming you by thinking out loud... ;)
>>
>>>
>>> Now I also understand the reason why the power init code was implemented
>>> using legacy non-DM drivers in other i.MX8MP boards. I probably also
>>> need to do this to save some space.
>>>
> * Why is there no warning in my case?
>>>
>>> Still, I fail to see why there isn't any error or where the size check
>>> is even implemented.
>>>
> * Any other ideas or pointers?
>
> Thanks for your help!
>
> Best regards
> Frieder
>>
>
> Hello,
> I fall in a similar problem.
>
> Some hints:
> - commit 5004901efb3b ("board_init: Do not reserve MALLOC_F area on stack
> if non-zero MALLOC_F_ADDR") - but you should already have it
> - Reduce (set to something different from default value)
> SPL_SYS_MALLOC_F_LEN.
> Normally that area is not used a lot. Stack start before heap area and,
> if I remember well, start address of heap area depend upon this config.
> And... its default value is equal to SYS_MALLOC_F_LEN, that normally
> is high.
>
> Suggestions from Rasmus are precious. I adopt a rather similar approch
> to find
> that stack / gd (global data) was overlapping DDR firmware / cfg.
Thanks a lot for the additional pointers. I do have commit 5004901efb3b,
but I didn't look at MALLOC_F_ADDR before. It seems like there are some
i.MX8MP boards which use this to place the malloc area in the separate
OCRAM_S (0x184000) instead of OCRAM which is interesting and another
possibility I didn't know of.
Thanks
Frieder
Re: i.MX8MP SPL failures due to memory corruption/overflow?
Hi Rasmus,
On 15.03.23 16:59, Rasmus Villemoes wrote:
> On 15/03/2023 16.24, Frieder Schrempf wrote:
>> On 15.03.23 15:42, Frieder Schrempf wrote:
>>> On 15.03.23 15:17, Michael Nazzareno Trimarchi wrote:
Hi
On Wed, Mar 15, 2023 at 3:13 PM Frieder Schrempf
wrote:
>
> Hi,
>
> I'm trying to bring up a new board based on the i.MX8MP and I have an
> issue I'm hoping someone can help solving.
>
> I'm seeing failures in the early SPL code, usually in the DDR
> initialization. Often they look like:
>
> U-Boot SPL 2023.04-rc3 (Mar 07 2023 - 14:32:34 +)
> Training FAILED
> Failed to initialize DDR RAM!
> ### ERROR ### Please RESET the board ###
>
> But sometimes ddr_init() doesn't even return an error and only the
> get_ram_size() afterwards which tries to allocate the memory fails.
>
In my experience you don't have space inside the cpu internal memory. It
means
that you overlap some stack with the code. Change the printf means
move a bit. So you have
problem but depends what you are going to destroy
>>>
>>> Thanks for your reply. That's exactly what I'm thinking, too.
>>>
> The strange thing is that the issues appear or disappear
> deterministically on the binary level. This means I sometimes get a
> U-Boot binary which runs just fine in 100% of cases. Then I change for
> example one of the following:
>
> * Adding a single printf() somewhere in the boards spl.c
> * Using the same binary but booting from SD card instead of USB loader
> * Using the same source but switching from the OS cross compiler to the
> one from Yocto/OE
>
> And afterwards I get 100% failure rate with an error as described above.
>
> My suspicion is that there is some memory corruption/conflict. My SPL is
> quite large and I wonder if it exceeds some limit.
>
> SPL is loaded to 0x92 and CONFIG_SPL_STACK is set to 0x96, which
> leaves 256 KiB in between for the SPL. But all i.MX8MP boards seem to
> set CONFIG_SPL_MAX_SIZE=0x26000 (152 KiB) for some reason. My
> u-boot-spl-ddr.bin currently has around 193 KiB but I don't get any
> warning about exceeding the SPL_MAX_SIZE.
>
> I also ran into this problem a while back, but that was back when the
> ddr firmware files were padded to 16K and 32K each to make the magic
> offset computations work; now that binman symbols are used, they only
> take up as much space as they actually use (give or take some 4-byte
> padding perhaps), and I no longer need the debug code I put in place in
> our 2022.07 branch.
>
> Remember that from the stack, the initial (and in SPL only) malloc arena
> is carved out, and if you haven't adjusted SPL_SYS_MALLOC_F_LEN, you
> probably have that set to the default SYS_MALLOC_F_LEN, which in turn
> (on imx8m) defaults to 0x1 aka 64KiB. So that could easily explain
> why you collide with the firmware.
Ok, that's something I missed before and it provides a good explanation
for my problems.
>
> Maybe you can use the debug code I added to our copy of spl.c; I also
> include most of my commit-message-for-future-me. But just something as
> simple as
>
> int dummy;
> printf("stack is around %p\n", );
>
> can be quite valuable.
Thanks for all the valuable information and explanations. This helps a
lot. In the first step I disabled some DM drivers in SPL and use legacy
implementations for the PMIC, GPIO, etc. just as other i.MX8MP boards
do. This seems to shrink the SPL enough to avoid collisions.
But I will also try to optimize SPL_SYS_MALLOC_F_LEN now that I know its
role.
Thanks
Frieder
Re: [PATCH RFC u-boot-mvebu] arm: kirkwood: Move internal registers in arch_very_early_init() function
On 3/11/23 11:57, Pali Rohár wrote:
Same change as was done for mvebu in commit 5bb2c550b11e ("arm: mvebu: Move
internal registers in arch_very_early_init() function") but for kirkwood.
Signed-off-by: Pali Rohár
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Hello! Please test this RFC patch on more Kirkwood boards if there is
any issue with it.
---
arch/arm/mach-kirkwood/Kconfig| 2 ++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/cpu.c | 3 ---
arch/arm/mach-kirkwood/lowlevel.S | 12
4 files changed, 15 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-kirkwood/lowlevel.S
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index c8a193dd4cdf..ba39e9ae416e 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -5,9 +5,11 @@ config FEROCEON_88FR131
config KW88F6192
bool
+ select ARCH_VERY_EARLY_INIT
config KW88F6281
bool
+ select ARCH_VERY_EARLY_INIT
config SHEEVA_88SV131
bool
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 3b2eef8d5419..0fb5a2326f5f 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -6,6 +6,7 @@
obj-y = cpu.o
obj-y += cache.o
+obj-y += lowlevel.o
obj-y += mpp.o
# cpu.o and cache.o contain CP15 instructions which cannot be run in
diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c
index df3e8f11782a..2b493b36c20d 100644
--- a/arch/arm/mach-kirkwood/cpu.c
+++ b/arch/arm/mach-kirkwood/cpu.c
@@ -189,9 +189,6 @@ int arch_cpu_init(void)
struct kwcpu_registers *cpureg =
(struct kwcpu_registers *)KW_CPU_REG_BASE;
- /* Linux expects the internal registers to be at 0xf100 */
- writel(KW_REGS_PHY_BASE, KW_OFFSET_REG);
-
/* Enable and invalidate L2 cache in write through mode */
writel(readl(>l2_cfg) | 0x18, >l2_cfg);
invalidate_l2_cache();
diff --git a/arch/arm/mach-kirkwood/lowlevel.S
b/arch/arm/mach-kirkwood/lowlevel.S
new file mode 100644
index ..3b339f97f056
--- /dev/null
+++ b/arch/arm/mach-kirkwood/lowlevel.S
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#include
+#include
+
+ENTRY(arch_very_early_init)
+ /* Move internal registers from KW_OFFSET_REG to KW_REGS_PHY_BASE */
+ ldr r0, =KW_REGS_PHY_BASE
+ ldr r1, =KW_OFFSET_REG
+ str r0, [r1]
+ bx lr
+ENDPROC(arch_very_early_init)
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] arm: kirkwood: Enable Debug UART for Zyxel NSA310S
On 3/13/23 04:35, Tony Dinh wrote: It's useful to enable Debug UART for future DM Serial regression tests for Kirkwood boards. Also, see background discussion in this thread: https://lists.denx.de/pipermail/u-boot/2023-March/512010.html Signed-off-by: Tony Dinh Reviewed-by: Stefan Roese Thanks, Stefan --- configs/nsa310s_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig index 76839e62dd..b936ae1b25 100644 --- a/configs/nsa310s_defconfig +++ b/configs/nsa310s_defconfig @@ -15,8 +15,11 @@ CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0xE CONFIG_DEFAULT_DEVICE_TREE="kirkwood-nsa310s" CONFIG_SYS_PROMPT="NSA310s> " +CONFIG_DEBUG_UART_BASE=0xf1012000 +CONFIG_DEBUG_UART_CLOCK=16667 CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server" CONFIG_SYS_LOAD_ADDR=0x80 +CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y @@ -50,6 +53,7 @@ CONFIG_MTD_RAW_NAND=y CONFIG_PHY_MARVELL=y CONFIG_MVGBE=y CONFIG_MII=y +CONFIG_DEBUG_UART_SHIFT=2 CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_UBIFS_SILENCE_MSG=y Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] console: Use flush() before panic and reset
On 3/15/23 20:43, Simon Glass wrote: On Tue, 14 Mar 2023 at 18:24, Tony Dinh wrote: To make sure the panic and the reset messages will go out, console flush() should be used. Sleep periods do not work in early u-boot phase when timer driver is not initialized yet. Reference: https://lists.denx.de/pipermail/u-boot/2023-March/512233.html Signed-off-by: Tony Dinh --- arch/arm/lib/reset.c | 4 ++-- lib/panic.c | 4 +++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c index 95169bae1c..3e051e36f1 100644 --- a/arch/arm/lib/reset.c +++ b/arch/arm/lib/reset.c @@ -25,6 +25,7 @@ #include #include #include +#include Reviewed-by: Simon Glass Reviewed-by: Stefan Roese Thanks, Stefan
Re: [PATCH v3 4/5] x86: dfi-bt700: Fix up adjustment of CONFIG_TEXT_BASE
On 3/15/23 00:59, Simon Glass wrote:
With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
several settings.
Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
cache out of the way too.
Signed-off-by: Simon Glass
Fixes: 5d1c8342aea ("x86: dfi-bt700: Adjust CONFIG_TEXT_BASE")
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Changes in v3:
- Add new patch
arch/x86/dts/dfi-bt700.dtsi | 2 +-
configs/dfi-bt700-q7x-151_defconfig | 1 +
configs/theadorable-x86-dfi-bt700_defconfig | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/dts/dfi-bt700.dtsi b/arch/x86/dts/dfi-bt700.dtsi
index dff2345d60d0..c077a84574f1 100644
--- a/arch/x86/dts/dfi-bt700.dtsi
+++ b/arch/x86/dts/dfi-bt700.dtsi
@@ -204,7 +204,7 @@
memory-map = <0xff80 0x0080>;
rw-mrc-cache {
label = "rw-mrc-cache";
- reg = <0x006f 0x0001>;
+ reg = <0x005f 0x0001>;
};
};
};
diff --git a/configs/dfi-bt700-q7x-151_defconfig
b/configs/dfi-bt700-q7x-151_defconfig
index bd8b2e1155d4..a48f7c25134c 100644
--- a/configs/dfi-bt700-q7x-151_defconfig
+++ b/configs/dfi-bt700-q7x-151_defconfig
@@ -13,6 +13,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
diff --git a/configs/theadorable-x86-dfi-bt700_defconfig
b/configs/theadorable-x86-dfi-bt700_defconfig
index 39c8a87fbeea..82c348884559 100644
--- a/configs/theadorable-x86-dfi-bt700_defconfig
+++ b/configs/theadorable-x86-dfi-bt700_defconfig
@@ -15,6 +15,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v3 3/5] x86: conga-qeval20-qa3-e3845: Fix up adjustment of CONFIG_TEXT_BASE
On 3/15/23 00:59, Simon Glass wrote:
With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
several settings.
Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
cache out of the way too.
Signed-off-by: Simon Glass
Fixes: 388f93f9635 ("x86: conga-qeval20-qa3-e3845: Adjust CONFIG_TEXT_BASE")
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Changes in v3:
- Add new patch
arch/x86/dts/conga-qeval20-qa3-e3845.dts | 2 +-
configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 +
configs/conga-qeval20-qa3-e3845_defconfig | 1 +
configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig | 1 +
configs/theadorable-x86-conga-qa3-e3845_defconfig | 1 +
5 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/dts/conga-qeval20-qa3-e3845.dts
b/arch/x86/dts/conga-qeval20-qa3-e3845.dts
index 705157ceaa33..d11e789945ac 100644
--- a/arch/x86/dts/conga-qeval20-qa3-e3845.dts
+++ b/arch/x86/dts/conga-qeval20-qa3-e3845.dts
@@ -193,7 +193,7 @@
memory-map = <0xff80 0x0080>;
rw-mrc-cache {
label = "rw-mrc-cache";
- reg = <0x006f 0x0001>;
+ reg = <0x005f 0x0001>;
};
};
};
diff --git a/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
b/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
index 3a84190bbfdc..f1bfc9653ca7 100644
--- a/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
+++ b/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
@@ -18,6 +18,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
diff --git a/configs/conga-qeval20-qa3-e3845_defconfig
b/configs/conga-qeval20-qa3-e3845_defconfig
index bb8b9ef312a6..09d08a842f09 100644
--- a/configs/conga-qeval20-qa3-e3845_defconfig
+++ b/configs/conga-qeval20-qa3-e3845_defconfig
@@ -14,6 +14,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
diff --git a/configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig
b/configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig
index 74c4a4967d0f..00fa3544bd10 100644
--- a/configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig
+++ b/configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig
@@ -17,6 +17,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
diff --git a/configs/theadorable-x86-conga-qa3-e3845_defconfig
b/configs/theadorable-x86-conga-qa3-e3845_defconfig
index 194b0519ea22..7cf8c551451e 100644
--- a/configs/theadorable-x86-conga-qa3-e3845_defconfig
+++ b/configs/theadorable-x86-conga-qa3-e3845_defconfig
@@ -16,6 +16,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] console: Use flush() before panic and reset
On 3/15/23 21:29, Tony Dinh wrote:
Hi Simon,
On Wed, Mar 15, 2023 at 12:43 PM Simon Glass wrote:
On Tue, 14 Mar 2023 at 18:24, Tony Dinh wrote:
To make sure the panic and the reset messages will go out, console flush()
should be used.
Sleep periods do not work in early u-boot phase when timer driver is not
initialized yet.
Reference: https://lists.denx.de/pipermail/u-boot/2023-March/512233.html
Signed-off-by: Tony Dinh
---
arch/arm/lib/reset.c | 4 ++--
lib/panic.c | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
index 95169bae1c..3e051e36f1 100644
--- a/arch/arm/lib/reset.c
+++ b/arch/arm/lib/reset.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
Reviewed-by: Simon Glass
Is flush implemented widely?
Pali wrote that flush function and here was his comment on the
referenced thread:
"Moreover there is already new function named flush() which
does "wait until stdout message was sent" and can be used instead of
those sleeps. I have already did it on some places (see git history for
flush function) but seems that you find some more."
So I think the answer is not yet widely implemented.
I just checked and it seems it's supported for all platforms using
DM_SERIAL when the serial driver supports the pending() function:
drivers/serial/serial-uclass.c:
#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
static void _serial_flush(struct udevice *dev)
{
struct dm_serial_ops *ops = serial_get_ops(dev);
if (!ops->pending)
return;
while (ops->pending(dev, false) > 0)
;
}
#endif
So AFAICT it's implemented widely. Not sure, why
CONFIG_CONSOLE_FLUSH_SUPPORT was introduced. It's enabled by default
and should be available in all cases IMHO.
Thanks,
Stefan
Re: [PATCH v6 5/7] fwu: meta-data: switch to management by common code
On Thu, 16 Mar 2023 at 13:56, Ilias Apalodimas wrote: > > On Mon, Mar 06, 2023 at 05:18:41PM -0600, jassisinghb...@gmail.com wrote: > > From: Jassi Brar > > > > The common code can now read, verify and fix meta-data copies > > while exposing one consistent structure to users. > > Only the .read_mdata() and .write_mdata() callbacks of fwu_mdata_ops > > are needed. Get rid of .get_mdata() .update_mdata() .get_mdata_part_num() > > .read_mdata_partition() and .write_mdata_partition() and also the > > corresponding wrapper functions. > > > > Signed-off-by: Jassi Brar > > Reviewed-by: Etienne Carriere > > --- > > cmd/fwu_mdata.c | 17 +- > > drivers/fwu-mdata/fwu-mdata-uclass.c | 165 --- > > drivers/fwu-mdata/gpt_blk.c | 124 +- > > include/fwu.h| 199 --- > > lib/fwu_updates/fwu.c| 235 --- > > 5 files changed, 38 insertions(+), 702 deletions(-) > > > Etienne, Sughosh, this looks correct, but can someone > verify it doesn't break the ST board? I will check on the ST board by tomorrow and get back. -sughosh
Re: [PATCH] net: ipv6: Add support for default gateway discovery.
On Thu, 2023-03-02 at 08:58 -0800, emohand...@linux.microsoft.com
wrote:
>
> From: Ehsan Mohandesi
>
> In IPv6, the default gateway and prefix length are determined by
> receiving
> a router advertisement as defined in -
> https://www.rfc-editor.org/rfc/rfc4861.
>
> Add support for sending router solicitation (RS) and processing
> router
> advertisements (RA).
>
> If the RA has prefix info option and following conditions are met,
> then
> gatewayip6 and net_prefix_length of ip6addr env variables are
> initialized.
> These are later consumed by IPv6 code for non-local destination IP.
>
> - "Router Lifetime" != 0
> - Prefix is NOT link-local prefix (0xfe80::/10)
> - L flag is 1
> - "Valid Lifetime" != 0
>
> Timing Parameters:
> - MAX_RTR_SOLICITATION_DELAY (0-1s)
> - RTR_SOLICITATION_INTERVAL (4s) (min retransmit delay)
> - MAX_RTR_SOLICITATIONS (3 RS transmissions)
>
> The functionality is enabled by CONFIG_IPV6_ROUTER_DISCOVERY and
> invoked
> automatically from net_init_loop().
>
> Signed-off-by: Ehsan Mohandesi
>
> Conflicts:
> cmd/Kconfig
> include/net.h
> net/net.c
> ---
> cmd/Kconfig | 7 ++
> include/ndisc.h | 23 ++
> include/net.h | 2 +-
> include/net6.h | 40 ++
> net/ndisc.c | 243
> +---
> net/net.c | 23 +-
> net/net6.c | 1 +
> 7 files changed, 327 insertions(+), 12 deletions(-)
>
I reviewed this patch and it looks good. I have no critical remarks,
only some small notes.
I've tested it on SiFive Unmatched board.
>
> +config IPV6_ROUTER_DISCOVERY
> + bool "Do router discovery"
> + depends on IPV6
> + help
> + Will automatically perform router solicitation on first
> IPv6
> + network operation
> +
> endif
>
I think it is better to write sth like Do IPv6 router discovery because
IPv4 has also router discovery protocol and it could lead to
misunderstanding
>
> net_set_timeout_handler(0, 0);
>
Maybe net_set_timeout_handler(0, NULL); is better
> +/*
> + * validate_ra() - Validate the router advertisement message.
> + *
> + * @ip6:
> + * @len: Length of the router advertisement packet
> + *
> + * Check if the router advertisement message is valid. Conditions
> are
> + * according to RFC 4861 section 6.1.2. Validation of Router
> Advertisement
> + * Messages.
> + *
> + * Return: true if the message is valid and false if it is invalid.
> + */
> +static bool validate_ra(struct ip6_hdr *ip6, int len)
> +{
> + struct icmp6hdr *icmp = (struct icmp6hdr *)(ip6 + 1);
> +
> + /* ICMP length (derived from the IP length) should be 16 or
> more octets. */
> + if (ip6->payload_len < 16)
> + return false;
> +
> + /* Source IP Address should be a valid link-local address. */
> + if ((ntohs(ip6->saddr.s6_addr16[0]) & IPV6_LINK_LOCAL_MASK)
> !=
> + IPV6_LINK_LOCAL_PREFIX)
> + return false;
> +
> + /*
> +* The IP Hop Limit field should have a value of 255, i.e.,
> the packet
> +* could not possibly have been forwarded by a router.
> +*/
> + if (ip6->hop_limit != 255)
> + return false;
> +
Unicast hop limit only?
> diff --git a/net/net.c b/net/net.c
> index c9a749f..39f0b81 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -24,7 +24,7 @@
> * - name of bootfile
> * Next step: ARP
> *
> - * LINK_LOCAL:
> + * LINKLOCAL:
>
Maybe it is better to move to other patch?!
Reviewed-by: Viacheslav Mitrofanov
Tested-by: Viacheslav Mitrofanov
Re: [PATCH v9 2/6] tpm: sandbox: Update for needed TPM2 capabilities
Hi Eddie,
Apologies for the late reply, I am now getting back on this.
There are some failures on the CI wrt to sandbox here [0]. Can you have a
look ?
Also I believe some of the existing tests are wrong because they are
using PCR0 (which is always going to be extended). Can you also pick up
[1] with your series?
[0] https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/15471
[1]
https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/0d28387cac5fafa59e4367d1548e021eeebe2004
Thanks
/Ilias
On Wed, Mar 08, 2023 at 03:25:33PM -0600, Eddie James wrote:
> The driver needs to support getting the PCRs in the capabilities
> command. Fix various other things and support the max number
> of PCRs for TPM2.
> Remove the !SANDBOX dependency for EFI TCG2 as well.
>
> Signed-off-by: Eddie James
> Reviewed-by: Simon Glass
> Acked-by: Ilias Apalodimas
> ---
> Changes since v8:
> - Use >= for checking the property against TPM2_PROPERTIES_OFFSET
>
> Changes since v5:
> - Remove the !SANDBOX dependency for EFI TCG2
>
> drivers/tpm/tpm2_tis_sandbox.c | 100 -
> lib/efi_loader/Kconfig | 2 -
> 2 files changed, 72 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/tpm/tpm2_tis_sandbox.c b/drivers/tpm/tpm2_tis_sandbox.c
> index e4004cfcca..d15a28d9fc 100644
> --- a/drivers/tpm/tpm2_tis_sandbox.c
> +++ b/drivers/tpm/tpm2_tis_sandbox.c
> @@ -22,11 +22,6 @@ enum tpm2_hierarchy {
> TPM2_HIERARCHY_NB,
> };
>
> -/* Subset of supported capabilities */
> -enum tpm2_capability {
> - TPM_CAP_TPM_PROPERTIES = 0x6,
> -};
> -
> /* Subset of supported properties */
> #define TPM2_PROPERTIES_OFFSET 0x020E
>
> @@ -38,7 +33,8 @@ enum tpm2_cap_tpm_property {
> TPM2_PROPERTY_NB,
> };
>
> -#define SANDBOX_TPM_PCR_NB 1
> +#define SANDBOX_TPM_PCR_NB TPM2_MAX_PCRS
> +#define SANDBOX_TPM_PCR_SELECT_MAX ((SANDBOX_TPM_PCR_NB + 7) / 8)
>
> /*
> * Information about our TPM emulation. This is preserved in the sandbox
> @@ -433,7 +429,7 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const
> u8 *sendbuf,
> int i, j;
>
> /* TPM2_GetProperty */
> - u32 capability, property, property_count;
> + u32 capability, property, property_count, val;
>
> /* TPM2_PCR_Read/Extend variables */
> int pcr_index = 0;
> @@ -542,19 +538,32 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const
> u8 *sendbuf,
> case TPM2_CC_GET_CAPABILITY:
> capability = get_unaligned_be32(sent);
> sent += sizeof(capability);
> - if (capability != TPM_CAP_TPM_PROPERTIES) {
> - printf("Sandbox TPM only support TPM_CAPABILITIES\n");
> - return TPM2_RC_HANDLE;
> - }
> -
> property = get_unaligned_be32(sent);
> sent += sizeof(property);
> - property -= TPM2_PROPERTIES_OFFSET;
> -
> property_count = get_unaligned_be32(sent);
> sent += sizeof(property_count);
> - if (!property_count ||
> - property + property_count > TPM2_PROPERTY_NB) {
> +
> + switch (capability) {
> + case TPM2_CAP_PCRS:
> + break;
> + case TPM2_CAP_TPM_PROPERTIES:
> + if (!property_count) {
> + rc = TPM2_RC_HANDLE;
> + return sandbox_tpm2_fill_buf(recv, recv_len,
> + tag, rc);
> + }
> +
> + if (property >= TPM2_PROPERTIES_OFFSET &&
> + ((property - TPM2_PROPERTIES_OFFSET) +
> + property_count > TPM2_PROPERTY_NB)) {
> + rc = TPM2_RC_HANDLE;
> + return sandbox_tpm2_fill_buf(recv, recv_len,
> + tag, rc);
> + }
> + break;
> + default:
> + printf("Sandbox TPM2 only supports TPM2_CAP_PCRS or "
> +"TPM2_CAP_TPM_PROPERTIES\n");
> rc = TPM2_RC_HANDLE;
> return sandbox_tpm2_fill_buf(recv, recv_len, tag, rc);
> }
> @@ -578,18 +587,53 @@ static int sandbox_tpm2_xfer(struct udevice *dev, const
> u8 *sendbuf,
> put_unaligned_be32(capability, recv);
> recv += sizeof(capability);
>
> - /* Give the number of properties that follow */
> - put_unaligned_be32(property_count, recv);
> - recv += sizeof(property_count);
> -
> - /* Fill with the properties */
> - for (i = 0; i < property_count; i++) {
> - put_unaligned_be32(TPM2_PROPERTIES_OFFSET + property +
> -i, recv);
> - recv += sizeof(property);
> -
Re: [PATCH v6 5/7] fwu: meta-data: switch to management by common code
On Mon, Mar 06, 2023 at 05:18:41PM -0600, jassisinghb...@gmail.com wrote:
> From: Jassi Brar
>
> The common code can now read, verify and fix meta-data copies
> while exposing one consistent structure to users.
> Only the .read_mdata() and .write_mdata() callbacks of fwu_mdata_ops
> are needed. Get rid of .get_mdata() .update_mdata() .get_mdata_part_num()
> .read_mdata_partition() and .write_mdata_partition() and also the
> corresponding wrapper functions.
>
> Signed-off-by: Jassi Brar
> Reviewed-by: Etienne Carriere
> ---
> cmd/fwu_mdata.c | 17 +-
> drivers/fwu-mdata/fwu-mdata-uclass.c | 165 ---
> drivers/fwu-mdata/gpt_blk.c | 124 +-
> include/fwu.h| 199 ---
> lib/fwu_updates/fwu.c| 235 ---
> 5 files changed, 38 insertions(+), 702 deletions(-)
>
> diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
> index f04af27de6..9b70340368 100644
> --- a/cmd/fwu_mdata.c
> +++ b/cmd/fwu_mdata.c
> @@ -43,23 +43,10 @@ static void print_mdata(struct fwu_mdata *mdata)
> int do_fwu_mdata_read(struct cmd_tbl *cmdtp, int flag,
>int argc, char * const argv[])
> {
> - struct udevice *dev;
> int ret = CMD_RET_SUCCESS, res;
> - struct fwu_mdata mdata = { 0 };
> + struct fwu_mdata mdata;
>
> - if (uclass_get_device(UCLASS_FWU_MDATA, 0, ) || !dev) {
> - log_err("Unable to get FWU metadata device\n");
> - return CMD_RET_FAILURE;
> - }
> -
> - res = fwu_check_mdata_validity();
> - if (res < 0) {
> - log_err("FWU Metadata check failed\n");
> - ret = CMD_RET_FAILURE;
> - goto out;
> - }
> -
> - res = fwu_get_mdata(dev, );
> + res = fwu_get_verified_mdata();
> if (res < 0) {
> log_err("Unable to get valid FWU metadata\n");
> ret = CMD_RET_FAILURE;
> diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c
> b/drivers/fwu-mdata/fwu-mdata-uclass.c
> index e03773c584..0a8edaaa41 100644
> --- a/drivers/fwu-mdata/fwu-mdata-uclass.c
> +++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
> @@ -14,7 +14,6 @@
>
> #include
> #include
> -#include
>
> /**
> * fwu_read_mdata() - Wrapper around fwu_mdata_ops.read_mdata()
> @@ -50,170 +49,6 @@ int fwu_write_mdata(struct udevice *dev, struct fwu_mdata
> *mdata, bool primary)
> return ops->write_mdata(dev, mdata, primary);
> }
>
> -/**
> - * fwu_get_mdata_part_num() - Get the FWU metadata partition numbers
> - * @dev: FWU metadata device
> - * @mdata_parts: array for storing the metadata partition numbers
> - *
> - * Get the partition numbers on the storage device on which the
> - * FWU metadata is stored. Two partition numbers will be returned.
> - *
> - * Return: 0 if OK, -ve on error
> - *
> - */
> -int fwu_get_mdata_part_num(struct udevice *dev, uint *mdata_parts)
> -{
> - const struct fwu_mdata_ops *ops = device_get_ops(dev);
> -
> - if (!ops->get_mdata_part_num) {
> - log_debug("get_mdata_part_num() method not defined\n");
> - return -ENOSYS;
> - }
> -
> - return ops->get_mdata_part_num(dev, mdata_parts);
> -}
> -
> -/**
> - * fwu_read_mdata_partition() - Read the FWU metadata from a partition
> - * @dev: FWU metadata device
> - * @mdata: Copy of the FWU metadata
> - * @part_num: Partition number from which FWU metadata is to be read
> - *
> - * Read the FWU metadata from the specified partition number
> - *
> - * Return: 0 if OK, -ve on error
> - *
> - */
> -int fwu_read_mdata_partition(struct udevice *dev, struct fwu_mdata *mdata,
> - uint part_num)
> -{
> - const struct fwu_mdata_ops *ops = device_get_ops(dev);
> -
> - if (!ops->read_mdata_partition) {
> - log_debug("read_mdata_partition() method not defined\n");
> - return -ENOSYS;
> - }
> -
> - return ops->read_mdata_partition(dev, mdata, part_num);
> -}
> -
> -/**
> - * fwu_write_mdata_partition() - Write the FWU metadata to a partition
> - * @dev: FWU metadata device
> - * @mdata: Copy of the FWU metadata
> - * @part_num: Partition number to which FWU metadata is to be written
> - *
> - * Write the FWU metadata to the specified partition number
> - *
> - * Return: 0 if OK, -ve on error
> - *
> - */
> -int fwu_write_mdata_partition(struct udevice *dev, struct fwu_mdata *mdata,
> - uint part_num)
> -{
> - const struct fwu_mdata_ops *ops = device_get_ops(dev);
> -
> - if (!ops->write_mdata_partition) {
> - log_debug("write_mdata_partition() method not defined\n");
> - return -ENOSYS;
> - }
> -
> - return ops->write_mdata_partition(dev, mdata, part_num);
> -}
> -
> -/**
> - * fwu_mdata_check() - Check if the FWU metadata is valid
> - * @dev: FWU metadata device
> - *
> - * Validate both copies of the FWU metadata. If one of the copies
> - * has gone bad, restore it from
Re: [PATCH v6 3/7] fwu: move meta-data management in core
On Mon, Mar 06, 2023 at 05:18:28PM -0600, jassisinghb...@gmail.com wrote:
> From: Jassi Brar
>
> Instead of each i/f having to implement their own meta-data verification
> and storage, move the logic in common code. This simplifies the i/f code
> much simpler and compact.
>
> Signed-off-by: Jassi Brar
> ---
> drivers/fwu-mdata/fwu-mdata-uclass.c | 34 +++
> include/fwu.h| 41 +
> lib/fwu_updates/fwu.c| 131 ++-
> 3 files changed, 201 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/fwu-mdata/fwu-mdata-uclass.c
> b/drivers/fwu-mdata/fwu-mdata-uclass.c
> index b477e9603f..e03773c584 100644
> --- a/drivers/fwu-mdata/fwu-mdata-uclass.c
> +++ b/drivers/fwu-mdata/fwu-mdata-uclass.c
> @@ -16,6 +16,40 @@
> #include
> #include
>
> +/**
> + * fwu_read_mdata() - Wrapper around fwu_mdata_ops.read_mdata()
> + *
> + * Return: 0 if OK, -ve on error
> + */
> +int fwu_read_mdata(struct udevice *dev, struct fwu_mdata *mdata, bool
> primary)
> +{
> + const struct fwu_mdata_ops *ops = device_get_ops(dev);
> +
> + if (!ops->read_mdata) {
> + log_debug("read_mdata() method not defined\n");
> + return -ENOSYS;
> + }
> +
> + return ops->read_mdata(dev, mdata, primary);
> +}
> +
> +/**
> + * fwu_write_mdata() - Wrapper around fwu_mdata_ops.write_mdata()
> + *
> + * Return: 0 if OK, -ve on error
> + */
> +int fwu_write_mdata(struct udevice *dev, struct fwu_mdata *mdata, bool
> primary)
> +{
> + const struct fwu_mdata_ops *ops = device_get_ops(dev);
> +
> + if (!ops->write_mdata) {
> + log_debug("write_mdata() method not defined\n");
> + return -ENOSYS;
> + }
> +
> + return ops->write_mdata(dev, mdata, primary);
> +}
> +
> /**
> * fwu_get_mdata_part_num() - Get the FWU metadata partition numbers
> * @dev: FWU metadata device
> diff --git a/include/fwu.h b/include/fwu.h
> index 0919ced812..13f8fdeb28 100644
> --- a/include/fwu.h
> +++ b/include/fwu.h
> @@ -24,6 +24,26 @@ struct fwu_mdata_gpt_blk_priv {
> * @update_mdata() - Update the FWU metadata copy
> */
> struct fwu_mdata_ops {
> + /**
> + * read_mdata() - Populate the asked FWU metadata copy
> + * @dev: FWU metadata device
> + * @mdata: Output FWU mdata read
> + * @primary: If primary or secondary copy of metadata is to be read
> + *
> + * Return: 0 if OK, -ve on error
> + */
> + int (*read_mdata)(struct udevice *dev, struct fwu_mdata *mdata, bool
> primary);
> +
> + /**
> + * write_mdata() - Write the given FWU metadata copy
> + * @dev: FWU metadata device
> + * @mdata: Copy of the FWU metadata to write
> + * @primary: If primary or secondary copy of metadata is to be written
> + *
> + * Return: 0 if OK, -ve on error
> + */
> + int (*write_mdata)(struct udevice *dev, struct fwu_mdata *mdata, bool
> primary);
> +
> /**
>* check_mdata() - Check if the FWU metadata is valid
>* @dev:FWU device
> @@ -126,6 +146,27 @@ struct fwu_mdata_ops {
> EFI_GUID(0x0c996046, 0xbcc0, 0x4d04, 0x85, 0xec, \
>0xe1, 0xfc, 0xed, 0xf1, 0xc6, 0xf8)
>
> +/**
> + * fwu_read_mdata() - Wrapper around fwu_mdata_ops.read_mdata()
> + */
> +int fwu_read_mdata(struct udevice *dev, struct fwu_mdata *mdata, bool
> primary);
> +
> +/**
> + * fwu_write_mdata() - Wrapper around fwu_mdata_ops.write_mdata()
> + */
> +int fwu_write_mdata(struct udevice *dev, struct fwu_mdata *mdata, bool
> primary);
> +
> +/**
> + * fwu_get_verified_mdata() - Read, verify and return the FWU metadata
> + *
> + * Read both the metadata copies from the storage media, verify their
> checksum,
> + * and ascertain that both copies match. If one of the copies has gone bad,
> + * restore it from the good copy.
> + *
> + * Return: 0 if OK, -ve on error
> +*/
> +int fwu_get_verified_mdata(struct fwu_mdata *mdata);
> +
> /**
> * fwu_check_mdata_validity() - Check for validity of the FWU metadata copies
> *
> diff --git a/lib/fwu_updates/fwu.c b/lib/fwu_updates/fwu.c
> index 5313d07302..8f1c05ad1c 100644
> --- a/lib/fwu_updates/fwu.c
> +++ b/lib/fwu_updates/fwu.c
> @@ -15,13 +15,13 @@
> #include
> #include
>
> +#include
> +
> +static struct fwu_mdata g_mdata; /* = {0} makes uninit crc32 always invalid
> */
> +static struct udevice *g_dev;
> static u8 in_trial;
> static u8 boottime_check;
>
> -#include
> -#include
> -#include
> -
> enum {
> IMAGE_ACCEPT_SET = 1,
> IMAGE_ACCEPT_CLEAR,
> @@ -161,6 +161,127 @@ static int fwu_get_image_type_id(u8 *image_index,
> efi_guid_t *image_type_id)
> return -ENOENT;
> }
>
> +/**
> + * fwu_sync_mdata() - Update given meta-data partition(s) with the copy
> provided
> + * @mdata: FWU metadata structure
> + * @part: Bitmask of FWU metadata partitions to be written to
> + *
> + * Return: 0 if OK, -ve on error
> + */
> +static int fwu_sync_mdata(struct
Re: [PATCH 0/9] binman: Show missing blob message when building U-Boot
Hi Simon, On 2023-03-10 21:49, Simon Glass wrote: > Hi Jonas, > > On Sun, 19 Feb 2023 at 14:02, Jonas Karlman wrote: >> >> binman currently support showing a helpful missing blob message, but >> only when the --allow-missing flag is used. >> >> This changes so that binman is invoked with the --allow-missing flag >> and the helpful message can be shown by default when building U-Boot. >> >> Using the following: >> >> make rockpro64-rk3399_defconfig >> make CROSS_COMPILE="aarch64-linux-gnu-" >> >> Before this series a build fails with: >> >> binman: Filename 'atf-bl31' not found in input path (...) >> >> After this series a build fails with: >> >> Image 'simple-bin' is missing external blobs and is non-functional: >> atf-bl31 >> >> /binman/simple-bin/fit/images/@atf-SEQ/atf-bl31 (atf-bl31): >> See the documentation for your board. You may need to build ARM Trusted >> Firmware and build with BL31=/path/to/bl31.bin >> >> Image 'simple-bin' is missing external blobs but is still functional: >> tee-os >> >> /binman/simple-bin/fit/images/@tee-SEQ/tee-os (tee-os): >> See the documentation for your board. You may need to build Open >> Portable >> Trusted Execution Environment (OP-TEE) with TEE=/path/to/tee.bin >> >> Some images are invalid >> >> Builds will continue to fail when there is missing blobs, and the use of >> BINMAN_ALLOW_MISSING=1 now only enables the --ignore-missing flag. >> >> This series also fixes a few minor issues that prevented some missing >> and optional blobs to be detected for fit and mkimage entries. >> >> Patch 1-3 contains spelling fixes and code cleanup for related parts. >> Patch 4-6 improve missing/optional detection for fit and mkimage entries. >> Patch 7-8 improve the missing blob warning message output. >> Patch 9 finally update Makefile to always pass the --allow-missing flag. >> >> The series is based on top of [1], and is the follow-up series meant to >> address the issue with missing blob message for mkimage entries. >> >> [1] >> https://patchwork.ozlabs.org/project/uboot/cover/20230219150629.4012377-1-jo...@kwiboo.se/ >> >> Jonas Karlman (9): >> binman: Remove redundant SetAllowFakeBlob from blob-ext entry >> binman: Fix spelling of nodes in code comments >> binman: Use correct argument name in docstrings >> binman: Override CheckOptional in fit entry >> binman: Implement missing check functions in mkimage entry >> binman: Mark mkimage entry missing when its subnodes is missing >> binman: Fix blank line usage for invalid images warning text >> binman: Show filename in missing blob help message >> Makefile: Show binman missing blob message >> >> Makefile | 2 +- >> tools/binman/control.py | 24 ++--- >> tools/binman/entry.py | 2 +- >> tools/binman/etype/blob.py| 2 +- >> tools/binman/etype/blob_ext.py| 8 --- >> tools/binman/etype/fit.py | 9 +++- >> tools/binman/etype/mkimage.py | 54 ++- >> tools/binman/etype/section.py | 6 +-- >> tools/binman/ftest.py | 9 >> tools/binman/state.py | 2 +- >> .../test/278_mkimage_missing_multiple.dts | 19 +++ >> 11 files changed, 111 insertions(+), 26 deletions(-) >> create mode 100644 tools/binman/test/278_mkimage_missing_multiple.dts >> >> -- >> 2.39.2 >> > > I applied what I could of this to -next > > Could you please take another look and see if we can get the rest in? Sure, I will take a look at a v2 (with more tests) in next few days. Still unclear what to do about "Makefile: Show binman missing blob message" at [2]. Should I re-send it as-is, change it or just drop it? [2] https://patchwork.ozlabs.org/project/uboot/patch/20230219220158.4160763-10-jo...@kwiboo.se/#3063614 Regards, Jonas > > Regards, > Simon
Re: [PATCH v3 1/5] x86: minnowmax: Fix up adjustment of CONFIG_TEXT_BASE
On Thu, Mar 16, 2023 at 3:27 PM Bin Meng wrote:
>
> On Wed, Mar 15, 2023 at 8:00 AM Simon Glass wrote:
> >
> > With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
> > several settings.
> >
> > Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
> > cache out of the way too.
> >
> > Add documentation on how to make this change safely.
> >
> > Signed-off-by: Simon Glass
> > Fixes: 66e2c665f ("x86: minnowmax: Adjust CONFIG_TEXT_BASE")
> > ---
> >
> > Changes in v3:
> > - Squash commits
> > - Fix ordering of Environment in docs
> > - Fix value of CONFIG_TEXT_BASE in docs
> > - Change the commit message and subject
> >
> > Changes in v2:
> > - Add new patch which boots while still enabling EFI_LOADER
> >
> > arch/x86/dts/minnowmax.dts| 2 +-
> > configs/minnowmax_defconfig | 1 +
> > doc/board/intel/minnowmax.rst | 15 +--
> > 3 files changed, 15 insertions(+), 3 deletions(-)
> >
>
> Reviewed-by: Bin Meng
series applied to u-boot-x86, thanks!
Re: [PATCH v3 5/5] x86: som-db5800-som-6867: Fix up adjustment of CONFIG_TEXT_BASE
On Wed, Mar 15, 2023 at 8:00 AM Simon Glass wrote:
>
> With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
> several settings.
>
> Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
> cache out of the way too.
>
> Signed-off-by: Simon Glass
> Fixes: e23cae30801 ("x86: som-db5800-som-6867: Adjust CONFIG_TEXT_BASE")
> ---
>
> Changes in v3:
> - Add new patch
>
> arch/x86/dts/baytrail_som-db5800-som-6867.dts | 2 +-
> configs/som-db5800-som-6867_defconfig | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
Re: [PATCH v3 4/5] x86: dfi-bt700: Fix up adjustment of CONFIG_TEXT_BASE
On Wed, Mar 15, 2023 at 8:00 AM Simon Glass wrote:
>
> With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
> several settings.
>
> Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
> cache out of the way too.
>
> Signed-off-by: Simon Glass
> Fixes: 5d1c8342aea ("x86: dfi-bt700: Adjust CONFIG_TEXT_BASE")
> ---
>
> Changes in v3:
> - Add new patch
>
> arch/x86/dts/dfi-bt700.dtsi | 2 +-
> configs/dfi-bt700-q7x-151_defconfig | 1 +
> configs/theadorable-x86-dfi-bt700_defconfig | 1 +
> 3 files changed, 3 insertions(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
Re: [PATCH v3 3/5] x86: conga-qeval20-qa3-e3845: Fix up adjustment of CONFIG_TEXT_BASE
On Wed, Mar 15, 2023 at 8:00 AM Simon Glass wrote:
>
> With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
> several settings.
>
> Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
> cache out of the way too.
>
> Signed-off-by: Simon Glass
> Fixes: 388f93f9635 ("x86: conga-qeval20-qa3-e3845: Adjust CONFIG_TEXT_BASE")
> ---
>
> Changes in v3:
> - Add new patch
>
> arch/x86/dts/conga-qeval20-qa3-e3845.dts | 2 +-
> configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 +
> configs/conga-qeval20-qa3-e3845_defconfig | 1 +
> configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig | 1 +
> configs/theadorable-x86-conga-qa3-e3845_defconfig | 1 +
> 5 files changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
Re: [PATCH v3 2/5] x86: bayleybay: Fix up adjustment of CONFIG_TEXT_BASE
On Wed, Mar 15, 2023 at 8:00 AM Simon Glass wrote:
>
> With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
> several settings.
>
> Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
> cache out of the way too.
>
> Signed-off-by: Simon Glass
> Fixes: f38be308683 ("x86: bayleybay: Adjust CONFIG_TEXT_BASE")
> ---
>
> Changes in v3:
> - Add new patch
>
> arch/x86/dts/bayleybay.dts | 2 +-
> configs/bayleybay_defconfig | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
Re: [PATCH v3 1/5] x86: minnowmax: Fix up adjustment of CONFIG_TEXT_BASE
On Wed, Mar 15, 2023 at 8:00 AM Simon Glass wrote:
>
> With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
> several settings.
>
> Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
> cache out of the way too.
>
> Add documentation on how to make this change safely.
>
> Signed-off-by: Simon Glass
> Fixes: 66e2c665f ("x86: minnowmax: Adjust CONFIG_TEXT_BASE")
> ---
>
> Changes in v3:
> - Squash commits
> - Fix ordering of Environment in docs
> - Fix value of CONFIG_TEXT_BASE in docs
> - Change the commit message and subject
>
> Changes in v2:
> - Add new patch which boots while still enabling EFI_LOADER
>
> arch/x86/dts/minnowmax.dts| 2 +-
> configs/minnowmax_defconfig | 1 +
> doc/board/intel/minnowmax.rst | 15 +--
> 3 files changed, 15 insertions(+), 3 deletions(-)
>
Reviewed-by: Bin Meng
[PATCH 2/2] configs: stm32mp13: Increase usb_pgood_delay for ST boards
With some USB device, the current usb_pgood_delay value is not long enough to ensure a correct detection. Signed-off-by: Patrice Chotard --- include/configs/stm32mp13_st_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/stm32mp13_st_common.h b/include/configs/stm32mp13_st_common.h index ad8126f6103..20ec11477d6 100644 --- a/include/configs/stm32mp13_st_common.h +++ b/include/configs/stm32mp13_st_common.h @@ -9,7 +9,7 @@ #define __CONFIG_STM32MP13_ST_COMMON_H__ #define STM32MP_BOARD_EXTRA_ENV \ - "usb_pgood_delay=1000\0" \ + "usb_pgood_delay=2000\0" \ "console=ttySTM0\0" #include -- 2.25.1
[PATCH 1/2] configs: stm32mp15: Add usb_pgood_delay for ST boards
Add usb_pgood_delay to ensure a correct detection of USB devices. Signed-off-by: Patrice Chotard --- include/configs/stm32mp15_st_common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/stm32mp15_st_common.h b/include/configs/stm32mp15_st_common.h index d0cd4130cec..866cd7a719f 100644 --- a/include/configs/stm32mp15_st_common.h +++ b/include/configs/stm32mp15_st_common.h @@ -9,6 +9,7 @@ #define __CONFIG_STM32MP15_ST_COMMON_H__ #define STM32MP_BOARD_EXTRA_ENV \ + "usb_pgood_delay=2000\0" \ "console=ttySTM0\0" #include -- 2.25.1
