[RFC] mmc: Remove alignment hole for cmdidx in struct mmc_cmd
The alignment hole caused by cmdidx in struct mmc_cmd cause strange
issues together with the peephole2 optimization on Amlogic SoCs.
Following was observed while working on SPL support for Amlogic SoCs.
sd_get_capabilities() normally issue a CMD55 followed by a CMD51.
However, on at least Amlogic S905 (Cortex-A53) and S905X3 (Cortex-A55),
CMD55 was instead followed by CMD8 (and a few reties) in SPL.
Code from the call site:
cmd.cmdidx = SD_CMD_APP_SEND_SCR; // 51
...
data.blocksize = 8;
...
err = mmc_send_cmd_retry(mmc, , , 3);
Running the code with MMC_TRACE enabled shows:
CMD_SEND:55
ARG 0x5048
MMC_RSP_R1,5,6,7 0x0920
CMD_SEND:8
ARG 0x
RET -110
Removing the alignment hole by changing cmdidx from ushort to uint or
building with -fno-peephole2 flag seem to resolve this issue.
CMD_SEND:55
ARG 0x5048
MMC_RSP_R1,5,6,7 0x0920
CMD_SEND:51
ARG 0x
MMC_RSP_R1,5,6,7 0x0920
Same issue was observed building U-Boot with gcc 8-13. Please advise on
how to best work around this possible gcc optimization bug.
Signed-off-by: Jonas Karlman
---
arch/arm/cpu/armv8/config.mk | 2 ++
include/mmc.h| 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk
index 4d74b2a533e0..7177dcd7c73b 100644
--- a/arch/arm/cpu/armv8/config.mk
+++ b/arch/arm/cpu/armv8/config.mk
@@ -7,6 +7,8 @@ PLATFORM_RELFLAGS += $(call cc-option,-mbranch-protection=none)
PF_NO_UNALIGNED := $(call cc-option, -mstrict-align)
PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED)
+PLATFORM_CPPFLAGS += $(call cc-option,-fno-peephole2)
+
EFI_LDS := elf_aarch64_efi.lds
EFI_CRT0 := crt0_aarch64_efi.o
EFI_RELOC := reloc_aarch64_efi.o
diff --git a/include/mmc.h b/include/mmc.h
index 9aef31ea5deb..7b3868bb5664 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -413,7 +413,7 @@ struct mmc_cid {
};
struct mmc_cmd {
- ushort cmdidx;
+ uint cmdidx;
uint resp_type;
uint cmdarg;
uint response[4];
--
2.42.0
[PATCH] board/km/cent2: Fix buffer overflow when fixing MAC address
String "/soc/fman/ethernet@e8000" is 25 bytes long
and not 24 due to extra byte for null character at
the end.
Signed-off-by: Francois Berder
---
board/keymile/kmcent2/kmcent2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/keymile/kmcent2/kmcent2.c b/board/keymile/kmcent2/kmcent2.c
index ed552c57b5..cd3a649c16 100644
--- a/board/keymile/kmcent2/kmcent2.c
+++ b/board/keymile/kmcent2/kmcent2.c
@@ -291,7 +291,7 @@ int last_stage_init(void)
void fdt_fixup_fman_mac_addresses(void *blob)
{
int node, ret;
- char path[24];
+ char path[25];
unsigned char mac_addr[6];
/*
--
2.34.1
Re: [PATCH] test: Fix SPL tests not being run
On 9/29/23 12:06, Sean Anderson wrote:
> SPL doesn't have OF_LIVE enabled, so we can only run tests with a flat
> tree. Don't skip them even if they don't use the devicetree.
>
> Fixes: 6ec5178c0ef ("test: Skip flat-tree tests if devicetree is not used")
> Signed-off-by: Sean Anderson
> ---
>
> test/test-main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/test/test-main.c b/test/test-main.c
> index 778bf0a18a0..edb20bc4b9c 100644
> --- a/test/test-main.c
> +++ b/test/test-main.c
> @@ -476,7 +476,8 @@ static int ut_run_test_live_flat(struct unit_test_state
> *uts,
>* (for sandbox we handle this by copying the tree, but not for other
>*boards)
>*/
> - if ((test->flags & UT_TESTF_SCAN_FDT) &&
> + if ((!CONFIG_IS_ENABLED(OF_LIVE) ||
> + (test->flags & UT_TESTF_SCAN_FDT)) &&
> !(test->flags & UT_TESTF_LIVE_TREE) &&
> (CONFIG_IS_ENABLED(OFNODE_MULTI_TREE) ||
>!(test->flags & UT_TESTF_OTHER_FDT)) &&
Upon further review, do we even need 6ec5178c0ef in the first place?
ut_test_run_on_flattree looks like it's trying to do the same thing.
--Sean
[PATCH] test: Fix SPL tests not being run
SPL doesn't have OF_LIVE enabled, so we can only run tests with a flat
tree. Don't skip them even if they don't use the devicetree.
Fixes: 6ec5178c0ef ("test: Skip flat-tree tests if devicetree is not used")
Signed-off-by: Sean Anderson
---
test/test-main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/test/test-main.c b/test/test-main.c
index 778bf0a18a0..edb20bc4b9c 100644
--- a/test/test-main.c
+++ b/test/test-main.c
@@ -476,7 +476,8 @@ static int ut_run_test_live_flat(struct unit_test_state
*uts,
* (for sandbox we handle this by copying the tree, but not for other
*boards)
*/
- if ((test->flags & UT_TESTF_SCAN_FDT) &&
+ if ((!CONFIG_IS_ENABLED(OF_LIVE) ||
+(test->flags & UT_TESTF_SCAN_FDT)) &&
!(test->flags & UT_TESTF_LIVE_TREE) &&
(CONFIG_IS_ENABLED(OFNODE_MULTI_TREE) ||
!(test->flags & UT_TESTF_OTHER_FDT)) &&
--
2.35.1.1320.gc452695387.dirty
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
On Fri, Sep 29, 2023 at 09:15:00AM -0600, Simon Glass wrote: > Hi Rasmus, > > On Mon, 25 Sept 2023 at 13:05, Rasmus Villemoes > wrote: > > > > On 25/09/2023 20.19, Tom Rini wrote: > > > On Mon, Sep 25, 2023 at 10:27:43AM +0200, Rasmus Villemoes wrote: > > >> On 04/05/2023 14.35, Rasmus Villemoes wrote: > > >>> On 03/05/2023 16.54, Tom Rini wrote: > > >> > > The one last problem now is on stm32mp15_dhcor_basic which is a > > defconfig missing one from OF_LIST but including it in the its file, so > > the above is the patch we need. > > > > >> > > >> Hi Tom > > >> > > >> Can I persuade you to try something like > > >> https://source.denx.de/u-boot/u-boot/-/commit/a05e0d0e6b9103542a1076f9cab0005f400fa072 > > >> again, but leaving the .dtbo targets in there? > > >> > > >> I could send a patch, but it's entirely mechanical, and not really meant > > >> for being applied until we know if there's more to be cleaned up. > > > > > > So what ended up being the problem I think is the case Simon pointed out > > > where we do take the output from "make all" and concatenate one of the > > > dtbs that was generated with u-boot.img or so, and it works. But maybe > > > that should just list all of the valid DTBs that it needs in the > > > defconfig to start with? I don't quite know, it was a case I hadn't > > > considered at the time. > > > > > > > Re-reading the thread, I can't see where that was mentioned. > > > > But yes, if some boards (still) need that, and have more than one > > possible .dtb, the board can't set an OF_LIST different from the default > > consisting of DEFAULT_DEVICE_TREE because changing OF_LIST requires > > SPL_LOAD_FIT || MULTI_DTB_FIT. > > > > How do we figure out if such boards even exist? > > Honestly at this point I've forgotten what this is all about. > > Perhaps the easiest approach is to create a new Kconfig to control > whether a board-level .dtsi is included in the list of wildcard > searches. Then you can enable it for your board without affecting > others. That's getting things backwards, from what this cleanup does. Today we have messy lists of "build these device trees" and then don't use most of them, and some of the list is just Wrong (listing dts files as an output). With the series to handle dtbo files, we could remove virtually all of that, and the only use cases that don't Just Work still are the ones I forget which board you mentioned (I think it was Samsung tho?) where the defconfig doesn't list all of the device trees, just one of them, and the other 5 that we build can also be easily used. Does that ring a bell? -- Tom signature.asc Description: PGP signature
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
Hi Rasmus, On Mon, 25 Sept 2023 at 13:05, Rasmus Villemoes wrote: > > On 25/09/2023 20.19, Tom Rini wrote: > > On Mon, Sep 25, 2023 at 10:27:43AM +0200, Rasmus Villemoes wrote: > >> On 04/05/2023 14.35, Rasmus Villemoes wrote: > >>> On 03/05/2023 16.54, Tom Rini wrote: > >> > The one last problem now is on stm32mp15_dhcor_basic which is a > defconfig missing one from OF_LIST but including it in the its file, so > the above is the patch we need. > > >> > >> Hi Tom > >> > >> Can I persuade you to try something like > >> https://source.denx.de/u-boot/u-boot/-/commit/a05e0d0e6b9103542a1076f9cab0005f400fa072 > >> again, but leaving the .dtbo targets in there? > >> > >> I could send a patch, but it's entirely mechanical, and not really meant > >> for being applied until we know if there's more to be cleaned up. > > > > So what ended up being the problem I think is the case Simon pointed out > > where we do take the output from "make all" and concatenate one of the > > dtbs that was generated with u-boot.img or so, and it works. But maybe > > that should just list all of the valid DTBs that it needs in the > > defconfig to start with? I don't quite know, it was a case I hadn't > > considered at the time. > > > > Re-reading the thread, I can't see where that was mentioned. > > But yes, if some boards (still) need that, and have more than one > possible .dtb, the board can't set an OF_LIST different from the default > consisting of DEFAULT_DEVICE_TREE because changing OF_LIST requires > SPL_LOAD_FIT || MULTI_DTB_FIT. > > How do we figure out if such boards even exist? Honestly at this point I've forgotten what this is all about. Perhaps the easiest approach is to create a new Kconfig to control whether a board-level .dtsi is included in the list of wildcard searches. Then you can enable it for your board without affecting others. Regards, Simon
Re: [PULL] u-boot-at91-fixes-2023.10-b
On Fri, Sep 29, 2023 at 05:36:38PM +0300, Eugen Hristev wrote: > > Hello Tom, > > Please pull tag u-boot-at91-fixes-2023.10-b , the second set of fixes for > 2023.10 cycle. > > This comes late, but I hope you can merge it before the release, it's only > two small fixes , one for an array not initialized and the second one fixes > an error case when a DT property is missing for the atmel NAND driver. > > Thanks, > Eugen > > > The following changes since commit 15155ab0a3d1f839509bcac620bfb38f950bead6: > > Merge tag 'u-boot-imx-20230923' of > https://source.denx.de/u-boot/custodians/u-boot-imx (2023-09-24 17:15:31 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-at91.git > tags/u-boot-at91-fixes-2023.10-b > > for you to fetch changes up to 7b4ffe8c32db284e25d3a2636904def8e093da9e: > > clk: at91: Fix initializing arrays (2023-09-29 16:45:40 +0300) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PULL] u-boot-at91-fixes-2023.10-b
Hello Tom, Please pull tag u-boot-at91-fixes-2023.10-b , the second set of fixes for 2023.10 cycle. This comes late, but I hope you can merge it before the release, it's only two small fixes , one for an array not initialized and the second one fixes an error case when a DT property is missing for the atmel NAND driver. Thanks, Eugen The following changes since commit 15155ab0a3d1f839509bcac620bfb38f950bead6: Merge tag 'u-boot-imx-20230923' of https://source.denx.de/u-boot/custodians/u-boot-imx (2023-09-24 17:15:31 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-at91.git tags/u-boot-at91-fixes-2023.10-b for you to fetch changes up to 7b4ffe8c32db284e25d3a2636904def8e093da9e: clk: at91: Fix initializing arrays (2023-09-29 16:45:40 +0300) Second set of u-boot-atmel fixes for the 2023.10 cycle Alexander Dahl (1): mtd: nand: raw: atmel: Add error handling when rb-gpios missing Francois Berder (1): clk: at91: Fix initializing arrays drivers/clk/at91/sam9x60.c | 4 ++-- drivers/clk/at91/sama7g5.c | 4 ++-- drivers/mtd/nand/raw/atmel/nand-controller.c | 11 +++ 3 files changed, 11 insertions(+), 8 deletions(-)
Re: [PATCH] spl: Jump to image at end of board_init_r
On Fri, Sep 29, 2023 at 07:56:49AM -0400, Tom Rini wrote:
> On Fri, Sep 29, 2023 at 02:57:42AM +0200, Heinrich Schuchardt wrote:
> > On 9/27/23 23:44, Jonas Karlman wrote:
> > > spl_board_prepare_for_boot() is not called before jumping/invoking atf,
> > > optee, opensbi or linux images.
> > >
> > > Jump to image at the end of board_init_r() to fix this.
> > >
> > > Signed-off-by: Jonas Karlman
> > > ---
> > > This patch have dependencies on the following patches:
> > >
> > > spl: add __noreturn attribute to spl_invoke_opensbi function
> > > https://patchwork.ozlabs.org/patch/1827057/
> > >
> > > spl: add __noreturn attribute to spl_invoke_atf function
> > > https://patchwork.ozlabs.org/patch/1831366/
> > >
> > > spl: Drop the switch() statement for OS selection
> > > from the "spl: Preparation for Universal Payload" series
> > > https://patchwork.ozlabs.org/patch/1839731/
> > > ---
> > > common/spl/spl.c | 12 +++-
> > > 1 file changed, 7 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/common/spl/spl.c b/common/spl/spl.c
> > > index f7608f14e365..79c39820262a 100644
> > > --- a/common/spl/spl.c
> > > +++ b/common/spl/spl.c
> > > @@ -647,6 +647,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > > BOOT_DEVICE_NONE,
> > > BOOT_DEVICE_NONE,
> > > };
> > > + typedef void __noreturn (*jump_to_image_t)(struct spl_image_info *);
> > > + jump_to_image_t jump_to_image = _to_image_no_args;
> > > struct spl_image_info spl_image;
> > > int ret, os;
> > >
> > > @@ -735,20 +737,20 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > > } else if (CONFIG_IS_ENABLED(ATF) && os ==
> > > IH_OS_ARM_TRUSTED_FIRMWARE) {
> > > debug("Jumping to U-Boot via ARM Trusted Firmware\n");
> > > spl_fixup_fdt(spl_image_fdt_addr(_image));
> > > - spl_invoke_atf(_image);
> > > + jump_to_image = _invoke_atf;
> > > } else if (CONFIG_IS_ENABLED(OPTEE_IMAGE) && os == IH_OS_TEE) {
> > > debug("Jumping to U-Boot via OP-TEE\n");
> > >
> > > spl_board_prepare_for_optee(spl_image_fdt_addr(_image));
> > > - jump_to_image_optee(_image);
> > > + jump_to_image = _to_image_optee;
> > > } else if (CONFIG_IS_ENABLED(OPENSBI) && os == IH_OS_OPENSBI) {
> > > debug("Jumping to U-Boot via RISC-V OpenSBI\n");
> > > - spl_invoke_opensbi(_image);
> > > + jump_to_image = _invoke_opensbi;
> > > } else if (CONFIG_IS_ENABLED(OS_BOOT) && os == IH_OS_LINUX) {
> > > debug("Jumping to Linux\n");
> > > if (IS_ENABLED(CONFIG_SPL_OS_BOOT))
> > > spl_fixup_fdt((void *)SPL_PAYLOAD_ARGS_ADDR);
> > > spl_board_prepare_for_linux();
> > > - jump_to_image_linux(_image);
> > > + jump_to_image = _to_image_linux;
> > > } else {
> > > debug("Unsupported OS image.. Jumping
> > > nevertheless..\n");
> > > }
> > > @@ -788,7 +790,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > > }
> > >
> > > spl_board_prepare_for_boot();
> > > - jump_to_image_no_args(_image);
> > > + jump_to_image(_image);
> > > }
> > >
> > > /*
> >
> > In SPL we are fighting for every byte of binary size.
> >
> > What is the impact of this change on the code size?
> >
> > I would expect that your increasing it; especially if only one of the
> > CONFIG_OPTIONS is enabled.
> >
> > If so, NAK to this patch despite all elegance.
>
> We aren't _that_ strict, no. And a very quick peek shows that this
> seems fine overall. Since you raised the question I'll do a quick
> world build but socfpga_agilex_vab (as a config I had size change
> results for in front of me for something else) shrank by 4 bytes with
> just the prerequsites and this patch applied.
Yes, this generally is a small shrink or a small growth and fine.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] clk: at91: Fix initializing arrays
On 9/24/23 12:58, Francois Berder wrote: Arrays are not cleared entirely because ARRAY_SIZE returns the number of elements in an array, not the size in bytes. This commit fixes the calls to memset by providing the array size in bytes instead of the number of elements in the array. Signed-off-by: Francois Berder --- Applied to u-boot-at91/ master, thanks !
[PATCH 6/6] arm: dts: k3-am625-sk: Mark dependent nodes for pre-relocation phase
CPSW node needs PHY, MDIO, pinmux, DMA and INTC nodes.
main_conf is required for phy_gmii_sel.
Mark them as 'bootph-all' so they are available in all
pre-relocation phases.
Fixes the below dts warnings:
: Warning (reg_format): /bus@f/syscon@10/phy@4044:reg: property
has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
: Warning (reg_format):
/bus@f/ethernet@800/ethernet-ports/port@1:reg: property has invalid
length (4 bytes) (#address-cells == 2, #size-cells == 1)
: Warning (unit_address_vs_reg): /bus@f/syscon@10: node has a
unit name, but no reg or ranges property
: Warning (pci_device_reg): Failed prerequisite 'reg_format'
: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
: Warning (avoid_default_addr_size): /bus@f/syscon@10/phy@4044:
Relying on default #address-cells value
: Warning (avoid_default_addr_size): /bus@f/syscon@10/phy@4044:
Relying on default #size-cells value
: Warning (avoid_default_addr_size):
/bus@f/ethernet@800/ethernet-ports/port@1: Relying on default
#address-cells value
: Warning (avoid_default_addr_size):
/bus@f/ethernet@800/ethernet-ports/port@1: Relying on default
#size-cells value
: Warning (avoid_unnecessary_addr_size): Failed prerequisite
'avoid_default_addr_size'
: Warning (unique_unit_address): Failed prerequisite
'avoid_default_addr_size'
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 39
1 file changed, 39 insertions(+)
diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index c658506256..b78d34b459 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
@@ -21,6 +21,10 @@
};
};
+_conf {
+ bootph-all;
+};
+
_main {
bootph-all;
};
@@ -118,8 +122,43 @@
};
};
+_main_dmss {
+ bootph-all;
+};
+
+_pktdma {
+ bootph-all;
+};
+
+_mdio {
+ bootph-all;
+};
+
+_phy0 {
+ bootph-all;
+};
+
+_phy1 {
+ bootph-all;
+};
+
+_rgmii1_pins_default {
+ bootph-all;
+};
+
+_rgmii2_pins_default {
+ bootph-all;
+};
+
+_gmii_sel {
+ bootph-all;
+};
+
{
bootph-all;
+ ethernet-ports {
+ bootph-all;
+ };
};
_port1 {
--
2.34.1
[PATCH 5/6] arm: dts: k3-am625-sk: Fix boot
Since commit [1] A53 u-boot proper is broken.
This is because nodes marked as 'bootph-pre-ram' are
not available at u-boot proper before relocation.
To fix this we mark all nodes in sk-u-boot.dtsi as
'bootph-all'.
[1]
9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after
relocation")
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 54 ++--
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
index c1685bc9ca..c658506256 100644
--- a/arch/arm/dts/k3-am625-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-sk-u-boot.dtsi
@@ -17,113 +17,113 @@
};
memory@8000 {
- bootph-pre-ram;
+ bootph-all;
};
};
_main {
- bootph-pre-ram;
+ bootph-all;
};
_timer0 {
clock-frequency = <2500>;
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_proxy_main {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_pds {
- bootph-pre-ram;
+ bootph-all;
};
_clks {
- bootph-pre-ram;
+ bootph-all;
};
_reset {
- bootph-pre-ram;
+ bootph-all;
};
_conf {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_mcu {
- bootph-pre-ram;
+ bootph-all;
};
_wakeup {
- bootph-pre-ram;
+ bootph-all;
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_mmc1_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
flash@0 {
- bootph-pre-ram;
+ bootph-all;
partitions {
- bootph-pre-ram;
+ bootph-all;
partition@3fc {
- bootph-pre-ram;
+ bootph-all;
};
};
};
};
{
- bootph-pre-ram;
+ bootph-all;
};
_port1 {
- bootph-pre-ram;
+ bootph-all;
};
_port2 {
--
2.34.1
[PATCH 4/6] arm: dts: k3-am642-sk: Mark dependent nodes for pre-relocation phase
CPSW node needs PHY, MDIO, pinmux, DMA and INTC nodes.
Mark them as 'bootph-all' so they are available in all
pre-relocation phases.
Fixes below dts warnings:
: Warning (reg_format):
/bus@f4000/ethernet@800/mdio@f00/ethernet-phy@1:reg: property has invalid
length (4 bytes) (#address-cells == 2, #size-cells == 1)
: Warning (unit_address_vs_reg): /bus@f4000/ethernet@800/mdio@f00:
node has a unit name, but no reg or ranges property
: Warning (pci_device_reg): Failed prerequisite 'reg_format'
: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
: Warning (avoid_default_addr_size):
/bus@f4000/ethernet@800/mdio@f00/ethernet-phy@1: Relying on default
#address-cells value
: Warning (avoid_default_addr_size):
/bus@f4000/ethernet@800/mdio@f00/ethernet-phy@1: Relying on default
#size-cells value
: Warning (avoid_unnecessary_addr_size): Failed prerequisite
'avoid_default_addr_size'
: Warning (unique_unit_address): Failed prerequisite
'avoid_default_addr_size'
: Warning (msi_parent_property):
/bus@f4000/bus@4800/dma-controller@485c0100:msi-parent: Could not get
phandle node for (cell 0)
: Warning (msi_parent_property):
/bus@f4000/bus@4800/dma-controller@485c:msi-parent: Could not get
phandle node for (cell 0)
: Warning (phys_property):
/bus@f4000/ethernet@800/ethernet-ports/port@2:phys: Could not get phandle
node for (cell 0)
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 5599977f6c..40a53df0b0 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -92,6 +92,38 @@
bootph-all;
};
+_main_dmss {
+ bootph-all;
+};
+
+_pktdma {
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+_mdio {
+ bootph-all;
+};
+
+_phy0 {
+ bootph-all;
+};
+
+_phy1 {
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
{
bootph-all;
@@ -100,6 +132,10 @@
};
};
+_gmii_sel {
+ bootph-all;
+};
+
_port2 {
bootph-all;
};
--
2.34.1
[PATCH 3/6] arm: dts: k3-am642-sk: Fix boot
Since commit [1] A53 u-boot proper is broken.
This is because nodes marked as 'bootph-pre-ram' are
not available at u-boot proper before relocation.
To fix this we mark all nodes in sk-u-boot.dtsi as
'bootph-all'.
Move cbass_mcu node to -r5-sk.dts as it is only required
for R5 SPL.
[1]
9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after
relocation")
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-r5-sk.dts | 4 ++
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 76 +---
2 files changed, 40 insertions(+), 40 deletions(-)
diff --git a/arch/arm/dts/k3-am642-r5-sk.dts b/arch/arm/dts/k3-am642-r5-sk.dts
index def4622ff1..daa483a781 100644
--- a/arch/arm/dts/k3-am642-r5-sk.dts
+++ b/arch/arm/dts/k3-am642-r5-sk.dts
@@ -53,6 +53,10 @@
bootph-pre-ram;
};
+_mcu {
+ bootph-pre-ram;
+};
+
_esm {
bootph-pre-ram;
};
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index c277ef8aba..5599977f6c 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -11,129 +11,125 @@
};
memory@8000 {
- bootph-pre-ram;
+ bootph-all;
};
};
_main{
- bootph-pre-ram;
-};
-
-_mcu {
- bootph-pre-ram;
+ bootph-all;
};
_timer0 {
- bootph-pre-ram;
+ bootph-all;
clock-frequency = <2>;
};
_conf {
- bootph-pre-ram;
+ bootph-all;
chipid@14 {
- bootph-pre-ram;
+ bootph-all;
};
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_i2c0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_i2c0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_proxy_main {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
k3_sysreset: sysreset-controller {
compatible = "ti,sci-sysreset";
- bootph-pre-ram;
+ bootph-all;
};
};
_pds {
- bootph-pre-ram;
+ bootph-all;
};
_clks {
- bootph-pre-ram;
+ bootph-all;
};
_reset {
- bootph-pre-ram;
+ bootph-all;
};
{
status = "disabled";
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_mmc1_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
ethernet-ports {
- bootph-pre-ram;
+ bootph-all;
};
};
_port2 {
- bootph-pre-ram;
+ bootph-all;
};
_bcdma {
- bootph-pre-ram;
+ bootph-all;
};
_pktdma {
- bootph-pre-ram;
+ bootph-all;
};
_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_phy1 {
- bootph-pre-ram;
+ bootph-all;
};
_usb0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_ln_ctrl {
@@ -141,25 +137,25 @@
};
{
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_wiz0 {
- bootph-pre-ram;
+ bootph-all;
};
_usb_link {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_refclk {
- bootph-pre-ram;
+ bootph-all;
};
--
2.34.1
[PATCH 2/6] arm: dts: k3-am64-evm: Mark dependent nodes for pre-relocation phase
CPSW node needs PHY, MDIO, pinmux, DMA and INTC nodes.
USB and MMC nodes need pinmux.
Mark them as 'bootph-all' so they are available in all
pre-relocation phases.
Fixes below dts warning:
: Warning (dmas_property): /bus@f4000/ethernet@800:dmas: Could not
get phandle node for (cell 0)
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 48 +++
arch/arm/dts/k3-am642-r5-evm.dts | 8 +
2 files changed, 56 insertions(+)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index d06955dfbc..953bbe9aaf 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -51,6 +51,10 @@
bootph-all;
};
+_usb0_pins_default {
+ bootph-all;
+};
+
{
dr_mode="peripheral";
bootph-all;
@@ -100,12 +104,56 @@
bootph-all;
};
+_mmc1_pins_default {
+ bootph-all;
+};
+
{
bootph-all;
};
+_main_dmss {
+ bootph-all;
+};
+
+_pktdma {
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+_mdio {
+ bootph-all;
+};
+
+_phy0 {
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
+_pins_default {
+ bootph-all;
+};
+
{
bootph-all;
+
+ ethernet-ports {
+ bootph-all;
+ };
+};
+
+_gmii_sel {
+ bootph-all;
+};
+
+_port1 {
+ bootph-all;
};
_port2 {
diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index 696735d8e2..64b3c3af63 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -74,6 +74,14 @@
ti,secure-host;
};
+_supply {
+ bootph-pre-ram;
+};
+
+ {
+ vtt-supply = <_supply>;
+};
+
{
clocks = <_200mhz>;
clock-names = "clk_xin";
--
2.34.1
[PATCH 1/6] arm: dts: k3-am64-evm: Fix boot
Since commit [1] A53 u-boot proper is broken.
This is because nodes marked as 'bootph-pre-ram' are
not available at u-boot proper before relocation.
To fix this we mark all nodes in sk-u-boot.dtsi as
'bootph-all'.
Move vtt_supply and cbass_mcu node to -r5-evm.dts as
it is only required for R5 SPL.
[1]
9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after
relocation")
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 56 ---
arch/arm/dts/k3-am642-r5-evm.dts | 8
2 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index c85f57d40f..d06955dfbc 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -11,109 +11,101 @@
};
memory@8000 {
- bootph-pre-ram;
+ bootph-all;
};
};
-_supply {
- bootph-pre-ram;
-};
-
_main {
- bootph-pre-ram;
-};
-
-_mcu {
- bootph-pre-ram;
+ bootph-all;
};
_timer0 {
- bootph-pre-ram;
+ bootph-all;
clock-frequency = <2>;
};
_conf {
- bootph-pre-ram;
+ bootph-all;
chipid@14 {
- bootph-pre-ram;
+ bootph-all;
};
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_i2c0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_i2c0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
{
dr_mode="peripheral";
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_mmc1_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_usb0_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_proxy_main {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
k3_sysreset: sysreset-controller {
compatible = "ti,sci-sysreset";
- bootph-pre-ram;
+ bootph-all;
};
};
_pds {
- bootph-pre-ram;
+ bootph-all;
};
_clks {
- bootph-pre-ram;
+ bootph-all;
};
_reset {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_port2 {
diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index 73461f8f6c..696735d8e2 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -40,6 +40,10 @@
};
};
+_supply {
+ bootph-pre-ram;
+};
+
_main {
sysctrler: sysctrler {
compatible = "ti,am654-system-controller";
@@ -53,6 +57,10 @@
bootph-pre-ram;
};
+_mcu {
+ bootph-pre-ram;
+};
+
_esm {
bootph-pre-ram;
};
--
2.34.1
[RESEND PATCH 0/6] arm: dts: k3-am64 / k3-am62: Fix boot
Hi,
(Apologies for resend as I missed the u-boot list the last time.
Thanks Vignesh for catching this :) )
Since commit [1] A53 u-boot proper is broken.
This is because nodes marked as 'bootph-pre-ram' are
not availble at u-boot proper before relocation.
To fix this we mark all nodes in sk-u-boot.dtsi as
'bootph-all'.
Move cbass_mcu node to -r5-sk.dts as it is only required
for R5 SPL.
[1]
9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc after
relocation")
In addition to this we also fix some dts warnings related
to CPSW nodes in R5 SPL DTBs.
cheers,
-roger
Roger Quadros (6):
arm: dts: k3-am64-evm: Fix boot
arm: dts: k3-am64-evm: Mark dependent nodes for pre-relocation phase
arm: dts: k3-am642-sk: Fix boot
arm: dts: k3-am642-sk: Mark dependent nodes for pre-relocation phase
arm: dts: k3-am625-sk: Fix boot
arm: dts: k3-am625-sk: Mark dependent nodes for pre-relocation phase
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 93 ++---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 104
arch/arm/dts/k3-am642-r5-evm.dts | 16
arch/arm/dts/k3-am642-r5-sk.dts | 4 +
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 112 +-
5 files changed, 230 insertions(+), 99 deletions(-)
base-commit: 90c81f407dd4a7747385b10f9b8f732202c45cde
--
2.34.1
Re: [PATCH 15/19] ARM: dts: renesas: Synchronize RZ R8A774A1 RZ/G2M DTs with Linux 6.5.3
On Sun, Sep 17, 2023 at 9:18 AM Marek Vasut
wrote:
>
> Synchronize RZ R8A774A1 RZ/G2M DTs with Linux 6.5.3,
Thanks!
> commit 238589d0f7b421aae18c5704dc931595019fa6c7 .
>
> Signed-off-by: Marek Vasut
Reviewed-by: Adam Ford
> ---
> arch/arm/dts/beacon-renesom-baseboard.dtsi | 45 ++
> arch/arm/dts/beacon-renesom-som.dtsi | 2 +-
> arch/arm/dts/hihope-common.dtsi| 21 --
> arch/arm/dts/r8a774a1-beacon-rzg2m-kit.dts | 21 --
> arch/arm/dts/r8a774a1-u-boot.dtsi | 1 -
> arch/arm/dts/r8a774a1.dtsi | 14 ---
> 6 files changed, 57 insertions(+), 47 deletions(-)
>
> diff --git a/arch/arm/dts/beacon-renesom-baseboard.dtsi
> b/arch/arm/dts/beacon-renesom-baseboard.dtsi
> index 8166e3c1ff4..2e9927b9773 100644
> --- a/arch/arm/dts/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm/dts/beacon-renesom-baseboard.dtsi
> @@ -367,7 +367,7 @@
>
> assigned-clocks = <_bb 1>, <_bb 2>,
> <_bb 3>, <_bb 4>;
> - assigned-clock-rates = <2400>, <2400>, <2400>,
> + assigned-clock-rates = <2400>, <2400>, <24576000>,
><24576000>;
>
> OUT1 {
> @@ -437,20 +437,6 @@
> };
> };
>
> - /* 0 - lcd_reset */
> - /* 1 - lcd_pwr */
> - /* 2 - lcd_select */
> - /* 3 - backlight-enable */
> - /* 4 - Touch_shdwn */
> - /* 5 - LCD_H_pol */
> - /* 6 - lcd_V_pol */
> - gpio_exp1: gpio@20 {
> - compatible = "onnn,pca9654";
> - reg = <0x20>;
> - gpio-controller;
> - #gpio-cells = <2>;
> - };
> -
> touchscreen@26 {
> compatible = "ilitek,ili2117";
> reg = <0x26>;
> @@ -482,6 +468,16 @@
> };
> };
> };
> +
> + gpio_exp1: gpio@70 {
> + compatible = "nxp,pca9538";
> + reg = <0x70>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-line-names = "lcd_reset", "lcd_pwr", "lcd_select",
> + "backlight-enable", "Touch_shdwn",
> + "LCD_H_pol", "lcd_V_pol";
> + };
> };
>
> {
> @@ -638,6 +634,25 @@
> #clock-cells = <1>;
> clock-frequency = <11289600>;
>
> + /* Reference versaclock instead of audio_clk_a */
> + clocks = < CPG_MOD 1005>,
> +< CPG_MOD 1006>, < CPG_MOD 1007>,
> +< CPG_MOD 1008>, < CPG_MOD 1009>,
> +< CPG_MOD 1010>, < CPG_MOD 1011>,
> +< CPG_MOD 1012>, < CPG_MOD 1013>,
> +< CPG_MOD 1014>, < CPG_MOD 1015>,
> +< CPG_MOD 1022>, < CPG_MOD 1023>,
> +< CPG_MOD 1024>, < CPG_MOD 1025>,
> +< CPG_MOD 1026>, < CPG_MOD 1027>,
> +< CPG_MOD 1028>, < CPG_MOD 1029>,
> +< CPG_MOD 1030>, < CPG_MOD 1031>,
> +< CPG_MOD 1020>, < CPG_MOD 1021>,
> +< CPG_MOD 1020>, < CPG_MOD 1021>,
> +< CPG_MOD 1019>, < CPG_MOD 1018>,
> +<_bb 4>, <_clk_b>,
> +<_clk_c>,
> +< CPG_CORE CPG_AUDIO_CLK_I>;
> +
> status = "okay";
>
> ports {
> diff --git a/arch/arm/dts/beacon-renesom-som.dtsi
> b/arch/arm/dts/beacon-renesom-som.dtsi
> index d3fc8ffd5b4..68b04e56ae5 100644
> --- a/arch/arm/dts/beacon-renesom-som.dtsi
> +++ b/arch/arm/dts/beacon-renesom-som.dtsi
> @@ -59,7 +59,7 @@
> status = "okay";
>
> phy0: ethernet-phy@0 {
> - compatible = "ethernet-phy-id004d.d074",
> + compatible = "ethernet-phy-id0022.1640",
> "ethernet-phy-ieee802.3-c22";
> reg = <0>;
> interrupt-parent = <>;
> diff --git a/arch/arm/dts/hihope-common.dtsi b/arch/arm/dts/hihope-common.dtsi
> index b1eb6a08029..83104af2813 100644
> --- a/arch/arm/dts/hihope-common.dtsi
> +++ b/arch/arm/dts/hihope-common.dtsi
> @@ -3,15 +3,26 @@
> * Device Tree Source for the HiHope RZ/G2H Rev.4.0 and
> * HiHope RZ/G2[MN] Rev.[2.0/3.0/4.0] main board common parts
> *
> - * Copyright (C) 2021 Renesas Electronics Corp.
> + * Copyright (C) 2019 Renesas Electronics Corp.
> */
>
> #include
>
> / {
> aliases {
> + i2c0 =
> + i2c1 =
> + i2c2 =
> + i2c3 =
> + i2c4 =
> + i2c5 =
> + i2c6 =
> + i2c7 = _pmic;
> serial0 =
> serial1 =
> + mmc0 =
> + mmc1 =
> + mmc2 =
> };
>
> chosen {
> @@ -50,7 +61,7 @@
> };
> };
>
> - reg_1p8v: regulator0 {
> + reg_1p8v: regulator-1p8v {
>
Re: [PATCH] configs: iot2050: Disable CONFIG_CONSOLE_MUX
On Wed, Sep 27, 2023 at 07:22:04PM +0200, Jan Kiszka wrote: > From: Jan Kiszka > > We only have serial as console option, and leaving this on turns on > SYS_CONSOLE_IS_IN_ENV which is also not true for these devices, leaving > an ugly > > In:No input devices available! > Out: No output devices available! > Err: No error devices available! > > behind. > > Signed-off-by: Jan Kiszka Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] smegw01: Fix inverted CONFIG_SYS_BOOT_LOCKED logic
On Mon, Sep 25, 2023 at 01:32:59PM -0300, Fabio Estevam wrote: > From: Eduard Strehlau > > CONFIG_SYS_BOOT_LOCKED means that a restricted boot environment will > be used. In this case, hab_auth_img_or_fail should be called to prevent > U-Boot to continue running when the fitImage authentication fails. > > Fix the logic accordingly. > > Additionally, select CONFIG_SYS_BOOT_LOCKED by default. > > Signed-off-by: Eduard Strehlau > Signed-off-by: Fabio Estevam Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3] env: ti: ti_common.env: Fix get_overlaystring for FIT Image
On Mon, Sep 25, 2023 at 11:53:42AM +0530, Manorit Chawdhry wrote:
> After the refactor with conf- nodes in fitImage, overlaystring wasn't
> didn't handle the new conf- nodes in FIT Booting. Fix get_overlaystring
> to handle conf- nodes.
>
> Fixes: 837833a724b7 ("environment: ti: Add get_fit_config command to get FIT
> config string")
> Reported-by: Aniket Limaye
> Signed-off-by: Manorit Chawdhry
> Reviewed-by: Andrew Davis
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/4] mkimage: also honour -B even without external data
On 9/28/23 03:10, Rasmus Villemoes wrote: On 27/09/2023 21.02, Sean Anderson wrote: On 9/19/23 07:37, Rasmus Villemoes wrote: In some cases, using the "external data" feature is impossible or undesirable, but one may still want (or need) the FIT image to have a certain alignment. Also, given the current 'mkimage -h' output, -B => align size in hex for FIT structure and header it is quite unexpected for -B to be effectively ignored without -E. FWIW, this behavior is documented in doc/mkimage.1 (which should also be updated if this behavior is implemented): | The alignment, in hexadecimal, that external data will be aligned to. | This option only has an effect when -E is specified. I'll send a follow-up to fix that, thanks. And, for additional context, the documentation for -E is | After processing, move the image data outside the FIT and store a data | offset in the FIT. Images will be placed one after the other | immediately after the FIT, with each one aligned to a 4-byte boundary. | The existing ‘data’ property in each image will be replaced with | ‘data-offset’ and ‘data-size’ properties. A ‘data-offset’ of 0 | indicates that it starts in the first (4-byte-aligned) byte after the | FIT. Based on this documentation and my understanding of the code as-is, -B controls the alignment of the images themselves, Yes, when -E is in effect. My patch does not affect the case where -E is present. Wherever possible, flags should be orthogonal. That is, they should have the same effect (or at least the same spirit) regardless of the presence of other flags. This matches their UX, as orthogonally selectable options. not the size multiple of the FIT. It is _also_ that, but mostly as a "necessary side effect" of getting the first image aligned. In order to achieve the desired alignment of the first external image, the FIT structure itself is aligned to the -B value, and each image's size similarly aligned up to that value so the next image ends on a -B multiple again. So with both -E and -B, the FIT structure itself is indeed also padded to the -B value, as the `mkimage -h` output suggests. The intent of -B is to align images. That the FIT itself is padded is an implementation detail. What I want, and expected from `mkimage -h`, is to make the whole FIT have a certain size multiple, without using -E, so in that case the alignment of the FIT is the primary goal. Why does mkimage have to do this? Can't you just use truncate or, in a binman context, align-size? However, from what I can tell, this patch does not actually affect the alignment of the images, No, because the images are (still) embedded within the FIT as ordinary values of the data= properties, and it's a basic property of the DTB format that those are always 4-byte aligned, and you can't (easily) change that [1]. Which, I suppose, is one of the reasons U-Boot invented the "external data" mechanism - so for example the .dtbs embedded in the FIT can all be guaranteed to be on an 8-byte boundary, and thus the selected one can be used in-place when passed to linux. but rather adjusts the size of the overall FIT to a certain alignment. I find this rather unexpected. Well, as I said, _I_ was surprised by -B having no effect based on the `mkimage -h` output, so the two sources of documentation were not in sync. The man page was/is correct wrt. the actual code. The mkimage -h putput is too terse to record the complete behavior of each option. Perhaps we should add a warning when -B is specified without -E. Rasmus [1] There's a nop tag one can insert, and I think I saw somebody actually suggesting to do that to align the embedded data= properties, but it's quite error-prone and inflexible, as any subsequent modification of the .dtb before that property will ruin the alignment. This would indeed be the way to go. I don't think we should worry about further modification of the fdt, as this could also ruin the alignment of external images. --Sean
Re: [PATCH 1/3] mtd: spi-nor: Add spi flash lock config option
On 9/28/23 05:49, Venkatesh Yadav Abbarapu wrote:
Provide an explicit configuration option to disable default "lock"
of any flash chip which supports locking.
Please also write reason for it. Based on 2/3 and 3/3 I expect you want to save
some memory.
Another reason could be not expose that functionality to be exposed to users.
Should we also guard sf protect command itself? It could give us additional
space.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/mtd/spi/Kconfig| 7 +++
drivers/mtd/spi/spi-nor-core.c | 8 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index a9617c6c58..476d848321 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -134,6 +134,13 @@ config SPI_FLASH_BAR
Bank/Extended address registers are used to access the flash
which has size > 16MiB in 3-byte addressing.
+config SPI_FLASH_LOCK
+ bool "Enable the Locking feature"
+ default y
+ help
+Enable the SPI flash lock support. By default this is set to y.
+If you intend not to use the lock support you should say n here.
+
config SPI_FLASH_UNLOCK_ALL
bool "Unlock the entire SPI flash on u-boot startup"
default y
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 6093277f17..9c51f2b1b0 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -1099,6 +1099,7 @@ static int spansion_erase_non_uniform(struct spi_nor
*nor, u32 addr,
}
#endif
+#if defined(CONFIG_SPI_FLASH_LOCK)
#if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
/* Write status register and ensure bits in mask match written values */
static int write_sr_and_check(struct spi_nor *nor, u8 status_new, u8 mask)
@@ -1386,6 +1387,7 @@ static int stm_is_unlocked(struct spi_nor *nor, loff_t
ofs, uint64_t len)
return stm_is_unlocked_sr(nor, ofs, len, status);
}
#endif /* CONFIG_SPI_FLASH_STMICRO */
+#endif
static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
{
@@ -1461,6 +1463,7 @@ read_err:
return ret;
}
+#if defined(CONFIG_SPI_FLASH_LOCK)
#ifdef CONFIG_SPI_FLASH_SST
/*
* sst26 flash series has its own block protection implementation:
@@ -1729,6 +1732,8 @@ sst_write_err:
return ret;
}
#endif
+#endif
+
/*
* Write an address range to the nor chip. Data must be written in
* FLASH_PAGESIZE chunks. The address range may be any size provided
@@ -4103,6 +4108,7 @@ int spi_nor_scan(struct spi_nor *nor)
mtd->_read = spi_nor_read;
mtd->_write = spi_nor_write;
+#if defined(CONFIG_SPI_FLASH_LOCK)
#if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
/* NOR protection support for STmicro/Micron chips and similar */
if (JEDEC_MFR(info) == SNOR_MFR_ST ||
@@ -4126,7 +4132,7 @@ int spi_nor_scan(struct spi_nor *nor)
nor->flash_is_unlocked = sst26_is_unlocked;
}
#endif
-
+#endif
if (info->flags & USE_FSR)
nor->flags |= SNOR_F_USE_FSR;
if (info->flags & SPI_NOR_HAS_TB)
M
Re: [PATCH v5 4/7] efi_loader: support boot from URI device path
On Fri, 29 Sept 2023 at 14:35, Masahisa Kojima
wrote:
>
> Hi Ilias,
>
> On Fri, 29 Sept 2023 at 20:48, Ilias Apalodimas
> wrote:
> >
> > Hi Kojima-san,
> >
> >
> > [...]
> >
> > > +
> > > +/**
> > > + * try_load_default_file() - try to load the default file
> > > + *
> > > + * Search the device having EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
> > > + * then try to load with the default boot file(e.g.
> > > EFI/BOOT/BOOTAA64.EFI).
> > > + *
> > > + * @dev pointer to the UCLASS_BLK or
> > > UCLASS_PARTITION udevice
> > > + * @image_handle:pointer to handle for newly installed image
> > > + * Return: status code
> > > + */
> > > +static efi_status_t try_load_default_file(struct udevice *dev,
> > > + efi_handle_t *image_handle)
> > > +{
> > > + efi_status_t ret;
> > > + efi_handle_t handle;
> > > + struct efi_handler *handler;
> > > + struct efi_device_path *file_path;
> > > + struct efi_device_path *device_path;
> > > +
> > > + if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **))) {
> > > + log_warning("DM_TAG_EFI not found\n");
> > > + return EFI_INVALID_PARAMETER;
> > > + }
> > > +
> > > + ret = efi_search_protocol(handle,
> > > + _simple_file_system_protocol_guid,
> > > );
> > > + if (ret != EFI_SUCCESS)
> > > + return ret;
> > > +
> > > + ret = EFI_CALL(bs->open_protocol(handle, _guid_device_path,
> > > + (void **)_path, efi_root,
> > > NULL,
> > > + EFI_OPEN_PROTOCOL_GET_PROTOCOL));
> > > + if (ret != EFI_SUCCESS)
> > > + return ret;
> > > +
> > > + file_path = expand_media_path(device_path);
> > > + ret = EFI_CALL(efi_load_image(true, efi_root, file_path, NULL, 0,
> > > + image_handle));
> > > +
> > > + efi_free_pool(file_path);
> > > +
> > > + return ret;
> > > +}
> >
> > We've discussed this on v4, but I am replying here, since you sent a v5 in
> > the meantime.
> > What I ideally wanted to do here is
> > - Add the boot option automatically once the disk gets mount (you've
> > already sent a patch for that)
> > - Since the boot option is automatically added we could instead of
> > searching for BOOTAA64.EFI search for matches with a load option of
> > '1234567'.
> > Is there some timing issue that I am missing which doesnt allow us to do
> > that ?
>
> Sorry, I probably misunderstood your design.
> What kind of boot option is automatically added when the disk is detected?
> Could you share your thoughts about the trigger to search for matches
> with a load option of '1234567'?
You've recently fixed the CI errors and reported this [0]. Once that
gets merged every time a new disk is added, it will be automatically
be scanned for BOOTXXX.efi files. If we do find such files, they will
be added to the efi bootmgr list of available options. We do mark
these with a '1234567' in the optional data.
Once that path gets merged, wouldn't it be simpler to just scan for
boot options with '1234567' in the load options on the mounted image,
instead of rescanning it for BOOTXXX.efi?
[0]
https://lore.kernel.org/u-boot/20230927010436.1503621-1-masahisa.koj...@linaro.org/
Thanks
/Ilias
>
> Thanks,
> Masahisa Kojima
>
> >
> > [...]
> >
> > Cheers
> > /Ilias
Re: [PATCH 2/3] arm64: versal: Disable the lock option for mini ospi and qspi
On 9/28/23 05:49, Venkatesh Yadav Abbarapu wrote: As mini configs are required only for flashing the images, so disabling the lock config which will save nearly 6KB of memory. Signed-off-by: Venkatesh Yadav Abbarapu --- configs/xilinx_versal_mini_ospi_defconfig | 3 ++- configs/xilinx_versal_mini_qspi_defconfig | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/configs/xilinx_versal_mini_ospi_defconfig b/configs/xilinx_versal_mini_ospi_defconfig index 27b59f899a..539ce2d3c0 100644 --- a/configs/xilinx_versal_mini_ospi_defconfig +++ b/configs/xilinx_versal_mini_ospi_defconfig @@ -12,7 +12,6 @@ CONFIG_SF_DEFAULT_SPEED=3000 CONFIG_ENV_SIZE=0x80 # CONFIG_DM_GPIO is not set CONFIG_DEFAULT_DEVICE_TREE="versal-mini-ospi-single" -CONFIG_SYS_PROMPT="Versal> " CONFIG_SYS_MEM_RSVD_FOR_MMU=y CONFIG_VERSAL_NO_DDR=y # CONFIG_PSCI_RESET is not set @@ -27,6 +26,7 @@ CONFIG_BOARD_EARLY_INIT_R=y # CONFIG_CMDLINE_EDITING is not set # CONFIG_AUTO_COMPLETE is not set # CONFIG_SYS_LONGHELP is not set +CONFIG_SYS_PROMPT="Versal> " Ignore this change. It will be handled by different patch. The same for ther est of file and 3/3. M
Re: [PATCH v5 4/7] efi_loader: support boot from URI device path
Hi Ilias,
On Fri, 29 Sept 2023 at 20:48, Ilias Apalodimas
wrote:
>
> Hi Kojima-san,
>
>
> [...]
>
> > +
> > +/**
> > + * try_load_default_file() - try to load the default file
> > + *
> > + * Search the device having EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
> > + * then try to load with the default boot file(e.g. EFI/BOOT/BOOTAA64.EFI).
> > + *
> > + * @dev pointer to the UCLASS_BLK or UCLASS_PARTITION
> > udevice
> > + * @image_handle:pointer to handle for newly installed image
> > + * Return: status code
> > + */
> > +static efi_status_t try_load_default_file(struct udevice *dev,
> > + efi_handle_t *image_handle)
> > +{
> > + efi_status_t ret;
> > + efi_handle_t handle;
> > + struct efi_handler *handler;
> > + struct efi_device_path *file_path;
> > + struct efi_device_path *device_path;
> > +
> > + if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **))) {
> > + log_warning("DM_TAG_EFI not found\n");
> > + return EFI_INVALID_PARAMETER;
> > + }
> > +
> > + ret = efi_search_protocol(handle,
> > + _simple_file_system_protocol_guid,
> > );
> > + if (ret != EFI_SUCCESS)
> > + return ret;
> > +
> > + ret = EFI_CALL(bs->open_protocol(handle, _guid_device_path,
> > + (void **)_path, efi_root,
> > NULL,
> > + EFI_OPEN_PROTOCOL_GET_PROTOCOL));
> > + if (ret != EFI_SUCCESS)
> > + return ret;
> > +
> > + file_path = expand_media_path(device_path);
> > + ret = EFI_CALL(efi_load_image(true, efi_root, file_path, NULL, 0,
> > + image_handle));
> > +
> > + efi_free_pool(file_path);
> > +
> > + return ret;
> > +}
>
> We've discussed this on v4, but I am replying here, since you sent a v5 in
> the meantime.
> What I ideally wanted to do here is
> - Add the boot option automatically once the disk gets mount (you've
> already sent a patch for that)
> - Since the boot option is automatically added we could instead of
> searching for BOOTAA64.EFI search for matches with a load option of
> '1234567'.
> Is there some timing issue that I am missing which doesnt allow us to do
> that ?
Sorry, I probably misunderstood your design.
What kind of boot option is automatically added when the disk is detected?
Could you share your thoughts about the trigger to search for matches
with a load option of '1234567'?
Thanks,
Masahisa Kojima
>
> [...]
>
> Cheers
> /Ilias
Re: [PATCH] spl: Jump to image at end of board_init_r
On 29.09.23 13:56, Tom Rini wrote:
On Fri, Sep 29, 2023 at 02:57:42AM +0200, Heinrich Schuchardt wrote:
On 9/27/23 23:44, Jonas Karlman wrote:
spl_board_prepare_for_boot() is not called before jumping/invoking atf,
optee, opensbi or linux images.
Jump to image at the end of board_init_r() to fix this.
Signed-off-by: Jonas Karlman
---
This patch have dependencies on the following patches:
spl: add __noreturn attribute to spl_invoke_opensbi function
https://patchwork.ozlabs.org/patch/1827057/
spl: add __noreturn attribute to spl_invoke_atf function
https://patchwork.ozlabs.org/patch/1831366/
spl: Drop the switch() statement for OS selection
from the "spl: Preparation for Universal Payload" series
https://patchwork.ozlabs.org/patch/1839731/
---
common/spl/spl.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index f7608f14e365..79c39820262a 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -647,6 +647,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
BOOT_DEVICE_NONE,
BOOT_DEVICE_NONE,
};
+ typedef void __noreturn (*jump_to_image_t)(struct spl_image_info *);
+ jump_to_image_t jump_to_image = _to_image_no_args;
struct spl_image_info spl_image;
int ret, os;
@@ -735,20 +737,20 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
} else if (CONFIG_IS_ENABLED(ATF) && os == IH_OS_ARM_TRUSTED_FIRMWARE) {
debug("Jumping to U-Boot via ARM Trusted Firmware\n");
spl_fixup_fdt(spl_image_fdt_addr(_image));
- spl_invoke_atf(_image);
+ jump_to_image = _invoke_atf;
} else if (CONFIG_IS_ENABLED(OPTEE_IMAGE) && os == IH_OS_TEE) {
debug("Jumping to U-Boot via OP-TEE\n");
spl_board_prepare_for_optee(spl_image_fdt_addr(_image));
- jump_to_image_optee(_image);
+ jump_to_image = _to_image_optee;
} else if (CONFIG_IS_ENABLED(OPENSBI) && os == IH_OS_OPENSBI) {
debug("Jumping to U-Boot via RISC-V OpenSBI\n");
- spl_invoke_opensbi(_image);
+ jump_to_image = _invoke_opensbi;
} else if (CONFIG_IS_ENABLED(OS_BOOT) && os == IH_OS_LINUX) {
debug("Jumping to Linux\n");
if (IS_ENABLED(CONFIG_SPL_OS_BOOT))
spl_fixup_fdt((void *)SPL_PAYLOAD_ARGS_ADDR);
spl_board_prepare_for_linux();
- jump_to_image_linux(_image);
+ jump_to_image = _to_image_linux;
} else {
debug("Unsupported OS image.. Jumping nevertheless..\n");
}
@@ -788,7 +790,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
}
spl_board_prepare_for_boot();
- jump_to_image_no_args(_image);
+ jump_to_image(_image);
}
/*
In SPL we are fighting for every byte of binary size.
What is the impact of this change on the code size?
I would expect that your increasing it; especially if only one of the
CONFIG_OPTIONS is enabled.
If so, NAK to this patch despite all elegance.
We aren't _that_ strict, no. And a very quick peek shows that this
seems fine overall. Since you raised the question I'll do a quick
world build but socfpga_agilex_vab (as a config I had size change
results for in front of me for something else) shrank by 4 bytes with
just the prerequsites and this patch applied.
Shrinking the size sounds great. Thanks for measuring.
Best regards
Heinrich
Re: [PATCH] spl: Jump to image at end of board_init_r
On Fri, Sep 29, 2023 at 02:57:42AM +0200, Heinrich Schuchardt wrote:
> On 9/27/23 23:44, Jonas Karlman wrote:
> > spl_board_prepare_for_boot() is not called before jumping/invoking atf,
> > optee, opensbi or linux images.
> >
> > Jump to image at the end of board_init_r() to fix this.
> >
> > Signed-off-by: Jonas Karlman
> > ---
> > This patch have dependencies on the following patches:
> >
> > spl: add __noreturn attribute to spl_invoke_opensbi function
> > https://patchwork.ozlabs.org/patch/1827057/
> >
> > spl: add __noreturn attribute to spl_invoke_atf function
> > https://patchwork.ozlabs.org/patch/1831366/
> >
> > spl: Drop the switch() statement for OS selection
> > from the "spl: Preparation for Universal Payload" series
> > https://patchwork.ozlabs.org/patch/1839731/
> > ---
> > common/spl/spl.c | 12 +++-
> > 1 file changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/common/spl/spl.c b/common/spl/spl.c
> > index f7608f14e365..79c39820262a 100644
> > --- a/common/spl/spl.c
> > +++ b/common/spl/spl.c
> > @@ -647,6 +647,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > BOOT_DEVICE_NONE,
> > BOOT_DEVICE_NONE,
> > };
> > + typedef void __noreturn (*jump_to_image_t)(struct spl_image_info *);
> > + jump_to_image_t jump_to_image = _to_image_no_args;
> > struct spl_image_info spl_image;
> > int ret, os;
> >
> > @@ -735,20 +737,20 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > } else if (CONFIG_IS_ENABLED(ATF) && os == IH_OS_ARM_TRUSTED_FIRMWARE) {
> > debug("Jumping to U-Boot via ARM Trusted Firmware\n");
> > spl_fixup_fdt(spl_image_fdt_addr(_image));
> > - spl_invoke_atf(_image);
> > + jump_to_image = _invoke_atf;
> > } else if (CONFIG_IS_ENABLED(OPTEE_IMAGE) && os == IH_OS_TEE) {
> > debug("Jumping to U-Boot via OP-TEE\n");
> > spl_board_prepare_for_optee(spl_image_fdt_addr(_image));
> > - jump_to_image_optee(_image);
> > + jump_to_image = _to_image_optee;
> > } else if (CONFIG_IS_ENABLED(OPENSBI) && os == IH_OS_OPENSBI) {
> > debug("Jumping to U-Boot via RISC-V OpenSBI\n");
> > - spl_invoke_opensbi(_image);
> > + jump_to_image = _invoke_opensbi;
> > } else if (CONFIG_IS_ENABLED(OS_BOOT) && os == IH_OS_LINUX) {
> > debug("Jumping to Linux\n");
> > if (IS_ENABLED(CONFIG_SPL_OS_BOOT))
> > spl_fixup_fdt((void *)SPL_PAYLOAD_ARGS_ADDR);
> > spl_board_prepare_for_linux();
> > - jump_to_image_linux(_image);
> > + jump_to_image = _to_image_linux;
> > } else {
> > debug("Unsupported OS image.. Jumping nevertheless..\n");
> > }
> > @@ -788,7 +790,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> > }
> >
> > spl_board_prepare_for_boot();
> > - jump_to_image_no_args(_image);
> > + jump_to_image(_image);
> > }
> >
> > /*
>
> In SPL we are fighting for every byte of binary size.
>
> What is the impact of this change on the code size?
>
> I would expect that your increasing it; especially if only one of the
> CONFIG_OPTIONS is enabled.
>
> If so, NAK to this patch despite all elegance.
We aren't _that_ strict, no. And a very quick peek shows that this
seems fine overall. Since you raised the question I'll do a quick
world build but socfpga_agilex_vab (as a config I had size change
results for in front of me for something else) shrank by 4 bytes with
just the prerequsites and this patch applied.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v5 4/7] efi_loader: support boot from URI device path
Hi Kojima-san,
[...]
> +
> +/**
> + * try_load_default_file() - try to load the default file
> + *
> + * Search the device having EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
> + * then try to load with the default boot file(e.g. EFI/BOOT/BOOTAA64.EFI).
> + *
> + * @dev pointer to the UCLASS_BLK or UCLASS_PARTITION
> udevice
> + * @image_handle:pointer to handle for newly installed image
> + * Return: status code
> + */
> +static efi_status_t try_load_default_file(struct udevice *dev,
> + efi_handle_t *image_handle)
> +{
> + efi_status_t ret;
> + efi_handle_t handle;
> + struct efi_handler *handler;
> + struct efi_device_path *file_path;
> + struct efi_device_path *device_path;
> +
> + if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **))) {
> + log_warning("DM_TAG_EFI not found\n");
> + return EFI_INVALID_PARAMETER;
> + }
> +
> + ret = efi_search_protocol(handle,
> + _simple_file_system_protocol_guid,
> );
> + if (ret != EFI_SUCCESS)
> + return ret;
> +
> + ret = EFI_CALL(bs->open_protocol(handle, _guid_device_path,
> + (void **)_path, efi_root, NULL,
> + EFI_OPEN_PROTOCOL_GET_PROTOCOL));
> + if (ret != EFI_SUCCESS)
> + return ret;
> +
> + file_path = expand_media_path(device_path);
> + ret = EFI_CALL(efi_load_image(true, efi_root, file_path, NULL, 0,
> + image_handle));
> +
> + efi_free_pool(file_path);
> +
> + return ret;
> +}
We've discussed this on v4, but I am replying here, since you sent a v5 in
the meantime.
What I ideally wanted to do here is
- Add the boot option automatically once the disk gets mount (you've
already sent a patch for that)
- Since the boot option is automatically added we could instead of
searching for BOOTAA64.EFI search for matches with a load option of
'1234567'.
Is there some timing issue that I am missing which doesnt allow us to do
that ?
[...]
Cheers
/Ilias
Re: Please pull u-boot-dm/next
On Fri, Sep 29, 2023 at 02:53:45PM +0530, Manorit Chawdhry wrote: > Hi Tom, Simon > > On 17:14-20230924, Tom Rini wrote: > > On Sat, Sep 23, 2023 at 01:52:55PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > This is for the -next branch > > > > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/17836 > > > > > > > > > The following changes since commit > > > b05a184379631d13c4a49e423aa1324dc1ae6158: > > > > > > Merge tag 'x86-pull-20230922' of > > > https://source.denx.de/u-boot/custodians/u-boot-x86 into next > > > (2023-09-22 11:16:22 -0400) > > > > > > are available in the Git repository at: > > > > > > git://git.denx.de/u-boot-dm.git tags/dm-next-23sep23 > > > > > > for you to fetch changes up to ae84514feee209091d331a8baaa344ed8d8e905b: > > > > > > kontron_sl28: Use u-boot-update.bin instead of u-boot.update > > > (2023-09-23 12:31:25 -0600) > > > > > > > Applied to u-boot/next, thanks! > > The following merge breaks K3 boards somehow, All have the same failure > signature, putting the logs here of J721e for your reference. This is what Roger has figured out here: https://lore.kernel.org/u-boot/20230820220316.3517102-1-jo...@kwiboo.se/T/#t And please note that both j721e_evm and am65x_evm are working fine which is why I merged the series. -- Tom signature.asc Description: PGP signature
[PATCH] clk: stm32mp1: Add support for USART1 clock
Add USART1 clock parents and mux configuration. This allows
support for configuring the USART1 as the serial console in
SPL and U-Boot via device tree. Without this patch the SPL
with usart1 serial console enabled crashes because it can
not find the clock specified in the device tree for usart1.
Signed-off-by: Anatolij Gustschin
---
drivers/clk/stm32/clk-stm32mp1.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/clk/stm32/clk-stm32mp1.c b/drivers/clk/stm32/clk-stm32mp1.c
index 6150287694..f3ac8c7583 100644
--- a/drivers/clk/stm32/clk-stm32mp1.c
+++ b/drivers/clk/stm32/clk-stm32mp1.c
@@ -72,6 +72,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define RCC_PLL2CSGR 0xA4
#define RCC_I2C46CKSELR0xC0
#define RCC_SPI6CKSELR 0xC4
+#define RCC_UART1CKSELR0xC8
#define RCC_CPERCKSELR 0xD0
#define RCC_STGENCKSELR0xD4
#define RCC_DDRITFCR 0xD8
@@ -317,6 +318,7 @@ enum stm32mp1_parent_sel {
_SPI45_SEL,
_SPI6_SEL,
_RTC_SEL,
+ _UART1_SEL,
_PARENT_SEL_NB,
_UNKNOWN_SEL = 0xff,
};
@@ -557,6 +559,7 @@ static const struct stm32mp1_clk_gate stm32mp1_clk_gate[] =
{
STM32MP1_CLK_SET_CLR(RCC_MP_APB5ENSETR, 0, SPI6_K, _SPI6_SEL),
STM32MP1_CLK_SET_CLR(RCC_MP_APB5ENSETR, 2, I2C4_K, _I2C46_SEL),
STM32MP1_CLK_SET_CLR(RCC_MP_APB5ENSETR, 3, I2C6_K, _I2C46_SEL),
+ STM32MP1_CLK_SET_CLR(RCC_MP_APB5ENSETR, 4, USART1_K, _UART1_SEL),
STM32MP1_CLK_SET_CLR(RCC_MP_APB5ENSETR, 8, RTCAPB, _PCLK5),
STM32MP1_CLK_SET_CLR(RCC_MP_APB5ENSETR, 16, BSEC, _UNKNOWN_SEL),
STM32MP1_CLK_SET_CLR(RCC_MP_APB5ENSETR, 20, STGEN_K, _STGEN_SEL),
@@ -602,6 +605,8 @@ static const struct stm32mp1_clk_gate stm32mp1_clk_gate[] =
{
static const u8 i2c12_parents[] = {_PCLK1, _PLL4_R, _HSI_KER, _CSI_KER};
static const u8 i2c35_parents[] = {_PCLK1, _PLL4_R, _HSI_KER, _CSI_KER};
static const u8 i2c46_parents[] = {_PCLK5, _PLL3_Q, _HSI_KER, _CSI_KER};
+static const u8 uart1_parents[] = {_PCLK5, _PLL3_Q, _HSI_KER, _CSI_KER,
+ _PLL4_Q, _HSE_KER};
static const u8 uart6_parents[] = {_PCLK2, _PLL4_Q, _HSI_KER, _CSI_KER,
_HSE_KER};
static const u8 uart24_parents[] = {_PCLK1, _PLL4_Q, _HSI_KER, _CSI_KER,
@@ -659,6 +664,7 @@ static const struct stm32mp1_clk_sel
stm32mp1_clk_sel[_PARENT_SEL_NB] = {
STM32MP1_CLK_PARENT(_RTC_SEL, RCC_BDCR, RCC_BDCR_RTCSRC_SHIFT,
(RCC_BDCR_RTCSRC_MASK >> RCC_BDCR_RTCSRC_SHIFT),
rtc_parents),
+ STM32MP1_CLK_PARENT(_UART1_SEL, RCC_UART1CKSELR, 0, 0x7, uart1_parents),
};
#ifdef STM32MP1_CLOCK_TREE_INIT
@@ -786,6 +792,7 @@ char * const stm32mp1_clk_parent_sel_name[_PARENT_SEL_NB] =
{
[_SPI1_SEL] = "SPI1",
[_SPI45_SEL] = "SPI45",
[_RTC_SEL] = "RTC",
+ [_UART1_SEL] = "UART1",
};
static const struct stm32mp1_clk_data stm32mp1_data = {
--
2.17.1
Re: [PATCH v2] dm: core: Report bootph-pre-ram/sram node as pre-reloc after relocation : regression
On 28/09/2023 22:18, Jonas Karlman wrote:
> Hi Roger,
>
> On 2023-09-28 14:59, Roger Quadros wrote:
>> Hi,
>>
>> On 21/08/2023 01:03, Jonas Karlman wrote:
>>> Nodes with bootph-pre-sram/ram props are bound in multiple phases:
>>> 1. At TPL (bootph-pre-sram) or SPL (bootph-pre-ram) phase
>>> 2. At U-Boot proper pre-relocation phase
>>> 3. At U-Boot proper normal phase
>>>
>>> However the binding and U-Boot Driver Model documentation indicate that
>>> only nodes marked with bootph-all or bootph-some-ram should be bound in
>>> the U-Boot proper pre-relocation phase.
>>>
>>> Change ofnode_pre_reloc to report a node with bootph-pre-ram/sram prop
>>> with a pre-reloc status only after U-Boot proper pre-relocation phase.
>>> Also update the ofnode_pre_reloc documentation to closer reflect the
>>> binding and driver model documentation.
>>>
>>> This changes behavior of what nodes are bound in the U-Boot proper
>>> pre-relocation phase. Change to bootph-all or add bootph-some-ram prop
>>> to restore prior behavior.
>>>
>>> Signed-off-by: Jonas Karlman
>>> Reviewed-by: Simon Glass
>>> ---
>>> Changes in v2:
>>> - Drop use of !! to convert into bool
>>> - Update documentation for ofnode_pre_reloc
>>> - Rewrite commit message
>>> - Collect r-b tag
>>
>> This patch breaks boot on AM642-EVM. Boot log at the end.
>
> From what I can tell your board use a lot of bootph-pre-ram.
> https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>
> What happens if you change to bootph-all or add bootph-some-ram next to
> bootph-pre-ram on devices that is also needed in U-Boot proper
> pre-relocation phase in addition to SPL phase?
Then it works.
BTW, AM62-SK is broken as well and I suppose most K3 TI boards would be broken.
Nishanth / Tom,
What approach to take here?
Replacing bootph-pre-ram to bootph-all in *-u-boot.dtsi would be a quick fix.
Then we need to mark nodes required only for SPL as bootph-pre-ram.
Meanwhile I will suggest to revert the $subject patch till this is sorted out
and gets a Ack from board maintainers.
cheers,
-roger
>
> Regards,
> Jonas
>
>>
>>>
>>> drivers/core/ofnode.c | 2 +-
>>> include/dm/ofnode.h | 8
>>> 2 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
>>> index 8df16e56af5c..b1e94b2d60df 100644
>>> --- a/drivers/core/ofnode.c
>>> +++ b/drivers/core/ofnode.c
>>> @@ -1353,7 +1353,7 @@ bool ofnode_pre_reloc(ofnode node)
>>> */
>>> if (ofnode_read_bool(node, "bootph-pre-ram") ||
>>> ofnode_read_bool(node, "bootph-pre-sram"))
>>> - return true;
>>> + return gd->flags & GD_FLG_RELOC;
>>>
>>> if (IS_ENABLED(CONFIG_OF_TAG_MIGRATE)) {
>>> /* detect and handle old tags */
>>> diff --git a/include/dm/ofnode.h b/include/dm/ofnode.h
>>> index 0f38b3e736de..13700f8266d7 100644
>>> --- a/include/dm/ofnode.h
>>> +++ b/include/dm/ofnode.h
>>> @@ -1198,15 +1198,15 @@ int ofnode_read_simple_size_cells(ofnode node);
>>> * determine if a node was bound in one of SPL/TPL stages.
>>> *
>>> * There are 4 settings currently in use
>>> - * - bootph-some-ram: U-Boot proper pre-relocation only
>>> + * - bootph-some-ram: U-Boot proper pre-relocation phase
>>> * - bootph-all: all phases
>>> * Existing platforms only use it to indicate nodes needed in
>>> * SPL. Should probably be replaced by bootph-pre-ram for new platforms.
>>> - * - bootph-pre-ram: SPL and U-Boot pre-relocation
>>> - * - bootph-pre-sram: TPL and U-Boot pre-relocation
>>> + * - bootph-pre-ram: SPL phase
>>> + * - bootph-pre-sram: TPL phase
>>> *
>>> * @node: node to check
>>> - * Return: true if node is needed in SPL/TL, false otherwise
>>> + * Return: true if node should be or was bound, false otherwise
>>> */
>>> bool ofnode_pre_reloc(ofnode node);
>>>
>>
>> ---boot log---
>>
>> U-Boot SPL 2023.10-rc4-00480-g9e644284ab (Sep 28 2023 - 15:53:09 +0300)
>> Resetting on cold boot to workaround ErrataID:i2331
>> Please resend tiboot3.bin in case of UART/DFU boot
>> resetting ...
>>
>> U-Boot SPL 2023.10-rc4-00480-g9e644284ab (Sep 28 2023 - 15:53:09 +0300)
>> SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.5--v09.00.05 (Kool Koala)')
>> SPL initial stack usage: 13408 bytes
>> Trying to boot from MMC2
>> Warning: Detected image signing certificate on GP device. Skipping
>> certificate to prevent boot failure. This will fail if the image was also
>> encrypted
>> Warning: Detected image signing certificate on GP device. Skipping
>> certificate to prevent boot failure. This will fail if the image was also
>> encrypted
>> Warning: Detected image signing certificate on GP device. Skipping
>> certificate to prevent boot failure. This will fail if the image was also
>> encrypted
>> Warning: Detected image signing certificate on GP device. Skipping
>> certificate to prevent boot failure. This will fail if the image was also
>> encrypted
>> Loading Environment from MMC...
Re: Please pull u-boot-dm/next
Hi Tom, Simon On 17:14-20230924, Tom Rini wrote: > On Sat, Sep 23, 2023 at 01:52:55PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > This is for the -next branch > > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/17836 > > > > > > The following changes since commit b05a184379631d13c4a49e423aa1324dc1ae6158: > > > > Merge tag 'x86-pull-20230922' of > > https://source.denx.de/u-boot/custodians/u-boot-x86 into next > > (2023-09-22 11:16:22 -0400) > > > > are available in the Git repository at: > > > > git://git.denx.de/u-boot-dm.git tags/dm-next-23sep23 > > > > for you to fetch changes up to ae84514feee209091d331a8baaa344ed8d8e905b: > > > > kontron_sl28: Use u-boot-update.bin instead of u-boot.update > > (2023-09-23 12:31:25 -0600) > > > > Applied to u-boot/next, thanks! The following merge breaks K3 boards somehow, All have the same failure signature, putting the logs here of J721e for your reference. U-Boot SPL 2023.10-rc4-00487-g90c81f407dd4 (Sep 29 2023 - 12:27:00 +0530) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.6--v09.00.06 (Kool Koala)') ESM init failed: -19 Trying to boot from UART Cicate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted Loaded 1008063 bytes Loading Environment from nowhere... OK init_env from device 7 not supported! Starting ATF on ARM64 core... NOTICE: BL31: v2.9(release):v2.9.0-dirty NOTICE: BL31: Built : 14:12:59, May 22 2023 I/TC: I/TC: OP-TEE version: 3.20.0 (gcc version 11.4.0 (GCC)) #1 Fri Jan 20 15:42:54 UTC 2023 aarch64 I/TC: WARNING: This OP-TEE configuration might be insecure! I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html I/TC: Primary CPU initializing I/TC: SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.6--v09.00.06 (Kool Koala)') I/TC: HUK Initialized I/TC: Activated SA2UL device I/TC: Fixing SA2UL firewall owner for GP device I/TC: Enabled firewalls for SA2UL TRNG device I/TC: SA2UL TRNG initialized I/TC: SA2UL Drivers initialized I/TC: Primary CPU switching to normal world boot U-Boot SPL 2023.10-rc4-00487-g90c81f407dd4 (Sep 29 2023 - 12:27:45 +0530) SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.6--v09.00.06 (Kool Koala)') Detected: J7X-BASE-CPB rev E3 Detected: J7X-VSC8514-ETH rev E2 Trying to boot from UART Certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted Warning: Detected image signing certificate on GP device. Skipping certificate to prevent boot failure. This will fail if the image was also encrypted Loaded 1270887 bytes [end] Regards, Manorit > > -- > Tom
[PATCH v5] imx: imx8mm: Add support for Mettler-Toledo snowflake board.
This patch probably got somehow lost. Rebased against latest master.
It is originally based on:
>From patchwork Fri Mar 31 14:18:41 2023
X-Patchwork-Submitter: Sebastian Andrzej Siewior
X-Patchwork-Id: 1763795
X-Patchwork-Delegate: sba...@denx.de
Return-Path:
X-Original-To: incom...@patchwork.ozlabs.org
Delivered-To: patchwork-incom...@legolas.ozlabs.org
Authentication-Results: legolas.ozlabs.org;
spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de
(client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;
envelope-from=u-boot-boun...@lists.denx.de; receiver=)
Authentication-Results: legolas.ozlabs.org;
The board is similar to "Kontron SL i.MX 8M Mini" SoM. There are two variants.
Snowflake_v2 has an external SDCard Interface. LEIG is the same, but without
display and without external SDCard Interface. Both variants support
only 1GiB of main memory.
[ bigeasy: porting and a bit of cleanup ]
Signed-off-by: Manuel Traut
Signed-off-by: Sebastian Andrzej Siewior
Reviewed-by: Frieder Schrempf
v4?v5:
- Rebased on top of todays master
v3?v4:
- Added Frieder's tag
- Rebased on top of v2023.07-rc5.
v2?v3:
Addressing Frieder's comments:
- Add "kontron,imx8mm-sl" to the compatible string.
- Remove pca9450 node and pinctrl_i2c1. The included
imx8mm-kontron-sl.dtsi already provides this.
- Merge the overwritten values in dram_timing.ddrc_cfg/fsp_msg directly
into lpddr4_timing.c.
- Simplify the init in spl_dram_init() and panic() if the init failed.
- Replace a reference to SMARC with the current product name of the
SoM.
v1?v2:
- Clarify details about the board and whether or not there is an
external SD-card interface.
---
arch/arm/dts/Makefile |1 +
arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi | 139 ++
arch/arm/dts/imx8mm-mt-snowflake-v2.dts | 126 ++
arch/arm/mach-imx/imx8m/Kconfig |8 +
board/mt/snowflake_v2/Kconfig | 18 +
board/mt/snowflake_v2/MAINTAINERS |7 +
board/mt/snowflake_v2/Makefile |9 +
board/mt/snowflake_v2/imximage.cfg |8 +
board/mt/snowflake_v2/lpddr4_timing.c | 1844 +++
board/mt/snowflake_v2/snowflake_v2.c| 32 +
board/mt/snowflake_v2/spl.c | 146 ++
configs/snowflake_leig_defconfig| 141 ++
configs/snowflake_sdcard_defconfig | 140 ++
include/configs/snowflake_v2.h | 113 ++
14 files changed, 2732 insertions(+)
create mode 100644 arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mm-mt-snowflake-v2.dts
create mode 100644 board/mt/snowflake_v2/Kconfig
create mode 100644 board/mt/snowflake_v2/MAINTAINERS
create mode 100644 board/mt/snowflake_v2/Makefile
create mode 100644 board/mt/snowflake_v2/imximage.cfg
create mode 100644 board/mt/snowflake_v2/lpddr4_timing.c
create mode 100644 board/mt/snowflake_v2/snowflake_v2.c
create mode 100644 board/mt/snowflake_v2/spl.c
create mode 100644 configs/snowflake_leig_defconfig
create mode 100644 configs/snowflake_sdcard_defconfig
create mode 100644 include/configs/snowflake_v2.h
Index: u-boot-deb-manut/arch/arm/dts/Makefile
===
--- u-boot-deb-manut.orig/arch/arm/dts/Makefile
+++ u-boot-deb-manut/arch/arm/dts/Makefile
@@ -1015,6 +1015,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-icore-mx8mm-edimm2.2.dtb \
imx8mm-kontron-bl.dtb \
imx8mm-kontron-bl-osm-s.dtb \
+ imx8mm-mt-snowflake-v2.dtb \
imx8mm-mx8menlo.dtb \
imx8mm-phg.dtb \
imx8mm-venice.dtb \
Index: u-boot-deb-manut/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
===
--- /dev/null
+++ u-boot-deb-manut/arch/arm/dts/imx8mm-mt-snowflake-v2-u-boot.dtsi
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Mettler-Toledo GmbH
+ */
+
+#include "imx8mm-u-boot.dtsi"
+
+/ {
+firmware {
+optee {
+compatible = "linaro,optee-tz";
+method = "smc";
+};
+};
+
+wdt-reboot {
+compatible = "wdt-reboot";
+u-boot,dm-spl;
+wdt = <>;
+};
+
+usbg1: usbg1 {
+u-boot,dm-spl;
+compatible = "fsl,imx27-usb-gadget";
+dr_mode = "peripheral";
+chipidea,usb = <>;
+status = "okay";
+};
+};
+
+&{/aliases} {
+usbgadget0 =
+};
+
+ {
+ status = "okay";
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ status = "okay";
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+_ecspi1 {
+ u-boot,dm-spl;
+};
+
+_i2c1 {
+ u-boot,dm-spl;
+};
+
+_pmic {
+ u-boot,dm-spl;
+};
+
+_uart3 {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+_usdhc1 {
+ u-boot,dm-spl;
+};
+
+_usdhc1_100mhz {
+
Re: [PATCH] spl: Jump to image at end of board_init_r
> We should understand the implications of your patch on the code size. If > it leads to binary code growth, we should evaluate alternatives. This is not my patch, but Jonas'. But sure. Cheers.
Re: [PATCH] spl: Jump to image at end of board_init_r
On 9/29/23 09:55, Ferass El Hafidi wrote: Hi Heinrich, On Fri Sep 29, 2023 at 2:57 AM CEST, Heinrich Schuchardt wrote: In SPL we are fighting for every byte of binary size. What is the impact of this change on the code size? I would expect that your increasing it; especially if only one of the CONFIG_OPTIONS is enabled. If so, NAK to this patch despite all elegance. Would you prefer removing `spl_board_prepare_for_boot()` instead? A handful of boards make use for it so I'd say this is a bug if it never gets ran on those. Or would it be better if it was enabled with a CONFIG_ option? We should understand the implications of your patch on the code size. If it leads to binary code growth, we should evaluate alternatives. Best regards Heinrich
Re: [PATCH] spl: Jump to image at end of board_init_r
On Fri Sep 29, 2023 at 1:42 AM CEST, Simon Glass wrote: > On Wed, 27 Sept 2023 at 15:44, Jonas Karlman wrote: > > > > spl_board_prepare_for_boot() is not called before jumping/invoking atf, > > optee, opensbi or linux images. > > > > Jump to image at the end of board_init_r() to fix this. > > > > Signed-off-by: Jonas Karlman > > --- > > This patch have dependencies on the following patches: > > > > spl: add __noreturn attribute to spl_invoke_opensbi function > > https://patchwork.ozlabs.org/patch/1827057/ > > > > spl: add __noreturn attribute to spl_invoke_atf function > > https://patchwork.ozlabs.org/patch/1831366/ > > > > spl: Drop the switch() statement for OS selection > > from the "spl: Preparation for Universal Payload" series > > https://patchwork.ozlabs.org/patch/1839731/ > > --- > > common/spl/spl.c | 12 +++- > > 1 file changed, 7 insertions(+), 5 deletions(-) > > > > Reviewed-by: Simon Glass > > Very nice to see this! Nice indeed!
Re: [PATCH] spl: Jump to image at end of board_init_r
Hi Heinrich, On Fri Sep 29, 2023 at 2:57 AM CEST, Heinrich Schuchardt wrote: > In SPL we are fighting for every byte of binary size. > > What is the impact of this change on the code size? > > I would expect that your increasing it; especially if only one of the > CONFIG_OPTIONS is enabled. > > If so, NAK to this patch despite all elegance. Would you prefer removing `spl_board_prepare_for_boot()` instead? A handful of boards make use for it so I'd say this is a bug if it never gets ran on those. Or would it be better if it was enabled with a CONFIG_ option? Cheers. > > Best regards > > Heinrich
Re: [PATCH v4 4/8] efi_loader: support boot from URI device path
On Fri, 29 Sept 2023 at 13:00, Masahisa Kojima
wrote:
> Hi Maxim,
>
> On Fri, 29 Sept 2023 at 15:24, Maxim Uvarov
> wrote:
> >
> >
> >
> > On Fri, 29 Sept 2023 at 08:13, Masahisa Kojima <
> masahisa.koj...@linaro.org> wrote:
> >>
> >> Hi Maxim,
> >>
> >> On Thu, 28 Sept 2023 at 20:35, Maxim Uvarov
> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, 26 Sept 2023 at 09:01, Masahisa Kojima <
> masahisa.koj...@linaro.org> wrote:
> >> >>
> >> >> Hi Ilias,
> >> >>
> >> >> On Mon, 25 Sept 2023 at 21:37, Ilias Apalodimas
> >> >> wrote:
> >> >> >
> >> >> > On Fri, Sep 22, 2023 at 04:11:15PM +0900, Masahisa Kojima wrote:
> >> >> > > This supports to boot from the URI device path.
> >> >> > > When user selects the URI device path, bootmgr downloads
> >> >> > > the file using wget into the address specified by loadaddr
> >> >> > > env variable.
> >> >> > > If the file is .iso or .img file, mount the image with blkmap
> >> >> > > then try to boot with the default file(e.g.
> EFI/BOOT/BOOTAA64.EFI).
> >> >> > > If the file is .efi file, load and start the downloaded file.
> >> >> > >
> >> >> > > Signed-off-by: Masahisa Kojima
> >> >> > > ---
> >> >> > > lib/efi_loader/efi_bootmgr.c | 189
> +++
> >> >> > > 1 file changed, 189 insertions(+)
> >> >> > >
> >> >> > > diff --git a/lib/efi_loader/efi_bootmgr.c
> b/lib/efi_loader/efi_bootmgr.c
> >> >> > > index a40762c74c..605be5041e 100644
> >> >> > > --- a/lib/efi_loader/efi_bootmgr.c
> >> >> > > +++ b/lib/efi_loader/efi_bootmgr.c
> >> >> > > @@ -7,10 +7,14 @@
> >> >> > >
> >> >> > > #define LOG_CATEGORY LOGC_EFI
> >> >> > >
> >> >> > > +#include
> >> >> > > +#include
> >> >> > > #include
> >> >> > > #include
> >> >> > > +#include
> >> >> > > #include
> >> >> > > #include
> >> >> > > +#include
> >> >> > > #include
> >> >> > > #include
> >> >> > > #include
> >> >> > > @@ -168,6 +172,182 @@ out:
> >> >> > > return ret;
> >> >> > > }
> >> >> > >
> >> >> > > +/**
> >> >> > > + * mount_image() - mount the image with blkmap
> >> >> > > + *
> >> >> > > + * @lo_label u16 label string of load option
> >> >> > > + * @image_addr: image address
> >> >> > > + * @image_size image size
> >> >> > > + * Return: pointer to the UCLASS_BLK udevice, NULL if failed
> >> >> > > + */
> >> >> > > +static struct udevice *mount_image(u16 *lo_label, ulong
> image_addr, int image_size)
> >> >> > > +{
> >> >> > > + int err;
> >> >> > > + struct blkmap *bm;
> >> >> > > + struct udevice *bm_dev;
> >> >> > > + char *label = NULL, *p;
> >> >> > > +
> >> >> > > + label = efi_alloc(utf16_utf8_strlen(lo_label) + 1);
> >> >> > > + if (!label)
> >> >> > > + return NULL;
> >> >> > > +
> >> >> > > + p = label;
> >> >> > > + utf16_utf8_strcpy(, lo_label);
> >> >> > > + err = blkmap_create_ramdisk(label, image_addr, image_size,
> _dev);
> >> >> > > + if (err) {
> >> >> > > + efi_free_pool(label);
> >> >> > > + return NULL;
> >> >> > > + }
> >> >> > > + bm = dev_get_plat(bm_dev);
> >> >> > > +
> >> >> > > + efi_free_pool(label);
> >> >> > > +
> >> >> > > + return bm->blk;
> >> >> > > +}
> >> >> > > +
> >> >> > > +/**
> >> >> > > + * try_load_default_file() - try to load the default file
> >> >> > > + *
> >> >> > > + * Search the device having EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
> >> >> > > + * then try to load with the default boot file(e.g.
> EFI/BOOT/BOOTAA64.EFI).
> >> >> > > + *
> >> >> > > + * @dev pointer to the UCLASS_BLK or
> UCLASS_PARTITION udevice
> >> >> > > + * @image_handle:pointer to handle for newly installed image
> >> >> > > + * Return: status code
> >> >> > > + */
> >> >> > > +static efi_status_t try_load_default_file(struct udevice *dev,
> >> >> > > + efi_handle_t
> *image_handle)
> >> >> > > +{
> >> >> >
> >> >> > Maybe I misunderstood you on the previous series. Wasn't the plan
> to merge
> >> >> > the patch that adds boot options automatically when a disk is
> scanned? This
> >> >>
> >> >> Adding the boot option automatically when a disk is scanned was sent
> >> >> separately[1] from this series
> >> >> since this feature is the matter of the timing of automatic boot
> >> >> option creation and not directly related
> >> >> to EFI HTTP Boot.
> >> >> I also included the fixes of the efi_secboot python test failure.
> >> >> Sorry for confusing you.
> >> >>
> >> >> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20230920084121.1248590-1-masahisa.koj...@linaro.org/
> >> >>
> >> >> > code could only look for a boot option with '1234567' in its load
> options
> >> >> > instead of rescanning all devices with the
> EFI_SIMPLE_FILE_SYSTEM_PROTOCO
> >> >> > installed
> >> >>
> >> >> Now we can scan and load the default file(EFI/BOOT/BOOTAA64.EFI) on
> the fly with
> >> >> load_default_file_from_blk_dev() function.
> >> >> The patch #8 of this series "efi_loader: create
Re: [PATCH v4 4/8] efi_loader: support boot from URI device path
Hi Maxim,
On Fri, 29 Sept 2023 at 15:24, Maxim Uvarov wrote:
>
>
>
> On Fri, 29 Sept 2023 at 08:13, Masahisa Kojima
> wrote:
>>
>> Hi Maxim,
>>
>> On Thu, 28 Sept 2023 at 20:35, Maxim Uvarov wrote:
>> >
>> >
>> >
>> > On Tue, 26 Sept 2023 at 09:01, Masahisa Kojima
>> > wrote:
>> >>
>> >> Hi Ilias,
>> >>
>> >> On Mon, 25 Sept 2023 at 21:37, Ilias Apalodimas
>> >> wrote:
>> >> >
>> >> > On Fri, Sep 22, 2023 at 04:11:15PM +0900, Masahisa Kojima wrote:
>> >> > > This supports to boot from the URI device path.
>> >> > > When user selects the URI device path, bootmgr downloads
>> >> > > the file using wget into the address specified by loadaddr
>> >> > > env variable.
>> >> > > If the file is .iso or .img file, mount the image with blkmap
>> >> > > then try to boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
>> >> > > If the file is .efi file, load and start the downloaded file.
>> >> > >
>> >> > > Signed-off-by: Masahisa Kojima
>> >> > > ---
>> >> > > lib/efi_loader/efi_bootmgr.c | 189
>> >> > > +++
>> >> > > 1 file changed, 189 insertions(+)
>> >> > >
>> >> > > diff --git a/lib/efi_loader/efi_bootmgr.c
>> >> > > b/lib/efi_loader/efi_bootmgr.c
>> >> > > index a40762c74c..605be5041e 100644
>> >> > > --- a/lib/efi_loader/efi_bootmgr.c
>> >> > > +++ b/lib/efi_loader/efi_bootmgr.c
>> >> > > @@ -7,10 +7,14 @@
>> >> > >
>> >> > > #define LOG_CATEGORY LOGC_EFI
>> >> > >
>> >> > > +#include
>> >> > > +#include
>> >> > > #include
>> >> > > #include
>> >> > > +#include
>> >> > > #include
>> >> > > #include
>> >> > > +#include
>> >> > > #include
>> >> > > #include
>> >> > > #include
>> >> > > @@ -168,6 +172,182 @@ out:
>> >> > > return ret;
>> >> > > }
>> >> > >
>> >> > > +/**
>> >> > > + * mount_image() - mount the image with blkmap
>> >> > > + *
>> >> > > + * @lo_label u16 label string of load option
>> >> > > + * @image_addr: image address
>> >> > > + * @image_size image size
>> >> > > + * Return: pointer to the UCLASS_BLK udevice, NULL if failed
>> >> > > + */
>> >> > > +static struct udevice *mount_image(u16 *lo_label, ulong image_addr,
>> >> > > int image_size)
>> >> > > +{
>> >> > > + int err;
>> >> > > + struct blkmap *bm;
>> >> > > + struct udevice *bm_dev;
>> >> > > + char *label = NULL, *p;
>> >> > > +
>> >> > > + label = efi_alloc(utf16_utf8_strlen(lo_label) + 1);
>> >> > > + if (!label)
>> >> > > + return NULL;
>> >> > > +
>> >> > > + p = label;
>> >> > > + utf16_utf8_strcpy(, lo_label);
>> >> > > + err = blkmap_create_ramdisk(label, image_addr, image_size,
>> >> > > _dev);
>> >> > > + if (err) {
>> >> > > + efi_free_pool(label);
>> >> > > + return NULL;
>> >> > > + }
>> >> > > + bm = dev_get_plat(bm_dev);
>> >> > > +
>> >> > > + efi_free_pool(label);
>> >> > > +
>> >> > > + return bm->blk;
>> >> > > +}
>> >> > > +
>> >> > > +/**
>> >> > > + * try_load_default_file() - try to load the default file
>> >> > > + *
>> >> > > + * Search the device having EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
>> >> > > + * then try to load with the default boot file(e.g.
>> >> > > EFI/BOOT/BOOTAA64.EFI).
>> >> > > + *
>> >> > > + * @dev pointer to the UCLASS_BLK or
>> >> > > UCLASS_PARTITION udevice
>> >> > > + * @image_handle:pointer to handle for newly installed image
>> >> > > + * Return: status code
>> >> > > + */
>> >> > > +static efi_status_t try_load_default_file(struct udevice *dev,
>> >> > > + efi_handle_t *image_handle)
>> >> > > +{
>> >> >
>> >> > Maybe I misunderstood you on the previous series. Wasn't the plan to
>> >> > merge
>> >> > the patch that adds boot options automatically when a disk is scanned?
>> >> > This
>> >>
>> >> Adding the boot option automatically when a disk is scanned was sent
>> >> separately[1] from this series
>> >> since this feature is the matter of the timing of automatic boot
>> >> option creation and not directly related
>> >> to EFI HTTP Boot.
>> >> I also included the fixes of the efi_secboot python test failure.
>> >> Sorry for confusing you.
>> >>
>> >> [1]
>> >> https://patchwork.ozlabs.org/project/uboot/patch/20230920084121.1248590-1-masahisa.koj...@linaro.org/
>> >>
>> >> > code could only look for a boot option with '1234567' in its load
>> >> > options
>> >> > instead of rescanning all devices with the
>> >> > EFI_SIMPLE_FILE_SYSTEM_PROTOCO
>> >> > installed
>> >>
>> >> Now we can scan and load the default file(EFI/BOOT/BOOTAA64.EFI) on the
>> >> fly with
>> >> load_default_file_from_blk_dev() function.
>> >> The patch #8 of this series "efi_loader: create BlockIo device boot
>> >> option" create the boot option
>> >> for the block device excluding the logical partition,
>> >>
>> >> >
>> >> > > + efi_status_t ret;
>> >> > > + efi_handle_t handle;
>> >> > > + struct efi_handler *handler;
>> >> > > + struct
Re: [PATCH v4 4/8] efi_loader: support boot from URI device path
On Fri, 29 Sept 2023 at 08:13, Masahisa Kojima
wrote:
> Hi Maxim,
>
> On Thu, 28 Sept 2023 at 20:35, Maxim Uvarov
> wrote:
> >
> >
> >
> > On Tue, 26 Sept 2023 at 09:01, Masahisa Kojima <
> masahisa.koj...@linaro.org> wrote:
> >>
> >> Hi Ilias,
> >>
> >> On Mon, 25 Sept 2023 at 21:37, Ilias Apalodimas
> >> wrote:
> >> >
> >> > On Fri, Sep 22, 2023 at 04:11:15PM +0900, Masahisa Kojima wrote:
> >> > > This supports to boot from the URI device path.
> >> > > When user selects the URI device path, bootmgr downloads
> >> > > the file using wget into the address specified by loadaddr
> >> > > env variable.
> >> > > If the file is .iso or .img file, mount the image with blkmap
> >> > > then try to boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI).
> >> > > If the file is .efi file, load and start the downloaded file.
> >> > >
> >> > > Signed-off-by: Masahisa Kojima
> >> > > ---
> >> > > lib/efi_loader/efi_bootmgr.c | 189
> +++
> >> > > 1 file changed, 189 insertions(+)
> >> > >
> >> > > diff --git a/lib/efi_loader/efi_bootmgr.c
> b/lib/efi_loader/efi_bootmgr.c
> >> > > index a40762c74c..605be5041e 100644
> >> > > --- a/lib/efi_loader/efi_bootmgr.c
> >> > > +++ b/lib/efi_loader/efi_bootmgr.c
> >> > > @@ -7,10 +7,14 @@
> >> > >
> >> > > #define LOG_CATEGORY LOGC_EFI
> >> > >
> >> > > +#include
> >> > > +#include
> >> > > #include
> >> > > #include
> >> > > +#include
> >> > > #include
> >> > > #include
> >> > > +#include
> >> > > #include
> >> > > #include
> >> > > #include
> >> > > @@ -168,6 +172,182 @@ out:
> >> > > return ret;
> >> > > }
> >> > >
> >> > > +/**
> >> > > + * mount_image() - mount the image with blkmap
> >> > > + *
> >> > > + * @lo_label u16 label string of load option
> >> > > + * @image_addr: image address
> >> > > + * @image_size image size
> >> > > + * Return: pointer to the UCLASS_BLK udevice, NULL if failed
> >> > > + */
> >> > > +static struct udevice *mount_image(u16 *lo_label, ulong
> image_addr, int image_size)
> >> > > +{
> >> > > + int err;
> >> > > + struct blkmap *bm;
> >> > > + struct udevice *bm_dev;
> >> > > + char *label = NULL, *p;
> >> > > +
> >> > > + label = efi_alloc(utf16_utf8_strlen(lo_label) + 1);
> >> > > + if (!label)
> >> > > + return NULL;
> >> > > +
> >> > > + p = label;
> >> > > + utf16_utf8_strcpy(, lo_label);
> >> > > + err = blkmap_create_ramdisk(label, image_addr, image_size,
> _dev);
> >> > > + if (err) {
> >> > > + efi_free_pool(label);
> >> > > + return NULL;
> >> > > + }
> >> > > + bm = dev_get_plat(bm_dev);
> >> > > +
> >> > > + efi_free_pool(label);
> >> > > +
> >> > > + return bm->blk;
> >> > > +}
> >> > > +
> >> > > +/**
> >> > > + * try_load_default_file() - try to load the default file
> >> > > + *
> >> > > + * Search the device having EFI_SIMPLE_FILE_SYSTEM_PROTOCOL,
> >> > > + * then try to load with the default boot file(e.g.
> EFI/BOOT/BOOTAA64.EFI).
> >> > > + *
> >> > > + * @dev pointer to the UCLASS_BLK or
> UCLASS_PARTITION udevice
> >> > > + * @image_handle:pointer to handle for newly installed image
> >> > > + * Return: status code
> >> > > + */
> >> > > +static efi_status_t try_load_default_file(struct udevice *dev,
> >> > > + efi_handle_t *image_handle)
> >> > > +{
> >> >
> >> > Maybe I misunderstood you on the previous series. Wasn't the plan to
> merge
> >> > the patch that adds boot options automatically when a disk is
> scanned? This
> >>
> >> Adding the boot option automatically when a disk is scanned was sent
> >> separately[1] from this series
> >> since this feature is the matter of the timing of automatic boot
> >> option creation and not directly related
> >> to EFI HTTP Boot.
> >> I also included the fixes of the efi_secboot python test failure.
> >> Sorry for confusing you.
> >>
> >> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20230920084121.1248590-1-masahisa.koj...@linaro.org/
> >>
> >> > code could only look for a boot option with '1234567' in its load
> options
> >> > instead of rescanning all devices with the
> EFI_SIMPLE_FILE_SYSTEM_PROTOCO
> >> > installed
> >>
> >> Now we can scan and load the default file(EFI/BOOT/BOOTAA64.EFI) on the
> fly with
> >> load_default_file_from_blk_dev() function.
> >> The patch #8 of this series "efi_loader: create BlockIo device boot
> >> option" create the boot option
> >> for the block device excluding the logical partition,
> >>
> >> >
> >> > > + efi_status_t ret;
> >> > > + efi_handle_t handle;
> >> > > + struct efi_handler *handler;
> >> > > + struct efi_device_path *file_path;
> >> > > + struct efi_device_path *device_path;
> >> > > +
> >> > > + if (dev_tag_get_ptr(dev, DM_TAG_EFI, (void **))) {
> >> > > + log_warning("DM_TAG_EFI not found\n");
> >> > > + return
