Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot
On 14/12/2023 21:15, Tom Rini wrote: On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote: On Thu, Dec 14, 2023 at 12:23 PM Tom Rini wrote: On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstr...@linaro.org wrote: Hi, On 14/12/2023 14:50, Sumit Garg wrote: Prerquisite s/Prerquisite/Prerequisite/ --- This patch series requires devicetree-rebasing git repo to be added as a subtree to the main U-boot repo via: $ git subtree add --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ v6.6-dts --squash So I think the big question is: when should the subtree be updated ? Because as we discussed in the previous GH pull request, if a bindings changes was made in the upstream Linux DT, then the subtree update should wait until the u-boot support is merged before updating. This could cause a lot of frustration. And this could cause a lot of regressions, even more if both Linux and U-boot are not maintained by the same people. I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either: - U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case. - It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem. A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.) I think we'll be fine, but time will tell. And perhaps the more frequent re-syncing will make any sort of corner cases show up more quickly and be something we can figure out how to resolve going forward really. Sure, I suppose I'll only switch the stable boards, and keep the in-progress ones with manual sync. And I'll need to make a prerequisite to any breaking DT change to have the corresponding U-Boot change submitted before (and probably other OSes like *BSD*s) Neil
Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot
On 14/12/2023 20:48, Rob Herring wrote: >> >> I think some of the important questions to ask are, how often / likely >> are the breakages to occur? It seems like these days it's either: >> - U-Boot had an early version of the binding and we already state we >> don't support backwards compatibility here. It should be on the >> maintainer to be proactive in this case. >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an >> incompatible DTS change now". This too is hopefully the kind of thing >> that at least board maintainers will be more actively aware of needing >> to deal with in U-Boot, if it's really a problem. > > A common issue in the kernel is with forward compatibility when > platforms add new resources from a new provider. Then the kernel > expects a driver for the provider and waits for the dependency. Of > course, older kernels don't have that provider driver and so the > dependency is never met. Not sure if u-boot will have similar issues? > At least you should/could know if the provider driver exists or not. > (The kernel doesn't because modules.) If some U-Boot platform decides to aggressively sync with kernel DTS, then probably the kernel subarch maintainer should be aware of it. Mentioned forward compatibility issue is a result of assumption that there are no out-of-tree upstream consumers of our DTS. I am certainly not aware of any such consumer for Samsung. If someone told me (me wearing Samsung hat), hey U-Boot now cares, I would start caring as well. The usual argument of contributors wanting to break the backward and forward compatibility, is "there is no other OS depending on this" (recent discussion with Johan about order of interrupts: https://lore.kernel.org/all/zwcpzpx-et-xh...@hovoldconsulting.com/ ). You need to tell the maintainers of that platform, that now they have other OS/firmware/bootloader depending on DTS compatibility. Best regards, Krzysztof
Re: [PATCH v1 1/1] arm64: zynqmp: Fix k24 psu_init_gpl.c clocking
Hi Neal, On 12/14/23 18:11, Frager, Neal wrote: Hi Michal, This patch corrects the k24 som clocking configuration such that the serdes Corrects the ... Ok. clocks are correctly enabled and the usb0 is configured to use the psgtr refclk2 for usb3 mode. I sort of have no problem with this patch but it should be better described. Pretty much serdes configuration should be called from u-boot because we already have psgtr driver and usb3.0 can be configured out of it. But we can't touch dwc3 driver now that's why the only way to do it is to configure via psu_init. But it should be clear from commit message that it is workaround not really something what should be here. I will re-test this without the serdes additions to see if they are really necessary. This patch also corrects the configuration of mio pins mio76 and mio77 which should be configured as gpio pins. This is definitely fine. Good. Signed-off-by: Neal Frager You mentioned that SPL didn't work before. Is it because of incorrect serdes configuration? Because that's sounds weird because you don't need serdes initialization for booting out of qspi. That's why looking for which is that bit which make SPL work on KD240. The SPL works. The issue is the same as I had with the kr260 board. The sd card interface is over usb, so unless the usb3 works correctly, u-boot has no sd card interface and cannot find the Linux kernel and file system. So what I meant was that I cannot boot up properly when starting from the SPL. This is what this patch is meant to fix. What I have seen on KD240 was that I could get to u-boot prompt. And for that you don't need any serdes initialization at all. Yes, agreed. I can get to u-boot prompt too without any additional patches. ok. Good. For booting OS you need it if you want to use USB3.0. And for the kd240, sd card requires usb3.0 also. That's why I want to make it clear what makes kd240 to boot u-boot. And what makes to access sd over usb to boot OS. Understood. The issue I am trying to solve is enabling sd over usb to boot OS. good. And no issue to add serdes initialization to psu_init to get boot OS part to work till someone has time to wire psgtr driver with dwc3 to configure it at run time. Is someone currently working on wiring psgtr driver with dwc3? I don't think so. If this were to happen soon, than this psu_init_gpl.c patch would become unnecessary. I will take some time to get there that's why it is fine to enable serdes lines via psu_init. You can put k24 to kv260/kr260 carrier cards but that's not normal mode of operations that's why it shouldn't be a problem. Maybe it is nice to test it to see but definitely not requirement. Thanks, Michal
[PATCH v2 1/1] arm64: zynqmp: Enable usb3 for k24 som
Currently, the u-boot zynqmp psgtr driver is not connected to the usb dwc3
driver. Without this, the only way for u-boot to be able to use usb3 is if
the psgtr serdes clocking is already enabled in the psu_init_gpl.c. This
patch enables the psgtr serdes for usb3 use, so the u-boot dwc3 driver will
work properly on boards based on the k24 som.
In addition, this patch correctly configures mio76 and mio77 as gpio pins
which are used as reset gpio pins on the kd240 starter kit.
This patch is needed for enabling u-boot to load an OS on the kd240
starter kit by either usb3 or the sd card interface connected over the usb3
to sd card bridge.
Signed-off-by: Neal Frager
---
V1->V2:
- rebased patch to latest u-boot master branch
- improved git commit message
---
.../zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c | 283 +-
1 file changed, 270 insertions(+), 13 deletions(-)
diff --git a/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c
b/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c
index 166e61431b..591f093752 100644
--- a/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c
+++ b/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c
@@ -72,6 +72,18 @@ static void dpll_prog(int div2, int ddr_pll_fbdiv, int
d_lock_dly,
Xil_Out32(((0xFD1AU) + 0x002C), pll_ctrl_regval);
}
+static int serdes_illcalib(u32 lane3_protocol, u32 lane3_rate,
+ u32 lane2_protocol, u32 lane2_rate,
+ u32 lane1_protocol, u32 lane1_rate,
+ u32 lane0_protocol, u32 lane0_rate)
+{
+ Xil_Out32(0xFD409914, 0xF3);
+ Xil_Out32(0xFD409940, 0xF3);
+ Xil_Out32(0xFD409990, 0x20);
+ Xil_Out32(0xFD409924, 0x37);
+ return 1;
+}
+
static unsigned long psu_pll_init_data(void)
{
psu_mask_write(0xFF5E0034, 0xFE7FEDEFU, 0x7E4B0C62U);
@@ -528,8 +540,8 @@ static unsigned long psu_mio_init_data(void)
psu_mask_write(0xFF180124, 0x00FEU, 0x0002U);
psu_mask_write(0xFF180128, 0x00FEU, 0x0002U);
psu_mask_write(0xFF18012C, 0x00FEU, 0x0002U);
- psu_mask_write(0xFF180130, 0x00FEU, 0x00C0U);
- psu_mask_write(0xFF180134, 0x00FEU, 0x00C0U);
+ psu_mask_write(0xFF180130, 0x00FEU, 0xU);
+ psu_mask_write(0xFF180134, 0x00FEU, 0xU);
psu_mask_write(0xFF180204, 0xU, 0x5000U);
psu_mask_write(0xFF180208, 0xU, 0x00B02020U);
psu_mask_write(0xFF18020C, 0x3FFFU, 0x0FC0U);
@@ -569,21 +581,16 @@ static unsigned long psu_peripherals_init_data(void)
psu_mask_write(0xFD1A0100, 0x0001807CU, 0xU);
psu_mask_write(0xFF5E0238, 0x001AU, 0xU);
psu_mask_write(0xFF5E023C, 0x0093C018U, 0xU);
- psu_mask_write(0xFF5E0230, 0x0008U, 0xU);
+ psu_mask_write(0xFF5E0230, 0x0002U, 0xU);
psu_mask_write(0xFF5E0238, 0x0001U, 0xU);
psu_mask_write(0xFF180390, 0x0004U, 0x0004U);
psu_mask_write(0xFF5E023C, 0x0400U, 0xU);
- psu_mask_write(0xFF5E0238, 0x0040U, 0xU);
- psu_mask_write(0xFF180310, 0x8000U, 0xU);
- psu_mask_write(0xFF180320, 0x3384U, 0x0284U);
- psu_mask_write(0xFF18031C, 0x7FFEU, 0x6450U);
- psu_mask_write(0xFF180358, 0x0008U, 0x0008U);
- psu_mask_write(0xFF180324, 0x03C0U, 0xU);
+ psu_mask_write(0xFF5E0238, 0x0080U, 0xU);
psu_mask_write(0xFF5E0238, 0x0400U, 0xU);
psu_mask_write(0xFF5E0238, 0x8000U, 0xU);
psu_mask_write(0xFF5E0238, 0x0010U, 0xU);
psu_mask_write(0xFF5E0238, 0x7800U, 0xU);
- psu_mask_write(0xFF5E0238, 0x0004U, 0xU);
+ psu_mask_write(0xFF5E0238, 0x0006U, 0xU);
psu_mask_write(0xFF5E0238, 0x0004U, 0xU);
psu_mask_write(0xFF4B0024, 0x00FFU, 0x00FFU);
psu_mask_write(0xFFCA5000, 0x1FFFU, 0xU);
@@ -591,13 +598,111 @@ static unsigned long psu_peripherals_init_data(void)
psu_mask_write(0xFFA60040, 0x8000U, 0x8000U);
psu_mask_write(0xFF260020, 0xU, 0x05F5DD18U);
psu_mask_write(0xFF26, 0x0001U, 0x0001U);
- psu_mask_write(0xFF5E0250, 0x0F0FU, 0x0202U);
+ psu_mask_write(0xFF0A0284, 0x03FFU, 0x0100U);
+ psu_mask_write(0xFF0A0288, 0x03FFU, 0x0100U);
+ psu_mask_write(0xFF0A0014, 0x03FF03FFU, 0x02FF0100U);
mask_delay(1);
- psu_mask_write(0xFF5E0250, 0x0F0FU, 0x0002U);
+ psu_mask_write(0xFF0A0014, 0x03FF03FFU, 0x02FFU);
mask_delay(5);
- psu_mask_write(0xFF5E0250, 0x0F0FU, 0x0202U);
+ psu_mask_write(0xFF0A0014, 0x03FF03FFU, 0x02FF0100U);
+
+ return 1;
+}
+
+static unsigned long
[PATCH] arm: dts: agilex: Increase reserved memory size to 32MB
From: Dinesh Maniyam
The reserved space is extended to 32MB in Linux kernel because
additional space is needed for authorization execution of JIC/RBF file.
U-Boot required to align with Linux.
Signed-off-by: Dinesh Maniyam
---
arch/arm/dts/socfpga_agilex.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/socfpga_agilex.dtsi b/arch/arm/dts/socfpga_agilex.dtsi
index c3ead2d72b..712304d07a 100644
--- a/arch/arm/dts/socfpga_agilex.dtsi
+++ b/arch/arm/dts/socfpga_agilex.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2019, Intel Corporation
+ * Copyright (C) 2019-2023 Intel Corporation
*/
/dts-v1/;
@@ -20,7 +20,7 @@
service_reserved: svcbuffer@0 {
compatible = "shared-dma-pool";
- reg = <0x0 0x0 0x0 0x100>;
+ reg = <0x0 0x0 0x0 0x200>;
alignment = <0x1000>;
no-map;
};
--
2.26.2
[PATCH] clk: altera: n5x: Fix MEMCLKMGR_EXTCNTRST_C0CNTRST to bit(0)
From: Dinesh Maniyam MEMCLKMGR_EXTCNTRST_C0CNTRST register defined as BIT[0] in documentation but it is wrongly defined as BIT[7] in u-boot code. This register is used to hold associated pingpong counter in reset while PLL and 5:1 mux configuration is changed. Signed-off-by: Dinesh Maniyam --- drivers/clk/altera/clk-mem-n5x.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/altera/clk-mem-n5x.h b/drivers/clk/altera/clk-mem-n5x.h index 7b687012e8..c6bc44bb34 100644 --- a/drivers/clk/altera/clk-mem-n5x.h +++ b/drivers/clk/altera/clk-mem-n5x.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause */ /* - * Copyright (C) 2020-2022 Intel Corporation + * Copyright (C) 2020-2023 Intel Corporation */ #ifndef_CLK_MEM_N5X_ @@ -77,7 +77,7 @@ #define MEMCLKMGR_PLLOUTDIV_C0CNT_MASK GENMASK(4, 0) #define MEMCLKMGR_PLLOUTDIV_C0CNT_OFFSET 0 -#define MEMCLKMGR_EXTCNTRST_C0CNTRST BIT(7) +#define MEMCLKMGR_EXTCNTRST_C0CNTRST BIT(0) #define MEMCLKMGR_EXTCNTRST_ALLCNTRST \ (MEMCLKMGR_EXTCNTRST_C0CNTRST) -- 2.26.2
Re: [PATCH 00/17] video: dw_hdmi: Support Vendor PHY
Hi Jagan, On 2023/12/15 14:36, Jagan Teki wrote: Hi Heiko/Kerver/Anatoloj, On Mon, Dec 11, 2023 at 2:30 PM Jagan Teki wrote: Unlike RK3399, Sunxi/Meson DW HDMI the new Rockchip SoC Rk3328 would support external vendor PHY with DW HDMI chip. Support this vendor PHY by adding new platform PHY ops via DW HDMI driver and call the respective generic phy from platform driver code. This series tested in RK3328 with 1080p (1920x1080) resolution. Patch 0001/0005: Support Vendor PHY Patch 0006/0008: VOP extension for win, dsp offsets Patch 0009/0010: RK3328 VOP, HDMI clocks Patch 0011: Rockchip Inno HDMI PHY Patch 0012: RK3328 HDMI driver Patch 0013: RK3328 VOP driver Patch 0014/0017: Enable HDMI Out for RK3328 Importent: One pontential issues is that Linux HDMI out on RK3328 has effected by this patchset as I wouldn't find any relation or clue. [0.752016] Loading compiled-in X.509 certificates [0.787796] inno_hdmi_phy_rk3328_clk_recalc_rate: parent 2400 [0.788391] inno-hdmi-phy ff43.phy: inno_hdmi_phy_rk3328_clk_recalc_rate rate 14850 vco 14850 [0.798353] rockchip-drm display-subsystem: bound ff37.vop (ops vop_component_ops) [0.799403] dwhdmi-rockchip ff3c.hdmi: supply avdd-0v9 not found, using dummy regulator [0.800288] rk_iommu ff373f00.iommu: Enable stall request timed out, status: 0x4b [0.801131] dwhdmi-rockchip ff3c.hdmi: supply avdd-1v8 not found, using dummy regulator [0.802056] rk_iommu ff373f00.iommu: Disable paging request timed out, status: 0x4b [0.803233] dwhdmi-rockchip ff3c.hdmi: Detected HDMI TX controller v2.11a with HDCP (inno_dw_hdmi_phy2) [0.805355] dwhdmi-rockchip ff3c.hdmi: registered DesignWare HDMI I2C bus driver [0.808769] rockchip-drm display-subsystem: bound ff3c.hdmi (ops dw_hdmi_rockchip_ops) [0.810869] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0 The only way I can use Linux HDMI by disabling IOMMU or support disable-iommu link for RK3328 via DT [1]. [1] https://www.spinics.net/lists/devicetree/msg605124.html Is anyone aware of this issue? I did post the patches for Linux IOMMU but seems not a proper solution. Any suggestions? I'm not expert in HDMI/VOP, so I can't provide a suitable solution in the kernel, but here is the reason why we need patch to workaround the issue in the kernel: - The VOP driver working in U-Boot is non-IOMMU mode, and the VOP access DDR by physical address; - The VOP driver working in kernel with IOMMU enabled(by default), the VOP access DDR with virtual address(by IOMMU); - The VOP is keep working in kernel before kernel VOP driver is enabled, and the IOMMU driver will be enabled by the Linux PM framework, since the IOMMU is not correctly configured at this point, the VOP will access unknown space(the original physical address in U-Boot) convert by IOMMU; So we need to disable the IOMMU temporary in kernel startup before VOP driver is enabled. Thanks, - Kever Thanks, Jagan.
RE: [PATCH v2 05/21] riscv: Add a reset_cpu() function
> -Original Message-
> From: Simon Glass
> Sent: Friday, December 15, 2023 1:50 AM
> To: U-Boot Mailing List
> Cc: Tom Rini ; Simon Glass ; Chanho
> Park ; Heinrich Schuchardt
;
> Leo ; Nikita Shubin ; Rick Chen
>
> Subject: [PATCH v2 05/21] riscv: Add a reset_cpu() function
>
> The current do_reset() is called from a command context. Add a function
> which can be used from anywhere, as is done on ARM. Adjust do_reset()
> to call it.
>
> Note that reset_cpu() is normally provided by SYSRESET so make this
> declaration conditional on that being disabled.
>
> Signed-off-by: Simon Glass
Reviewed-by: Chanho Park
Tested-by: Chanho Park
> ---
>
> (no changes since v1)
>
> arch/riscv/cpu/cpu.c | 13 +
> arch/riscv/lib/reset.c | 7 ++-
> 2 files changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index ebd39cb41a60..8445c5823e17 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -3,10 +3,13 @@
> * Copyright (C) 2018, Bin Meng
> */
>
> +#include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -162,3 +165,13 @@ int arch_early_init_r(void)
> __weak void harts_early_init(void)
> {
> }
> +
> +#if !CONFIG_IS_ENABLED(SYSRESET)
> +void reset_cpu(void)
> +{
> + printf("resetting ...\n");
> +
> + printf("reset not supported yet\n");
> + hang();
> +}
> +#endif
> diff --git a/arch/riscv/lib/reset.c b/arch/riscv/lib/reset.c
> index 712e1bdb8e1d..c4153c9e6e02 100644
> --- a/arch/riscv/lib/reset.c
> +++ b/arch/riscv/lib/reset.c
> @@ -4,14 +4,11 @@
> */
>
> #include
> -#include
> +#include
>
> int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const
> argv[])
> {
> - printf("resetting ...\n");
> -
> - printf("reset not supported yet\n");
> - hang();
> + reset_cpu();
>
> return 0;
> }
> --
> 2.43.0.472.g3155946c3a-goog
Re: [PATCH 00/17] video: dw_hdmi: Support Vendor PHY
Hi Heiko/Kerver/Anatoloj, On Mon, Dec 11, 2023 at 2:30 PM Jagan Teki wrote: > > Unlike RK3399, Sunxi/Meson DW HDMI the new Rockchip SoC Rk3328 would > support external vendor PHY with DW HDMI chip. > > Support this vendor PHY by adding new platform PHY ops via DW HDMI > driver and call the respective generic phy from platform driver code. > > This series tested in RK3328 with 1080p (1920x1080) resolution. > > Patch 0001/0005: Support Vendor PHY > Patch 0006/0008: VOP extension for win, dsp offsets > Patch 0009/0010: RK3328 VOP, HDMI clocks > Patch 0011: Rockchip Inno HDMI PHY > Patch 0012: RK3328 HDMI driver > Patch 0013: RK3328 VOP driver > Patch 0014/0017: Enable HDMI Out for RK3328 > > Importent: > One pontential issues is that Linux HDMI out on RK3328 has effected by > this patchset as I wouldn't find any relation or clue. > > [0.752016] Loading compiled-in X.509 certificates > [0.787796] inno_hdmi_phy_rk3328_clk_recalc_rate: parent 2400 > [0.788391] inno-hdmi-phy ff43.phy: > inno_hdmi_phy_rk3328_clk_recalc_rate rate 14850 vco 14850 > [0.798353] rockchip-drm display-subsystem: bound ff37.vop (ops > vop_component_ops) > [0.799403] dwhdmi-rockchip ff3c.hdmi: supply avdd-0v9 not found, > using dummy regulator > [0.800288] rk_iommu ff373f00.iommu: Enable stall request timed out, > status: 0x4b > [0.801131] dwhdmi-rockchip ff3c.hdmi: supply avdd-1v8 not found, > using dummy regulator > [0.802056] rk_iommu ff373f00.iommu: Disable paging request timed out, > status: 0x4b > [0.803233] dwhdmi-rockchip ff3c.hdmi: Detected HDMI TX controller > v2.11a with HDCP (inno_dw_hdmi_phy2) > [0.805355] dwhdmi-rockchip ff3c.hdmi: registered DesignWare HDMI I2C > bus driver > [0.808769] rockchip-drm display-subsystem: bound ff3c.hdmi (ops > dw_hdmi_rockchip_ops) > [0.810869] [drm] Initialized rockchip 1.0.0 20140818 for > display-subsystem on minor 0 > > The only way I can use Linux HDMI by disabling IOMMU or support > disable-iommu link for RK3328 via DT [1]. > > [1] https://www.spinics.net/lists/devicetree/msg605124.html Is anyone aware of this issue? I did post the patches for Linux IOMMU but seems not a proper solution. Any suggestions? Thanks, Jagan.
Re: [PATCH v3] board: ti: common: board_detect: Fix EEPROM offset read for 1-byte
On 15:15-20231107, Neha Malcom Francis wrote:
> Hi Prasanth,
>
> On 30/10/23 22:34, Prasanth Babu Mantena wrote:
> > EEPROM detection logic in ti_i2c_eeprom_get() involves reading
> > the total size and the 1-byte size with an offset 1. The commit
> > 9f393a2d7af8 ("board: ti: common: board_detect: Fix EEPROM read
> > quirk for 2-byte") that attempts to fix this uses a wrong pointer to
> > compare.
> >
> > The value with one offset is read into offset_test, but the pointer
> > used to match was still ep, resulting in an invalid comparison of the
> > values. The intent is to identify bad 2-byte addressing eeproms that
> > get stuck on the successive reads.
> >
> > Fixes: 9f393a2d7af8 (board: ti: common: board_detect: Fix EEPROM read quirk
> > for 2-byte)
> > Signed-off-by: Prasanth Babu Mantena
> > Tested-by: Matwey V. Kornilov
> > ---
> > v3 <--> v2:
> > Improved and concise commit description.
> >
> > v2 <--> v1:
> > Fix inplace for the else condition of CONFIG_IS_ENABLED(DM_I2C).
> > Improved commit message.
> >
> > board/ti/common/board_detect.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
> > index 9a53884c98..869f7a47f8 100644
> > --- a/board/ti/common/board_detect.c
> > +++ b/board/ti/common/board_detect.c
> > @@ -128,7 +128,7 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> > bus_addr, int dev_addr,
> > rc = dm_i2c_read(dev, 0x1, _test, sizeof(offset_test));
> > - if (*((u32 *)ep) != (header & 0xFF))
> > + if (offset_test != ((header >> 8) & 0xFF))
> > one_byte_addressing = false;
> > /* Corrupted data??? */
> > @@ -180,7 +180,7 @@ static int __maybe_unused ti_i2c_eeprom_get(int
> > bus_addr, int dev_addr,
> > rc = i2c_read(dev_addr, 0x1, byte, _test, sizeof(offset_test));
> > - if (*((u32 *)ep) != (header & 0xFF))
> > + if (offset_test != ((header >> 8) & 0xFF))
> > one_byte_addressing = false;
> > /* Corrupted data??? */
>
> Reviewed-by: Neha Malcom Francis
>
Can this patch be considered for merge considering no further comments.
Regards,
Prasanth
> --
> Thanking You
> Neha Malcom Francis
Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot
On Fri, 15 Dec 2023 at 01:45, Tom Rini wrote: > > On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote: > > On Thu, Dec 14, 2023 at 12:23 PM Tom Rini wrote: > > > > > > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstr...@linaro.org wrote: > > > > Hi, > > > > > > > > On 14/12/2023 14:50, Sumit Garg wrote: > > > > > Prerquisite > > > > > > > > s/Prerquisite/Prerequisite/ > > > > > > > > > --- > > > > > > > > > > This patch series requires devicetree-rebasing git repo to be added > > > > > as a > > > > > subtree to the main U-boot repo via: > > > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > > > \ > > > > >v6.6-dts --squash > > > > > > > > So I think the big question is: when should the subtree be updated ? > > > > > > > > Because as we discussed in the previous GH pull request, if a bindings > > > > changes > > > > was made in the upstream Linux DT, then the subtree update should wait > > > > until > > > > the u-boot support is merged before updating. This could cause a lot of > > > > frustration. > > > > > > > > And this could cause a lot of regressions, even more if both Linux and > > > > U-boot are > > > > not maintained by the same people. > > > > > > I think some of the important questions to ask are, how often / likely > > > are the breakages to occur? It seems like these days it's either: > > > - U-Boot had an early version of the binding and we already state we > > > don't support backwards compatibility here. It should be on the > > > maintainer to be proactive in this case. > > > - It's a "the DT was wrong about the hardware, sorry not sorry it's an > > > incompatible DTS change now". This too is hopefully the kind of thing > > > that at least board maintainers will be more actively aware of needing > > > to deal with in U-Boot, if it's really a problem. > > > > A common issue in the kernel is with forward compatibility when > > platforms add new resources from a new provider. Then the kernel > > expects a driver for the provider and waits for the dependency. Of > > course, older kernels don't have that provider driver and so the > > dependency is never met. Not sure if u-boot will have similar issues? > > At least you should/could know if the provider driver exists or not. > > (The kernel doesn't because modules.) > > I think we'll be fine, but time will tell. And perhaps the more frequent > re-syncing will make any sort of corner cases show up more quickly and > be something we can figure out how to resolve going forward really. > Agree, frequent re-syncing is something we should aim for. However, if required then we can always revisit our approach. -Sumit > -- > Tom
Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot
On Thu, 14 Dec 2023 at 23:53, Tom Rini wrote: > > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstr...@linaro.org wrote: > > Hi, > > > > On 14/12/2023 14:50, Sumit Garg wrote: > > > Prerquisite > > > > s/Prerquisite/Prerequisite/ > > Ack. > > > --- > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > subtree to the main U-boot repo via: > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > \ > > >v6.6-dts --squash > > > > So I think the big question is: when should the subtree be updated ? > > > > Because as we discussed in the previous GH pull request, if a bindings > > changes > > was made in the upstream Linux DT, then the subtree update should wait until > > the u-boot support is merged before updating. This could cause a lot of > > frustration. > > > > And this could cause a lot of regressions, even more if both Linux and > > U-boot are > > not maintained by the same people. > > I think some of the important questions to ask are, how often / likely > are the breakages to occur? It seems like these days it's either: > - U-Boot had an early version of the binding and we already state we > don't support backwards compatibility here. It should be on the > maintainer to be proactive in this case. > - It's a "the DT was wrong about the hardware, sorry not sorry it's an > incompatible DTS change now". This too is hopefully the kind of thing > that at least board maintainers will be more actively aware of needing > to deal with in U-Boot, if it's really a problem. Agree, also per discussion with Linux DT maintainers, they do care for DT backwards and forward compatibility. I expect the ABI changes to be rare. In case there is an ABI change then it will be great if Linux DT maintainers can ask contributors to CC corresponding U-boot platform maintainers too. BTW, Rob is already working on a tool to detect ABI changes as he described here [1]. If U-boot platform maintainers have any ideas regarding what would constitute an ABI change then feel free to share those. [1] https://lore.kernel.org/all/cal_jsqlo4nxrj93ddsfp3uyls08v02amnbccnsdj0mbbomc...@mail.gmail.com/ > > So I would plan on grabbing only full kernel releases and in to -next as > soon as possible. Our cadences don't match up exactly, but I think do > fairly well enough. I suppose that would give ample time to the U-boot platform/board maintainer to fix any ABI change regression found in the -next branch. That being said we aren't completely immune to changes to devicetree-rebasing subtree. If there is an DT ABI change that will take significant effort to fix in U-boot then we are open to accepting a revert given that it will be fixed before next uprev. -Sumit > > -- > Tom
[PATCH v2 16/16] x86: Drop message about features being missing with 64-bit
At this point most things work, including booting a distro, so drop
this message.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/x86/lib/spl.c | 2 +-
doc/board/emulation/qemu-x86.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/lib/spl.c b/arch/x86/lib/spl.c
index c15f11f8cdf4..4e4cf18dec5c 100644
--- a/arch/x86/lib/spl.c
+++ b/arch/x86/lib/spl.c
@@ -283,7 +283,7 @@ void __noreturn jump_to_image_no_args(struct spl_image_info
*spl_image)
{
int ret;
- printf("Jumping to 64-bit U-Boot: Note many features are missing\n");
+ printf("Jumping to 64-bit U-Boot\n");
ret = cpu_jump_to_64bit_uboot(spl_image->entry_point);
debug("ret=%d\n", ret);
hang();
diff --git a/doc/board/emulation/qemu-x86.rst b/doc/board/emulation/qemu-x86.rst
index c604e42990ed..4eeba46ba7a9 100644
--- a/doc/board/emulation/qemu-x86.rst
+++ b/doc/board/emulation/qemu-x86.rst
@@ -134,7 +134,7 @@ The output will be something like this::
U-Boot SPL 2023.07 (Jul 23 2023 - 08:00:12 -0600)
Trying to boot from SPI
- Jumping to 64-bit U-Boot: Note many features are missing
+ Jumping to 64-bit U-Boot
U-Boot 2023.07 (Jul 23 2023 - 08:00:12 -0600)
--
2.43.0.472.g3155946c3a-goog
[PATCH v2 15/16] pxe: Allow booting without CMDLINE for the zboot method
Use zboot_run() to boot rather than the command line. This allows
extlinux to be used (on x86) without CMDLINE being enabled.
Collect any error but do not return it, to match the existing code.
Signed-off-by: Simon Glass
---
(no changes since v1)
boot/pxe_utils.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index c9da82b8e45f..5ceabfd04ee6 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -568,10 +568,8 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
char *initrd_addr_str, char *initrd_filesize)
{
struct bootm_info bmi;
- char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
const char *fdt_addr;
ulong kernel_addr_r;
- int zboot_argc = 3;
void *buf;
int ret;
@@ -625,16 +623,10 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
}
bmi.addr_fit = kernel_addr;
- zboot_argv[1] = kernel_addr;
- if (initrd_addr_str) {
+ if (initrd_addr_str)
bmi.conf_ramdisk = initrd_str;
- zboot_argv[3] = initrd_addr_str;
- zboot_argv[4] = initrd_filesize;
- zboot_argc = 5;
- }
-
if (!fdt_addr)
fdt_addr = env_get("fdt_addr");
@@ -657,8 +649,13 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
else if (IS_ENABLED(CONFIG_BOOTM))
ret = bootz_run();
/* Try booting an x86_64 Linux kernel image */
- else if (IS_ENABLED(CONFIG_CMD_ZBOOT))
- do_zboot_parent(ctx->cmdtp, 0, zboot_argc, zboot_argv, NULL);
+ else if (IS_ENABLED(CONFIG_ZBOOT))
+ ret = zboot_run(hextoul(kernel_addr, NULL), 0,
+ initrd_addr_str ?
+ hextoul(initrd_addr_str, NULL) : 0,
+ initrd_addr_str ?
+ hextoul(initrd_filesize, NULL) : 0,
+ 0, NULL);
unmap_sysmem(buf);
--
2.43.0.472.g3155946c3a-goog
[PATCH v2 14/16] pxe: Allow booting without CMDLINE for bootm methods
Use bootm_run() and booti_run() to boot rather than the command line.
This allows extlinux to be used without CMDLINE being enabled.
Collect any error but do not return it, to match the existing code.
Signed-off-by: Simon Glass
---
Changes in v2:
- Update commit message to mention booti
- Use bootm_init() instead of memset()
boot/pxe_utils.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index a34f4410e07e..c9da82b8e45f 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
#include
@@ -566,13 +567,16 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
char *kernel_addr, char *initrd_str,
char *initrd_addr_str, char *initrd_filesize)
{
- char *bootm_argv[] = { "bootm", NULL, NULL, NULL, NULL };
+ struct bootm_info bmi;
char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
const char *fdt_addr;
ulong kernel_addr_r;
- int bootm_argc = 2;
int zboot_argc = 3;
void *buf;
+ int ret;
+
+ if (IS_ENABLED(CONFIG_BOOTM))
+ bootm_init();
fdt_addr = env_get("fdt_addr_r");
@@ -620,12 +624,11 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
}
}
- bootm_argv[1] = kernel_addr;
+ bmi.addr_fit = kernel_addr;
zboot_argv[1] = kernel_addr;
if (initrd_addr_str) {
- bootm_argv[2] = initrd_str;
- bootm_argc = 3;
+ bmi.conf_ramdisk = initrd_str;
zboot_argv[3] = initrd_addr_str;
zboot_argv[4] = initrd_filesize;
@@ -641,23 +644,18 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
if (!fdt_addr && genimg_get_format(buf) != IMAGE_FORMAT_FIT)
fdt_addr = env_get("fdtcontroladdr");
- if (fdt_addr) {
- if (!bootm_argv[2])
- bootm_argv[2] = "-";
- bootm_argc = 4;
- }
- bootm_argv[3] = (char *)fdt_addr;
+ bmi.conf_fdt = fdt_addr;
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(buf) != IMAGE_FORMAT_INVALID &&
-IS_ENABLED(CONFIG_CMD_BOOTM))
- do_bootm(ctx->cmdtp, 0, bootm_argc, bootm_argv);
+ IS_ENABLED(CONFIG_BOOTM))
+ ret = bootm_run();
/* Try booting an AArch64 Linux kernel image */
- else if (IS_ENABLED(CONFIG_CMD_BOOTI))
- do_booti(ctx->cmdtp, 0, bootm_argc, bootm_argv);
+ else if (IS_ENABLED(CONFIG_BOOTM))
+ ret = booti_run();
/* Try booting a Image */
- else if (IS_ENABLED(CONFIG_CMD_BOOTZ))
- do_bootz(ctx->cmdtp, 0, bootm_argc, bootm_argv);
+ else if (IS_ENABLED(CONFIG_BOOTM))
+ ret = bootz_run();
/* Try booting an x86_64 Linux kernel image */
else if (IS_ENABLED(CONFIG_CMD_ZBOOT))
do_zboot_parent(ctx->cmdtp, 0, zboot_argc, zboot_argv, NULL);
--
2.43.0.472.g3155946c3a-goog
[PATCH v2 13/16] pxe: Move calculation of FDT file into a function
This code undertakes a separate task from the main logic of
label_run_boot() so move it into its own function.
Signed-off-by: Simon Glass
---
(no changes since v1)
boot/pxe_utils.c | 112 +++
1 file changed, 64 insertions(+), 48 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index a6aee68bb797..a34f4410e07e 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -469,6 +469,68 @@ skip_overlay:
}
#endif
+/**
+ * calc_fdt_fname() - Figure out the filename to use for the FDT
+ *
+ * Determine the path to the FDT filename, based on the "fdtfile" environment
+ * variable. Use -.dtb as a fallback
+ *
+ * @fdtdir: Directory to use for the FDT file
+ * Return: allocated filename (including directory), or NULL if out of memory
+ */
+static char *calc_fdt_fname(const char *fdtdir)
+{
+ char *fdtfile;
+ char *f1, *f2, *f3, *f4, *slash;
+ int len;
+
+ f1 = env_get("fdtfile");
+ if (f1) {
+ f2 = "";
+ f3 = "";
+ f4 = "";
+ } else {
+ /*
+* For complex cases where this code doesn't generate the
+* correct filename, the board code should set $fdtfile during
+* early boot, or the boot scripts should set $fdtfile before
+* invoking "pxe" or "sysboot".
+*/
+ f1 = env_get("soc");
+ f2 = "-";
+ f3 = env_get("board");
+ f4 = ".dtb";
+ if (!f1) {
+ f1 = "";
+ f2 = "";
+ }
+ if (!f3) {
+ f2 = "";
+ f3 = "";
+ }
+ }
+
+ len = strlen(fdtdir);
+ if (!len)
+ slash = "./";
+ else if (fdtdir[len - 1] != '/')
+ slash = "/";
+ else
+ slash = "";
+
+ len = strlen(fdtdir) + strlen(slash) + strlen(f1) + strlen(f2) +
+ strlen(f3) + strlen(f4) + 1;
+ fdtfile = malloc(len);
+ if (!fdtfile) {
+ printf("malloc fail (FDT filename)\n");
+ return NULL;
+ }
+
+ snprintf(fdtfile, len, "%s%s%s%s%s%s", fdtdir, slash, f1, f2, f3, f4);
+
+ return fdtfile;
+}
+
/**
* label_run_boot() - Run the correct boot procedure
*
@@ -525,55 +587,9 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
if (label->fdt) {
fdtfile = label->fdt;
} else if (label->fdtdir) {
- char *f1, *f2, *f3, *f4, *slash;
- int len;
-
- f1 = env_get("fdtfile");
- if (f1) {
- f2 = "";
- f3 = "";
- f4 = "";
- } else {
- /*
-* For complex cases where this code doesn't
-* generate the correct filename, the board
-* code should set $fdtfile during early boot,
-* or the boot scripts should set $fdtfile
-* before invoking "pxe" or "sysboot".
-*/
- f1 = env_get("soc");
- f2 = "-";
- f3 = env_get("board");
- f4 = ".dtb";
- if (!f1) {
- f1 = "";
- f2 = "";
- }
- if (!f3) {
- f2 = "";
- f3 = "";
- }
- }
-
- len = strlen(label->fdtdir);
- if (!len)
- slash = "./";
- else if (label->fdtdir[len - 1] != '/')
- slash = "/";
- else
- slash = "";
-
- len = strlen(label->fdtdir) + strlen(slash) +
- strlen(f1) + strlen(f2) + strlen(f3) +
- strlen(f4) + 1;
- fdtfilefree = malloc(len);
- if (!fdtfilefree) {
- printf("malloc fail (FDT filename)\n");
+ fdtfilefree = calc_fdt_fname(label->fdtdir);
+ if (!fdtfilefree)
return -ENOMEM;
- }
-
- snprintf(fdtfilefree, len, "%s%s%s%s%s%s",
-label->fdtdir, slash, f1, f2, f3, f4);
[PATCH v2 12/16] pxe: Refactor to avoid over-using bootm_argv
The bootm_argv[3] expression is used in many places. It is the FDT
address, so use that name throughout.
Assign it to bootm_argv[3] only at the end, when all the conditions are
resolved.
Signed-off-by: Simon Glass
---
(no changes since v1)
boot/pxe_utils.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 6fbccadd99e6..a6aee68bb797 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -506,18 +506,19 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
{
char *bootm_argv[] = { "bootm", NULL, NULL, NULL, NULL };
char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
+ const char *fdt_addr;
ulong kernel_addr_r;
int bootm_argc = 2;
int zboot_argc = 3;
void *buf;
- bootm_argv[3] = env_get("fdt_addr_r");
+ fdt_addr = env_get("fdt_addr_r");
/* For FIT, the label can be identical to kernel one */
if (label->fdt && !strcmp(label->kernel_label, label->fdt)) {
- bootm_argv[3] = kernel_addr;
+ fdt_addr = kernel_addr;
/* if fdt label is defined then get fdt from server */
- } else if (bootm_argv[3]) {
+ } else if (fdt_addr) {
char *fdtfile = NULL;
char *fdtfilefree = NULL;
@@ -582,7 +583,7 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
free(fdtfilefree);
if (err < 0) {
- bootm_argv[3] = NULL;
+ fdt_addr = NULL;
if (label->fdt) {
printf("Skipping %s for failure
retrieving FDT\n",
@@ -599,7 +600,7 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
label_boot_fdtoverlay(ctx, label);
#endif
} else {
- bootm_argv[3] = NULL;
+ fdt_addr = NULL;
}
}
@@ -615,20 +616,21 @@ static int label_run_boot(struct pxe_context *ctx, struct
pxe_label *label,
zboot_argc = 5;
}
- if (!bootm_argv[3])
- bootm_argv[3] = env_get("fdt_addr");
+ if (!fdt_addr)
+ fdt_addr = env_get("fdt_addr");
kernel_addr_r = genimg_get_kernel_addr(kernel_addr);
buf = map_sysmem(kernel_addr_r, 0);
- if (!bootm_argv[3] && genimg_get_format(buf) != IMAGE_FORMAT_FIT)
- bootm_argv[3] = env_get("fdtcontroladdr");
+ if (!fdt_addr && genimg_get_format(buf) != IMAGE_FORMAT_FIT)
+ fdt_addr = env_get("fdtcontroladdr");
- if (bootm_argv[3]) {
+ if (fdt_addr) {
if (!bootm_argv[2])
bootm_argv[2] = "-";
bootm_argc = 4;
}
+ bootm_argv[3] = (char *)fdt_addr;
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(buf) != IMAGE_FORMAT_INVALID &&
--
2.43.0.472.g3155946c3a-goog
[PATCH v2 11/16] pxe: Refactor to reduce the size of label_boot()
This function is far too long and complicated. Split out the part
which actually calls the boot commands into a separate function.
Change a strncpy() to strlcpy() to keep checkpatch happy.
No functional change is intended.
Signed-off-by: Simon Glass
---
(no changes since v1)
boot/pxe_utils.c | 301 +--
1 file changed, 163 insertions(+), 138 deletions(-)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 2c87aba7ed33..6fbccadd99e6 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -470,159 +470,47 @@ skip_overlay:
#endif
/**
- * label_boot() - Boot according to the contents of a pxe_label
+ * label_run_boot() - Run the correct boot procedure
*
- * If we can't boot for any reason, we return. A successful boot never
- * returns.
+ * fdt usage is optional:
+ * It handles the following scenarios.
*
- * The kernel will be stored in the location given by the 'kernel_addr_r'
- * environment variable.
+ * Scenario 1: If fdt_addr_r specified and "fdt" or "fdtdir" label is
+ * defined in pxe file, retrieve fdt blob from server. Pass fdt_addr_r to
+ * bootm, and adjust argc appropriately.
*
- * If the label specifies an initrd file, it will be stored in the location
- * given by the 'ramdisk_addr_r' environment variable.
+ * If retrieve fails and no exact fdt blob is specified in pxe file with
+ * "fdt" label, try Scenario 2.
*
- * If the label specifies an 'append' line, its contents will overwrite that
- * of the 'bootargs' environment variable.
+ * Scenario 2: If there is an fdt_addr specified, pass it along to
+ * bootm, and adjust argc appropriately.
+ *
+ * Scenario 3: If there is an fdtcontroladdr specified, pass it along to
+ * bootm, and adjust argc appropriately, unless the image type is fitImage.
+ *
+ * Scenario 4: fdt blob is not available.
*
* @ctx: PXE context
* @label: Label to process
+ * @kernel_addr: string containing the kernel address / config
+ * @initrd_str: string containing the initrd address / size
+ * @initrd_addr_str: initrd address, or NULL if none
+ * @initrd_filesize: initrd size in bytes; only valid if initrd_addr_str is not
+ * NULL
* Returns does not return on success, otherwise returns 0 if a localboot
* label was processed, or 1 on error
*/
-static int label_boot(struct pxe_context *ctx, struct pxe_label *label)
+static int label_run_boot(struct pxe_context *ctx, struct pxe_label *label,
+ char *kernel_addr, char *initrd_str,
+ char *initrd_addr_str, char *initrd_filesize)
{
char *bootm_argv[] = { "bootm", NULL, NULL, NULL, NULL };
char *zboot_argv[] = { "zboot", NULL, "0", NULL, NULL };
- char *kernel_addr = NULL;
- char *initrd_addr_str = NULL;
- char initrd_filesize[10];
- char initrd_str[28];
- char mac_str[29] = "";
- char ip_str[68] = "";
- char *fit_addr = NULL;
+ ulong kernel_addr_r;
int bootm_argc = 2;
int zboot_argc = 3;
- int len = 0;
- ulong kernel_addr_r;
void *buf;
- label_print(label);
-
- label->attempted = 1;
-
- if (label->localboot) {
- if (label->localboot_val >= 0)
- label_localboot(label);
- return 0;
- }
-
- if (!label->kernel) {
- printf("No kernel given, skipping %s\n",
- label->name);
- return 1;
- }
-
- if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r",
- NULL) < 0) {
- printf("Skipping %s for failure retrieving kernel\n",
- label->name);
- return 1;
- }
-
- kernel_addr = env_get("kernel_addr_r");
- /* for FIT, append the configuration identifier */
- if (label->config) {
- int len = strlen(kernel_addr) + strlen(label->config) + 1;
-
- fit_addr = malloc(len);
- if (!fit_addr) {
- printf("malloc fail (FIT address)\n");
- return 1;
- }
- snprintf(fit_addr, len, "%s%s", kernel_addr, label->config);
- kernel_addr = fit_addr;
- }
-
- /* For FIT, the label can be identical to kernel one */
- if (label->initrd && !strcmp(label->kernel_label, label->initrd)) {
- initrd_addr_str = kernel_addr;
- } else if (label->initrd) {
- ulong size;
- if (get_relfile_envaddr(ctx, label->initrd, "ramdisk_addr_r",
- ) < 0) {
- printf("Skipping %s for failure retrieving initrd\n",
- label->name);
- goto cleanup;
- }
- strcpy(initrd_filesize, simple_xtoa(size));
- initrd_addr_str = env_get("ramdisk_addr_r");
- size =
[PATCH v2 10/16] pxe: Use strlcpy() instead of strcpy() in label_boot()
The intention here is to nul-terminate the result string, so use the correct function for that. Signed-off-by: Simon Glass --- Changes in v2: - Split out the strlcpy() change into its own patch boot/pxe_utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c index a92bb896c63e..2c87aba7ed33 100644 --- a/boot/pxe_utils.c +++ b/boot/pxe_utils.c @@ -593,7 +593,7 @@ static int label_boot(struct pxe_context *ctx, struct pxe_label *label) } if (label->append) - strncpy(bootargs, label->append, sizeof(bootargs)); + strlcpy(bootargs, label->append, sizeof(bootargs)); strcat(bootargs, ip_str); strcat(bootargs, mac_str); -- 2.43.0.472.g3155946c3a-goog
[PATCH v2 09/16] doc: Mention fastboot dependency on CMDLINE
The fastboot 'boot' command only supports running a U-Boot command if CONFIG_CMDLINE is enabled. Mention this in the documentation. Signed-off-by: Simon Glass Suggested-by: Tom Rini --- (no changes since v1) doc/android/fastboot.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst index 1ad8a897c853..933a652538c7 100644 --- a/doc/android/fastboot.rst +++ b/doc/android/fastboot.rst @@ -127,6 +127,7 @@ Boot command When executing the fastboot ``boot`` command, if ``fastboot_bootcmd`` is set then that will be executed in place of ``bootm ``. +This is supported if CONFIG_CMDLINE is enabled, which it normally is. Partition Names --- -- 2.43.0.472.g3155946c3a-goog
[PATCH v2 08/16] fastboot: Remove dependencies on CMDLINE
It is possible to boot a kernel without CMDLINE being enabled. Update
the implementation to handle this, and drop the condition from the
FASTBOOT config.
Signed-off-by: Simon Glass
---
Changes in v2:
- Avoid changing the logic when a command is not set
drivers/fastboot/Kconfig | 1 -
drivers/fastboot/fb_common.c | 30 ++
2 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index 11fc0fe1c800..837c6f1180da 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -1,5 +1,4 @@
menu "Fastboot support"
- depends on CMDLINE
config FASTBOOT
bool
diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
index 07f5946d9ed1..595954542a6e 100644
--- a/drivers/fastboot/fb_common.c
+++ b/drivers/fastboot/fb_common.c
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#include
#include
@@ -142,22 +143,19 @@ void (*fastboot_get_progress_callback(void))(const char *)
*/
void fastboot_boot(void)
{
- char *s;
-
- s = env_get("fastboot_bootcmd");
- if (s) {
- run_command(s, CMD_FLAG_ENV);
- } else if (IS_ENABLED(CONFIG_CMD_BOOTM)) {
- static char boot_addr_start[20];
- static char *const bootm_args[] = {
- "bootm", boot_addr_start, NULL
- };
-
- snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
-"%lx", fastboot_buf_addr);
- printf("Booting kernel at %s...\n\n\n", boot_addr_start);
-
- do_bootm(NULL, 0, 2, bootm_args);
+ char *s = NULL;
+
+ if (IS_ENABLED(CONFIG_CMDLINE)) {
+ s = env_get("fastboot_bootcmd");
+ if (s)
+ run_command(s, CMD_FLAG_ENV);
+ }
+
+ if (!s && IS_ENABLED(CONFIG_BOOTM)) {
+ int ret;
+
+ printf("Booting kernel at %lx...\n\n\n", fastboot_buf_addr);
+ ret = bootm_boot_start(fastboot_buf_addr, NULL);
/*
* This only happens if image is somehow faulty so we start
--
2.43.0.472.g3155946c3a-goog
[PATCH v2 07/16] bootm: Make cmdline optional with bootm_boot_start()
Allow the default command line to be used when booting the OS. This is needed by fastboot. Signed-off-by: Simon Glass --- Changes in v2: - Drop check for NULL with env_set() include/bootm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/bootm.h b/include/bootm.h index fe3a2b38b1c5..51e77bde4014 100644 --- a/include/bootm.h +++ b/include/bootm.h @@ -299,7 +299,7 @@ void zimage_dump(struct boot_params *base_ptr, bool show_cmdline); * bootm_boot_start() - Boot an image at the given address * * @addr: Image address - * @cmdline: Command line to set + * @cmdline: Command line to set, NULL for default */ int bootm_boot_start(ulong addr, const char *cmdline); -- 2.43.0.472.g3155946c3a-goog
[PATCH v2 06/16] fastboot: Change fastboot_buf_addr to an address
Given the name of this variable, it should be an address, not a
pointer. Update this, to make it easier to use with sandbox.
Signed-off-by: Simon Glass
Reviewed-by: Dmitrii Merkurev
Reviewed-by: Mattijs Korpershoek
Tested-by: Mattijs Korpershoek # on vim3
---
Changes in v2:
- Use unmap_sysmem() too
cmd/fastboot.c| 2 +-
drivers/fastboot/fb_command.c | 17 -
drivers/fastboot/fb_common.c | 15 ---
include/fastboot-internal.h | 2 +-
include/fastboot.h| 6 +++---
5 files changed, 21 insertions(+), 21 deletions(-)
diff --git a/cmd/fastboot.c b/cmd/fastboot.c
index c3c19231c988..792e83d372c3 100644
--- a/cmd/fastboot.c
+++ b/cmd/fastboot.c
@@ -159,7 +159,7 @@ NXTARG:
return CMD_RET_USAGE;
}
- fastboot_init((void *)buf_addr, buf_size);
+ fastboot_init(buf_addr, buf_size);
if (!strcmp(argv[1], "udp"))
return do_fastboot_udp(argc, argv, buf_addr, buf_size);
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 5fcadcdf503d..55ac1e96979f 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -243,6 +244,7 @@ void fastboot_data_download(const void *fastboot_data,
{
#define BYTES_PER_DOT 0x2
u32 pre_dot_num, now_dot_num;
+ void *buf;
if (fastboot_data_len == 0 ||
(fastboot_bytes_received + fastboot_data_len) >
@@ -252,8 +254,10 @@ void fastboot_data_download(const void *fastboot_data,
return;
}
/* Download data to fastboot_buf_addr */
- memcpy(fastboot_buf_addr + fastboot_bytes_received,
+ buf = map_sysmem(fastboot_buf_addr, 0);
+ memcpy(buf + fastboot_bytes_received,
fastboot_data, fastboot_data_len);
+ unmap_sysmem(buf);
pre_dot_num = fastboot_bytes_received / BYTES_PER_DOT;
fastboot_bytes_received += fastboot_data_len;
@@ -296,13 +300,16 @@ void fastboot_data_complete(char *response)
*/
static void __maybe_unused flash(char *cmd_parameter, char *response)
{
+ void *buf = map_sysmem(fastboot_buf_addr, 0);
+
if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_MMC))
- fastboot_mmc_flash_write(cmd_parameter, fastboot_buf_addr,
-image_size, response);
+ fastboot_mmc_flash_write(cmd_parameter, buf, image_size,
+response);
if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_NAND))
- fastboot_nand_flash_write(cmd_parameter, fastboot_buf_addr,
- image_size, response);
+ fastboot_nand_flash_write(cmd_parameter, buf, image_size,
+ response);
+ unmap_sysmem(buf);
}
/**
diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
index 3576b0677299..07f5946d9ed1 100644
--- a/drivers/fastboot/fb_common.c
+++ b/drivers/fastboot/fb_common.c
@@ -20,7 +20,7 @@
/**
* fastboot_buf_addr - base address of the fastboot download buffer
*/
-void *fastboot_buf_addr;
+ulong fastboot_buf_addr;
/**
* fastboot_buf_size - size of the fastboot download buffer
@@ -154,7 +154,7 @@ void fastboot_boot(void)
};
snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
-"0x%p", fastboot_buf_addr);
+"%lx", fastboot_buf_addr);
printf("Booting kernel at %s...\n\n\n", boot_addr_start);
do_bootm(NULL, 0, 2, bootm_args);
@@ -214,16 +214,9 @@ void fastboot_set_progress_callback(void (*progress)(const
char *msg))
fastboot_progress_callback = progress;
}
-/*
- * fastboot_init() - initialise new fastboot protocol session
- *
- * @buf_addr: Pointer to download buffer, or NULL for default
- * @buf_size: Size of download buffer, or zero for default
- */
-void fastboot_init(void *buf_addr, u32 buf_size)
+void fastboot_init(ulong buf_addr, u32 buf_size)
{
- fastboot_buf_addr = buf_addr ? buf_addr :
- (void *)CONFIG_FASTBOOT_BUF_ADDR;
+ fastboot_buf_addr = buf_addr ? buf_addr : CONFIG_FASTBOOT_BUF_ADDR;
fastboot_buf_size = buf_size ? buf_size : CONFIG_FASTBOOT_BUF_SIZE;
fastboot_set_progress_callback(NULL);
}
diff --git a/include/fastboot-internal.h b/include/fastboot-internal.h
index bf2f2b3c8914..d3e1c106e23f 100644
--- a/include/fastboot-internal.h
+++ b/include/fastboot-internal.h
@@ -6,7 +6,7 @@
/**
* fastboot_buf_addr - base address of the fastboot download buffer
*/
-extern void *fastboot_buf_addr;
+extern ulong fastboot_buf_addr;
/**
* fastboot_buf_size - size of the fastboot download buffer
diff --git a/include/fastboot.h b/include/fastboot.h
index 296451f89d44..744ab61cc18a 100644
--- a/include/fastboot.h
+++
[PATCH v2 05/16] boot: Update SYS_BOOTM_LEN to depend on BOOTM
Use the new CONFIG_BOOTM symbol to determine whether SYS_BOOT_LEN is visible or not, since we want to support decompression when CMDLINE is disabled. Signed-off-by: Simon Glass --- (no changes since v1) boot/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boot/Kconfig b/boot/Kconfig index 9fa8789bc2b1..d83047acbd0d 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -800,7 +800,7 @@ endif # MEASURED_BOOT config SYS_BOOTM_LEN hex "Maximum size of a decompresed OS image" - depends on CMD_BOOTM || CMD_BOOTI || CMD_BOOTZ || \ + depends on BOOTM || CMD_BOOTI || CMD_BOOTZ || \ LEGACY_IMAGE_FORMAT || SPL_LEGACY_IMAGE_FORMAT default 0x400 if PPC || ARM64 default 0x100 if X86 || ARCH_MX6 || ARCH_MX7 -- 2.43.0.472.g3155946c3a-goog
[PATCH v2 04/16] treewide: Make arch-specific bootm code depend on BOOTM
Allow these functions to be compiled in when CONFIG_BOOTM is enabled, even if CONFIG_CMD_BOOTM is not. Signed-off-by: Simon Glass --- (no changes since v1) arch/arc/lib/Makefile| 2 +- arch/arm/lib/Makefile| 2 +- arch/m68k/lib/Makefile | 2 +- arch/microblaze/lib/Makefile | 2 +- arch/mips/lib/Makefile | 2 +- arch/nios2/lib/Makefile | 2 +- arch/powerpc/lib/Makefile| 2 +- arch/riscv/lib/Makefile | 2 +- arch/sandbox/lib/Makefile| 2 +- arch/sh/lib/Makefile | 2 +- arch/x86/lib/Makefile| 2 +- arch/xtensa/lib/Makefile | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arc/lib/Makefile b/arch/arc/lib/Makefile index 0eb44bcf33d0..bde1c3d8af3a 100644 --- a/arch/arc/lib/Makefile +++ b/arch/arc/lib/Makefile @@ -12,6 +12,6 @@ obj-y += reset.o obj-y += ints_low.o obj-y += init_helpers.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o lib-$(CONFIG_USE_PRIVATE_LIBGCC) += _millicodethunk.o libgcc2.o diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index b1bcd3746625..b20a467f684c 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -31,7 +31,7 @@ endif obj-$(CONFIG_CPU_V7M) += cmd_boot.o obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o else obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o diff --git a/arch/m68k/lib/Makefile b/arch/m68k/lib/Makefile index 6e1fd938f526..5ccd9545cb5c 100644 --- a/arch/m68k/lib/Makefile +++ b/arch/m68k/lib/Makefile @@ -8,7 +8,7 @@ lib-$(CONFIG_USE_PRIVATE_LIBGCC) += lshrdi3.o muldi3.o ashldi3.o ashrdi3.o obj-y += bdinfo.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-y += cache.o obj-y += interrupts.o obj-y += time.o diff --git a/arch/microblaze/lib/Makefile b/arch/microblaze/lib/Makefile index dfd8135f4f25..2f234825f804 100644 --- a/arch/microblaze/lib/Makefile +++ b/arch/microblaze/lib/Makefile @@ -3,6 +3,6 @@ # (C) Copyright 2003-2006 # Wolfgang Denk, DENX Software Engineering, w...@denx.de. -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-$(CONFIG_CMD_BDI) += bdinfo.o obj-y += muldi3.o diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile index 9ee1fcb5c702..f8e162c53b58 100644 --- a/arch/mips/lib/Makefile +++ b/arch/mips/lib/Makefile @@ -10,7 +10,7 @@ obj-y += reloc.o obj-y += stack.o obj-y += traps.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-$(CONFIG_CMD_GO) += boot.o obj-$(CONFIG_SPL_BUILD) += spl.o diff --git a/arch/nios2/lib/Makefile b/arch/nios2/lib/Makefile index a9f3c7100e72..68a5ca007d55 100644 --- a/arch/nios2/lib/Makefile +++ b/arch/nios2/lib/Makefile @@ -4,5 +4,5 @@ # Wolfgang Denk, DENX Software Engineering, w...@denx.de. obj-y += cache.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-y += libgcc.o diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile index bb819dcbb6cc..dcce9834927d 100644 --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -34,7 +34,7 @@ obj-y += ticks.o endif obj-y += reloc.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-y += cache.o obj-y += extable.o obj-y += interrupts.o diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile index 9a05b662fd63..0b2c88db6bad 100644 --- a/arch/riscv/lib/Makefile +++ b/arch/riscv/lib/Makefile @@ -6,7 +6,7 @@ # Copyright (C) 2017 Andes Technology Corporation # Rick Chen, Andes Technology Corporation -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTI) += bootm.o image.o obj-$(CONFIG_CMD_GO) += boot.o obj-y += cache.o diff --git a/arch/sandbox/lib/Makefile b/arch/sandbox/lib/Makefile index a2bc5a7ee60f..c4924b23c832 100644 --- a/arch/sandbox/lib/Makefile +++ b/arch/sandbox/lib/Makefile @@ -7,5 +7,5 @@ obj-y += fdt_fixup.o interrupts.o sections.o obj-$(CONFIG_PCI) += pci_io.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-$(CONFIG_CMD_BOOTZ) += bootm.o diff --git a/arch/sh/lib/Makefile b/arch/sh/lib/Makefile index e7520a328d54..8c3c30293a3c 100644 --- a/arch/sh/lib/Makefile +++ b/arch/sh/lib/Makefile @@ -6,7 +6,7 @@ extra-y+= start.o obj-y += board.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o obj-y += time.o obj-$(CONFIG_CMD_SH_ZIMAGEBOOT) += zimageboot.o diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index 8fc35e1b51ea..94aa335ede4c 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -16,7 +16,7 @@ obj-$(CONFIG_X86_32BIT_INIT) += string.o endif ifndef CONFIG_SPL_BUILD -obj-$(CONFIG_CMD_BOOTM) += bootm.o +obj-$(CONFIG_BOOTM) += bootm.o endif obj-y += cmd_boot.o obj-$(CONFIG_$(SPL_)COREBOOT_SYSINFO) += coreboot/ diff --git a/arch/xtensa/lib/Makefile
[PATCH v2 03/16] bootm: Make OS booting dependent on BOOTM
Booting an OS does not require the 'bootm' command, so change the condition for these options. Move them into boot/ so they don't depend on CMDLINE Note that CMD_BOOTM_PRE_LOAD has been put directly into the bootm code so will need some additional refactoring (and a test!) to allow it to change over. Signed-off-by: Simon Glass Reviewed-by: Tom Rini --- (no changes since v1) boot/Kconfig | 49 + cmd/Kconfig | 49 - 2 files changed, 49 insertions(+), 49 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index 8b32a51f7e7c..9fa8789bc2b1 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -689,6 +689,55 @@ config BOOTM This option should normally be enabled. It is used to implement the 'bootm' command. +config BOOTM_LINUX + bool "Support booting Linux OS images" + depends on BOOTM || CMD_BOOTZ || CMD_BOOTI + default y + help + Support booting the Linux kernel directly via a command such as bootm + or booti or bootz. + +config BOOTM_NETBSD + bool "Support booting NetBSD (non-EFI) loader images" + depends on BOOTM + default y + help + Support booting NetBSD via the bootm command. + +config BOOTM_OPENRTOS + bool "Support booting OPENRTOS / FreeRTOS images" + depends on BOOTM + help + Support booting OPENRTOS / FreeRTOS via the bootm command. + +config BOOTM_OSE + bool "Support booting Enea OSE images" + depends on (ARM && (ARM64 || CPU_V7A || CPU_V7R) || SANDBOX || PPC || X86) + depends on BOOTM + help + Support booting Enea OSE images via the bootm command. + +config BOOTM_PLAN9 + bool "Support booting Plan9 OS images" + depends on BOOTM + default y + help + Support booting Plan9 images via the bootm command. + +config BOOTM_RTEMS + bool "Support booting RTEMS OS images" + depends on BOOTM + default y + help + Support booting RTEMS images via the bootm command. + +config BOOTM_VXWORKS + bool "Support booting VxWorks OS images" + depends on BOOTM + default y + help + Support booting VxWorks images via the bootm command. + config ANDROID_BOOT_IMAGE bool "Android Boot Images" default y if FASTBOOT diff --git a/cmd/Kconfig b/cmd/Kconfig index 2af66a66c1e1..116e53f972d0 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -291,48 +291,6 @@ config CMD_BOOTI help Boot an AArch64 Linux Kernel image from memory. -config BOOTM_LINUX - bool "Support booting Linux OS images" - depends on CMD_BOOTM || CMD_BOOTZ || CMD_BOOTI - default y - help - Support booting the Linux kernel directly via a command such as bootm - or booti or bootz. - -config BOOTM_NETBSD - bool "Support booting NetBSD (non-EFI) loader images" - depends on CMD_BOOTM - default y - help - Support booting NetBSD via the bootm command. - -config BOOTM_OPENRTOS - bool "Support booting OPENRTOS / FreeRTOS images" - depends on CMD_BOOTM - help - Support booting OPENRTOS / FreeRTOS via the bootm command. - -config BOOTM_OSE - bool "Support booting Enea OSE images" - depends on (ARM && (ARM64 || CPU_V7A || CPU_V7R) || SANDBOX || PPC || X86) - depends on CMD_BOOTM - help - Support booting Enea OSE images via the bootm command. - -config BOOTM_PLAN9 - bool "Support booting Plan9 OS images" - depends on CMD_BOOTM - default y - help - Support booting Plan9 images via the bootm command. - -config BOOTM_RTEMS - bool "Support booting RTEMS OS images" - depends on CMD_BOOTM - default y - help - Support booting RTEMS images via the bootm command. - config CMD_SEAMA bool "Support read SEAMA NAND images" depends on MTD_RAW_NAND @@ -349,13 +307,6 @@ config CMD_VBE is used to boot. Updating the parameters is not currently supported. -config BOOTM_VXWORKS - bool "Support booting VxWorks OS images" - depends on CMD_BOOTM - default y - help - Support booting VxWorks images via the bootm command. - config CMD_BOOTEFI bool "bootefi" depends on EFI_LOADER -- 2.43.0.472.g3155946c3a-goog
[PATCH v2 02/16] bootm: Add a Kconfig option for bootm functionality
Create a separate Kconfig option which enables the bootm logic, separate from the 'bootm' command. This will eventually allow booting without CMDLINE enabled. Update boards which disable CMD_BOOTM to disable BOOTM instead, since CMD_BOOTM now depends on BOOTM Signed-off-by: Simon Glass --- (no changes since v1) boot/Kconfig | 12 boot/Makefile| 2 +- cmd/Kconfig | 1 + configs/colibri_vf_defconfig | 2 +- configs/iot_devkit_defconfig | 2 +- configs/mx6memcal_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/xilinx_versal_mini_defconfig | 2 +- configs/xilinx_versal_mini_emmc0_defconfig | 2 +- configs/xilinx_versal_mini_emmc1_defconfig | 2 +- configs/xilinx_versal_mini_ospi_defconfig| 2 +- configs/xilinx_versal_mini_qspi_defconfig| 2 +- configs/xilinx_versal_net_mini_defconfig | 2 +- configs/xilinx_versal_net_mini_emmc_defconfig| 2 +- configs/xilinx_versal_net_mini_ospi_defconfig| 2 +- configs/xilinx_versal_net_mini_qspi_defconfig| 2 +- configs/xilinx_zynqmp_mini_defconfig | 2 +- configs/xilinx_zynqmp_mini_emmc0_defconfig | 2 +- configs/xilinx_zynqmp_mini_emmc1_defconfig | 2 +- configs/xilinx_zynqmp_mini_nand_defconfig| 2 +- configs/xilinx_zynqmp_mini_nand_single_defconfig | 2 +- configs/xilinx_zynqmp_mini_qspi_defconfig| 2 +- configs/zynq_cse_nand_defconfig | 2 +- configs/zynq_cse_nor_defconfig | 2 +- configs/zynq_cse_qspi_defconfig | 2 +- 25 files changed, 36 insertions(+), 23 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index e0098b3f31d7..8b32a51f7e7c 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -677,6 +677,18 @@ config BOOTMETH_SCRIPT endif # BOOTSTD +config BOOTM + bool "Support booting an application image from memory" + default y + help + This is the main boot implementation in U-Boot, supporting a wide + variety of features including FIT and legacy-image boot, kernel and + FDT selection, setting up of the command line for the OS and many + other features. + + This option should normally be enabled. It is used to implement the + 'bootm' command. + config ANDROID_BOOT_IMAGE bool "Android Boot Images" default y if FASTBOOT diff --git a/boot/Makefile b/boot/Makefile index de0eafed14b1..a4ea2f9e062f 100644 --- a/boot/Makefile +++ b/boot/Makefile @@ -6,7 +6,7 @@ ifndef CONFIG_SPL_BUILD obj-$(CONFIG_BOOT_RETRY) += bootretry.o -obj-$(CONFIG_CMD_BOOTM) += bootm.o bootm_os.o +obj-$(CONFIG_BOOTM) += bootm.o bootm_os.o obj-$(CONFIG_CMD_BOOTZ) += bootm.o bootm_os.o obj-$(CONFIG_CMD_BOOTI) += bootm.o bootm_os.o diff --git a/cmd/Kconfig b/cmd/Kconfig index 397e6472c036..2af66a66c1e1 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -219,6 +219,7 @@ config CMD_BOOTD config CMD_BOOTM bool "bootm" + depends on BOOTM default y help Boot an application image from the memory. diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig index 8b2324fd5648..48019f0fa0b8 100644 --- a/configs/colibri_vf_defconfig +++ b/configs/colibri_vf_defconfig @@ -17,6 +17,7 @@ CONFIG_SYS_MEMTEST_END=0x87c0 CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_HAS_BOARD_SIZE_LIMIT=y CONFIG_BOARD_SIZE_LIMIT=520192 +# CONFIG_BOOTM is not set CONFIG_BOOTDELAY=1 CONFIG_FDT_FIXUP_PARTITIONS=y CONFIG_USE_BOOTCOMMAND=y @@ -33,7 +34,6 @@ CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Colibri VFxx # " CONFIG_SYS_PBSIZE=1056 # CONFIG_CMD_BOOTD is not set -# CONFIG_CMD_BOOTM is not set CONFIG_CMD_BOOTZ=y # CONFIG_CMD_ELF is not set # CONFIG_CMD_IMI is not set diff --git a/configs/iot_devkit_defconfig b/configs/iot_devkit_defconfig index 55ced6bc3c32..a09f3ed5f77b 100644 --- a/configs/iot_devkit_defconfig +++ b/configs/iot_devkit_defconfig @@ -14,12 +14,12 @@ CONFIG_DEFAULT_DEVICE_TREE="iot_devkit" CONFIG_SYS_CLK_FREQ=1600 CONFIG_SYS_LOAD_ADDR=0x3000 CONFIG_LOCALVERSION="-iotdk-1.0" +# CONFIG_BOOTM is not set # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set CONFIG_SYS_PROMPT="IoTDK# " CONFIG_SYS_CBSIZE=256 CONFIG_SYS_PBSIZE=280 # CONFIG_CMD_BOOTD is not set -# CONFIG_CMD_BOOTM is not set # CONFIG_CMD_ELF is not set # CONFIG_CMD_XIMG is not set # CONFIG_CMD_LOADB is not set diff --git a/configs/mx6memcal_defconfig b/configs/mx6memcal_defconfig index 6dd64b6da1ba..6da7a0eaf09c 100644 --- a/configs/mx6memcal_defconfig +++ b/configs/mx6memcal_defconfig @@ -14,6 +14,7 @@ CONFIG_SPL_SERIAL=y CONFIG_SPL=y CONFIG_SYS_MEMTEST_START=0x1000 CONFIG_SYS_MEMTEST_END=0x2000 +# CONFIG_BOOTM is not set CONFIG_SUPPORT_RAW_INITRD=y CONFIG_SPL_SYS_MALLOC=y CONFIG_SPL_WATCHDOG=y @@
[PATCH v2 01/16] boot: Reorder FIT and BOOTSTD to be first
The boot menu shows Android first and then a timestamp option. Move these later since they are less commonly used. Signed-off-by: Simon Glass --- (no changes since v1) boot/Kconfig | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/boot/Kconfig b/boot/Kconfig index b438002059c3..e0098b3f31d7 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -2,24 +2,6 @@ menu "Boot options" menu "Boot images" -config ANDROID_BOOT_IMAGE - bool "Android Boot Images" - default y if FASTBOOT - help - This enables support for booting images which use the Android - image format header. - -config TIMESTAMP - bool "Show image date and time when displaying image information" - default y if CMD_DATE - help - When CONFIG_TIMESTAMP is selected, the timestamp (date and time) of - an image is printed by image commands like bootm or iminfo. This - is shown as 'Timestamp: xxx' and 'Created: xxx'. If this option is - enabled, then U-Boot requires FITs to have a timestamp. If a FIT is - loaded that does not, the message 'Wrong FIT format: no timestamp' - is shown. - menuconfig FIT bool "Flattened Image Tree (FIT)" select HASH @@ -695,6 +677,24 @@ config BOOTMETH_SCRIPT endif # BOOTSTD +config ANDROID_BOOT_IMAGE + bool "Android Boot Images" + default y if FASTBOOT + help + This enables support for booting images which use the Android + image format header. + +config TIMESTAMP + bool "Show image date and time when displaying image information" + default y if CMD_DATE + help + When CONFIG_TIMESTAMP is selected, the timestamp (date and time) of + an image is printed by image commands like bootm or iminfo. This + is shown as 'Timestamp: xxx' and 'Created: xxx'. If this option is + enabled, then U-Boot requires FITs to have a timestamp. If a FIT is + loaded that does not, the message 'Wrong FIT format: no timestamp' + is shown. + config LEGACY_IMAGE_FORMAT bool "Enable support for the legacy image format" default y if !FIT_SIGNATURE && !TI_SECURE_DEVICE -- 2.43.0.472.g3155946c3a-goog
Re: [PATCH] mtd: spi-nor: Add support for Macronix flash part
On 2023-12-14 17:36, Tejas Bhumkar wrote:
Added support for Macronix OSPI flash parts MX25UM51345G
and MX66UM2G45G, with initial testing conducted on the
Tenzing-se1 board using STR mode for basic erase, write,
and readback operations.
Signed-off-by: Tejas Bhumkar
---
drivers/mtd/spi/spi-nor-ids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c
b/drivers/mtd/spi/spi-nor-ids.c
index f86e7ff8e5..a08f105549 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -267,6 +267,8 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("mx66l2g45g", 0xc2201c, 0, 64 * 1024, 4096, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32, SPI_NOR_QUAD_READ
| SPI_NOR_4B_OPCODES | SECT_4K) },
{ INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) },
+ { INFO("mx25um51345g", 0xc2813a, 0, 64 * 1024, 1024, SECT_4K |
SPI_NOR_4B_OPCODES) },
+ { INFO("mx66um2g45g",0xc2803c, 0, 64 * 1024, 4096, SECT_4K |
SPI_NOR_4B_OPCODES) },
{ INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
{ INFO("mx66lm1g45g",0xc2853b, 0, 64 * 1024, 2048, SECT_4K |
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
{ INFO("mx25lm51245g", 0xc2853a, 0, 64 * 1024, 1024, SECT_4K |
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
The patch looks good to me, so:
Reviewed-by: Dragan Simic
Please see also [1]. I hope you'll be willing to test the patches when
they're ready.
[1]
https://lore.kernel.org/u-boot/0dc545aa9d32038dbe7bc48159519...@manjaro.org/T/#u
Re: [PATCH 1/2] ARM: imx: Force DRAM regulators into FPWM mode on Data Modul i.MX8M Plus eDM SBC
On Thu, Dec 7, 2023 at 2:51 PM Marek Vasut wrote: > > In case the Buck5 and Buck6 regulators which supply DRAM Vdd1 and Vdd2/Vddq > respectively operate in automatic PWM/PFM mode, the DRAM EDAC detects more > correctable errors than if the regulators operate in forced PWM only mode. > Force DRAM regulators to forced PWM mode only to stop tempting the DRAM. > > Signed-off-by: Marek Vasut Applied both to u-boot-imx master, thanks.
Re: [PATCH] ARM: imx: Enable CAAM on DH i.MX8M Plus DHCOM
On Fri, Dec 1, 2023 at 10:58 PM Marek Vasut wrote: > > Enable CAAM in U-Boot to make crypto available early in the boot process. > > This has a side-effect that in case an older kernel version contains a > broken CAAM initialization timeout code, initialization in bootloader > will help that old kernel version function correctly. > > Signed-off-by: Marek Vasut Applied to u-boot-imx master, thanks.
Re: [PATCH] ARM: imx: Enable CAAM on Data Modul i.MX8M Mini/Plus eDM SBC
On Fri, Dec 1, 2023 at 10:56 PM Marek Vasut wrote: > > Enable CAAM in U-Boot to make crypto available early in the boot process. > > This has a side-effect that in case an older kernel version contains a > broken CAAM initialization timeout code, initialization in bootloader > will help that old kernel version function correctly. > > Signed-off-by: Marek Vasut Applied to u-boot-imx master, thanks.
Re: [PATCH] ddr: imx: Add 3600 MTps rate support
On Fri, Dec 1, 2023 at 10:49 PM Marek Vasut wrote: > > Add PLL settings for DDR 3600 MTps . This is very similar to 3200 MTps > PLL setting, except the divider is not 9 but 8 . > > Signed-off-by: Marek Vasut Applied to u-boot-imx master, thanks.
Re: [PATCH] ddr: imx: Handle 3734 in addition to 3733 and 3732 MTps rates
On Fri, Dec 1, 2023 at 10:48 PM Marek Vasut wrote: > > The new MX8M DDR tool 3.31 now generates a programming file which uses > data rate 3734 instead of 3733 or 3732 . Handle another rounding option . > > Signed-off-by: Marek Vasut Applied to u-boot-imx master, thanks.
Re: [PATCH] arm64: imx8mp: Inhibit DTC warning on DH i.MX8MP DHCOM rev.100 DTO
On Sat, Nov 4, 2023 at 9:04 PM Marek Vasut wrote:
>
> Inhibit DTC warning in imx8mp-dhcom-pdk3-overlay-rev100.dts:
> "
> arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo: Warning (reg_format):
> /fragment@0/__overlay__:reg: property has invalid length (4 bytes)
> (#address-cells == 2, #size-cells == 1)
> arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo: Warning
> (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
> #address-cells value
> arch/arm/dts/imx8mp-dhcom-pdk3-overlay-rev100.dtbo: Warning
> (avoid_default_addr_size): /fragment@0/__overlay__: Relying on default
> #size-cells value
> "
>
> The DTO overwrites the 'reg' property of an ethernet PHY and is only
> used on specific combination of old prototype SoM and old prototype
> PDK3 carrier board, which had incorrectly placed pull resistor, which
> made the PHY change its MDIO address in that specific combination and
> which is already fixed on production hardware.
>
> The DTO is implemented in this simple manner because if it contained a
> full MDIO bus node reference to define #address-cells and #size-cells,
> it would also require a full new copy of the PHY node, i.e.
> ethernet-phy@5 { ... reg = <5>; ... }, to avoid DTC warnings about
> mismatch between node unit and reg value. The node unit in SoM DT is
> ethernet-phy@7 { ... }; .
>
> This simpler approach avoids unnecessary duplication without adverse
> side effects.
>
> Reported-by: Fabio Estevam
> Reported-by: Sean Anderson
> Signed-off-by: Marek Vasut
Applied to u-boot-imx master, thanks.
Re: [PATCH 1/3] board: gateworks: venice: remove extra file
On Thu, Dec 14, 2023 at 1:22 PM Tim Harvey wrote: > > Remove lpddr4_timing_imx8mm_512mb.c mistakenly committed > > Fixes: a1c711046b0d "(board: gateworks: venice: add imx8mm-gw7903 support)" > Signed-off-by: Tim Harvey Applied all to u-boot-imx master, thanks.
[PATCH v2] board: rockchip: Add the Turing RK1 SoM
The Turing RK1 is a Rockchip RK3588 based SoM from Turing Machines.
Specifications:
Rockchip RK3588 SoC
4x ARM Cortex-A76, 4x ARM Cortex-A55
8/16/32GB memory LPDDR4x
Mali G610MC4 GPU
32GB eMMC HS400
2x USB 2.0, 2x USB 3.0
2x MIPI CSI 4x lanes
1x MIPI-DSI DPHY 2x lanes
PCIe 2.0 x1, PCIe 3.0 x4
1x HDMI 2.1 output, 1x DP 1.4 output
Gigabit Ethernet
Size: 69.6mm x 45mm (260-pin SO-DIMM connector)
Kernel commit:
2806a69f3fef ("arm64: dts: rockchip: Add Turing RK1 SoM support")
Signed-off-by: Joshua Riek
Cc: Sam Edwards
---
Changes in v2:
- removed BOOT_TARGET #ifdef ... #endif in the RK1 header file
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi| 25 +
arch/arm/dts/rk3588-turing-rk1.dts| 21 +
arch/arm/dts/rk3588-turing-rk1.dtsi | 614 ++
arch/arm/mach-rockchip/rk3588/Kconfig | 24 +
board/turing/turing-rk1-rk3588/Kconfig| 15 +
board/turing/turing-rk1-rk3588/MAINTAINERS| 9 +
board/turing/turing-rk1-rk3588/Makefile | 6 +
.../turing-rk1-rk3588/turing-rk1-rk3588.c | 39 ++
configs/turing-rk1-rk3588_defconfig | 133
doc/board/rockchip/rockchip.rst | 1 +
include/configs/turing-rk1-rk3588.h | 15 +
12 files changed, 903 insertions(+)
create mode 100644 arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3588-turing-rk1.dts
create mode 100644 arch/arm/dts/rk3588-turing-rk1.dtsi
create mode 100644 board/turing/turing-rk1-rk3588/Kconfig
create mode 100644 board/turing/turing-rk1-rk3588/MAINTAINERS
create mode 100644 board/turing/turing-rk1-rk3588/Makefile
create mode 100644 board/turing/turing-rk1-rk3588/turing-rk1-rk3588.c
create mode 100644 configs/turing-rk1-rk3588_defconfig
create mode 100644 include/configs/turing-rk1-rk3588.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1be08c5fdc..97355d84de 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -195,6 +195,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588s-orangepi-5.dtb \
rk3588-orangepi-5-plus.dtb \
rk3588-quartzpro64.dtb \
+ rk3588-turing-rk1.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
diff --git a/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi
b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi
new file mode 100644
index 00..06c6f327c1
--- /dev/null
+++ b/arch/arm/dts/rk3588-turing-rk1-u-boot.dtsi
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Joshua Riek
+ *
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
+
+ {
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+};
+
+ {
+ bootph-pre-ram;
+ clock-frequency = <2400>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3588-turing-rk1.dts
b/arch/arm/dts/rk3588-turing-rk1.dts
new file mode 100644
index 00..7bcad28d73
--- /dev/null
+++ b/arch/arm/dts/rk3588-turing-rk1.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * This device tree covers the common case where the RK1 is used as a
+ * "compute node" system, where the carrier board is functioning more like a
+ * generic backplane (with no non-autoenumerable peripherals of its own) than
+ * like a device that the SoM is meant to enable.
+ *
+ * Copyright (c) 2023 Sam Edwards
+ */
+
+/dts-v1/;
+#include "rk3588-turing-rk1.dtsi"
+
+/ {
+ model = "Turing Machines RK1";
+ compatible = "turing,rk1", "rockchip,rk3588";
+
+ chosen {
+ stdout-path = "serial9:115200n8";
+ };
+};
diff --git a/arch/arm/dts/rk3588-turing-rk1.dtsi
b/arch/arm/dts/rk3588-turing-rk1.dtsi
new file mode 100644
index 00..9570b34aca
--- /dev/null
+++ b/arch/arm/dts/rk3588-turing-rk1.dtsi
@@ -0,0 +1,614 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree definitions for the Turing RK1 SoM.
+ *
+ * Copyright (c) 2023 Sam Edwards
+ *
+ * Based on RK3588-EVB1 devicetree
+ * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+#include
+#include
+#include "rk3588.dtsi"
+
+/ {
+ compatible = "turing,rk1", "rockchip,rk3588";
+
+ aliases {
+ ethernet0 =
+ mmc0 =
+ serial2 =
+ serial9 =
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 25 95 145 195 255>;
+ fan-supply = <_sys>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins _int>;
+ interrupt-parent = <>;
+ interrupts = ;
+ pwms = < 0 5 0>;
+ #cooling-cells = <2>;
+ };
+
+ vcc3v3_pcie30: vcc3v3-pcie30-regulator {
+ compatible = "regulator-fixed";
+
Re: [PATCH v4 1/8] binman: ti-secure: Add support for firewalling entities
Hi Manorit, This commit added a possibly unintentional dependency on python 3.9+. I ran into this while trying to build the soon-to-be-released 09.01.00.008. Build failure on ubuntu 20.04 which uses python 3.8: "binman: 'type' object is not subscriptable" This can be fixed by: diff --git a/tools/binman/etype/ti_secure.py b/tools/binman/etype/ti_secure.py index f80eb542c956..872c6d38ff46 100644 --- a/tools/binman/etype/ti_secure.py +++ b/tools/binman/etype/ti_secure.py @@ -16,7 +16,7 @@ class Firewall(): id: int region: int control : int -permissions: list[hex] +permissions: list start_address: str end_address: str > Hi Manorit, > > On Wed, 11 Oct 2023 at 23:02, Manorit Chawdhry wrote: > > > > Hi Simon, > > > > On 11:54-20231011, Manorit Chawdhry wrote: > > > We can now firewall entities while loading them through our secure > > > entity TIFS, the required information should be present in the > > > certificate that is being parsed by TIFS. > > > > > > The following commit adds the support to enable the certificates to be > > > generated if the firewall configurations are present in the binman dtsi > > > nodes. > > > > > > Signed-off-by: Manorit Chawdhry > > > --- > > [..] > > > tools/binman/btool/openssl.py | 16 +++- > > > tools/binman/etype/ti_secure.py | 90 > > > + > > > tools/binman/etype/x509_cert.py | 3 +- > > > 3 files changed, 106 insertions(+), 3 deletions(-) > > > > > > from binman.entry import EntryArg > > > from binman.etype.x509_cert import Entry_x509_cert > > > +from dataclasses import dataclass > > > > What all python versions do we support in u-boot? I see that dataclasses > > are in-built from python3.7 but for older versions we would need to > > install them separately, do I need to add this in buildman requirements > > for those versions? > > I would prefer not to worry about Python 3.6 if possible. There are a > few workarounds in buildman for it, though. > > Regards, > Simon
Re: [PATCH 1/7] doc: Update documentation URL
Hi Heinrich, On Thu, 14 Dec 2023 at 00:21, Heinrich Schuchardt wrote: > > > > Am 13. Dezember 2023 21:39:12 MEZ schrieb Simon Glass : > >Update to use the new docs.u-boot.org URL for documentation. > > Who owns that domain? Can we let http://www.u-boot.org forward to > https://docs.u-boot.org? I believe a website is in progress. Perhaps we should set a deadline to put something up by Christmas. If not, I can add a placeholder . Regards, Simon
Re: [PATCH RFC] dt-bindings: nvmem: u-boot, env: add any-name MAC cells compatible
Hi Rafał,
On Thu, 14 Dec 2023 at 08:36, Rafał Miłecki wrote:
>
> From: Rafał Miłecki
>
> So far we had a property for "ethaddr" NVMEM cell containing base
> Ethernet MAC address. The problem is vendors often pick non-standard
> names for storing MAC(s) (other than "ethaddr"). A few names were
> noticed over years:
> 1. "wanaddr" (Edimax, ELECOM, EnGenius, I-O DATA, Sitecom)
> 2. "et1macaddr" (ASUS)
> 3. "eth1addr" (Buffalo)
> 4. "athaddr" (EnGenius)
> 5. "baseMAC" (Netgear)
> 6. "mac" (Netgear)
> 7. "mac_addr" (Moxa)
> and more ("HW_LAN_MAC", "HW_WAN_MAC", "INIC_MAC_ADDR", "LAN_MAC_ADDR",
> "RADIOADDR0", "RADIOADDR1", "WAN_MAC_ADDR", "lan1_mac_addr", "wanmac",
> "wmac1", "wmac2").
>
> It doesn't make sense to add property for every possible MAC cell name.
> Instead allow specifying cells with "mac" compatible.
>
> Signed-off-by: Rafał Miłecki
> ---
> List of devices and their U-Boot MAC variables:
> alphanetworks,asl56026) wanmac
> asus,rt-ac65p) et1macaddr
> asus,rt-ac85p) et1macaddr
> belkin,f9k1109v1) HW_WAN_MAC + HW_LAN_MAC
> buffalo,ls220de) eth1addr
> buffalo,ls421de) eth1addr
> checkpoint,l-50) lan1_mac_addr
> dovado,tiny-ac) INIC_MAC_ADDR
> dovado,tiny-ac) LAN_MAC_ADDR + WAN_MAC_ADDR
> edimax,ra21s) wanaddr
> edimax,rg21s) wanaddr
> elecom,wrc-2533ghbk-i) wanaddr
> elecom,wrc-2533ghbk2-t) wanaddr
> engenius,ecb1200) athaddr
> engenius,ecb1750) athaddr
> engenius,epg5000) wanaddr
> engenius,epg600) wanaddr
> engenius,esr1200) wanaddr
> engenius,esr1750) wanaddr
> engenius,esr600) wanaddr
> engenius,esr600h) wanaddr
> engenius,esr900) wanaddr
> enterasys,ws-ap3705i) RADIOADDR0 + RADIOADDR1
> iodata,wn-ac1167dgr) wanaddr
> iodata,wn-ac1167gr) wanaddr
> iodata,wn-ac1600dgr) wanaddr
> iodata,wn-ac1600dgr2) wanaddr
> iodata,wn-ac733gr3) wanaddr
> iodata,wn-ag300dgr) wanaddr
> iodata,wnpr2600g) wanaddr
> moxa,awk-1137c) mac_addr
> netgear,wax220) mac
> netgear,wndap620) baseMAC
> netgear,wndap660) baseMAC
> ocedo,panda) wmac1 + wmac2
> sitecom,wlr-7100) wanaddr
> sitecom,wlr-8100) wanaddr
>
> .../devicetree/bindings/nvmem/u-boot,env.yaml | 33 +++
> 1 file changed, 33 insertions(+)
>
Are these upstream U-Boots, or just vendor forks?
Regards,
Simon
Re: Proposal: FIT support for extension boards / overlays
+Masahiro Yamada too
On Wed, 13 Dec 2023 at 01:22, Geert Uytterhoeven wrote:
>
> Hi,
>
> On Tue, Dec 12, 2023 at 4:52 PM Andrew Davis wrote:
> > On 12/12/23 8:05 AM, Simon Glass wrote:
> > > The devicetree files for a board can be quite large, perhaps around
> > > 60KB. To boot on any supported board, many of them need to be
> > > provided, typically hundreds.
> > >
> > > All boards for a particular SoC share common parts. It would be
> > > helpful to use overlays for common pieces, to reduce the overall size.
> > >
> >
> > For this to save much size we would need to have the SoC split
> > from each board that uses it. We don't have that in DT today.
> > There are some efforts in progress to help on this but until
> > then we will not get much here.
>
> Indeed.
>
> E.g. The Kingfisher board[1] is an extension for (various) ULCB
> boards[2], but we cannot use an overlay for the former, as the
> combinations need to have different top-level compatible (and model)
> values. Hence currently we use a .dtsi file and lots of extra .dts
> files[3].
>
> The other issue is the need for parameterization, due to slight
> differences in pins/signals on various base boards, or because the
> same connector is present multiple times (e.g. for multi-camera
> setups[4][5]).
>
> [1] arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
> [2] arch/arm64/boot/dts/renesas/*-ulcb.dts
> [3] arch/arm64/boot/dts/renesas/*-ulcb-kf.dts
> [4] arch/arm/boot/dts/renesas/r8a7742-iwg21d-q7-dbcm-ov5640-single.dtsi
> [5] arch/arm/boot/dts/renesas/r8a7742-iwg21d-q7-dbcm-ov7725-single.dtsi
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: [PATCH v6 1/3] dt-bindings: mtd: partitions: Add binman compatible
Hi Rob, On Thu, 14 Dec 2023 at 10:27, Rob Herring wrote: > > On Fri, Dec 08, 2023 at 03:58:10PM -0700, Simon Glass wrote: > > Hi Rob, > > > > On Fri, 8 Dec 2023 at 14:56, Rob Herring wrote: > > > > > > On Fri, Dec 8, 2023 at 11:47 AM Simon Glass wrote: > > > > > > > > Hi Rob, > > > > > > > > On Fri, 8 Dec 2023 at 08:00, Rob Herring wrote: > > > > > > > > > > On Thu, Nov 16, 2023 at 10:28:50AM -0700, Simon Glass wrote: > > > > > > Add a compatible string for binman, so we can extend > > > > > > fixed-partitions > > > > > > in various ways. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > --- > > > > > > > > > > > > (no changes since v5) > > > > > > > > > > > > Changes in v5: > > > > > > - Add #address/size-cells and parternProperties > > > > > > - Drop $ref to fixed-partitions.yaml > > > > > > - Drop 'select: false' > > > > > > > > > > > > Changes in v4: > > > > > > - Change subject line > > > > > > > > > > > > Changes in v3: > > > > > > - Drop fixed-partition additional compatible string > > > > > > - Drop fixed-partitions from the example > > > > > > - Mention use of compatible instead of label > > > > > > > > > > > > Changes in v2: > > > > > > - Drop mention of 'enhanced features' in fixed-partitions.yaml > > > > > > - Mention Binman input and output properties > > > > > > - Use plain partition@xxx for the node name > > > > > > > > > > > > .../bindings/mtd/partitions/binman.yaml | 68 > > > > > > +++ > > > > > > .../bindings/mtd/partitions/partitions.yaml | 1 + > > > > > > MAINTAINERS | 5 ++ > > > > > > 3 files changed, 74 insertions(+) > > > > > > create mode 100644 > > > > > > Documentation/devicetree/bindings/mtd/partitions/binman.yaml > > > > > > > > > > > > diff --git > > > > > > a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml > > > > > > b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml > > > > > > new file mode 100644 > > > > > > index ..329217550a98 > > > > > > --- /dev/null > > > > > > +++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml > > > > > > @@ -0,0 +1,68 @@ > > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > > > > +# Copyright 2023 Google LLC > > > > > > + > > > > > > +%YAML 1.2 > > > > > > +--- > > > > > > +$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml# > > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > > + > > > > > > +title: Binman firmware layout > > > > > > + > > > > > > +maintainers: > > > > > > + - Simon Glass > > > > > > + > > > > > > +description: | > > > > > > + The binman node provides a layout for firmware, used when > > > > > > packaging firmware > > > > > > + from multiple projects. It is based on fixed-partitions, with > > > > > > some > > > > > > + extensions, but uses 'compatible' to indicate the contents of > > > > > > the node, to > > > > > > + avoid perturbing or confusing existing installations which use > > > > > > 'label' for a > > > > > > + particular purpose. > > > > > > + > > > > > > + Binman supports properties used as inputs to the > > > > > > firmware-packaging process, > > > > > > + such as those which control alignment of partitions. This > > > > > > binding addresses > > > > > > + these 'input' properties. For example, it is common for the > > > > > > 'reg' property > > > > > > + (an 'output' property) to be set by Binman, based on the > > > > > > alignment requested > > > > > > + in the input. > > > > > > + > > > > > > + Once processing is complete, input properties have mostly served > > > > > > their > > > > > > + purpose, at least until the firmware is repacked later, e.g. due > > > > > > to a > > > > > > + firmware update. The 'fixed-partitions' binding should provide > > > > > > enough > > > > > > + information to read the firmware at runtime, including > > > > > > decompression if > > > > > > + needed. > > > > > > > > > > How is this going to work exactly? binman reads these nodes and then > > > > > writes out 'fixed-partitions' nodes. But then you've lost the binman > > > > > specifc parts needed for repacking. > > > > > > > > No, they are the same node. I do want the extra information to stick > > > > around. So long as it is compatible with fixed-partition as well, this > > > > should work OK. > > > > > > How can it be both? The partitions node compatible can be either > > > 'fixed-partitions' or 'binman'. > > > > Can we not allow it to be both? I have tried to adjust things in > > response to feedback but perhaps the feedback was leading me down the > > wrong path? > > Sure, but then the schema has to and that means extending > fixed-partitions. Can we cross that bridge later? There might be resistance to it. I'm not sure. For now, perhaps just a binman compatible works well enough to make progress. Regards, Simon
Re: [GIT PULL] xilinx patches for v2024.04-rc1
On Thu, Dec 14, 2023 at 04:50:53PM +0100, Michal Simek wrote: > Hi Tom, > > please pull these patches to your next branch. There is nothing > controversial from my point of view. The biggest change is to create new > kria defconfig to target couple of boards based on ZynqMP. There is going to > be work related to binman to start to composing boot images and especially > FIT image with dtb+dtbo together. That's why I am expecting more patches to > come for 2024.04 but I want to clean my queue now to get these patches for > testing. > > Thanks, > Michal > > > he following changes since commit be4a5f7c35685d228b3abc398a8d86c434274de5: > > test: bdinfo: Handle systems without getopt (2023-12-10 10:08:30 -0500) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2024.04-rc1 > > for you to fetch changes up to 4f340244b974d52c48e01cb845cfe8315f7e5764: > > clk: zynqmp: enable topsw_lsbus clock (2023-12-13 16:48:15 +0100) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/17] Introduce initial TI's J784S4 and AM69 support
On 12/14/23 2:10 PM, b...@ti.com wrote: On December 14, 2023 thus sayeth Marcel Ziswiler: Hi Apurva Thanks! On Wed, 2023-12-06 at 18:07 +0530, Apurva Nandan wrote: Hello Everyone! This series will introduce basic support (SD and UART) support for Texas Instruments J784S4 EVM. For the whole series: Tested-by: Marcel Ziswiler However, one thing I noticed is that with upstream TF-A I do get the following errors: NOTICE: BL31: v2.10.0 (release):v2.10.0-76-g02091541d NOTICE: BL31: Built : 18:13:08, Dec 14 2023 ERROR: Failed to get response (-19) ERROR: Transfer send failed (-19) ERROR: Unable to query firmware capabilities (-19) While with latest TF-A from downstream TI BSP (both 9.0 and 9.1 use the same versin) I do not get any errors: NOTICE: BL31: v2.9(release):v2.9.0-614-gd7a7135d3 NOTICE: BL31: Built : 18:40:38, Dec 14 2023 What version of TIFS are you running? Not getting a response usually means firmware is dead or we're not using the right thread to talk. In this case the early versions of TIFS/DM for J784S4/AM69 had a bug where the "query firmware capabilities" API was left disabled. This is fixed in the next version of firmware, this error message is harmless today anyway (no LPM yet). Andrew
Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot
On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote: > On Thu, Dec 14, 2023 at 12:23 PM Tom Rini wrote: > > > > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstr...@linaro.org wrote: > > > Hi, > > > > > > On 14/12/2023 14:50, Sumit Garg wrote: > > > > Prerquisite > > > > > > s/Prerquisite/Prerequisite/ > > > > > > > --- > > > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > > subtree to the main U-boot repo via: > > > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > > \ > > > >v6.6-dts --squash > > > > > > So I think the big question is: when should the subtree be updated ? > > > > > > Because as we discussed in the previous GH pull request, if a bindings > > > changes > > > was made in the upstream Linux DT, then the subtree update should wait > > > until > > > the u-boot support is merged before updating. This could cause a lot of > > > frustration. > > > > > > And this could cause a lot of regressions, even more if both Linux and > > > U-boot are > > > not maintained by the same people. > > > > I think some of the important questions to ask are, how often / likely > > are the breakages to occur? It seems like these days it's either: > > - U-Boot had an early version of the binding and we already state we > > don't support backwards compatibility here. It should be on the > > maintainer to be proactive in this case. > > - It's a "the DT was wrong about the hardware, sorry not sorry it's an > > incompatible DTS change now". This too is hopefully the kind of thing > > that at least board maintainers will be more actively aware of needing > > to deal with in U-Boot, if it's really a problem. > > A common issue in the kernel is with forward compatibility when > platforms add new resources from a new provider. Then the kernel > expects a driver for the provider and waits for the dependency. Of > course, older kernels don't have that provider driver and so the > dependency is never met. Not sure if u-boot will have similar issues? > At least you should/could know if the provider driver exists or not. > (The kernel doesn't because modules.) I think we'll be fine, but time will tell. And perhaps the more frequent re-syncing will make any sort of corner cases show up more quickly and be something we can figure out how to resolve going forward really. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/17] Introduce initial TI's J784S4 and AM69 support
On December 14, 2023 thus sayeth Marcel Ziswiler: > Hi Apurva > > Thanks! > > On Wed, 2023-12-06 at 18:07 +0530, Apurva Nandan wrote: > > Hello Everyone! > > > > This series will introduce basic support (SD and UART) support for Texas > > Instruments J784S4 EVM. > > For the whole series: > > Tested-by: Marcel Ziswiler > > However, one thing I noticed is that with upstream TF-A I do get the > following errors: > > NOTICE: BL31: v2.10.0 (release):v2.10.0-76-g02091541d > NOTICE: BL31: Built : 18:13:08, Dec 14 2023 > ERROR: Failed to get response (-19) > ERROR: Transfer send failed (-19) > ERROR: Unable to query firmware capabilities (-19) > > While with latest TF-A from downstream TI BSP (both 9.0 and 9.1 use the same > versin) I do not get any errors: > > NOTICE: BL31: v2.9(release):v2.9.0-614-gd7a7135d3 > NOTICE: BL31: Built : 18:40:38, Dec 14 2023 > What version of TIFS are you running? Not getting a response usually means firmware is dead or we're not using the right thread to talk. ~Bryan
Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot
On Thu, Dec 14, 2023 at 12:23 PM Tom Rini wrote: > > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstr...@linaro.org wrote: > > Hi, > > > > On 14/12/2023 14:50, Sumit Garg wrote: > > > Prerquisite > > > > s/Prerquisite/Prerequisite/ > > > > > --- > > > > > > This patch series requires devicetree-rebasing git repo to be added as a > > > subtree to the main U-boot repo via: > > > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > \ > > >v6.6-dts --squash > > > > So I think the big question is: when should the subtree be updated ? > > > > Because as we discussed in the previous GH pull request, if a bindings > > changes > > was made in the upstream Linux DT, then the subtree update should wait until > > the u-boot support is merged before updating. This could cause a lot of > > frustration. > > > > And this could cause a lot of regressions, even more if both Linux and > > U-boot are > > not maintained by the same people. > > I think some of the important questions to ask are, how often / likely > are the breakages to occur? It seems like these days it's either: > - U-Boot had an early version of the binding and we already state we > don't support backwards compatibility here. It should be on the > maintainer to be proactive in this case. > - It's a "the DT was wrong about the hardware, sorry not sorry it's an > incompatible DTS change now". This too is hopefully the kind of thing > that at least board maintainers will be more actively aware of needing > to deal with in U-Boot, if it's really a problem. A common issue in the kernel is with forward compatibility when platforms add new resources from a new provider. Then the kernel expects a driver for the provider and waits for the dependency. Of course, older kernels don't have that provider driver and so the dependency is never met. Not sure if u-boot will have similar issues? At least you should/could know if the provider driver exists or not. (The kernel doesn't because modules.) Rob
Re: Adding EFI runtime support to the Arm's FF-A bus
Hi Mark, Abdellatif On Thu, 14 Dec 2023 at 18:47, Mark Kettenis wrote: > > > Date: Thu, 14 Dec 2023 15:53:46 + > > From: Abdellatif El Khlifi > > Hi Abdellatif, > > > Hi guys, > > > > I'd like to ask for advice regarding adding EFI RT support to the Arm's > > FF-A bus > > in U-Boot. > > > > The objective is to enable the FF-A messaging APIs in EFI RT to be > > used for comms with the secure world. This will help getting/setting > > EFI variables through FF-A. > > > > The existing FF-A APIs in U-Boot call the DM APIs (which are not available > > at RT). > > > > Two possible solutions: > > > > 1/ having the entire U-Boot in RT space (as Simon stated in this > > discussion[1]) > > I don't think this is a terribly good idea. With this approach orders > of magnitude more code will be present in kernel address space one the > OS kernel is running and calling into the EFI runtime. Including code > that may access hardware devices that are now under OS control. It > will be nigh impossible to audit all that code and make sure that only > a safe subset of it gets called. So... +100 I think we should draw a line here. I mentioned it on another thread, but I did a shot BoF in Plumbers discussing issues like this, problems, and potential solutions [0] [1]. Since that talk patches for the kernel that 'solve' the problem for RPMBs got pulled into linux-next [2]. The TL;DR of that talk is that if the kernel ends up being in control of the hardware that stores the EFI variables, we need to find elegant ways to teach the kernel how to store those directly. The EFI requirement of an isolated flash is something that mostly came from the x86 world and is not a reality on the majority of embedded boards. I also think we should give up on Authenticated EFI variables in that case. We get zero guarantees unless the medium has similar properties to an RPMB. If a vendor cares about proper UEFI secure boot he can implement proper hardware. > > > > > 2/ Create an RT variant for the FF-A APIs needed. > > These RT variant don't call the DM APIs > > (e.g: ffa_mm_communicate_runtime, ffa_sync_send_receive_runtime, ...) > > > > What do you recommend please ? > > ...this is what I would recommend. Preferably in a way that refactors > the code such that the low-level functionality is shared between the > DM and non-DM APIs. Yes. The only thing you need to keep alive is the machinery to talk to the secure world. The bus, flash driver etc should all be running isolated in there. In that case you can implement SetVariableRT as described the the EFI spec. [...] [0] https://www.youtube.com/watch?v=UdQk0SCUAlA [1] https://lpc.events/event/17/contributions/1653/attachments/1338/2682/Plumbers%20-%20EFI%20setvariable%20problems%20and%20solutions.pdf [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c44b6be62e8dd4ee0a308c36a70620613e6fc55f /Ilias
Re: [PATCH] spi: cadence-quadspi: Fix error message on stuck busy state
On Mon, Oct 30, 2023 at 9:50 PM Jan Kiszka wrote: > > From: Jan Kiszka > > We are not iterating CQSPI_REG_RETRY, we are waiting 'timeout' ms, since > day 1. > > Signed-off-by: Jan Kiszka > --- Applied to u-boot-spi/master
Re: [PATCH] mtd: spi-nor-ids: add support for xtx XT55Q02G
On Wed, Oct 18, 2023 at 9:08 AM Bruce Suen wrote: > > Add support for XTX XT55Q02G(1.8V,2Gbit). > > Signed-off-by: Bruce Suen > --- Applied to u-boot-spi/master
[PATCH V2] board: rockchip: add Powkiddy X55
From: Chris Morgan
The Powkiddy X55 is a Rockchip RK3566 based handheld gaming device.
UART, ADC, eMMC, and SDMMC are tested to work in U-Boot and this
successfully boots mainline Linux.
Changes since V1:
- Built on top of this patch series [1] which makes the ADC detect
function more generic and also moves the board_rng_seed to a more
generic location.
- Updated U-Boot specific devicetree to drop redundant values and
add nodes required for ADC detection in SPL.
- Updated defconfig to add additional options for SPL ADC detection
logic as well as drop some drivers that are not needed. Note that
CONFIG_DM_PMIC_FAN53555 is used by the tcs,tcs4525 regulator on
i2c0 at 0x1c. Additionally the code fails to compile without
selecting CONFIG_SPL_ROCKCHIP_BACK_TO_BROM.
[1]
https://lore.kernel.org/u-boot/20231211232125.171438-1-macroalph...@gmail.com/
Signed-off-by: Chris Morgan
---
arch/arm/dts/Makefile| 1 +
arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi | 67 ++
arch/arm/dts/rk3566-powkiddy-x55.dts | 926 +++
arch/arm/mach-rockchip/rk3568/Kconfig| 6 +
board/powkiddy/x55/Kconfig | 15 +
board/powkiddy/x55/MAINTAINERS | 9 +
board/powkiddy/x55/Makefile | 6 +
board/powkiddy/x55/x55.c | 42 +
configs/powkiddy-x55-rk3566_defconfig| 92 ++
doc/board/index.rst | 1 +
doc/board/powkiddy/index.rst | 9 +
doc/board/powkiddy/x55.rst | 25 +
doc/board/rockchip/rockchip.rst | 1 +
include/configs/powkiddy-x55-rk3566.h| 14 +
14 files changed, 1214 insertions(+)
create mode 100644 arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3566-powkiddy-x55.dts
create mode 100644 board/powkiddy/x55/Kconfig
create mode 100644 board/powkiddy/x55/MAINTAINERS
create mode 100644 board/powkiddy/x55/Makefile
create mode 100644 board/powkiddy/x55/x55.c
create mode 100644 configs/powkiddy-x55-rk3566_defconfig
create mode 100644 doc/board/powkiddy/index.rst
create mode 100644 doc/board/powkiddy/x55.rst
create mode 100644 include/configs/powkiddy-x55-rk3566.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5fc888680b..6e5cb7c3e9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -172,6 +172,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-anbernic-rgxx3.dtb \
+ rk3566-powkiddy-x55.dtb \
rk3566-quartz64-a.dtb \
rk3566-quartz64-b.dtb \
rk3566-radxa-cm3-io.dtb \
diff --git a/arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi
b/arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi
new file mode 100644
index 00..1a3089b598
--- /dev/null
+++ b/arch/arm/dts/rk3566-powkiddy-x55-u-boot.dtsi
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path =
+ };
+
+ rng: rng@fe388000 {
+ compatible = "rockchip,cryptov2-rng";
+ reg = <0x0 0xfe388000 0x0 0x2000>;
+ status = "okay";
+ };
+};
+
+ {
+ assigned-clocks =
+ < CLK_RTC_32K>, < PLL_PPLL>,
+ < PCLK_PMU>, < PLL_CPLL>,
+ < PLL_GPLL>, < PLL_VPLL>,
+ < ACLK_BUS>, < PCLK_BUS>,
+ < ACLK_TOP_HIGH>, < ACLK_TOP_LOW>,
+ < HCLK_TOP>, < PCLK_TOP>,
+ < ACLK_PERIMID>, < HCLK_PERIMID>,
+ < CPLL_500M>, < CPLL_333M>,
+ < CPLL_250M>, < CPLL_125M>,
+ < CPLL_100M>, < CPLL_62P5M>,
+ < CPLL_50M>, < CPLL_25M>;
+ assigned-clock-rates =
+ <32768>, <2>,
+ <1>, <10>,
+ <12>, <12640>,
+ <15000>, <1>,
+ <5>, <4>,
+ <15000>, <1>,
+ <3>, <15000>,
+ <5>, <3>,
+ <25000>, <12500>,
+ <1>, <6250>,
+ <5000>, <2500>;
+ assigned-clock-parents =
+ < CLK_RTC32K_FRAC>;
+};
+
+ {
+ assigned-clocks = < SCLK_32K_IOE>;
+ assigned-clock-parents = < CLK_RTC_32K>;
+};
+
+/* Move the saradc to a fixed regulator so that it works in SPL. */
+ {
+ bootph-all;
+ vref-supply = <_sys>;
+ status = "okay";
+};
+
+ {
+ clock-frequency = <2400>;
+ bootph-all;
+ status = "okay";
+};
+
+_sys {
+ bootph-all;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3566-powkiddy-x55.dts
Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot
On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstr...@linaro.org wrote: > Hi, > > On 14/12/2023 14:50, Sumit Garg wrote: > > Prerquisite > > s/Prerquisite/Prerequisite/ > > > --- > > > > This patch series requires devicetree-rebasing git repo to be added as a > > subtree to the main U-boot repo via: > > > > $ git subtree add --prefix devicetree-rebasing \ > > > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > \ > >v6.6-dts --squash > > So I think the big question is: when should the subtree be updated ? > > Because as we discussed in the previous GH pull request, if a bindings changes > was made in the upstream Linux DT, then the subtree update should wait until > the u-boot support is merged before updating. This could cause a lot of > frustration. > > And this could cause a lot of regressions, even more if both Linux and U-boot > are > not maintained by the same people. I think some of the important questions to ask are, how often / likely are the breakages to occur? It seems like these days it's either: - U-Boot had an early version of the binding and we already state we don't support backwards compatibility here. It should be on the maintainer to be proactive in this case. - It's a "the DT was wrong about the hardware, sorry not sorry it's an incompatible DTS change now". This too is hopefully the kind of thing that at least board maintainers will be more actively aware of needing to deal with in U-Boot, if it's really a problem. So I would plan on grabbing only full kernel releases and in to -next as soon as possible. Our cadences don't match up exactly, but I think do fairly well enough. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/1] mtd: spinand: add support for ESMT F50x1G41LB
On Wed, Oct 18, 2023 at 12:59 AM Igor Prusov wrote: > > Adaptation of Linux commit d74c36480a67 > > This patch adds support for ESMT F50L1G41LB and F50D1G41LB. > It seems that ESMT likes to use random JEDEC ID from other vendors. > Their 1G chips uses 0xc8 from GigaDevice and 2G/4G chips uses 0x2c from > Micron. For this reason, the ESMT entry is named esmt_c8 with explicit > JEDEC ID in variable name. > > Datasheets: > https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50L1G41LB(2M).pdf > https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/F50D1G41LB(2M).pdf > > Signed-off-by: Igor Prusov > Signed-off-by: Chuanhong Guo > Signed-off-by: Martin Kurbanov > Signed-off-by: Dmitry Rokosov > Tested-by: Martin Kurbanov > --- Applied to u-boot-spi/master
[v2 16/16] lib: Remove inclusion from these files
After some header file cleanups to add missing include files, remove common.h from all files in the lib directory. This primarily means just dropping the line but in a few cases we need to add in other header files now. Signed-off-by: Tom Rini Reviewed-by: Simon Glass --- lib/abuf.c| 1 - lib/acpi/acpi.c | 1 - lib/acpi/acpi_device.c| 1 - lib/acpi/acpi_dp.c| 1 - lib/acpi/acpi_table.c | 1 - lib/acpi/acpi_writer.c| 2 +- lib/acpi/acpigen.c| 1 - lib/acpi/base.c | 3 ++- lib/acpi/csrt.c | 2 +- lib/acpi/dsdt.c | 2 +- lib/acpi/facs.c | 2 +- lib/acpi/mcfg.c | 4 +++- lib/acpi/ssdt.c | 3 ++- lib/addr_map.c| 1 - lib/aes.c | 2 +- lib/aes/aes-decrypt.c | 1 - lib/asm-offsets.c | 2 +- lib/at91/at91.c | 1 - lib/bch.c | 1 - lib/binman.c | 1 - lib/bzip2/bzlib.c | 3 +-- lib/bzip2/bzlib_decompress.c | 1 - lib/charset.c | 1 - lib/circbuf.c | 1 - lib/crc16-ccitt.c | 2 -- lib/crc32.c | 1 - lib/crc32c.c | 1 - lib/crc8.c| 2 -- lib/crypt/crypt-port.h| 3 +++ lib/crypt/crypt.c | 1 - lib/crypto/x509_public_key.c | 1 - lib/date.c| 1 - lib/dhry/cmd_dhry.c | 3 ++- lib/dhry/dhry_1.c | 2 +- lib/dhry/dhry_2.c | 2 +- lib/efi/efi.c | 1 - lib/efi/efi_app.c | 1 - lib/efi/efi_info.c| 1 - lib/efi/efi_stub.c| 1 - lib/efi_driver/efi_block_device.c | 1 - lib/efi_driver/efi_uclass.c | 1 - lib/efi_selftest/efi_selftest_esrt.c | 1 - lib/efi_selftest/efi_selftest_miniapp_exception.c | 1 - lib/efi_selftest/efi_selftest_miniapp_exit.c | 1 - lib/efi_selftest/efi_selftest_miniapp_return.c| 1 - lib/elf.c | 1 - lib/errno_str.c | 2 +- lib/fdtdec.c | 1 - lib/fdtdec_common.c | 1 - lib/fdtdec_test.c | 1 - lib/getopt.c | 2 +- lib/gunzip.c | 1 - lib/gzip.c| 1 - lib/hang.c| 2 +- lib/hash-checksum.c | 1 - lib/hashtable.c | 1 - lib/hexdump.c | 2 +- lib/image-sparse.c| 1 - lib/initcall.c| 1 - lib/linux_compat.c| 1 - lib/list_sort.c | 1 - lib/lmb.c | 1 - lib/lz4.c | 1 - lib/lz4_wrapper.c | 1 - lib/lzma/LzmaDec.c| 1 - lib/lzma/LzmaTools.c | 1 - lib/lzo/lzo1x_decompress.c| 3 ++- lib/md5.c | 1 - lib/membuff.c | 1 - lib/net_utils.c | 2 +- lib/of_live.c | 1 - lib/optee/optee.c | 1 - lib/panic.c | 1 - lib/physmem.c | 2 +- lib/qsort.c | 1 - lib/rand.c| 1 - lib/rc4.c | 3 --- lib/rsa/rsa-keyprop.c | 1 - lib/rsa/rsa-mod-exp.c | 1 - lib/rsa/rsa-verify.c | 1 - lib/rtc-lib.c | 1 - lib/semihosting.c | 3 ++- lib/slre.c
[v2 15/16] include: Further cleanup includes
Add some missing headers such as or or
to header files that make direct usage of things
provided by these headers.
Signed-off-by: Tom Rini
Reviewed-by: Simon Glass
---
include/atmel_lcd.h | 2 ++
include/getopt.h| 2 ++
include/mapmem.h| 2 ++
include/memalign.h | 1 +
include/net6.h | 1 +
include/rtc.h | 1 +
6 files changed, 9 insertions(+)
diff --git a/include/atmel_lcd.h b/include/atmel_lcd.h
index 66436b9b2772..a115d6c17014 100644
--- a/include/atmel_lcd.h
+++ b/include/atmel_lcd.h
@@ -9,6 +9,8 @@
#ifndef _ATMEL_LCD_H_
#define _ATMEL_LCD_H_
+#include
+
/**
* struct atmel_lcd_plat - platform data for Atmel LCDs with driver model
*
diff --git a/include/getopt.h b/include/getopt.h
index 6f5811e64be9..8645082da2a7 100644
--- a/include/getopt.h
+++ b/include/getopt.h
@@ -9,6 +9,8 @@
#ifndef __GETOPT_H
#define __GETOPT_H
+#include
+
/**
* struct getopt_state - Saved state across getopt() calls
*/
diff --git a/include/mapmem.h b/include/mapmem.h
index 2134c8004d94..bb68b4c11afd 100644
--- a/include/mapmem.h
+++ b/include/mapmem.h
@@ -13,6 +13,8 @@
# ifdef CONFIG_ARCH_MAP_SYSMEM
#include
# else
+#include
+
static inline void *map_sysmem(phys_addr_t paddr, unsigned long len)
{
return (void *)(uintptr_t)paddr;
diff --git a/include/memalign.h b/include/memalign.h
index f67f0a74f2e8..eaa9f6b5cbd6 100644
--- a/include/memalign.h
+++ b/include/memalign.h
@@ -11,6 +11,7 @@
* is used to align DMA buffers.
*/
#ifndef __ASSEMBLY__
+#include
#include
#include
diff --git a/include/net6.h b/include/net6.h
index 1e766aa72092..1ed989e584ae 100644
--- a/include/net6.h
+++ b/include/net6.h
@@ -12,6 +12,7 @@
#include
#include
+#include
/* struct in6_addr - 128 bits long IPv6 address */
struct in6_addr {
diff --git a/include/rtc.h b/include/rtc.h
index b6fdbb60dc2b..22f6d3705917 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
typedef int64_t time64_t;
struct udevice;
--
2.34.1
[v2 13/16] efi_loader: Remove
We largely do not need in these files, so drop it. The only exception here is that efi_freestanding.c needs and had been getting that via . Signed-off-by: Tom Rini --- lib/efi_loader/dtbdump.c | 1 - lib/efi_loader/efi_acpi.c | 1 - lib/efi_loader/efi_bootmgr.c | 1 - lib/efi_loader/efi_boottime.c | 1 - lib/efi_loader/efi_capsule.c | 1 - lib/efi_loader/efi_conformance.c | 1 - lib/efi_loader/efi_console.c | 1 - lib/efi_loader/efi_device_path.c | 1 - lib/efi_loader/efi_device_path_to_text.c | 1 - lib/efi_loader/efi_device_path_utilities.c | 1 - lib/efi_loader/efi_disk.c | 1 - lib/efi_loader/efi_dt_fixup.c | 1 - lib/efi_loader/efi_esrt.c | 1 - lib/efi_loader/efi_file.c | 1 - lib/efi_loader/efi_firmware.c | 1 - lib/efi_loader/efi_freestanding.c | 2 +- lib/efi_loader/efi_gop.c | 1 - lib/efi_loader/efi_helper.c| 1 - lib/efi_loader/efi_hii.c | 1 - lib/efi_loader/efi_hii_config.c| 1 - lib/efi_loader/efi_image_loader.c | 1 - lib/efi_loader/efi_load_initrd.c | 1 - lib/efi_loader/efi_load_options.c | 1 - lib/efi_loader/efi_memory.c| 1 - lib/efi_loader/efi_net.c | 1 - lib/efi_loader/efi_riscv.c | 1 - lib/efi_loader/efi_rng.c | 1 - lib/efi_loader/efi_root_node.c | 1 - lib/efi_loader/efi_runtime.c | 1 - lib/efi_loader/efi_setup.c | 1 - lib/efi_loader/efi_signature.c | 1 - lib/efi_loader/efi_smbios.c| 1 - lib/efi_loader/efi_string.c| 1 - lib/efi_loader/efi_tcg2.c | 1 - lib/efi_loader/efi_unicode_collation.c | 1 - lib/efi_loader/efi_var_common.c| 1 - lib/efi_loader/efi_var_file.c | 1 - lib/efi_loader/efi_var_mem.c | 1 - lib/efi_loader/efi_variable.c | 1 - lib/efi_loader/efi_variable_tee.c | 1 - lib/efi_loader/efi_watchdog.c | 1 - lib/efi_loader/initrddump.c| 1 - 42 files changed, 1 insertion(+), 42 deletions(-) diff --git a/lib/efi_loader/dtbdump.c b/lib/efi_loader/dtbdump.c index 3ce2a07f9eb0..5f39cf22da79 100644 --- a/lib/efi_loader/dtbdump.c +++ b/lib/efi_loader/dtbdump.c @@ -6,7 +6,6 @@ * to a file. */ -#include #include #include #include diff --git a/lib/efi_loader/efi_acpi.c b/lib/efi_loader/efi_acpi.c index f755af76f866..67bbd2a01c0b 100644 --- a/lib/efi_loader/efi_acpi.c +++ b/lib/efi_loader/efi_acpi.c @@ -5,7 +5,6 @@ * Copyright (C) 2018, Bin Meng */ -#include #include #include #include diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c index 48153bd5ffbb..4e42a8d694fd 100644 --- a/lib/efi_loader/efi_bootmgr.c +++ b/lib/efi_loader/efi_bootmgr.c @@ -9,7 +9,6 @@ #include #include -#include #include #include #include diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 3767fa2db429..7c5b5abb187e 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -5,7 +5,6 @@ * Copyright (c) 2016 Alexander Graf */ -#include #include #include #include diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c index af8a2ee940ce..de0d49ebebda 100644 --- a/lib/efi_loader/efi_capsule.c +++ b/lib/efi_loader/efi_capsule.c @@ -8,7 +8,6 @@ #define LOG_CATEGORY LOGC_EFI -#include #include #include #include diff --git a/lib/efi_loader/efi_conformance.c b/lib/efi_loader/efi_conformance.c index 0ca26f57a7f2..167067e26cd1 100644 --- a/lib/efi_loader/efi_conformance.c +++ b/lib/efi_loader/efi_conformance.c @@ -5,7 +5,6 @@ * Copyright (C) 2022 Arm Ltd. */ -#include #include #include #include diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c index a2d137d7a9e1..03dece51aeaa 100644 --- a/lib/efi_loader/efi_console.c +++ b/lib/efi_loader/efi_console.c @@ -8,7 +8,6 @@ #define LOG_CATEGORY LOGC_EFI #include -#include #include #include #include diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c index ed7214f3a347..8dbd8105ae26 100644 --- a/lib/efi_loader/efi_device_path.c +++ b/lib/efi_loader/efi_device_path.c @@ -7,7 +7,6 @@ #define LOG_CATEGORY LOGC_EFI -#include #include #include #include diff --git a/lib/efi_loader/efi_device_path_to_text.c b/lib/efi_loader/efi_device_path_to_text.c index 8c76d8be605d..0c7b30a26e7e 100644 --- a/lib/efi_loader/efi_device_path_to_text.c +++ b/lib/efi_loader/efi_device_path_to_text.c @@ -5,7 +5,6 @@ * Copyright (c) 2017 Heinrich Schuchardt */ -#include #include #include #include diff --git a/lib/efi_loader/efi_device_path_utilities.c
[v2 14/16] display_options: Clean up headers
In include/display_options.h we cannot include ourself, but do need directly. Then in lib/display_options.c we further clean the list to remove common.h. Signed-off-by: Tom Rini Reviewed-by: Simon Glass --- lib/display_options.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/display_options.c b/lib/display_options.c index 80def5201f96..d6b93553dcb5 100644 --- a/lib/display_options.c +++ b/lib/display_options.c @@ -4,14 +4,15 @@ * Wolfgang Denk, DENX Software Engineering, w...@denx.de. */ -#include #include #include #include #include #include #include +#include #include +#include char *display_options_get_banner_priv(bool newlines, const char *build_tag, char *buf, int size) -- 2.34.1
[v2 12/16] rmobile: Add to cpu_info-rzg2l.c
In order for RMOBILE_CPU_TYPE_R9A07G044L to be defined we need to include here. Signed-off-by: Tom Rini Reviewed-by: Marek Vasut --- arch/arm/mach-rmobile/cpu_info-rzg2l.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rmobile/cpu_info-rzg2l.c b/arch/arm/mach-rmobile/cpu_info-rzg2l.c index f69649dc7eaf..bd3146fb011f 100644 --- a/arch/arm/mach-rmobile/cpu_info-rzg2l.c +++ b/arch/arm/mach-rmobile/cpu_info-rzg2l.c @@ -4,6 +4,7 @@ * */ +#include #include #include -- 2.34.1
[v2 11/16] lib/sha*.c: Update header list
Cleanup the list of headers we include here. For the tools build we only
need to exclude as that's used by the target build for the
prototype for schedule(), and we don't need to get that via
. We can also make use of our intentionally
existing as a redirection to to reduce ifdef'd lines.
Signed-off-by: Tom Rini
---
lib/sha1.c | 7 ++-
lib/sha256.c | 7 ++-
lib/sha512.c | 6 +-
3 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/lib/sha1.c b/lib/sha1.c
index 8d0740789349..7ef536f4b5db 100644
--- a/lib/sha1.c
+++ b/lib/sha1.c
@@ -17,12 +17,9 @@
#endif
#ifndef USE_HOSTCC
-#include
-#include
-#else
-#include
+#include
#endif /* USE_HOSTCC */
-#include
+#include
#include
#include
diff --git a/lib/sha256.c b/lib/sha256.c
index 4d26aea1c8ce..665ba6f152e5 100644
--- a/lib/sha256.c
+++ b/lib/sha256.c
@@ -6,12 +6,9 @@
*/
#ifndef USE_HOSTCC
-#include
-#include
-#else
-#include
+#include
#endif /* USE_HOSTCC */
-#include
+#include
#include
#include
diff --git a/lib/sha512.c b/lib/sha512.c
index fbe8d5f5bfe9..ffe2c5cd9642 100644
--- a/lib/sha512.c
+++ b/lib/sha512.c
@@ -11,13 +11,9 @@
*/
#ifndef USE_HOSTCC
-#include
-#include
-#else
-#include
+#include
#endif /* USE_HOSTCC */
#include
-#include
#include
const uint8_t sha384_der_prefix[SHA384_DER_LEN] = {
--
2.34.1
[v2 09/16] m68k: Rework asm/global_data.h slightly
In the architecture global data, replace the one case of u32 with
unsigned long. Now, we can drop config.h here but then do need to add it
in two m68k-centric spaces.
Signed-off-by: Tom Rini
Acked-by: Angelo Dureghello
---
arch/m68k/include/asm/cache.h | 2 ++
arch/m68k/include/asm/global_data.h | 4 +---
arch/m68k/lib/traps.c | 1 +
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/m68k/include/asm/cache.h b/arch/m68k/include/asm/cache.h
index 8ed2b4dbab47..6ef7f7be1af8 100644
--- a/arch/m68k/include/asm/cache.h
+++ b/arch/m68k/include/asm/cache.h
@@ -9,6 +9,8 @@
#ifndef __CACHE_H
#define __CACHE_H
+#include
+
#if defined(CONFIG_MCF520x) || defined(CONFIG_MCF523x) || \
defined(CONFIG_MCF52x2)
#define CFG_CF_V2
diff --git a/arch/m68k/include/asm/global_data.h
b/arch/m68k/include/asm/global_data.h
index 5f576ba16f9a..c2ef5770a3df 100644
--- a/arch/m68k/include/asm/global_data.h
+++ b/arch/m68k/include/asm/global_data.h
@@ -7,8 +7,6 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
-#include
-
/* Architecture-specific global data */
struct arch_global_data {
#ifdef CONFIG_SYS_I2C_FSL
@@ -24,7 +22,7 @@ struct arch_global_data {
unsigned long sdhc_clk;
#endif
#if defined(CONFIG_FSL_ESDHC)
- u32 sdhc_per_clk;
+ unsigned long sdhc_per_clk;
#endif
};
diff --git a/arch/m68k/lib/traps.c b/arch/m68k/lib/traps.c
index c283351181d8..2a025c5a6e86 100644
--- a/arch/m68k/lib/traps.c
+++ b/arch/m68k/lib/traps.c
@@ -7,6 +7,7 @@
* Wolfgang Denk, DENX Software Engineering, w...@denx.de.
*/
+#include
#include
#include
#include
--
2.34.1
[v2 10/16] global: Rework architecture global_data.h to include
In most cases, the architecture global data currently makes use of
assorted linux types, but does not include to provide
them. Add instead of relying on indirect inclusion.
Signed-off-by: Tom Rini
---
Changes in v2:
- Update include/system-constraints.h and board/cssi/cmpc885/sdram.c
---
arch/mips/include/asm/global_data.h| 2 +-
arch/nios2/include/asm/global_data.h | 2 ++
arch/powerpc/include/asm/global_data.h | 1 -
arch/riscv/include/asm/global_data.h | 1 +
arch/x86/include/asm/global_data.h | 1 +
board/cssi/cmpc885/sdram.c | 1 +
include/system-constants.h | 2 ++
7 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/mips/include/asm/global_data.h
b/arch/mips/include/asm/global_data.h
index f0d3b07bf1eb..34b7e0bed945 100644
--- a/arch/mips/include/asm/global_data.h
+++ b/arch/mips/include/asm/global_data.h
@@ -7,8 +7,8 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+#include
#include
-#include
struct octeon_eeprom_mac_addr {
u8 mac_addr_base[6];
diff --git a/arch/nios2/include/asm/global_data.h
b/arch/nios2/include/asm/global_data.h
index 1a0e7d25fa3b..b56e8a5078e0 100644
--- a/arch/nios2/include/asm/global_data.h
+++ b/arch/nios2/include/asm/global_data.h
@@ -6,6 +6,8 @@
#ifndef__ASM_NIOS2_GLOBALDATA_H_
#define __ASM_NIOS2_GLOBALDATA_H_
+#include
+
/* Architecture-specific global data */
struct arch_global_data {
u32 dcache_line_size;
diff --git a/arch/powerpc/include/asm/global_data.h
b/arch/powerpc/include/asm/global_data.h
index 43d71f5caec0..f7860122a00b 100644
--- a/arch/powerpc/include/asm/global_data.h
+++ b/arch/powerpc/include/asm/global_data.h
@@ -8,7 +8,6 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
-#include
#include
/* Architecture-specific global data */
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index 937fa4d15446..d00247ad9536 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -10,6 +10,7 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+#include
#include
#include
#include
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index 6f4a7130f1da..1ef7f1f0349e 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -9,6 +9,7 @@
#ifndef __ASSEMBLY__
+#include
#include
#include
diff --git a/board/cssi/cmpc885/sdram.c b/board/cssi/cmpc885/sdram.c
index 11a50c3a52d6..828784bd368e 100644
--- a/board/cssi/cmpc885/sdram.c
+++ b/board/cssi/cmpc885/sdram.c
@@ -4,6 +4,7 @@
* Charles Frey
*/
+#include
#include
#include
#include
diff --git a/include/system-constants.h b/include/system-constants.h
index d688629f119b..e09fc418a47c 100644
--- a/include/system-constants.h
+++ b/include/system-constants.h
@@ -3,6 +3,8 @@
#ifndef __SYSTEM_CONSTANTS_H__
#define __SYSTEM_CONSTANTS_H__
+#include
+
/*
* The most common case for our initial stack pointer address is to
* say that we have defined a static intiial ram address location and
--
2.34.1
[v2 08/16] sandbox: Add to asm/global_data.h and asm/io.h
We need in these files as we reference Linux types.
Signed-off-by: Tom Rini
Reviewed-by: Simon Glass
---
arch/sandbox/include/asm/global_data.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/sandbox/include/asm/global_data.h
b/arch/sandbox/include/asm/global_data.h
index c6977735029d..001b2b53c1c8 100644
--- a/arch/sandbox/include/asm/global_data.h
+++ b/arch/sandbox/include/asm/global_data.h
@@ -9,6 +9,8 @@
#ifndef__ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+#include
+
/* Architecture-specific global data */
struct arch_global_data {
uint8_t *ram_buf; /* emulated RAM buffer */
--
2.34.1
[v2 07/16] arm: Remove from asm/global_data.h
We need and include and this in turn already includes , so drop it here. Signed-off-by: Tom Rini Reviewed-by: Simon Glass --- arch/arm/include/asm/global_data.h | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index 75bd9d56f893..2bb978d66839 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -11,7 +11,6 @@ #include -#include #include /* Architecture-specific global data */ -- 2.34.1
[v2 03/16] arm: Partial cleanup and audit usage of
We need to include directly when a file needs to have
something such as CFG_SYS_SDRAM_SIZE referenced as this file is not
automatically globally included and is most commonly indirectly included
via common.h. Remove most cases of arm including config.h directly, but
add it where needed. This includes a few board-specific fixes.
Signed-off-by: Tom Rini
---
Changes in v2:
- Update arch/arm/mach-keystone/cmd_mon.c
---
arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h | 2 --
arch/arm/include/asm/arch-ls102xa/fsl_serdes.h| 2 --
arch/arm/include/asm/assembler.h | 1 -
arch/arm/include/asm/secure.h | 1 -
arch/arm/include/asm/string.h | 2 --
arch/arm/mach-davinci/include/mach/pinmux_defs.h | 1 -
arch/arm/mach-exynos/exynos4_setup.h | 1 -
arch/arm/mach-exynos/exynos5_setup.h | 1 -
arch/arm/mach-k3/common.c | 1 +
arch/arm/mach-k3/include/mach/clock.h | 2 --
arch/arm/mach-k3/include/mach/j721e_hardware.h| 1 -
arch/arm/mach-k3/include/mach/j721s2_hardware.h | 1 -
arch/arm/mach-keystone/cmd_mon.c | 1 +
board/freescale/ls1088a/eth_ls1088aqds.c | 1 +
board/freescale/ls2080aqds/eth.c | 1 +
board/toradex/verdin-am62/verdin-am62.c | 1 +
drivers/ddr/marvell/axp/ddr3_axp.h| 2 ++
17 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
index 8f4365175697..9e29350ca4ba 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
@@ -7,8 +7,6 @@
#ifndef __FSL_SERDES_H__
#define __FSL_SERDES_H__
-#include
-
#ifdef CONFIG_FSL_LSCH3
enum srds_prtcl {
/*
diff --git a/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h
b/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h
index d99a6f318f8b..9244e0a78fd3 100644
--- a/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h
+++ b/arch/arm/include/asm/arch-ls102xa/fsl_serdes.h
@@ -6,8 +6,6 @@
#ifndef __FSL_SERDES_H
#define __FSL_SERDES_H
-#include
-
enum srds_prtcl {
/*
* Nobody will check whether the device 'NONE' has been configured,
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 8d42ef4823e9..4fda483b8d8d 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -14,7 +14,6 @@
* assembler source.
*/
-#include
#include
/*
diff --git a/arch/arm/include/asm/secure.h b/arch/arm/include/asm/secure.h
index c7b00be8e0b9..abfa46470b2c 100644
--- a/arch/arm/include/asm/secure.h
+++ b/arch/arm/include/asm/secure.h
@@ -1,7 +1,6 @@
#ifndef __ASM_SECURE_H
#define __ASM_SECURE_H
-#include
#include
#define __secure __section("._secure.text")
diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h
index ead3f2c35643..c9ecdde0d3d8 100644
--- a/arch/arm/include/asm/string.h
+++ b/arch/arm/include/asm/string.h
@@ -1,8 +1,6 @@
#ifndef __ASM_ARM_STRING_H
#define __ASM_ARM_STRING_H
-#include
-
/*
* We don't do inline string functions, since the
* optimised inline asm versions are not small.
diff --git a/arch/arm/mach-davinci/include/mach/pinmux_defs.h
b/arch/arm/mach-davinci/include/mach/pinmux_defs.h
index 4901ba49c9bb..120935310807 100644
--- a/arch/arm/mach-davinci/include/mach/pinmux_defs.h
+++ b/arch/arm/mach-davinci/include/mach/pinmux_defs.h
@@ -9,7 +9,6 @@
#define __ASM_ARCH_PINMUX_DEFS_H
#include
-#include
/* SPI0 pin muxer settings */
extern const struct pinmux_config spi0_pins_base[3];
diff --git a/arch/arm/mach-exynos/exynos4_setup.h
b/arch/arm/mach-exynos/exynos4_setup.h
index fbb45eb897e3..23c9011fbc63 100644
--- a/arch/arm/mach-exynos/exynos4_setup.h
+++ b/arch/arm/mach-exynos/exynos4_setup.h
@@ -8,7 +8,6 @@
#ifndef _ORIGEN_SETUP_H
#define _ORIGEN_SETUP_H
-#include
#include
/* Bus Configuration Register Address */
diff --git a/arch/arm/mach-exynos/exynos5_setup.h
b/arch/arm/mach-exynos/exynos5_setup.h
index af7a5afb03cd..e9874a8c1b24 100644
--- a/arch/arm/mach-exynos/exynos5_setup.h
+++ b/arch/arm/mach-exynos/exynos5_setup.h
@@ -8,7 +8,6 @@
#ifndef _SMDK5250_SETUP_H
#define _SMDK5250_SETUP_H
-#include
#include
#define NOT_AVAILABLE 0
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index fd400e7e3dd8..d5db805c62ba 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -6,6 +6,7 @@
* Lokesh Vutla
*/
+#include
#include
#include
#include
diff --git a/arch/arm/mach-k3/include/mach/clock.h
b/arch/arm/mach-k3/include/mach/clock.h
index 32368ce0ede3..866319365f0a 100644
--- a/arch/arm/mach-k3/include/mach/clock.h
+++ b/arch/arm/mach-k3/include/mach/clock.h
@@ -7,8 +7,6 @@
#ifndef
[v2 06/16] global: Remove duplicate common.h inclusions
These files include twice. Start by removing the second inclusion of the file. Signed-off-by: Tom Rini Reviewed-by: Simon Glass --- board/data_modul/common/common.c | 1 - board/grinn/liteboard/board.c | 1 - board/toradex/colibri_imx7/colibri_imx7.c | 1 - board/wandboard/wandboard.c | 1 - drivers/gpio/gpio-aspeed.c| 1 - drivers/spi/fsl_dspi.c| 1 - drivers/video/exynos/exynos_dp.c | 1 - 7 files changed, 7 deletions(-) diff --git a/board/data_modul/common/common.c b/board/data_modul/common/common.c index bf9a11472d11..4f308dad2e4d 100644 --- a/board/data_modul/common/common.c +++ b/board/data_modul/common/common.c @@ -12,7 +12,6 @@ #include #include #include -#include #include #include #include diff --git a/board/grinn/liteboard/board.c b/board/grinn/liteboard/board.c index 48392c48e5cc..cf1d7cee9252 100644 --- a/board/grinn/liteboard/board.c +++ b/board/grinn/liteboard/board.c @@ -20,7 +20,6 @@ #include #include #include -#include #include #include #include diff --git a/board/toradex/colibri_imx7/colibri_imx7.c b/board/toradex/colibri_imx7/colibri_imx7.c index e23f9af20da0..1d0c157d5394 100644 --- a/board/toradex/colibri_imx7/colibri_imx7.c +++ b/board/toradex/colibri_imx7/colibri_imx7.c @@ -16,7 +16,6 @@ #include #include #include -#include #include #include #include diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c index 48914450a294..8be62c86695d 100644 --- a/board/wandboard/wandboard.c +++ b/board/wandboard/wandboard.c @@ -28,7 +28,6 @@ #include #include #include -#include #include #include #include diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c index 2c5415c671d1..1c3d18796b3a 100644 --- a/drivers/gpio/gpio-aspeed.c +++ b/drivers/gpio/gpio-aspeed.c @@ -11,7 +11,6 @@ #include #include -#include #include #include #include diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c index 89907cbbb02a..9b3d5a94817f 100644 --- a/drivers/spi/fsl_dspi.c +++ b/drivers/spi/fsl_dspi.c @@ -14,7 +14,6 @@ #include #include #include -#include #include #include #include diff --git a/drivers/video/exynos/exynos_dp.c b/drivers/video/exynos/exynos_dp.c index a532d5ae1abb..59838da6c926 100644 --- a/drivers/video/exynos/exynos_dp.c +++ b/drivers/video/exynos/exynos_dp.c @@ -7,7 +7,6 @@ #include #include -#include #include #include #include -- 2.34.1
[v2 05/16] global: Drop common.h inclusion
In order to make it easier to move on to dropping common.h from code
directly, remove common.h inclusion from the rest of the header file
which had been including it.
Signed-off-by: Tom Rini
Reviewed-by: Simon Glass
---
board/BuR/common/br_resetc.h | 1 -
board/CZ.NIC/turris_mox/mox_sp.h | 2 --
board/freescale/common/vsc3316_3308.h | 1 -
board/ti/ks2_evm/mux-k2g.h | 1 -
board/tq/tqma6/tqma6_bb.h | 2 --
board/xilinx/zynqmp/xil_io.h | 1 -
disk/part_amiga.h | 1 -
drivers/bios_emulator/include/x86emu.h | 1 -
drivers/crypto/fsl/jobdesc.h | 1 -
drivers/crypto/fsl/rsa_caam.h | 2 --
drivers/ddr/altera/sdram_soc64.h | 1 -
drivers/ddr/marvell/a38x/ddr_ml_wrapper.h | 1 -
drivers/net/fm/fm.h| 1 -
drivers/net/fsl-mc/dpio/qbman_private.h| 1 -
drivers/net/fsl-mc/dpio/qbman_sys.h| 1 +
drivers/net/mscc_eswitch/mscc_mac_table.c | 1 +
drivers/net/mscc_eswitch/mscc_mac_table.h | 2 --
drivers/net/mscc_eswitch/mscc_xfer.c | 1 +
drivers/net/mscc_eswitch/mscc_xfer.h | 2 --
drivers/pci/pcie_layerscape_fixup_common.h | 2 --
drivers/pci_endpoint/pcie-cadence.h| 1 -
drivers/pinctrl/mtmips/pinctrl-mtmips-common.h | 2 --
drivers/usb/gadget/bcm_udc_otg.h | 2 --
fs/btrfs/ctree.h | 1 -
fs/yaffs2/ydirectenv.h | 1 -
lib/libavb/avb_sysdeps.h | 4 +++-
lib/zlib/zlib.h| 1 -
net/arp.h | 2 --
net/link_local.h | 5 +
net/net_rand.h | 1 -
net/ping.h | 1 -
31 files changed, 7 insertions(+), 40 deletions(-)
diff --git a/board/BuR/common/br_resetc.h b/board/BuR/common/br_resetc.h
index ba0689bf2050..999045b867d2 100644
--- a/board/BuR/common/br_resetc.h
+++ b/board/BuR/common/br_resetc.h
@@ -7,7 +7,6 @@
*/
#ifndef __CONFIG_BRRESETC_H__
#define __CONFIG_BRRESETC_H__
-#include
int br_resetc_regget(u8 reg, u8 *dst);
int br_resetc_regset(u8 reg, u8 val);
diff --git a/board/CZ.NIC/turris_mox/mox_sp.h b/board/CZ.NIC/turris_mox/mox_sp.h
index 720880d5df32..c766c7423ac5 100644
--- a/board/CZ.NIC/turris_mox/mox_sp.h
+++ b/board/CZ.NIC/turris_mox/mox_sp.h
@@ -6,8 +6,6 @@
#ifndef _BOARD_CZNIC_TURRIS_MOX_MOX_SP_H_
#define _BOARD_CZNIC_TURRIS_MOX_MOX_SP_H_
-#include
-
enum cznic_a3720_board {
BOARD_UNDEFINED = 0x0,
BOARD_TURRIS_MOX= 0x1,
diff --git a/board/freescale/common/vsc3316_3308.h
b/board/freescale/common/vsc3316_3308.h
index 8d343ba4d654..9725d6d9e390 100644
--- a/board/freescale/common/vsc3316_3308.h
+++ b/board/freescale/common/vsc3316_3308.h
@@ -6,7 +6,6 @@
#ifndef __VSC_CROSSBAR_H_
#define __VSC_CROSSBAR_H_
-#include
#include
#include
diff --git a/board/ti/ks2_evm/mux-k2g.h b/board/ti/ks2_evm/mux-k2g.h
index f24e62850b8b..447e70607f96 100644
--- a/board/ti/ks2_evm/mux-k2g.h
+++ b/board/ti/ks2_evm/mux-k2g.h
@@ -6,7 +6,6 @@
* Texas Instruments Incorporated,
*/
-#include
#include
#include
#include
diff --git a/board/tq/tqma6/tqma6_bb.h b/board/tq/tqma6/tqma6_bb.h
index ca81bdf58535..a2f871af1f83 100644
--- a/board/tq/tqma6/tqma6_bb.h
+++ b/board/tq/tqma6/tqma6_bb.h
@@ -7,8 +7,6 @@
#ifndef __TQMA6_BB__
#define __TQMA6_BB__
-#include
-
int tqma6_bb_board_mmc_getwp(struct mmc *mmc);
int tqma6_bb_board_mmc_getcd(struct mmc *mmc);
int tqma6_bb_board_mmc_init(struct bd_info *bis);
diff --git a/board/xilinx/zynqmp/xil_io.h b/board/xilinx/zynqmp/xil_io.h
index e6caa7c85033..dd823d6f62a5 100644
--- a/board/xilinx/zynqmp/xil_io.h
+++ b/board/xilinx/zynqmp/xil_io.h
@@ -5,7 +5,6 @@
/* FIXME remove this when vivado is fixed */
#include
-#include
#include
#define xil_printf(...)
diff --git a/disk/part_amiga.h b/disk/part_amiga.h
index 42f5eb0f941c..dfa70bdb8a8c 100644
--- a/disk/part_amiga.h
+++ b/disk/part_amiga.h
@@ -7,7 +7,6 @@
#ifndef _DISK_PART_AMIGA_H
#define _DISK_PART_AMIGA_H
-#include
#if CONFIG_IS_ENABLED(ISO_PARTITION)
/* Make the buffers bigger if ISO partition support is enabled -- CD-ROMS
diff --git a/drivers/bios_emulator/include/x86emu.h
b/drivers/bios_emulator/include/x86emu.h
index b28cdc6b8cad..d2650a8d1600 100644
--- a/drivers/bios_emulator/include/x86emu.h
+++ b/drivers/bios_emulator/include/x86emu.h
@@ -42,7 +42,6 @@
#define __X86EMU_X86EMU_H
#include
-#include
#include
#include
#define X86API
diff --git a/drivers/crypto/fsl/jobdesc.h b/drivers/crypto/fsl/jobdesc.h
index c4501abd26b2..69adfdca95b5 100644
--- a/drivers/crypto/fsl/jobdesc.h
+++ b/drivers/crypto/fsl/jobdesc.h
@@ -7,7 +7,6 @@
#ifndef __JOBDESC_H
#define __JOBDESC_H
-#include
#include
#include
[v2 04/16] sandbox: Audit config.h and common.h usage
Remove and replace common.h and config.h in sandbox when it's not needed
and add some explicit includes where needed.
Signed-off-by: Tom Rini
---
Changes in v2:
- Drop from arch/sandbox/cpu/state.c as it's also not
needed and leads to unrelated build failures with CMDLINE=n
---
arch/sandbox/cpu/cache.c | 1 -
arch/sandbox/cpu/cpu.c | 1 -
arch/sandbox/cpu/sdl.c | 2 +-
arch/sandbox/cpu/spl.c | 1 -
arch/sandbox/cpu/start.c | 2 +-
arch/sandbox/cpu/state.c | 3 +--
arch/sandbox/include/asm/io.h| 2 ++
arch/sandbox/include/asm/state.h | 1 -
arch/sandbox/lib/bootm.c | 1 -
arch/sandbox/lib/fdt_fixup.c | 1 -
arch/sandbox/lib/interrupts.c| 1 -
arch/sandbox/lib/pci_io.c| 1 -
board/sandbox/sandbox.c | 2 +-
13 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/arch/sandbox/cpu/cache.c b/arch/sandbox/cpu/cache.c
index 46c62c0b4461..c8a5e64214b6 100644
--- a/arch/sandbox/cpu/cache.c
+++ b/arch/sandbox/cpu/cache.c
@@ -3,7 +3,6 @@
* Copyright 2020, Heinrich Schuchardt
*/
-#include
#include
#include
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index a1c5c7c4311a..d6475c969c4d 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -5,7 +5,6 @@
#define LOG_CATEGORY LOGC_SANDBOX
-#include
#include
#include
#include
diff --git a/arch/sandbox/cpu/sdl.c b/arch/sandbox/cpu/sdl.c
index 590e406517bf..ed84646bdab7 100644
--- a/arch/sandbox/cpu/sdl.c
+++ b/arch/sandbox/cpu/sdl.c
@@ -72,7 +72,7 @@ static struct sdl_info {
static void sandbox_sdl_poll_events(void)
{
/*
-* We don't want to include common.h in this file since it uses
+* We don't want to include cpu_func.h in this file since it uses
* system headers. So add a declation here.
*/
extern void reset_cpu(void);
diff --git a/arch/sandbox/cpu/spl.c b/arch/sandbox/cpu/spl.c
index 16b766279833..9ad9da686c6a 100644
--- a/arch/sandbox/cpu/spl.c
+++ b/arch/sandbox/cpu/spl.c
@@ -3,7 +3,6 @@
* Copyright (c) 2016 Google, Inc
*/
-#include
#include
#include
#include
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index 2589c2eba738..dce804165296 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -3,7 +3,7 @@
* Copyright (c) 2011-2012 The Chromium OS Authors.
*/
-#include
+#include
#include
#include
#include
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
index e38bb248b7ff..a9ca79e76d2d 100644
--- a/arch/sandbox/cpu/state.c
+++ b/arch/sandbox/cpu/state.c
@@ -3,9 +3,8 @@
* Copyright (c) 2011-2012 The Chromium OS Authors.
*/
-#include
-#include
#include
+#include
#include
#include
#include
diff --git a/arch/sandbox/include/asm/io.h b/arch/sandbox/include/asm/io.h
index 77a02e5f5241..3c0a102697ec 100644
--- a/arch/sandbox/include/asm/io.h
+++ b/arch/sandbox/include/asm/io.h
@@ -6,6 +6,8 @@
#ifndef __SANDBOX_ASM_IO_H
#define __SANDBOX_ASM_IO_H
+#include
+
enum sandboxio_size_t {
SB_SIZE_8,
SB_SIZE_16,
diff --git a/arch/sandbox/include/asm/state.h b/arch/sandbox/include/asm/state.h
index 59a20595f51d..c84a1f7060f4 100644
--- a/arch/sandbox/include/asm/state.h
+++ b/arch/sandbox/include/asm/state.h
@@ -6,7 +6,6 @@
#ifndef __SANDBOX_STATE_H
#define __SANDBOX_STATE_H
-#include
#include
#include
#include
diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c
index a748ba650b12..290db4521702 100644
--- a/arch/sandbox/lib/bootm.c
+++ b/arch/sandbox/lib/bootm.c
@@ -4,7 +4,6 @@
* Copyright (c) 2015 Sjoerd Simons
*/
-#include
#include
#include
#include
diff --git a/arch/sandbox/lib/fdt_fixup.c b/arch/sandbox/lib/fdt_fixup.c
index a646f2059c2c..e333bd52ea28 100644
--- a/arch/sandbox/lib/fdt_fixup.c
+++ b/arch/sandbox/lib/fdt_fixup.c
@@ -2,7 +2,6 @@
#define LOG_CATEGORY LOGC_ARCH
-#include
#include
#include
diff --git a/arch/sandbox/lib/interrupts.c b/arch/sandbox/lib/interrupts.c
index 4d7cbff802c6..3f6583e11f04 100644
--- a/arch/sandbox/lib/interrupts.c
+++ b/arch/sandbox/lib/interrupts.c
@@ -5,7 +5,6 @@
* found in the LICENSE file.
*/
-#include
#include
#include
#include
diff --git a/arch/sandbox/lib/pci_io.c b/arch/sandbox/lib/pci_io.c
index 2038141947ab..6040eacb594f 100644
--- a/arch/sandbox/lib/pci_io.c
+++ b/arch/sandbox/lib/pci_io.c
@@ -8,7 +8,6 @@
* IO space access commands.
*/
-#include
#include
#include
#include
diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index 9d58860451c5..802596569c64 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -3,8 +3,8 @@
* Copyright (c) 2011 The Chromium OS Authors.
*/
-#include
#include
+#include
#include
#include
#include
--
2.34.1
[v2 02/16] arc: Cleanup and audit usage of
We need to include directly when a file needs to have
something such as CFG_SYS_SDRAM_SIZE referenced as this file is not
automatically globally included and is most commonly indirectly included
via common.h. Remove most cases of arc including config.h directly, but
add it where needed. Further clean up the tb100 board config.h file so
that we don't rely on config.h being included there for a value used in
a single place.
Signed-off-by: Tom Rini
Reviewed-by: Simon Glass
---
arch/arc/include/asm/arc-bcr.h | 2 --
arch/arc/include/asm/arcregs.h | 1 -
arch/arc/include/asm/cache.h | 2 --
arch/arc/lib/cpu.c | 1 +
board/abilis/tb100/tb100.c | 4
include/configs/tb100.h| 21 -
6 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/arch/arc/include/asm/arc-bcr.h b/arch/arc/include/asm/arc-bcr.h
index 823906d946e4..a6c972bf1e31 100644
--- a/arch/arc/include/asm/arc-bcr.h
+++ b/arch/arc/include/asm/arc-bcr.h
@@ -13,8 +13,6 @@
#define __ARC_BCR_H
#ifndef __ASSEMBLY__
-#include
-
union bcr_di_cache {
struct {
#ifdef CONFIG_CPU_BIG_ENDIAN
diff --git a/arch/arc/include/asm/arcregs.h b/arch/arc/include/asm/arcregs.h
index a9f54f61e0cc..273fb8eed859 100644
--- a/arch/arc/include/asm/arcregs.h
+++ b/arch/arc/include/asm/arcregs.h
@@ -7,7 +7,6 @@
#define _ASM_ARC_ARCREGS_H
#include
-#include
/*
* ARC architecture has additional address space - auxiliary registers.
diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h
index 74cff716ef60..65dff4214830 100644
--- a/arch/arc/include/asm/cache.h
+++ b/arch/arc/include/asm/cache.h
@@ -6,8 +6,6 @@
#ifndef __ASM_ARC_CACHE_H
#define __ASM_ARC_CACHE_H
-#include
-
/*
* As of today we may handle any L1 cache line length right in software.
* For that essentially cache line length is a variable not constant.
diff --git a/arch/arc/lib/cpu.c b/arch/arc/lib/cpu.c
index 803dfd425580..593950449f2e 100644
--- a/arch/arc/lib/cpu.c
+++ b/arch/arc/lib/cpu.c
@@ -3,6 +3,7 @@
* Copyright (C) 2013-2014, 2018 Synopsys, Inc. All rights reserved.
*/
+#include
#include
#include
#include
diff --git a/board/abilis/tb100/tb100.c b/board/abilis/tb100/tb100.c
index 3dc9e14ef8c0..eb7d12908134 100644
--- a/board/abilis/tb100/tb100.c
+++ b/board/abilis/tb100/tb100.c
@@ -14,6 +14,10 @@ void reset_cpu(void)
writel(0x1, (void *)CRM_SWRESET);
}
+/*
+ * Ethernet configuration
+ */
+#define ETH0_BASE_ADDRESS 0xFE10
int board_eth_init(struct bd_info *bis)
{
if (designware_initialize(ETH0_BASE_ADDRESS, 0) >= 0)
diff --git a/include/configs/tb100.h b/include/configs/tb100.h
index 1318f5e5ee44..08b6f3219c33 100644
--- a/include/configs/tb100.h
+++ b/include/configs/tb100.h
@@ -21,25 +21,4 @@
*/
#define CFG_SYS_NS16550_CLK1
-/*
- * Even though the board houses Realtek RTL8211E PHY
- * corresponding PHY driver (drivers/net/phy/realtek.c) behaves unexpectedly.
- * In particular "parse_status" reports link is down.
- *
- * Until Realtek PHY driver is fixed fall back to generic PHY driver
- * which implements all required functionality and behaves much more stable.
- *
- *
- */
-
-/*
- * Ethernet configuration
- */
-#define ETH0_BASE_ADDRESS 0xFE10
-#define ETH1_BASE_ADDRESS 0xFE11
-
-/*
- * Console configuration
- */
-
#endif /* _CONFIG_TB100_H_ */
--
2.34.1
[v2 01/16] qe: Add to linux/immap_qe.h
Given how we define QE_MURAM_SIZE today, this header needs to have added to it. Signed-off-by: Tom Rini Reviewed-by: Simon Glass --- include/linux/immap_qe.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/immap_qe.h b/include/linux/immap_qe.h index 45307f51c103..a692f5dfb373 100644 --- a/include/linux/immap_qe.h +++ b/include/linux/immap_qe.h @@ -11,6 +11,8 @@ #ifndef __IMMAP_QE_H__ #define __IMMAP_QE_H__ +#include + #ifdef CONFIG_MPC83xx #if defined(CONFIG_ARCH_MPC8360) #define QE_MURAM_SIZE 0xc000UL -- 2.34.1
Re: [PATCH v1] drivers: mtd: spi: Add support for GD55LB02GEBIR SPI NOR flash
On Fri, Aug 4, 2023 at 7:56 AM Jit Loon Lim wrote: > > From: Teik Heng Chong > > Add Support for GigaDevice GD55LB02GEBIR SPI NOR flash as QSPI > configuration flash > > Signed-off-by: Teik Heng Chong > --- Applied to u-boot-spi/master
Re: [PATCH v1] drivers: spi: Add MT25U01G part number for SPI NOR Flash
On Fri, Aug 4, 2023 at 7:57 AM Jit Loon Lim wrote: > > MT25QU01 OPN with 4B OPCODE support is currently not supported in > source code and the driver reuses the definition for "n25q00a" > which has the same silicon ID but is a slower part. > > Adding mt25u01g definition to the source code to support a faster > read response for MT25QU01 QSPI NOR Flash device. > > Signed-off-by: Jit Loon Lim > --- Applied u-boot-spi/master
Re: [PATCH] drivers: mtd: Add MT25QU128AB params
On Sat, Aug 5, 2023 at 2:05 AM wrote: > > From: Godfrey Mwangi > > Add Micron MT25QU128AB flash. > > Signed-off-by: Godfrey Mwangi > --- Applied u-boot-spi/master
Re: [PATCH v2] spi: cadence_qspi: Select flash subnode at runtime
On Tue, Sep 12, 2023 at 3:20 PM Udit Kumar wrote: > > Currently spi driver gets flash parameter from first subnode. > > Few boards have more than one flash with different parameters > and selection of flash is done by on board switch settings. > In such case, uboot needs to be recompiled with updated > device tree to align with board switch settings. > > This patch allows to select flash node at runtime. > > Boards those are supporting multiple flashes > needs to implement cadence_qspi_get_subnode function and return correct > flash node. > > Cc: Apurva Nandan > Signed-off-by: Udit Kumar > Reviewed-by: Neha Malcom Francis > --- Applied to u-boot-spi/master
Re: [PATCH v1] spi: spi-nor-ids: add flash model w25q01/02 support
On Tue, Sep 26, 2023 at 2:40 PM Jim Liu wrote: > > add flash w25q01jv, w25q01jvfim and w25q02jv support > > Signed-off-by: Jim Liu > --- Applied to u-boot-spi/master
Re: [patch v1] arm add initial support for the Phytium Pe2201 Board board：phytium：add pe2201 folder，It initializes pcie, ddr and other aspects of phytium pe2201 board dts：add phytium_pe2201.dts，it is
On Thu, Dec 14, 2023 at 11:06:58AM +0800, tracymg...@outlook.com wrote: > From: TracyMg_Li > > Signed-off-by: TracyMg_Li Please rework your commit message. > --- > arch/arm/Kconfig | 8 ++ > arch/arm/dts/Makefile| 1 + > arch/arm/dts/phytium-pe2201.dts | 43 +++ Please make sure this dts is being submitted upstream and passes validation there before submitting it upstream too. [snip] > @@ -2060,6 +2060,13 @@ config TARGET_POMELO > Support for pomelo platform. > It has 8GB Sdram, uart and pcie. > > +config TARGET_PE2201 > +bool "Support Phytium PE2201 Platform" > +select ARM64 > +help > + Support for pe2201 platform. > + It has 2GB Sdram, uart and pcie. > + Was your patch spacing corrupted? If not, please fix this here. [snip] > diff --git a/include/configs/pe2201.h b/include/configs/pe2201.h > new file mode 100644 > index 00..ff24dc5ac6 > --- /dev/null > +++ b/include/configs/pe2201.h > @@ -0,0 +1,32 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright (C) 2023, Phytium Technology Co., Ltd. > + * lixinde > + * weichangzheng > + */ > + > +#ifndef __PE2201_CONFIG_H > +#define __PE2201_CONFIG_H > + > +/* SDRAM Bank #1 start address */ > +#define PHYS_SDRAM_10x8000 > +#define PHYS_SDRAM_1_SIZE 0x7400 > +#define CFG_SYS_SDRAM_BASE PHYS_SDRAM_1 > + > +/* BOOT */ > +#define BOOT_TARGET_DEVICES(func)\ > + func(SCSI, scsi, 0) \ > + > +#include > + > +/* Initial environment variables */ > +#define CFG_EXTRA_ENV_SETTINGS \ > + "image=Image\0" \ > + BOOTENV \ > + "scriptaddr=0x9010\0" \ > + "kernel_addr_r=0x9020\0"\ > + "fdt_addr_r=0x9500\0" \ > + "boot_fit=no\0" \ > + "fdtfile=phytium-pe2201.dtb\0" \ Please switch to both bootstd and plain text environment, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH] spi: cadence-quadspi: Fix error message on stuck busy state
On Thu, Dec 14, 2023 at 06:36:37PM +0100, Jan Kiszka wrote:
> On 31.10.23 08:14, Stefan Roese wrote:
> > On 10/30/23 17:20, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> We are not iterating CQSPI_REG_RETRY, we are waiting 'timeout' ms, since
> >> day 1.
> >>
> >> Signed-off-by: Jan Kiszka
> >
> > Reviewed-by: Stefan Roese
> >
> > Thanks,
> > Stefan
> >
> >> ---
> >>
> >> We are unfortunately seeing that message right now, rarely but then
> >> prominently...
> >>
> >> drivers/spi/cadence_qspi_apb.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/spi/cadence_qspi_apb.c
> >> b/drivers/spi/cadence_qspi_apb.c
> >> index 9ce2c0f254f..d033184aa46 100644
> >> --- a/drivers/spi/cadence_qspi_apb.c
> >> +++ b/drivers/spi/cadence_qspi_apb.c
> >> @@ -171,8 +171,7 @@ static unsigned int cadence_qspi_wait_idle(void
> >> *reg_base)
> >> }
> >> /* Timeout, still in busy mode. */
> >> - printf("QSPI: QSPI is still busy after poll for %d times.\n",
> >> - CQSPI_REG_RETRY);
> >> + printf("QSPI: QSPI is still busy after poll for %d ms.\n", timeout);
> >> return 0;
> >> }
> >>
> >
> > Viele Grüße,
> > Stefan Roese
> >
>
> Ping.
Added to my dont-forget bundle.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] lib: rsa: Print detailed error info in rsa_engine_init() on engine resolution failure
On Thu, Dec 14, 2023 at 05:54:17PM +0100, Csókás Bence wrote: > Signed-off-by: Csókás Bence Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: spl: Use separate fault handlers instead of a single common one
On Thu, Dec 14, 2023 at 05:29:31PM +0100, Csókás Bence wrote: > It may be necessary to set breakpoints etc. on a specific fault handler in > SPL. > Add a Kconfig option to separate the different handlers into their own > individual infinite loops. > > Signed-off-by: Csókás Bence > --- > arch/arm/Kconfig | 10 ++ > arch/arm/lib/vectors.S | 18 ++ > 2 files changed, 28 insertions(+) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 328e2ddc33..47494cb72b 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -79,6 +79,16 @@ config SPL_SYS_NO_VECTOR_TABLE > depends on SPL > bool > > +config SPL_USE_SEPARATE_FAULT_HANDLERS > + bool "Use separate fault handlers instead of a single common one" > + depends on !SPL_SYS_NO_VECTOR_TABLE Will this dep catch that this is only valid for !ARM64 && !CPU_V7M ? > + default n "n" is the default, so don't add this. Otherwise looks good. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 17/21] bootm: Create a function to run through the bootm states
On Thu, Dec 14, 2023 at 09:50:26AM -0700, Simon Glass wrote:
> In quite a few places, the bootm command is used to handle a boot. We
> want these to be done without needing CONFIG_CMDLINE, so add a new
> bootm_run() function to handle this.
>
> Signed-off-by: Simon Glass
[snip]
> +int bootm_run(struct bootm_info *bmi)
> +{
> + int states;
> +
> + bmi->cmd_name = "bootm";
> + states = BOOTM_STATE_START | BOOTM_STATE_FINDOS | BOOTM_STATE_PRE_LOAD |
> + BOOTM_STATE_FINDOTHER | BOOTM_STATE_LOADOS |
> + BOOTM_STATE_OS_PREP | BOOTM_STATE_OS_FAKE_GO |
> + BOOTM_STATE_OS_GO;
> + if (IS_ENABLED(CONFIG_SYS_BOOT_RAMDISK_HIGH))
> + states |= BOOTM_STATE_RAMDISK;
> + if (IS_ENABLED(CONFIG_MEASURED_BOOT))
> + states |= BOOTM_STATE_MEASURE;
> + if (IS_ENABLED(CONFIG_PPC) || IS_ENABLED(CONFIG_MIPS))
> + states |= BOOTM_STATE_OS_CMDLINE;
> +
> + return bootm_run_states(bmi, states);
> +}
Looking at this, and then boot[zi]_run, I think we should either always set
BOOTM_STATE_MEASURE (it's a nop without CONFIG_MEASURED_BOOT) or always
IS_ENABLED check it before setting. I think we both would prefer the
former? And I really do wonder how much it would hurt or not to just
have boot_run() or something which takes the name as a param and handles
the few "bootm"-only flags.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 16/21] bootm: Tidy up boot_selected_os()
On Thu, Dec 14, 2023 at 09:50:25AM -0700, Simon Glass wrote: > Use struct bootm_info with this function, to avoiding needing to > create a new one. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 15/21] bootm: Rename do_bootm_states() to bootm_run_states()
On Thu, Dec 14, 2023 at 09:50:24AM -0700, Simon Glass wrote: > Rename the function to bootm_run_states() to better indicate ts > purpose. The 'do_' prefix is used to indicate a command processor, > which this is now not. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 10/21] bootm: Add more fields to bootm_info
On Thu, Dec 14, 2023 at 09:50:19AM -0700, Simon Glass wrote: > Add fields for the three bootm parameters and other things needed for > booting. Also add a helper to set up the struct correctly. > > Signed-off-by: Simon Glass [snip] > diff --git a/include/bootm.h b/include/bootm.h > index 85c560d5a0ae..c9ab55f18d39 100644 > --- a/include/bootm.h > +++ b/include/bootm.h > @@ -19,17 +19,52 @@ struct cmd_tbl; > /** > * struct bootm_info() - information used when processing images to boot > * > + * These mirror the first three arguments of the bootm command. They are > + * designed to handle any type of image, but typically it is a FIT. > + * > + * @addr_fit: Address of image to bootm, as passed to Maybe we should just call this addr_img ? I was fine with this at first, and then started reviewing 14+ and it just reads oddly at that point. Since we use this for starting everything in memory I think we should name this a bit more generically, and avoid the editorializing about being typically FIT as well. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 14/21] bootm: Drop arguments from do_bootm_states()
On Thu, Dec 14, 2023 at 09:50:23AM -0700, Simon Glass wrote: > Use the bootm_info struct to hold the information required by bootm. > > Now that none of the functions called from do_bootm_states() needs an > argv[] list, change the arguments of do_bootm_states() as well. Take > care to use the same value for boot_progress even though it is a little > inconsistent. > > For booti make sure it only uses argv[] and argc at the top of the > function, so we can eventually refactor to remove these parameters. > > With bootm, some OSes need access to the arguments provided to the > command, so set these up in the bootm_info struct, for bootm only. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 13/21] bootz: Avoid use of #ifdef
On Thu, Dec 14, 2023 at 09:50:22AM -0700, Simon Glass wrote: > Use the compiler to get the set of states, instead of the preprocessor. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 11/21] bootm: Move do_bootm_states() comment to header file
On Thu, Dec 14, 2023 at 09:50:20AM -0700, Simon Glass wrote: > This is an exported function, so move the function comment to the > bootm.h header file. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 12/21] booti: Avoid use of #ifdef
On Thu, Dec 14, 2023 at 09:50:21AM -0700, Simon Glass wrote: > Use the compiler to get the set of states, instead of the preprocessor. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 09/21] bootm: Adjust arguments of boot_os_fn
On Thu, Dec 14, 2023 at 09:50:18AM -0700, Simon Glass wrote: > Adjust boot_os_fn to use struct bootm_info instead of the separate > argc, argv and image parameters. Update the handlers accordingly. Few > of the functions make use of the arguments, so this improves code size > slightly. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 08/21] bootm: Create a struct for argument information
On Thu, Dec 14, 2023 at 09:50:17AM -0700, Simon Glass wrote: > Some OS functions require the arguments to the 'bootm' command. This is > inconvenient for two reasons. > > Firstly, there may not be any actual command, if CMDLINE is not enabled > and programmatic boot is being used. > > Secondly, most functions don't require the arguments, so it is > inefficient to pass them when not needed. For example it increases code > size. > > Create a new struct which holds the arguments, which can be used if > needed. > > Add the images pointer as well, since this is commonly needed. > > Signed-off-by: Simon Glass [snip] > @@ -39,7 +53,7 @@ typedef int boot_os_fn(int flag, int argc, char *const > argv[], > extern boot_os_fn do_bootm_linux; > extern boot_os_fn do_bootm_vxworks; > > -int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, char *const > argv[]); > +int do_bootelf(struct cmd_tbl *cmdtp, int fglag, int argc, char *const > argv[]); Typo, can just drop when applying if there's no v3. Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/17] Introduce initial TI's J784S4 and AM69 support
Hi Apurva Thanks! On Wed, 2023-12-06 at 18:07 +0530, Apurva Nandan wrote: > Hello Everyone! > > This series will introduce basic support (SD and UART) support for Texas > Instruments J784S4 EVM. For the whole series: Tested-by: Marcel Ziswiler However, one thing I noticed is that with upstream TF-A I do get the following errors: NOTICE: BL31: v2.10.0 (release):v2.10.0-76-g02091541d NOTICE: BL31: Built : 18:13:08, Dec 14 2023 ERROR: Failed to get response (-19) ERROR: Transfer send failed (-19) ERROR: Unable to query firmware capabilities (-19) While with latest TF-A from downstream TI BSP (both 9.0 and 9.1 use the same versin) I do not get any errors: NOTICE: BL31: v2.9(release):v2.9.0-614-gd7a7135d3 NOTICE: BL31: Built : 18:40:38, Dec 14 2023 Any idea? Cheers Marcel > The J784S4 SoC device tree patches are taken from kernel patch submissions > and will be updated as they are accepted and merged to the kernel tree. > All other patches are specific to SPL and u-boot and do not have > dependency on other trees. Appreciate a review for acceptance to u-boot > tree. > > Here are some of the salient features of the J784S4 automotive grade > application processor: > > The J784S4 SoC belongs to the K3 Multicore SoC architecture > platform, providing advanced system integration in automotive, > ADAS and industrial applications requiring AI at the network edge. > This SoC extends the K3 Jacinto 7 family of SoCs with focus on > raising performance and integration while providing interfaces, > memory architecture and compute performance for multi-sensor, high > concurrency applications. > > Some highlights of this SoC are: > * Up to 8 Cortex-A72s, four clusters of lockstep capable dual Cortex-R5F MCUs, > 4 C7x floating point vector DSPs with Matrix Multiply Accelerator(MMA) for > deep learning and CNN. > * 3D GPU: Automotive grade IMG BXS-4-64 MC1 > * Vision Processing Accelerator (VPAC) with image signal processor and Depth > and Motion Processing Accelerator (DMPAC) > * Three CSI2.0 4L RX plus two CSI2.0 4L TX, two DSI Tx, one eDP/DP and one > DPI interface. > * Integrated gigabit ethernet switch, up to 8 ports (TDA4VH), two ports > support 10Gb USXGMII; Two 4 lane PCIe-GEN3 controllers, USB3.0 Dual-role > device subsystems, Up to 20 MCANs, among other peripherals. > > See J784S4 Technical Reference Manual (SPRUJ52 - JUNE 2022) > for further details: http://www.ti.com/lit/zip/spruj52 > > In addtion, the J784S4 EVM board is designed for TI J784S4 SoC. It > supports the following interfaces: > * 32 GB DDR4 RAM > * x2 Gigabit Ethernet interfaces capable of working in Switch and MAC mode > * x1 Input Audio Jack, x1 Output Audio Jack > * x1 USB2.0 Hub with two Type A host and x1 USB 3.1 Type-C Port > * x2 4L PCIe connector > * x1 UHS-1 capable micro-SD card slot > * 512 Mbit OSPI flash, 1 Gbit Octal NAND flash, 512 Mbit QSPI flash, > UFS flash. > * x6 UART through UART-USB bridge > * XDS110 for onboard JTAG debug using USB > * Temperature sensors, user push buttons and LEDs > * 40-pin User Expansion Connector > * x2 ENET Expansion Connector, x1 GESI expander, x2 Display connector > * x1 15-pin CSI header > * x6 MCAN instances > > Schematics: https://www.ti.com/lit/zip/sprr458 > > eMMC UDA moode bootlog: > https://gist.githubusercontent.com/apurvanandan1997/3cffada252d50a8aa0c00a91f1f2f856/raw/ > > Changes in v6: > 1) Move bootph-all of memory node to u-boot.dtsi > 2) Used a while loop for DRAM controller init, instead of hard-coding for 4 > DRAM > 3) Fixed build error by adding board/ti/j784s4/Kconfig > 4) Trimmed out j784s4_evm.h > 5) Fixed checkpatch warnings > > Link to v5: > https://patchwork.ozlabs.org/project/uboot/cover/20231130115552.3580995-1-a-nan...@ti.com/ > > Changes in v5: > 1) Incorporated Andrew Davis' "Move R5 specific code into new r5/ directory" > and > "Move board selection to mach-k3" series changes. > 2) Incorporated Neha Francis' "Move to using templated FITs" series changes. > 3) Synced device tree files with Linux v6.7-rc1 > 4) Changed ti_mmc to mmc1 target from bootstd > 5) Updated doc based on review comments > 6) Removed remoteproc support from the series > 7) Splitted board files patch into smaller patches > 8) Trimmed j784s4.env to necessary variables > 9) Used fdtdec_setup_mem_size_base fdtdec_setup_memory_banksize in evm.c > 10) Trimmed down evm.c to essential header files. > 11) Switched to multi-dtb fit compilation with config fragments > > Link to v4: > https://lore.kernel.org/u-boot/20231001165545.494212-1-a-nan...@ti.com/ > > Changes in v4: > 1) Cleaned up Copyright and SPDX identifiers > 2) Synced the device trees to Linux v6.6-rc1 tag > 3) Added cleanup patch for sorting SoC JTAG ID entries > 4) Removed EEPROM board detect from evm.c and added am69 config fragments > 5) Updated MAINTAINERS files and commit messages > 6) Removed struct renaming in ti_k3_r5f_rproc driver > > Link to v3: >
Re: [PATCH] spi: cadence-quadspi: Fix error message on stuck busy state
On 31.10.23 08:14, Stefan Roese wrote:
> On 10/30/23 17:20, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> We are not iterating CQSPI_REG_RETRY, we are waiting 'timeout' ms, since
>> day 1.
>>
>> Signed-off-by: Jan Kiszka
>
> Reviewed-by: Stefan Roese
>
> Thanks,
> Stefan
>
>> ---
>>
>> We are unfortunately seeing that message right now, rarely but then
>> prominently...
>>
>> drivers/spi/cadence_qspi_apb.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/cadence_qspi_apb.c
>> b/drivers/spi/cadence_qspi_apb.c
>> index 9ce2c0f254f..d033184aa46 100644
>> --- a/drivers/spi/cadence_qspi_apb.c
>> +++ b/drivers/spi/cadence_qspi_apb.c
>> @@ -171,8 +171,7 @@ static unsigned int cadence_qspi_wait_idle(void
>> *reg_base)
>> }
>> /* Timeout, still in busy mode. */
>> - printf("QSPI: QSPI is still busy after poll for %d times.\n",
>> - CQSPI_REG_RETRY);
>> + printf("QSPI: QSPI is still busy after poll for %d ms.\n", timeout);
>> return 0;
>> }
>>
>
> Viele Grüße,
> Stefan Roese
>
Ping.
Jan
--
Siemens AG, Technology
Linux Expert Center
Re: [PATCH v6 1/3] dt-bindings: mtd: partitions: Add binman compatible
On Fri, Dec 08, 2023 at 03:58:10PM -0700, Simon Glass wrote: > Hi Rob, > > On Fri, 8 Dec 2023 at 14:56, Rob Herring wrote: > > > > On Fri, Dec 8, 2023 at 11:47 AM Simon Glass wrote: > > > > > > Hi Rob, > > > > > > On Fri, 8 Dec 2023 at 08:00, Rob Herring wrote: > > > > > > > > On Thu, Nov 16, 2023 at 10:28:50AM -0700, Simon Glass wrote: > > > > > Add a compatible string for binman, so we can extend fixed-partitions > > > > > in various ways. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > --- > > > > > > > > > > (no changes since v5) > > > > > > > > > > Changes in v5: > > > > > - Add #address/size-cells and parternProperties > > > > > - Drop $ref to fixed-partitions.yaml > > > > > - Drop 'select: false' > > > > > > > > > > Changes in v4: > > > > > - Change subject line > > > > > > > > > > Changes in v3: > > > > > - Drop fixed-partition additional compatible string > > > > > - Drop fixed-partitions from the example > > > > > - Mention use of compatible instead of label > > > > > > > > > > Changes in v2: > > > > > - Drop mention of 'enhanced features' in fixed-partitions.yaml > > > > > - Mention Binman input and output properties > > > > > - Use plain partition@xxx for the node name > > > > > > > > > > .../bindings/mtd/partitions/binman.yaml | 68 > > > > > +++ > > > > > .../bindings/mtd/partitions/partitions.yaml | 1 + > > > > > MAINTAINERS | 5 ++ > > > > > 3 files changed, 74 insertions(+) > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/mtd/partitions/binman.yaml > > > > > > > > > > diff --git > > > > > a/Documentation/devicetree/bindings/mtd/partitions/binman.yaml > > > > > b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml > > > > > new file mode 100644 > > > > > index ..329217550a98 > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/mtd/partitions/binman.yaml > > > > > @@ -0,0 +1,68 @@ > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > > > > > +# Copyright 2023 Google LLC > > > > > + > > > > > +%YAML 1.2 > > > > > +--- > > > > > +$id: http://devicetree.org/schemas/mtd/partitions/binman.yaml# > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > > > > + > > > > > +title: Binman firmware layout > > > > > + > > > > > +maintainers: > > > > > + - Simon Glass > > > > > + > > > > > +description: | > > > > > + The binman node provides a layout for firmware, used when > > > > > packaging firmware > > > > > + from multiple projects. It is based on fixed-partitions, with some > > > > > + extensions, but uses 'compatible' to indicate the contents of the > > > > > node, to > > > > > + avoid perturbing or confusing existing installations which use > > > > > 'label' for a > > > > > + particular purpose. > > > > > + > > > > > + Binman supports properties used as inputs to the > > > > > firmware-packaging process, > > > > > + such as those which control alignment of partitions. This binding > > > > > addresses > > > > > + these 'input' properties. For example, it is common for the 'reg' > > > > > property > > > > > + (an 'output' property) to be set by Binman, based on the alignment > > > > > requested > > > > > + in the input. > > > > > + > > > > > + Once processing is complete, input properties have mostly served > > > > > their > > > > > + purpose, at least until the firmware is repacked later, e.g. due > > > > > to a > > > > > + firmware update. The 'fixed-partitions' binding should provide > > > > > enough > > > > > + information to read the firmware at runtime, including > > > > > decompression if > > > > > + needed. > > > > > > > > How is this going to work exactly? binman reads these nodes and then > > > > writes out 'fixed-partitions' nodes. But then you've lost the binman > > > > specifc parts needed for repacking. > > > > > > No, they are the same node. I do want the extra information to stick > > > around. So long as it is compatible with fixed-partition as well, this > > > should work OK. > > > > How can it be both? The partitions node compatible can be either > > 'fixed-partitions' or 'binman'. > > Can we not allow it to be both? I have tried to adjust things in > response to feedback but perhaps the feedback was leading me down the > wrong path? Sure, but then the schema has to and that means extending fixed-partitions. Rob
Re: [PATCH 3/3] imx8mp-venice: update DRAM config for 2000MHz
Hi Tim, On Thu, Dec 14, 2023 at 2:09 PM Tim Harvey wrote: > Fabio, > > Thanks for asking. I suppose I should have put a Fixes on "[2/3] > imx8mp-venice: fix DRAM bus configuration" as that one does resolve a > real issue (patch 1 just removes a bogus file and patch 3 is a memory > speed improvement). > > Should I re-submit or do you want to just queue all three in your next > fixes pull? No need to re-submit. I will queue this series as fixes soon.
RE: [PATCH v1 1/1] arm64: zynqmp: Fix k24 psu_init_gpl.c clocking
Hi Michal, > >> This patch corrects the k24 som clocking configuration such that the serdes > >> Corrects the ... > > Ok. > >> clocks are correctly enabled and the usb0 is configured to use the psgtr >> refclk2 for usb3 mode. > >> I sort of have no problem with this patch but it should be better described. >> Pretty much serdes configuration should be called from u-boot because we >> already >> have psgtr driver and usb3.0 can be configured out of it. >> But we can't touch dwc3 driver now that's why the only way to do it is to >> configure via psu_init. >> But it should be clear from commit message that it is workaround not really >> something what should be here. > > I will re-test this without the serdes additions to see if they are > really necessary. > >> This patch also corrects the configuration of mio pins mio76 and mio77 >> which should be configured as gpio pins. > >> This is definitely fine. > > Good. > >> >> Signed-off-by: Neal Frager > >> You mentioned that SPL didn't work before. Is it because of incorrect serdes >> configuration? Because that's sounds weird because you don't need serdes >> initialization for booting out of qspi. That's why looking for which is that >> bit >> which make SPL work on KD240. > > The SPL works. The issue is the same as I had with the kr260 > board. The sd card interface is over usb, so unless the usb3 > works correctly, u-boot has no sd card interface and cannot > find the Linux kernel and file system. > > So what I meant was that I cannot boot up properly > when starting from the SPL. This is what this patch is > meant to fix. > What I have seen on KD240 was that I could get to u-boot prompt. And for that > you don't need any serdes initialization at all. Yes, agreed. I can get to u-boot prompt too without any additional patches. > For booting OS you need it if you want to use USB3.0. And for the kd240, sd card requires usb3.0 also. > That's why I want to make it clear what makes kd240 to boot u-boot. > And what makes to access sd over usb to boot OS. Understood. The issue I am trying to solve is enabling sd over usb to boot OS. > And no issue to add serdes initialization to psu_init to get boot OS part to > work till someone has time to wire psgtr driver with dwc3 to configure it at > run > time. Is someone currently working on wiring psgtr driver with dwc3? If this were to happen soon, than this psu_init_gpl.c patch would become unnecessary. Best regards, Neal Frager AMD
Re: [PATCH 3/3] imx8mp-venice: update DRAM config for 2000MHz
On Thu, Dec 14, 2023 at 8:29 AM Fabio Estevam wrote: > > Hi Tim, > > On Thu, Dec 14, 2023 at 1:22 PM Tim Harvey wrote: > > > > The imx8mp venice boards can support 2000Mhz DRAM. > > Update the DRAM config to support this. > > > > Signed-off-by: Tim Harvey > > Do you consider this series material for 2024.01 or 2024.04? Fabio, Thanks for asking. I suppose I should have put a Fixes on "[2/3] imx8mp-venice: fix DRAM bus configuration" as that one does resolve a real issue (patch 1 just removes a bogus file and patch 3 is a memory speed improvement). Should I re-submit or do you want to just queue all three in your next fixes pull? Thanks, Tim
Re: [PATCH v1 1/1] arm64: zynqmp: Fix k24 psu_init_gpl.c clocking
Hi Neal, On 12/14/23 17:30, Frager, Neal wrote: Hi Michal, This patch corrects the k24 som clocking configuration such that the serdes Corrects the ... Ok. clocks are correctly enabled and the usb0 is configured to use the psgtr refclk2 for usb3 mode. I sort of have no problem with this patch but it should be better described. Pretty much serdes configuration should be called from u-boot because we already have psgtr driver and usb3.0 can be configured out of it. But we can't touch dwc3 driver now that's why the only way to do it is to configure via psu_init. But it should be clear from commit message that it is workaround not really something what should be here. I will re-test this without the serdes additions to see if they are really necessary. This patch also corrects the configuration of mio pins mio76 and mio77 which should be configured as gpio pins. This is definitely fine. Good. Signed-off-by: Neal Frager You mentioned that SPL didn't work before. Is it because of incorrect serdes configuration? Because that's sounds weird because you don't need serdes initialization for booting out of qspi. That's why looking for which is that bit which make SPL work on KD240. The SPL works. The issue is the same as I had with the kr260 board. The sd card interface is over usb, so unless the usb3 works correctly, u-boot has no sd card interface and cannot find the Linux kernel and file system. So what I meant was that I cannot boot up properly when starting from the SPL. This is what this patch is meant to fix. What I have seen on KD240 was that I could get to u-boot prompt. And for that you don't need any serdes initialization at all. For booting OS you need it if you want to use USB3.0. That's why I want to make it clear what makes kd240 to boot u-boot. And what makes to access sd over usb to boot OS. And no issue to add serdes initialization to psu_init to get boot OS part to work till someone has time to wire psgtr driver with dwc3 to configure it at run time. Thanks, Michal
[PATCH] lib: rsa: Print detailed error info in rsa_engine_init() on engine resolution failure
Signed-off-by: Csókás Bence
---
lib/rsa/rsa-sign.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index d20bdb58a5..0d67a80b82 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -317,7 +317,8 @@ static int rsa_engine_init(const char *engine_id, ENGINE
**pe)
e = ENGINE_by_id(engine_id);
if (!e) {
- fprintf(stderr, "Engine isn't available\n");
+ fprintf(stderr, "Engine '%s' isn't available\n", engine_id);
+ ERR_print_errors_fp(stderr);
return -1;
}
--
2.25.1
[PATCH v2 00/21] Complete decoupling of bootm logic from commands
This series continues refactoring the bootm code to allow it to be used with CONFIG_COMMAND disabled. The OS-handling code is refactored and a new bootm_run() function is created to run through the bootm stages. This completes the work. A booti_go() function is created also, in case it proves useful, but at last for now standard boot does not use this. This is cmdd (part d of CMDLINE refactoring) It depends on dm/bootstda-working which depends on dm/cmdc-working Changes in v2: - Add new patch to enable more bootm OS methods in sandbox - Split addition of struct bootm_info to its own patch - Split changing of boot_os_fn parameters to a separate patch - Split out adding the rest of struct bootm_info fields to separate patch - Split out patch to move do_bootm_states() comment to header - Split out booti removal of #ifdef - Split out bootz removal of #ifdef - Adjust patch to focus just on dropping the do_bootm_states() arguments - Split do_bootm_states() rename to a separate patch - Rework series to allow OS access to cmdline arguments for bootm Simon Glass (21): mips: Add a reset_cpu() function m68k: Add a reset_cpu() function ppc: Add a reset_cpu() function nios2: Add a reset_cpu() function riscv: Add a reset_cpu() function bootm: Adjust how the board is reset sandbox: bootm: Enable more bootm OS methods bootm: Create a struct for argument information bootm: Adjust arguments of boot_os_fn bootm: Add more fields to bootm_info bootm: Move do_bootm_states() comment to header file booti: Avoid use of #ifdef bootz: Avoid use of #ifdef bootm: Drop arguments from do_bootm_states() bootm: Rename do_bootm_states() to bootm_run_states() bootm: Tidy up boot_selected_os() bootm: Create a function to run through the bootm states stm32: Use local vars in stm32prog for initrd and fdt bootm: Create a function to run through the bootz states stm32: Use bootm_run() and bootz_run() bootm: Create a function to run through the booti states arch/arc/lib/bootm.c | 5 +- arch/arm/lib/bootm.c | 6 +- .../cmd_stm32prog/cmd_stm32prog.c | 33 +++-- arch/m68k/lib/bootm.c | 5 +- arch/m68k/lib/traps.c | 7 + arch/microblaze/lib/bootm.c | 6 +- arch/mips/cpu/cpu.c | 8 +- arch/mips/lib/bootm.c | 8 +- arch/nios2/cpu/cpu.c | 8 +- arch/nios2/lib/bootm.c| 10 +- arch/powerpc/lib/bootm.c | 5 +- arch/powerpc/lib/traps.c | 10 ++ arch/riscv/cpu/cpu.c | 13 ++ arch/riscv/lib/bootm.c| 11 +- arch/riscv/lib/reset.c| 7 +- arch/sandbox/cpu/cpu.c| 8 ++ arch/sandbox/lib/bootm.c | 5 +- arch/sh/lib/bootm.c | 6 +- arch/x86/lib/bootm.c | 6 +- arch/xtensa/lib/bootm.c | 4 +- boot/bootm.c | 133 ++ boot/bootm_os.c | 78 +- cmd/booti.c | 55 +--- cmd/bootm.c | 43 -- cmd/bootz.c | 35 +++-- configs/sandbox_defconfig | 3 +- include/bootm.h | 124 ++-- 27 files changed, 440 insertions(+), 202 deletions(-) -- 2.43.0.472.g3155946c3a-goog
[PATCH] arm: spl: Use separate fault handlers instead of a single common one
It may be necessary to set breakpoints etc. on a specific fault handler in SPL. Add a Kconfig option to separate the different handlers into their own individual infinite loops. Signed-off-by: Csókás Bence --- arch/arm/Kconfig | 10 ++ arch/arm/lib/vectors.S | 18 ++ 2 files changed, 28 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 328e2ddc33..47494cb72b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -79,6 +79,16 @@ config SPL_SYS_NO_VECTOR_TABLE depends on SPL bool +config SPL_USE_SEPARATE_FAULT_HANDLERS + bool "Use separate fault handlers instead of a single common one" + depends on !SPL_SYS_NO_VECTOR_TABLE + default n + help + Instead of a common fault handler, generate a separate one for + undefined_instruction, software_interrupt, prefetch_abort etc. + This is for debugging purposes, when you want to set breakpoints + on them separately. + config LINUX_KERNEL_IMAGE_HEADER depends on ARM64 bool diff --git a/arch/arm/lib/vectors.S b/arch/arm/lib/vectors.S index 7cf7d1636f..a14bca6fb8 100644 --- a/arch/arm/lib/vectors.S +++ b/arch/arm/lib/vectors.S @@ -138,11 +138,29 @@ _fiq: .word fiq #if !CONFIG_IS_ENABLED(SYS_NO_VECTOR_TABLE) .align 5 undefined_instruction: +#if CONFIG_IS_ENABLED(USE_SEPARATE_FAULT_HANDLERS) + b undefined_instruction +#endif software_interrupt: +#if CONFIG_IS_ENABLED(USE_SEPARATE_FAULT_HANDLERS) + b software_interrupt +#endif prefetch_abort: +#if CONFIG_IS_ENABLED(USE_SEPARATE_FAULT_HANDLERS) + b prefetch_abort +#endif data_abort: +#if CONFIG_IS_ENABLED(USE_SEPARATE_FAULT_HANDLERS) + b data_abort +#endif not_used: +#if CONFIG_IS_ENABLED(USE_SEPARATE_FAULT_HANDLERS) + b not_used +#endif irq: +#if CONFIG_IS_ENABLED(USE_SEPARATE_FAULT_HANDLERS) + b irq +#endif fiq: 1: b 1b /* hang and never return */ -- 2.25.1
[PATCH v2 21/21] bootm: Create a function to run through the booti states
In a few places, the booti command is used to handle a boot. We want
these to be done without needing CONFIG_CMDLINE, so add a new
booti_run() function to handle this.
So far this is not used.
Signed-off-by: Simon Glass
---
Changes in v2:
- Rework series to allow OS access to cmdline arguments for bootm
boot/bootm.c| 13 +
include/bootm.h | 13 +
2 files changed, 26 insertions(+)
diff --git a/boot/bootm.c b/boot/bootm.c
index 1c5a99817a82..248341c927d9 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1155,6 +1155,19 @@ int bootz_run(struct bootm_info *bmi)
return bootm_run_states(bmi, states);
}
+int booti_run(struct bootm_info *bmi)
+{
+ int states;
+
+ bmi->cmd_name = "booti";
+ states = BOOTM_STATE_MEASURE | BOOTM_STATE_OS_PREP |
+ BOOTM_STATE_OS_FAKE_GO | BOOTM_STATE_OS_GO;
+ if (IS_ENABLED(CONFIG_SYS_BOOT_RAMDISK_HIGH))
+ states |= BOOTM_STATE_RAMDISK;
+
+ return bootm_run_states(bmi, states);
+}
+
int bootm_boot_start(ulong addr, const char *cmdline)
{
char addr_str[30];
diff --git a/include/bootm.h b/include/bootm.h
index 4665c7a24fa5..2245503eb0ea 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -176,6 +176,19 @@ int bootm_run(struct bootm_info *bmi);
*/
int bootz_run(struct bootm_info *bmi);
+/**
+ * booti_run() - Run the entire booti process
+ *
+ * This runs through the booti process from start to finish, using the default
+ * set of states.
+ *
+ * This uses bootm_run_states().
+ *
+ * @bmi: bootm information
+ * Return: 0 if ok, something else on error
+ */
+int booti_run(struct bootm_info *bmi);
+
void arch_preboot_os(void);
/*
--
2.43.0.472.g3155946c3a-goog
[PATCH v2 20/21] stm32: Use bootm_run() and bootz_run()
Use the new bootm/z_run() functions to avoid having to create an
argument list for the stm32prog code.
Signed-off-by: Simon Glass
---
(no changes since v1)
.../cmd_stm32prog/cmd_stm32prog.c | 20 ++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
index 8670535844d3..3ed393b7199f 100644
--- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
+++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -125,12 +126,10 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
char dtb_addr[20];
char initrd_addr[40];
char *fdt_arg, *initrd_arg;
- char *bootm_argv[5] = {
- "bootm", boot_addr_start,
- };
const void *uimage = (void *)data->uimage;
const void *dtb = (void *)data->dtb;
const void *initrd = (void *)data->initrd;
+ struct bootm_info bmi;
fdt_arg = dtb_addr;
if (!dtb)
@@ -141,7 +140,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
"0x%p", uimage);
- initrd_arg = "-";
+ initrd_arg = NULL;
if (initrd) {
snprintf(initrd_addr, sizeof(initrd_addr) - 1,
"0x%p:0x%zx", initrd, data->initrd_size);
@@ -149,15 +148,18 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag,
int argc,
}
printf("Booting kernel at %s %s %s...\n\n\n", boot_addr_start,
- initrd_arg, fdt_arg);
- bootm_argv[2] = initrd_arg;
- bootm_argv[3] = fdt_arg;
+ initrd_arg ?: "-", fdt_arg);
+
+ bootm_init();
+ bmi.addr_fit = boot_addr_start;
+ bmi.conf_ramdisk = initrd_arg;
+ bmi.conf_fdt = fdt_arg;
/* Try bootm for legacy and FIT format image */
if (genimg_get_format(uimage) != IMAGE_FORMAT_INVALID)
- do_bootm(cmdtp, 0, 4, bootm_argv);
+ bootm_run();
else if (IS_ENABLED(CONFIG_CMD_BOOTZ))
- do_bootz(cmdtp, 0, 4, bootm_argv);
+ bootz_run();
}
if (data->script)
cmd_source_script(data->script, NULL, NULL);
--
2.43.0.472.g3155946c3a-goog
