Re: [PATCH] xilinx: Allow alternative boot strategies in zynq-common.h
On 3/7/25 07:29, Mike Looijmans wrote: Allow config headers that include zynq-common.h to provide their own (distro) boot strategies. This is implemented by skipping the section when BOOT_ENV has already been defined. Signed-off-by: Mike Looijmans --- include/configs/zynq-common.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h index 37c77aa1611..ad872c9d922 100644 --- a/include/configs/zynq-common.h +++ b/include/configs/zynq-common.h @@ -48,6 +48,9 @@ #define BOOTENV #else +/* Only use this section if no BOOTENV has been configured yet */ +#ifndef BOOTENV + #ifdef CONFIG_CMD_MMC #define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0) func(MMC, mmc, 1) #else @@ -167,6 +170,9 @@ BOOT_TARGET_DEVICES_DHCP(func) #include + +#endif /* BOOTENV */ + #endif /* CONFIG_XPL_BUILD */ /* Default environment */ Just for the record v2 was sent. M
Re: [RFC PATCH 3/4] drivers: k3_fuse: Add fuse sub-system func calls
On 13/03/25 21:49, Tom Rini wrote: On Thu, Mar 13, 2025 at 05:25:16PM +0530, Harsha Vardhan V M wrote: Add K3_FUSE config option to add and enable fuse sub-system implementation function calls. Signed-off-by: Harsha Vardhan V M Reviewed-by: Tom Rini And can you please file an issue on https://source.denx.de/u-boot/u-boot/-/issues/ to further clean-up the fuse related Kconfig symbols and logic? What we have today is a bit odd, but it's I think easier for me to go and shuffle things than explain how I think it should be. Thanks. Filed an issue here, https://source.denx.de/u-boot/u-boot/-/issues/48 Thanks, Harsha
Re: [PATCH] cmd: version: Get information about GCC and LD back
Hi Tom,
On 3/10/25 14:56, Tom Rini wrote:
On Mon, Mar 10, 2025 at 08:49:32AM +0100, Michal Simek wrote:
On 3/6/25 15:12, Michal Simek wrote:
On 3/6/25 15:02, Tom Rini wrote:
On Thu, Mar 06, 2025 at 11:12:30AM +0100, Michal Simek wrote:
U-Boot version command is no longer showing information about GCC and LD.
The reason is that version.h has been removed that's why CC_VERSION_STRING
and LD_VERSION_STRING are not pass.
Values are generated to generated/version_autogenerated.h which is sourced
in version.h.
Fixes: 54ecce2cbf90 ("version: Separate our version string from
the version command")
Signed-off-by: Michal Simek
---
Tom: Not sure if this has been done on purpose or not but this issue has
been reported by our regression team.
It wasn't on purpose, no. Did you put this through CI / confirm
sandbox_nocmdline still builds?
Nope I did not.
CI is not reporting any issue.
https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/25029
Are you going to take this to 2025.04?
Or to next?
I don't mind. I can also take it via my tree just let me know.
Thanks,
Michal
Re: [PATCH 1/1] drivers: fpga: Add partial reconfiguration console commands
On 3/14/25 12:47, Naresh Kumar Ravulapalli wrote:
Partial Reconfiguration (pr) command is added to U-Boot console. The
pr command will use the Freeze Controller which can freeze and
unfreeze the specified partial reconfiguration region. The pr command
supports multiple regions for partial reconfiguration by specifying
the region ID.
Signed-off-by: Naresh Kumar Ravulapalli
---
drivers/fpga/Kconfig| 9 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/intel_pr.c | 191
3 files changed, 201 insertions(+)
create mode 100644 drivers/fpga/intel_pr.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 62cb77b098..bf34d11a9d 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -66,6 +66,15 @@ config FPGA_LATTICE
This is used for the lattice FPGAs. Please check the source code as
there is no documentation for this at present.
+config FPGA_INTEL_PR
+ bool "Enable Intel FPGA Partial Reconfiguration driver"
+ depends on FPGA_ALTERA
+ help
+ Say Y here to enable the Intel FPGA Partial Reconfiguration driver
+
+ This provides basic functionality for partial reconfiguration which
+ include the freeze controller support.
+
config FPGA_XILINX
bool "Enable Xilinx FPGA drivers"
select FPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 610c168fc3..70a8f88836 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -25,4 +25,5 @@ obj-$(CONFIG_FPGA_STRATIX_V) += stratixv.o
obj-$(CONFIG_FPGA_SOCFPGA) += socfpga.o
obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += socfpga_gen5.o
obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += socfpga_arria10.o
+obj-$(CONFIG_FPGA_INTEL_PR) += intel_pr.o
endif
diff --git a/drivers/fpga/intel_pr.c b/drivers/fpga/intel_pr.c
new file mode 100644
index 00..ecca2c9eeb
--- /dev/null
+++ b/drivers/fpga/intel_pr.c
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Intel Corporation
2018? That's quite old file.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define FREEZE_CSR_STATUS_OFFSET 0
+#define FREEZE_CSR_CTRL_OFFSET 4
+#define FREEZE_CSR_ILLEGAL_REQ_OFFSET 8
+#define FREEZE_CSR_REG_VERSION 12
+
+#define FREEZE_TIMEOUT 2
+
+#define FREEZE_CSR_STATUS_FREEZE_REQ_DONE BIT(0)
+#define FREEZE_CSR_STATUS_UNFREEZE_REQ_DONEBIT(1)
+
+#define FREEZE_CSR_CTRL_FREEZE_REQ BIT(0)
+#define FREEZE_CSR_CTRL_RESET_REQ BIT(1)
+#define FREEZE_CSR_CTRL_UNFREEZE_REQ BIT(2)
+
+static int intel_get_freeze_br_addr(fdt_addr_t *addr, unsigned int region)
+{
+ int offset;
+ char freeze_br[12];
+ struct fdt_resource r;
+ int ret;
+
+ snprintf(freeze_br, sizeof(freeze_br), "freeze_br%d", region);
_ is not allowed char for alias.
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/aliases.yaml#L30
+
+ const char *alias = fdt_get_alias(gd->fdt_blob, freeze_br);
+
+ if (!alias) {
+ printf("alias %s not found in dts\n", freeze_br);
+ return -ENODEV;
+ }
+
+ offset = fdt_path_offset(gd->fdt_blob, alias);
+ if (offset < 0) {
+ printf("%s not found in dts\n", alias);
+ return -ENODEV;
+ }
+
+ ret = fdt_get_resource(gd->fdt_blob, offset, "reg", 0, &r);
+ if (ret) {
+ printf("%s has no 'reg' property!\n", freeze_br);
+ return ret;
+ }
+
+ *addr = r.start;
+
+ return ret;
+}
+
+static int intel_freeze_br_req_ack(fdt_addr_t addr, u32 req_ack)
+{
+ u32 status, illegal, ctrl;
+ int ret = -ETIMEDOUT;
+ unsigned long start = get_timer(0);
+
+ while (1) {
+ illegal = readl(addr + FREEZE_CSR_ILLEGAL_REQ_OFFSET);
+ if (illegal) {
+ printf("illegal request 0x%08x detected in freeze
bridge\n", illegal);
+
+ writel(illegal, addr + FREEZE_CSR_ILLEGAL_REQ_OFFSET);
+
+ illegal = readl(addr + FREEZE_CSR_ILLEGAL_REQ_OFFSET);
+ if (illegal)
+ printf("illegal request 0x%08x detected in freeze
bridge are not cleared\n",
+ illegal);
+
+ ret = -EINVAL;
+ break;
+ }
+
+ status = readl(addr + FREEZE_CSR_STATUS_OFFSET);
+ status &= req_ack;
+ if (status) {
+ ctrl = readl(addr + FREEZE_CSR_CTRL_OFFSET);
+ printf("%s request %x acknowledged %x %x\n",
+ __func__, req_ack, status, ctrl);
+
+ ret = 0;
+ break;
+
Re: [RFC PATCH] cmd: fwu: Dump custom fields from mdata structure
On Mon, 17 Mar 2025 at 15:36, Michal Simek wrote:
>
> Hi Sughosh and Ilias,
>
> On 6/5/24 16:55, Michal Simek wrote:
> > The commit cb9ae40a16f0 ("tools: mkfwumdata: add logic to append vendor
> > data to the FWU metadata") added support for adding vendor data to mdata
> > structure but it is not visible anywhere that's why extend fwu command to
> > dump it.
> >
> > Signed-off-by: Michal Simek
> > ---
> >
> > I am using this for some time to check various configurations that's why it
> > can be useful for others too.
> > Sughosh: Maybe there is better way how to dump it.
> > ---
> > cmd/fwu_mdata.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
> > index 9c048d69a131..ff6435505167 100644
> > --- a/cmd/fwu_mdata.c
> > +++ b/cmd/fwu_mdata.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -45,6 +46,30 @@ static void print_mdata(struct fwu_data *data)
> > img_info->accepted == 0x1 ? "yes" : "no");
> > }
> > }
> > +
> > + if (data->version == 2) {
> > + struct fwu_mdata *mdata = data->fwu_mdata;
> > + struct fwu_fw_store_desc *desc;
> > + void *end;
> > + u32 diff;
> > +
> > + /*
> > + * fwu_mdata defines only header that's why taking it as array
> > + * which exactly point to image description location
> > + */
> > + desc = (struct fwu_fw_store_desc *)&mdata[1];
> > +
> > + /* Number of entries is taken from for loop - variable i */
> > + end = &desc->img_entry[i];
> > + debug("mdata %p, desc %p, end %p\n", mdata, desc, end);
> > +
> > + diff = data->metadata_size - ((void *)end - (void *)mdata);
> > + if (diff) {
> > + printf("Custom fields covered by CRC 0x%x\n", diff);
> > + print_hex_dump_bytes("CUSTOM ", DUMP_PREFIX_OFFSET,
> > + end, diff);
> > + }
> > + }
> > }
> >
> > int do_fwu_mdata_read(struct cmd_tbl *cmdtp, int flag,
>
> Can you please take a look at this patch?
Apologies, this got completely missed. I will spend some time this
week on this. Thanks.
-sughosh
Pull request efi-2025-04-rc5
Dear Tom, The following changes since commit 15d6518c942f0da13f9a7ceeadbd925c3317ec8d: ARM: dts: imx: Drop bogus regulator extras on DH i.MX6 DHCOM DRC02 (2025-03-13 15:22:48 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2025-04-rc5 for you to fetch changes up to 7f2fe3dda4ea5384eac4afadb8a4fe5d695e2ce1: scripts/Makefile.lib: efi: Preserve the .dynstr section as well (2025-03-17 09:35:52 +0100) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/25196 Pull request efi-2025-04-rc5 UEFI: * Export _start symbol from crt0_*_efi stubs * Move .dynamic out of .text in EFI * scripts/Makefile.lib: Preserve the .dynstr section as well Documentation: * net: miiphybb: Convert documentation to rst Marek Vasut (1): net: miiphybb: Convert documentation to rst Sam Edwards (3): arm: riscv: efi: Export _start symbol from crt0_*_efi stubs efi_loader: Move .dynamic out of .text in EFI scripts/Makefile.lib: efi: Preserve the .dynstr section as well arch/arm/lib/crt0_aarch64_efi.S | 1 + arch/arm/lib/crt0_arm_efi.S | 1 + arch/riscv/lib/crt0_riscv_efi.S | 1 + doc/README.bitbangMII | 39 - doc/develop/bitbangmii.rst | 75 + doc/develop/index.rst | 1 + lib/efi_loader/elf_efi.ldsi | 6 ++-- scripts/Makefile.lib| 4 +-- 8 files changed, 84 insertions(+), 44 deletions(-) delete mode 100644 doc/README.bitbangMII create mode 100644 doc/develop/bitbangmii.rst
[PATCH] pinctrl/qcom: fix kconfig option names
A copy-paste error is starting to get out of hand... Fix all these so they don't look like clock drivers in menuconfig. Signed-off-by: Caleb Connolly --- drivers/pinctrl/qcom/Kconfig | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig index 103ab05ed26e..f4a3942ee2f6 100644 --- a/drivers/pinctrl/qcom/Kconfig +++ b/drivers/pinctrl/qcom/Kconfig @@ -6,23 +6,23 @@ config PINCTRL_QCOM menu "Qualcomm pinctrl drivers" config PINCTRL_QCOM_APQ8016 - bool "Qualcomm APQ8016 GCC" + bool "Qualcomm APQ8016 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the MSM8916 / APQ8016 Snapdragon 410 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_APQ8096 - bool "Qualcomm APQ8096 GCC" + bool "Qualcomm APQ8096 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the MSM8996 / APQ8096 Snapdragon 820 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_IPQ4019 - bool "Qualcomm IPQ4019 GCC" + bool "Qualcomm IPQ4019 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the IPQ4019 SoC, as well as the associated GPIO driver. @@ -34,16 +34,16 @@ config PINCTRL_QCOM_IPQ9574 Say Y here to enable support for pinctrl on the IPQ9574 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_QCM2290 - bool "Qualcomm QCM2290 GCC" + bool "Qualcomm QCM2290 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the Snapdragon QCM2290 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_QCS404 - bool "Qualcomm QCS404 GCC" + bool "Qualcomm QCS404 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the Snapdragon QCS404 SoC, as well as the associated GPIO driver. @@ -55,51 +55,51 @@ config PINCTRL_QCOM_SC7280 Say Y here to enable support for pinctrl on the Snapdragon SC7280 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_SDM845 - bool "Qualcomm SDM845 GCC" + bool "Qualcomm SDM845 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the Snapdragon 845 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_SM6115 - bool "Qualcomm SM6115 GCC" + bool "Qualcomm SM6115 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the Snapdragon SM6115 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_SM8150 - bool "Qualcomm SM8150 GCC" + bool "Qualcomm SM8150 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the Snapdragon SM8150 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_SM8250 - bool "Qualcomm SM8250 GCC" + bool "Qualcomm SM8250 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the Snapdragon SM8250 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_SM8550 - bool "Qualcomm SM8550 GCC" + bool "Qualcomm SM8550 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the Snapdragon SM8550 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_SM8650 - bool "Qualcomm SM8650 GCC" + bool "Qualcomm SM8650 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the Snapdragon SM8650 SoC, as well as the associated GPIO driver. config PINCTRL_QCOM_X1E80100 - bool "Qualcomm X1E80100 GCC" + bool "Qualcomm X1E80100 Pinctrl" select PINCTRL_QCOM help Say Y here to enable support for pinctrl on the Snapdragon X1E80100 SoC, as well as the associated GPIO driver. -- 2.48.1
Re: [PATCH 00/10] clk: imx: Use Clock frameworkt to register UART clocks
On Sun, Mar 16, 2025 at 7:18 PM Adam Ford wrote: > The doc you referred me to states: Currently, we support running > GitLab CI pipelines only for custodians, due to the resources the > project has available Correct, so you should use the Github method. > I tried pushing my branch to Github, but I don't have permission. I > tried pushing it to my own github account, but it doesn't appear the > CI/CD stuff work. I looked at the log provided from the pipeline, and You should clone U-Boot into your local Github repo. Push your series into your repo and then create a pull request at: https://github.com/u-boot/u-boot/pulls Not sure about the problem you got. > I have been able to successfully build for that machine along with a > couple others that I have manually tested. Are you OK if I submit, or > is there something you want me to try before I do it? I have a second Feel free to post your updated series and I'll get it to run through CI.
Re: [PATCH] mach-snapdragon: handle platforms without PSCI support
On Mon, 27 Jan 2025 14:48:55 +, Sam Day wrote: > Most MSM8916 devices shipped without PSCI support. The history is quite > nuanced (a good overview can be found in [1]), but the end result is > that the upstream DTs for this SoC pretend that PSCI exists, and it's > expected that the bootloader handles the case where it doesn't. This is > codified by the de-facto bootloader for MSM8916 devices, lk2nd [2]. > > So we handle it here by deleting the /psci node if we detect the absence > of PSCI. We need to do this early to ensure sysreset works correctly, > since the PSCI firmware driver is PRE_RELOC and binds the PSCI sysreset > driver. > > [...] Applied, thanks! [1/1] mach-snapdragon: handle platforms without PSCI support https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/773a46b18b09 Best regards, -- Caleb Connolly
Re: [PATCH 2/3] misc: introduce Qcom GENI wrapper
On 3/17/25 14:12, Neil Armstrong wrote:
On 14/03/2025 17:09, Caleb Connolly wrote:
Qualcomm peripherals like UART, SPI, I2C, etc are all exposed under a
common GENI Serial Engine wrapper device. Replace the stub driver we use
for this currently with a full-on misc device and implement support for
loading peripheral firmware.
Each of the peripherals has it's own protocol-specific firmware, this is
stored on the internal storage of the device with a well-known partition
type GUID.
To support this, GENI will bind peripherals in two stages. First the
ones that already have firmware loaded (such as the serial port) are
bound in the typical way. But devices that require firmware loading are
deferred until EVT_LAST_STAGE_INIT. At this point we can be sure that
the storage device is available, so we load the firmware and then bind
and probe the remaining children.
Child devices are expected to determine if firmware loading is necessary
and call qcom_geni_load_firmware().
Since Linux currently doesn't support loading firmware (and firmware may
not be available), we probe all GENI peripherals to ensure that they
always load firmwaree if necessary.
-/\ firmwares
Hmm binding all QUP serial engines seems quite brutal, and this is really
only needed when fws are not loaded by previous bootloader.
In the best-case where no firmware loading is needed this should behave
almost the same as before, except for reading the GENI_FW_REVISION_RO
register for each (enabled) SE, so I don't think it's too bad.
I do wonder if there's a case where reading GENI_FW_REVISION_RO would
fail due to missing resources (like if GCC_QUPV3_WRAP_0_M_AHB_CLK is
disabled). But testing with the AHB clocks off doesn't seem to cause any
issues, so I guess it's fine??
Apart this, the design looks good :-)
Signed-off-by: Caleb Connolly
---
arch/arm/Kconfig | 1 +
drivers/misc/Kconfig | 9 +
drivers/misc/Makefile | 1 +
drivers/misc/qcom_geni.c | 576 +
++
drivers/serial/serial_msm_geni.c | 13 -
include/soc/qcom/geni-se.h | 36 +++
include/soc/qcom/qup-fw-load.h | 178
7 files changed, 801 insertions(+), 13 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index
cf08fe63f1e7dc73480b2ba0b707a7e891073d53..6149f284596641689407e076af5ad020176bd7dc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1116,8 +1116,9 @@ config ARCH_SNAPDRAGON
select BOARD_LATE_INIT
select OF_BOARD
select SAVE_PREV_BL_FDT_ADDR
select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK
+ select QCOM_GENI
imply OF_UPSTREAM
imply CMD_DM
config ARCH_SOCFPGA
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index
da84b35e8043bcef71ce78e03d1da2c445bf3af5..415832c73e2cb5a85ae8378977d597e5aedb5fb8 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -82,8 +82,17 @@ config GATEWORKS_SC
Enable access for the Gateworks System Controller used on
Gateworks
boards to provide a boot watchdog, power control, temperature
monitor,
voltage ADCs, and EEPROM.
+config QCOM_GENI
+ bool "Qualcomm Generic Interface (GENI) driver"
+ depends on MISC
+ select PARTITION_TYPE_GUID
+ help
+ Enable support for Qualcomm GENI and it's peripherals. GENI is
responseible
-/\
responsible
+ for providing a common interface for various peripherals like
UART, I2C, SPI,
+ etc.
+
config ROCKCHIP_EFUSE
bool "Rockchip e-fuse support"
depends on MISC
help
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index
dac805e4cdd48a8127f37d68d9fb5ba0bd17ab15..6866edbd8119268c0cc03abdc8529bd191f1c2d8 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -67,8 +67,9 @@ obj-$(CONFIG_QFW_PIO) += qfw_pio.o
obj-$(CONFIG_QFW_MMIO) += qfw_mmio.o
obj-$(CONFIG_QFW_SMBIOS) += qfw_smbios.o
obj-$(CONFIG_SANDBOX) += qfw_sandbox.o
endif
+obj-$(CONFIG_QCOM_GENI) += qcom_geni.o
obj-$(CONFIG_$(PHASE_)ROCKCHIP_EFUSE) += rockchip-efuse.o
obj-$(CONFIG_$(PHASE_)ROCKCHIP_OTP) += rockchip-otp.o
obj-$(CONFIG_$(PHASE_)ROCKCHIP_IODOMAIN) += rockchip-io-domain.o
obj-$(CONFIG_SANDBOX) += syscon_sandbox.o misc_sandbox.o
diff --git a/drivers/misc/qcom_geni.c b/drivers/misc/qcom_geni.c
new file mode 100644
index
..2b652765aa310b5a21d4aa99b50842c2e17e5942
--- /dev/null
+++ b/drivers/misc/qcom_geni.c
@@ -0,0 +1,576 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights
reserved.
+ * Copyright (c) 2025, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct qup_se_rsc {
+ phys_addr
[PATCH 2/2] clk/qcom: sc7280: add missing UFS and MMC clocks
These are all usually enabled, hence we don't (yet) bother configuring
their RCG src clocks.
Add them to remove the errors about missing clocks when the UFS and MMC
drivers probe.
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-sc7280.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/qcom/clock-sc7280.c b/drivers/clk/qcom/clock-sc7280.c
index
8691f08109b39639d8a5defe75161049399bf682..9aff8a847ad1bd59b7ec7246f5719e4d7c32ec65
100644
--- a/drivers/clk/qcom/clock-sc7280.c
+++ b/drivers/clk/qcom/clock-sc7280.c
@@ -106,8 +106,19 @@ static const struct gate_clk sc7280_clks[] = {
GATE_CLK(GCC_AGGRE_NOC_PCIE_CENTER_SF_AXI_CLK, 0x52008, BIT(28)),
GATE_CLK(GCC_QUPV3_WRAP0_S0_CLK, 0x52008, BIT(10)),
GATE_CLK(GCC_QUPV3_WRAP0_S1_CLK, 0x52008, BIT(11)),
GATE_CLK(GCC_QUPV3_WRAP0_S3_CLK, 0x52008, BIT(13)),
+ GATE_CLK(GCC_UFS_PHY_AXI_CLK, 0x77010, BIT(0)),
+ GATE_CLK(GCC_AGGRE_UFS_PHY_AXI_CLK, 0x770cc, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_AHB_CLK, 0x77018, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_UNIPRO_CORE_CLK, 0x7705c, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_PHY_AUX_CLK, 0x7709c, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_TX_SYMBOL_0_CLK, 0x7701c, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_RX_SYMBOL_0_CLK, 0x77020, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_RX_SYMBOL_1_CLK, 0x770b8, BIT(0)),
+ GATE_CLK(GCC_UFS_1_CLKREF_EN, 0x8c000, BIT(0)),
+ GATE_CLK(GCC_SDCC2_AHB_CLK, 0x14008, BIT(0)),
+ GATE_CLK(GCC_SDCC2_APPS_CLK, 0x14004, BIT(0)),
};
static int sc7280_enable(struct clk *clk)
{
--
2.48.1
[PATCH 1/2] clk/stub: add sc7280-rpmh clock
Stub the RPMh clock controller on SC7280
Signed-off-by: Caleb Connolly
---
drivers/clk/clk-stub.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk-stub.c b/drivers/clk/clk-stub.c
index
5fbbb07b7f7b93e619baf596064c4b3a3bfeecc0..343fa5cd3fe1704c6bb15a8c9852b9b4e4990351
100644
--- a/drivers/clk/clk-stub.c
+++ b/drivers/clk/clk-stub.c
@@ -49,8 +49,9 @@ static struct clk_ops stub_clk_ops = {
};
static const struct udevice_id stub_clk_ids[] = {
{ .compatible = "qcom,rpmcc" },
+ { .compatible = "qcom,sc7280-rpmh-clk" },
{ .compatible = "qcom,sm8150-rpmh-clk" },
{ .compatible = "qcom,sm8250-rpmh-clk" },
{ .compatible = "qcom,sm8550-rpmh-clk" },
{ .compatible = "qcom,sm8650-rpmh-clk" },
--
2.48.1
[PATCH 0/2] clk/qcom: fix UFS and MMC clock enable errors
We're missing a few clocks that the MMC and UFS drivers try to enable on SC7280. These aren't fatal (the clocks are actually already enabled by the previous bootloader stage). But it's good practise to enable them anyway. This doesn't handle programming the RCGs (the parent clocks) since we expect them to be enabled. This depends on https://lore.kernel.org/u-boot/20250314-sc7280-more-clocks-v1-0-ead54487c...@linaro.org --- Caleb Connolly (2): clk/stub: add sc7280-rpmh clock clk/qcom: sc7280: add missing UFS and MMC clocks drivers/clk/clk-stub.c | 1 + drivers/clk/qcom/clock-sc7280.c | 11 +++ 2 files changed, 12 insertions(+) --- base-commit: 0e1fc465fea62ebae91f2f56cb823e8b37ee1077 Caleb Connolly
Re: [PULL] u-boot-sh/master
On Mon, 17 Mar 2025 04:16:11 +0100, Marek Vasut wrote: > These are mainly DBSC5 DRAM controller specific fixes and updates for current > release. There is the long overdue BL31 start V4H board code as well, that > should be in the current release to make the V4H White Hawk board usable with > SPL, and a fallback U-Boot PSCI implementation enablement to make sure the > board always boots. And finally, there are two comment fixes. > > The following changes since commit 15d6518c942f0da13f9a7ceeadbd925c3317ec8d: > > [...] Merged into u-boot/master, thanks! -- Tom
Re: [PATCH v2 0/5] rng: msm: fixes for MSM8916
On Wed, 12 Feb 2025 07:01:20 +, Sam Day wrote: > The msm-rng driver is currently broken on MSM8916. > > The first issue is that the core clock isn't defined and thus not being > enabled before registers in the PRNG block are accessed. > > The second issue is that the enable method is only initializing the PRNG > registers if the block is *already* initialized. This would have likely > caused issues elsewhere once the driver was in more active use, but the > problems on MSM8916 are immediate: trying to modify the state of LFSR_CFG > causes SErrors, presumably because this register is protected by TZ. > > [...] Applied, thanks! [1/5] clk/qcom: apq8016: use BIT macro for clk en_vals https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/61781206cf19 [2/5] clk/qcom: apq8016: add PRNG_AHB_CLK https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/d146a8771f87 [3/5] rng: msm: don't enable PRNG if it's already enabled https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/6e933cd69ad9 [4/5] clk/qcom: apq8016: improve clk_enable logging https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/dc8754e8e408 [5/5] rng: msm: keep core clock disabled when PRNG not in use https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/2babb61428dc Best regards, -- Caleb Connolly
Re: [PATCH 1/2] clk/stub: add sc7280-rpmh clock
On 17/03/2025 17:15, Caleb Connolly wrote:
Stub the RPMh clock controller on SC7280
Signed-off-by: Caleb Connolly
---
drivers/clk/clk-stub.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk-stub.c b/drivers/clk/clk-stub.c
index
5fbbb07b7f7b93e619baf596064c4b3a3bfeecc0..343fa5cd3fe1704c6bb15a8c9852b9b4e4990351
100644
--- a/drivers/clk/clk-stub.c
+++ b/drivers/clk/clk-stub.c
@@ -49,8 +49,9 @@ static struct clk_ops stub_clk_ops = {
};
static const struct udevice_id stub_clk_ids[] = {
{ .compatible = "qcom,rpmcc" },
+ { .compatible = "qcom,sc7280-rpmh-clk" },
{ .compatible = "qcom,sm8150-rpmh-clk" },
{ .compatible = "qcom,sm8250-rpmh-clk" },
{ .compatible = "qcom,sm8550-rpmh-clk" },
{ .compatible = "qcom,sm8650-rpmh-clk" },
Reviewed-by: Neil Armstrong
[RFC] memtest
As far as I can tell no one makes any use of test/py/tests/test_memtest.py. At least there is no entry in u-boot-hooks that will enable its use. This is not surprising as the code does not actually work correctly. It will construct a command line for the 'mtest' command with some decimal parameters and some in hex. 'mtest' will interpret all parameters as hex and this makes the test fail for almost anything apart from the trivial cases where the affected parameters are 0. I looked into this for a while before I found the documentation that describes memory testing which states that 'mtest' is deprecated. So my question is should I submit a patch to fix the test even though the command itself is deprecated? Should I then enable its use in CI? Alternatively should I submit a patch to remove the test as it is not used and is broken? If the test should be removed a follow up question would be should the command itself be removed as well? This will be harder to do as it seems that some boards are using the config default values in their board code. Andrew
Re: Pull request efi-2025-04-rc5
On Mon, 17 Mar 2025 11:45:23 +0100, Heinrich Schuchardt wrote: > The following changes since commit 15d6518c942f0da13f9a7ceeadbd925c3317ec8d: > >ARM: dts: imx: Drop bogus regulator extras on DH i.MX6 DHCOM DRC02 > (2025-03-13 15:22:48 -0600) > > are available in the Git repository at: > >https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2025-04-rc5 > > [...] Merged into u-boot/master, thanks! -- Tom
Re: [PATCH] cmd: version: Get information about GCC and LD back
On Thu, 06 Mar 2025 11:12:30 +0100, Michal Simek wrote: > U-Boot version command is no longer showing information about GCC and LD. > The reason is that version.h has been removed that's why CC_VERSION_STRING > and LD_VERSION_STRING are not pass. > Values are generated to generated/version_autogenerated.h which is sourced > in version.h. > > > [...] Applied to u-boot/master, thanks! [1/1] cmd: version: Get information about GCC and LD back commit: ca3bea3fc415ce40dc58f1bea9327f6fa12928bb -- Tom
[PATCH] efi_loader: remove EFI_BOUNCE_BUFFER
The EFI subsystem defines its own bounce buffer for devices that can't transfer data > 4GB. U-Boot already has a generic BOUNCE_BUFFER which can be reused instead of defining another symbol. The only limitation for EFI is that we don't know how big the file a user chooses to transfer is and as a result we can't depend on allocating the memory from the malloc area, which can prove too small. So allocate an EFI buffer of the correct size and pass it to the DM, which already supports bounce buffering via bounce_buffer_start_extalign() Signed-off-by: Ilias Apalodimas --- arch/arm/Kconfig | 8 ++ configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028aqds_tfa_defconfig | 1 - configs/ls1028aqds_tfa_lpuart_defconfig | 1 - configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1028ardb_tfa_defconfig | 1 - configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1043ardb_tfa_defconfig | 1 - configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1046ardb_tfa_defconfig | 1 - configs/ls1088aqds_tfa_defconfig | 1 - configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls1088ardb_tfa_defconfig | 1 - configs/ls2088aqds_tfa_defconfig | 1 - configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/ls2088ardb_tfa_defconfig | 1 - configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160aqds_tfa_defconfig | 1 - configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2160ardb_tfa_defconfig | 1 - configs/lx2160ardb_tfa_stmm_defconfig | 1 - configs/lx2162aqds_tfa_SECURE_BOOT_defconfig | 1 - configs/lx2162aqds_tfa_defconfig | 1 - .../lx2162aqds_tfa_verified_boot_defconfig| 1 - configs/ten64_tfa_defconfig | 1 - include/efi_loader.h | 4 - lib/efi_loader/Kconfig| 7 -- lib/efi_loader/efi_disk.c | 78 +++ lib/efi_loader/efi_memory.c | 16 29 files changed, 36 insertions(+), 101 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index cf08fe63f1e7..bb946e69254c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1417,6 +1417,7 @@ config TARGET_LS2080A_EMU select ARCH_LS2080A select ARM64 select ARMV8_MULTIENTRY + select BOUNCE_BUFFER select FSL_DDR_SYNC_REFRESH select GPIO_EXTRA_HEADER help @@ -1432,6 +1433,7 @@ config TARGET_LS1088AQDS select ARMV8_MULTIENTRY select ARCH_SUPPORT_TFABOOT select BOARD_LATE_INIT + select BOUNCE_BUFFER select GPIO_EXTRA_HEADER select SUPPORT_SPL select FSL_DDR_INTERACTIVE if !SD_BOOT @@ -1448,6 +1450,7 @@ config TARGET_LS2080AQDS select ARMV8_MULTIENTRY select ARCH_SUPPORT_TFABOOT select BOARD_LATE_INIT + select BOUNCE_BUFFER select GPIO_EXTRA_HEADER select SUPPORT_SPL imply SCSI @@ -1467,6 +1470,7 @@ config TARGET_LS2080ARDB select ARMV8_MULTIENTRY select ARCH_SUPPORT_TFABOOT select BOARD_LATE_INIT + select BOUNCE_BUFFER select SUPPORT_SPL select FSL_DDR_BIST select FSL_DDR_INTERACTIVE if !SPL @@ -1485,6 +1489,7 @@ config TARGET_LS2081ARDB select ARM64 select ARMV8_MULTIENTRY select BOARD_LATE_INIT + select BOUNCE_BUFFER select GPIO_EXTRA_HEADER select SUPPORT_SPL help @@ -1500,6 +1505,7 @@ config TARGET_LX2160ARDB select ARMV8_MULTIENTRY select ARCH_SUPPORT_TFABOOT select BOARD_LATE_INIT + select BOUNCE_BUFFER select GPIO_EXTRA_HEADER help Support for NXP LX2160ARDB platform. @@ -1514,6 +1520,7 @@ config TARGET_LX2160AQDS select ARMV8_MULTIENTRY select ARCH_SUPPORT_TFABOOT select BOARD_LATE_INIT + select BOUNCE_BUFFER select GPIO_EXTRA_HEADER help Support for NXP LX2160AQDS platform. @@ -1529,6 +1536,7 @@ config TARGET_LX2162AQDS select ARMV8_MULTIENTRY select ARCH_SUPPORT_TFABOOT select BOARD_LATE_INIT + select BOUNCE_BUFFER select GPIO_EXTRA_HEADER help Support for NXP LX2162AQDS platform. diff --git a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig index 97eb7d9dca4c..e3b1018f6f8e 100644 --- a/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1028aqds_tfa_SECURE_BOOT_defconfig @@ -23,7 +23,6 @@ CONFIG_SYS_MEMTEST_START=0x8000 CONFIG_SYS_MEMTEST_END=0x9fff CONFIG_REMAKE_ELF=y CONFIG_MP=y -CONFIG_EFI_LOADER_BOUNCE_BUFFER=y CONFIG_FIT_VERBOSE=y CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTDELAY=10 diff --git a/configs/ls1028aqds_tfa_defconfig b/configs/ls1028aqds_tfa_defconfig i
Re: [PATCH 0/6] MSM8916: Bring secondary cores online with spin-table
On Mon, Mar 17, 2025 at 01:13:22PM +, Caleb Connolly wrote: > Hi Sam, > > Can you re-send this without all the prerequisite-patch-id tags? b4 is > desperately trying to apply ~140 patches from some old next branch to my > tree and tbh im not sure how to make it stop. You can use --merge-base HEAD to override that I think. If not I think it's worth asking to...@kernel.org because that sounds like a bug to me. -- Tom signature.asc Description: PGP signature
Re: [PATCH] cmd: version: Get information about GCC and LD back
On Mon, Mar 17, 2025 at 10:48:57AM +0100, Michal Simek wrote:
> Hi Tom,
>
> On 3/10/25 14:56, Tom Rini wrote:
> > On Mon, Mar 10, 2025 at 08:49:32AM +0100, Michal Simek wrote:
> > >
> > >
> > > On 3/6/25 15:12, Michal Simek wrote:
> > > >
> > > >
> > > > On 3/6/25 15:02, Tom Rini wrote:
> > > > > On Thu, Mar 06, 2025 at 11:12:30AM +0100, Michal Simek wrote:
> > > > > > U-Boot version command is no longer showing information about GCC
> > > > > > and LD.
> > > > > > The reason is that version.h has been removed that's why
> > > > > > CC_VERSION_STRING
> > > > > > and LD_VERSION_STRING are not pass.
> > > > > > Values are generated to generated/version_autogenerated.h which is
> > > > > > sourced
> > > > > > in version.h.
> > > > > >
> > > > > > Fixes: 54ecce2cbf90 ("version: Separate our version string from
> > > > > > the version command")
> > > > > > Signed-off-by: Michal Simek
> > > > > > ---
> > > > > >
> > > > > > Tom: Not sure if this has been done on purpose or not but this
> > > > > > issue has
> > > > > > been reported by our regression team.
> > > > >
> > > > > It wasn't on purpose, no. Did you put this through CI / confirm
> > > > > sandbox_nocmdline still builds?
> > > >
> > > > Nope I did not.
> > >
> > > CI is not reporting any issue.
> > >
> > > https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/25029
>
> Are you going to take this to 2025.04?
> Or to next?
>
> I don't mind. I can also take it via my tree just let me know.
Ah good question. I suppose I should pick this up for master.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 2/3] misc: introduce Qcom GENI wrapper
On 17/03/2025 15:33, Caleb Connolly wrote: On 3/17/25 14:12, Neil Armstrong wrote: On 14/03/2025 17:09, Caleb Connolly wrote: Qualcomm peripherals like UART, SPI, I2C, etc are all exposed under a common GENI Serial Engine wrapper device. Replace the stub driver we use for this currently with a full-on misc device and implement support for loading peripheral firmware. Each of the peripherals has it's own protocol-specific firmware, this is stored on the internal storage of the device with a well-known partition type GUID. To support this, GENI will bind peripherals in two stages. First the ones that already have firmware loaded (such as the serial port) are bound in the typical way. But devices that require firmware loading are deferred until EVT_LAST_STAGE_INIT. At this point we can be sure that the storage device is available, so we load the firmware and then bind and probe the remaining children. Child devices are expected to determine if firmware loading is necessary and call qcom_geni_load_firmware(). Since Linux currently doesn't support loading firmware (and firmware may not be available), we probe all GENI peripherals to ensure that they always load firmwaree if necessary. -/\ firmwares Hmm binding all QUP serial engines seems quite brutal, and this is really only needed when fws are not loaded by previous bootloader. In the best-case where no firmware loading is needed this should behave almost the same as before, except for reading the GENI_FW_REVISION_RO register for each (enabled) SE, so I don't think it's too bad. I do wonder if there's a case where reading GENI_FW_REVISION_RO would fail due to missing resources (like if GCC_QUPV3_WRAP_0_M_AHB_CLK is disabled). But testing with the AHB clocks off doesn't seem to cause any issues, so I guess it's fine?? Yeah it may be a fixed register, but let me test it on my sm8550 & sm8650 boards first to be sure it doesn't break. Neil Apart this, the design looks good :-) Signed-off-by: Caleb Connolly --- arch/arm/Kconfig | 1 + drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/qcom_geni.c | 576 + ++ drivers/serial/serial_msm_geni.c | 13 - include/soc/qcom/geni-se.h | 36 +++ include/soc/qcom/qup-fw-load.h | 178 7 files changed, 801 insertions(+), 13 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index cf08fe63f1e7dc73480b2ba0b707a7e891073d53..6149f284596641689407e076af5ad020176bd7dc 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1116,8 +1116,9 @@ config ARCH_SNAPDRAGON select BOARD_LATE_INIT select OF_BOARD select SAVE_PREV_BL_FDT_ADDR select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK + select QCOM_GENI imply OF_UPSTREAM imply CMD_DM config ARCH_SOCFPGA diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index da84b35e8043bcef71ce78e03d1da2c445bf3af5..415832c73e2cb5a85ae8378977d597e5aedb5fb8 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -82,8 +82,17 @@ config GATEWORKS_SC Enable access for the Gateworks System Controller used on Gateworks boards to provide a boot watchdog, power control, temperature monitor, voltage ADCs, and EEPROM. +config QCOM_GENI + bool "Qualcomm Generic Interface (GENI) driver" + depends on MISC + select PARTITION_TYPE_GUID + help + Enable support for Qualcomm GENI and it's peripherals. GENI is responseible -/\ responsible + for providing a common interface for various peripherals like UART, I2C, SPI, + etc. + config ROCKCHIP_EFUSE bool "Rockchip e-fuse support" depends on MISC help diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index dac805e4cdd48a8127f37d68d9fb5ba0bd17ab15..6866edbd8119268c0cc03abdc8529bd191f1c2d8 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -67,8 +67,9 @@ obj-$(CONFIG_QFW_PIO) += qfw_pio.o obj-$(CONFIG_QFW_MMIO) += qfw_mmio.o obj-$(CONFIG_QFW_SMBIOS) += qfw_smbios.o obj-$(CONFIG_SANDBOX) += qfw_sandbox.o endif +obj-$(CONFIG_QCOM_GENI) += qcom_geni.o obj-$(CONFIG_$(PHASE_)ROCKCHIP_EFUSE) += rockchip-efuse.o obj-$(CONFIG_$(PHASE_)ROCKCHIP_OTP) += rockchip-otp.o obj-$(CONFIG_$(PHASE_)ROCKCHIP_IODOMAIN) += rockchip-io-domain.o obj-$(CONFIG_SANDBOX) += syscon_sandbox.o misc_sandbox.o diff --git a/drivers/misc/qcom_geni.c b/drivers/misc/qcom_geni.c new file mode 100644 index ..2b652765aa310b5a21d4aa99b50842c2e17e5942 --- /dev/null +++ b/drivers/misc/qcom_geni.c @@ -0,0 +1,576 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved. + * Copyright (c) 2025, Linaro Ltd. + */ + +#include +#include +#include +#include +#includ
[PULL] Please pull qcom-next-20250317
Hi Tom, A new platform and a nice handful of improvements for Qualcomm so far this cycle: * msm8916 gets proper sysreset and spin-table support * the first new IPQ platform is added - the IPQ9574. The IPQ series are used in routers. The flashing process is also documented * mach-snapdragon gains the ability to boot with an internal FDT and still parse memory from an externally provided one * SC7280 gets a pinctrl driver and various clock driver improvements. * Qualcom clock drivers will now actually return an error when attempting to enable a clock which isn't described. * Qualcomm pinctrl drivers will now return an error when attempting to configure an invalid function mux Kind regards, Caleb The following changes since commit 0e1fc465fea62ebae91f2f56cb823e8b37ee1077: Merge tag 'dm-pull-15mar25' of git://git.denx.de/u-boot-dm into next (2025-03-15 08:19:31 -0600) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-snapdragon.git tags/qcom-next-20250317 for you to fetch changes up to 69aab567407efe67b8b2a10a3843656101b402ca: pinctrl/qcom: fix kconfig option names (2025-03-17 15:12:26 +) Qualcomm patches for U-Boot next 2025-03-17 Caleb Connolly (6): pinctrl: qcom: add sc7280 pinctrl driver qcom_defconfig: enable PINCTRL_QCOM_SC7280 clk/qcom: bubble up qcom_gate_clk_en() errors clk/qcom: sc7280: add some debug data clk/qcom: sc7280: add GENI, PCIe, and more USB clocks pinctrl/qcom: fix kconfig option names Sam Day (10): clk/qcom: apq8016: use BIT macro for clk en_vals clk/qcom: apq8016: add PRNG_AHB_CLK rng: msm: don't enable PRNG if it's already enabled clk/qcom: apq8016: improve clk_enable logging rng: msm: keep core clock disabled when PRNG not in use mach-snapdragon: support parsing memory info from external FDT mach-snapdragon: handle platforms without PSCI support mach-snapdragon: use PSCI sysreset driver sysreset: qcom-pshold: remove ARCH_IPQ40XX dependency qcom_defconfig: enable SYSRESET_QCOM_PSHOLD Varadarajan Narayanan (7): doc: board/qualcomm: document RDP building/flashing dts: ipq9574-rdp433-u-boot: add override dtsi clk/qcom: add initial clock driver for ipq9574 pinctrl: qcom: Handle get_function_mux failure pinctrl: qcom: Add ipq9574 pinctrl driver mmc: msm_sdhci: Reset clocks before reconfiguration configs: add qcom_ipq9574_mmc_defconfig arch/arm/dts/ipq9574-rdp433-u-boot.dtsi | 25 arch/arm/mach-snapdragon/board.c| 123 - configs/qcom_defconfig | 4 + configs/qcom_ipq9574_mmc_defconfig | 83 doc/board/qualcomm/index.rst| 1 + doc/board/qualcomm/rdp.rst | 55 drivers/clk/qcom/Kconfig| 8 ++ drivers/clk/qcom/Makefile | 1 + drivers/clk/qcom/clock-apq8016.c| 12 +- drivers/clk/qcom/clock-ipq9574.c| 94 + drivers/clk/qcom/clock-qcm2290.c| 4 +- drivers/clk/qcom/clock-qcom.h | 13 +- drivers/clk/qcom/clock-sa8775p.c| 4 +- drivers/clk/qcom/clock-sc7280.c | 124 -- drivers/clk/qcom/clock-sdm845.c | 4 +- drivers/clk/qcom/clock-sm6115.c | 4 +- drivers/clk/qcom/clock-sm8150.c | 4 +- drivers/clk/qcom/clock-sm8250.c | 4 +- drivers/clk/qcom/clock-sm8550.c | 4 +- drivers/clk/qcom/clock-sm8650.c | 4 +- drivers/clk/qcom/clock-x1e80100.c | 4 +- drivers/mmc/msm_sdhci.c | 10 ++ drivers/pinctrl/qcom/Kconfig| 38 -- drivers/pinctrl/qcom/Makefile | 2 + drivers/pinctrl/qcom/pinctrl-apq8016.c | 4 +- drivers/pinctrl/qcom/pinctrl-apq8096.c | 4 +- drivers/pinctrl/qcom/pinctrl-ipq4019.c | 3 +- drivers/pinctrl/qcom/pinctrl-ipq9574.c | 226 drivers/pinctrl/qcom/pinctrl-qcm2290.c | 2 +- drivers/pinctrl/qcom/pinctrl-qcom.c | 5 +- drivers/pinctrl/qcom/pinctrl-qcom.h | 3 +- drivers/pinctrl/qcom/pinctrl-qcs404.c | 4 +- drivers/pinctrl/qcom/pinctrl-sc7280.c | 106 +++ drivers/pinctrl/qcom/pinctrl-sdm845.c | 4 +- drivers/pinctrl/qcom/pinctrl-sm6115.c | 2 +- drivers/pinctrl/qcom/pinctrl-sm8150.c | 4 +- drivers/pinctrl/qcom/pinctrl-sm8250.c | 2 +- drivers/pinctrl/qcom/pinctrl-sm8550.c | 4 +- drivers/pinctrl/qcom/pinctrl-sm8650.c | 4 +- drivers/pinctrl/qcom/pinctrl-x1e80100.c | 4 +- drivers/rng/msm_rng.c | 13 +- drivers/sysreset/Kconfig| 1 - 42 files changed, 905 insertions(+), 119 deletions(-) create mode 100644 arch/arm/dts/ipq9574-rdp433-u-boot.dtsi c
Re: [PATCH v1] common/memsize.c: Fix get_ram_size() original data restore
Hi Tom,
On Fri, Mar 14, 2025 at 10:34:22AM -0600, Tom Rini wrote:
> On Fri, Mar 14, 2025 at 11:06:49AM +0100, Stefan Eichenberger wrote:
>
> > From: Stefan Eichenberger
> >
> > The get_ram_size() function fails to restore the original RAM data when
> > the data cache is enabled. This issue was observed on an AM625 R5 SPL
> > with 512MB of RAM and is a regression that became visible with
> > commit bc07851897bd ("board: ti: Pull redundant DDR functions to a common
> > location and Fixup DDR size when ECC is enabled").
> >
> > Observed boot failure messages:
> > Warning: Did not detect image signing certificate. Skipping
> > authentication to prevent boot failure. This will fail on Security
> > Enforcing(HS-SE) devices
> > Authentication passed
> > Starting ATF on ARM64 core...
> >
> > The system then hangs. This indicates that without a data cache flush,
> > data in the cache is not coherent with RAM, preventing the system from
> > booting. This was verified by printing the content of this address when
> > the issue occurs.
> >
> > Add a data cache flush after each restore operation to resolve this
> > issue.
> >
> > Fixes: bc07851897bd ("board: ti: Pull redundant DDR functions to a common
> > location and Fixup DDR size when ECC is enabled")
> > Fixes: 1c64b98c1ec4 ("common/memsize.c: Fix get_ram_size() when cache is
> > enabled")
> > Signed-off-by: Stefan Eichenberger
> > ---
> > common/memsize.c | 8
> > 1 file changed, 8 insertions(+)
>
> Ugh. Is there not a chance the problem being that we need a
> dcache_flush_all() in the K3 ddr code somewhere? I'm just trying to see
> how we got here and I notice now that yes, this does look like it
> finishes what 1c64b98c1ec4 started but in hindsight was that showing
> something else needing to be fixed?
I am also not entirely satisfied with the current fix. I rechecked with
U-Boot v2024.10, where we did not observe the issue. This difference is
due to the cache always being disabled when get_ram_size() is called.
This explains why it was working before commit bc07851897bd ("board: ti:
Pull redundant DDR functions to a common location and Fixup DDR size
when ECC is enabled").
I think my previous fix introduced this second call to get_ram_size()
when adding:
void spl_perform_fixups(struct spl_image_info *spl_image)
{
fixup_memory_node(spl_image);
}
Doing some more tests now shows that probably only adding the following
would have been sufficient:
gd->bd->bi_dram[0].size = gd->ram_size;
If confirmed through further testing, this patch may be unnecessary.
Regards,
Stefan
Re: [RFC PATCH] Gitlab CI: Clean up more
On Mon, Mar 17, 2025 at 09:12:14PM +0200, Ilias Apalodimas wrote:
> Hi Tom,
>
> On Sat, 15 Mar 2025 at 16:17, Tom Rini wrote:
> >
> > A problem we hit on our CI runners themselves, from time to time, is a
> > lack of disk space on the host. This is because Gitlab has no automation
> > itself around the removal of items it put in a "cache". While part of
> > the way to alleviate this is for the runners to run various docker
> > cleanup commands on their own, periodically, another thing to
> > potentially help would be to further clean-up in the job itself.
> >
> > This patch adds "git clean -dfx" in jobs that leave some files in the
> > source tree (these files may lead to a cache miss, more investigation
> > would be required) and deleting the board build directory. This part is
> > both a minimal size reclamation and minimal time increase (a few
> > seconds).
> >
> > The other part this adds is making the world build use "/tmp/world" as
> > the output directory not "/tmp" so that we can then delete "/tmp/world"
> > afterwards. This adds between 1m30 and 3m to the build.
> >
> > Signed-off-by: Tom Rini
> > ---
> > Cc: Simon Glass
> > Cc: Ilias Apalodimas
> > ---
> > .gitlab-ci.yml | 22 ++
> > 1 file changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index 2dbe6325f334..ce7a391bbd00 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -63,8 +63,9 @@ stages:
> > -r tools/buildman/requirements.txt -r
> > tools/u_boot_pylib/requirements.txt
> >
> >after_script:
> > +- git clean -dfx
> > - cp -v /tmp/${TEST_PY_BD}/*.{html,css,xml} .
> > -- rm -rf /tmp/uboot-test-hooks /tmp/venv
> > +- rm -rf /tmp/uboot-test-hooks /tmp/venv /tmp/${TEST_PY_BD}
>
> This deletes less?
No? Note that we're adding the "git clean -dfx" and that must be before
we copy the files grabbed as artifacts in.
> >script:
> > # If we've been asked to use clang only do one configuration.
> > - export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD}
> > @@ -130,11 +131,13 @@ build all platforms in a single job:
> > -r tools/buildman/requirements.txt
> > - ret=0;
> >git config --global --add safe.directory "${CI_PROJECT_DIR}";
> > - ./tools/buildman/buildman -o /tmp -PEWM -x xtensa || ret=$?;
> > + ./tools/buildman/buildman -o /tmp/world -PEWM -x xtensa || ret=$?;
>
> Since you are making the tmp-> /tmp/world it might make more sense to
> define a variable for the output directory.
OK.
> >if [[ $ret -ne 0 ]]; then
> > -./tools/buildman/buildman -o /tmp -seP;
> > +./tools/buildman/buildman -o /tmp/world -seP;
> > exit $ret;
> >fi;
> [...]
>
> Other than that I think it looks sane. The added 1 - 3 min build time
> is small enough to ignore
I'm ambivalent about it, and since Simon is most concerned with overall
pipeline time I'd like his input here too.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 0/6] MSM8916: Bring secondary cores online with spin-table
On Mon, Mar 17, 2025 at 01:13:22PM +, Caleb Connolly wrote: > Hi Sam, > > Can you re-send this without all the prerequisite-patch-id tags? b4 is > desperately trying to apply ~140 patches from some old next branch to my > tree and tbh im not sure how to make it stop. FYI, this only gets triggered on "shazam" so if you want to avoid this situation, you can just use "b4 am" and then follow by "git am" on top of the tree you like. -K
Re: [PATCH] efi_loader: remove EFI_BOUNCE_BUFFER
Hi Mark,
Thanks for taking a look
On Mon, 17 Mar 2025 at 18:18, Mark Kettenis wrote:
>
> > From: Ilias Apalodimas
> > Date: Mon, 17 Mar 2025 15:38:36 +0200
> >
> > The EFI subsystem defines its own bounce buffer for devices that
> > can't transfer data > 4GB. U-Boot already has a generic BOUNCE_BUFFER
> > which can be reused instead of defining another symbol.
> > The only limitation for EFI is that we don't know how big the file a user
> > chooses to transfer is and as a result we can't depend on allocating the
> > memory from the malloc area, which can prove too small.
> >
> > So allocate an EFI buffer of the correct size and pass it to the DM,
> > which already supports bounce buffering via bounce_buffer_start_extalign()
>
> The existing bounce buffer code servers a completely different purpose
> though. It exists to make sure that hardware with cache-incoherent
> DMA can safely do the required cache flushes.
>
> This means that:
>
> * SoCs with cache-coherent DMA don't necessarily set BOUNCE_BUFFER.
> Looks like you added that option to all the SoCs where you remove
> EFI_LOADER_BOUNCE_BUFFER.
Yes, and that has a side effect I should have probably added to the
commit message. Using the existing bounce buffer will flush caches
even if it's pointless.
>
> * SoCs that (now) set BOUNCE_BUFFER may double bounce if the buffers
> aren't properly aligned. I suppose that this won't happen since
> efi_disk_add_dev() sets medio.io_align to the device block size
> which is typically larger than the cache line size.
I think it won't happen indeed but for a different reason. The EFI
memory we allocate and pass to bounce_buffer_start_extalign() is
page-aligned.
The DM subsystem will call that function with either
blk_buffer_aligned() which always returns 1 or whatever the device has
defined. The strictest one I found was the virtio one which requires
page alignment.
Allocating memory from EFI is needed, simply because the current
bounce buffer API will use the malloc area, which might not be enough.
Do you think the extra cache flush is a no-go and we should leave the
code as-is?
>
> Still the commit message is somewhat misleading; this code doesn't
> really make us use the DM bounce buffering code.
>
> I also spotted a few bugs in the implementation. See below.
[...]
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -105,6 +105,8 @@ static efi_status_t efi_disk_rw_blocks(struct
> > efi_block_io *this,
> > int blksz;
> > int blocks;
> > unsigned long n;
> > + u64 bb = 0x;
> > + void *bb_ptr = buffer;
> >
> > diskobj = container_of(this, struct efi_disk_obj, ops);
> > blksz = diskobj->media.block_size;
> > @@ -113,27 +115,35 @@ static efi_status_t efi_disk_rw_blocks(struct
> > efi_block_io *this,
> > EFI_PRINT("blocks=%x lba=%llx blksz=%x dir=%d\n",
> > blocks, lba, blksz, direction);
> >
> > + if (IS_ENABLED(CONFIG_BOUNCE_BUFFER) && (uintptr_t)buffer >= SZ_4G +
> > buffer_size - 1) {
>
> Shouldn't that check be
>
> if (IS_ENABLED(CONFIG_BOUNCE_BUFFER) && (uintptr_t)buffer +
> buffer_size - 1 >= SZ_4G) {
>
> ?
Yes...
I originally had (uintptr_t)buffer > SZ_4G - buffer_size - 1 and avoid
potential overflows, but then I started to think what happens if
buffer_size is 4GB and completely messed this up ...
I think it's (uintptr_t)buffer + buffer_size + 1 >= SZ_4G though,
because SZ_4G is 0x1. Anyway yes, you are right, I'll fix it
in v2, but using subtractions.
>
> > + if (efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
> > EFI_BOOT_SERVICES_DATA,
> > +buffer_size >> EFI_PAGE_SHIFT, &bb) !=
> > EFI_SUCCESS)
> > + return EFI_OUT_OF_RESOURCES;
> > +
> > + bb_ptr = (void *)(uintptr_t)bb;
> > + }
> > /* We only support full block access */
> > - if (buffer_size & (blksz - 1))
> > + if (buffer_size & (blksz - 1)) {
> > + if (buffer != bb_ptr)
> > + efi_free_pages(bb, buffer_size >> EFI_PAGE_SHIFT);
> > return EFI_BAD_BUFFER_SIZE;
> > + }
>
> Any reason why you don't check the buffer_size check before allocating
> the bounce buffer? That way you don't have to worry about freeing it
> here.
Nop, that code was already there and I didn't move it. I'll move it around.
>
> You're missing a memcpy() here in the case direction == EFI_DISK_WRITE.
ah thanks
>
> > if (CONFIG_IS_ENABLED(PARTITIONS) &&
> > device_get_uclass_id(diskobj->header.dev) == UCLASS_PARTITION) {
> > if (direction == EFI_DISK_READ)
[...]
> > + efi_free_pages(bb, buffer_size >> EFI_PAGE_SHIFT);
> > return EFI_DEVICE_ERROR;
> > + }
> > +
> > + if (buffer != bb_ptr) {
> > + memcpy(buffer, bb_ptr, buffer_size);
>
> This memcpy() is only necessary if direction == EFI_DISK_READ.
Ok
[...]
Thanks
/Ilias
RE: [resend v2 05/13] drivers: i3c: Enabled Kconfig and Makefile for DWI3C
> -Original Message- > From: Tom Rini > Sent: Saturday, 15 March 2025 12:53 am > To: Maniyam, Dinesh > Cc: u-boot@lists.denx.de; Marek ; Simon > ; Simon Glass ; Dario > Binacchi ; Ilias Apalodimas > ; Heinrich Schuchardt ; > Jerome Forissier ; Mattijs Korpershoek > ; Ibai Erkiaga ; > Michal Simek ; Dmitry Rokosov > ; Jonas Karlman ; Sebastian > Reichel ; Meng, Tingting > ; Chee, Tien Fong ; > Hea, Kok Kiang ; Ng, Boon Khai > ; Yuslaimi, Alif Zakuan > ; Zamri, Muhammad Hazim Izzat > ; Lim, Jit Loon > ; Tang, Sieu Mun > Subject: Re: [resend v2 05/13] drivers: i3c: Enabled Kconfig and Makefile for > DWI3C > > On Fri, Mar 14, 2025 at 12:08:54PM +0800, dinesh.mani...@altera.com wrote: > > > From: Dinesh Maniyam > > > > Enable the Kconfig and Makefile for the MIPI DWI3C driver. > > > > Signed-off-by: Dinesh Maniyam > > --- > > drivers/i3c/Kconfig | 3 +++ > > drivers/i3c/Makefile| 1 + > > drivers/i3c/master/Kconfig | 11 +++ > > drivers/i3c/master/Makefile | 3 +++ > > 4 files changed, 18 insertions(+) > > create mode 100755 drivers/i3c/master/Kconfig create mode 100755 > > drivers/i3c/master/Makefile > > > > diff --git a/drivers/i3c/Kconfig b/drivers/i3c/Kconfig index > > fa68612787b..8140b530bb5 100755 > > --- a/drivers/i3c/Kconfig > > +++ b/drivers/i3c/Kconfig > > @@ -14,3 +14,6 @@ menuconfig I3C > > If you want I3C support, you should say Y here and also to the > > specific driver for your bus adapter(s) below. > > > > +if I3C > > +source "drivers/i3c/master/Kconfig" > > +endif # I3C > > We should have empty lines around if / endif here. > > -- > Tom Noted. I will add the empty lines for if /endif here. Dinesh
RE: [resend v2 12/13] configs: sandbox_defconfig: Enable configs for sandbox i3c
> -Original Message- > From: Tom Rini > Sent: Saturday, 15 March 2025 12:54 am > To: Maniyam, Dinesh > Cc: u-boot@lists.denx.de; Marek ; Simon > ; Simon Glass ; Dario > Binacchi ; Ilias Apalodimas > ; Heinrich Schuchardt ; > Jerome Forissier ; Mattijs Korpershoek > ; Ibai Erkiaga ; > Michal Simek ; Dmitry Rokosov > ; Jonas Karlman ; Sebastian > Reichel ; Meng, Tingting > ; Chee, Tien Fong ; > Hea, Kok Kiang ; Ng, Boon Khai > ; Yuslaimi, Alif Zakuan > ; Zamri, Muhammad Hazim Izzat > ; Lim, Jit Loon > ; Tang, Sieu Mun > Subject: Re: [resend v2 12/13] configs: sandbox_defconfig: Enable configs for > sandbox i3c > > On Fri, Mar 14, 2025 at 12:09:01PM +0800, dinesh.mani...@altera.com wrote: > > > From: Dinesh Maniyam > > > > Enable configs for sandbox i3c. > > > > Signed-off-by: Dinesh Maniyam > > --- > > configs/sandbox_defconfig | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig > > index 861a1f4cd90..d3617da8792 100644 > > --- a/configs/sandbox_defconfig > > +++ b/configs/sandbox_defconfig > > @@ -364,3 +364,6 @@ CONFIG_TEST_FDTDEC=y CONFIG_UNIT_TEST=y > > CONFIG_UT_TIME=y CONFIG_UT_DM=y > > +CONFIG_I3C=y > > +CONFIG_I3C_SANDBOX=y > > +CONFIG_CMD_I3C=y > > In both config patches, you need to use "savedefconfig" when adding options, > not > just adding to the end of the file. > > -- > Tom Noted. I will take note of this and will rework the commit. Thanks. Dinesh
RE: [resend v2 04/13] drivers: Enabled Kconfig and Makefile for i3c support
> -Original Message- > From: Tom Rini > Sent: Saturday, 15 March 2025 12:53 am > To: Maniyam, Dinesh > Cc: u-boot@lists.denx.de; Marek ; Simon > ; Simon Glass ; Dario > Binacchi ; Ilias Apalodimas > ; Heinrich Schuchardt ; > Jerome Forissier ; Mattijs Korpershoek > ; Ibai Erkiaga ; > Michal Simek ; Dmitry Rokosov > ; Jonas Karlman ; Sebastian > Reichel ; Meng, Tingting > ; Chee, Tien Fong ; > Hea, Kok Kiang ; Ng, Boon Khai > ; Yuslaimi, Alif Zakuan > ; Zamri, Muhammad Hazim Izzat > ; Lim, Jit Loon > ; Tang, Sieu Mun > Subject: Re: [resend v2 04/13] drivers: Enabled Kconfig and Makefile for i3c > support > > On Fri, Mar 14, 2025 at 12:08:53PM +0800, dinesh.mani...@altera.com wrote: > > > From: Dinesh Maniyam > > > > Add new i3c driver to U-Boot drivers. > > > > Signed-off-by: Dinesh Maniyam > > --- > > drivers/Kconfig | 2 ++ > > drivers/Makefile | 1 + > > drivers/i3c/Kconfig | 16 drivers/i3c/Makefile | 3 > > +++ > > 4 files changed, 22 insertions(+) > > create mode 100755 drivers/i3c/Kconfig create mode 100755 > > drivers/i3c/Makefile > > In this patch you should update the top-level MAINTAINERS file and list I3C > and > list yourself there. > > -- > Tom Noted. I will rework to update the MAINTAINER file. Dinesh
Re: [PATCH v3 0/6] lmb: miscellaneous fixes and improvements
On Mon, 03 Mar 2025 19:02:25 +0530, Sughosh Ganu wrote: > The patch series contains some fixes and improvements in the lmb > code, along with addition of corresponding test cases for the changes > made. > > The lmb_reserve() function currently does not check if the requested > reservation would overlap with existing reserved regions. While some > scenarios are being handled, some corner cases still exist. These are > being handled by patch 1, along with adding test cases for these > scenarios. > > [...] Applied to u-boot/next, thanks! [1/6] lmb: check if a region can be reserved by lmb_reserve() commit: 56f186a68b35e8b45136fd44b69c554a0bb0ce35 [2/6] lmb: handle scenario of encompassing overlap commit: e0a7ea3725d8931a2c31f29ed665ec1f22e37172 [3/6] lmb: check for a region's coalescing with all existing regions commit: 6e4df5886d27cff043561c8087f373e26cfe9f34 [4/6] lmb: remove superfluous address overlap check from lmb_add_region_flags() commit: f5f0a0287134223c16ce64303df60c3708684e6a [5/6] lmb: use a common function to check if regions overlap or are adjacent commit: fa5b4f5a5f99d1f4ab995d07845d2bff50aaabb7 [6/6] lmb: optimise the lmb allocation functions commit: 2bf5811e22efffe37bf5dccb8d13529c51fc65dd -- Tom
RE: [PATCH] ARM: socfpga: Drop incorrect imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION*
Hi Tony, > -Original Message- > From: Tom Rini > Sent: Saturday, March 15, 2025 9:29 AM > To: u-boot@lists.denx.de > Cc: Chee, Tien Fong > Subject: [PATCH] ARM: socfpga: Drop incorrect imply > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION* > > The use of both "imply > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION" and "imply > SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE" here is wrong > as those are both part of the same choice statement. Furthermore you > cannot select/imply something from a choice statement, it must be a > "default ... > if ..." construct within the choice statement in question. I think the imply here which allows for overwritten in defconfig. To support the "defaultif...", new config for platform specific in Kconfig is required. Is there any other approach better to support this? So latter approach is preferred? > > Signed-off-by: Tom Rini > --- > Cc: Tien Fong Chee > --- > arch/arm/Kconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index > cf08fe63f1e7..071fbf1fb202 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1163,8 +1163,6 @@ config ARCH_SOCFPGA > imply SPL_DM_SPI_FLASH > imply SPL_LIBDISK_SUPPORT > imply SPL_MMC > - imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION > - imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE > imply SPL_SPI_FLASH_SUPPORT > imply SPL_SPI > imply L2X0_CACHE > -- > 2.43.0 Best regards Tien Fong
Re: [PATCH v4 00/47] x86: Improve operation under QEMU
[cc list trimmed and adding Rasmus] On Sat, Mar 15, 2025 at 02:38:29PM +, Simon Glass wrote: > Hi Tom, > > On Sat, 15 Mar 2025 at 13:57, Tom Rini wrote: > > > > On Sat, Mar 15, 2025 at 12:54:25PM +, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 14 Mar 2025 at 16:06, Tom Rini wrote: > > > > > > > > On Fri, Mar 14, 2025 at 02:44:35PM +, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Fri, 7 Mar 2025 at 14:23, Tom Rini wrote: > > > > > > > > > > > > On Thu, Mar 06, 2025 at 09:03:27AM -0700, Simon Glass wrote: > > > > > > > > > > > > > U-Boot can start and boot an OS in both qemu-x86 and qemu-x86_64 > > > > > > > but it > > > > > > > is not perfect. > > > > > > > > > > > > > > With both builds, executing the VESA ROM causes an intermittent > > > > > > > hang, at > > > > > > > least on some AMD CPUs. > > > > > > > > > > > > > > With qemu-x86_64 kvm cannot be used since the move to long mode > > > > > > > (64-bit) > > > > > > > is done in a way that works on real hardware but not with QEMU. > > > > > > > This > > > > > > > means that performance is 4-5x slower than it could be, at least > > > > > > > on my > > > > > > > CPU. > > > > > > > > > > > > > > We can work around the first problem by using Bochs, which is > > > > > > > anyway a > > > > > > > better choice than VESA for QEMU. The second can be addressed by > > > > > > > using > > > > > > > the same descriptor across the jump to long mode. > > > > > > > > > > > > > > With an MTRR fix this allows booting into Ubuntu on qemu-x86_64 > > > > > > > > > > > > > > In v3 some e820 patches are included to make booting reliable and > > > > > > > avoid > > > > > > > ACPI tables being dropped. Also, several MTTR problems are > > > > > > > addressed, to > > > > > > > support memory sizes above 4GB reliably. > > > > > > > > > > > > Do you plan to rebase the prerequisite series' this requires so > > > > > > that it > > > > > > can be merged? > > > > > > > > > > Here's my understanding of where things are: > > > > > > > > > > 1. You rejected the membuf series and my replies to try to resolve > > > > > that haven't gone anywhere yet. So your tree doesn't have any tests > > > > > for that code and still has the old naming. > > > > > > > > https://patchwork.ozlabs.org/comment/3473898/ is a well thought out not > > > > gratuitous summary of why the series as it stands is a step in the wrong > > > > direction. Tests are good. They're not a reason to pull an otherwise bad > > > > series. This series should be rebased to not depend on that series. The > > > > tests from the other series should be split out. > > > > > > It's not a bad series, unfortunately. I replied with my own comments > > > and I stand by them. > > > > > > I don't mind if you want to drop the #ifdef (which shows how a flag > > > could be used and the code-size impact). But other than that, I am > > > firm on this for now. I've already applied it to my tree and a membuf > > > implementation with tests and without a power-of-two limitation is > > > important for my current work on distros and expo. > > > > Well, you need to rebase this series without that then as I'm not going > > to take something another long time project contributor said was wrong > > and offered lots of constructive feedback on. > > It doesn't affect this series. It is for future work. > > We'll see if the LTPC replies to my concerns. Well, I guess I'm going to regret choosing to not chime in there at the time and say that no, working against your tree is the wrong direction. There's certainly enough feedback in that thread for you to make a v2 against mainline. Because to be clear, no, your v1 isn't going in mainline. -- Tom signature.asc Description: PGP signature
Re: [PATCH] efi_loader: remove EFI_BOUNCE_BUFFER
> From: Ilias Apalodimas > Date: Mon, 17 Mar 2025 15:38:36 +0200 > > The EFI subsystem defines its own bounce buffer for devices that > can't transfer data > 4GB. U-Boot already has a generic BOUNCE_BUFFER > which can be reused instead of defining another symbol. > The only limitation for EFI is that we don't know how big the file a user > chooses to transfer is and as a result we can't depend on allocating the > memory from the malloc area, which can prove too small. > > So allocate an EFI buffer of the correct size and pass it to the DM, > which already supports bounce buffering via bounce_buffer_start_extalign() The existing bounce buffer code servers a completely different purpose though. It exists to make sure that hardware with cache-incoherent DMA can safely do the required cache flushes. This means that: * SoCs with cache-coherent DMA don't necessarily set BOUNCE_BUFFER. Looks like you added that option to all the SoCs where you remove EFI_LOADER_BOUNCE_BUFFER. * SoCs that (now) set BOUNCE_BUFFER may double bounce if the buffers aren't properly aligned. I suppose that this won't happen since efi_disk_add_dev() sets medio.io_align to the device block size which is typically larger than the cache line size. Still the commit message is somewhat misleading; this code doesn't really make us use the DM bounce buffering code. I also spotted a few bugs in the implementation. See below. > Signed-off-by: Ilias Apalodimas > --- > arch/arm/Kconfig | 8 ++ > configs/ls1028aqds_tfa_SECURE_BOOT_defconfig | 1 - > configs/ls1028aqds_tfa_defconfig | 1 - > configs/ls1028aqds_tfa_lpuart_defconfig | 1 - > configs/ls1028ardb_tfa_SECURE_BOOT_defconfig | 1 - > configs/ls1028ardb_tfa_defconfig | 1 - > configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 1 - > configs/ls1043ardb_tfa_defconfig | 1 - > configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 1 - > configs/ls1046ardb_tfa_defconfig | 1 - > configs/ls1088aqds_tfa_defconfig | 1 - > configs/ls1088ardb_tfa_SECURE_BOOT_defconfig | 1 - > configs/ls1088ardb_tfa_defconfig | 1 - > configs/ls2088aqds_tfa_defconfig | 1 - > configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 1 - > configs/ls2088ardb_tfa_defconfig | 1 - > configs/lx2160aqds_tfa_SECURE_BOOT_defconfig | 1 - > configs/lx2160aqds_tfa_defconfig | 1 - > configs/lx2160ardb_tfa_SECURE_BOOT_defconfig | 1 - > configs/lx2160ardb_tfa_defconfig | 1 - > configs/lx2160ardb_tfa_stmm_defconfig | 1 - > configs/lx2162aqds_tfa_SECURE_BOOT_defconfig | 1 - > configs/lx2162aqds_tfa_defconfig | 1 - > .../lx2162aqds_tfa_verified_boot_defconfig| 1 - > configs/ten64_tfa_defconfig | 1 - > include/efi_loader.h | 4 - > lib/efi_loader/Kconfig| 7 -- > lib/efi_loader/efi_disk.c | 78 +++ > lib/efi_loader/efi_memory.c | 16 > 29 files changed, 36 insertions(+), 101 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index cf08fe63f1e7..bb946e69254c 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1417,6 +1417,7 @@ config TARGET_LS2080A_EMU > select ARCH_LS2080A > select ARM64 > select ARMV8_MULTIENTRY > + select BOUNCE_BUFFER > select FSL_DDR_SYNC_REFRESH > select GPIO_EXTRA_HEADER > help > @@ -1432,6 +1433,7 @@ config TARGET_LS1088AQDS > select ARMV8_MULTIENTRY > select ARCH_SUPPORT_TFABOOT > select BOARD_LATE_INIT > + select BOUNCE_BUFFER > select GPIO_EXTRA_HEADER > select SUPPORT_SPL > select FSL_DDR_INTERACTIVE if !SD_BOOT > @@ -1448,6 +1450,7 @@ config TARGET_LS2080AQDS > select ARMV8_MULTIENTRY > select ARCH_SUPPORT_TFABOOT > select BOARD_LATE_INIT > + select BOUNCE_BUFFER > select GPIO_EXTRA_HEADER > select SUPPORT_SPL > imply SCSI > @@ -1467,6 +1470,7 @@ config TARGET_LS2080ARDB > select ARMV8_MULTIENTRY > select ARCH_SUPPORT_TFABOOT > select BOARD_LATE_INIT > + select BOUNCE_BUFFER > select SUPPORT_SPL > select FSL_DDR_BIST > select FSL_DDR_INTERACTIVE if !SPL > @@ -1485,6 +1489,7 @@ config TARGET_LS2081ARDB > select ARM64 > select ARMV8_MULTIENTRY > select BOARD_LATE_INIT > + select BOUNCE_BUFFER > select GPIO_EXTRA_HEADER > select SUPPORT_SPL > help > @@ -1500,6 +1505,7 @@ config TARGET_LX2160ARDB > select ARMV8_MULTIENTRY > select ARCH_SUPPORT_TFABOOT > select BOARD_LATE_INIT > + select BOUNCE_BUFFER > select GPIO_EXTRA_HEADER > help > Support for NXP LX2160ARDB platform. > @@ -1514,6 +1520,7 @@ config TARGET_LX2160AQDS > select ARMV8_MULTIENTRY > select ARCH_SUPPORT_TFABOO
[PATCH] sunxi: pmic_bus: Move SPL I2C addresses into Kconfig
Some of the X-Power AXP PMICs can be ordered with an alternative I2C
address, for instance an AXP717 could be shipped with address 0x34 or
with address 0x35. Similarly the AXP803 lists two possible addresses.
For DM (DT) based drivers this is no problem, but the Allwinner SPL
code relies on exactly one hardcoded address per PMIC so far.
Add a Kconfig variable that holds the I2C address used by the PMIC
accessed in the SPL, and provide the (mostly only one) supported address
as its default, for the PMICs we use. Boards using the other address
can easily set this in their defconfig.
This effectively moves the hardcoding from C code to Kconfig.
That enables to use the AXP717 on some boards with the new Allwinner
A523 chip, which use the other I2C address there.
Signed-off-by: Andre Przywara
---
arch/arm/mach-sunxi/pmic_bus.c | 27 ++-
drivers/power/Kconfig | 10 ++
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-sunxi/pmic_bus.c b/arch/arm/mach-sunxi/pmic_bus.c
index 8e19324c8ac..c77dc538456 100644
--- a/arch/arm/mach-sunxi/pmic_bus.c
+++ b/arch/arm/mach-sunxi/pmic_bus.c
@@ -16,33 +16,10 @@
#include
#include
-#define AXP152_I2C_ADDR0x30
-
-#define AXP209_I2C_ADDR0x34
-#define AXP717_I2C_ADDR0x34
-
-#define AXP305_I2C_ADDR0x36
-#define AXP313_I2C_ADDR0x36
-
#define AXP221_CHIP_ADDR 0x68
#if CONFIG_IS_ENABLED(PMIC_AXP)
static struct udevice *pmic;
-#else
-static int pmic_i2c_address(void)
-{
- if (IS_ENABLED(CONFIG_AXP152_POWER))
- return AXP152_I2C_ADDR;
- if (IS_ENABLED(CONFIG_AXP305_POWER))
- return AXP305_I2C_ADDR;
- if (IS_ENABLED(CONFIG_AXP313_POWER))
- return AXP313_I2C_ADDR;
- if (IS_ENABLED(CONFIG_AXP717_POWER))
- return AXP717_I2C_ADDR;
-
- /* Other AXP2xx and AXP8xx variants */
- return AXP209_I2C_ADDR;
-}
#endif
int pmic_bus_init(void)
@@ -88,7 +65,7 @@ int pmic_bus_read(u8 reg, u8 *data)
if (IS_ENABLED(CONFIG_SYS_I2C_SUN8I_RSB))
return rsb_read(AXP_PMIC_PRI_RUNTIME_ADDR, reg, data);
- return i2c_read(pmic_i2c_address(), reg, 1, data, 1);
+ return i2c_read(CONFIG_AXP_I2C_ADDRESS, reg, 1, data, 1);
#endif
}
@@ -102,7 +79,7 @@ int pmic_bus_write(u8 reg, u8 data)
if (IS_ENABLED(CONFIG_SYS_I2C_SUN8I_RSB))
return rsb_write(AXP_PMIC_PRI_RUNTIME_ADDR, reg, data);
- return i2c_write(pmic_i2c_address(), reg, 1, &data, 1);
+ return i2c_write(CONFIG_AXP_I2C_ADDRESS, reg, 1, &data, 1);
#endif
}
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 5c73bc75a15..eed65058e66 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -148,6 +148,16 @@ config SY8106A_POWER
endchoice
+config AXP_I2C_ADDRESS
+ hex "AXP PMIC I2C address"
+ depends on ARCH_SUNXI && !SUNXI_NO_PMIC
+ default 0x36 if AXP305_POWER
+ default 0x36 if AXP313_POWER
+ default 0x30 if AXP152_POWER
+ default 0x34
+ ---help---
+ I2C address of the AXP PMIC, used for the SPL only.
+
config AXP_DCDC1_VOLT
int "axp pmic dcdc1 voltage"
depends on AXP221_POWER || AXP809_POWER || AXP818_POWER || AXP803_POWER
--
2.46.3
Re: [PATCH 2/8] sunxi: pmic_bus: support alternative I2C address
On Thu, 23 Jan 2025 07:37:37 -0700 Simon Glass wrote: Hi Simon, thanks for chiming in, and sorry, just realised I never answered to that email > On Mon, 20 Jan 2025 at 17:06, Andre Przywara wrote: > > > > On Mon, 20 Jan 2025 12:21:28 -0700 > > Simon Glass wrote: > > > > Hi Simon, > > > > > On Mon, 20 Jan 2025 at 09:42, Jernej Škrabec > > > wrote: > > > > > > > > Dne nedelja, 19. januar 2025 ob 23:25:30 Srednjeevropski standardni čas > > > > je Andre Przywara napisal(a): > > > > > On Sat, 18 Jan 2025 08:21:31 +0100 > > > > > Jernej Škrabec wrote: > > > > > > > > > > Hi Jernej, > > > > > > > > > > many thanks for the review and your opinion. > > > > > > > > > > > Dne petek, 17. januar 2025 ob 02:45:31 Srednjeevropski standardni > > > > > > čas je Andre Przywara napisal(a): > > > > > > > Some of the X-Power AXP PMICs can be ordered with an alternative > > > > > > > I2C > > > > > > > address, for instance an AXP717 could be shipped with address > > > > > > > 0x34 or > > > > > > > with address 0x35. > > > > > > > The datasheets for the AXP717 and AXP803 list two possible > > > > > > > addresses, > > > > > > > and they are always consecutive. For DM (DT) based drivers this > > > > > > > is no > > > > > > > problem, but the Allwinner SPL code relies on a hardcoded address. > > > > > > > > > > > > > > Add a Kconfig variable that will add "1" to the existing address > > > > > > > if it > > > > > > > is set. > > > > > > > This enables to use the AXP717 as used on boards with the new > > > > > > > Allwinner > > > > > > > A523 chip. > > > > > > > > > > > > > > Signed-off-by: Andre Przywara > > > > > > > > > > > > This works until some board vendor start mixing one or another > > > > > > address > > > > > > PMIC. Note that BSP boot0 does address autodetection, so it's not > > > > > > entirely > > > > > > out of the question. Anyway, let's hope we don't see anything like > > > > > > that. > > > > > > > > > > I looked at the datasheets for all supported PMICs, and they either > > > > > state one or two supported addresses, in the latter case both > > > > > consecutive. Autodetection sounds nice, but also unnecessary: we > > > > > surely > > > > > know what address it is for a certain board? And with those A523 > > > > > boards > > > > > having two PMICs, autodetection might become sketchy, as we don't know > > > > > for sure which PMIC we got? > > > > > > > > Speaking for T527 BSP boot0 - they check version register to make sure > > > > that > > > > correct PMIC is installed. > > > > > > > > > > > > > > But that got me thinking: what about putting the I2C address in > > > > > Kconfig > > > > > directly, with defaults depending on the PMIC type? > > > > > > > > > > config AXP_I2C_ADDR > > > > > hex "AXP PMIC I2C address" > > > > > depends on ARCH_SUNXI && !SUNXI_NO_PMIC > > > > > default 0x36 if AXP305_POWER > > > > > > > > > > > > > > > That's should work seamlessly for all supported PMICs, and we just > > > > > need > > > > > one line for the Avaota, same as with this patch here. > > > > > > > > > > What do you think? > > > > > > > > Yeah, looks more universal and avoids code changes in pmic_bus.c when > > > > adding support for new AXP PMIC, which is very nice indeed. > > > > > > Shouldn't this be in the devicetree? > > > > It is, and the DM based I2C driver used in U-Boot proper does this > > properly, and works fine. But this here is for the SPL, where we don't > > have DT support. We need just minimal support to adjust the regulator > > for the DRAMs. So far there is one fixed address used by each PMIC, so > > this is simply hardcoded, based on which PMIC is selected. The patch I > > am now proposing (snippet above) just moves that hardcoding into > > Kconfig. > > I suppose you could use of-platdata? Theoretically, maybe, but from what I can see this would be a huge effort for very little gain. It's really about some odd board using a different address. I now made a new patch which selects the I2C address by default in Kconfig (it's just four lines there). Those special snowflake boards can then select the differing address in their defconfig. That's both flexible, simple and lean. Will send that patch in a minute. Cheers, Andre
Re: [PULL] u-boot-usb/next
On Mon, 17 Mar 2025 04:15:23 +0100, Marek Vasut wrote: > The following changes since commit 0e1fc465fea62ebae91f2f56cb823e8b37ee1077: > > Merge tag 'dm-pull-15mar25' of git://git.denx.de/u-boot-dm into next > (2025-03-15 08:19:31 -0600) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git next > > [...] Merged into u-boot/next, thanks! -- Tom
Re: Pull request for u-boot-nand-next External
On Sun, Mar 16, 2025 at 06:53:00PM +0100, Michael Nazzareno Trimarchi wrote: > The following changes since commit 15d6518c942f0da13f9a7ceeadbd925c3317ec8d: > > ARM: dts: imx: Drop bogus regulator extras on DH i.MX6 DHCOM DRC02 > (2025-03-13 15:22:48 -0600) > > are available in the Git repository at: > > git://source.denx.de:u-boot/custodians/u-boot-nand-flash.git nand-next > > for you to fetch changes up to 448d27f6adf6de576860fdb9c3c4ecbe51819e33: > > mtd: rawnand: meson: always use OOB bytes during write (2025-03-16 > 14:02:05 +0100) > > This merge request add support for cadence raw nand driver for agilex board > and > add a fix to meson driver > > The patches pass the pipeline CI: > https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/25178 > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] MAINTAINERS: Add USB driver file to visionfive2 maintain files.
> > On 3/17/25 12:36 PM, Minda Chen wrote: > > Add USB related file to Starfive visionfive2 MAINTAINERS. > > The N: pattern can override this. > > > > Signed-off-by: Minda Chen > > --- > > board/starfive/visionfive2/MAINTAINERS | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/board/starfive/visionfive2/MAINTAINERS > > b/board/starfive/visionfive2/MAINTAINERS > > index 898e284ce2c..f1d2deb9f5c 100644 > > --- a/board/starfive/visionfive2/MAINTAINERS > > +++ b/board/starfive/visionfive2/MAINTAINERS > > @@ -3,5 +3,6 @@ M: Minda Chen > > M:Hal Feng > > S:Maintained > > F:drivers/ram/starfive/ > > +F: drivers/usb/cdns3/cdns3-starfive.c > > What about using 'N: starfive' instead to match on all files which include the > string 'starfive' ? > Maybe other IC code will be upstreamed. It is not me to maintain > > N:jh7110 > > N:visionfive2
[PATCH] cmd: fuse: add switch for quiet operation
Add switch -q for quiet operation to all fuse subcommands. This helps
avoid bloating the console with messages that can be distracting to
users (particularly when the command is employed by scripts and multiple
fuse values are read/compared/programmed). For example, the "fuse cmp"
command normally produces five lines of output:
U-Boot # fuse cmp 6 0 0x70af49db
Comparing bank 6:
Word 0x:
Value 0x70af49db:0x70af49db
passed
U-Boot # echo $?
0
But scripts issuing the command do not know or care about that output
since the command exit code is the only relevant information visible to
them. With the new switch one can avoid the unnecessary output:
U-Boot # fuse cmp -q 6 0 0x70af49db
U-Boot # echo $?
0
Signed-off-by: Rogerio Guerra Borin
---
cmd/fuse.c | 79 ++
1 file changed, 50 insertions(+), 29 deletions(-)
diff --git a/cmd/fuse.c b/cmd/fuse.c
index 598ef496a43..5ed221b1ecf 100644
--- a/cmd/fuse.c
+++ b/cmd/fuse.c
@@ -45,14 +45,30 @@ static int do_fuse(struct cmd_tbl *cmdtp, int flag, int
argc,
char *const argv[])
{
const char *op = cmd_arg1(argc, argv);
- int confirmed = argc >= 3 && !strcmp(argv[2], "-y");
+ int confirmed = 0, quiet = 0;
u32 bank, word, cnt, val, cmp;
ulong addr;
void *buf, *start;
int ret, i;
- argc -= 2 + confirmed;
- argv += 2 + confirmed;
+#define IF_NOT_QUIET(stmt) do { if (!quiet) { stmt; } } while(0)
+
+ if (argc >= 2) {
+ argc -= 2;
+ argv += 2;
+ }
+
+ /* Handle common switches. */
+ while (argc) {
+ if (!strcmp(argv[0], "-y"))
+ confirmed = 1;
+ else if (!strcmp(argv[0], "-q"))
+ quiet = 1;
+ else
+ break;
+ argc--;
+ argv++;
+ }
if (argc < 2 || strtou32(argv[0], 0, &bank) ||
strtou32(argv[1], 0, &word))
@@ -64,18 +80,18 @@ static int do_fuse(struct cmd_tbl *cmdtp, int flag, int
argc,
else if (argc != 3 || strtou32(argv[2], 0, &cnt))
return CMD_RET_USAGE;
- printf("Reading bank %u:\n", bank);
+ IF_NOT_QUIET(printf("Reading bank %u:\n", bank));
for (i = 0; i < cnt; i++, word++) {
if (!(i % 4))
- printf("\nWord 0x%.8x:", word);
+ IF_NOT_QUIET(printf("\nWord 0x%.8x:", word));
ret = fuse_read(bank, word, &val);
if (ret)
goto err;
- printf(" %.8x", val);
+ IF_NOT_QUIET(printf(" %.8x", val));
}
- putc('\n');
+ IF_NOT_QUIET(putc('\n'));
} else if (!strcmp(op, "readm")) {
if (argc == 3)
cnt = 1;
@@ -87,7 +103,8 @@ static int do_fuse(struct cmd_tbl *cmdtp, int flag, int argc,
start = map_sysmem(addr, 4);
buf = start;
- printf("Reading bank %u len %u to 0x%lx\n", bank, cnt, addr);
+ IF_NOT_QUIET(printf("Reading bank %u len %u to 0x%lx\n",
+ bank, cnt, addr));
for (i = 0; i < cnt; i++, word++) {
ret = fuse_read(bank, word, &val);
if (ret)
@@ -102,38 +119,38 @@ static int do_fuse(struct cmd_tbl *cmdtp, int flag, int
argc,
if (argc != 3 || strtou32(argv[2], 0, &cmp))
return CMD_RET_USAGE;
- printf("Comparing bank %u:\n", bank);
- printf("\nWord 0x%.8x:", word);
- printf("\nValue 0x%.8x:", cmp);
+ IF_NOT_QUIET(printf("Comparing bank %u:\n", bank));
+ IF_NOT_QUIET(printf("\nWord 0x%.8x:", word));
+ IF_NOT_QUIET(printf("\nValue 0x%.8x:", cmp));
ret = fuse_read(bank, word, &val);
if (ret)
goto err;
- printf("0x%.8x\n", val);
+ IF_NOT_QUIET(printf("0x%.8x\n", val));
if (val != cmp) {
- printf("failed\n");
+ IF_NOT_QUIET(printf("failed\n"));
return CMD_RET_FAILURE;
}
- printf("passed\n");
+ IF_NOT_QUIET(printf("passed\n"));
} else if (!strcmp(op, "sense")) {
if (argc == 2)
cnt = 1;
else if (argc != 3 || strtou32(argv[2], 0, &cnt))
return CMD_RET_USAGE;
- printf("Sensing bank %u:\n", bank);
+ IF_NOT_QUIET(printf("Sensing bank %u:\n", bank));
for (i = 0; i < cnt; i++, word++) {
Re: [PATCH 1/2] imx8qxp: Do not use CONFIG_XPL_BUILD in device tree
Hello, On 17.03.25 12:10, Quentin Schulz wrote: Hi Fabio, On 3/15/25 12:58 PM, Fabio Estevam wrote: Hi Hendrik, On Fri, Mar 14, 2025 at 5:09 PM Hendrik Donner wrote: In c9713c155127 the device tree was moved from CONFIG_SPL to CONFIG_SPL_BUILD and later to CONFIG_XPL_BUILD, but the CONFIG_xPL_BUILD defines are never set for device trees, breaking the build. Move the guards back to CONFIG_SPL. Please provide details about the "breaking the build". Which target The nodes will simply never be added, because CONFIG_XPL_BUILD (or CONFIG_SPL_BUILD) simply aren't passed to dtc. So essentially, this is equivalent to dead/noop code. fails to build currently? After applying this series, the previous build failures return: Yes, it was never fixed, just silenced by never building it. See https://lore.kernel.org/u-boot/2849ff05-ef67-4471- aece-422daa570...@cherry.de/ additional information: the documentation is already telling the user to acquire the missing binary blobs: https://docs.u-boot.org/en/latest/board/nxp/imx8qxp_mek.html#get-scfw-tcm-bin-and-ahab-container-img So the error from make should not happen with the correct blobs being present. But most aspect were already discussed in the mail thread this patch series was in response to. Regards, Hendrik Cheers, Quentin
[PATCH v2] mmc: mmc_boot: support sandisk and micron emmc boot/rpmb partition resizing
From: Luke Wang
Current mmc bootpart-resize cmd only support samsung emmc boot/rpmb
partition resizing. Add sandisk and micron emmc boot/rpmb partition
resizing support. The commands and parameters for resizing partitions
are different for each manufacturer. Select the corresponding function
according to cid.
Signed-off-by: Luke Wang
---
Changed in v2:
- define some macros according to Tom's comment
- correct emmc manufacturer id
---
drivers/mmc/mmc_boot.c | 173 ++---
include/mmc.h | 6 ++
2 files changed, 150 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/mmc_boot.c b/drivers/mmc/mmc_boot.c
index 367c957b518..ba6261a8ffe 100644
--- a/drivers/mmc/mmc_boot.c
+++ b/drivers/mmc/mmc_boot.c
@@ -8,20 +8,107 @@
#include
#include "mmc_private.h"
-/*
- * This function changes the size of boot partition and the size of rpmb
- * partition present on EMMC devices.
- *
- * Input Parameters:
- * struct *mmc: pointer for the mmc device strcuture
- * bootsize: size of boot partition
- * rpmbsize: size of rpmb partition
- *
- * Returns 0 on success.
- */
+static int mmc_resize_boot_micron(struct mmc *mmc, unsigned long bootsize,
+ unsigned long rpmbsize)
+{
+ int err;
-int mmc_boot_partition_size_change(struct mmc *mmc, unsigned long bootsize,
- unsigned long rpmbsize)
+ /* micron emmc doesn't support resizing rpmb partition */
+ (void)rpmbsize;
+
+ /* boot partition size is multiple of 128KB */
+ bootsize = (bootsize * 1024) / 128;
+
+ if (bootsize > 0xff)
+ bootsize = 0xff;
+
+ /* Set EXT_CSD[175] ERASE_GROUP_DEF to 0x01 */
+ err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_ERASE_GROUP_DEF, 0x01);
+ if (err)
+ goto error;
+
+ /* Set EXT_CSD[127:125] for boot partition size, [125] is low byte */
+ err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BOOT_SIZE_MULT_MICRON, bootsize);
+ if (err)
+ goto error;
+
+ err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BOOT_SIZE_MULT_MICRON + 1, 0x00);
+ if (err)
+ goto error;
+
+ err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BOOT_SIZE_MULT_MICRON + 2, 0x00);
+ if (err)
+ goto error;
+
+ /* Set EXT_CSD[155] PARTITION_SETTING_COMPLETE to 0x01 */
+ err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_PARTITION_SETTING, 0x01);
+ if (err)
+ goto error;
+
+ return 0;
+
+error:
+ debug("%s: Error = %d\n", __func__, err);
+ return err;
+}
+
+static int mmc_resize_boot_sandisk(struct mmc *mmc, unsigned long bootsize,
+ unsigned long rpmbsize)
+{
+ int err;
+ struct mmc_cmd cmd;
+
+ /* boot/rpmb partition size is multiple of 128KB */
+ bootsize = (bootsize * 1024) / 128;
+ rpmbsize = (rpmbsize * 1024) / 128;
+
+ if (bootsize > 0xff)
+ bootsize = 0xff;
+
+ if (rpmbsize > 0xff)
+ rpmbsize = 0xff;
+
+ /* Send boot/rpmb resize op code */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = MMC_CMD62_ARG_SANDISK;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err)
+ goto error;
+
+ /* Arg: boot partition size */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = bootsize;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err)
+ goto error;
+
+ /* Arg: RPMB partition size */
+ cmd.cmdidx = MMC_CMD_RES_MAN;
+ cmd.resp_type = MMC_RSP_R1b;
+ cmd.cmdarg = rpmbsize;
+
+ err = mmc_send_cmd(mmc, &cmd, NULL);
+ if (err)
+ goto error;
+
+ return 0;
+
+error:
+ debug("%s: Error = %d\n", __func__, err);
+ return err;
+}
+
+static int mmc_resize_boot_samsung(struct mmc *mmc, unsigned long bootsize,
+ unsigned long rpmbsize)
{
int err;
struct mmc_cmd cmd;
@@ -32,10 +119,8 @@ int mmc_boot_partition_size_change(struct mmc *mmc,
unsigned long bootsize,
cmd.cmdarg = MMC_CMD62_ARG1;
err = mmc_send_cmd(mmc, &cmd, NULL);
- if (err) {
- debug("mmc_boot_partition_size_change: Error1 = %d\n", err);
- return err;
- }
+ if (err)
+ goto error;
/* Boot partition changing mode */
cmd.cmdidx = MMC_CMD_RES_MAN;
@@ -43,10 +128,9 @@ int mmc_boot_partition_size_change(struct mmc *mmc,
unsigned long bootsize,
cmd.cmdarg = MMC_CMD62_ARG2;
err = mmc_send_cmd(mmc, &cmd, NULL);
- if (err) {
- debug("mmc_boot_partition_size_change: Error2 = %d\n", err);
-
Re: [PATCH 1/2] imx8qxp: Do not use CONFIG_XPL_BUILD in device tree
Hi Fabio, On 3/15/25 12:58 PM, Fabio Estevam wrote: Hi Hendrik, On Fri, Mar 14, 2025 at 5:09 PM Hendrik Donner wrote: In c9713c155127 the device tree was moved from CONFIG_SPL to CONFIG_SPL_BUILD and later to CONFIG_XPL_BUILD, but the CONFIG_xPL_BUILD defines are never set for device trees, breaking the build. Move the guards back to CONFIG_SPL. Please provide details about the "breaking the build". Which target The nodes will simply never be added, because CONFIG_XPL_BUILD (or CONFIG_SPL_BUILD) simply aren't passed to dtc. So essentially, this is equivalent to dead/noop code. fails to build currently? After applying this series, the previous build failures return: Yes, it was never fixed, just silenced by never building it. See https://lore.kernel.org/u-boot/2849ff05-ef67-4471-aece-422daa570...@cherry.de/ Cheers, Quentin
Re: [RFC PATCH v2 2/5] doc: cmd: add documentation for fuse command
On 14/03/25 22:08, Tom Rini wrote: On Fri, Mar 14, 2025 at 07:27:03PM +0530, Harsha Vardhan V M wrote: Add documentation for the 'fuse' sub-system commands. Signed-off-by: Harsha Vardhan V M --- doc/usage/cmd/fuse.rst | 156 + 1 file changed, 156 insertions(+) create mode 100644 doc/usage/cmd/fuse.rst This should delete the old doc/ file as well. Also please run: make htmldocs KDOC_WERROR=1 As this will fail due to not including this in the index at a minimum. Thanks. Thanks, Will remove the doc/README.fuse file and add the fuse index in doc/usage/index.rst
[PATCH v3 03/11] test_fs: Allow testing FS_GENERIC
The generic filesystem interface was so far untested. The interface
is similar to the FS specific interfaces with FS specific prefixes,
like ext4ls, fatmkdir, ... but it does not have any prefixes, i.e.
it provides plain ls, mkdir, ... commands.
Extend the test parameters to include 'fs_cmd_prefix' and optionally
'fs_cmd_write' parameters. The 'fs_cmd_prefix' allow specifying the
filesystem specific command prefix, like 'ext4' in 'ext4ls'. The
'fs_cmd_write' allows selecting between 'write'/'save' command name
for storing files into the filesystem, see last paragraph.
Introduce new 'fs_generic' fs_type which is used to parametrize existing
tests and run them without any prefixes if detected, thus testing the
generic filesystem interface. Use the fatfs as the backing store for the
generic FS tests.
The check_ubconfig needs to be slightly adjusted to avoid test for
CMD_FS_GENERIC_WRITE which does not exist separately from CMD_FS_GENERIC.
The CMD_FS_GENERIC does not provide generic 'write' command, instead
the generic equivalent command is called 'save' . Add simple ternary
oeprator to use 'save' command for CMD_FS_GENERIC tests and '..write'
commands for filesystem specific tests.
Enable generic filesystem tests for basic/extended/mkdir/unlink tests.
Signed-off-by: Marek Vasut
---
Cc: Baruch Siach
Cc: Francesco Dolcini
Cc: Heinrich Schuchardt
Cc: Hiago De Franco
Cc: Ilias Apalodimas
Cc: Nam Cao
Cc: Simon Glass
Cc: Sughosh Ganu
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
V2: No change
V3: Rebase on u-boot/next
---
test/py/tests/fs_helper.py | 2 +-
test/py/tests/test_fs/conftest.py| 40 +--
test/py/tests/test_fs/test_basic.py | 71 ++--
test/py/tests/test_fs/test_ext.py| 156 +--
test/py/tests/test_fs/test_mkdir.py | 42
test/py/tests/test_fs/test_unlink.py | 38 +++
6 files changed, 187 insertions(+), 162 deletions(-)
diff --git a/test/py/tests/fs_helper.py b/test/py/tests/fs_helper.py
index ccfc0201a49..378d5ae0690 100644
--- a/test/py/tests/fs_helper.py
+++ b/test/py/tests/fs_helper.py
@@ -35,7 +35,7 @@ def mk_fs(config, fs_type, size, prefix, src_dir=None,
size_gran = 0x10):
else:
mkfs_opt = ''
-if re.match('fat', fs_type):
+if re.match('fat', fs_type) or fs_type == 'fs_generic':
fs_lnxtype = 'vfat'
else:
fs_lnxtype = fs_type
diff --git a/test/py/tests/test_fs/conftest.py
b/test/py/tests/test_fs/conftest.py
index 47a584ffe7c..691bdf41ede 100644
--- a/test/py/tests/test_fs/conftest.py
+++ b/test/py/tests/test_fs/conftest.py
@@ -11,11 +11,11 @@ from fstest_defs import *
# pylint: disable=E0611
from tests import fs_helper
-supported_fs_basic = ['fat16', 'fat32', 'ext4']
-supported_fs_ext = ['fat12', 'fat16', 'fat32']
+supported_fs_basic = ['fat16', 'fat32', 'ext4', 'fs_generic']
+supported_fs_ext = ['fat12', 'fat16', 'fat32', 'fs_generic']
supported_fs_fat = ['fat12', 'fat16']
-supported_fs_mkdir = ['fat12', 'fat16', 'fat32']
-supported_fs_unlink = ['fat12', 'fat16', 'fat32']
+supported_fs_mkdir = ['fat12', 'fat16', 'fat32', 'fs_generic']
+supported_fs_unlink = ['fat12', 'fat16', 'fat32', 'fs_generic']
supported_fs_symlink = ['ext4']
supported_fs_rename = ['fat12', 'fat16', 'fat32']
@@ -108,6 +108,22 @@ def pytest_generate_tests(metafunc):
#
# Helper functions
#
+def fstype_to_prefix(fs_type):
+"""Convert a file system type to an U-Boot command prefix
+
+Args:
+fs_type: File system type.
+
+Return:
+A corresponding command prefix for file system type.
+"""
+if fs_type == 'fs_generic':
+return ''
+elif re.match('fat', fs_type):
+return 'fat'
+else:
+return fs_type
+
def fstype_to_ubname(fs_type):
"""Convert a file system type to an U-Boot specific string
@@ -141,6 +157,8 @@ def check_ubconfig(config, fs_type):
"""
if not config.buildconfig.get('config_cmd_%s' % fs_type, None):
pytest.skip('.config feature "CMD_%s" not enabled' % fs_type.upper())
+if fs_type == 'fs_generic':
+return
if not config.buildconfig.get('config_%s_write' % fs_type, None):
pytest.skip('.config feature "%s_WRITE" not enabled'
% fs_type.upper())
@@ -178,6 +196,8 @@ def fs_obj_basic(request, u_boot_config):
volume file name and a list of MD5 hashes.
"""
fs_type = request.param
+fs_cmd_prefix = fstype_to_prefix(fs_type)
+fs_cmd_write = 'save' if fs_type == 'fs_generic' else 'write'
fs_img = ''
fs_ubtype = fstype_to_ubname(fs_type)
@@ -267,7 +287,7 @@ def fs_obj_basic(request, u_boot_config):
pytest.skip('Setup failed for filesystem: ' + fs_type + '.
{}'.format(err))
return
else:
-yield [fs_ubtype, fs_img, md5val]
+yield [fs_ubtype, fs_cmd_prefix, fs_cmd_write, fs_img, md5val]
finally:
call('rm -rf %s' % scratch_dir, shell=True)
call('rm -f %s' % fs_img, shel
Re: [PATCH v3 1/8] dt-bindings: clock: rename at91.h to at91-pmc-status.h
Hi Sumit,
On 07/03/25 11:46 am, Sumit Garg wrote:
> [Some people who received this message don't often get email from
> sumit.g...@kernel.org. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Thu, Mar 06, 2025 at 10:39:28AM +, manikanda...@microchip.com wrote:
>> Hi Sumit,
>>
>> On 06/03/25 12:30 pm, Sumit Garg wrote:
>>> [Some people who received this message don't often get email from
>>> sumit.g...@kernel.org. Learn why this is important at
>>> https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>>> content is safe
>>>
>>> Hi Manikandan,
>>>
>>> On Wed, Mar 05, 2025 at 11:37:04AM +0530, Manikandan Muralidharan wrote:
Rename the include at91.h to at91-pmc-status.h to avoid conflicts with
the upstream bindings that has the same file and update the
relevant legacy SoC Device Trees to reflect this change.
This is useful while compiling the DT and driver of the new SoC files with
OF_UPSTREAM enabled.
Signed-off-by: Manikandan Muralidharan
---
MAINTAINERS | 2 +-
arch/arm/dts/at91-sama7g5ek-u-boot.dtsi | 2 +-
arch/arm/dts/at91sam9260.dtsi | 2 +-
arch/arm/dts/at91sam9261.dtsi | 2 +-
arch/arm/dts/at91sam9263.dtsi | 2 +-
arch/arm/dts/at91sam9g45.dtsi | 2 +-
arch/arm/dts/at91sam9n12.dtsi | 2 +-
arch/arm/dts/at91sam9rl.dtsi| 2 +-
arch/arm/dts/at91sam9x5.dtsi| 2 +-
arch/arm/dts/sama5d3.dtsi | 2 +-
arch/arm/dts/sama5d3_mci2.dtsi | 2 +-
arch/arm/dts/sama5d3_tcb1.dtsi | 2 +-
arch/arm/dts/sama5d3_uart.dtsi | 2 +-
arch/arm/dts/sama5d4.dtsi | 2 +-
include/dt-bindings/clock/{at91.h => at91-pmc-status.h} | 0
15 files changed, 14 insertions(+), 14 deletions(-)
rename include/dt-bindings/clock/{at91.h => at91-pmc-status.h} (100%)
>>>
>>> AFAICS, include/dt-bindings/clock/at91.h is just a subset of
>>> dts/upstream/include/dt-bindings/clock/at91.h. If that's true then we
>>> should just be able to drop local include/dt-bindings/clock/at91.h from
>>> U-Boot tree. Won't that just work fine?
>>
>>
>> Yes, you're right. It's a subset of the upstream at91.h. However, we
>> must retain it due to dependencies with legacy SoC files that haven't
>> yet been migrated to OF_UPSTREAM. I believe migrating those files now
>> would introduce a significant number of changes w.r.t Device Tree files."
>>
>
> It's not required for SoCs to be migrated to OF_UPSTREAM to start using
> upstream bindings. The DT bindings headers are meant to be stable and
> reusable such that we don't have to maintain duplicated headers.
Thanks for the insights. I will drop the local clock/at91.h and other
SoCs can continue to use local clk/at91.h, which will be migrated and
addressed in the future.
>
> -Sumit
--
Thanks and Regards,
Manikandan M.
[PATCH v1] MAINTAINERS: Add USB driver file to visionfive2 maintain files.
Add USB related file to Starfive visionfive2 MAINTAINERS. The N: pattern can override this. Signed-off-by: Minda Chen --- board/starfive/visionfive2/MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/board/starfive/visionfive2/MAINTAINERS b/board/starfive/visionfive2/MAINTAINERS index 898e284ce2c..f1d2deb9f5c 100644 --- a/board/starfive/visionfive2/MAINTAINERS +++ b/board/starfive/visionfive2/MAINTAINERS @@ -3,5 +3,6 @@ M: Minda Chen M: Hal Feng S: Maintained F: drivers/ram/starfive/ +F: drivers/usb/cdns3/cdns3-starfive.c N: jh7110 N: visionfive2 -- 2.17.1
Re: [PATCH] lmb: change the return code on lmb_alloc_addr()
On Fri, 14 Mar 2025 at 16:27, Ilias Apalodimas wrote: > > Ben reports a failure to boot the kernel on hardware that starts its > physical memory from 0x0. > The reason is that lmb_alloc_addr(), which is supposed to reserve a > specific address, takes the address as the first argument, but then also > returns the address for success or failure and treats 0 as a failure. > > Since we already know the address change the prototype to return an int. > > Reported-by: Ben Schneider > Signed-off-by: Ilias Apalodimas > --- Reviewed-by: Sughosh Ganu > fs/fs.c | 2 +- > include/lmb.h | 6 ++--- > lib/efi_loader/efi_memory.c | 3 +-- > lib/lmb.c | 6 ++--- > test/lib/lmb.c | 53 +++-- > 5 files changed, 35 insertions(+), 35 deletions(-) > [...] > diff --git a/test/lib/lmb.c b/test/lib/lmb.c > index fcb5f1af532a..01b1c7fdedd0 100644 > --- a/test/lib/lmb.c > +++ b/test/lib/lmb.c > @@ -531,21 +531,21 @@ static int test_alloc_addr(struct unit_test_state *uts, > const phys_addr_t ram) > > /* Try to allocate a page twice */ > b = lmb_alloc_addr(alloc_addr_a, 0x1000, LMB_NONE); > - ut_asserteq(b, alloc_addr_a); > - b = lmb_alloc_addr(alloc_addr_a, 0x1000, LMB_NOOVERWRITE); > ut_asserteq(b, 0); > + b = lmb_alloc_addr(alloc_addr_a, 0x1000, LMB_NOOVERWRITE); > + ut_asserteq(b, -1); > b = lmb_alloc_addr(alloc_addr_a, 0x1000, LMB_NONE); > - ut_asserteq(b, alloc_addr_a); > + ut_asserteq(b, 0); > b = lmb_alloc_addr(alloc_addr_a, 0x2000, LMB_NONE); > - ut_asserteq(b, alloc_addr_a); > + ut_asserteq(b, 0); > ret = lmb_free(alloc_addr_a, 0x2000); > ut_asserteq(ret, 0); > b = lmb_alloc_addr(alloc_addr_a, 0x1000, LMB_NOOVERWRITE); > - ut_asserteq(b, alloc_addr_a); > - b = lmb_alloc_addr(alloc_addr_a, 0x1000, LMB_NONE); > ut_asserteq(b, 0); > + b = lmb_alloc_addr(alloc_addr_a, 0x1000, LMB_NONE); > + ut_asserteq(b, -1); > b = lmb_alloc_addr(alloc_addr_a, 0x1000, LMB_NOOVERWRITE); > - ut_asserteq(b, 0); > + ut_asserteq(b, -1); > ret = lmb_free(alloc_addr_a, 0x1000); > ut_asserteq(ret, 0); > > @@ -561,22 +561,22 @@ static int test_alloc_addr(struct unit_test_state *uts, > const phys_addr_t ram) > > /* allocate blocks */ > a = lmb_alloc_addr(ram, alloc_addr_a - ram, LMB_NONE); > - ut_asserteq(a, ram); > + ut_asserteq(a, 0); > ASSERT_LMB(mem_lst, used_lst, ram, ram_size, 3, ram, 0x801, >alloc_addr_b, 0x1, alloc_addr_c, 0x1); > b = lmb_alloc_addr(alloc_addr_a + 0x1, >alloc_addr_b - alloc_addr_a - 0x1, LMB_NONE); > - ut_asserteq(b, alloc_addr_a + 0x1); > + ut_asserteq(b, 0); > ASSERT_LMB(mem_lst, used_lst, ram, ram_size, 2, ram, 0x1001, >alloc_addr_c, 0x1, 0, 0); > c = lmb_alloc_addr(alloc_addr_b + 0x1, >alloc_addr_c - alloc_addr_b - 0x1, LMB_NONE); > - ut_asserteq(c, alloc_addr_b + 0x1); > + ut_asserteq(c, 0); > ASSERT_LMB(mem_lst, used_lst, ram, ram_size, 1, ram, 0x1801, >0, 0, 0, 0); > d = lmb_alloc_addr(alloc_addr_c + 0x1, >ram_end - alloc_addr_c - 0x1, LMB_NONE); > - ut_asserteq(d, alloc_addr_c + 0x1); > + ut_asserteq(d, 0); > ASSERT_LMB(mem_lst, used_lst, ram, ram_size, 1, ram, ram_size, >0, 0, 0, 0); > > @@ -586,57 +586,58 @@ static int test_alloc_addr(struct unit_test_state *uts, > const phys_addr_t ram) > ASSERT_LMB(mem_lst, used_lst, ram, ram_size, 1, ram, ram_size, >0, 0, 0, 0); > > - ret = lmb_free(d, ram_end - alloc_addr_c - 0x1); > + /* free thge allocation from d */ nit: typo in the comment > + ret = lmb_free(alloc_addr_c + 0x1, ram_end - alloc_addr_c - > 0x1); > ut_asserteq(ret, 0); > > /* allocate at 3 points in free range */ > > d = lmb_alloc_addr(ram_end - 4, 4, LMB_NONE); > - ut_asserteq(d, ram_end - 4); > + ut_asserteq(d, 0); > ASSERT_LMB(mem_lst, used_lst, ram, ram_size, 2, ram, 0x1801, > - d, 4, 0, 0); > - ret = lmb_free(d, 4); > + ram_end - 4, 4, 0, 0); > + ret = lmb_free(ram_end - 4, 4); > ut_asserteq(ret, 0); > ASSERT_LMB(mem_lst, used_lst, ram, ram_size, 1, ram, 0x1801, >0, 0, 0, 0); > > d = lmb_alloc_addr(ram_end - 128, 4, LMB_NONE); > - ut_asserteq(d, ram_end - 128); > + ut_asserteq(d, 0); > ASSERT_LMB(mem_lst, used_lst, ram, ram_size, 2, ram, 0x1801, > - d, 4, 0, 0); > - ret = lmb_free(d, 4); > + ram_end - 128, 4, 0, 0); > +
Re: [RFC PATCH] cmd: fwu: Dump custom fields from mdata structure
Hi Sughosh and Ilias,
On 6/5/24 16:55, Michal Simek wrote:
The commit cb9ae40a16f0 ("tools: mkfwumdata: add logic to append vendor
data to the FWU metadata") added support for adding vendor data to mdata
structure but it is not visible anywhere that's why extend fwu command to
dump it.
Signed-off-by: Michal Simek
---
I am using this for some time to check various configurations that's why it
can be useful for others too.
Sughosh: Maybe there is better way how to dump it.
---
cmd/fwu_mdata.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
index 9c048d69a131..ff6435505167 100644
--- a/cmd/fwu_mdata.c
+++ b/cmd/fwu_mdata.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -45,6 +46,30 @@ static void print_mdata(struct fwu_data *data)
img_info->accepted == 0x1 ? "yes" : "no");
}
}
+
+ if (data->version == 2) {
+ struct fwu_mdata *mdata = data->fwu_mdata;
+ struct fwu_fw_store_desc *desc;
+ void *end;
+ u32 diff;
+
+ /*
+* fwu_mdata defines only header that's why taking it as array
+* which exactly point to image description location
+*/
+ desc = (struct fwu_fw_store_desc *)&mdata[1];
+
+ /* Number of entries is taken from for loop - variable i */
+ end = &desc->img_entry[i];
+ debug("mdata %p, desc %p, end %p\n", mdata, desc, end);
+
+ diff = data->metadata_size - ((void *)end - (void *)mdata);
+ if (diff) {
+ printf("Custom fields covered by CRC 0x%x\n", diff);
+ print_hex_dump_bytes("CUSTOM ", DUMP_PREFIX_OFFSET,
+end, diff);
+ }
+ }
}
int do_fwu_mdata_read(struct cmd_tbl *cmdtp, int flag,
Can you please take a look at this patch?
Thanks,
Michal
[PATCH v4 6/8] ARM: dts: at91: sam9x75_curiosity: add tweaks for sam9x75 curiosity board
Since the SoC and board DT are already available in dts/upstream,
add the difference from upstream DTS to at91-sam9x75_curiosity-u-boot.dtsi
Signed-off-by: Manikandan Muralidharan
---
.../dts/at91-sam9x75_curiosity-u-boot.dtsi| 107 ++
1 file changed, 107 insertions(+)
create mode 100644 arch/arm/dts/at91-sam9x75_curiosity-u-boot.dtsi
diff --git a/arch/arm/dts/at91-sam9x75_curiosity-u-boot.dtsi
b/arch/arm/dts/at91-sam9x75_curiosity-u-boot.dtsi
new file mode 100644
index 000..dc4fef950ec
--- /dev/null
+++ b/arch/arm/dts/at91-sam9x75_curiosity-u-boot.dtsi
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * at91-sam9x75_curiosity-u-boot.dtsi - Device Tree file for SAM9X75
+ * CURIOSITY board.
+ *
+ * Copyright (C) 2025 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Manikandan Muralidharan
+ */
+
+/ {
+ cpus {
+ cpu@0 {
+ clocks = <&pmc PMC_TYPE_CORE 25>, <&pmc PMC_TYPE_CORE
17>, <&main_xtal>;
+ clock-names = "cpu", "master", "xtal";
+ };
+ };
+
+ clocks {
+ slow_rc_osc: slow_rc_osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <18500>;
+ };
+
+ main_rc: main_rc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <1200>;
+ };
+ };
+
+ ahb {
+ bootph-all;
+
+ apb {
+ bootph-all;
+
+ pinctrl {
+ bootph-all;
+ };
+ };
+ };
+
+ chosen {
+ bootph-all;
+ };
+};
+
+&clk32k {
+ bootph-all;
+ clocks = <&slow_rc_osc>, <&slow_xtal>;
+};
+
+&dbgu {
+ bootph-all;
+};
+
+&gmac {
+ compatible = "microchip,sam9x7-gem", "cdns,sama7g5-gem";
+};
+
+&main_rc {
+ bootph-all;
+};
+
+&main_xtal {
+ bootph-all;
+};
+
+&pinctrl_dbgu_default {
+ bootph-all;
+};
+
+&pinctrl_sdmmc0_default {
+ bootph-all;
+};
+
+&pioA {
+ bootph-all;
+};
+
+&pioB {
+ bootph-all;
+};
+
+&pit64b0 {
+ bootph-all;
+};
+
+&pmc {
+ bootph-all;
+ clocks = <&clk32k 1>, <&clk32k 0>, <&main_xtal>, <&main_rc>;
+ clock-names = "td_slck", "md_slck", "main_xtal", "main_rc";
+};
+
+&sdmmc0 {
+ bootph-all;
+};
+
+&slow_xtal {
+ bootph-all;
+};
+
+&slow_rc_osc {
+ bootph-all;
+};
--
2.25.1
Re: [PATCH] phycore_imx8mp: Rework some of the RAM related Kconfig symbols
Am Freitag, dem 14.03.2025 um 19:29 -0600 schrieb Tom Rini: > As the code is today, we get a warning about "select" statements on > "choice" options not doing anything. In this case we can easily fix > this > by dropping the select line as the following choice statement handles > things correctly. We also drop the "default false" line as false / n > is > the default. > > Signed-off-by: Tom Rini Reviewed-by: Teresa Remmet > --- > Cc: Teresa Remmet > --- > board/phytec/phycore_imx8mp/Kconfig | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/board/phytec/phycore_imx8mp/Kconfig > b/board/phytec/phycore_imx8mp/Kconfig > index bdf9e97beaa6..caf9cb0c3c39 100644 > --- a/board/phytec/phycore_imx8mp/Kconfig > +++ b/board/phytec/phycore_imx8mp/Kconfig > @@ -45,7 +45,6 @@ config PHYCORE_IMX8MP_RAM_SIZE_4GB > > config PHYCORE_IMX8MP_RAM_SIZE_8GB > bool "8GB RAM" > - select PHYCORE_IMX8MP_USE_2GHZ_RAM_TIMINGS > help > Set RAM size fix to 8GB for phyCORE-i.MX8MP. > Only 2GHz RAMs are supported. > @@ -54,7 +53,6 @@ endchoice > > config PHYCORE_IMX8MP_RAM_FREQ_FIX > bool "Set phyCORE-i.MX8MP RAM frequency fix instead of > detecting" > - default false > help > RAM frequency is automatic being detected with the help of > the EEPROM introspection data. Set RAM frequency to a fix > value -- PHYTEC Messtechnik GmbH | Barcelona-Allee 1 | 55129 Mainz, Germany Geschäftsführer: Dipl.-Ing. Michael Mitezki, Dipl.-Ing. Bodo Huber, Dipl.-Ing. (FH) Markus Lickes | Handelsregister Mainz HRB 4656 | Finanzamt Mainz | St.Nr. 26/665/00608, DE 149059855
Re: [PATCH v1] mtd: rawnand: meson: always use OOB bytes during write
Hi, thanks!
On 17.03.2025 09:09, Michael Nazzareno Trimarchi wrote:
> Hi Arseniy
>
> On Sun, Dec 22, 2024 at 10:23 PM Arseniy Krasnov <
> avkras...@salutedevices.com> wrote:
>
>> If 'oob_required' is not set by the caller (for example 'oobbuf' is NULL),
>> then driver doesn't copy OOB data from 'oob_poi' to special controller
>> structures, so zeroes will be written as OOB. But, generic raw NAND logic
>> in 'nand_base.c' already handles case when OOB is not required to write by
>> filling 'oob_poi' with 0xFF's. So let's remove 'oob_required' check to
>> always read 'oob_poi' data for OOB.
>>
>> Kernel driver (drivers/mtd/nand/raw/meson_nand.c) works in the same way,
>> so need to keep same behaviour here.
>>
>> Fixes: c2e8c4d09a7a ("mtd: rawnand: Meson NAND controller support")
>> Signed-off-by: Arseniy Krasnov
>> ---
>> drivers/mtd/nand/raw/meson_nand.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/raw/meson_nand.c
>> b/drivers/mtd/nand/raw/meson_nand.c
>> index 81122315f4..82a12ac061 100644
>> --- a/drivers/mtd/nand/raw/meson_nand.c
>> +++ b/drivers/mtd/nand/raw/meson_nand.c
>> @@ -607,9 +607,7 @@ static int meson_nfc_write_page_hwecc(struct mtd_info
>> *mtd, struct nand_chip *ch
>> memcpy(meson_chip->data_buf, buf, mtd->writesize);
>>
>> memset(meson_chip->info_buf, 0, chip->ecc.steps * PER_INFO_BYTE);
>> -
>> - if (oob_required)
>> - meson_nfc_set_user_byte(chip, chip->oob_poi);
>> + meson_nfc_set_user_byte(chip, chip->oob_poi);
>>
>> return meson_nfc_write_page_sub(chip, page, false);
>> }
>>
>
> Applied and sent already the pull request
>
> Michael
>
>
>> --
>> 2.30.1
>>
>
>
[PATCH v4 8/8] configs: sam9x75_curiosity: Add initial mmc default config
Add default configuration for sd-card to boot the linux kernel. Signed-off-by: Manikandan Muralidharan --- board/atmel/sam9x75_curiosity/MAINTAINERS | 1 + configs/sam9x75_curiosity_mmc_defconfig | 73 +++ 2 files changed, 74 insertions(+) create mode 100644 configs/sam9x75_curiosity_mmc_defconfig diff --git a/board/atmel/sam9x75_curiosity/MAINTAINERS b/board/atmel/sam9x75_curiosity/MAINTAINERS index a175053418f..f0dfdbe8d5c 100644 --- a/board/atmel/sam9x75_curiosity/MAINTAINERS +++ b/board/atmel/sam9x75_curiosity/MAINTAINERS @@ -4,3 +4,4 @@ S: Maintained F: board/atmel/sam9x75_curiosity/ F: include/configs/sam9x75_curiosity.h F: arch/arm/dts/at91-sam9x75_curiosity-u-boot.dtsi +F: configs/sam9x75_curiosity_mmc_defconfig diff --git a/configs/sam9x75_curiosity_mmc_defconfig b/configs/sam9x75_curiosity_mmc_defconfig new file mode 100644 index 000..76b85448285 --- /dev/null +++ b/configs/sam9x75_curiosity_mmc_defconfig @@ -0,0 +1,73 @@ +CONFIG_ARM=y +CONFIG_SKIP_LOWLEVEL_INIT=y +CONFIG_ARCH_AT91=y +CONFIG_TEXT_BASE=0x23f0 +CONFIG_SYS_MALLOC_LEN=0x81000 +CONFIG_SYS_MALLOC_F_LEN=0x12000 +CONFIG_TARGET_SAM9X75_CURIOSITY=y +CONFIG_ATMEL_LEGACY=y +CONFIG_NR_DRAM_BANKS=8 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20015f00 +CONFIG_ENV_SIZE=0x4000 +CONFIG_DM_GPIO=y +CONFIG_DEFAULT_DEVICE_TREE="microchip/at91-sam9x75_curiosity" +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_SYS_LOAD_ADDR=0x2200 +CONFIG_DEBUG_UART_BASE=0xf200 +CONFIG_DEBUG_UART_CLOCK=2 +CONFIG_DEBUG_UART_BOARD_INIT=y +CONFIG_DEBUG_UART=y +CONFIG_FIT=y +CONFIG_SD_BOOT=y +CONFIG_BOOTDELAY=3 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="mem=256M console=ttyS0,115200 root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait" +CONFIG_USE_BOOTCOMMAND=y +CONFIG_BOOTCOMMAND="fatload mmc 0:1 0x2100 at91-sam9x75_curiosity.dtb; fatload mmc 0:1 0x2200 zImage; bootz 0x2200 - 0x2100" +CONFIG_SYS_CBSIZE=256 +CONFIG_SYS_PBSIZE=281 +CONFIG_SYS_CONSOLE_IS_IN_ENV=y +# CONFIG_DISPLAY_BOARDINFO is not set +CONFIG_HUSH_PARSER=y +CONFIG_SYS_PROMPT="U-Boot> " +CONFIG_CMD_BOOTZ=y +CONFIG_CMD_CLK=y +CONFIG_CMD_DM=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_BOOTP_BOOTFILESIZE=y +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_HASH=y +CONFIG_HASH_VERIFY=y +CONFIG_CMD_FAT=y +CONFIG_OF_CONTROL=y +CONFIG_ENV_IS_IN_FAT=y +CONFIG_ENV_FAT_DEVICE_AND_PART="0:1" +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_CLK=y +CONFIG_CLK_CCF=y +CONFIG_CLK_AT91=y +CONFIG_AT91_GENERIC_CLK=y +CONFIG_AT91_SAM9X60_PLL=y +CONFIG_CPU=y +CONFIG_AT91_GPIO=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_AT91=y +CONFIG_I2C_EEPROM=y +CONFIG_MICROCHIP_FLEXCOM=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_ATMEL=y +CONFIG_MTD=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_AT91=y +CONFIG_DM_SERIAL=y +CONFIG_DEBUG_UART_ANNOUNCE=y +CONFIG_ATMEL_USART=y +CONFIG_TIMER=y +CONFIG_MCHP_PIT64B_TIMER=y +CONFIG_PHANDLE_CHECK_SEQ=y -- 2.25.1
[PATCH v9 0/8] Add pmem node for preserving distro ISO's
This is problematic in EFI, since U-Boot mounts the image, starts the installer, and eventually calls ExitBootServices. At that point the image U-Boot mounted disappears. Some distros don't care and download the missing packages from a web archive, while others halt the installation complaining they can't find certain packages. If the firmware uses ACPI, this is supported by using NFIT which provides NVDIMM ramdisks to the OS and preserves the image. We don't have anything in place for Device Trees though. Since DT supports persistent memory nodes (pmem) use those and preserve the .iso for installers. The issue can be reproduced by attempting an EFI HTTP boot with Ubuntu live server ISO, or a Rocky Linux ISO. The installation would fail with the failure to locate certain packages. The patches are adding support for adding the pmem node to the DT that is being passed to the OS, along with removing the memory region containing the ISO image from the EFI memory map. This is being done through a helper function in the blkmap driver which scans for all blkmap mappings and does the above configurations for the relevant mappings. This version of the patchset is adding two patches to the front of the series, which re-install a device-tree(DT) on the EFI configuration table afresh on every invocation of efi_install_fdt(). This fixes the issue of a stale DT being passed on to a OS in the scenario where the DT was already installed on the configuration table. Changes since V8: * Re-word the commit message to indicate DT being installed as EFI configuration table (patch 2) * Remove the existing EFI config table in copy_fdt() (patch 2) * Move assignment of new_fdt_addr and fdt_pages variables to the block freeing up the existing config table memory (patch 2) * Re-word the commit message to indicate that the ramdisk information is being passed to the OS through pmem node (patch 3) * Change the type of addr and size parameters to the fdt_fixup_pmem_region() as u64 (patch 3) * Rename the first parameter of fdt_fixup_pmem_region() as fdt instead of blob (patch 3) * Modify the format specifier of snprintf() call in fdt_fixup_pmem_region() accordingly (patch 3) * Remove pmem_start and pmem_size array variables in fdt_fixup_pmem_region() (patch 3) * s/pmem_node/node_name/g (patch 3) * Do not initialise node_name variable (patch 3) * Re-word the commit message to indicate using efi_update_memory_map() for removal of memory from the EFI memory map (patch 4) * Use efi_update_memory_map() for removing memory from the EFI memory map instead of adding a new function efi_remove_memory_map() (patch 4) * Re-word the commit message to indicate that the ramdisk region is being removed from the EFI memory map (patch 5) * Fix the comment in prepare_loaded_image() on similar lines as above (patch 5) * s/pmem memory area/pmem memory areas/ (patch 5) * s/MB/MiB/g (patch 5) * s/blkmap slice/blkmap slices/ in the commit message (patch 6) * Add comments to the macros added in the patch (patch 6) * Add comments to the macro added in the patch (patch 7) * s/blkmap_get_preserved_pmem_slice/blkmap_get_preserved_pmem_slices/g to highlight that more than one slice is being looked for (patch 8) * Add information on the parameters being passed to the callback function in blkmap_get_preserved_pmem_slices() description (patch 8) * Highlight the fact that the callback gets called for every slice found in blkmap_get_preserved_pmem_slices() description (patch 8) * Highlight the fact that invoking the callback stops when an error is returned by the callback in blkmap_get_preserved_pmem_slices() description (patch 8) * Put some description of a typical use-case of the callback function in blkmap_get_preserved_pmem_slices() description (patch 8) Ilias Apalodimas (2): efi_loader: allow for removal of memory from the EFI map efi_loader: remove memory occupied by a ramdisk from EFI memory map Masahisa Kojima (1): fdt: add support for adding pmem nodes Sughosh Ganu (5): efi_loader: remove unused code from copy_fdt() efi_loader: install device-tree on configuration table on every invocation blkmap: store type of blkmap slice in corresponding structure blkmap: add an attribute to preserve the mem mapping blkmap: pass information on ISO image to the OS boot/fdt_support.c| 39 +++- boot/image-fdt.c | 7 +++ cmd/blkmap.c | 9 +++- drivers/block/blkmap.c| 82 +++-- drivers/block/blkmap_helper.c | 2 +- include/blkmap.h | 33 +- include/efi.h | 13 ++ include/efi_loader.h | 15 +++ include/fdt_support.h | 14 ++ lib/efi_loader/efi_bootmgr.c | 25 --- lib/efi_loader/efi_helper.c | 85 +++ lib/efi_loader/efi_memory.c | 34 +++--- 12 files changed, 310 insertions(+), 48 deletions(-) -- 2.34.1
[PATCH v9 2/8] efi_loader: install device-tree on configuration table on every invocation
The efi_install_fdt() function is called before booting an EFI binary,
either directly, or through a bootmanager. This function installs a
copy of the device-tree(DT) on the EFI configuration table, which is
passed on to the OS.
The current logic in this function does not install a DT if a
device-tree is already installed as an EFI configuration
table. However, this existing copy of the DT might not be up-to-date,
or it could be a wrong DT for the image that is being booted. Always
install a DT afresh to the configuration table before booting the EFI
binary.
Installing a new DT also involves some additional checks that are
needed to clean up memory associated with the existing DT copy. Check
for an existing copy, and free up that memory.
Signed-off-by: Sughosh Ganu
---
Changes since V8:
* Re-word the commit message to indicate DT being installed as EFI
configuration table
* Remove the existing EFI config table in copy_fdt()
* Move assignment of new_fdt_addr and fdt_pages variables to the block
freeing up the existing config table memory
lib/efi_loader/efi_helper.c | 39 +++--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c
index 15ad042bc61..f6fbcdffe82 100644
--- a/lib/efi_loader/efi_helper.c
+++ b/lib/efi_loader/efi_helper.c
@@ -454,11 +454,30 @@ efi_status_t efi_env_set_load_options(efi_handle_t handle,
*/
static efi_status_t copy_fdt(void **fdtp)
{
- unsigned long fdt_pages;
efi_status_t ret = 0;
void *fdt, *new_fdt;
- u64 new_fdt_addr;
- uint fdt_size;
+ static u64 new_fdt_addr;
+ static efi_uintn_t fdt_pages;
+ ulong fdt_size;
+
+ /*
+* Remove the configuration table that might already be
+* installed, ignoring EFI_NOT_FOUND if no device-tree
+* is installed
+*/
+ efi_install_configuration_table(&efi_guid_fdt, NULL);
+
+ if (new_fdt_addr) {
+ log_debug("%s: Found allocated memory at %#llx, with %#zx
pages\n",
+ __func__, new_fdt_addr, fdt_pages);
+
+ ret = efi_free_pages(new_fdt_addr, fdt_pages);
+ if (ret != EFI_SUCCESS)
+ log_err("Unable to free up existing FDT memory
region\n");
+
+ new_fdt_addr = 0;
+ fdt_pages = 0;
+ }
/*
* Give us at least 12 KiB of breathing room in case the device tree
@@ -473,15 +492,18 @@ static efi_status_t copy_fdt(void **fdtp)
&new_fdt_addr);
if (ret != EFI_SUCCESS) {
log_err("Failed to reserve space for FDT\n");
- goto done;
+ return ret;
}
+ log_debug("%s: Allocated memory at %#llx, with %#zx pages\n",
+ __func__, new_fdt_addr, fdt_pages);
+
new_fdt = (void *)(uintptr_t)new_fdt_addr;
memcpy(new_fdt, fdt, fdt_totalsize(fdt));
fdt_set_totalsize(new_fdt, fdt_size);
- *fdtp = (void *)(uintptr_t)new_fdt_addr;
-done:
- return ret;
+ *fdtp = new_fdt;
+
+ return EFI_SUCCESS;
}
/**
@@ -534,9 +556,6 @@ efi_status_t efi_install_fdt(void *fdt)
const char *fdt_opt;
uintptr_t fdt_addr;
- /* Look for device tree that is already installed */
- if (efi_get_configuration_table(&efi_guid_fdt))
- return EFI_SUCCESS;
/* Check if there is a hardware device tree */
fdt_opt = env_get("fdt_addr");
/* Use our own device tree as fallback */
--
2.34.1
[PATCH v9 1/8] efi_loader: remove unused code from copy_fdt()
There is logic in the copy_fdt() function which is iterating over the
platform's DRAM banks and setting the fdt_ram_start variable. However,
this variable is not used subsequently in the function. Remove this
superfluous code.
Signed-off-by: Sughosh Ganu
Reviewed-by: Ilias Apalodimas
Reviewed-by: Heinrich Schuchardt
---
Changes since V8: None
lib/efi_loader/efi_helper.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c
index 04b2efc4a3b..15ad042bc61 100644
--- a/lib/efi_loader/efi_helper.c
+++ b/lib/efi_loader/efi_helper.c
@@ -454,23 +454,11 @@ efi_status_t efi_env_set_load_options(efi_handle_t handle,
*/
static efi_status_t copy_fdt(void **fdtp)
{
- unsigned long fdt_ram_start = -1L, fdt_pages;
+ unsigned long fdt_pages;
efi_status_t ret = 0;
void *fdt, *new_fdt;
u64 new_fdt_addr;
uint fdt_size;
- int i;
-
- for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
- u64 ram_start = gd->bd->bi_dram[i].start;
- u64 ram_size = gd->bd->bi_dram[i].size;
-
- if (!ram_size)
- continue;
-
- if (ram_start < fdt_ram_start)
- fdt_ram_start = ram_start;
- }
/*
* Give us at least 12 KiB of breathing room in case the device tree
--
2.34.1
[PATCH v9 8/8] blkmap: pass information on ISO image to the OS
The EFI HTTP boot puts the ISO installer image at some location in
memory. Information about this image has to be passed on to the OS
kernel, which is done by adding a persistent memory(pmem) node to the
devicetree(DT) that is passed to the OS. The OS kernel then gets
information about the presence of this ISO image and proceeds with the
installation.
In U-Boot, this ISO image gets mounted as a memory mapped blkmap
device slice, with the 'preserve' attribute. Add a helper function
which iterates through all such slices, and invokes a callback. The
callback adds the pmem node to the DT and removes the corresponding
memory region from the EFI memory map. Invoke this helper function as
part of the DT fixup which happens before booting the OS.
Signed-off-by: Sughosh Ganu
Reviewed-by: Tobias Waldekranz
---
Changes since V8:
* s/blkmap_get_preserved_pmem_slice/blkmap_get_preserved_pmem_slices/g
to highlight that more than one slice is being looked for
* Add information on the parameters being passed to the callback
function in blkmap_get_preserved_pmem_slices() description
* Highlight the fact that the callback gets called for every slice
found in blkmap_get_preserved_pmem_slices() description
* Highlight the fact that invoking the callback stops when an error is
returned by the callback in blkmap_get_preserved_pmem_slices()
description
* Put some description of a typical use-case of the callback function
in blkmap_get_preserved_pmem_slices() description
boot/image-fdt.c| 7 ++
drivers/block/blkmap.c | 43 +
include/blkmap.h| 29 +
include/efi.h | 13 +++
lib/efi_loader/efi_helper.c | 42
5 files changed, 134 insertions(+)
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index 9d1598b1a93..8f718ad29f6 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -649,6 +650,12 @@ int image_setup_libfdt(struct bootm_headers *images, void
*blob, bool lmb)
if (!ft_verify_fdt(blob))
goto err;
+ if (CONFIG_IS_ENABLED(BLKMAP) && CONFIG_IS_ENABLED(EFI_LOADER)) {
+ fdt_ret = fdt_efi_pmem_setup(blob);
+ if (fdt_ret)
+ goto err;
+ }
+
/* after here we are using a livetree */
if (!of_live_active() && CONFIG_IS_ENABLED(EVENT)) {
struct event_ft_fixup fixup;
diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
index 1b161bd90be..473c65b5911 100644
--- a/drivers/block/blkmap.c
+++ b/drivers/block/blkmap.c
@@ -517,6 +517,49 @@ err:
return err;
}
+static bool blkmap_mem_preserve_slice(struct blkmap_slice *bms)
+{
+ return (bms->attr & (BLKMAP_SLICE_MEM | BLKMAP_SLICE_PRESERVE)) ==
+ (BLKMAP_SLICE_MEM | BLKMAP_SLICE_PRESERVE);
+}
+
+int blkmap_get_preserved_pmem_slices(int (*cb)(void *ctx, u64 addr,
+ u64 size), void *ctx)
+{
+ int ret;
+ u64 addr, size;
+ struct udevice *dev;
+ struct uclass *uc;
+ struct blkmap *bm;
+ struct blkmap_mem *bmm;
+ struct blkmap_slice *bms;
+ struct blk_desc *bd;
+
+ if (!cb) {
+ log_debug("%s: No callback passed to the function\n", __func__);
+ return 0;
+ }
+
+ uclass_id_foreach_dev(UCLASS_BLKMAP, dev, uc) {
+ bm = dev_get_plat(dev);
+ bd = dev_get_uclass_plat(bm->blk);
+
+ list_for_each_entry(bms, &bm->slices, node) {
+ if (!blkmap_mem_preserve_slice(bms))
+ continue;
+
+ bmm = container_of(bms, struct blkmap_mem, slice);
+ addr = (u64)(uintptr_t)bmm->addr;
+ size = (u64)bms->blkcnt << bd->log2blksz;
+ ret = cb(ctx, addr, size);
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
int blkmap_destroy(struct udevice *dev)
{
int err;
diff --git a/include/blkmap.h b/include/blkmap.h
index 754d8671b01..57555fda4fb 100644
--- a/include/blkmap.h
+++ b/include/blkmap.h
@@ -7,6 +7,7 @@
#ifndef _BLKMAP_H
#define _BLKMAP_H
+#include
#include
/**
@@ -104,4 +105,32 @@ int blkmap_destroy(struct udevice *dev);
int blkmap_create_ramdisk(const char *label, ulong image_addr, ulong
image_size,
struct udevice **devp);
+/**
+ * blkmap_get_preserved_pmem_slices() - Look for memory mapped preserved slices
+ * @cb: Callback function to call for the blkmap slice
+ * @ctx: Argument to be passed to the callback function
+ *
+ * The function is used to iterate through all the blkmap slices, looking
+ * specifically for memory mapped blkmap mapping which has been
+ * crea
[PATCH v9 7/8] blkmap: add an attribute to preserve the mem mapping
Some blkmap memory mapped devices might have to be relevant even
after U-Boot passes control to the next image as part of the platform
boot. An example of such a mapping would be an OS installer ISO image,
information for which has to be provided to the OS kernel. Use the
'preserve' attribute for such mappings. The code for adding a pmem
node to the device-tree then checks if this attribute is set, and adds
a node only for mappings which have this attribute.
Signed-off-by: Sughosh Ganu
Reviewed-by: Tobias Waldekranz
Reviewed-by: Ilias Apalodimas
---
Changes since V8:
* Add comments to the macro added in the patch
cmd/blkmap.c | 9 +++--
drivers/block/blkmap.c| 19 +++
drivers/block/blkmap_helper.c | 2 +-
include/blkmap.h | 4 +++-
4 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/cmd/blkmap.c b/cmd/blkmap.c
index 164f80f1387..86a123b1cd3 100644
--- a/cmd/blkmap.c
+++ b/cmd/blkmap.c
@@ -62,13 +62,18 @@ static int do_blkmap_map_mem(struct map_ctx *ctx, int argc,
char *const argv[])
{
phys_addr_t addr;
int err;
+ bool preserve = false;
if (argc < 2)
return CMD_RET_USAGE;
addr = hextoul(argv[1], NULL);
- err = blkmap_map_pmem(ctx->dev, ctx->blknr, ctx->blkcnt, addr);
+ if (argc == 3 && !strcmp(argv[2], "preserve"))
+ preserve = true;
+
+ err = blkmap_map_pmem(ctx->dev, ctx->blknr, ctx->blkcnt, addr,
+ preserve);
if (err) {
printf("Unable to map %#llx at block 0x" LBAF ": %d\n",
(unsigned long long)addr, ctx->blknr, err);
@@ -221,7 +226,7 @@ U_BOOT_CMD_WITH_SUBCMDS(
"blkmap create - create device\n"
"blkmap destroy - destroy device\n"
"blkmap maplinear-
device mapping\n"
- "blkmap mapmem - memory mapping\n",
+ "blkmap mapmem [preserve] - memory
mapping\n",
U_BOOT_SUBCMD_MKENT(info, 2, 1, do_blkmap_common),
U_BOOT_SUBCMD_MKENT(part, 2, 1, do_blkmap_common),
U_BOOT_SUBCMD_MKENT(dev, 4, 1, do_blkmap_common),
diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
index 08f68570224..1b161bd90be 100644
--- a/drivers/block/blkmap.c
+++ b/drivers/block/blkmap.c
@@ -32,6 +32,14 @@ struct blkmap;
*/
#define BLKMAP_SLICE_MEM BIT(1)
+/**
+ * define BLKMAP_SLICE_PRESERVE - Preserved blkmap slice
+ *
+ * This blkmap slice is intended to be preserved, and it's
+ * information passed on to a later stage, like OS.
+ */
+#define BLKMAP_SLICE_PRESERVE BIT(2)
+
/**
* struct blkmap_slice - Region mapped to a blkmap
*
@@ -253,7 +261,7 @@ static void blkmap_mem_destroy(struct blkmap *bm, struct
blkmap_slice *bms)
}
int __blkmap_map_mem(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
-void *addr, bool remapped)
+void *addr, bool remapped, bool preserve)
{
struct blkmap *bm = dev_get_plat(dev);
struct blkmap_mem *bmm;
@@ -278,6 +286,9 @@ int __blkmap_map_mem(struct udevice *dev, lbaint_t blknr,
lbaint_t blkcnt,
.remapped = remapped,
};
+ if (preserve)
+ bmm->slice.attr |= BLKMAP_SLICE_PRESERVE;
+
err = blkmap_slice_add(bm, &bmm->slice);
if (err)
free(bmm);
@@ -288,11 +299,11 @@ int __blkmap_map_mem(struct udevice *dev, lbaint_t blknr,
lbaint_t blkcnt,
int blkmap_map_mem(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
void *addr)
{
- return __blkmap_map_mem(dev, blknr, blkcnt, addr, false);
+ return __blkmap_map_mem(dev, blknr, blkcnt, addr, false, false);
}
int blkmap_map_pmem(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
- phys_addr_t paddr)
+ phys_addr_t paddr, bool preserve)
{
struct blkmap *bm = dev_get_plat(dev);
struct blk_desc *bd = dev_get_uclass_plat(bm->blk);
@@ -303,7 +314,7 @@ int blkmap_map_pmem(struct udevice *dev, lbaint_t blknr,
lbaint_t blkcnt,
if (!addr)
return -ENOMEM;
- err = __blkmap_map_mem(dev, blknr, blkcnt, addr, true);
+ err = __blkmap_map_mem(dev, blknr, blkcnt, addr, true, preserve);
if (err)
unmap_sysmem(addr);
diff --git a/drivers/block/blkmap_helper.c b/drivers/block/blkmap_helper.c
index bfba14110d2..2f1bc28ee5d 100644
--- a/drivers/block/blkmap_helper.c
+++ b/drivers/block/blkmap_helper.c
@@ -28,7 +28,7 @@ int blkmap_create_ramdisk(const char *label, ulong
image_addr, ulong image_size,
bm = dev_get_plat(bm_dev);
desc = dev_get_uclass_plat(bm->blk);
blknum = image_size >> desc->log2blksz;
- ret = blkmap_map_pmem(bm_dev, 0, blknum, image_addr);
+ ret = blkmap_map_pmem(bm_dev, 0, blknum, image_addr, true);
if (ret) {
log_err("Unable to map %#llx at block %d : %d\n",
[PATCH v9 3/8] fdt: add support for adding pmem nodes
From: Masahisa Kojima
One of the problems an OS may face, when running in EFI, is that
a mounted ISO, after calling ExitBootServices goes away, if that ISO
is resident in RAM memory as a ramdisk.
ACPI has NFIT and NVDIMM support to provide ramdisks to the OS, but we
don't have anything in place for DTs. Linux and device trees have support
for persistent memory devices. So add a function that can inject a pmem
node in a DT, so we can pass information on the ramdisk the OS.
Signed-off-by: Masahisa Kojima
Signed-off-by: Sughosh Ganu
---
Changes since V8:
* Re-word the commit message to indicate that the ramdisk information
is being passed to the OS through pmem node
* Change the type of addr and size parameters to the
fdt_fixup_pmem_region() as u64
* Rename the first parameter of fdt_fixup_pmem_region() as fdt instead
of blob
* Modify the format specifier of snprintf() call in
fdt_fixup_pmem_region() accordingly
* Remove pmem_start and pmem_size array variables in
fdt_fixup_pmem_region()
* s/pmem_node/node_name/g
* Do not initialise node_name variable
boot/fdt_support.c| 39 ++-
include/fdt_support.h | 14 ++
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 49efeec3681..92f2f534ee0 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -464,7 +465,6 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
do_fixup_by_compat(fdt, compat, prop, &tmp, 4, create);
}
-#ifdef CONFIG_ARCH_FIXUP_FDT_MEMORY
/*
* fdt_pack_reg - pack address and size array into the "reg"-suitable stream
*/
@@ -493,6 +493,7 @@ static int fdt_pack_reg(const void *fdt, void *buf, u64
*address, u64 *size,
return p - (char *)buf;
}
+#ifdef CONFIG_ARCH_FIXUP_FDT_MEMORY
#if CONFIG_NR_DRAM_BANKS > 4
#define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
#else
@@ -,3 +2223,39 @@ int fdt_valid(struct fdt_header **blobp)
}
return 1;
}
+
+int fdt_fixup_pmem_region(void *fdt, u64 pmem_start, u64 pmem_size)
+{
+ char node_name[32];
+ int nodeoffset, len;
+ int err;
+ u8 tmp[4 * 16]; /* Up to 64-bit address + 64-bit size */
+
+ if (!IS_ALIGNED(pmem_start, SZ_2M) ||
+ !IS_ALIGNED(pmem_start + pmem_size, SZ_2M)) {
+ printf("Start and end address must be 2MiB aligned\n");
+ return -1;
+ }
+
+ snprintf(node_name, sizeof(node_name), "pmem@%llx", pmem_start);
+ nodeoffset = fdt_find_or_add_subnode(fdt, 0, node_name);
+ if (nodeoffset < 0)
+ return nodeoffset;
+
+ err = fdt_setprop_string(fdt, nodeoffset, "compatible", "pmem-region");
+ if (err)
+ return err;
+ err = fdt_setprop_empty(fdt, nodeoffset, "volatile");
+ if (err)
+ return err;
+
+ len = fdt_pack_reg(fdt, tmp, &pmem_start, &pmem_size, 1);
+ err = fdt_setprop(fdt, nodeoffset, "reg", tmp, len);
+ if (err < 0) {
+ printf("WARNING: could not set pmem %s %s.\n", "reg",
+ fdt_strerror(err));
+ return err;
+ }
+
+ return 0;
+}
diff --git a/include/fdt_support.h b/include/fdt_support.h
index f0ad2e6b365..049190cf3d7 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -471,6 +471,20 @@ int fdt_valid(struct fdt_header **blobp);
*/
int fdt_get_cells_len(const void *blob, char *nr_cells_name);
+/**
+ * fdt_fixup_pmem_region() - add a pmem node on the device tree
+ *
+ * This functions adds/updates a pmem node to the device tree.
+ * Usually used with EFI installers to preserve installer
+ * images
+ *
+ * @fdt: device tree provided by caller
+ * @addr: start address of the pmem node
+ * @size: size of the memory of the pmem node
+ * Return: 0 on success or < 0 on failure
+ */
+int fdt_fixup_pmem_region(void *fdt, u64 pmem_start, u64 pmem_size);
+
#endif /* !USE_HOSTCC */
#ifdef USE_HOSTCC
--
2.34.1
[PATCH v9 4/8] efi_loader: allow for removal of memory from the EFI map
From: Ilias Apalodimas
With upcoming changes supporting pmem nodes, we need to remove the
pmem area from the EFI memory map. Rename efi_add_memory_map_pg() to
efi_update_memory_map(), and allow removing memory from the EFI memory
map.
Signed-off-by: Ilias Apalodimas
Signed-off-by: Sughosh Ganu
---
Changes since V8:
* Re-word the commit message to indicate using efi_update_memory_map()
for removal of memory from the EFI memory map
* Use efi_update_memory_map() for removing memory from the EFI memory
map instead of adding a new function efi_remove_memory_map()
include/efi_loader.h| 15 +++
lib/efi_loader/efi_memory.c | 34 ++
2 files changed, 33 insertions(+), 16 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index e9c10819ba2..5f769786786 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -878,6 +878,21 @@ efi_status_t efi_get_memory_map(efi_uintn_t
*memory_map_size,
/* Adds a range into the EFI memory map */
efi_status_t efi_add_memory_map(u64 start, u64 size, int memory_type);
+/**
+ * efi_update_memory_map() - update the memory map by adding/removing pages
+ *
+ * @start: start address, must be a multiple of
+ * EFI_PAGE_SIZE
+ * @pages: number of pages to add
+ * @memory_type: type of memory added
+ * @overlap_conventional: region may only overlap free(conventional)
+ * memory
+ * @remove:remove memory map
+ * Return: status code
+ */
+efi_status_t efi_update_memory_map(u64 start, u64 pages, int memory_type,
+ bool overlap_conventional, bool remove);
+
/* Called by board init to initialize the EFI drivers */
efi_status_t efi_driver_init(void);
/* Called when a block device is added */
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 6d00b186250..487b5e302cc 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -258,7 +258,7 @@ static s64 efi_mem_carve_out(struct efi_mem_list *map,
}
/**
- * efi_add_memory_map_pg() - add pages to the memory map
+ * efi_update_memory_map() - update the memory map by adding/removing pages
*
* @start: start address, must be a multiple of
* EFI_PAGE_SIZE
@@ -266,12 +266,11 @@ static s64 efi_mem_carve_out(struct efi_mem_list *map,
* @memory_type: type of memory added
* @overlap_conventional: region may only overlap free(conventional)
* memory
+ * @remove:remove memory map
* Return: status code
*/
-static
-efi_status_t efi_add_memory_map_pg(u64 start, u64 pages,
- int memory_type,
- bool overlap_conventional)
+efi_status_t efi_update_memory_map(u64 start, u64 pages, int memory_type,
+ bool overlap_conventional, bool remove)
{
struct efi_mem_list *lmem;
struct efi_mem_list *newlist;
@@ -279,9 +278,9 @@ efi_status_t efi_add_memory_map_pg(u64 start, u64 pages,
uint64_t carved_pages = 0;
struct efi_event *evt;
- EFI_PRINT("%s: 0x%llx 0x%llx %d %s\n", __func__,
+ EFI_PRINT("%s: 0x%llx 0x%llx %d %s %s\n", __func__,
start, pages, memory_type, overlap_conventional ?
- "yes" : "no");
+ "yes" : "no", remove ? "remove" : "add");
if (memory_type >= EFI_MAX_MEMORY_TYPE)
return EFI_INVALID_PARAMETER;
@@ -364,7 +363,10 @@ efi_status_t efi_add_memory_map_pg(u64 start, u64 pages,
}
/* Add our new map */
-list_add_tail(&newlist->link, &efi_mem);
+ if (!remove)
+ list_add_tail(&newlist->link, &efi_mem);
+ else
+ free(newlist);
/* And make sure memory is listed in descending order */
efi_mem_sort();
@@ -401,7 +403,7 @@ efi_status_t efi_add_memory_map(u64 start, u64 size, int
memory_type)
pages = efi_size_in_pages(size + (start & EFI_PAGE_MASK));
start &= ~EFI_PAGE_MASK;
- return efi_add_memory_map_pg(start, pages, memory_type, false);
+ return efi_update_memory_map(start, pages, memory_type, false, false);
}
/**
@@ -502,7 +504,7 @@ efi_status_t efi_allocate_pages(enum efi_allocate_type type,
efi_addr = (u64)(uintptr_t)map_sysmem(addr, 0);
/* Reserve that map in our memory maps */
- ret = efi_add_memory_map_pg(efi_addr, pages, memory_type, true);
+ ret = efi_update_memory_map(efi_addr, pages, memory_type, true, false);
if (ret != EFI_SUCCESS) {
/* Map would overlap, bail out */
lmb_free_flags(addr, (u64)pages << EFI_PAGE_SHIFT, flags);
@@ -823,8 +825,8 @@ static void add_u_boot_and_runtime(void)
[PATCH v9 5/8] efi_loader: remove memory occupied by a ramdisk from EFI memory map
From: Ilias Apalodimas
ACPI has NFIT and NVDIMM support to provide ramdisks to the OS. Linux
and device trees have support for persistent memory(pmem) devices. The
firmware can then add a pmem node for the region of memory occupied by
the ramdisk when passing the device-tree to the OS.
It's worth noting that for linux to instantiate the /dev/pmemX device,
the memory described in the pmem node has to be omitted from the EFI
memory map we hand over to the OS if ZONE_DEVICES and SPARSEMEM is
enabled. With those enabled the pmem driver ends up calling
devm_memremap_pages() instead of devm_memremap(). The latter works
whether the memory is omitted or marked as reserved, but mapping pages
only works if the memory is omitted.
On top of that, depending on how the kernel is configured, that memory
area must be page aligned or 2MiB aligned. PowerPC is an exception here
and requires 16MiB alignment, but since we don't have EFI support for
it, limit the alignment to 2MiB.
Ensure that the ISO image is 2MiB aligned and remove the region
occupied by the image from the EFI memory map.
Signed-off-by: Ilias Apalodimas
Signed-off-by: Sughosh Ganu
---
* Re-word the commit message to indicate that the ramdisk region is
being removed from the EFI memory map
* Fix the comment in prepare_loaded_image() on similar lines as above
* s/pmem memory area/pmem memory areas/
* s/MB/MiB/g
lib/efi_loader/efi_bootmgr.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index c6124c590d9..f9534ef85ed 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
static const struct efi_boot_services *bs;
static const struct efi_runtime_services *rs;
@@ -348,6 +350,7 @@ static efi_status_t prepare_loaded_image(u16 *label, ulong
addr, ulong size,
struct efi_device_path **dp,
struct udevice **blk)
{
+ u64 pages;
efi_status_t ret;
struct udevice *ramdisk_blk;
@@ -362,13 +365,18 @@ static efi_status_t prepare_loaded_image(u16 *label,
ulong addr, ulong size,
}
/*
-* TODO: expose the ramdisk to OS.
-* Need to pass the ramdisk information by the architecture-specific
-* methods such as 'pmem' device-tree node.
+* Linux supports 'pmem' which allows OS installers to find, reclaim
+* the mounted images and continue the installation since the contents
+* of the pmem region are treated as local media.
+*
+* The memory regions used for it needs to be carved out of the EFI
+* memory map.
*/
- ret = efi_add_memory_map(addr, size, EFI_RESERVED_MEMORY_TYPE);
+ pages = efi_size_in_pages(size + (addr & EFI_PAGE_MASK));
+ ret = efi_update_memory_map(addr, pages, EFI_CONVENTIONAL_MEMORY,
+ false, true);
if (ret != EFI_SUCCESS) {
- log_err("Memory reservation failed\n");
+ log_err("Failed to reserve memory\n");
goto err;
}
@@ -490,6 +498,13 @@ static efi_status_t try_load_from_uri_path(struct
efi_device_path_uri *uridp,
ret = EFI_INVALID_PARAMETER;
goto err;
}
+ /*
+* Depending on the kernel configuration, pmem memory areas must be
+* page aligned or 2MiB aligned. PowerPC is an exception here and
+* requires 16MiB alignment, but since we don't have EFI support for
+* it, limit the alignment to 2MiB.
+*/
+ image_size = ALIGN(image_size, SZ_2M);
/*
* If the file extension is ".iso" or ".img", mount it and try to load
--
2.34.1
[PATCH v4 5/8] ARM: at91: Add sam9x7 soc
From: Varshini Rajendran
Add new Microchip sam9x7 SoC based on an ARM926.
Signed-off-by: Varshini Rajendran
Signed-off-by: Balamanikandan Gunasundar
Signed-off-by: Manikandan Muralidharan
---
arch/arm/mach-at91/Kconfig| 4 +
arch/arm/mach-at91/arm926ejs/Makefile | 1 +
arch/arm/mach-at91/arm926ejs/sam9x7_devices.c | 49 +
arch/arm/mach-at91/include/mach/hardware.h| 2 +
arch/arm/mach-at91/include/mach/sam9x7.h | 172 ++
5 files changed, 228 insertions(+)
create mode 100644 arch/arm/mach-at91/arm926ejs/sam9x7_devices.c
create mode 100644 arch/arm/mach-at91/include/mach/sam9x7.h
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 7c4ccc427c8..5429257875d 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -43,6 +43,10 @@ config SAM9X60
bool
select CPU_ARM926EJS
+config SAM9X7
+ bool
+ select CPU_ARM926EJS
+
config SAMA7G5
bool
select CPU_V7A
diff --git a/arch/arm/mach-at91/arm926ejs/Makefile
b/arch/arm/mach-at91/arm926ejs/Makefile
index 8f0bc5d997e..977299a5911 100644
--- a/arch/arm/mach-at91/arm926ejs/Makefile
+++ b/arch/arm/mach-at91/arm926ejs/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_AT91SAM9G45) += at91sam9m10g45_devices.o
obj-$(CONFIG_AT91SAM9N12) += at91sam9n12_devices.o
obj-$(CONFIG_AT91SAM9X5) += at91sam9x5_devices.o
obj-$(CONFIG_SAM9X60) += sam9x60_devices.o
+obj-$(CONFIG_SAM9X7) += sam9x7_devices.o
obj-y += clock.o
obj-y += cpu.o
ifndef CONFIG_$(PHASE_)SYSRESET
diff --git a/arch/arm/mach-at91/arm926ejs/sam9x7_devices.c
b/arch/arm/mach-at91/arm926ejs/sam9x7_devices.c
new file mode 100644
index 000..c65764a3de4
--- /dev/null
+++ b/arch/arm/mach-at91/arm926ejs/sam9x7_devices.c
@@ -0,0 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2025 Microchip Technology Inc. and its subsidiaries
+ */
+
+#include
+#include
+#include
+#include
+
+unsigned int get_chip_id(void)
+{
+ /* The 0x40 is the offset of cidr in DBGU */
+ return readl(ATMEL_BASE_DBGU + 0x40);
+}
+
+unsigned int get_extension_chip_id(void)
+{
+ /* The 0x44 is the offset of exid in DBGU */
+ return readl(ATMEL_BASE_DBGU + 0x44);
+}
+
+char *get_cpu_name(void)
+{
+ unsigned int extension_id = get_extension_chip_id();
+
+ if (cpu_is_sam9x7()) {
+ switch (extension_id) {
+ case ARCH_EXID_SAM9X70:
+ return "SAM9X70";
+ case ARCH_EXID_SAM9X72:
+ return "SAM9X72";
+ case ARCH_EXID_SAM9X75:
+ return "SAM9X75";
+ case ARCH_EXID_SAM9X75_D1M:
+ return "SAM9X75 16MB DDR2 SiP";
+ case ARCH_EXID_SAM9X75_D5M:
+ return "SAM9X75 64MB DDR2 SiP";
+ case ARCH_EXID_SAM9X75_D1G:
+ return "SAM9X75 125MB DDR3L SiP";
+ case ARCH_EXID_SAM9X75_D2G:
+ return "SAM9X75 250MB DDR3L SiP";
+ default:
+ return "Unknown CPU type";
+ }
+ } else {
+ return "Unknown CPU type";
+ }
+}
diff --git a/arch/arm/mach-at91/include/mach/hardware.h
b/arch/arm/mach-at91/include/mach/hardware.h
index 988ef492b62..de89714b097 100644
--- a/arch/arm/mach-at91/include/mach/hardware.h
+++ b/arch/arm/mach-at91/include/mach/hardware.h
@@ -23,6 +23,8 @@
# include
#elif defined(CONFIG_SAM9X60)
# include
+#elif defined(CONFIG_SAM9X7)
+# include
#elif defined(CONFIG_SAMA7G5)
# include
#elif defined(CONFIG_SAMA5D2)
diff --git a/arch/arm/mach-at91/include/mach/sam9x7.h
b/arch/arm/mach-at91/include/mach/sam9x7.h
new file mode 100644
index 000..998fa786f90
--- /dev/null
+++ b/arch/arm/mach-at91/include/mach/sam9x7.h
@@ -0,0 +1,172 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Chip-specific header file for the SAM9X7 SoC.
+ *
+ * Copyright (C) 2025 Microchip Technology Inc. and its subsidiaries
+ */
+
+#ifndef __SAM9X7_H__
+#define __SAM9X7_H__
+
+/*
+ * Peripheral identifiers/interrupts.
+ */
+#define ATMEL_ID_FIQ 0 /* Advanced Interrupt Controller - FIQ
*/
+#define ATMEL_ID_SYS 1 /* System Controller Interrupt */
+#define ATMEL_ID_PIOA 2 /* Parallel I/O Controller A */
+#define ATMEL_ID_PIOB 3 /* Parallel I/O Controller B */
+#define ATMEL_ID_PIOC 4 /* Parallel I/O Controller C */
+#define ATMEL_ID_FLEXCOM0 5 /* FLEXCOM 0 */
+#define ATMEL_ID_FLEXCOM1 6 /* FLEXCOM 1 */
+#define ATMEL_ID_FLEXCOM2 7 /* FLEXCOM 2 */
+#define ATMEL_ID_FLEXCOM3 8 /* FLEXCOM 3 */
+#define ATMEL_ID_FLEXCOM6 9 /* FLEXCOM 6 */
+#define ATMEL_ID_FLEXCOM7 10 /* FLEXCOM 7 */
+#define ATMEL_ID_FLEXCOM8 11 /* FLEXCOM 8 */
+#define ATMEL_ID_SDMMC0
Re: [PATCH v2 12/15] efi_loader: Move .dynamic out of .text in EFI
On 3/15/25 23:18, Sam Edwards wrote:
EFI applications need to be relocatable. Ordinarily, this is achieved
through a PE-format .reloc section, but since that requires toolchain
tricks to achieve, U-Boot's EFI applications instead embed ELF-flavored
relocation information and use it for self-relocation; thus, the
.dynamic section needs to be preserved.
Before this patch, it was tacked on to the end of .text, but this was
not proper: A .text section is SHT_PROGBITS, while the .dynamic section
is SHT_DYNAMIC. Attempting to combine them like this creates a section
type mismatch. While GNU ld doesn't seem to complain, LLVM's lld
considers this a fatal linking error.
This patch moves .dynamic out to its own section, so that the output ELF
has the correct types. (They're all mashed together when converting to
binary anyway, so this patch causes no change in the final .efi output.)
Signed-off-by: Sam Edwards
Cc: Heinrich Schuchardt
Reviewed-by: Heinrich Schuchardt
---
lib/efi_loader/elf_efi.ldsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/elf_efi.ldsi b/lib/efi_loader/elf_efi.ldsi
index 190a88fb69e..4fa5ca43872 100644
--- a/lib/efi_loader/elf_efi.ldsi
+++ b/lib/efi_loader/elf_efi.ldsi
@@ -21,10 +21,10 @@ SECTIONS
*(.gnu.linkonce.t.*)
*(.srodata)
*(.rodata*)
- . = ALIGN(16);
- *(.dynamic);
- . = ALIGN(512);
}
+ . = ALIGN(16);
+ .dynamic : { *(.dynamic) }
+ . = ALIGN(512);
.rela.dyn : { *(.rela.dyn) }
.rela.plt : { *(.rela.plt) }
.rela.got : { *(.rela.got) }
[PATCH v9 6/8] blkmap: store type of blkmap slice in corresponding structure
Add information about the type of blkmap slices as an attribute in the
corresponding slice structure. Put information in the blkmap slice
structure to identify if it is associated with a memory or linear
mapped device. Which can then be used to take specific action based on
the type of the blkmap slice.
Signed-off-by: Sughosh Ganu
Reviewed-by: Tobias Waldekranz
Reviewed-by: Ilias Apalodimas
---
Changes since V8:
* s/blkmap slice/blkmap slices/ in the commit message
* Add comments to the macros added in the patch
drivers/block/blkmap.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
index 34eed1380dc..08f68570224 100644
--- a/drivers/block/blkmap.c
+++ b/drivers/block/blkmap.c
@@ -16,6 +16,22 @@
struct blkmap;
+/**
+ * define BLKMAP_SLICE_LINEAR - Linear mapping to another block device
+ *
+ * This blkmap slice type is used for mapping to other existing block
+ * devices.
+ */
+#define BLKMAP_SLICE_LINEARBIT(0)
+
+/**
+ * define BLKMAP_SLICE_MEM - Linear mapping to memory based block device
+ *
+ * This blkmap slice type is used for mapping to memory based block
+ * devices, like ramdisks.
+ */
+#define BLKMAP_SLICE_MEM BIT(1)
+
/**
* struct blkmap_slice - Region mapped to a blkmap
*
@@ -25,12 +41,14 @@ struct blkmap;
* @node: List node used to associate this slice with a blkmap
* @blknr: Start block number of the mapping
* @blkcnt: Number of blocks covered by this mapping
+ * @attr: Attributes of blkmap slice
*/
struct blkmap_slice {
struct list_head node;
lbaint_t blknr;
lbaint_t blkcnt;
+ uint attr;
/**
* @read: - Read from slice
@@ -169,6 +187,7 @@ int blkmap_map_linear(struct udevice *dev, lbaint_t blknr,
lbaint_t blkcnt,
.slice = {
.blknr = blknr,
.blkcnt = blkcnt,
+ .attr = BLKMAP_SLICE_LINEAR,
.read = blkmap_linear_read,
.write = blkmap_linear_write,
@@ -248,6 +267,7 @@ int __blkmap_map_mem(struct udevice *dev, lbaint_t blknr,
lbaint_t blkcnt,
.slice = {
.blknr = blknr,
.blkcnt = blkcnt,
+ .attr = BLKMAP_SLICE_MEM,
.read = blkmap_mem_read,
.write = blkmap_mem_write,
--
2.34.1
Re: [PATCH v2 11/15] arm: riscv: efi: Export _start symbol from crt0_*_efi stubs
On 3/15/25 23:18, Sam Edwards wrote:
While the _start label is only intended for use locally to populate the
(hand-written) PE header, the linker script includes ENTRY(_start) which
designates it as the entry point in the output ELF, resulting in linker
warnings under some linkers (e.g. LLVM's lld) due to _start not being a
globally-visible symbol. Since ELF is only an intermediary build
format, and the aforementioned PE header correctly points to _start, the
ENTRY(_start) directive could easily be removed to silence this warning.
However, since some developers who are debugging EFI by analyzing the
intermediary ELF may appreciate having correct entry-point information,
this patch instead promotes the _start labels to global symbols,
silencing the linker warning and making the intermediary ELF reflect the
true entry point.
This patch doesn't affect the final output binaries in any way.
Signed-off-by: Sam Edwards
Reviewed-by: Heinrich Schuchardt
---
arch/arm/lib/crt0_aarch64_efi.S | 1 +
arch/arm/lib/crt0_arm_efi.S | 1 +
arch/riscv/lib/crt0_riscv_efi.S | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/arm/lib/crt0_aarch64_efi.S b/arch/arm/lib/crt0_aarch64_efi.S
index e21b54fdbcb..003d5f83041 100644
--- a/arch/arm/lib/crt0_aarch64_efi.S
+++ b/arch/arm/lib/crt0_aarch64_efi.S
@@ -144,6 +144,7 @@ section_table:
IMAGE_SCN_CNT_INITIALIZED_DATA)
.align 12
+ .globl _start
_start:
stp x29, x30, [sp, #-32]!
mov x29, sp
diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S
index 235b3a0c48f..593ee1e194a 100644
--- a/arch/arm/lib/crt0_arm_efi.S
+++ b/arch/arm/lib/crt0_arm_efi.S
@@ -143,6 +143,7 @@ section_table:
IMAGE_SCN_CNT_INITIALIZED_DATA)
.align 12
+ .globl _start
_start:
stmfd sp!, {r0-r2, lr}
diff --git a/arch/riscv/lib/crt0_riscv_efi.S b/arch/riscv/lib/crt0_riscv_efi.S
index 9eacbe4a859..f170e4b26d6 100644
--- a/arch/riscv/lib/crt0_riscv_efi.S
+++ b/arch/riscv/lib/crt0_riscv_efi.S
@@ -179,6 +179,7 @@ section_table:
IMAGE_SCN_CNT_INITIALIZED_DATA)
.align 12
+ .globl _start
_start:
addisp, sp, -(SIZE_LONG * 3)
SAVE_LONG(a0, 0)
Re: [RFC PATCH 1/4] cmd: fuse: Remove custom string functions
On 14/03/25 19:39, Tom Rini wrote:
On Fri, Mar 14, 2025 at 07:13:19PM +0530, Harsha Vardhan V M wrote:
On 13/03/25 21:45, Tom Rini wrote:
On Thu, Mar 13, 2025 at 05:25:14PM +0530, Harsha Vardhan V M wrote:
Remove custom string functions and replace them with normal string
functions. Remove the custom strtou32 and replace it with str2long.
Signed-off-by: Harsha Vardhan V M
Thanks for doing this.
---
cmd/fuse.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/cmd/fuse.c b/cmd/fuse.c
index 598ef496a43..9f489570634 100644
--- a/cmd/fuse.c
+++ b/cmd/fuse.c
@@ -15,17 +15,6 @@
#include
#include
-static int strtou32(const char *str, unsigned int base, u32 *result)
-{
- char *ep;
-
- *result = simple_strtoul(str, &ep, base);
- if (ep == str || *ep != '\0')
- return -EINVAL;
-
- return 0;
-}
-
static int confirm_prog(void)
{
puts("Warning: Programming fuses is an irreversible operation!\n"
@@ -54,14 +43,14 @@ static int do_fuse(struct cmd_tbl *cmdtp, int flag, int
argc,
argc -= 2 + confirmed;
argv += 2 + confirmed;
- if (argc < 2 || strtou32(argv[0], 0, &bank) ||
- strtou32(argv[1], 0, &word))
+ if (argc < 2 || !(str2long(argv[0], (ulong *)&bank)) ||
+ !(str2long(argv[1], (ulong *)&word)))
I didn't know we had "str2long" which is a differently rarely used
function. Why not just simple_strtoul inline? Am I missing something?
Thanks.
We cannot use simple_strtoul inline directly because we need proper error
checking to ensure the simple_strtoul conversion was successful. The
str2long function is a wrapper around simple_strtoul and the necessary error
checks. Hence, using str2long here.
Thanks.
I'm sorry I'm still not getting it. We virtually never call str2long. I
was taking a quick look at why if anything the 4 callers in the entire
tree today have more special error checking requirements than every
other command which parses user input.
Hi Tom,
I tried to retain the error checking done by the custom strtou32
function, hence replaced the custom strtou32 function with str2long. I
did notice that in some other files in the cmd/ directory,
simple_strtoul is used inline with NULL as the endp parameter, like
this: simple_strtoul(argv[2], NULL, 16).
Do I proceed with replacing the custom strtou32 function with
simple_strtoul inline by passing NULL as the endp parameter, similar to
the example above? Please let me know if you have an alternative suggestion.
Thanks,
Harsha
Re: [PATCH v1] MAINTAINERS: Add USB driver file to visionfive2 maintain files.
On 3/17/25 12:36 PM, Minda Chen wrote: Add USB related file to Starfive visionfive2 MAINTAINERS. The N: pattern can override this. Signed-off-by: Minda Chen --- board/starfive/visionfive2/MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/board/starfive/visionfive2/MAINTAINERS b/board/starfive/visionfive2/MAINTAINERS index 898e284ce2c..f1d2deb9f5c 100644 --- a/board/starfive/visionfive2/MAINTAINERS +++ b/board/starfive/visionfive2/MAINTAINERS @@ -3,5 +3,6 @@ M: Minda Chen M:Hal Feng S:Maintained F:drivers/ram/starfive/ +F: drivers/usb/cdns3/cdns3-starfive.c What about using 'N: starfive' instead to match on all files which include the string 'starfive' ? N:jh7110 N:visionfive2
Re: [PATCH 0/6] MSM8916: Bring secondary cores online with spin-table
Hi Sam, Can you re-send this without all the prerequisite-patch-id tags? b4 is desperately trying to apply ~140 patches from some old next branch to my tree and tbh im not sure how to make it stop. Kind regards, On 1/27/25 23:02, Sam Day wrote: This patch series depends on the "mach-snapdragon: handle platforms without PSCI support" patch that was submitted earlier today. That first patch lays some groundwork to handle detecting when a device is booting without PSCI and deletes the /psci node in that case. This series builds on top of that detection by rewriting all CPUs with enable-method="psci" to "spin-table". Once this is done, the existing spin-table support in U-Boot handles further patching the nodes with the appropriate cpu-release-addr and reserving the memory with the spin-table instructions. Interestingly, this spin-table code doesn't seem to be in active use anywhere, and it had bitrotted a little. But after blowing the dust off it and fixing a couple of missing #includes, it works great. I extended the spin-table support a little to make it easier for consumers to plug in a method that is called for each CPU that needs to be brought online. This saves the qcom board code from needing to hook into ft_board_setup or something that runs before booting the OS. Signed-off-by: Sam Day --- Sam Day (6): armv8: spin_table: Fix missing includes armv8: spin_table: add hook for booting cores mach-snapdragon: qcom SCM call support mach-snapdragon: fixup CPUs with PSCI enable-method mach-snapdragon: MSM8916 spin-table CPU boot support qcom_defconfig: enable spin-table support arch/arm/cpu/armv8/spin_table.c| 10 ++ arch/arm/include/asm/spin_table.h | 3 + arch/arm/mach-snapdragon/Makefile | 2 + arch/arm/mach-snapdragon/board.c | 41 arch/arm/mach-snapdragon/msm8916-smp.c | 135 +++ arch/arm/mach-snapdragon/qcom-scm.c| 145 + arch/arm/mach-snapdragon/qcom-scm.h| 165 + configs/qcom_defconfig | 2 + 8 files changed, 503 insertions(+) --- base-commit: 2eed5a1ff36217372e19f7513bd07077fc76718a change-id: 20250127-msm8916-smp-support-5f5e7b49d07e prerequisite-change-id: 20250127-qcom-handle-absent-psci-6e8e8af7bcd7:v1 prerequisite-patch-id: 6f85e145b7a25346a286396d9edf6106ae131c0b prerequisite-patch-id: 3b11763ea1d10ae9e23cb5c1b888f02220919284 prerequisite-patch-id: 030300d29b72f14fc528f2ad46c0d9e229934e9e prerequisite-patch-id: de0427537d887654f8dbf2e97ca6a3bc956512cd prerequisite-patch-id: 30db99afc91f657e484d4bb5a6613b64fb77649b prerequisite-patch-id: b1c46de57d0f82756d2bbeee6d13cf31c1f27a0f prerequisite-patch-id: 2d7d38f6ea846a5f183462d07ff962182e20a87e prerequisite-patch-id: 76ce7f79c8f4e2a5042dc8804194b0bef2d0a24b prerequisite-patch-id: 05eac938e6d33019a091ee721eba2d2dc7a03960 prerequisite-patch-id: 243fe8829719909ab6d65b512b0efcff4f4c9438 prerequisite-patch-id: fb7780ba617c036bc3b4e8fbc53541d485ae89d8 prerequisite-patch-id: 16e2a268f01739da59598b5f5b0d86a80c31449f prerequisite-patch-id: 43e1512fd0768b763cdf2079dce0054a736e97ea prerequisite-patch-id: 02cffb68f48d9d64c26373d6366c82bfcb86a7a2 prerequisite-patch-id: 19f382ead12fd5f583ad8b82fe618e6dd2c59615 prerequisite-patch-id: 764cc2a29ae7486610b6279cd71bedfb267f18bd prerequisite-patch-id: e22fa6b807a5df8e0257636a3edf8de92d4b3a36 prerequisite-patch-id: 159efbb7a5bd037b11eb20993716bdc7e641c89f prerequisite-patch-id: 0c4373ed5bda9e74a488796de8ce2e0c59c62c46 prerequisite-patch-id: fb2e81bbe11eed5d7af8ac4b1c2a29e2bdb6b237 prerequisite-patch-id: b105b1ec3f2ab8d9ad212eacf3a4736417950930 prerequisite-patch-id: 302c34fd65875a4a750a5a36b933e43639859487 prerequisite-patch-id: b1b62ac7e28eb0cc8a66d529911d6294b40cc5cd prerequisite-patch-id: 43de5453463d592c16d5669345528ded4e897605 prerequisite-patch-id: 861de3de3e008cfffcbcbfdd25c5bf1cdd9925ea prerequisite-patch-id: c91bbc83ea9d167f2451c7e9a13692c4cc92d1cb prerequisite-patch-id: cf9a09214da66d4bb1175b40a4e49c98212aaae3 prerequisite-patch-id: 671819fe6f2c93b420fec5ee283149d8e51a4f1c prerequisite-patch-id: 02a9a32547b5e850d27ada3bed7e88b4c970d342 prerequisite-patch-id: cb7baa3ce35948742a83d9b4acb7449f660818a6 prerequisite-patch-id: 9dd97eb36b380b64b43fb6718075106e1f4186c5 prerequisite-patch-id: c9ef7bfbbcf3a55a821dac749236440ae10fc89c prerequisite-patch-id: d37f02b2f520d3a84e5b4a515f88d217f78841ee prerequisite-patch-id: ad99b38cc1326272ec03e7cdced069e76b850d59 prerequisite-patch-id: b7467e24f0a21c08a52008374e18d3af996e0668 prerequisite-patch-id: a7d97af191a6adfb55af0fd89bdb97c378f86f65 prerequisite-patch-id: 87de3dd294acc2a220d97142bd615bdcd01fb00b prerequisite-patch-id: 5f2a37841670e9b941dce8f8b28c3e7e6c6048f6 prerequisite-patch-id: 5a77c17b8b78e760cd9bd4982d564fdb60ba667e prerequisite-patch-id: afa8a5a8572452ff8ac2f0dac1fc132fc5423150 prerequisite-patch-id: d68ce45f8993ba7c6967c28c25abdbc0f78a2cb3 prerequis
Re: [PATCH 2/3] misc: introduce Qcom GENI wrapper
On 14/03/2025 17:09, Caleb Connolly wrote:
Qualcomm peripherals like UART, SPI, I2C, etc are all exposed under a
common GENI Serial Engine wrapper device. Replace the stub driver we use
for this currently with a full-on misc device and implement support for
loading peripheral firmware.
Each of the peripherals has it's own protocol-specific firmware, this is
stored on the internal storage of the device with a well-known partition
type GUID.
To support this, GENI will bind peripherals in two stages. First the
ones that already have firmware loaded (such as the serial port) are
bound in the typical way. But devices that require firmware loading are
deferred until EVT_LAST_STAGE_INIT. At this point we can be sure that
the storage device is available, so we load the firmware and then bind
and probe the remaining children.
Child devices are expected to determine if firmware loading is necessary
and call qcom_geni_load_firmware().
Since Linux currently doesn't support loading firmware (and firmware may
not be available), we probe all GENI peripherals to ensure that they
always load firmwaree if necessary.
-/\ firmwares
Hmm binding all QUP serial engines seems quite brutal, and this is really
only needed when fws are not loaded by previous bootloader.
Apart this, the design looks good :-)
Signed-off-by: Caleb Connolly
---
arch/arm/Kconfig | 1 +
drivers/misc/Kconfig | 9 +
drivers/misc/Makefile| 1 +
drivers/misc/qcom_geni.c | 576 +++
drivers/serial/serial_msm_geni.c | 13 -
include/soc/qcom/geni-se.h | 36 +++
include/soc/qcom/qup-fw-load.h | 178
7 files changed, 801 insertions(+), 13 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index
cf08fe63f1e7dc73480b2ba0b707a7e891073d53..6149f284596641689407e076af5ad020176bd7dc
100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1116,8 +1116,9 @@ config ARCH_SNAPDRAGON
select BOARD_LATE_INIT
select OF_BOARD
select SAVE_PREV_BL_FDT_ADDR
select LINUX_KERNEL_IMAGE_HEADER if !ENABLE_ARM_SOC_BOOT0_HOOK
+ select QCOM_GENI
imply OF_UPSTREAM
imply CMD_DM
config ARCH_SOCFPGA
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index
da84b35e8043bcef71ce78e03d1da2c445bf3af5..415832c73e2cb5a85ae8378977d597e5aedb5fb8
100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -82,8 +82,17 @@ config GATEWORKS_SC
Enable access for the Gateworks System Controller used on Gateworks
boards to provide a boot watchdog, power control, temperature monitor,
voltage ADCs, and EEPROM.
+config QCOM_GENI
+ bool "Qualcomm Generic Interface (GENI) driver"
+ depends on MISC
+ select PARTITION_TYPE_GUID
+ help
+ Enable support for Qualcomm GENI and it's peripherals. GENI is
responseible
-/\
responsible
+ for providing a common interface for various peripherals like UART,
I2C, SPI,
+ etc.
+
config ROCKCHIP_EFUSE
bool "Rockchip e-fuse support"
depends on MISC
help
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index
dac805e4cdd48a8127f37d68d9fb5ba0bd17ab15..6866edbd8119268c0cc03abdc8529bd191f1c2d8
100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -67,8 +67,9 @@ obj-$(CONFIG_QFW_PIO) += qfw_pio.o
obj-$(CONFIG_QFW_MMIO) += qfw_mmio.o
obj-$(CONFIG_QFW_SMBIOS) += qfw_smbios.o
obj-$(CONFIG_SANDBOX) += qfw_sandbox.o
endif
+obj-$(CONFIG_QCOM_GENI) += qcom_geni.o
obj-$(CONFIG_$(PHASE_)ROCKCHIP_EFUSE) += rockchip-efuse.o
obj-$(CONFIG_$(PHASE_)ROCKCHIP_OTP) += rockchip-otp.o
obj-$(CONFIG_$(PHASE_)ROCKCHIP_IODOMAIN) += rockchip-io-domain.o
obj-$(CONFIG_SANDBOX) += syscon_sandbox.o misc_sandbox.o
diff --git a/drivers/misc/qcom_geni.c b/drivers/misc/qcom_geni.c
new file mode 100644
index
..2b652765aa310b5a21d4aa99b50842c2e17e5942
--- /dev/null
+++ b/drivers/misc/qcom_geni.c
@@ -0,0 +1,576 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ * Copyright (c) 2025, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct qup_se_rsc {
+ phys_addr_t base;
+ phys_addr_t wrapper_base;
+ struct udevice *dev;
+
+ enum geni_se_xfer_mode mode;
+ enum geni_se_protocol_type protocol;
+};
+
+struct geni_se_plat {
+ bool need_firmware_load;
+};
+
+/**
+ * geni_enable_interrupts() Enable interrupts.
+ * @rsc: Pointer to a structure representing SE-related resources.
+ *
+ * Enable the required interrupts during the firmware load process.
+ *
+ * Return: None.
+ */
+static voi
Re: [PATCH 3/3] i2c: geni: load firmware if required
On 14/03/2025 17:09, Caleb Connolly wrote:
Load firmware for the peripheral if necessary.
Signed-off-by: Caleb Connolly
---
drivers/i2c/geni_i2c.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/i2c/geni_i2c.c b/drivers/i2c/geni_i2c.c
index
4eb41ba852f7790ca646c8ba38f29fdb727fa804..fca0fab7201a2f86ff4a8c12d053297e660c4621
100644
--- a/drivers/i2c/geni_i2c.c
+++ b/drivers/i2c/geni_i2c.c
@@ -21,8 +21,9 @@
#include
#include
#include
#include
+#include
#define SE_I2C_TX_TRANS_LEN 0x26c
#define SE_I2C_RX_TRANS_LEN 0x270
#define SE_I2C_SCL_COUNTERS 0x278
@@ -498,8 +499,15 @@ static int geni_i2c_probe(struct udevice *dev)
proto = readl(geni->base + GENI_FW_REVISION_RO);
proto &= FW_REV_PROTOCOL_MSK;
proto >>= FW_REV_PROTOCOL_SHFT;
+ if (proto == 0xff) {
GENI_SE_INVALID_PROTO
+ qcom_geni_load_firmware(geni->base, dev);
+ proto = readl(geni->base + GENI_FW_REVISION_RO);
+ proto &= FW_REV_PROTOCOL_MSK;
+ proto >>= FW_REV_PROTOCOL_SHFT;
+ }
+
if (proto != GENI_SE_I2C) {
dev_err(dev, "Invalid proto %d\n", proto);
geni_i2c_disable_clocks(dev, geni);
return -ENXIO;
Reviewed-by: Neil Armstrong
Re: [PATCH v5 0/7] Add initial support for IPQ9574 based boards
On Tue, 25 Feb 2025 12:22:56 +0530, Varadarajan Narayanan wrote: > These patches introduce the initial support code needed > for the QTI IPQ9574 SoC and RDP433 board. > > SoC : Qualcomm IPQ9574 > RAM : 2GB DDR4 > Flash : eMMC 8GB > WiFi: 1 x 2.4GHz, 1 x 5GHz, 1 x 6GHz > > [...] Applied, thanks! [1/7] doc: board/qualcomm: document RDP building/flashing https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/a4c8912608ef [2/7] dts: ipq9574-rdp433-u-boot: add override dtsi https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/25edbbf7fde8 [3/7] clk/qcom: add initial clock driver for ipq9574 https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/ad3e8a2f59e7 [4/7] pinctrl: qcom: Handle get_function_mux failure https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/6ec61fd46222 [5/7] pinctrl: qcom: Add ipq9574 pinctrl driver https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/1b734e019048 [6/7] mmc: msm_sdhci: Reset clocks before reconfiguration https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/5bff42afd1c0 [7/7] configs: add qcom_ipq9574_mmc_defconfig https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/3c5a192a0530 Best regards, -- Caleb Connolly
Re: [PATCH v3] mach-snapdragon: support parsing memory info from external FDT
On Thu, 23 Jan 2025 12:12:14 +, Sam Day wrote: > qcom_parse_memory is updated to return a -ENODATA error if the passed > FDT does not contain a /memory node, or that node is incomplete (size=0) > > board_fdt_blob_setup first tries to call qcom_parse_memory with the > internal FDT (if present+valid). If that fails, it tries again with the > external FDT (again, if present+valid). > > [...] Applied, thanks! [1/1] mach-snapdragon: support parsing memory info from external FDT https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/11ff5a57e2fb Best regards, -- Caleb Connolly
Re: [PATCH] pinctrl/qcom: fix kconfig option names
On Mon, 17 Mar 2025 13:25:14 +, Caleb Connolly wrote: > A copy-paste error is starting to get out of hand... Fix all these so > they don't look like clock drivers in menuconfig. > > Applied, thanks! [1/1] pinctrl/qcom: fix kconfig option names https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/364f6610278d Best regards, -- Caleb Connolly
Re: [PATCH 0/3] qcom: MSM8916 sysreset support
On Sat, 25 Jan 2025 19:59:11 +, Sam Day wrote: > Most MSM8916 devices shipped without PSCI support in their TZ firmware. > Instead, they use PSHOLD. These patches enable both PSCI and PSHOLD > sysreset drivers in qcom_defconfig. > > Caleb had already submitted ([1]) a patch to do the switch to PSCI > sysreset driver as part of the UEFI capsule update series, but it seems > that the sysreset patch didn't make it upstream. > > [...] Applied, thanks! [1/3] mach-snapdragon: use PSCI sysreset driver https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/61a1a1b8ca73 [2/3] sysreset: qcom-pshold: remove ARCH_IPQ40XX dependency https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/11c7187253df [3/3] qcom_defconfig: enable SYSRESET_QCOM_PSHOLD https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/904379210985 Best regards, -- Caleb Connolly
Re: [PATCH 0/2] Snapdragon SC7280 pinctrl
On Wed, 22 Jan 2025 16:02:50 +0100, Caleb Connolly wrote: > Introduce and enable pinctrl support for SC7280 and QCM6490, similarly > to other platforms. > > This was missed during RB3 Gen 2 bringup. > Applied, thanks! [1/2] pinctrl: qcom: add sc7280 pinctrl driver https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/51ec7fdb64b3 [2/2] qcom_defconfig: enable PINCTRL_QCOM_SC7280 https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/77f0638576a0 Best regards, -- Caleb Connolly
Re: [PATCH 0/6] MSM8916: Bring secondary cores online with spin-table
On 3/17/25 13:45, Tom Rini wrote: On Mon, Mar 17, 2025 at 01:13:22PM +, Caleb Connolly wrote: Hi Sam, Can you re-send this without all the prerequisite-patch-id tags? b4 is desperately trying to apply ~140 patches from some old next branch to my tree and tbh im not sure how to make it stop. You can use --merge-base HEAD to override that I think. If not I think it's worth asking to...@kernel.org because that sounds like a bug to me. I think Sam had a bunch of big series pulled in for some reason, the bug is listing them all as prerequisite patches imo -- Caleb (they/them)
Re: [RFC PATCH 1/4] cmd: fuse: Remove custom string functions
On Mon, Mar 17, 2025 at 02:29:39PM +0530, Harsha Vardhan V M wrote:
>
>
> On 14/03/25 19:39, Tom Rini wrote:
> > On Fri, Mar 14, 2025 at 07:13:19PM +0530, Harsha Vardhan V M wrote:
> > >
> > >
> > > On 13/03/25 21:45, Tom Rini wrote:
> > > > On Thu, Mar 13, 2025 at 05:25:14PM +0530, Harsha Vardhan V M wrote:
> > > >
> > > > > Remove custom string functions and replace them with normal string
> > > > > functions. Remove the custom strtou32 and replace it with str2long.
> > > > >
> > > > > Signed-off-by: Harsha Vardhan V M
> > > >
> > > > Thanks for doing this.
> > > >
> > > > > ---
> > > > >cmd/fuse.c | 27 ---
> > > > >1 file changed, 8 insertions(+), 19 deletions(-)
> > > > >
> > > > > diff --git a/cmd/fuse.c b/cmd/fuse.c
> > > > > index 598ef496a43..9f489570634 100644
> > > > > --- a/cmd/fuse.c
> > > > > +++ b/cmd/fuse.c
> > > > > @@ -15,17 +15,6 @@
> > > > >#include
> > > > >#include
> > > > > -static int strtou32(const char *str, unsigned int base, u32 *result)
> > > > > -{
> > > > > - char *ep;
> > > > > -
> > > > > - *result = simple_strtoul(str, &ep, base);
> > > > > - if (ep == str || *ep != '\0')
> > > > > - return -EINVAL;
> > > > > -
> > > > > - return 0;
> > > > > -}
> > > > > -
> > > > >static int confirm_prog(void)
> > > > >{
> > > > > puts("Warning: Programming fuses is an irreversible
> > > > > operation!\n"
> > > > > @@ -54,14 +43,14 @@ static int do_fuse(struct cmd_tbl *cmdtp, int
> > > > > flag, int argc,
> > > > > argc -= 2 + confirmed;
> > > > > argv += 2 + confirmed;
> > > > > - if (argc < 2 || strtou32(argv[0], 0, &bank) ||
> > > > > - strtou32(argv[1], 0, &word))
> > > > > + if (argc < 2 || !(str2long(argv[0], (ulong *)&bank)) ||
> > > > > + !(str2long(argv[1], (ulong *)&word)))
> > > >
> > > > I didn't know we had "str2long" which is a differently rarely used
> > > > function. Why not just simple_strtoul inline? Am I missing something?
> > > > Thanks.
> > >
> > > We cannot use simple_strtoul inline directly because we need proper error
> > > checking to ensure the simple_strtoul conversion was successful. The
> > > str2long function is a wrapper around simple_strtoul and the necessary
> > > error
> > > checks. Hence, using str2long here.
> > > Thanks.
> >
> > I'm sorry I'm still not getting it. We virtually never call str2long. I
> > was taking a quick look at why if anything the 4 callers in the entire
> > tree today have more special error checking requirements than every
> > other command which parses user input.
> >
>
> Hi Tom,
> I tried to retain the error checking done by the custom strtou32 function,
> hence replaced the custom strtou32 function with str2long. I did notice that
> in some other files in the cmd/ directory, simple_strtoul is used inline
> with NULL as the endp parameter, like this: simple_strtoul(argv[2], NULL,
> 16).
>
> Do I proceed with replacing the custom strtou32 function with simple_strtoul
> inline by passing NULL as the endp parameter, similar to the example above?
Yes, that would be good, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v6 0/7] Add initial support for IPQ9574 based boards
On Wed, 26 Feb 2025 12:14:58 +0530, Varadarajan Narayanan wrote: > These patches introduce the initial support code needed > for the QTI IPQ9574 SoC and RDP433 board. > > SoC : Qualcomm IPQ9574 > RAM : 2GB DDR4 > Flash : eMMC 8GB > WiFi: 1 x 2.4GHz, 1 x 5GHz, 1 x 6GHz > > [...] Applied, thanks! [1/7] doc: board/qualcomm: document RDP building/flashing https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/a4c8912608ef [2/7] dts: ipq9574-rdp433-u-boot: add override dtsi https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/25edbbf7fde8 [3/7] clk/qcom: add initial clock driver for ipq9574 https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/ad3e8a2f59e7 [4/7] pinctrl: qcom: Handle get_function_mux failure https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/6ec61fd46222 [5/7] pinctrl: qcom: Add ipq9574 pinctrl driver https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/1b734e019048 [6/7] mmc: msm_sdhci: Reset clocks before reconfiguration https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/5bff42afd1c0 [7/7] configs: add qcom_ipq9574_mmc_defconfig https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/3c5a192a0530 Best regards, -- Caleb Connolly
Re: [PATCH 2/2] clk/qcom: sc7280: add missing UFS and MMC clocks
On 17/03/2025 17:15, Caleb Connolly wrote:
These are all usually enabled, hence we don't (yet) bother configuring
their RCG src clocks.
Add them to remove the errors about missing clocks when the UFS and MMC
drivers probe.
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-sc7280.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/qcom/clock-sc7280.c b/drivers/clk/qcom/clock-sc7280.c
index
8691f08109b39639d8a5defe75161049399bf682..9aff8a847ad1bd59b7ec7246f5719e4d7c32ec65
100644
--- a/drivers/clk/qcom/clock-sc7280.c
+++ b/drivers/clk/qcom/clock-sc7280.c
@@ -106,8 +106,19 @@ static const struct gate_clk sc7280_clks[] = {
GATE_CLK(GCC_AGGRE_NOC_PCIE_CENTER_SF_AXI_CLK, 0x52008, BIT(28)),
GATE_CLK(GCC_QUPV3_WRAP0_S0_CLK, 0x52008, BIT(10)),
GATE_CLK(GCC_QUPV3_WRAP0_S1_CLK, 0x52008, BIT(11)),
GATE_CLK(GCC_QUPV3_WRAP0_S3_CLK, 0x52008, BIT(13)),
+ GATE_CLK(GCC_UFS_PHY_AXI_CLK, 0x77010, BIT(0)),
+ GATE_CLK(GCC_AGGRE_UFS_PHY_AXI_CLK, 0x770cc, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_AHB_CLK, 0x77018, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_UNIPRO_CORE_CLK, 0x7705c, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_PHY_AUX_CLK, 0x7709c, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_TX_SYMBOL_0_CLK, 0x7701c, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_RX_SYMBOL_0_CLK, 0x77020, BIT(0)),
+ GATE_CLK(GCC_UFS_PHY_RX_SYMBOL_1_CLK, 0x770b8, BIT(0)),
+ GATE_CLK(GCC_UFS_1_CLKREF_EN, 0x8c000, BIT(0)),
+ GATE_CLK(GCC_SDCC2_AHB_CLK, 0x14008, BIT(0)),
+ GATE_CLK(GCC_SDCC2_APPS_CLK, 0x14004, BIT(0)),
};
static int sc7280_enable(struct clk *clk)
{
Reviewed-by: Neil Armstrong
Re: [PATCH v2 0/6] Add initial support for IPQ9574 based boards
On Thu, 30 Jan 2025 11:07:45 +0530, Varadarajan Narayanan wrote: > These patches introduce the initial support code needed > for the QTI IPQ9574 SoC and RDP433 board. > > SoC : Qualcomm IPQ9574 > RAM : 2GB DDR4 > Flash : eMMC 8GB > WiFi: 1 x 2.4GHz, 1 x 5GHz, 1 x 6GHz > > [...] Applied, thanks! [1/6] dts: ipq9574-rdp433-u-boot: add override dtsi https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/25edbbf7fde8 [2/6] clk/qcom: add initial clock driver for ipq9574 https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/ad3e8a2f59e7 [3/6] pinctrl: qcom: Add ipq9574 pinctrl driver https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/1b734e019048 [4/6] mmc: msm_sdhci: Reset clocks before reconfiguration https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/5bff42afd1c0 [5/6] qcom_defconfig: enable ipq9574 clock & pinctrl driver (no commit info) [6/6] configs: add ipq9574_mmc_defconfig (no commit info) Best regards, -- Caleb Connolly
Re: [PATCH v7 0/8] Add Starfive JH7110 Cadence USB driver
On 3/6/25 7:20 AM, Minda Chen wrote: Add Starfive JH7110 Cadence USB driver and related PHY driver. So the codes can be used in visionfive2 and star64 7110 board. The driver is almost the same with kernel driver. Test with Star64 JH7110 board USB 3.0 + USB 2.0 host. The code can work. The Starfive JH7110 has enable CONFIG_OF_UPSTREAM. The dts is from kernel Applied all except [PATCH v7 8/8] MAINTAINERS: Update Starfive visionfive2 maintain files. Can you please rebase the "MAINTAINERS: Update Starfive visionfive2 maintain files." and send it separately ? I already sent USB PR, you were on CC, so you should see the 1/8..7/8 patches are already on their way to u-boot/master . Sorry for the abysmal delay in replies on my side.
Re: [PATCH v5 07/46] x86: Drop mpspec from the SPL build
On Sat, Mar 15, 2025 at 02:25:27PM +, Simon Glass wrote: > This is not needed in SPL, so drop it. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/lib/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile > index 43e6a1de77d..a908356e8a6 100644 > --- a/arch/x86/lib/Makefile > +++ b/arch/x86/lib/Makefile > @@ -26,7 +26,9 @@ obj-y += e820.o > obj-y+= init_helpers.o > obj-y+= interrupts.o > obj-y+= lpc-uclass.o > +ifndef CONFIG_XPL_BUILD > obj-y+= mpspec.o > +endif > obj-$(CONFIG_$(PHASE_)ACPIGEN) += acpi_nhlt.o > obj-y+= northbridge-uclass.o > obj-$(CONFIG_I8259_PIC) += i8259.o What's going on? This should be discarded if unused in SPL automatically. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 09/46] x86: Drop use of CONFIG_REALMODE_DEBUG
On Sat, Mar 15, 2025 at 02:25:29PM +, Simon Glass wrote: > This option is not actually defined in Kconfig anymore. Use a normal > debug print instead, which has a similar effect. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 6/6] configs: add qcom_ipq5424_mmc_defconfig
On 3/12/25 08:51, Varadarajan Narayanan wrote: On Tue, Mar 11, 2025 at 03:27:25PM +, Caleb Connolly wrote: Hi Varadarajan, Thanks for the series, and apologies for the slow reply, i've been out sick and still finding my feet again. Oops. Sorry to have troubled you. no worries :D On 3/4/25 11:01, Varadarajan Narayanan wrote: Introduce a defconfig for the Qualcomm IPQ5424 SoC based RDPs. Presently supports eMMC. Per the flash memory layout, U-Boot size cannot exceed 756KB. With this defconfig, u-boot.mbn size is ~480KB. What are the differences between this and the other new IPQ platform? Can they share a defconfig? They are very similar. At this point, CONFIG_DEFAULT_DEVICE_TREE, CONFIG_CLK_QCOM_xxx, CONFIG_PINCTRL_QCOM_xxx, CONFIG_DEBUG_UART_xxx and memory map are different. Alternatively, could most of the things here be de-duplicated so there is a "base" config which they both #include (similarly to qcm6490_defconfig) this way we can nicely keep track of what parts of board specific. If you'd prefer to keep it this way that's fine too. Would having an ipq_defconfig and including that in ipq9574 and ipq5424 defconfigs be a good approach? No, I don't think so since every defconfig needs to build, and that one would be missing options. You could have one board inherit from another? Perhaps it makes sense to just keep things as-is. Kind regards, Should I be expecting more platforms like this? Yes. Thanks Varada [ . . . ] -- Caleb (they/them)
Re: [PATCH 2/3] clk/qcom: sc7280: add some debug data
On 14/03/2025 16:31, Caleb Connolly wrote:
Dump a few PCIe and USB clocks
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-sc7280.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/clk/qcom/clock-sc7280.c b/drivers/clk/qcom/clock-sc7280.c
index
8ffd1f43f23e51140c7822f0f523fdfd8ab1de7a..2cbc01b6e0a4f1db0e4a894cd869b532d6b3fa45
100644
--- a/drivers/clk/qcom/clock-sc7280.c
+++ b/drivers/clk/qcom/clock-sc7280.c
@@ -99,8 +99,20 @@ static const struct qcom_power_map sc7280_gdscs[] = {
[GCC_UFS_PHY_GDSC] = { 0x77004 },
[GCC_USB30_PRIM_GDSC] = { 0xf004 },
};
+static const phys_addr_t sc7280_rcg_addrs[] = {
+ 0x10f020, // USB30_PRIM_MASTER_CLK_CMD_RCGR
+ 0x10f038, // USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR
+ 0x18d058, // PCIE_1_AUX_CLK_CMD_RCGR
+};
+
+static const char *const sc7280_rcg_names[] = {
+ "USB30_PRIM_MASTER_CLK_SRC",
+ "USB30_PRIM_MOCK_UTMI_CLK_SRC",
+ "GCC_PCIE_1_AUX_CLK_SRC",
+};
+
static struct msm_clk_data qcs404_gcc_data = {
.resets = sc7280_gcc_resets,
.num_resets = ARRAY_SIZE(sc7280_gcc_resets),
.clks = sc7280_clks,
@@ -110,8 +122,12 @@ static struct msm_clk_data qcs404_gcc_data = {
.num_power_domains = ARRAY_SIZE(sc7280_gdscs),
.enable = sc7280_enable,
.set_rate = sc7280_set_rate,
+
+ .dbg_rcg_addrs = sc7280_rcg_addrs,
+ .num_rcgs = ARRAY_SIZE(sc7280_rcg_addrs),
+ .dbg_rcg_names = sc7280_rcg_names,
};
static const struct udevice_id gcc_sc7280_of_match[] = {
{
Reviewed-by: Neil Armstrong
Re: [PATCH 1/3] clk/qcom: bubble up qcom_gate_clk_en() errors
On 14/03/2025 16:31, Caleb Connolly wrote:
If we try to enable a gate clock that doesn't exist, we used to just
fail silently. This may make sense for early bringup of some core
peripherals that we know are already enabled, but it only makes
debugging missing clocks more difficult.
Bubble up errors now that qcom_gate_clk_en() can return an error code to
catch any still-missing clocks and make it easier to find missing ones
as more complicated peripherals are enabled.
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-apq8016.c | 3 +--
drivers/clk/qcom/clock-qcm2290.c | 4 +---
drivers/clk/qcom/clock-qcom.h | 12 +---
drivers/clk/qcom/clock-sa8775p.c | 4 +---
drivers/clk/qcom/clock-sc7280.c | 4 +---
drivers/clk/qcom/clock-sdm845.c | 4 +---
drivers/clk/qcom/clock-sm6115.c | 4 +---
drivers/clk/qcom/clock-sm8150.c | 4 +---
drivers/clk/qcom/clock-sm8250.c | 4 +---
drivers/clk/qcom/clock-sm8550.c | 4 +---
drivers/clk/qcom/clock-sm8650.c | 4 +---
drivers/clk/qcom/clock-x1e80100.c | 4 +---
12 files changed, 20 insertions(+), 35 deletions(-)
diff --git a/drivers/clk/qcom/clock-apq8016.c b/drivers/clk/qcom/clock-apq8016.c
index
b5def55dbc2ac671130624dec56592288a0ceb3d..3bafbfea3b6f5bf903f6f5a593e1f062bd40c53a
100644
--- a/drivers/clk/qcom/clock-apq8016.c
+++ b/drivers/clk/qcom/clock-apq8016.c
@@ -144,11 +144,10 @@ static int apq8016_clk_enable(struct clk *clk)
return 0;
}
debug("%s: clk %s\n", __func__, apq8016_clks[clk->id].name);
- qcom_gate_clk_en(priv, clk->id);
- return 0;
+ return qcom_gate_clk_en(priv, clk->id);
}
static struct msm_clk_data apq8016_clk_data = {
.set_rate = apq8016_clk_set_rate,
diff --git a/drivers/clk/qcom/clock-qcm2290.c b/drivers/clk/qcom/clock-qcm2290.c
index
c78705cb8cf19a75508f5a3a0fbc7c04d750d273..1326b770c3ebd723120de4b6657aafac726023d6
100644
--- a/drivers/clk/qcom/clock-qcm2290.c
+++ b/drivers/clk/qcom/clock-qcm2290.c
@@ -133,11 +133,9 @@ static int qcm2290_enable(struct clk *clk)
qcom_gate_clk_en(priv, GCC_USB3_PRIM_CLKREF_CLK);
break;
}
- qcom_gate_clk_en(priv, clk->id);
-
- return 0;
+ return qcom_gate_clk_en(priv, clk->id);
}
static const struct qcom_reset_map qcm2290_gcc_resets[] = {
[GCC_CAMSS_OPE_BCR] = { 0x55000 },
diff --git a/drivers/clk/qcom/clock-qcom.h b/drivers/clk/qcom/clock-qcom.h
index
ff336dea39cf5cbe35f37f93669285897ba185a4..e9eb659f3ed37522a71e04e9418f48091bf9a0aa
100644
--- a/drivers/clk/qcom/clock-qcom.h
+++ b/drivers/clk/qcom/clock-qcom.h
@@ -6,8 +6,9 @@
#define _CLOCK_QCOM_H
#include
#include
+#include
#define CFG_CLK_SRC_CXO (0 << 8)
#define CFG_CLK_SRC_GPLL0 (1 << 8)
#define CFG_CLK_SRC_GPLL0_AUX2 (2 << 8)
@@ -104,15 +105,20 @@ void clk_rcg_set_rate_mnd(phys_addr_t base, uint32_t
cmd_rcgr,
void clk_rcg_set_rate(phys_addr_t base, uint32_t cmd_rcgr, int div,
int source);
void clk_phy_mux_enable(phys_addr_t base, uint32_t cmd_rcgr, bool enabled);
-static inline void qcom_gate_clk_en(const struct msm_clk_priv *priv, unsigned long id)
+static inline int qcom_gate_clk_en(const struct msm_clk_priv *priv, unsigned
long id)
{
u32 val;
- if (id >= priv->data->num_clks || priv->data->clks[id].reg == 0)
- return;
+ if (id >= priv->data->num_clks || priv->data->clks[id].reg == 0) {
+ log_err("gcc@%#08llx: unknown clock ID %lu!\n",
+ priv->base, id);
+ return -ENOENT;
+ }
val = readl(priv->base + priv->data->clks[id].reg);
writel(val | priv->data->clks[id].en_val, priv->base +
priv->data->clks[id].reg);
+
+ return 0;
}
#endif
diff --git a/drivers/clk/qcom/clock-sa8775p.c b/drivers/clk/qcom/clock-sa8775p.c
index
e31f24ed4f0ca989f20d1eadcff5f24f173455fa..527cecf5c8282a7c2e16740e6520241a230bca73
100644
--- a/drivers/clk/qcom/clock-sa8775p.c
+++ b/drivers/clk/qcom/clock-sa8775p.c
@@ -72,11 +72,9 @@ static int sa8775p_enable(struct clk *clk)
qcom_gate_clk_en(priv, GCC_USB3_PRIM_PHY_COM_AUX_CLK);
break;
}
- qcom_gate_clk_en(priv, clk->id);
-
- return 0;
+ return qcom_gate_clk_en(priv, clk->id);
}
static const struct qcom_reset_map sa8775p_gcc_resets[] = {
[GCC_CAMERA_BCR] = { 0x32000 },
diff --git a/drivers/clk/qcom/clock-sc7280.c b/drivers/clk/qcom/clock-sc7280.c
index
5d343f120519da02d8ec3e269d348ab46cde70a8..8ffd1f43f23e51140c7822f0f523fdfd8ab1de7a
100644
--- a/drivers/clk/qcom/clock-sc7280.c
+++ b/drivers/clk/qcom/clock-sc7280.c
@@ -72,11 +72,9 @@ static int sc7280_enable(struct clk *clk)
qcom_gate_clk_en(priv, GCC_USB3_PRIM_PHY_COM_AUX_CLK);
break;
}
- qcom_gate_clk_en(priv, clk->id);
-
- return 0;
+ return qcom_gate_clk_en(priv, clk->id);
}
stati
Re: [PATCH 3/3] clk/qcom: sc7280: add GENI, PCIe, and more USB clocks
On 14/03/2025 16:31, Caleb Connolly wrote:
Add support for a bunch of new clocks, including PCIe, GENI (for all
peripherals used on the RB3 Gen 2), and some missing USB clocks.
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-sc7280.c | 104 +++-
1 file changed, 93 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/qcom/clock-sc7280.c b/drivers/clk/qcom/clock-sc7280.c
index
2cbc01b6e0a4f1db0e4a894cd869b532d6b3fa45..8691f08109b39639d8a5defe75161049399bf682
100644
--- a/drivers/clk/qcom/clock-sc7280.c
+++ b/drivers/clk/qcom/clock-sc7280.c
@@ -15,31 +15,66 @@
#include
#include "clock-qcom.h"
-#define USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR 0xf038
#define USB30_PRIM_MASTER_CLK_CMD_RCGR 0xf020
+#define USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR 0xf038
+#define USB30_SEC_MASTER_CLK_CMD_RCGR 0x9e020
+#define USB30_SEC_MOCK_UTMI_CLK_CMD_RCGR 0x9e038
+#define PCIE_1_AUX_CLK_CMD_RCGR 0x8d058
+#define PCIE1_PHY_RCHNG_CMD_RCGR 0x8d03c
+#define PCIE_1_PIPE_CLK_PHY_MUX 0x8d054
+
+static const struct freq_tbl ftbl_gcc_usb30_prim_master_clk_src[] = {
+ F(6667, CFG_CLK_SRC_GPLL0_EVEN, 4.5, 0, 0),
+ F(1, CFG_CLK_SRC_GPLL0, 4.5, 0, 0),
+ F(2, CFG_CLK_SRC_GPLL0_ODD, 1, 0, 0),
+ F(24000, CFG_CLK_SRC_GPLL0, 2.5, 0, 0),
+ { }
+};
+
+static const struct freq_tbl ftbl_gcc_usb30_sec_master_clk_src[] = {
+ F(6000, CFG_CLK_SRC_GPLL0_EVEN, 5, 0, 0),
+ F(12000, CFG_CLK_SRC_GPLL0_EVEN, 2.5, 0, 0),
+ { }
+};
static ulong sc7280_set_rate(struct clk *clk, ulong rate)
{
struct msm_clk_priv *priv = dev_get_priv(clk->dev);
+ const struct freq_tbl *freq;
if (clk->id < priv->data->num_clks)
debug("%s: %s, requested rate=%ld\n", __func__,
priv->data->clks[clk->id].name, rate);
switch (clk->id) {
- case GCC_USB30_PRIM_MOCK_UTMI_CLK:
- WARN(rate != 1920, "Unexpected rate for
USB30_PRIM_MOCK_UTMI_CLK: %lu\n", rate);
- clk_rcg_set_rate(priv->base, USB30_PRIM_MASTER_CLK_CMD_RCGR, 0,
CFG_CLK_SRC_CXO);
- return rate;
case GCC_USB30_PRIM_MASTER_CLK:
- WARN(rate != 2, "Unexpected rate for USB30_PRIM_MASTER_CLK:
%lu\n", rate);
+ freq = qcom_find_freq(ftbl_gcc_usb30_prim_master_clk_src, rate);
clk_rcg_set_rate_mnd(priv->base, USB30_PRIM_MASTER_CLK_CMD_RCGR,
-1, 0, 0, CFG_CLK_SRC_GPLL0_ODD, 8);
- clk_rcg_set_rate(priv->base, 0xf064, 0, 0);
- return rate;
+freq->pre_div, freq->m, freq->n,
freq->src, 8);
+ return freq->freq;
+ case GCC_USB30_PRIM_MOCK_UTMI_CLK:
+ clk_rcg_set_rate(priv->base, USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR,
1, 0);
+ return 1920;
+ case GCC_USB3_PRIM_PHY_AUX_CLK_SRC:
+ clk_rcg_set_rate(priv->base, USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR,
1, 0);
+ return 1920;
+ case GCC_USB30_SEC_MASTER_CLK:
+ freq = qcom_find_freq(ftbl_gcc_usb30_sec_master_clk_src, rate);
+ clk_rcg_set_rate_mnd(priv->base, USB30_SEC_MASTER_CLK_CMD_RCGR,
+freq->pre_div, freq->m, freq->n,
freq->src, 8);
+ return freq->freq;
+ case GCC_USB30_SEC_MOCK_UTMI_CLK:
+ clk_rcg_set_rate(priv->base, USB30_SEC_MOCK_UTMI_CLK_CMD_RCGR,
1, 0);
+ return 1920;
+ case GCC_USB3_SEC_PHY_AUX_CLK_SRC:
+ clk_rcg_set_rate(priv->base, USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR,
1, 0);
+ return 1920;
+ case GCC_PCIE1_PHY_RCHNG_CLK:
+ clk_rcg_set_rate(priv->base, PCIE1_PHY_RCHNG_CMD_RCGR, 5,
CFG_CLK_SRC_GPLL0_EVEN);
+ return 1;
default:
- return 0;
+ return rate;
}
}
static const struct gate_clk sc7280_clks[] = {
@@ -49,15 +84,37 @@ static const struct gate_clk sc7280_clks[] = {
GATE_CLK(GCC_USB30_PRIM_SLEEP_CLK, 0xf018, 1),
GATE_CLK(GCC_USB30_PRIM_MOCK_UTMI_CLK, 0xf01c, 1),
GATE_CLK(GCC_USB3_PRIM_PHY_AUX_CLK, 0xf054, 1),
GATE_CLK(GCC_USB3_PRIM_PHY_COM_AUX_CLK, 0xf058, 1),
+ GATE_CLK(GCC_CFG_NOC_USB3_SEC_AXI_CLK, 0x9e07c, 1),
+ GATE_CLK(GCC_USB30_SEC_MASTER_CLK, 0x9e010, 1),
+ GATE_CLK(GCC_AGGRE_USB3_SEC_AXI_CLK, 0x9e080, 1),
+ GATE_CLK(GCC_USB30_SEC_SLEEP_CLK, 0x9e018, 1),
+ GATE_CLK(GCC_USB30_SEC_MOCK_UTMI_CLK, 0x9e01c, 1),
+ GATE_CLK(GCC_USB3_SEC_PHY_AUX_CLK, 0x9e054, 1),
+ GATE_CLK(GCC_USB3_SEC_PHY_COM_AUX_CLK, 0x9e058, 1),
+ GATE_CLK(GCC_PCIE_CLKREF_EN, 0x8c004, 1),
+ GATE_CLK(GCC_PCIE_1_PIPE_CLK, 0x52000, BIT(30)),
+ GATE_CLK(GCC_PCIE_1_AUX_CLK, 0x52000, BIT(29)),
+ GATE_CLK(GCC_PCIE_1_CFG_AHB_CLK, 0x52000, BIT(28)),
+ GATE_CLK(GCC_PCIE_1_MSTR_AXI_CLK, 0x52000, BIT(
Re: [PATCH] common: spl: Enable Instruction cache after relocation in board_init_r
On Mon, Mar 17, 2025 at 12:15:07PM +0530, Prasanth Babu Mantena wrote:
> ICACHE is enabled in board_init_f which executes only before relocation.
> Instruction cache invalidation is needed after relocation as well in the
> common spl, which is taken care in the u-boot init_sequence, but missing
> for the spl. So, enable it at the start of board_init_r for spl, which
> invalidates icache needed after instruction relocation.
>
> Fixes: 52a86e69e20 ("arm: k3: Enable instruction cache for main domain SPL")
> Signed-off-by: Prasanth Babu Mantena
> ---
> arch/arm/mach-k3/common.c | 1 +
> common/spl/spl.c | 1 +
> 2 files changed, 2 insertions(+)
What's missing from spl_enable_cache() in K3 already? And looking more
at this, since Rockchip does this slightly differently I wonder if we
need to think harder about making some of these hook points generic.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/3] i2c: geni: fix error message wording in clk_disable
On 14/03/2025 17:09, Caleb Connolly wrote:
Correct the error messages so they accurately describe that we failed to
disable the clocks, not to enable them.
Signed-off-by: Caleb Connolly
---
drivers/i2c/geni_i2c.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/geni_i2c.c b/drivers/i2c/geni_i2c.c
index
eabf5c76c21c2bc12c80dbb9fb498a0080928248..4eb41ba852f7790ca646c8ba38f29fdb727fa804
100644
--- a/drivers/i2c/geni_i2c.c
+++ b/drivers/i2c/geni_i2c.c
@@ -330,17 +330,15 @@ static int geni_i2c_disable_clocks(struct udevice *dev,
struct geni_i2c_priv *ge
if (geni->is_master_hub) {
ret = clk_disable(&geni->core);
if (ret) {
- dev_err(dev, "clk_enable core failed %d\n", ret);
- return ret;
+ dev_err(dev, "clk_disable core failed %d\n", ret);
}
}
ret = clk_disable(&geni->se);
if (ret) {
- dev_err(dev, "clk_enable se failed %d\n", ret);
- return ret;
+ dev_err(dev, "clk_disable se failed %d\n", ret);
}
return 0;
}
Reviewed-by: Neil Armstrong
Re: [RFC PATCH] Gitlab CI: Clean up more
Hi Tom,
On Sat, 15 Mar 2025 at 16:17, Tom Rini wrote:
>
> A problem we hit on our CI runners themselves, from time to time, is a
> lack of disk space on the host. This is because Gitlab has no automation
> itself around the removal of items it put in a "cache". While part of
> the way to alleviate this is for the runners to run various docker
> cleanup commands on their own, periodically, another thing to
> potentially help would be to further clean-up in the job itself.
>
> This patch adds "git clean -dfx" in jobs that leave some files in the
> source tree (these files may lead to a cache miss, more investigation
> would be required) and deleting the board build directory. This part is
> both a minimal size reclamation and minimal time increase (a few
> seconds).
>
> The other part this adds is making the world build use "/tmp/world" as
> the output directory not "/tmp" so that we can then delete "/tmp/world"
> afterwards. This adds between 1m30 and 3m to the build.
>
> Signed-off-by: Tom Rini
> ---
> Cc: Simon Glass
> Cc: Ilias Apalodimas
> ---
> .gitlab-ci.yml | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 2dbe6325f334..ce7a391bbd00 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -63,8 +63,9 @@ stages:
> -r tools/buildman/requirements.txt -r
> tools/u_boot_pylib/requirements.txt
>
>after_script:
> +- git clean -dfx
> - cp -v /tmp/${TEST_PY_BD}/*.{html,css,xml} .
> -- rm -rf /tmp/uboot-test-hooks /tmp/venv
> +- rm -rf /tmp/uboot-test-hooks /tmp/venv /tmp/${TEST_PY_BD}
This deletes less?
>script:
> # If we've been asked to use clang only do one configuration.
> - export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD}
> @@ -130,11 +131,13 @@ build all platforms in a single job:
> -r tools/buildman/requirements.txt
> - ret=0;
>git config --global --add safe.directory "${CI_PROJECT_DIR}";
> - ./tools/buildman/buildman -o /tmp -PEWM -x xtensa || ret=$?;
> + ./tools/buildman/buildman -o /tmp/world -PEWM -x xtensa || ret=$?;
Since you are making the tmp-> /tmp/world it might make more sense to
define a variable for the output directory.
>if [[ $ret -ne 0 ]]; then
> -./tools/buildman/buildman -o /tmp -seP;
> +./tools/buildman/buildman -o /tmp/world -seP;
> exit $ret;
>fi;
[...]
Other than that I think it looks sane. The added 1 - 3 min build time
is small enough to ignore
Thanks
/Ilias
